
Rules for new FPGA designers - jsnell
http://zipcpu.com/blog/2017/08/21/rules-for-newbies.html
======
adwn
> _Do not use an asynchronous reset within your design._

This is flat out wrong. Registers that drive output pins should _always_ be
reset asynchronously. If you're not careful with your board design, it can
happen that your FPGA is powered and configured before your clock signal is
available, especially if it is generated by a PLL. An asynchronous reset on
the output IO registers ensures that you're not inadvertently driving external
electronics with bogus signals.

For internal registers it usually doesn't matter whether they're reset
synchronously or asynchronously. There are some cases where the synthesis
software cannot move async. reset registers from flip-flops into built-in hard
IP cores like DSP elements or block RAMs, so a sync. reset can make sense here
for performance reasons.

There's one caveat, though: An async. reset signal _must_ be released
synchronously to the clock, or there _will_ be timing errors. However, this is
a tiny, simple construct easily written by any non-beginner.

(source: I design FPGAs for a living)

~~~
tastythrowaway
what did you study/how did you learn to design FPGAs? I had an early intro to
verilog in school but it all seemed so opaque to me. Do you think it's
possible for people to teach themselves? Thanks.

~~~
fpgaminer
I taught myself and now design FPGAs for a living as well. Had 1 class in
college that, like your experience, was totally opaque. But it sparked my
curiosity.

Not sure I can advise exactly _how_; I'm usually strong at self learning. Just
letting you know it's possible. Personally I'd start with IntelFPGA (formerly
Altera) products; I found them easier to use.

~~~
gchadwick
Personally I taught myself with the aid of an Altera DE2 board (I had a
professor at university who was kind enough to lend me one of the class ones
on an extended loan).

