Forum Discussion
28 Replies
- Altera_Forum
Honored Contributor
Thank you,BadOmen!
Your codes are working.All unconstrained paths has been cleared! After Report All Summaries,the report pane of TimeQuest display 2 red warning: 1)Summary (setup) Clock slack end point TNS inst|the_altpll_0|altpll1|pll3|clk[0] -1.167 -131.807 2)Summary(recovery) inst|the_altpll_0|altpll1|pll3|clk[0] -5.900 -78.992 To constraining PLL,I place this code in the .sdc file: create_clock -name {clk_50mhz} -period 20.000 -waveform { 0.000 10.000 } \[get_ports {clk_50mhz}] derive_pll_clocks derive_clock_uncertainty The input clock of the altpll is 50mhz,and output clock is 166.7mhz I don’t understand where the negative slack come from,and how to eliminate it. After compilation ,I receive 3 critical warning(Timing requirements not met) because of this. - Altera_Forum
Honored Contributor
The setup failures are probably real timing violations. You are using a -7 speed grade so it might be difficult to hit 167MHz depending on your design. I would scale that clock down to 150MHz then start optimizing from there.
Recovery failures have typically come having the PLL instantiated within my SOPC Builder system. This is a result of a clock crossing adapter being placed in front of the PLL slave port. I normally instantiate my PLLs outside of SOPC Builder for this reason. A recovery failure is similar to a data setup time violation only instead of data it has to do with the reset of a flip flop.... I hope that makes sense, I'm not very good at explaining timing analysis. Using the latest SOPC Builder I have noticed fewer cases where recovery/removal timing violations occur during analysis. - Altera_Forum
Honored Contributor
Thank you for your help.The negative slack and critical warning has been dismissed.
Scaling the PLL down to 150MHz according to your idea also get setup failure(in slow 1200mv 85c model).So I was compelled to give in to the 133.333MHz,and then all right. The slow 1200mv 85c model Fmax=142.29MHz, The slow 1200mv 0c model Fmax=152.63MHz. I wish to work stable in 133.333MHz clock which can synchronous to the DDR2 SDRAM---my next objective. - Altera_Forum
Honored Contributor
Dear BadOmen:
Recently,I'm struggling with the DDR2 HP Controller under the direction of AN517(Using High-Performance DDR, DDR2, and DDR3 SDRAM With SOPC Builder).The design is targeted to the Cyclone® III EP3C120F780C7 Kit. In this example,the SOPC system contain a Half-Rate DDR2 Controller working at 150MHz(altmemddr_auxfull),the PLL of the controller simultaneously generate a 75MHz output clock(altmemddr_sysclk) which been used as SOPC system clock. After compilation,I got three critical warning again------also cause by JTAG.The TimeQuest report negative slack(-2.428) in Summary(Removal) of altera_reserved_tck. I lose my head of this because I've constrained the JTAG using the templet:# JTAG Signal Constraints constrain the TCK port create_clock -name tck -period 100.000 [get_ports altera_reserved_tck]# Cut all paths to and from tck set_clock_groups -asynchronous -group [get_clocks altera_reserved_tck]# Constrain the TDI port set_input_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tdi]# Constrain the TMS port set_input_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tms]# Constrain the TDO port set_output_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tdo] I didn't know what's wrong with it. An other problem is the unconstrained path cause by the reset_n(cpu reset pin).My constraint code below this: set_input_delay -add_delay -max -clock [get_clocks {inst|the_altmemddr|altmemddr_controller_phy_inst|altmemddr_phy_inst|altmemddr_phy_alt_mem_phy_inst|clk|pll|altpll_component| auto_generated|pll1|clk[0]}] 2.0 [get_ports {reset_n}] set_input_delay -add_delay -min -clock [get_clocks {inst|the_altmemddr|altmemddr_controller_phy_inst|altmemddr_phy_inst|altmemddr_phy_alt_mem_phy_inst|clk|pll|altpll_component| auto_generated|pll1|clk[0]}] 1.0 [get_ports {reset_n}] In my mind,the reset_n should be constrained by the system clock(altmemddr_sysclk,75MHz),I got it's name from the Clocks Summary of TimeQuest. But in the compilation warning,the constraint code was ignored assignment because the Argument -clock is an empty collection. It means the clock name was wrong. How can I get the correct system clock name generate by the PLL of DDR2 HP Controller? - Altera_Forum
Honored Contributor
Try this:
derive_pll_clocks -create_base_clocks set_clock_groups -asynchronous -group [get_clocks altera_reserved_tck] set_input_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tdi] set_input_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tms] set_output_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tdo] The first line will make sure that there is a clock called 'altera_reserved_tck' in your system and the last three lines will be constrained with respect to this clock. Usually I set these long clock names to short names names using variables. Then you can refer to the variable using $<variable name> set Short_Name <really long hierarchy name for signal/clock> Since reset_n into the system must be held low for a two or more cycles I normally cut the reset_n input pin. On the dev kits the reset_n signal is hooked up to a push button so the reset will occur for many cycles. Inside the SOPC Builder system reset_n is synchronized to each clock domain in your system. Usually I don't attempt to tackle recovery/removal timing violations until my design meets setup and hold times and all my I/O are constrained. Usually the recovery and removal timing violations can be resolved by additional constraints around the reset synchronization logic. - Altera_Forum
Honored Contributor
Hello,BadOmen:
Thank you for reply. As your suggestion,I add this code in the .SDC file: set sys_clk inst|the_altmemddr|altmemddr_controller_phy_inst|altmemddr_phy_inst|altmemddr_phy_alt_mem_phy_inst|clk|pll|altpll_component|auto_generated|pll1|clk[0] I'm not sure if it has no syntax error.The TimeQuest still warning like this: 1:Warning: At least one of the filters had some problems and could not be matched. --- Warning: sys_clk could not be matched with a clock. 2:Warning: Ignored assignment: set_input_delay -add_delay -max -clock [get_clocks {sys_clk}] 2.000 [get_ports {reset_n}] --- Warning: Argument -clock is an empty collection 3:Warning: Ignored assignment: set_input_delay -add_delay -min -clock [get_clocks {sys_clk}] 1.000 [get_ports {reset_n}] --- Warning: Argument -clock is an empty collection The long clock name which I got from the clock summary seemed incorrect: inst|the_altmemddr|altmemddr_controller_phy_inst|altmemddr_phy_inst|altmemddr_phy_alt_mem_phy_inst|clk|pll|altpll_component|auto_generated|pll1|clk[0] - Altera_Forum
Honored Contributor
You declare variables using 'set <var name> <value>' but when you use the variable in your script you have to use '$<var name>'
i.e. set Imavariable abc $Imavariable > abc - Altera_Forum
Honored Contributor
Thank you for your prompt.
The constraining on resrt_n is working,all unconstrained paths has beed cut. But the critical warning cause by JTAG still exist. The TimeQuest report negative slack(-2.435) in Summary(Removal) of altera_reserved_tck. The Top Failing Paths (Removal:altera_reserved_tck) is this: Slack:-2.435 From---altera_reserved_tck To-----pzdyqx:nabboc|pzdyqx_impl:zdyqx_impl_inst|FNUJ6967 I've tried to slow down the DDR2 clock to 133.333MHz,the NIOS clock down to 66.667MHz,but the slack value still negative. The constrainning code: derive_pll_clocks -create_base_clocks set_clock_groups -asynchronous -group [get_clocks altera_reserved_tck] set_input_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tdi] set_input_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tms] set_output_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tdo] - Altera_Forum
Honored Contributor
I don't have a good story for that one because that is the open core plus logic. Open up Timequest and have it report the worst failing paths. Then copy and paste those paths into a text file and either attach it to this thread or send it to me in a private message and I'll take a look. This logic is used to hold your logic in reset after a timeout if you disconnect the programming cable and use an IP core in OCP mode.
- Altera_Forum
Honored Contributor
Thank your guidence!
Here is the .txt of the worst failing path,also include some warning reported by TimeQuest because of cpu.sdc file.