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

Comb Logic order problem #1326

Closed
veripoolbot opened this issue Aug 6, 2018 · 3 comments
Closed

Comb Logic order problem #1326

veripoolbot opened this issue Aug 6, 2018 · 3 comments
Labels
resolution: abandoned Closed; not enough information or otherwise never finished

Comments

@veripoolbot
Copy link
Contributor

Author Name: Kyunghwan Cho
Original Redmine Issue: 1326 from https://www.veripool.org

When trying to compile systemverilog source, I found the following issues.

alu0_opd_update reflects the previous value of alu0_c, not the current value of alu0_c.
At verilated cpp file, I checked that the line of alu0_opd_update is before that of alu0_c.

logic alu0_c;
logic alu0_opd_update;

assign   alu0_c = (i_exe_alu0_c == 2'b00) |
               (i_exe_alu0_c == 2'b01 && status_true) | (i_exe_alu0_c == 2'b10 && ~status_true);
assign   alu0_opd_update = i_exe_alu0_update_enable & alu0_c & update_alu;

Using always_comb to enforce order of assignments, it works fine.

always_comb  begin
    alu0_c = (i_exe_alu0_c == 2'b00) |
               (i_exe_alu0_c == 2'b01 && status_true) | (i_exe_alu0_c == 2'b10 && ~status_true);

    alu0_opd_update = i_exe_alu0_update_enable & alu0_c & update_alu;
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Kyunghwan Cho
Original Date: 2018-08-06T05:25:28Z

always_comb begin 
alu0_c = (i_exe_alu0_c 2'b00) | (i_exe_alu0_c 2'b01 && status_true) | (i_exe_alu0_c == 2'b10 && ~status_true); 
alu0_opd_update = i_exe_alu0_update_enable & alu0_c & update_alu;
end

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-08-11T15:42:47Z

Verilator internally should treat assigns identically to always_comb, so probably something more complicated is going on.

Can you please make a standalone test ideally in test_regress format?

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-05-10T00:30:43Z

Didn't get more information - if you have more to go on please post.

@veripoolbot veripoolbot added the resolution: abandoned Closed; not enough information or otherwise never finished label Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
resolution: abandoned Closed; not enough information or otherwise never finished
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@veripoolbot