Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

always_latch and non-blocking assignment #864

Closed
veripoolbot opened this issue Dec 23, 2014 · 3 comments
Closed

always_latch and non-blocking assignment #864

veripoolbot opened this issue Dec 23, 2014 · 3 comments
Assignees
@wsnyder
Labels
area: lint Issue involves SystemVerilog lint checking resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor

Author Name: Iztok Jeras (@jeras)
Original Redmine Issue: 864 from https://www.veripool.org
Original Date: 2014-12-23
Original Assignee: Wilson Snyder (@wsnyder)

Hi,

While implementing a latch (part of an input pin metastability synchronizer):

always_latch
if (clk) gpio_latch <= sleep ? '0 : gpio_pin;

I received the next warning:

%Warning-COMBDLY: rtl/rp_8bit_gpio.sv:62: Delayed assignments (<=) in non-clocked (non flop or latch) block; suggest blocking assignments (=).
%Warning-COMBDLY: Use "/* verilator lint_off COMBDLY */" and lint_on around source to disable this message.
%Warning-COMBDLY: *** See the manual before disabling this,
%Warning-COMBDLY: else you may end up with different sim results.

This might not be appropriate, since the SystemVerilog standard (section 9.2.2.3 Latched logic always_latch procedure) provides the next example:

always_latch
if(ck) q <= d;

Regards,
Iztok Jeras
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-12-24T03:14:48Z

Fixed in git towards 3.869.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2015-02-13T01:40:17Z

In 3.870.

@veripoolbot veripoolbot added area: lint Issue involves SystemVerilog lint checking resolution: fixed Closed; fixed labels Dec 22, 2019
@gezalore
Copy link
Member

gezalore commented Apr 29, 2022 •
edited

@wsnyder I think our current behaviour is incorrect or at least unhelpful with the given input in this issue.

Specifically, we will silently convert that non-blocking assignment to blocking in V3Active, which is pretty scary. (we convert NBAs to BAs in initial, final, and comb blocks as well, but at least there is a warning!

As far as execution semantics go, always_comb and always_latch are identical.

From IEEE 1800-2017:

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.

It is very unfortunate that the example in the standard uses an NBA, but we currently don't really support NBAs in combinational processes (which include always_latch), we just execute them as BAs. With that in mind I'm going to turn back on the warning in this.

(On another note, I do have a way of supporting NBAs in combinational processes, but that's for another conversation)

@gezalore gezalore reopened this Apr 29, 2022
@abukharmeh abukharmeh mentioned this issue Jan 11, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@wsnyder wsnyder

Labels
area: lint Issue involves SystemVerilog lint checking resolution: fixed Closed; fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@wsnyder @gezalore @veripoolbot