This repository was archived by the owner on Dec 13, 2022. It is now read-only.
Do we need primitive support for registers with clock enable? #420
satnam6502
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Currently we have two types of registers:
delay, which is a unit delay, which delays every input by one cycle. It's like a D-type flip-flop with a clock input (rising or falling edge) with a reset that is asserted just once at start up (active low or active high) and never asserted again. The proofs that we perform assume this model of use.delayEnable, which is likedelaybut only reads the new value of the register state when the enable input is high. This models a clock-enable input to D-type flip-flops.Should both of these types of registers be primitives in Cava? Or can we make do with just
delayand havedelayEnabledefined just as a library circuit inCombinators.v?The experiment in the directory tests/AccumulatingAdderEnable contains two implementations of the same circuit, one using clock-enable behaviour defined explicitly with user logic (e.g. using a multiplexor) and the other uses a delay with built in clock enable functionality. The circuit is an accumulating adder which adds the current input to the current state which
enableis high.Will the Xilinix Vivado synthesis tools generate exactly the same implementation for these circuits? If yes, then we can just use
delayas the primitive and definedelayEnableas a library element. If not, then we should pickdelayEnabeas the primitive and perhaps definedelayas a special case ofdelayEnable.SystemVerilog was generated for both of these circuits and after synthesis with Xilinx Vivado this was the result:
delayand model clock-enable functionality with user-logic: 13 LUTs and 8 registers.delayEnablewith "built in" clock-enable: 8 LUTs and 8 registers.So the result is that we really should have a delay with clock-enable as a primitive because the user-defined logic version is not adequately optimized and generated a much larger circuit. I will perform a few more experiments to confirm.
Utilization report for user-defined clock-enable functionality:
Utilization report for built-in clock-enable functionality:
All reactions