Monday, October 19, 2015, 12:59 AM - Hardcore verificationFinding a good EDA problem to solve is not easy: it needs to be of interest for enough customers, not too easy that anyone can solve it, and not too hard that it will require years of investment. As a solution architect in a big EDA company, I can say they come at a ratio of about 1 in 10 at best: Disconnected as we are from what our customers really do, we are inclined to follow wishful, megalomaniac, solved or non-existent problems. The ISO 26262 safety automotive standard presents one problem, which is neither too easy nor too hard, and that combined with the coercive power standards often come to possess might become a challenge for quite a few customers. IMHO, it is the 1 in 10 weíve been waiting for.
Reluctant to take my word for it? check for yourselves. Open part 5 of the standard where random hardware fault analysis is discussed, and read carefully through it a few times. At a high level, this section describes the procedure IC engineers need to follow in order to prove that random hardware faults canít cause safety critical functions of their design to fail. At a low level, some of the technical details might bring DFT to your mind, but donít be tempted to follow this superficial resemblance too much. Yes, random hardware faults can be caused by production, but they can be caused by a variety of other reasons as well, and those can well occur long after the IC has left the fab, and even while it is running. Hence, unlike production faults that could basically be ignored by front-end IC flow, random hardware fault analysis is very much a front-end problem.
Abstracting from the gory details, this analysis requires that the probability of any fault to violate safety requirements is determined. This might seem simple at a first glance, but is far from it, and requires high level of integration between various tools/techniques: formal analysis to reduce fault population, coverage databases to prioritize faults according to risk, fast simulation and emulation engines to run selected faults, and a way of merging results from all these together in an ISO friendly way. Companies best positioned to solve this problem are those in possession of engine independent stimuli, debug and analysis platform and a strong vision of pursuing this consolidation. If youíre an automotive customer of such company, you should help it understand solving this problem is a win-win.
Meanwhile, in the absence of a good enough solution and sufficient analysis capabilities, customers are obliged to over-design. When you have no way of making sure your safety mechanisms are good enough, you just add more of them. Obviously, this comes at a high cost in RnD and silicon area, and can easily lead to schedule slips. The first EDA company to solve their analysis problem, will get to keep a good chunk of that over-design cost. And if that doesnít turn this problem into a good one, then I donít know what will.
Saturday, April 7, 2012, 07:51 AM - Hardcore verificationThis is an experiment, that I'm mainly conducting to help myself. In the next weeks/months I hope to start uploading SystemVerilog code and examples that are available on the web. UVM-1.1, which I luckily saved on my laptop before it went off the web, is the avant-garde.
One of the most useful pages is of course, UVM's own help, which is available here. This is the respective page for OVM.
Many thanks to Sandy Hefftz for her help with this one.
Friday, April 6, 2012, 03:57 AM - Hardcore verificationIn the latest months all my writing energy, in fact, all my energy, was consumed by two DVCon papers, that I can now share with you. The first, is about SV and UVM random stability, a subject which, surprisingly enough, no one ever wrote about in the past. It opens with a crash course on random stability in SystemVerilog, and then moves on to explore UVMís random stability infrastructure and some problems and possible solutions. If youíre looking for some more user-friendly material than IEEE-1864 and the non-existent UVM documentation on the subject, you are in the right place.
The second paper was harder and more demanding to write, but Iím sure some of this blogís readers will find it helpful as well. It deals with e/eRM to SV/UVM migration, and will help anyone who is about to go through this process understand better the challenges, and plan for the best solutions upfront. It contains many cool tips and code examples that show how to implement them. It will also help you do your SystemVerilog signal mapping just like you used to do when you were using Specman/e (i.e. by specifying strings to ďhdl_path()Ē, with a package that Iím especially proud of.
You can find both paperís here:
UVM Random Stability - don't leave it to chance
e/eRM to SystemVerilog/UVM - mind the gap but don't miss the train
And hereís the poster I prepared for the random stability paper presentation, just in case youíre looking to replace Elvis on your bedroom wall:
UVM Random Stability poster