CIII / Configuration

--- 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.

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

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

According to the code on the chip, I do have a config device that was mfg using the 0.15u process. Code = Z732X. The x = 0.15u process

But it still is a good idea to try a EPCS16--i'll try it.

See table 5, http://www.altera.com/literature/ds/ds_scg.pdf

DCLK max freq is stated at 20MHz.

From page 10-9 of http://www.altera.com/literature/hb/cyc3/cyc3_ciii51010.pdf

In Cyclone III devices, the active master clock frequency runs at a maximum of 40 MHz, and typically

at 30 MHz. Cyclone III devices only work with serial configuration devices that support up to

40 MHz. Existing batches of EPCS4 manufactured on 0.15 µ process geometry support AS

configuration in Cyclone III devices up to 40 MHz. However, batches of EPCS4 manufactured on

0.18 µ process geometry support only up to 20 MHz. EPCS16, EPCS64, and EPCS128 are not affected.

My guess is that you have the EPCS4 manufactured on the 0.18u process, and it only supports 20MHz dclk. Some boards may configure because some of the EPCS4's can tolerate the 30MHz DCLK clock or the FPGA is below the typical 30MHz. Maybe try ordering a couple EPCS16's and solder them on the boards that are not configuring?

--- Quote Start ---

But if you're telling me that the FPGA latches the data of the previous cycle JUST before the FLASH sends out the next bit then there must be an FPGA spec for hold time on the data line--what is it and where can I get this information? I can't seem to find it in the data sheet.

--- Quote End ---

Basically yes. Actually, there is a general (not device specific) specification in Configuration Handbook:

--- Quote Start ---

tH Data hold time after rising edge on DCLK 0 ns,

tSU Data set up time before rising edge on DCLK 5 ns

--- Quote End ---

The respective diagram is showing a falling DCLK edge, however.

Because of the simple fact, that EPCS data can't arive before clock edge, this specification can be expected to be met generally. For the same reason, there is no particular delay matching requirement, the clock frequency is rather low anyway.

Using the same clock edge for source and destination is a common method with fast SPI interfaces to increase the timing margin. With AS configuration, the most likely signal quality issue is double clocking of EPCS device due to distorted DCLK to my opinion.

MSEL is fine. I would imagine that the configuration sequence would not even start otherwise.

All of the configuration lines seem to be doing what is expected. The FPGA is sending out DCLK, CS, and ADI. The flash is also sending out DATA. It just won't configure unless I freeze the flash device. In fact I can turn on and off the problem by heating and cooling the FLASH device, not he FPGA.

I believe it is a timing issue but I'm not sure what paramater isn't happy. I can't find any specs on the tsu/thold from the FPGA's perspective. The FLASH device calls out no more than a 15ns delay from the falling edge of DCLK to the rising edge of DATA. My FLASH is actually putting out data ~3-4nsec after the falling edge of DCLK.

(just an aside)I don't necessarily agree with you on the FMAX. If your clock is running at 30MHz sending out data on the falling edge and another device is latching that data on the rising edge, then the data rate is 30MHz, not 15MHz.

But if you're telling me that the FPGA latches the data of the previous cycle JUST before the FLASH sends out the next bit then there must be an FPGA spec for hold time on the data line--what is it and where can I get this information? I can't seem to find it in the data sheet (CH10).

My DCLK and DATA trace lengths are almost matched, about 1mm difference.

I am thinking about board assembly, too. This is a full-up RoHS compliant board. And I know the RoHS process is more stringent than a leaded: pre-heat boards, solder temperatures, etc. Have you ever seen problems like this caused by a poor assembly process?

Thank you for the input.

VCCIO is 3.3V

MSEL is 0 1 0

DCLK frequency is ~30MHz

1 - Check MSEL setting.

2 - Grab an oscilloscope and check the configuration lines are wiggling.

3 - Scope a working board and check the signal integrity of the configuration lines. It's possible your layout has a borderline timing issue (not likely).

4 - Sounds like these are first-run boards. My experience is that it's almost always the board house's fault when an issue like this occurs.

5 - Does the part configure via JTAG?

--- Quote Start ---

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.

--- Quote End ---

This scheme is correct because the clock is driven from the FPGA. The FPGA latches the data that is present on it's DATA input. Then the clock edge signal propagates along the board trace to the EPCS device where it then drives the next data bit out.

Driving and latching on opposite edges would effectively reduce the fmax of the configuration scheme by 50% because the data signal would have half as much setup time before the latching edge.

Jake