clock gating and internally generated clocks

[heiner-bauer]

I have a large benchmark which heavily relies on clock gating using clock gates. Now i know there is no dedicated support for clock gating in VPR (and the shipped generic FPGA architecture descriptions) but I still would want to get some area / delay results and be able to check the post-routing netlist.

Commit 6ccf516d32f3f9c30dd438950b892fd9d858a76d introduced a function to 'fix' the input netlist if a clock net occurs at a data input in an atom. First, this netlist fix does not maintain functionality as the input of the added latch is left floating. Second, this commit hides the actual problem and only generates assertions and crashes when the VPR option --gen_postsynthesis_netlist is set to 'on'.

netlist_writer.cpp:1833 double NetlistWriterVisitor::get_delay_ps(tatum::NodeId, tatum::NodeId): Assertion  'edge' failed.

Expected Behaviour

I dont know which parts of VPR can handle clock gating or routing of internally generated clocks.

But judging from the comments in pack/cluster.cpp, data pins driven by clock nets should yield a hard error.

Steps to Reproduce

See the attached BLIF netlist for a minimal example. Curiously, I can route the design if the FF for r_enable is removed (clk_i only drives the AND gate), in which case gated_clock_s becomes a global clock signal. Either way, i can not generate the post-routing netlist.

vpr_clock_gating.zip

Context

Do you have more information on the potential within VPR (architecture description, packer, routing, timing analysis) to support this user generated clock gating and potentially dedicated clock routing supported by the FPGA architecture (i.e., using global signal groups and special pack patterns)?

Your Environment

• VTR revision used: 8.0.0-dev
• Operating System and version: GNU Linux-2.6.32 x86_64
• Compiler version: GCC 4.9.4

[kmurray]

Thanks for the bug report. This is definitely an area where VPR can be improved.

I'll try and reproduce the assertion issue you found, but in the meantime here are some thoughts and potential work arounds.

Clock as Data As you noted, VPR doesn't really support clock gating, and assumes that clock's are never used as data signals (i.e. inputs to logic). 6ccf516 is a workaround to enforce that assumption (see #111 for more context).

Internally Generated Clocks VPR does support internally generated clocks, provided the primitive port is specified appropriately.

Potential work-arounds

1. If you want arbitrary clock gating, one work around would be to replace your clock gating circuitry with atom primitives, modelling the 'gated' clock as an internally generated clock:

   
   #Instantiation
   .subckt clock_gater clk=external_clock enable=clock_enable gclk=gated_clock

Definition

.model clock_gater .inputs clk enable .outputs gclk .blackbox .end

Where you configure VPR to treat ``gclk`` as a generated clock.

2. If you are only using clock gating to get an enable-able DFF, you could use a blackbox ``.subckt`` to model it:

Instantiation

.subckt dffre clk=clk resetn=restn enable=enable d=data_in q=data_out

Definition

.model dffre .inputs clk resetn enable d .outputs q .blackbox .end

**Better Clock Support in VPR**
We do plan to add global clock network modelling and routing to VPR, but there is no target yet for when this will happen.