[P1] Support for GEP Operand

[Jackcuii]

Seems we need to support GEP(2opr), GEP_CONST(2opr) and GEP(3opr), GEP_CONST(3opr).

Hi Sir Tan @tancheng is someone available now? or maybe I can work on it to accelerate the iteration.

[tancheng]

Sure, plz do. You plan looks good to me. You (or codex/gemini/claude) can follow https://github.com/tancheng/VectorCGRA/blob/master/fu/single/MulRTL.py to implement the GepRTL.py.

The const can serve as stride for 2D. But what is GEP_CONST(2opr)? in this case, const serves as base? Can you please elaborate the functionality of the 4 GEP you are proposing, before starting the implementation. I am wondering whether single const_queue is enough in this case. If not, we need CMD to pre-configure GEP FU.

[Jackcuii]

Sure, plz do. You plan looks good to me. You (or codex/gemini/claude) can follow https://github.com/tancheng/VectorCGRA/blob/master/fu/single/MulRTL.py to implement the GepRTL.py.

The const can serve as stride for 2D. But what is GEP_CONST(2opr)? in this case, const serves as base? Can you please elaborate the functionality of the 4 GEP you are proposing, before starting the implementation. I am wondering whether single const_queue is enough in this case. If not, we need CMD to pre-configure GEP FU.

Hi Sir Tan~ My original plan is actually the GEP(2opr) is for base(can be const) and index, and GEP(3opr) is for base, stride and index. But in this way, we may need 2 constants and it calls for 2 const queues, which is a huge change.

According to folks' discussion in #305, I think maybe we can just let the logic of 2D/3D/..D stride logic to be out of the GEP and our GEP becomes only an ADD? This could be a general solution that need minimum modification to the RTL.

[tancheng]

Hi @Jackcuii, RTL change is easier than compiler change for this feature I guess.

We can have the GEP(2opr) and GEP(3opr) to support 1D/2D. More than 3D can be on software side.

We can limit the const_queue is only for base. For stride, we need another CMD to configure it before hand. Both @ShangkunLi and @yyan7223 supported CMD pre-configure certain FU. You can start with 1D first (no CMD needed). How does that sound? Then ask them for some reference about CMD pre-configure for more than 1D.

[Jackcuii]

Hi @Jackcuii, RTL change is easier than compiler change for this feature I guess.

We can have the GEP(2opr) and GEP(3opr) to support 1D/2D. More than 3D can be on software side.

We can limit the const_queue is only for base. For stride, we need another CMD to configure it before hand. Both @ShangkunLi and @yyan7223 supported CMD pre-configure certain FU. You can start with 1D first (no CMD needed). How does that sound? Then ask them for some reference about CMD pre-configure for more than 1D.

Cool! but can we have someone else work on the GEP or we have some other quick fix on it? since we only have very few kernels need 2D GEP (for 1D by now I can use ADD/ADD_CONST). Kernels are all updated and I am a bit too struggling on making the other kernels to run on VectorCGRA to spare effort on this. (ddl is so close)

[ShangkunLi]

Hi @Jackcuii, RTL change is easier than compiler change for this feature I guess.
We can have the GEP(2opr) and GEP(3opr) to support 1D/2D. More than 3D can be on software side.
We can limit the const_queue is only for base. For stride, we need another CMD to configure it before hand. Both @ShangkunLi and @yyan7223 supported CMD pre-configure certain FU. You can start with 1D first (no CMD needed). How does that sound? Then ask them for some reference about CMD pre-configure for more than 1D.

Cool! but can we have someone else work on the GEP or we have some other quick fix on it? since we only have very few kernels need 2D GEP (for 1D by now I can use ADD/ADD_CONST). Kernels are all updated and I am a bit too struggling on making the other kernels to run on VectorCGRA to spare effort on this. (ddl is so close)

I can provide the quick fix for 1D & 2D GEP RTL first.

For 2D GEP, do we need compiler support at the same time? @Jackcuii

[tancheng]

@Jackcuii this issue can be closed thanks to #280?

Should we also close coredac/neura#284 or compiler needs to be updated? @Jackcuii

[tancheng]

Friendly reminder @Jackcuii