5CGXFC5C6 fails verification after reboot

A couple of questions:

Where does your FPGA boot from - serial/parallel boot ROM, programming cable?

What 'verification' does it pass - is this some run-time check or something related to the FPGA programming?

By 'rebooted' - what do you mean? Soft restart of some internal logic; reconfiguration of FPGA; full power cycle?

How are you determining 'the boards are still working okay' after reboot?

Are you using any Altera IP and do you have the relevant license to use it?

You've not posted in the wrong place but a little more info might help.

Cheers,

Alex

Dear Alex,

Thanks for the response and the following are the responses from our hardware engineer:

Q. Where does your FPGA boot from - serial/parallel boot ROM, programming cable?

A. Serial Prom

Q. What 'verification' does it pass - is this some run-time check or something related to the FPGA programming?

A. During the programming cycle, using the Quartus programmer, the verify checkbox is active and the programmer does the verification and passes as long as we do not cycle the power.

Q. By 'rebooted' - what do you mean? Soft restart of some internal logic; reconfiguration of FPGA; full power cycle?

A. We power down the board, power back up and using the same Quartus programmer we do a verify and it Fails.

Q. How are you determining 'the boards are still working okay' after reboot?

A. We run video through the card and all works great. The debug leds show the correct blinking status, no underruns, no dropped frames etc.

Q. Are you using any Altera IP and do you have the relevant license to use it?

A. We have an enbedded NIOS in the FPGA. The compiler has been licensed and produces the licensed NIOS code. The test jig that we have is used for programming new boards and also running factory aceptance tests. Part of the factory test includes programming the board. There are two images on the serial prom. The latest image that gets programmed is the one we boot from. In the case where the boot image becomes corrupted due to a power failure during a field upgrade, the second image can be used for booting so we do not brick the card. I do not know if this is related to the verify failure. The dual image mechanisim is implemented in the "File, create programming file" dialog box. There it lists two files. The development engineer produces the .jic file based on these two files / dialog box and submits the output image to test engineering. In test engineering we program/verify the image and also do a video test which outputs video to a monitor.

Regards,

Have a look at solution id: rd01102012_443 (http://www.altera.com/support/kdb/solutions/rd01102012_443.html). It refers to a different device family but relates to the same error you're seeing.

When the FPGA boots from a Serial PROM there's no concept of verification - other than a successful boot. So, regarding your answers to Q2 & Q3, what is the difference in power-up/start-up sequence between a boot that successfully verifies and a re-boot that fails?

Regards,

Alex

Agreed.

So, having programmed your PROM using your .jic file, you power cycle your board. The FPGA configures from the PROM.

Then in the programmer (are you using the GUI or command line?) you open (or keep open) the same .jic file and select the 'verify' tick box next to the PROM in question. Click 'Start'.

Is this the sequence that results in the error code you're seeing?

The error message you're reporting indicates the FPGA is configured with an image that doesn't know how to talk to the serial PROM - i.e. there's no Altera IP in the FPGA that the programmer recognises.

When you try to verify your .jic image, the programmer should first configure the FPGA with the 'Factory default enhanced SFL image', overwriting any configuration image the FPGA booted with. This allows the programmer to talk to the PROM.

Can you be a little more explicit with the steps you're taking when verifying?

Cheers,

Alex

We are using the quartus programmer with the windows gui. Initially we activate the Program/Configure, Verify and Blank-check boxes. We press start. The programmer configures the serial prom and verifies. We then uncheck the Program/Configure and Blank check boxes only leaving the verify checked. Press start again and it passes the verify check.

We then power down the board and power back up. The FPGA loads via the serial prom. We press start again and it fails. Only the Verify box checked.

Does the verify fail with your original error message:

'209062 flash loader ip not loaded on device 1'

or

'209027 verification failed for device number 1'?

The following is a trace of a successful verify sequence, using a .jic file, with a single FPGA image in.

--- Quote Start ---

Info (209060): Started Programmer operation at Thu Dec 11 13:43:22 2014

Info (209016): Configuring device index 1

Info (209017): Device 1 contains JTAG ID code 0x020F10DD

Info (209007): Configuration succeeded -- 1 device(s) configured

Info (209018): Device 1 silicon ID is 0x16

Info (209021): Performing CRC verification on device(s)

Info (209011): Successfully performed operation(s)

Info (209061): Ended Programmer operation at Thu Dec 11 13:43:25 2014

--- Quote End ---

Can you post the trace you see in Quartus?

Further thoughts - which would lead to the 'Verification failed for device number 1' error. Does your FPGA image use (write to) the Serial PROM? If your FPGA image can write to the PROM after power up and modify it's contents (in a space beyond the FPGA's boot image), then verification might fail with that error.

