Excitement about NatAmi

[SamuraiCrow]

@Darrin

The reasons the LX board never went to market are as follows:

• The Altera Cyclone III FPGA was too small to hold all of the cores.
• The dual-bus architecture wasn't saturating more than half of the bandwidth of the DDR2 memories.
• The I/O pins could be put to better use with a single memory bus, making the whole thing smaller and cheaper.

The main deal-breaker for the LX board was that the 68050 is a larger core than the LX could hold with all of the rest of the features added to the SuperAGA core.

The MX board design has all of these things corrected and more.  The Cyclone IV chip has nearly twice the capacity of the earlier Cyclone III.

[SamuraiCrow]

Hahahahaha. Good luck sourcing many of those at anything like a reasonable cost. Hell you could probably buy an ARM A8 and emulate 68k faster for significantly less.

Actually the '060 card is 99 MHz.  It's the N68050 softcore that is in the 100+ MHz range.  With opcode fusion any pair of opcodes that can be simplified into a 3 operand instruction will be fused as one opcode internally.  This means that the '050 will compete well per clock vs. an '060.  (Note:  Since the LX board's FPGA was too small to hold both the '050 core and SuperAGA, the MX board prototype will have to be produced before the profiling and testing of the '050 core will be complete.)

Remember that the team gets to buy their systems first for testing purposes.  By the time you can buy the production model, the '050 softcore may be already running 100% performance and the team will be working on the N68070 to be superscalar on top of that.

BTW, if you try to run UAE on an ARM Cortex A8 (such as the Pandora), you'll see that it typically trips over itself and delivers roughly stock A1200 performance.

For the fastest '060 read the clock speed of this and weep:http://www.natami.net/gfx/NAe60F/NAe60F_1.jpg

[SamuraiCrow]

First off, as a member of the Natami team it would be unprofessional of me to allow hopes to get excessively high.  Without a prototype to test on we can't do much profiling.

Secondly, we can test the VHDL code with a simulator so it looks like the N68050 is right on track to be clocked at 133 MHz and to be able to combine instruction sequences internally for one instruction cycle-per-clock execution for most instructions.

Lastly, I think that the "almost ready" figure was a reference to AGA chipset feature set and didn't include the N68050/070 CPU core.  Also, I've mentioned in a previous post that the Natami LX was a prototype and had some performance lapses in it preventing it from going to market.

[SamuraiCrow]

@Belial6

Your perception is correct.  We intend to sell it and keep the source closed.

The problem with the Replay is that it uses a smaller FPGA and therefore won't get the performance of the N68050 or the extension of it, the N68070.  The CPU softcore used by the Replay MiniMig core hardly has any cache at all.

Natami is designed for efficient use of a medium-sized FPGA.  It will have a bigger cache on the CPU core and the ability to combine opcodes such that certain combinations of two opcodes will execute in one clock cycle.

Stay tuned.

[SamuraiCrow]

The hardware-banging functions of the Natami should be well documented by the time of release so updating drivers from the AROS 68k sources should be a simple matter.  At first we'll be using AfaOS though.

[SamuraiCrow]

What sort of compatibility are you looking at? (on par with an 040, for instance)

Can I ask what sorts of issues cropped up?

We're aiming for '030 level compatibility.  The issues that cropped up are in this post.

[SamuraiCrow]

How much 680x0 software is there that won't be compatible with the 030?  In my area, the release of the A600/AOS 2.0, with it's massive incompatibility with the A500 was the last nail in the coffin for the Amiga.  We never even saw A1200's in these parts.

If the 040/060 were just optimizations, and did not add new opcodes, or if the new opcodes were rarely or never used, then anything past the 030 computability would just be an interesting sidenote.

I guess the other question is, are their opcodes in the 68000 that the 68060 cannot run?

You may need WHDLoad to get some games to work on the Natami.  What that program does is allows all of the games supported to run from a hard drive targetting an A1200 with an '030 accelerator and some Fast RAM.

The only code that the 68000 can run that the 68060 cannot is self-modifying code.  The N050 is not superscalar but gains its performance using another method so it should run 68000 code with greater compatibility than that of an '040 or '060.

It is also noteworthy that the '030 has all of the addressing modes and instructions of the '040 and '060 except the inline FPU opcodes.  There were actually opcodes and addressing modes left out of the '040 and '060 for performance reasons that are being added back into the N050.

[SamuraiCrow]

Cheers for the update.

Is there any chance that someone could do something with the NatAmi website and update that to show the current status?

It shouldn't be too long now...  ;-)

Also, the use of AfaOS may be a stale statement but since the AROS Kickstart Replacement Bounty Phase 2 requires some changes in the AROS kernal, it seems likely that we'll have to wait a bit for a free OS to run on the Natami.

[SamuraiCrow]

The natami is a hardware emulation of the amiga architecture? Does this mean it is not a "real" amiga?

It's only as real as you make it.  It's called a NatAmi which stands for Native Amiga.  There's no emulation involved, it's a hardware implementation of the Amiga processors and chipsets brought up-to-date.

It's NOT designed to run Debian Linux 68k or any other OS than what a real Amiga runs.  It's likely that the only way to get other non-Amiga OSs to run on it will require the addition of the optional 68060 processor daughterboard.  It is guaranteed to run AmigaOS and in time, AROS 68k.

[SamuraiCrow]

I'd think if anything, the blitter would be able to run faster, as it's quite a bit simpler a circuit than a CPU on the 68k model. Still, only they can say for sure.

This is a good point. Anyone from Natami care to comment?

My only comment is that from what I gathered from the team, the blitter and all of the chipset functions will be buffered to take full advantage of the DDR2 memories' bandwidth.

This is in contrast to the AGA chipset which didn't even take full advantage of 32-bit page mode.  (32 bits plus page mode was only supported by the display DMAs, audio sampling rates, and sprites.  It wasn't used by the AGA blitter at all despite the fact that it could have made up to 4x speed increase of AGA.)

