Parrallel Flash Loader

Hi Tricky,

--- Quote Start ---

We are thinking about having the following setup in our new board (see attached image for architecture). We want to do this to give use access to the fast parrallel programming capability of the parrallel flash loader to get the Arria2 up in time to commicate on a PCIe link. We've had problems in the past with chips not coming up in time and then having the PCIe ignored, hence the fast parrallel programming.

The 2nd configuration interface comes from an ARM core that we have used to program other chips on other boards, but now we need it to program the flash rather than a chip. You cannot connect this to the PFL hence the custom IP needed (if we can make something that will fit!)

Another question is the format of the programming files. The Quartus programmer will only take pof, .jam and .jbc files, whereas the ARM core needs the data in .rbf format. Does this have any effect on the data in flash, or is that just because of the quartus programmer needing a file it can convert to JTAG? would the file in flash be the same at the end of the day, or is there some weird encoding I need to know about?

Any help on this greatly appreciated

Thanks :)

--- Quote End ---

I looked at the PFL and didn't like it. Instead I wrote my own:

http://www.ovro.caltech.edu/~dwh/carma_board/

http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf

Its used twice on the board; once in a MAX II CPLD to configure the Stratix II system controller FPGA, and then again inside that system controller FPGA as the programmer for the four data processing FPGAs.

The MAX II version brings the Stratix II and PowerPC to life in time for the PowerPC PCI interface to be activated before the PCI bus has been enumerated.

Let me know if you would like the code for this controller. Its written in VHDL, and has testbenches.

Cheers,

Dave

--- Quote Start ---

I looked at the PFL and didn't like it.

--- Quote End ---

An advantage of the existing PFL design is the Quartus programming support. If you don't need it, any other design is as good and most likely better suited for a specific task.

The PFL design isn't particularly instructive, but basically understandable if you want to adapt it to your purposes.

--- Quote Start ---

An advantage of the existing PFL design is the Quartus programming support.

--- Quote End ---

The features I did not like, were that you can not simulate it, and it would not allow you to target anything but a MAX II (those were the issues when it first came out, but perhaps that has changed).

Cheers,

Dave

--- Quote Start ---

The features I did not like, were that you can not simulate it, and it would not allow you to target anything but a MAX II.

--- Quote End ---

I see. You can basically simulate it, I remember that I did. The target restriction exists in so far that the Quartus programmer recognizes PFL VJTAG instances only for MAX II devices. Just a software restriction but existing so far.

So the ideal situation is the architecture above: We have access to the flash from the jtag via the quartus programmer so that when the board is manufactured all the configs can be loaded in production.

Then for engineering/customer updates we can reload the flash from the ARM core.

It looks like I might have a couple of problems:

The PFI core itself has a tristated data output, and because I cannot access the internals I cannot build a second data arbiter outside the PFI at the top level.

If I built just a custom IP, I dont think I can access the JTAG. They appear to be altera reserved.

So looks like Im going to have the choice of one or the other, not both.

The reason for all this is trying to make life easier for customer updates. In engineering its nice to have the JTAG connection to reload the flash. But for customer updates the idea is to just give them a USB stick that plugs into a USB (connected to the ARM) that then just automatically updates everything.

Im thinking I might just stick with the ARM route, as we can do that in engineering.

--- Quote Start ---

The PFI core itself has a tristated data output, and because I cannot access the internals I cannot build a second data arbiter outside the PFI at the top level.

--- Quote End ---

I don't exactly understand the problem. You can in fact parallel connect a second flash programming interface, utilizing the pfl_flash_access_request/pfl_flash_access_granted control lines. If pfl_flash_access_granted enables the respective flash signal buffers inside the MAX II design, it can work as a mux.

Regarding PFL VJTAG, you have a basic documentation of the VJTAG protocol in a user manual. The PFL specific protocol isn't explicitely documented, but can be extracted from the PFL design.

I agree however, that once you have the ARM flash access working, it can be used for factory programming as well.

Hi Tricky,

On the CARMA board

http://www.ovro.caltech.edu/~dwh/carma_board/ (http://www.ovro.caltech.edu/%7edwh/carma_board/)

I had a similar set of requirements;

* Stratix II system controller FPGA configured by a MAX II CPLD from flash

* PowerPC processor held in reset by the system controller, and then enabled to boot U-Boot from the flash

* PowerPC PCI interface that must be initialized (by U-Boot) before the BIOS configures PCI

* PowerPC boots Linux. The Linux image can be on the flash too, but that generally network boots over a virtual network link over the PCI bus

The MAX II and System controller FPGA have an Altera JTAG chain. A new board can be programmed via JTAG. However, during production, I simply programmed the MAX II and Flash devices prior to assembly.

The PowerPC has a JTAG connector, and I have a BDI2000 debugger. That debugger has flash programming capabilities. Given that, there was no point in having flash programming in the MAX II or System Controller FPGA.

Once the PowerPC boots, and is visible over the PCI bus, its pretty simple to program the Flash via PCI. So you can load the system controller using an .sof file, boot, and then program the flash. Or boot with an old system controller image, and then erase and re-program the flash. Since the production boards had system controller images and U-Boot images, boards could be plugged into a 19-slot cPCI crate, and the flash images updated en-mass to the latest versions.

In your system, your ARM processor can perform all the flash programming. Its likely to be faster than using the Altera JTAG cable.

Are you planning on reconfiguring the FPGA once its alive? If so, you may want to run a few tests. Linux and Windows are not very happy when PCI devices disappear. I plan on running some tests to see how well PCIe hot-swapping is supported under Linux.

What is the form-factor of your new board? I'm about to start designing an Advanced Mezannine Card (AMC).

Cheers,

Dave

--- Quote Start ---

If I built just a custom IP, I dont think I can access the JTAG. They appear to be altera reserved.

--- Quote End ---

The Virtual JTAG interface is not well documented, but it does work.

http://www.ovro.caltech.edu/~dwh/correlator/pdf/vjtag.pdf

I use it with my FPP core for control/status.

Cheers,

Dave