FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > Verilog

Verilog comp.lang.verilog newsgroup / usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 02-28-2006, 03:07 PM
Mahurshi Akilla
Guest
 
Posts: n/a
Default <= and =

i have read somewhere that whenever we're dealing with registers in
always @ blocks, we should ALWAYS use <= and that whenever we're using
pure combinatorial logic outside of always @ blocks, we should ALWAYS
use =

could anyone let me (a newbie) know if this is true?

Reply With Quote
  #2 (permalink)  
Old 02-28-2006, 04:19 PM
Ralf Hildebrandt
Guest
 
Posts: n/a
Default Re: <= and =

Mahurshi Akilla wrote:

> i have read somewhere that whenever we're dealing with registers in
> always @ blocks, we should ALWAYS use <= and that whenever we're using
> pure combinatorial logic outside of always @ blocks, we should ALWAYS
> use =
>
> could anyone let me (a newbie) know if this is true?


Have a look at Cliff Cummings: "Verilog Coding styles, that kill" (you
will find it as PDF in the web.)

Short:
1) Outside always-blocks (assign) use "=" (you don't have any option).
2) For combinational logic use "=".
3) For sequential logic use "<=".

Ralf
Reply With Quote
  #3 (permalink)  
Old 02-28-2006, 04:36 PM
Mahurshi Akilla
Guest
 
Posts: n/a
Default Re: <= and =

thanks.

this is probably a pretty dumb question. but i figured i should ask it
anyway. i promise the questions get smarter as i learn more and more
of this behavioral coding.

if i have a

FLIPLOP ---------- LOGIC ------------- FLIPFLOP

1. should the logic go under an always @(posedge clk) ? or should it
be done seperately?

2. if it goes under always @(posedge clk), i am assuming, we'll use "="
for that comb. logic, is that a safe assumption?

Reply With Quote
  #4 (permalink)  
Old 02-28-2006, 04:44 PM
Chris F Clark
Guest
 
Posts: n/a
Default Re: <= and =

> i have read somewhere that whenever we're dealing with registers in
> always @ blocks, we should ALWAYS use <= and that whenever we're using
> pure combinatorial logic outside of always @ blocks, we should ALWAYS
> use =


Your rules are not a bad approximation to the truth. You can also put
combinatorial logic inside an always block (and "need" to, to do
things like muxes and priority encoderr that require case statements).
When you put combinatorial logic in an always block, one uses a reg,
and one uses =, a blocking assignment, and if possible one should use
the Verilog 2001 "always @ *" as the wrapper for the block.

There are even more subtle cases to deal with, especially when
assigning multiple registers (especially when some of the registers
are both source and target) in the same always block, see below. In
those cases, you want to think carefully what you mean. You may after
careful deliberation, decide that some code fragments are not good
style and are more trouble than they are worth.

always @ (posedge clk)
begin
a <= b; // a gets the old value of b
b <= a; // b gets the old value of a
end

always @ (posedge clk)
begin
a <= a + 1;
if (b == 0) c <= a; // c gets the old value of a, not the new
end

always @ (posedge clk)
begin
a = a + 1; // note that I used a blocking assign here
if (b == 0) c <= a; // c gets the new value of a, not the old
end

There are people who have thought long about the various issues of <=
and =, Cliff Cummings is famous for it, and you would do well to read
their advice.

Hope this helps,
-Chris

************************************************** ***************************
Chris Clark Internet : [email protected]
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------
Reply With Quote
  #5 (permalink)  
Old 02-28-2006, 08:39 PM
Ralf Hildebrandt
Guest
 
Posts: n/a
Default Re: <= and =

Mahurshi Akilla wrote:

> if i have a
>
> FLIPLOP ---------- LOGIC ------------- FLIPFLOP
>
> 1. should the logic go under an always @(posedge clk) ? or should it
> be done seperately?


This depends on you. If one version seems to be more readable to you,
you got the decision.

I take the example from you other posting:

always @(posedge clk)
begin
sum <= a + b;
end

Here combinational logic plus the flipflops are modeled. You could also
write

always @(a or b)
begin
result = a + b;
end

always @(posedge clk)
begin
sum <= result;
end

but this would be less readable.


> 2. if it goes under always @(posedge clk), i am assuming, we'll use "="
> for that comb. logic, is that a safe assumption?


