So if anyone has suggestions for this sdc file so we can check the timing that would be great
t
Tobias Strauch
08/31/2022, 9:24 AM
Sorry, I lost track here. May I ask, what exactly do you like to check ?
m
Matt Venn
08/31/2022, 9:24 AM
That the incoming data to scan controller doesn't cause hold violation
t
Tobias Strauch
08/31/2022, 9:38 AM
So the path
from signal clk,
through scan_clk_r register,
through the scan_clk_r clock tree,
through the last scan_cell register,
through the controller FSM logic (here mux),
to the output_buf[something]_reg
clocked by signal clk,
should be checked for hold time violation.
Tobias Strauch
08/31/2022, 11:17 AM
So if you mean the path through scan_data_in and the path I have shown above is correct, then this path is for sure so long that it is greater than the hold time constraint of the receiving register.
Tobias Strauch
08/31/2022, 11:25 AM
But it is different for hold time violations between the scan registers. The scan_clk tree must be balanced as well and I hope you are doing that, or you use another trick which I don't see in the code right now. If you set the scan_clk as clock in STA, it should check for hold time violations within the scan chain.
I tried a second clock in my design with an unbalanced clock tree, and the hold time violations were massive.
m
Matt Venn
08/31/2022, 12:06 PM
tnt has tried a top level sdc (linked in the channel), but it is not working. So that would be great if you have any input on that