Question about GSR?

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, 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

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,

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

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

My problem wasn't with instantiating primitives. My problem is that the list of devices from the Xilinx Libraries Guide that support the FDS (and similar) primitives WILL power-up to a logic high when the SYNTHESIS decides to infer those inverted primitives. My Verilog went to EDIF even in my Spartan-3E without my intervention to produce FDS primitives in many, many places.

- John_H

John,

I get it: at the highest level, you didn't specifically request, nor expect, a particular 'behavior'.

The synthesis tool reached into its libraries, pulled out an element, and said "this will work..."...

In ASIC standard cell design, I have had to specifically declare some elements as "do not use" because of their (unwanted) behavior. Each standard cell library being somewhat unique for any given technology, this is a moving target. Then finally the synthesis gives me what I wanted, but only after a sometimes painful period of debugging.

If the designer doesn't capture everything and write it down, and someone else has to pick up what they have done, it can be a real nightmare.

Austin

Gee ... for all the responses, the issue with the traditionally long propagation delay of the GSR has not been mentioned. The GSR transition time thru the Spartan 2Es was speced at

30 ns +, with the resulting problem being that flip-flops throughout the design were not guarenteed to see the deassertion of reset on the same clock.

The rule of thumb was to avoid relying on the GSR for your chip reset. Instantiate your own reset as part of your design.

Regards, John Retta Owner and Designer Retta Technical Consulting Inc.

Colorado based Xilinx consultant

email : snipped-for-privacy@rtc-inc.com web :