Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 29975

Article: 29975
Subject: Re: TOA measurement
From: Ray Andraka <ray@andraka.com>
Date: Tue, 20 Mar 2001 03:22:18 GMT
Links: << >>  << T >>  << A >>
You may be able to recover the pulse using a matched filter, but you are
probably going to have to digitize your data with more than one bit to get good
results with the noise level you indicate.  The output of the matched filter is
essentially a correlation of the signal against a model of the signal.  A
rectangular pulse is not a very good pulse shape for this though.




Kolja Sulimma wrote:
> 
> If I interpret that correctly the main problem is that the noise on the
> relativly slow rise time requires more sophisticated
> processing of the data then just computing the center of the pulse or doing
> something similar.
> 
> I guess in that case I can not help you designing an algorithm, but when you
> find one, we can talk about the FPGA implementation.
> In general for DSP on small fixed point data FPGA is a good choice.
> 
> CU,
>         Kolja
> 
> Michal Kvasnicka wrote:
> 
> > OK...
> > From my point of view delay measurement needs two delayed signal which are
> > compared in the TDE (time delay estimation) algorithm, but TOA measurement
> > work only with one precisely sampled signal and any available additional
> > apriory knowledge (pulse shape, noise model, etc.).
> >
> > Radar pulse can be approximated by trapezoidal (symmetric or asymmetric)
> > pulse wit the following parameters:
> > pulse width = 0.5 - 500us (50% amplitude level)
> > rise time = 20-100ns
> > fall time = 20-200ns
> > sample interval = 1 - 10ns
> > Pulse repetition interval = 1 - 5000us
> >
> > These pulses (pulse train) is contaminated by noise of the general form
> > (colored nongaussian, spread spectrum, etc.) with low S/N ration (in many
> > cases). Finally is represented by 1-channel data stream sampled by 1-10ns
> > and with precise time stamping.
> >
> > Time sampling is realized by Rubidium normal (short term stability about
> > 10^-12 ) connected with GPS time receiver for long term stability about
> > 10^-13 - 10^-15.
> >
> > Required TOA accuracy is about 1-10ns.
> >
> > So, I need effective and robust TOA algorithm which can be realized on DSP
> > or FPGA chip sufficiently fast (see PRI value ~ 1-5000us).
> >
> > Regards,
> >
> > Michal
> >
> > "Kolja Sulimma" <kolja@bnl.gov> píse v diskusním príspevku
> > news:3AB65BBE.2055F00D@bnl.gov...
> > > Can you describe the rwquirements in more detail?
> > > Is it just delay measurement with high resolution?
> > > What resolution do you need? And how many channels?
> > >
> > > CU,
> > >         Kolja Sulimma
> > >
> > > Michal Kvasnicka wrote:
> > >
> > > > Does anyone know of any texts or references concerning implementing TOA
> > > > (time of arrival) measurement of the radar signal on FPGA or DSP chips?
> > > >
> > > > Thanks,
> > > >
> > > > Michal
> > >

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com

Article: 29976
Subject: Do I need to tie unused CPLD pins to GND?
From: pratipm@hotmail.com (Pratip Mukherjee)
Date: Tue, 20 Mar 2001 03:32:18 GMT
Links: << >>  << T >>  << A >>
WebPack shows all the unused pin as TIE and explains that:
        TIE  = Tie pin to GND or board trace driven to valid logic level
My question is do I really have to? If so, can I somehow do that internal to 
the CPLD, without actually trying to run a trace (even worse, solder wires) to 
all the unused pins?

Thanks.

Pratip Mukherjee
pratipm@hotmail.com

Article: 29977
Subject: Re: Spartan-II VREF and VCCO
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Tue, 20 Mar 2001 04:32:19 -0000
Links: << >>  << T >>  << A >>
> Sorry, I did not provide all the information: I need something around
> 200Mhz.  I did not find oscillators for that frequency range. If you
> have a source for 200MHz oscillators, please tell me.  That would
> save me a couple of hours.

I haven't seen many that go up to 200 MHz.  They will probably be
expensive.

Vectron makes them.  So does CTS.


This list was posted here a while ago.  You might try some of these links.

> manufacturers of self-contained crystal oscillators include:

> epson   http://www.eea.epson.com/products/qd/qd.htm (north america site)
> fox     http://www.foxonline.com/
> citizen http://www.citizencrystal.com/
> connor  http://www.conwin.com/products/clock.html
> cts     http://www.ctscorp.com/reeves/
> ecs     http://www.ecsxtal.com/

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 29978
Subject: Re: Altera Flex10K config
From: "C.Schlehaus" <carlhermann.schlehaus@t-online.de>
Date: Tue, 20 Mar 2001 07:13:35 +0100
Links: << >>  << T >>  << A >>
Hi,
normally You should just keep the traces between the Bitblaster
connector and the according device pins as short as possible
to ensure clean signals. I got some troubles in a past project
when I tried to configure a 8K by a longer cable between the
BitBlaster (Interface connector for the Bitblaster was
some inches away from the 8K).
I had to amplify the BitBlaster signals by means of a
normal Buffer, e.g. 74HCT240.
But before You put more devices on Your board, You should
check the wiring to be as short as possible and that all
Pulls are available and placed as stated in the AN.
Additionally You could measure, if the 10K responds to the
configuration request.
The normal configuration sequence is, that the BitBlaster
puts a short ground pulse to the nConfig, which the 10K
should respond with a similar "0" pulse at the NStatus.
After the nConfig is released and driven high by the Pull,
the NStatus is changing to high too. If this initial scheme
fails, the device itself doesn't work, thus the DCLK could
be as clean as possible.
If the nConfig / nStatus signals are i.O., it could be the
DCLK / DATA integrity (as I already wrote) or perhaps
You got problems with the stability of Your power supplies.
If You have a DigiScope available, You could send me a
plot of Your's board signals, I'll take a short look on them
and will be back with my comments.

HTH, Carlhermann

"Shareef Jalloq" <sjalloq@hotmail.com> schrieb im Newsbeitrag
news:9965kc$k1o$1@news6.svr.pol.co.uk...
> I've got the pull-up in place but I'm not sure about how clean the DCLK
> signal is.  This is a Uni project and I've put the device on a piece of
> veroboard.  How would I go about cleaning DCLK and DATA0?
>
> Thanks.
>
> "C.Schlehaus" <carlhermann.schlehaus@t-online.de> wrote in message
> news:9960b1$811$03$1@news.t-online.com...
> > Hi,
> >
> > "Shareef Jalloq" <sjalloq@hotmail.com> schrieb im Newsbeitrag
> > news:995p83$g4u$1@news8.svr.pol.co.uk...
> > > I get the following error message when trying to configure a 10K10:
> 'SRAM
> > > load unsuccessful'.  I'm using version 8.1 of MAX+PlusII and a
> BitBlaster
> > > download cable.  It seems to pause right at the end of the config
> process.
> > > Any ideas?
> >
> > That a sign, that the Conf_Done Signal (which is controlled by the 10K)
> > isn't released (You need to have an external pull-Up as shown in the
> > AN).
> > The only question is, why the Conf_Done does not change to high
> > state. You should check, that the Pull is connected an the suggested
> > value.
> > Then, You should check for the signal integrity of DCLK and DATA,
> > as the 10K needs spike-free signals.
> >
> > HTH, Carlhermann
> >
> >
>
>



Article: 29979
Subject: Re: TOA measurement
From: Kolja Sulimma <kolja@bnl.gov>
Date: Tue, 20 Mar 2001 07:32:09 +0100
Links: << >>  << T >>  << A >>
> The FPGA can handle 5-10 ns range gates fairly easily.  Getting much shorter
> than that will require more specialized tricks or some high speed external
> logic.

You mean like connecting the signal to multiple pins and then having IFFs with four
clock
phases?

Kolja


Article: 29980
Subject: Re: TOA measurement
From: "Michal Kvasnicka" <mkvasnicka@volny.cz>
Date: Tue, 20 Mar 2001 08:16:02 +0100
Links: << >>  << T >>  << A >>
Yes, you are absolutely right. But the standard correlation filter gives
very poor results, due to the trapezoidal model pulse with unknown pulse
width and variation of the rise and fall time. Actually, the basic problem
is presence of the noise.

So, I am thinking about STA/LTA (ratio of the short time vers. long time
averaging realized by IIF or FIR filtering) algorithm or something similar.
These kind of algorithms comes from seismology and are relatively robust and
simple to use.