[SamuraiCrow]

@commodorejohn

Each stage of the blitter is just an and-or-invert gate.  There is less latency for that than for the CPU instruction fetches.  I'd estimate closer to 200+ MHz for the blitter.  Add to that that there is better DMA allocation scheduling than the round-robin hardware scheduler that AGA had and you'll see how much improvements stack up.

@thread

According to Gunnar von Boehn on this thread on the NatAmi website (see seventh post from the bottom), the board layout for the NatAmi MX is complete.  By my guesses, production of the prototype will commence in small quantities for the team to work with soon.  This should speed up the design processes and benchmarks will likely follow.

[SamuraiCrow]

I have not been keeping up with the Natami's progress and did not even know that Jens was working on it (is this the same Jens of Individual Computers that I am thinking of, or another Jens?).

It is a different Jens.  See a picture of Jens Künzer on our contact page.

[SamuraiCrow]

My question is :
Futher down the track when FPGA prices drop will there be a chance to use a ARRIA II or Stratix V as the softcore or would a total redesign be necessary? and what estimated clock speeds could the N050 or N070 be running at ?

Gunnar has already tested some of the functionality on higher-end FPGAs.  The VHDL doesn't require changing and will run faster right out of the box.

I wouldn't be surprised if in two years or so you'll see a new NatAmi 2 design that clocks two to three times as fast and has more room to spare on the FPGA for new functionality.

Also, the 133 MHz figure is for the N68050 on the Cyclone IV.  The actual clock speed of the FPGA will be somewhat faster to allow better performance for the graphics cores.

[SamuraiCrow]

I don't know the answer to that one.  The speed of the memory may be fast enough without a clock bump.

[SamuraiCrow]

Benefit to whom? Most multiprocessing hardware you are likely to see is geared towards SMP. Having identical processor cores, preferably all on the same die, helps simplify everything from hardware cache coherency up to software kernel design.

There was at one time an effort to create a "Robin" core for the NatAmi.  It was to be a 4-threaded RISC machine with 64-bit SIMD clocked at 200 MHz (50 MHz per thread).  We were expecting to be able to use this core for audio mixing and vector processing.

Since we've switched from the LX to the MX design for the mainboard an alternative sidekick core will likely be more conventional and symmetric than first expected due to the capacity of the Cyclone IV being greater and allowing us to reuse some code from the main CPU design.  It won't be pure SMP but will be a more conventional ASMP core than the Robin core was slated to be.  We won't know how to build it until the initial N68050 tests are run on the MX prototypes.