Dangerous Prototypes Open Source Hardware

Re: Parts list (rough design, options)

Reply #75 – December 01, 2009, 01:14:35 am

I just checked in an update to the layout of the components on the FPGA side. I updated Ian's preferred 'C' layout, I think this should work for the FPGA side. Still up in the air is the location of the oscillator and which Global Clock will be used. Thank you for sharing the Design Note Klaus, and it looks like the JTAG port will probably not cause too much of an issue for routing so at this point lets leave it in.

Re: Parts list (rough design, options)

Reply #76 – December 01, 2009, 11:56:40 am

The JTAG works well there, if we don't try to move it to the edge of the PCB I think it will be fine. It's just for debugging.

Is there any reason the PIC needs to switch the 2.5v and 1.2v power supplies? I have the PIC connected to the /enable pin, but it would be nice to not route that trace. I'm not sure what good it is considering A) PROG_B resets for programming, and B)is it even ok to partially power the FPGA (3.3v to banks, 2.5v and 1.2v unpowered)?

I made a few minor updates and checked the PCB into SVN:
*Moved auxiliary UART I/O to 5volt tolerant pins. Makes it tolerant to old 5v MAX232 transceivers.
*Changed to smaller xtal, not sure this is permanent.

More importantly, I assembled a list of PIC->FPGA connections that I'll use to assign PIC pins:

*FLASH_CS
Shared chip select signal for ROM chip. Connects to ROM, FPGA, PIC, programming header. Uses PIC general IO pin.

*MOSI
Shared SPI data pin for ROM chip, SUMP UART TX, future SPI connection to FPGA. Connects to ROM, FPGA, PIC, programming header. Uses PIC SPI module 2, UART module 2 (module pin location is programmable).

*MISO
Shared SPI data pin for ROM chip, SUMP UART RX, future SPI connection to FPGA (also an interrupt from FPGA to PIC when FPGA_CS is disabled). Connects to ROM, FPGA, PIC, programming header. Uses PIC SPI module 2, UART module 2 (module pin location is programmable).

*CLK
Shared SPI clock pin for ROM chip, future SPI connection to FPGA. Connects to ROM, FPGA, PIC, programming header. Uses PIC SPI module 2 (module pin location is programmable).

*FPGA_CS
Chip select pin to future FPGA SPI interface. Connects to PIC, FPGA. PIC general IO pin.

*FPGA_DONE
Indicates FPGA loading is complete. Connect to PIC, FPGA. PIC general IO pin (needs pullup). PIC general IO pin.

*FPGA_PROG_B
Holds FPGA ROM pins HiZ while PIC writes an update to the ROM. Connect to PIC, FPGA (needs pullup). PIC general IO pin.


That's 3 reprogrammable RPx pins, and 4 general I/O pins.

Other non-required peripheral connections:
*MODE LED to show RX/TX activity and bootloader entry (probably FPGA should have a LED for armed/trigger/error).
*2 pins to 5volt tolerant external UART (uses fixed UART1 module).
*Vregulator enable (?)
*2 ADCs to measure 2v5 and 1v2 output(??)

Re: Parts list (rough design, options)

Reply #77 – December 02, 2009, 12:32:34 pm

Are the FPGA pins 3v3 tolerant, or are they only intended for use with the same voltage as the IO input voltage?

If the pins are 3v3 tolerant, we could eliminate a lot of power supply stuff on the FPGA side by running the I/Os at 2v5.

We can't get rid of the 3v3 supply because the PIC needs an external regulator to supply the 3v3 USB voltage. We could run the PIC at 2.5volts too, but it still needs the 3v3 supply on the VUSB pin. If the FPGA pins are 3v3tolerant when running at 2v5, then we could have the PIC at 3v3 or 2v5, whatever is easiest to route.

Re: Parts list (rough design, options)

Reply #78 – December 02, 2009, 01:07:27 pm

I looked through the datasheet and it appears that you can go above VDD, up to 4.x volts in some situations, but really Vdd+0.5volts is the max recommended voltage.

If the PIC and buffer were both 2v5, then this might be possible, but for expansion wings we'd probably do well to make sure the pins are 3v3 tolerant.

I checked in an update to the PCB.