Michal
"Kolja Sulimma" <kolja@bnl.gov> píse v diskusním príspevku
news:3AB68554.5C6AF1F2@bnl.gov...
> If I interpret that correctly the main problem is that the noise on the
> relativly slow rise time requires more sophisticated
> processing of the data then just computing the center of the pulse or
doing
> something similar.
>
> I guess in that case I can not help you designing an algorithm, but when
you
> find one, we can talk about the FPGA implementation.
> In general for DSP on small fixed point data FPGA is a good choice.
>
> CU,
>         Kolja
>
> Michal Kvasnicka wrote:
>
> > OK...
> > From my point of view delay measurement needs two delayed signal which
are
> > compared in the TDE (time delay estimation) algorithm, but TOA
measurement
> > work only with one precisely sampled signal and any available additional
> > apriory knowledge (pulse shape, noise model, etc.).
> >
> > Radar pulse can be approximated by trapezoidal (symmetric or asymmetric)
> > pulse wit the following parameters:
> > pulse width = 0.5 - 500us (50% amplitude level)
> > rise time = 20-100ns
> > fall time = 20-200ns
> > sample interval = 1 - 10ns
> > Pulse repetition interval = 1 - 5000us
> >
> > These pulses (pulse train) is contaminated by noise of the general form
> > (colored nongaussian, spread spectrum, etc.) with low S/N ration (in
many
> > cases). Finally is represented by 1-channel data stream sampled by
1-10ns
> > and with precise time stamping.
> >
> > Time sampling is realized by Rubidium normal (short term stability about
> > 10^-12 ) connected with GPS time receiver for long term stability about
> > 10^-13 - 10^-15.
> >
> > Required TOA accuracy is about 1-10ns.
> >
> > So, I need effective and robust TOA algorithm which can be realized on
DSP
> > or FPGA chip sufficiently fast (see PRI value ~ 1-5000us).
> >
> > Regards,
> >
> > Michal
> >
> > "Kolja Sulimma" <kolja@bnl.gov> píse v diskusním príspevku
> > news:3AB65BBE.2055F00D@bnl.gov...
> > > Can you describe the rwquirements in more detail?
> > > Is it just delay measurement with high resolution?
> > > What resolution do you need? And how many channels?
> > >
> > > CU,
> > >         Kolja Sulimma
> > >
> > > Michal Kvasnicka wrote:
> > >
> > > > Does anyone know of any texts or references concerning implementing
TOA
> > > > (time of arrival) measurement of the radar signal on FPGA or DSP
chips?
> > > >
> > > > Thanks,
> > > >
> > > > Michal
> > >
>



Article: 29981
Subject: Re: FFT in FPGAs
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Tue, 20 Mar 2001 02:37:17 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Rick Collins wrote:
> 
> >  So if the XC2V40 and XC2V1000 parts were available
> > now and I had some reason to believe that I could get them at reasonable
> > prices by the point of production (like a quote) I would love to design
> > them in.
> 
> Consider them available, and - in your time frame- the XC2V3000 also.

I will contact distribution. But I have not had much success in the past
getting any real data. Normally the best they can tell you is price and
delivery, and normally not even that on such new parts. They just say
"It doesn't show up in our computer. Are you sure this is a good
number???"

 
> > But one thing I forgot was that I need to interface to a 5
> > volt PC/104 bus.  The 5 volt IO would make the design much more
> > complex.
> > I would have to add another power rail for an XC2S part or add many
> > buffer parts. Neither one is very workable.
> 
> Well, people are doing it. It's the "price of progress"...

Well, people drive around the DC beltway to get to a job too. But I
don't plan to do that any time soon. I'm already planning on 5, 3.3 and
1.6 volts for the DSP. I can add either 2.5 for the XC2S or 1.8 for the
XC2V, but I really can't have two more voltages on the board, no room
for the supplies or the planes. 

 
> > I seem to remember that one of the V parts was 5 volt TTL compatible if
> > you added series resistors to limit the current. But that would mean
> > some 90+ extra resistors on the board! But it might work. Will the XC2V
> > work this way?
> 
> That's true of XC2V as well as XCV-E. There is a diode to Vccio on each pin ( as
> ESD protection). That diode clamps at 0.7 V above Vccio, i.e. at 4.0V, assuming 3.3
> V Vccio.
> If you have to drive 5-V stuff, you only go to Vccio, which, worst case, could be
> as low as 3.0V.
> If you receive something from 5-V logic, ( I call that "grandfather logic" ) it
> depends on the driving structure. You should be ok if the driver is a totem-pole (
> n-channel pull-up and pull-down), but you need a current-limiting resistor if the
> 5-V driver is complementary, rail-to-rail.

Is there an app note on this? Or is it just as simple as you are
describing it? What is the current limit, so that I can set the resistor
value?

 
> BTW, word is that the start-up current on Spartan-II is being improved, and the
> current is now kind-of proportional to size (i.e. part number). So the small 15 and
> 30 spartan-II devices have a low start-up current.
> 
> >
> >
> > BTW, how can the part be PCI compliant without being 5 volt tolerant? Is
> > it only 3 volt PCI compliant?
> 
> Yes.

