extra reset pin should not be needed..

J

Joseph H Allen

Guest
Do any of the vendors provide a way to use the global reset net, but avoid
having to tie it to a pin. In other words:

module top
(
in,
q
);

wire clk;
wire reset_l;

internal_clock_generator osc (.clk(clk)); // Some chips have this

internal_reset_generator rst (.reset_l (reset_l)); // None have this I think

always @(posedge clk or negedge reset_l)
if (!reset_l)
q <= 1; // Initial state is 1, not 0!
else
q <= in;

The answer used to be no, but maybe things have changed..

Yes, I know the global reset will reset everything anyway, but you need a
reset net for the synthesizer to infer the initial state. If you tie the
reset net to a constant, it gets optimized out.

Yes, I also know that the vendors provide ways of triggering the global
reset net from a pin by connecting it to the 'GSR' module.

I guess one way it make a black box hard macro which does nothing and tie it
to the fake reset net.

--
/* 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:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
 
On 10/11/2013 4:06 PM, Joseph H Allen wrote:
Do any of the vendors provide a way to use the global reset net, but avoid
having to tie it to a pin. In other words:

module top
(
in,
q
);

wire clk;
wire reset_l;

internal_clock_generator osc (.clk(clk)); // Some chips have this

internal_reset_generator rst (.reset_l (reset_l)); // None have this I think

always @(posedge clk or negedge reset_l)
if (!reset_l)
q <= 1; // Initial state is 1, not 0!
else
q <= in;

The answer used to be no, but maybe things have changed..

Yes, I know the global reset will reset everything anyway, but you need a
reset net for the synthesizer to infer the initial state. If you tie the
reset net to a constant, it gets optimized out.

Yes, I also know that the vendors provide ways of triggering the global
reset net from a pin by connecting it to the 'GSR' module.

I guess one way it make a black box hard macro which does nothing and tie it
to the fake reset net.

At least for Xilinx you don't "connect" the GSR net unless you use the
STARTUP module. Normally an explicit reset net, whether supplied by
a pin or from internal logic, uses general routing. If you can live
without this, XST will synthesis initial values in register declarations
like:

reg [3:0] foo = 4'd7;

It also properly synthesizes initial blocks for initializing registers
or arrays, including $readmemh or $readmemb.

For lower level modules, you can use an asynchronous reset term in
all your synchronous always blocks and tie that reset to a port,
then ground it (or tie high if you like active low reset) at the
instantiation. Then the resets will be trimmed during map, but
XST still infers the proper initial state for global reset.

In all the years I've used Xilinx tools and FPGA's I don't think
I ever actually assigned a package pin for a reset, although I
typically have an internally generated reset net using a short
shift register that initializes to all ones and shifts in zero
after power-up.

--
Gabor
 
In article <l3d4aa$dmi$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote:

>reg [3:0] foo = 4'd7;

Yeah I've been playing with this, it does work, but has the disadvantage
that your code will then be different from RTL for an ASIC.. I mean if you
used these initial values for all flops in the design, then you would not
need an explicit reset net at all. I'm pretty sure design compiler will not
support it.

In all the years I've used Xilinx tools and FPGA's I don't think
I ever actually assigned a package pin for a reset, although I
typically have an internally generated reset net using a short
shift register that initializes to all ones and shifts in zero
after power-up.

This means you will not be able to use the FPGA's already existing global
reset net in place of one which takes up routing resources. This one shift
register will prevent you from making the explicit reset net equal to the
built-in one (which only works if all flops in the entire design are
connected to the same net).

Anyway, it's not such a big deal with the chips these days, but still it
would be nice if there was a way to do it. The initial value is a good way
to make an internal reset generator as you say.
--
/* 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:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
 
In article <l3gq1p$ua8$1@dont-email.me>,
GaborSzakacs <gabor@alacron.com> wrote:
Joseph H Allen wrote:
In article <l3d4aa$dmi$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote:

reg [3:0] foo = 4'd7;

Yeah I've been playing with this, it does work, but has the disadvantage
that your code will then be different from RTL for an ASIC.. I mean if you
used these initial values for all flops in the design, then you would not
need an explicit reset net at all. I'm pretty sure design compiler will not
support it.

BTW, this syntax works for Synplify, but not for Lattice's new LSE.

Also I discovered that switching between synthesis tools breaks the pin
assignments.

In all the years I've used Xilinx tools and FPGA's I don't think
I ever actually assigned a package pin for a reset, although I
typically have an internally generated reset net using a short
shift register that initializes to all ones and shifts in zero
after power-up.

This means you will not be able to use the FPGA's already existing global
reset net in place of one which takes up routing resources. This one shift
register will prevent you from making the explicit reset net equal to the
built-in one (which only works if all flops in the entire design are
connected to the same net).

Anyway, it's not such a big deal with the chips these days, but still it
would be nice if there was a way to do it. The initial value is a good way
to make an internal reset generator as you say.

Now that I think of it, Lattice has a way to use the global reset net
internally. At least in the last parts I used (ECP and ECP2) you could
do essentially the same business I did with Xilinx, and then tie the
output of the shift register to the global reset net. The reason this
works in Lattice and not Xiinx is that the Lattice parts allow you to
remove the global reset function on a flop-by-flop basis. Thus you
turn off global reset on the reset S/R itself.

I found the part of Lattice's documentation which talks about this- it's
quite elborate (complex). It looks like the default is to use GSR for the
largest reset net, and disable it for any others. I'm surprised that they
found it worthwhile to add this configuration bit to every flop in the chip.

I wonder if flops with GSR disabled are really in an indeterminate state out
of configuration... I guess it could be either way: if they clear the config
bit chain and hit the global reset before loading the design they would get
cleared..



--
/* 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:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
 
Joseph H Allen wrote:
In article <l3d4aa$dmi$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote:

reg [3:0] foo = 4'd7;

Yeah I've been playing with this, it does work, but has the disadvantage
that your code will then be different from RTL for an ASIC.. I mean if you
used these initial values for all flops in the design, then you would not
need an explicit reset net at all. I'm pretty sure design compiler will not
support it.

In all the years I've used Xilinx tools and FPGA's I don't think
I ever actually assigned a package pin for a reset, although I
typically have an internally generated reset net using a short
shift register that initializes to all ones and shifts in zero
after power-up.

This means you will not be able to use the FPGA's already existing global
reset net in place of one which takes up routing resources. This one shift
register will prevent you from making the explicit reset net equal to the
built-in one (which only works if all flops in the entire design are
connected to the same net).

Anyway, it's not such a big deal with the chips these days, but still it
would be nice if there was a way to do it. The initial value is a good way
to make an internal reset generator as you say.

Now that I think of it, Lattice has a way to use the global reset net
internally. At least in the last parts I used (ECP and ECP2) you could
do essentially the same business I did with Xilinx, and then tie the
output of the shift register to the global reset net. The reason this
works in Lattice and not Xiinx is that the Lattice parts allow you to
remove the global reset function on a flop-by-flop basis. Thus you
turn off global reset on the reset S/R itself.

As for Xilinx and routing resources, initial values take no routing
resources because they just happen during configuration. Earlier
Xilinx FPGA's had no dedicated global reset net. i.e. if you used
a pin as a "global" reset, it still got routed using the general
fabric routing. The "GSR" was actually implemented as a global
write enable that holds off changes in all registers (including
SRL and BRAM) until the end of configuration. Only newer families
have a STARTUP primitive that allows you to re-assert the global
reset.

Still, you end up needing to be careful when using the global reset
for startup as its skew over the part is very large. Thus you may need
more than one startup state on a state machine to be sure all flops
in the part are out of reset before you get to any state that depends
on external (to the FSM) signals.

--
Gabor
 
Joseph H Allen wrote:
In article <l3gq1p$ua8$1@dont-email.me>,
GaborSzakacs <gabor@alacron.com> wrote:
Joseph H Allen wrote:
In article <l3d4aa$dmi$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote:

reg [3:0] foo = 4'd7;

Yeah I've been playing with this, it does work, but has the disadvantage
that your code will then be different from RTL for an ASIC.. I mean if you
used these initial values for all flops in the design, then you would not
need an explicit reset net at all. I'm pretty sure design compiler will not
support it.

BTW, this syntax works for Synplify, but not for Lattice's new LSE.

Also I discovered that switching between synthesis tools breaks the pin
assignments.

In all the years I've used Xilinx tools and FPGA's I don't think
I ever actually assigned a package pin for a reset, although I
typically have an internally generated reset net using a short
shift register that initializes to all ones and shifts in zero
after power-up.

This means you will not be able to use the FPGA's already existing global
reset net in place of one which takes up routing resources. This one shift
register will prevent you from making the explicit reset net equal to the
built-in one (which only works if all flops in the entire design are
connected to the same net).

Anyway, it's not such a big deal with the chips these days, but still it
would be nice if there was a way to do it. The initial value is a good way
to make an internal reset generator as you say.

Now that I think of it, Lattice has a way to use the global reset net
internally. At least in the last parts I used (ECP and ECP2) you could
do essentially the same business I did with Xilinx, and then tie the
output of the shift register to the global reset net. The reason this
works in Lattice and not Xiinx is that the Lattice parts allow you to
remove the global reset function on a flop-by-flop basis. Thus you
turn off global reset on the reset S/R itself.

I found the part of Lattice's documentation which talks about this- it's
quite elborate (complex). It looks like the default is to use GSR for the
largest reset net, and disable it for any others. I'm surprised that they
found it worthwhile to add this configuration bit to every flop in the chip.

I wonder if flops with GSR disabled are really in an indeterminate state out
of configuration... I guess it could be either way: if they clear the config
bit chain and hit the global reset before loading the design they would get
cleared..

Here's a snippet of an ECP2 project. The "FD1P3AX" is a library element
and it is reset to zero at configuration (this is an SRAM part like
Xilinx). However it is not connected to the GSR net. Note that I
also specify the GSR net, rather than get surprised when the ispLever
software decides to connect it to some other net. I've been burned
by that before.

Remember in these parts, the configuration bitstream contains the
initial value of all flops, which does not need to be the same
as the reset value, but defaults to that. This also used to be true
of Xilinx parts, but newer ones require an asynch reset to match the
configuration init value. So in fact without GSR you still come
up in a known state after configuration. This is not literally a
"reset" function, but the equivalent of shifting the data into
the flops during configuration. In the same way you can initialize
all your BRAM and SRL's (yeah Lattice has those, too), even though
they have no "reset" function.

// --------------------------------------------------------------------
// Instantiate flip-flops for internal reset signals
// This flip-flop comes up reset after configuration.
FD1P3AX sysclk_rst_ff
(
.D (1'b1),
.SP (1'b1),
.CK (sys_clock),
.Q (sysclk_rstn)
);

assign sys_reset = !sysclk_rstn;

// Prevent GSR from resetting its own source:
parameter DISABLED_GSR = "DISABLED";
defparam sysclk_rst_ff.GSR = DISABLED_GSR;

GSR GSR_INST
(
// Global set/reset is active low:
.GSR (sysclk_rstn)
);

--
Gabor
 

Welcome to EDABoard.com

Sponsor

Back
Top