Register automation is an integral part of IP and SoC development. Long ago, design, verification, firmware, and documentation teams preferred doing register management manually or each team wrote their own scripts for limited automation. Later, companies started doing this automation at the organization level. Central scripts were written for register automation for design, verification, firmware, and documentation teams, but still each had their own specifications. This led to many iterations between these teams before different collaterals were all brought in sync. As design complexity grew, maintaining these scripts became difficult, and commercial EDA tools took their place. Simultaneously, many open source tools also cropped up that could be used for register automation. Although commercial tools have their own value proposition, open source tools also have their use cases. The five primary reasons why you might use open source tool are:
1. Cost
Open source EDA tools are typically free to use as there is no license fee, support fee, etc. You can just download, install, and get going. Generally, these tools are ideal for students, academicians, and perhaps small companies or cash-starved start-ups. If the cost to fix a bug in the final product developed using an open source tool is less than the cost of a commercial EDA tool for register automation, then it may be beneficial to opt for it.
For companies, there are a few more factors that affect the cost indirectly; experienced CAD engineers are required to integrate the tool in the production environment without any compatibility issues. Also, design and verification teams must be able to quickly ramp up on the tool to be able to churn out fully tested and verified designs faster in order to meet the shrinking market window. Some software engineers may also be needed to fix any issues or tailor the open source tool to meet unique requirements.
Considering all the above factors, if you can ensure that the total cost of ownership of an open source tool remains less, then the open source tool can turn out to be cost-effective for your organization.
If saving money on a commercial tool is more important than the money spent on finding bugs later in the development flow then you can perhaps go with the open source solutions.
2. Features
More options, more confusion! Fewer options, less confusion!
Generally, commercial EDA tools offer a comprehensive range of features and functionalities, including a rich set of special registers, a large number of properties for customization, etc. as they are developed and maintained by dedicated teams with extensive resources and customer interactions.
The open source tools may not support comprehensive features and functionality, but with fewer options you are not spoiled for choice. Assess the specific requirements of your project, including design complexity, input specification format (System RDL/IP-XACT/Excel/Document or a mix of these formats), required output collateral formats (Verilog, VHDL, System Verilog, UVM, HTML, PDF, Markdown, etc.), performance targets, and time-to-market constraints. Determine whether the features and capabilities of the open source tool align with these requirements.
With limited requirements you can be satisfied with a smaller set of features. For example, you may be using just one input specification format so you may not need a tool that supports a mix of formats. Similarly, you may require only design and verification collaterals, so why should you pay for other collaterals such as firmware, documentation, and custom outputs? Also, you may be working on FPGAs so ASIC related features could be of no use to you. You may be dealing with small and fairly simple designs so you may not require high performance features like clock-domain-crossing (CDC), functional safety, and so on. Working across teams and geography may not be important for you, rendering enterprise level features useless for you.
If you have simple register maps and don’t have any 3rd party IPs in IP-XACT and other formats, then open source may be enough for you.
3. DIY
Companies can start with the open-source software and set up a team of software engineers to modify the code for specific project requirements, tailoring the tools to fit the company's unique needs. The main challenge here is when updates of an open source software are released. It is usually a thrilling adventure into the unknown. Your engineering team may need to spend hours tinkering with config files and compiling the source to maintain compatibility with your production tool flow. Some previous features may suddenly disappear or be implemented differently as these tools are ever evolving. Merging your custom changes to open source code with new updates often requires a major and costly effort.
If hours spent tinkering with the output generation is not going to cause delay in the project and the cost of dedicating software engineers in developing, refining and maintaining the open source tool for several years is less than the cost of the commercial tools, then open source might be a possible solution.
4. Support
Many open-source projects have vibrant communities of users and developers who contribute to ongoing development, provide support, and share knowledge. While open source communities are there to help, you need to navigate through different forums for advice. Extensive documentation requires skills to extract the right information or else you can drown in the sea of available materials.
Support can be a weakness for open source tools. Troubleshooting is a costly affair, and often time consuming as well, delaying your critical project. There are no training programs, although there could be numerous tutorials available to help users learn the nitty gritty of the tools. This kind of community based approach to support can make troubleshooting a tedious task, affecting productivity, and risking your project success.
If time to market is not important for your project, then the absence of quick support may be acceptable.
5. Transparency, Scaling and Certification
With open source software, the code transparency can provide reassurance regarding security and reliability. Transparency may also expose vulnerabilities and critical flaws making these tools susceptible to attacks.
Open source tools also need to scale with your company’s evolving needs to support future innovation and competitiveness. Your company’s growth trajectory is linked to the evolution trajectory of the open source tool, which may be good enough for the short term but not suitable for long term strategy.
In certain industries, such as aerospace, automotive, and medical devices, regulatory compliance is critical. Companies making products in these domains do not have the luxury of using open source tools as they may not offer features and certifications to ensure compliance with industry standards and regulations.
Open source crowdsource development has its advantages but what happens when multiple users have conflicting requirements? One will always need a person to maintain the branch with their changes.
ISO 26262 certification requires that the tool vendor follows standard development processes to ensure tool quality, predictability, and fault management. If certification is not important or necessary then open source software can be used.
Conclusion
Open source register automation tools have their strengths and weaknesses. There are numerous use cases for these tools especially in academics, prototyping, and non-critical projects/products. However, many other industries and applications have requirements that can only be met with commercial register automation solutions. Open source tools may look cost-effective in the short term but, in the long term, the cost of ownership and the risk to the project outweighs the perceived benefits.
