«

There is always a tendency to teach a new design method/langauge in
terms of translating the elements of the old method or language. When
teaching HDL to folks who know schematics with gates and registers, we
tend to focus on HDL descriptions of gates and registers. When we
teach vhdl to verilog users, we tend to focus on translating verilog
elements into their vhdl equivalents.

This method of teaching tends to restrict the use of the new language
to the limits imposed by the old one. Thus it is with vhdl's variables
and signals vs verilog's blocking and non-blocking assignment
statements. Because there are so many easy ways to get into trouble
with verilog blocking and non-blocking assignments, most tend not to
use one or the other effectively (usually blocking assignments).
However vhdl enforces Jan's restrictions on communication (signals) vs
local computation (variables), so using both effectively is much
safer.

This in turn allows one to focus on fewer, more complex, clocked vhdl
processes that describe the desired rusults in terms of cycle by cycle
behavior, instead of in terms of registers and gates. The increase in
abstraction allows designing something based on its intended behavior,
not its intended structure, which would have to be worked out
separately in one's head or on paper or whatever.

To be fair, with less concentration on the registers and gates it
takes to effect a desired behavior, it is easier to design something
that works, if only it would fit in the desired device or run at the
desired clock speed! However, even when faced with this dillema,
considering behavioral modifications in terms of adding cycles of
latency and spreading the behavioral complexity between them, instead
of structural additions of registered pipeline stages, is often
helpful, especially if the spreading step is an optimization available
in the synthesis tool (aka register retiming).

Hope this helps,

Andy

I guess the first point is to keep in mind the students will have done
a handful of trivial verilog modules before taking this class. And
they have to learn a huge number of other things. So we necessarily
oversimplify things. That said, it would be very useful for me to
understand why people believe these are over simplified. Even if we
don't change our rules, it's important for me to understand "truth" so
I can let them know the issues involved.

On Jan 28, 9:30*am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> Mark Brehob wrote:
> > On Jan 27, 9:00 pm, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:
> >> On 2009-01-28, Mark Brehob <bre...@gmail.com> wrote:
>
> >> And some encouragement: Think of how nice it will be to know that the
> >> students' code will not contain any blocking/non-blocking races.
>
> >> /Andreas
>
> > Actually, good coding style in Verilog completely eliminates that
> > problem. *In my other class, the students build a synthisizable out-of-
> > order processor starting with an in-order processor. *We've found that
> > blocking/non-blocking problems just don't occur if you follow simple
> > rules. *We teach those rules as "required" and the problem go away.
> > Seehttp://www.eecs.umich.edu/courses/eecs470/tools/verilog_guidelines.pdf
> > for a short summary.
>
> Simple enough, but especially intolerably simplistic.
>
> Do you realize that these rules forbid variable semantics?
> Even if you don't want to use variables in synthesizable code
> for some awkward reason, you surely want them in test benches,
> right? Don't you think you can have races there too? So what rule
> do you use then?

It's in that list and I think it works fairly well. We change inputs
from the testbench only on the falling edge of the clock. As we don't
worry about the testbench being synthisizable we don't worry too much
about the "rules" there. It has caused occasional problems, but
nothing I can think of as a huge or common problem at all.


>
> No, even in Verilog you need something more sophisticated that
> still permits variables: use signals (non-blocking assignments)
> for communication, and variables (blocking assignments) for
> local computation. It always works, for Verilog, VHDL, synthesis,
> test bench, high-level modeling, you name it.
>
> http://www.myhdl.org/doku.php/why#yo...t_blocking_and...

At a quick glance, I'm not seeing the definition of communication vs.
local. It would seem that sometimes things are both, but I'd guess
you have a formal definition that handles that. However, I'll note
that our rules are really simple to understand and a lint program can
be written to check for it. (In fact there is one some students wrote
on sourceforge). This is really handy when dealing with fairly novice
coders.

Thanks again!



Mark

>
> --
> Jan Decaluwe - Resources bvba -http://www.jandecaluwe.com
> * * *Python as a hardware description language:
> * * *http://www.myhdl.org

On Jan 28, 9:43*am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Wed, 28 Jan 2009 06:06:09 -0800 (PST), Mark Brehob wrote:
> >We teach those rules as "required" and the problem go away.
> >Seehttp://www.eecs.umich.edu/courses/eecs470/tools/verilog_guidelines.pdf
> >for a short summary.
>
> Ooooh, don't get me started about
>
> * * 10. Do not mix blocking and nonblocking assignments
> * * * * in the same always block.
>
> As a start, for beginners, it's fine. *For anything
> serious, it cramps the style horribly. *Cliff Cummings
> is an undoubted expert and a nice guy to boot, but he
> and I part company in a big way on that point. *You can't
> get the behaviour of VHDL variables in a clocked process
> without breaking that rule.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Could you give an example or otherwise illustrate the issue here? I'm
not sure what "the behaviour of VHDL variables in a clocked process"
is, or why I'd want it.

