Welcome, Guest. Please login or register.

Author Topic: Apollo Team announces the Vampire V4  (Read 68564 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline mikej

  • Hero Member
  • *****
  • Join Date: Dec 2005
  • Posts: 822
    • Show only replies by mikej
    • http://www.fpgaarcade.com
Re: Apollo Team announces the Vampire V4
« Reply #329 from previous page: August 25, 2017, 12:45:15 PM »
Quote from: grond;829984
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
 

Offline grond

  • Full Member
  • ***
  • Join Date: Feb 2016
  • Posts: 154
    • Show only replies by grond
Re: Apollo Team announces the Vampire V4
« Reply #330 on: August 25, 2017, 01:04:37 PM »
Quote from: mikej;829985
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.
 OK, so there is no new open-source 68k softcore. A pretty good software emulator has been around for quite a while even though its CPU emulator isn't 100% bugfree and thus incompatible (yuck!): WinUAE.  
Quote
No, I'm asking why Gunnar's implementation is difficult to maintain.

For the same reason the LHC is difficult to build and maintain: it's complicated.  
Quote
The 68000 die is extremely simple and elegant actually, the complexity being in the microcoding.
/Mike

Um, yes. The 68k family didn't end with the 68000. And 8 or 16 MHz and an IPC of something like 0.25 doesn't cut it today. Having all flags available for the subsequent instruction to evaluate and executing several such instructions in the same cycle along with the complex address modes available for each of the instruction is something that makes the 68k a few orders of magnitude more complicated than an ARM.
 

Offline kolla

Re: Apollo Team announces the Vampire V4
« Reply #331 on: August 25, 2017, 01:18:24 PM »
Quote from: psxphill;829978

It's simple. He is only wasting scarce resources on developing SAGA because he can't use code from minimig/replay because he's keeping apollo closed source for his intended commercial use.


SAGA is supposed to be open sourced at some point, maybe you can find a fitting speculation as for why that is? :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline mikej

  • Hero Member
  • *****
  • Join Date: Dec 2005
  • Posts: 822
    • Show only replies by mikej
    • http://www.fpgaarcade.com
Re: Apollo Team announces the Vampire V4
« Reply #332 on: August 25, 2017, 01:18:53 PM »
Quote from: grond;829986
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
 

Offline grond

  • Full Member
  • ***
  • Join Date: Feb 2016
  • Posts: 154
    • Show only replies by grond
Re: Apollo Team announces the Vampire V4
« Reply #333 on: August 25, 2017, 01:25:44 PM »
Quote from: mikej;829988
Yes, there will be, based on the layout extraction. Initially targeted as a very accurate 68000 replacement, but will be expanded to 68020 asap

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...
 

guest11527

  • Guest
Re: Apollo Team announces the Vampire V4
« Reply #334 on: August 25, 2017, 01:27:13 PM »
Quote from: grond;829986
OK, so there is no new open-source 68k softcore. A pretty good software emulator has been around for quite a while even though its CPU emulator isn't 100% bugfree and thus incompatible (yuck!): WinUAE.  
Presumably, Tony is doing is best to get the bugs out. However, bugs are normal, and I wouldn't be surprised if the Apollo core also has bugs, too, given that all the mot processors had some issues here and there.

The problems I see with software emulation are not really bugs. Bugs happen, such is life.

The problem I see is inconsistent performance. On eUAE, I see situations where the emulator crawls so slowly it is simply unusable, while a couple of moments later at a different task it runs ahead at light speed. This is simply not acceptable for a good quality of experience.

WinUAE: well, it runs on Windows. I don't have Windows, and I don't pay Microsoft to be able to emuate an Amiga. I already have a perfectly working Os, without spyware, thank you.

Quote from: grond;829986
Having all flags available for the subsequent instruction to evaluate and executing several such instructions in the same cycle along with the complex address modes available for each of the instruction is something that makes the 68k a few orders of magnitude more complicated than an ARM.
Hard to judge from here. It seems that the Apollo core is an out-of-order design which is necessarily more complicated, and there aren't many people around that know how to design such beasts. So yes, I have no doubt that Gunnar knows his business. I can hardly judge.
 

Offline mikej

  • Hero Member
  • *****
  • Join Date: Dec 2005
  • Posts: 822
    • Show only replies by mikej
    • http://www.fpgaarcade.com
Re: Apollo Team announces the Vampire V4
« Reply #335 on: August 25, 2017, 01:33:33 PM »
Quote from: grond;829990
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.
 

guest11527

  • Guest
Re: Apollo Team announces the Vampire V4
« Reply #336 on: August 25, 2017, 01:45:28 PM »
Quote from: mikej;829993
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.

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

Offline mikej

  • Hero Member
  • *****
  • Join Date: Dec 2005
  • Posts: 822
    • Show only replies by mikej
    • http://www.fpgaarcade.com
Re: Apollo Team announces the Vampire V4
« Reply #337 on: August 25, 2017, 01:55:55 PM »
Quote from: Thomas Richter;829995
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.
 

Offline grond

  • Full Member
  • ***
  • Join Date: Feb 2016
  • Posts: 154
    • Show only replies by grond
Re: Apollo Team announces the Vampire V4
« Reply #338 on: August 25, 2017, 02:04:42 PM »
Quote from: Thomas Richter;829991
Presumably, Tony is doing is best to get the bugs out. However, bugs are normal, and I wouldn't be surprised if the Apollo core also has bugs, too, given that all the mot processors had some issues here and there.

Sure. And we have reported bugs we found in UAE which we use for comparison with what the 080 does. All well.  
Quote
The problem I see is inconsistent performance. On eUAE, I see situations where the emulator crawls so slowly it is simply unusable, while a couple of moments later at a different task it runs ahead at light speed. This is simply not acceptable for a good quality of experience.

I totally agree!  
Quote
WinUAE: well, it runs on Windows. I don't have Windows, and I don't pay Microsoft to be able to emuate an Amiga. I already have a perfectly working Os, without spyware, thank you.

I don't have any Windows either. But I understand that WinUAE is the mother-of-all-UAEs today.  
Quote
It seems that the Apollo core is an out-of-order design

No, it is still in-order but already very complex. ooo would be another order of magnitude more complex.
 

Offline grond

  • Full Member
  • ***
  • Join Date: Feb 2016
  • Posts: 154
    • Show only replies by grond
Re: Apollo Team announces the Vampire V4
« Reply #339 on: August 25, 2017, 02:07:49 PM »
Quote from: mikej;829996
We end up with a more accurate, open source, 68000/20 FPGA soft core - and potentially a faster one as well.

Faster than what?
 

Offline wawrzon

Re: Apollo Team announces the Vampire V4
« Reply #340 on: August 25, 2017, 02:16:59 PM »
Quote from: mikej;829985
We are experimenting with a CPU running an emulation for the 68K processor.

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.
 

guest11527

  • Guest
Re: Apollo Team announces the Vampire V4
« Reply #341 on: August 25, 2017, 02:19:06 PM »
Quote from: mikej;829996
We end up with a more accurate, open source, 68000/20 FPGA soft core - and potentially a faster one as well.
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?
 

Offline mikej

  • Hero Member
  • *****
  • Join Date: Dec 2005
  • Posts: 822
    • Show only replies by mikej
    • http://www.fpgaarcade.com
Re: Apollo Team announces the Vampire V4
« Reply #342 on: August 25, 2017, 02:22:37 PM »
Quote from: wawrzon;830000
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.
 

Offline wawrzon

Re: Apollo Team announces the Vampire V4
« Reply #343 on: August 25, 2017, 02:23:18 PM »
Quote from: Thomas Richter;829991
WinUAE: well, it runs on Windows. I don't have Windows, and I don't pay Microsoft to be able to emuate an Amiga. I already have a perfectly working Os, without spyware, thank you.


i currently mostly use fs-uae under lubuntu under vmware player for immediate testing of changes to aros 68k. it isnt fast, especially that it runs without jit (testing) virtualized on so to say low mem machine (have only 4gb ram to date) but is is usable. you can also run winuae with wine under linux, no problem. you dont need windows.
 

Offline mikej

  • Hero Member
  • *****
  • Join Date: Dec 2005
  • Posts: 822
    • Show only replies by mikej
    • http://www.fpgaarcade.com
Re: Apollo Team announces the Vampire V4
« Reply #344 on: August 25, 2017, 02:24:24 PM »
Quote from: Thomas Richter;830001
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.