FPGA based A500 accelerator

[Samurai_Crow]

Originally Posted by ex68k

That seems to be pretty cool. Did you find any pictures of this board?
Or is it just a design still?

Looking at his GitHub, it seems he hasn't completed his MiniMig core for it yet.

[ex68k]

Originally Posted by Samurai_Crow

Looking at his GitHub, it seems he hasn't completed his MiniMig core for it yet.

So we will wait. The idea is cool, so you can update the FPGAs when they get faster, the mechanics (joysticks/com/printer/vga/etc.) stays the same ..

[CD32Freak]

Originally Posted by ex68k

That seems to be pretty cool. Did you find any pictures of this board?
Or is it just a design still?

No, not yet, but (s)he has an impressive website dedicated to this board with a BOM and a PCB explorer:
https://ranzbak.nl/

[ex68k]

Originally Posted by CD32Freak

No, not yet, but (s)he has an impressive website dedicated to this board with a BOM and a PCB explorer:
https://ranzbak.nl/

Great! So good luck to him to make it happen!

[VladR]

What a great project! I only now discovered this. Few questions:


1. As of now, the base core is 68EC020 (e.g. including 256 Byte ICache) ?
2. Long-term (say, 2 yrs from now) - is 68EC030 doable (free space-wise) with current FPGA board ?
3. Even later down the line, is 68040 on the roadmap ?

From my understanding, 020 already has 256 Byte Instruction cache, so EC030 core would "only" need 256 Byte data cache (and a burst mode) ?


This thing would definitely run my integer-based SW rasterizer pretty well (85 MHz 68020, mhhmmm - yes please )

[Samurai_Crow]

Originally Posted by Samurai_Crow

TG68.C supports caches but isn't pipelined. The SUSKA 68030 is pipelined with no caches. Maybe someone can figure out how to add caches and a barrel shifter to SUSKA to get up to 040 level performance. It'll need a second pipeline for 060 performance.

I stand by what I said, VladR.

[VladR]

Originally Posted by Samurai_Crow

I stand by what I said, VladR.

I don't follow. Can you elaborate a bit ?

[Samurai_Crow]

@VladR I had quoted post 359. Did the quote not show up?

[ex68k]

Originally Posted by Samurai_Crow

@VladR I had quoted post 359. Did the quote not show up?

No, no quote ;-)


Anyway, fooling with Suska, you are pretty lonely. On the tk68k, plenty of people applying patches.


But the guy who wrote Suska, has other cores too, but (AFAIK) no time to work on them ...

[Samurai_Crow]

Originally Posted by ex68k

No, no quote ;-)


Anyway, fooling with Suska, you are pretty lonely. On the tk68k, plenty of people applying patches.


But the guy who wrote Suska, has other cores too, but (AFAIK) no time to work on them ...

TG68.c looks like patchwork with its lack of pipelining and deeply nested If statements in VHDL. I've looked at TG68.C source. It'll forever be slow without pipelining and that is such an invasive addition that fixing Suska is MUCH easier than having to rewrite TG68 from scratch.

[ex68k]

Originally Posted by Samurai_Crow

TG68.c looks like patchwork with its lack of pipelining and deeply nested If statements in VHDL. I've looked at TG68.C source. It'll forever be slow without pipelining and that is such an invasive addition that fixing Suska is MUCH easier than having to rewrite TG68 from scratch.

I don't disagree with you at all. Suska is nicely written, and could be faster much quicker. But as always, you need somebody who actually does it, and that's what is really missing ;-)

[VladR]

Originally Posted by Samurai_Crow

@VladR I had quoted post 359. Did the quote not show up?

It did, but for whatever reason, instead of answering at least my first 2 questions with a simple yes/no, you have chosen to talk about suska, which from my understanding this project is not based on (and might never be for future major updates, for all we know).



So, let's get back to my first 2 questions:


1. As of now, the base core is 68EC020 (e.g. including 256 Byte ICache) ?
2. Long-term (say, 2 yrs from now) - is 68EC030 doable (free space-wise) with current FPGA board ?

From my understanding, 020 already has 256 Byte Instruction cache, so EC030 core would "only" need 256 Byte data cache (and a burst mode) ?

[robinsonb5]

Originally Posted by VladR

1. As of now, the base core is 68EC020 (e.g. including 256 Byte ICache) ?
2. Long-term (say, 2 yrs from now) - is 68EC030 doable (free space-wise) with current FPGA board ?

From my understanding, 020 already has 256 Byte Instruction cache, so EC030 core would "only" need 256 Byte data cache (and a burst mode) ?

It's best not to think about TG68 as "being" a 68020. It would be more accurate to think of it as being a new CPU core with somewhat-better-than-68020 performance, and mostly binary-compatible with 68020 code (with fixes and improvements being made from time to time.)
You're right that an EC030 only has the extra data cache and burst modes - but those are mostly implementation details and I'd be very surprised if Mike's glue logic around the TG68K doesn't already include both of those.

I think Samurai_Crow's point is that, impressive as the performance Mike's getting might be, it's nearing the limit of what's possible with TG68K (the only avenues for speed improvements are using a faster FPGA and improving the caches), and to go much further in terms of performance one would need to use a CPU core that makes use of pipelining and ultimately superscalar techiques. Those are not things one could realistically "bolt on" to TG68k.

[VladR]

Originally Posted by robinsonb5

It's best not to think about TG68 as "being" a 68020. It would be more accurate to think of it as being a new CPU core with somewhat-better-than-68020 performance, and mostly binary-compatible with 68020 code (with fixes and improvements being made from time to time.)
You're right that an EC030 only has the extra data cache and burst modes - but those are mostly implementation details and I'd be very surprised if Mike's glue logic around the TG68K doesn't already include both of those.

I think Samurai_Crow's point is that, impressive as the performance Mike's getting might be, it's nearing the limit of what's possible with TG68K (the only avenues for speed improvements are using a faster FPGA and improving the caches), and to go much further in terms of performance one would need to use a CPU core that makes use of pipelining and ultimately superscalar techiques. Those are not things one could realistically "bolt on" to TG68k.

Thanks, looks like I missed that this core is based on TG68k. It's been ~20 pages and I spent 3 days browsing through it all, so I guess I missed that info (as important as it is - though I must admit I never heard that particular name before, so it didn't stick).

Then Samurai Crow's post makes sense.

[VladR]

Originally Posted by jbilander

Very nice, can you say anything about the SD drive speed? I know earlier in the thread you talked about a 4-bit SDIO controller being implemented eventually possibly even with DMA. That sounds really promising.

Are you guys aware of the Atari "suska" project? He has implemented a full 030 with instruction set, addressing modes, MMU, cache, pipelined architecture. Called 68K30 but not released publicly, but the 68K30L without MMU is available Open Source under a cern ohl v1.2 license. Also 68000 and 68010 has been implemented as well as many of the Atari custom chips, very impressive.

I wonder how the 68K30L fairs in comparison to TG68 if it would be used in an Amiga?

https://download.experiment-s.de/Configware/

Latest release notes:
https://download.experiment-s.de/Con...leasenotes.txt

This below is taken from the release notes from an earlier version, dec 2015, apparently a fpu 68882 and an 040 is worked on as well, I don't know the status there:

There are two of those ip cores...
One is a fully featured complex instruction set computer (CISC) CPU with 68030 instruction set, addressing modes, memory management unit, instruction and data cache and the coprocessor interface. It is developed in a pipelined architecture. The shifter unit is designed as a barrel shifter with one clock cycle delay. This is the 68K30 version. I will not release this CPU in the near future. Interested people can contact me concerning this IP core.

The other version is a subset of the 68K30 called 68K30L. This ip core features all addressing modes and instructions but does not have MMU, cache and coprocessor interface. The shifter unit is modeled as a convetional shift register with several clock cycles delay. The 68K30F IP core which will implement the 68882 floating point unit seamlessly to the 68K30. This work is in progress. The 68K40 IP core featuring a MC68040 compatible machine.

