[UserReview] Vampire V2-128 received and it's just pure p0rn.

[mikej]

Obviously this leads to a future standalone Vampire Amiga - FPGA and RAM and I/O - in the same lines as MiniMig, Mist and FpgaArcade. Maybe in a couple of years? I guess the clue's in the name here, Vampire :-)

Accurate chipset cloaning is very time consuming. If they are to make a standalone board without using open source code, then they have a lot of work ahead of them. The downside of using GPL code is then they must release the CPU source as well, which seems unlikely. Perhaps they have already done all this groundwork from the Natami days.

The open source CPU is catching up - it will be interesting to see side by side comparisons for a real use case with the Replay (FPGAArcade board). Sure the Apollo core is faster, but I prefer being able to slow down and accurately run the A500/A1200 and Atari software as well when required.

/MikeJ

[mikej]

The "Free RTG SAGA Driver" is a P96 card driver. I just had a quick look through and compared it to mine.


"Does the apollo core need a patched exec.library or not?
The current version does, due to its inability to implement autoconfig for its on-board RAM. "

Replay doesn't

[mikej]

.... fpga arcade has been announced to be open as example. are they paying license fees for their p96 driver by the way? ao why is gunnar getting all the flak again;)

Yes, firmware and a lot of the hardware is open now, including the T68 CPU changes Till and I have been working on (as required by the license). The rest will be shortly once I've finished tidying it up. I'm rolling back some bits I haven't changed much to align with the MIST codebase, then we can share debug resources. I expect the open source CPU to get to 30-40K Dhrystones, which feels pretty speedy running classic systems. If you want to run a more recent OS, I suggest a RasPI3 will run it far better and cheaper than any FPGA solution. I'm far more interested in accurately cloaning and preserving the old hardware.

I have always been keen to find a fair licensing solution, but the old model of a fee per board is not appropriate for a generic platform such as Replay. I also got the feeling certain parties were trying to hold the remaining community hostage, and milk it for whatever they could get.

Like the Apollo driver, mine is built from the UAE driver and P96 public header files. I have support for hardware sprites and a dedicated blitter, but these are trivial from a software perspective.

I've tried to approach the authors, and all I got back was a "we'll get back to you". I assumed they had already come to a deal elsewhere.

/MikeJ

[mikej]

Some general comments on the CPU technology. I have had no direct contact with Gunnar, these are my own views.

The T68K opensource CPU we use in FPGAArcade and Mist runs at 28MHz single cycle when using I&D cache (in replay at least). If I was to build this on a Kintex ultrascale+ 16nm device (which are relatively cheap now) I'm pretty sure it would run at the base clock of 114MHz -  which would give it similar performance to the Apollo core for zero effort. I'll try this next week.

With some pipeline efforts which are going on, and new table based designs, 3-4x increase is perhaps possible. An opensource MMU may come at some point. These will likely be licensed under the GPL which would not enable them to be used with a closed source core.

Now - I'm putting on my ASIC manager hat. As a day job I work for a mature startup designing big endian CPUs for telecoms use (!).

I have use of the very expensive Cadence tools used for ASIC layout, and a team of people who can build these things. Even given all this, the numbers don't work out. To fab out a 28nm ASIC the mask costs are horrific.

You could try and find a fab which still made 90nm or even older nodes, and yes these are cheaper, but to be honest a 16nm finfet FPGA will be faster - and cheaper per unit part.

I've sourced IP for ASIC as well. When doing this, you need to be very very sure of your supplier and that you will not run into any GPL or licensing issues down the road. There are several suppliers selling highly tested, ASIC proven 68K class cores on the market already today.

If you want a 1-2GHz big endian CPU, people tend to use QoiIQ (PPC) which is cheap in volume and a complete SOC (memory controller, Ethernet, PCIe etc etc).

I really wish Gunnar well with his project, it's certainly a lot of work, but I don't believe it's going to end up as an ASIC.
/MikeJ

[mikej]

It's about performance per USD or €. Gunnar mentioned that he has some Stratix boards available. So what performance could we expect from them? It doesn't really matter as it would be pointless to put a 10,000 USD FPGA on an Amiga accelerator. How much do FPGAArcade and Mist cost and how does their 68k performance compare to the 150€ vampire?

But let us hear about your results.

Aren't you using GPL'ed stuff and thus have to open-source your modifications anyway?

It's not very likely, yes. That doesn't mean that this possibility should be killed from the start by open-sourcing the project.

Grond - good comments on the RTG earlier by the way, nice to see a reasoned argument for a change.

FPGAArcade Replay board is 199Euro+tax. Currently synthetic performance (benchmarks) is about 1/6th, but we should get to 1/4 to 1/3 of the Apollo core. We need to change to a pipelined architecture to increase performance further. I've had such a core going for years, but it's been easier to debug the T68K so far. System performance is quite speedy - the board has fast hard disk, blitter for RTG etc so it feels faster than the numbers would suggest.

Small modern FPGAs are quite cheap, we are talking more in the 50USD range than 10K.

I am not a fan of the GPL license for hardware - my stuff is usually licensed under a "do what you like style" - and yes it's open. As I am using the T68K core which is GPL, I release any modifications to that immediately (svn.fpgaarcde.com) and I must release the rest of the design - although not necessarily under the same license. The Amiga core is partially released now (I've send files to the Mist team), I'm awaiting some advice on modifying my usual license to prevent use in completely closed source designs.

I have no problem with Gunnar not open-sourcing his code, and I get extremely irritated by people demanding I open source everything as "we have a right to see it" - go write your own.

