I'd rather switch than fight!

[Patrick Maupin]

On Apr 22, 4:21 pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:

Let me put it more correctly. Initially, I think, everyone is confused
about this. I know I was (20 years ago already!). The confusion
is resolved by a new insight: how RTL synthesis *really* works.

I got it. In fact, I used to do what you said, but sometimes I would
be confused, or others would be. Haven't done that in 15 years.

Some get it quickly, others need more time.
I think that's a common pattern with new paradigms.

That's an old paradigm.

The benefit: a coding technique to solve real problems
significantly more elegantly.

But, in my previous experience, it doesn't. It just confuses people.

I suggest you try your coding style with my examples. You have the
spec and test vectors. If you find your code much clearer, I don't
have
a case (with you) to argue further. Otherwise, you'll remember me
when you start applying this technique in your designs

Been there, done that, got the t-shirt; somebody else showed me the
light over a decade ago, and I never went back.

Regards,
Pat

 

[Andy]

Other than twice the declarations, unintentional latches, explicitly
coding clock enables, simulation penalties, etc., using separate
combinatorial and sequential blocks is just fine.

Most designers here use single clocked processes / always blocks.
Those that don't are 'encouraged' to.

Andy

 

[Patrick Maupin]

On Apr 22, 5:32 pm, Andy <jonesa...@comcast.net> wrote:

Other than twice the declarations, unintentional latches, explicitly
coding clock enables, simulation penalties, etc., using separate
combinatorial and sequential blocks is just fine.

Unintentional latches don't happen if you use a consistent naming
style with, e.g. 'next_x' and 'x'.

I don't think simulation penalties happen if the simulator is halfway
decent.

Twice the declarations is a slight issue, but if you do reg [2:0] x,
next_x; it's not too bad at all.

Explicitly coding clock enables -- not sure what you mean here --
that's an if statement no matter how you slice it.

Regards,
Pat

 

[KJ]

On Apr 22, 6:36 pm, Patrick Maupin <pmau...@gmail.com> wrote:

On Apr 22, 5:32 pm, Andy <jonesa...@comcast.net> wrote:

Other than twice the declarations, unintentional latches, explicitly
coding clock enables, simulation penalties, etc., using separate
combinatorial and sequential blocks is just fine.

Unintentional latches don't happen if you use a consistent naming
style with, e.g. 'next_x' and 'x'.

Ha, ha, ha...having a convention naming style prevents latches???!!!

Ummmmmm, noooooooo, don't think so, but thanks for the possibly
unintended humor.

Whether you have a naming convention or not, latches will be created
when assignment statements to cover every path are not included in an
unclocked process totally independent of how they are named...end of
story

I suppose your point is that calling things 'next_x' and 'x' then
makes it easier to do a *manual* inspection and perhaps catch such a
missing assignment but that is a far, far stretch from your actual
statement "Unintentional latches don't happen if...". Andy, on the
other hand, is on much firmer ground had he said "Unintentional
latches don't happen if you only use clocked processes"...he didn't
explicitly say that, but I'm fairly certain he would agree.

Yes, you can do things to make *manual* inspections better...which is
like saying it hurts my head less if I use a rubber hammer to hit my
head than a steel one...but it is a far better process improvement to
just not hit my head at all with any hammer.

KJ

 

[Patrick Maupin]

On Apr 22, 8:57 pm, KJ <kkjenni...@sbcglobal.net> wrote:

I suppose your point is that calling things 'next_x' and 'x' then
makes it easier to do a *manual* inspection and perhaps catch such a
missing assignment but that is a far, far stretch from your actual
statement "Unintentional latches don't happen if...".  Andy, on the
other hand, is on much firmer ground had he said "Unintentional
latches don't happen if you only use clocked processes"...he didn't
explicitly say that, but I'm fairly certain he would agree.

Yes, I should have been more clear about that. Any decent synthesizer
or simulation tool will report latches, but sometimes the reports are
hard to interpret. If you use a consistent naming convention like I
have described, it is easy to find the latches, and also easy to write
a script to find them, as well.

