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 134700

Article: 134700
Subject: Re: Analog Imager interface to FPGA
From: Rob <buzoff@leavemealone.com>
Date: Tue, 26 Aug 2008 21:39:30 -0400
Links: << >>  << T >>  << A >>
Is the imager a CCD?  If so, there are plenty of mfg's out there that 
sell CCD/CIS AFE's: National, AKM, Epson, and TI.  And many of the 
devices offered have the capability of internally moving the sample 
edge.  The converted video is then sent out with a reference clock, so 
you are again sync'd up as the digital video comes into the FPGA.  A 
Cyclone3 will have no problem with these speeds. I've used a Cyclone3 
with a National AFE and Toshiba CCD running quite a bit faster than 15MHz.

Finding a 14 bit ADC might be a bit tricky.  Most of the devices are 
using 10 bit converters; but there are a couple that offer 16 bit (keep 
your eye on the the noise of the converter--usually you'll find that the 
bottom few bits are better suited for random noise generators than real 
data)!  You can get away with 10 bits and a good system will use 12. 
One usually loses a couple of bits in the processing.

If you want some part numbers I can pass them along, too.

Rob



wallge wrote:
> I am working on a video project using an FPGA for all the signal
> processing and output
> video generation, as well as to control all the peripheral PHYs, and
> the image sensor chip.
> 
> Now, one thing that concerns me is that there is a digital control
> interface to the imager IC (to the control the read out of imager rows/
> cols, as well as other integrated functions), yet the video output
> from the imager is a single analog pin. The analog output is actually
> synchronized to a clock that is sent to the imager IC from the FPGA.
> Based on the timing diagram, the analog video should be sampled on the
> falling edge of the clock that is sent to the imager IC.
> 
> Now in between the FPGA and the imager IC, I need a fast analog
> amplifier (to get the analog video in the correct voltage range to be
> sampled - this will depend on the input voltage accepted by the chosen
> ADC) and an ADC IC (to sample the analog video).
> I think both the ADC and the imager will run on the same clock (again,
> generated by the FPGA from external Osc.). My concern is with
> synchronizing the FPGA, the ADC, and the imager, so that the analog
> pixel values are sampled at the right time on the ADC (since they are
> sync'ed to the clock), and registered in at the right time by the FPGA
> (in the eye of the sampled data).
> I am worried that the PCB may introduce delays that will force me to
> have to manually tune (possibly several) clock phase shift(s) sent to
> the imager, the ADC, and the clock used in the FPGA to register in the
> sampled data.  Each block will run at the same clock speed, but may
> need different phase offsets in order to account for delays induced by
> the PCB interconnect or delays through various ICs (phase delay
> through gain ckt, phase delay through sampler, etc).
> 
> Does anyone have any thoughts on this? Perhaps there is a ref. design
> or white paper that you might know of that discusses how to handle
> capturing this kind of analog video output using an FPGA?
> 
> Further assumptions/details: (comments appreciated)
> video clock: <=15MHz (based on frame rate required)
> ADC sample rate: >= 15MSPS?
> ADC sampler bits: 14 (set by system requirements, or should there be
> more than this, due to sampler noise or other PCB induced noise?)
> Analog Gain IC stop/pass band: (pass band should be uniformly flat and
> extend from DC to well above 15MHz, so as not to attenuate any analog
> pixel values?)
> 
> 
> 

Article: 134701
Subject: Re: need fast FPGA suggestions
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 26 Aug 2008 20:09:03 -0700
Links: << >>  << T >>  << A >>
On Tue, 26 Aug 2008 12:56:50 -0500, Jon Elson <elson@wustl.edu> wrote:

>
>
>John Larkin wrote:
>> You can do coarse delays by counting at some modest clock frequency,
>> and get fine delays from a fast-clocked shift register or a simple
>> external analog vernier. The analog thing can take you down to
>> picosecond resolution.
>> 
>> You can also double resolution by using both clock edges.
>> 
>> But can you tolerate the 1-clock p-p jitter that you'll get from
>> asynchronous trigger inputs slamming into a continuous clock?
>
>
>I didn't think so, that's why I designed a hideous analog delay circuit,
>much like the no-longer-available-at-a-sane-price AD9501.  (A current 
>source,
>integrating cap, comparator and DAC)  I ended up with 1200 components on 
>one board for 64 of these delay circuits.  And, it uses the difficult to 
>mount AD CMP603 in the 3 mm square CSP that gave me FITS getting a 
>couple boards working.  Many, many, many shorts and opens!
>
>But, aparently, 2 ns of jitter is NOT a problem.  Only the initial delay 
>will suffer the jitter, the width of the second timer will always be 
>synched to the clock, and so the width won't vary.  That was the more 
>critical part of it.
>
>I'm still researching how you do this with the DDR feature.
>
>Jon

You might consider this trick: when a trigger comes in, start an
oscillator, and use that to clock the FPGA. Then time out with
counters, and use some fractional-clock trick if you need sub-clock
delay or width resolution.

I've done this with LC oscillators and coaxial ceramic resonator
oscillators; both can be started essentially instantly and can have
pretty good jitter performance. The resulting FPGA logic can be pretty
simple.

John




Article: 134702
Subject: Re: need fast FPGA suggestions
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 26 Aug 2008 21:10:17 -0700
Links: << >>  << T >>  << A >>
Andrew FPGA wrote:
>> So, you think a 13-bit counter feeding a 13-bit identity comparator will
>> work at 250 MHz?
> Others have said it may be possible but what they fail to acknowledge
> is the large amount of extra design effort and care required to get
> there. 250 MHz is really pushing the limits in spartan 3e in my
> experience. You may have to work very hard to get there: for example I
> have just finished a distributed arithmetic filter design, that has
> only 1 LUT level between flops and after a lot of effort I got it to
> run at 206 MHz in a sp3 1600e. I can see how to get to 220MHz, but
> beyond that I don't know. The longest carry chain is 10 bits.
> 
> I had to bypass synthesis and instantiate xilinx primitives directly
> to gaurantee my logic was implemented in 1 LUT level. Then I had to
> manually floorplan the design - placing each flop with the
> corresponding LUT by hand( I uses RLOC's embedded in the VHDL source).
> The automatic placer didn't always place the LUT with the FLOP so you
> end up with 2 routes which kills the timing completely.
> 
>> Yeah, I really don't think we can handle $2000 IC's.  This isn't a real
>> production project, we might build 5 of them at a time, but we are still
>> cost-sensitive.
> If its such low volumes just take the unit cost hit and move to a
> Virtex part. How valuable is your time?


Time is valuable - a good tradeoff in any cost analysis.  I'm afraid his 
management may look at his time as a fixed cost and not consider the 
lost opportunity cost of allowing him to get on to new projects quicker.

I had no problem running 300 MHz for a 600 Mb/s front end in the S3E 
(without using the DDR IOBs).  The trick is breaking everything down to 
the 1 level of logic, but through the LUT attached to the register in 
its slice.  I even transferred data between posedge and negedge domains 
(1.6ns!) with latches (rather than flops) to open up the timing budget.

If the counter doesn't want to run full-width at 250MHz, the 2 LSbits 
can run at that rate and a slower counter run at a much lower rate.  Or 
1 LSbit for a 125MHz rate.  It's all good.

The high-speed techniques are for those who know how to pipeline and to 
rearrange algorithms to implement the "lean" logic.  The programmable 
fixed-width counter is an excellent challenge for someone that has the 
brains but not (yet) the experience.  The problem is well confined and 
the results quickly verifiable.

I'd suggest any experienced FPGA designer could do this even if they 
haven't previously pushed the limits.  The experience - to me, at least 
- is very valuable.  For someone who hasn't worked with FPGAs (or 
fine-grain logic gates) the task might be too much "fresh out of the 
chute."  I'd recommend the challenge to anyone wanting to expand their 
skills.

- John_H

Article: 134703
Subject: Re: AES decryption (ASIC)
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Tue, 26 Aug 2008 22:55:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 26 Aug., 09:51, swissiyous...@gmail.com wrote:
> To implement an AES decryption (CBC mode ) algorithm in ASIC , what
> would be the best way to do it ? i mean among these architectures
> which one do you choose and why :
>
> * Basic iterative architecture
> * Partial loop  unrolling
> * full loop unrolling
> * Partia outer-round pipelining
> * Full outerround pipelining
> * Inner-round pipelining
> * Partial mixed innerand outerroundpipelining
> * Full mixed inner- and outer-round pipelining
> * other ...

the first is the smallest and slowest. You choose it, when small area
is more important than throughput. I'm no AES-Expert, but full loop
unrolling means you need ~14 times the area and gain a bit less then
14 times throughput.

Ask your self what you need.

bye Thomas

Article: 134704
Subject: Re: Side-BUFG, BRAMS and clock routing
From: Paul Boven <p.boven@xs4all.nl>
Date: Wed, 27 Aug 2008 07:57:32 +0200
Links: << >>  << T >>  << A >>
Hi Brian, everyone,

Brian Drummond wrote:
> On Tue, 26 Aug 2008 23:38:00 +0200, Paul Boven <p.boven@xs4all.nl>
 >> [ clocking a dual-port BRAM from a left and right side bufg ]
>> As this kit comes with a PCB and everything already soldered in place I 
>> can't change these pin assignments. Are there any recommended ways to 
>> improve timing in such a situation?
> 
> Derive a third clock from one of these two, in a DCM, which can use
> globally routable resources?

Ah thanks - that's a very simple solution, and as I have plenty of clock 
resources left, should just work. As the vga_clk is only driving the VGA 
outputs there's no need for a fixed (or even known) phase offset between 
the crystal and the actual pixel clock, so that's the one I'll try to 
run through a DCM this evening.

Regards, Paul Boven.

Article: 134705
Subject: Saving PAR Constraints
From: knight <krsheshu@gmail.com>
Date: Tue, 26 Aug 2008 23:39:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

I am doing an iterative design flow and iam using Xilinx 9.2i ISE
I am a newbie in Floorplan and PAR.

I wanted to set some constraints in Floorplanner.
Every time i change a constraint in floorplanner, for example placing
a LUT,
and run PAR the whole placements of other blocks gets changed.

Is it possible to save the constraints generated after PAR..?
i want to first make other blocks static and place my block at
different locations and evaluate timing..


Please help me



hoping your reply

Article: 134706
Subject: FPGA/CPLD Design Group on LinkedIn
From: cpld-fpga-asic <cpld.fpga.asic@gmail.com>
Date: Wed, 27 Aug 2008 03:22:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
FPGA/CPLD Design Group on LinkedIn

Group for People Involved In the Design and Verification of FPGA's and
CPLD's to Exchange Idea's and Techniques. You should have FPGA/CPLD
Design/Verification on your Profile to Join. (The focus is more on
FPGA/CPLD in the product as opposed to FPGA's solely as a path to an
ASIC) 750+ Members

http://www.cpldfpga.com

(Tip - when first signing up on linkedin cut-paste from a resume)

Article: 134707
Subject: Re: need fast FPGA suggestions
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 27 Aug 2008 22:36:05 +1200
Links: << >>  << T >>  << A >>
John McCaskill wrote:
> The Virtex 4 family has input and output SERDES on their IOs. These
> are not the MGTs of the FX version, and are on all versions of the
> Virtex 4s. The SERDES can be used with the DDR registers in the IOB to
> get even faster performance from them.  The SERDES can also be used in
> pairs to get a larger parallel to serial ratio.
<snip>

SERDES are on more devices these days, and are the obvious and simple'
way to get extended timing.
If the price/package excludes those, you can use multiple phase clocks
to interpolate time : generate as many phases as the device/DLLs
can, and capture, then feed into a priority encoder to get a
Phase Location, and then on output, a similar converse PhaseSum is used
for fractional clock times. More logic, but lower clock speeds.

-jg


Article: 134708
Subject: Re: Saving PAR Constraints
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 27 Aug 2008 12:49:01 +0100
Links: << >>  << T >>  << A >>
On Tue, 26 Aug 2008 23:39:53 -0700 (PDT), knight <krsheshu@gmail.com>
wrote:

>I wanted to set some constraints in Floorplanner.
>Every time i change a constraint in floorplanner, for example placing
>a LUT,
>and run PAR the whole placements of other blocks gets changed.
>
>Is it possible to save the constraints generated after PAR..?
>i want to first make other blocks static and place my block at
>different locations and evaluate timing..

I think you want to select "re-entrant flow" in the PAR properties menu
(there will be a command line option for this if you are not using
Project Navigator)
Read how to use re-entrant flow in the PAR manual.

- Brian

Article: 134709
Subject: Genode FPGA graphics project launched
From: Matthias Alles <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de>
Date: Wed, 27 Aug 2008 14:10:59 +0200
Links: << >>  << T >>  << A >>

Genode FX is a composition of hardware and software that enables the
creation of fully fledged graphical user interfaces as system-on-chip
solutions using commodity FPGAs, e.g., Xilinx' low-cost Spartan3 series.
The integrated solution complements the Microblaze soft core with custom
hardware for interconnecting display and input devices. On the software
side, the heart of the project is a complete GUI software stack
especially tailored to resource-constrained embedded systems. In
addition to leveraging the Microblaze architecture, support for the PPC
core as featured in high-end Virtex5 FPGAs is on the way. This prospect
makes Genode FX a solution that scales with the demands of current and
future applications. The release features a complete demonstration
project ready to use with widely popular Spartan3A Starter Kit boards.

To learn more about Genode FX visit:
http://www.genode-labs.com/products/fpga-graphics

To download Genode FX sourcecode and demo project visit:
https://sourceforge.net/projects/genode-fx/

Matthias

Article: 134710
Subject: Virtex 5 bitstream encryption
From: bamboutcha9999@hotmail.com
Date: Wed, 27 Aug 2008 07:51:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello !
 I would like to know the frequency used by Xilinx (Virtex 5) to
decrypt bitstream before configuration .
 The decrypter is it slow with small area ? fast with big area ?
unfortunately it's not documented by xilinx .

Thank u for help

Article: 134711
Subject: Re: Virtex 5 bitstream encryption
From: Peter Alfke <alfke@sbcglobal.net>
Date: Wed, 27 Aug 2008 08:09:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 27, 7:51=A0am, bamboutcha9...@hotmail.com wrote:
> Hello !
> =A0I would like to know the frequency used by Xilinx (Virtex 5) to
> decrypt bitstream before configuration .
> =A0The decrypter is it slow with small area ? fast with big area ?
> unfortunately it's not documented by xilinx .
>
> Thank u for help

Do you mean ENcrypt when you wrote DEcrypt ?
Peter Alfke

Article: 134712
Subject: Re: Analog Imager interface to FPGA
From: wallge <wallge@gmail.com>
Date: Wed, 27 Aug 2008 08:20:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 26, 9:39=A0pm, Rob <buz...@leavemealone.com> wrote:
> Is the imager a CCD? =A0If so, there are plenty of mfg's out there that
> sell CCD/CIS AFE's: National, AKM, Epson, and TI. =A0And many of the
> devices offered have the capability of internally moving the sample
> edge. =A0The converted video is then sent out with a reference clock, so
> you are again sync'd up as the digital video comes into the FPGA. =A0A
> Cyclone3 will have no problem with these speeds. I've used a Cyclone3
> with a National AFE and Toshiba CCD running quite a bit faster than 15MHz=
.
>
> Finding a 14 bit ADC might be a bit tricky. =A0Most of the devices are
> using 10 bit converters; but there are a couple that offer 16 bit (keep
> your eye on the the noise of the converter--usually you'll find that the
> bottom few bits are better suited for random noise generators than real
> data)! =A0You can get away with 10 bits and a good system will use 12.
> One usually loses a couple of bits in the processing.
>
> If you want some part numbers I can pass them along, too.
>
> Rob
>
> wallge wrote:
> > I am working on a video project using an FPGA for all the signal
> > processing and output
> > video generation, as well as to control all the peripheral PHYs, and
> > the image sensor chip.
>
> > Now, one thing that concerns me is that there is a digital control
> > interface to the imager IC (to the control the read out of imager rows/
> > cols, as well as other integrated functions), yet the video output
> > from the imager is a single analog pin. The analog output is actually
> > synchronized to a clock that is sent to the imager IC from the FPGA.
> > Based on the timing diagram, the analog video should be sampled on the
> > falling edge of the clock that is sent to the imager IC.
>
> > Now in between the FPGA and the imager IC, I need a fast analog
> > amplifier (to get the analog video in the correct voltage range to be
> > sampled - this will depend on the input voltage accepted by the chosen
> > ADC) and an ADC IC (to sample the analog video).
> > I think both the ADC and the imager will run on the same clock (again,
> > generated by the FPGA from external Osc.). My concern is with
> > synchronizing the FPGA, the ADC, and the imager, so that the analog
> > pixel values are sampled at the right time on the ADC (since they are
> > sync'ed to the clock), and registered in at the right time by the FPGA
> > (in the eye of the sampled data).
> > I am worried that the PCB may introduce delays that will force me to
> > have to manually tune (possibly several) clock phase shift(s) sent to
> > the imager, the ADC, and the clock used in the FPGA to register in the
> > sampled data. =A0Each block will run at the same clock speed, but may
> > need different phase offsets in order to account for delays induced by
> > the PCB interconnect or delays through various ICs (phase delay
> > through gain ckt, phase delay through sampler, etc).
>
> > Does anyone have any thoughts on this? Perhaps there is a ref. design
> > or white paper that you might know of that discusses how to handle
> > capturing this kind of analog video output using an FPGA?
>
> > Further assumptions/details: (comments appreciated)
> > video clock: <=3D15MHz (based on frame rate required)
> > ADC sample rate: >=3D 15MSPS?
> > ADC sampler bits: 14 (set by system requirements, or should there be
> > more than this, due to sampler noise or other PCB induced noise?)
> > Analog Gain IC stop/pass band: (pass band should be uniformly flat and
> > extend from DC to well above 15MHz, so as not to attenuate any analog
> > pixel values?)

Rob, thanks for your input.
Unfortunately the imager I am working with is something
slightly more peculiar and uncommon than a standard CCD.
But perhaps the interface with the imager is similar enough
that I can use some of the recommendations in the data sheets
for the CCDs you mentioned.
Can you list a few of the parts you had in mind?

What is the difference between a standard analog to digital
converter (ADC), and an analog front end (AFE)?

Thanks for your help.




Article: 134713
Subject: Re: Virtex 5 bitstream encryption
From: bamboutcha9999@hotmail.com
Date: Wed, 27 Aug 2008 08:39:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 27 ao=FBt, 17:09, Peter Alfke <al...@sbcglobal.net> wrote:
> On Aug 27, 7:51=A0am, bamboutcha9...@hotmail.com wrote:
>
> > Hello !
> > =A0I would like to know the frequency used by Xilinx (Virtex 5) to
> > decrypt bitstream before configuration .
> > =A0The decrypter is it slow with small area ? fast with big area ?
> > unfortunately it's not documented by xilinx .
>
> > Thank u for help
>
> Do you mean ENcrypt when you wrote DEcrypt ?
> Peter Alfke

Peter ,
i mean "decrypt ", in fact encrypted bitstream is sent from Eprom to
Fpga to be decrypted then configured . i  want to know more about this
decrypter . which AES 256 decryption architecture is used by xilinx
( area , throughput , ...) .

Article: 134714
Subject: Re: Virtex 5 bitstream encryption
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 27 Aug 2008 09:29:38 -0700
Links: << >>  << T >>  << A >>
bamboutcha9999@hotmail.com wrote:
> Hello !
>  I would like to know the frequency used by Xilinx (Virtex 5) to
> decrypt bitstream before configuration .
>  The decrypter is it slow with small area ? fast with big area ?
> unfortunately it's not documented by xilinx .
> 
> Thank u for help

It decrypts at the same rate as the configuration clock.  This could be 
anywhere from KHz to the maximum of 100 MHz as specified in the data sheet.

Ed McGettigan
--
Xilinx Inc.

Article: 134715
Subject: Re: Genode FPGA graphics project launched
From: Jon Beniston <jon@beniston.com>
Date: Wed, 27 Aug 2008 13:12:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 27 Aug, 13:10, Matthias Alles <REMOVEallesCAPIT...@NOeit.SPAMuni-
kl.de> wrote:
> Genode FX is a composition of hardware and software that enables the
> creation of fully fledged graphical user interfaces as system-on-chip
> solutions using commodity FPGAs, e.g., Xilinx' low-cost Spartan3 series.
> The integrated solution complements the Microblaze soft core with custom
> hardware for interconnecting display and input devices. On the software
> side, the heart of the project is a complete GUI software stack
> especially tailored to resource-constrained embedded systems. In
> addition to leveraging the Microblaze architecture, support for the PPC
> core as featured in high-end Virtex5 FPGAs is on the way. This prospect
> makes Genode FX a solution that scales with the demands of current and
> future applications. The release features a complete demonstration
> project ready to use with widely popular Spartan3A Starter Kit boards.
>
> To learn more about Genode FX visit:http://www.genode-labs.com/products/fpga-graphics
>
> To download Genode FX sourcecode and demo project visit:https://sourceforge.net/projects/genode-fx/
>
> Matthias

Looks interesting. Would the LGPL license be more appropriate though?
For example, can you legally distribute a project based on the GPLed
Genode that also uses MicroBlaze/NIOS, as doing so would presumably
require you to provide the MicroBlaze source as well, which will
obviously be a problem.

Jon

Article: 134716
Subject: Re: need fast FPGA suggestions
From: Jon Elson <elson@wustl.edu>
Date: Wed, 27 Aug 2008 16:45:38 -0500
Links: << >>  << T >>  << A >>


Andrew FPGA wrote:
>>So, you think a 13-bit counter feeding a 13-bit identity comparator will
>>work at 250 MHz?
> 
> Others have said it may be possible but what they fail to acknowledge
> is the large amount of extra design effort and care required to get
> there. 250 MHz is really pushing the limits in spartan 3e in my
> experience. You may have to work very hard to get there: for example I
> have just finished a distributed arithmetic filter design, that has
> only 1 LUT level between flops and after a lot of effort I got it to
> run at 206 MHz in a sp3 1600e. I can see how to get to 220MHz, but
> beyond that I don't know. The longest carry chain is 10 bits.
> 
> I had to bypass synthesis and instantiate xilinx primitives directly
> to gaurantee my logic was implemented in 1 LUT level. Then I had to
> manually floorplan the design - placing each flop with the
> corresponding LUT by hand( I uses RLOC's embedded in the VHDL source).
> The automatic placer didn't always place the LUT with the FLOP so you
> end up with 2 routes which kills the timing completely.
Yes, with 64 instantiations of the circuit on the FPGA, I really DON'T 
want to deal with this!

> 
> 
>>Yeah, I really don't think we can handle $2000 IC's.  This isn't a real
>>production project, we might build 5 of them at a time, but we are still
>>cost-sensitive.
> 
> If its such low volumes just take the unit cost hit and move to a
> Virtex part. How valuable is your time?

Yes, I think you are right, and I greatly appreciate the data points 
about the 206 MHz and the 10-bit carry.  The circuit I need to implement 
is REALLY simple, but gets a bit more complicated when you add in the 
logic to handle the DDR.  The SERDES components in the Virtex look like 
they would be ideal to handle this, and instead of only having an X2 
option with DDR, this makes an X8 option nearly as simple.  The part 
cost, all by itself, is not that terrible, the smaller Virtex chips are 
around $200.  The other problem, however, is we have no capability or 
experience with BGAs, and would have to send them out.  That at least 
doubles the cost!

Thanks again for the info!

Jon


Article: 134717
Subject: Re: need fast FPGA suggestions
From: Jon Elson <elson@wustl.edu>
Date: Wed, 27 Aug 2008 16:53:34 -0500
Links: << >>  << T >>  << A >>


John McCaskill wrote:
> I was not clear if you needed a minimum delay of 10ns, a minimum pulse
> width or 10 ns, or both. If you need a minimum delay of 10 ns, you
> would need to run a smaller ratio to get your parallel clock fast
> enough.
> 
Yes, as soon as you mentioned the SERDES in a previous message, I 
realized this was the best scheme for Virtex 4.  I think trying to use 
Spartan 3E at insane clock rates would be risky, and might lead to a 
total collapse of the automatic tools when they try to route 64 
instances of this module per chip.  I don't want to have to do what 
Andrew ran into with manual placing x64 times.  No FUN!

> Take a look at the Virtex-4 users guide section on the ISERDES and
> OSERDES for more information about them:
> http://www.xilinx.com/support/documentation/user_guides/ug070.pdf
> 
> I also noted that you did not like that they came in BGAs.  We have
> used out side rework shops to place BGAs for us with good results. If
> I remember correctly, it cost under $100 USD each for just a few
> boards.  I recommend http://www.process-sciences.com/services/default.asp
The outfits I've seen so far seem to have a high setup charge, which makes
them roughly double the component price.  There likely are shops with 
better rates for small jobs.

Jon


Article: 134718
Subject: Re: need fast FPGA suggestions
From: Jon Elson <elson@wustl.edu>
Date: Wed, 27 Aug 2008 16:54:55 -0500
Links: << >>  << T >>  << A >>


John Larkin wrote:
> You might consider this trick: when a trigger comes in, start an
> oscillator, and use that to clock the FPGA. Then time out with
> counters, and use some fractional-clock trick if you need sub-clock
> delay or width resolution.
> 
> I've done this with LC oscillators and coaxial ceramic resonator
> oscillators; both can be started essentially instantly and can have
> pretty good jitter performance. The resulting FPGA logic can be pretty
> simple.
But, we have 32 independent inputs, with no time correlation.  Not
enough global clock trees to handle that.

Jon


Article: 134719
Subject: Re: need fast FPGA suggestions
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 27 Aug 2008 16:10:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 27, 2:45=A0pm, Jon Elson <el...@wustl.edu> wrote:
>
> Yes, I think you are right, and I greatly appreciate the data points
> about the 206 MHz and the 10-bit carry. =A0The circuit I need to implemen=
t
> is REALLY simple, but gets a bit more complicated when you add in the
> logic to handle the DDR. =A0The SERDES components in the Virtex look like
> they would be ideal to handle this, and instead of only having an X2
> option with DDR, this makes an X8 option nearly as simple. =A0The part
> cost, all by itself, is not that terrible, the smaller Virtex chips are
> around $200. =A0The other problem, however, is we have no capability or
> experience with BGAs, and would have to send them out. =A0That at least
> doubles the cost!
>
> Thanks again for the info!

1) The Virtex is a good way to go; the SERDES will work for you as
long as your minimum delays are met (same is true of shorter delay DDR
version).
2) I thought you had 32 channels
3) One instantiation is almost the same as 64 in complexity.  It's one
lone module that produces the results for each instance.
4) BGAs can give growing pains, but it's the industry's current sweet-
spot.  If not now, than a few more months down the road.

