Cyclone III configuration corrupts image

Can you probe the INIT_DONE signal?

Look at p56 (these are for PS/FPP, but the signals should do the same thing for JTAG configuration):

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

Note how INIT_DONE goes low when programming starts, and then high again when done on p60. Note how there is a delay between CONF_DONE and INIT_DONE.

I wonder if your FPGA is being left in the no-mans land between CONF_DONE going high and INIT_DONE going high.

See p63 for enabling the INIT_DONE output.

Cheers,

Dave

--- Quote Start ---

But, on most of the boards, configuration with USBBlaster results no errors but a corrupt FPGA image in the chip.

--- Quote End ---

Does "no error" mean, the AS image verifies correctly after programming?

P.S.: How do you know, that the image is corrupted? It may be a case of unpredictlable design behaviour as well, e.g. due to asynchronous reset or PLL lock issues. I would activate the CRC output to decide if the image is actually corrupted.

As I understand it, CRC wouldn't help in this case: If the image is corrupted on download, the CRC would be computed on the corrupted image and tell you nothing.

Remember, once the image has been saved into EPCS, we have no problem bringing the board up. It's ONLY through the JTAG that there's a problem.

--- Quote Start ---

Can you probe the INIT_DONE signal?

Look at p56 (these are for PS/FPP, but the signals should do the same thing for JTAG configuration):

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

Note how INIT_DONE goes low when programming starts, and then high again when done on p60. Note how there is a delay between CONF_DONE and INIT_DONE.

I wonder if your FPGA is being left in the no-mans land between CONF_DONE going high and INIT_DONE going high.

See p63 for enabling the INIT_DONE output.

Cheers,

Dave

--- Quote End ---

I've checked. INIT_DONE toggles and goes high at the end, as it's supposed to.

--- Quote Start ---

I've checked. INIT_DONE toggles and goes high at the end, as it's supposed to.

--- Quote End ---

It sounds like the FPGA likes what it is receiving then.

Did you put any thought into FvM's suggestion - have you synchronized the reset to the clock domains within the FPGA? Have you checked your PLLs are locking ok?

I'd recommend putting a SignalTap II instance into the design. Then download and let Quartus communicate with the instance. If it can communicate, then you have a design error. If Quartus cannot communicate, then there must be some form of corruption - however its a strange one, since nSTATUS would normally go low in that case.

Cheers,

Dave

First, there are no PLLs. How would I synchronize a reset? I seems to me that all that is handled by the USB Blaster.

Second, i had the same idea, but to use signal tap requires that I am able to configure a bad board, which is what I can't do.

--- Quote Start ---

How would I synchronize a reset?

--- Quote End ---

Reset signals from a push-button, external reset supervisor, or from the USB-Blaster interface are asynchronous signals. The reset inputs on the registers within an FPGA have a setup and hold time (called the reset recovery and removal time). If you violate this, then weird things happen.

You synchronize the external reset to each clock domain by running the signal through a reset synchronizer circuit. Altera has examples. Cliff Cummings of Sunburst design also has several good papers which discuss the topic.

--- Quote Start ---

I seems to me that all that is handled by the USB Blaster.

--- Quote End ---

Nope. If you're using it to program the FPGA, that's all it does.

--- Quote Start ---

Second, i had the same idea, but to use signal tap requires that I am able to configure a bad board, which is what I can't do.

--- Quote End ---

Perhaps you can program the image into the boot device and then try connecting?

Cheers,

Dave

--- Quote Start ---

As I understand it, CRC wouldn't help in this case: If the image is corrupted on download, the CRC would be computed on the corrupted image and tell you nothing.

--- Quote End ---

The asumption is wrong. The CRC is compared to a precomputed value.

You didn't answer the question about verify. It's also unclear, if you are programming the serial flash through indirect JTAG or AS interface.

--- Quote Start ---

Remember, once the image has been saved into EPCS, we have no problem bringing the board up. It's ONLY through the JTAG that there's a problem.

--- Quote End ---

So the image does not verify correctly? In this case it's most likely a problem of JTAG or AS interface signal quality.

Resolution: It turns out that it's a power problem.

Verify: I don't know how to verify. The Verify box in the programming SW is disabled.

CRC: That would mean that I have to generate the checksum somewhere? Or is it already there?