Terrible Fire Accelerators

[plasmab]

For all the doubters I have the CPU running at 60mhz... however I've exceeded the speed capabilities of the ram cpld :/


Sent from my iPhone using Tapatalk

[Mr.Flibble]

Nice work, certainly proves the design though.

[Chucky]

Originally Posted by plasmab

For all the doubters I have the CPU running at 60mhz... however I've exceeded the speed capabilities of the ram cpld :/


Sent from my iPhone using Tapatalk

Any way of introducing waitstates? (hey. stupid.. I know. but for all those MHz hunters.. )

[plasmab]

Yeah. Unfortunately you actually get worse performance lol. Only 9 mips. Would be fine if the 030 had bigger caches


Sent from my iPhone using Tapatalk

[plasmab]

I've always followed the acorn philosophy that maxing RAM and lower MHz is more stable, cooler and performs just as well..


Sent from my iPhone using Tapatalk

[kgc210]

Glad you are still working on these boards, really need to get round to catching up on your videos and still need to pull my finger out and build them TF520 boards I got.
Just been that busy!

Will

[plasmab]

Reached the limit with the Rev2. I can make the CPU go faster but at 48mhz it's managing zero wait on the RAM. It's past 60Mhz before you make up for the wait states again.


Sent from my iPhone using Tapatalk

[wolfchild]

Amazing work plasmab!

Out of curiosity, what is it that mandates the use of wait states? Is it the RAM access time, or the CPLD speed grade? I believe there is a variant of the CPLD with just 5ns delay.

Keep up the great work man!

Ed

[plasmab]

I plan to try a faster cpld in the rev 3 when they arrive. It's a combination of all of the things you mentioned... were close to the combined timing limits. But are we really getting anything of value pushing past 50 MHz?


Sent from my iPhone using Tapatalk

[wolfchild]

Some things have no value, but they are priceless. Yours is probably the fastest an Amiga 030 has ever been at. All traditional designs are hampered down by old tech memory, while the TF530 is probably approaching the 030's theoretical maximum performance. No one else who has been exploring these speed boundaries on the Amiga has openly published their findings.

[matthey]

Originally Posted by plasmab

I plan to try a faster cpld in the rev 3 when they arrive. It's a combination of all of the things you mentioned... were close to the combined timing limits. But are we really getting anything of value pushing past 50 MHz?

You are if you push past a 68030. My 68060@75MHz CSMKIII with 50ns SIMMs and fastest memory settings is super fast. It really helps to keep everything close and the 68060 has enough on chip caches for good performance. Modern memory and support for clock speeds which a revision 6 68060 can handle would be even more fun and interesting .

[plasmab]

I think Jens has a faster 1200 030


Sent from my iPhone using Tapatalk

[plasmab]

Originally Posted by matthey

You are if you push past a 68030. My 68060@75MHz CSMKIII with 50ns SIMMs and fastest memory settings is super fast. It really helps to keep everything close and the 68060 has enough on chip caches for good performance. Modern memory and support for clock speeds which a revision 6 68060 can handle would be even more fun and interesting .

Absolutely agree. But we have a 68030 here.

EDIT: The RAM on the TF530 eats modern DRAM for breakfast still.

[wolfchild]

ab;1157715]I think Jens has a faster 1200 030 [/QUOTE]
True, Jens has provided all info here, along with AIBB comparison files.
http://wiki.icomp.de/wiki/ACA1232#ACA_12xx_Benchmarks

The TF530 is up with there with the best, speed wise...

[plasmab]

Originally Posted by wolfchild

ab;1157715]I think Jens has a faster 1200 030

True, Jens has provided all info here, along with AIBB comparison files.
http://wiki.icomp.de/wiki/ACA1232#ACA_12xx_Benchmarks

The TF530 is up with there with the best, speed wise...[/QUOTE]

Thanks. IIRC Jen's card manages to make use of burst mode. I tried to leave myself the option of this but i made a mistake with the A2-A3 address lines. These signals to RAM need to be separated from the main CPU address lines when doing burst it seems. I had hoped the CPU would get out of the way but it doesnt. Little fix for next time.

[wXR]

Originally Posted by plasmab

I understand why you might think that but I invite you to try it once i push the sources.. should do that later this week.

https://koolrpix.files.wordpress.com...who_da_man.png

[hooverphonique]

Originally Posted by plasmab

Absolutely agree. But we have a 68030 here.

EDIT: The RAM on the TF530 eats modern DRAM for breakfast still.

Indeed.. That's one of the reasons I think making burst mode work is probably not going to make much difference (I think you mentioned somewhere you would take a look at that). If you were using paged memory (e.g. dram) on the other hand...

[plasmab]

Sent from my iPhone using Tapatalk

[matthey]

Originally Posted by hooverphonique

Indeed.. That's one of the reasons I think making burst mode work is probably not going to make much difference (I think you mentioned somewhere you would take a look at that). If you were using paged memory (e.g. dram) on the other hand...

I expect burst mode would be good for the ICache as it is a sequential stream with most of the data from a cache line burst being used. A lot of DCache reads are random accesses which only use part of the data in a cache line and a 256 byte DCache means it is common for data not to be reused. There was a conversation about 68030 burst here on eab.

http://eab.abime.net/showthread.php?t=74060

It would be interesting to compare results with DCache burst on and off for a variety of benchmarks. SRAM acts like a L2 cache so results may vary from other 68030 accelerators.

[plasmab]

Keep in mind that with the TF530 RAM i *should* be able to fill a cache line in 5 clock cycles. @50Mhz that is 100ns elapsed time. Being able to keep a slow cpu fed is key to getting every last inch of performance. Slap 4-8Mb of this on and its going to be interesting.

Thats about the same total time as a single access in "normal" fastram when you add up the fluff at the start and end of the bus cycles.