minimig 4000

[HenryCase]

amigadave wrote:
Hmmm, thinking out loud.  Since the Coldfire had that hardware translator removed and since many have wanted to develop a Coldfire accel for the Amiga because of the Coldfire's low cost and availability, as well as its increased speed, maybe we could get Dennis to sit down for another year and develop the missing 68060 part of the Coldfire in an FPGA and we would end up with a real A3000/A4000 Coldfire accelerator that works and runs at 3 to 10 times faster than our old Phase5 060 boards?

If it were that simple, I guess someone would have done it already. :-?

amigadave, couple of things:
1. Dennis has already done enough hard work for us on this project already. Anything else we get from him is a huge bonus IMO.
2. TobiFlex has already implemented a Minimig+68000 on FPGA. This solution isn't open source yet but hopefully it will be soon. An A500 wouldn't use the extra instructions of an 68060, right?
3. As we already have a 68000 on FPGA, we could easily overclock it an get some of the speed improvements you are looking for.

There would be two things that limited overclocking; the maximum speed of the FPGA and the clock speed of the Amiga (which we cannot change AFAIK). Some useful overclocking info on this website (http://members.iinet.net.au/~davem2/amiga.html):
"Firstly is the computer being modified of "synchronous" or "asynchonous" design? Synchronous is where the CPU is clocked at a speed which is a direct multiple of the main clock which runs the entire computer."

If the main A500 clock runs at approximately 7.14MHz, we should be able to overclock the 'processor' part of the FPGA to high speeds for an Amiga CPU if we stick to multiples of this base value (121.38MHz, 164.22MHz, etc...). Anyone know what the maximum clock speed for a Spartan-3 FPGA is?

[alexh]

HenryCase wrote:
An A500 wouldn't use the extra instructions of an 68060, right?

Wrong.

If the program is compiled for / written for 68060 it will use any extra instructions.

If not, a standard 680x0 program will use the improved architecture, parallel execution units, Instruction and data cache, branch prediction etc.

If all you want to do is run A500 software, stick with MiniMig.

Also bare in mind that a LOT of Amiga workbench software is written for 68020+ only.

HenryCase wrote:
If the main A500 clock runs at approximately 7.14MHz, we should be able to overclock the 'processor' part of the FPGA to high speeds for an Amiga CPU if we stick to multiples of this base value (121.38MHz, 164.22MHz, etc...).

It doesnt work like that.

Anyone know what the maximum clock speed for a Spartan-3 FPGA is?

Absolutely doesnt work like that.

FPGA's dont really have a "maximum clock speed". Their maximum speed is determined partly by type/generation of FPGA it is and mainly by the logic that is programmed into them.

While the FPGA might be rated to 300MHz, when programmed it wont do a fraction of that speed!

Maybe low 10's of MHz with a well written design. Certainly not 100's.

[HenryCase]

Alexh, thank you for that info.

alexh said:
"If not, a standard 680x0 program will use the improved architecture, parallel execution units, Instruction and data cache, branch prediction etc."

I'd like to break down that statement so I have a better chance of understanding it:

"Improved architecture". Are you referring to refinements to existing operations (i.e. streamlined instruction architecture) or the addition of new facilities (i.e. more data bandwidth)?
"Parallel execution units" How does the 68060 do this? I didn't think the 68K series CPUs were parallel processors in the modern sense. Did it have multiple ALUs/FPUs, more registers, bigger instruction pipelines?
"Instruction and data cache" Are you referring to the increased space for more complex operations (complex in the sense that the 68060 could do larger calculations in a smaller number of cycles)?
"Branch prediction" You've lost me there. How does this work?

alexh said:
"It doesnt work like that."

Care to explain why we wouldn't be able to 'overclock' the 68000 in the way I described? Surely all timing is set on the FPGA. What would 'overclocking' the 68000 code break in the Minimig?

alexh said:
"FPGA's dont really have a "maximum clock speed". Their maximum speed is determined partly by type/generation of FPGA it is and mainly by the logic that is programmed into them.

While the FPGA might be rated to 300MHz, when programmed it wont do a fraction of that speed!

Maybe low 10's of MHz with a well written design. Certainly not 100's."

I have heard this before, in my enthusiasm for the overclocking idea I forgot that the maximum speed of FPGAs is determined by the complexity of their design as well as FPGA type. My question is, what does that 300MHz rating even mean, how is it calculated?

Thanks in advance for your help.

[AeroMan]

Hi to all,

    Wow, this thread is hot... seems to be that everybody have a small poject on the Amiga based on Minimig.
    I'm planning some stuff also, but as my time is getting very short, I don't want to make it public, as it may not see the light of the day (3 years old twin daughters and a classic car to restore fills my weekends :-D )
    Let me share some of my opinions. Then you can throw me some rocks :-D. I really believe that if there is a future for the Amiga it is in our hands, as the "big companies" had proven to be such a disaster. There are a lot of other folks doing compatibles around the world, and Minimig is a great start.
    I think if AGA compatibility is the target, we should have that in mind when doing any board. The hardware should be capable of supporting it, and we can grow the software slowly from OCS to ECS and then AGA without doing new boards. This keeps costs acceptable for us hobbists.
    The 68060 is an expensive guy. Coldfire is cheaper, but a litle bit incompatible. I would go to PPC, as OS4 needs it, and it is cheaper than the 060, but I believe the best place to start is to seek A1200 compatibility, so use a 020 or a 030 as a plug in daghterboard. It helps to use processor development kits also.
    Most software will run with AGA and 020. When we get A1200 compatibility, a PPC is the best choice to speed it up.
    Virtex 4 is also expensive. You can get a cheaper set up with a MPC5200 and a Spartan3, and the MPC already has SDRAM/DDR controllers, Ethernet, USB and some stuff more.
    I've talked with some friends who work with FPGAs, and they told me VHDL would fit best for this kind of project, althrough Verilog is easier to learn. I'm trying to learn Verilog first anyway.
    Now two quick questions to the people who are playing with Minimig already: How many gates are we using from the Spartan ? I would like to know how big we could expect an AGA version to be...
    The second one: wouldn't it be cheaper to use two or three smaller FPGAs for an AGA Minimig than upgrade to a bigger FPGA? The cost of those chips seems to grow exponentially.

[amigadave]

@HenryCase,

I was not thinking of just speeding up the MiniMig a little so games would run faster, or at the correct speed.  I am thinking of future projects where people will be working on advanced Amiga compatible designs by using the work Dennis has started and forwarding it up to and beyond anything we currently have in hardware on Classic Amigas.  This could include using 68060 CPUs, but it would be better if a Coldfire solution could be designed, as it is faster, cheaper and more available, and it is an extension of the 68000 series CPU.  Another group will probably go in the direction of PPC CPUs to obtain compatibility with AmigaOS4.x and yet another group will move toward integration with x86 architectures to use AROS and take advantage of all the cheap hardware.

I think one of the next steps will be to have ECS and AGA recreation in hardware and then go beyond to what AAA would have been.

[alexh]

AeroMan wrote:
    I've talked with some friends who work with FPGAs, and they told me VHDL would fit best for this kind of project, althrough Verilog is easier to learn.

I dont know who you're mates are but they are either poor engineers or they make stuff up they dont know!

VHDL and Verilog are just languages, you can write exactly the same thing in both languages. They are equally supported in all Xilinx and Altera FPGA's tools and have been for a long time.

If anything VHDL got full support later than verilog due to it's extensive typing and features such as generate and records.

AeroMan wrote:
How many gates are we using from the Spartan ?

You should start thinking about SLICES and BLOCKRAM rather than gates. Gates is an ASIC metric. To know exactly how much MiniMig uses... try to Synthesis it. The Xilinx toolkit is available freely as is the MiniMig source.

http://www.amiga.org/forums/showthread.php?t=32604

AeroMan wrote:
I would like to know how big we could expect an AGA version to be...

Impossible metric to measure, even if you knew the current size of MiniMig. How long is a bit of string? You have no idea how much more complicated AGA is over OCS, or how well MiniMig is written or how well someone will write AGA.

AeroMan wrote:
The second one: wouldn't it be cheaper to use two or three smaller FPGAs for an AGA Minimig than upgrade to a bigger FPGA? The cost of those chips seems to grow exponentially.

Yes. Most designs (Prometheus, X-Surf, Mediator, Picasso IV) use multiple smaller FPGA's (CPLD's) rather than go to bigger ones. There is usually some cost / size boundary. However IMHO form-factor is a bit selling point of MiniMig. In fact to me, it's the only selling point.