No. Everything inside a an edge-triggered always-statement should use
non-blocking signal assignments "<=".
Nevertheless - modeling pure combinational logic inside an
edge-triggered always statement is a little bit tricky. ;-) Usually one
models combinational logic _plus_ the final flipflop(s).


Ralf
Reply With Quote
  #6 (permalink)  
Old 03-01-2006, 09:26 AM
Guest
 
Posts: n/a
Default Re: <= and =

It is matter for simulation only. For synthesizer it is the same.

Reply With Quote
  #7 (permalink)  
Old 03-01-2006, 08:52 PM
Ralf Hildebrandt
Guest
 
Posts: n/a
Default Re: <= and =

Chris F Clark wrote:


> always @ (posedge clk)
> begin
> a = a + 1; // note that I used a blocking assign here
> if (b == 0) c <= a; // c gets the new value of a, not the old
> end


I agree with you and your examples are very nice, but there is one point
to mention - Cummings' guideline #5: "Don't mix blocking and
non-blocking signal assignments in one always statement."

Well - mixing both assignments for _one_ signal is forbidden. But if
there is more than one signal in an always statement?

I personally have to say, that I like the way of coding like shown in
your example. It is similar to VHDL: Everything, what is a VHDL
variable, gets blocking signal assignment "=", everything, what is a
VHDL signal gets non-blocking signal assignment "<=" with one exception:
After the "assign" command only blocking signal assignments are possible.
This simple rule reduces all the guidelines to this compact form and
makes translations between VHDL and Verilog much simpler.

But this is personal opinion and I am doubtful, if I did not miss an
important fact.
I know, that the rule of not mixing both assignments collides with my rules.
I know, that using non-blocking signal assignments in pure combinational
always statements make it necessary to have _all_ signals that are read
in the sensitivity list, which may lead to increased simulation time
because of triggering the always statement again. (Cummings' guideline #3)
But is there a trap, I miss?

Ralf
Reply With Quote
  #8 (permalink)  
Old 03-01-2006, 11:22 PM
Chris F Clark
Guest
 
Posts: n/a
Default Re: <= and =

Ralf Hildebrandt followed-up on my comments with:
> I agree with you and your examples are very nice, but there is one
> point to mention - Cummings' guideline #5: "Don't mix blocking and
> non-blocking signal assignments in one always statement."
>
> Well - mixing both assignments for _one_ signal is forbidden. But if
> there is more than one signal in an always statement?


I must admit that I haven't recently reviewed Cummings' rules. The
point of the Cummings' rules (like all good design rules) are to keep
one out of trouble. One of my mentors once said, never put something
in a coding standard unless you can identify the problem it solves.
Therefore, if you follow Cliff Cummings' rules, you can be reasonably
certain that when you violate a rule, there is some pitfall you must
steer around. That doesn't mean that there aren't other ways to avoid
those same pitfalls (i.e. different sets of rules that have the same
effect).

In fact, my examples were driven by what our in-house cycle-based
simulator allow our designers to do. They codify the rules that we
have laid down to keep our designers out of trouble. As a designer,
one can either just learn and follow the rules, or learn what the
rules are protecting you from and avoid the underlying problems. I
took the initial posters question as leaning that direction. I would
like to think that my examples provided a glimpse into one way of
thinking about the problem.

Hope this helps,
-Chris

************************************************** ***************************
Chris Clark Internet : [email protected]
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------



Reply With Quote
  #9 (permalink)  
Old 03-02-2006, 08:43 AM
Jan Decaluwe
Guest
 
Posts: n/a
Default Re: <= and =

Ralf Hildebrandt wrote:
> Mahurshi Akilla wrote:



>> 2. if it goes under always @(posedge clk), i am assuming, we'll use "="
>> for that comb. logic, is that a safe assumption?

>
>
> No. Everything inside a an edge-triggered always-statement should use
> non-blocking signal assignments "<=".


I wouldn't know why.

> Nevertheless - modeling pure combinational logic inside an
> edge-triggered always statement is a little bit tricky. ;-) Usually one
> models combinational logic _plus_ the final flipflop(s).


What the OP refers to is how that combinational logic can be
modeled, and whether it's OK to use '=' assigns to hold
intermediate results. And that is true.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Reply With Quote
  #10 (permalink)  
