Home Reviews Get On The Buss

Search

Get On The Buss PDF Print E-mail
User Rating: / 0
PoorBest 
Thursday, 24 December 2009 15:20

Wow, it’s been a while since we last had a good old techie talk about Specman so why not now? Today I’d like to focus on applying reuse to Specman external ports. Very much like little caterpillars, DUTs often have tens or even hundreds of pins which can usually be divided into groups and sub-groups based on their functionality. Certain sub-groups may form a bus - data bus, address bus, and so on - in which case it wouldn’t be as interesting to look at individual wires or pins as at the entire bus as a group.

When you add Specman to the picture, you will probably be tempted to use an external simple port defined as a uint with the size of the bus, be it a byte, word, etc. Actually, this is totally OK. But what happens if you have a group of signals that share the same functionality but have absolutely nothing to do with each other?

For example - your task is to verify the behavior of a group of 7 pins, each of which behaves as an output clock with a preset frequency (set by register). What is the most effective way to monitor and check all that in terms of code reuse?

You might be tempted to group these wires together in the top env. Like this:

extend my_env_u {
 clk_out_bus: out simple_port of uint(bits: 7) is instance;
 };

But I’m not sure if that would be so elegant. Remember - those pins have nothing to do with each other, what good will a 7-bit uint do?

You could try this:

extend my_env_u {
 clk_out0: out simple_port of bit is instance;
 clk_out1: out simple_port of bit is instance;
 clk_out6: out simple_port of bit is instance;
 };


But that smells a bit like a waste of code, doesn’t it?

What if we encapsulated the entire code required to verify a single pin (a lightweight eVC for each pin, if you will) and used a list of simple_ports in the top env instead? for example:

unit clk_out_pin_evc {
 // pointer to verilog port
 clk_out_p: out simple_port of bit; // only pointer, not instance
 
 // monitor
 
 // ptr to register
 
 // prot. checker
 };

And then in the env we’ll simply instantiate a list of ports, a list of evcs, connect them to each other and voila!

extend my_env_u {
 clk_out_port_l[7]: list of out simple_port of bit is instance;
 clk_out_env_l[7]: list of clk_out_pin_evc;
 keep for each in clk_out_env_l {
 it.clk_out_p == me.clk_out_port_l[index];
 };
 };

Now that’s more like it!

Oh, one more thing worth mentioning about using lists of ports - when you want to access (drive/monitor) an individual port within a list, remember to place the $ operator after the list index and not before. For example:

check that (env.clk_out_port_l[i]$ == 1);


To sum things up, the point I was trying to make in the simple example above is that smart encapsulation leads to efficient code reuse and eventually to a higher quality of your code (less code, clearer code, more organized structure and easier maintenance). So next time you meet a group of signals, ask yourself if what you’re dealing with is a buss or rather - a centipede

 

 

 

 

 

 

 

 
More articles :

» Top Level Verification - What's The Big Deal?

How to attack your chip from the top? Why is it so difficult to put together a good top level verification plan? Here are a few ideas.

» UVM Users: Here Are Some Great Tips [Video]

A couple of years ago I wrote here about how the UVM was becoming the next big thing in the verification world.And guess what? I was right. Not that it was too hard to predict... but anyway, the industry has finally standardized on language (SV) and...

» Let The New Game Begin

Things are changing. The EDA industry is changing, and the verification world is changing (check out Janick Bergeron's inspiring at SNUG San Jose for a glimpse of the future of verification). One of the major challenges we’re already facing today...

» Method Manipulation In SV and e

If you're familiar with SystemVerilog and taking your first steps in e (or vice versa) you might find this useful. Here are some of the most common method manipulations that you''ll need to master and how you should go about implementing them in e...

» Latest Buzz From The EDA & Verification Community

{loadposition pos101}{loadposition pos102}{loadposition pos103}{loadposition pos104}{loadposition pos105}{loadposition pos106}{loadposition pos107}{loadposition pos108}{loadposition pos109}{loadposition pos110}{loadposition pos111}{loadposition...

Add comment


Security code
Refresh

Copyright © 2018 Think Verification - Tips & Insights on ASIC Verification. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.