I'd personally be happy to crank out a design like this in the
Spartan3x series, but for a 5-up production the added speed and
functionality of the Virtex is a good win.

Article: 134720
Subject: Re: need fast FPGA suggestions
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 28 Aug 2008 11:52:41 +1200
Links: << >>  << T >>  << A >>
Jon Elson wrote:
> Yes, I think you are right, and I greatly appreciate the data points 
> about the 206 MHz and the 10-bit carry.  The circuit I need to implement 
> is REALLY simple, but gets a bit more complicated when you add in the 
> logic to handle the DDR.  The SERDES components in the Virtex look like 
> they would be ideal to handle this, and instead of only having an X2 
> option with DDR, this makes an X8 option nearly as simple.  The part 
> cost, all by itself, is not that terrible, the smaller Virtex chips are 
> around $200.  The other problem, however, is we have no capability or 
> experience with BGAs, and would have to send them out.  That at least 
> doubles the cost!

Lattice claim to have lowest cost SERDES - but I'm not sure anyone
does SERDES in non-BGA packages...

Could you target a low cost Eval Board - as a 'FPGA module' ?

-jg


From rgaddi@technologyhighland.com Wed Aug 27 17:03:39 2008
Path: flpi142.ffdc.sbc.com!flpi088.ffdc.sbc.com!prodigy.com!flpi089.ffdc.sbc.com!prodigy.net!bigfeed.bellsouth.net!news.bellsouth.net!dc3peer2.nntp.savvis.net!peer.nntp.savvis.net!cycny02.gnilink.net!cyclone1.gnilink.net!gnilink.net!nx02.iad01.newshosting.com!newshosting.com!216.196.98.140.MISMATCH!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.lmi.net!news.lmi.net.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 27 Aug 2008 19:03:00 -0500
Date: Wed, 27 Aug 2008 17:03:39 -0700
From: Rob Gaddi <rgaddi@technologyhighland.com>
Newsgroups: comp.arch.fpga
Subject: Re: need fast FPGA suggestions
Message-Id: <20080827170339.376d344a.rgaddi@technologyhighland.com>
References: <48B30324.2000603@wustl.edu>
	<e9399c93-012c-4e7c-8783-c724eba7fe99@k36g2000pri.googlegroups.com>
	<48B3242D.2020705@wustl.edu>
	<25394580-24fc-40b2-ad91-3bd7a31ae9e4@l33g2000pri.googlegroups.com>
	<48B5CB02.6000800@wustl.edu>
	<8af61e2d-3182-4cc6-bb2f-7fffd8f8bece@s20g2000prd.googlegroups.com>