Old 03-02-2006, 08:43 AM
Jan Decaluwe
Guest
 
Posts: n/a
Default Re: <= and =

Ralf Hildebrandt wrote:
> Mahurshi Akilla wrote:



>> 2. if it goes under always @(posedge clk), i am assuming, we'll use "="
>> for that comb. logic, is that a safe assumption?

>
>
> No. Everything inside a an edge-triggered always-statement should use
> non-blocking signal assignments "<=".


I wouldn't know why.

> Nevertheless - modeling pure combinational logic inside an
> edge-triggered always statement is a little bit tricky. ;-) Usually one
> models combinational logic _plus_ the final flipflop(s).


What the OP refers to is how that combinational logic can be
modeled, and whether it's OK to use '=' assigns to hold
intermediate results. And that is true.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Reply With Quote
  #11 (permalink)  
Old 03-02-2006, 04:02 PM
Ralf Hildebrandt
Guest
 
Posts: n/a
Default Re: <= and =

Jan Decaluwe wrote:


>> No. Everything inside a an edge-triggered always-statement should use
>> non-blocking signal assignments "<=".

>
> I wouldn't know why.
>
>> Nevertheless - modeling pure combinational logic inside an
>> edge-triggered always statement is a little bit tricky. ;-) Usually
>> one models combinational logic _plus_ the final flipflop(s).

>
> What the OP refers to is how that combinational logic can be
> modeled, and whether it's OK to use '=' assigns to hold
> intermediate results. And that is true.


Accepted - my fault.
I don't know why I forgot intermediate values (variables). Sorry.

always @(negedge reset or posedge clock)
begin
if (reset == 1'b0) begin
flipflop = 0;
end else /*if posedge clock*/ begin
temp = some_signal; // blocking for the variable
flipflop <= temp; // non-blocking the result
end //if
end //always

Nevertheless, this coding style (which is like) violates the rule of not
mixing the signal assignments in one always statement. Some company
design rules are very strict to not violate this rule.


Ralf
Reply With Quote
  #12 (permalink)  
Old 03-02-2006, 09:02 PM
Ralf Hildebrandt
Guest
 
Posts: n/a
Default Re: <= and =

Jan Decaluwe wrote:


> Let's try it for rule #5. Can you identify the problem it solves?
> Probably not, because you violate it in your own examples.
> I can't either. (I can merely identify the problems it *causes*.)
>
> Of course, Mr. Cummings himself should provide the answer. Here
> is the quote from the original paper, talking about mixing
> blocking and nonblocking assignments:
>
> "Although this will work, the author discourages this coding style".
>
> That's it. No arguments, technical or other, nothing. It works,
> but I don't like it and so you shouldn't do it.
>
> Sorry, but I cannot take this seriously.


Nice interpretation. I would follow it.

I guess this guideline #5 is given to avoid blocking and non-blocking
signal assignments to _one_ signal inside one always statement. (This
simulates, but synthesis tools refuse to synthesize this.)

Ralf
Reply With Quote
  #13 (permalink)  
Old 03-02-2006, 09:33 PM
Jan Decaluwe
Guest
 
Posts: n/a
Default Re: <= and =

Chris F Clark wrote:
> Ralf Hildebrandt followed-up on my comments with:
>
>>I agree with you and your examples are very nice, but there is one
>>point to mention - Cummings' guideline #5: "Don't mix blocking and
>>non-blocking signal assignments in one always statement."


> I must admit that I haven't recently reviewed Cummings' rules.


Always be careful when making recommendations - you may have to
follow them yourself :-)

You examples demonstrate the synchronous always block (or process)
style. This means that by default you map all hardware behavior
in an edge-triggered always block. You use both blocking
and non-blocking assignments, to get the behavior you want.

It's a great coding style. In many cases, it provides elegant coding
solutions that would be much harder (if not impossible) in a different
(lower level) coding style. And it synthesizes perfectly.

All fine - except that, if you believe Cummings' rule #5, you
can't do it. Which is why I recommend to ignore that rule.

> One of my mentors once said, never put something
> in a coding standard unless you can identify the problem it solves.


Good principle.

> Therefore, if you follow Cliff Cummings' rules, you can be reasonably
> certain that when you violate a rule, there is some pitfall you must
> steer around.


