Is it good practice to always assign initial value and reset signals in digital design?

Question

I have read that initial values to a signal can be set in an FPGA since the design is "loaded into it" after power up. However, in ASICs we can only rely on a reset signal to put all signals into a known state. Thus, is assigning initial value to all signals in code that shall be synthesized a good practice?

I have also read that reset signals makes heavy use of routing resources in FPGA and also in ASIC requires to be routed everywhere. In FPGAs, not using reset in every single register is a way to reduce use of routing resources but am not sure what benefit it is in ASICs. Is it a good practice to find ways to reduce use of reset signal in synchronous design by not using it in some parts of design but use it in others?

Answer 1

I would say that there are a couple of different ways that you could argue that. Not sure what the 'best' method is in general, it's going to be dependent on what you're trying to accomplish. It's easy to initialize everything on the FPGA in HDL so that when it comes out of the configuration routine, everything starts from a known state. However, usually resets are necessary, even on an FPGA, due to various clocking configurations. In which case, NOT initializing things may make more sense as then X propagation can be checked in simulation to make sure the resets are doing their job properly by resetting the appropriate registers.

In terms of routing, it makes sense to figure out what ACTUALLY needs to be reset and then omitting resets on things where the initial configuration doesn't matter. This will save routing resources on both FPGAs and ASICs. For example, things like data buses with valid signals don't need ANY of the data bus to be reset, only the valid signals. If your data bus is 32 or 64 bits wide, only resetting the valid signals will significantly reduce the complexity of the reset circuitry. The reduced routing complexity can lead to smaller resource utilization and easier timing closure. It also allows the synthesizer to use the reset inputs of the flip flops for other purposes, which could simplify the logic and again improve area and timing.

Also, what you reset and how you do it (sync vs. async, reset to 0 vs reset to non-zero) may affect how the synthesizer can infer things like RAMs. Pipeline registers in block RAM don't necessarily have reset or preload capabilities, so if your reset logic conflicts with what the block RAM on your target chip is capable of, then your pipeline registers won't get merged and your timing performance and resource utilization will suffer.

Answer 2

For neither technology (FPGA or ASIC) should you rely on signal initialization. If you need your gates and signals to start up at a known state - use resets.

I have read that initial values to a signal can be set in an FPGA since the design is "loaded into it" after power up.

Not necessarily. It's not a function of the VHDL standard itself, and therefore depends on the synthesizer/FPGA. Xilinx and Altera FPGAs support this, but it's not an industry given. So, you should be aware that designs which rely on initializations, sacrifice portability to some degree.

In fact, Pedroni in Circuit Design with VHDL flat out states ”the initial value [of signals] is not synthesizable, being only considered in simulations.” ref Section 7.2

Moreover, the initializations that actually are realized in fabric configurations should be considered as asynchronous, and (depending on your design) may result in timing violations. For reference see page 89 of Xilinx UG470 - 7 Series FPGAs Configuration, where the document discusses the startup sequencer. Specifically, see Note 3:

• GWE is asserted synchronously to the configuration clock (CCLK) and has a significant skew across the part. Therefore, sequential elements are not released synchronously to the user's system clock and timing violations can occur during startup. It is recommended to reset the design after startup and/or apply some other synchronization technique.

However, in ASICs we can only rely on a reset signal to put all signals into a known state.

This is accurate. So, should your design ever be ported to ASIC fabrication, you'll have a lot of rework to do if your design does not use resets.

Is it a good practice to find ways to reduce use of reset signal in synchronous design by not using it in some parts of design but use it in others?

I would argue that this would constitute poor practice. Good practice would be to always design resets into your modules. If you decide that you don't need to implement them, don't connect them and they won't be used - but, if you later find that your unconnected resets is the source of the bug you've been searching for (not a far fetched scenario), it will be trivial to connect them up.

Finally, I'll point out that designing out all of your resets (in lieu of intializations) precludes soft resets! How do you default back to your start-up state on soft-resets without a good reset model? (you don't)

Answer 3

Analogy: Is it good practice for game developers to initiate the state of the game when a user plays it? User 1:"Woaw, I started the game near the end and finished it... uhm... kay", user 2:"I started at the start and had a whole game to play, nice!".

In that case it's very important , because it matters a lot.

If you are working with digital filters, then whatever you initialize the registers with doesn't really matter because it's crap anyways.

In this case it is not important.

In other words, it depends on what you are actually doing, if you got a menu system or some finite state machines then it usually matters a lot. It's 100% up to you, or the errors you receive, (I know Quartus can throw some errors if you don't initiate signals properly).

I'd recommend that you always initiate when the system resets, that's good design in my opinion, I'd hate to press "reset" that doesn't do anything when/if a system has crashed.

If I see that much of the routing resources are just for initiating states, then I'd acquire an FPGA with more resources, but that's just my personal take on it. But in the end, it's up to you and your future company and how you are going to use it. If you'd be more precise regarding your usage my answer wouldn't have been as general.

---

Had you presented something more along these lines:

I can initiate every state of my menu on my FPGA if I buy some FPGA with more resources, this will cost 10 more dollars per unit, I will be selling 1000 of these. So that's 10 thousand dollars, a relatively large sum of money.

Or, you don't initiate every state of the menu and whenever someone opens the menu random choices appear and you don't have to buy another FPGA. You're saving a relatively large sum of money.

"What should I do?", then I'd say upgrade your FPGA because anyone who uses your unit will not come back again for the next version you sell. So you may make a lot of money now, but lose 99% of your customers.

---

I say "FPGA" everywhere as a synonym of FPGA and ASIC, the problems are similar if not identical.

Answer 4

Great post and everybody has given great answers here. A sync/async reset to initialise values, is always provided to be on the safer side, during power-on. This is especially true in case of ASICs. That's why all the processors, controllers, start up with a power-on reset. They also provide a way to bring system to its initial state, at any point of operation. In case of FPGAs, most synthesisers now synthesize initial values, even if no reset is present. In Altera, if an async reset signal is there , the synthesiser is intelligent to find it and initialize the values accordingly (not in case of sync reset). If both reset block and initial values are given, altera shows warning if some mismatch is there between the values under reset and initial values. Finally, routing resources , power and performance of the entire design depend on whether your reset is sync or async. You can find it here: http://only-vlsi.blogspot.in/2009/05/synchronous-reset-vs-asynchronous-reset.html?m=1

Answer 5

Pedroni would be wrong in the context of SRAM based FPGAs, in the context of ASIC he would be correct. However, if you listen to Harry Svensson, "FPGA everywhere as a synonym of FPGA and ASIC, the problems are similar if not identical.”, so now he is provably wrong.

Best practice is to understand your target architecture, understand the longer term usage of the code your writing, understand what the synthesizer and configuration process (in case of FPGA) will implement with your RTL. Write code appropriate for your application.