Location constraints and timing analysis

[Altera_Forum]

Hi everyone, 

 I'm working on an RGMII interface implemented in a Cyclone IV E FPGA.  The data input stage consists in an ALT_DDIO to recover DDR data in high-speed link, but also directly connected logic elements in case of low-speed links.  I'd like from fitting to fitting to keep the same timings from the FPGA input pins to the ALT_DDIO registers inputs. To do so, I've constrained the RGMII clock to be on a certain clock buffer all the time. Also, I've constrained the location of the ALT_DDIO registers. As I said, for low-speed link application, some logic is directly connected to the FPGA input pins (parallel to the ALT_DDIO) so I've also constrained the first logic elements on the FPGA inputs. With all those constraints, the path from the FPGA input pins to any of the first logic element is the same anytime.  The following figure illustrate such a signal path:  http://www.alteraforum.com/forum/attachment.php?attachmentid=10621&stc=1   The following elements on the path are constrained for location: - phy_rx_data[2]~5 - phy_rx_data[6]~2 - input_cell_h[2] (feeder is not constrained but is always placed at the same location) - input_cell_l[2] (feeder is not constrained but is always placed at the same location)  Moreover, the clock is using the same global clock network since placed on the same clock control block.  However, when I run fitting with the same source code but different seeds, the slack for the setup time for the two registers (input_cell_l[2] and input_cell_h[2]) is different. I expected it to be the same due to the constraints!  Do I miss something? Is there something I don't understand?  I'd really appreciate any help...  Thanks in advance, JG

[Altera_Forum]

Hi everyone, 

 I'm working on an RGMII interface implemented in a Cyclone IV E FPGA.  The data input stage consists in an ALT_DDIO to recover DDR data in high-speed link, but also directly connected logic elements in case of low-speed links.  I'd like from fitting to fitting to keep the same timings from the FPGA input pins to the ALT_DDIO registers inputs. To do so, I've constrained the RGMII clock to be on a certain clock buffer all the time. Also, I've constrained the location of the ALT_DDIO registers. As I said, for low-speed link application, some logic is directly connected to the FPGA input pins (parallel to the ALT_DDIO) so I've also constrained the first logic elements on the FPGA inputs.  With all those constraints, the path from the FPGA input pins to any of the first logic element is the same anytime.  The following figure illustrate such a signal path:  https://www.alteraforum.com/forum/attachment.php?attachmentid=10622   The following elements on the path are constrained for location: - phy_rx_data[2]~5 - phy_rx_data[6]~2 - input_cell_h[2] (feeder is not constrained but is always placed at the same location) - input_cell_l[2] (feeder is not constrained but is always placed at the same location)  Moreover, the clock is using the same global clock network since placed on the same clock control block.  However, when I run fitting with the same source code but different seeds, the slack for the setup time for the two registers (input_cell_l[2] and input_cell_h[2]) is different. I expected it to be the same due to the constraints!  Do I miss something? Is there something I don't understand?  I'd really appreciate any help...  Thanks in advance, JG

[Altera_Forum]

Your pin's locked and the register is locked. There are one of two things changing: 

1) Your input delay chain. Look in the fitter report and see what this is and if it's changing. You can lock this down with assignments in the Assignment Editor. 2) The routing. I'm guessing this is it. Run report_timing -show_routing on the paths in TimeQuest to compare two different place and routes. Note that this may change, and the fitter may then change the delay chains to react to that, so they may both be changing.  First, is it passing/failing timing with the changes? What your asking is almost never needed unless the timing is so absolutely tight that it passes/fails compile to compile. If this is something you just want to do without a pass/fail test, it's probably unnecessary.  To lock down routing, you can put the logic in a partition and set to post-fit. That is the easiest and what I would recommend.  Another option is to create a routing constraint file(.rcf) which is not well documented. Basically you need to back-annotate to the routing level, which will create an .rcf. It back-annotates the placement and routing of everything, and then you need to pull out the info you need. I believe the command is "quartus_cdb --back_annotate=routing <projectname>". This is really a method of last resort.

[Altera_Forum]

Hi Rysc, 

 Thanks for you very detailed answer and your tips :-) I'll take a look at routing and delay chains.  From compile to compile it pass/fails. Moreover I need to know with a high level of accuracy the time of incoming packet so it is required to keep the same routing for each FPGA programming file version.  Again, many thanks! JG

[Altera_Forum]

Hi everyone, 

 I can't enable the view of "Routing" layers in Chip Planner. Are some FPGA families not supported? I'm using a Cyclone IV E.  Thanks in advance, JG

[Altera_Forum]

There are special option to enable this "Routing" layers in Chip Planner, you will need to file a service request on this