FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

timing questions -false path for the experts

Altera_Forum
Honored Contributor II
3,156 Views

Hi, 

 

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

config_reg 

table_of_vaule 

 

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}] 

make sure than when I write and read I hold the values10 clocks, 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. 

 

 

thanks
0 Kudos
20 Replies
Altera_Forum
Honored Contributor II
603 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
603 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
603 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

Even if config reg don't change?

0 Kudos
Altera_Forum
Honored Contributor II
603 Views

no change means no worry at all

0 Kudos
Altera_Forum
Honored Contributor II
603 Views

but remember you are sampling to (a) which will change. So is that change going to affect next path

0 Kudos
Altera_Forum
Honored Contributor II
603 Views

So? It same? 

Does a has the value? 

 

Does the above conditions I wrote will work?
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

I read your first post and re-read it but you are not explaining the clocking scheme around (a). 

I understand you are clocking the register conf_reg with 25MHz. 

But what about register (a)? is it on 25MHz or 100MHz? 

From your statemet "if a=1 and conf_reg(0)" I know it is on clock 100MHz thereafter
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

@100Mhz 

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

... 

 

 

"a" and "sel" are at 100Mhz, and config_reg is 25Mhz, granting not to change.
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

 

--- Quote Start ---  

@100Mhz 

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

... 

 

 

"a" and "sel" are at 100Mhz, and config_reg is 25Mhz, granting not to change. 

--- Quote End ---  

 

 

Ok so reg(a) is clocked by 100MHz, so is reg(sel) but conf_reg is clocked by 25MHz. 

path 1) The path from conf_reg can be made false, but not the one (to) conf_reg, and  

path 2) provided the path on clock 100MHz from (a) to next register is given enough time to settle since (a) output could change anytime an may violate clock 100MHz. 

 

If you are not sure insert two registers on clock 100MHz just before (a) register.
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

The other option is to use en1 on reg(a) and en2 on next register and control delay of sampling between en1 & en2

0 Kudos
Altera_Forum
Honored Contributor II
603 Views

reg "a" will sample "config_reg" once at 100Mhz in one of the steps on the state machine.... 

 

values from register "a" are not set to false path.... 

 

process(clk100mhz) 

beginif (rising_edge(clk100mhz)) then 

if (sig_from_another_100mhz_process='1') then 

a<=config_reg; 

a_was_set<='1'; 

else 

a_was_set<='0'; 

end if; 

 

if (a_was_set='1') then 

b<=a; 

end if; 

end if; 

end process; 

 

 

b and a should be able to hold the correct value of config_Reg, assuming config_reg does ***not*** changes
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

 

--- Quote Start ---  

The other option is to use en1 on reg(a) and en2 on next register and control delay of sampling between en1 & en2 

--- Quote End ---  

 

 

just to correct myself. if conf_reg is constant then there is no problem. you can set false path from it an ignore my other notes
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

 

--- Quote Start ---  

just to correct myself. if conf_reg is constant then there is no problem. you can set false path from it an ignore my other notes 

--- Quote End ---  

 

 

is not define as a "constant" in vhdl, however.... it will not change...
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

 

--- Quote Start ---  

is not define as a "constant" in vhdl, however.... it will not change... 

--- Quote End ---  

 

 

so it is set early well before design starts using it even if (a) samples it from start the design is idle. That is ok
0 Kudos
Altera_Forum
Honored Contributor II
603 Views

thank you. 

 

 

what about : 

 

a<=config_reg(sel); 

 

where a,sel are 100Mhz ?
0 Kudos
Altera_Forum
Honored Contributor II
586 Views

 

--- Quote Start ---  

thank you. 

 

 

what about : 

 

a<=config_reg(sel); 

 

where a,sel are 100Mhz ? 

--- Quote End ---  

 

 

sel being generated in clk 100MHz domain is ok.
0 Kudos
Reply