reset strategy FPGA Igloo

[alb]

Dear all,

I fear that I have an issue with reset time propagation all over my
design and this may cause unknown initial conditions after reset.

We have a pll and we use the 'lock' signal as a global reset, in this
way we guarantee that flops are coming out of reset with a fully running
clock.

My question here is the following: should I route the 'lock' signal to a
special buffer to minimize delays or would it be sufficient to use it as is?

Thanks a lot,

Al

p.s.: I'm using Actel Igloo.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Mark Curry]

In article <bbq71aFcrddU1@mid.individual.net>,
alb <alessandro.basili@cern.ch> wrote:

I fear that I have an issue with reset time propagation all over my
design and this may cause unknown initial conditions after reset.

We have a pll and we use the 'lock' signal as a global reset, in this
way we guarantee that flops are coming out of reset with a fully running
clock.

My question here is the following: should I route the 'lock' signal to a
special buffer to minimize delays or would it be sufficient to use it as is?

Not familiar with Igloo family, so can't offer specific advice, but I do
have general advice on the "lock" signal coming out of PLLs.

These signals are notoriously unreliable from many families. They
tend to "chatter" going into lock (i.e. indicating a lock, then falling
out of lock, then back in). This all, of course, can vary by design.
But I now almost always take the tact of casting a suspicicious
eye on a PLL's lock indicator, and usually qualify it with something
else rather than using it raw.

Often, I just take the data sheet "max lock time" spec. I wait
for this time to pass, AND the lock signal to indicate true before
truly declaring lock.

Your mileage may vary - and as I said, I'm not familiar with the igloo
family, so don't know its PLL design at all. But my experience
with PLLs here is from many various designs, in many various technologies
(ASICs at various nodes/various FPGAs).

The second piece of advice I can offer is to have your STA tool check
the timing. You should synchronize your reset, then treat it like
any other signal that's timing checked - you'll know quickly
whether or not you'll need to treat that high-fanout net with special
handing.

Regards,

Mark

 

[glen herrmannsfeldt]

alb <alessandro.basili@cern.ch> wrote:

I fear that I have an issue with reset time propagation all over my
design and this may cause unknown initial conditions after reset.

We have a pll and we use the 'lock' signal as a global reset, in this
way we guarantee that flops are coming out of reset with a fully
running clock.

My question here is the following: should I route the 'lock'
signal to a special buffer to minimize delays or would it be
sufficient to use it as is?

First, I agree with what Mark says.

In addition, note that most FPGA families have a global reset line
similar to the global clock lines. They usually keep all the FF held
at reset until configuration is done, and also allow you to use that
reset line. It is there, it is free, and you might was well use it.

You do still have to get the timing right, so you release it at
the right time relative to the clock edge.

-- glen

 

[Joseph H Allen]

In article <l39dsb$4q1$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

First, I agree with what Mark says.

In addition, note that most FPGA families have a global reset line
similar to the global clock lines. They usually keep all the FF held
at reset until configuration is done, and also allow you to use that
reset line. It is there, it is free, and you might was well use it.

You do still have to get the timing right, so you release it at
the right time relative to the clock edge.

The timing provided by the global reset line is not good.. it's nowhere near
as good as a global clock line as far as I understand.

One way to deal with this is to have all of your state machines start in a
reset state which does nothing but wait for a synchronous "start" edge which
is generated after reset with a counter or a shift register.

This has a big advantage that you no longer have to worry about global reset
timing. On the other hand, if you use libraries you may have no choice
since you can't change the logic.

--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[Mark Curry]

In article <bbr63nFjeruU1@mid.individual.net>,
alb <alessandro.basili@cern.ch> wrote:

Hi Mark,

On 11/10/2013 18:46, Mark Curry wrote:
[]
My question here is the following: should I route the 'lock' signal to a
special buffer to minimize delays or would it be sufficient to use it as
is?
[]
These signals are notoriously unreliable from many families. They
tend to "chatter" going into lock (i.e. indicating a lock, then falling
out of lock, then back in). This all, of course, can vary by design.
But I now almost always take the tact of casting a suspicicious
eye on a PLL's lock indicator, and usually qualify it with something
else rather than using it raw.


That's a big hint! In the past I typically had a 'powerup reset' done
with an external RC line with a big time constant, enough to allow the
clock to be stable. The current design I'm working on had already been
written and I thought the idea of using the internal pll lock signal was
not too bad, but I was not aware of these reliability issues.

That might explain why every third power up nothing works!

Often, I just take the data sheet "max lock time" spec. I wait
for this time to pass, AND the lock signal to indicate true before
truly declaring lock.

Uhm... and how do you reset the counter you need to rely on? Certainly I
can use the 'not lock' signal to keep the counter reset and then add the
extra margin.

The counter needs to explictly NOT be connected to "lock" at all.
The counter should be initialized whenever the PLL begins it's acquisition.
If no explicit reset pin exists, then device init? You need a one shot
or something at end of config. Check docs for Igloo - like I said, I'm
not familiar with the family. Xilinx let you use init values for this
i.e.:

reg one_shot = 1;
always @( posedge clk )
one_shot <= 0;

Would create a one cycle high pulse after init. Modify as needed
for more than one cycle high.

The second piece of advice I can offer is to have your STA tool check
the timing. You should synchronize your reset, then treat it like
any other signal that's timing checked - you'll know quickly
whether or not you'll need to treat that high-fanout net with special
handing.

Checked and found timing violations. Fan-out is ~400. I've seen in the
past reset signals routed through a clockbuffer, is this a wise move?

Depends on FPGA architecture. I believe in Xilinx this wouldn't work,
as the clockbuffer only routes to clocks, not data pins (or resets).
Replicate the source FF maybe? Can you have the tools do this for you?
i.e. create your qualified lock. Pipeline delay it a few cycles,
then let the tool replicate the final stage as much as neccesary.
Depends on the synthesis/PAR tools.

Regards

Mark

 

[alb]

Hi Mark,

On 11/10/2013 18:46, Mark Curry wrote:
[]

