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 113225

Article: 113225
Subject: Query :Regarding Synthesis Report
From: "kartheic anantha" <karthik.anantha@gmail.com>
Date: 8 Dec 2006 11:32:40 -0800
Links: << >>  << T >>  << A >>
At the fourth line of the report, there is mention about CPU time and
Elapsed time. Similarly at the end of the report, just before the
message total memory usage, there is again mention about another CPU
time and Elapsed time. I would like to know precisely what do these two
times mean and what can be interpreted from them for a particular HDL
program. Do they carry significance ?

--Starting of the report --

Release 8.2i - xst I.31
Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved.
--> Parameter TMPDIR set to ./xst/projnav.tmp
CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s
--> Parameter xsthdpdir set to ./xst
CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s
--> Reading design: fsopform.prj


--End of Report --

=========================================================================
CPU : 15.02 / 20.44 s | Elapsed : 15.00 / 21.00 s
-->
Total memory usage is 241916 kilobytes


Article: 113226
Subject: FFT on Virtex II Pro (how to download .dat file?)
From: "Vitaliy" <m.vitaliy@gmail.com>
Date: 8 Dec 2006 11:33:01 -0800
Links: << >>  << T >>  << A >>
Hello,

I am using FFT v.3.2 core from Xilinx to implement FFT algorithm on
FPGA. I would like to download .dat file as my input (which is digital
representation of sinusoidal wave shown below) to test the real-time
functionality

0
30273
23170
-12539
-32767
-12539
23170
30273

I'm not sure if the above data would show up in the correct format in
the newsgroup, but each line represents a point on sine line (.dat file
taken from sample files on Xilinx website - sine_9_375mhz.dat).

Now, I would like to download the project into FPGA and test (using
.dat file) it. Is there a way to download .dat file into FPGA block
memory?

The connectors I have:
1) Parallel IV cable
2) CF card

The software I have (all full educational versions):
1) Xilinx ISE
2) Chipscope Pro
3) FPGA Advantage

I do not currently have A/D converters on FPGA board. I received a
suggestion that I can use counter to represent the sine wave; however,
I would need to perform further operations on the data (which would be
different than constant frequency sinusoidal wave), so using counters
to create those signals would not be the optimal solution for me.

PS. Sorry if this will be double posted.

Thanks,

Vitaliy
Ryerson University


Article: 113227
Subject: Re: RTL Hardware design issue: Count Leading Zeros CLZ
From: Ray Andraka <ray@andraka.com>
Date: Fri, 08 Dec 2006 14:49:15 -0500
Links: << >>  << T >>  << A >>
davidc@ad-holdings.co.uk wrote:

>>Let's consider a 16 bit input.  You can have from 0 to 16 leading 0's
>>(16 leading zeros is a special case, it is 15 where the data is also 0).
>>  In this case we shift left 0 to 15 places, left shifting if all the
>>leading bits for that shift are '0'.  This is done with 4 layers of 2:1
>>muxes shifting by 8,4,2 and then 1 bits.  Each layer's shift select is
>>the logical OR of the left N bits (N=8,4,2 and 1) so that a shift only
>>occurs if all those left bits are 0.
> 
> 
> 
> 
> OK, so the "top" layer has 8 x 2-1 muxes for a 16 bit input (A0-A15),
> the select line for each are connected together
> by a logical OR function, the inputs of which are the left N bits - so
> in this case would the inputs to the OR gate be A15-A8 or is it
> "A1, A3, A5, A7, A9, A11, A13, and A15" which are all OR'd together and
> the output goes to each select line SEL for
> that particular layer?
> 
> 
select for first layer (lyr8 below) is the logical or of bits 15:8 of 
the input.  If all those bits are zero, then it left shifts the input 8 
bit positions, shifting '0's into the 8 lsbs.

The next layer uses the output of the first layer.  If the 4 leftmost 
bits are zero then it shifts the previous (lyr8) result 4 bits to the 
left, filling the rightmost bits with zero.  and so on.

Basically, the decision at each layer is based on whether there are any 
significant (i.e. non-zero) bits in the field that will get shifted off 
the left end if a shift is performed.  If so, then the data is passed 
through unshifted, if not then it is left shifted by the amount for that 
layer.

> 
>>lyr8 <= din(7 downto 0) & X"00" when din(15 downto 8)=X"00" else din;
>>sout(3) <= '1' when din(15 downto 8)=X"00" else '0';
>>lyr4 <= lyr8(11 downto 0) & X"0" when lyr8(15 downto 12)=X"0" else lyr8;
>>sout(2) <= '1' when lyr8(15 downto 12)=X"0" else '0';
>>lyr2 <= lyr4(13 downto 0) &"00" when lyr4(15 downto 14)="00" else lyr4;
>>sout(1) <= '1' when lyr4(15 downto 14)="00" else '0';
>>dout <= lyr2(14 downto 0) & '0' when lyr2(15)='0' else lyr2;
>>sout(0) <= '1' when lyr2(15)='0' else '0';
>>
>>This works if din is unsigned because you only have leading '0's.  If
>>din is 2's complement data, then you have leading sign bits instead of
>>leading '0', so the detection at each stage is made more difficult; in
>>that case it has to see if all the bits that will get shifted out match
>>the leftmost retained bit instead of just being zero so the detect
>>function has an additional term:  when din(15 downto 7)="000000000" or
>>din(15 downto 7)="111111111";  This precludes some shortcuts like using
>>the carry chain to perform the detect.  It is often easier to convert
>>from 2's complement notation to sign-magnitude notation, which is an
>>unsigned magnitude plus an independent sign bit.  The conversion is done
>>by performing the 2's complement if the 2's complement input is negative
>>to get an unsigned magnitude, and then retaining the sign bit.  (this
>>description is to answer a question posed by email).
> 
> 
> I understand what you mean as negative numbers have a "1" at the most
> significant bit which will give a 0 for the CLZ. I think i'll leave the
> 2's compliment for now ;D

2's complement numbers repeat the sign until you get to the first 
significant bit.  For example consider -5 represented as a 2's 
complement 8 bit number:
-5 => 11111011.
for sign magnitude, we represent it instead as +5 with a sign bit:
-5 => 10000101  where the leftmost bit is the sign, and the remaining 
bits are the unsigned absolute value of the number to be represented. 
In that case we leave the sign bit out of the shifter and then shift the 
unsigned portion left to eliminate leading '0's.


> 
> Thanks
> 

Article: 113228
Subject: Xilinx platform flash data sheet confusion (ds123) for clocking
From: fpga_toys@yahoo.com
Date: 8 Dec 2006 11:51:29 -0800
Links: << >>  << T >>  << A >>
page 21 schematic shows "CLK" driving the FPGAs, but note 5 say
"CLKOUT" is used to drive the FPGA's CLK input, any clue which is
correct?


Article: 113229
Subject: FFT on Virtex-II Pro (how to download .dat file?)
From: "Vitaliy" <m.vitaliy@gmail.com>
Date: 8 Dec 2006 11:54:59 -0800
Links: << >>  << T >>  << A >>
Hello,

I am using FFT v.3.2 core from Xilinx to implement FFT algorithm on
FPGA. I would like to download .dat file as my input (which is digital
representation of sinusoidal wave shown below) to test the real-time
functionality

0
30273
23170
-12539
-32767
-12539
23170
30273

I'm not sure if the above data would show up in the correct format in
the newsgroup, but each line represents a point on sine line (.dat file
taken from sample files on Xilinx website - sine_9_375mhz.dat).

Now, I would like to download the project into FPGA and test (using
.dat file) it. Is there a way to download .dat file into FPGA block
memory?

The connectors I have:
1) Parallel IV cable
2) CF card

The software I have (all full educational versions):
1) Xilinx ISE
2) Chipscope Pro
3) FPGA Advantage

I do not currently have A/D converters on FPGA board. I received a
suggestion that I can use counter to represent the sine wave; however,
I would need to perform further operations on the data (which would be
different than constant frequency sinusoidal wave), so using counters
to create those signals would not be the optimal solution for me.


Thanks,

Vitaliy
Ryerson University


Article: 113230
Subject: Query :Regarding Synthesis Report
From: "kartheic anantha" <karthik.anantha@gmail.com>
Date: 8 Dec 2006 11:55:05 -0800
Links: << >>  << T >>  << A >>
At the fourth line of the report, there is mention about CPU time and
Elapsed time. Similarly at the end of the report, just before the
message total memory usage, there is again mention about another CPU
time and Elapsed time. I would like to know precisely what do these two
times mean and what can be interpreted from them for a particular HDL
program. Do they carry significance ?

--Starting of the report --

Release 8.2i - xst I.31
Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved.
--> Parameter TMPDIR set to ./xst/projnav.tmp
CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s
--> Parameter xsthdpdir set to ./xst
CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s
--> Reading design: fsopform.prj


--End of Report --

=========================================================================
CPU : 15.02 / 20.44 s | Elapsed : 15.00 / 21.00 s
-->
Total memory usage is 241916 kilobytes


Article: 113231
Subject: Re: Xilinx platform flash data sheet confusion (ds123) for clocking
From: "Gabor" <gabor@alacron.com>
Date: 8 Dec 2006 12:23:29 -0800
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:
> page 21 schematic shows "CLK" driving the FPGAs, but note 5 say
> "CLKOUT" is used to drive the FPGA's CLK input, any clue which is
> correct?

Note 5 says there are two ways to drive CCLK.  The schematic shows
an external oscillator (using dotted lines) to show one way.  The other
method is not shown in the schematic.  The CLK pin of the XCFxxS
is an input.  CLKOUT is only available on the larger parts (8 Mbits up).


Article: 113232
Subject: Barrel shifter in Virtex4?
From: jetmarc@hotmail.com
Date: 8 Dec 2006 12:25:22 -0800
Links: << >>  << T >>  << A >>
Hi.

I'm trying to implement a fast 128-bit barrel shifter in a Virtex4
device.

The obvious way is a 7-level cascade, each level shifting by another
power of 2.  The result is rather slow.  Adding one pipeline stop I can
achieve just above 125 MHz, but the result is available after 2 clocks
instead of 1.  For my application I'd prefer to get the full result
within a single clock period.

I saw that it's possible to use the DSP48 slices as 18-bit barrel
shifters, but I couldn't figure out how to combine them to form a
128-bit shifter - and less so in a single clock cycle (the DSP48 output
is registered).

Is there anything I can do to speed up the 7-level approach?

Regards,
Marc


Article: 113233
Subject: Re: FFT on Virtex-II Pro (how to download .dat file?)
From: "Gabor" <gabor@alacron.com>
Date: 8 Dec 2006 12:27:27 -0800
Links: << >>  << T >>  << A >>

Vitaliy wrote:
> Hello,
>
> I am using FFT v.3.2 core from Xilinx to implement FFT algorithm on
> FPGA. I would like to download .dat file as my input (which is digital
> representation of sinusoidal wave shown below) to test the real-time
> functionality
>
> 0
> 30273
> 23170
> -12539
> -32767
> -12539
> 23170
> 30273
>
> I'm not sure if the above data would show up in the correct format in
> the newsgroup, but each line represents a point on sine line (.dat file
> taken from sample files on Xilinx website - sine_9_375mhz.dat).
>
> Now, I would like to download the project into FPGA and test (using
> .dat file) it. Is there a way to download .dat file into FPGA block
> memory?
>
> The connectors I have:
> 1) Parallel IV cable
> 2) CF card
>
> The software I have (all full educational versions):
> 1) Xilinx ISE
> 2) Chipscope Pro
> 3) FPGA Advantage
>
> I do not currently have A/D converters on FPGA board. I received a
> suggestion that I can use counter to represent the sine wave; however,
> I would need to perform further operations on the data (which would be
> different than constant frequency sinusoidal wave), so using counters
> to create those signals would not be the optimal solution for me.
>
>
> Thanks,
>
> Vitaliy
> Ryerson University

The easiest way to get data into block memory, assuming it
doesn't have to change during operation, is to generate a ROM
using COREgen.  You can use a .coe format file to initialize
the ROM, which is then built into your project so the data
is in the blockRAM when the bitstream is loaded.  The .coe
file is described in the core datasheet.  It's a comma delimited
list with a selectable radix.

HTH,
Gabor


Article: 113234
Subject: Re: Query :Regarding Synthesis Report
From: "Eric Crabill" <eric.crabill@xilinx.com>
Date: Fri, 8 Dec 2006 12:30:56 -0800
Links: << >>  << T >>  << A >>
Hello,

The elapsed time is what you experience and can measure on your watch 
(namely, how long you had to wait, in seconds, for completion).

The CPU time is a measure of how long the CPU was actually executing 
instructions related to completing the task.  In a multitasking environment, 
your application is not the only application that is "running".  You can see 
this in the Windows task manager, or by using a command like "top" on a unix 
machine.

The difference between the elapsed time and the CPU time is time the CPU 
spent executing other applications, and I believe it also includes overhead 
from application context switching.  I'm not sure how the time spent waiting 
on I/O (e.g. disk or network access) is accounted for.

These values, along with the "Total memory usage is ..." statistic, are not 
directly relevant to digital logic design, and not generally useful to me 
except when trying to figure out:

1.  Why I had to wait longer than expected (was it the task, or the CPU 
load?)  Obviously, this never happens!  ;)
2.  If my computer is in need of a memory upgrade.

Eric

