Add Dockerfile

[yuqisun]

Trying to add Dockerfile for CGRA-Flow.

Environment works but 3 issues here:

1. Building with current master code, looks there's bug in add progress bar to load UI component  #62 to block CGRA rows/cols change. Should be fine as we are moving to multi-CGRA UI, but would be better if it's easy to push a fix. Hi @richardissuperman , could you have a try in your end to change rows/cols of CGRA with master code.

2. Didn't pass cmdline_opts into test_cgra_universal, pushed a fix.
   

   CGRA-Flow/mode_dark_light.py

   Lines 967 to 970 in 82fd6e7

   	cmdline_opts = {'test_verilog': 'zeros', 'test_yosys_verilog': '', 'dump_textwave': False, 'dump_vcd': False,
   	'dump_vtb': False, 'max_cycles': None}
   	test_cgra_universal(paramCGRA = paramCGRA)

3. Issue when clickSynthesize, @tancheng Have you ever seen this before, testing with fir.cpp, is it kernel error or code error?

design.name_mangled.v:733: ERROR: Unsupported expression on dynamic range select on signal `\recv_data__rdy'!
make: *** [Makefile:264: 3-open-yosys-synthesis/.execstamp] Error 1

Attached design.name_mangled.v.txt

Would like to make the single CGRA UI work, then start multi-CGRA integration in case issue will make the integration complicated to identify the root cause.

[tancheng]

3. Issue when clickSynthesize, @tancheng Have you ever seen this before, testing with fir.cpp, is it kernel error or code error?

• I thought the verilog testing won't leverage any kernel.cpp, the kernel.cpp is only used for compiler mapping. In other words, clickSynthesize should only synthesize the model CGRA.
• Did you update the VectorCGRA, so encounter this bug? I didn't see it in our old VectorCGRA version. It seems failed in following line, looks like yosys failed to handle such syntax. Yaotian and Ruihong did synthesize via Candence and Synopsys, but this open-source yosys cannot parse it (after using sv2v to convert from Sverilog to Verilog). Not sure it is sv2v's fault or yosys's fault.

recv_data__rdy[9 - in_dir_local[sv2v_cast_4(i)]+:1] = ((send_data__rdy[11 - sv2v_cast_4(i)+:1] & ~recv_blocked_vector[in_dir_local[sv2v_cast_4(i)]]) & ~recv_but_block_by_others[in_dir_local[sv2v_cast_4(i)]]) & ~send_but_block_by_others[sv2v_cast_4(i)];

After talking with GPT, I think the issue is Synopsys or Candence accepts SVerilog, and the lefthand indexing can be unrolled by them during static time; however, after sv2v and use yosys, the Verilog for loop (iterating on index i) cannot be recognized as an unrollable for loop by yosys.

---

GPT said:
The error from Yosys:

Unsupported expression on dynamic range select on signal `\recv_data__rdy'!

means that you're trying to do a dynamic part-select (a variable slice) on the left-hand side (LHS) of an assignment — something Yosys (and synthesizable Verilog in general) doesn't support.

Here's the problematic line:

recv_data__rdy[9 - in_dir_local[sv2v_cast_4(i)]+:1] = ...;

Why this fails

Verilog allows dynamic indexing (like foo[i]), but does not allow dynamic part-selects (like foo[i+:n] where i is not constant) on the LHS in a way that is compatible with synthesis — and certainly not with Yosys.

In this case, you're computing the index for a 1-bit wide dynamic slice starting at 9 - in_dir_local[...], but Yosys cannot synthesize this because it requires dynamic hardware wiring, which is not practical in hardware description.

---

How to fix

You must rewrite this assignment without a dynamic part-select on the LHS. Typically, this means rewriting it with an if statement or a case statement that covers all possible values.

If the expression 9 - in_dir_local[sv2v_cast_4(i)] can take only a small, known set of values (e.g., 0–9), you can unroll it like this:

always @* begin
  recv_data__rdy = ...; // default or previous value

  case (in_dir_local[sv2v_cast_4(i)])
    0: recv_data__rdy[9 - 0] = ...;
    1: recv_data__rdy[9 - 1] = ...;
    2: recv_data__rdy[9 - 2] = ...;
    // etc., up to the range of `in_dir_local[...]`
  endcase
end

Or, if it's inside a loop:

genvar i;
generate
  for (i = 0; i < N; i = i + 1) begin : gen_block
    wire [3:0] idx = 9 - in_dir_local[i];
    always @* begin
      recv_data__rdy[idx] = ...;
    end
  end
endgenerate

But again, this depends on the tool's capabilities. Yosys cannot handle variable bit-selects or part-selects on the LHS — it only allows constant indices.

---

Recommendation

You should convert the variable part-select into an indexed if or case assignment. Example:

integer idx;
always @* begin
  idx = 9 - in_dir_local[sv2v_cast_4(i)];
  recv_data__rdy = ...; // default assignment
  recv_data__rdy[idx] = ((send_data__rdy[11 - sv2v_cast_4(i)] & ~recv_blocked_vector[in_dir_local[sv2v_cast_4(i)]]) &
                         ~recv_but_block_by_others[in_dir_local[sv2v_cast_4(i)]]) &
                         ~send_but_block_by_others[sv2v_cast_4(i)];