Wait a moment, are you sure those rules adhere to the principle above?

Let's try it for rule #5. Can you identify the problem it solves?
Probably not, because you violate it in your own examples.
I can't either. (I can merely identify the problems it *causes*.)

Of course, Mr. Cummings himself should provide the answer. Here
is the quote from the original paper, talking about mixing
blocking and nonblocking assignments:

"Although this will work, the author discourages this coding style".

That's it. No arguments, technical or other, nothing. It works,
but I don't like it and so you shouldn't do it.

Sorry, but I cannot take this seriously.

Regards,

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Reply With Quote
  #14 (permalink)  
Old 03-02-2006, 11:27 PM
Chris F Clark
Guest
 
Posts: n/a
Default Re: <= and =

Jan Decaluwe contributed the following to the discussion:

J> You examples demonstrate the synchronous always block (or process)
J> style. This means that by default you map all hardware behavior
J> in an edge-triggered always block. You use both blocking
J> and non-blocking assignments, to get the behavior you want.
....
J> All fine - except that, if you believe Cummings' rule #5, you
J> can't do it. Which is why I recommend to ignore that rule.

and I had written:
C> Therefore, if you follow Cliff Cummings' rules, you can be reasonably
C> certain that when you violate a rule, there is some pitfall you must
C> steer around.

Jan again:
J> Wait a moment, are you sure those rules adhere to the principle above?

J> Let's try it for rule #5. Can you identify the problem it solves?
J> Probably not, because you violate it in your own examples.
J> I can't either. (I can merely identify the problems it *causes*.)

While I'd hate to put words in Cliff Cummings' mouth, I believe that he
is trying to avoid a problem that we solve another way.

The issue is that if one has a blocking assignment to a signal in an
edge triggered block and a use of that signal in another edge
triggered block, then the ordering of the two blocks can cause a race
condition which may or may not simulate and/or synthesize to what you
want. In fact, in the worse case, it simulates to what you want (due
to artifacts of the particular simulator you are using, but
synthesizes to something that doesn't work).

If you don't put blocking assignments in edge triggered blocks, you
will never have that problem. If you follow Cummings' rule 5 (in
conjunction with his other rules), you won't ever put a blocking
assignement in an edge triggered block, because you won't use an edge
triggered block for combinatorial or latch logic, and if you have a
non-blocking assignment representing a flop in your edge triggered
block, you won't put any combinatorial gates using blocking
assignments in that block. Thus, everything driven out of an edge
triggered block, will be a flop, and will be assigned by a
non-blocking assignment which will prevent the race described above.

Now, as I said, where I work, we solve this a different way. Our rule
is, you cannot use the result of a blocking assignment in an edge
triggered always block outside of that always block. Somewhere, I
even recall someone posting the suggestion that one should use named
begin blocks and local variables to enforce that rule. Not a bad
idea.

We enforce this by tools in our design and validation flow, so that we
are certain designers don't violate the rules. However, if one didn't
have tools to enforce it, one might be tempted to put something
simpler in place. Cliff Cummings' rules are "simpler" in that way.
You simply cannot write dangerous code where a signal assigned by a
blocking assignment in one edge triggered block is used in another,
because you cannot assign to a signal with a blocking assignment in an
edge triggered block.

Note that we considered making the same prohibition. We just decided
that we could safely loosen that rule, if we could check assignments
against uses. And, since we have to deal with imported IP written
outside our group and not adhering to our rules, it is best if we can
make the rules as non-stringent as possible, so that we have less
issues with in the imported IP.

If I were in Cliff Cummings' shoes and potentially teaching very
junior engineers, I might stick to his rule 5 as it is simpler to
remember. In fact, I would probably stick to blocking assignments
only in always @* blocks and non-blocking assignments only in edge
triggered always blocks. The only problem is then the junior coders
might see a design with more liberal rules and start doing that
without knowing when it is safe.

In the end, the good engineer tries to learn why the rules are in
place, and what they are trying to prevent. Then, you will know when
you can bend the rules, and when you shouldn't.

Hope this helps,
-Chris

************************************************** ***************************
Chris Clark Internet : [email protected]
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

Reply With Quote
  #15 (permalink)  
Old 03-05-2006, 08:43 AM
Mike Treseler
Guest
 
