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

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

"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" <nial@nialstewartdevelopments.co.uk> wrote in
message news:40337c46$0$8980$fa0fcedb@lovejoy.zen.co.uk...
>
> > ROC is a place holder and simulation primitive.  It should appear in
> > your edif netlist, then the xilinx mapper removes it and connects the
> > net to GSR.  It is doing what you want.  You can check the xilinx
> > results in FPGA editor to convince yourself.

> I had looked in FPGA editor, but am not _that_ familiar with
> it and wasn't sure what it was telling me.
>
> Time to read the tutorial.


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?

>:-0



Nial.

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?

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

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

I need something to drive my reset net, ie
GSR -> rst.


Nial.

"Ray Andraka" <ray@andraka.com> wrote in message
news:40336236.A85B6B7F@andraka.com...
> ROC is a place holder and simulation primitive.  It should appear in
> your edif netlist, then the xilinx mapper removes it and connects the
> net to GSR.  It is doing what you want.  You can check the xilinx
> results in FPGA editor to convince yourself.


Thanks Ray, this was the confirmation I was looking for.

Previously I think the reset net had to reset _all_ flip
flops in the design for the synthesis tools to pick it up
and connect it to GSR.

Do you know if these conditions still apply if using ROC?


I had looked in FPGA editor, but am not _that_ familiar with
it and wasn't sure what it was telling me.

Time to read the tutorial.


Thanks again,

Nial.

Nial Stewart <nial@nialstewartdevelopments.co.uk> wrote:
: > Any logic signal can drive the .GSR input of the STARTUP_SPARTANX. You can
: > generate it internally or connect to an external pin. Where's the problem?


: I don't want to have to drive it. GSR is driven as part of the
: power up process and I want this to drive my reset net.

: Previously using Leonardo I've been able to have a reset
: net declared as a signal with some directives to tell
: Leonardo to connect this net to the GSR.

: I was hoping that XST would do the same thing, but it doesn't
: seem to. As I said elsewhere in the thread Simplify has a
: directive "xc_isgsr" which looks like it's doing this, but
: there's no equivalent XST dierective listed.


You can access glbl.GSR in you testbench...

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

> Any logic signal can drive the .GSR input of the STARTUP_SPARTANX. You can
> generate it internally or connect to an external pin. Where's the problem?


I don't want to have to drive it. GSR is driven as part of the
power up process and I want this to drive my reset net.

Previously using Leonardo I've been able to have a reset
net declared as a signal with some directives to tell
Leonardo to connect this net to the GSR.

I was hoping that XST would do the same thing, but it doesn't
seem to. As I said elsewhere in the thread Simplify has a
directive "xc_isgsr" which looks like it's doing this, but
there's no equivalent XST dierective listed.



Nial.

Nial Stewart <nial@nialstewartdevelopments.co.uk> wrote:

: "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote
: in message news:c0vllm$d35$1@news.tu-darmstadt.de...

: > : This doesn't help me tie my top level 'rst' net to the GSR.
: > : I've checked through my design and _all_ my asynch reset
: > : declarations use this net with the correct polarity.
: >
: > have
: >   STARTUP_SPARTAN2 rst (.GSR(grst));
: >
: > in the top level module
: >
: > Use grst where you need it:
: >    always @ (posedge rclk or posedge grst)
: >      if (grst)
: >        rdo_cnt <= 20'h0;
: >      else if (!rdo_rr)
: >        rdo_cnt <= rdolen;
: >      else if ( rdo_rr)
: >        rdo_cnt <= rdo_cnt-1;
: >
: > Drive the reset in your test fixure

: I can't drive it, it's not a top level port.

: When I described 'rst' as a top level net, it's not
: actually a port on the top level design. The chip
: I'm designing for doesn't have an external reset
: input pin.

: My understanding is that STARTUP_SPARTAN2/3 is
: used to allow a top level reset input to drive
: the GSR net, but this isn't what I need.

Any logic signal can drive the .GSR input of the STARTUP_SPARTANX. You can
generate it internally or connect to an external pin. Where's the problem?

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------