Non-Blocking versus blocking

Thu May 20, 2010 8:28 pm   

On May 20, 3:08 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:


Can you show a real-world example of this danger?


Blocking assignments to "registers" inside non-clocked blocks and
continuous assignments to "wires" are essentially the same thing. I
don't see this as any kind of coincidence. If proof of a non-clocked
set of gates requires some sort of inherent propagation delay, that
might make the proof suspect, unless you can also prove that the
propagation delay is the correct magnitude.


In general, the bad effects of a race in your test bench will be that
the test fails. In general the bad effects of a post-synthesis race
are either, again, that the test fails (if you are lucky) or that the
silicon fails (if you are unlucky). So why is it a problem to explain
things in the context of synthesis?


[ Rest of comment on this snipped. ]

Yes, this will work. But in practice, examination to insure that
these guidelines have been followed can be more time-consuming than if
other guidelines are followed, and it may be possible, using just
these guidelines, to write code that may be more conceptually
difficult to understand than the code you write using other
guidelines. But that's (obviously) just my opinion.

Regards,
Pat

Thu May 20, 2010 9:34 pm   

On Thu, 20 May 2010 10:28:11 -0700 (PDT), Patrick Maupin wrote:


Easily, if you will permit the choice of "real world" to
extend somewhat outside the very constrained bounds of
RTL-for-synthesis.


I suspect that Jan, like me, is unhappy about Verilog's
completely uncontrolled concurrency model.

Decades ago, software folk discovered that you need some
structures and disciplines to make concurrency work.
Without them, processes merrily trample on each other's
variables and all bets are off. There are many possible
ways to do it right, some prettier than others:

- evaluate/update disciplines (VHDL, SystemC, various other
discrete-event simulation languages)
- semaphores (readily available as OS primitives in many
environments)
- monitors (ditto) - VHDL protected types are a bit like this
- Ada-style client-server rendezvous
- CSP (Occam, Handel-C, Haste)

And then there's Verilog:
- anyone can mess with any shared variable at any time,
with an explicit caveat in the language that you can't
expect any kind of built-in control

So I would totally support Jan's position that combinational
logic, with its acyclic dependencies and stateless behaviour,
is a special case that just happens to work well in Verilog.
The late addition of nonblocking assignment to Verilog was,
I suggest, an admission that this uncontrolled concurrency
was indeed a very serious problem in other situations.
Clocked logic is just one such, but one that is likely to
be evident and problematic for hardware designers.


In the synthesis mindset, yes. But only there. In the
semantics of Verilog as a simulation language (and that's
how it's defined) they are as different as chalk and cheese.
They happen to give the same results if you use them
to model zero-delay combinational logic. Of course
that is partly a reflection of Verilog's cleverly
focused design for its chosen applications.


No more than the "coincidence" that concurrent signal
assignment and a combunational-style process in VHDL
are exactly equivalent by definition. And there they
both exhibit delta-delay behaviour. Once again:
combinational logic is a special case that can be
handled in a variety of ways. Some of those ways don't
work reliably for more general concurrency problems.


There is of course no such "proof"; indeed, the nature of
combinational logic (output must be a pure function of
inputs) makes it possible to prove just the opposite.
I don't think that in any way invalidates Jan's concerns,
except possibly from a myopic RTL-centric viewpoint.
--
Jonathan Bromley

Fri May 21, 2010 12:28 am   

On May 20, 3:34 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

OK, I'll bite. Show me...

[ Other stuff snipped..]


While the language constructs are nice, certainly it is possible to do
useful concurrency work in C. And semaphores, monitors, and mutexes
are used from C every day without a fundamental language rework. (As
an aside, while erlang or go may be the way of the future, replacing
Ada and Occam as the way of the future, and while the C/C++ standard
may lurch towards the future by digesting those really useful bits
from other languages, it is possible that the dominant system language
for a long time to come will be called C, just as the dominant
technical language is called English.)


Au contraire. It may not be as great as some of the languages you
mentioned, but it's certainly much better than C. If you want to
insure that another process can never see incoherent state between
variable X and variable Y, just make sure you update them at exactly
the same time. No semaphore, mutex, or monitor required. Also,
unlike C, (assuming you at least follow the rule of at most one module
per file) two different processes in different files cannot write to
the same "shared variable" in synthesizable code at all, and can't
very easily do it inadvertently in non-synthesizable code.


Special case, perhaps. Coincidence? I think not :-)


