Add Dockerfile by yuqisun · Pull Request #69 · tancheng/CGRA-Flow

yuqisun · 2025-05-18T16:58:16Z

Trying to add Dockerfile for CGRA-Flow.

Environment works but 3 issues here:

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.

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

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)

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 · 2025-05-18T17:26:18Z

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 · 2025-05-19T14:59:36Z

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 · 2025-05-19T16:10:10Z

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'

yuqisun · 2025-05-28T09:59:04Z

Status for now - Dynamic Arrays issue, may need help from expert to change on RTL code:

PyMTL generates system verilog
sv2v converts system verilog to verilog, doesn't support Dynamic Arrays for now - Dynamic Arrays support zachjs/sv2v#316
Tried yosys and synlig, cannot synthesis such verilog

Error:

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'

tancheng · 2025-05-28T20:54:34Z

Hi @yuqisun, I actually cannot find the corresponding pymtl code for the error. Can you please try it on latest master, and let me know the corresponding pymtl code line, and the translated SVerilog code, and the corresponding Verilog code (after sv2v)? So we can debug this?

yuqisun · 2025-05-29T14:58:53Z

Hi @tancheng ,

Tested with the latest VectorCGRA(bac978a6f30a4c4af368de15d6051cf1b74b9aeb), as per error message, pymtl code should be CrossbarRTL:

s.prologue_count_inport = [InPort(PrologueCountType) for _ in range(num_inports)]

(venv) root@f48e580d4eb5:~/cgra/CGRA-Flow/VectorCGRA# git log -1
commit bac978a6f30a4c4af368de15d6051cf1b74b9aeb (HEAD, origin/master, origin/HEAD, master)

Attach system verilog and verilog(sv2v), also sent you the zip of build and mflowgen for more details:
design.v.txt
design.name_mangled.v.txt

Error message:

