syncronous clocks

[Altera_Forum]

This may seem a like a stupid question, but I am new to Altera FPGA's. When using a PLL to generate syncronous clocks, lets say a base clock and a base clock multipled by 2 for example, can I assume the edges are perfectly aligned? 

In other words if a have a regester clocked by the base clocked as the input to a register clocked by the 2x clock can I assume that the data clocked into the 2x register is the data prior to the base clock edge. Or to put it in simpler terms can I assume the positive edge of the base clock and the 2x clock act the same as if the registers are clocked from the same clock. OR do I need to clock both registers from the 2x clock and use a clock enable.

[Altera_Forum]

Basically yes. Default phase is zero at output, Quartus will tell you how true is that. Normally we assume such clks are synchronous. x and 2x edges will coincide every two fast clks

[Altera_Forum]

reading your post again, it seems you got some confusion about the question. 

There are two issues, phase and use of clks. They are separate...

[Altera_Forum]

Care to elaborate on that. I know the phase of the clocks should be closely aligned, my question was if they are close enough so I can transfer data from one clock domain to the other without metastable and race condition problems, and if the Quartus software will consider the skew between the clocks in the timing analyzer. If not then the prudent design would be to clock all registers with the faster clock and use a clock enable on the registers that I want to clock every other clock.

[Altera_Forum]

Basically you should always sample your data at the right speed. So you can't feed data from slow clk to fast clk unless you control the rate through enable signal. As you said, an enable signal is better than multiple clk system if that is feasible.

[Altera_Forum]

--- Quote Start ---  As you said, an enable signal is better than multiple clk system if that is feasible.  --- Quote End ---   The systems base clock is choosen usually in a tradeoff between speed requirements and allowed logic or arithmetic complexety. It typically doesn't allow a double speed without adding considerably more pipeline levels. Auxilary slower clocks can be most easily created as divider generated clock enables rather than additional PLL clocks. Faster clocks, e.g. to drive memory interfaces or serial IO need PLL outputs in contrast. Their relation to the main clock when crossing the domains is always considered correctly by the Quartus timing analysis, as far as I experienced.

[Altera_Forum]

TimeQuest will do proper analysis between these PLL outputs though, and sending logic between these clocks is done all the time. So there's nothing wrong with what you're doing.

[Altera_Forum]

Another related question: when using clock enables to clock data at a slower rate than the system clock I know you can use timing constraints to let the router know that this path can have reduced timing requirements for the data being transfered between registers. However, the clock enable signal must still meet the faster system clock timing requirements. If I use timing constraints for the multi-cycle paths does the Quartus software only apply them to the data path and not the clock enable path? 

P.S. Thanks for all the replies, they have helped me to understand the details of designing with Altera FPGA's

[Altera_Forum]

How things are analyzed is up to the user. If you do something like the following(I'm typing from memory so the syntax may not be exact): 

set enabled_regs [get_fanouts enable_reg] set_multicycle_path -setup 2 -to $enabled_regs set_multicycle_path -hold 1 -to $enabled_regs  In this case we've made a group of all registers fed by the enable and multicycled to them. Of course, if your enable is a toggling register that just feeds back on itself, then yes, you've multicycled that path. (I'm sure people have made that mistake, and I'm also sure the router will always use a short path on that feedback and it will always make timing anyway, but the constraint is incorrect and it's theoretically possibly something could go wrong.)  I've seen people limit the fanout, to only fniding registers where it feed the enable port. Examples are at: http://www.altera.com/support/examples/timequest/exm-tq-clock-enable.html?gsa_pos=1&wt.oss_r=1&wt.oss=get_fanouts&gsa_pos=1&wt.oss_r=1&wt.oss=get_fanouts The only issue here is what if the enable feeds the D port for some reason. I've never seen that happen, but potentially a concern.  Another option is to do the original and then just overwrite the enable path: set_multicycle_path -setup -from enable_reg -to enable_reg 1 set_multicycle_path -hold -from enable_reg -to enable_reg 0  Be sure to do a report_timing for both setup and hold on this path to make sure it is properly overwritten. But again, circuits are timed how the user specifies, so this case is really up to the user. (Another idea would be to have a toggle flip-flop feed another register. That second register is what is used for get_fanout, and since it doesn't feed back on itself, all of it's destinations would be correct.)

[Altera_Forum]

My understanding is that if you set multicycle path on "enable signal" then quartus understands that is meant for all registers that use this enable as enable...so it is not applied to enable register itself because it is not enabled by itself.