Organization: Highland Technology, Inc.
X-Newsreader: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 43
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 66.117.134.49
X-Trace: sv3-XtWmeA81sLLdLrPViwbOuh3ebakTzptsBxpvHP/k8cbgHFpaAupa+U5XIkuH6xMbICnASC4vKgFo0LI!KmVZQiI0OgY8f7NhK6ssXgAB2DaIuDV7Su+mi41ZM9s2L5JjMZMy2TMyowtxPhrIfdi20fi1P+lh!Cw3YaWTAbc5Sk9BJFnQ=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.39
Bytes: 3395
Xref: prodigy.net comp.arch.fpga:147522
X-Received-Date: Wed, 27 Aug 2008 20:03:00 EDT (flpi142.ffdc.sbc.com)

Regarding the long counters at 250 MHz:  I've only worked with Spartan 3s, =
not the Virtexes, but I was under the impression that the DSP48 blocks tend=
 to be built for this sort of thing.  Granted, using a full MAC block as a =
counter (possibly a down counter) seems to be overkill, but I can't see whe=
re you'd need them for anything else.

--=20
Rob Gaddi, Highland Technology
Email address is currently out of order

On Wed, 27 Aug 2008 16:10:21 -0700 (PDT)
John_H <newsgroup@johnhandwork.com> wrote:

> On Aug 27, 2:45=A0pm, Jon Elson <el...@wustl.edu> wrote:
> >
> > Yes, I think you are right, and I greatly appreciate the data points
> > about the 206 MHz and the 10-bit carry. =A0The circuit I need to implem=
ent
> > is REALLY simple, but gets a bit more complicated when you add in the
> > logic to handle the DDR. =A0The SERDES components in the Virtex look li=
ke
> > they would be ideal to handle this, and instead of only having an X2
> > option with DDR, this makes an X8 option nearly as simple. =A0The part
> > cost, all by itself, is not that terrible, the smaller Virtex chips are
> > around $200. =A0The other problem, however, is we have no capability or
> > experience with BGAs, and would have to send them out. =A0That at least
> > doubles the cost!
> >
> > Thanks again for the info!
>=20
> 1) The Virtex is a good way to go; the SERDES will work for you as
> long as your minimum delays are met (same is true of shorter delay DDR
> version).
> 2) I thought you had 32 channels
> 3) One instantiation is almost the same as 64 in complexity.  It's one
> lone module that produces the results for each instance.
> 4) BGAs can give growing pains, but it's the industry's current sweet-
> spot.  If not now, than a few more months down the road.
>=20
> I'd personally be happy to crank out a design like this in the
> Spartan3x series, but for a 5-up production the added speed and
> functionality of the Virtex is a good win.


