4
\$\begingroup\$

I have the little doubt related to initializing condition in Verilog. Like in given statement:

module rf(out1,ack,en,a,f,c,d,e,clka);
  input [7:0] a,f,c,d,e;
  input clka, en;
  output reg [7:0] out1;
  output reg ack;
  reg[7:0] b[1:5];
  reg [1:0] first=0; reg [2:0] k;

initial begin
  for (k = 1; k <6; k = k + 1) begin
    b[k] = 0;
  end
end

always @(negedge clka) begin
  if (en==1) begin 
    if (first==0) begin
      first<=1;
    end
    if (first==1) begin 
      first<=2;
      b[1]<=a;            
      b[2]<=f;               
      b[3]<=c;             
      b[4]<=d;            
      b[5]<=e; 
    end
  end
end
endmodule

I initialized reg first =0 ; Is it right ? As it is giving right result after simulation but is there any problem when we will synthesize it? I used the first condition because I wanted to execute statements written within (first == 1 ) execute after one clock pulse. Is it the right way? If not then what should I do if I want to execute few statements after one or two clock pulse ? Hope I explained my confusion clearly.
P.S :

module median_five_sh(out1,ack,reset,a,f,c,d,e,clka);
input [7:0] a,f,c,d,e;
input clka,reset;
output reg [7:0] out1;
output reg ack;
reg en0,en1,en2,en3,en4,en5,en6,en7,en8,en9;
reg[7:0] b[1:5],tmp;
reg first;
reg [3:0] i1,i2,n1,k;

initial begin
            for (k = 1; k <6; k = k + 1) begin
            b[k] = 0;
            end
end

always @( posedge reset) begin 
en0<=0;en1<=0;en2<=0;en3<=0;en4<=0;en5<=0;en6<=0;en7<=0;en8<=0;en9<=0;
first<=0;
i1<=0;i2<=0;n1<=0;k<=0;
tmp=0;
end

always @(negedge clka) begin
if (reset==1) begin 
statement;
en0<=1;
en1<=1;
.
.
end
end
endmodule

The above code is simulating and giving correct output but it is giving the error after synthesis.
**Error: Signal en0 in unit .... is connected to following multiple drivers:
* I wanted to execute statements written in always @( posedge reset) only once while initially. Basically its initialization of variables used in later statment.

\$\endgroup\$
  • \$\begingroup\$ You realise that (a) b is undeclared, (b) first is set to both 2 and 0 in the always block when first == 1. \$\endgroup\$ – Tom Carpenter Apr 7 '16 at 11:16
  • \$\begingroup\$ Thanks for pointing mistake. It was typing error here only. But Can you please explain the points i want to ask? \$\endgroup\$ – RO.BST Apr 7 '16 at 11:20
6
\$\begingroup\$

Initialising the registers at declaration is perfectly synthesisable. It tells the compiler what the power-on value of the register should be. Generally the initial value for the registers is always 0 anyway, and if you choose to have them set to 1, it will basically use bubble pushing optimisations to invert the register value and still use 0 as the initial value (but as far as your logic is concerned it would effectively be 1).

However, for anything other than a data bus (qualified by some valid signal), this is not recommended. Why? because of what happens if you have a reset signal somewhere else in your logic. If half of your logic is reset at some point and you have a control signal that only has a power-on initial value and not a reset, then your two cores go out of sync - one is in in a nice known reset state, the other is in whatever unknown state it was when the reset occurred. For qualified data signals, a don't care/unknown value doesn't matter as long as the valid-like signal is reset to a known state of invalid.

The better practice is to use a reset signal for all control and valid signals to have a reset value, either synchronous or asynchronous. This eliminates the need for an initial power-on value requirement (you can still add it, but it's no longer required). The power-on value will be determined by the synthesizer based on the requested reset value.

always @ (<edge> clock or posedge reset) begin
    if (reset) begin
        //Reset value goes in here, this value also determines power-on value.
    end else ...

    end
end
\$\endgroup\$
  • 1
    \$\begingroup\$ "Initialising the registers at declaration is perfectly synthesisable" only for FPGA, I believe that ASIC does not support this. \$\endgroup\$ – pre_randomize Apr 7 '16 at 11:53
  • \$\begingroup\$ @Tom Carpenter So as you told , Generally the initial value for the registers is always 0 anyway, Can be use this 0 value as condition anywhere in code? \$\endgroup\$ – RO.BST Apr 7 '16 at 11:58
  • \$\begingroup\$ @RO.BST I wouldn't rely on that. Use a reset signal for your flip flops, either synchronous or asynchronous. That way you guarantee what state they are in after a reset condition. For simulation you can assert the reset for a couple of cycles at the beginning of the simulation. \$\endgroup\$ – Tom Carpenter Apr 7 '16 at 12:49
1
\$\begingroup\$

It's generally poor practice to rely on that kind of initialization in synthesized logic. For one thing, the initialization — if it supported at all — only applies immediately after power-up configuration of the FPGA. This generally only works on SRAM-based FPGAs; other technologies don't support power-up initialization at all.

It is much better to have an explicit reset input to every module that puts everything into a known state, and this reset can be generated by any number of conditions, including power-up, a manual reset button, or various internal error condition detectors.

\$\endgroup\$
  • \$\begingroup\$ My understanding was that this was the preferred method for FPGA< I have an ASIC background and was strongly against it but slowly was convinced by others. Mainly my current understanding is that on FPGA flip-flops with async resets are not that common or at least a limited resource. \$\endgroup\$ – pre_randomize Apr 7 '16 at 11:52
  • \$\begingroup\$ @pre_randomize: FPGAs have FFs with reset inputs, but that isn't the mechanism that is used for implicit power-up initialization. Those reset inputs are what are used when you explicitly specify an asynchronous reset in your behavioral code. \$\endgroup\$ – Dave Tweed Apr 7 '16 at 11:56
  • \$\begingroup\$ I think that was my point, using initial, you specify power-up initialization. Using async reset you need all flip-flops to have an async reset. It will depend on the FPGA but flip-flops without the async reset are present in higher numbers? \$\endgroup\$ – pre_randomize Apr 7 '16 at 12:30
  • \$\begingroup\$ "It is much better to have an explicit reset input" are you implying sync resets? \$\endgroup\$ – pre_randomize Apr 7 '16 at 12:30
  • 2
    \$\begingroup\$ @pre_randomize: I personally prefer synchronous resets. However, there is a lot of code out there that uses asynchronous resets. With async resets, you need to pay attention to the reset recovery time WRT the clock. Most of the time, it's a non-issue, but there are some circumstances in which it will bite you. \$\endgroup\$ – Dave Tweed Apr 7 '16 at 12:35
0
\$\begingroup\$

Yes, It is completely legal to initialise the registers to a value if your RTL targets FPGA, like the others have pointed out. Initial blocks too, aren't synthesizable in ASIC flow. The initialization values will become a part of the bitstream file(If you are used to Xilinx terms), and will be loaded when 'Configuring' the FPGA. As a matter of fact Xillinx recommends against adding an explicit reset, since the reset signal has to be routed to all your logic. But if you plan to port it to an ASIC later then adding a reset(preferably synchronous) is a must.

I couldn't help but notice you are using two separate always blocks for a register. That's why your synthesis tool is complaining of multiple drivers.An always block synthesizes into a flop/latch(if you are describing sequential logic), with the logic inside the always block used for determining the D-input (& rst) for the flop. Also tmp is assigned with blocking assignment. It is generally said to be a bad idea to mix blocking and non blocking assignment in the same always block.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.