Feature Articles
EDA Taking Its Toll
Cadence’s Dan Holden pointed me to his blog entry that pointed to a YouTube video that Cadence’s CMO John Bruggeman made regarding the iPad’s new role as gatekeeper to content. He discusses this in terms of what he calls “tolltakers” and relates it to the need for the EDA industry to find new ways to get paid for the value they provide. This got me thinking about what it means to be a tolltaker. These thoughts don’t reflect specific support or repudiation of John’s comments, but rather spring from those comments and go on their own from there.
It’s no secret that the EDA industry has struggled to find ways to be paid fair value for the capabilities it feels it brings to semiconductor companies. Here’s how I could summarize an abstracted annual EDA negotiation: Read More
Attacking Constraint Complexity
Part 2 – E Soft and SystemVerilog Default Constraints
The growth in both the size and complexity of chips is driving greater use of constrained-random testing. As a direct result, the size and complexity of constraint problems are also growing, and with it the consequences of not just constraint-related mistakes, but of employing less-than-optimum strategies. This is all driving the need to understand constraints in order to get the most out of their capacity and overall performance potential. Part 1 of this article series [LAURA, PLEASE HYPERLINK “PART 1 OF THIS ARTICLE SERIES”] focused on verification IP reuse, examining how a solver typically interprets constraints and providing a constraint case study around a networking ASIC. Part 2 of this article series focuses on the SystemVerilog[1] E[2] and OpenVera[3] constructs that allow constraints to be disabled or overridden using a soft or default keyword.
This article will explore the similarities and differences, including subtle semantic differences, between E Soft Constraints and OpenVera Default constraints in the interest of optimizing constraint performance and speeding validation. Test writers must be aware of the constraint semantics and the constraints present in the VIP and testbench environment in either SystemVerilog, OpenVera or E. Without such knowledge, confusing constraint failures or incorrect test stimulus are likely to occur. This results in significant debug to find the root cause, and, with it, the likelihood that a design team will incur greater development costs and also miss critical deadlines. For this reason, understanding the differences between soft and default constraints types is critical to successful validation.
Yet Another Parallel Approach
PrimeTime Gets Multi-threading
It’s no secret that EDA tools that process billions of transistors have a lot of work to do and can take a really long time to do it. It’s also no secret that having multiple computers do much of that work in parallel should be an obvious way to speed things up.
What is surprising, then, is the number of different approaches that have been taken to making parallel algorithms work. Which says that, as obvious as multi-processing looks, how to get there is not obvious.
There are two classic ways of pulling apart – or “decomposing” – a program if you want to exploit opportunities for parallelism. The first is to pull apart the data and have multiple machines do the same thing to different clumps of data. The other is to separate out the tasks and have different machines do different tasks. In practice, some methodologies rely on a bit of both.
Attacking Constraint Complexity
Part 1 Verification IP Reuse
As chip design becomes larger and more complex, verification engineers are expanding constrained-random testing to meet the validation demand. Yet this expansion in the use of constraints creates a new set of challenges. Because the size and complexity of constraint problems are growing, verification engineers now also face verification performance and capacity issues. As a result, it is no longer enough to write constraints that simply function to validate a design. Today, verification engineers must also optimize the constraints they write for performance if they wish to have any hope of both successfully validating their design and meeting their deadlines. A scalable methodology for writing constraints and maintaining performance is increasingly becoming a necessity as more engineers write and debug ever-increasing amounts of larger, more complex sets of constraints.
This two-part article series looks at a scalable constraint methodology and provides an overview of some of the key constraint optimization challenges and strategies of concern to verification engineers. Part 1 of this article series focuses on verification IP reuse—detailing how a solver typically interprets constraints and providing a case study focused on a constraint-driven performance optimization strategy with respect to the flexible packet parser of a hypothetical networking ASIC. Part 2 of this article series focuses on SystemVerilog and OpenVera constructs and the significant impact on validation performance that can result from the differences between E Soft Constraints and OpenVera Default constraints.
IP Outlook
Cautiously Optimistic
For aspiring historians, a topic that regularly causes concern is that of history and memory: surely first-hand eye-witness reports of an event have to carry greater evidential weight than documents? But documents are static, and human memory can be fragile: it can change and evolve. Take a fisherman who catches a big fish - as he tells the story over the years, the fish gets bigger and the fight longer.
Lord, grant that I may catch a fish so big that even I, when speaking of it afterwards, may have no cause to lie.
Threading the Needle
Imagination Technology’s META Processor Gets Clever with Threads
The IP business is a wild and wooly place. There have been a lot of casualties as companies have tried to figure out how to make money saving other companies time. And time equals money. Should be a simple concept, but it’s amazing how hard it can be to get someone to spend money in order to save money. Somehow it always just feels like spending money.
So the market has shaken out a bit, but, in that process, no IP component has ascended to the same lofty heights as the processor. It becomes the critical first decision, and all other decisions flow from that. Not only does a processor decision drive the other architectural and IP choices for a chip under design, it also drives future versions of that chip because of the software legacy that gets established, making it hard to change later. And it drives a huge ecosystem of tools and accompanying IP providers that must tailor their offerings to the processor.
Grappling with Intuition
Everyone likes to think their tool is intuitive.
Wait, let me restate that.
Everyone wants their customers and prospects to believe that their tool is intuitive. Whether it actually is or not doesn’t matter if everyone believes it is. Welcome to marketing.
The intuitiveness wars play out most visibly in the desktop space, with one camp claiming exclusive rights to intuitiveness. However, I have sat down many times in front of a Mac and not had a clue as to how to proceed next. I was able to learn quickly once someone explained it, but it wasn’t intuitive. And does anyone wish to try to convince me that the following iPod operations are intuitive? To wit: “to play music, press the play button. To stop playing music, press the play button for longer.” I don’t think so.
On the Radio
Agilent’s Approach to RFIC
It’s hard to tell if it’s a businessperson’s dream or nightmare market. Imagine a large market, a huge market, a market that spans the world. A market that starts with a device and spawns an entire ecosystem of tools, services, and accessories. A market where the technology starts out complex and just gets harder from there, making it difficult to enter but helping to keep interlopers out. A market where competition is fierce and windows of opportunity are tiny. And where the life of a given product is short and must be immediately followed up with the next version. Where prices need to be low, performance high, and battery life long. And where more types of technology need to play nicely together in a smaller space than in any other application. And where the device itself has to play nicely with its neighbors, like the TV, radio, or cockpit controls.
Bringing Together Two Points of View
He had been following this guy for about five miles, and his legs were starting to get tired. But he couldn’t let that distract him; if he were noticed now, it would blow the entire investigation. Hanging back just a bit in the shadows, he gave up some distance and then started forward again. But, from around the corner, a policeman stepped in front of him and in a slightly suspicious, insinuating tone, asked, “Est-ce que je vous pourrais aider, peut-être?”
Reflexively, he pulled out a badge and said, “Ik ben rechercheur met…” and then realized that this wasn’t going to work. He wasn’t in Flanders anymore; he had crossed into Wallonia. And even though “rechercheur” came from French, it would carry implications more of research than detective work, and, even if understood, his Walloon counterpart wouldn’t be willing to acknowledge any such understanding, given its contamination by Dut… er… Flemish usage.