FPGA based A500 accelerator

[Promilus]

Originally Posted by robinsonb5

* Establishing a way of sharing memory between the two CPUs

As far as I was exploring Zynq I see memory controller being in hard processor subsystem domain, FPGA part with 68k softcore can access it through AXI bus iirc. In that aspect both ARM and 68k would be sharing the same memory controller and DMA engine. That's how it is made hardware-wise, software is a bit of the problem, along with the next two points you've made.

Nonetheless there are numerous projects now which involve putting an ARM inside an Amiga in one way, shape or form - since they're there anyway, it would be interesting to find a way to use them.

Warp H7 microcontroller isn't going to be user-programmable from OS. That's one out.
ZZ9000 has SDK available although - since it's ZII/ZIII the number of users won't be high. Plus - Z II needs workarounds to get it working good.
Buffee - although CPU core is quite fast it's also pretty old tech. And even if there was feature of running native code on it that'd only mean 68k concurrent execution would be slowed down. I don't think that's desirable outcome.
PiStorm - here we go with interesting part. PiStorm is basically a way to emulate things on RPi and "fool" AOS it's their own hardware. That gives possibility to get e.g. usb mass storage acting like Amiga hard disk but much faster. AFAIK there's been great progress in that matter. Sooner or later there'd be connectivity (ethernet, wifi), graphics (2d, 3d rtg), maybe codecs (a/v decoding) and unused cores as well. But that's a lot of software emulation to cover... eventually using rpi to emulate whole amiga might be faster and more reliable. So while I do find PiStorm intriguing and I find it to be the one thing I considered in the past I am actually more fond of classical approach for a turbo card. There isn't one true recipe for turbo card which could satisfy all. But I guess in time PiStorm can become pretty good alternative for Vampire V2. And with either Cortex A53 (Rpi3) or A72 (RPi4) being available from AOS3 - well that might be a renaissance of classic amiga co-processor design. I think one way or another ARM will come to AOS and take place above PPC cards. But the point is - will developers find it useful and write apps using it. If it'll only handle mp3 decoding or jpeg decoding or mpeg2 decoding (yes, it can!) ... well that's plenty enough. But it would be a shame if that's all there is to it.

[utri007]

Any change this project to materialize to buyable product?

This has some points over competitors, so please?

[ex68k]

Cancelled?

[digiflip]

@mkstr anynews?

[Lemaru]

So is this now a dead project? Would have been great to see this completed.

[mkstr]

Hi All,

Sorry for my disappearance - I have had some personal stuff going on, and in the meantime PiStorm appears to have rendered this obsolete at much lower overall cost.

I'm no longer in a position to put this into production. However, there seems little point in sitting on the work done so far so I will open source it, probably over Christmas when I have some time to sort the repo out.

The bootable SD interface is potentially useful on its own too, and would fit in a more modest FPGA, although that still needs some more logic to make writes work.

Mike

[AJCopland]

That's great to hear that you'll open source it. A lot of projects just disappear.

Hope the personal stuff is ok.

[Niklas]

I hope the personal stuff is only good things.

About making the accelerator open source.. yay! That's what I hoped for from the beginning. Although PiStorm is very competent and cheap, I am personally more excited by a free and open FPGA accelerator.

Will you be upstreaming any changes to the TG68 project, or are all your additions outside of the processor core?

Either way I look forward to your release.

[Samurai_Crow]

TG68 is small but not pipelined. WF68K30L is pipelined to 4 stages. All it needs are caches, a barrel shifter on the instruction fetcher and a burst-capable memory controller. Only downside: it's not small.

[robinsonb5]

Originally Posted by Samurai_Crow

TG68 is small but not pipelined. WF68K30L is pipelined to 4 stages. All it needs are caches, a barrel shifter on the instruction fetcher and a burst-capable memory controller. Only downside: it's not small.

Has anyone done any benchmarks on this WF68K30L?
It seems to have about 2.5 times the footprint of TG68 - partly because the register file is implemented as logic rather than memory blocks (because it needs 2 read ports and 2 write ports)

[Samurai_Crow]

In its current state, I consider it only partially done. It doesn't include caches in the design and it uses a repeat shifter rather than a barrel shifter in the instruction fetcher. Of course the registered version has these features added.

[mkstr]

I hadn't come across that. My design has caches and a burstable memory controller so it might hook up to it quite effectively. I never made any changes to TG68 - all the performance improvements were in keeping it busy all the time.

[Samurai_Crow]

I'm glad my link helped. If you do make changes, the license requires you to maintain a changelog in a particular source file in VHDL comments. The WF68K30 closed source version (without the L at the end) was for making an Atari Falcon system in FPGAs but I won't hold it against him. After all, it is open source in the L version so you can change it if you like!

[ex68k]

Originally Posted by mkstr

I hadn't come across that. My design has caches and a burstable memory controller so it might hook up to it quite effectively. I never made any changes to TG68 - all the performance improvements were in keeping it busy all the time.

What size of caches did you use?


Any chance to put it up on GIT anytime?


It is Christmas ;-)

[ex68k]

Originally Posted by ex68k

What size of caches did you use?
Any chance to put it up on GIT anytime?
It is Christmas ;-)

Please?
;-)

[Shadowfire]

Originally Posted by robinsonb5

Has anyone done any benchmarks on this WF68K30L?
It seems to have about 2.5 times the footprint of TG68 - partly because the register file is implemented as logic rather than memory blocks (because it needs 2 read ports and 2 write ports)

This is easily converted to memory blocks, as long as you have four dual-port memory blocks available. Split them up into two banks, and just have a single flipflop per register track which bank has the most recent copy of that particular register. Writes to a register from a write port, update that tracking register (and both blocks in that write bank). Reads have a mux which use that tracking register as a selector, and they pick off the outputs of 1 block in each bank.

[mkstr]

Originally Posted by ex68k

Please?
;-)

Still been busy I'm afraid. I was going to port it back to the DE10 nano first (which is what it started out on) because it will be easier for others to build a carrier board for that. The Artix board is a funny shape and hard to wire up.

[ex68k]

Originally Posted by mkstr

Still been busy I'm afraid. I was going to port it back to the DE10 nano first (which is what it started out on) because it will be easier for others to build a carrier board for that. The Artix board is a funny shape and hard to wire up.

I'll take whatever you have or finish ;-)
Have artix, cyclone & lattice here, actually even prefer artix ...


THANKS!

[ex68k]

Hi again, don't worry about cleaning it up for me, figured it out here.
Thanks

[utri007]

Originally Posted by mkstr

I hadn't come across that. My design has caches and a burstable memory controller so it might hook up to it quite effectively. I never made any changes to TG68 - all the performance improvements were in keeping it busy all the time.

Seems that competitors are in dead end? It has happened before, some people announce product and they cancel it when other announce similar products. After all that none of these get released.