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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 111275

Article: 111275
Subject: Re: Xilinx MIG 1.6 doesn't launch
From: "Nagesh" <nageshcgupta@gmail.com>
Date: 31 Oct 2006 17:05:43 -0800
Links: << >>  << T >>  << A >>
Hi,

Can you verify the following:

1. %xilinx%coregen\ip\xilinx\other\com\xilinx\ip  ------------ This
folder should have a folder mig_v1_6

2. %xilinx%coregen\ip\xilinx\other --------------------------- This
folder should have mig_v1_6.xml file it has all the settings needed by
coregen.

MIG has been working well with Coregen. Make sure to also check the
Xilinx answer record 23787 - it talks about the ISE versions required
for MIG 1.6.

Let us know how this goes.

Thanks,
Nagesh

RobertP. wrote:
> Your name wrote:
> > Hi there,
> >
> > I've recently installed the Xilinx ISE toolset so that I can play with the
> > Memory Interface Generator.  I followed the readme and installed ISE 8.1i,
> > 8.1i_SP3 and then MIG 1.6.  When I open CORE Generator and select MIG from
> > the drop down list nothing happens. I get the "Customise" and "View Data
> > Sheet" links but when I click on them nothing happens.
> >
> > Is there another download that I've missed or is the Xilinx software just
> > flaky?
> >
> What family are you targeting?
>
> I think there is a mistake in mig_v1_6.xml file.
> If you view it, you can find a following line:
> <family>virtex5</family>
>
> In version 1.5 it is:
> <family>spartan3 spartan3e virtex4</family>
>
> Some time ago I tried to add other families to a 1.6 version .xml file
> and it worked fine for Spartan3.
> 
> -- 
> Regards
> RobertP.


Article: 111276
Subject: Blog from Lattice Semiconductor
From: MK Wong <lsckwong@netvigator.com>
Date: Wed, 01 Nov 2006 09:46:45 +0800
Links: << >>  << T >>  << A >>
Hi there,

I found one blog which is written by Lattice's staff. It sounds like a 
"un-official" channel to provide feedback or ask question to Lattice. 
Here is the URL.

http://www.latticeblogs.typepad.com/

Have fun.

MK

Article: 111277
Subject: Re: Dual Port RAM
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 31 Oct 2006 17:47:10 -0800
Links: << >>  << T >>  << A >>
KJ, You like standards.
We just finished implementing PCIexpress. When I look at the complexity
of that standard, I just cringe. I cannot fathom why one needs so much
stuff to communicate data. But then I am old frugal and basic guy who
believes in simplicity.
Talking about a FIFO, what other standard interface do you want, except
data-in, data-out, 2 clocks, 2 enables, 4 flags and perhaps a reset?
Isn't that about as generic as it can get? Why would Altera do it
differently, except that they don't have a hard-coded 550 MHz one...
:-(
I vote for smarter synthesis tool that interprete your intentions in
the best possible way.
Peter Alfke

On Oct 31, 12:33 pm, "KJ" <Kevin.Jenni...@Unisys.com> wrote:
> Peter Alfke wrote:
> > Real progress comes from better integration of popular functions.
> > That's why we now include "hard-coded" FIFO and ECC controllers in the
> > BlockRAM, Ethernet and PCIe controllers, multi-gigabit transceivers,
> > and microprocessors.None of that is precluded, I'm just saying that I haven't heard why it
> could not be accomplished within a standard framework.  Why would the
> entity (i.e. the interface) for brand X's FIFO with ECC, Ethernet,
> blah, blah, blah, not use a standard user side interface in addition to
> the external standards?  Besides facilitating movement (which is not
> the only concern) it promotes ease of use in the first place.
>
> > Clock control with DCMs and PLLs, as well as
> > configurable 75-ps incremental I/O delays are lower-level examples.I agree, those are good examples of some of the easiest things that
> could have a standardized interface....although I don't think you
> really agree with my reading of what you wrote ;)
>
> > These features increase the value of our FPGAs, but they definitely are
> > not generic.I said standardized not 'generic'.  I was discussing the interface to
> that nifty wiz bang item and saying that the interface could be
> standardized, the implementation is free to take as much advantage of
> the part as it wishes.
>
>
>
> > If a user wants to treat our FPGAs in a generic way, so that the design
> > can painlessly be migrated to our competitor, all these powerful,
> > cost-saving and performance-enhancing features (from either X or A)
> > must be avoided. That negates 80% of any progress from generation to
> > generation. Most users might not want to pay that price.My point was to agree on a standard interface for given functionality
> not some dumbed down generic vanilla implementation of that function.
>
> To take an example, and using your numbers, are you suggesting that the
> performance of a Xilinx DDR controller implemented using the Wishbone
> interface would be 80% slower than the functionally identical DDR
> controller that Xilinx has?  If so, why is that?  If not then what
> point were you trying to make?
>
>
>
> > And remember, standards are nice and necessary for interfacing between
> > chips, but they always lag the "cutting edge" by several years.I don't think any of the FPGA vendors target only the 'cutting edge'
> designs.  I'm pretty sure that most of their revenue and profit comes
> from designs that are not 'cutting edge' so that would give you those
> 'several years' to get the standardized IP in place.
>
> > Have
> > you ever attended the bickering at a standards meeting?...Stop bickering so much.  The IC guys cooperate and march to the
> drumbeat of the IC roadmap whether they think it is possible or not at
> that time (but also recognizing what the technology hurdles to get
> there are).  There is precedent for cooperation in the industry.
>
> > Cutting edge FPGAs will become ever less generic.Again, my point was standardization of the entity of the IP, not
> whether it is 'generic'.
>
> > That's a fact of life, and it helps you build better and less costly
> > systems.But not supported by anything you've said here.  Again, my point was
> for a given function, why can't the interface to that component be
> standardized?  Provide an example to bolster your point (as I've
> suggested with the earlier comments regarding the Wishbone/Xilinx DDR
> controller example).
> 
> KJ
> 
> KJ


