GSR in Spartan3 ?

[Nial Stewart]

In most FPGA designs I've done there's been an external reset
input which has been used as the power on reset mechanism.

I'm now doing a design for a Spartan-3 with no external reset,
and I've some signals I need pre-set so I need to use the
internal asynch reset mechanism.

I've read here in the past of the problems of using the GSR,
but in this design there are synchronous enables which
control the data flow. The functionality of these means there
shouldn't be any timing problems out of reset.

I was under the impression that if you had a top level signal
which was used in the usual VHDL asynchronous reset template
manner, the synthesis tools would pick it out and connect it
to the GSR net.

I'm using XST and getting ..

"Signal <rst> is used but never assigned. Tied to value 0."


So what do I need to do to get 'rst' connected to the GSR
net?

I've spent a fair bit of time searching the Xilinx site/docs
and googling this group with no results. It seems to be one
of those things that I should probably know, but just can't
find anywhere.

Thanks for any pointers,


Nial.

 

[Symon]

So what do I need to do to get 'rst' connected to the GSR
net?

I've spent a fair bit of time searching the Xilinx site/docs
and googling this group with no results. It seems to be one
of those things that I should probably know, but just can't
find anywhere.

Thanks for any pointers,

Nial.

Hi Nial,

Can you instantiate the STARTBUF_SPARTAN3 design element? Listed under
STARTBUF_architecture in the Design Elements section of the Libraries guide.
Cheers mate, Syms.
p.s. I see Mr.Easton's expecting again! There should be a law against it!

 

[Nial Stewart]

"Symon" <symon_brewer@hotmail.com> wrote in message
news:c0rrgi$1b7t8e$1@ID-212844.news.uni-berlin.de...

So what do I need to do to get 'rst' connected to the GSR
net?

I've spent a fair bit of time searching the Xilinx site/docs
and googling this group with no results. It seems to be one
of those things that I should probably know, but just can't
find anywhere.

Thanks for any pointers,

Nial.

Hi Nial,
Can you instantiate the STARTBUF_SPARTAN3 design element? Listed under
STARTBUF_architecture in the Design Elements section of the Libraries
guide.
Cheers mate, Syms.

Symon, that doesn't do it.

The STARTUP_SPARTAN3 module allows you to drive the GSR net from
an user defined source but this reset mechanism isn't visible to
HDL so simulations won't work.

The STARTBUF_SPARTAN3 module does the same thing, but with an
output you can connect to your HDL reset lines which mirrors
the GSR net. Thus simulations should match real life.


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.

Any more ideas?


Nial.

 

[John Adair]

There has been a push away from using GSR resources. Synthesisers probably
now have the feature removed or turned off for modern families. I think this
has been done mainly for simulation purposes and to speed up timing.

My way around this is to use a small lfsr, or other counter, and recognise a
pattern of '1's and '0's. Make your reset active when the pattern of the
lfsr does not match you given final state (final state freezes count).
Whatever default power up state of the flip-flops, be in '0' or '1', you
won't start with pattern that releases reset. The output can be used for GSR
driving or wired reset.

John Adair
Enterpoint Ltd.

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.


"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message
news:40313fb8$0$6685$fa0fcedb@lovejoy.zen.co.uk...

In most FPGA designs I've done there's been an external reset
input which has been used as the power on reset mechanism.

I'm now doing a design for a Spartan-3 with no external reset,
and I've some signals I need pre-set so I need to use the
internal asynch reset mechanism.

I've read here in the past of the problems of using the GSR,
but in this design there are synchronous enables which
control the data flow. The functionality of these means there
shouldn't be any timing problems out of reset.

I was under the impression that if you had a top level signal
which was used in the usual VHDL asynchronous reset template
manner, the synthesis tools would pick it out and connect it
to the GSR net.

I'm using XST and getting ..

"Signal <rst> is used but never assigned. Tied to value 0."


So what do I need to do to get 'rst' connected to the GSR
net?

