Question about GSR?

Hello,
What does GSR pin do, when should I use it? How do I use it?
Is it required in every design?
Thanks in advance for any response.

http://direct.xilinx.com/bvdocs/userguides/ug332.pdf

Page 234.

GSR sets all DFF's or latches CLB's to a specified initial condition
(either 0, or 1).  The initial state comes from the RTL code (verilog or
VHDL) attributes.

If not specified, the device has all flops and latches in the 0 state
upon startup.

Ignoring timing issues, this is useful to restart (reset) state machines
in a known initial state.

If GSR is asserted while the device is running, it is best if clock
enables are used to disable the clocks in order to ensure that the GSR
state is properly loaded in all flops and latches, and then the enables
my be enabled.

Austin

"austin" <austin@xilinx.com> wrote in message 
news:f8dad7$mvu1@cnn.xilinx.com...
> http://direct.xilinx.com/bvdocs/userguides/ug332.pdf
>
> Page 234.
>
> GSR sets all DFF's or latches CLB's to a specified initial condition
> (either 0, or 1).  The initial state comes from the RTL code (verilog or
> VHDL) attributes.
>
> If not specified, the device has all flops and latches in the 0 state
> upon startup.

Austin,
  Flops and latches are initialized to zeros only if they don't have a set 
pin without a reset.  No controls initialize to a zero.  Set only control 
initializes to a one.  Reset control (with or without set) initializes to 
zero.

Are things different now?  Look at the FDS primitive, for instance.

- John_H


> Ignoring timing issues, this is useful to restart (reset) state machines
> in a known initial state.
>
> If GSR is asserted while the device is running, it is best if clock
> enables are used to disable the clocks in order to ensure that the GSR
> state is properly loaded in all flops and latches, and then the enables
> my be enabled.
>
> Austin 

John,

