Altera ACEX chip wide reset

I am trying to decide if I should use a chip wide reset on an Altera
ACEX 1K part.  In reading how this works, it appears that the FFs are
actually only able to be reset or "loaded with a '1'" using an async
signal.  So if I am not using a signal to preset a FF in my design, but
just want the power on/chip wide reset state to be a '1', how would I
code that in VHDL?  Is this like the Xilinx tools where you code in a
chip wide reset and then drive it with a special module?  Or do I
explicitly drive it from the chip wide reset pin and the tool figures it
out?  

-- 

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 <spamgoeshere4@yahoo.com> wrote in message news:<40390862.222DCE7F@yahoo.com>...
> I am trying to decide if I should use a chip wide reset on an Altera
> ACEX 1K part.  In reading how this works, it appears that the FFs are
> actually only able to be reset or "loaded with a '1'" using an async
> signal.  So if I am not using a signal to preset a FF in my design, but
> just want the power on/chip wide reset state to be a '1', how would I
> code that in VHDL?  Is this like the Xilinx tools where you code in a
> chip wide reset and then drive it with a special module?  Or do I
> explicitly drive it from the chip wide reset pin and the tool figures it
> out?  
> 
> -- 
> 
> 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

Rick,

When the ACEX device is initialized after configuration, or when you
assert the Chip Wide Reset, the FFs are all set to 0. There are two
ways of achieving your goal of having an FF power up to 1.

1. You can code the VHDL so that you end up with a NOT gate before the
D of the FF, and another NOT gate after the Q of the FF. Any logic
that the FF drives would actually be driven by the NOT gate in the
HDL. When the FF powers up at 0, it will appear as 1 by the rest of
the logic. But in normal operation, the double-negation will have no
effect. You'll have to be careful with simulation however, since the
FF's value will be the opposite of what you expect. This works in
MAX+PLUS II or Quartus II as it's simply an HDL code.

2. Quartus II has an ACF setting called "POWER_UP_LEVEL". You can set
this to HIGH or LOW for an individual register. You can apply this
setting using the Assignment Editor or in the HDL using the
"altera_attribute" syntax. Here's an example:

signal my_reg : std_logic
attribute altera_attribute : string;
attribute altera_attribute of my_reg : signal is
"POWER_UP_LEVEL=HIGH";

Either approach works - just depends on whether you would rather
modify the HDL or change assignments.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation

gregs@altera.com (Greg Steinke) writes:
<snip>
> Rick,
> 
> When the ACEX device is initialized after configuration, or when you
> assert the Chip Wide Reset, the FFs are all set to 0. There are two
> ways of achieving your goal of having an FF power up to 1.
> 
> 1. You can code the VHDL so that you end up with a NOT gate before the
> D of the FF, and another NOT gate after the Q of the FF. Any logic
> that the FF drives would actually be driven by the NOT gate in the
> HDL. When the FF powers up at 0, it will appear as 1 by the rest of
> the logic. But in normal operation, the double-negation will have no
> effect. You'll have to be careful with simulation however, since the
> FF's value will be the opposite of what you expect. This works in
> MAX+PLUS II or Quartus II as it's simply an HDL code.
> 

IIRC the 10K, on which the 1K is based, cannot do a preset without NOT
gates anyway, irrespective of whether it's a chip-side reset, or not.
If you write an aync reset clause that initialises something to a '1',
Synplify (at least) will put the appropriate NOT gates in for you.
Which will then hammer your tco for any pins you want to default to a
'1' - like ooh, maybe a chip-select....  Not that I bear the scars or
anything :-)

> 2. Quartus II has an ACF setting called "POWER_UP_LEVEL". You can set
> this to HIGH or LOW for an individual register. You can apply this
> setting using the Assignment Editor or in the HDL using the
> "altera_attribute" syntax. Here's an example:
> 
> signal my_reg : std_logic
> attribute altera_attribute : string;
> attribute altera_attribute of my_reg : signal is
> "POWER_UP_LEVEL=HIGH";
> 
> Either approach works - just depends on whether you would rather
> modify the HDL or change assignments.
> 


I assume this only affects the configuration bitstream, not how the
chip-wide reset behaves?  Or have I misunderstood the chip-wide reset?