I've spent a fair bit of time searching the Xilinx site/docs
and googling this group with no results. It seems to be one
of those things that I should probably know, but just can't
find anywhere.

Thanks for any pointers,


Nial.

 

[Nial Stewart]

There has been a push away from using GSR resources. Synthesisers probably
now have the feature removed or turned off for modern families. I think
this
has been done mainly for simulation purposes and to speed up timing.

It looks like it John, a search for 'GSR' in the XST user guide only comes
up with one hit, and that's for the Synplicity directive "xc_isgsr" which
has no XST equivalent.

My way around this is to use a small lfsr, or other counter, and recognise
a
pattern of '1's and '0's. Make your reset active when the pattern of the
lfsr does not match you given final state (final state freezes count).
Whatever default power up state of the flip-flops, be in '0' or '1', you
won't start with pattern that releases reset. The output can be used for
GSR
driving or wired reset.

I'd thought of this, but it felt like a bit of a bodge.
I suppose it should be reliable as the data sheet stipulates that
the registers power up to '0' unless otherwise specified.

Have you had any problems with it?

I'll give it a go and see how I get on.

Thanks,


Nial.

 

[John Adair]

I have not had any issues doing this. The synthesiser will usually pick a
flop macro with '0' default but if it chooses a '1' default type you are
covered by looking for pattern of mixed '0's and '1's. It is very unlikely
that the pattern you choose will be the same as the synthesiser by way of
the power up defaults. You can always double check and have a look using
FPGA Editor or the equivalent.

John Adair
Enterpoint Ltd.

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.


"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message
news:4031fad1$0$25865$fa0fcedb@lovejoy.zen.co.uk...

There has been a push away from using GSR resources. Synthesisers
probably
now have the feature removed or turned off for modern families. I think
this
has been done mainly for simulation purposes and to speed up timing.

It looks like it John, a search for 'GSR' in the XST user guide only comes
up with one hit, and that's for the Synplicity directive "xc_isgsr" which
has no XST equivalent.


My way around this is to use a small lfsr, or other counter, and
recognise
a
pattern of '1's and '0's. Make your reset active when the pattern of
the
lfsr does not match you given final state (final state freezes count).
Whatever default power up state of the flip-flops, be in '0' or '1', you
won't start with pattern that releases reset. The output can be used for
GSR
driving or wired reset.

I'd thought of this, but it felt like a bit of a bodge.
I suppose it should be reliable as the data sheet stipulates that
the registers power up to '0' unless otherwise specified.

Have you had any problems with it?

I'll give it a go and see how I get on.

Thanks,


Nial.

 

[Lars Unger]

Hi Nial,

I'm not quite sure if it solves your problem, but i currently use
the ROC (ResetOnConfiguration) primitive to connect the reset
signal to the GSR. You'll find more information about it in the
Xilinx "Libraries Guide" (lib.pdf).

Kind regards,
Lars.

 

[Symon]

"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message news:<4031ec0e$0$19544$fa0fcedb@lovejoy.zen.co.uk>...

The STARTBUF_SPARTAN3 module does the same thing, but with an
output you can connect to your HDL reset lines which mirrors
the GSR net. Thus simulations should match real life.


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.

Any more ideas?


Nial.

Hi Nial,
Yeah, tricky one, what I've done in the past is use the
STARTBUF_whatever instantiation, its output connected to rst, and its
input tied to an 'unconnected on the PCB' or an unbonded IOB with the
PULLUP turned on. This stops things being optimised away. I've used
John's method too; it's just as bodgy as the IOB method but gets the
job done!
In fact I just looked at my latest masterpiece; I did the IOB thing
above but left out the STARTBUF_ instantiation. All my FFs get set or
reset on power up correctly, as if by magic!

Cheers, Syms.

 

[Nial Stewart]

"Lars Unger" <larsu@ida.ing.tu-bs.de> wrote in message
newsine.LNX.4.50.0402171641240.23416-100000@tom.ida.ing.tu-bs.de...

Hi Nial,

