Forum Discussion

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

case analysis and false path issues

Hi,

Is there any feature called case analysis in Quartus2 9.0 edition which allows to select specific path to be considered among three paths going through the 2:1 mux?

My design has a cell in the Data Required Path consisting of two flip-flops and a mux with outputs of two FFs connected to inputs of the 2:1 mux and select signal is the clock driving the the flip-flops.

The fitter/TimeQuest selects the path through the muxsel instead of through the data inputs resulting in negative slack in accordance with the Data Arrival Path.

I tried using set_false_path through the muxsel pin but it didn't help.

Is there anyway the tool selects the other path but not the path through muxsel?

Any help in this regard is appreciated.

3 Replies

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

    There is no Case Analysis, but from my understanding, that's not what you want. Basically the select line of the mux is not what you want analyzed, so you want a False Path on it. Be sure to apply it using the get_pins option(use the Name Finder) and the -through. That should work.

    That being said, when the clock drives the select of the mux, you've basically got a double-data rate output going. I don't know if this architecture is in the I/O or the fabric, but in general I would argue that the clock change is relevant, since it's what causes the data value to change. In fact, the devices that have DDR registers in their I/O cells, the delays are creates such that the ONLY thing that matters is the clock through the mux select. This makes the output glitch-free.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thank you for the response.

    I agree with you that the false path should work and the cell is a DDIOOUTCELL.

    The tool (TimeQuest) does recognize the the pins and command "set_false_path -through [get_pins {path to muxsel}] " in the sdc constraint file but the element muxsel still shows up in timing report of Data Required Path. What am I missing here?

    Also, I added the constraint in the sdc file that the launch clock and latch clock which are of two different domains are a specific max. delay apart. The negative slack still shows up.

    Please correct me if I am wrong anywhere.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Open the word document at and look at page 18, Dedicated DDR Output:

    http://www.alteraforum.com/forum/showthread.php?t=4806&highlight=source+synchronous

    You can see how the clock path is the ONLY relevant path through the DDR cell. That document was written a long time ago, and I think TimeQuest now automatically puts a false path on the registers(behind the scenes) so you only see the clock path through it. That is good, as the registers change doesn't cause the output to change, and instead it's the select path that you want.

    This is a thing called "Clock as Data", whereby the source clock doesn't feed the clock of the source register, and instead directly feeds the D input(or any input besides the clock) fo the destination register. It still might not meet timing, but the path sounds correct.