The DE series still exists and has a wide range:
[http://www.terasic.com.tw/cgi-
bin/page/archive.pl?Language=E...](http://www.terasic.com.tw/cgi-
bin/page/archive.pl?Language=English&CategoryNo=163#Category165)

The DE0 Nano is pretty cheap: [https://www.digikey.co.uk/product-
detail/en/terasic-inc/P008...](https://www.digikey.co.uk/product-
detail/en/terasic-inc/P0082/P0082-ND/2625112) the more capable DE10 Nano looks
interesting too: [https://www.digikey.co.uk/product-detail/en/terasic-
inc/P049...](https://www.digikey.co.uk/product-detail/en/terasic-
inc/P0496/P0496-ND/6817231) only slightly more expensive.

They provide a good plug and play solution. Program over USB, software
available free from Altera (Ages ago Mentor used to do a free version of
ModelSim in conjunction with Altera, something similar is probably still
around).

You can also just grab Icarus Verilog
([http://iverilog.icarus.com/](http://iverilog.icarus.com/)) it's an open
source verilog simulator. Will allow you to get to grips with verilog without
needing the hardware. The main problem is you may start building designs that
simply cannot be built in hardware (plenty of ways to build stupid circuits in
verilog).

There are few resources on the internet (comparing to what's available for
learning programming). Maybe try 'Digital Design and Computer Architecture' by
David Money Harris & Sarah L. Harris.

~~~
mattcoles
I wouldn't recommend Icarus Verilog, it's not a very good simulator. You're
much better off downloading either the free Altera/IntelFPGA copy of Modelsim
or using the free version of Xilinx's Vivado.

The DE10 Nano is a great board though, huge FPGA that can hold big designs and
the HPS gives you a lot of extra capabilities.

~~~
gchadwick
> I wouldn't recommend Icarus Verilog, it's not a very good simulator.

Haven't really used it much myself but fair enough :) I suspect many people on
HN would be more comfortable with free opensource tools. Which is why I
mention it.

The majority of the EDA world is proprietary software and huge licensing fees,
free limited versions available for home/educational use if you're lucky. A
bit of a culture shock for someone used to the software world!

~~~
Cyph0n
And the proprietary stuff is better 99% of the time.

------
jhallenworld
Here are some more rules I like to use:

Use I/O flip flops: the external world should be separated from the internal
world via one pipeline stage, and that stage should be in the I/O cells. This
is not always easy to pull off (Xilinx, ugh), but when you do it you will get
consistent I/O timing from run to run, and basically not have to worry about
it once it's working. It's less error-prone than trying to have accurate
external timing constraints. This is really for older (board-level)
synchronous designs.

Often the FPGA and board designs are happening at the same time. Get a
skeleton design working before the board design is complete. This design
should include all I/O, clocks and resets. There can be many non-obvious
constraints involving these things, so you better have them right before the
board design is done or you are in for a world of hurt.

Along the same lines: take baby steps during the design (get blinking LEDs and
some kind of software accessible register interface running first).

Oh a big one: use version control. Unfortunately the tools (Xilinx) do not
make this easy, but it is really essential. You would be surprised at how
often this is not done.

------
jhallenworld
>Do not use an asynchronous reset within your design

It's not bad advice for new designers, but also be aware of the consequences:
you might have a performance penalty from this if your FPGA's flip flops do
not have direct synchronous resets. Also if your design might have to be
ported to an ASIC you might have the same issue.

Better is to use the "asynchronous assert, synchronous release" reset and
learn about recovery and removal timing closure.

In the past I've also designed with no timing requirements on reset, but start
out all state machines doing nothing, and have a (synchronous) start pulse or
edge to get things going. This can allow you to use the already existing slow
global reset net. It mattered on older FPGAs with limited routing resources.

~~~
kevin_thibedeau
> Better is to use the "asynchronous assert, synchronous release" reset

Also put that synchronized async. reset onto a clock buffer if your synthesis
tool isn't inferring one since it will be a high fanout net. For an FPGA
target you lose most of the benefits from synchronizing it if you let the
reset be delayed by running over the normal routing fabric. For an ASIC you're
going to have to buffer it no matter what.

A common problem is that most FPGA dev. boards don't have any provision for an
external reset and student's never learn the discipline of properly
initializing their circuits. Xilinx takes an official stance against global
resets [1] which I feel does untold damage to impressionable developers.
Thankfully they do have the ROC library component that will simulate a reset
after completion of configuration. Use this or your platform's equivalent if
you don't have access to an external reset.

[1]
[https://www.xilinx.com/support/documentation/white_papers/wp...](https://www.xilinx.com/support/documentation/white_papers/wp272.pdf)

------
mikejmoffitt
> Do not transition on any negative (falling) edges. > Falling edge clocks
> should be considered a violation of the one clock principle, as they act
> like separate clocks.

I think this is a good thing to point out if you are working in a primarily
rising-edge system, which is common, but if your _entire design_ uses falling
edges for one reason or another, I don't see the problem.

I have had to transition a design to falling edge when I needed interop with
existing external hardware that operated on the falling edge. Rather than
invert my clock, using the falling edge was fine.

------
tsayin
Resets NEED to be asynchronous assertion, what if the clock distribution logic
is messed up, or just isn't running yet on power-up? De-assertion does need to
be synchronized, though. Method is left as an exercise for the reader.

Also, aside from the latency added, dual-flop synchronizers are pretty good
probabilistically for uniformly distributed single-bit random events, but they
aren't guaranteed. For mesochronous signals they can actually make things
worse, and for periodic signals or buses, there are much better methods.

But those issues usually come up in advanced designs with high-speed data
inputs (PCIe or Ethernet) or other reasons to NEED multiple clocks. For
beginners, the important thing to remember is that resets assert
asynchronously and de-assert synchronously.

------
peterburkimsher
Great advice, and clear writing style.

Story time! During my 2nd year of university, I built a small CPU as a
project. It was split across 2 breadboards, using an FPGA for the control
unit.

It worked fine during debugging, but sometimes it would give really weird
problems. Then when we tried to debug again, it was fixed. What was going on?

We'd forgotten to connect a common GND between the breadboards. When we
attached the probes to debug it, the ground was passed via the USB port on the
PC.

~~~
jacquesm
In low power circuits forgotten ground is annoying but that's about it. In
power circuits it can cause spectacular and expensive side effects.

~~~
msds
And with RF, well, things get really weird really fast...

~~~
williamscales
In my undergraduate I worked in a lab where we made very sensitive voltage
measurements on a large apparatus. The experiment was grounded to a large
copper bar buried under the floor but the measurement equipment was connected
to the building ground thereby creating a gigantic loop that could pick up all
kinds of crazy noise. The solution was to break the (literal) ground loop with
a buffer amplifier.

------
chillingeffect
Literally the same rules I was taught on day 1 of my engineering co-op 23
years ago.

We also added, "no external capacitors can be used for timing," because people
would try to fix things that way.

------
FullyFunctional
Good list for starters, but obviously the reset question has nuances (not
opening that can of worms).

One thing that bit me when I was a complete n00b: assigning registers from
within more than a single always block. On my simulator (at the time) it
worked perfectly but the synthesis tool silently ignored one of the blocks.

EDA tools suck. There I said it. Coming from a software it's truly shocking
how poor error/warnings are handled. My "favorite" part is that you cannot
enforce a "0 warnings" discipline as the libraries and examples from the
vendors provoke thousands warnings and the only workaround is to filter the
individual _instances_ of the messages.

~~~
gluggymug
"One thing that bit me when I was a complete n00b: assigning registers from
within more than a single always block. On my simulator (at the time) it
worked perfectly but the synthesis tool silently ignored one of the blocks."

It's tool dependent but I believe you should see a warning that two drivers
are assigned to the same net.

This is probably where I am guessing you mistakenly thought you were creating
a register in Verilog with the keyword "reg". Synthesis tools don't work like
that and haven't for quite a while.

Taken from
[https://blogs.mentor.com/verificationhorizons/blog/2013/05/0...](https://blogs.mentor.com/verificationhorizons/blog/2013/05/03/wire-
vs-reg/) :

"Initially, Verilog used the keyword reg to declare variables representing
sequential hardware registers. Eventually, synthesis tools began to use reg to
represent both sequential and combinational hardware as shown above and the
Verilog documentation was changed to say that reg is just what is used to
declare a variable. SystemVerilog renamed reg to logic to avoid confusion with
a register – it is just a data type (specifically reg is a 1-bit, 4-state data
type). However people get confused because of all the old material that refers
to reg."

A lot of people here on HN seem to be self taught and not keeping up with tool
and language developments. If you use tools and techniques from the 90s, don't
expect wonderful results.

------
DigitalJack
They mostly seem reasonable to me. I'm not sure exactly what they mean by
_external wire inputs_ in this statement: "Synchronize all external wire
inputs with two clocks before using them."

You can ruin a design by trying to synchronize data. We've had to respin an
ASIC because somebody "synchronized" the data on a bus.

~~~
DigitalJack
And to clarify further, they mean two flip flops in series, not two clocks.

It sort of becomes a short hand to refer to the delay incurred by flip flops
in series as "clocks" (short for clock cycles). And to capture data in a flip
flop is often referred to as "clocking" the data.

~~~
zipcpu
Thank you for that comment. I've adjusted the text so that it's hopefully
clearer!

Dan

------
senatorobama
Unfortunately, FPGA designers don't get the big bucks anymore.

------
nayuki
There is a wrong link to [http://asic-world/verilog/veritut.html](http://asic-
world/verilog/veritut.html) . It seems Firefox automatically fixes it to
[http://www.asic-world.com/verilog/veritut.html](http://www.asic-
world.com/verilog/veritut.html) . Does anybody else find this behavior
surprising?

------
tuckermi
On the topic of good practices for FPGA design, does anyone have a
recommendation for an online course that covers this or similar material?

~~~
duskwuff
Not an online course, but my go-to recommendation is "FPGA Prototyping by
Verilog Examples" [1]. Or, if you want to learn VHDL, [2].

[1]:
[https://www.amazon.com/dp/0470185325](https://www.amazon.com/dp/0470185325)

[2]:
[https://www.amazon.com/dp/0470185317](https://www.amazon.com/dp/0470185317)

~~~
planteen
The old edition of the VHDL book had dated coding practices that are no longer
necessary like splitting out comb and sequential logic. Is it still like that?

~~~
skummetmaelk
Not necessary, but still easier to read in most cases.

------
Cerium
Nice list. I wish I had something like this as a student. I made all those
mistakes and had to learn them the hard way.

------
skdjksjdksjdk
What is the best resource for understanding how to create FPGA constraints?
Any good resource for floor planning ?

~~~
jhallenworld
IMHO, If you have to floor plan, you're doing it wrong.

You should try to design FPGAs so that they work like software, in that you
should be able to run the tools consistently like you would software through a
C compiler and not have difficulty with failed timing. If you had to do floor
planning to close timing, you are giving up a huge advantage.

~~~
fpgaminer
That's good in theory, but ... it's not realistic. The compilers are too
unstable. I lost a couple days of my life last year because Quartus forgot how
to route its multipliers.

But usually you only have to floor plan if you're near the limits of your
target FPGA, or if you're using some of its special IP (like say pinning some
of DRAMs or PLLs).

~~~
pheon
Yup or your design is just large. Due to the non-deterministic nature of the
compiler guiding it at a high level makes it less likely to choose resources
in weird locations. e.g. I roughly map out block ram assignments for some of
the top level modules but still give it plenty of wiggle space.

~~~
esmi
Not only that but you don’t want to have to redo analysis and verification on
blocks that have been already mapped, placed and routed. Especially as one
does minor bug fixes towards the end of a design. It’s like refusing to use
libraries.

------
aphextron
How does one go about learning IC design to begin with? I only have the
vaguest notion of what all these terms mean to begin with. Is it analogous to
teaching yourself to code, or is it fundamentally different/harder?

~~~
esmi
It’s very different if you do it right but not really harder. The first thing
you learn is digital logic design at an abstract level. Something like this:
[https://www.csie.ntu.edu.tw/~pjcheng/course/asm2008/asm_ch2_...](https://www.csie.ntu.edu.tw/~pjcheng/course/asm2008/asm_ch2_dl.pdf)
Then once you can make digital designs you learn to describe them in a
hardware description language (HDL) such as Verilog. When reviewing verilog
designs it’s very easy to spot the “verilog coders” vs the hardware designers.

------
cushychicken
No falling edge clocks? Good luck writing a proper SPI peripheral.

~~~
pjc50
For doing SPI within an FPGA under these rules, you would have the input clock
as a signal sampled by the FPGA clock _not_ used as a flop clock, and detect a
falling edge synchronously with a chain of two flops.

Works very well so long as master clock speed >> SPI speed.

~~~
wyager
True, but many slow uCs support system clock == SPI clock. Probably not as
relevant these days with 99% of stuff happening on 32-bit devices with clocks
so fast you would need RF experience to route SPI at system clock.

------
blackguardx
Good list. I've seen use of both synchronous and asynchronous resets. People
have some good arguments for both methods sort of like the tabs vs spaces
arguments.

~~~
gluggymug
The problem is that reset logic requires a bit of design rather than hard fast
rules.

Designs are getting larger these days with a lot of 3rd party IP that you
can't assume use a particular reset method.

Tips #2 and #5 in this article,
[http://www.eetimes.com/document.asp?doc_id=1278998](http://www.eetimes.com/document.asp?doc_id=1278998)
, explain how you have to tailor your reset methods to the modules you are
integrating.

If you don't, you chew up resources.

A new FPGA designer should learn the first principles so they can understand
how to make decisions and where to look for potential issues when bugs occur.

------
wyager
A bit late to the party, but my advice: unlesss your goal is to learn high-
performance design, try to save yourself a _lot_ of effort by using a higher-
level HDL. Depending on how cool your professor is and what their pedagogical
goals are, they'll be fine with it. Using something like CLaSH will statically
prevent you from doing a lot of hardware stuff that's non-synthesizable,
flammable, or just plain dumb. You can do a lot of things in standard HDLs
that just don't make any sense, and a lot of students get confused and do
them. Not only will something like CLaSH or Chisel prevent you from doing dumb
things, but they will get you in the mindset of doing things correctly.

~~~
lvoudour
I don't agree teaching students experimental high-level languages in lieu of
proven industry standards just because those standards are archaic and/or un-
intuitive. It's a great academic endeavor but the FPGA (and ASIC) landscape is
driven by industry not by academia.

If you're aiming for an FPGA job after school you'll need to be proficient in
verilog or vhdl (ideally both), there's no shortcut. The sooner you learn how
to deal with their quirks and pitfalls (I agree they have a lot), the better.
Sprinkle some good-ol' TCL in there and you're good to go. Yes python is
better and more feature/library rich but the industry is still using TCL
(which is not bad, just not modern).

Don't get me wrong, I'd like to see a standardized higher level approach to
hardware description, but unless the vendors agree and support it there's very
little chance it will be useful. The current trend in high level synthesis is
non-portable vendor specific tools. The only way I see the trend changing is
when FPGAs become more mainstream (already happening in the server/deep
learning sectors) and there's a critical mass of customers that ask for FPGA
tools in par with software tools (ie. high level languages, open source, etc.)

PS. You forgot the python based myHDL :)

~~~
gluggymug
It's the _experimental_ part of the high level language that is the problem. I
agree you shouldn't teach it to students. It just leads them down a divergent
path away from what is done in industry. It isn't addressing the needs of the
student, only their short term "wants".

But the language is just a small part of the design process. You have to be
learn to design HW. The HW engineering project tailors the tool choices around
the requirements of the product. It is assumed that engineers know the
fundamentals. They can adapt to any high level synthesis tool.

Vendors training courses for all fancy HLS tools are done in a few days at
most. They don't have a semester for any newbies to learn Verilog/VHDL or
C/C++ first. It's assumed you know them.

