Mentor’s Colin Walls examines the distinction between using SystemC for hardware models and test models. This is sort of like building the crash dummy or testing its limits.

Cadence’s Richard Goering reports on a development in formal analysis called “case-splitting” that can close up coverage holes in verification. This is an interesting twist.

Calypto’s Shawn McCloud, writing in DeepChip, unveils a survey of 744 engineers on what they do to reduce power in designs. Clock gating and power gating are at the top of the list. The 6% who “don’t know” may be unemployed soon.

Mentor’s Mike Jensen delivers the second part of his how-to on analog modeling, which may be coming to an engineering team near you—even if they swear they’ll never use this stuff.

Semico’s Morry Marshall looks at the pros and cons of an all-electric vehicle and who the likely buyer would be. But is it really pollution-free?

Cadence roared back to life in Q4 with revenue of $308 million compared to $249 million in the same period in 2010, and net income of $11 million (or $46 million non-GAAP) compared to a loss of $37 million in 2010 (or $18 million non-GAAP). The company anticipates revenue will be in the range of $305 million to $315 million this quarter, with annual revenue in the range of $1.24 billion to $1.28 billion.

Sonics and Tensilica are working together to integrate Tensilica’s DSP processor interface with Sonics’ OCP-IP interface. The goal is to boost on-chip performance while making it easier to integrate IP. These kinds of deals are helpful in getting SoCs to market more quickly. Sonics also issued its formal response to rival Arteris’ countersuit.

SLD: As we go up in abstraction, will transaction-level modeling be enough? It doesn’t address software or the physical effects, does it?
Zorian: That’s correct. It’s a higher-level model. But it’s good for initial exploration.
Subramaniam: You need to be able to explore all the different multidimensional aspects of the problem—power, performance and area. Being able to look at one aspect is good, but it’s not sufficient. That’s the missing link here.
McNamara: That’s where you get to things like parasitic extraction. You need to lift up the power information from the RTL and the gate-level simulation and project that up to the TLM so you can run simulations there and boot software on it and get a sense of your power. As you switch to a different manufacturer, that also has an effect on the leakage power. You’d like to be able to project that information up, too. That’s crossing nodes with abandon. You’re going from a choice of one transistor to another and projecting that onto system-level power. But for us to tame the complexity we have to have a system that lets us do that. I may not care how fast it works. I may just need more than a day of life on a battery. I may need it to last the flight from here to India.
Varadarajan: The abstraction only works when there is correlation. It enables you to do design exploration. If you make all these choices and you can’t trust and implement those choices when you go to the back end then it’s not useful. The correlation is key as you go down in implementation. In a typical SoC you have IPs and complex bus fabrics switching up these IPs. What designers do is transform the SoC from a hierarchy where they collect IPs and push them to the bus fabrics into larger subsystems that get implemented by design teams. That is a difficult task. One of our customers complained there was a timing signal that went from the lower left corner of the chip to the top and all the way back down. That’s something that should have been addressed up front. When you go down into the implementation of a very complex IP that is coming from a third party, the implementation is going to be a function of how you break down the data flow, how you organize the memory and the floor plan of the entire IP. Being able to capture that and make high-value decisions, like whether you can push it from 400MHz to 500MHz, is going to be a function of how the floor plan is going to look. You need a predictable way of handling that. Once you have taken care of the global topology, all the physical synthesis tools are commodities. If you organize the data flow, they can all converge to the same timing targets. You need to demystify IP and break it down at the abstract level, and have enough confidence you can achieve your targets, whether that’s timing or condition or power, and then be able to implement that predictably when you go into the back end.