Basically, since the entire configuration is set to zeroes, the set, or
reset values that are loaded by GSR are set to 0 for resetting
(default).  Basically, on startup, GSR, GHIGH, GTS, and DONE (however
you decide to program the startup, as the sequence itself is
programmable -- see the configuration user's guide for details).

When the device starts up, everything is a zero: flops, latches, LUTRAM,
SRL16, BRAM...

As far as a clean and maintainable design goes, you should not count on
this, but rather specify everything, as hardware may change.

I am an IC designer, so I see the world with that perspective (as wraped
as that is).  Sometimes  it is helpful, and in a case like this one,
perhaps I have provided more information than is required.

Your point of "don't assume" is proper from a systems engineering
standpoint.

Austin

"austin" <austin@xilinx.com> wrote in message 
news:f8dkpf$muk3@cnn.xilinx.com...
> John,
>
> Basically, since the entire configuration is set to zeroes, the set, or
> reset values that are loaded by GSR are set to 0 for resetting
> (default).  Basically, on startup, GSR, GHIGH, GTS, and DONE (however
> you decide to program the startup, as the sequence itself is
> programmable -- see the configuration user's guide for details).
>
> When the device starts up, everything is a zero: flops, latches, LUTRAM,
> SRL16, BRAM...
>
> As far as a clean and maintainable design goes, you should not count on
> this, but rather specify everything, as hardware may change.
>
> I am an IC designer, so I see the world with that perspective (as wraped
> as that is).  Sometimes  it is helpful, and in a case like this one,
> perhaps I have provided more information than is required.
>
> Your point of "don't assume" is proper from a systems engineering
> standpoint.
>
> Austin


Austin - I'm not asking, I'm telling.

In the Spartan-2, 2E, 3, and 3E designs that I did, ALL elements with set 
(but no reset) controls power up high.  I implore you again - check out the 
FDR primitive.  Not all flops power up zero, hence the occasional problems 
when compiling a design without explicit asynchronous resets or INIT 
attributes.  I had to parse through EDIF files to find the set-on-power-up 
synchronous elements to get my simulation to match my hardware.

Unless something is different in the Virtex family of devices (which I would 
not expect at this very low level) the behavior of the synchronous elements 
as defined empirically and through the primitive definitions themselves is 
different than "all zeros all the time on power up."  Life would be *so* 
much easier if this was the case.

- John_H 

"austin" <austin@xilinx.com> wrote in message 
news:f8dkpf$muk3@cnn.xilinx.com...
> John,
>
> Basically, since the entire configuration is set to zeroes, the set, or
> reset values that are loaded by GSR are set to 0 for resetting
> (default).  Basically, on startup, GSR, GHIGH, GTS, and DONE (however
> you decide to program the startup, as the sequence itself is
> programmable -- see the configuration user's guide for details).
>
> When the device starts up, everything is a zero: flops, latches, LUTRAM,
> SRL16, BRAM...
>
> As far as a clean and maintainable design goes, you should not count on
> this, but rather specify everything, as hardware may change.
>
> I am an IC designer, so I see the world with that perspective (as wraped
> as that is).  Sometimes  it is helpful, and in a case like this one,
> perhaps I have provided more information than is required.
>
> Your point of "don't assume" is proper from a systems engineering
> standpoint.
>
> Austin


Austin,

It appears things are slightly different for the newest families which use a 
common FDRSE primitive.  Heck, this may be a software-only thing.  The 
Spartan-3E Libraries Guide for HDL Designs for (ISE 8.1i and 9.1i checked) 
*does* have the common FDRSE primitive but the Xilinx Libraries Guide for 
8.1i (9.2i has bookmark problems) has a separate FDS primitive (and FDSE, 
FDP, FDPE, LDP, LDPE, and all _1 variants) which states:

"For Spartan-II, Spartan-IIE, Spartan-3, Virtex, Virtex-E, Virtex-II, 
Virtex-II Pro, and Virtex-II Pro X, the flip-flop is preset to active high 
when GSR is active."

I would hope the Spartan-3 maintains the old variants but I'm not certain 
EDIFs I've generated from the 3rd party synthesis doesn't use FDS style 
primitives - I'll have to check.  I would expect XST to only support the 
FDRSE primitive.

- John_H 

John,

OK.  I will check.

I can be, and have been wrong before.

I am staring at someone else's schematics (of the CLB) and perhaps I am
seeing a behavior that doesn't exist.  Without a simulation, well, you
know, my statement is not much more than second hand stories, retold.
Just because I don't see the problem, doesn't mean anything, as I am not
making designs for production (just characterizing and testing).

As much as I am a proponent of always doing a simulation, I am not
setting a good example here!

Austin

> Austin,
>
> It appears things are slightly different for the newest families which use 
> a common FDRSE primitive.  Heck, this may be a software-only thing.  The 
> Spartan-3E Libraries Guide for HDL Designs for (ISE 8.1i and 9.1i checked) 
> *does* have the common FDRSE primitive but the Xilinx Libraries Guide for 
> 8.1i (9.2i has bookmark problems) has a separate FDS primitive (and FDSE, 
> FDP, FDPE, LDP, LDPE, and all _1 variants) which states:
>
> "For Spartan-II, Spartan-IIE, Spartan-3, Virtex, Virtex-E, Virtex-II, 
> Virtex-II Pro, and Virtex-II Pro X, the flip-flop is preset to active high 
> when GSR is active."
>
> I would hope the Spartan-3 maintains the old variants but I'm not certain 
> EDIFs I've generated from the 3rd party synthesis doesn't use FDS style 
> primitives - I'll have to check.  I would expect XST to only support the 
> FDRSE primitive.
>
> - John_H

Going through my EDIF from a few months ago, my design is an xc3s1600E and - 
although the S3E Libraries Guide shows no FDS primitives - the 3rd party 
synthesizer does use FDS primitives.  When I spelunk into FPGA Editor to 
find one instance of an FDS without an INIT property, the register is 
checked with SRHIGH and INIT1, carrying over the expected behavior 
appropriate for a pre-Spartan-3E FDS primitive.

I look forward to seeing only FDRSE style primitives instead to help with 
async-reset-free designs with better known inits.  Now do the most recent 
synthesis tool verions produce these library elements exclusively?  I'll 
have to check the latest release and, perhaps, call the Vendor for a new 
customer enhancement request.

I'm happy this nuance in the devices is figured out - at least in my mind - 
such that future designs have a chance of running smoother.

- John_H 

John,

OK.  If this is a software thing, then I am out of my field.

Obviously, the software can fiddle with the bits to create any behavior
that is desired on start-up, and it isn't a hardware issue at all.

If the customer is programming with verilog, or VHDL (which I assume
they are) then what they instantiate will be what they get (as you so
clearly point out).


If they also want to set, or reset the flops or latches at sometime
other than initial start-up, then they may use GSR to do that.

Austin

John,

I learned something new:  software is everywhere....

Austin