My question here is the following: should I route the 'lock' signal to a
special buffer to minimize delays or would it be sufficient to use it as is?
[]
These signals are notoriously unreliable from many families. They
tend to "chatter" going into lock (i.e. indicating a lock, then falling
out of lock, then back in). This all, of course, can vary by design.
But I now almost always take the tact of casting a suspicicious
eye on a PLL's lock indicator, and usually qualify it with something
else rather than using it raw.

That's a big hint! In the past I typically had a 'powerup reset' done
with an external RC line with a big time constant, enough to allow the
clock to be stable. The current design I'm working on had already been
written and I thought the idea of using the internal pll lock signal was
not too bad, but I was not aware of these reliability issues.

That might explain why every third power up nothing works!

Often, I just take the data sheet "max lock time" spec. I wait
for this time to pass, AND the lock signal to indicate true before
truly declaring lock.

Uhm... and how do you reset the counter you need to rely on? Certainly I
can use the 'not lock' signal to keep the counter reset and then add the
extra margin.

Your mileage may vary - and as I said, I'm not familiar with the igloo
family, so don't know its PLL design at all. But my experience
with PLLs here is from many various designs, in many various technologies
(ASICs at various nodes/various FPGAs).

Since I do not have any experience with this strategy at all I guess
that your point is already discouraging enough to continue stubbornly
along this path.

I'll try the 'max lock time' approach and see what it leads to.

The second piece of advice I can offer is to have your STA tool check
the timing. You should synchronize your reset, then treat it like
any other signal that's timing checked - you'll know quickly
whether or not you'll need to treat that high-fanout net with special
handing.

Checked and found timing violations. Fan-out is ~400. I've seen in the
past reset signals routed through a clockbuffer, is this a wise move?

 

[alb]

Hi Glen,

On 11/10/2013 19:52, glen herrmannsfeldt wrote:
[]

My question here is the following: should I route the 'lock'
signal to a special buffer to minimize delays or would it be
sufficient to use it as is?

First, I agree with what Mark says.

and I also start to believe my reset strategy is weak!

In addition, note that most FPGA families have a global reset line
similar to the global clock lines. They usually keep all the FF held
at reset until configuration is done, and also allow you to use that
reset line. It is there, it is free, and you might was well use it.

Apparently I have not found a 'global reset line' for the igloo family,
but there's an interesting application note from Actel/Microsemi on
their Flash-based devices which I find quite interesting:

http://www.actel.com/documents/LPF_AC380_AN.pdf

It boils down to exploiting the difference in power up between input
buffer and output buffer, therefore leading to the possibility to drive
two states for an active/deactive reset.

In the AN it refers to the possibility to extend the reset line with a
counter which is 'preset' by the Power-on Reset (POR), potentially
useful to wait for external circuitry to reach to an operational state
before the FPGA logic starts.

It's unfortunate that in my case I do not have an unused pulled-up pin
and I'm wondering whether I can use the same technique profiting of the
'weak pull-up' capabilities that can be programmed in the I/O. From this AN:

http://www.eettaiwan.com/STATIC/PDF/200811/20081121_Actel_AN03.pdf?SOURCES=DOWNLOAD

it seems that 'weak pull-up/down' will be activated as soon as Vcc and
Vcci are above functional threshold, which is essentially enough to have
a logic '1' driven at the input of the POR proposed in the other note.

You do still have to get the timing right, so you release it at
the right time relative to the clock edge.

This is something I typically do. I keep a couple, if not more, of clock
tics to deactivate the reset. This makes the reset signal like any other
one and no special time constraints are needed.

 

[rickman]

On 10/11/2013 5:46 PM, alb wrote:

Hi Glen,

On 11/10/2013 19:52, glen herrmannsfeldt wrote:
[]
My question here is the following: should I route the 'lock'
signal to a special buffer to minimize delays or would it be
sufficient to use it as is?

First, I agree with what Mark says.

and I also start to believe my reset strategy is weak!

In addition, note that most FPGA families have a global reset line
similar to the global clock lines. They usually keep all the FF held
at reset until configuration is done, and also allow you to use that
reset line. It is there, it is free, and you might was well use it.

Apparently I have not found a 'global reset line' for the igloo family,
but there's an interesting application note from Actel/Microsemi on
their Flash-based devices which I find quite interesting:

http://www.actel.com/documents/LPF_AC380_AN.pdf

Wow, if Actel doesn't have a global reset line I have no idea how they
make their parts work. I haven't read the above app note, but the way
most brands of FPGAs work, there is a global reset line which holds the
user logic in reset until the end of config. This like is similar to a
global clock line, but without the high speed drive. When the reset is
released the entire chip can start. The problem is the delay on this
line is long enough to cause problems releasing the entire design on the
same clock cycle.

It is seldom that an entire FPGA design has to start on the same clock
edge. I design individual circuits to start up on a local copy of the
reset. Or better still is to design them so they start in an idle state
waiting for something else to happen which will take a clock cycle or
two providing enough delay that they don't need a synchronous reset.

It boils down to exploiting the difference in power up between input
buffer and output buffer, therefore leading to the possibility to drive
two states for an active/deactive reset.

In the AN it refers to the possibility to extend the reset line with a
counter which is 'preset' by the Power-on Reset (POR), potentially
useful to wait for external circuitry to reach to an operational state
before the FPGA logic starts.

It's unfortunate that in my case I do not have an unused pulled-up pin
and I'm wondering whether I can use the same technique profiting of the
'weak pull-up' capabilities that can be programmed in the I/O. From this AN:

http://www.eettaiwan.com/STATIC/PDF/200811/20081121_Actel_AN03.pdf?SOURCES=DOWNLOAD

it seems that 'weak pull-up/down' will be activated as soon as Vcc and
Vcci are above functional threshold, which is essentially enough to have
a logic '1' driven at the input of the POR proposed in the other note.

Are you saying you have designed the board without consideration to
resetting the FPGA? I can't imagine the Actel parts require an external
reset. I'm glad I am finding this out now.