[HenryCase]

amigadave wrote:
@HenryCase,

I was not thinking of just speeding up the MiniMig a little so games would run faster, or at the correct speed.  I am thinking of future projects where people will be working on advanced Amiga compatible designs by using the work Dennis has started and forwarding it up to and beyond anything we currently have in hardware on Classic Amigas.  This could include using 68060 CPUs, but it would be better if a Coldfire solution could be designed, as it is faster, cheaper and more available, and it is an extension of the 68000 series CPU.  Another group will probably go in the direction of PPC CPUs to obtain compatibility with AmigaOS4.x and yet another group will move toward integration with x86 architectures to use AROS and take advantage of all the cheap hardware.

I think one of the next steps will be to have ECS and AGA recreation in hardware and then go beyond to what AAA would have been.

amigadave, you made a very good point by illustrating the different ways the Amiga community will want to take the Minimig. As I wasn't considering all the possibilities when I made my comments about your previous post I didn't give your ideas fair consideration and for this I apologise.

I don't have a problem with any ideas for Minimig expansions, the more options we have the better the project as a whole becomes. However, I am concerned with making sure the Minimig is improved as fast as possible to make it a viable source of new Amiga hardware rather than making it a bit of a curio. For the amount of work necessary to make these big hardware improvements I tend to see the PPC route as the one with the most immediate potential. When the hardware is sufficiently powerful then we have more time to explore other uses of the tech. IMHO.

