I have been involved in SoC developments for a long time. During this period I tried to learn what impacts the productivity and subsequently the market opportunity. Over the last year or so at SoCScape I have been involved designing solutions that can improve them. I have decided to post some of my thoughts here in a series of blogs from this experience and effort. I hope you participate and enlighten me on this topic more by providing your comments below.
Integrated circuits have been packing larger functionality due to tighter geometry to reduce total system cost. However, design cost for large chips is on the rise. There are multiple elements contributing to the cost to consider. I am not talking about the cost of simulation or synthesis of complex functionality here. Those are addressed by the multitude of -constantly improving EDA products and methodologies. I am addressing cost of preparing the RTL before hand-off.
The following three issues stand out the most:
Complexity
Cost due to the inherent complexity of functionality. It takes time to put them together in an SoC. Delivering the complete RTL to the simulation and synthesis team in a consistent manner is non trivial.
Lack of uniformity
The building blocks, commonly termed as intellectual properties (IPs), may come from different sources. These IPs are typically reused over multiple chips. The style, naming convention etc. are different depending on where they come from. The lack of uniformity in situations like this can increase resource needs and have a negative impact on cost.
Change in requirement
Today’s design practices present requirement changes based on market demand a few times through its life cycle. Adjusting to these changes incur cost since time to market often has a significant impact on product revenue.
A solution that controls cost by improving productivity in these areas is my primary interest. After all, experience suggests that SoCs are not becoming simpler and smaller! We need to make chips to make money without letting the market opportunity slide away. A great SoC delivered late to the market does not yield its full revenue potential.
Complexity
I would like to give a brief historical perspective. Remember when hardware description languages (HDL) were introduced? When HDLs were in their infancy, many designers were reluctant to adopt HDL because of the absence of robust synthesis tools. Although digital design at gate level was tedious, chips were simpler. It was still fun to craft new functions with gates. But then the complexity made gate level more mechanical and therefore the creative fun was not at the gate level any more. I started coding chips with Verilog and VHDL. Both have their great features and pains, but it started becoming fun to code at RTL level. I could cater to my creative side and I also got immediate productivity boost.
History is repeating itself again! I am encountering many proponents of high level synthesis (HLS) these days. This is a good thing. With HLS, designing logic that produces high level complex functions will not be as tedious.
So how does the complexity of today impact the designers?
Lots of signals to connect
I mean a lot! They are traversing up and down through the hierarchy. Hooking them up individually is error prone and time consuming. This is where the protocol based connections can help. So what is a protocol based connection?
They behave much like cables. They contain a collection of functionally related wires. When you connect them to a connector they all get connected at the same time, no need to connect them individually. Moreover, you cannot take one type of cable and connect it to another type of connector. Of course I am purposely ignoring the case where someone tries to use pure brute force!
It is possible to use HDL to apply such a paradigm. A VHDL record aggregates a collection of signals. A System Verilog struct also provides similar facilities. HLS methodology supports this paradigm as well.
However, in any given SoC or a chip design, we may have a number of IP. One could be designed using a different HDL than the next. The front-end designer of an SoC or chip has to deal with this mixed bag and that is where it starts becoming tedious. Fortunately, this is where automation comes to the rescue. To take advantage of the automation, an IP needs to provide meta-data describing all the protocol based connections. An EDA tool can use the information and connect everything on behalf of the designer. This type of automation presents a huge opportunity to improve productivity and reduce manual error.
The IP-XACT (IEEE 1685) standard provides an XML format to describe the meta-data. There are a growing number of EDA vendors providing support for IP-XACT. As a result, an increasing number of IP vendors are also delivering IP-XACT files with their IPs.
IP-XACT format is quite comprehensive and elaborate. It addresses a broad spectrum of needs above and beyond the protocol based connections. The XML format is intended to facilitate machine reading. Manually producing the IP-XACT files are not practical.
As a result, a particular EDA tool may support one or more additional mechanisms such as human readable meta-data description language, simpler meta-data format, APIs, or graphical user interface. These additional mechanisms allow the user to provide the meta-data for an IP that lacks a preexisting IP-XACT file. A designer should evaluate an EDA tool based on the simplicity of its additional mechanisms. Simplicity is a powerful contributor towards productivity.
Creation of glue logic
Designers will need to provide glue logic that realizes a multitude of functions while they are bolting the IPs to their SoC or chip. They spend quite a bit of time on the glue logic. This is what makes the SoC act as a single cohesive entity. Typically these are small pieces of logic, but they could be large as well. Complexity in SoC design increases the number of these pieces. Automation can improve productivity here too by introducing division of labor.
An EDA tool for this purpose should be able to provide facilities for the designer to dynamically introduce glue logic blobs inside different areas of an SoC as the designer needs. These blobs should not contain any actual logic. They simply should provide a placeholder for the designer’s need so that he can focus on integrating the rest of the IPs. The EDA tool should permit one to come back to these blobs and add logic later. This will allow us to take advantage of divide and conquer strategy. You can employ multiple designers to parallel process the task, some defining and creating the blobs while others filling up the blobs with actual logic.
Chip specific customized IP
There are quite a few pieces in an SoC which are to be customized per SoC basis. Clock/power management is a great example. It is indeed very complex in nature. There are other pieces such as padring, design for test (DFT) logic, etc. which also fall under customized IP category.
These pieces are challenging since change in SoC design impact them quite a bit. Additionally, their role also continue to evolve over time in terms of how they handle their designated tasks.
This is actually an interesting topic, which deserves its own space. I will go over this topic in my next post. Stay tuned! I appreciate you providing feedback, which allows me to refine my thoughts. Cheers!
Share this post via:
Build a 100% Python-based Design environment for Large SoC Designs