Can somebody please educate me why we need DPI-C function import to do UVM specific functions like uvm_hdl_force or uvm_hdl_deposit even when force and deposit system verilog constructs exist? What extra flexibility does the C functions give with these regards?
Thanks in advance
There's no deposit functionality in SystemVerilog, only force. Although most tools give you deposit functionality, there is no standard way to deal with it. The DPI-C give you a tool independent method.
UVM REG gives you the ability to look-up registers by string name, and build paths from string hierarchies. Although there are ways of creating this functionality without resorting to the DPI/VPI, it's far easier to use the VPI.
If your DUT is VHDL, there is no standard for interoperability between standards with hierarchical references across language boundaries.
Related
SystemVerilog interfaces have really simplified my FPGA designs. They allow me to route many signals to multiple blocks in logical groupings. I really like them. I use them with modports to indicate the in/out directions. In the two books I've read on SystemVerilog, interfaces are introduced and the syntax is shown before modports. At the end of the chapter/section, modports are introduced as a helpful way to use interfaces. As far as I can tell, I would never use an interface if the concept of a modport did not exist. So, this brings me to my question...
Are there usage cases for interfaces that make sense without using modports?
The usage case could be in implementation/synthesis or in verification/simulation. I'm mostly curious to learn something new here about interfaces. I looked for related questions but didn't see any.
modports are intended for tools (like synthesis) that compile a design with boundaries that require direction information. If you flatten out the hierarchy with an embedded interface, there's no need for directions. Simulation tools almost always do this, so interfaces used just for verification do not need modports.
Some people put modports in interfaces for verification as a way of restricting access to certain signals, but unfortunately, many simulation tools do not enforce the direction, especially when used with a virtual interface.
I see a lot of articles which talk about whether you should be using field macros.
General guideline is:
`uvm_do... macro:
Can be used, but try to avoid if you are lazy.
`uvm_field... macro:
Avoid like the plague.
Sure, people also tell not to use
`uvm_component_param_utils...
`uvm_object_param_utils...
But i cannot seem to find what anyone thinks about the
`uvm_component_utils...
`uvm_object_utils...
Should they be avoided? Or they can be used without much issues?
Thanks :)
The *_utils macros do not introduce any performance penalties. They do save some typing and may reduce typographical errors, but I wish people would learn the code behind the macros before using them. See http://go.mentor.com/mcem
I taught my first ever UVM course this week (with the Doulos CTO - John Aynsley - sitting in as backup). In his assessment of my performance, he said this about macros, which I'm sure he won't mind me repeating:
`uvm_component_utils and friends - a good thing
`uvm_do and friends - a bit naughty
Field macros - evil
I always use uvm_field_ and uvm_object_utils/uvm_component_utils macros. They provide a lot of nifty features.
One feature I love: The uvm_component will automatically get the variable for you from the uvm_config_db if you use uvm_field_* to register it.
For example:
class myclass extends uvm_component;
bit enable;
`uvm_component_utils_begin(myclass)
`uvm_field_int(bit, UVM_ALL_ON) // UVM_READ_ONLY wouldn't work for this feature
`uvm_component_utils_end
virtual class build_phase(uvm_phase phase);
super.build_phase(phase);
endclass
virtual task run_phase(uvm_phase phase);
if (enable) begin
// blah blah
end
endtask
endclass
To set bit enable, all you have to do in a class that is at a higher hierarchichal level is uvm_config_db(int)::set(this, "path/to/class", "enable", 1)
There is no need for any "get" in the class itself. Kinda neat...
I don't think you can work around these two macros.
`uvm_component_utils...
`uvm_object_utils...
These two set up the factory. If you don't use them, you have to write the same few lines of tedious boiler plate code in every one of your uvm_object or uvm_component.
uvm_component_param_utils
uvm_object_param_utils
is just the same as the previous two, you need to use them when your uvm_object or uvm_component has parameters. I found having parameters in uvm_object/uvm_componet is handy in some case, but I know some one think it is a bad idea. But that's another debate.
Personally, I avoid the uvm_do macros, I prefer to create and randomize my seq_item with full control, then use `uvm_send (which is just some boiler plate sequencer book keeping)
I took the Doulos training and I remember they said avoid the uvm_field macros. Somehow I just have a feeling that the uvm_field macros is kind of complicate, so they simply avoid teaching it because we don't have enough time.
The uvm_field macros are VERY useful, specially if you build your own uvm_comparer. Whether or not to implement your own do_copy, do_print function is a matter of taste, but the uvm_comparer is really useful. I recommend you always use the uvm_field macros
A friend of mine needs to implement some statistical calculations in hardware.
She wants it to be accomplished using VHDL.
(cross my heart, I haven't written a line of code in VHDL and know nothing about its subtleties)
In particular, she needs a direct analogue of MATLAB's betainc function.
Is there a good package around for doing this?
Any hints on the implementation are also highly appreciated.
If it's not a good idea at all, please tell me about it as well.
Thanks a lot!
There isn't a core available that performs an incomplete beta function in the Xilinx toolset. I can't speak for the other toolsets available, although I would doubt that there is such a thing.
What Xilinx does offer is a set of signal processing blocks, like multipliers, adders and RAM Blocks (amongst other things, filters, FFTs), that can be used together to implement various custom signal transforms.
In order for this to be done, there needs to be a complete understanding of the inner workings of the transform to be applied.
A good first step is to implement the function "manually" in matlab as a proof of concept:
Instead of using the built-in function in matlab, your friend can try to implement the function just using fundamental operators like multipliers and adders.
The results can be compared with those produced by the built-in function for verification.
The concept can then be moved to VHDL using the building blocks that are provided.
Doing this for the incomplete beta function isn't something for the faint-hearted, but it can be done.
As far as I know there is no tool which allow interface of VHDL and matlab.
But interface of VHDL and C is fairly easy, so if you can implement your code(MATLAB's betainc function) in C then it can be done easily with FLI(foreign language interface).
If you are using modelsim below link can be helpful.
link
First of all a word of warning, if you haven't done any VHDL/FPGA work before, this is probably not the best place to start. With VHDL (and other HDL languages) you are basically describing hardware, rather than a sequential line of commands to execute on a processor (as you are with C/C++, etc.). You thus need a completely different skill- and mind-set when doing FPGA-development. Just because something can be written in VHDL, it doesn't mean that it actually can work in an FPGA chip (that it is synthesizable).
With that said, Xilinx (one of the major manufacturers of FPGA chips and development tools) does provide the System Generator package, which interfaces with Matlab and can automatically generate code for FPGA chips from this. I haven't used it myself, so I'm not at all sure if it's usable in your friend's case - but it's probably a good place to start.
The System Generator User guide (link is on the previously linked page) also provides a short introduction to FPGA chips in general, and in the context of using it with Matlab.
You COULD write it yourself. However, the incomplete beta function is an integral. For many values of the parameters (as long as both are greater than 1) it is fairly well behaved. However, when either parameter is less than 1, a singularity arises at an endpoint, making the problem a bit nasty. The point is, don't write it yourself unless you have a solid background in numerical analysis.
Anyway, there are surely many versions in C available. Netlib must have something, or look in Numerical Recipes. Or compile it from MATLAB. Then link it in as nav_jan suggests.
As an alternative to VHDL, you could use MyHDL to write and test your beta function - that can produce synthesisable (ie. can go into an FPGA chip) VHDL (or Verilog as you wish) out of the back end.
MyHDL is an extra set of modules on top of Python which allow hardware to be modelled, verified and generated. Python will be a much more familiar environment to write validation code in than VHDL (which is missing many of the abstract data types you might take for granted in a programming language).
The code under test will still have to be written with a "hardware mindset", but that is usually a smaller piece of code than the test environment, so in some ways less hassle than figuring out how to work around the verification limitations of VHDL.
Maybe its because I've been coding around two semesters now, but the major stumbling block that I'm having at this point is converting the professor's project description and requirements to actual code. Since I'm currently in Algorithms 101, I basically do a bottom-up process, starting with a blank whiteboard and draw out the object and method interactions, then translate that into classes and code.
But now the prof has tossed interfaces and abstract classes into the mix. Intellectually, I can recognize how they work, but am stubbing my toes figuring out how to use these new tools with the current project (simulating a web server).
In my professors own words, mapping the abstract description to Java code is the real trick. So what steps are best used to go from English (or whatever your language is) to computer code? How do you decide where and when to create an interface, or use an abstract class?
So what steps are best used to go from English (or whatever your language is) to computer code?
Experience is what teaches you how to do this. If it's not coming naturally yet (and don't feel bad if it doesn't, because it takes a long time!), there are some questions you can ask yourself:
What are the main concepts of the system? How are they related to each other? If I was describing this to someone else, what words and phrases would I use? These thoughts will help you decide what classes are useful to think about.
What sorts of behaviors do these things have? Are there natural dependencies between them? (For example, a LineItem isn't relevant or meaningful without the context of an Order, nor is an Engine much use without a Car.) How do the behaviors affect the state of the other objects? Do they communicate with each other, and if so, in what way? These thoughts will help you develop the public interfaces of your classes.
That's just the tip of the iceberg, of course. For more about this thought process in general, see Eric Evans's excellent book, Domain-Driven Design.
How do you decide where and when to create an interface, or use an abstract class?
There's no hard and fast prescriptions; again, experience is the best guide here. That said, there's certainly some rules of thumb you can follow:
If several unrelated or significantly different object types all provide the same kind of functionality, use an interface. For example, if the Steerable interface has a Steer(Vector bearing) method, there may be lots of different things that can be steered: Boats, Airplanes, CargoShips, Cars, et cetera. These are completely unrelated things. But they all share the common interface of being able to be steered.
In general, try to favor an interface instead of an abstract base class. This way you can define a single implementation which implements N interfaces. In the case of Java, you can only have one abstract base class, so you're locked into a particular inheritance hierarchy once you say that a class inherits from another one.
Whenever you don't need implementation from a base class, definitely favor an interface over an abstract base class. This would also be handy if you're operating in a language where inheritance doesn't apply. For example, in C#, you can't have a struct inherit from a base class.
In general...
Read a lot of other people's code. Open source projects are great for that. Respect their licenses though.
You'll never get it perfect. It's an iterative process. Don't be discouraged if you don't get it right.
Practice. Practice. Practice.
Research often. Keep tackling more and more challenging projects / designs. Even if there are easy ones around.
There is no magic bullet, or algorithm for good design.
Nowadays I jump in with a design I believe is decent and work from that.
When the time is right I'll implement understanding the result will have to refactored ( rewritten ) sooner rather than later.
Give this project your best shot, keep an eye out for your mistakes and how things should've been done after you get back your results.
Keep doing this, and you'll be fine.
What you should really do is code from the top-down, not from the bottom-up. Write your main function as clearly and concisely as you can using APIs that you have not yet created as if they already existed. Then, you can implement those APIs in similar fashion, until you have functions that are only a few lines long. If you code from the bottom-up, you will likely create a whole lot of stuff that you don't actually need.
In terms of when to create an interface... pretty much everything should be an interface. When you use APIs that don't yet exist, assume that every concrete class is an implementation of some interface, and use a declared type that is indicative of that interface. Your inheritance should be done solely with interfaces. Only create concrete classes at the very bottom when you are providing an implementation. I would suggest avoiding abstract classes and just using delegation, although abstract classes are also reasonable when two different implementations differ only slightly and have several functions that have a common implementation. For example, if your interface allows one to iterate over elements and also provides a sum function, the sum function is a trivial to implement in terms of the iteration function, so that would be a reasonable use of an abstract class. An alternative would be to use the decorator pattern in that case.
You might also find the Google Techtalk "How to Design a Good API and Why it Matters" to be helpful in this regard. You might also be interested in reading some of my own software design observations.
Also, for the coming future, you can keep in pipeline to read the basics on domain driven design to align yourself to the real world scenarios - it gives a solid foundation for requirements mapping to the real classes.
I'm investigating using DbC in our Perl projects, and I'm trying to find the best way to verify contracts in the source (e.g. checking pre/post conditions, invariants, etc.)
Class::Contract was written by Damian Conway and is now maintained by C. Garret Goebel, but it looks like it hasn't been touched in over 8 years.
It looks like what I want to use is Moose, as it seems as though it might offer functionality that could be used for DbC, but I was wondering if anyone had any resources (articles, etc.) on how to go about this, or if there are any helpful modules out there that I haven't been able to find.
Is anyone doing DbC with Perl? Should I just "jump in" to Moose and see what I can get it to do for me?
Moose gives you a lot of the tools (if not all the sugar) to do DbC. Specifically, you can use the before, after and around method hooks (here's some examples) to perform whatever assertions you might want to make on arguments and return values.
As an alternative to "roll your own DbC" you could use a module like MooseX::Method::Signatures or MooseX::Method to take care of validating parameters passed to a subroutine. These modules don't handle the "post" or "invariant" validations that DbC typically provides, however.
EDIT: Motivated by this question, I've hacked together MooseX::Contract and uploaded it to the CPAN. I'd be curious to get feedback on the API as I've never really used DbC first-hand.
Moose is an excellent oo system for perl, and I heartily recommend it for anyone coding objects in perl. You can specify "subtypes" for your class members that will be enforced when set by accessors or constructors (the same system can be used with the Moose::Methods package for functions). If you are coding more than one liners, use Moose;
As for doing DbC, well, might not be the best fit for perl5. It's going to be hard in a language that offers you very few guarantees. Personally, in a lot of dynamic languages, but especially perl, I tend to make my guiding philosophy DRY, and test-driven development.
I would also recommend using Moose.
However as an "alternative" take a look at Sub::Contract.
To quote the author....
Sub::Contract offers a pragmatic way to implement parts of the programming by contract paradigm in Perl.
Sub::Contract is not a design-by-contract framework.
Sub::Contract aims at making it very easy to constrain subroutines input arguments and return values in order to emulate strong typing at runtime.
If you don't need class invariants, I've found the following Perl Hacks book recommendation to be a good solution for some programs. See Smart::Comments.