AeroMan wrote:
I think if AGA compatibility is the target, we should have that in mind when doing any board. The hardware should be capable of supporting it, and we can grow the software slowly from OCS to ECS and then AGA without doing new boards. This keeps costs acceptable for us hobbists.

Aeroman, this is very important, and it's something that hasn't been discussed much. The key to doing this is expandibility, which is the one major weakness with the v1.1 PCB. Let's say an AGA solution was made. It seems very likely that AGA wouldn't fit on the current design, so those people who want it have no choice but to upgrade to a newer PCB revision. If we had something like the CPU Fast Slot then we could design an upgrade board for the existing design, with an FPGA providing the extra processing capacity. People who hadn't bought a Minimig before this time could just buy a newer version of the PCB with the expanded capabilities built in.

I don't know if Minimig v1.1 had enough I/O pins on the FPGA to handle an expansion port, but if TobiFlex does release his code then we'll have plenty more I/O pins to play with. Downix, how many pins does your A500-like expansion port need?

If an expansion port is included in v1.2 a greater number of early adopters have more versatile hardware sooner, which in turn will speed up development. Any thoughts?

[AJCopland]

I think there's more to having AGA support than just changing the Verilog. It'll need the data and probably address buses upgrading to 32bit as well as running at a higher clock speed. Then to actually support software which expects AGA you'll probably need at least an '020 processor.

Basically take the A1200 as a minimum spec' for AGA and upgrade the MiniMig v1.1 to it.

From the way I've just written it that doesn't actually sound like too onerous a task :-D but I bet in practice it won't be so simple!

There seems to be a fairly common theme in peoples postsa bout AGA probably not fitting into the current FGPA which I'm curious about. I seem to remember Dennis stating that he was only using about 60% of the current for OCS. Now the difference between OCS and AGA wasn't that staggering, a faster and wider data bus. Extra registers etc, but it was mostly described as evolutionary rather than revolutionary.

What I'm trying to say is that I've heard no good argument as to why AGA shouldn't fit within the current FPGA. Has anyone got any knowledge about this? It seems to be a bit of an inaccurate science guessing how much space any given implementation might occupy.

