Many design problems do not become apparent until timing analysis has been performed following extraction of realistic physical values based on the actual place and route. This may result in numerous time-consuming iterations, which can so delay a design that it completely misses its time-to-market window. (In many cases, there is only room in the market for the winner, and there's no such thing as second place!)

The answer is to create a silicon virtual prototype (SVP), which can be quickly generated and which contains sufficient information to be able to support global decisions. This allows engineers to explore design alternatives and provides a high level of confidence that timing and performance goals can be achieved. The time taken to iterate a design using an SVP can be measured in hours - as opposed to days/weeks or weeks/months using conventional physical synthesis or legacy flows, respectively.

Figure 1 - Silicon virtual prototype flow

SVP approaches can have their own problems
By modeling physical effects at a high level of abstraction very early in the process, an SVP can eliminate costly iterations later in the flow resulting in faster time-to-market. Unfortunately, some existing SVP-generation flows can introduce their own errors, resulting in back-end correlation problems that negate the advantages of using an SVP in the first place.

One key problem is that, as conventional synthesis tools consume too much time and computational resources to meet the speed demands of prototyping, many SVP-based flows make use of a "fast and dirty" synthesis engine.

Figure 2 - "Fast and dirty"

This "fast-and-dirty" synthesis tool is typically based on completely different algorithms to the main engine - for example, direct RTL mapping - which means that the ensuing gate-level netlist used to form the SVP is not an accurate representation of the design's final implementation.

In turn, this means that once the SVP has been used to perform RTL exploration and timing analysis, engineers still have to perform a full-up logic synthesis using a completely different synthesis engine in order to generate the real netlist to be passed on to physical implementation. Thus, in the case of this SVP-based approach, the prototyping tools and their methodologies are separate from the implementation tools and their methodologies. This leads to unpredictability of design convergence due to lack of correlation, which can result in time-consuming back-end to front-end iterations. As I previously noted, this sort of defeats the whole purpose of using an SVP in the first place!

One rather cunning SVP approach
Of course everyone is aware of the above problem and lots of EDA companies are enthusiastically beavering away on solutions that (they hope) will leap up, clamor for our attention, and take our breath away. One interesting little rapscallion is Blast Prototype from Magma Design Automation. Earlier this year, in my "Max Bytes" column entitled "How Magma Makes Timing," I talked about Magma's gain-based synthesis and fixed timing concepts. As you may recall, the idea is that a fixed timing plane is established very early in the process, and that the physical implementation tools work within this plane.

This means that all timing optimizations are completed and all circuit delays are determined and frozen by the end of the synthesis step. Later, when Magma's placement engine performs its task, it uses a size-driven algorithm in which all of the cells are dynamically sized to meet their timing budgets based on the actual loads they see. Following placement, a load-driven routing engine is used to tune the width and spacing of the interconnect so as to maintain the original timing budgets and to ensure signal integrity.

One key point about Magma's approach is that the amount of computer memory and computational effort required to perform gain-based synthesis is a fraction of that demanded by conventional synthesis tools. This means that a gain-based synthesis engine can synthesize several million gates at once (Magma claims a 10x increase in capacity over conventional synthesis solutions).

"But what about designs containing as many as 10 million gates?" you cry! Well, one component of Blast Prototype is Blast Create. This little scalawag takes the RTL for the design (in Verilog or VHDL), the SDC timing constraints, and a top level floorplan (containing any important fixed structures such as pad locations and the positioning of large macros) and outputs an SVP.

One key point here is that Blast Create incorporates Magma's gain-based synthesis engine. This means that the SVP netlist generated by Blast Create can be passed to the back-end implementation tools as-is, and there is no need to perform a separate logical synthesis step. This SVP netlist can be fed to third party place and route tools if required, but the advantage of staying in the Magma flow is that both the prototyping and implementation environments are based on the same algorithms, tools, and methodologies. This provides high correlation, predictable design convergence, and dramatically reduces any time-consuming back-end to front-end iterations.

Another key point is that Blast Create can generate an SVP for extremely large designs in a single pass. This high capacity is possible because Blast Create uses the concept of "clusters" as a basis for its placement decisions. The way in which this works is that Blast Create automatically gathers groups of cells into clusters. Each cluster typically consists of tens to hundreds of cells, which means that they are small enough to preserve the overall placement quality. However, the fact that the number of clusters is orders of magnitude smaller than the number of cells provides extremely significant runtime improvements.

Figure 3 -- Portion of an SVP showing clusters (small rectangles) and macros/IP (large rectangles)

The actual number of cells may vary from cluster to cluster so as to keep the areas of the clusters as uniform as possible. In order to streamline computational complexity and capacity requirements, optimization and analysis is performed on the clustered data. Furthermore, in cases where two clusters are linked by multiple wires (which is a common occurrence), these wires are considered to be a single "weighted" wire for the purposes of estimating routing resource utilization, which has an effect on cluster placement.

Of course there's much more to all of this than we have the space to discuss here, but I'm sure that the folks at Magma would be happy to talk your ears off if you call or email them for more information. And I'm also sure that there are lots of other cunning SVP approaches lurking around waiting for their chance in the limelight (if you know of one, please feel free to get in touch with me, and I'll be more than happy to peruse and ponder it and write a column on it in the future). And so I bid you adieu. Until next time, have a good one!

Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.