Motorola 68060 FPGA replacement module (idea)

[billt]

Anything that isn't 68k will most probable require some FPGA glue. That means the minimum configuration is FPGA + EEPROM (core boot image). Adding anyting else adds to the BGA soldering hêll.

I say like @psxphill, there already exist TG68, opencore 68k, and FPGA Arcade 68030 softcore hybrid which is essentially a TG68 modded to 68020 modded to 68030.

I think that a CPU core in FPGA is fast enough to saturate the computer bus in Amiga.

So the least amount of hardware mess and using existing software availability is an FPGA + EEPROM with perhaps SRAM for cache.

KISS..

I don't understand the horror of many pins BGAs. have it assembled. no big deal. or get a rework kit to assemble BGAs. (I am gradually building this up myself) But pro Assemblers are probably better.

Indeed, there are a handful of open/free 68k softcores to start with, so that simply is not a problem. Get them on the 040 or 060 bus is a little  work, but quite doable.

For those without resources to get harcware designed, consider KiCad or UpVerter. UpVerter sounds good for this sort of thing, but may need to advance a bit more first. Online tools, cloud data, free for open-source projects... KiCad is GPL (and one of the reasons I want WxWidgets for OS4)... Upverter sounds like it's becoming a good platform for collaborative/group design.

I'd put a microSD slot for the FPGA bitstream, so it's relatively easy to update even if something goes bad, rather than a soldered-on eeprom/flash. Maybe a simple microcontroller to get some config manager like FPGA-arcade to choose 68k softcore or Aros Arm-native or etc. I like the idea of using the internal Arm for that, but not sure how easy that is to do. (I've not done reconfigurable work before, and am not sure what mikej's approach is, or what other minimig boards do or not.

I'd use a Zync or Cyclone/Arria5 soc FPGA with Arm inside. Then Aros peeps can play with Arm, 68k peeps can play with softcore and maybe figure out something interesting for Arm to do, and software emu peeps have a fast cpu to interpret or jit 68k on. And I think that these Arm things inside would do better than adding a Geode or other X86/64 Pc to it all. Also consider than the Arms connect to the FPGA fabric, as I understand, via the Arm AXI system bus, so there is a better pathway to 68k socket than through PCI or PCI-express from a PC chipset.

[billt]

The other is getting a fast link between the CPU and the Amiga bus.  Most SOC's have limited IO capability.  GPIO isn't fast enough on any I've seen and local buses are long gone.  PCI-e is on some of them, but that's not a cheap interface.

GPIO would be terrible. I've done Arm APB bus over GPIO (as a software C implementation) and it was horribly slow. funtional yes. some things would have been weird such as interrupt latency. But this was for a testbench experiment (inside verilog simulator of a full soc chip) and ended up not used in favor of something else. Doing 68k bus as GPIO would not be any better, and probably worse as APB is not very complicated.

The Arm AXI bus inside the SoC FPGA chips is your local bus.

[billt]

I also had the idea a while back also to approach the problem from the opposite end... make an Amiga graphics card (preferably AGA, for me) for PCs. The PC would then only need to emulate the 68k.

Inside Out board made with Minimig-AGA, once Yaqube and friends have that finished up.

[billt]

My issue with the FPGA/ARM combo chips is the price.

I've been trying to find a good way to interface the wave of super cheap ARM's that are 800-1200Mhz and loaded with peripherals.

It might take a combo chip, but then we're back to $1000 CPU cards.

Well, I'm just saying what I would do. Considering my available time, I'm not likely to. Anyone that might actually take up this sort of project is free to do things as they see fit. More than one are free to each do things their own way, which may have several different things happen.

My real dream is a 3000/4000 style accelerator card that's just an FPGA, memory and a bunch of connectors, including a Com-Express type 6 connector. Most other connectors would go to that, perhaps through the FPGA first for some muxing. Then that FPGA would be either a softcore 68k or a bridge to a ComExpress module, which could be PowerPC, x86, whatever. But I don't have time to do that either. I'm more likely to spend time on a PowerPC ComExpress module, which iealize as the best way to design OS4 "Amiga" motherboards today if we must stick with PPC. This 68060 direct replacement idea is an interesting diversion for the moment though.

[billt]

I never heard of Inside Out board, it seems to be a complete Amiga, CPU and all?

Don't really need the CPU on board. Just the graphics + sound.

Someone took the Amiga chipset and put it on an ISA (I think) card for a PC. I don't think it was around for very long, and I don't think there were very many of them.

[billt]

Forgive me if this sounds terribly stupid, but surely an Arm chip (for instance) has data and address buses that we could connect to the trapdoor slot via some relatively simple FPGA glue logic, just as we would a 68060?

You might look for one with an EBI bus. (I htink that's what it's called) forgot about that one until today. I'm not sure what kind of selection there is though, I'm only aware of moderate performance ones between 100MHz and 200MHz which don't thrill me for this task. But I don't know much about the higher-end ARM chips. This is typically used for memory, bu tmay work for this sort of project as well.

I'm not aware of any ARM chips that expose an AHB or APB bus externally for connecting to an FPGA, which would probably be preferable to EBI. The new ARM SoC FPGA chips DO (as I understand) expose the newer AXI system bus internally to the FPGA, which is part of my attraction to them. Cool stuff! Yes, somewhat to terribly expensive just now, but I've only found the Xilinx low and high end ones at Digikey, I haven't found the Altera ones anywhere to compare. Maybe they aren't quite out the door just yet. I'm hopeful that prices will adjust when both companies have them on distributor shelves.

[billt]

Interrupts can be handled by letting the Amiga side setting an interrupt register in the FPGA which in turn just signal a general interrupt (like "IRQ" on C64) to the overdrive CPU. The CPU side then reads what interrupt source that triggered the event and act accordingly. The extra performance will negate any delays for this code.

On 8086 etc.. an instruction may take 3 cycles but an IRQ may take 100 cycles just to hint on the amount of wasted cycles that may occur. Not counting Push/Pop instructions.

This could work. Capture the 68k interrupt pins while triggering an interrupt to the upstream host, host checks what interrupt value was captured, and does whatever it needs to in interpreting the 68k binaries, jumping to the 68k irq handler routine to be interpreted, etc. Took a couple minutes for that to soak in, but I'm on board with it now.

[billt]

A large enough FPGA like XC3S1600 as used in FPGA Arcade cost 68 USD at D-key. Currently it can be seen in the FPGA Arcade thread it can beat 68030 @ 20 MHz Amigas using a 16-byte cache (4.46 times A1200). With hope of 28 MHz.

And Spartan3 is old stuff now. Since then they did Spartan6 and now the 7-series stuff, which should e both easier on performance as well as easier on power. I'm not familiar with Altera parts in terms of speed or capacity etc. I have a DE1 buried in storage somewhere for Minimig, hope to get to use it at some point... I also really want to get a Zed board to play with someday. But I of course need a 56 hour day too.

[billt]

Using an SOC gives a huge amount of devices for free, FPGA just gives a CPU.

Two thoughts in response to this:

1: Look at all them peripherals on opencores. Stick some of them in that same boring FPGA.... OK, now you may need a bigger FPGA, but something to consider. Understand that an FPGA can give you anything you can fit in there and meet timing with...

2: For the ARM SoC FPGAs, can the FPGA area only be a slave, or can it be an AXI master, and use all them ARM peripherals as if they belonged to our 68k softcore? I don't know the answer to that, but it would be interesting to find out.

[billt]

Finding one that has that plus external interrupts with levels is tricky.

It's also not standardized across chips so you're back to vendor lock-in.

Well, we're not going to find a better 060 already made for us, and we're not going to find an ARM with an 060 bus on it either.

I don't think anyone will find the perfect chip in a standard package from lots of vendors that are all pin compatible for this. You may have to suck it up and live with vendor lock-in of something. That includes straight FPGAs, as changing from one FPGA to another is not a trivial thing. I don't believe Altera has anything to go on a Xilinx board or vice-versa...

[billt]

Edit: Also, like I said, *I* can't reasonably do it in an FPGA.  I can do a localbus interface and I can do software.  I'm just tired of waiting for "it's not that hard" to happen and following my gut on the quickest path to get there.

I think doing the PCB of an FPGA (or SoC FOGA) only design would be pretty straight forward. I do not expect the softcore to be trivial. Luckily TG and Yaqube have already been doing wonderful things. This part needs a processor designer, and Motorola surely had quite a team. As do Arm, Intel, AMD etc. Not just a simple student engineer like me, but we do have some good people doing this sort of thing, and at some point it'll open up and more of us can see and play, and if time allows try some more ideas in there. I was surprised at how simple a RISC control unit can be this past fall semester, I really wish our project had been in something useful like VHDL or Verilog instead of the crummy schematic tool LogicWorks...

Look at the instruction set, and start breaking each down into easy steps. (hardwired logic or microcode, I don't have a good handle on microcode way yet) Look for common pieces, such as the first part of every instruction is the fetch part. Then decode. If you know VHDL and are good with digital logic, you should be able to figure it out. I had my aha moment and it's making a lot more sense now, so anybody can...

It starts with a counter, up to the maximum number of steps for your instruction analysis. The longest instruction (most steps) determines the maximum this counter increments up to. Shorter instrictions can clear the counter earlier back to 0 (fetch step). Along side that you have your instruction opcode, which is used to address/select registers, select which ALU operation gets to the ALU output, etc.

Then things get more complicated as you bring in pipelines, bypassing (shortcut result of one instruction back to ALU input for use before it actually gets written to its destination register), mux NOPs into pipeline stages if they need to stall/bubble  for a cycle, start doing superscalar (multiple parallel ALUs), caching, branch prediction, etc. And goes on from there.

The fundamental thing isn't hard. Competing with an 060 most likely is hard, but is possible. Will take a while though.

[billt]

Different angle here..... Coldfire is not too far off from 68K instructions. A Coldfire V1 core is available for Altera FPGAs. Would it be a shorter easier journey to start with a Coldfire core and modify it to be more 68K compatible for our purpose?

EDIT: Hold on, I may be reading this Coldfire core information incorrectly. More study required.

EDIT 2: Yes, looks like my first comment was correct....  http://chipdesignmag.com/display.php?articleId=2371

Check the store for this thing at http://www.ip-extreme.com/corestore/

Yes, it is free without cost, but it is also encrypted. You are not going to take this and go make changes to turn it into something else (even ever so slightly) without spending a lot of money.

Still, it is very cool they have something without cost for those that can use exactly what that is.

[billt]

Um, yeah. That's not going to happen. Darn, thought I had something there.

It's not a bad thought process to go through. If the source for a well designed core was available, it would be a great idea to be looking at that for ideas and to see if it can be mutated to our ideal here. The problem with that idea is that the really great cores are expensive closed source things, particularly if they have a corporate name on them, and the free/open ones are catching up. Though TG68 is at least getting some real attention and becoming far more than the simple 68000 it started out as.

Some other 68k cores to look at:
ao68000 (github is newer than opencores, is wishbone rather than 68000 bus, but is 32bit)
k68 (opencores)
suska

I'm not really familiar with other architecture cores to consider. There's others out there, but I don't know how well they compare to what Yaqube and TG are doing to TG68 now.
Someone started an opencores project for a simple PowerPC core called zCore that I'd like to look at, but they've never actually uploaded anything. There's an older ARM core somewhere, but as it's an older ARM version I'm not sure how advanced it may be.

[billt]

@billt
Is this the ARM project you mentioned? Doesn't look like much aditional worl has been done in a while.

http://opencores.com/project,core_arm

Plaz

Once upon a time there was a maybe more advanced one than that but ARM had it disposed of. If you look hard enough you might find it in some shady corner of the netiverse, but that was news over 10 years ago...

[billt]

I took bloodline's reference as a point of study of how to do another cpu project, not necessarily an ARM.

I haven't messed with VHDL in an uncountable number of years. Someone please point me to a good reference where I can retrain some brain cells on some tools needed here.

Plaz

My favorite, and I wish he had a Verilog "port" of this one:
http://www.amazon.com/RTL-Hardware-Design-Using-VHDL/dp/0471720925/ref=la_B001ITRMEY_1_3?ie=UTF8&qid=1358352110&sr=1-3

and:
http://www.amazon.com/FPGA-Prototyping-VHDL-Examples-Spartan-3/dp/0470185317/ref=la_B001ITRMEY_1_2?ie=UTF8&qid=1358352110&sr=1-2

http://www.amazon.com/Embedded-SoPC-Design-Processor-Examples/dp/111800888X/ref=la_B001ITRMEY_1_5?ie=UTF8&qid=1358352110&sr=1-5

And verilog "ports" of a couple of these as well:

http://www.amazon.com/FPGA-Prototyping-Verilog-Examples-Spartan-3/dp/0470185325/ref=pd_sim_b_3

http://www.amazon.com/Embedded-Design-Processor-Verilog-Examples/dp/1118011031/ref=pd_sim_b_2

Note that these won't really talk as much about some things one needs to know for an FPGA softcore sort of project, such as number representation and such, particularly floating point stuff. I'm currently checking out this one too (Verilog, but should be easy to understand and use toward VHDL projects too):

http://www.amazon.com/Computer-Arithmetic-Verilog-HDL-Fundamentals/dp/1439811245/ref=sr_1_1?s=books&ie=UTF8&qid=1358352361&sr=1-1&keywords=verilog+arithmetic

[billt]

Personally I prefer Verilog. But it lack som capabilities, I think it was in regard to level triggering etc. So VHDL is it.

Btw, those links are books , not hw.

I also prefer Verilog, but am now comfortable enough with VHDL to go either way.

He asked for references to retrain his brain since he hadn't used VHDL in so long... So book links seemed appropriate.