Changes:
*Chose pins to connect to FLASH SPI, DONE, PROG_B, and routed them to get a feel for the layout.
*The two bottom-layer routed traces are NOT high speed nor do they change in normal modes (FLASH_CS, DONE).
*Chose PIC pin for FPGA_CS. (not routed)
*Named 3 FPGA_AUXx pins to connect between the PIC and FPGA for future development.
*Did some routing to get a feel for my side of the PCB. Nothing's set in stone.
*Reordered ROM header for easiest routing
*Moved ROM slightly away from FPGA for easier routing and soldering.
*Removed VREGEN connection, power supplies hard-wired on.
*Changed license to noncommercial to limit use of the design before we finish.

Still needed:
*Power routing on PIC side (and to FPGA side)
*MCLR pin routing
*FPGA_CS, and FPGA_AUX1-3 route to FPGA (choose FPGA pins)

Re: Parts list (rough design, options)

Reply #79 – December 02, 2009, 01:35:25 pm

One last post for the day...

My to do list:
*How to activate ROM update (add jumper or button)?
*Check port B pullup resistor isn't hurting the 2v5 pins (DONE, PROG_B)
*Add resistors for DONE, PROG_B as indicated in the datasheet
*Add pull-downs/ups to SPI FLASH configuration pins as indicated in the datasheet
*Check buffer supply.
*Add LED for USB power to PIC side
*Add armed, error LEDs to FPGA
---
*Power routing on PIC side (and to FPGA side)
*MCLR pin routing
*FPGA_CS, and FPGA_AUX1-3 route to FPGA (choose FPGA pins)

Jack mentioned not finding the buffer I used, it made me nervous about supply problems. There are a number of high-speed, 3v3 supply 5v tolerant input 573 buffers, but I used this one from Fairchild:
http://www.mouser.com/Search/ProductDet ... 74LVT573WM

Re: Parts list (rough design, options)

Reply #80 – December 02, 2009, 02:27:27 pm

Couldn't leave it alone.

*Moved DONE to RA5 out of concern for internal PORTB pull-up violating the 2v5 limit on DONE during programming and debugging.
*Verified that RA5 will detect 2v5 as a high level (TTL H = 0.25vdd + 0.8 =  1.625)
*Added power LED
*Added ROM update button
*Added 2 LEDs to FPGA side (current sink)
*Added DONE, PROG_B resistors to 2v5
*Added INIT_B resistor (as in diagram, ) Will move ROM over when I have verification this is needed.

New TO DO:
*Add pull-downs/ups (?) to SPI FLASH configuration pins as indicated in the datasheet
*Check buffer chip supply.
*Power routing on PIC side (and to FPGA side)
*MCLR pin routing
*FPGA_CS, and FPGA_AUX1-3 route to FPGA (choose FPGA pins)
*Need INIT_B resistor to 3v3?
*Need HSWAP pull-down?
*How to place ROM in manual in manual programming mode without PIC pin on PROG_B (through jumper, as in datasheet diagram?)

Re: Parts list (rough design, options)

Reply #81 – December 02, 2009, 03:04:33 pm

