I am very interested in being able to place new bitstreams into Platform Flash from inside an XC3S chip (preferably using Arlet's 6502 core). I know it can be done, and there are some pointers to how - there is an ancient Xilinx app note, there is a more recent one on storing application data in Platform Flash, etc.

Xilinx HDL guide shows something called 'BSCAN_SPARTAN3' which may be the key to controlling the JTAG pins after configuration.

Before I start digging mounds of dirt, has anyone done that? Or seen someone else's work along these lines?

I am especially interested in understanding the bitstream flavor (svf, perhaps) and doing it pretty low level - without layers of JTAG libraries and large OS requirements. I am convinced that the recipe for flashing is pretty simple once boiled down to specific JTAG commands.

Thanks in advance for any information.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

From a mostly-unrelated spate of research I did recently, I'd suggest that you get the "Spartan-3 Generation Configuration User Guide" (UG332) from Xilinx, and see if that covers what you need to know. I'd also try to hunt down datasheets for whatever external flash chip you're using for the bitstream and seeing if that helps at all.

I'm really, really inexperienced with FPGA stuff, so this is about the extent of what I can suggest, and I'm sure that at least half of it is obvious. I wish you the best of luck with this, though.

enso:

The answer is that it goes very much along the lines described in the Xilinx app notes. I did not do the actual work, but I did commission it. Although you will probably want to use the serial port, our in-system Platform Flash reprogramming module uses an Ethernet interface also contained within the Xilinx Virtex 5 FPGA. I am not able at this time to release the source code (or a netlist) for this function, and it would not likely be of much use to you since it's in VHDL.

I think that you are coming at this from the CHOCHI FPGA board perspective, because you have used a Xilinx Platform Flash for that design. For my 6502 board using a Spartan 3A XC3S50A/XC3S200A device, I have chosen to use the SPI programming mode. Although the Xilinx Platform Flash is very simple to use and it is JTAG reprogrammable, my FPGA team and I have chosen a different path for any future designs.

There are two reasons for this course change. First, Xilinx has informed me the further development of the Platform Flash product line is not a priority. It is not their intent to terminate the production using existing fabrication lines, but like the case with the Spartan II family, if a fab change is required, then support for whatever products are being manufactured by that fab that can't be easily ported to another fab will simply cease to be produced after a last-time-buy notice is given.

Second, there's a substantial amount of complexity associated with using the BSCAN_SPARTAN component to program the Platform Flash from within the FPGA. First, there's a set of FPGA pins, not its own JTAG pins, that must be reserved and connected to the Platform Flash's JTAG pins. Second, the app notes simplify the problem by allowing only one device in the JTAG chain. Thus, on the CHOCHI FPGA board, there is a need to have separate JTAG chains for the FPGA and the Platform Flash.

(Sorry, still haven't soldered the connectors onto the CHOCHI board you sent me, so I can't say if you have one or two JTAG chains designed into the board. From the connectors that you sent, I would venture a guess that you put the Platform Flash and the FPGA on a single JTAG chain. This would mean you'd have to take the data in the app notes, and extend it account for the two devices on the chain.)

For my team's purposes, we wanted a path to higher density parts, and since Xilinx has issued that warning to us regarding its Platform Flash product line, my team and I have chosen to follow the third party SPI Serial Flash path recommended by Xilinx. On my Spartan 3A 65C02 FPGA Development board, I chose to use SPI configuration devices. It's is fairly straight forward to use these devices with all Xilinx FPGAs since at least the Spartan 3A family.

I can't say anything definitive regarding the compatibility of the various third party SPI serial Flash devices with the Spartan 3 and Spartan 3E FPGA families. I have not built any projects using either of these two families. I have recently brought up a Spartan 6 design and a Spartan 3A design using SPI serial Flash devices. And my FPGA team is using 256Mb devices for our new XC5VLX110T FPGA designs. In fact, both of us are using these type of devices for configuration and general storage.

On final thought on the SPI serial Flash configuration approach. Although it requires that the Xilinx tool download a custom image in the FPGA that contains both a BSCAN_XXXXXX and an SPI Master interface, the usage of this special programmer is transparent to the user. It also works in a system with several devices on the same JTAG chain. On my 65C02 FPGA board, I have an FPGA and a CPLD in the same JTAG chain, and I have not issues whatsoever loading the SPI programmer in the FPGA.

This custom SPI serial Flash programmer is supplied by Xilinx and supports a number of different SPI serial device formats. It's like choosing between the old Atmel small block Flash EPROM programming algorithms or the Intel/AMD large block programming algorithms. Luckily, there are a large number of parts from multiple vendors which are compatible, and much less expensive than the corresponding Xilinx Platform Flash device.

Finally, the pins that you use to connect the SPI Flash are general purpose FPGA IO pins. This is unlike the JTAG pins or several of the Slave/Master Serial configuration pins. Thus, with SPI configuration, you can use an SPI Master of your design, and one to which you can attach other peripheral devices without reserving additional FPGA IO pins.

If you still want to proceed on this path, I will try and provide as much help as I can. You'll have to give me a couple of days to get the data as I will have to consult with the designer.

Again, if you have any changes to make to the CHOCHI FPGA board, I would very much recommend changing from Platform Flash to an SPI Flash for the reasons I wrote about above.

_________________
Michael A.

Michael, thank you for the info. It is very much along the lines of what I expected.

Chochi is constrained by the XC3S50 (not A) chip which does not support SPI flash as far as I understand. So I am stuck with Platform flash for now, which is fine as it is still available and I have a bunch of chips still around.

I am working on a CHOCHI-like design with an XC3S400 chip, and will try to see wire a few pins into the JTAG path to at least support future development.

I've considered putting a small PIC to configure the FPGA in a manner similar to the way XESS boards do it, but I find that it confuses the issue even more as there is yet another device to maintain. Platform Flash is still more straightforward...

I'd love to be able to flash it from the 6502 - it would be really easy to update the system then.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

The next issue that you'll need to continue is a means to ensure a bad load does not "brick" the FPGA. There are several app notes that deal with the "multi-boot" concept that is built into the Platform Flash by Xilinx. In my previous effort, we used/planned on using this feature/capability. However, we never got this part of the reprogramming capability fully tested. With the SPI Flash, we are in complete control using an SPI Master I/F of our own design and implementation. Using the BSCAN_XXXX component, it is possible to assert PROGB internally with out the external circuits needed to drive the PROGB pin of the FPGA and drive the Platform Flash pins that select the section of the Flash that contain the configuration image desired.

In the multi-boot concept, the first image written is always loaded. User circuit in the FPGA selects the image to reboot from and issues the PROGB pulse using either an FPGA pin or the BSCAN_XXXX module.

_________________
Michael A.

The verdict seems to be that Platform Flash is awkward to use, and SPI flash is easier, more versatile, and cheaper. However, I thought it might be worth posting some links.
xapp483 Multiple-Boot with Platform Flash PROMs
xapp058 Programming Xilinx CPLDs, FPGAs, and Configuration PROMs
xapp972 Updating a Platform Flash PROM Design
Revision In-System Using SVF

In particular, enso's CHOCHI board uses Platform Flash. In my case, I'd like to reprogram it with an updated bitstream. As I already have a Xilinx "Platform Cable USB" the easiest way is probably to install the free Xilinx tools onto a suitable OS and use the GUI. But not everyone has that dongle. As JTAG is a simple serial protocol which includes a clock signal that can go as slow as you like, it's practical to bitbang from any 3.3V host, or using a cheap level converter to bitbang from a 5V host.

For a 3.3V host, try an Arduino or Raspberry Pi.

Here's a recipe for Arduino. Here's another. And here's one for Raspberry Pi. And another.

For in-circuit programming, here's a relevant-looking post about using Python which points to "Example code for reading and writing data via BSCAN_SPARTAN3 with urJTAG and Python"

The CHOCHI F boards have a bitbanged SPI port that would normally be jumpered to the onboard uSD connector. It would be possible to jumper it to the JTAG port and blast away. The FPGA operates independently of the flash, so it can completely write and verify the flash, and try again for as long as it's not power-cycled (the board is wired to boot from the flash). Bricking would require the real Platform Cable intervention.

Now if only I had a clear understanding of what to send on the JTAG port. I guess SVF files are sort of transcripts to play into the port, but I haven't looked at it at all. My overall self-assessment of my JTAG/configuration underastanding stands at around 1%.

Thanks for all the pointers... I have my work cut out. When I get to it...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I think http://www.xilinx.com/support/documenta ... app188.pdf gives an idea of JTAG in overview and gory detail, but yes, AIUI, the SVF file contains all the pin-wiggling information. So there are just two puzzles
- how to get the tools to give you the right SVF
- how to wiggle the pins of your host according to the SVF instructions
and I'm sure both of those have been answered and explained, if only we can find the info!

Well, let's keep looking. I am open to redesigning CHOCHI if it's required. I also have an SPI port design that works 8 bits at a time with proper timing, but it needs a little work. I am not sure how the Xilinx chips will treat the bitbanged SPI clock that's all over the place.

I am also considering a XULA-like design by replacing the platform flash with an external microcontroller and an SPI flash. While it opens its own can of worms, at least it makes it possible for a non-zealot to update their bitstream. There are a few chips these days that are under a couple of bucks.

I see at least three tiers of CHOCHI (and similar FPGA project) users

-Advanced FPGA users with toolchains set up
-Serious 6502 users
-Beginners

Right now, only the top group can update their board. The second group will probably not want to bother buying a Platform Cable and spending days installing and learning a really obtuse multi-gigabyte toolchain. The third group stands no chance.

I would really feel better if users can update their bitstreams without too many problems...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut