I am making a very simple model of a an output driver which can have 3 output levels. It can also be turned off. What I want to do is model this as a real so I can assign different numbers for the three levels. I am unsure to do to model the 'off' state. I found some discussion about using inf or NaN to model z in a real number, but it doesn't seem like this is a settled argument. So this is a 2 part question:
1) is NaN the right way to model z on a real in system verilog?
2) how do I assign NaN in system verilog? This works:
realnum = 0.0/0.0;
But it seems like a bit of a kludge to do this. Is there already a defined way to get NaN?
The right way to do what I want is probably to use verilog-AMS but I want to avoid using a license for a simulator that supports it for such a simple model.
Edit: To clarify why I want to do this: this model will be a cell view in the top level schematic that I will netlist. I can't do a 2 bit output since the schematic has only one wire.
A new feature 6.6.7 User-defined nettypes was added to the 1800-2012 LRM, but I do not think it has been implemented by most vendors yet. In the meantime, you can create your own resolution functions, and manually insert them where needed to convert your real to a 4-state value.
Related
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.
Hi, I have some troubles understanding which analysis is suitable to test this expected pattern.
The idea here is that in Condition 1, the difference between A and B is higher, but small between C and IC. In Condition 2, the difference between C and IC should be higher, but lower between A and B. Ideally, I would like to test this via a three-way ANOVA (2x2x2), but as the graphs are parallel in both plots, it seems that there would not be a significant interaction. Does anyone have an idea? Thanks a lot in advance
The proposed model seems to be something like:
RT ~ Condition * GroupAB * GroupCIC
Based on the plots provided, this should produce output with:
no meaningful 3-way interaction, nor a meaningful 2-way interaction between GroupAB and GroupCIC since the lines are parallel in both conditions.
A meaningful Condition:GroupCIC interaction, since the lines are further apart in condition 2 that condition 1
A meaningful Condition:GroupAB interaction, since the slopes of the lines are different between the two conditions.
This is a follow-up to a suggestion by #DCTLib in the post below.
Cudd_PrintMinterm, accessing the individual minterms in the sum of products
I've been pursuing part (b) of the suggestion and will share some pseudo-code in a separate post.
Meanwhile, in his part (b) suggestion, #DCTLib posted a link to https://github.com/VerifiableRobotics/slugs/blob/master/src/BFAbstractionLibrary/BFCudd.cpp. I've been trying to read this program. There is a recursive function in the classic Somenzi paper, Binary Decision Diagrams, which describes an algo to compute the number of satisfying assignments (below, Fig. 7). I've been trying to compare the two, slugs and Fig. 7. But having a hard time seeing any similarities. But then C is mostly inscrutable to me. Do you know if slugs BFCudd is based on Somenze fig 7, #DCTLib?
Thanks,
Gui
It's not exactly the same algorithm.
There are two main differences:
First, the "SatHowMany" function does not take a cube of variables to consider for counting. Rather, that function considers all variables. The fact that "recurse_getNofSatisfyingAssignments" supports cubes manifest in the function potentially returning NaN (not a number) if a variable is found in the BDD that does not appear in the cube. The rest of the differences seem to stem from this support.
Second, SatHowMany returns the number of satisfying assignments to all n variables for a node. This leads, for instance, to the division by 2 in line -4. "recurse_getNofSatisfyingAssignments" only returns the number of assignments for the remaining variables to be considered.
Both algorithms cache information - in "SatHowMany", it's called a table, in "recurse_getNofSatisfyingAssignments" it's called a buffer. Note that in line 24 of "recurse_getNofSatisfyingAssignments", there is a constant string thrown. This means that either the function does not work, or the code is never reached. Most likely it's the latter.
Function "SatHowMany" seems to assume that it gets a BDD node - it cannot be a pointer to a complemented BDD node. Function "recurse_getNofSatisfyingAssignments" works correctly with complemented nodes, as a DdNode* may store a pointer to a complemented node.
Due to the support for cubes, "recurse_getNofSatisfyingAssignments" supports flexible variable ordering (hence the lookup of "cuddI" which denotes for a variable where it is in the current BDD variable ordering). For function SatHowMany, the variable ordering does not make a difference.
One of my memory model files showing the notation IN22_R2P_W00064B080M02C064.mdt. I want to know what is W , B, M, C in the model name can any one explain ?
As Greg stated above, this is usually a naming convention to explain features (such as BIST, port widths/operations, etc.) and it most often is associated with process nodes (28nm, 14nmfinfet). Depends on what generated this model.
R2P would likely mean 2 port register file
W00064 likely means 64 bits in width.
and so on. But this just looks like a pure model and not something that will eventually be used for synthesis.
TSMC has a memory "compiler" that will generate these models and will usually name them something strange like this but makes sense once you read the manual on it.
I am new to understanding Verilog as this language requires thinking in terms of synthesis.
While doing some program I found that:
begin
buf_inm[row][col] =temp_data;
#1 mux_data=buf_inm[row][col];
end
gave correct results than
begin
buf_inm[row][col] =temp_data;
mux_data=buf_inm[row][col];
end
in terms of assignments of variables.
Can anybody explain what is the difference between these two?
In any other higher level languages construct 2 (without delay) would have given correct assignments.
Thanking you,
Yours sincerely,
R. Ganesan.
First of all #1 is a one time scale delay that you can use in simulation, but it is not synthesizeable. When you say "gave correct results", it might help if you explained what results you are seeing, but my guess is that you assigned something to the 2 dimensional vector, and then you assign that to the max_data and are expecting mux_data to be what temp data was. Is it retaining old data? Is it undefined?
That said, I would say the difference is a synthesizeable assignment versus a non-sythesizeble one. In the first case you should see two state changes separated by a timescale unit. The second case, because it is blocking, should see both values update in zero-time, and in the order as written top to bottom. If you aren't seeing that, something else is potentially at foot here. What tool are you using? Tool version? Maybe you can share your full code and test bench so we can see why your results are unexpected.