Cheers,

Alex

The following is the trace with 5CGXFC5C6 Program/Configure checked; EPCS64 Program/Configure checked, verify checked and Blank Check checked

Info (209060): Started Programmer operation at Thu Dec 11 09:20:45 2014

Info (209016): Configuring device index 1

Info (209017): Device 1 contains JTAG ID code 0x02B020DD

Info (209007): Configuration succeeded -- 1 device(s) configured

Info (209018): Device 1 silicon ID is 0x16

Info (209044): Erasing ASP configuration device(s)

Info (209019): Blank-checking device(s)

Info (209023): Programming device(s)

Info (209021): Performing CRC verification on device(s)

Info (209011): Successfully performed operation(s)

Info (209061): Ended Programmer operation at Thu Dec 11 09:22:40 2014

The following is the trace with EPCS64 verify checked right after the above process, without restart.

Info (209060): Started Programmer operation at Thu Dec 11 09:27:15 2014

Info (209018): Device 1 silicon ID is 0x16

Info (209021): Performing CRC verification on device(s)

Info (209011): Successfully performed operation(s)

Info (209061): Ended Programmer operation at Thu Dec 11 09:27:26 2014

The following is the trace with EPCS64 verify checked, after restart.

Info (209060): Started Programmer operation at Thu Dec 11 09:29:21 2014

Error (209062): Flash Loader IP not loaded on device 1

Error (209012): Operation failed

Info (209061): Ended Programmer operation at Thu Dec 11 09:29:21 2014

Thanks,

I think I see...

In order to verify the contents of the EPCS the FPGA must be configured with and image containing IP that can talk to it. When you're programming the device, as per your 1st trace, the following lines relate to the configuration of the FPGA:

--- Quote Start ---

Info (209016): Configuring device index 1

Info (209017): Device 1 contains JTAG ID code 0x02B020DD

Info (209007): Configuration succeeded -- 1 device(s) configured

--- Quote End ---

The FPGA is now able to control the EPCS and goes on to program it:

--- Quote Start ---

Info (209018): Device 1 silicon ID is 0x16

Info (209044): Erasing ASP configuration device(s)

Info (209019): Blank-checking device(s)

Info (209023): Programming device(s)

Info (209021): Performing CRC verification on device(s)

Info (209011): Successfully performed operation(s)

--- Quote End ---

Your second and third traces do not perform first step above - they do not configure the FPGA and go straight on and attempt to check the EPCS.

The second trace shows a pass because the FPGA remains configured with the factory programming image from your previous programming step.

The third trace fails because the FPGA has booted from the EPCS and your user FPGA image does not contain the IP the programmer needs to control the EPCS.

So, the fix. When you are trying to verify the EPCS from a power up you need to ensure the 'Program/Configure' check box, next to the 'Factory default enhanced SFL image', is ticked (as well as the verify check box next to the EPCS64 - see attached image). This will force the programmer to configure the FPGA with an image containing the necessary IP before it tries to check the contents of the EPCS.

Cheers,

Alex

Alex,

I tried the way you suggested, it worked fine. Thank you for your help so we can have a good conclusion on the issue.