Skip to main content ↑ ↓
Topic: Use PIC SPI to feed Configuration to FPGA? (Read 7716 times) previous topic - next topic

Use PIC SPI to feed Configuration to FPGA?

I just thought of a potential feature for the OLSv2, but I'm not sure whether it would be useful beyond the prototyping phase. I'm not even sure that it would necessarily be a significant improvement during prototyping, so I welcome comments.

With all this talk about the Flash_Destroyer, as well as the upgrades to the OLSv1 to switch from UART to SPI, I got to wondering whether the PIC could take over the Flash and load the Configuration directly into the FPGA.

As I understand it, the FPGA automatically starts by pulling its Configuration directly from the Flash. The PIC also has access to this Flash in order to load different Configurations. Seems like it would be possible for the PIC to disable the Flash, reboot the FPGA, and feed a temporary Configuration into the FPGA via SPI without requiring the Flash to be reprogrammed.

First of all, I realize that it's a little silly to worry about Flash longevity. As soon as a final Configuration is developed which can handle all bitstreams, the Flash will probably only be programmed once and then left alone. Even during the development phase, it seems unlikely that the Flash would be worn out, especially now that work is being done that would avoid reprogramming the Flash whenever the user sets up for a different width (8-bit, 16-bit, 32-bit).  But if the feature I describe could be supported with a few clever traces and maybe a pullup or two, it seems like it might be worth it.

I guess the number one question is how to create a circuit that would disable the Flash under PIC control, but still allow for the default operation we have now where the FPGA automatically loads its Configuration from Flash. There are super tiny 5-pin decoders that are no larger than an SMD FET that could select between two sources for the Flash /CS.  If the select were tied to a default state by a pull-up or pull-down, such that the FPGA is the default master and the Flash is the default slave, then this could work. The PIC pin driving the select would have to default to Hi-Z at reset. The selector would have to switch things around so that the FPGA thinks the PIC is the slave instead of the Flash. Without /CS, the Flash would stay quiet whenever the PIC is taking control. The decoder chip would add cost, so perhaps an SMD jumper would be cheaper, and developers would simply add a jumper to allow this new mode.

The whole point of this suggestion is that a PIC firmware could be developed which holds an FPGA Configuration in RAM, as delivered over USB, and available for quick development and testing of new Configurations. Anyone working on FPGA design could download a new Configuration via USB, then instruct the PIC to reboot the FPGA and feed the new Configuration directly via SPI, temporarily disabling the Flash. Nothing burned, nothing risked.

Another consideration is that if the Flash is just as quick to program as a USB download of new data to PIC RAM, then perhaps there isn't much use for such a feature.

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #1 –
I hope that was entertaining ;-) because I just realized that you could use the JTAG interface to do the same thing without changing anything. In other words, the FPGA JTAG interface can be used instead of the SPI Flash as a source for a Configuration. So, anyone wanted to do what I suggest would probably have a Xilinx tool with JTAG support for trying out a new Configuration.

What inspired this whole thread is that I have been working on firmware for a TMS320VC5506 DSP using JTAG, but as soon as I finish the firmware I need to load a copy into the SPI Flash that's been sitting unused on my board all this time. My "brainstorm" was that it might be useful to skip the Flash for FPGA development just like I'm skipping it for DSP development. I jumped the gun, then looked at the datasheet and realized it's already there (page 37).

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #2 –
rsdio, your idea is good and feasible ... the mechanism you describe is implemented on most FPGA Development/Evaluation boards (like the Xilinx/Digilent/Avmet Spartan-3/3E/3A(N) boards - the 3AN having the special feature of it's own internal non-volatile memory) - actually all provide various boot options (serial (SPI) master/slave and parallel master/slave) for the FPGA that can be selected via jumpers ... giving the users the chance to evaluate the different options of loading the bitstreams into the FPGA including the option of using an onboard USB MCU (like our PIC18F24J50) to transfer the bitstream from the PC via USB to the MCU and the MCU - acting as a master - loading the bitstream directly into the FPGA via the SPI or JTAG interface. I think this is the most commonly used mode in FPGA development while loading the FPGA from flash is the predominat mode in standalone production systems.

Jacks original Butterfly 1.00 FPGA board had no flash memory for example ... it required a FT2232 based USB board that acted as a JTAG interface to load the bitstream every time it was powered on or reset. Today Jack still uses his FT2232 based USB board as a JTAG interface for his OLS development ...

We discussed the idea of directly loading the bitstream from the PC via the PIC directly into the FPGA via the SPI interface (discussion about SPI Master and Slave mode) in some detail during the early development phase of the project (the discussion started about here). In the end the idea was dismissed for the following two main reasons:

1. The use of the OLS should be as easy as possible and having the bitstream stored in SPI flash onboard means that no other software is required on the PC but the SUMP Java client - no need to run a "bitstream loader" every time you connect/reset the OLS (like the pump-loader we now use for bitstream updates to the SPI flash only) and no need to develop, integrate and support more multi-platform code.

2. The OLS board was not intended to be used as a FPGA development platform but is supposed to be a low-cost SUMP engine - like you said in your 2nd post, for development we have the JTAG interface and there is no real option but to use a JTAG adapter supported by the Xilinx ISE development package/iMPACT ;) After the decision in favour of the PIC (and against the FT2232) had been made it would have taken a considerable development effort and extra logic to make the OLS compatible with the Xilinx tools ... 

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #3 –
Thanks for bringing me up to speed, and also for your patience.

