simpler stuff!!!

It has been awhile since I coded up any VHDL and there are some things
I have forgotten. One of them is how to infer the GSR state of a
register. What I remember is that you use an async reset on all
registers and specify the state in an assignment in that part of the
if statement. But I have always had an external reset to use as the
controlling signal for the reset state. What do you use if you have
no external reset and only want to specify the reset state for the
power on reset?

Here is code I am currently using.

GSR <= not Switch(5);

SysReset <= SysRst(0);
SysRstReg: process (GenClk, GSR) begin
if (GSR = '1') then
SysRst <= "1111";
elsif (rising_edge(GenClk)) then
SysRst <= '0' & SysRst(3 downto 1);
end if;
end process SysRstReg;

But if I don't have the input Switch(5), what do I specify? This is
for a Lattice part which should be very similar to the Xilinix parts
since they share the same hardware and software roots. I have dug all
through the Lattice docs and found lots of info on how to *control*
the GSR/PUR signal, but not on how to *use* the GSR signal.

Rick

rickman

On May 20, 9:28*am, rickman <gnu...@gmail.com> wrote:
> It has been awhile since I coded up any VHDL and there are some things
> I have forgotten. *One of them is how to infer the GSR state of a
> register. *What I remember is that you use an async reset on all
> registers and specify the state in an assignment in that part of the
> if statement. *But I have always had an external reset to use as the
> controlling signal for the reset state. *What do you use if you have
> no external reset and only want to specify the reset state for the
> power on reset?
>
> Here is code I am currently using.
>
> * GSR <= not Switch(5);
>
> * SysReset <= SysRst(0);
> * SysRstReg: process (GenClk, GSR) begin
> * * * * if (GSR = '1') then
> * * * * * SysRst <= "1111";
> * * * * elsif (rising_edge(GenClk)) then
> * * * * * SysRst <= '0' & SysRst(3 downto 1);
> * * * * end if;
> * end process SysRstReg;
>
> But if I don't have the input Switch(5), what do I specify? *This is
> for a Lattice part which should be very similar to the Xilinix parts
> since they share the same hardware and software roots. *I have dug all
> through the Lattice docs and found lots of info on how to *control*
> the GSR/PUR signal, but not on how to *use* the GSR signal.
>
> Rick

Assuming the Lattice tools support signal initializers, then the way
you handle it is by specifying an initial value for the 'SysRst'
vector

signal SysRst: std_logic_vector(3 downto 0) := (others => '1');

Kevin Jennings

KJ

On May 20, 10:18 am, KJ <kkjenni...@sbcglobal.net> wrote:
> On May 20, 9:28 am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > It has been awhile since I coded up any VHDL and there are some things
> > I have forgotten. One of them is how to infer the GSR state of a
> > register. What I remember is that you use an async reset on all
> > registers and specify the state in an assignment in that part of the
> > if statement. But I have always had an external reset to use as the
> > controlling signal for the reset state. What do you use if you have
> > no external reset and only want to specify the reset state for the
> > power on reset?
>
> > Here is code I am currently using.
>
> > GSR <= not Switch(5);
>
> > SysReset <= SysRst(0);
> > SysRstReg: process (GenClk, GSR) begin
> > if (GSR = '1') then
> > SysRst <= "1111";
> > elsif (rising_edge(GenClk)) then
> > SysRst <= '0' & SysRst(3 downto 1);
> > end if;
> > end process SysRstReg;
>
> > But if I don't have the input Switch(5), what do I specify? This is
> > for a Lattice part which should be very similar to the Xilinix parts
> > since they share the same hardware and software roots. I have dug all
> > through the Lattice docs and found lots of info on how to *control*
> > the GSR/PUR signal, but not on how to *use* the GSR signal.
>
> > Rick
>
> Assuming the Lattice tools support signal initializers, then the way
> you handle it is by specifying an initial value for the 'SysRst'
> vector
>
> signal SysRst: std_logic_vector(3 downto 0) := (others => '1');
>
> Kevin Jennings

Good point, but I don't know if it will work. I do know that
historically this has been frowned upon in general, but I think that
is because it only specifies the power up reset state and can leave
the designer thinking he has provided a true reset when such is not
the case.

I want to say that I have seen some tools use the initialization value
as the asynch reset state, but I don't recall which.

Rick

rickman

On May 20, 12:07*pm, rickman <gnu...@gmail.com> wrote:
> On May 20, 10:18 am, KJ <kkjenni...@sbcglobal.net> wrote:
>
>
>
>
>
> > On May 20, 9:28 am, rickman <gnu...@gmail.com> wrote:
>
> > > It has been awhile since I coded up any VHDL and there are some things
> > > I have forgotten. *One of them is how to infer the GSR state of a
> > > register. *What I remember is that you use an async reset on all
> > > registers and specify the state in an assignment in that part of the
> > > if statement. *But I have always had an external reset to use as the
> > > controlling signal for the reset state. *What do you use if you have
> > > no external reset and only want to specify the reset state for the
> > > power on reset?
>
> > > Here is code I am currently using.
>
> > > * GSR <= not Switch(5);
>
> > > * SysReset <= SysRst(0);
> > > * SysRstReg: process (GenClk, GSR) begin
> > > * * * * if (GSR = '1') then
> > > * * * * * SysRst <= "1111";
> > > * * * * elsif (rising_edge(GenClk)) then
> > > * * * * * SysRst <= '0' & SysRst(3 downto 1);
> > > * * * * end if;
> > > * end process SysRstReg;
>
> > > But if I don't have the input Switch(5), what do I specify? *This is
> > > for a Lattice part which should be very similar to the Xilinix parts
> > > since they share the same hardware and software roots. *I have dug all
> > > through the Lattice docs and found lots of info on how to *control*
> > > the GSR/PUR signal, but not on how to *use* the GSR signal.
>
> > > Rick
>
> > Assuming the Lattice tools support signal initializers, then the way
> > you handle it is by specifying an initial value for the 'SysRst'
> > vector
>
> > signal SysRst: std_logic_vector(3 downto 0) := (others => '1');
>
> > Kevin Jennings
>
> Good point, but I don't know if it will work.

As long as...
1. The physical device has a guaranteed powerup state for flops
2. The tools support initial values

then it will work. As you no doubt know, those are two big 'ifs' that
you need to get the answer to before using it. If not, then you'll
need to provide some external signal (even an otherwise unused signal
pulled up or down to a valid logic level will do the trick) to provide
the 'external reset' to the FPGA.

> I do know that
> historically this has been frowned upon in general, but I think that
> is because it only specifies the power up reset state and can leave
> the designer thinking he has provided a true reset when such is not
> the case.
>

Correct, you don't want to have to sprinkle your code with initial
values in case you end up targetting a device that violates #1 or
using a tool that violates #2.

KJ

KJ

> then it will work. As you no doubt know, those are two big 'ifs' that
> you need to get the answer to before using it. If not, then you'll
> need to provide some external signal (even an otherwise unused signal
> pulled up or down to a valid logic level will do the trick) to provide
> the 'external reset' to the FPGA.

That would be quite a trick! An unused pull-up/down will either
hold the FPGA in perma-reset or not provide a reliable power-on
reset. The only way to generate a reliable power-on reset for an FPGA
that doesn't have its own is to use a carefully designed analog reset
or use an IC that's designed to do that.

Yes, I have successfully designed a non-carefully designed analog
reset.

jens

"jens" <> wrote in message
news:0d73662d-b39b-43a9-a19f-...
>> then it will work. As you no doubt know, those are two big 'ifs' that
>> you need to get the answer to before using it. If not, then you'll
>> need to provide some external signal (even an otherwise unused signal
>> pulled up or down to a valid logic level will do the trick) to provide
>> the 'external reset' to the FPGA.
>
> That would be quite a trick! An unused pull-up/down will either
> hold the FPGA in perma-reset or not provide a reliable power-on
> reset. The only way to generate a reliable power-on reset for an FPGA
> that doesn't have its own is to use a carefully designed analog reset
> or use an IC that's designed to do that.
>

The trick is that the external reset pin is not really providing a reset,
the logic level that it's providing is always a 'not reset'...but the code
in the FPGA doesn't know that. To provide an internal logic reset at power
up without an external (carefully designed reset) IC you need a device and
tool set that supports assignment of initial values.

signal Reset_Shift_Reg: std_ulogic_vector(3 downto 0) := (others => '1');
....
Fpga_Reset <= Reset_Shift_Reg(3);

where Reset_Shift_Reg will shift in a constant of '0' into the low end.
This will give you a couple clock cycle wide Fpga_Reset signal. But if your
synthesis tools are too smart in their optomization they could optomize the
whole shift register thing away replacing it with '0' and essentially
prevent you from getting any reset.

If that situation arises, then usually you can work around this by adding
attributes to tell it not to optomize the shift register logic. If that
still doesn't work then you could change your code so that the input from
the shift register is not a constant of '0' but instead comes from a pin
(that you pull down on the board, nothing fancy needed). In that situation
the synthesis tool would not be able to optomize anything the shift register
would remain intact. Since the pin is pulled to the 'not reset' logic level
it will get shifted through bringing the FPGA out of reset.

I used this trick once before years ago when the stars aligned just so
meeting all of the criteria that I mentioned. Now-a-daze the tools might
not be so unforgiving so you might not need this idea, but it does work and
works reliably as well.

> Yes, I have successfully designed a non-carefully designed analog
> reset.

You should've thought of it as a carefully designed 'not reset' instead

Kevin Jennings

KJ

