3

I have design consisting of several interconnected modules. The TimeQuest complains about timing violations, and it is correct in its complaints. The paths it highlights must be out of the optimization, marked as false paths. The lower level module under consideration has a register, it goes through set of multipliers and other logic, the goes out of the lower level module to top module, muxed, then registered and then connected to the bidirectional pin (the fact that there's a register in top-level module makes difference). TQ wants to mark false path from that register up to the wires looking out of the chip. I want to design .sdc file for lower level module only, constraining from register to the output of this lower level module only, and not farther. The rationale is if I will be using this lower level module in other design I will already have module-specific constraint false-pathing the route from register of the module to its output (and if needed, will put more constraints into upper module .sdc file).

But I can't find a way how to do it. Whatever set_false_path arguments I put, I am unable to select output wires (and logic before them) going out of the lower level module.

Let's say, lower level module has register

reg [5:0] my_register;

the there's some logic and embedded functions, and at the end there's

assign output_wires[7:0] = result_for_my_register[7:0];

and this is declared as port for the module

module my_module (
...
output wire [7:0] output_wires,
...
);

How do I tell Quartus/TQ to false the path from my_register to output_wires within this my_module module?

Update 1: thinking further about the issue I concluded that in this lower level module has unregistered output, the target latching register is located in the top-level module, but I can constrain only between registers. Therefore the task seems to be to constrain the register my_register with the -to option wildcarded. Am I correct?

Like this:

set_false_path -from [get_registers {my_module|my_register[*]}] -to [get_registers {*}]

But this technique seems not correct falsing all the paths from my_register, while I want to false only path going through output_wires... and I am so far unsuccessful with -through clause for the set_false_path...

Update 2:

set_false_path -from [get_registers {my_module|my_register[*]}] -through [get_nets {my_module|output_wires[*]*}] -to [get_registers {*}]

seems to do a job, but I am not sure if the result is appropriate. Please advise.

Update 3: To make false path working within this module I can introduce latching register at the output of this module, therefore module's output will become registered. But I do not need this register spending on its flip-flops and rouing.

Anonymous
  • 6,908
  • 1
  • 14
  • 41
  • I am not sure to understand. Is your signal output_wire connected to an output pin of the FPGA? –  Jan 13 '23 at 11:00
  • no, it is being latched to some other register and then routed outside. There's definitely a register for this set of wires in the top level module. But you raised another issue. If I design the way as laid out on my second update and connect output_wire directly to the unregistered output or bidir pin, rule will be discarded. – Anonymous Jan 13 '23 at 12:07
  • I don't understand why you are false-pathing what sound to be true paths – user253751 Jan 13 '23 at 12:16
  • Because I do not *need* optimization on this path and TQ complains that there's a violation. Thus primary goal is to remove warning by properly constraining the design. – Anonymous Jan 13 '23 at 12:39
  • 1
    @Anonymous what do you have in mind by "I do not need optimization on this path", is it retiming? –  Jan 13 '23 at 21:41
  • As there is a mux in the top module and you use a tristate, I think you should get an approach by constraining from top level on this path. I am not sure I understand the whole context of your goal –  Jan 13 '23 at 21:46
  • 1
    (1) "I do not need optimization on this path" - there's no need to restrict the path to fit into single clock cycle, even two clock cycles and even some more. The device connected to FPGA has significant delay and instead of forcing Quartus trying to optimize this path for best result having minimal violations I do not want it to focus on this path at all and focus on other, more important paths. (2) register `my_register` is located in `my_module` module, and problematic path is from this module to top level module, not the other way round. – Anonymous Jan 14 '23 at 08:59

0 Answers0