Welcome, Guest. Please login or register.

Author Topic: Minimig PCB run - interest thread  (Read 99148 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Dennis

  • Full Member
  • ***
  • Join Date: Dec 2005
  • Posts: 128
    • Show all replies
Re: Minimig PCB run - interest thread
« on: July 25, 2007, 09:14:41 PM »
May I give some suggestions?
If you do a new board design please change the following from the orginal design:

1) Use a single chip ram like this one, available at digikey for example.
2) Include a +5V regulator on board OR use an ATX-style powerplug if you go Mini-ITX. The +5V regulator should be capable of providing about 1A to safely power all peripherals one might attach.
3) Hardwire the patch needed to get the current board to run. Alternatively, you can also swap pin81 and pin 79 on the FPGA. This way you still have four user-IO's left. You do need to change the .UCF file though and recompile the core.
4) The MMC card interface has a resistor based clock gate circuit around R50,R51. This should be replaced with a proper (single) gate "OR" chip. The margins on this signal are pretty tight on the current board. Also, R49 should be 0 ohm ideally to avoid problems when upgrading the PIC to a newer PIC18LF2620 or something similair. Margins are tight on that signal too atm.

And you could do the following optional improvements:

5) You could consider using a single 20MHz oscillator and figure out how to program the DCM to generator the proper clocks, this would spare a crystal.

Have fun!

PS Offcourse I would like one too!  :-)
 

Offline Dennis

  • Full Member
  • ***
  • Join Date: Dec 2005
  • Posts: 128
    • Show all replies
Re: Minimig PCB run - interest thread
« Reply #1 on: July 29, 2007, 10:09:56 PM »
Quote
What could be different and may cause an issue between these SRAM parts is ground/VCC bounce since the PCB is only 2layer and lends itself to a higher inductive volatge drop Ldi/dt on the power and ground connections to the ICs. We can only tell this by testing some of these SRAM parts in an actual 2layer MiniMig PCB.


That can be a problem. On the current board I have had none of such problems however. A friend of mine used to pause Lemmings the whole night and the board was still running every morning. The ground path from RAM to FPGA is pretty wide so inductance is probably not too bad. A single ram chip would be even better though, as no signal routing is necessary on the ground plane.

Dennis
 

Offline Dennis

  • Full Member
  • ***
  • Join Date: Dec 2005
  • Posts: 128
    • Show all replies
Re: Minimig PCB run - interest thread
« Reply #2 on: August 01, 2007, 09:13:47 PM »
After reading this thread, I think it's best to just keep the first "batch" of Minimig's simple and plain, so no PCI, no USB  etc. The Minimig is already complex enough in it's current form and if we get the hang with the rev1.0, we can move to rev2.x. That board can be mini-itx with larger fpga, usb, sdram, compactflash-harddisk... but I would stay away from PCI slots and ram slots. SDRAM is so cheap nowadays you can just solder 32mbytes onto the board for a couple of dollars. Saves the hassle of making the board compatible with any brand of ram sticks out there. Also, who needs PCI if you can code your own graphics card into the FPGA?? Just a simple framebuffer would suffice to create an 800*600 16bit color desktop. Switching the monitor from rtg to ocs? Just a couple of lines of verilog. Coupled with a 20Mhz 68000 or even a 68020 it would be very nice and still simple to build, maybe even on 2 layers.

So, my proposition is that the minor revisions be all core/firmware compatible (so rev1.1 would have the bugs fixed but still be 100% compatible with 1.0) and 2.0 will have different fpga, different ram etc. If we keep the verilog code modulair, we can build cores from the same source tree for both rev1.x and rev2.x boards. If you look at the code now, only minimig1.v and minimig1.ucf are board specific, all other sources could be re-used for a rev2.0 board.

Dennis
 

Offline Dennis

  • Full Member
  • ***
  • Join Date: Dec 2005
  • Posts: 128
    • Show all replies
Re: Minimig PCB run - interest thread
« Reply #3 on: August 03, 2007, 08:40:28 AM »
Well done to convert the schematic.
I'll try to answer all of your questions/observations.

Quote
* The +1.25V and +2.5V can be connected to +3.3V to save power. Due P_heat=U_drop*I.

The LM1117 has a dropout voltage of 1.3V, so the +2.5 must be connected to +5V to be able to regulate properly.
Besides, power dissipation will be the same; it doesn't matter if the heat is dissipated in +3.3V regulator or in the +2.5/+1.25V regulators.

Quote
* Howcome the many connections to the fpa isn't in numerical order?

The connections are made that way to ease the PCB layout.

Quote
* What is the value of C37 100uF/6.3V ?

Yes.

Quote
* Why is R42 present?, it's just sitting between +1,25V and GND.

R42 is to provide a minimum load for the LM1117. Just to be sure.

Quote
* Howcome (54,55,56) M1,M0,M2 is connected to VccAUX, doesn't it need 3.3V?

No, they need +2.5. All config pins on the spartan do. If you want to connect them to +3.3V, proper current-limiting should be applied.

Quote
* The 'SPI_DOUT' from the fpga and SPI_DOUT from the sdcard (via 1k) can drive eachothers output, maybe this can be resolved with an or gate or such instead?

A gate would be better. During normal operation, the SPI out of the MMC card is tristated by disabling the MMC, the same goes at the FPGA side (it's a tristate port). This way, they can share the SPI bus.

Quote
* Maybe the keyboard and mouse can share connection?, I've seen that on laptops asfair (saves i/o).

That is possible, but you still need 4 I/Os. It does save a PS/2 connector though.

Quote
* There's no over/under potential protection for keyboard or mouse?, like video output have. Howcome?

It is a minimal design. The spartan has built-in ESD protection that this design relies on. However, monitors and TV's are notorious for blowing up video ports so extra protection has been added there!

Quote
* Maybe the rs232 output of mcu and fpga can be shared without a jumper by setting an AND-gate between. Because the default level for rs232 is "1". And thus any transmission will produce "0", and if the other maintain the rs232 "1" resting state. IT should work.

Yes, no problem. However, all debug output of the PIC has to be disabled as not to interfer with the FPGA serial output.

Dennis