FPGA Replay Board

[ChaosLord]

Instruction sequences that involves some kind of looping can be optimized to identify those in the instruction queue. And performing them directly with logic gates with way less clock cycles per operation.

Sadly, there is no way of actually doing that using current FPGA technology.

You could realtime analyze the instruction sequences but there is no way to reconfigure the FPGA in realtime.  In fact it cannot be reconfigured at all while it is in use.

Hopefully this will all become possible 10-20 years from now.

[matthey]

Thus ColdFire and 680x0 compatibility is mutually exclusive when the same op-code is supposed to act in different ways?

Right. It's not possible to have 100% 68k compatibility and 100% CF compatibility at the same time in the same CPU. It is possible to have 100% 68k compatibility and 99.9% CF (user level) compatibility at the same time. That's what I think should be targeted.

Then it's no longer a re-implementation, but something completely new. I see the main goal as being able to run the existing software base independently of rotting hardware.

The 68000 was not completely compatible with the 68020 at the user level either. The movem instruction was slightly different and some instructions became supervisor level. The 68020 call/rtm instructions were dropped in later 68k processors. The CF is similar with different ISA levels. There is a big difference between CF ISA_A which is minimalist and ISA_C which is close to the power of 68k. There are other options which can exist or not from one CF CPU to the next like MAC (3 different versions), FPU, division. If you want a new name for the slight differences, we could call 68k+CF "Cold Fusion". It would avoid the trademark infringement .

Instruction sequences that involves some kind of looping can be optimized to identify those in the instruction queue. And performing them directly with logic gates with way less clock cycles per operation.

The 68k should be a good candidate for loop optimization logic like a loop counter combined with branch prediction. We know when a dbra instruction will terminate ahead of time making it easy to predict which code target of the branch not to load. The post-increment/pre-decrement addressing modes give a hint as to what memory the memory controller should be pre-loading. I suggested as much on the Natami forum but the simple gains need to be realized first. Using the 68040/68060 branch prediction scheme instead of 68020/68030 would save 2 cycles on every iteration of a loop (except last) assuming the same timing as the 68020/68030. That savings adds up fast. Branch prediction schemes generally don't save as many cycles on the 68k due to the short pipeline compared to most other processors.

[freqmax]

You could realtime analyze the instruction sequences but there is no way to reconfigure the FPGA in realtime.  In fact it cannot be reconfigured at all while it is in use.

Actually the trick doesn't require any reconfiguration at runtime. You simple compare the instruction queue contents passively (huge and-gate), and when conditions are meet. Another path of instruction handling is selected.

And the current FPGA:s can be runtime partially reconfigured in blocks. Provided proper internal I/O pads has been configured in the first place. The synthesization of a new block is only dependent of the software used. Be it 120 seconds, or 0.1 seconds with a fast computer.

[billt]

but there is no way to reconfigure the FPGA in realtime.  In fact it cannot be reconfigured at all while it is in use.

Hopefully this will all become possible 10-20 years from now.

Reconfigurable computing is not new. Heck, old 40K tech Atmel FPGAs could be reconfigured on the fly. Spartan3 has an external bus for that, which can be connected to other FPGA pins to be controlled by itself. Spartan6 moves that bus connection inside the chip where it belongs.

There is of course overhead to this process. It takes time to read in a new configuration for that area of the FPGA chip. You have to wait for that before proceeding. I wouldn't want to do that frequently. If frequently is a must, it's probably better to just have both implementations in the design and choose them with a mux controlled by a software settable register. But then what do you do if you're context-switching between both kinds of software during operation, not just setting it and then running whatever one of those environments until some kind of system reset to change... Old software doesn't know about pushing this to stack to keep track. Maybe keep track of where in memory things come from and have a way to tell which memory pages are which instruction set. Ugh... New software could be made smart enough to handle this with a smart compiler for the situation, but old stuff would be a problem.

[mikej]

It is possible to configure the logic cells on the fly by configuring them a RAMDs.
Then, the read path works as a 4 input LUT, but you can rewrite the contents from other logic elements.
If you use block rams as decode tables, you can also update these during runtime as well.
/MikeJ

[Colin_Camper]

He probably doesn't even know this project exists and is therefore thinking absolutley nothing of it.

Is this Mick Tinker of BoXeR fame?

http://www.linkedin.com/profile/view?id=114238066&authType=NAME_SEARCH&authToken=H7rQ&locale=en_US&srchid=136bc207-9f93-4768-ae8f-66db2602e481-0&srchindex=3&srchtotal=4&goback=%2Efps_PBCK_*1_Mick_Tinker_*1_*1_*1_*1_*2_*1_Y_*1_*1_*1_false_1_R_true_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2&pvs=ps&trk=pp_profile_name_link

[psxphill]

No, it's not dangerous. You would need to double the instruction rate to do the work of a mvs or mvz instruction and they would be common. You would need to at least triple the instruction rate to do the work of a byterev which is less common but used intensely in some drivers and data conversions for loaders/pictures etc.

It depends on the software. If you could get a 25% overall increase then you'd still be faster than CF instructions unless your software was all mvs/mvz.
 
