Cyclone II programming and verification using JTAG

[Altera_Forum]

Hi people, 

 I'm a software engineer and quite new to Altera. For our new product we have an ARM9 processor, Flash memory connected to this processor, Linux 2,4 running and an Cyclone II FPGA for general IO support. Currently the FPGA's PS programming pins are directly connected to some ARM9 pins, and I'm able to successfully configure the FPGA from the ARM9 using a Linux kernel module driver (I am not using any PC software for this).  We might get problems in the field though, as our product will be out in the rain, sun, and every other weather phenomena you can think of, for weeks or months at a time powered on. Now we are looking for a method to verify the current FPGA configuration at certain time intervals. My hardware engineer collegues pointed me to the JTAG protocol, which can also be used for programming the FPGA (I am new to JTAG also:( ). I know that during programming, I can also verify the bits that I program, because I can read them back. I need a method though that can verify (without re-programming) the FPGA content, basically readout the current configuration.  Is this possible at all ?:confused:  Is JTAG the correct interface for this ? Can someone point out HOW to do this (from the ARM9 under linux) ? Has anyone got source code for this ?  P.S. I cannot use solutions from byteblaster. These are only helpful if they expose which JTAG stuff I have to use.  Thanks, Bart:cool:

[Altera_Forum]

I find it odd that you feel your product will not work under those conditions. 

Cellular base stations exist in those (and worse) conditions on a daily basis (and they are using FPGA's). ((I assume that the board is not really directly exposed to those elements, but is in an enclosure - correct?))  Altera does not provide a method for reading back the configuration loaded into the Cyclone II FPGA for design security reasons.  You can however use a nice feature built into the Cyclone II device just for what you are looking to accomplish.  There is a chapter in the Users Guide as follows: Section I. - Chapter 3. Configuration and Testing - Cyclone II Automated SEU Detection.  Read that section and the related Application note and all your needs should be satisfied.  Now to formally answer your questions. Yes, it is possibleto check the device (indirectly) You do not need to use JTAG See the Ap note I do not know if anyone has any source code, it should not be an issue to test a bit and decide if you need to reload the part.  Enjoy.

[Altera_Forum]

Of course, the hardware is enclosed in a watertight casing, which can also cause high-temperatures inside when exposed to direct sunlight (which can be the case). 

My software department manager want to add this feature to be able to verify the FPGA contents. Maybe if I can find the 100% guarantee that the FPGA's contents do not change over time given the fact that power supply is not interrupted, I might be able to convince my manager that the verify option is not neccessary. But for this moment, I am curious myself about how to do this.  I searched for the user manual, but all I have is the Cyclone II Device Handbook (All Sections) (downloaded from link http://www.altera.com/literature/hb/cyc2/cyc2_cii5v1.pdf last thursday). I cannot find the section you mention also the searchterm "SEU" in this almost 800 page document does not deliver any search result.  I did some further searching and stumbled accross this document : http://www.altera.com/literature/an/an357.pdf. It explains CRC error checking, using the JTAG interface. Is this document what you mean ? How can it be done without JTAG ? It does not state how to read-out the current configuration.....  Can you please specify a link to the document you are referring to ?  Not having source code might not be a problem. When the explanation is detailed, I can manage.  Thanks, Bart

[Altera_Forum]

Sorry about the question about the exposed to the elements query, I have seen all sorts of interesting question on this forum, and so I assume nothing and ask everything. 

 I just re-downloaded the document.  A search for SEU (no quotes) reveals a hit on page 93 of the pdf file. Chapter 3, page 7 as I explained above.  The Application Note you stumbled across is also referenced just below that section of the Users Guide - good find.  Re-read the AN, as Igot a little confused as to what they were trying to tell me on the first pass read. The JTAG interface can be used to load the part, and there is a CRC instruction that can be used to get at the CRC storage location. THat is all they are saying there. THe rest of the document goes on to explain the automatic in the background CRC checking that can be turned on in the device. (Note that the memory contents and I/O configuration are NOT a part of that circuitry.)  I do NOT believe Altera provides Readback of the internal configuration for their devices. I hope this help.

[Altera_Forum]

--- Quote Start ---  ... the hardware is enclosed in a watertight casing, which can also cause high-temperatures inside when exposed to direct sunlight (which can be the case)... Maybe if I can find the 100% guarantee that the FPGA's contents do not change over time given the fact that power supply is not interrupted, I might be able to convince my manager that the verify option is not neccessary.  --- Quote End ---     Other than a hiccup from the kind of thing the automated SEU detection was meant for, the FPGA should operate reliably for an indefinite time as long as you do not exceed the allowed operating conditions given in the device handbook. If you are going to expose the device to high ambient temperatures or even to direct heating from sunlight, be careful that these external sources of heat in combination with the power dissipated internal to the device do not cause the junction temperature to exceed the specification limit.  FPGAs are successfully used in applications that require very long operating periods with extremely low failure rates.

[Altera_Forum]

Thanks for the quick replies. 

 The mainboard containing the FPGA is to be mounted in a metal box, so no direct exposure to sunlight, but plenty of ambient and radiating (from the metal casing) temperatures.  I will propose the CRC checking mechanism to my manager. I can also ask my hardware collegue if it is possible to implement in-FPGA memory checking. I heard from my hardware collegua, that we have a temperature sensor on-board, with which we can power down when we exceed temperature specifications.  My manager has accepted the CRC checking mechanism, but we still have some open questions : Brad is talking of a hiccup. Can you describe what the influence of the hickup is ? Suppose I want to turn an output off during such a hiccup, is this off command executed or is it executed delayed ? How much is the delay if any ?  Thanks again, Bart

[Altera_Forum]

--- Quote Start ---  Brad is talking of a hiccup. Can you describe what the influence of the hickup is ?  --- Quote End ---     I said "a hiccup from the kind of thing the automated SEU detection was meant for". I don't deal with this area, but I expect the documentation covers why to use this feature and how to make use of it. In an environment exposed to cosmic particles (some environments are exposed to more of them than others are), there is some chance of a particle flipping a bit. That's a probability-of-failure contributor that in some applications needs to be considered in addition to ordinary reliability. The odds of a cosmic particle disrupting FPGA operation are very low and can be ignored in many, probably the vast majority, of applications. (Again, I'm no expert on this.) SEU had already been mentioned in the thread, so to be complete I was just qualifying my statement about high long-term reliability when you operate within the spec limits because there is this other failure cause regardless of those operating conditions that some people need to consider.