Questions on Bridging to VectorCGRA

[n0thingNoob]

@Jackcuii

[Jackcuii]

Thanks Yijia for creating this channel, I will update some questions here soon. 😃

[Jackcuii]

Hi Sir Tan @tancheng 🤠
I have some questions on VectorCGRA signals.

1. How do we represent the constants in the VectorCGRA signal?
2. It seems that some ops in neura are not in VectorCGRA(e.g. fadd_fadd), maybe we should find a way to solve it. (And if we try to hack this gap, then it will mess up the cycles of each op)

Thanks ❤️ ~

[tancheng]

Hi Sir Tan @tancheng 🤠 I have some questions on VectorCGRA signals.

1. How do we represent the constants in the VectorCGRA signal?
2. It seems that some ops in neura are not in VectorCGRA(e.g. fadd_fadd), maybe we should find a way to solve it. (And if we try to hack this gap, then it will mess up the cycles of each op)

Thanks ❤️ ~

• An op has constant as operand, we have const in the op's naming (phi vs. phi_const):

  VectorCGRA/cgra/test/CgraRTL_fir_test.py

  Line 526 in 4f25ca7

  ctrl = CtrlType(OPT_PHI_CONST,

  • We don't have standalone constant operation yet, all constant operand should be embedded in the corresponding consumer operation, which is done by --fold-constant.
  • We preload the constant into a register for the phi_const to consume it:

    VectorCGRA/cgra/test/CgraRTL_fir_test.py

    Line 505 in 4f25ca7

    IntraCgraPktType(0, 1, payload = CgraPayloadType(CMD_CONST, data = DataType(kSumInitValue, 1))),

• We can support "limited" fused op now in VectorCGRA, but I would suggest we start from non-fused kernel/ops as first step? And I suggest we start from integer data type before trying out floating-point (we can either modify the source C++/mlir kernel for data type change, or replace FADD with ADD in the generated instructions.yaml)

How does this sound? Let me know anything is not clear to you.

[Jackcuii]

Got it~ Then I just ignore the fused op for now~

[Jackcuii]

Hi Sir Tan @tancheng 🤠 I came across this bug when I run the test, is it something wrong with the version of my env? or is there any recommended version for running it? Thanks~

(vecCGRA) jackcui@JcUbuntu:~/Arch/Validation_CaseStudy/VectorCGRA$ pytest cgra/test/CgraRTL_fir_test.py -xvs --tb=short --test-verilog --dump-vtb --dump-vcd
============================= test session starts ==============================
platform linux -- Python 3.7.12, pytest-7.4.4, pluggy-1.2.0 -- /home/jackcui/anaconda3/envs/vecCGRA/bin/python3.7
cachedir: .pytest_cache
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/home/jackcui/Arch/Validation_CaseStudy/VectorCGRA/.hypothesis/examples')
rootdir: /home/jackcui/Arch/Validation_CaseStudy/VectorCGRA
configfile: pytest.ini
plugins: hypothesis-6.79.4, pymtl3-3.1.13
collected 5 items                                                              

cgra/test/CgraRTL_fir_test.py::test_homogeneous_4x4_fir_combinational_mem_access_terminate FAILED

=================================== FAILURES ===================================
_________ test_homogeneous_4x4_fir_combinational_mem_access_terminate __________
cgra/test/CgraRTL_fir_test.py:2608: in test_homogeneous_4x4_fir_combinational_mem_access_terminate
    sim_fir_vector_terminate(cmdline_opts, mem_access_is_combinational = True)
cgra/test/CgraRTL_fir_test.py:1980: in sim_fir_vector_terminate
    th = config_model_with_cmdline_opts(th, cmdline_opts, duts = ['dut'])
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/stdlib/test_utils/test_helpers.py:129: in config_model_with_cmdline_opts
    top = VerilogTranslationImportPass()( top )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/verilog/VerilogTranslationImportPass.py:35: in __call__
    top.apply( c.get_translation_pass()() )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/dsl/Component.py:530: in apply
    pass_instance( s )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/verilog/translation/VerilogTranslationPass.py:109: in __call__
    s.traverse_hierarchy( top )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/verilog/translation/VerilogTranslationPass.py:205: in traverse_hierarchy
    s.traverse_hierarchy( child )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/verilog/translation/VerilogTranslationPass.py:134: in traverse_hierarchy
    s.translator.translate( m, m.get_metadata( c.translate_config ) )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/RTLIRTranslator.py:64: in translate
    s.clear( tr_top, tr_cfgs )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/RTLIRTranslator.py:28: in clear
    super().clear( tr_top )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/behavioral/BehavioralTranslatorL5.py:23: in clear
    super().clear( tr_top )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/behavioral/BehavioralTranslatorL1.py:26: in clear
    s.gen_behavioral_trans_metadata( tr_top )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/behavioral/BehavioralTranslatorL2.py:29: in gen_behavioral_trans_metadata
    super().gen_behavioral_trans_metadata( tr_top )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/behavioral/BehavioralTranslatorL1.py:40: in gen_behavioral_trans_metadata
    s._gen_behavioral_trans_metadata( tr_top )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/behavioral/BehavioralTranslatorL5.py:42: in _gen_behavioral_trans_metadata
    s._gen_behavioral_trans_metadata( child )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/behavioral/BehavioralTranslatorL5.py:42: in _gen_behavioral_trans_metadata
    s._gen_behavioral_trans_metadata( child )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/behavioral/BehavioralTranslatorL5.py:42: in _gen_behavioral_trans_metadata
    s._gen_behavioral_trans_metadata( child )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/backends/generic/behavioral/BehavioralTranslatorL5.py:31: in _gen_behavioral_trans_metadata
    m.apply( BehavioralRTLIRGenL5Pass( s.tr_top ) )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/dsl/Component.py:530: in apply
    pass_instance( s )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/rtlir/behavioral/BehavioralRTLIRGenL1Pass.py:70: in __call__
    upblk = visitor.enter( blk, upblk_info[-1] )
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/rtlir/behavioral/BehavioralRTLIRGenL1Pass.py:108: in enter
    ret = s.visit( ast )
../../../anaconda3/envs/vecCGRA/lib/python3.7/ast.py:271: in visit
    return visitor(node)
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/rtlir/behavioral/BehavioralRTLIRGenL1Pass.py:140: in visit_Module
    ret = s.visit( node.body[0] )
../../../anaconda3/envs/vecCGRA/lib/python3.7/ast.py:271: in visit
    return visitor(node)
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/rtlir/behavioral/BehavioralRTLIRGenL1Pass.py:163: in visit_FunctionDef
    ret.body.append( s.visit( stmt ) )
../../../anaconda3/envs/vecCGRA/lib/python3.7/ast.py:271: in visit
    return visitor(node)
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/rtlir/behavioral/BehavioralRTLIRGenL1Pass.py:192: in visit_AugAssign
    value = s.visit( node.value )
../../../anaconda3/envs/vecCGRA/lib/python3.7/ast.py:271: in visit
    return visitor(node)
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/rtlir/behavioral/BehavioralRTLIRGenL2Pass.py:214: in visit_IfExp
    cond = s.visit( node.test )
../../../anaconda3/envs/vecCGRA/lib/python3.7/ast.py:271: in visit
    return visitor(node)
../../../anaconda3/envs/vecCGRA/lib/python3.7/site-packages/pymtl3/passes/rtlir/behavioral/BehavioralRTLIRGenL2Pass.py:174: in visit_BoolOp
    'Boolean operations are not translatable due to inconsistent semantics '
E   pymtl3.passes.rtlir.errors.PyMTLSyntaxError: 
E   In file /home/jackcui/Arch/Validation_CaseStudy/VectorCGRA/_lambda__s_dut_tile_0__element_fu_12__reduce_add_in__0_, Line 2, Col 13:
E     s.reduce_add.in_[i] @= lambda: (s.temp_result[i]
E                 ^
E   - Boolean operations are not translatable due to inconsistent semantics between Python and PyMTL. Please consider using bitwise &, |, and ~ instead!
!!!!!!!!!!!!!!!!!!!!!!!!!! stopping after 1 failures !!!!!!!!!!!!!!!!!!!!!!!!!!!
============================== 1 failed in 7.48s ===============================

My pip list

Package             Version
------------------- ---------
attrs               24.2.0
bleach              6.0.0
certifi             2025.10.5
cffi                1.15.1
charset-normalizer  3.4.4
cryptography        45.0.7
docutils            0.20.1
exceptiongroup      1.3.0
greenlet            3.1.1
hypothesis          6.79.4
idna                3.10
importlib-metadata  6.7.0
importlib-resources 5.12.0
iniconfig           2.0.0
jaraco.classes      3.2.3
jeepney             0.9.0
keyring             24.1.1
markdown-it-py      2.2.0
mdurl               0.1.2
more-itertools      9.1.0
packaging           24.0
pip                 24.0
pkginfo             1.10.0
pluggy              1.2.0
py                  1.11.0
py-markdown-table   0.4.0
pycparser           2.21
Pygments            2.17.2
pymtl3              3.1.13
pytest              7.4.4
readme-renderer     37.3
requests            2.31.0
requests-toolbelt   1.0.0
rfc3986             2.0.0
rich                13.8.1
SecretStorage       3.3.3
setuptools          68.0.0
six                 1.17.0
sortedcontainers    2.4.0
tomli               2.0.1
twine               4.0.2
typing_extensions   4.7.1
urllib3             2.0.7
webencodings        0.5.1
wheel               0.41.3
zipp                3.15.0

[tancheng]

You don't need to translate, so you can just use:

pytest cgra/test/CgraRTL_fir_test.py -sv --tb=short

But maybe there is some bug due to the translation for s.reduce_add.in_[i] @= lambda: (s.temp_result[i]. Which pymtl you are using? Is that this one?

VectorCGRA/.github/workflows/python-package.yml

Line 53 in 4f25ca7

pip install -U git+https://github.com/tancheng/pymtl3.1@yo-struct-list-fix

[Jackcuii]

You don't need to translate, so you can just use:

pytest cgra/test/CgraRTL_fir_test.py -sv --tb=short

But maybe there is some bug due to the translation for s.reduce_add.in_[i] @= lambda: (s.temp_result[i]. Which pymtl you are using? Is that this one?

VectorCGRA/.github/workflows/python-package.yml

Line 53 in 4f25ca7
pip install -U git+https://github.com/tancheng/pymtl3.1@yo-struct-list-fix

Yep~ I followed the configuration instructions in the README

[tancheng]

You don't need to translate, so you can just use:

pytest cgra/test/CgraRTL_fir_test.py -sv --tb=short

But maybe there is some bug due to the translation for s.reduce_add.in_[i] @= lambda: (s.temp_result[i]. Which pymtl you are using? Is that this one?
VectorCGRA/.github/workflows/python-package.yml
Line 53 in 4f25ca7
pip install -U git+https://github.com/tancheng/pymtl3.1@yo-struct-list-fix

Yep~ I followed the configuration instructions in the README

Sounds like my command works for you? I also suggest you to comment out the unrelated tests and only keep

VectorCGRA/cgra/test/CgraRTL_fir_test.py

Line 2601 in 2fa0724

def test_homogeneous_4x4_fir_combinational_mem_access_return(cmdline_opts):

for your test/development.

[Jackcuii]

This command works well, thanks~~

[Jackcuii]

Hi Sir Tan 😃 I have a question about the . Does VectorCGRA support not fully-synchronized instructions, which means if the data is not ready, then stall and wait? Since the fir kernel is now the rewritten version and the exact cycle is not respected when we write them.

[tancheng]

Does VectorCGRA support not fully-synchronized instructions, which means if the data is not ready, then stall and wait?

Yes. Current test already shows such behavior. We send specific ctrl signals to each tile, then send out 8 LAUNCH to 8 tiles (we only need 8 out of 16 for my hand-written test). 8 tiles receives the LAUNCH at different cycles so they start asynchronously.

the fir kernel is now the rewritten version and the exact cycle is not respected when we write them.

Can you elaborate on this?

[Jackcuii]

Yes. Current test already shows such behavior. We send specific ctrl signals to each tile, then send out 8 LAUNCH to 8 tiles (we only need 8 out of 16 for my hand-written test). 8 tiles receives the LAUNCH at different cycles so they start asynchronously.

Cool!

Can you elaborate on this?

Sure~ I mean the YAML I use now actually does not fill any nop to the instructions sequence, so all the insts are actually just waiting for data and make progress 😃

We do not have these:

# NAH.
          IntraCgraPktType(0, 0,
                           payload = CgraPayloadType(CMD_CONFIG, ctrl_addr = 2,
                                                     ctrl = CtrlType(OPT_NAH,
                                                                     fu_in_code,
                                                                     [TileInType(0), TileInType(0), TileInType(0), TileInType(0),
                                                                      TileInType(0), TileInType(0), TileInType(0), TileInType(0)],
                                                                     [FuOutType(0), FuOutType(0), FuOutType(0), FuOutType(0),
                                                                      FuOutType(0), FuOutType(0), FuOutType(0), FuOutType(0)]))),

And the cycle info is actually lost

[Jackcuii]

Oh I have another question about the signals is that:
I am not quite sure about these signals:

          IntraCgraPktType(0, 0,
                           payload = CgraPayloadType(CMD_CONFIG_PROLOGUE_ROUTING_CROSSBAR, ctrl_addr = 0,
                                                     ctrl = CtrlType(routing_xbar_outport = [
                                                        TileInType(0), TileInType(0), TileInType(0), TileInType(0),
                                                        TileInType(0), TileInType(0), TileInType(0), TileInType(0)]),
                                                     data = DataType(1, 1))),
          IntraCgraPktType(0, 0,
                           payload = CgraPayloadType(CMD_CONFIG_PROLOGUE_FU_CROSSBAR, ctrl_addr = 0,
                                                     ctrl = CtrlType(fu_xbar_outport = [
                                                        FuOutType(0), FuOutType(0), FuOutType(0), FuOutType(0),
                                                        FuOutType(0), FuOutType(0), FuOutType(0), FuOutType(0)]),
                                                     data = DataType(1, 1))),
          IntraCgraPktType(0, 0,
                           payload = CgraPayloadType(CMD_CONFIG_PROLOGUE_FU_CROSSBAR, ctrl_addr = 1,
                                                     ctrl = CtrlType(fu_xbar_outport = [
                                                        FuOutType(0), FuOutType(0), FuOutType(0), FuOutType(0),
                                                        FuOutType(0), FuOutType(0), FuOutType(0), FuOutType(0)]),
                                                     data = DataType(1, 1))),

Thanks~

[tancheng]

Yes. Current test already shows such behavior. We send specific ctrl signals to each tile, then send out 8 LAUNCH to 8 tiles (we only need 8 out of 16 for my hand-written test). 8 tiles receives the LAUNCH at different cycles so they start asynchronously.

Cool!

Can you elaborate on this?

Sure~ I mean the YAML I use now actually does not fill any nop to the instructions sequence, so all the insts are actually just waiting for data and make progress 😃

We do not have these:

# NAH.
          IntraCgraPktType(0, 0,
                           payload = CgraPayloadType(CMD_CONFIG, ctrl_addr = 2,
                                                     ctrl = CtrlType(OPT_NAH,
                                                                     fu_in_code,
                                                                     [TileInType(0), TileInType(0), TileInType(0), TileInType(0),
                                                                      TileInType(0), TileInType(0), TileInType(0), TileInType(0)],
                                                                     [FuOutType(0), FuOutType(0), FuOutType(0), FuOutType(0),
                                                                      FuOutType(0), FuOutType(0), FuOutType(0), FuOutType(0)]))),

And the cycle info is actually lost

VectorCGRA/cgra/test/CgraRTL_fir_test.py

Line 952 in 2fa0724

IntraCgraPktType(0, 0, payload = CgraPayloadType(CMD_CONFIG_COUNT_PER_ITER, data = DataType(kCtrlCountPerIter, 1))),

I simply send 4 to all tiles indicating all of them have 4 ctrl signals.

VectorCGRA/cgra/test/CgraRTL_fir_test.py

Line 864 in 2fa0724

kCtrlCountPerIter = 4

So i have to provide NAH. If you don't provide NAH, you need to send 1/2/3/4 to specific tile accordingly.