I'm not quite sure if it solves your problem, but i currently use
the ROC (ResetOnConfiguration) primitive to connect the reset
signal to the GSR. You'll find more information about it in the
Xilinx "Libraries Guide" (lib.pdf).

Kind regards,
Lars.

Thanks Lars, I've implemented the reset count as discussed with
John earlier. This looks cleaner though so I'll try it tomorrow
and report back results.



Nial

 

[Nial Stewart]

Thanks Lars, I've implemented the reset count as discussed with
John earlier. This looks cleaner though so I'll try it tomorrow
and report back results.

Hmm.

I've tried using the ROC component as Lars suggested. The syntheis
report doesn't give many clues as to what's going on, it says...
"Generating a Black Box for component <ROC>"

.... which might be expected, but rst or GSR aren't mentioned.

The map report says ...


The trimmed logic reported below is either:
1. part of a cycle
2. part of disabled logic
3. a side-effect of other trimmed logic

The signal "roc_inst_1" is unused and has been removed.

Optimized Block(s):
TYPE BLOCK
GND XST_GND
VCC XST_VCC
BUF roc_inst_1
BUF roc_inst_2


....which might suggest that ROC has been replaced with
something else (ie a connection to the GSR net) but
it doesn't explicitly state this.

Can anyone confirm that this means the ROC component has been
removed and the rst net has been connected to GSR?

If I can't get this confirmed I'll stick with the startup
counter.

Time for an experiment with a SpartanII I think.



Nial.

 

[Nial Stewart]

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

I want the synthesis tool to drive my rst with
the GSR net.

Nial

 

[Ray Andraka]

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.

Nial Stewart wrote:

Thanks Lars, I've implemented the reset count as discussed with
John earlier. This looks cleaner though so I'll try it tomorrow
and report back results.

Hmm.

I've tried using the ROC component as Lars suggested. The syntheis
report doesn't give many clues as to what's going on, it says...
"Generating a Black Box for component <ROC>"

... which might be expected, but rst or GSR aren't mentioned.

The map report says ...

The trimmed logic reported below is either:
1. part of a cycle
2. part of disabled logic
3. a side-effect of other trimmed logic

The signal "roc_inst_1" is unused and has been removed.

Optimized Block(s):
TYPE BLOCK
GND XST_GND
VCC XST_VCC
BUF roc_inst_1
BUF roc_inst_2

...which might suggest that ROC has been replaced with
something else (ie a connection to the GSR net) but
it doesn't explicitly state this.

Can anyone confirm that this means the ROC component has been
removed and the rst net has been connected to GSR?

If I can't get this confirmed I'll stick with the startup
counter.

Time for an experiment with a SpartanII I think.

Nial.

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

 

[Uwe Bonnes]

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

: "Symon" <symon_brewer@hotmail.com> wrote in message
: news:c0rrgi$1b7t8e$1@ID-212844.news.uni-berlin.de...
: >
: > > So what do I need to do to get 'rst' connected to the GSR
: > > net?
: > >
: > > I've spent a fair bit of time searching the Xilinx site/docs
: > > and googling this group with no results. It seems to be one
: > > of those things that I should probably know, but just can't
: > > find anywhere.
: > >
: > > Thanks for any pointers,
: > >
: > > Nial.
: > >
: > Hi Nial,
: > Can you instantiate the STARTBUF_SPARTAN3 design element? Listed under
: > STARTBUF_architecture in the Design Elements section of the Libraries
: guide.
: > Cheers mate, Syms.


: Symon, that doesn't do it.

: The STARTUP_SPARTAN3 module allows you to drive the GSR net from
: an user defined source but this reset mechanism isn't visible to
: HDL so simulations won't work.

: The STARTBUF_SPARTAN3 module does the same thing, but with an
: output you can connect to your HDL reset lines which mirrors
: the GSR net. Thus simulations should match real life.


: 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

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

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

 

[Nial Stewart]

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]

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

 

[Uwe Bonnes]

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

 

[Nial Stewart]

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.

 

[Uwe Bonnes]

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

 

[Nial Stewart]

"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]

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