1) This reminds me of the question I'm looking into now with my DSP project. The board already has SMD pads for Flash and EEPROM, so I have both bootloader options with SMD jumpers to select between at least 4 different sources: USB, SPI (24-bit or 16-bit address).  But if I go with firmware in Flash, I need to write both the firmware and a command set for upgrading the firmware via USB unless I want users to be stuck with the original firmware. On the other hand, if I use the USB bootloader to go direct from host computer to DSP, I need to write Windows drivers and the user has to wait a few seconds for the firmware to transfer every time they plug in.  At the moment, I'm working under the assumption that I will ship with firmware in Flash and jumpers hard-wired to disable the USB bootloader.  I'll just have to add a USB command to write the Flash to support field upgrades of firmware, which adds to the product schedule.  Forgive the sidetrack, since this whole paragraph has nothing to do with OLS.

2) I feel embarrassed that I wrote that long initial topic posting before scanning the data sheet again to look for the details. Having the JTAG header on the OLS makes it perfect for both FPGA development and a cheap logic analyzer.

One thing that bugs me, but sorta makes sense is how JTAG devices are so proprietary.  The JTAG interface itself is a standard, but the pinouts for headers are not.  Plus, the interface between the computer and, e.g., a USB JTAG device is not standard.  In other words, I already own a 14-pin Texas Instruments JTAG 'emulator' but I suppose I would need to buy another JTAG device to work with Xilinx FPGA (unless, by some strange coincidence, the two look the same to the PC software).

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #4 –
Just looked at the Bus Blaster JTAG adapter thread and saw that your DSP design is based on a TI TMS320VC5506 ... nifty device comes with a preinstalled bootloader with a myriad of boot options (kind of like the SPARTAN-3E but) including direct USB  ... after a quick glance at SPRA840C and SPRA375F I can clearly see your dilemma:

The standard TI USB bootloader does not provide an option like the feature Ian implemented on the OLS .... it will load the code from the host and execute it without saving it to serial or parallel flash. But then TI says that the bootloader code is available, is based on their standard USB Chip Support Library and can be modified ... you may want to modify it in a way that it will try to upload the application from the host and write it to flash only when connected to a host upon stratup otherwise it just boots from flash ... one way or the other it will require some coding.

For discussing variations of JTAG interfaces and the general problem of proprietary interfaces between applications and JTAG adapters we should start a new general JTAG thread in the Bus Blaster high speed JTAG/flash programmer section, I think ...