I'm curious about floating-point implementations you mentioned above.

Are there any other open-source FPU implementations that could be [eventually] used for this project ?

How many FPGA resources (gates) does an FPU consume on the board compared to the TG68 ? 50% or more ?

[Promilus]

@robinsonb5 - I think most ppl are missing the point. TG68 isn't the fastest available softcore running 68k ISA and doesn't pretend to be. It however can (with decent cache to utilize pretty fast SDRAM) outperform both 030@50MHz and even slower 040. And with that said - what is the problem with even faster CPU? It doesn't give anything spectacular to Amiga. Sure, CPU+Fast is pretty nice but you forgot chipset is seriously lagging behind and design from this thread doesn't aim to be vampire competitor at all. To utilize fast CPU you'll have to either support Z3 RTG (which is ok-ish up to 040 level) or softcore RTG on FPGA just like Vampire and Warp1260 does (and as a matter of fact VA2000 and ZZ9000 as well but as a dedicated product for Zorro slot). When it comes to suska - I am somehow confused how they chose OHL. Most softcores are treated rather as software (which makes sense because vhdl or verilog based softcore isn't directly hardware implementation, product of synthesis is). In the end there're plenty of ppl which doesn't really care if they got "fastest possible" classic amiga but rather want to have easy-of-use amiga which runs classic software smoothly and with no incompatibilities. Power hungry users already have either Warp1260 and 560 for those wanting real motorola cpu and Vampire V2 and V4SA for those who don't really care. No matter how fast softcore you'd use with A500/A2000/A600 or A1200 - it won't change the fact base of that machine is damn slow. What would be a gamechanger? E.g. Zynq with Wazp3D accelerated internally on ARM Cortex A9. What else? LiteSATA implementation. What else? Fast WiFi (not ESP32 bound by ~1mbit uart rate of STM32 with Warp or ENC28J60 SPI rate of Vampire). Good software to change speed and compatibility settings. Voltage and temperature monitoring. Things like that - to make things easier to use. For a speed demon I can run a WinUAE and no vampire can match that. MOS and AOS4 users can run with their UAE counterparts as well, more or less seamless (if program uses rtg and system libs). I'd rather see fast 030 speed and low price than 060 speed and high price. I'd rather see low cost enhancements.
@Vlad - FPU isn't all that useful in amiga world. Only apps designed to run on 060-class machines use it often. FPU itself is almost as complex as CPU (when we're talking about 020-class). 060 - CPU is way more complex than FPU but FPU is way more complex than 020.

[ex68k]

FPU can be always emulated, MMU can't be, that's why I am always more interested in the MMU ('30, '40), than the FPU ...

[Promilus]

Maybe so but MMU hasn't got much of use on Amiga either. It's perfectly fine to assume 040 feature level of softcore should include both MMU and FPU. I don't really see a reason for turbocharged 020-like softcore to add MMU or FPU functionality at all unless final design has big enough FPGA with small enough price. And that's something I doubt you can achieve.

[ex68k]

Originally Posted by Promilus

Maybe so but MMU hasn't got much of use on Amiga either. It's perfectly fine to assume 040 feature level of softcore should include both MMU and FPU. I don't really see a reason for turbocharged 020-like softcore to add MMU or FPU functionality at all unless final design has big enough FPGA with small enough price. And that's something I doubt you can achieve.

If somebody will spend the time to make it faster and implement the MMU & FPU & '20 opcodes, he is not thinking about amiga only ;-)



There were plenty of machines out there which used the 68*** cpus, and could use a nice upgrade...

[Promilus]

If somebody will spend the time to make it faster and implement the MMU & FPU & '20 opcodes, he is not thinking about amiga only ;-)

I'd love to meet that someone ... there aren't great many ppl actively getting involved in such enterprise. There are more than enough of those compiling their wishlists. And while I have nothing against wish lists I'm rather skeptical, that allows me to be closer to what I can achieve without being discouraged by failed attempts on something even bigger. Baby steps. I think Mike has to finish design and start pre-production to testers first. Then he'll have time to choose which way to go from now on.