Cheers,
Martin
-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Martin Thompson <martin.j.thompson@trw.com> wrote in message news:<uishvxwee.fsf@trw.com>...
> gregs@altera.com (Greg Steinke) writes:
> <snip>
> > Rick,
> > 
> > When the ACEX device is initialized after configuration, or when you
> > assert the Chip Wide Reset, the FFs are all set to 0. There are two
> > ways of achieving your goal of having an FF power up to 1.
> > 
> > 1. You can code the VHDL so that you end up with a NOT gate before the
> > D of the FF, and another NOT gate after the Q of the FF. Any logic
> > that the FF drives would actually be driven by the NOT gate in the
> > HDL. When the FF powers up at 0, it will appear as 1 by the rest of
> > the logic. But in normal operation, the double-negation will have no
> > effect. You'll have to be careful with simulation however, since the
> > FF's value will be the opposite of what you expect. This works in
> > MAX+PLUS II or Quartus II as it's simply an HDL code.
> > 
> 
> IIRC the 10K, on which the 1K is based, cannot do a preset without NOT
> gates anyway, irrespective of whether it's a chip-side reset, or not.
> If you write an aync reset clause that initialises something to a '1',
> Synplify (at least) will put the appropriate NOT gates in for you.
> Which will then hammer your tco for any pins you want to default to a
> '1' - like ooh, maybe a chip-select....  Not that I bear the scars or
> anything :-)
> 
> > 2. Quartus II has an ACF setting called "POWER_UP_LEVEL". You can set
> > this to HIGH or LOW for an individual register. You can apply this
> > setting using the Assignment Editor or in the HDL using the
> > "altera_attribute" syntax. Here's an example:
> > 
> > signal my_reg : std_logic
> > attribute altera_attribute : string;
> > attribute altera_attribute of my_reg : signal is
> > "POWER_UP_LEVEL=HIGH";
> > 
> > Either approach works - just depends on whether you would rather
> > modify the HDL or change assignments.
> > 
> 
> 
> I assume this only affects the configuration bitstream, not how the
> chip-wide reset behaves?  Or have I misunderstood the chip-wide reset?
> 
> Cheers,
> Martin

Martin,
The ACEX 1K (and FLEX 10K) LE has an async clear and an async load. An
async preset could be implemented by the NOT technique or by using the
async load. A design that uses just the preset will generally end up
using the NOT technique, whereas a design that uses a preset and a
clear will use the async load technique.

The IO Element has a programmable inversion in it to accomodate the
NOT technique. So for example if an LE register drives a pin, and the
design calls for the register to be async preset, the compiler will
use the NOT technique and implement the after-register NOT in the IOE.
However, the best tCO is obtained by using the IOE register, and the
programmable inversion is before the D of the IOE register. So there
is no way to implement an async preset in the IOE, which is probably
the reason for the tCO pushout that you saw - the register was moved
into an LE which increases tCO.

If you see a design where an async-preset LE drives a pin, and there's
an extra LE put into the path to implement the NOT gate, this is a bug
and should be reported to Altera and/or Synplicity. But I'll bet that
the tCO pushout is due to the register moving from the IOE to the LE.

You will be happy to know that we have enhanced the IOE registers of
the Stratix and Cyclone FPGAs. In these devices, you can choose to
have an async clear or async preset on an IOE. This is selectable per
IOE. Furthermore, an IOE register that uses the async preset will
power up high. Perfect for your active-low chip select.

For the second question -
In ACEX 1K FPGAs, on the silicon level, the chip-wide reset sets all
the registers to zero. The NOT technique that I proposed simply
modifies the LUT that feeds the register, and the LUTs that the
register feeds, to add the NOT gates. (Through the configuration
bitstream as you suggest.) If you were to microprobe the register, you
would see it go low when chip-wide reset is asserted. But every case
where that register is used now would have a NOT gate, so it would
seem to go high.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation

gregs@altera.com (Greg Steinke) writes:

> Martin Thompson <martin.j.thompson@trw.com> wrote in message news:<uishvxwee.fsf@trw.com>...
> > gregs@altera.com (Greg Steinke) writes:
> > <snip>
> > > Rick,
> > > 
> > > When the ACEX device is initialized after configuration, or when you
> > > assert the Chip Wide Reset, the FFs are all set to 0. There are two
> > > ways of achieving your goal of having an FF power up to 1.
> > > 
> > > 1. You can code the VHDL so that you end up with a NOT gate before the
> > > D of the FF, and another NOT gate after the Q of the FF. Any logic
> > > that the FF drives would actually be driven by the NOT gate in the
> > > HDL. When the FF powers up at 0, it will appear as 1 by the rest of
> > > the logic. But in normal operation, the double-negation will have no
> > > effect. You'll have to be careful with simulation however, since the
> > > FF's value will be the opposite of what you expect. This works in
> > > MAX+PLUS II or Quartus II as it's simply an HDL code.
> > > 
> > 
> > IIRC the 10K, on which the 1K is based, cannot do a preset without NOT
> > gates anyway, irrespective of whether it's a chip-side reset, or not.
> > If you write an aync reset clause that initialises something to a '1',
> > Synplify (at least) will put the appropriate NOT gates in for you.
> > Which will then hammer your tco for any pins you want to default to a
> > '1' - like ooh, maybe a chip-select....  Not that I bear the scars or
> > anything :-)
> 
<snip>
> Martin,
> The ACEX 1K (and FLEX 10K) LE has an async clear and an async load. An
> async preset could be implemented by the NOT technique or by using the
> async load. A design that uses just the preset will generally end up
> using the NOT technique, whereas a design that uses a preset and a
> clear will use the async load technique.
> 

True - my memory was only of the IOEs.  However, if you want a preset,
you have to sacrifice DATA3 in the LUT according to my datasheet (as
implicated by the use of the term "load" rather than "preset").  I
knew I'd recalled something about presets not being quite as "free" as
resets :-)

> The IO Element has a programmable inversion in it to accomodate the
> NOT technique. So for example if an LE register drives a pin, and the
> design calls for the register to be async preset, the compiler will
> use the NOT technique and implement the after-register NOT in the IOE.
> However, the best tCO is obtained by using the IOE register, and the
> programmable inversion is before the D of the IOE register. So there
> is no way to implement an async preset in the IOE, which is probably
> the reason for the tCO pushout that you saw - the register was moved
> into an LE which increases tCO.
> 
> If you see a design where an async-preset LE drives a pin, and there's
> an extra LE put into the path to implement the NOT gate, this is a bug
> and should be reported to Altera and/or Synplicity. But I'll bet that
> the tCO pushout is due to the register moving from the IOE to the LE.
> 

Yes, that is what was happening - it was a while ago, I remember now!
What happens to the power-up (not reset) behaviour?  Does it still
power up low until the reset occurs?

> You will be happy to know that we have enhanced the IOE registers of
> the Stratix and Cyclone FPGAs. In these devices, you can choose to
> have an async clear or async preset on an IOE. This is selectable per
> IOE. Furthermore, an IOE register that uses the async preset will
> power up high. Perfect for your active-low chip select.
> 

Good stuff!

> > 
> > > 2. Quartus II has an ACF setting called "POWER_UP_LEVEL". You can set
> > > this to HIGH or LOW for an individual register. You can apply this
> > > setting using the Assignment Editor or in the HDL using the
> > > "altera_attribute" syntax. Here's an example:
> > > 
> > > signal my_reg : std_logic
> > > attribute altera_attribute : string;
> > > attribute altera_attribute of my_reg : signal is
> > > "POWER_UP_LEVEL=HIGH";
> > > 
> > > Either approach works - just depends on whether you would rather
> > > modify the HDL or change assignments.
> > > 
> > 
> > 
> > I assume this only affects the configuration bitstream, not how the
> > chip-wide reset behaves?  Or have I misunderstood the chip-wide reset?
> > 
> > Cheers,
> > Martin
> For the second question -
> In ACEX 1K FPGAs, on the silicon level, the chip-wide reset sets all
> the registers to zero. The NOT technique that I proposed simply
> modifies the LUT that feeds the register, and the LUTs that the
> register feeds, to add the NOT gates. (Through the configuration
> bitstream as you suggest.) If you were to microprobe the register, you
> would see it go low when chip-wide reset is asserted. But every case
> where that register is used now would have a NOT gate, so it would
> seem to go high.
> 

OK, that's clear enough (although Figure 12 of the datasheet implies
that chip-wide reset *can* do a preset of the FF)