Also a CPU fast slot isn't going to make a v1.2 any better at supporting AGA as it'll still be connecting to the same FPGA via the same 16bit wide data path running at half the clock speed of AGA. Since a large part of AGAs benefit was actually the 32bit data bus and the doubled bus clockspeed over the OCS/ECS system you'll lose whatever benefits you hope to gain by having it.

Just my opinion obviously.

Andy

HenryCase wrote:

AeroMan wrote:
I think if AGA compatibility is the target, we should have that in mind when doing any board. The hardware should be capable of supporting it, and we can grow the software slowly from OCS to ECS and then AGA without doing new boards. This keeps costs acceptable for us hobbists.

Aeroman, this is very important, and it's something that hasn't been discussed much. The key to doing this is expandibility, which is the one major weakness with the v1.1 PCB. Let's say an AGA solution was made. It seems very likely that AGA wouldn't fit on the current design, so those people who want it have no choice but to upgrade to a newer PCB revision. If we had something like the CPU Fast Slot then we could design an upgrade board for the existing design, with an FPGA providing the extra processing capacity. People who hadn't bought a Minimig before this time could just buy a newer version of the PCB with the expanded capabilities built in.

I don't know if Minimig v1.1 had enough I/O pins on the FPGA to handle an expansion port, but if TobiFlex does release his code then we'll have plenty more I/O pins to play with. Downix, how many pins does your A500-like expansion port need?

If an expansion port is included in v1.2 a greater number of early adopters have more versatile hardware sooner, which in turn will speed up development. Any thoughts?

[AeroMan]

alexh wrote:
I dont know who you're mates are but they are either poor engineers or they make stuff up they dont know!

VHDL and Verilog are just languages, you can write exactly the same thing in both languages.

I'm not stating that we should ignore what was done in Verilog and try to rewrite everything in VHDL. It was just one comment from them I would like to share.

Actually, one of them is PHD... What they told me in that discussion is that there are some stuff that you can implement in VHDL easier than in Verilog, but it is more difficult to learn. I'm starting to learn those languages right now, so I don't have enough knowledge to say if it is true or not, but it sounds reasonable to me, as Assembly and C are also languages and althrough C is very powerful, there are things that can't be done using it. You can do everything in Assembly, but it is way more difficult.

alexh wrote:
Impossible metric to measure, even if you knew the current size of MiniMig

Yes, It can give me a north to go. With the 60% number that AJCopland said below, I can tell the hardware needs prevision for a second FPGA or a bigger one, but it may fit in the current chip. Why? Because Paula and the CIAs are the same, blitter and copper have little differences, and the big work will be on Lisa and the memory fetch part of Alice. If the number was 30%, for example, I would say 99% of chance that if there are enough free IOs, we can use the same chip.

alexh wrote:
However IMHO form-factor is a bit selling point of MiniMig. In fact to me, it's the only selling point.

I agree with you, if we consider the Mini side fo Minimig. But if we are heading to a new Amiga hardware, we will need more area for stuff. The A1200 and A500 have perfect sizes, but a PC sized board would be nice, as we could fit it inside cheap PC cases.

[HenryCase]

AJCopland wrote:
I think there's more to having AGA support than just changing the Verilog. It'll need the data and probably address buses upgrading to 32bit as well as running at a higher clock speed. Then to actually support software which expects AGA you'll probably need at least an '020 processor.

AJCopland, I agree about the 68020 requirement for AGA Amigas, but would argue that this is even more reason to have two FPGAs. I'd certainly prefer 2x FPGAs than 1x FPGA and 1x 68020, simply because this is a more flexible design and frees us from components that may not be supported forever.

Also a CPU fast slot isn't going to make a v1.2 any better at supporting AGA as it'll still be connecting to the same FPGA via the same 16bit wide data path running at half the clock speed of AGA. Since a large part of AGAs benefit was actually the 32bit data bus and the doubled bus clockspeed over the OCS/ECS system you'll lose whatever benefits you hope to gain by having it.

