what will be the logic inferred for the below code
always_ff @(posedge clk)
begin
if(enable)buffer[address] <= data_in;
end
will it infer any latch, what will happen when the enable=0 ?
In reply to svishnu:
what will be the logic inferred for the below code
always_ff @(posedge clk)
begin
if(enable)buffer[address] <= data_in;
end
will it infer any latch, what will happen when the enable=0 ?
It will infer a memory with one entry updated at the clock edge if enable==1.
For a true asynchronous latch:
always_latch
begin
if(enable)buffer[address] <= data_in;
end
// Note:
always_latch @(posedge clk)
|
..(testbench.sv,8|16): Event control illegal within an always_latch construct.
Below are paragraphs from 1800 that clearly explains the restrictions.
9.2.2.3 Latched logic always_latch procedure
SystemVerilog also provides a special always_latch procedure for modeling latched logic behavior. For example:
always_latch
if(ck) q <= d;
The always_latch construct is identical to the always_comb construct except that software tools should perform additional checks and warn if the behavior in an always_latch construct does not represent latched logic, whereas in an always_comb construct, tools should check and warn if the behavior does not represent combinational logic. All statements in 9.2.2.2 shall apply to always_latch.
9.2.2.4 Sequential logic always_ff procedure
The always_ff procedure can be used to model synthesizable sequential logic behavior. For example:
always_ff @(posedge clock iff reset == 0 or posedge reset) begin
r1 <= reset ? 0 : r2 + 1;
...
end
The always_ff procedure imposes the restriction that it contains one and only one event control and no blocking timing controls. Variables on the left-hand side of assignments within an always_ff procedure, including variables from the contents of a called function, shall not be written to by any other process.
Software tools should perform additional checks to warn if the behavior within an always_ff procedure does not represent sequential logic.
In reply to ben@SystemVerilog.us:
An intersting note on the always_latch:
1800 says “tools should perform additional checks”, and not “must”.
The following code with a few tools in EdaPlayground show that the warning is a NYI (Not Yet Implemented), a disappointment.
"In an always_comb construct, tools should check and warn if the behavior does not
represent combinational logic. "
always_latch
begin
if(clk) b = c;
else b =0; // combinational!!!
end
// Assertion in code intentionally wrong
Inputs from colleagues:
‘should’ is correct. It is a recommendation.
In this case, for example, a simulator is required to simulate. It is not required to synthesize or decide whether or not a construct is combinational. That requires more sophisticated internal programming that a simulator is not required to contain.
Besides that, the definition of latch and combinational is not defined by the LRM. There are corner cases, for example, where one tool will call it a latch and other will say it is combinational.