Monday, April 16, 2007, 07:17 AM - Hardcore verification
The new version of Mentor’s cookbook (2.0) is several months old by now, and would probably be soon replaced by a new one, but only this last month I had a real chance of giving it a through reading, and of doing some real work with the AVM. I have plenty of thoughts I would like to share, with you my readers, and with anyone from Mentor who gets over this website name:-). I know there are slim chances these would get to the right place at the right time, but I’m ready to give it a try anyway. After all, this had partially worked with Cadence before…
Let me begin by saying that Mentor gets my complete and utter respect for open-sourcing their AVM, and that I hope they will see it pay. It has been quite a nice experience to be able to just wonder through the source code when I couldn’t understand how certain parts work. The source code is, by the way, is thoroughly commented and in general written in a very clear way. I would like to see the open-source approach taken several steps ahead, though…for example, I couldn’t find any forum/blog or another type of public stage to voice whatever I have to say. In the lack of any of these, I had to place it here. Or, an even crazier idea: why not try and place it under some sort of a GNU licensing scheme?
Ok, enough day dreaming let’s get to the ground again. Here are two other general comments I have, before I get to the contents themselves. First, there got to be some way to save us the trouble of reading the whole cookbook from beginning to end every time a new version is released. I’ve read the first version and now the second one. I don’t want to read anything but the parts that have changed in the third…is there some way of arranging that? With all due respect, the only book I’ve read three times in my life is “the catcher in the rye”, and I don’t think the cookbook is quite there yet. Second, I don’t know what political reasons are driving Mentor to put SystemC into the cookbook as well, but I really don’t think there are that many people that can learn how to do things with two languages at the very same time. SystemVerilog is hard enough, so there is really no need to make readers even more confused by with random SystemC code snippets every now and then. If SystemC is that important, let it have its own book. If it isn’t then just drop it out.
And now for the content…here’s my main problem with the cookbook and the AVM library in one sentence: They put way too much emphasis on how testbench elements should be connected and way too little emphasis on the elements themselves. Reading the cookbook you often get the impression that connecting the generator and the driver, or the driver and the scoreboard, in a reusable decoupled way, is more important then the generator, the driver and the scoreboard themselves. It is not. Don’t get me wrong – it is quite important to know how to connect things, but it is surely not the first thing on your mind when you build a testbench, and it is not the most important one.
I really wouldn’t mind this exaggerated attention if only such common testbench elements as generators and scoreboards did get a decent place. The problem is they don’t. While the two first real-meat chapters (4,5) are dedicated in full to FIFOs, analysis port and interfaces, scoreboards and coverage get only a single chapter. Generators get their own chapter, but only a way too simplified example. Given that disproportionate division, no wander that the cookbook is (almost) mute about some of the hardest methodological problems: Try to find any example of complex data modelling (for example packets with several subtypes), of how to write a non-trivial generator that generates such subtypes, of complex data checking in a scoreboard, of coverage of several subtypes – you will find some hints here and there, but no real serious discussion. In fact the only example of a real class factory I could find is in the old cookbook version, under one of the domain examples.
Generally speaking, the examples provided with anything not related to connecting things are a bit too simplistic and shallow for my taste. True, an ideal example should be simple, but it also (and that’s the important part), should be able to convince the audience that they really do need the special capabilities that your tool has. If I had to buy a CRV tool based on an example that randomises an 8 bit address and 32 bit data packet, I’m not sure I would.
Also, at least one of the examples, the one that shows error generation, is simply outright wrong, and I’m surprised it made it past the editors to the second version. In fact, it’s a clear demonstration of how an error generation should not be done, because the errors in the data are inserted by the physical level driver, while they should have been inserted by the higher level generator. The only errors that should ever be inserted by a physical level BFM are protocol errors, never data errors.
On the connection and communication parts I’ve only this to say: I wish Mentor would put the same amount of thought and serious work into the other testbench parts as well. The only thing that did bother me a little bit was the ambiguous use of the term “interface”. As the cookbook itself notes, this term can have one of three meanings: (a) an SV interface as defined by the SV LRM (b) a reference to such an interface or (c) the object oriented concept of a virtual base class, which has nothing to do with the other two meanings. Unfortunately, when the word is used in the text, the authors seldom bother to clarify which one of the three they refer too. As far as I could tell, (a) and (b) are only used when some real DUT pins are involved, while in all other cases the term refers to (c). This goes very well with my own assumption that you would do better to keep SV interfaces out of any high-level code, because they simply have no added value there, plus, they don’t support inheritance.
Having said all of that, I still think that the cookbook is a tremendous piece of work, a big step in the right direction, and a must read for anyone who intends to work in verification in an SV era. It taught me a lot, and I’m sure it will teach you as well, plus you can find there many hidden treasures like the parts that are dedicated to random stability (just compare this with the absolute silence of Cadence about Specman’s random stability) and those where programming patterns (prototype, class factory, wrapper) are explained.
And any of my readers who would like to add their thoughts about the cookbook are of course invited. As I said, that’s the only (small) public space available…
| permalink
Thursday, March 15, 2007, 03:40 AM - Hardcore verification
Here's a short tip that I should have written long time ago. Say you are me at this very moment, and you have to run the an AHB eVC environment through a remote connection on a quite slow server. Say you're also done reading all your local newspapers over the internet, and waiting for 3 minutes for the whole AHB packege to load every time you change the very last top configuration file starts driving you out of your mind. In that case, you could do a simple thing...you just load the AHB eVC files, then save, then load your top configuration file. The next time instead of using reload you can just use restore, and then load your top file. Here's an AHB eVC example, but of course this could be done with any other package that takes time to load:
load vr_ahb/e/vr_ahb_top; #load the package
save vr_ahb_top.esv; #save specman state to file vr_ahb_top.esv
load e/ahb_config; #load your own configuration on top
test;
next time instead of rel:
restore vr_ahb_top.esv;
load e/ahb_config;
test;
If you are using several packages or eVCs on a regular basis then the best way would be just to load the top files of all of these packages and then save. For example, say you're using AHB and vr_ad eVCs:
load vr_ahb/e/vr_ahb_top;
load vr_ad/e/vr_ad_top;
....other eVCs come here
save my_evcs.esv
In fact, every specman release comes with a .esv file that includes the packages and eVCs that are built in into Specman (such as erm_lib) so that these packages are loaded seemlessly when you start Specman.
| permalink
Friday, March 2, 2007, 03:55 PM - Hardcore verification
A friend of mine who is in verification business just like myself, but just unlike myself, is a sworn user of file stealing software, such as the one named after a pack animal, reports a strange phenomenon: no later than three months after a new Modelsim or Questasim version is released, it is available for download on the net, along with a full feature license generator. According to him (lets make “him” “her” so that it would sound more reliable)…So, According to her, this has been happening regularly, at least for the last couple of years. She also noted a curious sentence that often appears in the license generator instructions, and says something like “This commercial product is provided for evaluation only. If you like this software buy it!”. Now who said honest, law biding hackers do not exist?
So far for the facts, and now for the interesting part: My friend, who is an amateur of conspiracy theories, swears that none other then Mentor themselves are behind this. For the moment, lets ignore the fact that she believes the Mosad is behind 911, and that UFOs killed JFK, and concentrate on the arguments she brings to support her case. These are quite simple in fact: According to her, it is absolutely impossible that someone had been stealing Mentor’s software and cracking up their licenses for so long without being caught…its even less probable that this bitter illusive anti-mentor type, would urge people to buy the software “in case they like it”. Quite convincing ah?
Remains one riddle to solve, the toughest of them all…what would be Mentor’s motive for performing such an apparently suicidal act? My friend smiles and gives me a pitiful look “suicidal? Why is that?”. Why in fact? The only clients that Mentor can possible lose, are small contractor companies, with 1-2 persons max, because these are the only ones that would take the chance of using the software illegally (well they could always claim they didn’t "like it" in the first place). Above that number it becomes too risky – who knows when some frustrated ex-employee will turn into a rat and decide to open up his trap at the wrong place? On the other hand, Mentor gets to publicize its products among all these people who are almost working in verification/design but are not there yet – students and the like. How many times did I have to disappoint people who asked me where they could download Specman evaluation software from? So, considering the risk and the potential gain, my friend sees Mentor’s motive as an established fact.
And now, she says, let me show you why it must have been an ET who shot JFK…
| permalink
Back Next
