Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

always block blocking assigment synthesis

Status
Not open for further replies.
B

brasilino

Newbie level 4
Newbie level 4
Joined
Mar 4, 2014
Messages
5
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
26
Hi,

I'm not a Verilog guru but have some experience. My question is about how a always block is synthetized in hardware, not its behaviour.

let's suppose I've got an always block as:

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9

input wire a, b, c;
output reg y;
 
always @(*)
begin
    y = a;
    y = y & b;
    y = y & c;
end


Since I'm using a blocking assigment and y is a 1-bit reg, it should be inferred as a FF, so it should need some pulse signal to latch the previous bitwise operation result.

My question is: once synthetized in a FPGA, this circuit seems to need a sequence of 3 clock-like pulse signal, one for each assignment. Am I right ?

Thanks!
regards
Brasilino
 
Last edited:

y - is not FF, it's just a piece of combo logic (as it doesn't have clock/reset specified).
In this case your code is equivalent to:
Code: 
input wire a, b, c;
output y;
wire y0, y1;
 
assign y0 = a;
assign y1 = y0 & b;
assign y = y1 & c;
 
brasilino,

Dont't get confused by the term "reg". When verilog was developed originally it was meant to be only register. But later the verilog LRM redefined its meaning to be just a variable that can be used to model either a register or latch or gates.

Pasting here a detailed post on that
http://blogs.mentor.com/verificationhorizons/blog/2013/05/03/wire-vs-reg/

There are two flaws in your coding.
1. You are trying to assign the variable y three times. The synthesis and simulation tools will ignore the first two statements (y = a and y = y & b). Only the last statement tools will consider. This behavior is defined in the verilog LRM.

2. The statement y = y & c will result in combinational loop as you are feeding the output of the same AND gate to its input.
 
There are two flaws in your coding.
1. You are trying to assign the variable y three times. The synthesis and simulation tools will ignore the first two statements (y = a and y = y & b). Only the last statement tools will consider. This behavior is defined in the verilog LRM.

2. The statement y = y & c will result in combinational loop as you are feeding the output of the same AND gate to its input.
Click to expand...
Both comments are wrong. You are ignoring the operation of blocking assignments.

The three lines can be however combined to a single statement.
Code: 
    y = a & b & c;
Of course it can be also written as a continuous assignment without a process.

Although it makes no difference for bit variables, we would use a logical && and instead of a bitwise & operator, just for clarity.
 

I doubt the above code will result in the behavior y = a & b & c;
Are you sure the synthesis will result in y = a & b & c ?

My comment may be wrong in the context of blocking assignment.
 

The code is synthesizing as three input AND gate. What do you expect else?
 
Last edited:

Thanks for the reply.

mr_vasanth said:
My comment may be wrong in the context of blocking assignment.
Click to expand...

I agree with FvM, you are forgetting the blocking assignment.

But, anyway, my question was in the regards of hardware synthesis, not its behaviour. Makes sense on the verilog preprocessor/compiler/whatever to infer a three port AND gate.

My question was based in what literature says, that the code:

Code Verilog - [expand]
1
2
3
4
5
6

always @(*)
begin
    y = a;
    y = y & b;
    y = y & c;
end


Is evaluated in a procedural manner, I mean, each statement being "assigned" by time.

So I was wondering how actually the circuit are connected within a FPGA.


Brasilino.

- - - Updated - - -

kornukhin said:
y - is not FF, it's just a piece of combo logic (as it doesn't have clock/reset specified).
In this case your code is equivalent to:
Code: 
input wire a, b, c;
output y;
wire y0, y1;
 
assign y0 = a;
assign y1 = y0 & b;
assign y = y1 & c;
Click to expand...

Yep, I know it is equivalent to this latter one. But if this circuit is 'wired' into a FPGA, each assignment run concurrently and, for a period of time, y can be a wrong value - if, por example, its propagation time is lower than y1 propagation time. So, for a short period of time, this circuit is somewhat non-deterministic.

- Brasilino.
 

Is evaluated in a procedural manner, I mean, each statement being "assigned" by time.
Click to expand...
I'm not sure what you exactly mean with "by time". If you are assuming any kind of sequential action in time, you are misunderstanding HDL synthesis.

The "sequential" aspect in procedural statements describes only the order of evaluation. But at the end, the sequence is "executed" in no time. In the present case, the order of second and third line is irrelevant because both AND2 operations are combined to an AND3 and synthesized in a single logic element.

But, anyway, my question was in the regards of hardware synthesis, not its behaviour.
Click to expand...
I think the equivalence of behavioral description and hardware is quite obvious in the present case.

P.S.:
Yep, I know it is equivalent to this latter one. But if this circuit is 'wired' into a FPGA, each assignment run concurrently and, for a period of time, y can be a wrong value - if, por example, its propagation time is lower than y1 propagation time. So, for a short period of time, this circuit is somewhat non-deterministic.
Click to expand...
As said, you can be very sure that everything ends up in a single logic element (at least as long as you don't enforce a specific hardware topology by synthesis attributes). So the only non-deterministic behaviour that might happen is caused by propagation delay skew of the logic element representing the AND3 gate and arbitrary routing delay. But these effects aren't determined by the HDL expression because it doesn't involve a priority for one or the other logic input.

In other words, you are describing effects that happen in real hardware, but they aren't related to the discussed problem.
 
Last edited:

I agree with FvM. the result equals to y=a&b&c.

PHP: 
Yep, I know it is equivalent to this latter one. But if this circuit is 'wired' into a FPGA, each assignment run concurrently and, for a period of time, y can be a wrong value - if, por example, its propagation time is lower than y1 propagation time. So, for a short period of time, this circuit is somewhat non-deterministic.

brasilino mentioned the circuit is non-deterministic for a short period. That's the combinational competetion&risk and unavoidable. But it's not a isssue if we always sample it at the determined period (by proper logic and timing).
:grin:

FvM said:
I'm not sure what you exactly mean with "by time". If you are assuming any kind of sequential action in time, you are misunderstanding HDL synthesis.

The "sequential" aspect in procedural statements describes only the order of evaluation. But at the end, the sequence is "executed" in no time. In the present case, the order of second and third line is irrelevant because both AND2 operations are combined to an AND3 and synthesized in a single logic element.


I think the equivalence of behavioral description and hardware is quite obvious in the present case.

P.S.:

As said, you can be very sure that everything ends up in a single logic element (at least as long as you don't enforce a specific hardware topology by synthesis attributes). So the only non-deterministic behaviour that might happen is caused by propagation delay skew of the logic element representing the AND3 gate and arbitrary routing delay. But these effects aren't determined by the HDL expression because it doesn't involve a priority for one or the other logic input.

In other words, you are describing effects that happen in real hardware, but they aren't related to the discussed problem.
Click to expand...
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top