SLD: To get a design out faster you’re decoupling IP from the rest of the design. But to do exploration you need to really understand all the tradeoffs of performance, power and area from a system level. How do we bridge those disparate ideas?
McNamara: There’s a tools aspect to it of being able to extract information so it can be shared. The end customer needs to be trade off ‘A’ versus ‘B.’ You can assemble one company’s IP with another company’s IP, but you’re going to be just like someone else. So how do you differentiate?
Subramaniam: This is where system-level tools come into play. Today you can figure out performance and what speed you need to run your system at. But they don’t have the ability to absorb information that is available at the lower level. What we need to do is to input the implementation-related information up into the system-level tools. When the system-level designer is exploring the system bandwidth requirements and how to architect the system and organize the software and hardware partition, they should be cognizant of the implementation-level details at that level. That is a missing link today, and it’s a gap that needs to be addressed.
Rey: There is the issue of certification. You need to understand interactions when IP is placed in a certain area. Look at 3D integration, where you have things in different die that have to work together. Even though the general consensus is this is really a cost equation, as soon as you want to stretch the limits a little bit and go to higher frequency the approach breaks down. More research into implementation and testing will be required to make sure it works. When you go to very high frequencies we’re starting to see some effects that were not important before.
Subramaniam: If you look at memory, there are different kinds of memory interfaces. You can have a wide I/O interface in a 3D stack that is running at a much lower speed but giving you the same bandwidth as a much higher-speed interface that is SerDes-based and has fewer pin-count. In a 3D environment, both are applicable. In fact, the wide I/O is more amenable to a 3D environment. One of the things system-level tools should enable is for you to determine which makes more sense for this design. Should you use a SerDes-based high-speed serial interface to access memory or a wide I/O low-speed interface? This is where the power-performance-bandwidth-area tradeoff comes into play.
McNamara: It’s also the implementation. If it’s displaying video you need a lot of data, but it’s also 24 frames per second so you know exactly what bandwidth is needed for the next frame. Wide I/O could make more sense in that case. If you have a low-latency message and you need to get it quickly and it’s small, both would work. You could send the same message over either channel. But you need to see which one is better for the application. We’ve talked about power-performance-area, but there are many other cost metrics—things like routability. One design may be 10% smaller but the routing guys will kill you. You also have reliability. As geometries get smaller and smaller, maybe there’s another way of implementing something that’s more reliable, particularly if this is going into the back office of a bank. If you care about one of these other dimensions, is there a way to extract that information and project it through the system?
Subramaniam: You need to define the metrics and have those metrics defined for each one of these subsystems. That’s required for exploration.
Zorian: Exactly. But architecture-level exploration is there already—the prototyping capabilities where you can explore different architecture options, whether it’s 3D or 2D or wide I/O or not wide I/O. You can play with those. We do have virtual prototyping capabilities that allow you to play the game early on—pre-silicon.

SLD: That’s assuming your IP is very well characterized, though. From the big companies like Cadence, Synopsys, Mentor and ARM, that’s going to happen. From other sources, maybe not.
Zorian: When we started IP it was just for re-use. It was a design piece. Today that isn’t the case. There is differentiation between IP providers. I believe in IP completeness. You need to put out a complete package for IP. From a design point of view and from a manufacturing point of view you have to prove it in silicon, you have to have the silicon reports with it, and you have to maintain it internally with built-in self-test and built-in self-repair and debug diagnostics. That makes your IP complete, and it’s a differentiator in the future between one IP provider and another.
Subramaniam: This is where a standard like IP-XACT may come into play. If you have a host of third-party IP providers out there, how can the small IP players enable their IP in the ecosystem? The answer is by using a common standard to characterize the IP and fit their IP into the tools environment. That will enable designers to access that IP in their environment.
McNamara: And you mentioned the subsystem. It’s no longer that I want this PCI Express. I need a compute subsystem that gives me the floating point, the graphics, and so on. There’s IP that’s software for that. Often IP suppliers of these subsystems are giving you demo drivers. They almost work. You’re assembling this device to get to market by Christmas. You figure all you have to do is slap this thing together, put on Android and you’re there. Then you realize the driver doesn’t actually work. Then you integrate it all with the rest of the system and you find out you have to fix the driver again, because while it worked great after you fixed it on a point-to-point link, it doesn’t work as well on a shared bus. There’s also a software component there that has to be tested and proven. When you get to platform-based design, there will be common subsystems and the Linux kernels will already know about these. They’ll already have the device drivers. So then there may be hot IP from another company that gives you 10% more performance with 15% less area, but the Linux kernel doesn’t know about it. That’s now another challenge to the small IP providers. They need Unix developers working for them to deliver all of this and they may not be able to afford them. But how we’ve made these devices better every year is by taming complexity.

SLD: We also have to start dealing with yield issues, right? Multiple known good die could end up in a package or stack as all bad die.
Zorian: It’s not only the dies. It’s also the interconnects. Those TSVs are of a different nature. The defects that can hurt them are different. Our ability to test them at the end is not sufficient because by then you’ve destroyed your whole device. At the stack level you have to test and prove and retest.

SLD: It’s also the interposer, right?
Zorian: Same approach.