And I agree that you won't have latches if all your processes are
clocked, but latches are much easier to detect and rectify than some
other possible logic problems.

Regards,
Pat

 

[KJ]

On Apr 22, 10:12 pm, Patrick Maupin <pmau...@gmail.com> wrote:

On Apr 22, 8:57 pm, KJ <kkjenni...@sbcglobal.net> wrote:


Yes, I should have been more clear about that.

Agreed, you're not very clear when you have statements like this from
your previous post...

Unintentional latches don't happen if you use a consistent naming
style with, e.g. 'next_x' and 'x'.

followed up with statements like this...

If you use a consistent naming convention like I
have described, it is easy to find the latches,

So, first you say that the naming convention by itself will prevent
unintentional latches and then follow that up to say that the naming
convention helps you to *find* the unintended latches that couldn't be
created in the first place...hmmm....yes, I agree, not very clear.

Both statements indicating that you may be oblivous to the simple
point that using non-clocked processes opens you up to making it easy
to create your own problems (i.e. the latches) that are easily avoided
in the first place...

And I agree that you won't have latches if all your processes are
clocked,

Oop, I guess not because now it seems that you do get the point that
clocked processes for the most part avoid the unintended latch...but
based on the earlier comments I guess you must not practice it or
something for some reason...You admit it avoids a potential design
problem, but don't use it because....hmmmm....well, perhaps you have a
sponge hammer...

Ah well...as long as there are textbooks I guess there will always be
those disciples that think that separating combinatorial logic from
the register description actually is of some value to somebody,
somewhere at some point in time...but inevitably they come up short
when trying to demonstrate that value.

easy to find the latches, and also easy to write
a script to find them, as well

Then they will trot out the methods they use to minimize the problem
that others do not even have.

While those disciples are steadfast in their belief, it usually
doesn't get across to them that the value they perceive is actually
negative, it is costing them...and they are left clinging to the only
thing they have left which is always a statement of the form "That's
the way I do it, I'm comfortable with it, I feel I'm productive doing
it this way"

Every now and then, it seems like good sport to challenge those folks
to see if they have anything better to offer, but it never seems to
be.

but latches are much easier to detect and rectify than some
other possible logic problems.

And much easier to avoid in the first place too...with the correct

methodology (hint: that would be the one that avoids using unclocked
processes)

Just having fun...like I said, every now and then it's good sport to
poke fun at the people who make their own problems.

Kevin Jennings

 

[Patrick Maupin]

On Apr 22, 11:38 pm, KJ <kkjenni...@sbcglobal.net> wrote:

but latches are much easier to detect and rectify than some
other possible logic problems.

And much easier to avoid in the first place too...with the correct
methodology (hint:  that would be the one that avoids using unclocked
processes)

Just having fun...like I said, every now and then it's good sport to
poke fun at the people who make their own problems.

But, the reason I was unclear to start with, is that it's been so long
since I've had an unintended latch (probably several years) that I
really don't think that hard about it at all. So you can think what
you want, but the *reason* I code the way I do isn't really that much
about latches at all (obviously, if I was *worried* about them, I
would code everything in sequential blocks, where they could never
happen, but I could have some other hard to find logic problems, which
I *have* had in the past). However, unintended latches just don't
happen for me with my coding style, so I don't worry about it until
somebody like you comes along to tell me about all the problems that
I'm causing for myself that I never knew I had!

Regards,
Pat

 

[Bernd Paysan]

Andy wrote:

Other than twice the declarations, unintentional latches, explicitly
coding clock enables, simulation penalties, etc., using separate
combinatorial and sequential blocks is just fine.

LoL. Note that there are further difficulties to understand this separated
code due to the fact that things which conceptually belong together are
spread apart over the file. This is just too messy.

Most designers here use single clocked processes / always blocks.
Those that don't are 'encouraged' to.