Thanks!
Mark

On Jan 28, 6:17*am, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:
> On 2009-01-28, Mark Brehob <bre...@gmail.com> wrote:
>
> > Actually, good coding style in Verilog completely eliminates that
> > problem. *In my other class, the students build a synthisizable out-of-
> > order processor starting with an in-order processor. *We've found that
> > blocking/non-blocking problems just don't occur if you follow simple
> > rules. *We teach those rules as "required" and the problem go away.
> > Seehttp://www.eecs.umich.edu/courses/eecs470/tools/verilog_guidelines.pdf
> > for a short summary.
>
> Well, we teach more or less the same rules as well, but there is always
> at least one group per year who manages to come up with some nice and
> interesting blocking/non-blocking race condition

Other than with testbenches I can't think of a time it has come up.
And even then, it requires effort. Of course students seem really
good at generating that effort.

>
> The course you are talking about sounds very interesting by the way,
> I wish I could have attended such a course as an undergraduate student.
> Do you know roughly how much time students spend doing the projects in
> this course? *

A lot. We assign the project with 8-9 weeks left and they can count on
200+ hours of work each. It's crazy, but we have 80-100 people take
it a year and it certainly isn't required (though for computer
engineers there aren't a lot of other options...) We've also gotten
very good at giving them starting points (in-order processor, *very*
basic I-cache and RS) and teaching them exactly the right things to be
able to tackle the problem with the tools we have. Plus we have people
(instructor, TA, staff member) who are good a debugging when things
are really crazy. But they spend 15+ hours just on the high level
design before they even start coding. It's really cool to watch.

> Do they have to care about the efficiency of their
> RTL code or do they only have to get it synthesizable?
>

Clock cycle matters, but is a second-order issue. The way we grade
things about 20% of the grade is for performance, and that is
basically measured by how long it takes the various testbenches to
run. Good architecture can get you there (lots of CPI) but clock
cycle obviously plays a big role too. And as memory latency is held
constant, going slow isn't _that_ bad. Generally 1 group out of 10
will not have synthesis working, 1 other will have a cycle time that
is 2-3x what it should be and one will be very low indeed for the
process used.

The real problem is that until most everything is built it can be hard
for them to judge clock-cycle. Individual parts may come in quite
well, but their might be (will be) a combinational path they didn't
think about. So they have to hunt and fix these in 2-10 days
depending on how fast they were at everything else.

Mark


> /Andreas

On Jan 28, 9:35*am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Tue, 27 Jan 2009 17:33:44 -0800 (PST), Mark Brehob <bre...@gmail.com>

<clip>
>
> >I had a bunch of other questions, but of course I've forgotten (did my
> >coding over the weekend and I guess 48 hours ago is enough time to
> >forget). *I'm mostly enjoying it, but as you might expect, it's
> >bringing back Ada nightmares. *
>
> Like having code that actually worked first time once you got it through
> the compiler?

First of all, thanks for the comments above. They help me understand
the "VHDL way". Which is important if I'm going to teach it.

That said, I never had that "problem" Ada. I guess I'm lucky, but
type problems rarely burn me. Logic errors or syntax errors do, but
type checking doesn't help much there.

>
> > C/Verilog people should not
> >have to deal with strict type checking .
>
> It eats into their precious debugging time...

*laugh* that literally made me laugh out loud. Yeah, I understand
that viewpoint. Just doesn't match my experience for the most part.

Although thinking about it, I've had problems with C on Atmel
processors. But they were actual _bugs_ a real compiler with -Wall
would have caught. I will admit, the strong desire to save a few
bytes here and there on the small embedded processors can make you
dream of strict checking of sizes...

Again, thanks!
Mark
>
> - Brian

Tha

On 2009-01-29, Mark Brehob <> wrote:
> But it is _really_ helpful to understand why good people like to
> "break our rules". Otherwise I just know people do, but can't give
> examples to the students.

Another example for your consideration. Unrolling a CRC for Ethernet.
You could do this without variables by unrolling it manually, but why
do work yourself when the synthesis tool can do it for you?

/Andreas


