I seem to have missed some articles in this thread, as there are some
things being reference that I can't having seen.  However, I would
like to respond to some of the last comments I've seen.

Reza Naima wrote:
> It seems my biggest problem was that I though that HDL would give me
> the ability to write behavioral code and the software would be able
> to make it work...

Yes, that is always the hitch--in every area where we have automated
tools: synthesizers, parser generators (my area of expertise), 4GL
lanugages, natural language translators, et al.  There is some level
of behavioral code that tools will be able translate.  However, they
will never reach the "holy grail".  This is no "dwim" (do what I mean)
instruction and cannot be.  What we have are idioms that tools can
understand and paraphrase.  If you learn the idioms (dialect) the tool
can speak, you can make it do quite a bit.  

Here is some very specific advice about what idioms that synthesizers
understand.

Jan Decaluwe wrote:
> My advice: for implementation-oriented modeling, you only need 2
> templates: the synchronous always block (sensitive to a clock
> edge and possibly a reset edge), and the combinatorial always
> block (sensitive to the input signal levels).

This is the essence of a digital design course.  Laying down
combinatorial logic that is fed into (or driven by) a set of
flip-flops that are clocked at an appropriate time.  At some very deep
level all synchronous digital design is about designing an FSM (finite
state machine) which is merely a collection of gates around
flip-flops.

J> To a large extent, you can concentrate on getting the behavior
> right (hard enough), and rely on the synthesis tool to give you a good
> implementation.

This is true.  If you build everything, out of the two blocks
described, you will have designed a circuit that a synthesizer can
build.  There are still timing issues and other things to worry about.
However, the synthesizer will be able to lay down a set of gates that
does what your model does.  This is the technology that the
syntehsizer writers' have, a way of translating those two idioms into
circuitry.  Those are probably about the only two universal idioms,
because they represent things that are present in all forms
(implementations) of Boolean logic.

Things like tri-state drivers are not universal, because they are not
purely parts of Boolean logic and some implementations will have them
and others may not.  Moreover, they may work "differently" in varying
implementations, because the underlying mechanism may work
"differently", and that may require specifying them differently at the
source level, to give a better interpretation of the semantics of the
implementation.

J> In contrast to what many people will tell you (and sometimes shout
> at you), there's no need to try to visualize the exact hardware that
> will come out. Believe me, they can't either.

Here I will disagree to some extent.  Jan is correct in that I can't
predict exactly what gates will be infered by a synchronous always
block I write.  However, I do have a reasonable expectation, that it
will be some combinatorial logic feeding some flip-flops and some
combinatorial logic leading away from the flip-flops.  Moreover, when
I've written a synchronous always block, I have a pretty code idea
what signal is going to be driving the clock pins of the flip-flops in
that block.  Now, if I want something different, say a tri-state bus
with some keeper that has a specific decay on it, I will write
different Verilog code.  I will be really surprised if a synthesizer
writes out a tri-state bus when I've written a synchronous always
block--the synchronous always block is not the idiom used to create a
tri-state bus.

This is what I mean, by think hardware.  Learn the idioms and what
they translate to.  There aren't many of them.  I think I know about
5: combinatorial code, synchronous (clocked) always block, tri-state
driver, priority encoder, and mux.  Once you've learned the idioms,
then you know when you want something that works like x, you pick the
idiom that generates an x.  Now, you may not know all the hardware the
synthesizer will generate to lay down an x (and the synthesizer may
even be more clever than you are and know that a y will work in the
given context and substitute a y), but you'll have basic concepts of
what the synthesizer can do for you and you will design circuits which
the synthesizer can lay down.  When I want to design something, I
think how I can build it using those basic concepts, and once I know
that I can build it out of those things, then I have a rough design.
If I want something that I can't map to those concepts, then I don't
know how to build it (and I don't know what to tell the synthesizer
either).

Not to beat a dead horse, but I have one final comment on the topic
of "thinking in hardware".  It has to do with for-loops.  There are
some for loops that can be synthesized, but many (most) cannot.  In
general for-loops that search cannot by synthesized.  Nor can ones
that do sorting.  For-loops that simply iterate over each bit of a
resigter can.  If one lays down an unsynthesizable for-loop in an
otherwise synthesizable always block, the result is unsynthesizable.
The whole point of "thinking in terms of hardware" is avoiding writing
that kind of code.

Finally, I don't have a good answer to:

R> -  There have been several replies indicating that the order of the
> statment has to do with priorities, and an async reset has a higher
> priority.  Why is this?  Is this just how flipflops are physically
> built?

It's probably more likely an artifact of the synthesizer.  As I said
previoiusly, the synthesizer works by matching your code to its
templates.  Those templates have some assumptions built into them.
Now, there are some variations in the templates the synthesizer can
handle (and better synthesizers generally can handle more variation).
However, at some level, when you've strayed too far from the
templates, the synthesizer writer cannot legitimately infer what you
"meant" and the writer chooses instead to give you an error telling
you to change your code into something that better matches the
templates (rather than instantiating something that is wrong).

Hope this helps,
-Chris

*****************************************************************************
Chris Clark                    Internet   :  compres@world.std.com
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)
------------------------------------------------------------------------------

Reza Naima wrote:
> Wow, this thread had hit the 40 post mark already.  First off, I want
> to thank all the people that have given me a great deal of help and
> insight in understanding verilog/synthesizers.  It seems my biggest
> problem was that I though that HDL would give me the ability to write
> behavioral code and the software would be able to make it work - i.e.
> if I add a delay, it generates all the required counters/etc to
> implment the delay.  But it seems to be a lot more primative than I had
> expected.

Yes. You'll have to scale down such expectations about synthesis
drastically.

> I think of verilog/HDL as a tool to use, not a career destination.

That may explain your communication problems with many of the people
here.

On a personal note, the meta-goal of my current work is to show that
your approach is meaningful and productive. You may want to
explore the link in the signature section.

> - Are there a standard set of templates that all synthesizers use?

There is an IEEE synthesis standard that all reasonable synthesis tools
will adhere to - but I agree that it doesn't seem that easy to get that
info for free.

My advice: for implementation-oriented modeling, you only need 2
templates: the synchronous always block (sensitive to a clock
edge and possibly a reset edge), and the combinatorial always
block (sensitive to the input signal levels).

Out of these, use the synchronous template for the bulk of your
work. The big advantage is that you can then raise your expectations
again. To a large extent, you can concentrate on getting the behavior
right (hard enough), and rely on the synthesis tool to give you a good
implementation. In contrast to what many people will tell you (and
sometimes shout at you), there's no need to try to visualize the exact
hardware that will come out. Believe me, they can't either.

I'll go further. Once you follow the advice above, relying on
"hardware thinking" too much will hamper productivity. Die-hard
hardware thinkers may miss the opportunity to find an elegant coding
solution without giving up efficiency in the synthesized result. So
here's a chance to do better than the experts.

> -  There have been several replies indicating that the order of the
> statment has to do with priorities, and an async reset has a higher
> priority.  Why is this?  Is this just how flipflops are physically
> built?

I think they just implement what "asynchronous" means. Priority
seems an inherent property.

> - about the rising & falling edge of a signal triggering a block - if
> two flipflops are required, so be it.  is it bad form?  Shouldn't the
> synthesizer be able to deal with it?

To me, it's not obvious they should. A particular case is not
a general solution yet.

For now, just code the behavior you want using two
synchronous blocks, sensitive to different edges.

Jan

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

Hi Reza!


I will recommend two readings that will save you a lot of headache:

The first one is an expensive, but invaluable book (sorry, don't know
if it exists in a Verilog version): "VHDL for Logic Synthesis"


And the second one is a free PDF downloadable from Actel homepage:
"Actel HDL Coding"

(I am sure the other players have their own HDL coding style guides
too, but this one looks the best).

They will show you how synthesizers work internally.

good luck!
(and happy new year)



PS. for some reason some people one the newsgroups waste a lot of their
own time and our time by giving non-answers. If you dont have an
answer, dont post!!

Wow, this thread had hit the 40 post mark already.  First off, I want
to thank all the people that have given me a great deal of help and
insight in understanding verilog/synthesizers.  It seems my biggest
problem was that I though that HDL would give me the ability to write
behavioral code and the software would be able to make it work - i.e.
if I add a delay, it generates all the required counters/etc to
implment the delay.  But it seems to be a lot more primative than I had
expected.

However, I am a bit irked at the continued comments about this "digital
design" class.  I have no problems taking a course that's recommended,
but when I try to map "digital design" to a real course and ask for
help doing so, I get nothing but degrading comments.  So, I will ask
one last time in a more direct fasion: Rather than degrading my
abilities, please find a "digital design" class from the Berkely course
schedule.  http://schedule.berkeley.edu .  I also want to follow by
saying that I am not an EE major nor have I taken any EE classes in my
life.  I'm a bioengineering major and the bulk of my courses have been
dealt with mechanics, chemistry, physics, biology, etc.  With that
said, I have done a lot of electronics work - mostly with
microcontrollers, and the work I've done has been well liked by the
people I have worked for.

I think of verilog/HDL as a tool to use, not a career destination.
All I want is a rudementary understanding of it so I can later make
informed decisions about what the right tool to use for a task is.

And getting back to the notion of asking questions vs. doing my own
"studying" -- I've learned more in the past 40 posts about
verilog/synthesizers than I have in the dozens of hours I've spent
reading books and web pages on the material.  And in response to the
RTFM, I actually followed someone else's suggestion of googling for
"tristate verilog".  I found some docs for altera, whch didn't seem to
work for xilinx.  After  bit of playing, I figured it out.  I
appreciate that you answered my question, twice, but there was no need
to be insultive about it.  I really didn't know where to look about the
tristate thing - you could have said "look in the xxxxx docs" or given
me the answer and had that been the end of it.

One other comment before I ask some real questions.  I really want to
thank the people that have posted brief and accurate answers to my
questions as well as those that have provided me with pointers.

Ok, Real questions in response :

- Are there a standard set of templates that all synthesizers use?  The
problem was that the same synthesizer said it couldnt find a template
for one target CPLD, but it found it for another.  Why would this be?
Does anyone know of a respository for standard templates?
-  There have been several replies indicating that the order of the
statment has to do with priorities, and an async reset has a higher
priority.  Why is this?  Is this just how flipflops are physically
built?  Andy gave an example about a high vs. low reset.   Was the
second example invalid?   My code "if (!reset)..." failed, but what if
it was an active low reset.  Then shouldn't it have worked?  Or was the
reset implied in the <= 0, in which case the problem was not the
(!reset), but rather the location of <=0?  What exactly defines a
reset?
- about the rising & falling edge of a signal triggering a block - if
two flipflops are required, so be it.  is it bad form?  Shouldn't the
synthesizer be able to deal with it?

thnx,
reza

p.s. people keep saying there are great resources on the net, but i'm
having problems finding good information.  If anyone knows of some good
sites, I would love to know.  google is not a valid answer to this
question, but google search terms are if you've found good info using
the phrase.

>I found the RTL schematic viewer - though I sitll am not sure what RTL
>stands for.   

google works pretty well for that sort of problem.  If you can't find
something interesting right away, add acronym to the search list.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Reza Naima wrote:

> - The async verilog code will only be run once every few days, and will
> be controlled from a microcontroller that I can tweak to guarantee
> sufficient time between each state change.  I do have a clock available
> that I could feed into it to make it a synchronous design - but I'll go
> for the async first to see if I can get it to work.

How often the code runs is irrelevant.  The question is how long
between changes must you wait for all affected logic to settle.

> p.s. I've added some extra code (see below) that is synthesized just
> fine on one of the xilinx CPLDs, but gives errors if I configure it for
> another CPLD types.

If you're referring to the code below, I say: Impossible.

> It says it can't find a matching template for the
> other cpld architectures.   I also found that I had to do the posedge
> and negedge explicitly.

It's perfectly legal to use both sides of the clock for different
flip-flops.  However, there's no CPLD/FPGA flip-flop that is sensitive
to both edges of the clock.

> I thought that if I left that out, any state
> change for the signal would initiate the block.

No -- the only things that "initiate" the block are the signals on the
sensitivity list.  Which is why a sensitivity list exists.

> 	/* cs toggler - cs goes high for one clock cycle every 17 clk_in
> cycles */
> 	always @(posedge clk_in or negedge clk_in) begin
> 		sck = !sck;
> 		spi_counter <= spi_counter + 1;
> 		if (spi_counter == 16)
> 			cs <= 1;
> 		if (spi_counter == 17) begin
> 			cs <= 0;
> 			spi_counter <= 0;
> 		end
> 	end

-a

mottoblatto@yahoo.com wrote:
> "If A do a else do b
> If !A do b else do a"
>
> In regards to the above.  These statements make "logical" sense.  But
> it is BAD design practice when writing RTL code.  It JUST is.  I have
> never heard or read any differently.  Put your "reset" condition first,
> then follow that with your other conditions.  I don't pretend to be an
> expert, so if anyone has a different opinion, please let me know.
>
> I don't know why the synthesizer has a problem with it,

PRIORITY!!!!

The async reset has priority over the synchronous (clocked) logic.
That's why its condition is handled FIRST.

-a

Reza Naima wrote:
> John,
>
> I'm just trying to use the usenet as a resource to learn.  In reading
> other sources, it seems that I could output a 'z' in order to achieve a
> tri-state -- however, as I've found out, there is a lot of strange
> behaviour in actually going from verilog syntax to application and
> implementation.  I wanted to see if there were any gotcha's in this
> approach.  I also wanted to know if it was possible for a physical
> input to read 'z' if I configure the microcontroller's pin as an input
> (putting it in tri-state), or if I would have to add another pin (say,
> enable_Z) to specify when I want the output to be equal to 'z'.  I'm
> also not sure about the implementation differences - say, between
> xilinx and altera, and if one supports a certain mode of opperation
> that the other does not.

Turns out that both Altera's and Xilinx' proprietary synthesis tools,
as well as Synplify and Mentor Precision, use the same constructs to
infer tristate buffers.

And it turns out that all four tools have documentation that clearly
explains how to infer a tristate!

R T F M.  Really.

> Another aspect of my questions is trying to understand the strange
> behaviour.  I still don't see why the synthesizer has a problem
> equating these two constructs :
>
> If A do a else do b
> If !A do b else do a
>
> they seem identical to me, and I'll have to do some more research and
> re-read some of the replies to this thread to try to figure it out.

In the specific case of the reset circuit, you have to realize
something.   Perhaps the circuit has an active low reset.  In that
case, the condition

    if (reset_n)
        q <= q + 1;
    else
        q <= 0;

has a different meaning than

    if (~reset_n)
        q <= 0;
    else
        q <= q + 1;

Even though at first glance they appear identical.

You must realize that the async reset _has priority_ over the rest of
the logic, so you must write your code to reflect that.  The synthesis
tool helpfully complains if you do it wrong.

-a

Reza Naima wrote:
> Rob,
> 
> I never asked if a microprocessor could read a 'z', I asked if a CPLD
> could determine if an input was floating or not - though I doubt it
> could.  And as I've stated, I'm a graduate student, so I'm obviously
> not working in industry.  I take it you like to skim.
> 
> I found the RTL schematic viewer - though I sitll am not sure what RTL
> stands for.   
> 
> Reza
> 
  RTL = Register Transfer Level.  It means the design is specified in 
the HDL by describing the registers and the logic that goes between it. 
  RTL is generally considered to be device independent, but as giving 
enough detail to make synthesis fairly easy.

Contrast this with a structural description, which is basically a 
netlist containing the FPGA primitives and the wiring connections for 
them.  Structural implementations are device specific, and leave nothing 
for the tools to infer during synthesis; also contrast with  behavioral 
which describes the black box function of the design but not the details 
for the implementation.  Behavioral descriptions are generally not 
synthesizable.

It is good advice if you are just starting out designing using an HDL.
If you don't have a picture of the circuit you are describing, then you
may write crappy code.  I lied.  I do not draw the circuit out.  But I
have in the past when I was first starting with simple logic...like
what the guy is trying to do.  It is SIMPLE.  I can visualize digital
hardware and code from there, but I didn't want to muddy the waters.

Schematic capture would be fine for this example, but defeats the
purpose of trying to learn the HDL.  I'm just trying to give helpful
advice to someone who obviously does not know what is going on.  "What
would a Digital Design class cover?"  Come on.  This guy needs to draw
a circuit!!

I am surprised at your response though.  Being an "electronic design
consultant", I would think that you would agree with what I said.
Maybe it didn't come across well.  I didn't mean "draw your seriously
complex design, and then code it".  Do you write code before you know
what your circuit is going to do, or how it will work?  If so, I
wouldn't use you as a consultant.  Jan.