FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 08-01-2005, 09:24 PM
Brad Smallridge
Guest
 
Posts: n/a
Default 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


Reply With Quote
  #2 (permalink)  
Old 08-01-2005, 11:18 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

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
Reply With Quote
  #3 (permalink)  
Old 08-02-2005, 01:09 AM
Duane Clark
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

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.


Reply With Quote
  #4 (permalink)  
Old 08-02-2005, 03:40 PM
Vladislav Muravin
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

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" <[email protected]> wrote in message
news:[email protected]
> 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
>
>



Reply With Quote
  #5 (permalink)  
Old 08-03-2005, 01:44 PM
Nial Stewart
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

"Mike Treseler" <[email protected]> wrote in message news:[email protected]
> 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.


Reply With Quote
  #6 (permalink)  
Old 08-03-2005, 06:45 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

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
Reply With Quote
  #7 (permalink)  
Old 08-04-2005, 12:15 AM
Brad Smallridge
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

> 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



Reply With Quote
  #8 (permalink)  
Old 08-04-2005, 01:08 AM
mk
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

On Wed, 3 Aug 2005 15:15:22 -0700, "Brad Smallridge"
<[email protected]> 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.

Reply With Quote
  #9 (permalink)  
Old 08-04-2005, 12:57 PM
Nial Stewart
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

>>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.





Reply With Quote
  #10 (permalink)  
Old 08-04-2005, 01:53 PM
Jonathan Bromley
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

On Thu, 4 Aug 2005 11:57:51 +0100, "Nial Stewart"
<[email protected]> 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:[email protected]
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.
Reply With Quote
  #11 (permalink)  
Old 08-04-2005, 05:37 PM
Nial Stewart
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

>>> synchronizing the reset to your local cock(s)
>
> nooooo, you really don't want to do that at all. Jolly painful.


Jonathan, I hope you're not being rude ;-)

> See the recent thread "Bulletproofing CPLD Design" on comp.lang.vhdl
> for further suggestions from me and others on this issue.


To recap, Jonathan suggests.....
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>

- Datapaths, configuration registers etc have simple asynch reset.
- Sequence-control state machines have asynch reset, but also have
synchronous reset signal that holds them in their idle state.
- Arrange one small dedicated piece of logic that is reset by
asynch reset, and holds the synch reset signal active for
two clocks after asynch reset has been released.

Now, your sequence controllers will remain in their idle state
for two clocks after the end of asynch reset. While they are
in the idle state, no other activity will run in the other parts
of the design. Consequently, it doesn't matter what happens
to the other flip-flops immediately after the end of asynch reset.
But the synchronous reset is applied only to a small part of the
design (the sequence control FSMs) so it consumes very little
extra logic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>


Which is similar to the approach I take, except often the synchronous
reset can also be triggered by an SBC/CPU or whatever to get the FPGA
to a known state.


The question still remains...

"If you drive flip-flop asynchronous reset inputs from a synchronous source,
are the tools intelligent enough to include these paths and the flip-flop
reset mechanism in the timing analysis"?

If so then the extra synchronous reset logic could also be dispensed with.

Anybody from Altera/Xilinx want to comment?


Nial.





Reply With Quote
  #12 (permalink)  
Old 08-04-2005, 07:45 PM
Brad Smallridge
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

Hmm. I have to admit that I didn't think of this. So you can register
your reset at the IO pin and then have that synced output drive the
internal global reset? Is that right?

>> 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.



Reply With Quote
  #13 (permalink)  
Old 08-04-2005, 08:37 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

Brad Smallridge wrote:

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


I like to play with templates.
For production code, I just pick one and use it.

> 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.


Unless the inactive edge is synchronized.

> So this
> sold me on sync resets, end of story.


That will work fine.

>
> When does a CPU know when to reset the FPGA?


In our system, the cpu runs the show.
The FPGA is just one of many chips
that is initialized during boot up.


-- Mike Treseler
Reply With Quote
  #14 (permalink)  
Old 08-04-2005, 09:25 PM
mk
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

On Thu, 4 Aug 2005 11:57:51 +0100, "Nial Stewart"
<[email protected]> wrote:

>>>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.