Perhaps the data sheet could point this out rather than a blanket
statement of being PCI compatible? It could say, "3.3 volt PCI
compatible". 


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 29982
Subject: Jobs....?
From: "Raintech Consulting Limited" <resumes@raintech.bc.ca>
Date: Tue, 20 Mar 2001 08:08:58 GMT
Links: << >>  << T >>  << A >>
Can one post jobs for design engineers here?



Article: 29983
Subject: Book on FPGA-Design with Xilinx chips
From: Rainer Storn <rainer.storn@infineon.com>
Date: Tue, 20 Mar 2001 09:25:24 +0100
Links: << >>  << T >>  << A >>
Hi all,

I want to make myself knowledgeable in FPGA-Design
with Xilinx-Chips. We have found that for small designs
everything is pretty straightforward. However, for
high clock frequencies (50MHz) and more complex designs
clock delay and skew as well as the clock signal quality
which enters the chip seem to have crucial importance.
In fact even if the VHDL-code is correct, proven by
simulation, the actual implementation sometimes doesn't
work (or does so only with cooling). Can anyone name me
some good references where I can get more insight into
the pits and trapfalls of FPGA-design ?

Regards

Rainer




Article: 29984
Subject: Packing density of Xilinx FPGAs
From: Rainer Storn <rainer.storn@infineon.com>
Date: Tue, 20 Mar 2001 09:35:00 +0100
Links: << >>  << T >>  << A >>
Hi All,

I am new to the FPGA design business so I would like
to verify an information that was given to me by a
fellow engineer. He said that once the packing
density of Xilinx FPGAs exceeds 30% I may run into
timing problems because of the delay variations that
inevitably arise due to difficult routing. In fact we experienced
these problems. It seems that certain clock skew constraints
can never be met. (2ns, 43MHz clock rate, XC40150XV).

Is this a known problem ? Is there anything we can do
about this ?

Regards

Rainer


Article: 29985
Subject: Re: xilinx Webpack missing speed grade
From: Nicolas Matringe <nicolas.matringe@IPricot.com>
Date: Tue, 20 Mar 2001 10:03:50 +0100
Links: << >>  << T >>  << A >>
Eric Smith wrote:

> Yes, and Floorplanner *does* support those devices --- IF you're
> running it from the full-blown Foundation software.  But WebPACK
> doesn't, so they don't supply the necessary data files.

That's what I supposed (I should think more before posting)
I went back to old 2.1i ans I'll wait until we upgrade to 3.3 (planned
soon)
-- 
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/

Article: 29986
Subject: virtex block ram
From: "Andreas Wolf" <andreas.wolf@prodesigncad.de>
Date: Tue, 20 Mar 2001 10:18:50 +0100
Links: << >>  << T >>  << A >>
does anyone have an idea for using lpm-ram ( lpm-ram-dp ) to implement block
ram in a xilinx virtex device ?
With my tests (leo spec + xilinx fitter) i've got only distributed ram .

Andy



Article: 29987
Subject: Re: TOA measurement
From: Juri Kanevski <kanevski@comsys.ntu-kpi.kiev.ua>
Date: Tue, 20 Mar 2001 12:14:15 +0200
Links: << >>  << T >>  << A >>
The correlation method is probably the best solution.
Even the signal can be sampled with poor amplitude resolution.
After thousands of correlation averages you can 
derive the robust correlation peak.
FPGA can implement the correlation with the sampling frequency ca 100
MHz.
When the correlation peak wave is then interpolated
then its peak point can be estimated with the error up to ~1-2 ns.
Really, when the radar impulse has more rich spectrum
then the correlation peak will be stronger.

