h1

Parametrized Reset Values

April 19, 2009

For some odd reason some designers refuse to use parametrized blocks. I have no idea what are the reasons for such an opinion, but here is a good example why one would want to decide for the usage of parameters.

Imagine you need to design a block, which will be used several times throughout the design. The problem is, that each instance might need to have different reset values to some of its internal flops.
One (wrong) possibility is to define an extra input, which will in turn be connected as the reset value – but this is not something you’d like to do (why??)

The better option is to send the reset value as a parameter, which if it wasn’t clear by now, is the way to go.

4 comments

  1. I imagine you would not want to define an extra input because the synthesizer will need to allocate logic space for that extra input. However, if you use a parameter to define the size of a block, the synthesizer does not have to allocate extra logic for that parameter besides the actual block generation. Correct?

    I usually use parametrized blocks in my FPGA designs for block ram generation, FIFO sizes, and clock domains.


  2. On reset one can set value of the Flip Flop to 0 or 1. Reset value can not be a variable(signal).


  3. Hello, interesting article, but very small. Where can I learn more on this subject.


  4. This is a good article. I have experience with using a variable (input) as reset/set values. DC simply cannot take it. Here is a sample code:

    input var;
    input clk, rst;

    reg a;

    always @(posedge clk or posedge rst)
    if (rst)
    a <= var;
    else
    a <= #1 (other logic);

    DC is simply not sufisticated enought to handle this coding style. Here is why:

    By making a variable reset/set value, DC needs to infer a flop with both asynchronous set and reset pins (call them SET and RESET). Then depending on the value of var, it sometimes needs to assert SET (var = 1) and RESET (var = 0). DC, as far I as I know, does not like this style and the synthesis result is not what the RTL intends to give.

    Author's suggestion of using a parameter is a good one, because at DC compile time the parameter values is deterministic and there equivalent to a constant.

    The code becomes:

    parameter VAL=0;

    always @(posedge clk or posedge rst)
    if (rst)
    a <= VAL;
    else
    a <= #1 (other logic);

    when instantiating a block like this, you can use:

    `paramdef (hierarchy_path).block_inst.VAL = 1;

    to overwrite the value to infer a set (default is reset).

    Strictly speaking, the topic is on ASYNCHRONOUS set/reset. Here is a good reference on async set/reset:

    Click to access CummingsSNUG2003Boston_Resets.pdf



Leave a comment