Just my opinion obviously.

Andy

I'm just trying to make sure the Minimig is good VFM (at least as much as possible) by ensuring we think about features the design may need in the future, rather than designing a new board that will hinder growth. Would a CPU Fast Slot really not help AGA? Using my limited knowledge, I figure since the slot is 86pin it could handle a 32bit data bus. I could be wrong.

AJCopland said:
Basically take the A1200 as a minimum spec' for AGA and upgrade the MiniMig v1.1 to it.

I like this idea.

I would just like to state that there's plenty of mileage left in the v1.1 design for improvements (ability to write to the MultiMediaCard being #1 in my opinion), but the next revision of the PCB should be more ambitious.

[downix]

HenryCase wrote:
Downix, how many pins does your A500-like expansion port need?

92, but I wasn't using "pins" but a card-edge.

[freqmax]

Just want to point out that Xilinx Spartan-3 (like XC3S400 and XC3S500E) can do 622 Mbps transfers via a single I/O. So a 2x FPGA board won't need a staggering amount of fpga2fpga lanes.

Regarding Coldfire, it might be fast enough and have other benefits. But will it be cycle accurate to the MC68060 ..?, because lot of Amiga software is relying on cycle exact timing.

Cycle exact timing is the reason why FPGA/CPLD will perform and UAE won't.

[HenryCase]

downix wrote:

HenryCase wrote:
Downix, how many pins does your A500-like expansion port need?

92, but I wasn't using "pins" but a card-edge.

92, a fair few then! :crazy: :-D
I should have asked a little clearer, but I was actually wanting to know how many I/O pins from the FPGA (or 68000 CPU) your design uses. Could you break that down for me?

freqmax wrote:
Just want to point out that Xilinx Spartan-3 (like XC3S400 and XC3S500E) can do 622 Mbps transfers via a single I/O. So a 2x FPGA board won't need a staggering amount of fpga2fpga lanes.

Awesome, I was hoping this was the case. Is the transfer speed affected by FPGA complexity?

[downix]

HenryCase wrote:

downix wrote:

HenryCase wrote:
Downix, how many pins does your A500-like expansion port need?

92, but I wasn't using "pins" but a card-edge.

92, a fair few then! :crazy: :-D
I should have asked a little clearer, but I was actually wanting to know how many I/O pins from the FPGA (or 68000 CPU) your design uses. Could you break that down for me?

2 pins total.  Everything else is off of the CPU bus.

[freqmax]

The 622 Mbps speed depend on how you design your data flows.
I think every flip-flop in Spartan-3 cause a delay about 5 ns.

[alexh]

AeroMan wrote:
I'm not stating that we should ignore what was done in Verilog and try to rewrite everything in VHDL. It was just one comment from them I would like to share.

Sure, but the comment is invalid.

AeroMan wrote:
Actually, one of them is PHD... What they told me in that discussion is that there are some stuff that you can implement in VHDL easier than in Verilog

Not true. Trust me I've worked as a Verilog and VHDL designer for over 10 years. Ask them to name something, just out of curiosity.

AeroMan wrote:
but it is more difficult to learn.

It depends. If you've never done C (software) then you'll find both equally difficult. If you've done any C then you'll probably favour verilog as its syntax is quite similar.

AeroMan wrote:
as Assembly and C are also languages and althrough C is very powerful, there are things that can't be done using it. You can do everything in Assembly, but it is way more difficult.

Nice simile. Unfortunately not a valid one. C is a high level language and Assembler is a low level language. VHDL and Verilog are both equally high level languages.

Verilog has pro's and cons, VHDL has pro's and cons. The majority are not valid for MiniMig as they centre on verification and code reuse.

AeroMan wrote:
With the 60% number that AJCopland said below, I can tell the hardware needs prevision for a second FPGA or a bigger one.

No you cant, cos you dont know how more complex AGA is over ECS. Dont try to tell me you do, cos you dont :-P

The only thing you could work out is if we had enough I/O for 32-bit CPU/RAM interface and 24-bit video interface.