> 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.
This is actually surprisingly hard to do reliably when you're not using an FPGA but a large board with TTL or CMOS logic. I really struggled with keeping outputs 'muted' until the control system was up and running in one particular design. In the end my solution was to have a single relay in the supply line to the power electronics and to only trigger this relay after the control system output a complex code on it's IO lines. The chances of this happening randomly during the power on sequence were nil and once the system was powered up it did not matter any more (relay held itself and the only way to reset it was an emergency stop after which the whole machine would be cycled anyway).
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.
Most real world hardware bugs I've come across are problems with power-on-reset as pin state problems (smoke included), garbage data in/out, or such stupid timing requirements that they couldn't be used in an integrated system without some sort of isolator.
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.
Eh, the design may be able to work without async reset. If the board level reset net causes the FPGA to reconfigure, then the real I/O reset is implicit anyway. In this case you do need to give initial values to registers so that the synthesis tool can figure out the initial state (it may not be able to infer it from the sync reset net alone).
I mean initial value like this in Verilog:
reg output_reg = 1'd1;
(or at the very least check that the synthesis tool did infer correctly).
I'm sorry but everything you said doesn't make any sense in context of hardware design.
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.
On FPGAs there is a third way for a register to get new values: FPGA configuration. When FPGA is re/configured initial values specified (like in previous post) will be set as value of FF.
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.
I studied computer science and taught myself FPGA design on my own.
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.
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.
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).
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.
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.
> 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!
Well, a couple of the people whom "The Steves" (inside joke: for a while it seemed like everybody who was committing code to Icarus Verilog was named Steve--I think there were 5 at one point) used to work with were on the Verilog committee itself. Both Cadence and Synopsys used to fail the validation suite that Icarus used to run.
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.
I was using free tools, so maybe that's was the issue, but I always found that trying to even approach abstraction would always totally explode my routing requirements. Is this the case with professional tools, or is abstraction avoided?
This helps a lot actually, thank you. I know what works for one may not work for another - but it's good to know that revisiting it as a hobby may not be a complete waste of time.
You're absolutely right, but I feel the author's statement refers to internal logic only. I/O bring up is certainly more tricky - a reset that goes through the FPGA is not a guarantee of proper power-on behaviour anyway, you need to deal with the pre-configuration state as well.
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
I used to think the same way, but I've since changed my mind and consider it now premature optimization: It's totally okay to do it in a just-for-fun project, but otherwise the usual rules for optimizations apply: 1) Only do it once you know if and where it is actually necessary and 2) measure the impact of your changes.
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;
will execute the else-branch in simulation, but might take the then-branch in a hardware.
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)