- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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. thanksLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can we assume a<=config_reg will be valid, asume config_reg does not change?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Even if config reg don't change?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
no change means no worry at all
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
but remember you are sampling to (a) which will change. So is that change going to affect next path
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So? It same?
Does a has the value? Does the above conditions I wrote will work?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@100Mhz
if(a=1 and config_reg(sel)) then ... "a" and "sel" are at 100Mhz, and config_reg is 25Mhz, granting not to change.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The other option is to use en1 on reg(a) and en2 on next register and control delay of sampling between en1 & en2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thank you.
what about : a<=config_reg(sel); where a,sel are 100Mhz ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page