Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

Timequest contraints: pseudo-asynchronous case

Hi all,

I am doubtful about how to constraint a few things in a design I have in a Cyclone II FPGA. Basically, the situation is as follows:

There is a module A with two processes, Process_in and Process_out.

1) Process_in reads input data to the module synchronous with the main clock and using a clock enable, namely CLK_EN_IN. The frequency of this clock enable is very low compared with the main clock.

2) the data read is used in asynchronous operations (multiplications, etc...) which are not clocked.

3) Process_out reads the results of this operation with the main clock and a clock enable, CLK_OUT. The frequency of this clock enable is again very low.

I have designed everything so that CLK_IN happens let's say 100 ns before CLK_OUT, so that there is enough time to carry out the asynchronous operations. I can check the paths in TimeQuest and make sure that it's OK, but my question is very simple: what would be the right way to constraint a case like this.

I am thinking about cutting all the paths that come into Module A to avoid confusing the analyzer, and after that use set_max_delay, but I don't quite like cutting paths as that will hinder possible failures and also might change how the fitter operates in my design (which is currently working).

Thanks in advance for your help!

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    If I understood you correctly, you are using only 1 clock and two clock enables.

    Then, what you need it set_multicycle_path.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Thanks for your answer,

    I am using the multicycle command to contraint clock enables in the design, but in this particular case if I use a multicycle I must use a really high multiplication factor (the clock enable is maybe 2000 times slower than the main clock), so that will definitively pass timing. I thing that what I need is to contraint the timing BETWEEN the two clock enables, so I need some sort of outphasing.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Are both of your clock enables dividing the clock by the same factor and is the delay constant?

    If yes this is what you can do:

    Let's say that you have register regA that uses CLK_EN_IN and register regB which uses CLK_EN_OUT.

    And let's say that CLK_EN_IN *always* comes 10 clocks before CLK_EN_OUT.

    Thus, the combinatory logic you have between A and B has 10 clocks to get the job done and you can use the following constrain to tell TimeQuest about that:

    set_multicycle_path -setup -end -from [get_pins reg1|clk] -to [get_pins reg2|*] 10

    If this doesn't work out for you then you need to change your design a bit. Adding a layer of registers should suffice.

    regA -> complex combinatory logic -> regB -> regC

    regA and regB both use CLK_EN_IN, maximizing the allowed delay between regA and regB.

    regC uses CLK_EN_OUT; since there's only routing delay between regB and regC, it will achieve fast timings.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Thanks a lot!

    That was enough (along with the hold constraints) to get what I was looking for and to make sure that my comb delays were small enough. I am still not complying all the paths because I coded things in a way that I don't really have a true register input - comb logic - register output structure, but that's another issue.

    Thank you very much for your help!