Article: 134721
Subject: Re: need fast FPGA suggestions
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 27 Aug 2008 17:06:34 -0700
Links: << >>  << T >>  << A >>
On Wed, 27 Aug 2008 16:54:55 -0500, Jon Elson <elson@wustl.edu> wrote:

>
>
>John Larkin wrote:
>> You might consider this trick: when a trigger comes in, start an
>> oscillator, and use that to clock the FPGA. Then time out with
>> counters, and use some fractional-clock trick if you need sub-clock
>> delay or width resolution.
>> 
>> I've done this with LC oscillators and coaxial ceramic resonator
>> oscillators; both can be started essentially instantly and can have
>> pretty good jitter performance. The resulting FPGA logic can be pretty
>> simple.
>But, we have 32 independent inputs, with no time correlation.  Not
>enough global clock trees to handle that.
>
>Jon

Oh, 32 separate triggers. Stick with analog ramps?

Some of the LVDS line receivers make might fine fast and cheap
comparators, duals even. So could probably do it all in cmos these
days, fairly simple stuff.

Trigger fires flipflop, turns ramp loose; ramp drives two comparators,
which drive a logic gate to make rising/falling output edges. 2nd
comparator clears flipflop. 64 DAC channels program the mess, not bad
if you use serial octal dacs. Figure 2 square inches per channel to be
generous, so it's an 8x8" board.