"Mist and Vampire use the same Cyclone 3 FPGA. Mist runs at 28MHz on it when Apollo runs at 100MHz. Running Apollo on Kintex would probably lead to something in the 800MHz range"

It doesn't quite work like that. Apollo has been pipelined but those benefits do not really carry through to smaller geoms - you run into routing delays etc. I would guess 200-300MHz absolute max.

Even with 28nm ASIC you have to work a bit to get much above 500MHz.
/MikeJ

[mikej]

As a person who worked a lot with TG68 I think that I know a lot about it. Only thing I ll say is that TG68 have nice feature to be able to run at higher speeds and shows some nice results. Too bad that in real life we can consider those results as a fake. Maybe bustest can prove me wrong.

Hi Majsta. Not quite sure I understand what you mean?

Even with the cache logic around the TG68, I don't have any problems (now) getting 28MHz out of it. Executes in single cycle. P&R takes around 3 mins.

Going much faster with the current design on the Spartan FPGA is not going to happen without pipelining it, true.

I'm rebuilding my laptop for some Kintex+ development, I'll give it a run though and see what speed we get.

If Gunnar sends the Apollo code (under NDA obviously) I'll run it through the ASIC toolchain and we can see the predicted performance with TSMC 28nm?
/MikeJ

[mikej]

Maybe bustest can prove me wrong.

READL is about 29MB/sec - but I've yet to finish the 32 bit changes to TG68 (The CPU data bus is 16 bit, cache is 128 bit).

I expect to get to around 60MB/sec which is comparable to a 68060.

[mikej]

At the time, 3 years ago I had best result with TG68 and I think that no one were able to beat it yet. Those results regarding bustest are exactly 12X lower than slowest compiled version of Apollo is capable of. In standalone system I m making now according to calculations we will double Apollo performance. Exact reason why I stopped messing with TG68...

I guess you had not written a cache ?
/MikeJ

[mikej]

I saw the tg68 vhdl about a year ago and  even just judging from the code size it is the bare minimum for making  it execute 68k code. I guess the apollo code is several dozen times  bigger, if not 100s of times. Heck, I bet there are more signal  declarations in apollo than tg68 has lines of code! Gunnar and the  others making the apollo core are professional CPU designers and have  been working on the apollo core for seven years!

Hi,
I think you miss understand me a little. I am not suggesting the TG68 will out perform the Apollo core, I am saying then if targeted to a more modern FPGA it will get similar performance for little effort.

I too am an ASIC CPU designer b.t.w.

"But it would be a very, very, very long way for the tg68 core to surpass what actual Amigas could do in 1994. "

It already is petty much, and as I said complete system compatibility is more important to me. I'm sure I could run the a software 68K emulator on a 10$ SOC and surpass the performance of the Apollo core without all the effort. If the CPU core is faster, then what is the difference between an FPGA CPU and an emulated on a different CPU, CPU? Especially if the rest of the hardware is still FPGA based?

http://www.xilinx.com/support/documentation/selection-guides/zynq-ultrascale-plus-product-selection-guide.pdf

Quad core 1.5GHz ARM +16nm FPGA fabric?

/MikeJ

[mikej]

"This is a hare and tortoise type argument. When you put tg68 in a faster FPGA to narrow the gap to apollo, apollo will already be in that faster FPGA and again far ahead of you."

The gap will  be narrower. As I said the routing delays become similar to the logic delay. I'll run some tests next week.

"Actual Amigas" meant 060 and graphics cards.

Yup, we have a HD capable graphics card with dedicated blitter, and ~ 060 performance (sans MMU and FPU) already.

Anyhow, best of luck with the roll out.
/MikeJ

[mikej]

But right now it doesn't sound like a convincing approach to have a more expensive product which has less processing power than your competition and then trying to solve this by putting in a more expensive component.

It's slightly more expensive, but it is the complete system. It's also a bit more than a one-trick-pony, so to speak. Who said the newer FPGA would be more expensive than the current one?

"The 060 has fast caches, you still need to add those."

I have full I & D cache with full bus snooping and prefetch already.

"For us the adoom fps is a standard test because it is more interesting than just some sysinfo MIPS."

For sure, I'll give it a go. If I want to play adoom at silly speeds however, I'll dig out UAE and run it on the PI.

"BTW, does the fact that you didn't say anything about the offer to try to maintain compatibility between the apollo core and the fpgaarcade's implementation of AGA and 68k that you are going to consider it?"

If the Apollo core adds non-standard instructions then it's no longer "retro" and of little interest (to me at least) to emulate. The beauty of open source is that it's an option open at any time of course.
/MikeJ

[mikej]

OK, I understand that. How about stuff like device drivers? I think that's something where both strictly retro and enhanced retro implementations can benefit from cooperation. Our device drivers will be open.

I so no reason not to. My RTG driver will be open too. I have a licensed USB stack so binaries only for that at the moment.

[mikej]

If I supply people with the software to program a off the self board for free, I don't see a need for license or re-license. I see nothing about license in this board or cheaper 40 buck dev-boaards!?  http://www.robotshop.com/en/nexys4-ddr-artix-7-fpga-board.html?gclid=CIyjzvj3vdICFQkMaQod4UQFAA

The reason I designed the FPGAArcade Replay board was non of the off-the-shelf boards were suitable. They also have a short lifetime.

Despite the problems I had with supply, making the board is the easy part. The FPGA and firmware design is a big task. The idea with the Replay system is that both software and hardware components can be re-used between cores - and this is starting to pay off now.