NuSMV: Initialising range constant with parameter - model-checking

I'm new to NuSMV. I'm trying to define a module, where each state has a duration variable than can range from 0 to the specified bound.
MODULE state(inc, bound)
VAR
duration : 0..bound;
ASSIGN
init(duration) := 0;
next(duration) := inc ? (duration + 1) mod (bound+1) : duration ;
DEFINE limit := duration = bound;
However, this yields the syntax error: A variable is expected in left-hand-side of assignment: init(duration) := 0. I'm able to fix this by declaring duration to duration : 0..1+bound.
In my main module, I wish to calculate the total_duration (or actually calculate all possible combinations of state's duration and make sure that no combination exceeds e.i. 3 as in the SPEC) of running my model and make sure that variable does not succeed a specific limit.
Here's my main module:
MODULE main
VAR
s0 : state(TRUE, 0);
s1 : state(s0.limit, 0);
s2 : state(s1.limit, 3);
state : {s0, s1, s2};
DEFINE
max_duration := s0.bound + s1.bound + s2.bound;
VAR
total_duration : 0..max_duration;
ASSIGN
init(state) := s0;
next(state) :=
case
state = s0 : s1;
state = s1 : s2;
state = s2 : s2;
esac;
total_duration := s0.duration + s1.duration + s2.duration;
SPEC
AG (state = s2 -> AF total_duration <= 3);
My problem is: When I run the model, NuSMV keeps adding to the total_duration variable and thus fails with the message "line 39: cannot assign value 5 to variable total_duration". This is due to the declaration of duration : 0..1+bound, because, in the particular example of
s0.duration = 0, s1.duration = 0 and s2.duration = 3, it will try to add 1 + 1 + 4 to total_duration, as that is the state's bound + 1.
However, if I check the trace there's no point where total_duration exceed 3. I have checked the followed specs:
-- specification AG total_duration < 4 is true
-- specification F total_duration = 4 is false
-- specification EF total_duration >= 4 is false
How can I fix this? Either by declaring duration in another way or changing anything else?

The software does something very simple. It takes the domain of each addend, and checks whether the result variable would be able to hold the result of every possible combination of value. In this case:
the domain of s0.duration is 0..1
the domain of s1.duration is 0..1
the domain of s2.duration is 0..4
so, in principle, the maximum total_duration could be 6 and its domain should thus be 0..6. Therefore:
DEFINE
max_duration := s0.bound + s1.bound + s2.bound + 3
You may want to run NuSMV with the following option:
-keep_single_value_vars
Does not convert variables that have only one
single possible value into constant DEFINEs
In this way, you'll be able to run the model without having to add +1 to the domain of bound.

Related

Display query in ABB HMI using software panel builder 600

I am using ABB HMI and programming it on panel builder 600. I have used meters to display angles and set the scale from -100 to +100. I have acheived success in displaying angles but the problem is the change in angle is very frequent and the needle of the meter gets out of control. For example: the angle is 5 degree then it suddenly increased to 10 degree and the decreased to 3 degree again in a very short span of time and my needle in display meter gets out of control. What should I do to resolve this issue? I am using ABB plc and writing my code in codesys in CFC language. Awaiting for the helpful replies TIA
Decreasing Sampling Rate
VAR
plcValue: INT; // this value changes a lot
hmiValue: INT := plcValue; // this value is sent to the HMI to be displayed
sampleRate: TIME := T#2S; // hmiValue will change every 2 seconds
timer: TON; // the timer
END_VAR
timer(IN := TRUE, PT := sampleRate);
IF (timer.Q) THEN
hmiValue := plcValue;
timer(IN := FALSE, PT := sampleRate); // reset
END_IF
Moving Average
VAR CONSTANT
SIZE: INT := 100; // the number of values to average
END_VAR
VAR
plcValue: INT; // this value changes a lot
hmiValue: INT := plcValue; // this value is sent to the HMI to be displayed
movingAverage: ARRAY [0..SIZE] OF INT; // last SIZE number of values of plcValue
maIndex: INT := 0;
maFilled: BOOL;
sum: REAL;
i: INT;
END_VAR
movingAverage[maIndex] := plcValue;
sum := 0;
IF (maFilled) THEN
FOR i := 0 TO SIZE DO
sum := sum + movingAverage[i];
END_FOR
hmiValue := REAL_TO_INT(sum / SIZE);
ELSE
FOR i := 0 TO maIndex DO
sum := sum + movingAverage[i];
END_FOR
hmiValue := REAL_TO_INT(sum / (maIndex + 1));
END_IF
IF (maIndex = SIZE) THEN
maIndex := 0;
maFilled := TRUE;
ELSE
maIndex := maIndex + 1;
END_IF
Comparison
running this code:
IF (plcValue = 5) THEN
plcValue := 10;
ELSIF (plcValue = 10) THEN
plcValue := 3;
ELSE
plcValue := 5;
END_IF
Reduced sampling rate results in the hmiValue still jumping every 2 seconds (or whatever sampleRate was set), while moving average was stuck at 6, which usually makes it the more preferred of the two, though a little bigger codewise, as well as slower to execute (though it shouldn't matter, unless you are counting thousands of averages every cycle). You can also change the average size: The bigger it is, the smoother the value, but also slower to react to change. Try not to make it too big
You can use some different blocks on OSCAT library (It's a 3rd party free library. You need to downloade it if you want to use it). I know you work in CFC and perhaps you are not familiar with ST, but this is best way to represent how to solve your task.
FADE
This block allows slowly change value from one value to another.
PROGRAM PLC_PRG
VAR
iValue: INT(-100..100); (* Value input *)
iGauge: INT(-100..100); (* Smoothed Value for HMI *)
fbFade: FADE; (* fade block *)
END_VAR
(* Play with TF parameter to achieve desired smoothness *)
fbFade(IN1 := INT_TO_REAL(iValue), IN2 := INT_TO_REAL(iGauge), F := FALSE, TF := T#500MS);
iGauge := REAL_TO_INT(fbFade.Y);
END_PROGRAM
FILTER_I
This block averages value for a given time interval. FILTER_I is a filter of the first degree for 16-bit INT data.
PROGRAM PLC_PRG
VAR
iValue: INT(-100..100); (* Value input *)
iGauge: INT(-100..100); (* Smoothed Value for HMI *)
fbFilter: FILETR_I; (* filter block *)
END_VAR
(* Play with T parameter to achieve desired smoothness *)
fbFilter(X := iValue, T := T#500MS, Y => iGauge);
END_PROGRAM
FILTER_MAV_W
And another filter is like #Guiorgy made en example based not on time but on number of values stored which is called MA (Moving Average).
PROGRAM PLC_PRG
VAR
iValue: INT(-100..100); (* Value input *)
iGauge: INT(-100..100); (* Smoothed Value for HMI *)
fbFilter: FILTER_MAV_W; (* filter block *)
END_VAR
(* Play with N parameter to achieve desired smoothness *)
fbFilter(X := INT_TO_WORD(iValue), N := INT#32);
iGauge := WORD_TO_INT(fbFilter.Y);
END_PROGRAM

Find MAX value of `define in Verilog

I want to create a define constant that is assigned to one of multiple otherdefine constants that has the largest value. Something like:
`define MAXWIDTH $MAX(`WIDTH0,`WIDTH1,`WIDTH2)
Is this possible in Verilog/SystemVerilog?
Depending on exactly what you need, there are a few ways to do it (there is no builtin call for maximum like in other languages):
You have some vectors and you need to get the maximum width for a new vector
$bits(v1 + v2 + v3 ...)
Use the language to your advantage, noting that the addition of vectors results in a vector that has the maximum width of all the operand vector widths and use $bits to get that size. Example:
logic [1:0] x;
logic [7:0] y;
logic [10:6] z;
...
max = $bits(x + y + z); // Result: max = 8
You have a few numbers of which you need the maximum
If you put your numbers in an array or queue, you can use the max method to get the largest:
int x[] = '{n1, n2, n3, ...};
...
max = x.max;
Note that this approach has the downside that it cannot be used at compile time for getting the maximum size. Example:
int _nums[] = '{13, 2, 17, 8, -1};
...
max = _nums.max; // Result: max = 17
Basically any other time
You'll just have to use the conditional operator, either in a macro or using let:
`define max2(v1, v2) ((v1) > (v2) ? (v1) : (v2))
`define max3(v1, v2, v3) `max2((v1), `max2((v2), (v3)))
OR
let max2(v1, v2) = (v1 > v2) ? v1 : v2;
let max3(v1, v2, v3) = max2(v1, max2(v2, v3));
The advantage of macros is that you can use them as compile-time constants in a wider range of tools, while older tools might not support let as a compile-time constant (or at all). Example:
max = `max3(10, 2, 3); // Result: max = 10
OR
max = max3(10, 2, 3); // Result: max = 10

Verilog modulus operator for wrapping around a range

My background is in software and I'm new to (System)Verilog so when tasked with implementing a caesar shifter (shift each letter in a string by N letters, wrapping around if necessary e.g. ABCXYZ shifted by 3 becomes DEFABC), I wrote the following, hoping to be able to reduce code duplication, like I would in software:
/* every variable except 'direction' has the type 'byte' */
always_comb
begin
shifted_char = fresh_char; /* don't touch bytes that aren't letters */
is_lower_case = "z" >= fresh_char && fresh_char >= "a";
is_upper_case = "Z" >= fresh_char && fresh_char >= "A";
if (is_lower_case || is_upper_case)
begin
unique if (is_lower_case)
alphabet_start = "a";
else if (is_upper_case)
alphabet_start = "A";
alphabet_position = fresh_char - alphabet_start;
if (direction == "f") /* direction is a module parameter: f for forwards results in a shifter, any other value results in an 'unshifter' */
new_alphabet_position = (26 + (alphabet_position + shift_by)) % 26;
else
new_alphabet_position = (26 + (alphabet_position - shift_by)) % 26;
shifted_char = new_alphabet_position + alphabet_start;
end
end
My question is (assuming it's a forward shifter): regarding the "% 26" part, can I expect the synthesizer to deduce that the range of possible values it's going to get at that point is [26, 26+25+25] ([26, 76]) and so there's only 2 cases the logic needs to distinguish between (>26 and >52), rather than [whatever is the smart call when having handle all possible 256 different inputs - (would it be to consider the cases >26, >52, >78 etc...? Or is there a better way? I digress...)]?
I could always do the following:
new_alphabet_position = alphabet_position + shift_by;
if (new_alphabet_position > 25)
new_alpahbet_position -= 26;
/* Or, for the reverse shifter: */
new_alphabet_position = alphabet_position - shift_by;
if (new_alphabet_position < 0)
new_alpahbet_position += 26;
...but was curious and wanted to ask that, as well as a related one (that I expect more people will be able to answer): Can it be used to make a normal non-power-of-2 counter (e.g.
count <= (count + 1) % 6;
)? Going by hgleamon1's response to the following thread, it seems as though (at least one) VHDL synth tool might interpret it as intended: https://forums.xilinx.com/t5/Synthesis/Modulus-synthesizable-or-non-synthesizable/td-p/747493
Unless there is a specialized macro cell, non powers of 2 modulus will take a large number of gates and have relatively long propagation delays especially if done as pure combiantional logic.
Be aware depending on your synthesizer the variables 'alphabet_start', 'alphabet_position', and 'new_alphabet_position' my be inferred latches. The way you used them is as intermediated logic, so if you don't references them outside this always block and your synthesizer has decent optimization, then it will not be a latch. To guarantee they will not be latches, they must be given default values outside the if statement.
You state that all variables except 'direction' are type 'byte', this means 'shift_by' may have a value greater than 25 or less than -25 ('byte' is a signed value by default). By using a signed values and adding three value (26 + (alphabet_position + shift_by)) before using the modulus, there is a decent changes that the mod26 will be evaluated on a 10-bit signed value. That will use more logic than if used on an 8-bit value. There is a change your synthesizer may do some optimization, but it might not be great.
If you can guarantee 'shift_by' is less than 26 and greater than -26 ( greater or equal to 0 if unsigned), then you don't need 'alphabet_position' or 'new_alphabet_position'. Simply add or subtract the 'shift_by' and calculate if out of range. For the range check, fist check if 8'(shifted_char-26) >= alphabet_start. The reason for this is to make sure we are comparing positive numbers. "z"+25 is 147 which is negative for a signed 8-bit value. The 8'() with cast it as an 8-bit unsigned value to trim any non-zero intermediate 9th+ bit(s). If an adjustment is not needed then check if hifted_char < alphabet_start as now the possibility of overflowing to a negative number has been already handled.
If you cannot guarantee 'shift_by' is within range, then you have no choose by to mod it. Luckily this is an 8-bit signed value which is better than your original worse case with a 10-bit signed value. This is not ideal but the best I can offer. It is more optimal to have the driver of 'shift_by' assign a legal value then adding more logic to mod it.
Since you are using SystemVerilog, you may want to consider using fresh_char inside { ["A":"Z"] } which is functionally the same as "Z" >= fresh_char && fresh_char >= "A". The inside is keyword is intended to be synthesizable, but I don't know if it is commonly supported.
Consider the following code. It may not be the most optimized, but it is more optimized than your original code:
always_comb
begin
shift_by_mod26 = shift_by % 26; // %26 is not need if guaranteed asb(value) < 26
alphabet_start = (fresh_char inside { ["A":"Z"] }) ? "A" : "a";
if ( fresh_char inside { ["A":"Z"], ["a":"z"] } )
begin
if (direction == "f")
shifted_char = fresh_char + shift_by_mod26;
else
shifted_char = fresh_char - shift_by_mod26;
// subtract 26 first in case shifted_char is >127
// bring back to a positive if signed (>127 unsigned is negative signed)
if (8'(shifted_char-26) >= alphabet_start)
shifted_char -= 26;
else if (shifted_char < alphabet_start)
shifted_char += 26;
end
else
begin
/* don't touch bytes that aren't letters */
shifted_char = fresh_char;
end
end
Note: if 'direction' is not a type 'byte', then it must be at least a 7bits(unsigned) wide or greater (sign agnostic) to every match "f"
Cross post answer for a cross post question

How to write cover points for transition in systemverilog?

there is a N bit register in my RTL design and I want to check if testbench is covering following particular case-
000..0 -> 000..001 -> 000....011 -> 00...111 -> ...... -> 111....111
I'm not sure how to write cover group for above. I can see how transition coverage can be useful. As an example:
covergroup cg;
cover_point_y : coverpoint y {
bins tran_34 = (3=>4);
bins tran_56 = (5=>6);
}
However in my case, my register is paraterized (N bits: reg[(N-1):0]) and it's too big to write the full sequence manually. Can I write a generate or for loop to cover above sequence that I want to see?
It's not really clear to me which transitions you want to cover. I guess you want to cover that each value changed to every other value. What you need to keep in mind is that you can write multiple values on either side of the => operator. For example:
cover_point_y : coverpoint y {
bins transitions = ( 0, 1 => 0, 1 );
}
This will create bins for 0 => 0, 0 => 1, 1 => 0, 1 => 1. If I interpreted the BNF properly, according to the LRM, the values you put on either side of the => operator are of type covergroup_value_range, meaning that any value range syntax for coverpoints should be accepted. This means the following should also be legal:
cover_point_y : coverpoint y {
bins transitions = ( [0 : 2^N - 1] => [0 : 2^N - 1] );
}
This should create transition bins from every value to every other value. You're at the mercy of tool support here. This doesn't work in my simulator, for example, but it might work in others.
If you want to exclude certain transitions (for example, 0 => 0, 1 => 1, etc.) this won't help you anyway, because the syntax to specify transition bins just isn't expressive enough...
Don't fret, there are ways to do it. Going back to basics, transition coverage is basically a form of cross coverage between the current value and the past value. Cross coverage allows much more diverse ways of specifying bins. You need to track the previous value of the variable you're covering. The thing you need to be careful of is that you should only start collecting coverage once you've sampled at least 2 values (so that you have a previous). With transition coverage, the tool would do this for you under the hood.
The best way I can think of doing it is to wrap the covergroup inside a class:
class cg_wrapper #(int unsigned WIDTH = 3);
covergroup cg with function sample(bit [WIDTH-1 : 0] val,
bit [WIDTH-1 : 0] prev
);
coverpoint val;
coverpoint prev;
cross prev, val;
endgroup
function new();
cg = new();
endfunction
// ...
endclass
The class would keep track of the previous value and whether a previous value was collected (i.e. we tried to sample a second value):
class cg_wrapper #(int unsigned WIDTH = 3);
protected bit has_prev;
protected bit [WIDTH-1 : 0] prev;
// ...
endclass
To ensure that coverage is sampled at the appropriate points, the class would expose a sample(...) function (similar to what a covergroup has) that handles sampling the actual covergroup and storing the previous value:
class cg_wrapper #(int unsigned WIDTH = 3);
// ...
function void sample(bit [WIDTH-1 : 0] val);
if (has_prev)
cg.sample(val, prev);
prev = val;
has_prev = 1;
endfunction
endclass
This will ensure that you'll get meaningful crosses. For example, calling sample(...) twice with values 0 and 1, will result in only a single "transition" from 0 to 1 (i.e. one bin in the cross getting filled).
If you want to start excluding bins the "transitions" you can use a lot different ways to do that. For example, to exclude identical transitions, you could do:
cross prev, val {
ignore_bins ignore =
(binsof (val) && binsof (prev)) with (prev == val);
}
This ignores transitions of type 0 => 0, 1 => 1, 2 => 2, etc.
There's also a nice article from AMIQ Consulting showcasing some cool ways of specifying cross bins.
Your first solution needs little modification. You have to use [] after bin name to make it auto bin. I think that is the reason why it was not working for you.
cover_point_y : coverpoint y {
bins transitions[] = ( 0, 1 => 0, 1 );
}
Assuming you want to cover consecutive increments a cover property could do the trick:
bit [7:0] y;
property y_inc(int n); #(posedge clk) y == $past(y+1)[*n]; endproperty
y_inc_3: cover property (y_inc(3));
y_inc_full: cover property (y_inc((1<<$bits(y))-1));

Integer to String goes wrong in Synthesis (Width Mismatch)

I am trying to convert a integer to string (using integer'image(val)) and either pad or limit it to a specific length. I have made this function which does the job just fine when I use a report statement and simulate.
function integer2string_pad(val: integer; stringSize: integer) return string is
variable imageString: string(1 to integer'image(val)'length);
variable returnString: string(1 to stringSize);
begin
imageString := integer'image(val);
-- Are we smaller than the desired size?
if integer'image(val)'length < stringSize then
-- Pad the string if we are
returnString := integer'image(val) & (1 to stringSize-integer'image(val)'length => ' ');
-- Are we to big for the desired size
elsif integer'image(val)'length > stringSize then
-- Only use the top most string bits and append a "." to the end signifing that there is more
returnString := imageString(1 to stringSize-1) & ".";
-- Otherwise we are just the right size
else
returnString := integer'image(val);
end if;
return returnString;
end function;
Here is some sample input, output of that function (underscore = space because SO inline code truncates extra space):
integer2string_pad(12, 6) : 12____
integer2string_pad(123456, 6) : 123456
integer2string_pad(1234567890, 6) : 12345.
integer2string_pad(0, 6) : 0_____
integer2string_pad(-123, 6) : -123__
integer2string_pad(-1, 6) : -1____
integer2string_pad(-123456, 6) : -1234.
But when I synthesize, I get width mismatch errors on all 4 lines where I assign values to pongScoreLeft or pongScoreRight. It also says they have a constant value of 0 and get trimmed out.
Width mismatch. <pongScoreLeft> has a width of 48 bits but assigned
expression is 6-bit wide.
Width mismatch. <pongScoreRight> has a width
of 48 bits but assigned expression is 6-bit wide.
Width mismatch. <pongScoreLeft> has a width of 48 bits but assigned expression is 6-bit wide.
Width mismatch. <pongScoreRight> has a width of 48 bits but assigned expression is 6-bit wide.
VHDL that produces those width mismatch errors:
type type_score is
record
left : integer range 0 to 255;
right : integer range 0 to 255;
end record;
constant init_type_score: type_score := (left => 0, right => 0);
signal pongScore: type_score := init_type_score;
signal pongScoreLeft: string(1 to 6) := (others => NUL);
signal pongScoreRight: string(1 to 6) := (others => NUL);
...
scoreToString: process(clk)
begin
if rising_edge(clk) then
if reset = '1' then
pongScoreLeft <= (others => NUL);
pongScoreRight <= (others => NUL);
else
pongScoreLeft <= integer2string_pad(pongScore.left, 6);
pongScoreRight <= integer2string_pad(pongScore.right, 6);
--report "|" & integer2string_pad(pongScore.left, 6) & "|";
end if;
end if;
end process;
What is wrong with my integer2string_pad function? What goes wrong in synthesis?
I would not expect 'image or 'value to be supported for synthesis - other than in asserts that run at elaboration time. They would involve a lot of processing.
Whenever I have converted integers to ASCII I have processed a character at a time, using character'val and character'pos, which are synthesisable, because they involve no processing; they just convert a character to/from its underlying binary representation.
EDIT:
Think how you would implement 'image! It involves multiple divisions by 10 : that's a LOT of hardware if you unroll it into a single delta cycle (as required by the semantics of an unclocked function call)
Processing a digit per (several) clock cycle(s) you can reduce that to a single division, or successive subtraction, or excess-6 addition, or however you want according to your hardware resources and time budget.
It really doesn't make sense for the synthesis tool to make these decisions on your behalf. So - while I concede it's theoretically possible, I would be surprised to see a synth tool that did it correctly. (OTOH it's such an unlikely scenario I'd not be surprised to see bugs in synth tool's error reporting should you try it)

Resources