Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
18 years ago

EPC16 and EP1K30 configuration issue

Hi,

I am trying to get my configuration data transfered from a EPC16 to a chain of EP1K30 devices on my pcb. So far, it doesnt work. These are the relevant things (please let me know if there is anything else that might help to help me):

- MSEL[] = GND

- nCE = GND

- TDI,TMS,TDO,nCONFIG = 1K pull up to 3.3V

- TCK = pull down

- added a 100 pF to DCLK as suggested in this forum, it didnt help.

I already isolated 4 devices so that I can work with only one and try to find the root of the problem. This is how my signals behave:

nCONFIG goes HIGH then nSTATUS goes HIGH for a few miliseconds and then return LOW. CONF_DONE signal is always LOW. I checked DCLK and it toggles at ~10 MHz during the time that nSTATUS is HIGH. What I noticed is that DATA0 is always HIGH... Can this mean that the programming file is corrupted? I checked the pcb and apparently there are no shorts to DATA0 line.

What is also curious is that we have the Quartus II configure to restart the configuration if an error is detected. I am using Quartus II 5.1 SP2. My programmer is the Quarts Standalone 7.2.

Isnt the FPGA supposed to pull down nSTATUS if an error is detected and then release it again so that configuration restarts? When does the FPGA performs its checksum? Is it online or does it wait until all configuration data is sent? How can I know what is the exact size of my configuration data so that I can check if the time it takes (with nSTATUS HIGH) is enough for al of the data to be sent?

Hopefully someone can help us out. Thank you for any suggestions.

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hello,

    I started Altera FPGA design with ACEX family, but never used PS configuration with EPC devices, thus I'm not familiar to this. But DATA0 staying high most likely indicates that the EPC16 is completely unprogrammed. How did you verify EPC16 programming?

    The restart on error option can only work, if a small part of your configuration could be transmitted, how should the FPGA know otherwise?

    Regards,

    Frank
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Frank,

    I verified the ECP16 using the Quartus II programmer. It says it is programmed ok. So I guess I have to believe it. My concern is that the file that I am using might be somehow broken or that this data gets corrupted when sent from EPC16 to ACEX.

    Regarding the restart on error part, I can tell that some of the file is sent because I get a pretty clear DCLK burst for a few milliseconds, something between 5 ms and 50 ms depending of the board configuration (I already tried so many things). So, I would hope it to restart because it does start configuration, no? Unless the FPGA releases nSTATUS and the configuration isnt properly started... but then, why would it pull nSTATUS low to indicate the error? This should by itself restart the EPC16 configuration controller. But it will require nSTATUS to go back high to signal the ACEX is ready for a second try...

    The serial scheme is described in the configuration handbook and seemed like a good alternative to having 5 (we have a total of 5 ACEX on the board) EPC2. You can set it to a concurrent programming scheme and then each of the 8 data outputs from EPC16 can be used to configure a different device.

    Thank you for your input. Do you have any other ideas?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I have an addition: I just added a JTAG connector to try to program the EP1K30 directly through the JTAG interface. I can read the device correcly using the auto-detect mode but when I try to program it I always receive a "CONF_DONE pin failed to go high in device 1" message. I have pull ups for these: TCK, TMS, TDI, TDO, nSTATUS, nCONFIG and CONFIG_DONE.

    What can it be? Does this mean that my FPGA isnt working?

    Thanks!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hello,

    with functional hardware, this could happen if the PS configuration pulls down nConfig while you're using JTAG.

    Regards,

    Frank
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    It happened that in one of the boards I had the FPGA got somehow burned. We added the 100 pF cap and a power up reset chip to solve the issue. Now I can program one of the devices in the chain. Thanks for your assistance, Frank!