How to eliminate a reset input

[Miti]

I developed my project in Verilog on a development board with Cyclone 4 that has a RESET button on pin 25. Once everything worked as I wanted, I made a board where I don't have a reset button. Once I received my board and reassigned some of the pins that were different than the development board, everything went well and I forgot that my reset input is floating... until yesterday when I started seeing some erratic behavior. I figured out that I have to get rid of reset and I thought, easy peasy, I just enable the pull-up on pin 25.
Nope, pin 25 is dedicated clock pin and doesn't have pull up. I moved then the reset input to a different I/O pin and enabled pull up and all is good now.
My question is, what is the correct way to eliminate the external pin and pull up the reset line internally, without removing it from all the modules?
I tried:

reg Rst;
initial Rst = 1'b1;

and replace all the RESET with Rst but it doesn't work anymore.

Thanks,
Miti

[SiliconWizard]

reg Rst;
initial Rst = 1'b1;

and replace all the RESET with Rst but it doesn't work anymore.

How are you handling RESET inside your code? I'm assuming you have implemented asynchronous reset in most of your processes? If so and you're initializing signals inside of your reset cases, obviously it won't work if the reset signal is never asserted. The reason why it works if it's tied to an external pin, even with a pull-up enabled, is that in this case, a reset signal will still get instantiated and routed through a clock distribution network internally. And it will get asserted automatically upon configuration. That's called "GSR", look that up.

Now if you tie your resets to a fixed signal internally, that's completely different. I'm assuming you have a low-level reset. If you tie it to a fixed '1', then synthesis will prune all of your reset handling since it can assume it never gets there.

Is there a problem with the way you circumvented this (using an I/O pin and enabling pull-up on it)? Do you want to save this I/O for something else? This is actually something I've done a few times for designs requiring an asynchronous reset. This isn't wrong per se IMO.

Another way of course would be to get rid of async resets. Some people will even tell you those should be usually avoided on FPGAs.

