I have the Verilog statement below:
module test (A,B, CLK);
input A, CLK;
output B;
always#(posedge CLK)
if(A) B <= 1'b1;
endmodule
I am expecting a register. However, after I synthesis it with Yosys, I got the result as follow:
assign B = 1'b1;
I don't understand why Yosys translate the above Verilog statement to a constant 1.
Please advice, thanks!
Your B has two possible values:
1'b x during initialization (more in IEEE Std 1364 4.2.2 Variable declarations),
1'b 1 when A is equal to 1'b 1.
You really have only one value. Thats mean you can optimize it to hardwired 1'b 1.
This is not a Yosys fault. All (or almost all) synthesis software will behave same way. If you want to let it work (if I guess what you want), you have to allow B to take two different values. You can do it by initial value equal to 1'b 0 or by reset to value 1'b 0.
I suggest to use reset instead of initial value because initial value can be implemented as A connected to register's set pin.
Interesting! I noticed that if you assign an initial value of zero to the register (e.g. output reg B = 1'b0) you do get a flip-flop. (I used read_verilog <your_code.v> ; synth ; show.)
However, an initial value of one still produces the constant output you mention. So perhaps what's happening here (and I'm only speculating) is that when an initial value is not given, yosys is free to pick its own, in which case it picks 1'b1, so that the whole circuit is equivalent to a simple hard-wired constant? Only when the initial value is zero is the flip-flop necessary?
Related
In Practical Common Lisp, Peter Seibel write:
The mechanism by which multiple values are returned is implementation dependent just like the mechanism for passing arguments into functions is. Almost all language constructs that return the value of some subform will "pass through" multiple values, returning all the values returned by the subform. Thus, a function that returns the result of calling VALUES or VALUES-LIST will itself return multiple values--and so will another function whose result comes from calling the first function. And so on.
The implementation dependent does worry me.
My understanding is that the following code might just return primary value:
> (defun f ()
(values 'a 'b))
> (defun g ()
(f))
> (g) ; ==> a ? or a b ?
If so, does it mean that I should use this feature sparingly?
Any help is appreciated.
It's implementation-dependent in the sense that how multiple values are returned at the CPU level may vary from implementation to implementation. However, the semantics are well-specified at the language level and you generally do not need to be concerned about the low-level implementation.
See section 2.5, "Function result protocol", of The Movitz development platform for an example of how one implementation handles multiple return values:
The CPU’s carry flag (i.e. the CF bit in the eflags register) is used to signal whether anything other than precisely one value is being returned. Whenever CF is set, ecx holds the number of values returned. When CF is cleared, a single value in eax is implied. A function’s primary value is always returned in eax. That is, even when zero values are returned, eax is loaded with nil.
It's this kind of low-level detail that may vary from implementation to implementation.
One thing to be aware: there is a limit for the number of values which can be returned on a specific Common Lisp implementation.
The variable MULTIPLE-VALUES-LIMIT has the implementation/machine specific value of the maximum numbers of values which can be returned. The standard says that it should not be smaller than 20. SBCL has a very large number on my computer, while LispWorks has only 51, ECL has 64 and CLISP has 128.
But I can't remember seeing Lisp code which wants to return more than 5 values.
My goal is to understand how Eva shrinks the intervals for a variable. for example:
unsigned int nondet_uint(void);
int main()
{
unsigned int x=nondet_uint();
unsigned int y=nondet_uint();
//# assert x >= 20 && x <= 30;
//# assert y <= 60;
//# assert(x>=y);
return 0;
}
So, we have x=[20,30] and y=[0,60]. However, the results from Eva shrinks y to [0,30] which is where the domain may be valid.
[eva] ====== VALUES COMPUTED ======
[eva:final-states] Values at end of function main:
x ∈ [20..30]
y ∈ [0..30]
__retres ∈ {0}
I tried some options for the Eva plugin, but none showed the steps for it. May I ask you to provide the method or publication on how to compute these values?
Showing values during abstract interpretation
I tried some options for the Eva plugin, but none showed the steps for it.
The most efficient way to follow the evaluation is not via command-line options, but by adding Frama_C_show_each(exp) statements in the code. These are special function calls which, during the analysis, emit the values of the expression contained in them. They are especially useful in loops, for instance to see when a widening is triggered, what happens to the loop counter values.
Note that displaying all of the intermediary evaluation and reduction steps would be very verbose, even for very small programs. By default, this information is not exposed, since it is too dense and rarely useful.
For starters, try adding Frama_C_show_each statements, and use the Frama-C GUI to see the result. It allows focusing on any expression in the code and, in the Values tab, shows the values for the given expression, at the selected statement, for each callstack. You can also press Ctrl+E and type an arbitrary expression to have its value evaluated at that statement.
If you want more details about the values, their reductions, and the overall mechanism, see the section below.
Detailed information about values in Eva
Your question is related to the values used by the abstract interpretation engine in Eva.
Chapter 3 of the Eva User Manual describes the abstractions used by the engine, which are, succinctly:
sets of integers, which are maximally precise but limited to a number of elements (modified by option -eva-ilevel, which on Frama-C 22 is set to 8 by default);
integer intervals with periodicity information (also called modulo, or congruence), e.g. [2..42],2%10 being the set containing {2, 12, 22, 32, 42}. In the simple case, e.g. [2..42], all integers between 2 and 42 are included;
sets of addresses (for pointers), with offsets represented using the above values (sets of integers or intervals);
intervals of floating-point variables (unlike integers, there are no small sets of floating-point values).
Why is all of this necessary? Because without knowing some of these details, you'll have a hard time understanding why the analysis is sometimes precise, sometimes imprecise.
Note that the term reduction is used in the documentation, instead of shrinkage. So look for words related to reduce in the Eva manual when searching for clues.
For instance, in the following code:
int a = Frama_C_interval(-5, 5);
if (a != 0) {
//# assert a != 0;
int b = 5 / a;
}
By default, the analysis will not be able to remove the 0 from the interval inside the if, because [-5..-1];[1..5] is not an interval, but a disjoint union of intervals. However, if the number of elements drops below -eva-ilevel, then the analysis will convert it into a small set, and get a precise result. Therefore, changing some analysis options will result in different ranges, and different results.
In some cases, you can force Eva to compute using disjunctions, for instance by adding the split ACSL annotation, e.g. //# split a < b || a >= b;. But you still need the give the analysis some "fuel" for it to evaluate both branches separately. The easiest way to do so is to use -eva-precision N, with N being an integer between 0 and 11. The higher N is, the more splitting is allowed to happen, but the longer the analysis may take.
Note that, to ensure termination of the analysis, some mechanisms such as widening are used. Without it, a simple loop might require billions of evaluation steps to terminate. This mechanism may introduce extra values which lead to a less precise analysis.
Finally, there are also some abstract domains (option -eva-domains) which allow other kinds of values besides the default ones mentioned above. For instance, the sign domain allows splitting values between negative, zero and positive, and would avoid the imprecision in the above example. The Eva user manual contains examples of usage of each of the domains, indicating when they are useful.
What I have
I've a signal of std_logic_vector. I need to give it values from a ROM, what I already do.
The problem
At the beginning of the simulation or use, there's an initialization process which makes it to need some time before ROM returns it first value (about 2 clk period).
Until then, ROM output vector is "UUUU" (since it's 4 bits of width). Let's call this signal ROM_coef_inf, so in simulation, this appears with "UUUU" value, so its colour is orange.
I need
I need to know how can I compare this output in order to know if it's an "undefined vector", in order to give another value (i.e. "0000") to my vector until the first ROM value is ready.
There are several possible solutions:
You could initialize all registers between your ROM and your destination (at least in simulation) with a different value to "UUUU".
A standard compare can test for all 9 STD_LOGIC values:
if (mySignal == 'U') then
You can test signals for special values with is_x(...).
Is is defined like this:
FUNCTION Is_X ( s : std_ulogic) RETURN BOOLEAN IS
BEGIN
CASE s IS
WHEN 'U' | 'X' | 'Z' | 'W' | '-' => RETURN TRUE;
WHEN OTHERS => NULL;
END CASE;
RETURN FALSE;
END;
There are overload for vectors, too.
I assume this is for FPGA use, in which case all registers will have a predictable value after programming, which is zeros unless you specify something else. If all you need is for ROM_coef_inf to have zeros instead of U's for the first clock cycles in simulation, you can simply specify an initial value when declaring the signal:
signal ROM_coef_inf : std_logic_vector(3 downto 0) := "0000";
In ASICs registers will have an unknown value after power is applied. In this case you need to use a reset signal to clear all the registers in your design. It is often a good idea to use a reset signal in an FPGA as well, for example to prevent your circuit from doing anything until the clock is stable.
The answer provided by #Paebbels works only in simulation. In the real world the signals tend to be either an 1 or a 0 (or a transition between them, but that is not discussed here). Number 1 will work, but you need to set it to a value that will never occur in your ROM if you want to check for uninitialized. The simpler option is to count clock cycles. The ROM will always behave the same. So if it takes three cycles to get the first data out, it will always take three cycles. So if you count three cycles you are ok.
This is related to my previous question. if I don't have the insert, it goes into a recursive loop as expected. But if I do have the insert the program ends. What am I missing here?
rule "Recurse"
when
f : Fibonacci(value == 0)
not Fibonacci(sequence == 0)
then
System.out.println(f.sequence + "/" + f.value);
insert(new Fibonacci(f.sequence - 1));
f.value = 0;
update(f);
end
For the purpose of explaining this example, lets assume:
there is only one rule in the system
that the initial fact set provided to the rule engine meets the criteria of the when in that rule
that sequence is a positive integer value
Firstly, we consider the case where the insert is commented out:
We know that the Working Memory contains at least one object that has value == 0 and there are no objects that have sequence == 0. (I find the more verbose form of not slightly more legible, you can replace not Fibonacci (...) with not ( exists Fibonacci(...))). Note that the rule is valid if there is a single object that meets both criteria.
The consequence sets the object's value to zero and notifies the engine that this object has changed. An infinite loop is then encountered as there is no object in the system with sequence == 0 and we've set the value to be such that this object will trigger the rule to fire.
Now, lets consider the case where the insert is uncommented:
We already know that the initial fact set fires the rule at least once. The consequence is that now an object is placed in working memory which has a decremented sequence and the object referenced by f has its value set to zero (it isn't changed from zero) and updated. There is a mechanism in place by which the end conditions are met, since now, at some point there will be an object inserted that has a zero sequence. That meets the end condition.
In short: the engine will exit when there is a Fibonacci object with sequence zero in it.
I, err.., think that this system might need a little bit of changing before it will output the Fibonacci sequence. You need a way to reference the previous two Fibonacci numbers to evaluate the one being set, the recursive method is much more elegent ;)
Apologies for making this my second Z80 DAA question - I have pretty much implemented this instruction now, but there is one thing I'm not sure about - is the H flag set by this instruction at all? The Z80 manual says 'see instruction', but it only mentions the flag before DAA, not after it is executed.
I set the flags as follows:
S is set if result is negative (0x80 & result equals 0x80)
Z is set if result is zero
H (not sure hence this question)
P/V is set to the parity of the result (1 if even, 0 if odd)
N is left alone
C is set if the higher nibble of the original accumulator value is modified
Other than this, the instruction seems to perform as I expect it to :-) I hope someone can clear this up for me, many thanks.
I could only find here that the half-carry/borrow flag is modified by DAA.
I recommend that this flag be set exactly as the AF (auxiliary carry) flag is set by the DAA and DAS instructions on x86 CPUs. I see no reason why there should be any difference in operation between i8080/i8085/Z80's and i8086's DAA/DAS.
The x86 DAA/DAS sets AF to 1 if it adjusts the lowest 4 bits of the accumulator by 6. If it does not adjust them, it resets AF to 0.
See the pseudo-code for DAA and DAS in the intel's (or AMD's) x86 CPU manuals.
It's a good question. Yes, H flag's behaviour is not clearly documented because it is behaviour is non-standard with DAA.
If lower nibble (least significant four bits) of A is a non base-10 number (greater than 9 like A,B,C,D,E or F) or H flag is set, 6 is added to the register. This means even if lower nibble is in 0-9 range, you can force to add 6 to A register by setting H flag.
When it comes to your question, H flag usually remains untouched in my experience but you cannot depend on that because it is said that "the effect is non-standard" which means H flag may change or may not change depending on the situation. In cases like this, you should always think H flag is affected by the DAA instruction after execution even if you see it is not affected in your tests.