I do view the synthesis results as the end product, yes. Anything
that has to be done in the testbench is ancillary to that (and by the
way, Verilog's laissez-faire attitude to coding is a double-edged
sword that can, in some cases, make the test code very readable and
maintainable).


Agreed.


Guilty as charged. While the process of getting to correct
synthesizable logic is interesting, useful, and necessary, the actual
synthesizable logic itself is, if not more interesting, at least more
useful and necessary.

Regards,
Pat

Fri May 21, 2010 10:44 am   

Patrick,

I don't have time to write a complete reply just now,
but I can't let this piece of nonsense go unchallenged:

[me]

[Pat]

That is simply untrue:

always @(posedge clock)
X = some_expression;
always @(posedge clock)
Y = some_other_expression;
always @(posedge clock) begin : observer
if (some relationship between X and Y) ....;
end

"observer" has absolutely no guarantee of coherence of X and Y.
So, you may say, let's update them together:

always @(posedge clock) begin
X = some_expression;
Y = some_other_expression;
end

Bzzzt! Doesn't work: Verilog does not guarantee atomic execution
of a zero-time sequential block, so "observer" still has no
guarantee of coherence. So we must resort to yet another
special case (and even this unusable mess isn't strictly
guaranteed to give atomic update, even though it will
most likely do so in practice):

always @(posedge clock)
{X,Y} = {some_expression, some_other_expression};


You're kidding, right? In Verilog you make this
work correctly by wheeling out the evaluate/update
model made possible by nonblocking assignment.
In other environments you would use other exclusion
or synchronisation primitives. Either way, you need
some discipline.

Verilog is _much_ worse than C in this regard because
it has concurrency constructs built in to the language,
but they are completely undisciplined. In C, to get
concurrency you must appeal to some library or toolkit;
if properly designed, that library will provide not
only the parallelism but also the synchronisation
primitives that you need, so you get a proper way to
do things as a single package.

I'll try to respond more thoughtfully to your other
points over the weekend.
--
Jonathan Bromley

Fri May 21, 2010 11:13 am   

On May 20, 10:15 am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

Personally I think this is a strange concept that a zero-delay sim
should be... I can't think of a word, "optimized" is not right,
"tweaked" seems biased... "adjusted" to allow a particular type of
design to simulate as if there were no delay in a logic element, but
that there is a delay in sequential elements. This can be handled
very easily by adding explicit delays to sequential elements. Then it
is very clear that an assumption is being made about relative delays.
I guess this shows that I never gate clocks. I can see how this would
be a real can of worms.

Has anyone here used clock gating in VHDL? How do you handle that?



Except that it produces a glitch free output which is not realistic.
Of course, in the real world the implemented logic will be determined
by the tools so there may or may not be a glitch in the output. So I
guess this is similar to clock gating.



Wow! I didn't know it worked like that. I don't think that is the
same in VHDL. I think the VHDL "after" delay is done without blocking
the execution of the sequential flow even for variables.



Yeah, it will be interesting to learn.

Rick

Fri May 21, 2010 11:19 am   

On May 20, 1:28 pm, Patrick Maupin <pmau...@gmail.com> wrote:

This last guideline is essentially what VHDL does. Variables only
have scope within a process so can not be used for communication
between processes. What guidelines would accomplish the same thing
and be easier to verify? Sounds like something a tool should be
checking for you.

Rick

Fri May 21, 2010 12:07 pm   

On May 20, 7:28 pm, Patrick Maupin <pmau...@gmail.com> wrote:

Use blocking assignments for communication anywhere else, and you
immediately have race problems. Just look in the manuals of mainstream
synthesis vendors for plenty of problematic examples.

"As a matter of forming good coding habits", avoid blocking
assignments for communication altogether, and stop worrying about
races.


That is not what I was talking about.

Suppose you start manipulating clocks combinatorially, using assigns
or blocking assignments. I don't see why the resulting transactions
would be race-free. I immediately add that this is probably
nonsensical usage, and that in practice, blocking assignment-based
communication works for the special case of "meaningful" combinatorial
logic. But do you see why I call that a coincidence? It feels like
plain luck based on shaky foundations.


Given the fact that races are costly in any case, do you see the value
of having one single guideline that covers everything?


I have a single guideline that covers everything; Cummings has a set
of guidelines that covers synthesis only and that introduces a number
of special cases. It seems obvious that my proposal will make the work
of the reviewer or the linting tool both more meaningful and much
simpler.

Jan

Fri May 21, 2010 2:12 pm   

On May 20, 10:34 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:


Absolutely correct. Rather unhappy :-)

In 1990, I designed a chip with Verilog, using blocking assignments
only because that's all there was at the time. Non-blocking behavior
was provided by using modules and ports - otherwise Verilog would have
been completely unusable at the time.

Much later, in 2000, I found out that simulation vendors had exploited
loopholes in the Verilog standard to take away non-blocking behavior
from ports. In other words, my trusted coding style and legacy code
had now become undeterministic and unreliable.

When I complained about this, I experienced not a single grain of
sympathy or understanding from the Verilog design community. Instead,
they started to explain the loopholes to me. The message was that I
had been stupid to think that it was possible to design with Verilog
in a reliable way at the time.

At that moment, I developed a fundamental distrust against Verilog's
zero-delay (non)model, and against Verilog's design community and its
guru's in the same pass. I learned to forgive VHDL almost anything
just for giving us the delta cycle algorithm. When using Verilog, I
tried to do it as much as possible as VHDL. And whenever I hear
someone sing the praises of Verilog's ease of use, I invariably think:
you don't have enough experience.

For my outcry in despair at the time, see:

http://groups.google.com/group/comp.lang.verilog/browse_frm/thread/edc6d326a821c9a9/67ec9f89afe22b3b

Jan

Fri May 21, 2010 3:37 pm   

On May 21, 12:12 pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:


At least Evan Lavelle backed you up
--
Jonathan Bromley

Fri May 21, 2010 4:20 pm   

On May 21, 2:37 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

That's right. My thanks to him, even if they are little out-of-date

Fri May 21, 2010 9:40 pm   

On May 21, 2:44 am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

Yes, I should have known that you would be both pedantic and
dismissive.
What I said is not nonsense *if* you always use non-blocking
assignments in sequential blocks. Of course you know I believe that
is the right answer, so of course you show an opposite example.

<snipped lots more examples of blocking assignments>


Ahhh, so you *do* understand. But yes, a C semaphore or mutex or
monitor requires something *below* the level of the language, whereas
the Verilog language itself provides the needed primitives, and, let's
face it, "evaluate/update" is what has to happen with clocked
processes in all but the simplest cases.


Coding requires discipline. With verilog, there is no *extra*
discipline that would be required for the kind of IPC thing we were
discussing than there is for sequential coding in general.


You can easily be as undisciplined in C. The fact that C has no
concurrency, but C + package allows you concurrency doesn't mean that
C + package enforces anything on the user.

Regards,
Pat

Fri May 21, 2010 9:47 pm   

On May 21, 3:19 am, nemo <gnu...@gmail.com> wrote:


Obviously opinions vary, but if you always use non-blocking
assignments in sequential blocks, and always use blocking assignments
in combinatorial blocks, and adhere to a few other guidelines, it's
very easy to spot issues at a glance.

Regards,
Pat

Fri May 21, 2010 9:59 pm   

On May 21, 4:07 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:

So by "anywhere else" you mean in a sequential block. Yes, I don't do
that.