"kartheic anantha" <karthik.anantha@gmail.com> wrote in message 
news:1165606360.895392.303820@l12g2000cwl.googlegroups.com...
> At the fourth line of the report, there is mention about CPU time and
> Elapsed time. Similarly at the end of the report, just before the
> message total memory usage, there is again mention about another CPU
> time and Elapsed time. I would like to know precisely what do these two
> times mean and what can be interpreted from them for a particular HDL
> program. Do they carry significance ?
>
> --Starting of the report --
>
> Release 8.2i - xst I.31
> Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved.
> --> Parameter TMPDIR set to ./xst/projnav.tmp
> CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s
> --> Parameter xsthdpdir set to ./xst
> CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s
> --> Reading design: fsopform.prj
>
>
> --End of Report --
>
> =========================================================================
> CPU : 15.02 / 20.44 s | Elapsed : 15.00 / 21.00 s
> -->
> Total memory usage is 241916 kilobytes
> 



Article: 113235
Subject: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: sp_mclaugh@yahoo.com
Date: 8 Dec 2006 12:49:17 -0800
Links: << >>  << T >>  << A >>
Hello,

I'm in the middle of a project which involves digitizing and decoding
baseband NTSC composite video. Right off the top, I'll let everybody
know that this is part of an educational project (part of it for a
university project, though it's largely a hobbyist type project). I
realize that the project will be useless in a couple years, and that
there are pre-made devices out there, but I still want to do it.

That being said, I think the hardest part of the whole project (for me)
is just getting the data into the FPGA (cleanly)! I know very little
about clock management, and I'm worried that I'm pushing the limits of
my setup. Let me briefly describe what I'm doing.

The traditional way to sample NTSC video, as I understand it, is to use
dedicated chips to derive a "pixel clock" off of the hsync. This clock
then feeds the ADC, and perhaps the FPGA. I am not doing this. I am
using a fixed, free-running crystal oscillator clock (50 MHz Epson
SG-8002JF). For the record, that clock came on my Digilent Spartan 3
starter board, which I'm using for the project. I plan on sampling at
the full 50 MSPS, even though the video signal is band-limited to about
4.2 MHz.

Now -- I'm posting in this group for help on getting the ADC data into
the FPGA. If you don't know anything about video, you can ignore this
next paragraph.

But for those who are interested, I then use an algorithm I've
developed to look for the hsync pulses. The time between hsync pulses
is not exactly constant in the real world. However, since I have many
more samples than I intend on keeping, I use an adaptive algorithm to
keep a fixed number of pixels per line. I'm still working on the gritty
details, but it'll probably involve some type of polyphase resampling.
I then use a DPLL to lock onto the chroma subcarrier burst. The DPLL's
use an efficient sinusoid table, which are made of a block RAM and an
interpolater. I think I've seen this referred to as DDS (direct digital
synthesis). Basically, you keep an index which contains more bits than
are necessary to index the table. Then you use the extra low bits for
interpolation. The DPLL's have two outputs, one of which is 90 degrees
out of phase. In practice, I use two DPLL's, which each lock onto every
other line... Since the chroma subcarrier phase is reversed every other
line, I think this helps the DPLL's to track. I use the DPLL's to
coherently demodulate the chroma signal into I and Q. This involves a
digital multiplier and a FIR windowed-sinc filter. I might change this
to a CIC filter, due to a helpful suggestion from another newgroup
poster. I'll won't go into details of anything past that on this
newsgroup, unless anyone is interested. There are some things I left
out, like a 2d adaptive comb filter, VGA generator, etc.

OK, now onto the issue at hand !

My Digilent starter board has some headers conveniently soldered onto
the PCB. These connect to available digital I/O ports on the Spartan 3.
I was previously going to naively output my clock onto any old pin on
one of these headers, and feed it into the ADC. The ADC will be on a
seperate breadboard. I would also attach a header on that breadboard,
and would use a ribbon cable to connect the clock and (parallel) data
pins. I knew (know) very little about how jittery the clock output
would be. So... I would love to get some help from this group.

I did a google seach for "fpga adc jitter", and found some Usenet
comments. I posted them at the very end of this post. Sorry if it's
considered rude to include such long clips, I'm not sure what the
netiquitte is for that. Some of them were helpful, but I still feel
shakey about the subject.

I now plan to connect my crystal oscillator *directly* to the ADC (by
soldering on a wire directly from the PCB, without going through the
FPGA at all), will jitter be a problem? In one of my threads from a
different newsgroup, a poster said that I might want to use a buffer
register (or a FIFO) to seperate the "clean" clock domain from the
"dirty" clock domain. That way, the data will be delayed a tiny amount,
but it will always be ready when the FPGA tries to read it (with its
jittered clock). However, when I did a search for "adc fifo", I found
that lots of people are using an FPGA *as* the FIFO. So is an external
buffer needed? Could I perhaps the Xilinx's DCM to just phase-shift my
FPGA clock by 90 or 180 degrees, so that the ADC data is sure to be
ready and waiting when I read it?

One of the posts (which I clipped to this post) says that some
high-speed ADC's have their own clock *OUTPUT*, which I can feed *TO*
the FPGA. Can someone suggest an example of a 50 MSPS video ADC (ie, by
"video ADC", I mean: with built-in clamping, sample-and-hold, and AGC)?
I hadn't even thought of doing it this way, but would it be easier?

Finally, another one of the clippings below says that commercial FPGA +
ADC boards often feed the ADC clock directly from the FPGA (as I had
intended to do). So, the obvious question is, how bad is it in reality?
I only need 8 bits of precision (10 might be nice) - some loss of color
detail is acceptable for this educational project. Can I get that by
driving the ADC from the FPGA's clock? Remember that my signal is
band-limited to 4.2 MHz, so it isn't very fast-changing relative to
what the ADC can handle.

Is there a way (in Xilinx) that I can be *sure* that the clock passes
directly from the FPGA input pin to the output pin *without* going
through a DPLL?

Any completely alternative ideas? Suggestions to web sites or books
with explanations?

Thanks for the help, and for reading this long post !!

Regards,

Sean

------------------------------------

1)

The issue is not whether or not it works, rather it is an issue of
noise added
to you sampled signal due to sampling jitter.  A better set-up is to
run the
clock directly from your oscillator to the ADC and to the FPGA, then
use the DLL
in the FPGA to solve the I/O timing issues at the ADC.  Frequently, the
ADC data
is brought through a discrete registers such as an 'LS374 before going
into the
FPGA to improve the timing relationship at the expense of an additional
cycle of
clock latency.

Amazingly, several of the commercial boards out there that have an FPGA
and a
decent speed ADC are set up with the ADC clock supplied through the
FPGA, an
arrangement that doesn't make sense for real DSP applications.

2)