Ray Andraka wrote:
> 
> You may be able to recover the pulse using a matched filter, but you are
> probably going to have to digitize your data with more than one bit to get good
> results with the noise level you indicate.  The output of the matched filter is
> essentially a correlation of the signal against a model of the signal.  A
> rectangular pulse is not a very good pulse shape for this though.
> 
> Kolja Sulimma wrote:
> >
> > If I interpret that correctly the main problem is that the noise on the
> > relativly slow rise time requires more sophisticated
> > processing of the data then just computing the center of the pulse or doing
> > something similar.
> >
> > I guess in that case I can not help you designing an algorithm, but when you
> > find one, we can talk about the FPGA implementation.
> > In general for DSP on small fixed point data FPGA is a good choice.
> >
> > CU,
> >         Kolja
> >
> > Michal Kvasnicka wrote:
> >
> > > OK...
> > > From my point of view delay measurement needs two delayed signal which are
> > > compared in the TDE (time delay estimation) algorithm, but TOA measurement
> > > work only with one precisely sampled signal and any available additional
> > > apriory knowledge (pulse shape, noise model, etc.).
> > >
> > > Radar pulse can be approximated by trapezoidal (symmetric or asymmetric)
> > > pulse wit the following parameters:
> > > pulse width = 0.5 - 500us (50% amplitude level)
> > > rise time = 20-100ns
> > > fall time = 20-200ns
> > > sample interval = 1 - 10ns
> > > Pulse repetition interval = 1 - 5000us
> > >
> > > These pulses (pulse train) is contaminated by noise of the general form
> > > (colored nongaussian, spread spectrum, etc.) with low S/N ration (in many
> > > cases). Finally is represented by 1-channel data stream sampled by 1-10ns
> > > and with precise time stamping.
> > >
> > > Time sampling is realized by Rubidium normal (short term stability about
> > > 10^-12 ) connected with GPS time receiver for long term stability about
> > > 10^-13 - 10^-15.
> > >
> > > Required TOA accuracy is about 1-10ns.
> > >
> > > So, I need effective and robust TOA algorithm which can be realized on DSP
> > > or FPGA chip sufficiently fast (see PRI value ~ 1-5000us).
> > >
> > > Regards,
> > >
> > > Michal
> > >
> > > "Kolja Sulimma" <kolja@bnl.gov> píse v diskusním príspevku
> > > news:3AB65BBE.2055F00D@bnl.gov...
> > > > Can you describe the rwquirements in more detail?
> > > > Is it just delay measurement with high resolution?
> > > > What resolution do you need? And how many channels?
> > > >
> > > > CU,
> > > >         Kolja Sulimma
> > > >
> > > > Michal Kvasnicka wrote:
> > > >
> > > > > Does anyone know of any texts or references concerning implementing TOA
> > > > > (time of arrival) measurement of the radar signal on FPGA or DSP chips?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Michal
> > > >
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com

Article: 29988
Subject: Re: TBUFs in Virtex and later chips, going out of fashion, what instead
From: Juri Kanevski <kanevski@comsys.ntu-kpi.kiev.ua>
Date: Tue, 20 Mar 2001 12:37:22 +0200
Links: << >>  << T >>  << A >>


Neil Franklin wrote:
> 
> In the earlier Xilinx chips (3000, 4000, 5200) there is always 2
> TBUFs per CLB of 2 LUT+FF. And both TBUF lines can be read.
> 
> In Virtex and Spartan-II it is down to 2 TBUFS for the 4 LUT+FF of an
> CLB, so only one slice can be routed to them, and even only 1 line for
> reading back from TBUF lines.
> 
> In Virtex-II there is even only 2 TBUFs for 8 LUT+FF per CLB. Which
> makes even connecting the output of the 4-wide 2 slices of an single
> carry chain to an bus impossible. The data sheet does not give the
> amount of readbacks.
> 
> From this I get the impression, that Xilinx regards TBUF buses as going
> out of fashion. After all, the TBUFs cost in chip space is next to nothing
> relative to them many PIPs (about 900 per CLB in Virtex).
> 
> 
> So I have a question: What is the Xilinx-suggested replacement for TBUFs?
> Is one supposed to use MUXes implemented in the CLBs? Is there an other
> trick I have not yet stumbled over?

I think that Xilinx
found a compromise in the space functionality-cost.
For these TBUFs and tristate wires 
Xilinx's devices were 2 fold more costly than Altera's ones, I suppose,
because of their heavy technology.

And therefore the only solution is
to try to do without large multiplexors and shared busses.
The way to do without large shared busses in the chip
is the stable tendency now and in the future
because they do not support the clock frequency increase,
and afford the high switshing energy .

A.Ser.

Article: 29989
Subject: Re: TOA measurement
From: "Michal Kvasnicka" <m.kvasnicka@era.cz>
Date: Tue, 20 Mar 2001 12:26:02 +0100
Links: << >>  << T >>  << A >>
You are talking about correlation, but in previous messages I said that the
model pulse (asymmetric trapezoidal pulse with unknown pulse width and rise
or fall time variations) is more or less uknown.

What kind of correlation you have in mind? Please, could you be so kind and
describe your idea more detailed?

Thanks in advance,