SLD: From a designer standpoint, assuming we have subsystems that can plug and play and IP that can be mixed and matched, how do companies differentiate themselves.
McNamara: That’s where having a complete flow is essential. One company did a great memory controller that could handle any device with 15 common memories, and you could use this IP on your device and build something that didn’t require custom memory. What this meant was there was wasted silicon. There were bits available to talk to memories that this device would never talk to. When we have this great system where we have the transformation tools down and the analysis tools up and this way to select IP and put it together, there’s another phase of this optimization that goes across the whole thing. It isn’t just gate-level optimization to clean up a couple bits. You’re looking across the whole stack and realizing the customer is going to run iOS on it and it will never run Android, so maybe there’s something you can get rid of reliably on this design, but keep the IP for another design and delete something else. That’s a differentiator. You need a way to optimize a design.
Rey: There is always the possibility of stretching the technology into limits that are defined in a conservative way by the manufacturer. Yield is one aspect. Another aspect is related to performance. You can see the companies that have an intimate understanding of the technology processes. They can go beyond the recommended rules and the established rules that the foundries have imposed, and it can give them an advantage.

SLD: Can that be done in a disaggregated market, or can it only be done by the large IDMs?
Rey: It can be done in a disaggregated market, and it has been proven by some of the companies we work with. What you need is a certain level of volume so the manufacturers will pay attention to you. Otherwise it’s going to be a lot harder.
Subramaniam: I agree. If you look at the performance of different technology nodes, there’s a significant overlap in performance between neighboring technologies—40nm and 28nm, and 40nm and 65nm. Somebody who makes a smart choice can differentiate their product by implementing it in a cheaper technology versus someone else who uses brute force in a more expensive technology. That’s one way of differentiation. But in spite of there being a lot of re-use, there’s always going to be some aspect of the problem which is unique to the individual—algorithms, software techniques—and those will be designed independently. They will be complementary to the re-usable IP and that will always be there. But when you talk about wasted silicon, that is a by-product of re-use. Not everyone can afford to do a custom design for every design. There will be some customization, but that will be dedicated to a small portion of the overall system.

Synopsys’ Karen Bartleson is hosting a trivia game throughout 2012. Prizes are $40 Amazon gift cards. Given Amazon’s just-announced earnings, this may qualify as a corporate charity write-off for Synopsys.

Mentor’s Robin Bornoff looks at the reasons why thermal interface materials go bad and what to look out for to prevent bottlenecks or, worse, complete meltdowns.

DeepChip’s John Cooley is soliciting comments for the FTC on the proposed Synopsys acquisition of Magma in light of previous concerns that were raised when Synopsys bought Avanti in 2002. But are those claims still relevant? Mike Demler offers up a completely different viewpoint, also in DeepChip. He says that Magma shareholders should be thrilled by the offer.

Cadence’s Richard Goering focuses on a white paper that shows verification performance is more than just raw simulation speed. There are some notable pointers to how to speed up the simulation process.

Tom De Schutter, writing in Synopsys’ TLMCentral, is running a competition for sensor device modeling. The deadline for submissions is in 16 days. Start coding.

Mentor’s Colin Walls addresses an engineer’s concerns about real-time signal processing with Android and other OSes.

And in case you missed the most recent System-Level Design newsletter, here are some standout blogs:

–Mentor’s Jon McDonald looks into how differences of opinion can affect design.

–Synopsys’ Achim Nohl addresses the question of what makes one model better than another.

–Cadence’s Frank Schirrmeister expounds on the importance of software in hardware designs.

–Sonics’ Frank Ferro pulls back the covers on the reasons why SoC design is suddenly much more interesting to a lot more people.

–Arteris’ Kurt Schuler adds meat to the argument that the time to invest in semiconductors is during a downturn.

–eSilicon’s Doug Ridge draws a parallel between the odd mix known as turducken and SoC design.

–Methodics’ Simon Butler digs into why IP distribution is such a big problem.

–And Atrenta’s Tiffany Sparks looks at some electronic designs that literally can change lives.

Arteris charges that Sonics’ new SonicsGN infringes on two of its patents. It also denied that it has infringed on any of Sonics patents, which Sonics claimed in the lawsuit it filed in November against Artertis lawsuit against Arteris. Arteris is seeking damages and “equitable relief” from Sonics.

Sonics declined to comment.

