GSR in Spartan3 ?

GSR isn't connected to the reset that I've used throughout my code to asynchronously reset flip flops on power up.

(At least I can find nothing in the tools to say it's been connected, and as I said there's no XST directive to indicate which net should be connected to GSR).

Nial.

Reply to
Nial Stewart
Loading thread data ...

I may be mistaken, but I thought that *all* FFs were *always* driven by the global reset signal. By specifying in your code the async reset, you can make the simulation match the chip and you can control whether the FF is set vs. reset.

Am I mistaken about this? Can the chip remove the GSR from FFs? Maybe I am confusing the GSR which can be controlled by the user with a power on reset...

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

GSR is fed to all flip-flops. I'm afraid I may have mislead you by saying you can check it in FPGA editor. All you can check there is the initial values of the flip-flops. On configuration, every flip-flop is set to a known value. Generally speaking, the default is '0' unless the flip-flop has a set or preset input, in which case it is a '1'. What ROC does for you is provide a simulation of the reset on configuration, and where the initial value is not the default it sets the initial FF value. If it is connected to all the flip-flops in your design, then the simulation will match the hardware exactly. If it is not connected to all flip-flops in your design, the ones that it is not conencted to will come out of configuration with the default value in the hardware. The simulation of that circuit will result in initial values of 'U' for any inferred flip-flops that are not initialized by the roc component. You can also have multiple ROC's in the design so that a global reset does not necessarily have to be propagated to the top level of a design. For simulation, it doesn't matter and for implementation, the mapper takes them out before the multiple instances cause trouble.

One caution however, using a global reset with the ROC will also prevent inference of flip-flops using the dedicated set/reset, so you won't get inferred FDRE's or FDSE's. That can be an issue if you are trying to get max density or performance. If you want those, you'll either have to accept the default init state by forgoing the global reset (you can still put the global reset in the code, but surround it with a syn_translate off pragma so that the simulation matches the hardware) or instantiate the appropriate primitive.

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Reply to
Ray Andraka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.