Rules for new FPGA designers
zipcpu.com
zipcpu.com
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)
Hackish but it worked very well.
The root cause of the complexity was that the system contained way too many circuits that could be powered up/down independently, some of those under end user control and that there was no easy way for me to reliably sequence power so the only place where any difference could be made was the end stage ignoring everything in between.
Connected to the end stage were some pretty powerful servos and inputs to inverters driving large AC motors so keeping things 'off' until the time was right was rather crucial to the safe operation of the machinery.
As far as I know these systems never failed to reliably power up in production even with 1000's of systems sold and used by three shifts daily.
The few FPGA projects I completed all had async reset released synchronously. This wasn't taught to me, I was just so paranoid of making a crap device that I wanted to be sure, and it was the only scheme I could come up with. It always ended up being a fairly significant part of the routing, considering what it was doing.
I mean initial value like this in Verilog:
reg output_reg = 1'd1;
There are two ways in which the nodes of your design can obtain new values: - Through a clock edge - Through an asynchronous event like the reset
Your expression for that initial value doesn't represent any of those. You need to have an initial state on your design in order to have the proper initial conditions. And that initial state is the reset.
BTW This Xilinx white paper is a good read about FPGA resets. https://www.xilinx.com/support/documentation/white_papers/wp...
The thing is, implementing non-trivial FPGA designs is much closer to software development than to analog hardware design, both in the problem-solving approaches and in the tools you use (text-based languages instead of schematics); a "low-level mindset" is necessary, though. The association of FPGAs with electrical engineering is mostly due to historical reasons.
As for learning FPGA design: Download the free Xilinx Vivado Webpack (or the Intel/Altera equivalent), it is so feature-complete that it's even sufficient for many commercial designs. Most online tutorials (and university courses) are pretty crap though, because the teach you extremely low-level approaches, like building your own adders, which you should never do in FPGAs. This is great for understanding bit-level arithmetic, but useless for approaching and partitioning larger problems. It's the equivalent of teaching someone assembly (great for understanding the inner operations of a CPU), and then asking them to implement a webserver.
Besides, most online tutorials and university courses teach outdated coding styles, like separating sequential and combinational processes. It's good to read, e.g., the Xilinx forums to stay up-to-date.
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.
The DE series still exists and has a wide range: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=E...
The DE0 Nano is pretty cheap: https://www.digikey.co.uk/product-detail/en/terasic-inc/P008... the more capable DE10 Nano looks interesting too: https://www.digikey.co.uk/product-detail/en/terasic-inc/P049... 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/) 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.
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.
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!
I'm going to make you define "good". Icarus, at one point, handled way more of the standard than even Cadence did and had far fewer bugs.
And I can tell you that at least one graphics chip used to run it's validation suite through Icarus.
And I, personally, was the person who reduced our Cadence Verilog licenses by 25% once I got Icarus Verilog up and running. At the time, the EDA vendors were dragging their feet on Linux versions because you had to buy significantly more licenses if you were stuck running it on Sun equipment.
Obviously, my info is highly dated. I haven't tracked Icarus Verilog in quite a while, but code doesn't magically get worse as long as it is being actively maintained. And the original writer/maintainer (Steven Williams) is a solid developer and is still on board.
Dan
But since we're here talking about resets I'll give my own 10 cents for beginners:
- Do not reset EVERY REGISTER. Before you apply reset to a register ask yourself: does this piece of logic really require an initial state? This is especially true for data registers where the validity of its data is signaled by a separate control signal. Rule of thumb, reset the control signal not the data value - or better, design your circuits so that you only need to reset control signals (state machines included). Excessive use of resets puts a burden on the routing tools, can negatively affect your timing and prevent certain optimizations
Especially for beginners I would recommend that you reset all your registers, because errors due to uninitialized signals are a pain to debug, and they might not be visible in simulation. For example, if r is uninitialized and has the value 'U' (or 'X'), then
if r = '0' then ... else ... end if;
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.
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.
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...
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.
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.
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.
We also added, "no external capacitors can be used for timing," because people would try to fix things that way.
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.
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... :
"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.
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.
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.
Dan
>> "Synchronize all external wire inputs with two clocks before using them."
"Metastability in electronics is the ability of a digital electronics system to persist for an unbounded time in an unstable equilibrium or metastable state.
In metastable states, the circuit may be unable to settle into a stable '0' or '1' logic level within the time required for proper circuit operation.
As a result, the circuit can act in unpredictable ways, and may lead to a system failure..."
https://en.wikipedia.org/wiki/Metastability_in_electronicsYou 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.
If you're building a soft-core CPU designed for a wide range of FPGAs and you can't make it go without a custom floor-plan then yes you're probably doing it wrong.
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).
Works very well so long as master clock speed >> SPI speed.
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 , 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.
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 :)
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.
Understanding why something is non-synthesizable or inefficient in hardware is 90% of your education as a chip designer. Exposure to HLS tools can, and should, wait.
If your language (in the case of CLaSH) or DSL (in the case of Chisel) is designed correctly, there's a clear and direct correspondence between high-level semantic constructs and low-level hardware constructs.
Take a look at Conal Elliot's Lambda-CCC. The semantics of synthesizable hardware and the semantics of lazy lambda calculus are exactly the same in many fundamental ways. There's no fooling or trickery going on. If you understand why your lambda calculus program is divergent, you understand why your circuit is unstable.