Article: 111278
Subject: Re: Dual Port RAM
From: Ray Andraka <ray@andraka.com>
Date: Tue, 31 Oct 2006 21:49:11 -0500
Links: << >>  << T >>  << A >>
KJ,

This is actually a fairly common usage  model for the Xilinx dual port 
RAMs. It lets you, for example store two words per clock on one port and 
read them one word per clock on the opposite port at perhaps a faster 
clock rate. The data width and address width vary inversely so that 
there are always 18k or 16K bits in the memory (18K for the widths that 
support the parity bit).  For example, if you set one port for 36 bit 
width, that port has a depth of 512 words.  If you then set the other 
port for 18 bit width, it has a 1K depth, and the extra address bit (the 
  extra bits are added at the lsbs) essentially selects the low or high 
half of the 36 bit width for access through the 18 bit port.  Similarly, 
a 9 bit wide port is 2K deep and accesses a 9 bit slice of that 36 bit 
word for each access, with the slice selected with the 2 lsbs of the 9 
bit wide port's address.

I've found the easiest way to deal with the dual port memories is to 
instantiate the primitives.  Xilinx has made it far easier with the 
virtex 4 which has a common BRAM element for all aspect ratios with 
generics on it to define the width.  Previously, you needed to 
instantiate the specific primitive with the right aspect ratios on each 
port.  I found it easiest to develop a wrapper for the memory that uses 
the width of the address and data to select the BRAM aspect ratio and 
instantiate as many as are needed to obtain the data width, that way the 
hard work is done just once.  This is especially true with the older 
style primitives.

Article: 111279
Subject: Re: Dual Port RAM
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 31 Oct 2006 19:14:58 -0800
Links: << >>  << T >>  << A >>
There is also a way to use the two ports as two completely independent
half-size RAMs, by making sure thet the two ports never overlap their
addressing. The division does not even have to be 50:50 and the widths
can differ, as can clock and enables. There is some room for
creativity...
Peter Alfke

On Oct 31, 6:49 pm, Ray Andraka <r...@andraka.com> wrote:
> KJ,
>
> This is actually a fairly common usage  model for the Xilinx dual port
> RAMs. It lets you, for example store two words per clock on one port and
> read them one word per clock on the opposite port at perhaps a faster
> clock rate. The data width and address width vary inversely so that
> there are always 18k or 16K bits in the memory (18K for the widths that
> support the parity bit).  For example, if you set one port for 36 bit
> width, that port has a depth of 512 words.  If you then set the other
> port for 18 bit width, it has a 1K depth, and the extra address bit (the
>   extra bits are added at the lsbs) essentially selects the low or high
> half of the 36 bit width for access through the 18 bit port.  Similarly,
> a 9 bit wide port is 2K deep and accesses a 9 bit slice of that 36 bit
> word for each access, with the slice selected with the 2 lsbs of the 9
> bit wide port's address.
>
> I've found the easiest way to deal with the dual port memories is to
> instantiate the primitives.  Xilinx has made it far easier with the
> virtex 4 which has a common BRAM element for all aspect ratios with
> generics on it to define the width.  Previously, you needed to
> instantiate the specific primitive with the right aspect ratios on each
> port.  I found it easiest to develop a wrapper for the memory that uses
> the width of the address and data to select the BRAM aspect ratio and
> instantiate as many as are needed to obtain the data width, that way the
> hard work is done just once.  This is especially true with the older
> style primitives.


Article: 111280
Subject: Re: filter design for low-pass
From: will.parks@gmail.com
Date: 31 Oct 2006 19:15:31 -0800
Links: << >>  << T >>  << A >>
I think you are right that sampling and then filtering does not buy you
more S/N ratio.

However, I'm not sure if I explained the problem correctly. The analogy
would be more similar to if you had a noisey dotted line that goes down
the middle of the road. You want to follow the line as quickly as
possible, but your car only moves at 200 Hz. So you can either decimate
your observations of the dotted line to 200 Hz or filter to 200 Hz.

Maybe if I understood what decimation did in fourier space? Is
decimation like sampling? Is it like applying a cut-off frequency, and
so the nyquist theorem applies? does it need it's own anti-aliasing
filters?

