Global reset question?

Hello all

I guess I had better stop saying that I'm new to this FPGA stuff
as I've being saying that for two years now. Anyway Im certainly a
novice
who is improving with time and the gratefully accepted input of
this newsgroups members.

At this stage I am reasonably happy with my design in Verilog
targeting
a xilinx xcs05xl.

However, I find that there is one latch that I dont want to reset when
I am reseting everything else in the FPGA. This is because it holds
configuration
information for the FPGA and the external circuitry. If I dont set
this latch
to zero when my global clear line is low I get about 55 warnings at my
synthesis step.

I get:
DPM  : Warning NET ACB/ACB_NOT_TRIGGER_FOUND does not set/reset
/Int_read_trigger_address/Q_reg (FPGA -GSRMAP-13)

about 55 times.

Im not sure how the nets mentioned above relate to the latch that is
not being cleared.


What is the effect of my action. Are there lots of FFs not being reset
by my global clear signal?
How do I get rid of all these warnings?
Can I decide not to clear one latch and get all others to clear
without all the warnings?


Thanks in advance.

Denis
___________________
http://www.CentronSolutions.com
From concept to production

Denis Gleeson wrote:
> 
> Hello all
> 
> I guess I had better stop saying that I'm new to this FPGA stuff
> as I've being saying that for two years now. Anyway Im certainly a
> novice
> who is improving with time and the gratefully accepted input of
> this newsgroups members.
> 
> At this stage I am reasonably happy with my design in Verilog
> targeting
> a xilinx xcs05xl.
> 
> However, I find that there is one latch that I dont want to reset when
> I am reseting everything else in the FPGA. This is because it holds
> configuration
> information for the FPGA and the external circuitry. If I dont set
> this latch
> to zero when my global clear line is low I get about 55 warnings at my
> synthesis step.
> 
> I get:
> DPM  : Warning NET ACB/ACB_NOT_TRIGGER_FOUND does not set/reset
> /Int_read_trigger_address/Q_reg (FPGA -GSRMAP-13)
> 
> about 55 times.
> 
> Im not sure how the nets mentioned above relate to the latch that is
> not being cleared.
> 
> What is the effect of my action. Are there lots of FFs not being reset
> by my global clear signal?
> How do I get rid of all these warnings?
> Can I decide not to clear one latch and get all others to clear
> without all the warnings?

I could be wrong, so maybe I should let the Xilinx people reply.  But I
am pretty sure that in the Xilinx parts, *all* CLB FFs are either set or
reset by the async GRS. This is a hardware feature and does not depend
on how you specify the async reset in your code.  The code can only
control whether it is set vs. reset.  (I don't remember if the IOB FFs
are cleared or have a controlled async set/reset).  

The GRS always controls the starting state of the CLB FFs on
configuration, but you don't have to use the GRS signal when you reset
your design otherwise.  In that case you can use your own input to
globally reset your design and have that signal go to the FFs of your
choice.  

In either case, you need to be aware of the problems created anytime you
use a global reset.  The delays are typically pretty long and it is hard
to assure that your reset trailing edge meets the setup and hold times
on all the FFs.  When it does not, it can create problems with FFs
coming out of reset on different clock cycles and even FFs suffering
from metastability problems, although I expect that would be exceedingly
rare.  

Typically an async reset needs to be combined with a mechanism to hold
various parts of your design in reset until every FF has been released.  

-- 

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

rickman is right, GSR forces every flip-flop in the chip. Faced with the
need to store some bits that must be unaffected, I have suggested using
latches made up of feddback across one LUT, but nowadays the SRL16 would
be better. You just shift in some data into the SRL16, and you can rest
assured that it will remain undisturbed by GSR.

Peter Alfke
=========================
rickman wrote:
> 
> 
> I could be wrong, so maybe I should let the Xilinx people reply.  But I
> am pretty sure that in the Xilinx parts, *all* CLB FFs are either set or
> reset by the async GRS. This is a hardware feature and does not depend
> on how you specify the async reset in your code.  The code can only
> control whether it is set vs. reset.  (I don't remember if the IOB FFs
> are cleared or have a controlled async set/reset).v

Peter Alfke wrote:
> 
> rickman is right, GSR forces every flip-flop in the chip. Faced with the
> need to store some bits that must be unaffected, I have suggested using
> latches made up of feddback across one LUT, but nowadays the SRL16 would
> be better. You just shift in some data into the SRL16, and you can rest
> assured that it will remain undisturbed by GSR.

Although that begs the question of how is this latch set on the initial
power up of the part?  It will either power up randomly (differently)
each time, or it will power up in a consistent state, but not defined. 
I guess whether this matters depends on how it is being used...

-- 

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

In article <40479FA2.88E36F15@yahoo.com>,
rickman  <spamgoeshere4@yahoo.com> wrote:
>> rickman is right, GSR forces every flip-flop in the chip. Faced with the
>> need to store some bits that must be unaffected, I have suggested using
>> latches made up of feddback across one LUT, but nowadays the SRL16 would
>> be better. You just shift in some data into the SRL16, and you can rest
>> assured that it will remain undisturbed by GSR.
>
>Although that begs the question of how is this latch set on the initial
>power up of the part?  It will either power up randomly (differently)
>each time, or it will power up in a consistent state, but not defined. 
>I guess whether this matters depends on how it is being used...

Actually, isn't the case that SRL16/LutAsRam data starts up at a
known, DEFINED state based on the initial configuration of the LUT
itself?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