You do still have to get the timing right, so you release it at
the right time relative to the clock edge.

This is something I typically do. I keep a couple, if not more, of clock
tics to deactivate the reset. This makes the reset signal like any other
one and no special time constraints are needed.

Yes.

--

Rick

 

[Alan Reynolds]

On 2013-10-13 03:18:43 +0000, rickman said:

On 10/11/2013 5:46 PM, alb wrote:
Hi Glen,

On 11/10/2013 19:52, glen herrmannsfeldt wrote:
[]
My question here is the following: should I route the 'lock'
signal to a special buffer to minimize delays or would it be
sufficient to use it as is?

First, I agree with what Mark says.

and I also start to believe my reset strategy is weak!

In addition, note that most FPGA families have a global reset line
similar to the global clock lines. They usually keep all the FF held
at reset until configuration is done, and also allow you to use that
reset line. It is there, it is free, and you might was well use it.

Apparently I have not found a 'global reset line' for the igloo family,
but there's an interesting application note from Actel/Microsemi on
their Flash-based devices which I find quite interesting:

http://www.actel.com/documents/LPF_AC380_AN.pdf

Wow, if Actel doesn't have a global reset line I have no idea how they
make their parts work. I haven't read the above app note, but the way
most brands of FPGAs work, there is a global reset line which holds the
user logic in reset until the end of config. This like is similar to a
global clock line, but without the high speed drive. When the reset is
released the entire chip can start. The problem is the delay on this
line is long enough to cause problems releasing the entire design on
the same clock cycle.

Actel/Microsemi FPGAs are FLASH so don't need configuration. You have
to reset them in the same way you would an ASIC.

It is seldom that an entire FPGA design has to start on the same clock
edge. I design individual circuits to start up on a local copy of the
reset. Or better still is to design them so they start in an idle
state waiting for something else to happen which will take a clock
cycle or two providing enough delay that they don't need a synchronous
reset.

Designing for all-IDLE FSMs is the proper approach but doesn't
eliminate the need to have an explicit reset. Global resources are
typically used for the RESET even when timing is not an issue to remove
the routing burden of thousands of loads. The locally copied RESETs are
usually only useful if you need to support synchronous resets.

It boils down to exploiting the difference in power up between input
buffer and output buffer, therefore leading to the possibility to drive
two states for an active/deactive reset.

In the AN it refers to the possibility to extend the reset line with a
counter which is 'preset' by the Power-on Reset (POR), potentially
useful to wait for external circuitry to reach to an operational state
before the FPGA logic starts.

It's unfortunate that in my case I do not have an unused pulled-up pin
and I'm wondering whether I can use the same technique profiting of the
'weak pull-up' capabilities that can be programmed in the I/O. From this AN:

http://www.eettaiwan.com/STATIC/PDF/200811/20081121_Actel_AN03.pdf?SOURCES=DOWNLOAD


it seems that 'weak pull-up/down' will be activated as soon as Vcc and
Vcci are above functional threshold, which is essentially enough to have
a logic '1' driven at the input of the POR proposed in the other note.

Are you saying you have designed the board without consideration to
resetting the FPGA? I can't imagine the Actel parts require an
external reset. I'm glad I am finding this out now.


You do still have to get the timing right, so you release it at
the right time relative to the clock edge.

This is something I typically do. I keep a couple, if not more, of clock
tics to deactivate the reset. This makes the reset signal like any other
one and no special time constraints are needed.

Yes.

 

[alb]

On 13/10/2013 05:18, rickman wrote:
[]

Apparently I have not found a 'global reset line' for the igloo family,
but there's an interesting application note from Actel/Microsemi on
their Flash-based devices which I find quite interesting:

http://www.actel.com/documents/LPF_AC380_AN.pdf

Wow, if Actel doesn't have a global reset line I have no idea how they
make their parts work.

please do not take my words for granted. Maybe I haven't looked careful
enough. OTOH I've worked with Actel components since a lot and found
them very easy to handle (provided the board designer puts in a powerup
reset circuitry!).

I haven't read the above app note, but the way
most brands of FPGAs work, there is a global reset line which holds the
user logic in reset until the end of config. This like is similar to a
global clock line, but without the high speed drive. When the reset is
released the entire chip can start. The problem is the delay on this
line is long enough to cause problems releasing the entire design on the
same clock cycle.

They are 'live at power up' (LAPU). See here for more information:

http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf

(warning: it took me a long time to download the file even though the
size is relatively small - 727KB)

It is seldom that an entire FPGA design has to start on the same clock
edge. I design individual circuits to start up on a local copy of the
reset. Or better still is to design them so they start in an idle state
waiting for something else to happen which will take a clock cycle or
two providing enough delay that they don't need a synchronous reset.

I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
approach but doesn't eliminate the need to have an explicit reset"

it seems that 'weak pull-up/down' will be activated as soon as Vcc and
Vcci are above functional threshold, which is essentially enough to have
a logic '1' driven at the input of the POR proposed in the other note.

Are you saying you have designed the board without consideration to
resetting the FPGA? I can't imagine the Actel parts require an external
reset. I'm glad I am finding this out now.

I jumped in the project far after those details were left out of the
design phase. How do you reset your logic only through the internal
resources of your device?

 

[rickman]

On 10/13/2013 7:39 AM, Alan Reynolds wrote:

On 2013-10-13 03:18:43 +0000, rickman said:

On 10/11/2013 5:46 PM, alb wrote:
Hi Glen,

On 11/10/2013 19:52, glen herrmannsfeldt wrote:
[]
My question here is the following: should I route the 'lock'
signal to a special buffer to minimize delays or would it be
sufficient to use it as is?

First, I agree with what Mark says.

and I also start to believe my reset strategy is weak!

In addition, note that most FPGA families have a global reset line
similar to the global clock lines. They usually keep all the FF held
at reset until configuration is done, and also allow you to use that
reset line. It is there, it is free, and you might was well use it.

Apparently I have not found a 'global reset line' for the igloo family,
but there's an interesting application note from Actel/Microsemi on
their Flash-based devices which I find quite interesting:

http://www.actel.com/documents/LPF_AC380_AN.pdf

Wow, if Actel doesn't have a global reset line I have no idea how they
make their parts work. I haven't read the above app note, but the way
most brands of FPGAs work, there is a global reset line which holds
the user logic in reset until the end of config. This like is similar
to a global clock line, but without the high speed drive. When the
reset is released the entire chip can start. The problem is the delay
on this line is long enough to cause problems releasing the entire
design on the same clock cycle.

Actel/Microsemi FPGAs are FLASH so don't need configuration. You have to
reset them in the same way you would an ASIC.

I don't think that is relevant to the discussion. What you call it
doesn't matter, the point is that the device must have some way to reset
all the user FFs at power up and also when controlled by the user. In
the Xilinx devices the problem comes from the fact that this global
reset signal is not fast enough to assure all FFs are reset or released
from reset in the same clock cycle. That is the issue.

So do the Actel devices have a global reset/set signal? Is it fast
enough to control all FFs in the same clock cycle?

It is seldom that an entire FPGA design has to start on the same clock
edge. I design individual circuits to start up on a local copy of the
reset. Or better still is to design them so they start in an idle
state waiting for something else to happen which will take a clock
cycle or two providing enough delay that they don't need a synchronous
reset.

Designing for all-IDLE FSMs is the proper approach but doesn't eliminate
the need to have an explicit reset. Global resources are typically used
for the RESET even when timing is not an issue to remove the routing
burden of thousands of loads. The locally copied RESETs are usually only
useful if you need to support synchronous resets.

Yes, I agree, but I don't get your point. I am discussing the global
reset signal, does the Actel devices have one.

The local resets are for things that *do* need to start up on the same
clock cycle; call it a synchronous reset then. A free running state
machine is a good example. A counter is another.

--

Rick

 

[rickman]

On 10/14/2013 4:35 PM, alb wrote:

On 13/10/2013 05:18, rickman wrote:
[]
Apparently I have not found a 'global reset line' for the igloo family,
but there's an interesting application note from Actel/Microsemi on
their Flash-based devices which I find quite interesting:

http://www.actel.com/documents/LPF_AC380_AN.pdf

Wow, if Actel doesn't have a global reset line I have no idea how they
make their parts work.

please do not take my words for granted. Maybe I haven't looked careful
enough. OTOH I've worked with Actel components since a lot and found
them very easy to handle (provided the board designer puts in a powerup
reset circuitry!).

I'm trying to understand what you *are* saying about the reset. Does
Actel provide a mechanism so that each FF is brought out of reset on the
same clock cycle? This makes a *big* difference in how you design your
reset operation.

I think you are saying the FPGA has an external reset pin which the
board controls. Good. Does your board control that? What does the
reset do on the FPGA exactly?

I haven't read the above app note, but the way
most brands of FPGAs work, there is a global reset line which holds the
user logic in reset until the end of config. This like is similar to a
global clock line, but without the high speed drive. When the reset is
released the entire chip can start. The problem is the delay on this
line is long enough to cause problems releasing the entire design on the
same clock cycle.

They are 'live at power up' (LAPU). See here for more information:

http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf

(warning: it took me a long time to download the file even though the
size is relatively small - 727KB)

I don't care if they are live at power up. Is that relevant? I'm
trying to understand the reset process.

It is seldom that an entire FPGA design has to start on the same clock
edge. I design individual circuits to start up on a local copy of the
reset. Or better still is to design them so they start in an idle state
waiting for something else to happen which will take a clock cycle or
two providing enough delay that they don't need a synchronous reset.

I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
approach but doesn't eliminate the need to have an explicit reset"

Maybe I don't understand what you are saying at all. Hopefully you will
explain exactly what the problem is. Is there *no* reset to the FPGA on
your board?

it seems that 'weak pull-up/down' will be activated as soon as Vcc and
Vcci are above functional threshold, which is essentially enough to have
a logic '1' driven at the input of the POR proposed in the other note.

Are you saying you have designed the board without consideration to
resetting the FPGA? I can't imagine the Actel parts require an external
reset. I'm glad I am finding this out now.

I jumped in the project far after those details were left out of the
design phase. How do you reset your logic only through the internal
resources of your device?

So are you saying there is no external reset on the board for the FPGA?
Why can't you add one? The need for this seems like a no-brainer even
if it is a white wire job.

If there is no reset, what can you know about the state of the FFs on
powerup? If they are random, I don't think you can make this work
without a power up reset.

Ah! I went back to your initial post about the PLL lock signal.
Assuming this signal is meaningful at all times I would expect it to be
"unlock" (as opposed to "lock") at power up. If that is true then I
think you can condition it to give you a reset to your logic.

A small circuit consisting of a long period counter can be held in reset
while the PLL is not locked. The rest of the design is held in reset by
the counter. When the counter reaches its final state, implying the PLL
lock signal has been valid long enough to actually indicate a true PLL
lock, the reset to the rest of the logic is released.

Maybe this is obvious to you. If so, I don't understand what your
question is.

To tell you the truth, I would try discussing this with an Actel FAE.
Hopefully they know the answer.

--

Rick

 

[Alan Reynolds]

On 2013-10-15 01:59:34 +0000, rickman said:

On 10/14/2013 4:35 PM, alb wrote:
On 13/10/2013 05:18, rickman wrote:
[]
Apparently I have not found a 'global reset line' for the igloo family,
but there's an interesting application note from Actel/Microsemi on
their Flash-based devices which I find quite interesting:

http://www.actel.com/documents/LPF_AC380_AN.pdf

Wow, if Actel doesn't have a global reset line I have no idea how they
make their parts work.

please do not take my words for granted. Maybe I haven't looked careful
enough. OTOH I've worked with Actel components since a lot and found
them very easy to handle (provided the board designer puts in a powerup
reset circuitry!).

I'm trying to understand what you *are* saying about the reset. Does
Actel provide a mechanism so that each FF is brought out of reset on
the same clock cycle? This makes a *big* difference in how you design
your reset operation.

Non-FLASH FPGAs have to be configured on power-on so the reseting of
FFs is a by-product of that activity which allows for the deassertion
of the configuration RESET *after* every FF has been configured to a
known value. Like an ASIC, Actel parts require and explicit POR
because they do not have a configuration sequence. If the POR signal
(or logic output) is placed on a global net and your design frequency
is below insertion delay plus skew of the global net and the POR is
synchronously deasserted then every FF in the chip will be in the reset
state in the same clock cycle. Again, this is the same consideration
you have to use when reseting an ASIC.

I think you are saying the FPGA has an external reset pin which the
board controls. Good. Does your board control that? What does the
reset do on the FPGA exactly?


I haven't read the above app note, but the way
most brands of FPGAs work, there is a global reset line which holds the
user logic in reset until the end of config. This like is similar to a
global clock line, but without the high speed drive. When the reset is
released the entire chip can start. The problem is the delay on this
line is long enough to cause problems releasing the entire design on the
same clock cycle.

They are 'live at power up' (LAPU). See here for more information:

http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf

(warning: it took me a long time to download the file even though the
size is relatively small - 727KB)

I don't care if they are live at power up. Is that relevant? I'm
trying to understand the reset process.

No configuration sequence means no global reset.

It is seldom that an entire FPGA design has to start on the same clock
edge. I design individual circuits to start up on a local copy of the
reset. Or better still is to design them so they start in an idle state
waiting for something else to happen which will take a clock cycle or
two providing enough delay that they don't need a synchronous reset.

I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
approach but doesn't eliminate the need to have an explicit reset"

Maybe I don't understand what you are saying at all. Hopefully you
will explain exactly what the problem is. Is there *no* reset to the
FPGA on your board?


it seems that 'weak pull-up/down' will be activated as soon as Vcc and
Vcci are above functional threshold, which is essentially enough to have
a logic '1' driven at the input of the POR proposed in the other note.

Are you saying you have designed the board without consideration to
resetting the FPGA? I can't imagine the Actel parts require an external
reset. I'm glad I am finding this out now.

I jumped in the project far after those details were left out of the
design phase. How do you reset your logic only through the internal
resources of your device?

So are you saying there is no external reset on the board for the FPGA?
Why can't you add one? The need for this seems like a no-brainer
even if it is a white wire job.

If there is no reset, what can you know about the state of the FFs on
powerup? If they are random, I don't think you can make this work
without a power up reset.

Ah! I went back to your initial post about the PLL lock signal.
Assuming this signal is meaningful at all times I would expect it to be
"unlock" (as opposed to "lock") at power up. If that is true then I
think you can condition it to give you a reset to your logic.

A small circuit consisting of a long period counter can be held in
reset while the PLL is not locked. The rest of the design is held in
reset by the counter. When the counter reaches its final state,
implying the PLL lock signal has been valid long enough to actually
indicate a true PLL lock, the reset to the rest of the logic is
released.

This is a perfectly reasonable approach and one that I have used when
the stability of LOCK was a potential issue.

Maybe this is obvious to you. If so, I don't understand what your question is.

To tell you the truth, I would try discussing this with an Actel FAE.
Hopefully they know the answer.

 

[rickman]

On 10/15/2013 8:34 AM, Alan Reynolds wrote:

On 2013-10-15 01:59:34 +0000, rickman said:

On 10/14/2013 4:35 PM, alb wrote:
On 13/10/2013 05:18, rickman wrote:
[]
Apparently I have not found a 'global reset line' for the igloo
family,
but there's an interesting application note from Actel/Microsemi on
their Flash-based devices which I find quite interesting:

http://www.actel.com/documents/LPF_AC380_AN.pdf

Wow, if Actel doesn't have a global reset line I have no idea how they
make their parts work.

please do not take my words for granted. Maybe I haven't looked careful
enough. OTOH I've worked with Actel components since a lot and found
them very easy to handle (provided the board designer puts in a powerup
reset circuitry!).

I'm trying to understand what you *are* saying about the reset. Does
Actel provide a mechanism so that each FF is brought out of reset on
the same clock cycle? This makes a *big* difference in how you design
your reset operation.

Non-FLASH FPGAs have to be configured on power-on so the reseting of FFs
is a by-product of that activity which allows for the deassertion of the
configuration RESET *after* every FF has been configured to a known
value. Like an ASIC, Actel parts require and explicit POR because they
do not have a configuration sequence. If the POR signal (or logic
output) is placed on a global net and your design frequency is below
insertion delay plus skew of the global net and the POR is synchronously
deasserted then every FF in the chip will be in the reset state in the
same clock cycle. Again, this is the same consideration you have to use
when reseting an ASIC.

Thanks. I don't need an explanation of what a Flash or RAM based FPGA
is, I need to know what mechanism is provided in the Actel FPGAs for
resetting all the FFs in your design on power up or external reset
signal. Is there *any* specific resource for this? Or is it up to the
synthesis tool to use the otherwise available routing? This makes it
sound like there are no specific features to support reset of the FFs.

I can't imagine there wouldn't be a clear explanation somewhere of how
this is intended to be done.

I think you are saying the FPGA has an external reset pin which the
board controls. Good. Does your board control that? What does the
reset do on the FPGA exactly?


I haven't read the above app note, but the way
most brands of FPGAs work, there is a global reset line which holds the
user logic in reset until the end of config. This like is similar to a
global clock line, but without the high speed drive. When the reset is
released the entire chip can start. The problem is the delay on this
line is long enough to cause problems releasing the entire design on
the
same clock cycle.

They are 'live at power up' (LAPU). See here for more information:

http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf

(warning: it took me a long time to download the file even though the
size is relatively small - 727KB)

I don't care if they are live at power up. Is that relevant? I'm
trying to understand the reset process.

No configuration sequence means no global reset.

No, no configuration means no configuration. The global reset is an
entirely separate feature.

I jumped in the project far after those details were left out of the
design phase. How do you reset your logic only through the internal
resources of your device?

