Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21608 Discussions

Arria II. Load Image with FPP Protocol. Nstatus stuck low ?!

Altera_Forum
Honored Contributor II
1,401 Views

Hello. 

 

I have an FPGA board with an Altera II connected to a Cypress bridge. 

 

I have written a firmware for the bridge in order to load the FPGA image with the FPP protocol (all 4 MSEL low). 

 

The first step does not seem to work actually. 

here is the issue: 

 

I set nCONFIG high for ~200ns. then low for 50ns, and high again. 

The FPGA seems to reset: nSTATUS is pulled low less than 1ns after nCONFIG, and comes back high after ~300ns. 

 

first issue: CONF_DONE does not change however, and stays low. the pin is pulled by a 10k resistor to 2.5V. I have actually never seen it moving, and yes I am probing the good pin. 

 

second issue: INIT_DONE does not change either. 

after the init phase described above, I send DCLK and DATA[7:0] (MSB>LSB ). 

INIT_DONE stays low the whole time. I have never seen that pin change status either. 

 

third issue: during the middle of the data sent, nSTATUS goes low, and stays low until the end of the transmission... 

this is weird. I would have thought that only nCONFIG would affect nSTATUS. apparently not. nCONFIG stays high the whole time, but nSTATUS decides to go low at a certain moment. and does not come back high at any moment. 

 

 

would anyone have an idea of where the issue could be ? 

 

is there any other pins I could probe to get more information about the FPGA state ? 

 

thanks a lot, 

 

edit: I gathered more information on the issue and continued on the following topic: http://www.alteraforum.com/forum/showthread.php?t=42667
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
695 Views

nSTATUS goes low during configuration if the FPGA does not like the data you are sending. 

 

Have you confirmed that you can program the FPGA using JTAG? 

 

Here's some notes on Passive Serial and Fast Passive Parallel programming. Read through them. Perhaps you will see something useful: 

 

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

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
695 Views

thanks for your reply. 

 

I have checked more in detail, and nSTATUS actually always goes low between the 62.000th and 62.999th byte. 

 

I do not have access to a JTAG port for the FPGA, so this is unfortunately the only way I can troubleshoot it. 

 

thanks for the document, I will have a second look at it
0 Kudos
Altera_Forum
Honored Contributor II
695 Views

 

--- Quote Start ---  

 

I have checked more in detail, and nSTATUS actually always goes low between the 62.000th and 62.999th byte. 

 

--- Quote End ---  

 

If its that consistent, then its likely a data format error. The error may have nothing to do with those bytes though, it likely takes multiple clocks internally to check previously loaded data bytes. 

 

If the error was not consistent, I would tell you to check the DCLK edge signal integrity. If your observations are repeatable, then check whether you are serializing data correctly. 

 

 

--- Quote Start ---  

 

I do not have access to a JTAG port for the FPGA, so this is unfortunately the only way I can troubleshoot it. 

 

--- Quote End ---  

 

That was a poor design decision. You should always include the JTAG port. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
695 Views

 

--- Quote Start ---  

If its that consistent, then its likely a data format error. The error may have nothing to do with those bytes though, it likely takes multiple clocks internally to check previously loaded data bytes. 

 

If the error was not consistent, I would tell you to check the DCLK edge signal integrity. If your observations are repeatable, then check whether you are serializing data correctly. 

 

--- Quote End ---  

 

 

I am sending the LSB on data0 and MSB on data7. DCLK has a period of 18ms, with 50% duty cycle, so I believe all of this is correct. 

 

the thing that bothers me most is that CONF_DONE never goes high. It is pulled high to 2.5V through a 10kohm resistor, but never released by the FPGA. what does this mean ?
0 Kudos
Altera_Forum
Honored Contributor II
695 Views

 

--- Quote Start ---  

If its that consistent, then its likely a data format error. The error may have nothing to do with those bytes though, it likely takes multiple clocks internally to check previously loaded data bytes. 

 

If the error was not consistent, I would tell you to check the DCLK edge signal integrity. If your observations are repeatable, then check whether you are serializing data correctly. 

 

 

That was a poor design decision. You should always include the JTAG port. 

 

Cheers, 

Dave 

--- Quote End ---  

 

 

yes, the design was bad. unfortunately I will have to deal with it. 

 

the error is consistent. always between the 62k th packet and 62,999th. 

 

the INIT_DONE pin stays high all the time. is that normal ? I though it should go low after 3 DCLK periods. 

 

(I have pulled the INIT_DONE to 2.5V with a 10k resistor)
0 Kudos
Reply