The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Design Languages >> Verilog-AMS >> concurrency semantics in VerilogA
https://designers-guide.org/forum/YaBB.pl?num=1199719693

Message started by rajdeep on Jan 7^th, 2008, 7:28am

Title: concurrency semantics in VerilogA
Post by rajdeep on Jan 7^th, 2008, 7:28am

Hi there,

I've got a confusion regarding usage of two cross statements in the same analog process. Following is the code section..

Quote:

@(cross(V(clk)-thresh,-1)) begin
if((V(enable) > thresh) && (n>0)) begin
count = count + 1;
end
else
count = 0;
end

@(cross(V(clk)-thresh,-1)) begin
if((V(enable) > thresh) && (n>0) && (count==n-1)) begin
save_value = V(value_in);
save_time = V(time_in);
end
end

As you can see I'm upadating a variable named count in the first cross statement and then trying to use the same count variable in the second cross statement. I'm not sure whether the next cross block would see the updated value or an older value of count, evaluated in the previous simulation time point. From simulation results I found it is seeing the updated value, which means the 2 cross blocks here are not truely concurrent!! But then their triggering condition is same and they are supposed to be simulated at a single time point. I'm pretty confused. Following are the 2 questions, I think are fundamental to this confusion.

1. Is it semantically defined what would be the value of count in the second cross block?? count is an integer variable, what if it was an electrical signal??
2. Are the = statements blocking statements like Verilog??

Thanks!
Rajdeep

Title: Re: concurrency semantics in VerilogA
Post by Geoffrey_Coram on Jan 7^th, 2008, 12:46pm

rajdeep wrote on Jan 7^th, 2008, 7:28am:

...the 2 cross blocks here are not truely concurrent!! But then their triggering condition is same and they are supposed to be simulated at a single time point. I'm pretty confused. Following are the 2 questions, I think are fundamental to this confusion.

1. Is it semantically defined what would be the value of count in the second cross block?? count is an integer variable, what if it was an electrical signal??
2. Are the = statements blocking statements like Verilog??

I don't think you should expect them to be concurrent; Verilog-A statements are evaluated sequentially. Semantically, therefore, you should expect to get the updated value of count in the second block.

= statements are not blocking; "blocking" doesn't make sense in an analog simulator.

If you had an electrical signal, you'd have to worry about a different set of things, like not sourcing and probing a voltage on the same branch, and the fact that you can't contribute (<+) inside an event.

Title: Re: concurrency semantics in VerilogA
Post by Ken Kundert on Jan 7^th, 2008, 9:12pm

In your example you can combine the @cross blocks, which would eliminate any confusion.

-Ken

Title: Re: concurrency semantics in VerilogA
Post by rajdeep on Jan 9^th, 2008, 2:33am

Hi all,

Thanks a lot for the replies.

Quote:

= statements are not blocking; "blocking" doesn't make sense in an analog simulator.

But then a sequential execution of statements is similar to be blocking!! Isn't it?
a=b; c=a; will make c equal to b!! It is because, the next statement c=a's execution was blocked till the 1st statment is executed.
But in case of concurrent simulation c would have taken the older value (evaluated in the last time step) of a.

But it's a fact that statements where real and integer variables are assigned values, are all executed sequentially. That's what I observed so far. But really though cross statements are executed paralley, pretty much like always blocks. It does not matter though if it is semantically defined and I understand that. :)

Rajdeep

Title: Re: concurrency semantics in VerilogA
Post by Ken Kundert on Jan 9^th, 2008, 11:30am

Statements in verilog-a are all non-blocking. By this I mean that no statement will pause execution of the model.

In an initial or always block (in Verilog), if you have

@(posedge clk) ...

the execution of the model will pause at that statement until a rising edge occurs on clk, then execution proceeds. Similarly, if you have

x =#10 y;

then execution pauses 10 ticks before moving on to the next statement.

These things do not occur in analog blocks (in Verilog-A). First off, blocking constructs such as # and wait are not supported in an analog block. @ statements are supported, but code included in the @ block is simply skipped except when the event triggers their execution. In this way, execution is never blocked. The entire analog block is evaluated at every timestep except for code within if and @ statements that are not active, which is simply skipped.

Thus in your example, the code is always evaluated in order, and the code within the event blocks is skipped except at the falling threshold crossings of V(clk). Since both @ blocks are triggered with the same event, they will always execute together, and of course, in order.

-Ken

Title: Re: concurrency semantics in VerilogA
Post by rajdeep on Jan 9^th, 2008, 9:13pm

Then can we say that the statements in Verilog-A are NOT executed like a set of non-blocking statements in Verilog?? :-/

I mean a<=b; c<=a; c wud get the older value of a in verilog, but in VerilogA c wud get the value of b. Am I right?

Rajdeep

Title: Re: concurrency semantics in VerilogA
Post by Ken Kundert on Jan 10^th, 2008, 1:34am

With assignments in Verilog there are several different things going on at once. In particular ...
1. The time when the right-hand side is evaluated.
2. The time when the assignment to the left-hand side occurs.
3. Whether assignment includes delay.
4. Whether the delay blocks execution.

Assignments using the "=" operator are considered blocking assignments because if they include delays they will block execution during the delay. In this case, the order of evaluation is ...
1. evaluate the right-hand side.
2. block execution for the length of the delay.
3. assign the value to the left-hand side.
4. execute the next statement.

Assignments using the "<=" operator are considered non-blocking assignments because they do not block execution even if they include delays. In this case, the order of evaluation is ...
1. evaluate the right-hand side.
2. execute the next statement.
3. continue execution while waiting for the length of the delay.
4. assign the value to the left hand side.

Analog assignments never block. So the order of evaluation is ...
1. evaluate the right-hand side
2. assign value to the left-hand side
3. execute the next statement.

So the point is analog statements are all non-blocking. But this does not mean that analog assignments act in the same way that traditional verilog non-blocking assignments act. Traditional verilog non-blocking assignments have behavior in addition to the fact that they do not block execution that is different from the behavior of analog assignments.

The behavior of analog assignments is the same as the behavior of assignments in traditional programming languages. It is also the same as simple verilog assignments that contain no delay.

For example,

Code:

analog begin
a = b;
c = a;
end

would end up with c getting the value of b, as you say.

-Ken

Title: Re: concurrency semantics in VerilogA
Post by rajdeep on Jan 10^th, 2008, 11:21am

Thanks Ken!! I do not have any confusion any more.

Rajdeep