John





Article: 134722
Subject: Re: need fast FPGA suggestions
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 28 Aug 2008 13:06:02 +1200
Links: << >>  << T >>  << A >>
John Larkin wrote:

> Oh, 32 separate triggers. Stick with analog ramps?
> 
> Some of the LVDS line receivers make might fine fast and cheap
> comparators, duals even. So could probably do it all in cmos these
> days, fairly simple stuff.
> 
> Trigger fires flipflop, turns ramp loose; ramp drives two comparators,
> which drive a logic gate to make rising/falling output edges. 2nd
> comparator clears flipflop. 64 DAC channels program the mess, not bad
> if you use serial octal dacs. Figure 2 square inches per channel to be
> generous, so it's an 8x8" board.

Analog is a candidate, but the OP mentioned a 100:1 dynamic range.
Maybe some range-sw caps ?

Anyone seen Vos vs Common Mode voltage plots for LVDS channels
in FPGAs ? Cross talk figures ?

-jg


Article: 134723
Subject: Re: need fast FPGA suggestions
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 27 Aug 2008 19:03:42 -0700
Links: << >>  << T >>  << A >>
On Thu, 28 Aug 2008 13:06:02 +1200, Jim Granville
<no.spam@designtools.maps.co.nz> wrote:

>John Larkin wrote:
>
>> Oh, 32 separate triggers. Stick with analog ramps?
>> 
>> Some of the LVDS line receivers make might fine fast and cheap
>> comparators, duals even. So could probably do it all in cmos these
>> days, fairly simple stuff.
>> 
>> Trigger fires flipflop, turns ramp loose; ramp drives two comparators,
>> which drive a logic gate to make rising/falling output edges. 2nd
>> comparator clears flipflop. 64 DAC channels program the mess, not bad
>> if you use serial octal dacs. Figure 2 square inches per channel to be
>> generous, so it's an 8x8" board.
>
>Analog is a candidate, but the OP mentioned a 100:1 dynamic range.
>Maybe some range-sw caps ?
>
>Anyone seen Vos vs Common Mode voltage plots for LVDS channels
>in FPGAs ? Cross talk figures ?
>
>-jg