Posts: n/a
Default Re: <= and =

Chris F Clark wrote:

> Now, as I said, where I work, we solve this a different way. Our rule
> is, you cannot use the result of a blocking assignment in an edge
> triggered always block outside of that always block. Somewhere, I
> even recall someone posting the suggestion that one should use named
> begin blocks and local variables to enforce that rule. Not a bad
> idea.


Thanks. Note that one way I can meet your rule
is to use only one block per module with as
many regs as I need.

-- Mike Treseler
Reply With Quote
  #16 (permalink)  
Old 03-05-2006, 10:12 PM
Chris F Clark
Guest
 
Posts: n/a
Default Re: <= and =

I wrote:

C> Now, as I said, where I work, we solve this a different way. Our rule
C> is, you cannot use the result of a blocking assignment in an edge
C> triggered always block outside of that always block. Somewhere, I
C> even recall someone posting the suggestion that one should use named
C> begin blocks and local variables to enforce that rule. Not a bad
C> idea.

Mike Treseler added:

M> Thanks. Note that one way I can meet your rule
M> is to use only one block per module with as
M> many regs as I need.

Other than the modularity issue (i.e. does your one always block get
too large to read and comprehend), I'm not sure that one always block
per module is a bad idea, expecially if it is sensitive only to one
clock (and maybe a reset and enable), as in:

always @(posedge clock or negedge reset or posedge enable)
begin
if (reset == 0)
begin
// lots of code explaining what to do on reset
end
else if (enable == 1) and (clock == 1)
begin
// lots of code explaining what to do in the enabled clock case
end
end

That looks a whole lot like you can just read the code and tell what
the state to next-state transitions are on each clock cycle. Again,
that might not be modular enough, as the code to transition from one
state to the next can be complex and you might want to break it down
into parts. However, the basic idea behind wriiting coode like that
seems reasonable.

BTW, I should put out that the rule that the target of a blocking
assignment cannot be used outside an always block is not our only
coding rule. We also prohibit the loop-around case, where you assign
the to variable with a blocking assignment in one pass through the
always block and then later reenter the always block and use the value
that was assigned on the previous pass. That is we make the following
code illegal:

always @(posedge clock)
begin
t = a + 1; // use of a
// more code
a = b; // non-blocking assignment that can "reach" the above use
// the next time this block is executed
end

There is no inherent problem with the above code and it will both
synthesize and simulate correctly. However, a is now a register,
latch, or flop of some type. We don't want our coders "accidently"
coding state devices that way, so we prohibit it. We "require" that
state devices (memories) be coded by non-blocking assignments and
combinatorial devices be coded by blocking assigns. The flaw we are
trying to avoid there is the creation of memories in the chip that the
designer hasn't anticipated. The designer is supposed to understand
the design and know where memories are located. Any place where a
memory is put that the designer hasn't planned represents a lack of
understanding on the designers part.

Hope this helps,
-Chris

************************************************** ***************************
Chris Clark Internet : [email protected]
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

Reply With Quote
  #17 (permalink)  
Old 03-06-2006, 01:29 AM
Allan Herriman
Guest
 
Posts: n/a
Default Re: <= and =

On 05 Mar 2006 17:12:39 -0500, Chris F Clark
<[email protected]> wrote:

>I wrote:
>
>C> Now, as I said, where I work, we solve this a different way. Our rule
>C> is, you cannot use the result of a blocking assignment in an edge
>C> triggered always block outside of that always block. Somewhere, I
>C> even recall someone posting the suggestion that one should use named
>C> begin blocks and local variables to enforce that rule. Not a bad
>C> idea.
>
>Mike Treseler added:
>
>M> Thanks. Note that one way I can meet your rule
>M> is to use only one block per module with as
>M> many regs as I need.
>
>Other than the modularity issue (i.e. does your one always block get
>too large to read and comprehend), I'm not sure that one always block
>per module is a bad idea, expecially if it is sensitive only to one
>clock (and maybe a reset and enable), as in:
>
>always @(posedge clock or negedge reset or posedge enable)
> begin
> if (reset == 0)
> begin
> // lots of code explaining what to do on reset
> end
> else if (enable == 1) and (clock == 1)
> begin
> // lots of code explaining what to do in the enabled clock case
> end
> end