Historically, patent infringement cases in the technology sector have started when markets are either heating up or when they are in steep decline. In EDA, for example, the majority of legal battles were fought when the industry was in high growth and acquisition mode. In the PC era, the famous battles between Apple and Microsoft were initiated early in the boom cycle.

NoC technology is still in its nascent stage, but it is gaining in popularity at advanced process nodes because of the enormous quantity of IP and the ability to add flexibility into a design on a variety of fronts, including power management.

“There is certainly much more contention for board seats,” said Jodi Shelton, GSA’s president. “We’ve also been on a roll for the past two years to build up the board. We took eight seats and made them appointed for each region. The rest are open elections.”

It’s those open elections that are creating angst among companies vying for seats. Some of the contenders’ Web sites have direct links to place a vote for their CEO on the board. “There are a lot of relationships built on the board,” said Shelton. “It’s a who’s who of the industry. There are all the major foundries, the fabless companies, and all the top executives from those companies. And they actually show up for meetings four times a year and are fully engaged.”

That’s apparent in the growth of candidates. In 2009, there were four open semiconductor board positions and 10 candidates. In 2010 there was 1 open position and 9 candidates, while in 2011 there are 4 open positions and 16 candidates. In this year’s election there are 5 open positions for the semiconductor slots and 10 candidates, and 1 position in the value chain producer slot and 4 candidates.

How this will all play out is anyone’s guess, and losing or winning the election certainly doesn’t mean a company will do well or fail going forward. But in the world of business relationships, this is an easy “in,” and the number of votes cast is expected to be quite large by the time balloting ends in mid-February.

Synopsys also is collaborating with Sigrity to accelerate signal integrity analysis, and it won a deal with Yamaha, which is standardizing on its Processor Designer tool for custom DSPs.

Mentor Graphics won a deal with Altera, which will use its Voloce emulator to verify its next-generation FPGAs.  Mentor also won a deal with Fujitsu Semiconductor, which is expanding its use of Mentor’s Calibre platform for physical verification and DFM. e

Open-Silicon rolled out a 28nm version of its Interlaken IP core for chip-to-chip packet transfers for networking products.

Arteris reported more than 100% growth in NoC technology licensees in 2011. The number is now 39, up from 18 at the beginning of last year.

Click here to view the embedded video.

Verification has always been described as an unbounded problem. You can always verify more, and just knowing when to call it quits is something of an art. Moreover, with software now thrown into the mix, engineering teams have to decide what’s good enough for tapeout and what can be fixed once the chip is already in the market.

Making that decision is becoming tougher, though. The amount that has to be verified is less clear, in part because of the growing amount of outside IP that is now included in designs. Of the 70% or 90% of IP that is used or re-used in a complex SoC, less than 50% is now commercially purchased with the remainder internally developed, often for previous projects. The amount of commercially generated IP is expected to rise over the next few years, though, basically creating a series of black boxes that companies didn’t create internally.

While much of this commercial IP will be sold as pre-verified, what works in one design may not work exactly the same way in another. That’s particularly true with different process technologies. A general-purpose process built for speed may cause IP to behave completely differently than one optimized for low power. And in stacked die, two known good die may no longer work when they are packaged together.

“The new world is a broader supply chain for chips,” said Mike Gianfagna, vice president of marketing at Atrenta. “There is a need for better visibility in the supply chain, including everything from early predictions to yield to the track record of the supplier. There are multiple points of failure. For data management, planning, thermal and mechanical analysis you need fundamental enabling technologies. At the same time there is a re-invention of the industry into smaller, more niche markets.”

Knowing what to verify
Just knowing how much to verify is a challenge. Taher Madrawala, vice president of engineering at Open-Silicon, said this is not a simple decision because file sizes for verification are becoming enormous. That means what gets left out of the verification process may be as strategic as what gets included, because all of this can affect time to market. Verification budgets remain tight, both from a manpower and equipment standpoint.

“On top of that you don’t always have access to all of the functionality,” Madrawala said. “That’s especially true in 3D stacks or system-in-package. You don’t always have access to increased functionality because some things are encapsulated inside the package.”

He noted that from an NRE perspective, the percentage spent on verification has remained constant from 90nm down to 45nm. That has been helped by more standards, including modeling of IP in C or C++, an increased use of emulation, and the ability to run tests on multiprocessing computers. But with compressed schedules and greater complexity, those numbers can change.