We did some experiments on Spartan 3's, running Vccio at 3.3 to 3.5
volts. It sure looked like the LVDS inputs were good
almost-rail-to-rail comparators. I was impressed.

We didn't measure Vos, as we were just interested in using them as the
comparators in analog ramp circuits, to generate sub-ns tunable
delays, and we assumed we'd calibrate out any offsets. Linear analog
ramp goes onto one side of an lvds input, dac driving the other side.

We did find that they have a lot of jitter when the compare happens
anywhere near the edge of any of the on-chip clocks. With a bunch of,
say, 25 ns ramps coming in, you might expect pretty good jitter, 40 ps
RMS maybe, but with delay zones that peak in the 100 ps range as a
result of crosstalk from clocks or adjacent channels. Not too bad, but
it wasn't good enough for our applications.

John



Article: 134724
Subject: Re: Analog Imager interface to FPGA
From: Rob <buzoff@leavemealone.com>
Date: Wed, 27 Aug 2008 23:18:41 -0400
Links: << >>  << T >>  << A >>
Here are some of the parts I have used or looked at:

National: LM98714
TI: VSP5000
AKM: AK8433
EPSON: S1R77022

An AFE has many more functions baked into like dark loop control, timing 
generators, and CDS.  They are basically one chip wonders that let you 
control and convert analog CCD/CIS sensors.