The danger comes from platform fragementation. It's rather early for natami to try dominating the Amiga market. There never has been a coldfire Amiga, so there is no software that takes advantage of it except for that which you produce yourself & that software won't run on anything but a natami. That would kill my interest pretty quickly.

[Bennymee]

Is this Mick Tinker of BoXeR fame?

http://www.linkedin.com/profile/view?id=114238066&authType=NAME_SEARCH&authToken=H7rQ&locale=en_US&srchid=136bc207-9f93-4768-ae8f-66db2602e481-0&srchindex=3&srchtotal=4&goback=%2Efps_PBCK_*1_Mick_Tinker_*1_*1_*1_*1_*2_*1_Y_*1_*1_*1_false_1_R_true_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2&pvs=ps&trk=pp_profile_name_link

http://www.linkedin.com/in/micktinker

[matthey]

It depends on the software. If you could get a 25% overall increase then you'd still be faster than CF instructions unless your software was all mvs/mvz.

I see your point. Making all the instructions 25% faster would be faster overall. I think after a few easy changes, like enabling the cache and prefetch in the case of the fpga Arcade, finding 25% overall performance increase will start to get difficult. Adding instructions is an easy way to increase performance. Making the decoding path wider should has little impact on performance. Mike verified that adding the 68020 support has little effect on the speed...

The cache and prefetch must be disabled in the current core. This is what is hurting performance, not the (68020) cpu extensions. The new memory controller and cache system does a lot better.

The danger comes from platform fragmentation. It's rather early for natami to try dominating the Amiga market. There never has been a coldfire Amiga, so there is no software that takes advantage of it except for that which you produce yourself & that software won't run on anything but a natami. That would kill my interest pretty quickly.

If you didn't notice, we already have platform fragmentation . We need supported open standards (helps to glue the fragments back together) and that's why I would like to see standards for an enhanced CPU and AGA. There won't be much new software without standards. It's the chicken and the egg problem that I'm trying to solve. The executables that have CF support would be much like for current 68k CPUs (000, 020, 030, 040, 060, 68CF, 68CF2, etc). Compilers only need a recompile to support whatever ISA/CPU.

[freqmax]

I see your point. Making all the instructions 25% faster would be faster overall. I think after a few easy changes, like enabling the cache and

Mike verified that adding the 68020 support has little effect on the speed...

The point is to being able to run software that requires 68020 enchantments. Which some A1200, A3000, A4000 is likely to require.

If you didn't notice, we already have platform fragmentation . We need supported open standards (helps to glue the fragments back together) and that's why I would like to see standards for an enhanced CPU and AGA. There won't be much new software without standards. It's the chicken and the egg problem that I'm trying to solve. The executables that have CF support would be much like for current 68k CPUs (000, 020, 030, 040, 060, 68CF, 68CF2, etc). Compilers only need a recompile to support whatever ISA/CPU.

I was under the impression we were in the business of re-implementing existing  Commodore computers. Not inventing new APIs for which there is no software for. Let the existing Commodore models be the "standard".

[billt]

I was under the impression we were in the business of re-implementing existing  Commodore computers. Not inventing new APIs for which there is no software for. Let the existing Commodore models be the "standard".

I think what he meant was that natami team are making a new CPU, intending to be compatible with 68K but may have something new in it, and that it would be nice if Yaqube's enhancements to TG68 would be compatible with those new things. Have the different groups working together to maintain compatibility between them for all new stuff.

I'm not sure we'll see that happen, and I'm not sure it's completely a bad thing. If everyone is agreeing on everything to be done, then we're waiting for committees to approve anything at all, and we may be losing out on some unique improvements that not everyone on the committee agrees with. Competition can be good for us. It can be uncomfortable and all that, but Hyperion's decisions have left us without any hope for an OS4 laptop, while MorphOS intends to demo one very soon. I wish it would come for an iBook G4 as I already have one of those, but it's more than the Red camp has been willing to allow to happen. (Note that Hyperion is not philosophically against an OS4 laptop, but their rules to get anything done have to date not allowed it to actually come to be. I've tried. If MorphOS on a laptop gives hyperion reason to adjust some of their rules and past decisions, then that might turn out to be a great thing for OS4 fans.)

Besides, if Natami does come up with something cool, if documentation is available then others can reimplement based on that documentation. It'll have to be somewhere. Will they make a nice datasheet? If not, will they use gcc? What ever they use will have to be in gcc sources somewhere... Perhaps not easy to decypher, but there. What about SuperAGA? If they want to see it used, it'll have to have a datasheet. Otherwise it'l be hidden in a P96 or CGX driver, and at that point who cares if it's an extension to AGA or something completely unrelated such as Yacube's P96 graphics thing, which is a parallel block separate from his AGA udpate to Minimig. It could be a simple VGA framebuffer, it could be OpenGraphics, it could be an ARM Mali core, a reimplementation of Voodoo3 from datasheet, whatever, and who cares at that point. (A P96 core would be great, I'm not denying that, but if you're marketing an extension to AGA in particular, then it's not any of these other things which are separate core blocks than AGA) There will of course be some delay in others absorbing whatever information they can find on a new unique feature in one of the various products, then time to reimplement it into their particular product, and for end users to benefit from that, but it is possible.