Thanks for this discussion! I think I've made a lot of headway in
understanding. If I can write a filter that filters once or twice and
gets most of the work done by decimation, this will save a lot of gates
on my fpga.

Also, thanks for the choise of textbooks. The book I've been consulting
is good at almost telling you how it works, but then they give example
code in MATLAB, which is too meta and you never see anything!

Will

On Oct 31, 7:35 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> First addressing the broader question:
>   The A/D converter will have a noise floor specified in dBFS.  This noise
> floor is what you would integrate over the filtered bandwidth to determine
> the total Signal to Noise Ratio.  If you use a much higher bandwith, the
> total noise power will increase proportionately but you filter that back out
> and you're back to where you started.  Typically the moise increases when
> you start to approach the device limits; using a 1 MS/s A/D at 1 kS/s versus
> 5 kS/s may make no difference but 500 kS/s to 800 kS/s may be noticeable.
>
> At particularly low frequencies, you may see an uptick in the noise floor as
> other noise sources start to invade your signal chain such as schott noise.
>
> On another subject, decimation could be a good thing.  Imagine being able to
> evaluate your position on the road as you're driving at 60 frames per second
> video rates.  Do you need to adjust your steering at 60 Hz?  No.  Your
> adjustments are partly dictated by the response of your system.  There's no
> sense in providing 200 kS/s of adjustments to a system with 200 Hz response.
> You can, but there will be no gain as driving isn't improved with faster
> corrections.
>
> - John_H
>
> <will.pa...@gmail.com> wrote in messagenews:1162334446.598731.231140@m7g2000cwm.googlegroups.com...
>
> > Thanks for your reply. It does seem like I sould start with an easy
> > filter first and work up to the filter I want to built.
>
> > Something Tim Wescott said perplexes me, though. Filtering and then
> > decimating does sound like it will be computationally cheap, but I
> > wonder just what is the advantage of decimating a control variable?
>
> > I'm fixed at 200kHz sampling, and the process I'm interested in
> > controling is at 200 Hz. Having 200 kHz bandwidth makes the noise
> > larger, (it should be a constant in volts per root hertz, so more
> > bandwidth means larger noise in volts). It seems to me that filtering
> > to 200 Hz is the correct way to reduce the bandwidth and thus reduce
> > the noise in volts. Minimizing the noise is an important concern for
> > controling the process quickly.
>
> > It's not clear to me (and I'm sure this is my fault for not being
> > better informed) that decimating is an equivalent way of reducing the
> > bandwidth. What effect will decimating have on noise as expressed in
> > volts?
>
> > And this brings up a broader question I've hand in the back of my mind.
> > Is it better to sample as high as possible and then filter down to the
> > desired bandwidth? Or is it better to sample as needed, and the gains
> > of sampling like mad and filtering like crazy are minimal. Forget the
> > practical aspects of limited memory and large files.
>
> > I do have a hardware anti-aliasing filters. Your notes made some good
> > points, anti-aliasing is always an important concern!
> 
> > Will


Article: 111281
Subject: Re: Dual Port RAM
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 01 Nov 2006 16:15:55 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> KJ, You like standards.
> We just finished implementing PCIexpress. When I look at the complexity
> of that standard, I just cringe. I cannot fathom why one needs so much
> stuff to communicate data. But then I am old frugal and basic guy who
> believes in simplicity.

Could this have been made any faster, by relaxing some of the standard ?
(and would that have a cost, like interopability ?)

-jg


Article: 111282
Subject: Re: filter design for low-pass
From: Ray Andraka <ray@andraka.com>
Date: Tue, 31 Oct 2006 22:24:51 -0500
Links: << >>  << T >>  << A >>
will.parks@gmail.com wrote:

> Thanks for your reply. It does seem like I sould start with an easy
> filter first and work up to the filter I want to built.
> 
> Something Tim Wescott said perplexes me, though. Filtering and then
> decimating does sound like it will be computationally cheap, but I
> wonder just what is the advantage of decimating a control variable?
> 
> I'm fixed at 200kHz sampling, and the process I'm interested in
> controling is at 200 Hz. Having 200 kHz bandwidth makes the noise
> larger, (it should be a constant in volts per root hertz, so more
> bandwidth means larger noise in volts). It seems to me that filtering
> to 200 Hz is the correct way to reduce the bandwidth and thus reduce
> the noise in volts. Minimizing the noise is an important concern for
> controling the process quickly.
> 
> It's not clear to me (and I'm sure this is my fault for not being
> better informed) that decimating is an equivalent way of reducing the
> bandwidth. What effect will decimating have on noise as expressed in
> volts?
> 
> And this brings up a broader question I've hand in the back of my mind.
> Is it better to sample as high as possible and then filter down to the
> desired bandwidth? Or is it better to sample as needed, and the gains
> of sampling like mad and filtering like crazy are minimal. Forget the
> practical aspects of limited memory and large files.
> 
> I do have a hardware anti-aliasing filters. Your notes made some good
> points, anti-aliasing is always an important concern!
> 
> Will
> 
> 


