23 simulation traces are not understandable for human being

[yuqisun]

Attched log sample of VectorCGRAKingMeshRTL_test, please help review, thanks. (There may some trace logs be missed, too many, will update during developing, WDYT)

VectorCGRAKingMeshRTL_test_log.txt

Also sync changes from master.

[tancheng]

Hi @yuqisun, thanks for the PR,

+--------------+----------------+---------+------+-----+
|port_direction|     payload    |predicate|bypass|delay|
+--------------+----------------+---------+------+-----+
|     NORTH    |0000000000000000|    0    |   0  |  0  |
+--------------+----------------+---------+------+-----+

• Can we distinguish the port_direction into inport_direction and outport_direction?

outport: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
predicate_in: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

• Can we have the meaningful content inside those array? Say, outport: [N, S, -, -, ..., -]?

===>
- channel_recv:

+----------------+---------+------+-----+
|     payload    |predicate|bypass|delay|
+----------------+---------+------+-----+
|0000000000000000|    0    |   0  |  0  |
+----------------+---------+------+-----+
|0000000000000000|    0    |   0  |  0  |
+----------------+---------+------+-----+

• What is above channel_recv, is this necessary to be shown? If yes, can we provide its name?

[yuqisun]

Hi,

channel_recv is from:
[ x.recv.msg.__dict__ for x in s.channel ] <=== s.channel = [ ChannelRTL( DataType ) for _ in range( num_xbar_outports ) ] <=== num_xbar_outports = num_fu_inports + num_connect_outports.

So channel should be the lines of crossbar, channel_recv should be the inports which in green in below picture, am I correct?

And there's also channel_send: [ x.send.msg.__dict__ for x in s.channel ] which should be the outports in blue in picture?

[tancheng]

Hi,

channel_recv is from: [ x.recv.msg.__dict__ for x in s.channel ] <=== s.channel = [ ChannelRTL( DataType ) for _ in range( num_xbar_outports ) ] <=== num_xbar_outports = num_fu_inports + num_connect_outports.

So channel should be the lines of crossbar, channel_recv should be the inports which in green in below picture, am I correct?

And there's also channel_send: [ x.send.msg.__dict__ for x in s.channel ] which should be the outports in blue in picture?

Nope. Channel actually includes registers. The channel.recv is the blue one, the channel.send is the one after the yellow register. Imagine the channel as a pipe, it doesn't contain the xbar, it connects to the xbar.

[yuqisun]

How to use line_trace and verbose_trace in *_test.py

There're 2 kinds of formats of trace log:

1. line_trace: refers to a single-line trace
2. verbose_trace: prints more details, such as ctrl_mem ...

For example:
cgra/translate/VectorCGRAKingMeshRTL_test.py

def line_trace( s ):
    # verbose trace (test without verilog), uncomment below to use verbose_trace
    # verbosity = 1
    # return s.dut.verbose_trace(verbosity = verbosity)
    return s.dut.line_trace()

Note: --test-verilog mode requires line_trace always as it uses line_trace in python file which is generated by PyMTL instead of defined in VectorCGRA.

[tancheng]

• Plz sync to TOT
• Plz enable the verbosity for https://github.com/tancheng/VectorCGRA/blob/master/scale_out/RingMultiCgraRingCtrlMemRTL.py & https://github.com/tancheng/VectorCGRA/blob/master/systolic/CgraMemRightAndBottomRTL.py

Thanks!

[yuqisun]

• Plz sync to TOT

  • Plz enable the verbosity for https://github.com/tancheng/VectorCGRA/blob/master/scale_out/RingMultiCgraRingCtrlMemRTL.py & https://github.com/tancheng/VectorCGRA/blob/master/systolic/CgraMemRightAndBottomRTL.py

Thanks!

CgraMemRightAndBottomRTL good.
RingMultiCgraRingCtrlMemRTL pending on CtrlMemDynamicRTL and DataMemWithCrossbarRTL, will add tmr.

[tancheng]

Remove the unnecessary space, (keep the one before and after =).

[yuqisun]

done

[tancheng]

If this is the way to invoke the verbose_trace(), let's enable it by default for this test?

[yuqisun]

verbose_trace works for -xvs --tb=short but not --test-verilog, it looks up line_trace(), can test this with -xvs --tb=short for RingMultiCgraRingCtrlMemRTL_test.py, current is pytest --tb=short -sv ../scale_out/translate/RingMultiCgraRingCtrlMemRTL_test.py --test-verilog --dump-vtb --dump-vcd?

[tancheng]

• Then the xxx_test.py within translate/ folder can have line_trace(), while the one in test/ can have vervose_trace() enabled by default.

• Or I guess actually you can control it based on the flag?

  def line_trace(s, verbosity=0):
    if verbosity = 0:
      return s.dut.line_trace(verbosity)
    if verbosity = 1:
      return s.dut.verbose_trace(verbosity)

......

dut = Top()

if flags not contains --test-verilog:
  dut.set_param('top.x.y.z.line_trace', verbosity=1) # Or use a global variable?

[yuqisun]

Oops, you both are right, controlling by set_param is better, I should use it from the beginning.

Added a line in *_test.py th.set_param('top.dut.line_trace', verbosity = 1), will enable verbose_trace by default and when there's --test-verilog, will ignore verbose itself.

[tancheng]

Enable by default?

[yuqisun]

There're both -xvs --tb=short and --tb=short --test-verilog --dump-vtb --dump-vcd in testcases, if enable verbose_trace by default, can I remove and ignore --tb=short --test-verilog --dump-vtb --dump-vcd case in action workflow?

[yuqisun]

Make it by set_param.

[tancheng]

Hi @yuqisun, I am currently working on a huge cleanup. Plz let me merge first... So then you can sync and merge. Sorry about the inconvenience.

You can move to #44, thanks~!