-- (This could be done in a neater way using ranges)
process (clk)
variable crc_tmp : std_logic_vector(31 downto 0);
variable fb : std_logic;
begin -- process
if clk'event and clk = '1' then -- rising clock edge
if enable = '1' then
crc_tmp := crc;

-- Unrolled to process a nibble at a time.
for i in 0 to 3 loop
fb := crc_tmp(31);
crc_tmp(31) := crc_tmp(30);
crc_tmp(30) := crc_tmp(29);
crc_tmp(29) := crc_tmp(2;
crc_tmp(2 := crc_tmp(27);
crc_tmp(27) := crc_tmp(26);
crc_tmp(26) := d(i) xor fb xor crc_tmp(25); -- x^26
crc_tmp(25) := crc_tmp(24);
crc_tmp(24) := crc_tmp(23);
crc_tmp(23) := d(i) xor fb xor crc_tmp(22); -- x^23
crc_tmp(22) := d(i) xor fb xor crc_tmp(21); -- x^22
crc_tmp(21) := crc_tmp(20);
crc_tmp(20) := crc_tmp(19);
crc_tmp(19) := crc_tmp(1;
crc_tmp(1 := crc_tmp(17);
crc_tmp(17) := crc_tmp(16);
crc_tmp(16) := d(i) xor fb xor crc_tmp(15); -- x^16
crc_tmp(15) := crc_tmp(14);
crc_tmp(14) := crc_tmp(13);
crc_tmp(13) := crc_tmp(12);
crc_tmp(12) := d(i) xor fb xor crc_tmp(11); -- x^12
crc_tmp(11) := d(i) xor fb xor crc_tmp(10); -- x^11
crc_tmp(10) := d(i) xor fb xor crc_tmp(9); -- x^10
crc_tmp(9) := crc_tmp(;
crc_tmp( := d(i) xor fb xor crc_tmp(7); -- x^8
crc_tmp(7) := d(i) xor fb xor crc_tmp(6); -- x^7
crc_tmp(6) := crc_tmp(5);
crc_tmp(5) := d(i) xor fb xor crc_tmp(4); -- x^5
crc_tmp(4) := d(i) xor fb xor crc_tmp(3); -- x^4
crc_tmp(3) := crc_tmp(2);
crc_tmp(2) := d(i) xor fb xor crc_tmp(1); -- x^2
crc_tmp(1) := d(i) xor fb xor crc_tmp(0); -- x^1
crc_tmp(0) := d(i) xor fb; -- 1

crc <= crc_tmp;


elsif clear = '1' then
crc <= (others => '1');
end if;
end if;
end process;

> In a clocked process:
> 1.ALWAYS use nonblocking assignment to any variable
> * whose value will be used outside the process;
> 2.NEVER mix blocking and nonblocking assignment
> * to a single variable;
> 3.any variable assigned by blocking assignment must
> * be declared locally in the process's begin-end, so
> * that it can't be referenced from outside (at least,
> * not for synthesis);
> 4.be aware of the immediate-update semantics of
> * blocking assignment. *This means...
> * - if you read such a variable before assigning
> * * to it, you get the value that it was given
> * * on the PREVIOUS clock - held in a flip-flop;
> * - if you read such a variable after assigning
> * * to it, you get the combinational value that
> * * you just assigned to it.


This is the best blocking/non-blocking guideline I've seen. Thanks
for sharing.

George K.

On Jan 29, 5:59*am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
<clip>
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Thanks! For our courses, we try to avoid things like this and tell
them that while good people do code that way, our way is safer. When
they get more expert, they can be more brave.

But it is _really_ helpful to understand why good people like to
"break our rules". Otherwise I just know people do, but can't give
examples to the students.

Mark

Mark

Interesting references to Ada; back in the 90's I took a couple of ada
training classes so that I could learn some "software" techniqes for
vhdl that are not generally taught in vhdl classes (at least the ones
I had taken). I learned general stuff about using types/subtypes
effectively, using scope to control access, applications of packages,
deferred constants (still not synthesizable?!), procedures/functions,
etc. The type-based genericity of ada was really nice; completely
different from what vhdl generics offer.

Andy

I was fine with two process (combinatorial & clocked) styles, until I
had to infer clock enabled registers; so much for the simple
functional boundary between logic and registers.

Jonathan's "two-bubble" state machine example is one I do not
personally use. I use a single clocked process with variables, and any
outputs that need to be "on" in a given state are assigned at every
entrance to that state. Sometimes a little more coding, but not
usually. One tends to modify their approach to state machine design to
suit their favorite coding style anyway.

Andy