TG68 - The Open Source Minimig CPU into the FPGA

[Belial6]

So, from the software running on the machines point of view, the only difference is that the 68060 has floating point?

[freqmax]

Guess the 2 instructions in parallel can be achived with some instruction decode pipeline?

[Cymric]

So, from the software running on the machines point of view, the only difference is that the 68060 has floating point?

And an integrated memory management unit. Plus a superscalar architecture (though not pipelined, if Wikipedia is to be believed). The latter is not much of a problem since there never were any official Amigas coming from the main manufacturer with a 68060 installed, and it's just a means of speeding up execution rather than implementing a different set of mnemonics.

Personally, I think that if a more advanced make of CPU were to be coded into a FPGA, then it should be the one with the most informative exception handler stack frame (I vaguely recall that this began with the 68030, which could be made to recover from nearly everything you threw at it). A full implementation of the 68882 would be useful; I don't think the full 68851 is required and one can make do with the MMU-subset found in the 68030 and 68040. From the looks of the software-68000, it shouldn't be much work nor take much extra gates adding the instructions and abilities of a plain 68030 given that almost nothing changed in the register model save for the addition of proper support for longwords.

[Cymric]

freqmax wrote:
Guess the 2 instructions in parallel can be achived with some instruction decode pipeline?

Or multiple execution units. The question is: why would you want to? It's an addition to increase performance on the original chip, not to increase its capabilities. The FPGA'd 680x0 relies on a completely different model to increase its performance, and modelling the performance enhancements of the original chips is not guaranteed to work for the FPGA-equivalent. I know very little of FPGA-programming, so I'm not even sure a standard trick as introducing a cache will work. One would say it would, true. But it's the nature of the FPGA which determines what will work and what will not, and I'll leave that to the actual coders to sort out the details.

[downix]

Cymric wrote:
From the looks of the software-68000, it shouldn't be much work nor take much extra gates adding the instructions and abilities of a plain 68030 given that almost nothing changed in the register model save for the addition of proper support for longwords.

Not singling you out specifically, but this has a bit in it that is driving me a bit nutty.  A lot of people keep calling this a software CPU.  No, it's an HDL CPU, that is it's a description of hardware.  While it can be run as software, it's end goal is to be hardware.  So please, let's just call it the TG68000?

[FrenchShark]

jkonstan wrote:
The Stratix II development board sounds like a nice idea; however, it is really expensive right now ($2K to $3K) unless you have access to one via work or school. Affordable FPGA evaluation boards today, would be Altera Cyclone II/III or Xilinx Spartan 3e.

 :-)

The Nios II boards cost $1000. And only $400 WITHOUT the software (the software is a 1 year licence for Quartus II full version).
The Stratix FPGA are not supported by the Web edition so if you do not have access to a full version of Quartus II, you are limited to the Nios II Cyclone II board or the new E.E.K. Cyclone III.

[FrenchShark]

amigadave wrote:

Sounds like a great plan, are you going to be working alone, or with others to make it a reality?  The reason I ask is that I hope that the huge effort to create AGA and/or 68020+ softcore code is at least done in cooperation and not several individuals working on the same thing at the same time and having it take many times as long to complete as it would if they work together.

I will work alone but of course, I will re-use the nice designs from Dennis and Tobias.
Currently, I am working on a RISC CPU that has the same ALU than a 68000 so I can easily emulate a 68000 with it.
It has a 4-stage pipeline. The Fetch, Decode and Execute stages are almost finished. I am fixing the bugs right now. I need to write the Load/Store unit. The Fmax given by Quartus is 125 MHz.
With a software emulation layer I think I can achieve 5-10 MIPS, if I use some HW acceleration, I can get 10-20 MIPS and maybe with a full HW translator, I can get 100 MIPS.
Even if I do not use it for the main CPU, it can make a nice coprocessor (a la Jaguar) for the audio and video. :-P

[Cymric]

downix wrote:
Not singling you out specifically, but this has a bit in it that is driving me a bit nutty.  A lot of people keep calling this a software CPU.  No, it's an HDL CPU, that is it's a description of hardware.  While it can be run as software, it's end goal is to be hardware.  So please, let's just call it the TG68000?

You are correct in that I get my terminology mixed up, and I shouldn't be doing that. For the record, I know that it isn't a genuine 'software' CPU in the ASIC sense.

However, thinking of the HDL CPU as a genuine software CPU when coupled with advanced Minimigs does aid people in showing why it isn't important to implement the full superscalar, cache rich, branch predicting core of a 68060. Even a 68020 isn't particularly useful.

[AMC258]

Okay, forgive my ignorance, and note that I'm not trying to be critical.  But, would not 'firmware' be more appropriate than 'software' or 'hardware'?

[freqmax]

One could call it configuration file, design file, HDL files etc..

Regarding 68020, is it mainly the 32bit capability that is needed/wanted from a 68000->68020 upgrade?
In such case maybe a hybrid solution where the HDL 68000 is made 32-bit capable is an easier and faster approach to accomplish any 68020 needs?

Other factors are ofcourse FPU, and MMU. I know MMU is used by unix operating systems. But for anything else are these things really used in the Amiga enviroment?

Trying to find a less burdensome upgrade path.

I also think any software emulate cpu will just like UAE have problems with latency.

[Cymric]

freqmax wrote:
Regarding 68020, is it mainly the 32bit capability that is needed/wanted from a 68000->68020 upgrade?
In such case maybe a hybrid solution where the HDL 68000 is made 32-bit capable is an easier and faster approach to accomplish any 68020 needs?

You cannot make a 68000 32-bit without turning it into a 68020; there's portability issues to consider. And the difference between a 68020 and 68030 is very small. Since the latter has a more informative stack frame upon handling of exceptions, I'd be in favour of doing a 68030 instead of a 68020.

