GSR in Spartan3 ?

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!

guide.

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.

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.

this

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.

GSR

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.

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.

probably

recognise

the

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.

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.

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

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 "

... which might be expected, but rst or GSR aren't menti 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.

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

--

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

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

: "Uwe Bonnes" wrote : in message news:c0vllm$d35$ snipped-for-privacy@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

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

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.

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.

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

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?

Nial.