end

Check whether this approach works in simulation and Yosys. If Yosys still rejects this due to indirect indexing, you'll have to fully unroll each possible case into a separate condition.

Let me know if you want help writing the unrolled version for a specific width or range.

[yuqisun]

3. Issue when clickSynthesize, @tancheng Have you ever seen this before, testing with fir.cpp, is it kernel error or code error?

• I thought the verilog testing won't leverage any kernel.cpp, the kernel.cpp is only used for compiler mapping. In other words, clickSynthesize should only synthesize the model CGRA.
• Did you update the VectorCGRA, so encounter this bug? I didn't see it in our old VectorCGRA version. It seems failed in following line, looks like yosys failed to handle such syntax. Yaotian and Ruihong did synthesize via Candence and Synopsys, but this open-source yosys cannot parse it (after using sv2v to convert from Sverilog to Verilog). Not sure it is sv2v's fault or yosys's fault.

recv_data__rdy[9 - in_dir_local[sv2v_cast_4(i)]+:1] = ((send_data__rdy[11 - sv2v_cast_4(i)+:1] & ~recv_blocked_vector[in_dir_local[sv2v_cast_4(i)]]) & ~recv_but_block_by_others[in_dir_local[sv2v_cast_4(i)]]) & ~send_but_block_by_others[sv2v_cast_4(i)];

After talking with GPT, I think the issue is Synopsys or Candence accepts SVerilog, and the lefthand indexing can be unrolled by them during static time; however, after sv2v and use yosys, the Verilog for loop (iterating on index i) cannot be recognized as an unrollable for loop by yosys.

GPT said: The error from Yosys:

Unsupported expression on dynamic range select on signal `\recv_data__rdy'!

means that you're trying to do a dynamic part-select (a variable slice) on the left-hand side (LHS) of an assignment — something Yosys (and synthesizable Verilog in general) doesn't support.

Here's the problematic line:

recv_data__rdy[9 - in_dir_local[sv2v_cast_4(i)]+:1] = ...;

Why this fails

Verilog allows dynamic indexing (like foo[i]), but does not allow dynamic part-selects (like foo[i+:n] where i is not constant) on the LHS in a way that is compatible with synthesis — and certainly not with Yosys.

In this case, you're computing the index for a 1-bit wide dynamic slice starting at 9 - in_dir_local[...], but Yosys cannot synthesize this because it requires dynamic hardware wiring, which is not practical in hardware description.

How to fix

You must rewrite this assignment without a dynamic part-select on the LHS. Typically, this means rewriting it with an if statement or a case statement that covers all possible values.

If the expression 9 - in_dir_local[sv2v_cast_4(i)] can take only a small, known set of values (e.g., 0–9), you can unroll it like this:

always @* begin
  recv_data__rdy = ...; // default or previous value

  case (in_dir_local[sv2v_cast_4(i)])
    0: recv_data__rdy[9 - 0] = ...;
    1: recv_data__rdy[9 - 1] = ...;
    2: recv_data__rdy[9 - 2] = ...;
    // etc., up to the range of `in_dir_local[...]`
  endcase
end

Or, if it's inside a loop:

genvar i;
generate
  for (i = 0; i < N; i = i + 1) begin : gen_block
    wire [3:0] idx = 9 - in_dir_local[i];
    always @* begin
      recv_data__rdy[idx] = ...;
    end
  end
endgenerate

But again, this depends on the tool's capabilities. Yosys cannot handle variable bit-selects or part-selects on the LHS — it only allows constant indices.

Recommendation

You should convert the variable part-select into an indexed if or case assignment. Example:

integer idx;
always @* begin
  idx = 9 - in_dir_local[sv2v_cast_4(i)];
  recv_data__rdy = ...; // default assignment
  recv_data__rdy[idx] = ((send_data__rdy[11 - sv2v_cast_4(i)] & ~recv_blocked_vector[in_dir_local[sv2v_cast_4(i)]]) &
                         ~recv_but_block_by_others[in_dir_local[sv2v_cast_4(i)]]) &
                         ~send_but_block_by_others[sv2v_cast_4(i)];
end

Check whether this approach works in simulation and Yosys. If Yosys still rejects this due to indirect indexing, you'll have to fully unroll each possible case into a separate condition.

Let me know if you want help writing the unrolled version for a specific width or range.

Looks need manually change the verilog, but it should be generated from RTL right?
And I didn't use the latest VectorCGRA, testing with CGRA-Flow master version and sub modules with commit hash in master. I can try with the latest VectorCGRA and Mapper, hope there's luck.

[yuqisun]

Looks same kind of issue, but change to, thinking why it works before:

design.name_mangled.v:8577: ERROR: Unsupported expression on dynamic range select on signal `\prologue_count_inport'!
make: *** [Makefile:264: 3-open-yosys-synthesis/.execstamp] Error 1
Exception in thread Thread-6 (runYosys):
Traceback (most recent call last):
  File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/root/cgra/CGRA-Flow/build/../mode_dark_light.py", line 1012, in runYosys
    statsFile = open("3-open-yosys-synthesis/stats.txt", 'r')
FileNotFoundError: [Errno 2] No such file or directory: '3-open-yosys-synthesis/stats.txt'