USER RESET in XILINX FPGA

duplicated several reset signal and cause some output DFFs can not place into IOB.

any other way?

You may be able to remove the user reset completely. Is your user reset only to guarantee the initial state of the design (a common ASIC practice)? If so, you can eliminate this reset signal, which will potentially make your design significantly smaller.

Xilinx FPGAs have an internal Global Set/Reset signal that is asserted at the end of the configuration process, guaranteeing the initial conditions.

Also see the following TechXclusive article.

Get Smart About Reset (Think Local, Not Global)

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs

--------------------------------- Spartan-3: Make it Your ASIC

Dear Steven:

Thanks for ur reply and Kens's artical. Now, i have removed reset from DFF which need to be placed into IOB. Just like the followings. However, ISE map "r_dbus_o" into "FDS"(D and SR are connected with "s_dt_cdio_o" ) not "FD", this still prevent DFF placed into IOB. Oh, god save me.

---------IN ISE6.2.03i ---------- always @ ( posedge SYSCLK ) begin r_dbus_t

This can't be good advice. I have a co-worker who does that often, and I get to write drivers for the resulting chips. It bugs me a lot.

Using the configuration process to initialize things to a safe startup state is nice and all (especially for "roms" and the like) but RESET is *not* the same thing.

(snip)

I thought Xilinx FPGA's have the ability to connect reset inputs to a global reset line. That can only reset to the same state that the initial startup state is, though.

-- glen

This gets discussed here a lot. On both the Xilinx and Altera FPGAs there is a global reset line. This can establish an initial condition of all FFs in the device (but not RAM). It is activated on configuration (power up or otherwise) and can also be driven to a signal from inside or from an external pin.

The problem with using this global signal is its slow propagation speed. Even if you release the reset synchronously with the clock (asynchronous release is guaranteed to create problems at some point) the slow prop speed means that with a fast clock different FFs can be released from reset on different clock cycles. This can result in bad values in counters and finite state machines (FSMs), possibly even locking up the design. There are many ways to deal with this problem. I typically design my circuits to not care if the global reset release is slow. This is done by giving a given section a separate synchronous reset that is part of the circuit. I think this may be discussed in the c.a.f FAQ.

But with the Icarus Verilog support of Initial blocks, can't the power-up state be provided exceptionally clean?

If the reset is actually used for more than initial states, then the reset is *needed* but if it's just for power-up, are there things that the initial block synthesis support wouldn't cover?

reset

practice)?

your

at

conditions.

: > You may be able to remove the user reset completely. Is your user reset : > only to guarantee the initial state of the design (a common ASIC practice)? : > If so, you can eliminate this reset signal, which will potentially make your : > design significantly smaller. : >

: > Xilinx FPGAs have an internal Global Set/Reset signal that is asserted at : > the end of the configuration process, guaranteeing the initial conditions.

: This can't be good advice. I have a co-worker who does that often, : and I get to write drivers for the resulting chips. It bugs me a lot.

: Using the configuration process to initialize things to a safe : startup state is nice and all (especially for "roms" and the like) : but RESET is *not* the same thing.

Stephan,

is there a way to tell iverilog ( or other verilog simulators) to use registers with a default initial value, so no "initial" assiignment would be needed. Only registers with a non default values would be needed to be set explicitly.

Bye

: > You may be able to remove the user reset completely. Is your user reset : > only to guarantee the initial state of the design (a common ASIC practice)? : > If so, you can eliminate this reset signal, which will potentially make you r : > design significantly smaller. : >

: > Xilinx FPGAs have an internal Global Set/Reset signal that is asserted at : > the end of the configuration process, guaranteeing the initial conditions.

: This can't be good advice. I have a co-worker who does that often, : and I get to write drivers for the resulting chips. It bugs me a lot.

: Using the configuration process to initialize things to a safe : startup state is nice and all (especially for "roms" and the like) : but RESET is *not* the same thing.

Stephen,

is there a way to tell iverilog ( or other verilog simulators) to use registers with a default initial value, so no "initial" assignment would be needed. Only registers with a non default values would be needed to be set explicitly.

Bye

practice)?

you

Yes, the Verilog-2001 declaration assignment syntax works. For example "reg foo = 1;" gets you a foo with an initial value of 1. What's more, xst seems to know what to do with this as well. I was at first reluctant to use it in my designs, doubting the xst support, but I found it works, so I use it, now.

However, that really only simulates the power-on case. If you have resets at times other then power on, or soft resets for subsystems, this feature is obviously no help.

Have you looked at what it's actually doing?

My guess is it's using the global reset line. Have you seen the discussions here? They happen quite frequently. They might be a bit complicated until you "get it".

Stephen Williams wrote: ...

: Yes, the Verilog-2001 declaration assignment syntax works. For : example "reg foo = 1;" gets you a foo with an initial value of 1. : What's more, xst seems to know what to do with this as well. I : was at first reluctant to use it in my designs, doubting the xst : support, but I found it works, so I use it, now.

Stephen,

I know that option and use it. But even if I create a register with reg foo; XST gives that register a default value (FALSE). For the simulator however it is unknown (x). What I ask about is something like

pragma register_default_state FALSE

and then the simulator would come up with all registers in state FALSE if they are not initializes in an explicit way (either as above "reg foo = 1;" or in an initial statement)

: However, that really only simulates the power-on case. If you have : resets at times other then power on, or soft resets for subsystems, : this feature is obviously no help.

Totally clear!

Bye

It sets the INIT attribute on the flip flop.

Regards, Allan