So are you saying there is no external reset on the board for the
FPGA? Why can't you add one? The need for this seems like a no-brainer
even if it is a white wire job.

If there is no reset, what can you know about the state of the FFs on
powerup? If they are random, I don't think you can make this work
without a power up reset.

Ah! I went back to your initial post about the PLL lock signal.
Assuming this signal is meaningful at all times I would expect it to
be "unlock" (as opposed to "lock") at power up. If that is true then I
think you can condition it to give you a reset to your logic.

A small circuit consisting of a long period counter can be held in
reset while the PLL is not locked. The rest of the design is held in
reset by the counter. When the counter reaches its final state,
implying the PLL lock signal has been valid long enough to actually
indicate a true PLL lock, the reset to the rest of the logic is released.

This is a perfectly reasonable approach and one that I have used when
the stability of LOCK was a potential issue.

It does not resolve the issue of how the reset reaches the rest of the
FFs in the device. I find it hard to believe that there is no global
reset feature in an Actel device. This means the general routing or
possibly clock routing must be used.

Maybe this is obvious to you. If so, I don't understand what your
question is.

To tell you the truth, I would try discussing this with an Actel FAE.
Hopefully they know the answer.

I remember when FAEs used to respond to posts here. But then some of
them generated some rather bad press for their company with a rather
confrontational style.

--

Rick

 

[alb]

Hi Rick,

On 15/10/2013 03:59, rickman wrote:
[]

Wow, if Actel doesn't have a global reset line I have no idea how they
make their parts work.
please do not take my words for granted. Maybe I haven't looked careful
enough. OTOH I've worked with Actel components since a lot and found
them very easy to handle (provided the board designer puts in a powerup
reset circuitry!).

I'm trying to understand what you *are* saying about the reset. Does
Actel provide a mechanism so that each FF is brought out of reset on the
same clock cycle? This makes a *big* difference in how you design your
reset operation.

No. You need to take care of it on your own, externally (with dedicated
circuitry) and internally (with dedicated logic).

I think you are saying the FPGA has an external reset pin which the
board controls. Good. Does your board control that? What does the
reset do on the FPGA exactly?

In the design I'm working on there's no external reset circuitry on the
pcb and no pin is reserved for this purpose except for an 'init' pin
which can be activated upon certain conditions which, as of now, do not
include power on.

I've not yet found any dedicated pin and/or buffer to route the reset in
the IGLOO family.

I haven't read the above app note, but the way
most brands of FPGAs work, there is a global reset line which holds the
user logic in reset until the end of config. This like is similar to a
global clock line, but without the high speed drive. When the reset is
released the entire chip can start. The problem is the delay on this
line is long enough to cause problems releasing the entire design on the
same clock cycle.

They are 'live at power up' (LAPU). See here for more information:

http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf

(warning: it took me a long time to download the file even though the
size is relatively small - 727KB)

I don't care if they are live at power up. Is that relevant? I'm
trying to understand the reset process.

I mentioned the 'live at power up' feature to refer to the fact that
they *do not need* a configuration.

It is seldom that an entire FPGA design has to start on the same clock
edge. I design individual circuits to start up on a local copy of the
reset. Or better still is to design them so they start in an idle state
waiting for something else to happen which will take a clock cycle or
two providing enough delay that they don't need a synchronous reset.

I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
approach but doesn't eliminate the need to have an explicit reset"

Maybe I don't understand what you are saying at all. Hopefully you will
explain exactly what the problem is. Is there *no* reset to the FPGA on
your board?

Correct, there's *no* reset to the FPGA on my board.

[]

I jumped in the project far after those details were left out of the
design phase. How do you reset your logic only through the internal
resources of your device?

So are you saying there is no external reset on the board for the FPGA?
Why can't you add one? The need for this seems like a no-brainer even
if it is a white wire job.

A white wire job will not help you since you need at least an RC
pulled-up to Vcc and C might be the equivalent of 4 caps (a series of
two parallel ones) to avoid single point failure and hold the FPGA in
reset state permanently upon a short fault on the cap.

Besides, we are about to enter flight module production (it's a space
application) and we cannot functionally deviate from the qualification
module (at least this are the rules we have to follow).

If there is no reset, what can you know about the state of the FFs on
powerup? If they are random, I don't think you can make this work
without a power up reset.

In the AN I posted there's a solution the vendor proposes to implement a
POR. They suggest to rely on an external weak pull-up and profit of the
different time for input/output configuration during a power-up
sequence. I do not have an external pull-up, but I/Os can be opted with
a weak pull-up and maybe the result is the same.

[]

A small circuit consisting of a long period counter can be held in reset
while the PLL is not locked. The rest of the design is held in reset by
the counter. When the counter reaches its final state, implying the PLL
lock signal has been valid long enough to actually indicate a true PLL
lock, the reset to the rest of the logic is released.

I'll set the counter to count the maximum lock time as specified in the
datasheet and I should be good to go. Synchronous release of the reset
line should make it simple to perform STA on the reset line and let the
P&R meet the time constraints.

Maybe this is obvious to you. If so, I don't understand what your
question is.

In the OP, I was asking whether I should route the reset signal
(currently coming from the 'lock' signal on the pll) to a special global
net to avoid timing issues. After my post, Mark pointed out how
unreliable are 'lock' signals from PLL and hence the whole discussion.

To tell you the truth, I would try discussing this with an Actel FAE.
Hopefully they know the answer.

That is a valid suggestion, I used to believe that places like this one
would have been good ones to get an answer from an FAE, <rant mode on>
but it seems those days are gone and companies tend to continue to lock
in users within their closed circles <rant mode off>.

 

[rickman]

On 10/16/2013 4:02 AM, alb wrote:

Hi Rick,

On 15/10/2013 03:59, rickman wrote:
[]
Wow, if Actel doesn't have a global reset line I have no idea how they
make their parts work.
please do not take my words for granted. Maybe I haven't looked careful
enough. OTOH I've worked with Actel components since a lot and found
them very easy to handle (provided the board designer puts in a powerup
reset circuitry!).