Well, I just avoid blocking assignments at all in sequential blocks.
As we have discussed previously, that can also be a viable strategy.


[ stuff snipped]


I see. I agree that (as you have also pointed out in other posts) the
foundations of Verilog were somewhat shaky (at least in the sense of
not being regular and extremely well thought out) and that some of the
subsequent fixes have created a non-orthogonal language.
"Coincidence" sounds like a lucky accident we got there at all, when
at the end of the day, it was through a lot of hard work, so "hack"
might be a better word :-)

[ stuff snipped ]


Yes, but I also see the cost. For example, in a large block with
intermingled blocking/non-blocking assignments, there might be a lot
of scrolling back and forth to determine if a variable is local or
not. For another example, if you need the local variable in another
block, now you have to go back and check all the uses of it and
possibly do some recoding.


Cummings certainly covers synthesis. What in his guidelines will
break for non-synthesis?


Well, I've shown you an example of how I would code something, so you
know my mileage varies on that.

Regards,
Pat

Sat May 22, 2010 8:24 pm   

[Jonathan Bromley]


What do you mean by that(implementing clock gating)?

I know,
always@(*) begin
a = b;
c = a;
end
these statements are executed sequentaly, a = b blocks the c = d;

But what about these?
always@(*) begin
a = b; //statement1
c = d; //statement2
end
Is there any order of those staments?

As for the nonblocking,
Is there any order between nonblocking assignments in the same
execution
path according to the verilog standart?

always@(posedge clk) begin
a <= b;
c <= d;
end

Ali

Sat May 22, 2010 10:06 pm   

On Sat, 22 May 2010 10:24:52 -0700 (PDT), Ali Karaali wrote:


If you're using an FPGA, please don't worry about it.

When designing ASICs for low power consumption, folk
often use clock gating to suppress the clock to some
part of the design when it's not active. This is
*not* usually a good idea in an FPGA design, but in
an ASIC it can be a useful technique. So let's
suppose that the designer has correctly crafted a
clock gating signal ClockIsActive, and has carefully
arranged its timing so that
MasterClock & ClockIsActive
will behave nicely, with no unpleasant glitches.
OK, so now we try...

always @(posedge MasterClock)
Qm <= something;

always @*
GatedClock <= MasterClock & ClockIsActive;

always @(posedge GatedClock)
Qg <= Qm;

The problem is that GatedClock is delayed by
one nonblocking assignment delay (a delta cycle)
in just the same way as Qm is delayed. So now
there is a simulation race condition between the
change of Qm and the (posedge GatedClock) that's
used to sample it.

However, if you change the clock gate logic to

always @*
GatedClock = MasterClock & ClockIsActive;

or, just as good,

assign GatedClock = MasterClock & ClockIsActive;

then the clock gate (and any other combinational logic)
updates earlier than the nonblocking assignments, and the
sampling of Qm in the GatedClock domain works correctly.

Of course, this is merely a trick to make zero-delay
simulation work correctly. In the finished device it's
very important to apply appropriate timing constraints
to ensure that the real logic also behaves in this way.



Yes, certainly. Sequential statements in a begin...end block
are definitely executed in order. The whole point about blocking
assignment is that the assignment has completed (has taken effect)
before the next statement is executed. Just like normal software.


Yes! The two assignments execute sequentially. Consequently the
order of activity is:

1) Evaluate "b"
2) Make a delayed assignment of that value to "a" - put the
assignment on the queue of future activity, but don't do it yet
3) Evaluete "d"
4) Make the delayed assignment to "c"
5) Do any other "always" blocks that were triggered by
(posedge clk), in the same way as I just described
6) When all such activity is finished, update the variables
that have scheduled delayed assignments, BUT DO IT IN THE
SAME ORDER IN WHICH THE CORRESPONDING ASSIGNMENTS WERE
EXECUTED (first-in first-out). Therefore, first update
"a" and then update "c".

Hope this helps you to see what's happening.
--
Jonathan Bromley