Forum Discussion

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

CIII / Configuration

Hi,

I have a cyclone EP3C10F256C8 and configuration flash EPCS4SI8N. I have 2 of 10 boards which won't configure. All the signals are present: DCLK coming from the FPGA, CS, ASDI, and DATA coming out of the flash.

In my reading I noticed that the flash drives out on the falling edge of DCLK and the FPGA latches also on the falling edge--is this correct? It seems more logical for the FPGA to latch on the rising edge if the flash is sending out on the falling edge. Otherwise it would seem that the tsu would be rather tight.

The data line is point to point and is approximately 17mm in length.

The clock line is point to point and is approximately 18mm in length.

I believe I'm running into a timing problem but I can't figure out why 8 boards work great while 2 are behaving erratically.

Any help would be greatly appreciated.

Best regards,

Rob

13 Replies

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

    Well you should have mentioned the temperature dependence earlier.

    Have you scoped the data and clock signals while freezing / heating the part. I'm guessing one of the signals will cease to toggle (or the amplitude will diminish). Judging by your comments, I'm guessing this is the first RoHS compliant board this board-house has assembled for you. I have seen numerous issues with board-houses overheating / underheating RoHS boards and resulting in these same problems.

    I've seen the following issues:

    1 - cracked vias (from overheating). Via makes contact until board reaches a certain temperature then expands and no longer makes contact. Look for loss of signal when you vary the temperature. I've seen the x-rays of this phenomenon.

    2 - incomplete solder joint on BGA package (from underheating). Ball inconsistently or never makes contact with solder pad. Again look for loss of signal when you vary the temperature.

    3 - Shorts under a ball grid (these are not normally due to temperature). A sloppy solder job can cause intermittent shorts that are heat dependent. Also, solder flux left under a part can cause this to occur after fabrication. Look for diminished amplitude on the signal and check signals for shorts (or very low resistance) with each other or with VCC or GND). If your scope shows a signal not quite reaching VCC or GND, you've probably got a short somewhere.

    This is probably a long shot but a good JTAG boundary-scan tool will do open-short tests. I don't suppose you've got any of those at your disposal?

    Have you tried varying the temperature on the boards that are working? If they don't start failing, then throw the idea of timing out the window. A borderline timing violation would manifest itself on your other boards under the right conditions (temperature).

    Now, to readdress the timing question. Almost all digital circuits both latch and drive on the same clock edge. In this case, we have a clock frequency of 30MHz (a period of 33.33ns). Let's make an incorrect assumption just for the sake of argument.

    Suppose the falling clock edge arrives at both the input latch (within the FPGA) and the data output latch( on the serial flash device) at the exact same instant.

    The new data out signal has 33.33ns to travel through the latch, through the serial flash die, out the pad on the die, along the internal wire bond to the pin, along the pin, along the board trace, along the pin on the FPGA, along the internal wire bond from the pin to the die (assuming non-BGA), through the pad on the die, to the input of the flip-flop within the FPGA. If it arrives within this 33.33ns, the next falling clock edge will sucessfully latch the new data signal into the flip-flop.

    Now, suppose we change the scheme and drive out of the serial-flash device on falling clock edge but latch the input into the FPGA on rising clock edge. Assuming the clock duty cycle is 50%, we've now cut the time available for the signal to reach its destination from 33.33ns down to 16.66ns (a 60MHz clock frequency). Now of course there are many other numbers in this calculation. This is just assuming an ideal situation.

    Anyway, driving and latching on seperate clock edges is not the proper way to guarantee setup / hold times in a digital circuit.

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

    I posted about the freeze phenomenon when I found out about it. I wouldn't lead you guys along and not paint a full picture.

    I am more and more leaning towards a fabrication/assembly issue. I have engaged Altera through my local FAE as this is a big issue for my company right now. Altera has assured me that if one adheres to their layout rules (traces less than 6" and matched) that the timing is all baked in and owned by them. I meet both of those criteria. There really isn't much else to look at beyond some type of assembly issue, I believe.

    The only JTAG tool I have is the programmer attached with Quartus--is this something Quartus can do? I could probably get my hands on one, though.

    I am having one of the boards that doesn't work x-rayed (3D) tomorrow. Maybe that will show something.

    I do appreciate your time and insight.

    I do understand what you're saying about timing; but if your receiver doesn't have a tHOLD time of 0 then you could get into trouble. Some of the AFE's that I've worked with operate using the falling edge/rising edge approach. In these cases, I've been forced to write data out on one edge and read it in on the other.

    I will inform the forum on the end of this saga.

    Take care,

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

    --- Quote Start ---

    I do understand what you're saying about timing; but if your receiver doesn't have a tHOLD time of 0 then you could get into trouble.

    --- Quote End ---

    Yes, but by specification, it is zero. You should also consider, that the clock is generated by the FPGA itself. So from the FPGA internal view, the DCLK and DATA0 I/O cell delay subtracts from the setup and adds to the hold time of the receiving register. Hard to imagine, how a timing issue should arise here, assuming the internal register has a hold time comparable to other FPGA resources.

    I also expect an assembly problem as most likely reason.