There also are differences of opinion about what works, what will continue to work, and what needs to be changed in the future, both from a physical and a functional standpoint. Tools vendors insist that most of the capabilities are already there to do verification, even though they will need to be speeded up through better modeling at a higher level of abstraction with a greater reliance on multiprocessing servers. They also say that verification teams need to learn to use the tools that are out there better.

Chipmakers generally acknowledge the need for better training on the tools, but they say the growth in complexity will create the need for additional testbenches. In particular, there will need to be new tools for partitioning designs and verifying the results once stacked die become more mainstream.

“As complexity grows, integration will be the issue,” said Prasad Subramaniam, vice president of design technology at eSilicon. “You will need specialists for each part of the design. People’s specialties will get narrower. And then you will need people to manage more specialties. The generalists, who will be the architects and higher-level engineers, will define the problem. Once they have made the decision about what to do, then the specialists will take over. But there will also be a lot of feedback. This will be an iterative process. There will be meetings where you need to reconcile differences and make adjustments. There will be a lot of collaboration, and verification will start from the get-go.”

Verification strategies
There are two main approaches to verification. One is to verify the pieces. Another is to verify the system. Both are necessary, but the order in which they need to be done as part of a verification flow can vary greatly for even derivative chips.

Samta Bansal, 3D IC lead and silicon realization digital project manager at Cadence, said that in stacked die an incremental approach will be needed to do verification. “If you analyze it all together it overcomplicates the process,” Bansal said. “For one thing, not all of the pieces will be available at the same time. A more feasible approach will be to verify each chip in a stack as part of a verification flow, then focus on the microbumps, TSVs, LVS and DRC for alignment and ultimately create a single file.”

That’s not so simple, of course. In stacked die there are physical verification issues that can complicate the functional verification, notably stress and power. And there is now software that needs to be considered in the mix, with the trend toward an increasing portion of the stack.

“Functional and physical verification are both important but independent tasks,” said George Zafiropoulos, vice president of solutions marketing at Synopsys. “In both cases, verification is moving up in system complexity. We’ve gone from blocks to lots of blocks to lots of processes and I/O, and there is more stuff coming. Complex interface IP at the periphery of the chip has gone up by an order of magnitude. The design team can’t verify everything, though.”

Zafiropoulos said design teams used to think there was not enough time to do verification at the block level. He said that putting 100 blocks together increases the challenge exponentially.

“A lot of this is bottom up,” he said. “You build sub-circuits up to the chip and then in multiple chips. You can’t afford to have errors inside these blocks. But you also need to change the scope of what has to be done. In the past, one engineer could comprehend everything on a chip. Now we’ve gone from the guy who knows everything about a chip to teams that are in different companies and maybe different countries.”

The result, he said, will be a gradual change in three areas. First, more and more engineers will do verification, rather than just specific verification teams. Second, all engineers will become more software savvy. And third, new kinds of tools will be introduced, including formal approaches.

SLD: What’s changing in design?
McNamara: Software is a component that can’t be ignored anymore. It can’t be done later in the design cycle. The hardware-software co-design is a real problem—and a real opportunity. When you look at battery life, often it’s the software that has to be fixed. It isn’t the hardware. The software is now smarter and does more.
Subramaniam: As you go into smaller geometries you have more choices in terms of technology and complexity. There are more variables in the technology, different libraries that are available, more choices in terms of transistor Vt and channel length. If you look at the combination of what’s available to do a design, finding the optimal point in your design optimization is key. How do you optimize for power, performance and area all at the same time. Many people only see a small portion of the design space that’s available to them, but while it may be good enough for them it may not be the optimal solution.
Varadarajan: What’s changed is the increasing commonality between SoCs today. You see an ARM core, a GPU from ARM or Imagination, and DDRs. The challenge is how to improve the turnaround time for closure. These designs undergo a lot of derivatives over their lifespan, which are incremental changes. The real challenge is how you can close on a new derivative in 10% to 15% of the time it took to do the original design. What can you capture to achieve closure at the front end so every single design is not a complex back-end-to-front-end netlist handoff process? There are some customers going down that path already, putting in methodologies and mechanisms to ease that process.
Rey: There are a lot of tendencies and trends that require the tools to be faster and have new functionality, and the designers need to be aware of that to get an edge over their competition. In addition to that, there is also a need for portability. People don’t want to be tied to a single semiconductor manufacturer. They want more than one source. Designers need to be aware of that and be able to port their design to different places, and the tools need to be able to play in more than one place at the same level.
Zorian: There are two things going on. One is that complexity is going up, and the other is that shrinkage continues. On the complexity side IP usage is going up. It’s now 70% to 90% of a chip. But if you look at vertical markets, IP is not enough. These need to be grouped together into subsystems to improve re-use and reduce design time. On the shrinkage side, maintaining the health of the chip is a problem. The more we shrink, the more important our yields, quality, reliability and testability. We need to ensure those capabilities are available early on in our IP and our subsystems. You have placeholders, so as you move down you can shrink while maintaining the health of the chip.

