johnp wrote:> 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 ProvidenzaI 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.
More beginner's verilog questions
Started by ●December 19, 2005
Reply by ●December 22, 20052005-12-22
Reply by ●December 22, 20052005-12-22
"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.
Reply by ●December 22, 20052005-12-22
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:> 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) ------------------------------------------------------------------------------
Reply by ●December 22, 20052005-12-22
mottoblatto@yahoo.com wrote:> 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
Reply by ●December 22, 20052005-12-22
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.
Reply by ●December 22, 20052005-12-22
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.
Reply by ●December 22, 20052005-12-22
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
Reply by ●December 22, 20052005-12-22
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
Reply by ●December 22, 20052005-12-22
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
Reply by ●December 23, 20052005-12-23
>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.