On May 22, 11:56 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "jens" <ro...@rochester.rr.com> wrote in message
>
> news:0d73662d-b39b-43a9-a19f-...
>
> >> then it will work. As you no doubt know, those are two big 'ifs' that
> >> you need to get the answer to before using it. If not, then you'll
> >> need to provide some external signal (even an otherwise unused signal
> >> pulled up or down to a valid logic level will do the trick) to provide
> >> the 'external reset' to the FPGA.
>
> > That would be quite a trick! An unused pull-up/down will either
> > hold the FPGA in perma-reset or not provide a reliable power-on
> > reset. The only way to generate a reliable power-on reset for an FPGA
> > that doesn't have its own is to use a carefully designed analog reset
> > or use an IC that's designed to do that.
>
> The trick is that the external reset pin is not really providing a reset,
> the logic level that it's providing is always a 'not reset'...but the code
> in the FPGA doesn't know that. To provide an internal logic reset at power
> up without an external (carefully designed reset) IC you need a device and
> tool set that supports assignment of initial values.
>
> signal Reset_Shift_Reg: std_ulogic_vector(3 downto 0) := (others => '1');
> ...
> Fpga_Reset <= Reset_Shift_Reg(3);
>
> where Reset_Shift_Reg will shift in a constant of '0' into the low end.
> This will give you a couple clock cycle wide Fpga_Reset signal. But if your
> synthesis tools are too smart in their optomization they could optomize the
> whole shift register thing away replacing it with '0' and essentially
> prevent you from getting any reset.
>
> If that situation arises, then usually you can work around this by adding
> attributes to tell it not to optomize the shift register logic. If that
> still doesn't work then you could change your code so that the input from
> the shift register is not a constant of '0' but instead comes from a pin
> (that you pull down on the board, nothing fancy needed). In that situation
> the synthesis tool would not be able to optomize anything the shift register
> would remain intact. Since the pin is pulled to the 'not reset' logic level
> it will get shifted through bringing the FPGA out of reset.
>
> I used this trick once before years ago when the stars aligned just so
> meeting all of the criteria that I mentioned. Now-a-daze the tools might
> not be so unforgiving so you might not need this idea, but it does work and
> works reliably as well.
>
> > Yes, I have successfully designed a non-carefully designed analog
> > reset.
>
> You should've thought of it as a carefully designed 'not reset' instead
>
> Kevin Jennings

That shift register will only work if you can reliably define the
initial state of the registers within it.

That is the whole problem being adressed: Some targets (ASICs) do not
support known power up states on registers.

Thankfully, most FPGAs do. Most tools will initialize a register to
its reset value anyway, so a reset clause that ends up getting
optimized away (due to being driven with a constant) will usually
still result in the same initialization of the register at the end of
configuration.

Andy

Andy

On May 23, 10:47*am, Andy <jonesa...@comcast.net> wrote:
> On May 22, 11:56 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
>
> That shift register will only work if you can reliably define the
> initial state of the registers within it.
>

I said that in an earlier post (May 20).

> That is the whole problem being adressed: Some targets (ASICs) do not
> support known power up states on registers.
>

Then you're reading a whole different problem than what rickman
posted.

> Thankfully, most FPGAs do. Most tools will initialize a register to
> its reset value anyway, so a reset clause that ends up getting
> optimized away (due to being driven with a constant) will usually
> still result in the same initialization of the register at the end of
> configuration.
>

I disagree, any 'optomization' will likely break it. The initial
value specified for the shift register will always be the opposite
polarity of the constant that is being driven into the shift
register. In any case, that is a situation where the tool chain
doesn't provide the support which violates criteria #2 from my May 20
post...or it could also be interpreted as a synthesis optomization bug
to be reported to the vendor.

Kevin Jennings

KJ

On May 23, 11:37*am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 23 May 2008 08:35:36 -0700 (PDT), KJ wrote:
> >I disagree, any 'optomization' will likely break it.
>
> Is optomization something to do with the use of
> photonics to make FPGAs go faster?
> --
> Jonathan Bromley, Consultant

optimization

KJ

KJ

On May 23, 12:56 am, "KJ" <kkjenni...@sbcglobal.net> wrote:
>
> where Reset_Shift_Reg will shift in a constant of '0' into the low end.
> This will give you a couple clock cycle wide Fpga_Reset signal. But if your
> synthesis tools are too smart in their optomization they could optomize the
> whole shift register thing away replacing it with '0' and essentially
> prevent you from getting any reset.

If the synthesis software "optimizes" the shift register away, it is
not optimizing, it is malfunctioning. When tools optimize, they
replace circuitry with equivalent circuitry which uses less
resources. Obviously no shift register is not equivalent to a shift
register in this case. The tools won't optimize this away.

The problem is that the global async reset provided in an FPGA is not
at all useful as a global async reset. Or more accurately, it is not
a very good release from reset. It has to be released from reset
synchronously to prevent part of a state machine from starting without
the rest of it. For example, a one-hot encoded FSM might have the
initial hot deselect but the next hot, which is still seeing the
reset, not be asserted. This leaves the FSM in a "no-hot" state.

So you can't rely on the global async reset to release the entire chip
at the right time unless it is synchronized to the appropriate clock.
That is what the shift register does. The good thing about the shift
register is that it itself is not subject to any issues with the
timing of the async reset release. All that will do is to possibly
extend the duration of the reset by one clock.

Rick

rickman