SRL16 starts up out of configuration with known contents (all '0's is the
default, use the INIT attribute to set some other value).  It is not altered at
all by GSR.  Just be careful coming out of reset that you don't write into it
inadvertently.

"Nicholas C. Weaver" wrote:

> IActually, isn't the case that SRL16/LutAsRam data starts up at a
> known, DEFINED state based on the initial configuration of the LUT
> itself?
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

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

Denis,

There are a few solutions to this problem.  First the SRL was mentioned 
but since you are targeting a Spartan-XL, you do not have an SRL but you 
do have LUT-RAM and it can serve this same purpose.  You can use a 
RAM16X1S with all address lines tied to a known value (zeroes) and the 
write enable tied high.  You would have more-or-less a FF not tied to 
global set/reset (GSR) at all.  Another possibility to fix this problem 
is to use a regular FF and have the initial state specied to a one.  It 
sounded like the problem was this the register going to zero and the 
default state can be made to a one if that solves the issue.  In that 
case, and time GSR is used that register would be set to a one not a 
zero.  Both of the above suggestions are assuming that you are using the 
STARTUP block to get access to the dedicated GSR net which will set or 
reset depending on the defined init state of the FF at configuration. 
If you have not instantiated a STARTUP block in your code, then you will 
be using local resets using standard routing and in that case anything 
that you do not connect to the reset will not be reset after power up. 
This will consume routing resources but the XCS05XL is a small device 
and as long as timing can be met, should be OK.

The warning message below looks to be issued by the synthesis tool and I 
am not exactly sure why it is being issued.  I think it is trying to 
warn you that you may have made a mistake in accidentally not connecting 
one register to the reset but it sounds like you want this done.  My 
suggestion would be to do a timing simulation and see if it works as you 
want it to.  If so, then that can be ignored.  If it does not act 
properly, then you can figure out why and maybe that can address this 
warning as well.

Hope this helps,

--  Brian


Denis Gleeson wrote:

> Hello all
> 
> I guess I had better stop saying that I'm new to this FPGA stuff
> as I've being saying that for two years now. Anyway Im certainly a
> novice
> who is improving with time and the gratefully accepted input of
> this newsgroups members.
> 
> At this stage I am reasonably happy with my design in Verilog
> targeting
> a xilinx xcs05xl.
> 
> However, I find that there is one latch that I dont want to reset when
> I am reseting everything else in the FPGA. This is because it holds
> configuration
> information for the FPGA and the external circuitry. If I dont set
> this latch
> to zero when my global clear line is low I get about 55 warnings at my
> synthesis step.
> 
> I get:
> DPM  : Warning NET ACB/ACB_NOT_TRIGGER_FOUND does not set/reset
> /Int_read_trigger_address/Q_reg (FPGA -GSRMAP-13)
> 
> about 55 times.
> 
> Im not sure how the nets mentioned above relate to the latch that is
> not being cleared.
> 
> 
> What is the effect of my action. Are there lots of FFs not being reset
> by my global clear signal?
> How do I get rid of all these warnings?
> Can I decide not to clear one latch and get all others to clear
> without all the warnings?
> 
> 
> Thanks in advance.
> 
> Denis
> ___________________
> http://www.CentronSolutions.com
> From concept to production

The LUT content is defined in the bitstream. That defines the original state
of the latch. Same for SRL16.
Peter Alfke

> From: rickman <spamgoeshere4@yahoo.com>
> Reply-To: spamgoeshere4@yahoo.com
> Newsgroups: comp.arch.fpga
> Date: Thu, 04 Mar 2004 16:29:06 -0500
> Subject: Re: Global reset question?
> 
> Peter Alfke wrote:
>> 
>> rickman is right, GSR forces every flip-flop in the chip. Faced with the
>> need to store some bits that must be unaffected, I have suggested using
>> latches made up of feddback across one LUT, but nowadays the SRL16 would
>> be better. You just shift in some data into the SRL16, and you can rest
>> assured that it will remain undisturbed by GSR.
> 
> Although that begs the question of how is this latch set on the initial
> power up of the part?  It will either power up randomly (differently)
> each time, or it will power up in a consistent state, but not defined.
> I guess whether this matters depends on how it is being used...
> 
> -- 
> 
> 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

The configuration holds the LUTs contents which defines the combinatorial
function of the LUT, but that does not describe the LUT's output value.  You
cross couple two luts, but I don't see how you force a particular initial value
from initialization.  This is much different than an SRL16, where the
configuration bits are the SRL16 state, or even a flip-flop where the state is
part of the initialization.  What am I missing here?

Peter Alfke wrote:

> The LUT content is defined in the bitstream. That defines the original state
> of the latch. Same for SRL16.
> Peter Alfke
>
> >

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

   According to the Virtex-II datasheet, if your SRL16 is configured as 
a simple 16-bit shift register, you have direct access to the 
"shift-out" bit of the register, so it would seem you don't need to 
worry about the LUT inputs.  I believe this essentially bypasses the LUT 
address mux, although I could be wrong.

Ray Andraka wrote:
> The configuration holds the LUTs contents which defines the combinatorial
> function of the LUT, but that does not describe the LUT's output value.  You
> cross couple two luts, but I don't see how you force a particular initial value
> from initialization.  This is much different than an SRL16, where the
> configuration bits are the SRL16 state, or even a flip-flop where the state is
> part of the initialization.  What am I missing here?
> 
> Peter Alfke wrote:
> 
> 
>>The LUT content is defined in the bitstream. That defines the original state
>>of the latch. Same for SRL16.
>>Peter Alfke
>>
>>
> 
> --
> --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
> 
> 

-- 
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --