[SI-LIST] Re: LC filters on SDRAM signal lines
- From: "Rose, Michael" <mrose@xxxxxxxxxxxxxxxxx>
- To: steve weir <weirsi@xxxxxxxxxx>, "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>
- Date: Fri, 24 Jun 2011 20:05:09 -0400
Is the buffer drive strength configurable? Slew rate configurable? Are there
any signal line terminations? Are the nets topologies tee'd or point to point?
Is the problem worse when you write alternating FFFF, 0000? More predomnant on
reads or writes?
This sounds like a fundamental SI issue. Might be time to roll up your sleeves
and probe around with a scope while running various patterns. Adding series
inductance seems counter intuitive to me.
Good luck, Mike
________________________________________
From: si-list-bounce@xxxxxxxxxxxxx [si-list-bounce@xxxxxxxxxxxxx] On Behalf Of
steve weir [weirsi@xxxxxxxxxx]
Sent: Friday, June 24, 2011 3:29 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: LC filters on SDRAM signal lines
OK so the problem is that you need to protect your receiver from BB
noise. Appropriate placement and stack-up are the first and most
important issues. After that will be noise coupling through the PDN.
Trying to slow your signals down should be a method of last resort.
Steve.
On 6/24/2011 11:08 AM, David Carney (Neenah) wrote:
> To clarify, our problem is that the GSM module is picking up broadband
> noise whose source is the processor SDRAM bus on the board that the GSM
> module is attached to. The proposal is to filter the SDRAM data lines
> to reduce the high frequency 869-894 MHz + content in these signals
> without affecting the useful frequency content in these 75 MHz signals
> and wrecking the signal integrity or timing on the SDRAM bus. Reducing
> this high frequency content should reduce the amount of noise coupled in
> to the GSM receiver which is currently causing it to have a higher than
> acceptable BER.
>
> This is not necessarily a desirable solution to us since adding all
> these filters is a challenge for space and redoing a lot of routing, but
> it has been suggested that this is one of the most effective solutions.
> I'm trying to figure out how to evaluate whether it will be effective
> and also whether it will not wreck the SDRAM bus SI and timing.
>
> It sounds like your suggestion is to look more closely at the PDN around
> the SDRAM bus before considering filtering the data lines?
>
> Thanks for the response.
>
>
>
> -----Original Message-----
> From: steve weir [mailto:weirsi@xxxxxxxxxx]
> Sent: Friday, June 24, 2011 12:19 PM
> To: David Carney (Neenah)
> Cc: si-list@xxxxxxxxxxxxx
> Subject: Re: [SI-LIST] LC filters on SDRAM signal lines
>
> The point of any filter is to separate signal energy from noise energy.
>
> Before you can begin thinking about a filter you need to determine if
> the offending noise is well outside your signal spectrum. If it is not,
>
> then your only available option is to shield. That is assuming that
> your problem is GSM pick-up on the signal lines. Even though your SDRAM
>
> is only running a 75MHz clock, in order for the timing to be stable you
> will have spectrum at least out to around 400MHz, which is close to half
>
> of the GSM. You don't have much of a window between your required pass
> and stop bands.
>
> The GSM "buzz of death" can get directly into anything that acts as an
> antenna. It also does bad things to PDNs. You need to have a hard look
>
> at your PDN and your layout to see just where it is that the GSM noise
> is coupling in. If you are lucky, you can fix this with some changes to
>
> your bypass network. If you've got a poorly designed stack-up and
> layout where GSM noise is for example directly coupling into your signal
>
> returns, then you will have to address that.
>
> Steve.
> On 6/24/2011 8:47 AM, David Carney (Neenah) wrote:
>> I'm working on an embedded product with a GSM cellular module. The
>> module is picking up broadband noise in the GSM850 band (869-894 MHz)
> at
>> levels of approximately -90dBm to -100dBm from the board it is on.
> The
>> noise is causing BER levels that are too high (fails some tests). The
>> source of the noise has been tracked to a processor SDRAM bus
> interface
>> running at 75 MHz clock frequency. This processor and SDRAM are
>> physically close to the GSM module on the board. One of the many
>> suggestions for mitigating this problem that we are considering is to
>> add LC filters to all of the SDRAM data lines such as the following
>> example parts:
>>
>>
>> Murata NFM18PS105R0J3
>>
> (http://search.murata.co.jp/Ceramy/image/img/PDF/ENG/L0111S0111NFM18PS.p
>> df)
>>
>> TDK MEA1608PH (http://www.tdk.co.jp/tefe02/e9621_mea_signal_1.pdf)
>>
>>
>>
>> These parts are recommended for LCD interfaces. Does anyone have
>> experience using these on SDRAM interfaces? Is this an effective way
> to
>> solve the problem? What considerations do we need to account for in
>> using them? Has anyone modeled these parts for signal integrity
>> simulations? We have been told by Murata that no model is available.
>> What modeling approach did you use?
>>
>>
>>
>> Thanks.
>>
>>
>>
>>
>>
>> David T. Carney P.E.
>>
>> Senior Design Engineer
>>
>> Plexus Engineering Solutions
>>
>> Neenah Design Center
>>
>> 920.751.5646
>>
>>
>>
>>
>> ------------------------------------------------------------------
>> To unsubscribe from si-list:
>> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>>
>> or to administer your membership from a web page, go to:
>> //www.freelists.org/webpage/si-list
>>
>> For help:
>> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>>
>>
>> List technical documents are available at:
>> http://www.si-list.net
>>
>> List archives are viewable at:
>> //www.freelists.org/archives/si-list
>>
>> Old (prior to June 6, 2001) list archives are viewable at:
>> http://www.qsl.net/wb6tpu
>>
>>
>>
>
--
Steve Weir
IPBLOX, LLC
150 N. Center St. #211
Reno, NV 89501
www.ipblox.com
(775) 299-4236 Business
(866) 675-4630 Toll-free
(707) 780-1951 Fax
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
_______________________________________________________________________
This e-mail and any files transmitted with it are proprietary and intended
solely for the use of the individual or entity to whom they are addressed. If
you have reason to believe that you have received this e-mail in error, please
notify the sender and destroy this email and any attached files. Please note
that any views or opinions presented in this e-mail are solely those of the
author and do not necessarily represent those of the Curtiss-Wright Corporation
or any of its subsidiaries. Documents attached hereto may contain technology
subject to government export regulations. Recipient is solely responsible for
ensuring that any re-export, transfer or disclosure of this information is in
accordance with applicable government export regulations. The recipient should
check this e-mail and any attachments for the presence of viruses.
Curtiss-Wright Corporation and its subsidiaries accept no liability for any
damage caused by any virus transmitted by this e-mail.
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
