Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
882 Views

Timing violation, from clock to data

Hello! 

I'm having a bit of trouble understanding this so here I come again hoping you guys can help me. 

 

I have a design which takes an input clock, goes through a PLL then through a logic mux and finally out a DDR pin, something like this: 

clk --> PLL --> CLKCTRL --> logicMUX --> CLKCTRL --> DDR pin 

 

First of all, I am aware of the problems with logic MUXes, but I don't have enough PLLs remaining to use and I can't use the CLKCTRL internal clock mux because all the clock sources are internal. I don't think it should be a problem though because I'm not using them as synchronous clocks in any way: there's no data exchange between this one and any of the others except for one spot which uses a dual clock FIFO. 

 

I think I've constraint the device correctly, create_clock on input, manually generated_clocks for PLL and then another generated clock after clock mux. 

 

Now on to what is confusing me. I keep getting some timing violations when running TimeQuest, but I'm not sure what to make of them. The source node is the PLL's PLL_OUTPUT_COUNTER|divclk (so basically the clock output from the PLL) and the target node is the DDR output pin, the launch clock is also the PLL while the latch clock is the mux'd one. Why would I get a timing path where the source node and latch clock are both the same? Am I supposed to cut paths between the pll output clock and the mux'd one? 

 

Thank you for your help. If there's not enough information please let me know and I'll update it with anything that you think is missing.
0 Kudos
2 Replies
Altera_Forum
Honored Contributor I
53 Views

I don't understand this statement: "I can't use the CLKCTRL internal clock mux because all the clock sources are internal." Just add the clock control block as an IP to your design. Internal clocks can use this, not just PLL outputs. 

 

You need set_clock_groups exception(s) to isolate the clocks going into the mux (use the -exclusive option, though that doesn't really matter). Only one clock can come out of the mux at a time so you need to tell the tool this. 

 

You also need a generated clock on the output clock pin with the source as the output of the PLL and the target as the output pin (port) of the device. The timing analyzer see outputs as data paths, not clock paths, so you need this extra generated clock and a false path constraint on that path as well (so the output clock path is not analyzed as a data path). 

 

It might be helpful to show your current .sdc file.
Altera_Forum
Honored Contributor I
53 Views

I should have specified the device, sorry about that. This is running on a Cyclone 5CGX. 

 

 

--- Quote Start ---  

Internal clocks can use this, not just PLL outputs. 

--- Quote End ---  

 

I think this isn't true, at least for my device, I don't know about others. Only certain clocks can go into the clock-control multiplexer according to the documentation, this is the relevant part (summarized from CycV handbook vol1, table 4-6 on version 2016.06.10): 

  • inclk
  • inclk
  • inclk
 

If you try to connect it differently it just doesn't compile. 

 

I really want to avoid having to post my sdc file because it's going to take me a _long_ time to strip it down, it's actually multiple files with lots of variables and constants. I'll do it if needed though, of course, but I want to ask you about one thing before I go down that road. 

I already have a generated clock for each clock after the mux and they're all excluded from one another. My timing violation is about the source clock (PLL) being used as the source node for the output pin (target node). I think this is related to your last comment 

 

--- Quote Start ---  

... and a false path constraint on that path as well (so the output clock path is not analyzed as a data path) 

--- Quote End ---  

 

do you mind explaining this in a bit more detail please? 

 

Thanks!
Reply