I am new to systemverilog. I learned the functionality of "interface" to connect testbench and DUT but what I am thinking is why do I need to connect these two? Can't I simple pass the testcases generated by testbench to my DUT via "mailbox"? If not, then why?
They are two different concepts. A mailbox is a type of class—a data type. An interface is a collection of instances of data types, and that collection is used a possible port to DUT. Conceivably, any data type can be used as a port of a module, but RTL synthesis does not handle class data types.
You can certainly use a mailbox in your testbench to pass stimulus transactions to your DUT, but something (usually a component called a driver) has to translate the transaction object to a set of pin wiggles to your DUT.
Related
I made a concurrent system which has a critical section which involves read and write access to a TXT file.
First, an Auctioneer class creates a TXT file and writes the number 50 to it. The Auctioneer then allows the next node, one of three instances of the Bidder class, to open the file and change the current bid. The bidder class then allows the next node, another bidder to bid, then another bidder, and then that bidder allows the Auctioneer to look at the file.
I allowed the nodes to take turns using server sockets. Each node waits for access using the ServerSocket.accept() method, and allows the next node to enter its critical section by creating a Socket object with the socket that ne next nde is listening on.
Each of these nodes run independantly in seperate java environments and only communicate with server sockets.
Each node of the ring relies on the previous node because in order for that node to access the resource, the previous node needs to pass the current node the token. I'm unsure on how I would represent that kind of relationship in a UML compliant way.
It is of my understanding that class diagrams should not include several instances of the same class such as the example below with 3 bidders.
Is this the correct way to represent the relationship which I have described? If not, which way would be better/UML compliant?
Class diagrams, as the name suggest represent classes of objects and not individual objects, i.e. instances of these classes. Moreover, a class diagram is structural: it does not tell how objects interact or wait one for another, but how classes relate.
In tour case the class diagram would therefore represent one bidder class. To represent a concrete example with instances and how they relate, you could consider an object diagram. There you could very well represent different instances of the same class.
However, if you’re interested in the interactions between classes (e.g. the tokens they exchange), you’d better consider an interaction diagram such as the sequence diagram.
The only use with uvm_config_db is when we have more than one testbench in our system?
I`ll be glad to have some explanation about this macro.
The uvm_config_db class (it's not a macro) has many uses besides multiple testbenches. The most common is sharing data from the top-level testbench module, like the location of interface instances, with the drivers and monitor classes that need to access the virtual interfaces.
It also gets used for communicating data between components and sequences, not just for passing values, but notifiers when data has been set.
You could certainly write a testbench without using the uvm_config_db, or the entire UVM for that matter. But that misses the whole point about writing testbenches for maintainability within the same testbench and reusability with other testbenches.
I'm trying to build a model with many same blocks, which need to have different inports data types. Is it possible to make it with referenced models (no subsystems/library blocks) ?
I've already did it with subsystems, but copying objects with changing some parameters manually looks depressing. I put repeatable code in a separate model, created arguments with which I want to change the data types of the output ports.
I got a behavior I didn't expect - the arguments only affected the values of the blocks of constants, but the port types remained the same as in the default values of the arguments.
UPD. All these models are used in HDL code generation.
I have a fairly complex Simulink model with multiple referenced models that I am trying to interface with external C++ code. I am using 2014a and generating code using Simulink Coder. Below are two important requirements I would like to satisfy while doing this:
Have the ability to create multiple instances of the model in my
external C++ code.
Have the ability to overwrite data that is input to the model and
have it reflected to the external application.
Given these requirements, at the top level what is the best method to interface to external IO, datastores or IO ports?
From my understanding using datastores (or Simulink.Signal objects) and by specifying the appropriate storage class I may be able to satisfy 2 above, but in doing so I would have to specify signal names and this would not allow me to satisfy 1.
If I use IO port blocks at top level, I may be able to satisfy 1 but not 2.
Update: #2 constraint has been removed due to design change. Hence the io port approach works for me.
Are interfaces a layer between objects(different objects) and actions(different object types trying to perform same action)? and Interface checks what kind of object is it and how it can perform a particular action?
I'd say that it's better to think of an interface as a promise. In Java there is the interface construct that allows for inheritance of an API, but doesn't specify behavior. In general though, an interface is comprised of the methods an object presents for interacting with the object.
In duck-typed languages, if an object presents a particular set of methods (the interface) specific to a particular class, then that object is like the specifying class.
Enforcement of interface is complicated, since you need to specify some set of criteria for behavior. An interesting example would the design-by-contract ideas in Eiffel.
Are you asking about the term "interface" as used in a specific language (such as Java or Objective-C), or the generic meaning of the term?
If the latter, then an "interface" can be almost anything. Pour oil on water -- the line between them is an "interface". An interface is any point where two separate things meet and interact.
The term does not have a rigorous definition in computing, but refers to any place where two relatively distinct domains interact.
To understand interfaces in .net or Java, one must first recognize that inheritance combines two concepts:
Implementations of the derived type will include all fields (including private ones) of the base type, and can access any and all public or protected members of the base type as if it were its own.
Objects of the derived type may be freely used in place of objects of the base type.
Allowing objects to use members of more than one base type as their own is complicated. Some languages provide ways of doing so, but there can often be confusion as to which portion of which base object is being referred to, especially if one is inheriting from two classes which independently inherit from a third. Consequently, many frameworks only allow objects to inherit from one base object.
On the other hand, allowing objects to be substitutable for more than one other type of object does not create these difficulties. An object representing a database table may, for example, allow itself to be passed to a routine that wants a "thing that can enumerate contents, which are of type T (IEnumerable<T> in .net)", or a routine that wants a "thing that can have things of type T added to it" (ICollection<T> in .net), or a thing that wants a "thing that wants to know when it's no longer needed (IDisposable in .net)". Note that there are some things that want notification when they're no longer needed that do not represent enumerable collections, and there are other things that represent enumerable collections that can be abandoned without notification. Thus, neither type of object could inherit from the other, but if one uses an interface to represent "things which can enumerate their contents, which are of type T", or "things that want to know when they are no longer needed", then there's no problem having classes implement both interfaces.