**design.name_mangled.v:8577**: ERROR: Unsupported expression on dynamic range select on signal `\prologue_count_inport'!
make: *** [Makefile:271: 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'

tancheng · 2025-05-29T15:14:23Z

Hi @tancheng ,

Tested with the latest VectorCGRA(bac978a6f30a4c4af368de15d6051cf1b74b9aeb), as per error message, pymtl code should be CrossbarRTL:

s.prologue_count_inport = [InPort(PrologueCountType) for _ in range(num_inports)]

(venv) root@f48e580d4eb5:~/cgra/CGRA-Flow/VectorCGRA# git log -1
commit bac978a6f30a4c4af368de15d6051cf1b74b9aeb (HEAD, origin/master, origin/HEAD, master)

Attach system verilog and verilog(sv2v), also sent you the zip of build and mflowgen for more details: design.v.txt design.name_mangled.v.txt

Error message:

**design.name_mangled.v:8577**: ERROR: Unsupported expression on dynamic range select on signal `\prologue_count_inport'!
make: *** [Makefile:271: 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'

Thanks @yuqisun, it is this part in pymtl:
https://github.com/tancheng/VectorCGRA/blob/bac978a6f30a4c4af368de15d6051cf1b74b9aeb/noc/CrossbarRTL.py#L119-L121

Corresponding SVerilog:

always_comb begin : update_prologue_allowing_vector
  prologue_allowing_vector = 12'd0;
    for ( int unsigned i = 1'd0; i < 4'( __const__num_outports_at_update_prologue_allowing_vector ); i += 1'd1 )
      if ( in_dir[4'(i)] > 2'd0 ) begin
        prologue_allowing_vector[4'(i)] = prologue_counter[in_dir_local[4'(i)]] < prologue_count_inport[in_dir_local[4'(i)]];
      end
      else
        prologue_allowing_vector[4'(i)] = 1'd1;
end

Corresponding Verilog:

always @(*) begin : update_prologue_allowing_vector
  prologue_allowing_vector = 12'd0;
    begin : sv2v_autoblock_3
      reg [31:0] i;
      for (i = 1'd0; i < __const__num_outports_at_update_prologue_allowing_vector; i = i + 1'd1)
        if (in_dir[sv2v_cast_4(i)] > 2'd0)
          prologue_allowing_vector[sv2v_cast_4(i)] = prologue_counter[in_dir_local[sv2v_cast_4(i)]] < prologue_count_inport[(1 - in_dir_local[sv2v_cast_4(i)]) * 3+:3];
        else
          prologue_allowing_vector[sv2v_cast_4(i)] = 1'd1;
    end

tancheng · 2025-05-29T15:44:03Z

Hi @yuqisun, can you change:

          s.prologue_allowing_vector[i] @= \
              (s.prologue_counter[s.in_dir_local[i]] < \
               s.prologue_count_inport[s.in_dir_local[i]])

to

          in_dir_local_temp[i] = s.in_dir[i] - 1
          s.prologue_allowing_vector[i] @= \
              (s.prologue_counter[in_dir_local_temp[i]] < \
               s.prologue_count_inport[in_dir_local_temp[i]])

i.e., remove the s., declare the python in_dir_local_temp array inside the update block. The problem is basically related to the bit slicing (+:): [(1 - in_dir_local[sv2v_cast_4(i)]) * 3+:3], let's see how could we avoid it.

yuqisun · 2025-05-29T16:22:29Z

Hi @yuqisun, can you change:
          s.prologue_allowing_vector[i] @= \
              (s.prologue_counter[s.in_dir_local[i]] < \
               s.prologue_count_inport[s.in_dir_local[i]])
to
          in_dir_local_temp[i] = s.in_dir[i] - 1
          s.prologue_allowing_vector[i] @= \
              (s.prologue_counter[in_dir_local_temp[i]] < \
               s.prologue_count_inport[in_dir_local_temp[i]])
i.e., remove the s., declare the python in_dir_local_temp array inside the update block. The problem is basically related to the bit slicing (+:): [(1 - in_dir_local[sv2v_cast_4(i)]) * 3+:3], let's see how could we avoid it.

I tried but got below exception:

In file /root/cgra/CGRA-Flow/VectorCGRA/noc/CrossbarRTL.py, Line 119, Col 10:
  in_dir_local_temp[i] = s.in_dir[i] - 1
  ^
- tmpvar in_dir_local_temp used before assignment!

Tried changed to variable instead of list:

in_dir_local_temp = s.in_dir[i] - 1
s.prologue_allowing_vector[i] @= (s.prologue_counter[in_dir_local_temp] < s.prologue_count_inport[in_dir_local_temp])

Error:

pymtl3.passes.rtlir.errors.PyMTLTypeError:
In file /root/cgra/CGRA-Flow/VectorCGRA/noc/CrossbarRTL.py, Line 120, Col 43:
  s.prologue_allowing_vector[i] @= (s.prologue_counter[in_dir_local_temp] < s.prologue_count_inport[in_dir_local_temp])
                                   ^
- expects a 1-bit index but the given index has more (2) bits!

Changed to:

in_dir_local_temp = trunc(s.in_dir[i] - 1, NumInportType)

Looks good - generate SV good, synthesis backs to the same issue but in a new part - update_signal:

Warning: Replacing memory \fu_recv_in_rdy_vector with list of registers. See design.name_mangled.v:8307, design.name_mangled.v:8304
Warning: Replacing memory \fu__recv_in__val with list of registers. See design.name_mangled.v:8303
Warning: Replacing memory \fu__recv_in__msg with list of registers. See design.name_mangled.v:8302
Warning: Replacing memory \fu__send_out__rdy with list of registers. See design.name_mangled.v:8281
Warning: Replacing memory \fu__recv_predicate__msg with list of registers. See design.name_mangled.v:8272
Warning: Replacing memory \fu__recv_predicate__val with list of registers. See design.name_mangled.v:8270
Warning: Replacing memory \fu__recv_opt__val with list of registers. See design.name_mangled.v:8267
Warning: Replacing memory \fu__recv_opt__msg with list of registers. See design.name_mangled.v:8266
Warning: Replacing memory \fu__recv_const__val with list of registers. See design.name_mangled.v:8264
Warning: Replacing memory \fu__recv_const__msg with list of registers. See design.name_mangled.v:8263
design.name_mangled.v:8675: ERROR: Unsupported expression on dynamic range select on signal `\recv_data__msg'!
make: *** [Makefile:271: 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'

Corresponding v code (update_signal):

8634         always @(*) begin : update_signal
8635                 recv_predicate_vector = 2'd0;
8636                 send_predicate__val = 1'd0;
8637                 send_predicate__msg = 2'h0;
8638                 begin : sv2v_autoblock_10
8639                         reg [31:0] i;
8640                         for (i = 1'd0; i < __const__num_inports_at_update_signal; i = i + 1'd1)
8641                                 recv_data__rdy[1 - sv2v_cast_1(i)+:1] = 1'd0;
8642                 end
8643                 begin : sv2v_autoblock_11
8644                         reg [31:0] i;
8645                         for (i = 1'd0; i < __const__num_outports_at_update_signal; i = i + 1'd1)
8646                                 begin
8647                                         send_data__val[11 - sv2v_cast_4(i)+:1] = 1'd0;
8648                                         send_data__msg[(11 - sv2v_cast_4(i)) * 35+:35] = 35'h000000000;
8649                                 end
8650                 end
8651                 recv_opt__rdy = 1'd0;
8652                 if (recv_opt__msg[140])
8653                         send_predicate__msg = 2'h0;
8654                 if (recv_opt__val & (recv_opt__msg[146-:6] != __const__OPT_START)) begin
8655                         begin : sv2v_autoblock_12
8656                                 reg [31:0] i;
8657                                 for (i = 1'd0; i < __const__num_inports_at_update_signal; i = i + 1'd1)
8658                                         if (recv_opt__msg[48 + sv2v_cast_3(i)+:1]) begin
8659                                                 send_predicate__val = 1'd1;
8660                                                 send_predicate__msg[1] = 1'd1;
8661                                                 recv_predicate_vector[sv2v_cast_1(i)] = recv_data__msg[((1 - sv2v_cast_1(i)) * 35) + 2];
8662                                         end
8663                         end
8664                         begin : sv2v_autoblock_13
8665                                 reg [31:0] i;
8666                                 for (i = 1'd0; i < __const__num_inports_at_update_signal; i = i + 1'd1)
8667                                         recv_data__rdy[1 - sv2v_cast_1(i)+:1] = (&recv_valid_vector & &send_rdy_vector) & recv_required_vector[sv2v_cast_1(i)];
8668                         end
8669                         begin : sv2v_autoblock_14
8670                                 reg [31:0] i;
8671                                 for (i = 1'd0; i < __const__num_outports_at_update_signal; i = i + 1'd1)
8672                                         begin
8673                                                 send_data__val[11 - sv2v_cast_4(i)+:1] = &recv_valid_vector & send_required_vector[sv2v_cast_4(i)];
8674                                                 if (&recv_valid_vector & send_required_vector[sv2v_cast_4(i)]) begin
8675                                                         send_data__msg[((11 - sv2v_cast_4(i)) * 35) + 34-:32] = recv_data__msg[((1 - in_dir_local[sv2v_cast_4(i)]) * 35) + 34-:32];
8676                                                         send_data__msg[((11 - sv2v_cast_4(i)) * 35) + 2] = recv_data__msg[((1 - in_dir_local[sv2v_cast_4(i)]) * 35) + 2];
8677                                                 end
8678                                         end
8679                         end
8680                         send_predicate__msg[0] = |recv_predicate_vector;
8681                         recv_opt__rdy = &send_rdy_vector & &recv_valid_or_prologue_allowing_vector;
8682                 end
8683         end

tancheng · 2025-05-29T16:41:43Z

Hi @yuqisun, I think you need to declare in_dir_local_temp array outside the for loop, and use another for loop to assign in_dir_local_temp[i] = 0, to avoid tmpvar in_dir_local_temp used before assignment!. The reason we need the array rather than your scalar is I think the hardware should have separate in_dir_local_temp[] wires as the for loop would be unrolled and initialized into multiple wires, using single wire might be incorrect.

For the second error: design.name_mangled.v:8675: ERROR: Unsupported expression on dynamic range select on signal \recv_data__msg'!`, I think you can ignore those warnings, and this error looks exactly same reason as what you fixed, so same solution could be applied, please have a try, thanks~!

tancheng · 2025-05-29T18:40:07Z

Can you please share the updated/generated SVerilog and Verilog after you make the changes?

tancheng · 2025-05-29T18:42:32Z

Also, can you try w/o the changes, just replace --test-verilog with --test-yosys-verilog to try? Pymtl3 could directly generate Verilog (@yo96).

yuqisun · 2025-05-30T14:29:37Z

Also, can you try w/o the changes, just replace --test-verilog with --test-yosys-verilog to try? Pymtl3 could directly generate Verilog (@yo96).

Have a double check just now, it is --test-yosys-verilog now, same error. Trying your solution to change code.

 966     # pymtl function that is used to generate synthesizable verilog
 967     cmdline_opts = {'test_verilog': 'zeros', 'test_yosys_verilog': '', 'dump_textwave': False, 'dump_vcd': False,
 968                     'dump_vtb': False, 'max_cycles': None}
 969     test_cgra_universal(cmdline_opts, paramCGRA = paramCGRA)

yuqisun · 2025-05-30T14:46:48Z

Hi @yuqisun, I think you need to declare in_dir_local_temp array outside the for loop, and use another for loop to assign in_dir_local_temp[i] = 0, to avoid tmpvar in_dir_local_temp used before assignment!. The reason we need the array rather than your scalar is I think the hardware should have separate in_dir_local_temp[] wires as the for loop would be unrolled and initialized into multiple wires, using single wire might be incorrect.

For the second error: design.name_mangled.v:8675: ERROR: Unsupported expression on dynamic range select on signal \recv_data__msg'!`, I think you can ignore those warnings, and this error looks exactly same reason as what you fixed, so same solution could be applied, please have a try, thanks~!

Looks a scalar variable would be good? Let me try this solution on the other error first.

yuqisun · 2025-06-03T23:20:07Z

Hi @tancheng ,

The dynamic array issue is good now, but synthesis took more than 6 hours and didn't finish yet, paste some of the warnings below, no error message. Should we optimize the RTLs further or just wait?

...
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[0]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[1]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[2]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[3]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[4]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[5]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[6]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[7]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[8]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[9]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[10]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[11]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_wdata__rdy[0]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_wdata__rdy[1]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.

tancheng · 2025-06-03T23:29:32Z

Hi @tancheng ,

The dynamic array issue is good now, but synthesis took more than 6 hours and didn't finish yet, paste some of the warnings below, no error message. Should we optimize the RTLs further or just wait?

...
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[0]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[1]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[2]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[3]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[4]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[5]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[6]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[7]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[8]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[9]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[10]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[11]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_wdata__rdy[0]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_wdata__rdy[1]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.

What is the detailed configuration for this Verilog? Can you check whether you can see VectorAdderComboRTL or MulRTL in the verilog?

My point is can we have a tiny one to go through OpenRoad:

  topology = "Mesh"
  FuList = [AdderRTL]
  data_bitwidth = 8
  th = init_param(topology, FuList, x_tiles = 2, y_tiles = 2,
                  data_bitwidth = data_bitwidth)

Referring to: https://github.com/tancheng/VectorCGRA/blob/bac978a6f30a4c4af368de15d6051cf1b74b9aeb/cgra/test/CgraRTL_test.py#L626-L640

And these are too large.

yuqisun · 2025-06-09T15:23:46Z

Hi @tancheng ,
The dynamic array issue is good now, but synthesis took more than 6 hours and didn't finish yet, paste some of the warnings below, no error message. Should we optimize the RTLs further or just wait?

...
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[0]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[1]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[2]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[3]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[4]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[5]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[6]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[7]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[8]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[9]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[10]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_waddr__rdy[11]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_wdata__rdy[0]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.
No latch inferred for signal `\FlexibleFuRTL__834ab351a38f693d.\fu__to_mem_wdata__rdy[1]' from process `\FlexibleFuRTL__834ab351a38f693d.$proc$design.name_mangled.v:7767$95086'.

What is the detailed configuration for this Verilog? Can you check whether you can see VectorAdderComboRTL or MulRTL in the verilog?

My point is can we have a tiny one to go through OpenRoad:

  topology = "Mesh"
  FuList = [AdderRTL]
  data_bitwidth = 8
  th = init_param(topology, FuList, x_tiles = 2, y_tiles = 2,
                  data_bitwidth = data_bitwidth)

Referring to: https://github.com/tancheng/VectorCGRA/blob/bac978a6f30a4c4af368de15d6051cf1b74b9aeb/cgra/test/CgraRTL_test.py#L626-L640

And these are too large.

Hi @tancheng ,

There's no VectorAdderComboRTL and after FuList changed, no MulRTL either in the verilog.
I adjusted size below to:

  data_mem_size_global = 16
  data_mem_size_per_bank = 4

And

  cgra_id = 0
  controller2addr_map = {
          0: [0, 3],
          #1: [4, 7],
          #2: [8, 11],
          #3: [12, 15],
  }

  idTo2d_map = {
          0: [0, 0],
          #1: [1, 0],
          #2: [2, 0],
          #3: [3, 0],
  }

Still slow in processing idTo2d_x_lut and idTo2d_x_lut, do you think there is workaround to speed up it?

  1763/23311: $5\crossbar__recv__msg[1099:0] [2]
  1764/23311: $2$mem2reg_rd$\idTo2d_x_lut$design.name_mangled.v:1707$6172_DATA[1:0]$23863
  1765/23311: $2$mem2reg_rd$\idTo2d_y_lut$design.name_mangled.v:1707$5071_DATA[0:0]$22762
  1766/23311: $5\crossbar__recv__msg[1099:0] [0]
  1767/23311: $2$mem2reg_rd$\idTo2d_x_lut$design.name_mangled.v:1707$6168_DATA[1:0]$23859
  1768/23311: $2$mem2reg_rd$\idTo2d_y_lut$design.name_mangled.v:1707$5069_DATA[0:0]$22760
  1769/23311: $2$mem2reg_rd$\idTo2d_x_lut$design.name_mangled.v:1707$6170_DATA[1:0]$23861
  1770/23311: $2$mem2reg_rd$\idTo2d_x_lut$design.name_mangled.v:1707$6164_DATA[1:0]$23855
  1771/23311: $2$mem2reg_rd$\idTo2d_y_lut$design.name_mangled.v:1707$5067_DATA[0:0]$22758

Verilog:
design_sv2v.v.txt

tancheng · 2025-06-09T15:56:44Z

Hi @yuqisun, what is the target timing/frequency? 100MHz takes such long time? Can we try 10MHz? Or even 1MHz?

tancheng · 2025-06-09T16:00:52Z

@yuqisun, I have no idea about why the two lut make it slow, does gpt or deepseek can help triage by providing the .v and the dumped trace?

BTW, does 1767/23311 mean its progress just in 7.58%?

yuqisun · 2025-06-10T01:01:19Z

Hi @yuqisun, what is the target timing/frequency? 100MHz takes such long time? Can we try 10MHz? Or even 1MHz?

This is Synthesize, finally cost 16671.6 seconds (4.6 hours) to end. It is faster after I comment (previously cannot finish overnight even), so multi-cgra would cost much more time suppose:

  cgra_id = 0
  controller2addr_map = {
          0: [0, 3],
          #1: [4, 7],
          #2: [8, 11],
          #3: [12, 15],
  }

  idTo2d_map = {
          0: [0, 0],
          #1: [1, 0],
          #2: [2, 0],
          #3: [3, 0],
  }

BTW, does 1767/23311 mean its progress just in 7.58%?

Yes.

tancheng · 2025-06-10T01:04:32Z

Thanks @yuqisun, let's just use this version for the CGRA-Flow/GUI update. And let's see how long it takes for place&route.

…r consistency

- Change Docker image to cgra/cgraflow:v1 and update container name to mycgraflow in run_windows_docker.sh. - Correct import paths in mode_dark_light.py for consistency. - Add openroad_urls.txt with relevant download links for OpenROAD and related tools.

yuqisun · 2025-06-12T07:53:20Z

Hi @tancheng @ytliu74,

I ran with 20 cores machine again, the 2.2.8. Executing PROC_DLATCH pass passed quickly, but got interrupt (should be OOM) in 2.13. Executing SHARE pass (SAT-based resource sharing), have you ever encountered this?

      Model from SAT solver: { $auto$rtlil.cc:2493:Not$780370 $auto$rtlil.cc:2493:Not$780375 $and$design.name_mangled.v:7364$7579_Y \reset } = 4'1100
    Analyzing resource sharing with $memrd$\prologue_counter$design.name_mangled.v:7294$7349 ($memrd):
      Found 3 activation_patterns using ctrl signal { $auto$rtlil.cc:2493:Not$780380 $and$design.name_mangled.v:7414$8058_Y $and$design.name_mangled.v:7364$7579_Y \recv_opt__rdy \reset }.
      Forbidden control signals for this pair of cells: { $and$design.name_mangled.v:7414$8168_Y $and$design.name_mangled.v:7414$8158_Y $and$design.name_mangled.v:7414$8148_Y $and$design.name_mangled.v:7414$813./mflowgen-run: line 20:   420 Killed                  yosys -s synth.ys -l synth.log

While ran with old code(20241028 image), no warnings:

2.13. Executing SHARE pass (SAT-based resource sharing).
Found 2 cells in module ShifterRTL__cf54288ae5eea774 that may be considered for resource sharing.
  Analyzing resource sharing options for $shr$design.name_mangled.v:1242$1143 ($shr):
    Found 1 activation_patterns using ctrl signal $auto$rtlil.cc:2540:And$11864.
    No candidates found.
  Analyzing resource sharing options for $shl$design.name_mangled.v:1234$1109 ($shl):
    Found 1 activation_patterns using ctrl signal $auto$rtlil.cc:2540:And$11864.
    No candidates found.

2.14. Executing OPT pass (performing simple optimizations).

Attached logs:

log for new code:
20cores_mflowgen_make3.log
log for 20241028 code:
https://1drv.ms/u/c/a058f5f4a512f5b9/EQiAp4y5L3FJsY1P-dVbvR4BOiocmOnyI0at2Zip2vu4Zw?e=cPZfV2

Thanks,

tancheng · 2025-06-12T22:12:43Z

Hi @yuqisun, with @yo96's guidance, we suspect this part of code is the culprit:

https://github.com/tancheng/VectorCGRA/blob/bddd1d500ddd5d93d3c65710161a95979980c180/noc/CrossbarRTL.py#L120-L123

and

https://github.com/tancheng/VectorCGRA/blob/bddd1d500ddd5d93d3c65710161a95979980c180/noc/CrossbarRTL.py#L186

Basically, we don't want lhs be written with an unknown (unknown at static time) index. Let's make it a static index, but manipulate the rhs part to align the functionality. Plz try to understand those codes, and let me know if you don't understand them. TODO:

Try to simplify these two parts of codes, ignoring the functionality, just try to modify/simplify (avoid using in_dir_local[i] as index, maybe just use i) the code and re-do the synthesis, to see whether that help the synthesis time.
If it helps, try to understand the code, and let's refactor them.

yo96 · 2025-06-12T23:04:28Z

Right, I suspect that this line is going to significantly increase the problem complexity for the SAT solver and exponentially increase the run time.

s.prologue_counter[s.in_dir_local[i]] <<= s.prologue_counter[s.in_dir_local[i]] + 1

The s.in_dir_local[i] is a dynamic index that cannot be resolved statically. This means the write logic for every signal in the prologue_counter array depends on the read logic for all is.

I think it might be difficult to solve this problem through refactoring the code itself. The fundamental cause is that what you want here is equivalent to an N-entry register file with N write ports, which is not scalable and blows up the SAT solver in Yosys. We should try to come up with a better design for this part of logic.

tancheng · 2025-06-12T23:34:05Z

Thanks for the hint @yo96.
@yuqisun please try to replace the s.prologue_counter[s.in_dir_local[i]] with s.prologue_counter[i] in the two places to see whether it helps yosys, then we can make a decision. And please file an issue for this.

yuqisun · 2025-06-13T07:51:43Z

Hi experts @tancheng @yo96 ,

You are right, after setting the LHS to a static idx, the synthesis process concluded quickly (approximately 5 minutes).

I hardcoded idx to 0 as there would be bitwidth mismatch issue if set as i.

Log snippet:

   Chip area for module '\CgraTemplateRTL': 1110164.033995
     of which used for sequential elements: 197905.330000 (17.83%)

Warnings: 442 unique messages, 1586 total
End of script. Logfile hash: b256876fc2, CPU: user 115.59s system 1.67s, MEM: 1953.38 MB peak
Yosys 0.45+139 (git sha1 4d581a97d, clang++ 14.0.0-1ubuntu1.1 -fPIC -O3)
Time spent: 64% 2x abc (165 sec), 6% 96x opt_expr (15 sec), ...

Full log: https://1drv.ms/u/c/a058f5f4a512f5b9/EVd6WeWQPvtFhczvGvGYEbEBHdi4PThF1r4tVzXM1xmdLw?e=k5bzFQ

Issue raised: tancheng/VectorCGRA#148

tancheng · 2025-07-12T16:22:31Z

Hi experts @tancheng @yo96 ,

You are right, after setting the LHS to a static idx, the synthesis process concluded quickly (approximately 5 minutes).

I hardcoded idx to 0 as there would be bitwidth mismatch issue if set as i.

Log snippet:
   Chip area for module '\CgraTemplateRTL': 1110164.033995
     of which used for sequential elements: 197905.330000 (17.83%)

Warnings: 442 unique messages, 1586 total
End of script. Logfile hash: b256876fc2, CPU: user 115.59s system 1.67s, MEM: 1953.38 MB peak
Yosys 0.45+139 (git sha1 4d581a97d, clang++ 14.0.0-1ubuntu1.1 -fPIC -O3)
Time spent: 64% 2x abc (165 sec), 6% 96x opt_expr (15 sec), ...
Full log: https://1drv.ms/u/c/a058f5f4a512f5b9/EVd6WeWQPvtFhczvGvGYEbEBHdi4PThF1r4tVzXM1xmdLw?e=k5bzFQ

Issue raised: tancheng/VectorCGRA#148

Hi @yuqisun, a reminder for trying tancheng/VectorCGRA#155, thanks~!

yuqisun · 2025-11-17T16:33:42Z

Hi @tancheng ,

This Dockerfile will:

prepare env (llvm12)
clone the latest repo
build sub modules (Mapper, mflowgen, cacti, sv2v)
install python libs
install OpenRoad and yosys(0.45+139)

Dockerfile is still running in my local for testing, will merge once verified.

Thanks,

yuqisun added 14 commits May 18, 2025 00:52

Add Dockerfile. tancheng#29

aa54917

Add Dockerfile. tancheng#29

982c636

Add Dockerfile. tancheng#29

09e08ae

Add Dockerfile. tancheng#29

6d0f675

Add Dockerfile. tancheng#29

ac1bf37

Add Dockerfile. tancheng#29

78a2104

Add Dockerfile. tancheng#29

3b98e55

Add Dockerfile. tancheng#29

312ec36

Add Dockerfile. tancheng#29

9c659e3

Add Dockerfile. tancheng#29

db7d680

Add Dockerfile. tancheng#29

cb02e8f

Add Dockerfile. tancheng#29

a601e20

Use ubuntu-22.04.

77bcf20

Use ubuntu-22.04.

25f053f

yuqisun mentioned this pull request Jun 3, 2025

Workaround for sv2v Flattening Arrays into One-dimensional Vectors tancheng/VectorCGRA#147

Merged

yuqisun added 3 commits June 10, 2025 16:43

Refactor Dockerfile to use /WORK_REPO path instead of ${HOME}/cgra fo…

60f68ac

…r consistency

Temp rollback to fix no response issue. Will merge from Qing's PR.

611d103

yuqisun mentioned this pull request Jun 13, 2025

[P0] Dynamic Indexing in CrossbarRTL Causes Synthesis Issues tancheng/VectorCGRA#148

Closed

Add missing PATH for sv2v tools and clean up Dockerfile

0ac0853

tancheng assigned yuqisun Jun 20, 2025

yuqisun added 2 commits November 15, 2025 16:38

merge from the latest master

12aae10

Update dockerfile and submodule for CGRA-Flow

7b73de2

tancheng approved these changes Nov 16, 2025

View reviewed changes

Comment thread mode_dark_light.py Outdated

Comment thread mode_dark_light.py Outdated

Comment thread mode_dark_light.py

Comment thread tools/mflowgen

Comment thread CGRA-Mapper

clean code and add openroad install steps in Dockerfile

cff08df

tancheng reviewed Nov 17, 2025

View reviewed changes

Comment thread docker/config.mk Outdated

Comment thread docker/config.mk Outdated

Update Place and Route layer config and README

fedf57c

yuqisun merged commit 89f0a23 into tancheng:master Nov 18, 2025
2 checks passed

yuqisun mentioned this pull request Nov 18, 2025

Can you post the Dockerfile? #29

Closed

yuqisun mentioned this pull request Dec 1, 2025

[P1] Update sub-modules to latest version #39

Closed

	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)

Conversation

yuqisun commented May 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tancheng commented May 18, 2025

Why this fails

How to fix

Recommendation

Uh oh!

yuqisun commented May 19, 2025

Why this fails

How to fix

Recommendation

Uh oh!

yuqisun commented May 19, 2025

Uh oh!

yuqisun commented May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tancheng commented May 28, 2025

Uh oh!

yuqisun commented May 29, 2025

Uh oh!

tancheng commented May 29, 2025

Uh oh!

tancheng commented May 29, 2025

Uh oh!

yuqisun commented May 29, 2025

Uh oh!

tancheng commented May 29, 2025

Uh oh!

tancheng commented May 29, 2025

Uh oh!

tancheng commented May 29, 2025

Uh oh!

yuqisun commented May 30, 2025

Uh oh!

yuqisun commented May 30, 2025

Uh oh!

yuqisun commented Jun 3, 2025

Uh oh!

tancheng commented Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yuqisun commented Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tancheng commented Jun 9, 2025

Uh oh!

tancheng commented Jun 9, 2025

Uh oh!

yuqisun commented Jun 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tancheng commented Jun 10, 2025

Uh oh!

yuqisun commented Jun 12, 2025

Uh oh!

tancheng commented Jun 12, 2025 • edited by yo96 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yo96 commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tancheng commented Jun 12, 2025

Uh oh!

yuqisun commented Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tancheng commented Jul 12, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yuqisun commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

yuqisun commented May 18, 2025 •

edited

Loading

yuqisun commented May 28, 2025 •

edited

Loading

tancheng commented Jun 3, 2025 •

edited

Loading

yuqisun commented Jun 9, 2025 •

edited

Loading

yuqisun commented Jun 10, 2025 •

edited

Loading

tancheng commented Jun 12, 2025 •

edited by yo96

Loading

yo96 commented Jun 12, 2025 •

edited

Loading

yuqisun commented Jun 13, 2025 •

edited

Loading

yuqisun commented Nov 17, 2025 •

edited

Loading