Decimating is different than bandwidth reduction.  Decimating is 
basically lowering the sample rate to something less that is still 
sufficiently sampled to convey the bandwidth of the signal.  For 
example, if oyur signal has a bandwidth of 200 Hz, it can be fully 
reconstructed with sample rates as low as 400 Hz (although the 
anti-aliasing filters will approach an ideal brick-wall filter as you 
approach 400 Hz sample rate, and therefore get tougher to design as your 
  sample rate approaches the nyquist rate for the signal).

Now, if your signal that is sampled at 200KHz has other noise or other 
signals that you are not interested in, you need to filter those out 
before you decimate, otherwise those out-of-band signals will fold into 
your band of interest (aliasing) when you decimate the sample rate. 
Whether you need to filter or not depends on the signal.

Oversampling has the advantage of making the analog anti-alias filters 
considerably easier to design, and the more the signal is oversampled 
the less stringent the filter characteristics are.  It also spreads out 
the noise due to quantization and other noises in the ADC over a wider 
bandwidth, so after filtering you can end up with a lower effective 
noise floor.  The disadvantage of oversampling is is greatly increases 
the processing load for your digital processing.  In the case of an FIR 
filter, the steepness of the features in the filter's spectral response 
translate to the length of the filter required.  If you try to filter 
the 200 Hz signal from the 200KHz signal in one step, the passband of 
the filter is only 1/500th of the fs/2 for the filter, which in turn 
means a rather long FIR filter. Also, the higher sample rate means less 
time per sample to compute the filtered sample; so by using a higher 
sample rate, you have both a greater number of multiplications to 
perform per sample, and less time to do it in.

The brute-force approach would be to make such a filter, and then 
decimate by 500 after the filter.  As it turns out, you don't need to do 
the computations for the discarded output samples.  There is a structure 
called a poly-phase decimator that rearranges the math so that the 
filter works at the output rate and only performs the computations that 
are needed for the retained output samples.  Also, in this case, it is 
more efficient to decimate in steps with a series of filters.  The first 
filters in the series need only a few taps because the transition region 
  between the passband and stopband doesn't have to be sharp, as it gets 
cut off by the next filter in the chain.  Half-band filters are a 
special class of FIR filters that have a response that is anti-symmetric 
about fs/4 and have nearly half the coefficients set to zero.  For more 
details, google multi-rate filtering.

For high decimation ratios like you have here (500:1), there is yet 
another filter structure that is quite helpful called the CIC or 
cascaded-integrator-comb filter, also sometimes known as a Hogenaur 
filter for the inventor.  That filter is a multiplier-less filter that 
is a recursive implementation of a boxcar filter (a moving average 
without the divide by N).  If I were designing your filter, I would use 
a CIC filter to decimate by 125 or 250 to get the rate down, and follow 
that with one or two decimate by 2 FIR stages, with the second FIR being 
  the one that defines the actual shape of the passband.  The first FIR 
filter is probably no more than about 15 taps, and can be a halfband 
filter.  The second is typically less than 100 taps, but depends highly 
on the shape of the passband relative to the output sample rate.

Article: 111283
Subject: Re: filter design for low-pass
From: Ray Andraka <ray@andraka.com>
Date: Tue, 31 Oct 2006 22:37:59 -0500
Links: << >>  << T >>  << A >>
will.parks@gmail.com wrote:
> I think you are right that sampling and then filtering does not buy you
> more S/N ratio.
> 

Depends on the source of the noise.  It isn't going to help if you have 
wideband noise in the signal.  However, if the noise is due to 
quantization in the ADC, then by decimating you gain effective ADC bits. 
  This is sort of like averaging the error on many samples to get a 
better estimate of one sample assuming the input hasn't changed 
significantly over the many samples.  You can also shape the noise 
induced within the system by employing feedback to push the system noise 
into the stopband of your filter.   This is the principle behind 
delta-sigma converters.

The classic advantage to oversampling, as I mentioned before is that it 
relaxes the specification for your anti-alias filters, making them much 
cheaper to implement.

Article: 111284
Subject: Re: SPDIF receiver
From: Jeff Cunningham <jcc@sover.net>
Date: Tue, 31 Oct 2006 22:51:17 -0500
Links: << >>  << T >>  << A >>
rickman wrote:
> aravind wrote:
> 
>>Hi
>>     Im planning to design an SPDIF receiver for implementation on
>>Spartan 3 FPGA , But im not sure how to go about the design,Does any
>>one have ideas ?
>>Thank u
> 
> 
> I did a quick Google search and found some very informative entries at
> Wikipedia.  To get the low level format description I had to click
> through to the AES/EBU description and even more detail is available at
> one of the references given.
> 
> This should not be a difficult design to figure out, but there are
> details that require attention depending on your application.

One big detail is are you just receiving the data, or are you also 
recovering a clock to feed to downstream codecs?

Article: 111285
Subject: Spectre of Metastability Update
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Tue, 31 Oct 2006 21:14:01 -0800
Links: << >>  << T >>  << A >>
Good news: the "spectre of metastability" appears to be on the wane. I
live less than a mile from Xilinx HQ, yet on Halloween night, not a
single person dressed as metastability showed up at my door for candy
(the closest was a kid in a Napoleon Dynamite getup).