I'm not sure what you mean by drive the ADC with the FPGA. The signal
flow is the other way around: the ADC will drive the FPGA. You should
not drive your ADC clocks from the FPGA. The jitter introduced by the
FPGA will absolutely kill the noise performance of the ADC at 800MHz.
At 100 MHz it will reduce the SNR to considerably less than the 10
bits.
Use a clean external clock to clock the ADC. Most high speed ADCs have
a clock output that can be fed to the FPGA to get a clean transfer of
the ADC data into the FPGA.

3)

BTW, the jitter tolerance for the ADC is based on your input
frequencies rather than
on the ADC clock itself. The problem comes about by the sampling time
uncertainty.
The faster your signal changes, the less jitter you can handle at a
given noise
level. It is not trivial to design an ADC circuit that meets the part
specs even at
40 MHz, jitter can make the effective size of the converter quite a bit
smaller if
you are not careful.
There are a number of commercial boards out with FPGAs and ADCs on
them. I can't
think of even one that isn't driving the ADC clock from the FPGA. That
doesn't mean
it is the right way to do it, just that the designer either didn't know
better or
didn't want to give up the 'flexibility'.

4)

The major caution to using PLL generated clocks is to watch the clock
jitter,
which can be significant at 200MHz.  This can be accounted for in the
FPGA design
by subtracting the max jitter from the period constraint.  It is a bit
more
problematic if it is used to clock an ADC or DAC, as then you introduce
aperature
jitter which in turn translates to a degradation of the SNR.

---

The above were all posted by Ray Andraka, I believe. Hopefully he's
still around on these newsgroups, he seems to know the subject very
well!


Article: 113236
Subject: Re: Barrel shifter in Virtex4?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 08 Dec 2006 15:53:11 -0500
Links: << >>  << T >>  << A >>
jetmarc@hotmail.com wrote:

> Hi.
> 
> I'm trying to implement a fast 128-bit barrel shifter in a Virtex4
> device.
> 
> The obvious way is a 7-level cascade, each level shifting by another
> power of 2.  The result is rather slow.  Adding one pipeline stop I can
> achieve just above 125 MHz, but the result is available after 2 clocks
> instead of 1.  For my application I'd prefer to get the full result
> within a single clock period.
> 
> I saw that it's possible to use the DSP48 slices as 18-bit barrel
> shifters, but I couldn't figure out how to combine them to form a
> 128-bit shifter - and less so in a single clock cycle (the DSP48 output
> is registered).
> 
> Is there anything I can do to speed up the 7-level approach?
> 
> Regards,
> Marc
> 

There's not a lot you can do if you need it in a single clock cycle. 
The DSP48's can be used with some pipelining for more than 17 bits shift 
(17 bits is what you get with one because the multipliers are signed) by 
recognizing a shift is a multiply by a power of two and then cascading 
the DSP48s as though you were building a multi-precision multiplier. 
You can get clever with the DSP48's to reduce the number needed as well.

Article: 113237
Subject: Re: FFT on Virtex-II Pro (how to download .dat file?)
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Fri, 8 Dec 2006 15:08:29 -0600
Links: << >>  << T >>  << A >>
I wouldn't put to much faith in that plan as I have tried something similar 
to that and putting any serious amount of data into a .coe file crashes 
corgen.


---Matthew Hicks


"Gabor" <gabor@alacron.com> wrote in message 
news:1165609647.067578.96990@80g2000cwy.googlegroups.com...
>
> Vitaliy wrote:
>> Hello,
>>
>> I am using FFT v.3.2 core from Xilinx to implement FFT algorithm on
>> FPGA. I would like to download .dat file as my input (which is digital
>> representation of sinusoidal wave shown below) to test the real-time
>> functionality
>>
>> 0
>> 30273
>> 23170
>> -12539
>> -32767
>> -12539
>> 23170
>> 30273
>>
>> I'm not sure if the above data would show up in the correct format in
>> the newsgroup, but each line represents a point on sine line (.dat file
>> taken from sample files on Xilinx website - sine_9_375mhz.dat).
>>
>> Now, I would like to download the project into FPGA and test (using
>> .dat file) it. Is there a way to download .dat file into FPGA block
>> memory?
>>
>> The connectors I have:
>> 1) Parallel IV cable
>> 2) CF card
>>
>> The software I have (all full educational versions):
>> 1) Xilinx ISE
>> 2) Chipscope Pro
>> 3) FPGA Advantage
>>
>> I do not currently have A/D converters on FPGA board. I received a
>> suggestion that I can use counter to represent the sine wave; however,
>> I would need to perform further operations on the data (which would be
>> different than constant frequency sinusoidal wave), so using counters
>> to create those signals would not be the optimal solution for me.
>>
>>
>> Thanks,
>>
>> Vitaliy
>> Ryerson University
>
> The easiest way to get data into block memory, assuming it
> doesn't have to change during operation, is to generate a ROM
> using COREgen.  You can use a .coe format file to initialize
> the ROM, which is then built into your project so the data
> is in the blockRAM when the bitstream is loaded.  The .coe
> file is described in the core datasheet.  It's a comma delimited
> list with a selectable radix.
>
> HTH,
> Gabor
> 



Article: 113238
Subject: Re: About partial reconfiguration in Virtex 4
From: Vic Vadi <vicv@xilinx.com>
Date: Fri, 08 Dec 2006 13:21:23 -0800
Links: << >>  << T >>  << A >>
Hi Perry,
         Partial Configuration through ICAP can be used to dynamically
reconfigure any functional block.

You may find this link helpful:
http://www.xilinx.com/publications/xcellonline/xcell_55/xc_prmethod55.htm
Basically the Xilinx PlanAhead tool has been enhanced to better support
partial reconfiguration flows.

For added convenience we have included a DRP on the System Monitor (V5),
and CMT/MGT (V4 and V5) blocks as Austin mentioned. The DRP allows
faster access to a limitted set of bits at normal fabric clock speeds -
ICAP allows R/W access to all bits - but is slower (configuration clock
frequencies).

Which one you use depends on your application.

- Vic


Austin Lesea wrote:
> Perry,
> 
> Only those blocks that have a dynamic reconfiguration port (DRP) interface.
> 
> We standardized on the DRP so that any block that wanted to provide the
> feature should follow the same interface (a bit like creating an
> internal bus architecture for blocks that need reconfiguration).
> 
> At this time, the DCM, the MGT, and the System Monitor all have DRP.
> There may be more, but you may go to the user's guide, and look at each
> block (PPC, EMAC, PCIe, etc.) to see if they use DRP, or if they have a
> set of registers that are part of the fabric access (or both).
> 
> Austin
> 
> 
> Perry wrote:
> 
>>Hi all,
>>It seems that run-time reconfigurations are only available in DCM and
>>RocketIO blocks.
>>Concerning about partial reconfiguration, can every functional block be
>>partially reconfiged?
>>thanks
>>

