Can you really meet your SoC design schedule without a good GUI?

Talk to the members of a digital design team and you will always find two types of users. One who likes using the GUI while working on his design and the other who is passionate about using scripts and the command line options. This is akin to the two camps of users who either love either good old Vi/Vim or the ever versatile Emacs editor. But these days when there is every effort to meet the SoC tape-out deadlines, is there any place for a well-designed GUI, given the general belief is that using the GUI slows down the design process?

Using the GUI in some areas of the design flow such as floor-planning, simulation, debug etc. is quite common. But at the same time the GUI is getting ignored in a number of milestones of the SoC design flow where its usage could be quite useful. This is despite the fact that designers feel the need to use it but are handicapped by the way the GUI has been designed. For most engineers developing EDA software, functionality always gains a precedence over usability and aesthetics. One reason for this perhaps is the high complexity involved in developing the EDA tools. However, much has changed among the designers who use EDA tools to build their SoC designs. The higher expectation of the GUI has been set in part by the well designed and usable apps on the smart phone and other software tools which the designers use. But while the need to develop an easy-to-use GUI with good aesthetics has been embraced by software designers, it has been slow in gaining acceptance in the semiconductor world.

Whatever the cause may be for the lack of good GUI in the semiconductor world, few can deny that a well-designed GUI makes a big difference in improving the productivity of the designer. A good GUI makes the software approachable as it bridges functionality and aesthetics. This ensures better user engagement and improved productivity because it makes inherently hard to understand flows/tasks accessible and “easy”.

The other perspective one should also consider, is the GUI the designers have been habituated to. Most engineers are usually resistant to change as it means relearning and potentially recreating/testing their scripts, time which they can ill afford to waste given the tight design schedules. This is particularly true in areas such as physical implementation, simulation etc. EDA companies have found out the hard way that changing a GUI which the designers are habituated to can yield disastrous results in terms of usage. But this does not imply that a good GUI is not a necessity! In fact, on the contrary, a well-designed and intuitive GUI to address more aspects of the front end SoC design flow becomes all the more important as it ensures designers are cooperating in the most efficient way and collaborating in a well understood process.

With increasing design complexity, design companies have married their EDA design tool flows with flow automation and efficient design handoffs to ensure software, hardware and verification teams can work in tandem and engage in productive collaboration. Emphasis is placed on re-usability and using a single source to automatically generate the desired correct-by-construction output consumed in various formats by different members of the design team lower down in the design flow. Setting up a design flow and automating as far as possible helps in performing well defined, potentially mundane tasks which are prone to human error. These include for example, virtual prototyping, defining the hardware-software interface, generation of structural RTL for top level wiring, insertion of test logic, documentation, design handoffs and creation of testbench and test vectors to verify the design. Doing this manually using scripts and command line across a design flow becomes rather tedious and error prone. With deadlines constantly looming before the design engineers, learning/relearning new methods to be more productive is a constant challenge.Consider the case of an IP in development. A common question often asked by engineers working on the IP is “Where is the golden source of information for my IP?” The answers change depending on whom you talk to. But given the design complexities, some parts of the design are auto generated while some are developed manually. Keeping track of the essential components and compiling the entire source in the desired format whenever a change is made, is easier said than done.  For example, the RTL designers need the updated RTL every time a change is made to the memory map or a change is made in the logical hierarchy to resolve congestion issues faced in the back end. Similarly, the verification engineers need an updated UVM test environment. And once the IP has been developed, packaging it with the necessary up-to-date documentation and datasheet is another hurdle which must be overcome. Managing this manually or through scripts poses a challenge which limits the productivity of the designer. This is a scenario wherein a well-developed GUI could increase the efficiency of designers considerably by an order of magnitude.

In the SoC world, any GUI without a datamodel has limited usefulness. While tool providers have used different types of data models to meet the GUI requirements, the semiconductor industry has been slowly adopting the IP-XACT standard owing to its capabilities. The fact that IP-XACT is an IEEE standard is equally important for most design companies. To see the benefits of using a datamodel, consider another example wherein an issue has been reported against an IP or a SoC. Resolving the issue involves first identifying the cause of the issue and then fixing the same. Debugging the issues quickly to find the root cause also helps save considerable time, something which a well-designed GUI can help considerably. Having a central representation of the IP such as interfaces, memory map, design connectivity etc. reduces the prospect of having to repeat the fix in multiple sources (HDL description, SW description, UVM description…). This central representation also helps finding corner case issues that are at the hardware-software boundary. With IP-XACT as a central datamodel, design companies can develop their own custom generators which they can leverage any time the datamodel is updated to generate the various outputs which are required.

But developing a good GUI is easier said than done. A number of factors needs to be considered while developing a GUI which addresses several parts of the SoC design flow. Some of these are

• Providing a common UI environment which addresses different parts of the SoC design flow to ensure familiarity.
• Intuitive and usable to make it easy for designers to use the tool
• Optional built-in flows to guide designers through the various steps
• Hooks to prevent mis-steps by the designers
• A central data model which can meet the requirements of the complex design flows

To hasten the process of developing the SoC or IP using well defined flows, it becomes necessary to use solutions which are tried and tested and is part of a production flow in several companies. The new Design Environment from Magillem is one such solution which helps you to automate your design flows and build your designs faster. For more information on the Magillem products, visit www.magillem.com. Magillem customers include the top 20 semiconductor companies worldwide.

Magillem is a pioneer and the leading provider of IP-XACT based solutions aimed at providing disruptive solutions by integrating specifications, designs & documentation for the semiconductors industry. Using the solutions provided by Magillem, design companies can automate their design flows and successfully tape-out their designs faster at a reduced cost.

Magillem is one of the leading authorities on IP-XACT standard. It is also the Co-chair of the IP-XACT 2021 Accellera Working Group and an active member since the inception of the IP-XACT standard.