timing questions -false path for the experts

--- Quote Start ---

You have false_path'ed config reg, so the fitter is free to place them wherever it likes, and any timing will ignore config_reg. Are you sure you want to do this? it could be violating timing and increase the chance of a metastable event when it changes.

--- Quote End ---

We can assume config_reg will not change...

when i do write to it, i am making sure i hold values long enough,

i also read back to validate.

--- Quote Start ---

Can we assume a<=config_reg will be valid, asume config_reg does not change?

--- Quote End ---

For clock crossing there are two scenarios:

If any signal transition from clk1 domain to clk2 domain is designed to be sampled after several clocks periods on clk2 then it is safe. This implies slow signals

For faster signals (as well as short pulses) , above cannot be done and a fifo (or handshake) solution is needed.

So? It same?

Does a has the value?

Does the above conditions I wrote will work?

If you mean conf_reg is constant then that is not a timing path to reg (a).

Now if reg (a) is on slow clk you are sampling a constant (no problem) and (a) will acquire new value. If this is passed to fast clock then this path from (a) must be allowed to settle.

You need to explain clocks used in your request of a <= conf_reg

--- Quote Start ---

If you mean conf_reg is constant then that is not a timing path to reg (a).

Now if reg (a) is on slow clk you are sampling a constant (no problem) and (a) will acquire new value. If this is passed to fast clock then this path from (a) must be allowed to settle.

You need to explain clocks used in your request of a <= conf_reg

--- Quote End ---

Hi,

I explained it before, but ill do it again:

Hi,

I have a design that has value in it that define the code behavior, let call them:

config_reg

1. because of the nature of those things, they are deep in the design.

2. those values are being configured using 25Mhz clock

3. values are used using a 100Mhz clock.

I run a set_flase_path :

set_false_path -from [get_keepers {config_reg}]

set_false_path -to[get_keepers {config_reg}]

*making sure that when I write and read I hold the values 10 clocks (or more), make sure it sticks.

Another code run on a different 100Mhz, used config_reg(0) to branch.

Assuming values at config_reg are stable does the set_flase_path has any damaging effect?

@100Mhz

if(a=1 and config_reg(0)) then

...

what about that:

@100Mhz

if(a=1 and config_reg(sel)) then

...

where sel and a are 100Mhx values with NO false_path on them.