Apollo Team announces the Vampire V4

[mikej]

Meanwhile we (FPGAArcade) have a very stable/accurate chipset implementation.

The 68060 daughterboard is about to go to manufacture (pictures at Datastorm next week), and the CM3 compute module approach for CPU emulation looks very promising.

Our new (open source) CPU core continues to develop based on reverse engineering and the Replay main board is being updated with 28nm Spartan7. The current Reply1 board will continue to be supported.

More info on my forum or come chat at Datastorm if you are in Scandinavia.
Cheers,
Mike

[mikej]

Does it have an MMU and FPU?

The 68060 and CM3 softcore does yes. The new hardware core is designed to replace the TG68K and the first priority is accuracy (required for the AtariST demo scene amongst others).  

The fact it goes an order of magnitude faster than the current core in the Spartan7 is a nice bonus when required. We'll see how it develops. For the 68060/MMU/FPU the ARM SOC emulation offers the best price/performance ratio while keeping the rest of the system in the FPGA. I switch back to the internal core when accuracy is important (A1200/600/500 etc). I agree the TG68K is hard to maintain ( I do a lot of it), and it's important for the whole community we have a next gen open source core.

"I am a microchip developer by profession, I know VHDL. There is no chance in hell I could do architectural changes to Gunnar's core. "

So I am (actually a CPU designer). ^^ So, what you are saying is the core is unmaintainable by anybody else? Sounds like some poor design decisions there. Even very complex ARM designs are quite clean and can be maintained, which is a requirement obviously in a commercial environment. What happens to your customers if Gunnar gets bored then?

/Mike

[mikej]

The verb is singular but you mention two things to go along with it? What is the CM3 softcore? Farther below you mention an ARM SOC, so are you referring to some ordinary microcontroller running some qemu-type software CPU emulator?     You are a CPU designer and yet compare the complexity of a clean and orthogonal RISC architecture to that of the 68k?      Rest assured that Gunnar knows the requirements of the commercial environment. He has designed parts of the POWER8 and recently of some ARMv8 processor.

The 68060 clearly contains both. The CM3 is a Rasp Pi ARM SOC
http://www.fpgaarcade.com/punbb/viewtopic.php?id=1221

We are experimenting with a CPU running an emulation for the 68K processor.  It's pretty good at this. Given there is a massive open source effort here, they are pretty refined - and we don't care about the cycle timing as long as it's fast. The rest of the chipset is still held in the FPGA, so all the timing critical video stuff is spot on - and the CPU can get on with it's stuff. Very Fast. It also has build in "fast" memory, and an HDMI for RTG etc.

"clean and orthogonal RISC architecture to that of the 68k? "
No, I'm asking why Gunnar's implementation is difficult to maintain.

The 68000 die is extremely simple and elegant actually, the complexity being in the microcoding.
/Mike

[mikej]

OK, so there is no new open-source 68k softcore. .

Yes, there will be, based on the layout extraction. Initially targeted as a very accurate 68000 replacement, but will be expanded to 68020 asap and replace the TG68K. Meanwhile the 68060 real CPU and CM3 projects cover the top end.

/MikeJ

[mikej]

Layout extraction? So you are going to do a Register-Transfer Level clone of the 68000? While that is interesting from a tech-archaeological point of view, how do you think such a "core" could be expanded for higher speed, newer architecture, superscalarity and so on? The only practical way to improve the outcome of the layout extraction would be to clock it faster than it was in the original silicon. The 080 already reaches the speed of a GHz 020 in a consumer level FPGA, though. No current FPGA could reach those speeds let alone the fact that you would somehow have to get the "core" to interoperate with more recent peripherals such as DDR3 RAM and the like. I wouldn't want to dig through a network of flip-flops and logic gates and try add a more modern memory controller...

It's done. I'm using the layout to understand the low level operation. A lot of the quirks arise from the way it's built. This allows us to build a clean(er) implementation which fits nicely within our current FPGA SOC.

[mikej]

That's all certainly nice as an academic exercise, but why does it help the end user to address his computing/emulation needs?

We end up with a more accurate, open source, 68000/20 FPGA soft core - and potentially a faster one as well.

[mikej]

thats what i proposed for years. i hope all the best for your project. however it is completely different approach than gunnar and apollo team. and its a bit misleading, not to mention the obsious differences. also im not sure if mmu can be run with jit, which, if enabled, would certainly cripple the performance below that of apollo core. emulating 040 on a fast pc without jit doesnt reach integer performance of apollo core in current vampire hardware implementation.

MMU is problematic with jit correct.
With jit, and note the ARM is Only emulating the CPU core, it flies. And its a ~$25 BOM cost.

We are aiming for different things here, my model is something like an A1200 with a fast accelerator card and RTG plugged in.

[mikej]

Hold on. If that's the goal, why do you start with the 68000 design in first place? It's purely microcode-based, and certainly completely outdated. If you'd want a "fast" 68000 design, why not start with a better performing member of the family?

I need a cycle accurate 68000. I can extend this to 68020 and faster performance, but I think ARM emulation for the CPU core is the way to go for 68060/MMU/FPU etc.

[mikej]

"Go ahead with your project, it will certainly find its market. "

Why thank you, I'm sure it will.

[mikej]

@mikej

You looked familiar...

I only just put two and two together.

Lol. I've been quiet (and busy).

This is the image map of the netlist the tools are running. Credit to Oliver Galibert for the hard work.

http://fpgaarcade.com/68k/

Data IO pins are round the bottom. Op-code flows bottom left to right then up through the microcode on the RHS of the die.
The A and D registers are the vertical strips on the left, along with a very simple ALU slice.
/Mike