Xilinx Best Source for Reset

Up to now, I have been doing much of my work with ModelSim and
a BMP file reader and writer.  Most of my VHDL designs have clk
and reset.  I know where to attach the clk but what do I use for
reset.  An external pin? The Done pin?  Or a DCM lock signal?

Brad Smallridge
b r a d @ a i v i s i o n . c o m

Brad Smallridge wrote:
> Up to now, I have been doing much of my work with ModelSim and
> a BMP file reader and writer.  Most of my VHDL designs have clk
> and reset.  I know where to attach the clk but what do I use for
> reset.  An external pin? The Done pin?  Or a DCM lock signal?

I drive reset from a cpu running on
the fpga clock. Pulse it after the
binary image is loaded.
This is vendor independent
and synchronous.

     -- Mike Treseler

Brad Smallridge wrote:
> Up to now, I have been doing much of my work with ModelSim and
> a BMP file reader and writer.  Most of my VHDL designs have clk
> and reset.  I know where to attach the clk but what do I use for
> reset.  An external pin? The Done pin?  Or a DCM lock signal?
> 

Is this an asynchronous (power-on) reset you are talking about? In that 
case, for Xilinx parts, instantiate a ROC component:

    component roc
       port (
       O    : out std_logic
       );
    end component;

begin

    -- model of the Xilinx POR
    roc_e: roc
       port map(
          O => RESET
       );

The model for the ROC is in the Xilinx unisim library. The Xilinx tools 
know to assign the RESET net to the internal POR structure. You don't 
need to connect it to any pins.

Brad,

There are two types of reset. One, hardware reset, is typically sourced by 
an external pin. Two, software reset, is typically sourced by a bit written 
by CPU & any other host controller. It all depends on what you are up to.

Sometimes, you might want to reset parts of the design upon some 
synchronization reached or something like this.

Vladislav


"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
news:11estoihe350a2f@corp.supernews.com...
> Up to now, I have been doing much of my work with ModelSim and
> a BMP file reader and writer.  Most of my VHDL designs have clk
> and reset.  I know where to attach the clk but what do I use for
> reset.  An external pin? The Done pin?  Or a DCM lock signal?
>
> Brad Smallridge
> b r a d @ a i v i s i o n . c o m
>
> 

"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:3l7hslF10tsq8U1@individual.net...
> Brad Smallridge wrote:
>> Up to now, I have been doing much of my work with ModelSim and
>> a BMP file reader and writer.  Most of my VHDL designs have clk
>> and reset.  I know where to attach the clk but what do I use for
>> reset.  An external pin? The Done pin?  Or a DCM lock signal?
>
> I drive reset from a cpu running on
> the fpga clock. Pulse it after the
> binary image is loaded.
> This is vendor independent
> and synchronous.
>     -- Mike Treseler


Mike,

Do you then code that reset signal using the normal asynchronous reset
at the start of a clocked process model, or do you code it as a synchronous
reset?

Or do you treat it on a case by case basis?

Nial. 

Nial Stewart wrote:

> Do you then code that reset signal using the normal asynchronous reset
> at the start of a clocked process model, or do you code it as a synchronous
> reset?

I use the asynchronous reset template.
As others have noted, this saves gates.

Here is a benchmark of three templates
on the same design:

http://home.comcast.net/%7Emike_treseler/uart.vhd

     -- Mike Treseler

> http://home.comcast.net/%7Emike_treseler/uart.vhd

Wow, that's an interesting use of procedures to automatically
restructure a program.

I brought the question of async vs. sync reset to the group awhile ago,
and someone told me (they should harp in here to get credit), that with
an async reset you may have metastable issues when your reset goes
inactive, which sort of defeats the purpose of having a reset.  So this
sold me on sync resets, end of story.

When does a CPU know when to reset the FPGA?  PowerUp timing
delay? I am using a Cypress USB chip which has some interesting
PowerUp ennumeration and renumeration issues if anyone has any
experience with this sort of thing.

Brad
 

On Wed, 3 Aug 2005 15:15:22 -0700, "Brad Smallridge"
<bradsmallridge@dslextreme.com> wrote:

>> http://home.comcast.net/%7Emike_treseler/uart.vhd
>
>Wow, that's an interesting use of procedures to automatically
>restructure a program.
>
>I brought the question of async vs. sync reset to the group awhile ago,
>and someone told me (they should harp in here to get credit), that with
>an async reset you may have metastable issues when your reset goes
>inactive, which sort of defeats the purpose of having a reset.  So this
>sold me on sync resets, end of story.

Actually this is a false compromise. There is a perfectly safe way of
synchronizing the reset to your local cock(s) so that there is no
chance of metastability regardless of the reset release time. This way
you can continue to use async resets.

>>I brought the question of async vs. sync reset to the group awhile ago,
>>and someone told me (they should harp in here to get credit), that with
>>an async reset you may have metastable issues when your reset goes
>>inactive, which sort of defeats the purpose of having a reset.  So this
>>sold me on sync resets, end of story.
>
> Actually this is a false compromise. There is a perfectly safe way of
> synchronizing the reset to your local cock(s) so that there is no
> chance of metastability regardless of the reset release time. This way
> you can continue to use async resets.


If you generate a synchronous reset signal then connect that to the asynch
reset input of the registers in your design, can you be sure that the tools
include this path in the timing analysis?

It be a reasonable assumption of those designing the timing analysis tools
that anything going to an asynchronous input doesn't need to be included.

Could you be caught out doing this?

BTW, I'm playing devil's advocate here as I've been using this technique myself
for a while, I'm just checking it's as bulletproof as I assumed it was.


Nial.

On Thu, 4 Aug 2005 11:57:51 +0100, "Nial Stewart"
<nial@nialstewartdevelopments.co.uk> wrote:

>> synchronizing the reset to your local cock(s) 

nooooo, you really don't want to do that at all.  Jolly painful.

>If you generate a synchronous reset signal then connect that to the asynch
>reset input of the registers in your design, can you be sure that the tools
>include this path in the timing analysis?
>
>It be a reasonable assumption of those designing the timing analysis tools
>that anything going to an asynchronous input doesn't need to be included.
>
>Could you be caught out doing this?
>
>BTW, I'm playing devil's advocate here as I've been using this technique myself
>for a while, I'm just checking it's as bulletproof as I assumed it was.

See the recent thread "Bulletproofing CPLD Design" on comp.lang.vhdl
for further suggestions from me and others on this issue.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223          mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.