Basic question: sequence of execution within FPGAs

Trying to get my head around FPGAs after 40 years of 2GLs. I can't
seem to find a clear exposition of the following, would appreciate if
someone could confirm or clarify the following assumption:

I have the following Verilog code say:

always @ (posedge clk)
begin
do 1
do 2
do 3
end

assign outA = wireA & wireB
assign outB = wireC & wireD

always @ (posedgeclk)
begin
do 4
do 5
end


Is the following correct?

1, 2 and 3 are done (more or less) in a sequential manner, ie. the
result of 1 will be present when 2 is performed. Hence, statement
order is important here.

4 and 5 will be done using their own gate resources, clocked "more or
less" in parallel with 1,2,3. However, presumably assuming any sort of
time alignment between the results of the two always blocks would be
risky at best (explicit synchronisation required).

For the assign statements, does clocking pay a part, or do these
statements simply run at gate delay speed? Or is the answer
device-dependent?

 

[mnentwig]

Hi,

you may want to get a modern textbook on synchronous logic. With FPGAs, th
design needs to follow a certain pattern, or things get much more difficul
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 las
assignment holds.

Here is an example for later statements overruling earlier ones. This isn'
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 <= i_addr;
db_dataWA <= i_data;
db_weA <= i_we;
o_ack <= 1'b1;

assigns input from an external bus source (i_addr, i_data, i_we) t
registers that access a memory internal to this subsystem.

Later during the same block, when moon and stars are in the righ
constellation, the unit decides to do its own memory access during the sam
cycle, and executes this:

if (... certain conditions apply)
// reads from data memory
db_addrA <= addr;
// take priority over any external memory access attempt
db_weA <= 1'b0;
o_ack <= 1'b0;

What happens is that any earlier assignment is overruled: A differen
address is set, different data, and the write_enable flag is changed a
needed. In this example, "o_ack" gets cleared to tell the outside worl
"your bus access attempt was ignored - try again"



---------------------------------------
Posted through http://www.FPGARelated.com

 

[Allan Herriman]

On Fri, 08 Aug 2014 17:38:23 +0800, Bruce Varley wrote:

Trying to get my head around FPGAs after 40 years of 2GLs. I can't seem
to find a clear exposition of the following, would appreciate if someone
could confirm or clarify the following assumption:

I have the following Verilog code say:

always @ (posedge clk)
begin do 1 do 2 do 3 end

assign outA = wireA & wireB assign outB = wireC & wireD

always @ (posedgeclk)
begin do 4 do 5 end


Is the following correct?

1, 2 and 3 are done (more or less) in a sequential manner, ie. the
result of 1 will be present when 2 is performed. Hence, statement order
is important here.

No. Presumably 1, 2 and 3 involve non-blocking assignments (i.e. using
<= ) to regs and the statement order isn't important.

I assume your code looks something like this:

always @(posedge clk)
begin
reg1 <= (some logic);
reg2 <= (some logic);
reg3 <= (some logic);
end


Most coding guides will tell you to only using non-blocking assignments
inside a clocked "always block".

*Very* roughly, these work in simulation by not updating the destination
reg until all the statements have been executed in all the always blocks
sensitive to that clock edge.
That simulation behaviour matches flip flop functionality in hardware.

Note that the following two code fragments are equivalent, both in terms
of simulation behaviour and the hardware described, despite one having
the statements in reverse order:

always @(posedge clk)
begin
reg1 <= (some logic);
reg2 <= reg1;
reg3 <= reg2;
end

always @(posedge clk)
begin
reg3 <= reg2;
reg2 <= reg1;
reg1 <= (some logic);
end

At each clock,
reg1 gets the value of (some logic) from before the clock edge.
reg2 gets the value of reg1 from before the clock edge.
reg3 gets the value of reg2 from before the clock edge.

[Switch to fixed point font for the ASCII art]

Here are the three flip flops inferred by those code fragments:

clk--------+------------+------------+
| | |
+-----+ +-----+ +-----+
| C | | C | | C |
some | | reg1 | | reg2 | | reg3
logic-->|D Q|----->|D Q|----->|D Q|---->
| | | | | |
| | | | | |
+-----+ +-----+ +-----+


Blocking assignments (using = ) to regs behave roughly like software
variables and you can have races between always statements. Don't do
that, even though it will seem more familiar to you with your software
background. You aren't writing software - you are modelling hardware
using a hardware description language (HDL). Make sure you think in
terms of hardware, not software.