SLD: How do we deal with all of this complexity? Is it a matter of raising the abstraction or do we need to deal with the problem differently?
Varadarajan: Abstraction is the key message. If you look at all the advancement over 20 years, physical synthesis still closes timing at the cell level. It places and routes standard cells and finally signs off on timing at the standard-cell level. That’s what designers trust, and it has to go down to that level today. Being able to have enough confidence at a higher level of abstraction and having global design closure with confidence is essential. Being able to predictably create subsystems and validate timing closure at that level, before you descend into the detailed implementation is essential.
Subramaniam: Abstraction alone is not enough. What you need in addition to that is an actual implementation of that abstraction. One of the reasons IP re-use has been successful, particularly in the analog and mixed-signal area, is that you have the abstraction and the actual implementation. You know that when you implement something it’s going to work. We need to extend that to the subsystem level. Today we have it at the individual IP block level. We don’t have it at the level of the subsystem. We need to create hardened or quasi-hardened models, so you can have an abstract view of that subsystem and also know how it will behave. You know its performance characteristics, its power characteristics and all the other critical characteristics. In 3D ICs, you might have pre-implemented version of subsystems that you can simply drop in. That makes derivatives simple. You have a common subsystem with a standard interface. It allows the designer to focus on one portion of a design, no matter what the technology node.
Zorian: I agree that having abstraction isn’t sufficient. You also need the ability to explore the different options and optimize between them. You need automation capabilities to explore those options and see what the best choices are. It may be 2D or it may be 3D. But with designs today you have so many ways of optimizing them. To explore that is very important.
Rey: On the implementation side, historically there were not robust methods to keep the abstraction level all the way down to the implementation. That is changing. You come up with IP, you know where you can stretch the limits of implementation, and you need to get those details down to the implementation. The foundries are jumping into that. It’s becoming mainstream. Think about keeping several different power domains. You need to make sure information moves all the way from the system level to GDS II to ensure you are not crossing from one power domain to another without the proper protection. That’s happening now.
McNamara: At each design level we need some way of modeling the design. Then we need a way of verifying the design is behaving the way we think it should behave, whether it’s functional or electrical. There’s a transformation stage, which we call synthesis, where you take that abstraction level and push it down to the next level, whether that’s RTL to gates to polygons. And then you have an analysis or extraction phase that takes information from that level and projects it up to a higher level of abstraction. We’ve all built tools that do pieces of that. But if we want to raise it to a higher level of abstraction we need to have a modeling language and a way of transforming it to the lower levels and abstracting information up. There is a system above every design node that just considers us as a component. That plays all the way from the transistor to the macro cell and up. As we look at increasing complexity, we have to tame this. We need a way of bounding these things and putting rules around them so the higher levels can abstract away that detail but also take advantage of the power. If you have too firm a rule that doesn’t let you take advantage of what the power can do, then you’re leaving performance, area or power on the table. It helps to think of this in four boxes. Do we have a modeling language? Do we have a way of verifying it’s correct. Do we have a way of projecting it to the lower level? And do we have a way of abstracting things up to a higher level?
Subramaniam: The modeling language should be able to address all the key attributes of the design. You need to be able to define a set of metrics for every design, and then you need to be able to look at all the different alternatives that are available for that design and translate each of those implementations into the metrics. Now, when you’re in the exploration phase, you can take a particular design and if you use this combination of transistors or this process from this foundry, what does it look like? That’s really critical as part of the exploration phase. Both tools and language are required for this exploration phase.

SLD: Is there a language that does this?
Zorian: We are going up in abstraction. TLM is a high-level description. That same IP has multiple levels of description. But what is being shared for exploration purposes is a transaction-level model. Once you decide to use it, you go down to the detailed models. But there’s a good exchange of information at that level.