I'm trying to understand what you *are* saying about the reset. Does
Actel provide a mechanism so that each FF is brought out of reset on the
same clock cycle? This makes a *big* difference in how you design your
reset operation.

No. You need to take care of it on your own, externally (with dedicated
circuitry) and internally (with dedicated logic).

I think you are saying the FPGA has an external reset pin which the
board controls. Good. Does your board control that? What does the
reset do on the FPGA exactly?

In the design I'm working on there's no external reset circuitry on the
pcb and no pin is reserved for this purpose except for an 'init' pin
which can be activated upon certain conditions which, as of now, do not
include power on.

I've not yet found any dedicated pin and/or buffer to route the reset in
the IGLOO family.

I haven't read the above app note, but the way
most brands of FPGAs work, there is a global reset line which holds the
user logic in reset until the end of config. This like is similar to a
global clock line, but without the high speed drive. When the reset is
released the entire chip can start. The problem is the delay on this
line is long enough to cause problems releasing the entire design on the
same clock cycle.

They are 'live at power up' (LAPU). See here for more information:

http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf

(warning: it took me a long time to download the file even though the
size is relatively small - 727KB)

I don't care if they are live at power up. Is that relevant? I'm
trying to understand the reset process.

I mentioned the 'live at power up' feature to refer to the fact that
they *do not need* a configuration.

It is seldom that an entire FPGA design has to start on the same clock
edge. I design individual circuits to start up on a local copy of the
reset. Or better still is to design them so they start in an idle state
waiting for something else to happen which will take a clock cycle or
two providing enough delay that they don't need a synchronous reset.

I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
approach but doesn't eliminate the need to have an explicit reset"

Maybe I don't understand what you are saying at all. Hopefully you will
explain exactly what the problem is. Is there *no* reset to the FPGA on
your board?

Correct, there's *no* reset to the FPGA on my board.

[]
I jumped in the project far after those details were left out of the
design phase. How do you reset your logic only through the internal
resources of your device?

So are you saying there is no external reset on the board for the FPGA?
Why can't you add one? The need for this seems like a no-brainer even
if it is a white wire job.

A white wire job will not help you since you need at least an RC
pulled-up to Vcc and C might be the equivalent of 4 caps (a series of
two parallel ones) to avoid single point failure and hold the FPGA in
reset state permanently upon a short fault on the cap.

Besides, we are about to enter flight module production (it's a space
application) and we cannot functionally deviate from the qualification
module (at least this are the rules we have to follow).

If there is no reset, what can you know about the state of the FFs on
powerup? If they are random, I don't think you can make this work
without a power up reset.

In the AN I posted there's a solution the vendor proposes to implement a
POR. They suggest to rely on an external weak pull-up and profit of the
different time for input/output configuration during a power-up
sequence. I do not have an external pull-up, but I/Os can be opted with
a weak pull-up and maybe the result is the same.

[]
A small circuit consisting of a long period counter can be held in reset
while the PLL is not locked. The rest of the design is held in reset by
the counter. When the counter reaches its final state, implying the PLL
lock signal has been valid long enough to actually indicate a true PLL
lock, the reset to the rest of the logic is released.

I'll set the counter to count the maximum lock time as specified in the
datasheet and I should be good to go. Synchronous release of the reset
line should make it simple to perform STA on the reset line and let the
P&R meet the time constraints.

Maybe this is obvious to you. If so, I don't understand what your
question is.

In the OP, I was asking whether I should route the reset signal
(currently coming from the 'lock' signal on the pll) to a special global
net to avoid timing issues. After my post, Mark pointed out how
unreliable are 'lock' signals from PLL and hence the whole discussion.

To tell you the truth, I would try discussing this with an Actel FAE.
Hopefully they know the answer.

That is a valid suggestion, I used to believe that places like this one
would have been good ones to get an answer from an FAE,<rant mode on
but it seems those days are gone and companies tend to continue to lock
in users within their closed circles<rant mode off>.

Ok, I think I understand the problem now. The fact that you are working
on a space application makes it more clear why you are using an Actel
part. I think space applications are what kept Actel alive for so many
years.

So you have a poor hardware design that you can't change and you are
looking for some trick within the FPGA to generate a power on reset.
I'm still not clear on why you can't use the PLL lock signal with
conditioning. If the PLL lock signal is deasserted at power on, there
is your power on reset. Then you simply need to condition it well
enough to properly control exit from reset reliably.

Am I still missing something?

--

Rick

 

[Joseph H Allen]

In article <bc6vftF32k1U1@mid.individual.net>,
alb <alessandro.basili@cern.ch> wrote:

In the design I'm working on there's no external reset circuitry on the
pcb and no pin is reserved for this purpose except for an 'init' pin
which can be activated upon certain conditions which, as of now, do not
include power on.

A white wire job will not help you since you need at least an RC
pulled-up to Vcc and C might be the equivalent of 4 caps (a series of
two parallel ones) to avoid single point failure and hold the FPGA in
reset state permanently upon a short fault on the cap.

Besides, we are about to enter flight module production (it's a space
application) and we cannot functionally deviate from the qualification
module (at least this are the rules we have to follow).

Well one hack is to make a probabilistically correct reset pulse generator.
Use a counter to generate a reset pulse and use random values for the start
and end of the pulse. The counter will come up in some random state, but
most of the time you will still get a good reset pulse. With enough bits
you should be able to get the chance of failure to be very small.. I
suspect an asynchronous counter will be better for this since (if you can
make on ein Igloo) it will be less likely that a clock glitch will upset the
entire count value.

I might do it if the FPGA is running an experiment. I would not do it if
the FPGA is for a flight critical system: but then you should have TMR
anyway.

--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[Joseph H Allen]

In article <l3mbf3$mc1$1@pcls7.std.com>,
Joseph H Allen <jhallen@TheWorld.com> wrote:

In article <bc6vftF32k1U1@mid.individual.net>,
alb <alessandro.basili@cern.ch> wrote:
In the design I'm working on there's no external reset circuitry on the
pcb and no pin is reserved for this purpose except for an 'init' pin
which can be activated upon certain conditions which, as of now, do not
include power on.

A white wire job will not help you since you need at least an RC
pulled-up to Vcc and C might be the equivalent of 4 caps (a series of
two parallel ones) to avoid single point failure and hold the FPGA in
reset state permanently upon a short fault on the cap.

Besides, we are about to enter flight module production (it's a space
application) and we cannot functionally deviate from the qualification
module (at least this are the rules we have to follow).

Well one hack is to make a probabilistically correct reset pulse generator.
Use a counter to generate a reset pulse and use random values for the start
and end of the pulse. The counter will come up in some random state, but
most of the time you will still get a good reset pulse. With enough bits
you should be able to get the chance of failure to be very small.. I
suspect an asynchronous counter will be better for this since (if you can
make on ein Igloo) it will be less likely that a clock glitch will upset the
entire count value.

I might do it if the FPGA is running an experiment. I would not do it if
the FPGA is for a flight critical system: but then you should have TMR
anyway.

Here is the idea in code:

reg [7:0] cntr_1; // Powers up to some random value..
reg [7:0] cntr_2; // Chance is not high that they all power up to
reg [7:0] cntr_3; // their final value.
reg [7:0] cntr_4;

reg reset_l_1;
reg reset_l_2;
reg reset_l; // Main reset net

always @(posedge clk)
begin
if (lock && cntr_1 != 8'h55) cntr_1 <= cntr_1 + 1'd1;
if (lock && cntr_2 != 8'hAA) cntr_2 <= cntr_2 + 1'd1;
if (lock && cntr_3 != 8'hbb) cntr_3 <= cntr_3 + 1'd1;
if (lock && cntr_4 != 8'h33) cntr_4 <= cntr_4 + 1'd1;
reset_l_2 <= (cntr_1 == 8'h55) && (cntr_2 == 8'haa) && (cntr_3 == 8'hbb)
&& (cntr_4 == 8'h33);
reset_l_1 <= reset_l_2;
reset_l <= reset_l_1;
end

Should be 1 / 2^32 chance of not having a good reset...
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[alb]

Hi Rick,

On 16/10/2013 10:29, rickman wrote:
[]

Ok, I think I understand the problem now. The fact that you are working
on a space application makes it more clear why you are using an Actel
part. I think space applications are what kept Actel alive for so many
years.

and automotive, avionics, defense, just to mention a few more.

So you have a poor hardware design that you can't change and you are
looking for some trick within the FPGA to generate a power on reset.

correct.

I'm
still not clear on why you can't use the PLL lock signal with
conditioning. If the PLL lock signal is deasserted at power on, there
is your power on reset. Then you simply need to condition it well
enough to properly control exit from reset reliably.

Am I still missing something?

Maybe you missed what I wrote in my previous post in reply to your
suggestion, so I'll paste it here for your convenience:

I'll set the counter to count the maximum lock time as specified in the
datasheet and I should be good to go. Synchronous release of the reset
line should make it simple to perform STA on the reset line and let the
P&R meet the time constraints.

Exactly as you proposed but specifying the length of the counter.

Indeed there's even a more subtle detail to add: since I do not know
what is the state of the lock signal at power up, my counter should have
a fixed value at reset and start to count when lock signal is deasserted
if and only if the fixed value of the counter is present. In this way I
can guarantee that a lock signal which is undefined at the beginning
does not allow the counter to start from a random position and hit the
target value too early. Something along these lines:

<code: not tested!>
-- rst is the lock signal from PLL
process (clk, rst)
if rst = '0' then
counter <= "101001000000"; -- 6 bit counter + 6 bit check
global_rst <= '0'; -- active low reset
elsif rising_edge(clk) then
if counter (11 downto 6) = "101001" then
counter <= counter + 1;
elsif counter (6) = '0' then
global_rst <= '1';
end if;
end if;
end process;
</code>

I'm not sure the synthesis will prune the upper end of the bits, so I
might need to do something more clever, but the upper part of the
counter is to verify that it did have a proper reset signal at some point.

 

[Mark Curry]

In article <l3mli5$g8o$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:

On 10/11/2013 3:43 PM, Joseph H Allen wrote:
In article<l39dsb$4q1$1@speranza.aioe.org>,
glen herrmannsfeldt<gah@ugcs.caltech.edu> wrote:

First, I agree with what Mark says.

In addition, note that most FPGA families have a global reset line
similar to the global clock lines. They usually keep all the FF held
at reset until configuration is done, and also allow you to use that
reset line. It is there, it is free, and you might was well use it.

You do still have to get the timing right, so you release it at
the right time relative to the clock edge.

The timing provided by the global reset line is not good.. it's nowhere near
as good as a global clock line as far as I understand.

One way to deal with this is to have all of your state machines start in a
reset state which does nothing but wait for a synchronous "start" edge which
is generated after reset with a counter or a shift register.

This has a big advantage that you no longer have to worry about global reset
timing. On the other hand, if you use libraries you may have no choice
since you can't change the logic.

This really doesn't solve the problem. The problem is that globally
resetting all the state machines in a design can tax the routing and
timing of the global reset signal. If you do this the routing problem
can be fixed by resynchronizing the reset to the clock before using it
in a given section of logic that should be geographically local on the
chip. Otherwise you can give P&R some very tough problems to solve.

Wow - can't keep up - lots of replies here. The GSR from Xilinx isn't
the end all solution that Xilinx touts it as. The release of the global
GSR is completely asynchronous. It doesn't really matter much that
router may have trouble routing this signal with low skew. It's
asynchronous - Murphy's law says that one FFs going to see the inactive
edge of reset on one clock edge - the next FF's going to see the it on the
following clock cycle. Low skew likely lowers the likelihood of the event,
but it can happen none-the-less and should be accounted for in your design.

I've gone into this in the Xilinx forums some, but you've got to be careful
on using that GSR...

Regards,

Mark