I'm fully on your side.

--
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

 

[Chris Higgs]

On Apr 23, 5:38 am, KJ <kkjenni...@sbcglobal.net> wrote:

Ah well...as long as there are textbooks I guess there will always be
those disciples that think that separating combinatorial logic from
the register description actually is of some value to somebody,
somewhere at some point in time...but inevitably they come up short
when trying to demonstrate that value.

http://www.gaisler.com/doc/structdes.pdf

I'd recommend casting your eye over this presentation. It details some
of the advantages of the "2 process" coding style with a real world
example (LEON SPARC-V8 processor).

Thanks,

Chris

 

[Marcus Harnisch]

Chris Higgs <chiggs.99@googlemail.com> writes:

I'd recommend casting your eye over this presentation. It details some
of the advantages of the "2 process" coding style with a real world
example (LEON SPARC-V8 processor).

Actually the rpesentation seems to compare two entirely different
designs done using different approaches. In this comparison, the
Two-Process-style appears to only *one* of the aspects.

--
Marcus

note that "property" can also be used as syntactic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)

 

[Brian Drummond]

On Fri, 23 Apr 2010 01:03:03 -0700 (PDT), Chris Higgs
<chiggs.99@googlemail.com> wrote:

On Apr 23, 5:38 am, KJ <kkjenni...@sbcglobal.net> wrote:

Ah well...as long as there are textbooks I guess there will always be
those disciples that think that separating combinatorial logic from
the register description actually is of some value to somebody,
somewhere at some point in time...but inevitably they come up short
when trying to demonstrate that value.

http://www.gaisler.com/doc/structdes.pdf

I'd recommend casting your eye over this presentation. It details some
of the advantages of the "2 process" coding style with a real world
example (LEON SPARC-V8 processor).

Not over the single-process style, which it doesn't even mention.
Other aspects of this document are worthwhile, however.

- Brian

 

[KJ]

On Apr 23, 1:01 am, Patrick Maupin <pmau...@gmail.com> wrote:

On Apr 22, 11:38 pm, KJ <kkjenni...@sbcglobal.net> wrote:

but latches are much easier to detect and rectify than some
other possible logic problems.

And much easier to avoid in the first place too...with the correct
methodology (hint:  that would be the one that avoids using unclocked
processes)

Just having fun...like I said, every now and then it's good sport to
poke fun at the people who make their own problems.

But, the reason I was unclear to start with, is that it's been so long
since I've had an unintended latch (probably several years) that I
really don't think that hard about it at all.

The two process people generally do fall back on excuses about being
misunderstood.

 So you can think what
you want, but the *reason* I code the way I do isn't really that much
about latches at all (obviously, if I was *worried* about them, I
would code everything in sequential blocks, where they could never
happen,

Hmmm...so you prefer to take what you admit as unnecessary
chances....fair enough, that implies though that you expect some
actual benefit from that decision...but are probably unable to come up
with an actual example demonstrating that benefit.

but I could have some other hard to find logic problems, which
I *have* had in the past).  

Ahhh....one of those examples...now what sort of 'hard to find' logic
problem would you like to offer up to to the group to actually
demonstrate that two processes are better than one? I'm willing to
listen, but I'll warn that you that every time in the past that this
debate pops up, the two process people are unable to coherently
describe anything other than vague generalities as you've done
here...so here is your opportunity to present a clear example
describing a 'hard to find' logic problem that is easier to find when
coded with two processes. The clocked process folks (i.e. the one
process camp) have in the past presented actual examples to back their
claims, Googling for 'two process' in the groups should provide some
good cases.

However, unintended latches just don't
happen for me with my coding style, so I don't worry about it until
somebody like you comes along to tell me about all the problems that
I'm causing for myself that I never knew I had!

Whether you in particular have this problem, I don't know (apparently
not). You in particular though are
- Doing more work (two process will always be more typing and lines of
code then one process),
- Producing less maintainable code (two process will always physically
separate related things based only on whether the logic signal is a
'register' or not)