The major problem with JTAG interfaces and adapters isn't so much the mechanical/electrical interface between the target (board) and the JTAG (probe) adapter but more the interface between host based applications and the JTAG adapters. These are in most cases proprietary. The same applies to many functions of the JTAG chain inside devices/chips. Silicon manufacturers and development/test tool developers will share certain information only among "the community" and with major customers and only after the receipients have signed strict NDAs. In the end any open source JTAG adapter and software can only support open architectures and applications unless it's reduced to a cable with a couple of level shifters/converters (i.e. parallel port Wiggler/. However, over the last couple of years many chip manufacturers and even software tool developers have carefully started to open up ... providing details about interfaces for their host applications and "special" on-chip features beyond the standard scan path (for testing), low-cost JTAG adapters, free software tools or even open tools like the TI XDS100 you mentioned.

If you want to develope with Xilinx FPGAs (Spartan-3/Virtex-5 and newer) and interact directly from within ISE/iMPACT or ChipScope with your target you will have to use one of the JTAG adapters directly (or indirectly via a plug-in) supported by ISE/XIlinx tools  - your TI USB JTAG adapter will not do because it will not be recognized by iMPACT ... (eventhough the XDS100 is an open design, TIs licensing policy does not allow the design to be modified/sold for use with any other but TIs products). If you are looking for a JTAG adapter for Xilinx FPGAs check the Digilent XUP USB-JTAG Programming Cable. It's compatible with the Xilinx Platform Cable USB (not sure if it supports the new Spartan-6 and Virtex-6 FPGAs), costs less than half the price and comes from the company that designed many if not most of the CPLD and FPGA development and starter boards Xilinx sells including the onboard USB JTAG interface (based on the Cypress FX2 USB MCU and a Xilinx Coolrunner CPLD). There may even be a solution for JTAG adapters not directly supported by Xilinx: Digilent offers a plug-in for ISE that will allow the use of their low cost JTAG adapters/cables in connection with their (free) Adept Programmable Logic Software  ... I never tried it but there seems to be a way of using other than the supported JTAG adapters with ISE via plug-ins.

Just noticed this on the Digilent site: "The XUP USB-JTAG cable is currently only available to academic customers." ;)

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #5 –
Thanks for the details about the Xilinx JTAG (which are, of course, on-topic).

I look forward to reading any thread about JTAG varieties in the Bus Blaster forum.  With the Bus Pirate able to program the PIC, maybe the Bus Blaster could be useful with the Xilinx in some way.  Neither would allow full debugging, but at least simple programming is possible.

As for the TMS430VC5506, yes, it's quite cool, even if off-topic.  The ROM reads 4 I/O pins as inputs and then selects a bootloader mode. There are obvious a lot more options than the 4 that I might use (but not all 16 possibilities have been defined).  The USB bootloader, in particular, has a fixed VID/PID. That makes perfect sense when you consider that it's in ROM. The VID is Texas Instruments. You can obviously load any kind of firmware you want, including an interim firmware which programs the Flash.

I have already written a minimal firmware which has my product firmware in a giant array. This minimal firmware reads the Flash and compares it to the massive array, and if any differences are detected then it erases the Flash and programs the entire contents of the array into the Flash. This is a bizarre way to program the Flash, because it requires another tool that I wrote to convert the hex file of the product firmware into C source code that I then compile into my minimal firmware. I currently use the debugger/emulator to download and run this firmware, but I could just as easily get it on the chip using the USB bootloader.

There are third-party systems in the TMS320 community which do something similar, allowing the product firmware to be downloaded via USB using a minimal firmware like the OLS PIC Flash programmer. These require moderately-expensive licenses and only run on Windows because that's where their driver / DLL runs. I think the trade name is FlashBurn. I chose to save the money and potentially be able to support Mac or other Unix for the assembly line. I may eventually write something like it myself, but I like the minimal approach because it avoids data transfer and timing issues completely.

One thing I was thinking of is to have a button that would switch boot from Flash to USB so that the assembly line could load product firmware into the Flash. Problem is that making one hidden switch change 4 I/O pins requires some logic or lots of through-hole soldering, and I'd rather have nothing in the Bill of Materials that isn't needed by the end user. A header with jumpers or some logic gates that do nothing but enable a one-time Flash programming could affect the retail price. The discussions of pogo-pins in other threads of this forum have given me ideas for ways to do this without putting one-time-use parts on every board.

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #6 –
Xilinx impact supports FT2232 based cables through library preload (on linux) and I am not sure about windows.

I was thinking about the same - wire the Mx pins to the PIC and be able to load the bitstream directly from PC. There is one catch :) There are not many free pins on the PIC. Maybe Ian could add "solder bridges" that would be able to overdrive the Mx pins of the FPGA for anyone who is willing to experiment...

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #7 –
[quote author="robots"]Maybe Ian could add "solder bridges" that would be able to overdrive the Mx pins of the FPGA for anyone who is willing to experiment...[/quote]Good suggestion, although space is tight.