Article: 113239
Subject: Re: Xilinx platform flash data sheet confusion (ds123) for clocking
From: fpga_toys@yahoo.com
Date: 8 Dec 2006 13:31:30 -0800
Links: << >>  << T >>  << A >>
Which is what I presumed when I did the layout, and it means that the
schematic is wrong, IE should have CLKOUT for PROM 0, since the
schematic implies that is an output, and the note should say that it's
wired to CLK for the optional configuration with an external clock.


Gabor wrote:
> fpga_toys@yahoo.com wrote:
> > page 21 schematic shows "CLK" driving the FPGAs, but note 5 say
> > "CLKOUT" is used to drive the FPGA's CLK input, any clue which is
> > correct?
>
> Note 5 says there are two ways to drive CCLK.  The schematic shows
> an external oscillator (using dotted lines) to show one way.  The other
> method is not shown in the schematic.  The CLK pin of the XCFxxS
> is an input.  CLKOUT is only available on the larger parts (8 Mbits up).


Article: 113240
Subject: regarding -ve slack while doing post PAR timing analysis
From: "ekavirsrikanth@gmail.com" <ekavirsrikanth@gmail.com>
Date: 8 Dec 2006 13:41:36 -0800
Links: << >>  << T >>  << A >>
                  hi all,

                    i am using spartan 3e fpaga xc3s100e -4 speed grade
i have a  problem while i am doing PAR after that post PAR static
timing analysis i am getting -ve slack as my design needs 155mhz clock
internal i am using DCM and i am generating that clock and that
CLK2X_BUF of DCM is volating and as a result i am getting -ve slack
about 1ns i have tried optins like


place and route effort level medium....

palce and route mode -> multipass route...

and other optins that are there in timing closure report............

but still i am getting -ve slack so i tried option of changing speed
grade -5 that time slack is meetig but i have spartan 3e fpga which is
xc3s100e -4 grade ........

so i tried false path option ........ but in my design timing is
critical so i need to meet timing as false path will ignor that path i
am not sure whether i will get actul timing slack (0 or +ve) in
realtime on board...........

so anybody can plz help me in finding the solution for this and i have
a doubt whether spartan 3e xc3s100e will support freq of 155mhz
............ 

regards
srik


Article: 113241
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: "Gabor" <gabor@alacron.com>
Date: 8 Dec 2006 13:56:32 -0800
Links: << >>  << T >>  << A >>

sp_mclaugh@yahoo.com wrote:
> Hello,
>
> I'm in the middle of a project which involves digitizing and decoding
> baseband NTSC composite video. Right off the top, I'll let everybody
> know that this is part of an educational project (part of it for a
> university project, though it's largely a hobbyist type project). I
> realize that the project will be useless in a couple years, and that
> there are pre-made devices out there, but I still want to do it.
>
> That being said, I think the hardest part of the whole project (for me)
> is just getting the data into the FPGA (cleanly)! I know very little
> about clock management, and I'm worried that I'm pushing the limits of
> my setup. Let me briefly describe what I'm doing.
>
> The traditional way to sample NTSC video, as I understand it, is to use
> dedicated chips to derive a "pixel clock" off of the hsync. This clock
> then feeds the ADC, and perhaps the FPGA. I am not doing this. I am
> using a fixed, free-running crystal oscillator clock (50 MHz Epson
> SG-8002JF). For the record, that clock came on my Digilent Spartan 3
> starter board, which I'm using for the project. I plan on sampling at
> the full 50 MSPS, even though the video signal is band-limited to about
> 4.2 MHz.
>

Quick calculation:
using 4.2 MHz full scale (of the ADC input range) sine wave
4.2MHz is about 26 Mradians/s
ADC input range corresponds to -1 to +1 of normalized sine
1 LSB of 8-bit ADC is therefore 1/128 (normalized).
1 / (26M * 128)  is about 0.3 nS

So for a 1 LSB sampling error, you could live with 300 pSec of
sampling jitter.  My guess is that the threads you looked at
were concerned about significantly smaller acceptable jitter,
as would be the case in most networking applications where
the sampling rate and bandwidth are closer to the same
frequency.

I would guess that your clock oscillator should have much
less than 300 pS jitter unless it is poorly bypassed (power
supply decoupling).  You can run this through the FPGA
without a DCM.  Additional jitter would then only come from
threshold jitter and ground bounce at the FPGA input, which
can be minimized by not using the adjacent IOB's or driving
the adjacent IOB's to ground.

I would worry more about accounting for off-board routing
and ground returns.  Using a differential clock from the
FPGA to the ADC board would help.  If you don't have
an ADC that directly takes a differential clock you'll need
to add a receiver of some sort.  By this time you'll have
a significant delay built up on the data clock, so running
the clock back to the FPGA along with the data will help
you to properly sample the ADC data.


HTH,
Gabor


Article: 113242
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: "John_H" <newsgroup@johnhandwork.com>
Date: 8 Dec 2006 15:18:22 -0800
Links: << >>  << T >>  << A >>
o You wonder about the jitter on the clock.

I liked Gabor's calculations that showed you wouldn't have much of a
problem in data accuracy for your situation.  The differential clock
approach would make things cleaner overall.

o You were worried about bypassing the DCM.

Your FPGA won't use a DCM unless you explicitly include it.

o You're concerned about getting the right sampling point for the data.

The clock-to-out times should be well specified for the ADC you choose.
 At 50 MHz, you'll probably have no issues but if your timing adds up
to be tight, you might run a DCM from the same clock feeding the ADC or
improve your timing budget through other means.  If you can use a
global clock I/O pair on the S3 part on your headers (I don't think I/O
is available for S3E global clocks, just input) you could even use the
clock as it appears on the FPGA pad/ball feeding the ADC as the input
to your global clock buffer with a little care.

Put together a timing budget that shows what your times are from the
clock edge until data is ready at the FPGA pins and compare that with
what the FPGA needs in setup time relative to the 20 ns clock period.
It's the amount of slack in the budget that tells you if your
implementation is a breeze.

o Polyphase filtering is only part of what you can do.

Since the noise you'll see from the clock jitter will be spread across
the full 25 MHz bandwidth of your 50 MS/s data stream, you could either
subsample your signal (aliasing all the noise into your slower rate
baseband) or you can actively filter the signal before decimating with
an FIR or other filter without taking up excessive resources.  Good
execution on this aspect of a video design is superb experience for
digital design.
____

You seem on target with knowing much of what to look for in the design.
 I hope it's fun.

- John_H


Article: 113243
Subject: computer vision projects for open cores
From: "wallge" <wallge@gmail.com>
Date: 8 Dec 2006 15:29:50 -0800
Links: << >>  << T >>  << A >>
I was thinking of implementing some computer vision or neuro-morphic
VHDL designs and then
posting them on open cores, maybe build a library of useful vision
components for the embedded computer vision community (embedded CV was
the topic of my MS thesis).
I wonder if any one would be interested in cooperating in some effort
to make this happen. We could even publish some papers if there was
interest in the library.

Let me know if you are interested and we can look at starting small and
maybe work up to something bigger. I am interested in all sorts of
embedded CV projects (classifiers, feature extraction/detection, image
processing, systolic arrays for image enhancement, GA's, etc).


Regards,

Geoffrey Wall


Article: 113244
Subject: Re: About Unstable Operation of ACTEL(A3P1000)....
From: burn.sir@gmail.com
Date: 8 Dec 2006 16:56:08 -0800
Links: << >>  << T >>  << A >>
Alan,

first of all, if you want to ask questions, please respect the
newsgroup "netiquette". there are already way too many "plz help!!!
design doesnt work!!!" posts on this NG.

that being said, lets take a look at your problem. i am not an expert,
hopefully i can do some helping anyway :)

> The board is A3PE-A3P-EVAL-BRD1 REV3 which is manufactured by Actel Co.
> This board has expantion port for I/O, some LEDs, 1 LCD and regulators,
> just simple design.

A very simple board, rock solid FPGA. Ive never had any problems with
that one. but as far as i know, they come with a A3P250, not a
A3P-1000...

> The tested VHDL source has function of serial communication(UART).

but there are no UART connectors on this board?


> And always, LED blink correctly in VHDL source
> But serial communication function operates unregular
> Sometimes Reciever operates well, But Transmitter is not.
> Sometimes Transmitter operates well, But Reciever is not.

Either your board or FPGA is borken, or its your VHDL design. I would
bet on the latter.

> X-tal is 11.0592MHz and operates correctly.

the default board clock is 40. are you using a PLL? some of the PLLs
are not powered on some actel boards, and sometimes Designer chooses to
use one of them. check your boards documentation!


> Supply voltage is 3.3V for I/O which supplied by Application board from
> Actel
> As I know, TTL level can adapt CMOS 3.3V
> Power ground was one point.
> And I use RS232 to USB converter, but they operate well. Self test
> passed.

that doesnt prove anything. find a scope and check the TX signal
manually.
and I wouldnt add extra sources of failure when things arent working,
connect the UART directly to your PC!

> I don't know well about timing constraints which is default option.
> But palce&router of Actel said satisfying the timing constraint.

do you actually _have_ any?
in any case, i dont think something as simple as an UART could have
timing problems.

> I can't understand about this situation....
> I use same source(VHDL), same program tool(Libero), same
> device(A3P1000) and same programmer(FlashPro3)....But the device
> operation is not regular....
> I test some functions using StartKit from Actel Co.
> Many times, parts of function are un-operation....
> The un-operated functions are not fixed !!! Malfunctions are
> irregular.....................

I usually get this kind of behavior when i forget to synchronize
external signals before reading them. google for "Peter Alfke" and
"Metastability" for more info.

> Also, the source of VHDL had been verified in Altera device
> (EPF10K100ARC240)
> In Altera, all functions are operated correctly...........

I dont think it has anything to do with the FPGA vendor. I have had the
same quick'n-dirty UART design running on actel, xilinx, altera and
lattice boards without any problems.

your problem could of course have something to do with the different
clocks on each board, maybe in some cases the _derived_ uart clock
differs a few percent too much against the ideal UART clock??

> Always, Actel's programmer said "Verifying Passed"....Is that true????

that means that flash pro writes your program to FPGA, then reads it
back to make sure there were to communication errors.
note that some actel FPGAs cant do readback, so the flash pro tool
sometimes says Verifying Passed" without really checking.


> Plz, help me.... I lost self control using Actel's device.... Help me,
> Help me
>
> Are U want any informations? Plz, let me know.. I'm beginner of FPGA..
> :-)
> Are there some options or parameters to consider for palce&route ?