As I've mentioned in other topics such as the replacement for classic motherboard thread somewhere, if you're reimplementing something, why not add something new and cool to it? Why stop at the 1994 feature set, datasheets, etc? If you're going to all this trouble to make something new, sure, make it compatible so we can run old software on it. The entire point of Minimig and Natami is to make something compatible with our old Amiga software. But, while we're at it, why not add something new, for new software to benefit from? Why not add a P96 graphcis core to Minimig, so that it can run P96 games as well as ECS games? Why not add a PCI slot to Natami, so we can get a much better P96/CGX graphics than what will fit and run inside an FPGA? (I understand that OpenGraphics takes up a LOT of space, and their board has a huge FPGA) If you're going to the trouble to make a new A2000 motherboard, why not add an active 3.3V PCI slot? (like building-in a Mediator or Prometheus to the motherboard itself) If you're making a repalcement for an A4000T motherboard, why not have active PCI slots, plus a bridge to a PCI-Express slot so we can plug in an even newer graphics card? (even if it won't have full PCI-Express connection speed, it will still function) If you're making a new A1200 motherboard, why not add a MiniPCI slot for wireless network and an MXM slot for a modern laptop graphics card? Why not...

[matthey]

@billt
That's the right attitude. Technology has moved forward, why keep the limits of the past? We can have high and true color chunky screens. We can add a few instructions and larger caches to the CPU as the few logic gates required are minor today. We can have many times the memory and storage space as we had in the past. The one thing we can't upgrade is the closed minds of Amiga users living in the past :/.

[freqmax]

The problem shows when you alter instruction sets, register structure, etc.. which will kill the capability to run exisiting software. Increasing memory, frequency, caches, etc..

If you want updated performance, try Intel Core (MIPS for freedom, or ARM for efficiency might be alternatives), Intel graphics (free API), it ends up being a PC. Though ARM + Graphics is becoming more common as well. However any compatability goes out the window. Also modern systems use memory protection, preemptive multitasking, virtual memory, and user accounts which asfair AmigaOS doesn't support.

It's too bad that Intel/Compaq bought up all good processor projects. NVidia have their super propietary stuff, etc..

[HenryCase]

The danger comes from platform fragementation. It's rather early for natami to try dominating the Amiga market. There never has been a coldfire Amiga, so there is no software that takes advantage of it except for that which you produce yourself & that software won't run on anything but a natami. That would kill my interest pretty quickly.

You do know that the Natami doesn't use a Coldfire CPU, right?

[amigadave]

Enhancing the original Amiga features with more modern additions to the feature set in these FPGA based Amiga systems is a good thing that will allow new apps and games to look and/or behave differently than was previously possible on an Amiga, while still maintaining good backward compatibility.

Having open communication of ideas between all of the people working on such systems will help  encourage more programmers to use these new features and without new apps and games that use the new features, there is no point in having them.

Not all new features that are created for one of the new FPGA systems will work on all of the other FPGA based systems, but most of them should be possible.  It appears that there is a spirit of cooperation between all people working on FPGA based systems, not competition, which is refreshing to see in the Amiga community.

[matthey]

I was under the impression we were in the business of re-implementing existing  Commodore computers. Not inventing new APIs for which there is no software for. Let the existing Commodore models be the "standard".

There is software available for the ColdFire! Add ColdFire instructions to the 68k and this software will run with a very high degree of compatibility on the new 68k + CF.

The problem shows when you alter instruction sets, register structure, etc.. which will kill the capability to run existing software. Increasing memory, frequency, caches, etc..

Well, Mike better go back to the 68000 and throw out all the 68020 changes because he's killed compatibility with 68000 code, right? This is blatantly wrong! The 68000 to a 68020 was a very radical change, was not 100% compatible and made a few mistakes in my opinion but it was still a big enhancement in a positive direction. Adding CF instructions would be much more compatible than 68000 to 68020. It would be more compatible than enlarging the caches. Maybe you should stick with the MiniMig and ECS so you have all that compatibility. Oh wait, they enlarged memory and added new storage devices. There went compatibility. I guess your only option is an original unexpanded Amiga 1000 so you can enjoy your compatibility.

If you want updated performance, try Intel Core (MIPS for freedom, or ARM for efficiency might be alternatives), Intel graphics (free API), it ends up being a PC. Though ARM + Graphics is becoming more common as well. However any compatibility goes out the window. Also modern systems use memory protection, preemptive multitasking, virtual memory, and user accounts which asfair AmigaOS doesn't support.

I think an updated 68k processor has more potential than ARM. I think with a few relatively minor additions the 68k can have...

+ better performance
+ better code density (I think 68CF+ can have 5-10% better code density than 68020)
+ easier to program

with the negatives of...

- higher power requirements (but still good and better than x86 derivatives)
- more gates (cost not really a problem today, power requirements higher)

I'm sorry if you can't see the potential.