IOPLL related clock constraints
Hello Every one I am struggling with creating clock constraint and need help. I have agilix 10 FPGA design at project level top module I have input "iopll_clk_clk". this input is mapped to clock capable input pin on FPGA and is connected to 50MHz on board clock source. The toplevel module has iopll instantiation as following pcie_ed_iopll_0 iopll_0 ( .refclk (iopll_clk_clk), // input, width = 1, refclk.clk .locked (), // output, width = 1, locked.export .rst (resetip_ninit_done_reset), // input, width = 1, reset.reset .outclk0 (iopll_0_outclk0_clk) // output, width = 1, outclk0.clk ); "iopll_0_outclk0_clk" is supposed to be used as clock input for inner logic only. in Platform designer IOPLL is IP is configured to output only one clock at 300MHz. in the project SDC file I have following constraints #iopll Clock create_clock -period 20 [get_ports iopll_clk_clk] #derive_pll_clocks -create_base_clocks - Tried it but not supported for Agilex 10 create_generated_clock -multiply_by 6 -source [get_ports iopll_clk_clk] -name iopll_0_outclk0 [get_pins iopll_0|iopll_0_outclk0] - this is line 17 Here while compiling the design during fitter stage i see following warning messages. Warning(332174): Ignored filter at intel_rtile_pcie_ed.sdc.terp(17): iopll_0|iopll_0_outclk0 could not be matched with a pin Warning(332049): Ignored create_generated_clock at intel_rtile_pcie_ed.sdc.terp(17): Argument <targets> with value [get_pins {iopll_0|iopll_0_outclk0}] contains zero elements This tells me that the IOPLL clocks are not constrained properly and Quartus wont be able to evaluate clock paths correctly for internally generated 300MHz clock. can you help me in figuring out what am i doing wrong here? How can I correctly constraint that iopll is fed with 50MHz clock and its output is 300MHz clock?
Hard reset with USB-Blaster and Quartus
Hello there, I am working on few JTAG operations using Quartus prime standard (v24) with USB-Blaster (cable). After every operation I need to hard reset to perform the next operation. Unless Hard-reset is performed, the data received in TDO is not correct. Is there any command to make sure we do not have to perform hard-reset (Just to note, soft-reset is always performed). A quick response to this would be appreciated. Thanks in advance :) BR, Alkesh
Realistic values for set_max_skew
I have a design with asynchronous input and output bus signals. For the input bus signals I do not care how much time it takes from the Input Ports to the first register. For the output signals I also do not care how much time it takes from the last register to the output ports. The only thing that I really care about is, the skew of the bus signals. I have created a very simple dummy design and added sdc design constraints. module top( input clk, input [1:0] input_bus, output reg [1:0] output_bus ); reg [1:0] register; always @(posedge clk) begin register <= input_bus; output_bus <= register; end endmodule create_clock -name clk -period 20 [get_ports clk] set_max_skew -from [get_ports {input_bus[*]}] 0.5 set_max_skew -to [get_ports {output_bus[*]}] 0.5 Timing Analyzer fails. I do not have a lot of experience with SDC constraints and bus timing. My feelfing is, that 0.5ns bus skew is not unrealistic. Is my expectation wrong, or am I doing something wrong?CDC violations from DCFIFO
CDC-50007 design rules violation are coming internal from DCFIFO. What is the Altera suggestion for the violation internal to the IP. I can see DC_FIFO has false path constraint embedded in the IP. I am wondering why these violations are coming even when false path constraint there on those paths.
Setup slack violations?
Hi, I have a design implemented in a Cyclone 10LP device, but I am struggling a bit with the Timing Analyzer. I am using Quartus Prime Lite edition 24.1. The setup-slack is violated for a number of paths, but I need some help interpreting the waveform shown in the attachment. And, looking at the path in Technology Map viewer I also struggle on how to improve the timing. How can I attack the issue? A pointer to relevant documentation is highly appreciated
TimeQuest Question Relating PLL
I have a design on a DE23-lite board. I use the onboard 50 MHz clock to feed a PLL set to 150 MHz. All registers clock on the PLL. I_clk is the 50 MHz clock. I use the following rule: create_generated_clock -name clk_pll -source [get_ports {I_clk}] -multiply_by 3 [get_pins {pll0|iopll_0|tennm_ph2_iopll|out_clk[0]}] (Yes, the PLL output has that name) Now TimeQuest complains: No paths exist between clock target "pll0|iopll_0|tennm_ph2_iopll|out_clk[0]" of clock "clk_pll" and its clock source. Assuming zero source clock latency. So I looked up the PLL input clock. But if I write: create_generated_clock -name clk_pll \ -source [get_pins {pll0|iopll_0|tennm_ph2_iopll|ref_clk0}] \ -multiply_by 3 \ [get_pins {pll0|iopll_0|tennm_ph2_iopll|out_clk[0]}] the setup slack on I_clk is -7 ns, but no register clocks on this clock. So what to do?Timing Violations: 8x F-Tile ETH Hard IP TX_CLKOUT
Hello Intel Team, In our design, we instantiated eight 10G F-Tile Ethernet Hard IPs (including ANLT) using the VHDL "GENERATE" construct. During timing analysis, we are encountering setup and hold violations on the "TX_CLKOUT" path of the F-Tile transceivers. The "REPORT_CLOCKS" command shows that these 8 clocks are being generated with a frequency of 402.83 MHz under the following names: gen_eth[0].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch23 gen_eth[1].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch22 ... gen_eth[7].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch16 The corresponding master clocks are: gen_eth[0].proc_ftile_eth_hardip|eth_f_0|tx_pld_pcs_clk_reg|ch23 TX_CLKOUT clocks are asynchronous to each other and operate independently. Therefore, we attempted to exclude them from timing analysis using the "set_clock_groups -asynchronous" constraint, like this: set_clock_groups -asynchronous \ -group { [get_clocks {gen_eth[0].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch23}] } \ -group { [get_clocks {gen_eth[1].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch22}] } \ -group { [get_clocks {gen_eth[2].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch21}] } \ -group { [get_clocks {gen_eth[3].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch20}] } \ -group { [get_clocks {gen_eth[4].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch19}] } \ -group { [get_clocks {gen_eth[5].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch18}] } \ -group { [get_clocks {gen_eth[6].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch17}] } \ -group { [get_clocks {gen_eth[7].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch16}] } However, this approach results in the following errors: - Warning(20314): Invalid collection filter: [get_clocks {gen_eth[0].proc...}] - Warning(332049): Ignored set_clocks_group: Argument -group with value could not match any element of the type clk. - Warning(332049): Argument -group is not an obejct ID. I’ve tried multiple approaches, get_nets, Get_pins, also using wildcards and "create_generated_clock", but nothing has resolved the issue. According to my understanding, a "create_generated_clock" constraint shouldn't be necessary, since these clocks are automatically generated by Quartus. When inspecting the design in the Timing Analyzer using "get_clocks *ch23, the clock names appear to be internally resolved to autogenerated IDs like "_co15660". However, these IDs are not stable and may change with each compile (fit), which makes them unsuitable for constraints. At this point, I am running out of ideas. Question: How can I properly constraint or eliminate the setup and hold violations on the eight "TX_CLKout" clocks generated by Quartus in the F-Tile Ethernet Hard IPs? Should I just use "Set_False_Path"? I used the "Generate" command in VHDL to instantiate the 8 F-Tile ETH Hard IP + 8 ANLT. Could be this a problem ? kind regards JacobQuartus Prime Pro 25.1.0 Reports Unconstrained Paths in Cyclone 10GX PCIe Hard IP
Hi, Recently I have installed Quartus Prime Pro 25.1.0 and recompiled a Cyclone 10GX design that was originally compiled in Quartus Prime Pro 20.1.0. All IP's were updated automatically in 25.1.0. The Timing Analyzer reports Illegal Clocks and Unconstrained Clocks within the PCIe Hard IP. Those errors are not reported in 20.1.0. Are they genuine errors? Can they be ignored? Many thanks Wei
