Port to SystemVerilog
laforest opened this issue · comments
At some point, once the architecture stabilizes (Octavo as top-level, over Mesh, over SIMD, over Scalar), we need to convert (and replace with!) the entire codebase to SystemVerilog.
Why
Support for interfaces in ports, which will eliminate the flat vectors passed in and out of Memory modules, which make each higher level harder and harder to write. Mesh already pushes at the limit of what's practical.
Similarly, support for structs, list parameters, etc... will make parameterizing large Octavo instances much cleaner. (e.g. we could easily implement heterogeneous Meshes)
Approach
Start a branch and rewrite from the bottom-up. The lowest modules (BRAMs, Controller, ALU, etc...) should convert almost without change. The Memory module will have port interfaces instead of flat vectors, and that will reflect in all higher modules, simplifying things.
When
After I graduate. :)
On second thought: no.
Support for SystemVerilog is less common than for Verilog-2001. Also, it seems that making Meshes in Verilog can't be done reasonnably nor will SV grant the necessary code introspection to really build larger systems sensibly. The real difficulty came from the long-ago decision to bundle the scalar and SIMD I/O ports in the same vector. Lesson learnt: don't mix "kinds" within vectors It makes composability very hard.
A better approach would be to have a base Octavo_ControlPath, Octavo_DataPath, an Octavo_Scalar core, an Octavo_SIMD core built from these (with a separate port vector for SIMD I/O), an Octavo_Mesh core, etc... each with their own generator scripts (in Python), each in their own subtrees.
With the parameters kept in a dict, any design hierarchy and introspection can be done in the scripts caling eachother, leaving the Verilog to solely specify single (parameterizable) building blocks, which is what it's good at.