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

Identation after always* construct inside named block #330

Closed
veripoolbot opened this issue Mar 8, 2011 · 3 comments
Closed

Identation after always* construct inside named block #330

veripoolbot opened this issue Mar 8, 2011 · 3 comments

Comments

@veripoolbot
Copy link
Collaborator


Author Name: Pierre-David Pfister
Original Redmine Issue: 330 from https://www.veripool.org


Hi,

It looks like indentation is wrong after the first always_ff (I think this is also true for other types of always) inside a named block (I'm using version 665). E.g.:

module testcase;
  begin : block
     logic s1, s2;
     wire w1 = '1;
     wire w2 = '0;
     always_ff @(clk) s1 <= w1;
  always_ff @(clk) s2 <= s1; // wrong indentation
end // wrong indentation
endmodule

Thanks,
Pierre

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Pierre-David Pfister
Original Date: 2011-03-08T14:15:05Z


This is still true in 667, Pierre.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-03-09T02:59:16Z


Not that we shouldn't necessarily indent them, but "bare" begin/end blocks are a Verilog 2001 feature that were deprecated in SystemVerilog 2005.
Note if you throw it in a "generate"/"endgenerate" it works correctly.

Anyhow, up to Mac.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-11-19T13:11:39Z


Given bare end blocks are no longer standard, and there was not a patch, closing due to age.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant