1) When this procedural block will be executed?
output a;
reg a;
always#(a)
begin
// Do something...
end
In C this would be executed when "a" has a value non-zero.
2) When this if statement would be true?
if(!a)
begin
// Do something...
end
I come from C and I'm actually confused about Verilog.
verilog is 4-state simulator, meaning that any bit in a variable could have one of the 4 values: 0, 1, x and z. 'x' expresse an unknown value and all variables in verilog are initialized to this value at the beginning.
now if a is initizlized to x, the following statements will always fail:
if (a) -> because x cannot be true (in verilog)
if (!a) -> false, because !x is also unknown and is x;
You should check verilog 4-state simulation and arithmetic rules.
Always block, on the other hand, will wait till value of 'a' changes, for exemple, from 'x' to '0'.
always #(a) ...
So, untill you assign a value of '1', the 'if' statement will fail and always block will not execute till you change the value of 'a' to something different from 'x'. Initilzation of those variables is usually done in test bench code, say in an initial block. For example
initial #10 a = 1; // initialize 'a' to '1' after 10 time units.
Since you coming from 'c', there is a big difference in the language concept. Verilog is a parallel programming language, it means that all procedural blocks are executed preemptively in parallel. inital blocks and always blocks are procedural blocks. Statements in side a block are executed sequentially, but two different blocks are executed in parallel. Events and delays cause preemption.
Related
I have an inferred latch problem after synthesis when I designed a simple dual port RAM block. Due to large code size, I have just embedded this always block code as follows:
integer i;
always_latch
begin
for (i=0;i<NUM_RAMS;i=i+1) begin
if (ena_t == 1) begin
w_addra_t[i] = w_addra[i];
end
else begin
w_addra_t[bank_addra[i]] = w_addra[i];
end
end
end
My RAM block includes NUM_RAMS numbers of banks. The addresses of respective input data are stored in w_addra.
Data with given w_addra addresses are scrambled into w_addra_t depend on the values of respective bank_addra (depend on access pattern) when ena_t = 0.
I tried to replace for loop with if...else, switch...case, generate but the problem is same. With different always block in my code that the left-side is with only w_addra_t[i] in both if.else of ena_t, there is no error.
I would like to get your suggestion if you have any idea. I did look for similar issue but getting no results.
Thanks very much :)
My guess is the entries for bank_addra are not guaranteed to be unique. If two or more entries hold the same values then an index hole is created for w_addra_t; which will infer a latch.
Here are three possible solution:
Functionally guaranteed that bank_addra entries will have unique values, then the synthesizer should not infer a latch. This can be challenging.
Move the address variation from the LHS to the RHS so that each index of w_addra_t is guaranteed to be assigned a value. Ex change w_addra_t[bank_addra[i]] = w_addra[i]; to w_addra_t[i] = w_addra[bank_addra_lookup[i]];.
Assign all entries of w_addra_t to a known value (constant, flip-flop, or deterministic value) before other logic. You can put this default assignment at the top of your always block (option 1 example) or above the logic where the latches were about to be inferred (option 2 example). This is the simplest solution to implement assuming it still satisfies relational requirements with your other code.
// NOTE: SystemVerilog supports full array assignments (Verilog requires a for-loop)
always_comb
begin
w_addra_t = '{default:'0}; // <-- default assignment : option 1
if (ena_t == 1) begin
w_addra_t = w_addra;
end
else begin
w_addra_t = w_addra_t_ff; // <-- default assignment : option 2
for (i=0;i<NUM_RAMS;i=i+1) begin
w_addra_t[bank_addra[i]] = w_addra[i];
end
end
end
always_ff #(posedge clk) begin
w_addra_t_ff <= w_addra_t; // assuming w_addra_t should hold it current values
end
TL;DR
always_latch is a SystemVerilog keyword to identify explicit latches. Some tools will auto-waive the warning when the keyword is used, but will throw an error/warning if the keyword is used and a latch is not detected.
If you know it should be combinational logic, then use the always_comb SystemVerilog keyword. With always_comb, if the synthesis detects a latch then it should report an error.
Read related question:
What is inferred latch and how it is created when it is missing else statement in if condition. Can anybody explain briefly?
I don't know if it will solve your problem by changing to
int i
always_comb
instead. Perhaps the tool gets sad when you use a 4-state variable like integer?
I am doing a computer architecture course on Coursera called
NandtoTetris and have been struggling with my 16-bit CPU design. The
course uses a language called HDL, which is a very simple Verilog like
language.
I have spent so many hours trying to iterate on my CPU design based on
the diagram below and I don't understand what I am doing wrong. I
tried my best to represent the fetch and execute mechanics. Does
anyone have any advice on how to solve this?
Here are the design and control syntax diagram links:
CPU IO high-level diagram:
Gate level CPU diagram:
Control instruction syntax:
Here is my code below:
// Put your code here:
// Instruction decoding:from i of “ixxaccccccdddjjj”
// Ainstruction: Instruction is 16-bit value of the constant that should be loaded into the A register
// C-instruction: The a- and c-bits code comp part, d- and j-bits code dest and jump(x-bits are ignored).
Mux16(a=outM, b=instruction, sel=instruction[15], out=aMUX); // 0 for A-instruction or 1 for a C-instruction
Not(in=instruction[15], out=aInst); // assert A instruction with op-code as true
And(a=instruction[15], b=instruction[5], out=cInst); // assert wite-to-A-C-instruction with op code AND d1-bit
Or(a=aInst, b=cInst, out=aMuxload); // assert Ainstruction or wite-to-A-C-instruction is true
ARegister(in=aMUX, load=cInst, out=addressM); // load Ainstruction or wite-to-A-C-instruction
// For C-instruction, a-bit determines if ALU will operate on A register input (0) vs M input (1)
And(a=instruction[15], b=instruction[12], out=Aselector); // assert that c instruction AND a-bit
Mux16(a=addressM, b=inM, sel=Aselector, out=aluMUX); // select A=0 or A=1
ALU(x=DregisterOut, y=aluMUX, zx=instruction[11], nx=instruction[10], zy=instruction[9], ny=instruction[8], f=instruction[7], no=instruction[6], zr=zr, ng=ng,out=outM);
// The 3 d-bits of “ixxaccccccdddjjj” ALUout determine registers are destinations for for ALUout
// Whenever there is a C-Instruction and d2 (bit 4) is a 1 the D register is loaded
And(a=instruction[15], b=instruction[4], out=writeD); // assert that c instruction AND d2-bit
DRegister(in=outM, load=writeD, out=DregisterOut); // d2 of d-bits for D register destination
// Whenever there is a C-Instruction and d3 (bit 3) is a 1 then writeM (aka RAM[A]) is true
And(a=instruction[15], b=instruction[3], out=writeM); // assert that c instruction AND d3-bit
// Programe counter to fetch next instruction
// PC logic: if (reset==1), then PC = 0
// else:
// load = comparison(instruction jump bits, ALU output zr & ng)
// if load == 1, PC = A
// else: PC ++
And(a=instruction[2], b=ng, out=JLT); // J2 test against ng: out < 0
And(a=instruction[1], b=zr, out=JEQ); // J1 test against zr: out = 0
Or(a=ng, b=zr, out=JGToutMnot)); // J0 test if ng and zr are both zero
Not(in=JGToutMnot, out=JGToutM; // J0 test if ng and zr are both zero
And(a=instruction[0], b=JGToutM, out=JGT);
Or(a=JLT, b=JEQ, out=JLE); // out <= 0
Or(a=JGT, b=JLE, out=JMP); // final jump assertion
And(a=instruction[15], b=JMP, out=PCload); // C instruction AND JMP assert to get the PC load bit
// load in all values into the programme counter if load and reset, otherwise continue increasing
PC(in=addressM, load=PCload, inc=true, reset=reset, out=pc);
It is tricky to answer these kinds of questions without doing the work for you, which isn't helpful to you in the long run.
Some general thoughts.
Consider each element in isolation (including the circles where signals come together).
Label each line between elements with a name. These will become internal control lines. It helps reduce the chances of confusion.
Be very careful about junk outputs. If you're not supposed to be putting valid data on outM, use a Mux to output false.
Potential gotcha: I seem to remember that it's a bad idea to use a design output (like outM) as an input to something else. Outputs should only be outputs. Right now you are sending the output of the ALU to outM and using outM as an input to other elements. I suggest you try outputting the ALU to a new signal "ALUout", and using that as the input for the other elements and (through a mux with false controlled by writeM) outM. But remember, writeM is an output! So the block that generates writeM needs to generate a copy of itself to use as the control to the mux. FORTUNATELY, a block can have multiple out statements!
For example, right now you're generating outM like this (I won't comment on whether it is wrong, I am just using it as an illustration):
And(a=instruction[15], b=instruction[3], out=writeM);
You can create a second output like this:
And(a=instruction[15], b=instruction[3], out=writeM, out=writeM2)
and then "clean" your outM like this:
Mux16(a=false,b=ALUout,sel=writeM2,out=outM);
Good luck!
I understand that, for 2 always blocks with the same trigger, their order of evaluation is completely unpredictable.
However, suppose I have:
always #(a) begin : blockX
c = 0;
d = a + 2;
if(c != 1) e = 2;
end
always #(a) begin : blockY
e = 3;
end
always #(d) begin : blockZ
c = 1;
e = 1;
end
Suppose block X evaluates first. Does changing d in blockX immediately jump to blockZ? If not, when is blockZ evaluated with respect to blockY?
My programmer's instinct thinks of the sequence of events as a stack, where evaluating blockX is like a function call to blockZ and I immediately jump there in the code, then finish evaluating blockX.
However, because we call the active events queue, well, a queue, this suggests blockZ is enqueued at the back of the active events queue, and I'm 100% guaranteed it will be evaluated last (unless there are other triggered always blocks).
There's also the intermediate possibility, where it's neither first nor last but is also evaluated in a random and unpredictable order.
So in this example, are 1, 2, or 3 all possible final values for e, depending on how the compiler is feeling at run time?
Additionally, while I understand, of course, this represents awful style, where might I find the specification for this kind of behvaior?
Always blocks are not function calls. See a recent answer I just gave for a similar question. These blocks are concurrent processes. The LRM only guarentees the ordering of statements within a begin/end block. There is no defined ordering between concurrently executing begin/end blocks (See Section 4.7 Nondeterminism in the 1800-2012 LRM) So a simulator is free to interleave the statements in any way as long as it honors the order within a single block.
So you are correct that e could have the final values 1, 2 or 3 depending on how a simulator decides to implement and optimize your code.
Is these two codes behave in the same way ?
always #(a == 1'b1) // I guess for this one, it's like a combinational if (AND gate logic : a AND 1).
// code
and
always #(a) begin // I guess for this one, if a= 1 from the time 0,
// it won't go inside since there wouldn't be any change.
if (a == 1) begin
// code
end
end
Is it true ?
It's a basic question but I'd like to know if I miss something, thank you!
Nope, both are not same.
Note that variables in the sensitivity list are considered as an event
and hence they are not executed, rather just change in the variable is
considered as a trigger to that event.
So the 1st always block
always # (a==1'b1)
is same as :
always # (a)
So 1st always block will execute with both a = 1 & 0, whereas in 2nd case, because of "if" condition, it will be executed only with a = 1
Say I have a scenario in which I need to compare only a few bits of a register and I don't care about other bits. eq, I need to check the first and last bits of a 3 bit register (A[2:0]) and I don't care about the middle bit, say compare vector is 3'b1X0 (Parameter).
Simplest way to do this is choose all the bits I care about, AND them and I have generated a control signal:
if ((A[2]==1) & ((A[0]==0)) Here the condition inside if statement is my control signal.
Another way is to use a casex statement: casex(A) begin 3'b1?0: ... , ... endcase.
Is there anything like ifx-elsex statement or something that can be used to do this kind of operation without using the 1st and 2nd method?
Thanks!
if (A[2:0] inside {3'b1?0} )
SystemVerilog keyword inside. It has been supported since at least Accellera's SystemVerilog 3.1 (before SystemVerilog was a part of IEEE). IEEE Std 1800-2012 11.4.13 has examples of use. inside is synthesizable.
There is also if ( A[2:0] ==? 3'b1?0 ) (IEEE Std 1800-2012 11.4.6). The only reference I have on hand (a book published 2004) says it is not supported for synthesis yet. You are welcome to try it.
(A[2]==1) is a logical expression the & is a bitwise operator, although either works it would be better semantics to use the && logical and operator. This is slightly different to most other languages where the && is a short-circuit operator.
Logically what you want is if ((A[2]==1) && ((A[0]==0)) but it could be reduced to a bitwise expression :
if ( ~A[0] & A[2] )
NB: Try to avoid using casex, the unknown parts will match x's in simulation. Try to use casez instead, ? can still be used to match don't cares.
Update comparing inside to casez
Case statements a clean control structure used in most languages to avoid large if elsif else chains. the inside operation will match x's to the do not care '?' values. this makes it usage similar to the casex which is considered to be bad practise to use as it can hide simulation fails.
casez(sel)
4'b1??? a= 3'd4;
4'b01?? a= 3'd3;
4'b001? a= 3'd2;
4'b0001 a= 3'd1;
4'b0000 a= 3'd0;
endcase
vs
if (sel inside {4'b1???})
a= 3'd4;
else if (sel inside {4'b01??})
a= 3'd3;
else if (sel inside {4'b001?})
a= 3'd2;
...
The above is actually equal to the casex (but more verbose) I believe that instead of casex you could also use :
case(sel) inside
4'b1??? a= 3'd4;
4'b01?? a= 3'd3;
4'b001? a= 3'd2;
4'b0001 a= 3'd1;
4'b0000 a= 3'd0;
endcase
but then I would never use a casex.
There's no operator I'm aware of that allows you to use '?' or 'x' inside an equality comparison to have them ignored.
Another alternative that you didn't mention would be to use a bitmask to select the bits you only care about. If you have a lot of bits this can be more compact than testing each bit individually.
If you only care about A == 3'b1?0, then it can be written as such:
if((A & 3'b101) == 3'b100)