Of course, real metastability is still out there.  As Jack Nicholson
would say, act accordingly.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

Article: 111286
Subject: Re: filter design for low-pass
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 31 Oct 2006 21:30:55 -0800
Links: << >>  << T >>  << A >>
will.parks@gmail.com wrote:

(top posting fixed)

> Tim Wescott wrote:
> 
-- snip --

> Thanks for your reply. It does seem like I sould start with an easy
> filter first and work up to the filter I want to built.
> 
> Something Tim Wescott said perplexes me, though. Filtering and then
> decimating does sound like it will be computationally cheap, but I
> wonder just what is the advantage of decimating a control variable?

It reduces computational load in two ways.  First, and obviously, it 
reduces the frequency that you have to recompute the loop.  This is a 
big deal if you're using a microprocessor, not so much with an FPGA. 
Secondly, it reduces the precision requirements, and hence data path 
widths, in any internal filters in your controller.  Controllers are 
almost invariably implemented with IIR filters, and the closer the 
filter's poles and zeros are to 1 the more precision one needs to 
implement them properly.  If you downsample by a factor of 1000 you 
theoretically reduce your data path widths by 10 bits.
> 
> I'm fixed at 200kHz sampling, and the process I'm interested in
> controling is at 200 Hz. Having 200 kHz bandwidth makes the noise
> larger, (it should be a constant in volts per root hertz, so more
> bandwidth means larger noise in volts). It seems to me that filtering
> to 200 Hz is the correct way to reduce the bandwidth and thus reduce
> the noise in volts. Minimizing the noise is an important concern for
> controling the process quickly.

Ooh ouch.  You're confusing sampling rate with bandwidth.  Please read 
that paper on sampling that I linked to -- you need it.

By "controlling at 200Hz" do you mean that the process has a natural 
bandwidth of 200Hz before you control it, that you designing things to 
have a 200Hz bandwidth after you control it, or that for some reason 
you're constrained to sampling at 200Hz on the output side?  These are 
three very different questions, all of which have the answer "200Hz".

Having a 200kHz bandwidth doesn't necessarily make the noise larger -- 
it depends on the source of the noise.  And you seem to be confusing 
sampling rate with bandwidth.  They _aren't_ the same.

If you're sampling with a typical SAR A/D converter then the converter's 
front end has a bandwidth that's well above the sampling rate, and it 
has a noise level that's well above thermal noise levels.  One of these 
A/D converters will pretty much give you the same noise statistics per 
sample whether you sample it as fast as it'll go, or once every year. 
In this case oversampling and filtering _after_ the A/D conversion 
_will_ reduce noise.
> 
> It's not clear to me (and I'm sure this is my fault for not being
> better informed) that decimating is an equivalent way of reducing the
> bandwidth. What effect will decimating have on noise as expressed in
> volts?

No, decimating by itself doesn't reduce bandwidth, and it won't reduce 
noise at all.  The effect of decimating is to just resample the sampled 
data.  To effectively decimate you need low-pass filter first.  This is 
anti-aliasing, but it isn't usually stated as such -- people usually say 
"filter and decimate".  I dunno why -- it's just common usage.
> 
> And this brings up a broader question I've hand in the back of my mind.
> Is it better to sample as high as possible and then filter down to the
> desired bandwidth? Or is it better to sample as needed, and the gains
> of sampling like mad and filtering like crazy are minimal. Forget the
> practical aspects of limited memory and large files.

It depends on your A/D converter.  With a typical SAR converter, if 
noise is everything you should sample like mad, filter and decimate.  In 
fact, a sigma-delta converter does just that.
> 
> I do have a hardware anti-aliasing filters. Your notes made some good
> points, anti-aliasing is always an important concern!
> 
> Will
> 
> 


-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 111287
Subject: Xilinx ISE, where do the pins go?
From: scott moore <nospam@nowhere.com>
Date: Tue, 31 Oct 2006 22:27:03 -0800
Links: << >>  << T >>  << A >>
Hi, it seems obvious, but I'll ask the question anyways to be sure.

My dual port ram on a Spartan 3 does not use the rst or ena inputs, nor
have but one clock (clka). On the schematic view, it shows these pins
going nowhere. Can I assume this is "shorthand" for "goes to pullup"?
The documentation on the embedded rams says that pullup of unused inputs
is recommended, because "it takes no routed resources", vs. zero driven
inputs. This implies there is a special bit to pull up right at the
input. Does the unconnected pin on the schematic represent this?

Thanks,

Scott Moore

Article: 111288
Subject: Re: Need just a few 5V Spartan
From: Jon Elson <elson@pico-systems.com>
Date: Wed, 01 Nov 2006 00:35:48 -0600
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Have you tried the distributors, including DigiKey?
Digi-Key has NO stock of 5 V Spartan parts.  They will gladly
order some if I place an order for only 60 parts.  That's
a $2178 order!  This is what I get from a number of "stocking"
distributors.  Digi-Key dropped the 5 V Spartan line about 2001,
I think.

