Question about set_false_path statements.

[Altera_Forum]

Hello! 

I'm trying to constrain a module but I'm not sure if the sdc statement I'm using has any undesired consequences. Specifically, I have a reset synchronizer I use all the time to synchronize an asynchronous reset deassertion to a clock so I want to embed the sdc statement in the vhdl source code, otherwise people tend to forget to constrain it and violations appear everywhere. I use the following piece of code for that, it's as simple as you get but it helps to show my problem:  process (reset, clock) begin if (reset = '1') then sync <= '1'; sync_rst <= '1'; elsif (rising_edge(clock)) then sync <= '0'; sync_rst <= sync; end if; end process;   The sdc statement I'm embedding in the code is the following (entity's name is rst_sync):  set_false_path -to set_false_path -to   Now, I'm not sure whether the -to ...sync_rst command also cuts the path in the sync_rst <= sync assignment, that would certainly not be what I want. I only want to remove the paths from the reset to the sync and sync_rst signals, however, I can't include the -from option in the sdc statements because the path to those is unknown to me.  I've also looked at the Quartus Handbook and it says to use the  attribute altera_attribute: string; attribute altera_attribute of sync: signal is "-name CUT ON -from reset";  attribute, but this doesn't seem to work or do anything though, does it work for the TimeQuest analyzer or is it only for the older time analyzer?  I'd appreciate it if someone could help me out with this!  Regards, Sebastian.

[Altera_Forum]

a -to will mean any path to register sync_rst including sync to sync_rst. 

I suggest adding max/min delay to that path to override but I am not sure if t will override

[Altera_Forum]

There's usually no need to specifically constrain a reset synchronizer, as long as reset is an external input and not sourced from a constrained clock domain.

[Altera_Forum]

--- Quote Start ---  a -to will mean any path to register sync_rst including sync to sync_rst. I suggest adding max/min delay to that path to override but I am not sure if t will override  --- Quote End ---   This sounds interesting. I'm not sure what values I should be using though, it seems pretty arbitrary. I'll try it out and see if it actually overrides the false path.    --- Quote Start ---  There's usually no need to specifically constrain a reset synchronizer, as long as reset is an external input and not sourced from a constrained clock domain.  --- Quote End ---   Unfortunately, the reset is not always sourced from an external input and there are cases that need to be synchronized from another clock domain. For example, some modules are used in just about all of our projects and, since we can't be sure everyone will be using the correct async reset, they have an internal reset synchronizer, in this case the signal might come from an input pin or an already synchronized reset. It's also useful to us during debugging, we might need to intentionally reset a module and the logic that drives this reset might be running on another clock domain.  Thank you both for the answers!  Regards, Sebastian.

[Altera_Forum]

The synopsis original set_false_path had a switch to exclude any desired path(it is called reset_path -from...) 

Altera seems ignored it.  Regarding how much max/min delay. I suggest a max = min = half clock period or so to achieve balanced tSU/tH as this improves MTBF

[Altera_Forum]

Thank you all for your input on this. 

I actually wasn't convinced on the half clock period min/max settings, the problem being that I can't know which clock would be used to synchronize the reset. The reset_path command doesn't seem to exist anymore, can't find it on any help or reference manual and google barely comes up with two forum posts (one of which is this one). In the end, I changed to SDC statement to the following which I believe does the trick: set_false_path -to set_false_path -to  If I'm not mistaken, this would only create a false path to the clear port of the register, thus keeping the path between sync and sync_rst.  Regards, Sebastian.