| Author |
Message |
Guest
|
 Posted:
Thu Dec 22, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
"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, but if it not
immediately intuitive at first glance (which it wasn't), then it very
likely will get more difficult to synthesize. I personally think that
putting the reset condition first like "if (reset condition)..." makes
complete sense. I don't know. I guess I have looked at too much RTL
code here, read too many of our format docs, etc to see it any
differntly. But when you have to write code that will ultimately be
used in an ASIC (not me...others in the company) costing a freaking
ass-ton of money to develop, you tend to keep things consistent.
I would not spend too much time worrying about why your particular
construct wouldn't synthesize. Instead, focus on the de facto
standards that are used. Any Verilog book I have seen, and any Verilog
website with examples that I have seen will help. Writing RTL code is
not a field where you want to be creatively different with regards to
the format.
The best advice I can give is: Do NOT write ANY code until you know
EXACTLY how the circuit will work. This includes FF's and the
combinational logic attached to them. I sometimes draw this out on
paper. Then you write RTL code using your drawing. Then it is just
the process of translating that drawing to code, which should be
relatively trivial. |
|
| Back to top |
|
 |
Jan Decaluwe
Guest
|
| Posted:
Thu Dec 22, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
mottoblatto@yahoo.com wrote:
| Quote: | The best advice I can give is: Do NOT write ANY code until you know
EXACTLY how the circuit will work. This includes FF's and the
combinational logic attached to them. I sometimes draw this out on
paper. Then you write RTL code using your drawing. Then it is just
the process of translating that drawing to code, which should be
relatively trivial.
|
Why not draw the circuit on a computer with a schematic capture
package then? Why the overhead of going through Verilog
and synthesis?
Either that, or your advice is not that good really.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com |
|
| Back to top |
|
|
Guest
|
| Posted:
Thu Dec 22, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
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. |
|
| Back to top |
|
|
Chris F Clark
Guest
|
| Posted:
Thu Dec 22, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
You've had people recommend that you "think hardware" and I'm of that
camp. It's one of the reasons for using "templates", each template
corresponds to a specific "piece" of hardware (often called a library
cell in ASIC design, there are similar concepts in FPGA design, but I
don't know if the terminology is changed). In fact, the original
synthesizers were close to template matchers. They simply looked at
the code and matched it to a library of templates and if it found a
match, the synthesizer lay down the piece of hardware corresponding to
that template.
Now synthesizers have grown much smarter, but the basic concept still
holds. This is why, it is important for you as a designer to follow
the templates carefully. If you write verilog that matches the
templates, you can predict exactly what kind of hardware the
synthesizer will create. If your verilog is a little off, the
synthesizer can bend a little to match the templates, but it may do so
by either matching a template that you don't expect or by inserting
extra logic etc.
For example, a "tri-state buffer" in the library I'm failiar with look
like:
assign out[31:0] = enable ? value[31:0] : 32'bz;
If you put this fragment in your verilog and use the library I
mentioned, you will instantiate 32 parallel 1 bit buffers with a
tri-state enable pin, which copy value to output when the enable is
true and leave the value floating if enable is false. You can vary
this template to get 32 distinct enable pins--personally, I would
write that as 32 1 bit assignments, but I'm not a chip designer, just
an architect, so there may be a shorter solution.
However, I would not attempt to put this code into a "clocked always
block". To me that is tempting the synthesizer to match a different
template than I expected (and tri-state buffers are something I know
have specific semantics that I want followed exactly and not have the
synthesizer "winging it"). That's part of the thinking hardware
aspect. I have a specific piece of hardware in mind when I write the
verilog code. I don't mix templates together willy-nilly, as the
synthesizer may figure out what I want and may not. There are some
places where I allow more latitude, because I know the synthesizer can
generate some circuit that will work and the chip designer can modify
the verilog if the synthesizer doesn't generate a circuit which is
"good enough"--state machines are a good example of where this
latitude is usually ok.
This now bring up the last example, you have given:
| Quote: | always @(posedge clk_in or negedge clk_in) begin
.... |
I don't know what kind of hardware you expect to react exactly to both
rising and falling edges of your clock (and nothing else). Most
synthesizers don't know of such logic either. Therefore, this line is
a recipe for disaster. If you can explain what kind of gates you
expect it to create, there may be another way to write the code.
However, the synthesizers that are complaining that they can't find a
matching template are doing so for good reason.
One final little point on this topic, the code in the templates makes
the verilog behavior match hardware behavior under a set of
assumptions. These assumptions are normally met under the "clocked
digital design regimen". That is, if we only look at the values when
things are stable (in between clocks and when things have had enough
time to settle), the behavior the verilog code models and the behavior
the hardware exhibits will match. However, there are things which
happen in the hardware that don't happen in the verilog model, and
vice versa. Thus, you can in verilog ask if a signal is floating, but
there probably isn't a piece of hardware that can ask that
question. Designers who forget that the hardware and the verilog
"aren't the same" and only behave the same under controlled
conditions, often write verilog code that corresponds only to
imaginary hardware that can't be built. Gross violations won't get
through the synthesizer. More subtle violations will result in pre-
and post- synthesis mismatches or worse a design that simulates but
fails in real hardware under conditions that violate the assumptions
of the simulations.
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)
------------------------------------------------------------------------------ |
|
| Back to top |
|
|
Guest
|
| Posted:
Thu Dec 22, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
johnp wrote:
| Quote: | Reza -
I suggest you do some studying on your own rather than asking this
group to design your circuit.
On your tri-state question, try Google "verilog tristate", then do some
reading.
John Providenza
|
I have to agree. No offense, but if you are in an EE graduate level
course, it is shameful that you are asking what a "Digital Design"
course would cover. And everyone has been more than helpful here.
There are SO many resources available on the Internet with respect to
Verilog and Xilinx CPLD/FPGA's. I just started working with the group
in our company that does FPGA systems design and there IS a learning
curve.
I have had to do a lot of reading, a lot of RTL coding and simulation,
and a lot of experimentation. I have asked a couple of questions on
this forum, but have not relied on it for an absolute answer. Don't
get me wrong. It is a great resource, but you are doing yourself a
disservice if you won't try to figure this out on your own. Trust me.
An employer will see this immediately and you won't make it very far.
Just try. |
|
| Back to top |
|
|
Ray Andraka
Guest
|
| Posted:
Thu Dec 22, 2005 11:20 pm Post subject:
Re: More beginner's verilog questions |
|
|
Reza Naima wrote:
| Quote: | 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. |
|
| Back to top |
|
|
Andy Peters
Guest
|
| Posted:
Fri Dec 23, 2005 1:16 am Post subject:
Re: More beginner's verilog questions |
|
|
Reza Naima wrote:
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
Andy Peters
Guest
|
| Posted:
Fri Dec 23, 2005 1:16 am Post subject:
Re: More beginner's verilog questions |
|
|
mottoblatto@yahoo.com wrote:
| Quote: | "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 |
|
| Back to top |
|
|
Andy Peters
Guest
|
| Posted:
Fri Dec 23, 2005 1:16 am Post subject:
Re: More beginner's verilog questions |
|
|
Reza Naima wrote:
| Quote: | - 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | /* 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 |
|
| Back to top |
|
|
Hal Murray
Guest
|
| Posted:
Sat Dec 24, 2005 12:01 am Post subject:
Re: More beginner's verilog questions |
|
|
| Quote: | 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. |
|
| Back to top |
|
|
Reza Naima
Guest
|
| Posted:
Sun Dec 25, 2005 4:03 pm Post subject:
Re: More beginner's verilog questions |
|
|
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. |
|
| Back to top |
|
|
Bob Perlman
Guest
|
| Posted:
Sun Dec 25, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
On 25 Dec 2005 02:03:40 -0800, "Reza Naima" <google@reza.net> wrote:
| Quote: | stuff snipped
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 .
|
EL ENG 42 Introduction to Digital Electronics
EL ENG 141 Introduction to Digital Integrated Circuits
You may also want to look at the online lecture notes for this course:
http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-111Spring2004/CourseHome/index.htm
Bob Perlman
Cambrian Design Works |
|
| Back to top |
|
|
Guest
|
| Posted:
Sun Dec 25, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
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!! |
|
| Back to top |
|
|
Bob Perlman
Guest
|
| Posted:
Sun Dec 25, 2005 11:16 pm Post subject:
Re: More beginner's verilog questions |
|
|
There's one more course I should mention. Eric Crabill of Xilinx
teaches a digital design course at SJSU. The class notes are online
at:
http://www.engr.sjsu.edu/crabill/
This is probably the best how-to-do-FPGA-design course for beginners
that I've seen.
Bob Perlman
Cambrian Design Works |
|
| Back to top |
|
|
Jan Decaluwe
Guest
|
| Posted:
Mon Dec 26, 2005 1:15 am Post subject:
Re: More beginner's verilog questions |
|
|
Reza Naima wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: | - 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.
| Quote: | - 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.
| Quote: | - 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 |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in