GSR in Spartan3 ?

"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
news:c104o6$j54$1@news.tu-darmstadt.de...
> Nial Stewart <nial@nialstewartdevelopments.co.uk> wrote:
> : > You can access glbl.GSR in you testbench...
>
> : But what about in real life, which is what I'm
> : worried about.
>
> : The STARTUP_SPARTAN3 only has an input port,
> : this is used to drive GSR.
>
> Inn real life, GSR is driven when the FPGA boots. For simulation you drive
> or force it. Wher's the problem?


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.

Nial Stewart wrote:
> 
> I've built the design with the ROC module driving rst.
> 
> In the floorplanner if I do a search for Net rst, highlight it then
> look for all logic loading that net I get 491 flip flops.
> There are 1372 slice flip-flops in the design, and many that
> aren't loading rst are asynchronously reset in the code.
> You can easily find flip flos in the floor plan that aren't
> selected.
> 
> I'm not happy this is doing what I want it to.
> 
> When I use the counter reset mechanism as discussed
> elsewhere in the thread and do a search for rst I
> get 15 nets. Selecting these and doing a search for
> then selecting logic loading these nets gives 1558 symbols,
> and I can't see a flip_flop on the floorplan that's
> not selected.
> 
> I'll stick with this method unless I can work out why
> the GSR implementation isn't working.
> 
> Did Ray actually give advice that was wrong?

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

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.

In summary:
The hardware comes up in a known state regardless of the presence of ROC.
ROC is a simulation primitive: in simulation, it generates a reset pulse
which puts all the attached FF's to a known state
ROC a place holder, it preserves the global reset in the netlist, which is
necessary to initialize any of the flip-flops in the non-default state,
    but also blocks use of the FF's reset pin by the synthesizer (I think
synplify might have fixed that in 7.3.4)
You won't see a dedicated net for the global reset in FPGA editor, GSR is a
dedicated net connected to all flip-flops in the design.  The only evidence
you'll see in FPGA editor is the application of the correct init values for
FF's with non-default init values.

rickman wrote:

> Nial Stewart wrote:
> >
> > I've built the design with the ROC module driving rst.
> >
> > In the floorplanner if I do a search for Net rst, highlight it then
> > look for all logic loading that net I get 491 flip flops.
> > There are 1372 slice flip-flops in the design, and many that
> > aren't loading rst are asynchronously reset in the code.
> > You can easily find flip flos in the floor plan that aren't
> > selected.
> >
> > I'm not happy this is doing what I want it to.
> >
> > When I use the counter reset mechanism as discussed
> > elsewhere in the thread and do a search for rst I
> > get 15 nets. Selecting these and doing a search for
> > then selecting logic loading these nets gives 1558 symbols,
> > and I can't see a flip_flop on the floorplan that's
> > not selected.
> >
> > I'll stick with this method unless I can work out why
> > the GSR implementation isn't working.
> >
> > Did Ray actually give advice that was wrong?
>
> 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

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

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