Basic question: sequence of execution within FPGAs

Hi,

you may want to get a modern textbook on synchronous logic. With FPGAs, the design needs to follow a certain pattern, or things get much more difficult than they need to be.

In Verilog, don't think of a sequence of statements as ordered in time. Everything happens concurrently. Sometimes the order of statements sets a priority, in a sense that the last assignment holds.

Here is an example for later statements overruling earlier ones. This isn't directly related to your example, maybe it is useful, maybe not. The code works on a Spartan 6 at 100 MHz.

This...

always @(posedge i_clk) begin //***************************************************************** // default: external bus access, confirmed by o_ack //***************************************************************** db_addrA

No. Presumably 1, 2 and 3 involve non-blocking assignments (i.e. using However, presumably assuming any sort of

Again, if using non-blocking assignments, you can ignore execution order.

They describe combinatorial logic. No clock is involved. In hardware, two AND gates are generated. The actual delay you get will be determined by ... well, it's probably more determined by the routing than the actual gates (which are pretty fast in contemporary devices). You can control the delay by applying timing constraints in the tools. In most cases you won't do this as the output of the combinatorial logic is simply feeding another flip flop, and the timing constraint you gave for the minimum clock period takes care of all paths (including the combinatorial logic) between flip flops clocked by that clock.

I hope this helps.

Allan

Hey Bruce:

This is just a supplement to what Allan and Mark have said:

You are NOT writing software. The reason it's called a hardware description language is because it does just that -- it describes the structure of some hardware. It's up to you to make sure that the structure thus described behaves the way you want it to.

This isn't easy for a seasoned software engineer to wrap their heads around -- I have trouble with it whenever I go visiting FPGA-land, in spite of the fact that I have no such trouble when I'm designing analog circuits with schematics.

I agree with Allan's recommendation -- get a book on logic design with Verilog. A good book will devote at least half of the content to language-independent issues, essentially telling you what you want to get. The rest of the content will go into the differences between simulation and synthesis, how to write the code for synthesis, and how to structure your test bench to properly test the code that'll actually make an FPGA.

Well, I have some work (and some backtracking) to do. Many thanks for the good info, folks.

Most of my HDL background is with VHDL and I have only used Verilog when required. I have asked a number of times about a good Verilog reference and been repeatedly told there aren't any. Has that changed? Do you have one you like?

I'm not really qualified to answer that. By training I'm a designer of analog circuits, control systems, and low-level communications algorithms (i.e., detecting bits). By experience I'm all of those, but my actual customer deliverables have been primarily lines of C or C++ code; a GOOD project is one where I'm backing that up with control or comms design.

I have done exactly one small job each with Verilog and VHDL, and the comment I got back from the (real) digital guys on my VHDL code was "you're a software guy, aren't you?" (well, no -- I'm an analog circuit designer who puts food on the table by writing C++ code, but I certainly LOOK like a software guy when the light is shining from a certain direction).

The books that I have are "The Verilog Hardware Description Language" by Thomas & Moorby, and the IEEE Verilog Standard. Thomas & Moorby was selected because, out of the three books on the shelf at Powell's Technical Books that day in 2003, it was the one that seemed to be the most clear and informative.

...snip...

The most important thing I would want from a Verilog book wasn't mentioned in your list of features of a good Verilog book, a description of the pitfalls of the Verilog language. The issues you cover are all language independent in my opinion. I once asked specifically about finding a book to cover the pitfalls and was told that none existed. I asked again a year or two ago and was told the same thing.

Unfortunately I have become very accustomed to writing VHDL and have lost any strong desire to become as proficient in Verilog. If "the" book becomes available I might buy it and finish my education, but I'm not expecting that to happen.

(snip)

(snip)

Yes, and I would recommend it, too. You want a nice reference that you can look something up in when you need to.

Some will probably complain that it isn't up to date with the newer standards, but most of the time that isn't a problem.

I like writing structural verilog, using continuous assignment and module references, except that registers are in behavioral verilog. I put the registers into a module, and just reference that when I need one. (Like reg8 for an 8 bit register.)

Some people like behavioral verilog, as it is more similar to writing software, but to me that distracts from the fact that it isn't software. Like analog circuits and digital logic, you have to remember that everything happens all the time, not sequentially like in C. If you think sequentially, you will write poor and inefficient verilog (or VHDL).

For those who grew up in the days of TTL (or MSI CMOS), thinking about wiring up gates, I believe it is fairly easy to learn to think in verilog. Think about wires and gates. (And it shouldn't be so hard for analog designers.)

But people used to thinking sequentially, like writing a C program, will have a harder time.

Now, consider the design of a digital clock. Years ago, you would wire up some 7490 and 7492 counters, some 7447 (or maybe 7441) decoders, and let them count away. A little more recently, it might be done with a microprocessor or microcontroller, probably multiplexing the display. (That is, for those that don't use an LSI clock chip.)

In the case of a digital clock, you don't need anywhere near the 10's of MHz that TTL can run at, and there is plenty of time to update the display in a software loop. Both make inefficent use of the available hardware resources, but that is fine.

-- glen

It is crucial to understand how synthesis works, but it is not necessary to code a netlist of the HW you think will do what you want.

In 20+ years of VHDL-based FPGA development, I have made behavioral mistake s FAR more often than I have made HW design mistakes (in other words, the c ircuit was viable and reliable, it just didn't do what I wanted it to).

Writing the code such that the clock cycle behavior is at least as apparent , if not moreso, than the HW circuit helps avoid the most common mistakes.

Sure, there are cases where I have to code "closer to the HW" to get perfor mance or utilization where I need it, but those are few and far between. To o far to code that way all the time.

Learn what behaviors infer latches (bad), registers and ram (good). Study t he synthesis tool's examples for ram inference, but learn their behavior, n ot so much about how they happened to code that behavior. This will let you write portable code that will work for multiple target FPGAs.

Describe the desired behavior on every clock cycle. Think in terms of behav ior and clock cycles of latency, rather than gates and registers. The latte r will go to pot as soon as you turn on retiming and pipelining optimizatio ns anyway.

Andy

A decent reference for this is Sutherland and Mills "Verilog and SystemVerilog Gotchas".

Regards, Chris