Kevin Jennings

 

[KJ]

On Apr 23, 4:03 am, Chris Higgs <chiggs...@googlemail.com> wrote:

On Apr 23, 5:38 am, KJ <kkjenni...@sbcglobal.net> wrote:

Ah well...as long as there are textbooks I guess there will always be
those disciples that think that separating combinatorial logic from
the register description actually is of some value to somebody,
somewhere at some point in time...but inevitably they come up short
when trying to demonstrate that value.

http://www.gaisler.com/doc/structdes.pdf

I'd recommend casting your eye over this presentation. It details some
of the advantages of the "2 process" coding style with a real world
example (LEON SPARC-V8 processor).

OK, but it doesn't compare it to the 'one process' approach, the
comparison is to a 'traditional method'. The 'traditional method'
though is all about lumping all signals into records (refer to the
'Benefits' area of that document). All of the comparisons are between
'traditional method' which has discrete signals and 'two-process
method' which lumps signals into a record.

There is absolutely nothing comparing 'one process' and 'two
process'. Why the author chose to title his new method the 'two-
process' method is totally unclear...just another example either of
sloppy academic thinking to name your method after something that is
not even relevant to the point of the paper.

The author does mention "No distinction between sequential and comb.
signals" as being a "Problem". Maybe it's a problem for the author,
but it's somewhat irrelevant for anyone skilled in design. The author
presents no reason for why having immediate knowledge of whether a
signal comes out of a flip flop or a gate is relevant...(hint: it's
not). What is relevant is the logic that the signal represents and
whether it is implemented properly or not. Whether 'proper
implementation' means the signal is a flop or not is of very little
concern (one exception being when you're generating gated
clocks...which is a different can of worms).

Even the author's 'State machine' example demonstrates the flaw of
using two processes. Referring to slide #27 partially shown below,
note that (the undeclared) variable v has no default assignment, v
will result in a latch.

begin
comb : process(...., r)
begin
case r.state is
when first =>
if cond0 then v.state := second; end if;
when second =>
....

This to me demonstrates that the author didn't even take the time to
compile his own code...and not notice the (possibly) unintended latch
that gets generated. Maybe the author is living in an ASIC world
where latches are not a problem, who knows? But in an FPGA, a latch
most certainly is indicative of a design problem more times than not.

You seem to have been caught up by his statement "A synchronous design
can be abstracted into two separate parts; a combinational and a
sequential" and the slide titled "Abstraction of digital logic" and
thought that this was somehow relevant to the point of his
paper...it's not...his point is all about combining signals into
records...totally different discussion.

The only conclusion to draw from this paper is that you shouldn't
believe everything you read...and you shouldn't accept statements that
do not stand up to scrutiny.

Kevin Jennings

 

[Muzaffer Kal]

On Fri, 23 Apr 2010 08:32:48 -0700 (PDT), Jan Decaluwe
<jan@jandecaluwe.com> wrote:

So this is now already the third post that I devote to explaining
to two seasoned Verilog designers how a very simple example in
their favourite language with the ultra-short learning curve
actually works. I'm beginning to think that Verilog designers
don't know how to use variables

Actually it was mostly a matter of not paying close attention to
something one "knows" would not work. Of course in a clocked process
if a register is not assigned in a path it remembers its value so a
register is inferred and if it's a blocking assignment, its value is
available in the same clock cycle. When one finally puts these
together, your example is "obvious".
And you're right; personally I don't use variables in this fashion. I
would write the same logic as follows:

if (turnleft) was_turnleft <= 1;
if (turnleft || was_turnleft) do_left turn;

which I think how the synthesizer would generate the logic for your
example.

--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

 

[Chris Higgs]

On Apr 23, 3:02 pm, KJ <kkjenni...@sbcglobal.net> wrote:

OK, but it doesn't compare it to the 'one process' approach, the
comparison is to a 'traditional method'.  The 'traditional method'
though is all about lumping all signals into records (refer to the
'Benefits' area of that document).  All of the comparisons are between
'traditional method' which has discrete signals and 'two-process
method' which lumps signals into a record.

I think one of the points (implicitly) made by the paper is an
admission that the two-process method is a mess unless you use
records. I think it's also implied that 'traditional method' people
are more prone to using discrete signals rather than record types.

The author does mention "No distinction between sequential and comb.
signals" as being a "Problem".  Maybe it's a problem for the author,
but it's somewhat irrelevant for anyone skilled in design.  The author
presents no reason for why having immediate knowledge of whether a
signal comes out of a flip flop or a gate is relevant...(hint:  it's
not).  What is relevant is the logic that the signal represents and
whether it is implemented properly or not.  Whether 'proper
implementation' means the signal is a flop or not is of very little
concern (one exception being when you're generating gated
clocks...which is a different can of worms).

Sometimes it's necessary to use the combinatorial signal.

Even the author's 'State machine' example demonstrates the flaw of
using two processes.  Referring to slide #27 partially shown below,
note that (the undeclared) variable v has no default assignment, v
will result in a latch.

Yes, that's just sloppy.

You seem to have been caught up by his statement "A synchronous design
can be abstracted into two separate parts; a combinational and a
sequential" and the slide titled "Abstraction of digital logic" and
thought that this was somehow relevant to the point of his
paper...it's not...his point is all about combining signals into
records...totally different discussion.

Well combining state into records makes a "two-process" technique neat
enough to be feasible. Personally I use a similar style and I find it
very clear and understandable. As an example:

entity myentity is
generic (
register_output : boolean := true
);
port (
clk : in std_ulogic;
srst : in std_ulogic;

-- Input
data : in some_type_t;

-- Output
result : out another_type_t
);
end;

architecture rtl of myentity is

type state_enum_t is (IDLE, OTHER_STATES);

type state_t is record
state : state_enum_t;
result : another_type_t;
end record;

constant idle_state : state_t := (state => IDLE,
result => invalid_result);

signal r, rin : state_t;

begin

combinatorial: process(r, srst, data)
variable v : state_t;
begin

--DEFAULTS
v := r;
v.result := invalid_result;

-- STATE MACHINE
case v.state is
when IDLE =>
null;
when OTHER_STATES =>
null;
end case;

-- RESET
if srst = '1' then
v := idle_state;
end if;

--OUTPUTS
if register_output then
result <= r.result;
else
result <= v.result;
end if;

rin <= v;
end process;

sequential : process(clk)
begin
if rising_edge(clk) then
r <= rin;
end if;
end process;

end;

The only conclusion to draw from this paper is that you shouldn't
believe everything you read...and you shouldn't accept statements that
do not stand up to scrutiny.

You can only use sequential processes and make it impossible to infer
a latch but lose the ability to use a combinatorially derived signal.
Alternatively you can use a two-process technique which allows
intermediate/derived signals to be used but accept the risk that bad
code will introduce latches. We can ague forever about which method is
more 'correct' but it's unlikely to boil down to anything other than
personal preference.

Thanks,

Chris

 

[Jan Decaluwe]

On Apr 22, 10:04 pm, Muzaffer Kal <k...@dspia.com> wrote:

On Thu, 22 Apr 2010 08:08:59 -0700 (PDT), Jan Decaluwe

Quoting from the article:
"""
This example is more subtle and complex than it may seem at first
sight. As said before, variables dir and run are state variables and
will therefore require a flip-flop in an implementation. However, they
are also used “combinatorially”: when they change, they may influence
the counter operation “in the same clock cycle”, that is, before the
flip-flop output changes. This is perfectly fine behavior and no
problem for synthesis tools, but it tends to confuse a lot of
designers.
"""

I am not sure who is really confused here.

You are: both about Verilog (suprizing) and about RTL synthesis
(anticipated).

