Configuring 2 Cyclone III's from one EPCS16 Using 2.5V

--- Quote Start ---

AS configuration master of the two and IO_FPGA.sof is set as the PS configured slave FPGA

--- Quote End ---

So do you have the nCE of the second device driven by the nCEO of the first device?

I performed a timing analysis of this method, and technically it can fail to meeting timing, eg., see the attached.

The SN74CB3T1G125DBVR is a bus-switch, so you have selected the appropriate type of part to minimize the buffer delay.

You should measure the signals with a scope and compare them to the setup/hold time requirements in the attached.

If its possible to separate the nSTATUS signal and CONF_DONE signals for the two FPGAs, you could try configuring them individually. You could also try configuring them with JTAG to check that they do actually configure correctly. JTAG will only work if you configure them in sequence, so that nCEO from the first enables the second.

Cheers,

Dave

MORE INFO FROM POSTER:

12. The Config_Done line does not even twitch off of zero Volts.

13. The nStatus line has a rise time (10% to 90%) of approx. 700 ns, and a fall time of about 1.5 ns.

14. The INIT_DONE line will go high 448 ns after the nStatus line goes low, and goes low 115 us later, 60 us after nStatus goes high again.

15. nStatus goes low 800 ns before nCEO of the Master FPGA goes back high.

16. From estimates made by my PCB CAD program, the delay of DCLK from FPGA to EPCS16 is 0.56 ns plus the translator delay. The delay of DATA_0 from the EPCS16 to the FPGA is 0.47 ns plus the translator delay. the translator delay from the datasheet is 0.15 ns max., but could actually be seen to be 1.5 ns. Round trip clock to data back is then about 1.5 + 1.5 + 0.56 + 0.47 = 4.03 ns.

--- Quote Start ---

12. The Config_Done line does not even twitch off of zero Volts.

--- Quote End ---

If it did, we probably would not be having this conversation :)

--- Quote Start ---

13. The nStatus line has a rise time (10% to 90%) of approx. 700 ns, and a fall time of about 1.5 ns.

--- Quote End ---

To be expected; its driven low, but tri-stated and pulled-up when going high.

--- Quote Start ---

14. The INIT_DONE line will go high 448 ns after the nStatus line goes low, and goes low 115 us later, 60 us after nStatus goes high again.

--- Quote End ---

INIT_DONE is an optional pin, it only has meaning near the end of configuration.

Have a look at this doc, it has some INIT_DONE timing examples

http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf

--- Quote Start ---

15. nStatus goes low 800 ns before nCEO of the Master FPGA goes back high.

--- Quote End ---

Could you clarify; did nCEO transition from high-to-low, implying that the first FPGA configured ok, and its the second that causes the failure?

--- Quote Start ---

16. From estimates made by my PCB CAD program, the delay of DCLK from FPGA to EPCS16 is 0.56 ns plus the translator delay. The delay of DATA_0 from the EPCS16 to the FPGA is 0.47 ns plus the translator delay. the translator delay from the datasheet is 0.15 ns max., but could actually be seen to be 1.5 ns. Round trip clock to data back is then about 1.5 + 1.5 + 0.56 + 0.47 = 4.03 ns.

--- Quote End ---

So do the math - is there any timing margin for the PS device?

Cheers,

Dave

Thank you for your reply.

I do have nCE of the second device driven by the nCEO of the first device.

I believe you helped me pick the bus-switch when I was doing the schematics for the board.

I see the issue in your diagram, that the PS timing of the second FPGA has little or no margin.

I did not get the impact of this the last time I saw this.

I did measure my signals and have included images with this reply. The clock was measured with a nice

differential probe, but the data was measured with a standard probe with a long ground lead.

I really have very little margin on the PS as you suspected.

Q3: Do you know off the top of your head whether I can simply invert the clock to the second FPGA

to improve the PS Timing? I could use a NAND gate buffer instead of an AND.

I did notice that DCLK does not pause at the point where nCEO goes from inactive to active. DATA

however does not transition for an interval before and after the switch (nCEO going active). I

expect that there is a "start bit" in the DATA and the timing of the clock with respect to nCEO does

not matter. What do you think?

Much to my dismay the nStatus and Config_Done signals between the two FPGA run completely on

inner signal layers from one BGA via to the other BGA via.

Thanks again

"Could you clarify; did nCEO transition from high-to-low, implying that the first FPGA configured ok, and its the second that causes the failure?"

Sorry, Good catch. nStatus goes low when nCEO goes inactive, low-to-high.

Q4: Would nStatus go low earlier if the first FPGA had detected failure?

--- Quote Start ---

I do have nCE of the second device driven by the nCEO of the first device.

--- Quote End ---

Ok.

--- Quote Start ---

I believe you helped me pick the bus-switch when I was doing the schematics for the board.

--- Quote End ---

I recalled helping someone, but was not sure it was you :)

--- Quote Start ---

I see the issue in your diagram, that the PS timing of the second FPGA has little or no margin.

I did not get the impact of this the last time I saw this.

--- Quote End ---

Right, but that margin is only in the worst-case condition of the internal oscillator having the minimum period. If your scope traces show a slower DCLK period, then you might be ok.

--- Quote Start ---

I did measure my signals and have included images with this reply. The clock was measured with a nice

differential probe, but the data was measured with a standard probe with a long ground lead.

--- Quote End ---

I don't see the images - try attaching them again (use the "Go Advanced" button to get to the page that allows you to add attachments).

--- Quote Start ---

I really have very little margin on the PS as you suspected.

--- Quote End ---

If you have margin, then it should work.

--- Quote Start ---

Q3: Do you know off the top of your head whether I can simply invert the clock to the second FPGA

to improve the PS Timing? I could use a NAND gate buffer instead of an AND.

--- Quote End ---

Try it and see. The problem I suspect you will trying to change DCLK to the FPGA, is that you have a common DCLK to both the EPCS device and second FPGA, so you will need to remove your bus switch and create two unique DCLK paths.

--- Quote Start ---

I did notice that DCLK does not pause at the point where nCEO goes from inactive to active. DATA

however does not transition for an interval before and after the switch (nCEO going active). I

expect that there is a "start bit" in the DATA and the timing of the clock with respect to nCEO does

not matter. What do you think?

--- Quote End ---

If you look at the .pof files, there's a bunch of FFs at the start. There is likely something in the bit-sequence that acts as the start indicator.

--- Quote Start ---

Much to my dismay the nStatus and Config_Done signals between the two FPGA run completely on

inner signal layers from one BGA via to the other BGA via.

--- Quote End ---

You live and learn.

There lesson here is to make all configuration signals route through 0-ohm resistors so that you can disconnect your programming chain when debugging. This goes for JTAG chains too. I've had to jumper over bad devices before, and its very convenient to simply remove a 0-ohm resistor on the TDO->TDI paths, and jumper the working TDO to a working TDI.

Cheers,

Dave

--- Quote Start ---

"Could you clarify; did nCEO transition from high-to-low, implying that the first FPGA configured ok, and its the second that causes the failure?"

Sorry, Good catch. nStatus goes low when nCEO goes inactive, low-to-high.

Q4: Would nStatus go low earlier if the first FPGA had detected failure?

--- Quote End ---

If there was something wrong with the configuration data, then I would expect the first device to "complain" earlier, i.e., drop nSTATUS low.

Do you have JTAG connected on this board? Does it work?

If it does, you could ...

1. Confirm that both devices can be configured using JTAG. Probe nCEO, nSTATUS, and CONF_DONE.

2. Load the EPCS with only the configuration data for the first device.

Pulse nCONFIG, and the EPCS should configure only the first device. That first device should assert nCEO to enable the second device.

2. Use JTAG to load the second device.

I don't see any reason why that should not work - but I'm not sure if its totally valid - try it and see.

Cheers,

Dave

I cannot program the two FPGA's separately since I cannot decouple the Config_Done's. However, if I repeatedly trigger

off of nCEO and monitor Config_Done at 10 mV per division and lots of averaging I can tell that the first FPGA must have

released its Config_Done right at the time that nCEO goes active (low). Config_Done shows ringing and a 3 mV change in

its level.

This looks like evidence that it is the second FPGA that is failing its configuration, yes ??

--- Quote Start ---

I cannot program the two FPGA's separately since I cannot decouple the Config_Done's.

--- Quote End ---

You misunderstand. The first FPGA *can* be configured by the EPCS device, but it will not enter user mode, since the other device is holding CONF_DONE low.

If you use JTAG to program the second device, then it will release CONF_DONE, and both FPGAs should enter user mode.

Yeah, its subtle, but it should work.

--- Quote Start ---

However, if I repeatedly trigger off of nCEO and monitor Config_Done at 10 mV per division and lots of averaging I can tell that the first FPGA must have

released its Config_Done right at the time that nCEO goes active (low). Config_Done shows ringing and a 3 mV change in its level.

This looks like evidence that it is the second FPGA that is failing its configuration, yes ??

--- Quote End ---

Yeah, that sounds like a reasonable assumption.

You did not comment yet whether you can program these devices with JTAG.

Cheers,

Dave