no, the default options are usually ok.

one last thing, the Libero tool comes with a _superb_ beginner tutorial
(there are also videos on their web site), which explains everything
from creating a project to post-layout simulation. have a good look at
those document, then do a post-synthesis simulation to find those nasty
bugs.



burns


Article: 113245
Subject: Re: Looking for simple Cycone 2 example design
From: burn.sir@gmail.com
Date: 8 Dec 2006 17:18:40 -0800
Links: << >>  << T >>  << A >>
there are two 2C35 boards that I know of: Altera NIOS II kit and
Terasic DE2. by the way Mike, there are *hint* IRDA *hint* components
on the DE2 board.

you will find many projects on the Terasic website, ranging from LEDs
flashers to a fully working TV decoder and a music synthesizer. There
are also few universities that use this board in courses, and they
usually have some very exciting projects online.

burns


Mike Harrison wrote:
> I'm looking for a complete project  containing a minimal VHDL design for the Cyclone II, preferably
> 2C35 or similar to have a play around with with prior to getting hold of a real board for an
> upcoming proiject  - the sort of thing that usually comes with a low-end devboard to flash a few
> LEDs etc.
> Can't find anything at Altera for this family.
> If <5MB, please email to mike@whitewing.co.uk, thanks.


Article: 113246
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: sp_mclaugh@yahoo.com
Date: 8 Dec 2006 17:47:30 -0800
Links: << >>  << T >>  << A >>
Comments below.

Gabor wrote:

> Quick calculation:
> using 4.2 MHz full scale (of the ADC input range) sine wave
> 4.2MHz is about 26 Mradians/s
> ADC input range corresponds to -1 to +1 of normalized sine
> 1 LSB of 8-bit ADC is therefore 1/128 (normalized).
> 1 / (26M * 128)  is about 0.3 nS
>
> So for a 1 LSB sampling error, you could live with 300 pSec of
> sampling jitter.  My guess is that the threads you looked at
> were concerned about significantly smaller acceptable jitter,
> as would be the case in most networking applications where
> the sampling rate and bandwidth are closer to the same
> frequency.

Thanks, it's nice to have a concrete figure like that. I hadn't thought
to work backwards and calculate what jitter I can live with (not yet
knowing how much jitter I have).

> I would guess that your clock oscillator should have much
> less than 300 pS jitter unless it is poorly bypassed (power
> supply decoupling).  You can run this through the FPGA
> without a DCM.  Additional jitter would then only come from
> threshold jitter and ground bounce at the FPGA input, which
> can be minimized by not using the adjacent IOB's or driving
> the adjacent IOB's to ground.

OK, after spending *far* too long on Epson's web site (the
eea.epson.com site is poorly organized, though epsontoyocom.co.jp is
better), I found some jitter figures. It says that for a 15pF load and
a 3.3V power source, I should expect 200 ps maximum cycle-to-cycle
jitter, or 250 ps maximum peak-to-peak jitter. As you said, that is
assuming a clean (isolated) power source. I'll describe the power
source in a second. But first, let me paste two lines from Epson's data
sheet that sound a bit ominous:

"Because we use a PLL technology, there are a few cases that the jitter
value will increase when SG-8002 is connected to another
PLL-oscillator. In our experience, we are unable to recommend these
products for applications such as telecom carrier use or analog video
clock use. Please be careful checking in advance for these applications
(jitter specification is max 250 ps / CL = 5 pF."

Perhaps they recommend against it because most commercial applications
would need more than 8 bits of resolution (10 is usually used, I think,
maybe 12 for professional video equipment). After reading that, do you
still think that my application will be OK? And even if I run the clock
through the FPGA?

I don't mind spending $20 or whatever on getting a better clock, if it
sounds like the best solution. I want this system for perform
reasonably well, and I'm willing to pay for it. The starter board even
has an optional 8-pin clock socket, so it would be exceptionally easy
to do. After reading the specs on that Epson clock, I know *why* they
included that socket! :-)

Anyway, I'll now quickly describe the power supply (and decoupling of
clock power input) on the Digilent starter board:

- All power first comes from a 5V AC-DC wall plug
- All power then goes through a LM1086CS-ADJ 3.3V regulator
- For the FPGA, 2.5V and 1.2V are generated from the 3.3V
- The 3.3V is used directly (shared) by a number of on-board
components, including the crystal oscillator clock
- There appear to be 35 parallel 47nF capacitors between 3.3V and
ground
- The only other isolation provided to the oscillator's power pin is
another locally placed 47nF capacitor between power and ground

Does it sound like the clock power input is adequately isolated
(clean)? I don't have a "gut feeling" one way or the other.

> I would worry more about accounting for off-board routing
> and ground returns.

What do you think about the previous plan I mentioned. I'd use about 6"
of standard ribbon cable (about the same grade as ATA cabling) to
connect from a header on the Digilent starter board to the ADC
breadboard.

> Using a differential clock from the
> FPGA to the ADC board would help.  If you don't have
> an ADC that directly takes a differential clock you'll need
> to add a receiver of some sort.

I've never used a differential clock before. I wonder if my Spartan can
do that... Some initial searching did turn up some mention of
differential output pins (being used mostly for DDR memory clocks). If
I can't do it on-chip though, there's no point, because I have to get
to the breadboard to mount any discrete chips. There's no extra space
on the starter board. And I don't intend to build a custom PCB (with
the FPGA) to replace the starter board.

> By this time you'll have
> a significant delay built up on the data clock, so running
> the clock back to the FPGA along with the data will help
> you to properly sample the ADC data.

I understand why there would be delay, but can you explain the part
about running the clock back to the FPGA? Since it's a fixed delay,
couldn't I just use the DCM to delay the Spartan's clock by a fixed
amount?

> HTH,
> Gabor

Very much !! Thanks.


Article: 113247
Subject: How to develop custom opb devices for Microblaze?
From: beagle197@hotmail.com
Date: 8 Dec 2006 21:26:35 -0800
Links: << >>  << T >>  << A >>
Folks,

I have an EDK(*1) based project that utilizes the Microblaze, along
with several peripherals connected via OPB (on-chip peripheral bus) for
use with a Spartan3(*2). The project is set to use VHDL. I would like
to develop a custom data encoder(*3) Verilog module that can be
accessed via C, and I am trying to determine if developing the module
as device that attaches to the OPB would be a good choice of
implementation. Probably I am missing some important technical
considerations about the verilog module's interfaces, etc. However, it
appears that if I try to develop the lzw_opb in this fashion, it will
require that I write a device driver similar to the other OPB
components. Also since the project is set for VHDL, I am not certain
how to develop the Verilog project along side. Wondering if anyone else
has had a similar issue and can perhaps shed some light on how to
approach this kind of problem?

The basic design I have in mind is as follows:

Data Input => UART => C code running on uBlaze => updates state of
lzw_opb => UART => Data out

Thanks,
BEA

*1 Using Xilinx EDK 6.3 Build EDK_Gmm.12.3+1
*2 Spartan3 xc3s400
*3 LZW compression algo


Article: 113248
Subject: Re: Xilinx MPMC2 "External Ports" question
From: "ed_h" <ehenciak@gmail.com>
Date: 8 Dec 2006 22:21:45 -0800
Links: << >>  << T >>  << A >>
I got this working today using the following configuration :

16 bit interface to DRAM (yes, I am using the ML403 right now, but I
plan on migrating to a mini-module in the near future).

One PLB interface (I will split this out to ISPLB and DSPLB later...I
had issues, but that is probably due to lack of experience with EDK).

One NPI interface.  I created an NPI "wrapper" and connected this to
the NPI port on the MPMC2.  Just curious, I noticed that "transparent"
busses are being depreciated according to some documentation I
read...what is the replacement bus type going to be?

Everything looks good so far in terms of running in hardware.  With
this base configuration up and running,   I'll have plenty of
time/flexibility to experiment.  The first thing I want to do is use
the ISPLB/DSPLB interfaces for the performance increases.  For now, I
am simply running a memory test over the weekend.

Just curious, did anyone get this up and running using SRL16s as
opposed to BRAM for the interface FIFOs?  I cannot wait for the version
of the core where you can trade off LUTs for BRAM since the ideal
situation is a mix of memories....still, this is more than adequate for
now :)!

Xilinx support has been very helpful as well as this group.  Thanks!  I
hope to return the favor someday :)!  I've been lurking way too long...

Ed




