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

prev/prev(1) is not correctly assigned to VARs #137

Open
MartinC45 opened this issue May 13, 2024 · 2 comments
Open

prev/prev(1) is not correctly assigned to VARs #137

MartinC45 opened this issue May 13, 2024 · 2 comments

Comments

@MartinC45
Copy link

Description

Assigning .prev / .prev(1) to an OUT gives the expected result, but assigning it to a VAR doesn't. In the below example, the Verilog code has a being assigned to c directly instead of a_reg1. For higher orders, it works as expected, as shown by e.

Example

import dfhdl.*

class FirstDF() extends DFDesign:
    val a = Bit <> IN init 0
    val c = Bit <> VAR 
    val e = Bit <> VAR
    c := a.prev(1)
    e := a.prev(2)
    
    val d = Bit <> OUT init 0
    d := a.prev

@main def main = 
    FirstDF().compile

Output

module FirstDF(
  input wire logic clk,
  input wire logic rst,
  input wire logic a,
  output logic     d
);
  logic c;
  logic e;
  logic a_reg1;
  logic a_reg2;
  always @(*)
  begin
    e        = a_reg2;
    d        = a_reg1;
  end
  always @(posedge clk)
  begin
    if (rst == 1'b1) begin
      a_reg1 <= 1'b0;
      a_reg2 <= 1'b0;
      c      <= 1'b0;
    end
    else begin
      a_reg1 <= a;
      a_reg2 <= a_reg1;
      c      <= a;
    end
  end
endmodule
@MartinC45
Copy link
Author

Technically, it is correct, as c assumes the value of a one cycle later. But c is in the clocked process, which is not the case for OUT or for higher orders and a bit unexpected.

@soronpo
Copy link
Collaborator

soronpo commented May 14, 2024

In dataflow you can only assume dependency and insertion order. There are no clocks in DF. Although this could suggest something unplanned is happening there due to the different behavior, but there is no descrepency with DF rules in this example alone.

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

No branches or pull requests

2 participants