Hi all,I have a design with major recovery timing violation (among others). The design wasn't written by me, I'm only editing it, so I'm not fully aware of everything inside it. There's a photo in the attachment with screenshots from timequest with the worst failing recovery path. I'm unable to grasp where is the ~7000 ns latch edge time in the data required path coming from??? Launch clock is 24 MHz, latch clock is 200 MHz. I tried putting the reset signal to global resources, but quartus just ignores this assignment. I'm working in quartus 17.1. I tried using the following assignment:
set_instance_assignment -name GLOBAL_SIGNAL ON -to "h158_core:u0|h158_core_mem_if_ddr3_emif_0:mem_if_ddr3_emif_0|h158_core_mem_if_ddr3_emif_0_p0:p0|h158_core_mem_if_ddr3_emif_0_p0_memphy:umemphy|h158_core_mem_if_ddr3_emif_0_p0_reset:ureset|h158_core_mem_if_ddr3_emif_0_p0_reset_sync:ureset_afi_clk|reset_reg";Any help would be appreciated as I'm stuck and have no idea what to do next. Thanks for your help!
Quartus by default always assumes that clocks are related so it's just trying to find the worst case interaction between the two. From your description of what you're trying to do, it sounds like all you should need to do is set a false path between the two nodes (or possibly even between the two clocks if you want to simplify things).Hope that helps! Andy
Thank you for your responses.It seems that my issue was this: https://www.altera.com/support/support-resources/knowledge-base/solutions/rd01032012_191.html That's why I had large timing violations in the ddr3 emif interface.