What is suggested in the
above paragraph is not really feasible; assuming by 'dir' one refers
to the output of a flop.

The problem with the last verilog block shown is the dir and run are
not flops anymore but combinational signals decoded from goleft and
goright so the last direction will not be remembered. If last
direction needs to be remembered, one needs to decode the
'instruction', use  the decoded value and remember the decoded value
as above.

So this is now already the third post that I devote to explaining
to two seasoned Verilog designers how a very simple example in
their favourite language with the ultra-short learning curve
actually works. I'm beginning to think that Verilog designers
don't know how to use variables

'dir' and 'run' keep their value over always block invocations, OK?
Depending on the conditions, they may or may not get a new
value. Basic Verilog stuff.

Then the implementation. Clearly there is both a sequential and
a combinatorial path from these variables. If you think this is
not feasible, don't argue with me, but just synthesize it and
simulate the result to verify.

FInally, RTL synthesis. No, 'dir' is not a flop and no, it isn't
combo logic either. It gives rise to both. Technically, the
same variable 'dir' creates multiple nodes in a multi-level
logic network that represents the code. Voilŕ.

Jan

 

[Andy]

Coding clock enables in a combinatorial process requires an additional
assignment for the clock-disable case (otherwise you get a latch,
regardless of your naming convention). Only one assignment is required
(the enabled assignment) in a clocked process, and it is the
assignment you had to make anyway.

KJ has already well stated the problems with latches (requiring
additional assignments) in combinatorial processes/blocks, regardless
of the naming convention employed.

Any decent simulator (maybe not a half-decent one) will merge
processes or always blocks that share the same sensitivity list. Since
they are usually identical for all synchronous processes clocked by
the same clock, they get merged, thus improving performance by
avoiding duplicative process-related overhead. Since combinatorial
processes rarely share the same sensitivity list, they don't get
merged, and performance suffers.

Andy

 

[Patrick Maupin]

On Apr 23, 10:34 am, Andy <jonesa...@comcast.net> wrote:

Coding clock enables in a combinatorial process requires an additional
assignment for the clock-disable case (otherwise you get a latch,
regardless of your naming convention). Only one assignment is required
(the enabled assignment) in a clocked process, and it is the
assignment you had to make anyway.

Oh, I see the point you're trying to make. Two points I tried (and
obviously failed) to make are that (1) I don't mind extra typing,
because it's really all about readability (obviously, from the
discussion, my opinion of what is readable may differ from others);
and (2) With the canonical two process technique, the sequential
process becomes boilerplate (even to the point of being able to be
generated by a script or editor macro, in most cases) that just
assigns a bunch of 'x <= next_x' statements. The top of the
combinatorial process becomes boilerplate as well, with corresponding
'next_x = x' statements (for some variables, it could be other things,
e.g. 'next_x = 0'. But you can just glance at those and not think
about it. So, when reading, you aren't really looking at that, or the
register declarations.

Once you accept that the sequential block, and the top of the
combinatorial block, are both boilerplate that you don't even need to
look at, then it's no more work than anything else. (In fact, if you
can type faster than 20 wpm and/or know how to write scripts or editor
macros, it's less work overall.)

KJ has already well stated the problems with latches (requiring
additional assignments) in combinatorial processes/blocks, regardless
of the naming convention employed.

I understand the issue with latches. I just never see them. The
coding style makes it easy to check and avoid them. It can even be
completely automatic if you have a script write your boilerplate.

Any decent simulator (maybe not a half-decent one) will merge
processes or always blocks that share the same sensitivity list. Since
they are usually identical for all synchronous processes clocked by
the same clock, they get merged, thus improving performance by
avoiding duplicative process-related overhead. Since combinatorial
processes rarely share the same sensitivity list, they don't get
merged, and performance suffers.

I'm pretty sure that verilator is smart enough to figure all this
out. That's the simulator I use if I care about execution time.

Regards,
Pat

 

[Patrick Maupin]

On Apr 23, 8:12 am, KJ <kkjenni...@sbcglobal.net> wrote:

The two process people generally do fall back on excuses about being
misunderstood.

Well, I'm not going to generalize about "one process people" but at
least some of them are supercilious bastards who think that anybody
who doesn't do things their way is an idiot. BTW, this is the last
post I'm going to reply to you on, so feel free to have fun with more
piling on.

Hmmm...so you prefer to take what you admit as unnecessary
chances....fair enough, that implies though that you expect some
actual benefit from that decision...but are probably unable to come up
with an actual example demonstrating that benefit.

Well, I haven't used the single process style in many years, so no, I
can't point you directly to the issues I had that led me to switch.
But I have helped others to switch over they years, and they have all
been grateful. In any case, I posted elsewhere in this thread a
pointer to Cliff Cumming's paper on blocking vs non-blocking
assignments. I assume you've been studiously avoiding that for
plausible deniability, so here it is: http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

If you read this paper carefully, you will come to an understanding
that, while it is often possible to follow it using a single process
method, in many cases, in order to follow it, you will have to assign
related variables from *different* sequential processes (one blocking
sequential process, one non-blocking sequential process). With the
sequential/combinatorial process method, using the boilerplate for
sequential processes is actually very easy and requires little
thinking, and allows you to do all the real work of coding on related
variables within the same combinatorial process, with a sequential
boilerplate process. You can concentrate all your hard thinking on
the problem at hand, in the non-boilerplate code in the combinatorial
process.

but I could have some other hard to find logic problems, which
I *have* had in the past).  

