What do we do when we have to create a scoreboard for a certain design logic? For a memory I understand that we can compare the data written to DUT at a certain address to the data read at the same address. Suppose for a basic example of full adder how do we maintain a scoreboard. What values do we compare and what method will we be using?
Typically scoreboard is used to compare the data as you have mentioned in your question. Every scoreboard has a reference model (just the functionality of DUT).
For a full adder, you will implement the variables(declared in scoreboard) addition and receive the values from the monitor through the interface and your reference model calculates the sum and carry. This is compared with the sum and carry coming out of DUT captured by the monitor.
In UVM terminology, a scoreboard it a component that coordinates checking the expected results against the actual results. The expected results gets generated either inside the scoreboard, or as a separate component called a predictor or golden reference model.
Regardless of whether you are verifying a simple full adder or a complex CPU, a UVM testbench applies stimulus to both the DUT and reference models, and the scoreboard must know when to look at the actual results and do the comparison with expected results.
Related
Say I have a Verilog module that's parameterizable like the below example:
// Crunches numbers using lots of parallel cores
module number_cruncher
#(parameter NUMBER_OF_PARALLEL_CORES = 4)
(input clock, ..., input [31:0] data, ... etc);
// Math happens here
endmodule
Using Verilog 1364-2005, I want to write a testbench that runs tests on this module with many different values NUMBER_OF_PARALLEL_CORES.
One option that I know will work is to use a generate block to create a bunch of different number_crunchers with different values for NUMBER_OF_PARALLEL_CORES. This isn't very flexible, though - the values need to be chosen at compile time.
Of course, I could also explicitly instantiate a lot of different modules, but that is time consuming and won't work for the sort of "fuzz" testing I want to do.
My questions:
Is there a way to do this by using a plusarg passed in from the command line using $value$plusargs? (I strongly suspect the answer is 'no' for Verilog 1364-2005).
Is there another way to "fuzz" module parameterizations in a testbench, or is using a generate block the only way?
Since $value$plusargs is evaluated at runtime, it can not be used to set parameter values, which must be done at compile-time.
However, if you use generate to instantiate multiple instances of the design with different parameter settings, you might be able to use $value$plusargs to selectively activate or enable one instance at a time. For example, in the testbench, you could use the runtime argument to only drive the inputs of a specific instance.
I have a question regarding modeling on an Activity Diagram that has been bothering me for some time and I was not able to find any answers / Convention anywhere.
Here is an example to better understand my question:
Let say that I have two class named "flat" and "house". both are a generalization of the class "housing".
housing contain an attribute "residents" for the person living in it.
flat contain an attributes "floor" that says at which floor the flat is.
Here is the class diagram:
In an activity diagram, I want to represent the action of giving persons a housing.
this action can take either house or flat as input (so the use of "housing" type for the input pin is correct I think) as well as an undefined number of people.
I want this action to give an updated house or flat as output (not an updated housing as this would mean that information specific to the house or flat would be lost.
I don't really know if I must create two actions (one for house and another for flats) or if there is a way to reuse the action for both class and have a correct output out of it.
Here is the activity Diagram:
My question is: how to represent in an activity diagram, an action that is the same for different type of Object flows as input, and that give the updated Object flow as output (that may be therefore of different type)?
nb:
all type of object flow are class and inherit from a same other class.
I'm representing this in modelio but first had this issue in Cameo.
I'm Trying to fit as best as I can within the rules of UML Language.
Cameo is right in rejecting this model. Give Flat Floor expects a Flat and will not work with a House, but Assign Resident to Housing could return a House. I know, in your context it can only return a Flat, but how should the tool know that?
The correct way to capture this fact would be to add a postcondition to Activity Assign Resident to Housing that states that the type of the input and output pin will be the same.
However, it would be really hard to define a complete set of compatibilty rules that takes into account all the global and local pre- and postconditions and the tools would also be hard pressed to validate a model according to these rules. Therefore the UML specification choose the easy road and simply doesn't allow to connect the pins.
The solution is to use the transformation property of the ObjectFlow. Just assign an OpaqueBehavior that casts the Type House to the Type Flat. Cameo will then accept the model. It is the modelers responsibility to ensure, that this cast will always work, since no exception handling can be defined here. Maybe this should be documented with a local postcondition.
In your specific example there is an even easier solution: simply fork the ObjectFlow of Type Flat and omit the OutputPin of Assign Resident to Housing.
As a side note: Due to a bug in Cameo, you can change the type of the OutputPin to a more specific Type than that of the ActivityParameter. This is correct for InputPins, but should be the opposite for OutputPins. You could use this to let the Parameter be of type House, but the OutputPin-Type would be Flat.
The two flows (top object and lower control) in the blue frame could stay as they are. Give flat floor would commence only when it receives a Flat object and the control token is sent. In order to make the right action sort of optional I would just use the object flow, thus only triggering when a Flat object is passed. That would just be enough and no additional control flow is needed.
To make things clear I would also add a guarded flow from the Assign action to an exit reading [ house was assigned ] or the like.
Is it possible to have two flops/any other instances have the same name in the netlist?
Considering that there is no hierarchy, say I have a design of 10M instances and there exists an flop called foo, is it possible that another flop have same name 'foo'?
No. Within a single scope, you cannot re-use the same identifier for another purpose,
As Dave says, no. But if you had 10M instances, you wouldn't have coded that manually, your logic synthesiser would have. And it won't output an illegal netlist.
The only way your question makes sense is to consider one large verilog file - obviously, here there can't be more than one reg/logic with the name foo. This is fundamental to the verilog scoping rules.
If there is any iteration or local scope of any form in your design, the elaboration process will construct a form of heirarchy to handle this iteration. If you flatten the resulting netlist (by default or design), then each element will either gain an abstract unique identifier (n1, n2, n3...), or be pre/post fixed with some heirarchical information (gen_1_foo, gen_2_foo...).
After the netlist generation, it may be non-trivial to relate a specific flop to it's syntactic source in the verilog - but you brought this on yourself by the lack of heirarchy and structure in the design.
I would like to generate some combinatorial logic, and I would like to use recursive functions for this (with predefined preprocessor arguments, of course).
Simple example: Factorial function
I have a reg [10:0] number; and I want to have the logic for counting it's factorial, but I want some predefined variable msb to be determine the MSB and have number[msb:0] as a starting number, and go on from there.
And module would receive the number and call fact_func(number) which would calcuate the factorial, but only the shortened one.
Is something like this possible in Verilog? Have functions generate logic?
I'm not totally sure what you're asking, but building logic with recursive function calls is very much possible in Verilog. You'll need to build a parameterized module that includes a generate block instantiating itself with a progressively smaller (or larger) parameter value, until you get to the base case.
Here's an example of it in action. You could easily modify this to generate the Fibonacci sequence.
Keep in mind, however, that generating blocks this way can synthesize very, very large. You will need to ensure the tools you're using are succeeding in optimizing it to a reasonable size.
I am a beginner in circuit synthesis, and I came across the word net a lot, but I am never able to find its standard definition. It seems to me that it refers to any kind of "black box" where it receives inputs and produce outputs. So it can be a sub circuit inside a big circuit and it can be an array of gates. Is my understanding correct?
No, your understanding is not correct.
Verilog
In Verilog, net has a precise definition:
IEEE 1800-2012 states:
6.5 Nets and variables
There are two main groups of data objects: variables and nets. These two groups differ in the way in which they
are assigned and hold values.
A net can be written by one or more
continuous assignments, by primitive outputs, or through module ports.
The resultant value of multiple drivers is determined by the
resolution function of the net type. A net cannot be procedurally
assigned.
A net can be one of many types, for example: wire, supply0, wand, but by far the most common type is wire.
IEEE 1800-2012 goes on to say:
Variables can be written by one or more procedural statements,
including procedural continuous assignments. The last write determines
the value. Alternatively, variables can be written by one continuous
assignment or one port.
The main difference between the behaviour of a variable and a net is their behaviour when assigned to from more than one place, as highlighted by the bold text in the two quotes:
For a net, if you assign to it from more than one place, its resulting value is determined by a resolution function, which for the built-in net types (wire etc). The behaviour of the resolution function depends on the net type and that is the difference between the net types. So, for example, with a wire, if both 1'b0 and 1'b1 are assigned to it, the resulting value will be 1'bx (unknown) if both assignments assign values with the same strength. The resolution function is intended to model real electronics. (There is also the added complication of user-defined net types and drive strengths, but let's leave those out for this discussion.)
For a variable, if you assign to it from more than one place, its resulting value is determined by whatever value is written last (just like a normal software variable). So, for example, if a 1'b0 is assigned and then a 1'b1 is assigned, the resulting value will be 1'b1 because that value was assigned last. There is no resolution function involved nor any concept of drive strength.
Both nets and variables are used to model combinational logic and sequential logic. There are rules for when you can use a net and when you can use a variable and the choice of which to use is governed by those rules (given in the quotes above). These were strict in verilog, but have been relaxed in System-Verilog to such an extent that, if you are not designing using tri-state logic, you don't need nets in System-Verilog.
VHDL has exactly the same distinction. The VHDL equivalent of a Verilog net is a signal; the VHDL equivalent of a Verilog variable is a variable. The rules about which to use where in VHDL are different, however, and more strict (no surprise there).
Electronics
In electronics a net means a piece of metal through which current flows. In other words, a net is the connection between one place and another. Physically, it could be a PCB track, a cable, a bond wire or a metal connection on an IC. Generally, in digital electronics, it is most like to be a metal connection on an IC.
Synthesis
So, to answer your question, if someone uses the term "net" when talking about the output of a logic synthesiser (the gate-level netlist), they almost certainly mean the second idea: the construct in whatever format that gate-level netlist uses that models the connection between one gate and another. As it is common for synthesisers to output their gate-level netlist as Verilog, those connections between gates are probably modeled using Verilog nets anyway (probably wires).