Still can't leave it alone:
*MCLR pin routing
*FPGA_CS, and FPGA_AUX1-4 route to FPGA (didn't attach, just chose NC pins)
*Added PROG_B pulldown jumper for manual ROM programming
*Moved ICSP to bottom for much nicer, cleaner routing.
*Messed up power supply area a bit for now.

New TO DO:
*Add pull-downs/ups (?) to SPI FLASH configuration pins as indicated in the datasheet
*Check buffer chip supply.
*Power routing on PIC side (and to FPGA side)
*determine and connect FPGA_CS, and FPGA_AUX1-4 pins
*Need INIT_B resistor to 3v3?
*Need HSWAP pull-down?

Re: Parts list (rough design, options)

Reply #82 – December 02, 2009, 06:11:02 pm

[quote author="ian"]
*Added PROG_B pulldown jumper for manual ROM programming
[/quote]
If you connect your programmer first and than set the jumper to programming you could get problems (BTDT). I would  add two pins to the programming header, one for a ground pin and the other for PROG_B. A bridge in the connector would switch automatically to manual programming when you insert the connector.

Klaus Leiss

Re: Parts list (rough design, options)

Reply #83 – December 02, 2009, 11:23:44 pm

Today I found a low cost Spartan-3A evalauation kit by Avnet - Xilinx® Spartan®-3A Evaluation Kit with a surprisingly similar concept of Ian's and Jack's current design approach.

USB MCU (Cypress PSoC), SPI Flash, Spartan-3A FPGA for less than US$ 50. Now the really interesting part is the documentation on how they have interfaced the MCU, SPI Flash and FPGA and how the MCU controlls everything. On top of that the MCU acts as an intelligent communication interface and there is a quite extensive API for application software development on the PC side (so only for Windows) ... lots of good and detailed documentation (schematics, API reference, user interface ...).

Maybe the most interesting reads (explaining in detail how to implement the MCU/SPI/FPGA/JTAG interface) on the Xilinx Spartan-3A Evaluation Kit's design resource page are:

- Xilinx Spartan-3A Evaluation Kit - User Guide
- Application Programmer Implementation Guide
- Serial Flash (SPI) Configuration
- Slave Serial Configuration from a Processor
- Schematics for Xilinx Spartan-3A Evaluation Kit

The MCU on their bord controlls the FPGA - unless a JTAG interface is attached. The MCU controlls the FPGA "configuration" pins thus allowing various configuration options - Master SPI Mode (from SPI Flash), Slave SPI mode (direct load from PC via MCU into the FPGA) and Parallel Flash (BPI) Mode (not of interest in this project).

Eventhough it's a Spartan-3A based design most if not all details apply to the Spartan-3E as well.

Re: Parts list (rough design, options)

Reply #84 – December 03, 2009, 12:54:05 am

I like the Spartan 3A Evaluation kit, whenever I get some time to make a Spartan 3A based Cocoon that kit is what I will pattern it after. They actually have a really good webinar about how they accomplished their low cost power supply, I think it is on the TI website. Luckily for us the only two modes of programming that we support is SPI Slave and JTAG. We have the config pins set for SPI Slave and JTAG is always active on the Spartan 3E. Maybe for version 2 we will see what tricks we can adopt from this kit.

On another note, I just routed all of the IO pins for the Buffer and the Wing and have checked them into SVN.

Re: Parts list (rough design, options)

Reply #85 – December 03, 2009, 01:05:59 am

What happened to the use of •M74LCX16245 16 Bit buffers.?  
The M74lcx16245  was a bidirectional buffer where as th 74lvtx573 is a  Latch, I don't recacll a discussion on why a latch was required  Note 74LCX245 is an 8 bit version altough the savings are small

If still planning to support 100mhtz, I suggest adding 22ohm serial termination resistors as was mentioned in  an earilier post/

Re: Parts list (rough design, options)

Reply #86 – December 03, 2009, 01:07:07 pm

I'd like to add the termination resistors, especially if we use the 8 channel buffer.

Here's an update, files checked into SVN:
*Moved MCLR trace
*Cleaned up power supplies
*cleaned up ROM, moved, routed power
*Cleaned up a few tight areas on the PIC side
*Assigned and connected the 5 FPGA_AUX connections between the PIC and FPGA.

New TO DO:
*Check buffer chip supply.
*Power routing on PIC side (and to FPGA side)


Jack, have you already connected the FPGA SPI FLASH mode configuration pins?
Do we need the INIT_B pull-up resistor to 3v3 (it is on the CCT)?
I don't think we need the HSWAP pull-down (is not on the CCT), but I'm not sure.

Re: Parts list (rough design, options)

Reply #87 – December 03, 2009, 04:05:59 pm

wow, this is coming together quite nicely and faster than I thought ...

One more suggestion (for now): I'd add a pin for +5V (in) on the UART (legacy) header ... the +5V trace from the USB connector to the power converters runs right by the connector ... to allow for use of the LA without connecting it to a USB device ... and (so this will require an extra jumper to select between USB power and external power) to allow for external powering in case the LA is used via USB on a laptop i.e. that can't provide sufficient power via USB or if header boards will be used that would kick up total power drain beyond what can be drawn from/provided by USB.

Re: Parts list (rough design, options)

Reply #88 – December 03, 2009, 04:51:48 pm

Yes, that's a really good idea.

*Add 5v pin to UART header.

Re: Parts list (rough design, options)

Reply #89 – December 04, 2009, 12:10:01 am

I didn't get much chance to work on the design today but I was able to rotate the JTAG port to make routing a little nicer.