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.
formatting link
. 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
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!!
Yes. You'll have to scale down such expectations about synthesis drastically.
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.
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.
I think they just implement what "asynchronous" means. Priority seems an inherent property.
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
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:
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
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
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
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 : snipped-for-privacy@world.std.com Compiler Resources, Inc. Web Site :
formatting link
23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.