System Reset / GSR with Virtex 2 & Virtex 4
 

Howdy Gang !

It seems we have some sort of a problem with system reset in
one of our SoC.

It appears that after the board power up we have to press the
external rest button to get the system 100% operational. Before
hitting the rest button, it seems as most of the system is
working but some parts are working "strangely".

I have not traced the problem yet, as it is rather a complex
SoC ...

So I have a generic question to the group:

My understanding was that all flops will be cleared automatically
after the FPGA has been configured. How does the FPGA know
which FLOPS have to be initialized to a '1' vs. a '0' ?

How should I implement the rest such that it would specifically
be asserted after FPGA configuration is done. Do I have to
connect the GSR signal to my reset signal ? There seems to be
very little inconclusive guidelines for this problem.

Any pointers/information highly appreciated !

Best Regards,
rudi
================================================== ===========
Rudolf Usselmann, ASICS World Services, http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

Re: System Reset / GSR with Virtex 2 & Virtex 4
 

First, the registers are not always cleared on power up. When asynchronous
set/reset logic isn't used, synthesizers often bundle other logic into the
synchronous set/reset pins of the flops beyond system set/reset. The FDS
and FDSE primitives (anything with a set but not reset) power up to logic 1
unless the user overrides the value with an INIT=R attribute. The FD, FDR,
FDRE, FDRS, FDRSE primitives (anything with a reset) power up to logic 0
unless the user overrides the value with an INIT=S attribute. I haven't
included the register primitives with async set/reset in the lists but the
idea carries through. Some synthesizers also support register
initialization in the code, producing the INIT=S and INIT=R attributes from
the initializations.

To get a synchronous reset into the design without pressing a reset *I*
would just use a countdown that starts at power up and keeps the system in
reset (except for the counter) until the count expires. I don't want to get
in the business of async resets without additional controls to guarantee the
deassertion of reset is synchronous where needed.


"Rudolf Usselmann" <[email protected]> wrote in message
news:[email protected]
>
> Howdy Gang !
>
> It seems we have some sort of a problem with system reset in
> one of our SoC.
>
> It appears that after the board power up we have to press the
> external rest button to get the system 100% operational. Before
> hitting the rest button, it seems as most of the system is
> working but some parts are working "strangely".
>
> I have not traced the problem yet, as it is rather a complex
> SoC ...
>
> So I have a generic question to the group:
>
> My understanding was that all flops will be cleared automatically
> after the FPGA has been configured. How does the FPGA know
> which FLOPS have to be initialized to a '1' vs. a '0' ?
>
> How should I implement the rest such that it would specifically
> be asserted after FPGA configuration is done. Do I have to
> connect the GSR signal to my reset signal ? There seems to be
> very little inconclusive guidelines for this problem.
>
> Any pointers/information highly appreciated !
>
> Best Regards,
> rudi
> ================================================== ===========
> Rudolf Usselmann, ASICS World Services, http://www.asics.ws
> Your Partner for IP Cores, Design, Verification and Synthesis
>

Re: System Reset / GSR with Virtex 2 & Virtex 4
 

Just to confirm and expand on John_H's posting:
At the end of configuration, Xilinx applies an asynchronous (p)reset to
all flip-flops. That's the good news.
The bad news is that the trailing edge of this initialization signal,
even when it has been synchronized to the clock, has such a long
propagation delay, that it often straddles several incoming clock
periods. As a result, state machines can get half initiated and half
running.
The user is advised to augment the "free" initialization with
deliberate synchronous initialization of critical flip-flops.
Peter Alfke, Xilinx Applications.

Re: System Reset / GSR with Virtex 2 & Virtex 4
 

Peter Alfke wrote:

> Just to confirm and expand on John_H's posting:
> At the end of configuration, Xilinx applies an asynchronous (p)reset to
> all flip-flops. That's the good news.
> The bad news is that the trailing edge of this initialization signal,
> even when it has been synchronized to the clock, has such a long
> propagation delay, that it often straddles several incoming clock
> periods. As a result, state machines can get half initiated and half
> running.
> The user is advised to augment the "free" initialization with
> deliberate synchronous initialization of critical flip-flops.
> Peter Alfke, Xilinx Applications.


Thanks for the feed back John and Peter.

Quick follow up question:

I have a reset block which prolongs the reset and does a few
other things. In addition to the Reset Button, I also take
the lock output from the DPLL that generates the clock to the
SoC. As long as there is no lock, I hold the system in reset,
and even after a lock for some more cycles. So perhaps my reset
should not be a problem after all ? If I assume that the lock
signal of a DPLL would be asserted some time AFTER configuration ?!

Best Regards,
rudi
================================================== ===========
Rudolf Usselmann, ASICS World Services, http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

Re: System Reset / GSR with Virtex 2 & Virtex 4
 

As long as your reset is synchronous, you have a solid solution.

Keep in mind there's a programming option to hold of operation of the FPGA
until the DLLs are stable. If you *don't* engage this option, your reset
ciruit should take care of everything for you.


"Rudolf Usselmann" <[email protected]> wrote in message
news:[email protected]
<snip earlier quote>
> Thanks for the feed back John and Peter.
>
> Quick follow up question:
>
> I have a reset block which prolongs the reset and does a few
> other things. In addition to the Reset Button, I also take
> the lock output from the DPLL that generates the clock to the
> SoC. As long as there is no lock, I hold the system in reset,
> and even after a lock for some more cycles. So perhaps my reset
> should not be a problem after all ? If I assume that the lock
> signal of a DPLL would be asserted some time AFTER configuration ?!
>
> Best Regards,
> rudi
> ================================================== ===========
> Rudolf Usselmann, ASICS World Services, http://www.asics.ws
> Your Partner for IP Cores, Design, Verification and Synthesis