I am new to Specman and trying to learn it by reading existing code.
I came across the following function and can't find an explanation in specman documentation...
VerifyNode(end_point:string, derived_value:uint) is also {
if ('(end_point)' === ~derived_value) {
message("Error1");
}
else if ('(end_point)' === derived_value) {
message("Error2");
}
else {
message("Error3");
}
}
I assume logically the '(end_point)' is getting actual value of end_point signal in run-time. Is that true?
Error1 will be the message if value of end_point at run time is negate the derived_value unsigned integer.
Error2 will be the message if value of end_point at run time is the same as the derived_value unsigned integer.
How can i explain the "Error3" condition?
Indeed this is the very old school of signal access based on string. I recommend you search for "simple_port".
The end_point is a string, that should be the full HDL path of the signal you want to read. Example of calling this method:
// check if signal has the value 3:
VerifyNode("top.module_a.sig_val", 3);
The official name of '' is called the tick notation in Specman documentation. Search for the term "tick notation" in cdnshelp and you will find it.
'(end_point)' is two things. It is old-school, non-port access to the device under test (DUT) and the (end_point) part of that snippet is the way to do string substitution directly in the '' access to the DUT. Using the old style of access to the DUT can drastically slow down simulation speed, if your design is big enough for that to be a concern for you. Also, this methodology lacks more static compile time checks as those strings can be anything and you'll only know the path is wrong when you simulate it and the DUT path cannot be found, creating an error.
Related
I am currently using LibFuzzer (or more particular, cargo fuzz, but it's just a wrapper around LibFuzzer) in order to fuzz a function that only accepts input of even length. So you can imagine the code being something like this:
function toFuzz(String input){
if((input.length() % 2)==1){
return 0; // Not equal length
}
// logic goes here
}
I do not want to fuzz this particular check - is there any way I can tell libFuzzer to only generate inputs of even length? Or is filtering out even inputs in the test harness the best way to go?
You can filter out inputs in the test harness or just call the function and let it do the early return. Either way LibFuzzer will notice that it isn't an "interesting" case and not spend much time on it.
I am writing a signal processing program using matlab. I know there are two types of float-pointing variables, single and double. Considering the memory usage, I want my code to work with only single type variable when the system's memory is not large, while it can also be adapted to work with double type variables when necessary, without significant modification (simple and light modification before running is OK, i.e., I don't need runtime-check technique). I know this can be done by macro in C and by template in C++. I don't find practical techniques which can do this in matlab. Do you have any experience with this?
I have a simple idea that I define a global string containing "single" or "double", then I pass this string to any memory allocation method called in my code to indicate what type I need. I think this can work, I just want to know which technique you guys use and is widely accepted.
I cannot see how a template would help here. The type of c++ templates are still determined in compile time (std::vector vec ...). Also note that Matlab defines all variables as double by default unless something else is stated. You basically want runtime checks for your code. I can think of one solution as using a function with a persistent variable. The variable is set once per run. When you generate variables you would then have to generate all variables you want to have as float through this function. This will slow down assignment though, since you have to call a function to assign variables.
This example is somehow an implementation of the singleton pattern (but not exactly). The persistent variable type is set at the first use and cannot change later in the program (assuming that you do not do anything stupid as clearing the variable explicitly). I would recommend to go for hardcoding single in case performance is an issue, instead of having runtime checks or assignment functions or classes or what you can come up with.
function c = assignFloat(a,b)
persistent type;
if (isempty(type) & nargin==2)
type = b;
elseif (isempty(type))
type = 'single';
% elseif(nargin==2), error('Do not set twice!') % Optional code, imo unnecessary.
end
if (strcmp(type,'single'))
c = single(a);
return;
end
c = double(a);
end
I'm trying to check the input of a Matlab function to see whether the user has forgotten about it or not (which is easy to do in this case).
If the user has not supplied number_obs then I want to pause the program and wait for the user to input this information.
Some other StackOverflow posts seem to suggest using ~exist however this doesn't seem to work. Can anybody suggest what I'm doing wrong here?
function output=test(number_obs)
if ~exist('number_obs'),
number_obs=input('How many observations do you have in your experiments?')
end
The Python equivalent would be something like:
def test(number_obs):
if nummber_obs != None:
output=raw_input('How many observations do you have in your experiments? :')
return output
You can do this with nargin
function output=test(number_obs)
if nargin<1
number_obs=input('How many observations do you have in your experiments?')
end
(Edited to correct the truth) It may not matter here, but to be on the safe side, you should always specify the type of object you're checking. In your case, its a 'var', so
if ~exist('number_obs','var'),
Thanks to dasdingonesin for pointing this out.
I'm working on an expression evaluator. There is an evaluate() function which is called many times depending on the complexity of the expression processed.
I need to break and investigate when this method returns null. There are many paths and return statements.
It is possible to break on exit method event but I can't find how to put a condition about the value returned.
I got stuck in that frustration too. One can inspect (and write conditions) on named variables, but not on something unnamed like a return value. Here are some ideas (for whoever might be interested):
One could include something like evaluate() == null in the breakpoint's condition. Tests performed (Eclipse 4.4) show that in such a case, the function will be performed again for the breakpoint purposes, but this time with the breakpoint disabled. So you will avoid a stack overflow situation, at least. Whether this would be useful, depends on the nature of the function under consideration - will it return the same value at breakpoint time as at run time? (Some s[a|i]mple code to test:)
class TestBreakpoint {
int counter = 0;
boolean eval() { /* <== breakpoint here, [x]on exit, [x]condition: eval()==false */
System.out.println("Iteration " + ++counter);
return true;
}
public static void main(String[] args) {
TestBreakpoint app = new TestBreakpoint();
System.out.println("STARTED");
app.eval();
System.out.println("STOPPED");
}
}
// RESULTS:
// Normal run: shows 1 iteration of eval()
// Debug run: shows 2 iterations of eval(), no stack overflow, no stop on breakpoint
Another way to make it easier (to potentially do debugging in future) would be to have coding conventions (or personal coding style) that require one to declare a local variable that is set inside the function, and returned only once at the end. E.g.:
public MyType evaluate() {
MyType result = null;
if (conditionA) result = new MyType('A');
else if (conditionB) result = new MyType ('B');
return result;
}
Then you can at least do an exit breakpoint with a condition like result == null. However, I agree that this is unnecessarily verbose for simple functions, is a bit contrary to flow that the language allows, and can only be enforced manually. (Personally, I do use this convention sometimes for more complex functions (the name result 'reserved' just for this use), where it may make things clearer, but not for simple functions. But it's difficult to draw the line; just this morning had to step through a simple function to see which of 3 possible cases was the one fired. For today's complex systems, one wants to avoid stepping.)
Barring the above, you would need to modify your code on a case by case basis as in the previous point for the single function to assign your return value to some variable, which you can test. If some work policy disallows you to make such non-functional changes, one is quite stuck... It is of course also possible that such a rewrite could result in a bug inadvertently being resolved, if the original code was a bit convoluted, so beware of reverting to the original after debugging, only to find that the bug is now back.
You didn't say what language you were working in. If it's Java or C++ you can set a condition on a Method (or Function) breakpoint using the breakpoint properties. Here are images showing both cases.
In the Java example you would unclik Entry and put a check in Exit.
Java Method Breakpoint Properties Dialog
!
C++ Function Breakpoint Properties Dialog
This is not yet supported by the Eclipse debugger and added as an enhancement request. I'd appreciate if you vote for it.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=425744
Let's say I maybe want to import a component based on some condition, let's say a boolean variable. I've tried this, but it gives me an error message. For instance, consider the following code:
model myNewModel
parameter Boolean use_Something;
myLibrary.myComponent component[if use_Something then 1 else 0];
// In other words (pseudo):
// if use_Something then 'Import The Component' else 'Do Nothing At All';
end myNewModel;
This is, intuitively, a safe statement, and as long as the boolean variable is true, it'll work as intended. For some units, for instance the fluidports of the Modelica Standard Library, it also works with the [0] size. But as soon as I turn the variable to false, I encounter errors regarding the fact that many components are not compatible with "zero size". I've had this problem, for instance, with the MassFlowSources in the Modelica Standard Library. Is there a smooth/elegant way to work around this? Thanks in advance!
You can use conditional components in Modelica.
model myNewModel
parameter Boolean use_Something;
myLibrary.myComponent component if use_Something;
end myNewModel;
This component may then only be used in connect-statements. If the condition is false, these connections are ignored by the tool.