The ReUse conundrum

The 3DP FPGA on-chip bus protocol could be AXI-Lite. Essentially, the open source project uses the MIT license (arbitrary choice I made). VUnit has some useful packages for AXI but uses the Mozilla Foundation 2.0 open source license. Let's not get into the whole license issue, it is a whole discussion in itself. Here, the reuse question is how to include files from other open source projects in a sound and controlled way.

Assume the package I want to reuse is axi_pkg.vhd.

On the unit level, in every project my position is that every unit stands on its own. I could take out the "motorctrl_a4988" unit from the 3DP FPGA project and use it in another project. Hence when I clone it, I need everything that the unit relies on. The directory structure for the project allows this, so the RTL, the unit testbench and all testcases are inside the unit directory. VHDL specific, the directory name "motorctrl_a4988" means that the entity (it defines the unit IO) matches the directory name. The files are all named like this: <unit_name>.<object>.vhd.

Files for unit motorctrl_a4988:

• motorctrl_a4988/rtl/motorctrl_a4988.ent.vhd (entity).
• motorctrl_a4988/rtl/motorctrl_a4988.rtl.vhd (RTL).
• motorctrl_a4988/beh/motorctrl_a4988.beh.vhd (model).
• motorctrl_a4988/bbox/motorctrl_a4988.bbox.vhd (empty, outputs strapped).
• motorctrl_a4988/tb/motorctrl_a4988.tb.vhd (testbench for the unit).
• motorctrl_a4988/test/<testcase_name> (testcases that need to run, I favor a numbering scheme which has pro's and con's).

If the unit uses the AXI protocol definitions from VUnit, there will be a master in the system and multiple slaves. Each slave needs to use the package. And if we want to take out the unit, this package is required as well. Do we copy it in a <unit_name>/common or one level up, one common directory for all units? The latter will have more common files that aren't necessary for all units. In this specific case, it is one package for this unit, other units might use other or more files from the common area.

It is clear now that the language has the constructs to handle reuse. But this is a requirement, it isn't enough to guarantee reuse. This is so important, even though we tend to forget about it. The language has these capabilities. But the use of a HDL for System-On-Chip reuse always requires rules and discipline. Complication today definitely is the decoupling of all front-end design tasks. Coding guidelines and a methodology exist. The reasons behind them are never explained during onboarding of new team members. Example, we never design units that contain latches since the DFT tools do not like those, they rely on flip-flops (synchronous design). DFT tools do insert latches, but the tools add those for specific DFT things. But in design, we should never deliver RTL code to the synthesis team that contains a latch. For most rules, there is a reason that all-round front-end designers know, but less experienced team members do not. That is specific to tools and the design. Another layer on top of that is the reusability of source code. We are again talking about one layer up in understanding how a System-On-Chip methodology should solve issues, layer by layer. Unfortunately, there is no uniform standard for reuse. In the software world, there are initiatives to come to try to become more uniform but even they don't succeed. In System-On-Chip design? Our niche is way too small compared to software.

Most designers today aren't aware of the requirement for discipline and rules. For example, FPGA tools have a collection of files, push a few buttons and the bit-file that contains the FPGA configuration magically appears. If you want to sell FPGA devices, the entry to using them must be as low as possible. If you don't know if your product built around an FPGA will ever be successful (sales), then spending time on reuse and methodology is a waste of time. This is the business filter, which is the dominating filter in any company. An observation, not a judgement. Engineers must understand the different filters on reality to explain why something happens.

My argument is that the business filter aligns with the fact based (scientific sometimes) filter of the engineer. If there is a reuse methodology in place for every project you do, this will have the benefits of future development ease. Without the business cost of searching for tools, methodologies and trying them out one by one. Building a system and building teams is problematic in a business setting. People leave, people get sick, people go through personal ordeals, ... The perfect engineer evolved into the good enough engineer until we reached the anyone with the right answers to our interview questions gets the job. No matter how many ISO certification or quality assurance people you employ, the problem is still the system that incentivizes "bad" behavior. I hate running into the same issue over and over again, that is why I build systems to solve repeating issues. To solve the reuse conundrum in ASIC/FPGA design, we need to look at the current state of the version control tools we use. Most hardware teams use proprietary version control or open source. The latter would still be subversion, transitioning to git over time. Our beloved sector is quite conservative after all. So, let's assume git is our choice for an open source project that starts from scratch today.

GIT

Git is basically repository based, it has a submodules concept. In this case, I could include VUnit as a submodule to the FPGA project but there are some drawbacks to that. Version control over the source inside VUnit is one concern. And specifically an AXI package, is just one file that is used multiple times inside the 3DP units source code. So, there are solutions that build on top of git to make reuse happen. But for software projects mostly. Software resources are quite used to branching, merging and tagging releases. Hardware resources not so much. The requirements for us are:

• No duplication of code, that is error prone.
• Control over the version of the file outside the project repo that is included in our project.
• Unit reuse must be possible, we need those files that are external as well.

FuseSoC

FuseSoC is a package manager and a set of build tools for HDL projects. Searching the web for FuseSoC and VUnit some things pop up. One thing I noticed from a VUnit gitter discussion is this:

(screenshot of discussion in VUnit gitter, 2020)

Moreover, in 2015, the FuseSoC developer blogged about VUnit:

"The first inconvenient difference between FuseSoC and VUnit is that the vunit run script need all source files that should be compiled for any testbench to run. FuseSoC on the other hand don't know which source files to use until we tell it which core to use as it's top-level core".

There is a github FuseSoC VUnit example project here.

It hasn't been updated for 5 years, not sure if what I am doing is correct, need a deeper dive to get to the bottom.

Pipe cleaning is one of those big time consumers.

Hope to use both VUnit and FuseSoC to be able to add the reuse layer to the 3DP development methodology.