Ahhh....one of those examples...now what sort of 'hard to find' logic
problem would you like to offer up to to the group to actually
demonstrate that two processes are better than one?  I'm willing to
listen, but I'll warn that you that every time in the past that this
debate pops up, the two process people are unable to coherently
describe anything other than vague generalities as you've done
here...so here is your opportunity to present a clear example
describing a 'hard to find' logic problem that is easier to find when
coded with two processes.  The clocked process folks (i.e. the one
process camp) have in the past presented actual examples to back their
claims, Googling for 'two process' in the groups should provide some
good cases.

That's because you're *not* really willing to listen. If you were,
you would have heard, from me, anyway, loud and clear, that it's not
really about the *language constructs*, it's about how much people can
hold in their heads at a single time. The two process method reduces
the need for that, so even if I presented an example where it helped
me in my thinking, you would just superciliously explain how any idiot
should have seen the error in the one process method, so it doesn't
prove anything. Since you're the smartest asshole in the world, the
two process method couldn't possibly offer any benefits you would be
interested in, so just forget about it.

- Producing less maintainable code (two process will always physically
separate related things based only on whether the logic signal is a
'register' or not)

See, this is another place where you haven't listened. What don't you
understand about 'boilerplate'? It's a tiny bit of overhead, not
really part of what you need to worry about in maintenance. It is
easily checked and even automated.

Regards,
Pat

 

[Jonathan Bromley]

On Fri, 23 Apr 2010 09:25:50 -0700 (PDT), Patrick Maupin wrote:

In any case, I posted elsewhere in this thread a
pointer to Cliff Cumming's paper on blocking vs non-blocking
assignments. I assume you've been studiously avoiding that for
plausible deniability

Very droll.

If you have had even half an eye on comp.lang.verilog
these past few years you will have seen a number of
posts clearly pointing out the very serious flaws in
Cliff's otherwise rather useful paper. In particular,
the "guideline" (=myth) about not using blocking
assignments in a clocked always block was long
ago exposed for the nonsense it is.

Cliff is quite rightly highly respected in the industry,
but he's no more infallible than the rest of us and
he made a serious mistake (which, to his great
discredit, he has never chosen to retract) on
that issue.

You have the freedom to choose your coding
style, as we all do. You do yourself no favours
by citing flawed "authority" as discrediting
a style that you dislike.
--
Jonathan Bromley