Michal
"Juri Kanevski" <kanevski@comsys.ntu-kpi.kiev.ua> pise v diskusnim prispevku
news:3AB72D77.E53BFB9E@comsys.ntu-kpi.kiev.ua...
> The correlation method is probably the best solution.
> Even the signal can be sampled with poor amplitude resolution.
> After thousands of correlation averages you can
> derive the robust correlation peak.
> FPGA can implement the correlation with the sampling frequency ca 100
> MHz.
> When the correlation peak wave is then interpolated
> then its peak point can be estimated with the error up to ~1-2 ns.
> Really, when the radar impulse has more rich spectrum
> then the correlation peak will be stronger.
>
> Ray Andraka wrote:
> >
> > You may be able to recover the pulse using a matched filter, but you are
> > probably going to have to digitize your data with more than one bit to
get good
> > results with the noise level you indicate.  The output of the matched
filter is
> > essentially a correlation of the signal against a model of the signal.
A
> > rectangular pulse is not a very good pulse shape for this though.
> >
> > Kolja Sulimma wrote:
> > >
> > > If I interpret that correctly the main problem is that the noise on
the
> > > relativly slow rise time requires more sophisticated
> > > processing of the data then just computing the center of the pulse or
doing
> > > something similar.
> > >
> > > I guess in that case I can not help you designing an algorithm, but
when you
> > > find one, we can talk about the FPGA implementation.
> > > In general for DSP on small fixed point data FPGA is a good choice.
> > >
> > > CU,
> > >         Kolja
> > >
> > > Michal Kvasnicka wrote:
> > >
> > > > OK...
> > > > From my point of view delay measurement needs two delayed signal
which are
> > > > compared in the TDE (time delay estimation) algorithm, but TOA
measurement
> > > > work only with one precisely sampled signal and any available
additional
> > > > apriory knowledge (pulse shape, noise model, etc.).
> > > >
> > > > Radar pulse can be approximated by trapezoidal (symmetric or
asymmetric)
> > > > pulse wit the following parameters:
> > > > pulse width = 0.5 - 500us (50% amplitude level)
> > > > rise time = 20-100ns
> > > > fall time = 20-200ns
> > > > sample interval = 1 - 10ns
> > > > Pulse repetition interval = 1 - 5000us
> > > >
> > > > These pulses (pulse train) is contaminated by noise of the general
form
> > > > (colored nongaussian, spread spectrum, etc.) with low S/N ration (in
many
> > > > cases). Finally is represented by 1-channel data stream sampled by
1-10ns
> > > > and with precise time stamping.
> > > >
> > > > Time sampling is realized by Rubidium normal (short term stability
about
> > > > 10^-12 ) connected with GPS time receiver for long term stability
about
> > > > 10^-13 - 10^-15.
> > > >
> > > > Required TOA accuracy is about 1-10ns.
> > > >
> > > > So, I need effective and robust TOA algorithm which can be realized
on DSP
> > > > or FPGA chip sufficiently fast (see PRI value ~ 1-5000us).
> > > >
> > > > Regards,
> > > >
> > > > Michal
> > > >
> > > > "Kolja Sulimma" <kolja@bnl.gov> píse v diskusním príspevku
> > > > news:3AB65BBE.2055F00D@bnl.gov...
> > > > > Can you describe the rwquirements in more detail?
> > > > > Is it just delay measurement with high resolution?
> > > > > What resolution do you need? And how many channels?
> > > > >
> > > > > CU,
> > > > >         Kolja Sulimma
> > > > >
> > > > > Michal Kvasnicka wrote:
> > > > >
> > > > > > Does anyone know of any texts or references concerning
implementing TOA
> > > > > > (time of arrival) measurement of the radar signal on FPGA or DSP
chips?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Michal
> > > > >
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com



Article: 29990
Subject: Re: TOA measurement
From: p.kootsookos@remove.ieee.org
Date: 20 Mar 2001 12:02:30 +0000
Links: << >>  << T >>  << A >>
"Michal Kvasnicka" <mkvasnicka@volny.cz> writes:

> Yes, you are absolutely right. But the standard correlation filter gives
> very poor results, due to the trapezoidal model pulse with unknown pulse
> width and variation of the rise and fall time. Actually, the basic problem
> is presence of the noise.

The main reason that correlation gives poor results in this instance
is that the return signal is not pre-whitened.

The unknown pulse width can possibly be catered for by using a bank of
correlators which assume different pulse widths.

The detection problem (finding a signal from noise) is best solved by
a) making sure everything is white and b) choosing a good
peak-detector.

