[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Glitching of PCIRSTN
I appreciate your comments and discussed with my colleague about your
idea and found your assertion is right.
It may cause metastability situations for any FF when rising edges of
clock and nRESET happen at the same time.
The method I will use to get around the situation is to use a 5 levels
of shift registers as nRESET buffers and use the 5th FF signal as global
synchronous reset signal to reset all other FF that will change an
asynchronous reset to a synchronous reset. After 5 levels of shift
registers, metastability situation will be eliminated. I see TI T50 CPU
uses 5 levels of shift registers to change external asynchonous
interrupt signal to internal synchonized interrupt signal.
Thank you very much.
From: Neal Palmer [mailto:firstname.lastname@example.org]
Sent: Tuesday, November 27, 2001 10:48 AM
To: Weng Tianxiang
Subject: RE: Glitching of PCIRSTN
that works fine as long as the deassertion edge of RESET# doesn't
occurr at the rising edge of CLK66M. There are problems when some of
your FFs are in reset and some of them are not in reset on that first
rising edge of the clock. If your design somehow magically has no FFs
changing on the first clock edge after coming out of reset, then you
might be in good shape (not that I have ever seen such a design).
All async reset FFs have a timing requirement between the deassertion
of RST and the rising edge of the clock, and if it isn't met then you
have an unknown output (and the rest of the chip probably won't work).
Also, what happens if you have a reset glitch that is about 0.5ns in
width. Will it get to every FF in your entire design? Probably not.
You really need a way to guarantee that either the entire device reset,
or none of it.
On Tue, 27 Nov 2001, Weng Tianxiang wrote:
> I think my following code is insensitive to RESET# glitch:
> DoDMAPCIPtr : process(nRESET, CLK66M) begin
> if(nRESET = '0') then
> -- initialize code
> elsif(CLK66M'event and CLK66M = '1') then
> -- registered values
> end if;
> end process;
> When nRESET is low, all registers are cleared. It is level sensitive,
> not edge sensitive. nRESET rising edge is used only to latch
> nPCIBusWidth from nREQ64. The value can be correctly loaded, no matter
> nRESET has a glitch or not.
> Any comments are welcome.
> Weng Tianxiang
> Micro Memory Inc.
> 9540 Vassar Avenue
> Chatsworth, CA 91311
> Tel: 818-998-0070
> Fax: 818-998-4459
> -----Original Message-----
> From: Mike Dini [mailto:email@example.com]
> Sent: Monday, November 26, 2001 7:50 PM
> To: firstname.lastname@example.org
> Cc: James Murray
> Subject: Re: Glitching of PCIRSTN
> AHHHHHHHHHHHHHHHHHHH -- Sensitive subject!!!!
> Do NOT EVER trust the async reset on an ASIC to be glitch free! This
> is especially true with PCIRST#!
> At 03:54 PM 11/21/01 -0800, you wrote:
> I have a question regarding the PCIRST.
> Is it necessary to provide a de-glitching circuit on the PCIRST input
> to an ASIC, or can one count on a glitchless PCIRST? What do the FPGA
> people do inside the FPGA regarding this signal?
-- Neal Palmer
The Dini Group
1010 Pearl St #6
La Jolla, CA 92037
(858) 454-3419 x16
(858) 454-1728 (Fax)