Somebody else mentioned the Xilinx store.  They don't sell chips,
period, as far as I can see.  They have links to their franchised
distributors, but there is no link at all for Spartan, or Spartan
2 or 2E.  Only Spartan 3 and 3E.

Jon

Article: 111289
Subject: Re: Need just a few 5V Spartan
From: Jon Elson <elson@pico-systems.com>
Date: Wed, 01 Nov 2006 00:38:21 -0600
Links: << >>  << T >>  << A >>
John_H wrote:
> "Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> wrote in message 
> news:ei8iuu$elg$1@lnx107.hrz.tu-darmstadt.de...
> 
>>Peter Alfke <peter@xilinx.com> wrote:
>>
>>>Have you tried the distributors, including DigiKey?
>>>Peter Alfke
>>
>>For the 5 Volt Xilinx series, none of the part is on stock at Digi,
>>and all have quite high minimum order
>>
>>-- 
>>Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>>
>>Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
>>--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
> 
> 
> 
> 
> XCS30XL-4TQG144I (or C) are both in stock at Digikey but the -3 speed grades 
> have the 60pc minimum order.  Can you get by with the different speed grade? 
> 
> 
Spartan XL is not the 5 V Spartan, it is 3.3 V, and not pin compatible 
with 5 V Spartan.  These chips will not work without major changes to 
the board.  I am doing that, but going to XCS2E.  It is a complete 
from-scratch redesign.

Jon

Article: 111290
Subject: Re: filter design for low-pass
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 01 Nov 2006 07:12:27 GMT
Links: << >>  << T >>  << A >>
will.parks@gmail.com wrote:

<snip>

> Maybe if I understood what decimation did in fourier space? Is
> decimation like sampling? Is it like applying a cut-off frequency, and
> so the nyquist theorem applies? does it need it's own anti-aliasing
> filters?

<snip>

In Fourier space, decimation folds the wideband spectrum over the lower 
frequency in precisely the same fashion that sampling below nyquist 
aliases the higher frequency content back into your band of interest. 
If you sample significantly below nyquist (or decimate by a large 
factor) the folding can happen several times.  By guaranteeing you have 
good stopbands where the aliases fall on your bandwidth of interest, the 
filter-then-decimate approach works for analog and/or digital front ends.

Ray's description is superb but I, too, like to visualize Fourier space.

- John_H

Article: 111291
Subject: Re: Nios 2 application running from external ram
From: Frank van Eijkelenburg <someone@work.com.invalid>
Date: Wed, 01 Nov 2006 08:29:14 +0100
Links: << >>  << T >>  << A >>
Mark wrote:
> Frank van Eijkelenburg wrote:
>> Hi,
>>
>> I have a bootloader running from internal ram (m4k blocks). I also 
>> build a standalone application to run from external ram. The 
>> application is a .bin file which is sent to the bootloader through a 
>> serial interface (RS232). The bootloader copies the application to 
>> external ram and executes it. My application is built to run from 
>> address 0x00200000. If I make a .bin file from the generated .elf file 
>> I get a file of about 2 MB. This is because the alt_exception and 
>> alt_irq_handler is laid at address 0x20 and 0xEC. AFAIK this is not 
>> necessary. Do I have to make a linker file to fix this? Or should I 
>> use another startup assembly file? In case of a linker file, does 
>> anyone have an example for this situation?
>>
>> So the bootloader runs from internal ram (with base address 0) and the 
>> application runs from external ram (with base address 0x00200000).
> 
> I'm assuming you're producing the bootloader and application as separate
> programs and that the bootloader isn't using interrupts.
> 
> In SOPC Builder, set the reset address to 0 and set the exception address
> to 0x00200000.  When you extract the .bin file from the elf file, exclude
> the .reset section so you don't get the generated code at 0x0.
> 
> Mark
> 

Actually, I am using interrupts. Changing the reset address and exception 
address in SOPC builder is not an option. Each time I build the bootloader or 
application I have to check if these addresses are correct. Is there another 
option like using an linker script? For the microblaze I know you can specify 
the start address. Is there a same option for the Nios 2 software?

TIA,
Frank

Article: 111292
Subject: Re: SPDIF receiver
From: "aravind" <aramosfet@gmail.com>
Date: 31 Oct 2006 23:34:46 -0800
Links: << >>  << T >>  << A >>

Jeff Cunningham wrote:
> rickman wrote:
> > aravind wrote:
> >
> >>Hi
> >>     Im planning to design an SPDIF receiver for implementation on
> >>Spartan 3 FPGA , But im not sure how to go about the design,Does any
> >>one have ideas ?
> >>Thank u
> >
> >
> > I did a quick Google search and found some very informative entries at
> > Wikipedia.  To get the low level format description I had to click
> > through to the AES/EBU description and even more detail is available at
> > one of the references given.
> >
> > This should not be a difficult design to figure out, but there are
> > details that require attention depending on your application.
>
> One big detail is are you just receiving the data, or are you also
> recovering a clock to feed to downstream codecs?