> So, I am thinking about STA/LTA (ratio of the short time vers. long time
> averaging realized by IIF or FIR filtering) algorithm or something similar.
> These kind of algorithms comes from seismology and are relatively robust and
> simple to use.

I'm not sure what you mean by this: do you mean running two filters:
one tuned to the shortest pulse length and one to the longest?

Ciao,

Peter K.

-- 
Peter J. Kootsookos          Wb: www.clubi.ie/PeterK
"Here comes the future and you can't run from it,
If you've got a blacklist I want to be on it"
- 'Waiting for the great leap forwards', Billy Bragg

Article: 29991
Subject: Re: TOA measurement
From: p.kootsookos@remove.ieee.org
Date: 20 Mar 2001 12:03:46 +0000
Links: << >>  << T >>  << A >>
Meant to say: Sorry my previous post wasn't particularly relevant to
FPGAs; I do think you need to understand what the _best_ solution to
the problem is first and _then_ apply the best FPGA implementation of
it.

Ciao,

Peter K.

-- 
Peter J. Kootsookos          Wb: www.clubi.ie/PeterK
"Here comes the future and you can't run from it,
If you've got a blacklist I want to be on it"
- 'Waiting for the great leap forwards', Billy Bragg

Article: 29992
Subject: Re: Packing density of Xilinx FPGAs
From: "Simon Bacon" <simonb@tile.demon.co.cut_this.uk>
Date: Tue, 20 Mar 2001 12:07:55 -0000
Links: << >>  << T >>  << A >>
"Rainer Storn" <rainer.storn@infineon.com> wrote

> I am new to the FPGA design business so I would like
> to verify an information that was given to me by a
> fellow engineer. He said that once the packing
> density of Xilinx FPGAs exceeds 30% I may run into
> timing problems because of the delay variations that
> inevitably arise due to difficult routing. In fact we experienced
> these problems. It seems that certain clock skew constraints
> can never be met. (2ns, 43MHz clock rate, XC40150XV).

This was a problem on XC4000 parts, though 30% sounds rather
low.  Much better on Virtex/Virtex-E, where the ratio of
routing to logic is higher.

> Is this a known problem ? Is there anything we can do
> about this ?

Floorpan, floorplan, floorplan.





Article: 29993
Subject: Re: IRDY/TRDY (was Re: More detailed Spartan II CLB drawings?)
From: "Simon Bacon" <simonb@tile.demon.co.cut_this.uk>
Date: Tue, 20 Mar 2001 12:09:21 -0000
Links: << >>  << T >>  << A >>
"Ray Andraka" <ray@andraka.com> wrote
> it is a 5 input ROM (combinatorial, not configurable).  I had the contents
about
> a year ago, but alas, I've misplaced the information. Fortunately you can
easily
> discover the function with a trivial test circuit which you can wire using the
> FPGA editor.

I guess the logic should be available in a simulation library.





Article: 29994
Subject: Re: TOA measurement
From: Kolja Sulimma <kolja@bnl.gov>
Date: Tue, 20 Mar 2001 13:41:12 +0100
Links: << >>  << T >>  << A >>


Juri Kanevski wrote:

> FPGA can implement the correlation with the sampling frequency ca 100
> MHz.

There was a 16 channel correlator published years ago that achieved 250 MHz in
XC3192A
I admit it was a 100% FPGA-Editor design - I guess those people would have kille to
get their
hands on JBits - but with Virtex-E or Virtex-II higher frequency should be possible.

Kolja


Article: 29995
Subject: Re: Spartan-II VREF and VCCO
From: krw@btv.ibm.com (Keith R. Williams)
Date: Tue, 20 Mar 2001 13:26:29 GMT
Links: << >>  << T >>  << A >>
On Mon, 19 Mar 2001 20:35:15 +0100, Kolja Sulimma <kolja@bnl.gov>
wrote:

>Austin Lesea wrote:
>
>> Don't work so hard!
>
>People keep telling me that ;-)
>
>> Less than 50 ps of RMS jitter is an enormous budget!  There are very few
>> oscillators that are that bad!  Any LVCMOS packaged oscillator will have
>> typically 50 ps peak to peak jitter, and around 6 to 10 ps RMS jitter.
>
>Sorry, I did not provide all the information: I need something around 200Mhz.
>I did not find
>oscillators for that frequency range. If you have a source for 200MHz
>oscillators, please tell me.
>That would save me a couple of hours.
>But there are a couple of clock synthesizers. Most of them - like ICS525 -
>have something like
>200ps to 300ps peak to peak jitter. The Spartan DLL for example adds 60ps
>jitter to the input jitter.
>I only found PECL synthesizers meeting the spec.