But does the POWER_UP_LEVEL technique infer NOT gates as in solution
1), or do you get a '1' on power up and then a '0' on chip-wide reset?

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Martin Thompson wrote:
> 
> gregs@altera.com (Greg Steinke) writes:
> 
> > Martin Thompson <martin.j.thompson@trw.com> wrote in message news:<uishvxwee.fsf@trw.com>...
> > > gregs@altera.com (Greg Steinke) writes:
> > > <snip>
> > > > Rick,
> > > >
> > > > When the ACEX device is initialized after configuration, or when you
> > > > assert the Chip Wide Reset, the FFs are all set to 0. There are two
> > > > ways of achieving your goal of having an FF power up to 1.
> > > >
> > > > 1. You can code the VHDL so that you end up with a NOT gate before the
> > > > D of the FF, and another NOT gate after the Q of the FF. Any logic
> > > > that the FF drives would actually be driven by the NOT gate in the
> > > > HDL. When the FF powers up at 0, it will appear as 1 by the rest of
> > > > the logic. But in normal operation, the double-negation will have no
> > > > effect. You'll have to be careful with simulation however, since the
> > > > FF's value will be the opposite of what you expect. This works in
> > > > MAX+PLUS II or Quartus II as it's simply an HDL code.
> > > >
> > >
> > > IIRC the 10K, on which the 1K is based, cannot do a preset without NOT
> > > gates anyway, irrespective of whether it's a chip-side reset, or not.
> > > If you write an aync reset clause that initialises something to a '1',
> > > Synplify (at least) will put the appropriate NOT gates in for you.
> > > Which will then hammer your tco for any pins you want to default to a
> > > '1' - like ooh, maybe a chip-select....  Not that I bear the scars or
> > > anything :-)
> >
> <snip>
> > Martin,
> > The ACEX 1K (and FLEX 10K) LE has an async clear and an async load. An
> > async preset could be implemented by the NOT technique or by using the
> > async load. A design that uses just the preset will generally end up
> > using the NOT technique, whereas a design that uses a preset and a
> > clear will use the async load technique.
> >
> 
> True - my memory was only of the IOEs.  However, if you want a preset,
> you have to sacrifice DATA3 in the LUT according to my datasheet (as
> implicated by the use of the term "load" rather than "preset").  I
> knew I'd recalled something about presets not being quite as "free" as
> resets :-)
> 
> > The IO Element has a programmable inversion in it to accomodate the
> > NOT technique. So for example if an LE register drives a pin, and the
> > design calls for the register to be async preset, the compiler will
> > use the NOT technique and implement the after-register NOT in the IOE.
> > However, the best tCO is obtained by using the IOE register, and the
> > programmable inversion is before the D of the IOE register. So there
> > is no way to implement an async preset in the IOE, which is probably
> > the reason for the tCO pushout that you saw - the register was moved
> > into an LE which increases tCO.
> >
> > If you see a design where an async-preset LE drives a pin, and there's
> > an extra LE put into the path to implement the NOT gate, this is a bug
> > and should be reported to Altera and/or Synplicity. But I'll bet that
> > the tCO pushout is due to the register moving from the IOE to the LE.
> >
> 
> Yes, that is what was happening - it was a while ago, I remember now!
> What happens to the power-up (not reset) behaviour?  Does it still
> power up low until the reset occurs?

The data sheet is one thing.  But I was asking about how to get the FF
to use whatever is available.  From what I read in the data sheet, it
looks like a preset can be done by putting a 1 on DATA3.  This will also
become part of the power on reset as well as the reset pin function. 
But it also appears that to use it I have to provide an async set in my
code separate from the global reset.  

Either way this does not look good.  

-- 

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

Greg Steinke wrote:
<snip>
> You will be happy to know that we have enhanced the IOE registers of
> the Stratix and Cyclone FPGAs. In these devices, you can choose to
> have an async clear or async preset on an IOE. This is selectable per
> IOE. Furthermore, an IOE register that uses the async preset will
> power up high. Perfect for your active-low chip select.
> 
> For the second question -
> In ACEX 1K FPGAs, on the silicon level, the chip-wide reset sets all
> the registers to zero. The NOT technique that I proposed simply
> modifies the LUT that feeds the register, and the LUTs that the
> register feeds, to add the NOT gates. 

  One small detail - on these Async resets, how is reset recovery
( trailing edge of ASYNC RST, to any appearing Clocks ) handled inside 
the device ?

-jg

Jim Granville wrote:
> 
> Greg Steinke wrote:
> <snip>
> > You will be happy to know that we have enhanced the IOE registers of
> > the Stratix and Cyclone FPGAs. In these devices, you can choose to
> > have an async clear or async preset on an IOE. This is selectable per
> > IOE. Furthermore, an IOE register that uses the async preset will
> > power up high. Perfect for your active-low chip select.
> >
> > For the second question -
> > In ACEX 1K FPGAs, on the silicon level, the chip-wide reset sets all
> > the registers to zero. The NOT technique that I proposed simply
> > modifies the LUT that feeds the register, and the LUTs that the
> > register feeds, to add the NOT gates.
> 
>   One small detail - on these Async resets, how is reset recovery
> ( trailing edge of ASYNC RST, to any appearing Clocks ) handled inside
> the device ?

It's not, just like any other async reset.  You need to either provide a
sync reset to critical logic or design it so that it has a couple of
post reset states that only vary by one FF, like a gray code.  

-- 

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 <spamgoeshere4@yahoo.com> wrote in message news:<403E4742.1F02D0B8@yahoo.com>...
> Martin Thompson wrote:
> > 
> > gregs@altera.com (Greg Steinke) writes:
> > 
> > > Martin Thompson <martin.j.thompson@trw.com> wrote in message news:<uishvxwee.fsf@trw.com>...
> > > > gregs@altera.com (Greg Steinke) writes:
> > > > <snip>
> > 
> > > The IO Element has a programmable inversion in it to accomodate the
> > > NOT technique. So for example if an LE register drives a pin, and the
> > > design calls for the register to be async preset, the compiler will
> > > use the NOT technique and implement the after-register NOT in the IOE.
> > > However, the best tCO is obtained by using the IOE register, and the
> > > programmable inversion is before the D of the IOE register. So there
> > > is no way to implement an async preset in the IOE, which is probably
> > > the reason for the tCO pushout that you saw - the register was moved
> > > into an LE which increases tCO.
> > >
> > > If you see a design where an async-preset LE drives a pin, and there's
> > > an extra LE put into the path to implement the NOT gate, this is a bug
> > > and should be reported to Altera and/or Synplicity. But I'll bet that
> > > the tCO pushout is due to the register moving from the IOE to the LE.
> > >
> > 
> > Yes, that is what was happening - it was a while ago, I remember now!
> > What happens to the power-up (not reset) behaviour?  Does it still
> > power up low until the reset occurs?
> 
> The data sheet is one thing.  But I was asking about how to get the FF
> to use whatever is available.  From what I read in the data sheet, it
> looks like a preset can be done by putting a 1 on DATA3.  This will also
> become part of the power on reset as well as the reset pin function. 
> But it also appears that to use it I have to provide an async set in my
> code separate from the global reset.  
> 
> Either way this does not look good.  
> 
> -- 
> 
> 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

Rick,
If you do a preset by putting the 1 on the DATA3 and doing an async
load, then the register will power up low, and the Chip Wide Reset
will force the register low. The advantage here is that you can have
async preset and async clr as separate controls. The disadvantage is
that it takes up one of the LUT inputs.

If you do the preset by putting a NOT gate before the D, and another
after the Q, then the register will appear to power up high, and the
Chip Wide Reset will appear to force the register high. (In reality it
is low, but it seems high due to the NOT.) The advantage here is that
it is free (unless you need fast tCO as this technique can't be done
in the ACEX IOE). The disadvantage is that you cannot have a preset
and clear on the same FF.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation

Greg Steinke wrote:
> 
> Rick,
> If you do a preset by putting the 1 on the DATA3 and doing an async
> load, then the register will power up low, and the Chip Wide Reset
> will force the register low. The advantage here is that you can have
> async preset and async clr as separate controls. The disadvantage is
> that it takes up one of the LUT inputs.
> 
> If you do the preset by putting a NOT gate before the D, and another
> after the Q, then the register will appear to power up high, and the
> Chip Wide Reset will appear to force the register high. (In reality it
> is low, but it seems high due to the NOT.) The advantage here is that
> it is free (unless you need fast tCO as this technique can't be done
> in the ACEX IOE). The disadvantage is that you cannot have a preset
> and clear on the same FF.

At this point, I understand the ACEX hardware.  But I can't put gates
anywhere.  I am asking how to control this from my VHDL.  In the Xilinx
parts, you use a symbol to drive a global reset net.  The tools then
remove the symbol and use the GSR feature to control the FFs reset
function.  I have no idea how to do this in VHDL for the ACEX parts. 

-- 

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