Flexible support for clock signal routing

[tangxifan]

Proposed Behaviour

We propose to allow users to select routing strategy for each clock signal in their design, through additional syntax in the VPR constraints.

  <vpr_constraints>
        <global_route_constraints> 
        <!-- specify route method for a global pin that needs to be connected globally --> 
                <set_global_signal name="clk0" type="clock" route_model="ideal"/> 
                <set_global_signal name="clk1" type="clock" route_model="route"/> 
                <set_global_signal name="clk2" type="clock" route_model="dedicated_network"/> 
                <set_global_signal name="reset0" type="reset" route_model="ideal"/> 
                <set_global_signal name="reset1" type="reset" route_model="route"/> 
                <set_global_signal name="reset2" type="reset" route_model="dedicated_network"/> 
        </global_route_constraints> 
  </vpr_constraints>

Current Behaviour

Currently, VPR supports three types of routing strategies for clock signals, through the command-line option --clock_modeling:

• ideal
• routing
• dedicated_network

See details in doc

However, users may want more precise control on clock signal routing. For example, we may have two types of clock signals, each of which require different routing strategies:

• Clocks as primary inputs of a netlist (driven through a dedicated network) -> Ideal or dedicated_network
• Clocks generated by internal logics, e.g., LUT. -> routing

Take the example above, a CLB may have two clocks, where

• lclk denotes a local clock, which is generated by internal logics. This clock should be routed using the --clock_modeling route method.
• glck denotes a global clock, which comes from a dedicated clock network, e.g., H-tree. This clock should not be routed. We prefer to use the --clock_modeling ideal method.

A practical application could be a Pulse Width Modulation (PWM) driven by a clock divider.

In current methodology, we cannot specify the routing strategy for each clock. As a result, the routing results may be incorrect for some FPGAs.

Possible Solution

Brain-storming is welcomed.

Context

We are trying to address our proposal in #2233

[tangxifan]

@vaughnbetz @mithro This feature is required by our FPGAs. We are actually contributing to VPR on this. We can discuss this in the next VPR meeting. Also, if you have any early comment, feel free to post. Thank you!

[vaughnbetz]

Looks like a useful feature. Suggest allowing wild cards for the signal names (matches existing vpr_constraints file parsing for placement locations/floorplanning) and generally more powerful.

[tangxifan]

@vaughnbetz Thanks for the insights. We will include this when delivering the feature.

@Tulong4Dev Please upload a detailed PRD about the feature. We need clarification with a detailed example and explain why it should be a VPR constraint. Also propose the changes on the user interface (command-line options).

[Tulong4Dev]

@vaughnbetz @tangxifan The PRD is uploaded here: Route Constraint PRD.pdf

[Tulong4Dev]

Looks like a useful feature. Suggest allowing wild cards for the signal names (matches existing vpr_constraints file parsing for placement locations/floorplanning) and generally more powerful.

@vaughnbetz wild cards for signal names had been implemented; also, mutliple constraint files are supported through "--read_vpr_constraints FILE0:FILE1:...:FILEn", it is designed to use colon ":" as separator so we can use existing vtr_token functions to do the parsing; we are open to other suggestions.

Meanwhile, there is on open issue left: How to write out constraint files if there are multiple input constraint files? We can discuss at the meeting.

[vaughnbetz]

Thanks, that sounds good. For writing out: perhaps each command to write out some set of constraints should take a filename?
You could then decide if it overwrites any existing data (so if there are multiple options to write out locations vs. clock routing constraints, they would need to write to different files). Or you could append to the existing file (allowing merging of the constraints into one file) but this could get confusing if there are old versions of the file lying around already. On balance I therefore lean toward the option of each command to write out takes a filename. You can default them to some standard filename too.

[vaughnbetz]

Can't make the meeting today, unfortunately.

[tangxifan]

Hi @vaughnbetz, no problem for us. We will keep improving the PRD and update our code changes. We can discuss in the next meeting.