»

[lou_dias]

166 * 7 = 1162

If so, I think even I would have preferred 200 * 5.5...

[mbrantley]

Originally Posted by Jupp3

I have wondered this way too often. So could you (or anyone else) finally explain to me, how does software emulation (UAE) become "hardware support", when basically the same SOFTWARE is running on a different kind of chip (FPGA instead of "generic" processor)?

I'll let a FPGA guru tackle the meat of that, and I'm not one.

But what I'm after is seamless emulation alongside native software so that I can't tell when it's native or emulated. Apple did this with two different architecture changes (68K to PPC and later PPC to Intel).

After this past weekend (and thanks to the assistance of number6), I have ADPro working pretty well in AOS4, and there is nothing that telegraphs to me that I'm not running native code. Seamless integration. On my Sam and with AOS4, LightWave is the same except it lacks the necessary emulation or hardware to handle the chipset work on the preview animations.

And when I'm running UAE (even with the excellent RunInUAE by Chris), it isn't really seamless.

But... this thread is focused in another direction and I guess we're straying a bit. But the subject is a worthwhile one, I think

[Hans_]

Originally Posted by Jupp3

I have wondered this way too often. So could you (or anyone else) finally explain to me, how does software emulation (UAE) become "hardware support", when basically the same SOFTWARE is running on a different kind of chip (FPGA instead of "generic" processor)?

Because an FPGA doesn't run any software; it is not a CPU. FPGA stands for Field Programmable Gate Array. These devices are essentially a large array of gates with programmable interconnects. On power up these devices read in a bitstream that enables or disables interconnects between individual gates. Once this is done, the gate array operates as whatever circuit has been programmed in. It does not execute code (unless the circuit that has been programmed in is a CPU). There's more to it than that, but that's the basics.

So, you program a hardware design into an FPGA, not a software program. This array of interconnected logic gates could also be put into an ASIC, or form the basis for a fully custom integrated circuit. The bottom line is that it's a hardware design.

This is why I think that it's wrong to call something like Minimig an emulator. It's a hardware reimplementation of the Amiga OCS chipset.

Hans

[mbrantley]

Cool. Thanks, Hans, for the great explanation.

[minator]

Originally Posted by lou_dias

Probably but not everything is appropriate for such things. If Altivec was the be-all-end-all of application performance, don't you think all chips would have it...

They do.
All desktop processors have some form of vector processors included.
Many of Freescale's embedded chips have vector units (not necessarily AltiVec).

Fast branch prediction and OoO execution are more generally useful... Even the GC and Wii have SIMD...can you explain to me how that will make your email download faster? Surfing? How does your favorite text editor benefit from SIMD? It doesn't.

Do you do search and replace? spell checking? They can both be accelerated.

SIMD has niche use.

Wrong: Look up Libfreevec, it accelerates many basic functions.

Let's see some real-world benchmarks before denouncing the SAM460... The G5 Macs only got up to DDR2-533, iirc. If this board can support DDR2-800 and higher, then real-world benchmarks will get interesting...

They been decidedly unimpressive so far. No sure why, could be it's not set up right.

[minator]

BTW the reason some CPUs don't have vector units it generally cost. Something like AltiVec is quite big and takes up a lot of silicon. Cost is king in the embedded world so low end chips don't get it.

[m3x]

Originally Posted by Piru

@m3x

It appears that Sam460 runs the AMCC460 slightly (15%) overclocked. Is this similar to the overclocked 440 models where the memory bus is slightly underclocked? Does this explain why 7447 166MHz DDR-333 memory interface appears to be faster than Sam460 DDR2-400 memory interface?

You have some information slight wrong and outdated

On the Sam440ep models, the DDR runs at the nominal speed (133 Mhz) on the 667 Mhz and 800 models, and run overclocked on the 733 Mhz model (147 Mhz)
There is a pci-update which overclock the PCI unit on the SoC, but due constraints in the internal multipliers, is not possibile to overclock both DDR and PCI unit, and thus on this model the user may choose to keep the original setup or to overclock the PCI unit.

On the Sam460ex the DDR is overclocked as the CPU. The reason why right now the reported speed is somewhat low is due the very conservative setup done by U-Boot, and because APM is still updating their autoconfig code.

I was able to enhance the speed just recently and now the figures are as follow:

Read: 350 MB/s - Write: 560 MB/s

Next U-Boot versions for our board will include modifications on the DDR config code to achive higher speed transfers.

[Piru]

Originally Posted by m3x

You have some information slight wrong and outdated

On the Sam440ep models, the DDR runs at the nominal speed (133 Mhz) on the 667 Mhz and 800 models, and run overclocked on the 733 Mhz model (147 Mhz)
There is a pci-update which overclock the PCI unit on the SoC, but due constraints in the internal multipliers, is not possibile to overclock both DDR and PCI unit, and thus on this model the user may choose to keep the original setup or to overclock the PCI unit.

On the Sam460ex the DDR is overclocked as the CPU. The reason why right now the reported speed is somewhat low is due the very conservative setup done by U-Boot, and because APM is still updating their autoconfig code.

I was able to enhance the speed just recently and now the figures are as follow:

Read: 350 MB/s - Write: 560 MB/s

Next U-Boot versions for our board will include modifications on the DDR config code to achive higher speed transfers.

Thanks for the info. Still slower than 7447 166MHz bus + DDR though

[Karlos]

Since we're bus-performance willy-waving...

Originally Posted by Piru

Still slower than 7447 166MHz bus + DDR though

Which in turn is far slower than my (now entirely outdated) Core2 Q9450 1333MHz FSB + dual channel DDR3 (with suitably evil 6-6-6 config). Then again, it is totally eclipsed by the 104GB/s VRAM to VRAM (ie transfer, not just read or write) bandwidth of the GPU. Which is again rather eclipsed by the latest cards.

-edit-

Although, I better be careful what I say about bus-performance. I might wake up Shaun

[stevieu]

Originally Posted by Karlos

Since we're bus-performance willy-waving...

Which in turn is far slower than my (now entirely outdated) Core2 Q9450 1333MHz FSB + dual channel DDR3 (with suitably evil 6-6-6 config). Then again, it is totally eclipsed by the 104GB/s VRAM to VRAM (ie transfer, not just read or write) bandwidth of the GPU. Which is again rather eclipsed by the latest cards.

-edit-

Although, I better be careful what I say about bus-performance. I might wake up Shaun

My 'ego' is starting to dent now, as I keep being reminded that my i7 920 setup is hardly the 'fastest'.

Rationale kicks in though and I am reminded that it will last me a good while yet.

Only (military spec) Amigaaaaaaa(s) make(s) it possible! >;D

Steve

[Iggy]

Originally Posted by Piru

Thanks for the info. Still slower than 7447 166MHz bus + DDR though

Actually its about the speed of my PC133 7447A equipped Quicksilver, which does make it surprisingly slow.

[TheDaddy]

X86 machines and an old mac...which in turn are slower than a quantum computer

[DAX]

As usuasl Acube will keep updating everything continuosly (which will also bring in performance improvements) which is great
Thanks for another real HW product

[mbrantley]

Originally Posted by m3x

Next U-Boot versions for our board will include modifications on the DDR config code to achive higher speed transfers.

Great to hear, Max. Keep on tweaking!