Solder bridges are so old-school, though. The easy, modern equivalent is an SMD resistor or SMD jumper. They're easy to place when designing the PCB and easy to populate. You can even decide to fill them during manufacturing if the idea takes off.

My habit is to use the UK resistor symbol for such bridges in my schematic, and the US resistor symbol for normal resistors. That way I can tell what's what at a glance when looking at the schematic.

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #8 –
There should be SMD resistors to pull these pins the right way for the FPGA to retrieve the data from dataflash and solderbridges could be on the other side, to allow changing of the config sequence. There is lot of space on the other side :)

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #9 –
You could put the idea about the option to load bitstreams via PIC SPI directly into the FPGA up in the Logic Sniffer v1.03 manufacturing update thread ... maybe Ian and Jack will catch on.
robots suggestion to put all resistors required for both configurations on the top side and solder bridges on the bottom (the layout should by default enable the current SPI Master mode so no soldering will be required in production) would increase the production cost only insignificantly. :)

rsdio pointing at the TI XDS100 and robots making the comment about the Linux version of ISE supporting FT2232 based JTAG adapters may become rather valuable information to be considered for the Bus Blaster JTAG adapter concept: I can't read anything in the TI license for the XDS100 that would disallow to build an adapter that is compatible with the XDS100 but a design of its own. ;)

Jack could feed us in on using a FT2232 based JTAG adapter with the Linux version of ISE - that's exactly the combination he used for developing the OLS bitstreams.
I will give the Digilent plug-in that seems to allow to use their (not Xilinx Platform Cable USB compatible) low-cost JTAG adapters with the ISE Windows version a try one of the next days ...

If the Bus Blaster will incorporate a CPLD or FPGA besides the FT2232H it would become feasible to provide XDS100 comaptibility (support for some TI DSPs and ARM/DSP hybrids), maybe even make it "Xilinx iMPACT compatible" ... 

rsdio, I think I never answered your question about sources for "spring loaded contacts" like Parallax uses on the edge connector of their USB programming adapter ...

Basically they are called pogo pins, too ... or spring probe connectors. They come in SMD and through-hole versions so you can mount them on PCBs.
Harwin is one manufacturer ... try their P20-XX Product Families or look for "spring probe (test) connectors/contacts" at Mauser and Farnell/Newark. They would work well in production for programming and testing the product you are developing (and make the extra switch and logic you described unnecessary) ... if you don't put components on the backside of your PCB design you can place contact pads (solder bridges^^) there and design a matching programming/test PCB with the pogos. You should talk with the assembler first ... the design of the adapter must match his equipment. 

Re: Use PIC SPI to feed Configuration to FPGA?

Reply #10 –
[quote author="IPenguin"]
You could put the idea about the option to load bitstreams via PIC SPI directly into the FPGA up in the Logic Sniffer v1.03 manufacturing update thread ... maybe Ian and Jack will catch on.[/quote]
I actually started this thread by putting a link from the Revision 2 design discussion thread. But there haven't been any additional comments there since my posting.

Quote
I can't read anything in the TI license for the XDS100 that would disallow to build an adapter that is compatible with the XDS100 but a design of its own. ;)
I think that Texas Instruments would not be able to do anything so long as you don't use the XDS100 brand name, and did not use their VID. The question then becomes: How does the Bus Blaster work with existing TI tools if it has a totally new name and VID/PID? The good news is that hackers can change the VID/PID on their own and DP would be safe as long as they don't directly provide the files or instructions.

Quote
If the Bus Blaster will incorporate a CPLD or FPGA besides the FT2232H it would become feasible to provide XDS100 comaptibility (support for some TI DSPs and ARM/DSP hybrids), maybe even make it "Xilinx iMPACT compatible" ... 
At the very least, having a CPLD type device on board would make it a fun learning experience, and would open up opportunities for many alternate uses!

Quote
rsdio, I think I never answered your question about sources for "spring loaded contacts" like Parallax uses on the edge connector of their USB programming adapter ...
Thanks, but the one question that remains open is where do I get the non-conductive clip that fits around the back side of the board. The commercial product that I saw at one of the provided URLs had conductors on the top and a clip on the back. I could 3D print such a thing, but my experience is that 3D material these days does not stand up to repeated use. It seems doubtful that a pre-fab part exists for this, since there could be many useful variations, but maybe...