You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

Another Application of Automated RTL Editing

DeFacto and their STAR technology are already quite well known among those who want to procedurally apply edits to system-level RTL. I’m not talking here about the kind of edits you would make with your standard edit tools. Rather these are the more convoluted sort of changes you might attempt with Perl (or perhaps Python these days). You know, changes that need to span multiple levels of hierarchy, looking for certain types of block, then adding, removing or changing connections which also cross hierarchy. Technically possible with custom scripts perhaps but these can get really hairy, leaving you at time wondering if you’re battling on out of a stubborn refusal to quit or because that’s really the best way.

DeFacto originally got into this space in support of DFT teams who need to add and connect complex BIST logic which may have to be reconfigured on new RTL drops and reconfigured again on floorplan changes. Their big value-add is in making these edits easily scriptable without demanding that you tie yourself in knots figuring out hierarchy implications. Since they can edit RTL, and such needs are common beyond DFT, their customers have expanded use of these tools into many other applications, each of which needs at least a subset of those complex find, restructure, edit, re-stitch and similar operations.

One such use-model was announced recently – using scripted editing to trim down SoC RTL in order to greatly accelerate simulations. The design application in the case was in graphics, a domain which has lots of repeated block instances, in common with quite a lot of other applications like networking. Also in common with those applications, these designs tend to be huge. Now imagine you have to simulate this monster – yes, simulate, not emulate or prototype. Why on earth would you do that? Lots of reasons – you have to include AMS in your verification, you have to do 4-state modeling (0, 1, X, Z), you need to do on-the-fly debug, it’s faster to experiment in simulation, or maybe acceleration hardware is tied up on another project. But compile and simulation on the full core/chip will take forever.

Fortunately, a lot of verification objectives don’t require the simulator to swallow the whole design. You can trim repeated instances down to just one or a few instances, replacing the rest with shell models. But this isn’t quite as simple as black-boxing. First and most obviously a black-box outputs will float at X, which will mess up downstream logic. So at minimum you have to tie these outputs off, inside the black-box.

But even that isn’t quite enough. Integration logic often depends on handshake acknowledgement. If I send you a req, you better respond with an ack at some point, otherwise everything locks up. So now you have to add a little logic (again inside the black-box) to fake that req-ack handling. And so on. The shell starts to accrete some logic structure just to make sure it behaves itself while you focus on the real simulation. This may extend to keeping whole chunks of a logic block while removing/tying off the rest. So much for simple black-boxing.

This is a perfect application for the DeFacto toolset, as Synapse Design observed in their endorsement of STAR. They found that some simulations they were running would take 3 weeks – each. But many of the sims only exercised subsets of the system, in some cases only needing certain instances in a repeated set, in others requiring only a part of the functionality of a module. By intelligently exploiting scripted edits over the design, they found they were able to reduce these simulation run-times by 4X (in one case by 5X). That’s a pretty huge advantage in getting to verification closure.

I’m a strong believer in this kind of scripted RTL editing/manipulation. There are many tasks through design and verification (and touching even implementation) which beg for automation but don’t easily fall into canned solutions. Many design teams hack scripts or simply accept they can’t do better when they hit these cases. There is a better way which doesn’t constrain your ingenuity and control but does automate the mechanical (and very painful) part of the job. Check it out.