Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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. JohnArticle: 134702
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_HArticle: 134703
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 ThomasArticle: 134704
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
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 replyArticle: 134706
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
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. -jgArticle: 134708
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. - BrianArticle: 134709
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/ MatthiasArticle: 134710
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 helpArticle: 134711
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 AlfkeArticle: 134712
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
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
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
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. JonArticle: 134716
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! JonArticle: 134717
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. JonArticle: 134718
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. JonArticle: 134719
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
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
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. JohnArticle: 134722
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 ? -jgArticle: 134723
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. JohnArticle: 134724
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:
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