Negative slack with the lib/clock/xd #176
-
|
Hi, I'm new to Verilog and fpga, but some experience with low level programming. The ProjectF website is great! I've got an Arty-7 and I've followed the VGA graphics tutorials up to "draw a white square", and then built on it a text mode that draws 80x30 text using a character map and a bitmap font. I've taken the same approach as the stretched bitmap example: I've got the VGA section running with the 25.2Mhz clock, and the part that renders characters to pixels running at 125Mhz. Between them is a line buffer. I'm using the xd module to communicate new lines and new frames. It's mostly working, but the xd module continually fails timing with negative slack. I've tried many, many variations but the amount it fails by is unchanged. It seems to me that the shift register and/or toggle bit simply aren't available soon enough to satisfy the faster clock. I wonder if there's something obvious that I'm doing wrong? Common beginner problem? I've attached a screenshot from Vivado's timing report. Thanks.
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Your design is fine. The problem is that Vivado doesn't know you're crossing clock domains safely with the xd module. Vivado performs timing analysis on the inter-clock path between the 25.2 and 125 MHz clocks and can't make it work. You need to add an entry in your constraints (XDC) file to tell Vivado these clocks are asynchronous. For example, this is what I use in my framebuffer example from https://projectf.io/posts/framebuffers/ ## Pixel Clock is async to System Clock
set_clock_groups -name SysPixel -asynchronous \
-group [get_clocks -of_objects [get_pins clock_sys_inst/MMCME2_BASE_inst/CLKOUT0]] \
-group [get_clocks -of_objects [get_pins clock_pix_inst/MMCME2_BASE_inst/CLKOUT1]];Your clock names might be different, so adjust the command accordingly. Vivado won't perform timing analysis between async clocks. If you accidentally use the wrong clock in an always block sensitivity list you won't get any warning, so be careful. For more details on |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for that. I suspected it to be the case, but red highlighted errors like that are always a worry when something is not quite working. |
Beta Was this translation helpful? Give feedback.
Your design is fine. The problem is that Vivado doesn't know you're crossing clock domains safely with the xd module. Vivado performs timing analysis on the inter-clock path between the 25.2 and 125 MHz clocks and can't make it work.
You need to add an entry in your constraints (XDC) file to tell Vivado these clocks are asynchronous.
For example, this is what I use in my framebuffer example from https://projectf.io/posts/framebuffers/