Take care,
Rob

wallge wrote:
> On Aug 26, 9:39 pm, Rob <buz...@leavemealone.com> wrote:
>> Is the imager a CCD?  If so, there are plenty of mfg's out there that
>> sell CCD/CIS AFE's: National, AKM, Epson, and TI.  And many of the
>> devices offered have the capability of internally moving the sample
>> edge.  The converted video is then sent out with a reference clock, so
>> you are again sync'd up as the digital video comes into the FPGA.  A
>> Cyclone3 will have no problem with these speeds. I've used a Cyclone3
>> with a National AFE and Toshiba CCD running quite a bit faster than 15MHz.
>>
>> Finding a 14 bit ADC might be a bit tricky.  Most of the devices are
>> using 10 bit converters; but there are a couple that offer 16 bit (keep
>> your eye on the the noise of the converter--usually you'll find that the
>> bottom few bits are better suited for random noise generators than real
>> data)!  You can get away with 10 bits and a good system will use 12.
>> One usually loses a couple of bits in the processing.
>>
>> If you want some part numbers I can pass them along, too.
>>
>> Rob
>>
>> wallge wrote:
>>> I am working on a video project using an FPGA for all the signal
>>> processing and output
>>> video generation, as well as to control all the peripheral PHYs, and
>>> the image sensor chip.
>>> Now, one thing that concerns me is that there is a digital control
>>> interface to the imager IC (to the control the read out of imager rows/
>>> cols, as well as other integrated functions), yet the video output
>>> from the imager is a single analog pin. The analog output is actually
>>> synchronized to a clock that is sent to the imager IC from the FPGA.
>>> Based on the timing diagram, the analog video should be sampled on the
>>> falling edge of the clock that is sent to the imager IC.
>>> Now in between the FPGA and the imager IC, I need a fast analog
>>> amplifier (to get the analog video in the correct voltage range to be
>>> sampled - this will depend on the input voltage accepted by the chosen
>>> ADC) and an ADC IC (to sample the analog video).
>>> I think both the ADC and the imager will run on the same clock (again,
>>> generated by the FPGA from external Osc.). My concern is with
>>> synchronizing the FPGA, the ADC, and the imager, so that the analog
>>> pixel values are sampled at the right time on the ADC (since they are
>>> sync'ed to the clock), and registered in at the right time by the FPGA
>>> (in the eye of the sampled data).
>>> I am worried that the PCB may introduce delays that will force me to
>>> have to manually tune (possibly several) clock phase shift(s) sent to
>>> the imager, the ADC, and the clock used in the FPGA to register in the
>>> sampled data.  Each block will run at the same clock speed, but may
>>> need different phase offsets in order to account for delays induced by
>>> the PCB interconnect or delays through various ICs (phase delay
>>> through gain ckt, phase delay through sampler, etc).
>>> Does anyone have any thoughts on this? Perhaps there is a ref. design
>>> or white paper that you might know of that discusses how to handle
>>> capturing this kind of analog video output using an FPGA?
>>> Further assumptions/details: (comments appreciated)
>>> video clock: <=15MHz (based on frame rate required)
>>> ADC sample rate: >= 15MSPS?
>>> ADC sampler bits: 14 (set by system requirements, or should there be
>>> more than this, due to sampler noise or other PCB induced noise?)
>>> Analog Gain IC stop/pass band: (pass band should be uniformly flat and
>>> extend from DC to well above 15MHz, so as not to attenuate any analog
>>> pixel values?)
> 
> Rob, thanks for your input.
> Unfortunately the imager I am working with is something
> slightly more peculiar and uncommon than a standard CCD.
> But perhaps the interface with the imager is similar enough
> that I can use some of the recommendations in the data sheets
> for the CCDs you mentioned.
> Can you list a few of the parts you had in mind?
> 
> What is the difference between a standard analog to digital
> converter (ADC), and an analog front end (AFE)?
> 
> Thanks for 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