I want to receive the data from spdif and convert it to I2S format to
shift out the audio data to a dac such as cs4334.How do i sample the
spdif signal ,synchronize it and convert the biphase mark code to
normal 16 bit audio data in a register.
   I've done all the basic stuff in vhdl like multiplexed 7 segment
display drivers,simple programs on picoblaze processor,etc.


Article: 111293
Subject: Re: Question about bandwidth of scope?
From: "Chris" <nospam@nospam.com>
Date: Tue, 31 Oct 2006 23:45:57 -0800
Links: << >>  << T >>  << A >>
(1) The frequency response of a scope input has nothing to do with the input
impedance.  The frequency response of a scope is measured by driving the
input with an ideal 50 Ohm signal generator.  The input impedance matters
little, and with most very high bandwidth scopes the input impedance is
often 50 Ohms.  The -3dB bandwidth is measured in this way.  That is the
response of the scope by itself.  No probe involved.  This is the ideal
conditions - scope alone.

(2) The input impedance of the front end of the scope is reactive, and has
both a resistive component and capacitance component.  Those are the figures
you quote.  The idea is to match/trim a probe to this input impedance.

(3) When you attach a probe (say 10:1), you adjust/trim the series
capacitance of the probe so that it maintains the 10:1 ratio across all
frequencies.  The Voltage divider is formed by the series impedance of the
probe and the front end impedance of the scope.  That is how the probe input
impedance ends up at 10M Ohms, while the scope is 1M.  However all probes
are designed to work/trim against a fixed range of input impedance.  So for
a scope with a 15pf input, a probe that can trim against a 30-60pf input
impedance would not trim right.  They tell you what the input impedance is
so you can select a probe that will match.

(4)  The 12MHz bandwidth you quote is very low.  For any digital work today
you need at least a 100MHz scope.  Most 10:1 probes today easily go to
100MHz or even 500MHz.  In your case the most limiting factor is the scope.
12MHz is 20-30 years out of date.  You cannot troubleshoot modern circuitry
with 5nS edge times using a scope with 12MHz bandwidth.  The 5nS edge rates
represent about 200MHz bandwidth.  Your signals could be ringing everywhere
causing massive errors in the logic and you would never even see it.

You can by a 100MHz scope on Ebay for about $100.

Regards,  Chris.





Article: 111294
Subject: Re: SPDIF receiver
From: Ian <${send-direct-email-to-news1021-at-jusme-dot-com-if-you-must}@jusme.com>
Date: Wed, 01 Nov 2006 08:21:20 GMT
Links: << >>  << T >>  << A >>
On 2006-10-31, aravind <aramosfet@gmail.com> wrote:
>      Im planning to design an SPDIF receiver for implementation on
> Spartan 3 FPGA , But im not sure how to go about the design,Does any
> one have ideas ?

How *not* to do it:

  http://projects.jusme.com/project/spdifdac

