Forum Discussion

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

EPC16 does not configure EP2C35 at high temperature

Folks,

I have been debugging this issue where the EPC16 device I use does not configure the EP2C35 (Cyclone II) device - at slightly high temperature. I can make it configure by cooling down both devices using freeze spray. :confused:

This is the most fascinating and ridiculous part of the problem - how could the temperature be influencing the basic config cycle??

I am using the Passive Serial mode of configuration. The programming files are proven good. I see the nCONFIG going high followed shortly by nSTATUS and after that ... nothing. The DCLK/DATA0 lines are flatlined (DATA0 continues to remain high and DCLK continues to remain low). Obviously in this case, the CONF_DONE signal does not go high at all.

See waveforms below -

Ch1 – Yellow – nCONFIG

Ch2 – Blue – nSTATUS

Ch3 – Purple – CONF_DONE

Ch4 – Green – INIT_DONE

This is a bad config cycle.

http://i41.tinypic.com/23ib0pl.jpg

On a good config cycle (same board, freezing cold ICs)...

http://i43.tinypic.com/1evt07.jpg

I verified the power up sequence - the VCCIO (3.3V) powers up first (t0). The FPGA-VCCINT (1.2V) powers up at (t0 + 69.2ms). The EPC16 is set to have a POR of 100ms. So I am assuming this powers up at (t0 + 100ms).

This meets the spec.

I have tried 1K & 10K pullups on the INIT_CONF signal with no luck.

I am seeing this on 4-5 of 30 boards. On some boards the issue is a lot more aggravated than the others. One board in particular fails at room temperature. Other boards only seem to fail @ 45-55C.

I have checked to verify that the EPC16 is revC silicon.

Any ideas??

14 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Generally, I must admit that I never used an EPC device and thus don't have any experience regarding it's particular behaviour and don't know, if there are hidden design traps or known issues.

    From the reported observations, the problem seems to be caused by the EPC16 only, but I don't see a point how to localize it further. The previous comments on possible soldering, power supply, bypassing and grounding issues should be checked to my opinion. But it's hard to decide if these are more or less likely without knowing the design details and having the board at your fingertips.

    As another comment, the (working circuit) waveforms don't look really good, the overshoot, if actually present with the shown amount, is considerably exceeding the FPGA maximum voltage range. I guess however, this may be a simple probing problem. If the design has long signal traces for the respective signals, the overshoot could be real and you're missing a source sided serial termination. But I don't think that the no-operation is related to this waveforms.

    Good luck,

    Frank
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Looking at the last scope image, it appears that there are some serious signal integrity issues on the board. I dont think your problem is related to the EPC16 but rather the board design.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    --- Quote Start ---

    it appears that there are some serious signal integrity issues on the board

    --- Quote End ---

    You're right, if the waveforms would be real. However, you easily get apparent overshoot by simply using a normal passive probe with standard ground lead.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    It would be interesting to see the results with an active FET probe, and know that it was measured at the receiver end of the net.