Global reset question?

[Denis Gleeson]

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

 

[rickman]

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

 

[Peter Alfke]

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

 

[rickman]

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

 

[Ray Andraka]

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

 

[Brian Philofsky]

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

 

[Nicholas C. Weaver]

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

 

[Peter Alfke]

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

 

[Ray Andraka]

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

 

[PO Laprise]

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

 

[Ray Andraka]

I'm not sure what that has to do with my statement, but you are correct, for VirtexII
the SRL16 has a cascade out that is permanently connected to the last 'register' in
the SRL16, which in effect is the same as forcing '1111' on the LUT inputs and
looking at the normal output. The cascade output was a new feature for virtexII.

What Peter was saying is that you can create a latch out of cross-coupled LUTs that
will not be affected by global reset (which is true), however he also seemed to
indicate that you could have that latch come up in a known state on reconfiguration.
My statement simply says that for a LUT, the configuration sets the combinatorial
function of the LUT, but does not determine its output value (the output is
determined by the values of the inputs and the ccombinatorial function assigned to
the LUT). Therefore, the latch created from cross coupled LUTs cannot be directly
assigned an initial value by configuration. To get it to a known state, one of the
set/reset inputs must be asserted, which requires something external to the latch and
explicitly designed in the user logic to accomplish. The SRL16 is different than a
LUT in that it has internal storage accessible to the user circuit. The SRL16 can be
viewed as a LUT whose program can be altered by shifting new bits into it. If held
with the WE='0', it behaves exactly as a LUT, with the output being the value of the
program bit selected by the inputs.

PO Laprise wrote:

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

 

[PO Laprise]

Sorry, my bad. I thought you were referring to his statement on the
use of the SRL16. However, the OP implied that his global clear was
post-power-up. Couldn't there be a way to initialize the latch at
power-up, after which the value would be kept across global clears? I
haven't thought out the details, but it doesn't seem too complicated
(famous last words ... I was under the impression that there was a
way of differentitating power-up reset and subsequent global clears...

Ray Andraka wrote:

I'm not sure what that has to do with my statement, but you are correct, for VirtexII
the SRL16 has a cascade out that is permanently connected to the last 'register' in
the SRL16, which in effect is the same as forcing '1111' on the LUT inputs and
looking at the normal output. The cascade output was a new feature for virtexII.

What Peter was saying is that you can create a latch out of cross-coupled LUTs that
will not be affected by global reset (which is true), however he also seemed to
indicate that you could have that latch come up in a known state on reconfiguration.
My statement simply says that for a LUT, the configuration sets the combinatorial
function of the LUT, but does not determine its output value (the output is
determined by the values of the inputs and the ccombinatorial function assigned to
the LUT). Therefore, the latch created from cross coupled LUTs cannot be directly
assigned an initial value by configuration. To get it to a known state, one of the
set/reset inputs must be asserted, which requires something external to the latch and
explicitly designed in the user logic to accomplish. The SRL16 is different than a
LUT in that it has internal storage accessible to the user circuit. The SRL16 can be
viewed as a LUT whose program can be altered by shifting new bits into it. If held
with the WE='0', it behaves exactly as a LUT, with the output being the value of the
program bit selected by the inputs.

PO Laprise wrote:


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

 

[Nicholas C. Weaver]

In article <7752c.112739$2g.74392@charlie.risq.qc.ca>,
PO Laprise <pl_N0SP4M_apri@cim._N0SP4M_mcgill.ca> wrote:

Sorry, my bad. I thought you were referring to his statement on the
use of the SRL16. However, the OP implied that his global clear was
post-power-up. Couldn't there be a way to initialize the latch at
power-up, after which the value would be kept across global clears? I
haven't thought out the details, but it doesn't seem too complicated
(famous last words ... I was under the impression that there was a
way of differentitating power-up reset and subsequent global clears...

There is. SRL16, initialized to 0x0001, arbitrary delay lenght, with
the input as a 0. The first cycle on startup it will be a 1, but
every cycle thereafter, even after global reset, it will be a 0. If
you want a longer "start high" you can make the initial chain of 1s be
longer. Or use logic to drive a LUT-as-ram which you then set to 0
after enough startup time has passed.

Basically, you observe that LUT-as-RAM, SRL, BlockRAM contents are
preserved across global reset, but start on initialization in a
defined state.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Peter Alfke]

What I wrote is not completely correct, but there is a work-around: use
DONEbar to force a starting value into the latch. Also: the latch is just
one LUT with its output used as one of the inputs. No need for 2 LUTs...
We might also agree that the start-up after power-up is not so important.
All external RAMs (but not the BlockRAMs) come up with unknown content.
Anyhow, the SRL16 solution is the most elegant, and therefore the preferred
solution.
Peter Alfke

From: Ray Andraka <ray@andraka.com
Organization: Andraka Consulting Group, Inc
Newsgroups: comp.arch.fpga
Date: Fri, 05 Mar 2004 12:49:28 -0500
Subject: Re: Global reset question?

I'm not sure what that has to do with my statement, but you are correct, for
VirtexII
the SRL16 has a cascade out that is permanently connected to the last
'register' in
the SRL16, which in effect is the same as forcing '1111' on the LUT inputs and
looking at the normal output. The cascade output was a new feature for
virtexII.

What Peter was saying is that you can create a latch out of cross-coupled LUTs
that
will not be affected by global reset (which is true), however he also seemed
to
indicate that you could have that latch come up in a known state on
reconfiguration.
My statement simply says that for a LUT, the configuration sets the
combinatorial
function of the LUT, but does not determine its output value (the output is
determined by the values of the inputs and the ccombinatorial function
assigned to
the LUT). Therefore, the latch created from cross coupled LUTs cannot be
directly
assigned an initial value by configuration. To get it to a known state, one
of the
set/reset inputs must be asserted, which requires something external to the
latch and
explicitly designed in the user logic to accomplish. The SRL16 is different
than a
LUT in that it has internal storage accessible to the user circuit. The SRL16
can be
viewed as a LUT whose program can be altered by shifting new bits into it. If
held
with the WE='0', it behaves exactly as a LUT, with the output being the value
of the
program bit selected by the inputs.

PO Laprise wrote:

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, 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 Gleeson]

Hi Brian

Thanks for your answer, directed at my problem.

I should have said that at the end of all the warnings I received,
was the following.

Warning: No Global(GSR) net could be used in the design because there
is not a unique net that sets or resets all the sequential cells.

So I am assuming that the STARTUP block has been included, even though
I didnt specifically stipulate that it should.

I am also assuming that my synthesis tool is trying to assign a signal
assigned to a pin as a stimulus for this global net.
As soon as one register is not cleared by this signal the GSR net is
no more.

I ran a simulation to see what I would get. The simulation was done
with the scenario described, i.e. one register is not cleared by the
input "clear" pin and synthesis gives the warnings described.

I get one BUS signal at xxx? and another at 000?. Even though I am
setting my external clear signal high.
This is new and not what I normally get from this simulation. I
normally get things cleared when the
clear signal is high.

From this I assume that my efforts to clear a section of the FPGA
leaving one register un cleared
is not working.

Now this is really confusing me. I have a pin assigned to have an
external signal(with the name clear).
This signal is sent to all FFs and counters in the FPGA in my verilog
code. Now because I have not complied with the requirements for a GSR
signal, I effectivly have no clear?


Many thanks for your input.


Denis
__________________________
From Concept to Production
http://www.centronsolutions.com


Brian Philofsky <brian.philofsky@no_xilinx_spam.com> wrote in message news:<4047ACA2.4010808@no_xilinx_spam.com>...

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