Forum Discussion

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

timequest alt_sqrt how to choose properly signals for multicycle

Dear All,

I have in my design 2 ALT_SQRTs, which are working in time multiplex to relax the timing. The system clock is 40MHz. When I use the timequest to check for timing, of course it fails, because it claims that there is timing problem in SQRT modules, which are able to bring results in like 29 ns.

This would be fine, but as they work in time multiplex, they have relaxed timing from 25ns to 50ns. The problem is, that I have no clue how to insert the set_multicycle condition because the signals, which in timequest fail are internal to the SQRT module. When clicking right-click on the setup time to generate multicycle, it comes with command like this one:

set_multicycle_path -from {qsys_didt_firmware:NIOS_CPU|didt_master:didt_beam2|iqdemodulator:IQDEMODULATIONY|altsqrt:\SQUARES:0:altsqrt_2|_~113_OTERM2945} -to {qsys_didt_firmware:NIOS_CPU|didt_master:didt_beam2|iqdemodulator:IQDEMODULATIONY|altsqrt:\SQUARES:0:altsqrt_2|dffpipe:b_dffe[27]|sr[0][0]} -setup -end 2

(I do not put hold-time here) My obvious problem is, that I need to generalize that path such, that with single 'set_multicycle_path' I can address all the signals concerning this particular SQRT module....

how can I achieve this?

thanks

.d.

5 Replies

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

    If you mean that you have applied clock enable at half clock rate then you can apply multicycle to clock enable fanout (see altera example somewhere?)

    Remember multicycle would not apply unless you have designed to sample every two clocks by whatever way.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Yes, I've completely forgotten of timequest cookbook, where similar case is described. i'm not sure however, whether I fully understand your claim:

    "multicycle would not apply unless you have designed to sample every two clocks by whatever way"

    what is it? the way I see this multicycle thingy is, that even if one clocks a register on, say 160MHz, if you shift data into such register on 40MHz, the 40MHz timing constraints should apply, right?

    let's imagine two registers, which are clocked by 160MHz clock, but the actual rate on the data pin is 40MHz, hence data change once per 25ns while clock is 6.25ns. Now, if in between those two registers I have a combinatorial logic, which takes 15ns to propagate, is this valid for multicycle? This is kind of my problem. I do not use clock enable to 'freeze' the clock. I'm using fast clock, but with slow data...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Multicycle is very poorly understood by us all and is recipe for failure. If you are not sure do timing model simulation not just functional simulation + STA;

    Here is the scenario: If your clock is 160MHz (period = 6.25 ns) then it is not the propagation delay that decides multicycle but the edge you sample the data.

    If indeed your data changes only every 2 clocks then you need also to make sure you sample two clocks after launch. If your data changes every say 10 clocks but you sample on immediate next clock edge after transition then it is multicycle of 1 not 10.

    when you use enable to control launch and latch then that guarantees that you sample correctly for multicycle.

    When you declare multicycle there two things that result:

    1) STA is deconstrained, this is obvious

    2) less obvious is that the fitter assumes your clock is indeed clk/multicycle and hence inserts delays at its pleasure such that data transition is only correct after MC clocks. While this may not violate timing it will disturb the logic at sampling point. We then lost track of logic by this additional delay.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    allright, I have to change the design. I see the point. Basically all the registers have to physically stop operation (using clkenable) and it is not enough to slow the data stream.... that of course has some consequencies in latency. if my SQRT has latency of 4 clock cycles, using the clock enable will result in latency twice higher because SQRT is not operational every second cycle...

    interesting.

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

    --- Quote Start ---

    allright, I have to change the design. I see the point. Basically all the registers have to physically stop operation (using clkenable) and it is not enough to slow the data stream.... that of course has some consequencies in latency. if my SQRT has latency of 4 clock cycles, using the clock enable will result in latency twice higher because SQRT is not operational every second cycle...

    interesting.

    thanks

    --- Quote End ---

    Basically yes though there are some unique exceptions e.g. you can use another clock to sample data without having to stop the register in which case some edge(before sampling edge) will be violated but the sampling edge will be ok. The main point is to realise that the fitter will "look" at your multicycled path and apply deconstraint on latching register + apply full freedom to push data transition off launch register within MC periods.

    The data stream sequence will stay correct but may shift relative to sampling edge from the single MC default where you assume transition occurs within one clock period.