But if you want to keep your code intact - except for forcing the reset signal to '1' - and avoid having to use an external pin just for making use of the internal GSR, you can do just like what you tried with your fixed Rst signal, and give initial values for all signals in your design that are otherwise initialized in the async  "reset" condition (which I've been assuming is your problem here.) This is tedious, but something many people working with FPGAs actually do.

[ejeffrey]

Don't use an initial statement.  Remove reset from the top level module pins and replace with "always_comb nReset=1" which should cause the synthesis to prune all the reset logic.

Alternately if you actually need a reset signal at startup (often not needed in FPGAs) you can create a reset process with a counter and a clock that is guaranteed to be present.

[mascotte]

As said above, you can implement a reset process at top level with e.g. a shift register or a state machine that synchronously resets the rest of your design for a specific number of cycles. You can initialize the  flip-flops of that logic in code so they don't need a reset itself (that works because the power up values are stored in SRAM). If you use a PLL in your design to generate the clock, you can also use the lock signal as reset but you would probably need to synchronize it into your system clock domain.

[Miti]

@SiliconWizard

No, I don't need that I/O, actually I have plenty of free I/Os, I just wanted to understand what happens. Thanks!

@ejeffrey

Isn't that System Verilog? It doesn't seem to work in Verilog.

@mascotte

Yes, I know that I can make a counter to control the reset line, but I wanted to understand why my implementation doesn't work. However, the PLL "locked" idea is very clever and it works. Thanks!

[gnuarm]

Unless there is a specific need for an external reset, I don't bother coding a reset into any of my logic.  I design the logic to start in a state that will not become scrambled on the first clock edge if some registers see it and others don't.  That is, I design my state machines, counters and the overall design itself to be tolerant of the vagueness of the release of the internal global async reset. 

This does sometimes require specific circuitry or added states to FSMs to assure they do not enter illegal states.  That's not normally a real issue though.  It just becomes part of the habit of good design, like handling clock domain crossings.

BTW, typically when I do need an external reset, it is used to drive the configuration pin.  Then the entire chip reboots just like a power on.  If one works, both should work.

[BrianHG]

Yes, I know that I can make a counter to control the reset line, but I wanted to understand why my implementation doesn't work. However, the PLL "locked" idea is very clever and it works. Thanks!

PLL Locked can fail, IE state that it is already locked if the PLL doesn't receive a reset.
This is cumbersome with brown-out issues.

I once made a design which used could read and write to free space in the boot-prom for data storage, as well as upgrade the firmware.  The problem was it sometimes self-destructed during power-off.  As the functioning systems power dropped, and most of the electronics halted, the drop in current on the power supply left a second small 'kick' of remaining juice into the lower voltage VCCint, enough for a weird code state and a stray 'erase sector' function to escape the FPGA killing it's own bootprom.  Lesson learned, I need a brown-out or power supply good feeding an FPGA input to prevent stray crap executing during the power-out death of the system.

[Miti]

I once made a design which used could read and write to free space in the boot-prom for data storage, as well as upgrade the firmware.  The problem was it sometimes self-destructed during power-off.  As the functioning systems power dropped, and most of the electronics halted, the drop in current on the power supply left a second small 'kick' of remaining juice into the lower voltage VCCint, enough for a weird code state and a stray 'erase sector' function to escape the FPGA killing it's own bootprom.  Lesson learned, I need a brown-out or power supply good feeding an FPGA input to prevent stray crap executing during the power-out death of the system.

Did that happen because of the self programming code or you say it can happen to any design?

[BrianHG]

I once made a design which used could read and write to free space in the boot-prom for data storage, as well as upgrade the firmware.  The problem was it sometimes self-destructed during power-off.  As the functioning systems power dropped, and most of the electronics halted, the drop in current on the power supply left a second small 'kick' of remaining juice into the lower voltage VCCint, enough for a weird code state and a stray 'erase sector' function to escape the FPGA killing it's own bootprom.  Lesson learned, I need a brown-out or power supply good feeding an FPGA input to prevent stray crap executing during the power-out death of the system.

Did that happen because of the self programming code or you say it can happen to any design?

It was the self programming code I wrote.  Well, in Altera, the serial prom IOs are reserved and cannot be used as generic IOs to access the prom unless a specific set of global controls are enabled in the compiler.  Then, for the bootprom, it takes a clock, enable, a specific sequence of structured commands to actually erase a sector in the prom, so, without all this specific code, there is practically no way to manipulate the bootprom's contents.  When connected to a programmer, it's the programmer generating the bootprom instructions for erase and write.

[BrianHG]

The bug was around 1 in 100 power off cycles.  It took a month to track down...
Finally caught in this snapshot:

You are looking at the power rails (Cyan was 5v from the mains switcher) plus 2 lines on the boot prom.  That tiny pulse captured was either a write or erase command to a critical part of the bootprom which wasn't supposed to do anything.

Well, at least the Canadian government covered part of the dev cost under the R&D tax credit program.

Adding a circuit to detect a drop in the 5v to hold the FPGA in global reset/reboot during any glitch/drop on the 5V by more than 1v cleared up all the problems.

[Miti]

BTW, typically when I do need an external reset, it is used to drive the configuration pin.  Then the entire chip reboots just like a power on.  If one works, both should work.

I have a 10K pull-up and a 100nF to GND connected to nCONFIG pin. I think I should use that pin as reset input.

[BrianHG]

What you have should be fine, but, for something a little more critical, I used this circuit:
(nCONFIG reboots the FPGA, reloading from the boot-prom and makes everything into a known state.)

Attach the 'V5' to your DC input, it may be 12v or 5v or 21v, as long as it has some sort of regulation.  (Increase the voltage of cap C380 for higher voltage support.)

The nCONFIG will be pulled low during power-up for ~50ms, and it will be held low as the V5 terminal drops by a volt over 100ms or faster.

As a bonus, if your drive the 'SELF_REBOOT' with a 1-10KHz digital square wave, by the ~5th oscillation, the nCONFIG will be driven low and further held low for ~10ms allowing you to software drive a cold-boot.  (This by design required oscillation prevents accidental self-reboot during power-up software setting of FPGA IOs, their tri-states and driven values.)

In my above scope shot, this circuit would have triggered and held the nCONFIG low by around ~2ms all the way on the left as the cyan blue trace was falling before the yellow 3.3v trace has even begun to fall at 4ms.

[BrianHG]

Here is a power-off with the above circuit.
The yellow trace is the nCONFIG.
The cyan is the +5v source.

Sorry about the slow 40ms/div.  These are 11 year old snapshots an I cannot redo the measurements.  You'll just have to zoom in the graphic.

[BrianHG]

Here is a power on.  Sorry, but the hold time is ~50ms, not my original quote of 10ms.

But you can see it is a nice quality held logic low for 50ms before it's allowed to rise except for a tiny glitch.
The 2 other signals is the bootprom booting.  (Looks like my scope needed a DC calibration at the time...)

[ejeffrey]

@ejeffrey

Isn't that System Verilog? It doesn't seem to work in Verilog.

Always_comb is modern verilog which is to say systemverilog.  You can use always @(*) or assign instead if you prefer but there is really no reason not to use a modern version of the language.

[BrianHG]

I never had to do so, but with the above circuit feeding an IO instead, and a added delay circuit, you can manipulate the setup to inform your circuit of a power failure and give it time to do or abort something before issuing a reset.
You can also add a hold to the reset if you are using a variable voltage USB source, but I think those power supply IC have a power-loss detect capability of their own.