Are you sure that's what you mean? You have described a system with a
gated clock, rather than a clock enable.

Changing this line:

>always @(posedge clock or negedge reset or posedge enable)


to this:

>always @(posedge clock or negedge reset)


will give you a true clock enable. This will match the hardware
available in (e.g.) FPGAs.


Another point: many coding standards require that active low signals
be identified as such. You use an active low reset called 'reset'
rather than resetb, resetn, or whatever.

Regards,
Allan
Reply With Quote
  #18 (permalink)  
Old 03-06-2006, 09:04 PM
Jan Decaluwe
Guest
 
Posts: n/a
Default Re: <= and =

Ralf Hildebrandt wrote:
> Jan Decaluwe wrote:
>
>
>> Let's try it for rule #5. Can you identify the problem it solves?
>> Probably not, because you violate it in your own examples.
>> I can't either. (I can merely identify the problems it *causes*.)
>>
>> Of course, Mr. Cummings himself should provide the answer. Here
>> is the quote from the original paper, talking about mixing
>> blocking and nonblocking assignments:
>>
>> "Although this will work, the author discourages this coding style".
>>
>> That's it. No arguments, technical or other, nothing. It works,
>> but I don't like it and so you shouldn't do it.
>>
>> Sorry, but I cannot take this seriously.

>
>
> Nice interpretation. I would follow it.
>
> I guess this guideline #5 is given to avoid blocking and non-blocking
> signal assignments to _one_ signal inside one always statement. (This
> simulates, but synthesis tools refuse to synthesize this.)


No, that is not correct. The guideline very clearly targets all
cases, in particular the one in which the blocking and non-blocking
assignments are made to different regs. Actually, the phrase "although
this will work" clearly targets this case, and acknowledges
that it will work for both simulation and synthesis. See the paper.

The other case - using a blocking and a non-blocking assignment
on the same reg - deserves more consideration. It is also
mentioned in the paper, showing that leading synthesis tools will
treat this as an error. I believe that is the proper thing to do.
In fact, I believe Verilog itself should not allow this.
[Possible exception: initialization syntax at declaration time]

To put it more strongly, I consider the fact that Verilog doesn't
distinguish between 'variables' and 'signals' as a language
flaw. If it would, the latter case would no longer exist
and the useful, former case would confuse nobody (well, you
never know.) Anyway, one should never have to give up on a
superior design style because of a language flaw.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Reply With Quote
  #19 (permalink)  
Old 03-06-2006, 11:17 PM
Jan Decaluwe
Guest
 
Posts: n/a
Default Re: <= and =

Chris F Clark wrote:

> While I'd hate to put words in Cliff Cummings' mouth, I believe that he
> is trying to avoid a problem that we solve another way.
>
> The issue is that if one has a blocking assignment to a signal in an
> edge triggered block and a use of that signal in another edge
> triggered block, then the ordering of the two blocks can cause a race
> condition which may or may not simulate and/or synthesize to what you
> want.


[No need to put words in his mouth - he attempted to rationalize the
guideline himself in a later paper. His arguments are different, and
yours is better, by the way. But I must conclude that few people
actually read his papers (granted, they are boring at times), or are
interested in his arguments and lack thereof. Which doesn't prevent
us from referring to what he calls "guidelines" (to his credit)
as "rules", and treating him as if he were Mozes or Mohamed.]

That is a real issue - in Verilog. To solve it you could either
use a different language (best solution), use linting tools (second
best), or design discipline, such as using only local variables
(as you refer to.) But applying guideline 5 to solve this is really
a cure that's worse than the disease, as it would ban an essential
design paradigm.

> If I were in Cliff Cummings' shoes and potentially teaching very
> junior engineers, I might stick to his rule 5 as it is simpler to
> remember.


I would try to teach good design principles right from the start,
so I would introduce the synchronous always block paradigm right away.
You seem to suggest that this would be "too difficult" for
junior engineers. But it isn't: it just approaches the hardware
design problem from a different angle, that is, the one of using
a language and synthesis. (Note that guideline 5 essentially
bans the use of variables - rather strange when you are familiar
with other programming languages). Better yet, it even has
advantages in terms of simulation speed (less events) and
synthesis (no problems with incomplete sensitivity lists
and unwanted latches).

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 12:06 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved