BTW, inside chips it's normal to use the negative edge of a clock, because pulldowns are faster: does anyone know if it makes any difference on an FPGA which clock edge you choose?

With fully static flip flops, don't you need both edges anyway, for the master/slave latch ? Ultimately, it depends on how exactly the FPGA vendor has implemented the negative clock, though. Looking at the Spartan-6 CLB implementation, for example, it appears they have a per-slice clock inverter + mux, and the output goes to the 4 FF clock inputs in that slice. Whether the two mux paths are equally long, I don't know, but we're probably talking < 1 ps difference if there is any.

Since you brought it up...

I recommend positive logic everywhere. That is, do not mix active high and active low signals. Naming conventions notwithstanding, mixed logic conventions is the quickest path into the dungeon.

Therefore, I try to define all of my signals as active high: Wait rather that nRdy (not Ready). This generally means that I apply inverters to active low input/output signals at the topmost level so that within the design all signals are active high.

Thus, posedge Clk, posedge Rst, etc. As Arlet indicated, inverters are available throughout the FPGA fabric. The synthesizer and PAR tools automatically make use of these resources to ensure signal integrity and that the implementation meets the performance requirements you have set via the User Constraints File (ucf). Further, in a RAM-based FPGA (Xilinx and Altera are prime examples), inverters are free in the look-up tables. The tools need only change the 1s into 0s and vice versa in the LUTs.

The specific inverter resources in each CLB/Slice/LE are not meant to be explicitly used from the behavioral synthesis level, but can be accessed at the structural synthesis level. I prefer to operate at the behavioral level rather than the structural level. I generally use structural level synthesis only when accessing specialized, non-inferrable resources like the Digital Clock Managers (DCMs) or similar resources.

_________________
Michael A.

Andrew Gibiansky has some blog posts on building a computer from bottom up.
He first talks about verilog here, and then here he talks us through a minimal CPU design.

Edit: fixup rotted links

Ed:

First, Merry Christmas and happy holidays to all.

In general, a very nice effort to make a subject that is a bit overwhelming for novices much more understandable. However, several misconceptions are perpetuated, but I've already touched on those before in this thread and been rebuffed for emphasizing esoteric, difficult to understand HDL simulator/synthesizer details.

As many are trying to get their feet wet with an HDL, the website that you linked to is as good as any with which to get started. With respect to VHDL and Verilog, the only way to get started is to jump in and get your feet wet. The problems with the misconceptions that are being perpetuated by the author will come later in more complex designs. (Several of the comments posted at the two referenced links refer to some of the issues that I (and Arlet) have written about previously.)

From a SW developer's perspective, the biggest difference between the HW model described by an HDL and SW is that all of the equations described in the always @(), process() blocks, and simple assign statements are operating in parallel. Nothing in the HW model is processed sequentially unless the HDL designer specifically creates special sequential logic, i.e. a state machine, to implement the required sequential processing. Even for loops in Verilog and VHDL do not generate sequential operations; they just generate more HW operating in parallel with the rest of the HW model.

The Verilog and VHDL synthesizers do not generate FFs unless clocked always @() or process() blocks are explicitly included in the source code by the designer. They will, however, generate latches for the output of any logic equation for which the behaviour is incompletely specified. This is particularly true for standalone un-clocked VHDL statements that include conditionals such as if without an else.

As Arlet pointed out in an earlier post, the HDL synthesizers provide warnings in their synthesis reports regarding any automatically inferred latches it inserted into its output. The maxim from SW development -- read the compiler warnings -- applies just as well to HW development with or without HDLs. However, since the inferred latches are very likely to change the intended behavior of the circuit, the maxim -- no inferred latches are allowed -- should be permanently burned into an HDL designer's consciousness.

_________________
Michael A.

Thanks for your comments!
So, if this is bad code should I remove the links? Does it need a health warning?
What simply-stated rules has he broken?
Because verilog is more subtle than it appears, I feel the need for simple rules. Many attempts at introduction go on about the parallelism, which may indeed be a source of confusion to someone with a coding background, but what are the rules to avoid misinterpretation of the intended design?
As an example, one doesn't even need to know about the danger of implying a latch, if one has rules which make that impossible. Break the rules, you're in unknown territory. Don't do that until you have a deeper understanding.
I'm not saying there's no need for a full explanation, I'm saying I think beginners would have an easier time of getting started and getting a working design quickly if they had concise guidance.
Cheers, Ed.

Ed:

Not bad code per se, but not necessarily precise. It has been my personal experience, stemming from a lack of a precise understanding of the subject matter at the time, that there's too much glossing over of the distinction between hardware modeling and hardware implementation. In other words, the HDL hardware designer is left with the task of determining how the HDL synthesizer interprets his source code and generates the desired HW.

It's rather unfortunate that these languages are named Hardware Design Languages. The primary purpose of languages like Verilog and VHDL is as a modeling language for HW. There are many situations in HW development/engineering where a model is more important to the understanding and testing of a design than it is to have the hardware itself. One example of this is when the model developed, without regard for the actual details of the implementation itself, is used to specify the desired behavior that the implementation is to have. Subsequently, this same model can be used as a reference to which the implementation, the RTL implementation, can be compared for the purposes of testing and verification.

We've discussed on this thread Verilog papers from Sunburst Designs and papers by Stuart Sutherland. Mr. Sutherland has been heavily involved in the development of Verilog and SystemVerilog, and provides consulting services for industry on the subject of design and simulation using Verilog. Mr. Sutherland prepared a presentation which is fairly appropos to this discussion. It provides the essential rules for using blocking (=) and non-blocking (<=) assignments for both combinational and sequential logic. Although it is 16 years old, it directly addresses the issue that seems to be driving most designers crazy with regard when to use these assignment operators in the their designs. If you'll peruse the presentation, you'll find justification for the simple rules I provided here at your request.

One thing to keep in mind when reviewing the material provided in that presentation, Mr. Sutherland is presenting the topic from a simulation first perspective. That is, most of his examples represent models of the desired behavior and the discussion of when to use the block (=) and non-blocking (<=) assignment operators is focused on describing desired behavior. On page 26 of the presentation is the coup de gras. On that slide, he poses the question "How many Verilog statements does it take to model an 8 stage pipeline?", and he provides the solution.

In the first example you linked to, he presents the test bench for a simple 2:1 multiplexer. He then proceeds to develop a testbench to test the multiplexer module. In the explanatory text following the testbench, he stated that the three inputs, S, A, and B, were FFs. They are no such things in the simulation testbench. There is much confusion of the two primary Verilog signal types: reg and wire. reg does not refer to FFs. The Verilog reg signal type is simply a signal that can hold a value.

A signal assigned a value in the simulation must be declared as having type reg since the other Verilog signal types can not hold a value. A signal assigned with an always block must be a reg even if the desired behavior is as a combinatorial signal. In the referenced post, I said to use the non-blocking assignment operator within always blocks regardless of whether the signal is a combinational or sequential logic signal. Arlet correctly pointed out that a blocking assignment operator may also be used. In simulation, blocking assignments, with delays, can be used to model the behavior of HW FFs. That statement alone should be enough to drive home the point: reg is a signal that can hold a value and is not a FF. This may seem to be a fine point, but it is important when more complex circuits are desired. It also explains why Verilog is allowed to insert latches when combinational signals are not fully defined. Only simple combinational circuits that can generally be described with the ?: conditional construct that can be used in assign statements. More complicated combinational circuits must be described in always blocks, which require the output variable to be declared as a reg. As a consequence, when the signal is incompletely specified, Verilog can insert a latch to hold its value since the output signal has type reg. The ?: conditional requires that both components be specified (or a syntax error is generated), so it can't generate an inferred latch.

This in an incomplete analogy, but the best I can come up with is that all statements (contained within an always or assign statements) must be considered independent threads of execution. The combinational circuits require no synchronization mechanism. All of the sequential logic statements synchronize once per clock period, and it is for this reason that the number of clocks in a design should be minimized. Otherwise, the problem of thread synchronization that occurs in multi-threaded SW occurs in multi-clock HW (and there is no operating system to fall back on).

Latches are a useful design component, and most FPGAs have an explicit way of specifying latches when they truly needed. Like the SW GOTO, latches can in most cases be designed out. But just like in SW when there are exceptional conditions when a GOTO is required, there are times when explicit latches may be required.