ed_h wrote:
> Hi all,
>
>    Has anyone ever had success routing an NPI port of the MPMC2
> controller to an External Port of a PPC based system component in EDK
> (i.e. I would like to route an NPI port to some custom logic...I use
> the flow where I use EDK simply to generate a component & I
> subsequently instantiate this in the top level of my VHDL design)?  I
> am having a lot of problems doing this.  Xilinx doesn't have a
> reference design available for this partuicular case; however, the
> documentation for MPMC2 implies that one can do this.  Please keep in
> mind that I am an EDK newbie....I have been using Xilinx
> Alliance/ISE/etc. for many years though :)!
>
>    What I seem to be seeing is that MPMC2 declares the NPI interface to
> be a "transparent bus".  Now, does this imply that I have to make some
> kind of "bus to pins" converter and subsequently declare this component
> in an MPD file, or is this completely useless?  What I tried doing was
> modify the MPMC2 MPD generated by the GUI...I simply removed the
> "transparent bus" declaration from the MPD as well as all the labels on
> the ports that were part of this bus, but that did not seem to help.
> It almost seems like EDK is automatically recognizing the NPI bus as
> some sort of "bus" and is getting confused no matter what I comment out
> of the MPD.
>
>     I understand that my above description sounds rather stupid.
> However, I am just throwing this out there for discussion to see if
> anyone was successful doing this.  Basically, my MPMC has 5 ports :
>
> ISPLB
> DSPLB
> PLB (seems I need this so that I can add PLB slaves....if not added in
> the MPMC2, I recall seeing errors...all reference designs seem to have
> this as well).
> OPB (again, seems like I need this in the MPMC2 or else I get errors
> when adding OPB slaves to my EDK design...all reference designs seem to
> have this as well)
> NPI
>
> All I really thought I would need would be the ISPLB and DSPLB so that
> the PowerPC would have fast access to the DDR DRAM.  The NPI is
> basically intended as port for storing data that is streaming into the
> FPGA.  I hope to use custom hardware to pop data from DRAM after the
> PowerPC does some processing on it.
>
> If anyone has any tips, tricks, pointers, etc., it would be appreciated
> greatly!  I filed a webcase on this, but I would have to imagine that
> someone out there has run into this situation before!
>
> Thanks!
>
> Ed
>
> PS After re-reading this before posting, I realized that some of the
> errors or warnings I get are related  to the block diagram generator
> getting confused about multiple busses and probably not able to place
> and route the block diagram...this might simply be a red herring & an
> actual physical implementation might be OK....I will post again if that
> is the case, but I am having problems with the PLB masters and slaves
> now not having matching bit widths...ugh...


Article: 113249
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: sp_mclaugh@yahoo.com
Date: 8 Dec 2006 22:22:51 -0800
Links: << >>  << T >>  << A >>
Wow! This newsgroup is like having a whole team of consultants or
professors. Barely took an hour to get two really helpful replies!

John_H wrote:
> o You wonder about the jitter on the clock.
>
> I liked Gabor's calculations that showed you wouldn't have much of a
> problem in data accuracy for your situation.  The differential clock
> approach would make things cleaner overall.

As did I ! I'm looking into the differential clock approach now, though
I fear that it won't be do-able. I *think* the Spartan 3 can do
differential output, using special features of the IOB's, but it seems
that some external setup/calibration components (resistors) are
required. It would be up to Digilent (producer of my starter board) to
have properly implemented these. There appear to be quite a few
"special" output modes (ie, LVPECL, etc) and I would be lucky for them
to have implemented exactly the one I need. Building my own PCB for the
Spartan is out of the question at this time (it would take me a year or
more to learn all the necessary skills). I could be mistaken - maybe
there is an easy way. That's just my current best-guess after a few
hours of research.

> o You were worried about bypassing the DCM.
>
> Your FPGA won't use a DCM unless you explicitly include it.

That's good to know. I wonder if I should still worry about routing the
clock through the FPGA's output header to drive the ADC. Perhaps there
would be added jitter due to other reasons, such as active switching
flip-flops near the driving IOB... ? I'm basically repeating this from
another post I've read, I don't know what order of noise we're talking
about here, and whether it's negligible compared to my poor oscillator.

> o You're concerned about getting the right sampling point for the data.
>
> The clock-to-out times should be well specified for the ADC you choose.
>  At 50 MHz, you'll probably have no issues but if your timing adds up
> to be tight, you might run a DCM from the same clock feeding the ADC or
> improve your timing budget through other means.

I think you're talking about the same thing I say a bit further down
(offsetting the FPGA clock by the clock-to-out time), but correct me if
I'm wrong.

>  If you can use a
> global clock I/O pair on the S3 part on your headers (I don't think I/O
> is available for S3E global clocks, just input) you could even use the
> clock as it appears on the FPGA pad/ball feeding the ADC as the input
> to your global clock buffer with a little care.

As of even yesterday, anything about the internal clock distribution in
the FPGA would have flown right over my head. However, earlier this
afternoon, I was reading a bit about the global clock buffers, etc.
It'll take me awhile to digest all the literature I've read from
Xilinx, plus what you wrote. So I'll get back to you on that one.
Though if you're in the spoon-feeding type of mood, my mouth is open.

> Put together a timing budget that shows what your times are from the
> clock edge until data is ready at the FPGA pins and compare that with
> what the FPGA needs in setup time relative to the 20 ns clock period.
> It's the amount of slack in the budget that tells you if your
> implementation is a breeze.

Ah yes, a timing budget is something I will be doing. Of course, the
rest of my design isn't finished yet, so I don't yet know what type of
max setup times I'll need. I guess if I use input buffers (using
IOB's), the setup time to get the data into the FPGA will be
independent of the rest of my design, right? I've never touched any IOB
features before, but it seems easy (just set a single attribute, I
think...?).

On the other hand, couldn't I avoid the issue altogether by using a DCM
to adjust my FPGA clock by the clock-to-out time of the ADC? That way,
the data is ready right on the rising edge of my FPGA clock. It seems
that I can make adjustments in increments of 1/256 of my clock
frequency.

> o Polyphase filtering is only part of what you can do.
>
> Since the noise you'll see from the clock jitter will be spread across
> the full 25 MHz bandwidth of your 50 MS/s data stream, you could either
> subsample your signal (aliasing all the noise into your slower rate
> baseband) or you can actively filter the signal before decimating with
> an FIR or other filter without taking up excessive resources.  Good
> execution on this aspect of a video design is superb experience for
> digital design.

Good point! On my first reading, I got caught up on the "subsample"
part for awhile, and kept thinking thoughts about running an ADC below
the center frequency of a narrow band-pass signal. Then I realized that
you were referring to the method I use to choose which samples to keep
(ie, decimation, etc), and the "aliasing noise into..." part became
clear.

Now, it turns out that I *was* going to include a low-pass block in my
polyphase resampler, but I must confess, I wasn't thinking of cutting
out noise due to clock jitter in my ADC. I knew that I had to
band-limit my signal before decimation, but I figured that the only
high-frequency information would be noise coming directly from the
video source. Cutting out a large chunk of the noise caused by jitter
in my sampling clock is a very welcome bonus!

So in essence, by sampling at 50 MSPS rather than the minimum of 8.4
MSPS, and then applying a low pass with cutoff around 4.2 MHz, I'm
getting rid of about (25-4.2)/25 * 100% = 83% of the noise to to jitter
on the ADC clock (assuming the noise content is uniformly distributed
from 0 to 25 MHz)... Does that calculation sound right (assumes ideal
filters, etc)? If so, what a pleasant surprise!

 ____
>
> You seem on target with knowing much of what to look for in the design.
>  I hope it's fun.

I appreciate the kind words, though I think I'm right on the borderline
capability-wise. Let's hope I'm not right below that line - close
enough to waste a lot of time, but just too far to ever get it working!
But yes, it should be a fun project.

The info you gave was very helpful, thanks!

Regards,

Sean




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