The Reset to Clock path of a flop is very similar to Input to Clock
path and in all libraries I have used it is a timing check which is
included in the flop description. The release time of the reset is
checked against the clock pulse. By supplying a registered reset, you
are allowing to STA tool to do a better job because now it has an
availabitlity number for reset with respect to clock which can be
checked.
Of course this assumes that your cell library has the reset to clock
timing checks.
Reply With Quote
  #15 (permalink)  
Old 08-04-2005, 09:36 PM
mk
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

On Thu, 4 Aug 2005 10:45:04 -0700, "Brad Smallridge"
<[email protected]> wrote:

>Hmm. I have to admit that I didn't think of this. So you can register
>your reset at the IO pin and then have that synced output drive the
>internal global reset? Is that right?
>
>>> 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.

>


In a way yes and it's safe to do. You don't register the reset signal
though. Assume you have an active low reset. You connect input of a
flop to 1 and connect its async reset input to the reset io pin, a
second flop takes the output of the first as input and it's also async
reset by the io pin. These are clock by your local clock (of course
you have to make sure that for every clock domain in your design, you
repeat this process).

So now when reset io is on, both flops are reset which also resets
your design. When reset io goes high, the first flop can get upset if
it's close to the clock edge but the second flop is perfectly happy as
its input doesn't change at the same clock. On the next clock it sees
the high value on its input (as the first flop is not being reset
anymore) and propagates it to its output (as it's not being reset
either).

This works very nicely if the library has the reset to clk path
characterized and timed.

Reply With Quote
  #16 (permalink)  
Old 08-05-2005, 08:04 PM
Brad Smallridge
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

> In a way yes and it's safe to do. You don't register the reset signal
> though. Assume you have an active low reset. You connect input of a
> flop to 1 and connect its async reset input to the reset io pin, a
> second flop takes the output of the first as input and it's also async
> reset by the io pin. These are clock by your local clock (of course
> you have to make sure that for every clock domain in your design, you
> repeat this process).


OK. Are you doing this with Unisim components? Or can the
XST infer all this through VHDL? And then does the synched
reset from the second flop then connect to some global reset?
And then how do you check that the synthesizer is correctly
inferring to use the synched reset signal?

Brad


Reply With Quote
  #17 (permalink)  
Old 08-05-2005, 08:16 PM
Phil Hays
Guest
 
Posts: n/a
Default Re: Xilinx Best Source for Reset

"Brad Smallridge" wrote:

>> In a way yes and it's safe to do. You don't register the reset signal
>> though. Assume you have an active low reset. You connect input of a
>> flop to 1 and connect its async reset input to the reset io pin, a
>> second flop takes the output of the first as input and it's also async
>> reset by the io pin. These are clock by your local clock (of course
>> you have to make sure that for every clock domain in your design, you
>> repeat this process).

>
>OK. Are you doing this with Unisim components? Or can the
>XST infer all this through VHDL? And then does the synched
>reset from the second flop then connect to some global reset?


Try something like this:

Process(clk,resetin)
begin
if resetin = '1' then
reset1 <= '1';
reset2 <= '1';
elsif rising_edge(clk)
reset1 <= not dll_lock;
reset2 <= reset1;
end if;
end process;

-- one of many processes
Rest_of_logic: process(clk)
begin
if rising_edge(clk) then
if reset = '1' then
-- set reset conditions where needed
else
-- normal operation
end if;
end if;
end process;

Output_needing_forced_off_during_reset: process(regular_oe, reset, d)
begin
if regular_oe = '0' or reset = '1' then
OUTPIN <= 'Z';
else
OUTPIN <= d;
end if;
end process;

>And then how do you check that the synthesizer is correctly
>inferring to use the synched reset signal?


FPGA_editor.


--
Phil Hays
Phil-hays at comcast.moc (remove moc and add net) should work for
email


Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
source control and Xilinx ISE 6 and 7 Andy Peters FPGA 20 04-22-2005 05:28 AM
Source of reset for synchronous reset can lead to metastability? Ken FPGA 6 02-23-2005 09:07 AM
Xilinx source dragonsources Jon Elson FPGA 2 09-17-2003 08:16 PM


All times are GMT +1. The time now is 06:31 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved