--- 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
Honored Contributor
