Timing constraints on a clock divider - Page 1
Forum section: electronics / general

author: link87
author_rank: Newbie
timestamp: April 16, 2025, 06:31:37 pm
content: Am I setting up these timing constraints incorrectly? I have a 27MHz crystal and use PLL to generate both a 100Mhz SYS_CLK. I am using an IP that produces a 25Mhz clock through a runtime-configurable clock divider internally. I am trying to constrain the output of this divider to the 25MHz SDIO_HIGHFREQ_CLK output. When I setup the constraints as shown below, I'm getting a hold violation between the output of the divider counter MSB flip-flip and a LUT used in a feedback path. This signal should still be in the SYS_CLK 100Mhz clock domain I think, but because the output of this FF is the SDIO_HIGHFRFEQ_CLK domain due to my constraint it gets confused. Is there a way for me to specify this correctly without adding another flip flop between the output and the feedback path?Code:create_clock -name XTAL_IN -period 37.037 -waveform {0 18.518} [get_ports {clock_27_pad}]create_generated_clock -name SYS_CLK -source [get_ports {clock_27_pad}] -master_clock XTAL_IN -divide_by 7 -multiply_by 26 [get_nets {clk_100}]create_generated_clock -name SDIO_HIGHFREQ_CLK -source [get_nets {clk_100}] -master_clock SYS_CLK -divide_by 4 [get_pins {sd_master/sd_controller0/clock_divider0/SD_CLK_O_s2/Q}]

author: whollender
author_rank: Regular Contributor
timestamp: April 18, 2025, 07:07:12 pm
content: Is that 'SDIO' clock just going to an output pin?If so, then you don't need a clock constraint for it at all.If it's being used to clock other internal logic, then it would be better to run your internal logic from your 100MHz sysclk with a clock enable that's divided down to give you a 25MHz rate. That way you still don't need to have a clock constraint for your SDIO clock, and everything should work fine.

author: bson
author_rank: Unknown
timestamp: April 23, 2025, 09:48:42 pm
content: It's a hold violation. This means the data output or input isn't held sufficient long after the active clock edge to meet the constraint. If output it means the clock is too late, or data too early. If input it means an input clock doesn't clock a FF to capture an input within the hold constraint.For SDIO the hold constraint should be derived form the card spec.

author: asmi
author_rank: Super Contributor
timestamp: April 25, 2025, 01:44:28 am
content: This is a weird timing error. Usually timing path is shown from one clocked component to another one, but in your case it goes from LUT to a register. That usually means you're doing something weird with the clock - like using it in some sort of logic calculation. If so, you're doing it wrong and you should get rid of that part and rewrite it with something which can be clocked normally. Also clock crossing typically requires using syncronizer with at least a pair of flip-flops.

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 26, 2025, 05:09:42 am
content: run a tcl commandreport_clock_networksread up on this (both definition, and timign closure ) in vivado user guidesIt's like you have two related clocks that cause a awkward timing closure. so you are probably doing something wrong.SDIO is leaving the chip , just time it against the SCLK clock pin on the interface. or if its sync with the SCLK, use a ODR with 0,1 on the inputs and clock from the clock . then it will easily be timed up. if its clocked out @90deg, you might need to use a 2x clock or a quadrature clock, or bodgy it with set_output_delay but that's alot of delay (100meg ext clock, 2.5nS offset) to do that way, but the tools would do it.... no big sin.

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 27, 2025, 04:45:58 am
content: if there are two related clocks in there, specially related by a odd value divisor, I think you are going to have to sort that one out.you'd almost be better to use a DFFS to cross a clock boundary along with all the ASYNC _REG stuf that goes with it, set_false_path etc etc.That's assuming its slow compared to the fast clock....if not, then you might need to reevaluate your strategy. maybe a shallow asynchronous LUT based FIFO.