Other factors are ofcourse FPU, and MMU. I know MMU is used by unix operating systems. But for anything else are these things really used in the Amiga enviroment?

They are used in program development in order to catch badly behaving programs. I've experienced enough crashes on my EC030 to know I would want its functionality, even if it isn't supported by the OS.

[downix]

One thing I was pondering was in rolling this into a spare FPGA I have, and pairing it next to an original 60000, to duplicate instructions and see what differences there are.  Just need to find a minimalistic motherboard design for the 68k, like the old Altair, so I can directly manipulate them.

[MiniMorph]

I just thought I would let people know that I am working on an improved boot loader based on the Minimig one.

The aim is to extend the excellent work done by Dennis and Tobiflex, so the Minimig can do more and also so a board like the Minimig board can be made to run more cores.

The one thing I plan to add if I ever get it going is Ethernet to the Minimig.

I think Tobiflex has worked on a Amstrad CPC core in the past and there are many other cores out there that can benefit from been run on a board like the Minimig one.

I am no expert FPGA coder at this time so I would have to get Tobiflex's core running on one of my two Xilinx based boards.

I notice Tobiflex's is running on Altera based boards at the moment. I hope I can get hold of the HDL and get it ported to my boards. I may be able to get that done.

I would really like to try anyway.

You can see what I have been up to on my website here :-

http://minimorph.com/forum/viewforum.php?f=42

I have non of this working at this point. I am actually still waiting for a Dev kit to arrive for my chosen Micro controller hardware platform.

The one bit of good news is that the tool chain I am using is totally open source and free to download, unlike the Hitech tool chain used on the current Minimig boot loader.

I plan to put the code up on Source Forge on maybe Open Cores when I have it working.

What do you all think ?

Feedback welcome.

[freqmax]

You can make it run more cores this way:
1) A coreselector is loaded and run just like "minimig1.bit" is now. Once this is running it will put up a fileselector. And any selected core will have it's filename written to a eeprom area in the PIC18.
2) The PIC18 will reset the FPGA by playing with the PROG, INIT_B etc.. signals. And load the core again, but now using the filename selected in eeprom.

So a two-stage loader could make it happen with current pcb layout.
The default action if no bitfile is selected is to start the "last one selected" within 5s or such.
One could also use a small file on the flashmemory for bitfile selection. Maybe that would be a more portable idea.

Regarding ethernet. What you will need is a PHY. And you will need to wire up RX_Clock, RX_Datavalid, RX_Error, RX_Data[3:0], TX_Clock, TX_Enable, TX_Error, TX_Data[3:0].
For 1 Gigabit mode an additional 4 more databits will be needed per direction (GMII). Possible you may need MCLK and MDATA to configure the PHY aswell, but the defaults seems alright. A minimal setup will be 12 IOs and a full at least 16 IOs.

[MiniMorph]

Hi freqmax,

You have exactly the same idea as I have of running more cores on a FPGA board and how to achieve that.

The current PIC18 series code would need modifications to make it suitable for running more cores and that is just what I am working on.

The MiniMig board is not ideal for running other cores however. The on board 68000 is not much use if your core needs a 8086 or a Z80 !

The FPGA on the Minimig may be too small to run some more complex cores.

The Minimig board should be great however for emulating things like the Atari ST, Mac Classic and Sinclair QL.

It should easily be able to run older computers like the C64 and Spectrum.

Tobiflex's new version with a 68000 in the FPGA is much more suitable for running other cores.

I think Gigabit on an Amiga class of computer would be a waste of time. It would never be able to keep up with the data.

The new Micro controller I am developing for my version of the boot loader has Ethernet built in, so no extra PHY is not required. This will add an Ethernet Capability to both the Boot Loader and the FPGA and use no extra FPGA pins. It will also allow the boot loader to retarget classic ports such as RS232 and Parallel ports over the Ethernet.

The chip is also much more capable than the 18 s series PIC, so more suited to a board that can run many cores.

Lastly the tool chain I am using is Open Source and Free to download, which I think is important for an Open Source community project.

All the best.

[HenryCase]

freqmax wrote:
Regarding ethernet. What you will need is a PHY.

It looks like the microcontroller MiniMorph is proposing we use already handles the physical layer of the ethernet connection for us.

@Minimorph
First of all, thank you for taking on this project, the possibilities unlocked using an improved bootloader and ethernet+USB connections are great.

I would like to ask you a few questions.

1. As the LM3S6965 chip and FPGA would both be reprogrammable through the JTAG port, could we configure the LM3S6965 to act as a co-processor at runtime? Not sure why we would do this, just wanted to know if it would be possible.

2. LM3S6965 adds USB and Ethernet connectors to the Minimig. How easily can these be used for outgoing comms if Minimig code was amended to think they are serial port connectors?

3. Does the microSD slot support SDHC cards?

4. Price issue. So that I had some understanding of the added cost, I went onto Digikey's website. For the Microcontroller itself, we're talking around $13.10 USD:
Link
The evaluation board is around $69.00 USD:
Link
Other than the LCD screen and speaker (neither of which I see as essential, especially as the new bootloader would handle selecting the cores), would we lose any features by incorporating the microcontroller, microSD slot, ethernet port, JTAG port and USB port directly into the Minimig PCB design?

5. Last question relates to the bootloader. It seems to me that you are looking to replace the PIC with the LM3S6965 rather than having both devices on the board. I noticed that you plan on using ZIP files to hold the FPGA core data. Would the PIC chip used in Minimig 1.1 be powerful enough to do the unzipping? Just want to make sure Minimig 1.1 owners get access to the new cores.