Completely specify all combinational logic to prevent the synthesizer from inferring latches.

I think that I can say with absolute certainty that inferred latches are never allowed is an absolute, no come backs, stone tablets from the mountain type of rule. There won't be any seeking of a deeper understanding. Inferred latches change the behavior of the HW design, and generally cause the specification (simulated behavioral RTL) and the synthesized RTL to not yield the same result.

In general I agree, the rules that I provided are the type of simple concise guidance that is required. However, like SW, designing HW in an HDL still requires some basic knowledge of the subject. The Xilinx ISE lightbulb tool (I'm sure that there exists a similar syntax and code example tool in virtually all FPGA development toolsets) provides extensive code examples in both Verilog and VHDL that I use all the time, and which I recommend to all.

If a background in HW design is lacking, then there is simply going to be some tough times for a period of time. Some concepts can be learned from books and classroom time, but it's been my experience that these methods simply provide a stepping stone or path, and do not provide the experience necessary to be a HW or SW developer.

However, I firmly believe where there's a will to learn, there's a new HW designer. Just like jumping in and using code examples from a working SW application to learn a new SW programming language, I think it is important to jump in and start developing HDL-based HW designs. Forums like this one exist for HDL designs, and there is a lot of help available from forums operated/facilitated by each of the FPGA vendors.

_________________
Michael A.

First, let me correct a freudian slip (error) in my previous post: HDL => Hardware Description Language, not Hardware Design Language.

I wish that Verilog and VHDL were HW design languages instead of HW description languages. The problems many designers encounter with using these languages for HW design is due to the fact that these languages are first and foremost HW description languages. That is, their original intent was to provide digital models of the behavior of devices. The models developed can then be used to specify the desired behavior of a particular device, or they can be used to test the behavior exhibited by a Device-Under-Test (DUT) against an set of response vectors when common stimulus vectors are applied to both the device (using an in-circuit tester) and the device's corresponding HDL model.

If a subset of either of these languages is used in a particular manner, then it is possible to develop the actual design and implementation files for an Integrated Circuit or a programmable logic device like a Complex Programmable Logic Device (CPLD) or a Field Programmable Gate Array (FPGA). Generally, this process is known as writing the "Register Transfer Level" or RTL model of the device.

I think it worth going over the issue of when to use the blocking and non-blocking assignment operators (tokens) that Stuart Sutherland addresses in this presentation. On slide #6, Mr. Sutherland states the following:


He then presents two Verilog code examples and asks why they won't perform the action claimed in the Verilog comment above each example.


First, let me say that the first example above can be synthesized, but the problem arises in simulation. If you plan on using pre-synthesis functional simulation to verify your design, then the issue of using a blocking (=) assignment will cause the pre-synthesis simulation results not to match the post-synthesis simulation or HW test results. Second, the second example is not an example of synthesizable Verilog code. Each Verilog statement in a fork/join block is "concurrently" executed during simulation. (Fork/join blocks can be used to simulate actions to be performed concurrently during simulation. One example of their use would be to concurrently drive the input and outputs of a FIFO to test its behavior when read and write are simultaneously asserted. I have used a fork/join block just once in the years that I've been using exclusively for HW design. There are other uses for fork/join blocks, but I've always found other ways to achieve the desired results.)

Now back to his question. The second behaviour he stated for the blocking assignment is the reason why the code as written won't behave the same pre-synthesis as it does post-synthesis. The first blocking assignment in the block essentially halts the simulator and forces it to assign Word[7:0] to Word[15:8]. The simulator can then proceed to evaluate the next statement in the always @(posedge Clk) block. Since the Right Hand Side (RHS) of the first blocking assignment has already been evaluated and the assignment has been made to its Left Hand Side (LHS), the value of Word[7:0] is unchanged, i.e. Word[7:0] = Word[7:0]. With respect the second example, I stated that Verilog statements in fork/join blocks are concurrently executed. The exception is when the concurrent statements use blocking assignments. Mr. Sutherland's third rule, combined with the second, means that the second example has the same results as the first example.

Now let's move on to slide #7 in the presentation:

To make his point, he simply provided the same two examples discussed above except that the blocking assignments where replaced with non-blocking assignments:


In these two code examples, the use of the non-blocking assignment results in the pre-synthesis simulation matching the post-synthesis simulation. Furthermore, the bytes of Word are indeed swapped as desired. The question is why is this the case. First, the right-hand sides are evaluated immediately. During simulation this means that all of the RHS signals are sampled simultaneously with the occurence of the clock edge, and then assigned to temporary variables appropriately linked to the assignment operator. After all timing statements have been processed, the temporary variables are assigned to the LHS variables. Because of the non-blocking behavior of the RHS evaluations (sample) and assignment to temporary variables (hold), the desired results, i.e. byte swapping, will be loaded into the LHS variables at the completion of the simulation step.

I am pretty sure that everyone will agree that there is no physical structure within a device such as an FPGA that can be said to be represented by the blocking assignment operator. That is, you can not find something in the FPGA that will stop the evaluation of any equations through the look-up tables until the assignment is made either to the combinatorial net/node, or to a FF. Therefore, within the FPGA, the concepts that blocking and non-blocking assignments represent are not present. Within the FPGA, all signals are concurrent and non-blocking.

The confusion arises regarding these operators because of the need of the language to describe behavior that a circuit exhibits. The blocking assignment allows the HW model to describe the sequential behavior of signals within a circuit in a manner that does not require sequential logic. In other words, one use of the blocking assignment is to represent sequential logic without building a state machine. Another use is to represent signal delays as might be expected if the behavior in time of real circuits was needed for testing or for other modeling and specification purposes/reasons.

I restate the simple syntax rules for RTL that are intended to yield the same simulation results pre-synthesis as post-synthesis. Let me say, I use the rules stated below to ensure that my pre-synthesis RTL simulation results will match the post-synthesis simulation results. Further, after spending countless hours verifying that my RTL source synthesizes as expected (after all errors have been removed), I have not run a post-synthesis simulation in years, but I always run a pre-synthesis simulation (and I almost always regret it when I get in a hurry and don't take the time).



As Arlet has recommended, and which I endorse as well, examine the technology schematics that the synthesizers put out to see if the synthesizer is converting your source into circuits as you intend. After a while, the general pattern for each type circuit will become a habit and you won't need to refer to these schematics as often. There a large number of synthesizable code examples provided in the ISE tools for various circuits. Even experienced designers will refer to these RTL code examples from time to time. In particular, I refer to these RTL code examples when inferring particular resources in my code, such as RAMs, latches, etc. Keeping track of the special rules and secret handshakes is for the birds, since these resources are peculiar to each FPGA vendor's components.

Hope this write-up helps establish the rules for using = and/or <= in your Verilog code.

_________________
Michael A.

Hi Michael. Thanks for elaborating, and for stating some simple rules.
If I were a little wiser, I'd feel confident in putting an introductory document online somewhere, and revising it until it meets only criticisms which I feel happy to leave standing.

I feel the situation is a little like trying to define a subset of any language which gives you too much rope: maybe C would be an example. The subset is for those not skilled in the art, who just wish to get on and make something which works. They can then learn more subtleties having got some ability to make progress.

In passing, the style of Verilog (or indeed HDL) expression which I'm used to has some conventions such as
- never use delays
- never use latches
- use as few clocks as possible, preferably one, and if possible only one edge
- stick within a synthesisable subset
- follow some naming conventions, for example for the D and Q sides of each FF
- use agreed conventions for coding conventional things, such as state machines
- fix everything which gives rise to a warning
- understand everything in the log files of each tool you use

This is not to say that delays and latches and multiple clocks have no place, but you can do a lot of useful work without them. (In testbenches which are there only to simulate and not to synthesise one may relax the conventions.)

Thanks for the pointer to the Xilinx example code.

Cheers
Ed

That's a good start, but I'm feeling a bit contrarian today in a friendly sort of way.

This may be stated better as: never use delays in synthesizable code except after spending several hours debugging perfectly valid synthesizable code because the simulator is confused by all of the signals which are changing state at the same time, and you can't afford the $40k version which is supposedly better but will have the same problem except that it will happen when there are more signals to dig through because it doesn't have the same code simulation limits as your "free" simulator. (There, that run-on sentence proves I'm from the US south just like Faulkner, except that I'll get an F and he'll get a prize and a statue.)

Except when interfacing to processor like the 65816 or 8051 which uses address latch enable signals to demultiplex address and data from the same bus lines, and you like trying to figure out why the processor has decided to follow Peter Pan off to Never-Never land because you insist the all interfaces must be synchronous regardless of how they are truly implemented.

Sorry, I can't say anything snide about these, and the bit about using the synthesizable subset is actually very good. It's exactly how I learned what is and is not synthesizable. I forced myself to write both the code to be synthesized into the FPGA and much of my early testbenches as RTL. However, testbenches almost always have to deviate from synthesizable subset, but those features can be learned after you have achieved a level of comfort with the synthesizable subset.

Yes and no. Naming conventions have a tendency to go off the rails. I tend to use Polish? notation like that introduced with VisualC many years ago. Meaning I use a lower case n for active low inputs or outputs, and a lower case p to signify parameters. Other than that, I find that most conventions tend to increase the size of the variables. Clear comments supplied when the signal is declaration are better than increasing the length of the name so that the source code goes off the displayable region or forces a break into multiple lines. I use multiple lines to define an equation when that improves the readability of the code. But, in general, single line equations are easier to read and understand.

Some very knowledgeable people actually recommend this approach for the implementation of sequential circuits and state machines. I imagine that even the synthesizer providers have chosen this approach so that the tool can "recognize" a state machine and apply optimizations to it. I recommend strongly against this approach. A missing else or default case is the quickest way to generate an inferred latch in the combinational state transition equations. If the state transition equations and the FFs of the state machine are within the same clocked always block, then either state machine works in pre-synthesis and post-synthesis or it does not, and latches cannot be inferred; the state machine may incorrectly stay in the same state, but no latches are inferred.
Finally, although intrigued by the efficiency of one-hot encoded state machines, I would stay away from them. If two states become simultaneously active, how is that detected in order to recover the state machine. How do you test a that a 32 state one-hot encoded state machine is not in incorrect configuration. It's true that a one-hot state machine is ideal for FPGA implementations, and they generally yield the fastest state machines.

Instead, I recommend: read and understand all warnings. I always use a #1 for my sequential logic. The synthesis tools always flag that as warning because its not synthesizable, but I won't pull it from the source as you should be able to tell from the rant above. Further, FPGA tools generally trim unused circuitry unless you take explicit care to prevent them from doing so. Some warnings are warnings that the tool has optimized a circuit, and that will result in certain logic being trimmed. I don't recommend editing perfectly good source to remove a warning because you've decided only to use one port of a Verilog 6522 instead of the two you built into the module; the chance for introducing an error is too high, and the tools will only trim the unused portions of the module.

_________________
Michael A.

I wouldn't worry too much about one-hot encoded state machines for hobby work like most of us would be doing here. In case the FPGA gets struck by a cosmic ray, and the state machine ends up in a bad state, it's usually not a big deal to hit the reset.

Yeah, one needs radiation hardened die to avoid that possibility!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Slightly OT

Hungarian. Polish notation would be RPN

_________________
Practice safe HEX !

I realize I have been pretty much blindly experimenting with Verilog in the recent past, primarily with the syntax rules, expecting success to pop out of the ether.

In all my previous experience in hardware design, I've always drawn a schematic, based on the IC's to be used in the design. Now I'm talking over 20 years ago, so individual TTL IC's are all I remember at this point. Especially, some 8 bit wide IC's I remember off the top are the '244, '245, '373, '374.

I think that one of my flaws in my transition to learning Verilog is that not only do I not have a block diagram, but also I don't even have an overall schematic.

I'm sure a schematic must be needed for the Verilog beginner, or at least a block diagram with some critical signals, so one can 'translate' it into code.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I think a block diagram can indeed be helpful - one which shows the clock boundaries especially so. http://asciiflow.com is a possible tool to help here - ascii diagrams can be embedded in comment blocks. Note that MichaelM has put some impressive docs into the wiki pages of his github project for the MAM65C02 core: https://github.com/MorrisMA/MAM65C02-Pr ... chitecture

Cheers
Ed

Edit: updated link