4 and 5 will be done using their own gate resources, clocked "more or
less" in parallel with 1,2,3.

No. Assuming you have used non-blocking statements, 1, 2, 3, 4 and 5 all
infer flip flops clocked by the same clock signal. Logic resources will
be allocated / shared / replicated / optimised at the synthesiser's whim
and this is not necessarily influenced by grouping (or even hierarchy) in
your source code, unless you have explicitly told the synthesiser not to
share (perhaps with an attribute).

You should group them so that it makes the code easier to understand and
maintain.

However, presumably assuming any sort of
time alignment between the results of the two always blocks would be
risky at best (explicit synchronisation required).

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

For the assign statements, does clocking pay a part, or do these
statements simply run at gate delay speed? Or is the answer
device-dependent?

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.

[I apologise if some of my descriptions don't use the correct terminology
wrt the Verilog LRM. I'm just trying to explain the gist of the thing.]

Allan

 

[Tim Wescott]

On Fri, 08 Aug 2014 17:38:23 +0800, Bruce Varley wrote:

Trying to get my head around FPGAs after 40 years of 2GLs. I can't seem
to find a clear exposition of the following, would appreciate if someone
could confirm or clarify the following assumption:

I have the following Verilog code say:

always @ (posedge clk)
begin do 1 do 2 do 3 end

assign outA = wireA & wireB assign outB = wireC & wireD

always @ (posedgeclk)
begin do 4 do 5 end


Is the following correct?

1, 2 and 3 are done (more or less) in a sequential manner, ie. the
result of 1 will be present when 2 is performed. Hence, statement order
is important here.

4 and 5 will be done using their own gate resources, clocked "more or
less" in parallel with 1,2,3. However, presumably assuming any sort of
time alignment between the results of the two always blocks would be
risky at best (explicit synchronisation required).

For the assign statements, does clocking pay a part, or do these
statements simply run at gate delay speed? Or is the answer
device-dependent?

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.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

 

On Fri, 08 Aug 2014 17:38:23 +0800, Bruce Varley wrote:

Trying to get my head around FPGAs after 40 years of 2GLs. I can't
seem to find a clear exposition of the following, would appreciate if
someone could confirm or clarify the following assumption:

I have the following Verilog code say:

always @ (posedge clk)
begin
do 1
do 2
do 3
end

assign outA = wireA & wireB
assign outB = wireC & wireD

always @ (posedgeclk)
begin
do 4
do 5
end


Is the following correct?

1, 2 and 3 are done (more or less) in a sequential manner, ie. the
result of 1 will be present when 2 is performed. Hence, statement
order is important here.

4 and 5 will be done using their own gate resources, clocked "more or
less" in parallel with 1,2,3. However, presumably assuming any sort of
time alignment between the results of the two always blocks would be
risky at best (explicit synchronisation required).

For the assign statements, does clocking pay a part, or do these
statements simply run at gate delay speed? Or is the answer
device-dependent?

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

 

[glen herrmannsfeldt]

Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote:

(snip)

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?

(snip)

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.

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

 

[rickman]

On 8/8/2014 12:09 PM, Tim Wescott wrote:

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.

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?

--

Rick

 

[Tim Wescott]

On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote:

On 8/8/2014 12:09 PM, Tim Wescott wrote:

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.

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.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[rickman]

On 8/10/2014 3:19 PM, Tim Wescott wrote:

On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote:

On 8/8/2014 12:09 PM, Tim Wescott wrote:

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.

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?

....snip...

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.

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.

--

Rick

 

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 mistakes FAR more often than I have made HW design mistakes (in other words, the circuit 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 performance or utilization where I need it, but those are few and far between. Too far to code that way all the time.

Learn what behaviors infer latches (bad), registers and ram (good). Study the synthesis tool's examples for ram inference, but learn their behavior, not 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 behavior and clock cycles of latency, rather than gates and registers. The latter will go to pot as soon as you turn on retiming and pipelining optimizations anyway.

Andy

 

[Christopher Felton]

On 8/10/2014 3:33 PM, rickman wrote:

On 8/10/2014 3:19 PM, Tim Wescott wrote:
On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote:

On 8/8/2014 12:09 PM, Tim Wescott wrote:

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.

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?

...snip...

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.

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.

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

Regards,
Chris