FPGAARCADE minimig compatible board, comments?

[mikej]

I think it's going to be G.A.M.E

General Arcade/Amiga/Atari/Anything Machine Emulator



Any other offers ??

[mikej]

Hi all,

"Does this new motherboard mean that it is going to be in direct competition with the Minimig and eventually kill it off?"

Not necessarily. MiniMig, like the FPGAARCADE board (whatever we call it) is just a platform to run the firmware on. The FPGAARCADE board is more flexible, and I also write the firmware for it so it will be more compatible eventually and run more systems. I am designing this board as I want a better platform to test the code I write on.

I had a chat to Dennis about this and we are both keen to keep a common codebase as much as possible. There will be some additions to the MiniMig firmware to make it work on my board, and hopefully most improvements will be picked up by the MiniMig build as well.

The FPGAARCADE board has an external 68K and the FPGA is big enough to fit an internal core. The idea is the first few boards will be fitted with the 68k and used to test the internal core. You can run both processors in lock step and see if there is any differences. They you can fix the softversion. Then you can not-fit the external 68K and use the softcore (which can be clocked faster). All the pins that the external 68K uses go to the expansion connector so they can be used as IO, or an external processor can be used. I maintain the T65 and T80 (6502/z80) cores on opencores, and this was the trick we used to bash out most of the bugs.

The AVR handles the SD card file system but all the processing is done in the FPGA. I need to do this to handle Atari disk formats as well.

Ethernet port is also going to be an option for the daughter board.

Cheers,
Mike.

[mikej]

Some really good suggestions. I think we want to stay away from certain fruit related products.

I really wouldn't recommend even thinking of a case until the thing is manufactured, routing may cause minor placement changes.
/Mike

[mikej]

mm

Computing and Retro Arcade Platform

is sadly C.R.A.P

R.A.P Retro Arcade Platform ?

Retro Arcade Gaming Engine/Emulation (R.A.G.E.)
Retro Arcade Computing Engine/Emulation (R.A.C.E.)

Generic Arcade Machine Emulator (G.A.M.E.)

quite hard choice this
/MikeJ

[mikej]

mmm about to publish the schematics, really need to choose a name....

Generic Retro Machine Emulation (G.A.M.E.)

Anybody think of another word that doesn't imply "emulation"?

/Mike

[mikej]

that starts with "e"

[mikej]

I have posted the current schematics on
www.fpgaarcade.com

Comments & questions are welcome.

Mike.

[mikej]

"I did not see the termination resistor (@ 100 ohm depending upon the actual Zdiff of Mem_CLK_P & Mem_CLK_N) across the DDR diff pair of Mem_CLK_P & Mem_CLK_N. This termination resistor should be placed near U6, the DDR IC (TSOP66)."

The memory clocks are complimentary signals, not differential so I have got two 51R to VTT placed after the memory. I would use a 100R between the P and N signals if I did not have a termination supply.

As the traces are quite short, and the board is pretty close to 50R on the signal layers, I think I could actually get away without the termination on the rest of the signals, certainly on the address lines. I have run it through Hyperlynx and the signals look ok, but they are better with the termination.

I think what will happen is I'll build a test board without the terminators and just a 100R across the clock nets and see how wide the margins are. A cost reduced board may follow later.
Cheers,
Mike.

[mikej]

"DDR pcb has to be impedance controlled, and you have to have a range/window of trace length matching for different group of DDR I/O in order to meet timing requirements of DDR."

I am matching all the DDR signals to the clock pair within 50ps. You can cheat a bit and fiddle things with the FPGA to an extent to put the clock in the correct phase with respect to the write data. Recovering the read data is a right pain.
/Mike

[mikej]

Good advice, thanks.
I have been working with DDR2 recently (I design ASICs which use DDR2 external memory). We made a few boards and experimented. We found that for short traces you can use no termination up to at least 600Mbit as long as you are point to point with no additional vias. Adding the series termination made things slightly worse actually, we think due to the via stubs.  

With the Spartan3 I haven't got the same control over the memory timing or drive strength/termination I get with Virtex5 or the ASICs, so I am being a bit more careful. I've put the termination resistors in the middle of the trace which works well in simulation. It also has the benefit I can remove them to test that configuration without any stubs.

I saw the Micron app note. As far as I can figure out the input buffers for the clocks are single ended, so in theory the traces should be 50R impedance and terminated to VTT. Most people do use a 100R across the clocks, but if there is any skew between the clocks the VTT termination would work better. In our designs with faster memories (RLDRAM and SRAM) we always use a resistor to VTT. I could save a resistor though .....

Cheers,
Mike.

[mikej]

ha ha, that should be complementary clocks not complimentary - although I quite like the idea of free clocks

I am discussing this 100R verses two 50R with some other people, looking around you see both. I am not sure at the moment which is "more correct" - they are probably both fine.
/Mike

[mikej]

"Why not just call it Perfectly Obsolete Retro Nostalgia."

mmm, actually that's not a bad idea

Updated layout pictures from the complete board at www.fpgaarcade.com
It's off to manufacture we go ....

Regards,
/Mike

Edit: Fixed link, thanks Chris.

[mikej]

"Excellent work/news Mike.

I hope you don't mind if we create a new section over on www.Minimig.net for your board."

Sure Darrin, feel free.
The forum at fpgaarcade will be active shortly as well.
/Mike

[mikej]

Latest schematics are up if anybody wishes to have a look / comment. A few days to go until manufacture now....

www.fpgaarcade.com

Cheers,
MikeJ

[mikej]

Hi Chaps,
Thanks for the comments.

One thing I added in the latest version was the polyfuse and TVS diode for this reason. They will be populated assuming there is no problem with them.

The TVS diode will start to clamp at 5.somthing volts and the polyfuse will open. Likewise for reverse polarity the diode will go into full conduction and the fuse will open (fast). It is not a perfect solution as the 5v devices are still exposed to some risk, but I think it is an acceptable compromise. There is not much on the 5V rail apart from the switchers and protection diodes.

I would prefer a 12v to 5v step down like you did, but I can only fit it on if I compromise the other power supplies, and I am expecting to be pulling quite a bit of power on the FPGA core and 3V3 rails. The 2V5 supply also drives the termination regulator so I can't do much there either. I am trying to keep the cost down as much as possible also.

I imagine that normally the board will be used in a mini-itx case with a decent 5v regulated supply.


These polyfuses by the way fix themselves when the problem is removed.

Best,
Mike.
oh Illuwater, I am also in Sweden (Stockholm) although I am not Swedish.

[mikej]

There is going to be another update.

Originally for hard disk usage I was going to use an IDE connector and either hard disk or CF disk on the daughter card. It would be a great feature to have hardfile support from the SD card for the base platform. The AVR SPI transfer speed in this case is limited to about 300KBytes per second. This is ok for floppy and booting, but not great.

So, I am going to add a multiplexer which lets the FPGA master the SD card directly. The AVR will still contain the knowledge of the file system and talk over the current SPI link to the FPGA. The FPGA will then enable it's second SPI interface (reusing the 4 IO programming pins which conveniently already go to the AVR part of the PCB) and take over the job. Depending on the SD card we should get transfer speeds of several MBytes per second. This will delay the board a week or so.
so comments can still change things
/Mike