(That's my design so I can say that :)

HTH,
-- 
Ian

"Tamahome!!!" - "Miaka!!!"

Article: 111295
Subject: DDR_controller_EDK
From: "Logaras Evangelos" <>
Date: Wed, 1 Nov 2006 00:25:32 -0800
Links: << >>  << T >>  << A >>
I want to use the MCH OPB DDR controller (mch_opb_ddr) provided in EDK, to connect a DDR memory module to a custom processor design, which does not support the OPB (On-chip Peripheral Bus). I' going to implement the design in a Virtex-II Pro device (XUP board) Are there any modifications that I have to do to the controller produced by the EDK in order to attach it to my design? Is this usage possible, or the controller can only be attached to a Microblaze processor?

Article: 111296
Subject: Re: Need just a few 5V Spartan
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 01 Nov 2006 09:14:30 GMT
Links: << >>  << T >>  << A >>
On Wed, 01 Nov 2006 00:20:36 GMT, "John_H" <newsgroup@johnhandwork.com> wrote:

>"Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> wrote in message 
>news:ei8iuu$elg$1@lnx107.hrz.tu-darmstadt.de...
>> Peter Alfke <peter@xilinx.com> wrote:
>>> Have you tried the distributors, including DigiKey?
>>> Peter Alfke
>>
>> For the 5 Volt Xilinx series, none of the part is on stock at Digi,
>> and all have quite high minimum order
>>
>> -- 
>> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>>
>> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
>> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>
>
>
>XCS30XL-4TQG144I (or C) are both in stock at Digikey but the -3 speed grades 
>have the 60pc minimum order.  Can you get by with the different speed grade? 
>
Have you tried www.findchips.com ? plenty of hits on a search for XC2S -is this the correct family?


Article: 111297
Subject: Re: A spectre is haunting this newsgroup, the spectre of metastability
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Wed, 1 Nov 2006 10:32:30 -0000
Links: << >>  << T >>  << A >>

"Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message 
news:ei8e0q$avt$1@news.lysator.liu.se...
> On 2006-10-31, Ben Jones <ben.jones@xilinx.com> wrote:
>> In fact, register duplication rarely makes timing better; in fact in many
>> high-performance pipelined designs, it can make it much worse 
>> (explanation
>> available on demand).
>
> I guess I'll bite and see if my understanding is close to what you have
> in mind:
>
> My feeling is that register duplication could worsen a design with
> combinatorial logic followed by a flip flop. This means either that
> the combinatorial logic has to be duplicated (which would enlarge the
> design and perhaps slow down the circuit due to extra routing, or
> by only duplicating the flip flop which will certainly demand extra
> routing since it is normally possible to place a FF directly after a LUT
> using only high speed dedicated routing.

Got it in one. The "enlargement" problem isn't much of a problem, since in 
FPGA technology if you need to allocate a new register then you basically 
get the preceding LUT for free. However, it's the "extra routing" problem 
that's the killer.

> On the other hand, I can't really see that register duplication will make
> the performance much worse (unless the synthesizer makes very bad choices)

Say your design is supposed to run at 400MHz (2.5ns clock period). The extra 
route from the combinatorial output of the LUT to the input of the "extra" 
register added by the replication process may be 500ps. That's 20% of your 
cycle budget! Often, it's more like 800ps... of course if your clock speed 
is only 100MHz, this is much less of an issue.

There may be a few scenarios in which register duplication really is a good 
thing, but in my experience synthesis tools don't always find them. So I 
tend to just leave this "feature" turned off.

Cheers,

         -Ben-

(Whoops, off topic...) 



Article: 111298
Subject: Re: Dual Port RAM
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 01 Nov 2006 10:46:22 +0000
Links: << >>  << T >>  << A >>
"KJ" <Kevin.Jennings@Unisys.com> writes:

<snip>

> To have vendor independent useful modules like this, these modules
> should be standardized.  This is exactly the type of thing that LPM
> attempted to do.  LPM languishes as a standard though because it
> didn't get updated to include new and useful modules.

More like it was an Altera-driven "standard" that Xilinx never
supported, so it never got to be vendor independent.

Hmmm, maybe we should all get together and write a Xilinx LPM
library....

> Presumably this is because the FPGA vendors would
> rather go the Mr. Wizard path and try to lock designers in to their
> parts for irrational reasons rather than enhance standards like LPM so
> that designers can remain vendor neutral at design time and let the
> parts selection be based on rational reasons like cost, function and
> performance.
> 
> 

Surely not :-)

Cheers,
Martin
-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   

Article: 111299
Subject: Re: xup virtex2 pro
From: kollarameshk@gmail.com
Date: 1 Nov 2006 03:22:03 -0800
Links: << >>  << T >>  << A >>
Hello,
          Here is a process,that decribes how to create the .cdc file
for chipscope debugging.After you add and open the new .cdc file to the
ise project,it opens the chipscope core inserter window.In that go to
second stage window,you will 3 tabs.
1.Trigger parameters.2.Capture parameters.3.Net connections.

1.In the trigger parameters window you can take the signals,that you
want to trigger with i.e at which stage you want to observe the
data.Trigger width specifies the maximum number of trigger signals.

2.In the capture parameters window you will find all the setting for
capturing.Default the option "Data same as trigger" is checked.So you
can uncheck this field if you want to observe more data than what you
give for trigger.If you uncheck this you will find "Data width" field
which selects the number of signals that you observe.Next "Data depth"
field specifies the number of clock cycles or samples that you want to
capture the data.Then select the clock edge rising or fallling.

3.In the net connections window,you can make signal connections to the
ports that you want to observe.In this window,you will find three
ports(CLOCK,TRIGGER,DATA)in red color initially,when nothing is
connected to the ports.If you want to make make signal connections to
the ports,click modify connections button,then you will get new window
showing three tabs(Trigger signals,Clock signals,Data signals) in the
right side of the window.In the left side you will see all the design
signals.Select the signal what you want to connect and CH number and
click make connections,it will get connected automatically.After
connecting all the signals click ok and click return to project
navugator by saving it.Here all the channels should be connected.

You can also change the previous parameters by going back to previous
sections.
Let me know if you have any questions.

On Oct 31, 4:09 am, "nana" <nmic...@utk.edu> wrote:
> Hello,
>     > I am using xup virtex2 pro with xc2vp30 fpga and I am trying to
> send data
>     > between two boards.
>     > I do not want to use the example (xupv2p_aurora.zip), I want to
> create it.
>     > using aurora software, I generated the aurora core and at the
> command page I
>     > used xilperl to create the .ise file, then I used project
> navigator to run the
>     > project.
>     > Using chipscope, I synthesized and inserted ila.cdc file into the
> design.
>     > One of my problems is when I try to modify my connections in
> chipscope
>     > inserter I don't know what I'm doing, I am a beginner in this.
> Another problem
>     > is the data, I don't know how to deal with it, in other words I
> don't know how
>     > and where to insert it into the design ( I am not very good in
> vhdl or
>     > verilog). And the last problem is that I am using one board right
> now to loop
>     > my data out and in the board, now when I use two boards how do I
> deal with
>     > this and what file should I make changes to?
>     > I really appreciate your help
>     >




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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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