I'm using a Motorola 12429 clock generator. It is PECL, which I
continue in a distribution/delay chain with Micrel/Synergy Clockworks
parts. The differential/terminated nature of PECL really helps out at
these frequencies. I then use a SY100EL92 to translate to LVPECL into
the VirtexE. This is expensive stuff, but then so is the VirtexE. 

My backup plan uses an ICS AV9110. These are CMOS and will work to
130MHz.  Using a clock doubler in the CLKDLL would get me to my
desired frequency. The 9110 is 5V CMOS though.  I had to use quick
switches to limit the voltage to 3.3V for the VirtexE.

----
  Keith

Article: 29996
Subject: Re: TOA measurement
From: "Michal Kvasnicka" <m.kvasnicka@era.cz>
Date: Tue, 20 Mar 2001 14:39:48 +0100
Links: << >>  << T >>  << A >>
Thank you very much for your messages.

I know that I need deep insight to the "detection problem (finding a signal
from noise)". So, could you recommend me some good references regarding this
topic and relevant to my previous problem specification?
And next, I want to make myself knowledgeable in FPGA-Design. Is there any
good reference?

Could you prefer fast accessible internet resources before standard literal
references?

Thanks, Michal
<p.kootsookos@remove.ieee.org> píše v diskusním příspěvku
news:uwv9ksl3x.fsf@remove.ieee.org...
> Meant to say: Sorry my previous post wasn't particularly relevant to
> FPGAs; I do think you need to understand what the _best_ solution to
> the problem is first and _then_ apply the best FPGA implementation of
> it.
>
> Ciao,
>
> Peter K.
>
> --
> Peter J. Kootsookos          Wb: www.clubi.ie/PeterK
> "Here comes the future and you can't run from it,
> If you've got a blacklist I want to be on it"
> - 'Waiting for the great leap forwards', Billy Bragg



Article: 29997
Subject: Re: TOA measurement
From: "Michal Kvasnicka" <m.kvasnicka@era.cz>
Date: Tue, 20 Mar 2001 14:41:55 +0100
Links: << >>  << T >>  << A >>
Could you send me references on this correlator?

Michal
"Kolja Sulimma" <kolja@bnl.gov> píse v diskusním príspevku
news:3AB74FE8.5734C3A7@bnl.gov...
>
>
> Juri Kanevski wrote:
>
> > FPGA can implement the correlation with the sampling frequency ca 100
> > MHz.
>
> There was a 16 channel correlator published years ago that achieved 250
MHz in
> XC3192A
> I admit it was a 100% FPGA-Editor design - I guess those people would have
kille to
> get their
> hands on JBits - but with Virtex-E or Virtex-II higher frequency should be
possible.
>
> Kolja
>



Article: 29998
Subject: Re: TOA measurement
From: Ray Andraka <ray@andraka.com>
Date: Tue, 20 Mar 2001 13:42:43 GMT
Links: << >>  << T >>  << A >>
DIfferent animal.  That was a bit pattern correlator.  He needs a matched filter
in this case. 

Kolja Sulimma wrote:
> 
> Juri Kanevski wrote:
> 
> > FPGA can implement the correlation with the sampling frequency ca 100
> > MHz.
> 
> There was a 16 channel correlator published years ago that achieved 250 MHz in
> XC3192A
> I admit it was a 100% FPGA-Editor design - I guess those people would have kille to
> get their
> hands on JBits - but with Virtex-E or Virtex-II higher frequency should be possible.
> 
> Kolja

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com

Article: 29999
Subject: Re: TOA measurement
From: Ray Andraka <ray@andraka.com>
Date: Tue, 20 Mar 2001 13:47:04 GMT
Links: << >>  << T >>  << A >>
Yes. As well as possibly using fractionally placed parallel filters for
fractional range bin resolution.  Reading more of the posts this morning it is
evident that your transmit pulse is not well controlled, which makes it much
tougher...Matched filtering isn't going to work that well.  If you could nail
down either the pulse width or the rise/fall time or both you'd have better
success.



Kolja Sulimma wrote:
> 
> > The FPGA can handle 5-10 ns range gates fairly easily.  Getting much shorter
> > than that will require more specialized tricks or some high speed external
> > logic.
> 
> You mean like connecting the signal to multiple pins and then having IFFs with four
> clock
> phases?
> 
> Kolja

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search