Forum Discussion
Altera_Forum
Honored Contributor
12 years agoWhat is Timing between nCEO and DCLK in a multi-device AS Configuration ?
Is there timing requirements between nCEO and DCLK when configuring two FPGA's from one EPCS device?
The master device (the first FPGA configured) operates in an AS configuration mode and once configured pulls down the nCEO output connected to the nCE pin of the next FPGA to be configured. The DCLK does runs continuously through the point where nCEO transitions to low. The FPGA's are Cyclone III's. The online documentation for configuring Cyclone III's discusses using the PS mode to configure multiple FPGA's in the context of using a MAX II or a processor. It states: "After the first device completes configuration in a multi-device configuration chain, its nCEO pin drives low to activate the nCE pin of the second device, which prompts the second device to begin configuration. The second device in the chain begins configuration in one clock cycle." Configuration begins in one clock cycle, it says, but is it OK to be off by a clock after nCEO goes low? DCLK to the second FPGA has a delay of 5.5 ns with respect to nCEO because DCLK is buffered before being routed to the second FPGA. Does the bitstream have padding at the start of the second FPGA configuration and use a "Start" indication before clocking in the configuration bits? This would avoid issues with the nCEO/DCLK timing. Currently my second FPGA is not configuring correctly and allowing Config_Done.11 Replies
- Altera_Forum
Honored Contributor
--- Quote Start --- The problem has been resolved. My expensive PCB layout tool was not supposed to let me cross my signals, but some how it did. DATA0 and DCLK on the FPGA that would not configure were swapped on the PCB but not on the schematic. Its over. I can get on with the project and my life again. --- Quote End --- Can you elaborate on this a little more. I have PCB tools from Mentor and Cadence, and have never seen this issue (other than a user-mistake in the schematic). Can you check that when you netlist the schematic design, and import that netlist into your PCB design that you get no net changes? It sounds more like a case that the error was fixed in the schematic after the PCB was built. Though if you were the designer of both the schematic and PCB, and you do not recall doing that, then we'll have to think of another hypothesis :) I'm glad to hear you resolved the issue, however, the cause still sounds a little scary ... Cheers, Dave