It’s been quite a while since I talked with Agnisys CEO and founder Anupam Bakshi, when he described their successful first user group meeting. I reached out to him recently to ask what’s new at Agnisys, and his answer was “collaborative specification.” I told him that I wasn’t quite sure what that term meant, and he offered to spend some time with me to explain. I’d like to share some of our conversation.
Can you please tell us what collaborative specification means?
It’s a term used in slightly different ways in multiple industries, but to us it’s similar to parallel design. The concept of multiple design engineers working together on a single chip is well established, and in fact it’s essential given the size and complexity of today’s devices. Distributed design teams and the ongoing pandemic mean that engineers are rarely working side by side physically, so a highly automated online system is required. The same argument applies to chip verification; modern testbenches are incredibly complicated and require many verification engineers collaborating. We’ve extended this idea to specification of the design, with many architects and designers working together virtually.
Why is collaborative specification different than collaborative documentation?
Well, if your design specification is just another text document, there’s really no difference at all. But the Agnisys approach is based on executable specifications that our tools use to automatically generate RTL designs, Universal Verification Methodology (UVM) testbenches, assertions for formal verification, C/C++ code for firmware and drivers, and end user documentation. Collaborating on executable specifications is a rigorous process that offers more opportunities for automation.
Are you talking about multiple engineers working on a single specification at the same time?
Yes, that’s sometimes the case, so it’s important to have a great change tracking and control system in place. I should comment that the way these systems have evolved is one of the biggest changes in software and hardware development over the years. Revision control systems used to be based on a locking model, where any engineers wishing to edit a file (schematics, RTL code, testbenches, programs, etc.) would “check out” the file and have exclusive access to it during the editing period. If someone else wanted to make a change, the first engineer would have to “check in” the edits first. For quite a few years now, the dominant approach has been the merge model, in which multiple engineers might be editing the same file at the same time. Resolving any inconsistencies has become an essential part of any version control system flow. Of course, we support the merge model in our IDS NextGen (IDS-NG) solution.
So is IDS-NG a version control system?
No, there are excellent solutions out there and we saw no reason to “reinvent the wheel.” In talking with our customers and partners, we found that the open source Git distributed version control system is extremely popular and very powerful. IDS-NG now has a tight, native integration with Git so that our users can create and edit executable specifications that are saved in a repository and managed by an industry-standard system.
Can you give an example of how this works?
Sure! The user creates and edits a specification using the intuitive graphical environment and language-aware editor within IDS-NG. They may import existing specification information from common standard formats such as IP-XACT and SystemRDL, or they may leverage the highly configurable standard IP blocks available in our SLIP-G library. Once they have reached a good checkpoint, they can easily “commit” their changes to a local branch of the design specification and then “push” these changes to the main development branch in the project-wide repository. Other users can then “pull” the new version of the file for use in their local branches.
What if someone else has edited the same file in parallel and already pushed those changes?
In that case, Git reports that there are conflicting edits, but it cannot resolve the differences by itself. This is where the cleverness of IDS-NG really kicks in. If the user pulls the other updated version of the file, IDS-NG performs a comparison (“diff”) of the two design specifications and reports the results. Some changes can be merged automatically, but others require user input. For example, if two users change the width of the same register in their respective edits, one of the users needs to decide which is the correct value. This information is displayed very clearly in the IDS-NG interface and it’s easy for the user to review and resolve any differences. This unique approach is easier and more intuitive than doing a simple text comparison on two SystemRDL files.
Is seems to me that this capability would be very useful in a CI-based workflow; is that correct?
Yes indeed. In continuous integration (CI), which Git supports well, all committed changes are pushed to the main development branch frequently, perhaps at the end of every work day. The motivation for this approach is finding conflicting edits sooner rather than later, so that they can be resolved before two versions of the specification diverge wildly. You could argue that the “compare documents” function in Microsoft Word played a big role in enabling collaborative documentation. With the recent Git integration and diff capability in IDS-NG, we’ve done the same to enable collaborative specification.
Will you be demonstrating these new features at the upcoming virtual DVCon Europe show?
Yes, we are a Silver Sponsor for this important event, and we have a very nice collaborative specification demo and video available. We are looking forward to sharing them with the online DVCon Europe attendees. We’re excited at the advanced project workflows we now enable, and we expect a lot of user interest.
Overcoming the weaknesses of traditional natural language specifications requires writing the specifications in a precise format rather than natural language, and making this format executable so that tools can generate as many files as possible for the design, verification, programming, validation, and documentation teams. Learn how Agnisys approaches a solution to this challenge that is available today.
