`always_comb` allows `<=`, `always_ff` allows `=`

[hughperkins]

If I run sv2v on:

module foo(input clk, input a, input b, output reg c, output reg d);
    always_comb begin
        c <= a;
    end

    always_ff @(posedge clk) begin
        d = b;
    end
endmodule

I would expect errors because:

• usnig <= inside always_comb
• always_ff doesn't contain even a single <=

Yet, sv2v compiles quite happily.

Personally, I feel one of the major benefits of systemverilog is the protections of using always_comb, and always_ff, however sv2 currently, yes, accepts always_comb and always_ff as valid syntax, but doesn't run the checks that the systemverilog standard requires.

[zachjs]

I would expect errors because:

• usnig <= inside always_comb
• always_ff doesn't contain even a single <=

sv2 currently, yes, accepts always_comb and always_ff as valid syntax, but doesn't run the checks that the systemverilog standard requires.

Assuming you're referring to the two bullets above, can you help me understand where in the standard these checks are defined/required? I've heard of these usages being unusual or frowned-upon, but I'm not aware of language in the standard which forbids them.

You may also be interested in -e always, which can exclude the conversion of always_* should your downstream tool support them directly.

[hughperkins]

You may also be interested in -e always, which can exclude the conversion of always_* should your downstream tool support them directly.

I mean, the point of using sv2v would be to be able to use a tool which doesn't understand systemverilog :)

As far as the standard. Hmmm. Well... yes, looks like you are right for always_comb. 1800-2017 even provides using <= in an always_comb as an example of correct usage :)

It does say:

"Software tools should perform additional checks to warn if the behavior within an always_comb procedure does not represent combinational logic, such as if latched behavior can be inferred."

Do you know if sv2v does such checks?

section 9.2.2.2.2, I confess I don't understand. It says "Statements in an always_comb shall not include those that block". I must be mis-understanding. I thought statements that block are things like "a = b;" ? (which are statement we usually wnat in combinatorial always blocks; and are also given in one of the examples for always_comb)

For always_ff, section 9.2.2.4 says:

"Software tools should perform additional checks to warn if the behavior within an always_ff procedure does not represent sequential logic."

I'm fairly sure my always_ff block above would violate such a check?

[hughperkins]

Hmmm, actually, I suppose my always_ff is actually sequential, by virtue of only running on the posedge? I'm trying to think of an example, that uses posedge, that is somehow not sequential. I'm not sure how that would look actually?