CIII / Configuration

--- Quote Start ---

I have a cyclone EP3C10F256C8 and configuration flash EPCS4SI8N.

--- Quote End ---

Does the EP3C10F256C8 have an N postfix? i.e. is it a lead free part? The Flash you mention is a lead fre part

Mixing Lead Free and Leaded parts needs careful control at assembly.

I only say that because I have worked on a mixed board and seen signal integrity problems on some PCBs due to incorrect solder temperatures.

From the Altera website:

Q: Can I use both leaded and RoHS-compliant parts on the same board?

A: Yes, both leaded and RoHS-compliant parts can be used on the same board. There are high-volume consumer products that are currently using both types of packages. However, using both lead and RoHS-compliant parts together will add to the complexity of the manufacturing process. Altera does not recommend this design for volume production.

Might be worth checking with the PCB assembler.

Thank you.

But yes, both parts are RoHS compliant. In fact, the whole board was done with RoHS compliance. But you bring up a good point about the RoHS process.

Rob

What's your voltage for Vccio of IO bank 1 and setting for MSEL?

Whats DCLK frequency?

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

VCCIO is 3.3V

MSEL is 0 1 0

DCLK frequency is ~30MHz

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.

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

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?

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.