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
James Morrison wrote:
>
> Does anyone have any good numbers for the power consumption
> used by the DCI circuitry on the I/O's? The data sheet says,
> and I quote, "more power". I kid you not--look it up.
>
I've posted a few links below to old posts on this subject for
both V2 and S3.
It's particularly bad for the parallel input terminators, which
have a +/-20% accuracy for the 2R pullup/pulldowns.
In V2, I measured static DCI power at about 200 mW per bank
and 100 mW per LVDS_25_DCI pair (2.5V, 50 ohm VRP/N), much
greater than the 25 mW and 62.5 mW numbers from Xilinx.
Back in early 2003, I opened webcases and filed CR's for the
various tool and documentation problems relating to the greatly
under-reported static DCI power in V2.
After a three month webcase, and countless phone calls and emails,
the best Xilinx could do was give me an estimate, because they had
never properly characterized DCI power after implementing the
FreezeDCI bitgen patch.
After six months, the documentation and tools still were wrong, so
I posted a summary of the various V2 DCI problems here in Fall 2003.
If you look today, 2.5 years post-Webcase:
Answer Record #11661 :
ignores +/- 20% parallel terminator error, skips LVDS_25_DCI
Answer Record #15633 :
still says 62.5 mW per LVDS_25_DCI pair
Answer Record #11794 :
ignores stall-internal-resistor-at-R/2 case for VRP/VRN overhead
WebPower now includes LVDS_25_DCI for V2 and S3, but still
under-reports power.
old DCI power posts:
http://groups-beta.google.com/group/comp.arch.fpga/msg/5daa6eea44f16213?hl=en
http://groups-beta.google.com/group/comp.arch.fpga/msg/4a7fa8984b3395db?hl=en
http://groups-beta.google.com/group/comp.arch.fpga/msg/ea29413b0b200f5c?hl=en
Brian
Article: 85876Unbeliever wrote: > "Jon Beniston" <jon@beniston.com> wrote in message > news:1119008115.592497.325850@g14g2000cwa.googlegroups.com... > > comp.arch.fpga.cpu might be a good idea. Somewhere for all the NIOS & > > MicroBlaze queries. > > > > Cheers, > > Jon > > > > Which newsgroup would I post my question relating to my implementation of a > 6805 core in an fpga? The .cpu group or the parent group or both. At an > average of 10 topics per day, I'd prefer to keep it in one place, like Mike. > > Cheers, > Alf I agree. ~50 posts a day is not ~50 threads a day. I use the google groups site to access the newsgroup and almost never need to click the "older topics" to find a thread that's still active. I enjoy seeing threads related to vendors of fpga's I'm not currently using. I also enjoy seeing topics not related to my current work. I would miss most of this if I had to browse through multiple groups to find them. Just my 2 cents. GaborArticle: 85877
Hello, We use different Xilinx FPGAs (Spartan3, Virtex2, etc.). When downloading the code, everything works fine except the fact that the DONE pine is going high before the last data is written (tested on XC2V250fg456 or XC3S50vc100: DONE goes high after writing the N-13th byte). If we check the ODNE pin after loading ALL bytes, everyhing is still fine, but we would like to check the INIT pin during the configuration process in order to determine CRC errors. Has anyone experince with this, thus is it possible to determine when the DONE pins must go high and is it possible to define a point at the end of the configuration process where the INIT pin can be checked for CRC errors? thanks for any comments.... GuenterArticle: 85878
Anton Erasmus wrote: > <jon_harrisTIGER@hotmail.com> wrote: > >> Are you taking pictures of stationary things from a stationary >> camera? That's what the astronomy case involves. But since you >> are concerned with a moving camera, I assumed you were talking >> about pictures taken with a hand-held camera. In that case, the >> reason the shake creates blur is that the exposure is too long. >> And the reason for the long exposure is lack of light (due to >> lens limitations, ambient light conditions, or both). If you >> were to shorted the exposure, you would end up with a picture >> that is too dark. > > [Stuff snipped] > > I have read a bit about the astronomical image processing mention > in one of the other posts. One thing that came up quite often, is > that CCD sensors are linear. i.e. double the exposure time gives > double the energy recieved. (They do not mention CMOS, but it is > probably the same.) > > I agree that blurring occurs when taking a single photo when the > camaera is moved and the exposure is to long. If one can say take > in stead of 1x 2sec exposure, take 20x 0.1 sec exposures, and > stack them into a single picture in software, one should end up > close to the exposure level of the 2sec picture, but without the > blur. In the astronomical case, the "short" exposure pictures are > in minutes for a total exposure time of hours. Of course the > subject must not move during the "short" exposure time. > > If one scaled this down so that the "short" exposure time is in > milli-seconds or even micro-seconds depending on what the sensors > can do, then one can do the same thing just at a much faster > scale. What is the minimum exposure time for a current CMOS sensor > before one just see the inherant sensor noise ? I think, at any particular time, you have an accumulated picture and a picture increment to combine. Around any particular point you have a matrix of adjacent points, described by the indices -1, 0, +1 in each direction. To do the combination, and arrive at a new accumulated picture, you 'just' have to form the 9 value matrix and combine all points accordingly. Now you can get a new picture increment, and recompute the matrix. You combine the old into the new, so you never have to worry about more than one increment of motion. Forming the matrix will depend on a herd of heuristics, such as 'where is the CG of the input points', 'where is the minimum', 'where is the maximum'. This is pure speculation on my part. I have no knowledge of real world algorithms here. It's how I would go about it. I might want a buffer for picture increment, so that the combining can take place in parallel with the input of the next increment. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!Article: 85879
Hal Murray wrote: > > I'm starting to learn FPGA programming (using a Xilinx Spartan II > >200K). I will use VHDL and already have bought VHDL books, but I think > >I also need a general introduction to FPGA so I plan to buy a book on > >FPGA. I found this one: > > Have you checked the data sheet? For Xilinx parts like Spartan2 there are both datasheets and user guides. They are not on the same web page so you need to look for the user guide. The user guide has lots of detailed information that isn't always easy to grok in the datasheet. Also on the Xilinx site are tons of app notes and a plethora (if plethora is the word I want to use) of tech tips. > > It's got all the info you need. You will probably have to read it > at least 6 times - more will make sense each pass. > > You can learn a lot of details and what's behind them if you > follow this newsgroup. Look through some older threads on board products and you'll find links to interesting sites like: http://www.fpga4fun.com/ Good Luck, GaborArticle: 85880
Ian wrote: > Hi Everyone, > > I would be really for any help or advice you can offer me on the > following. > > I have created a simple tri-state bus as a macro using xdl. The design > consists of two TBUFs driving a single long line. > > (Diagram at http://www.comms.scitech.susx.ac.uk/~ian/files/tbuf.gif) > > <img src="http://www.comms.scitech.susx.ac.uk/~ian/files/tbuf.gif"> > > I attach external macro pins to Out, Enable and In of each TBUF. > However, when I try to include the macro in a design, the DRC in the > map phase complains that the Out pin is being driven by two sources. > MAP Error Message: > > > ERROR:MapLib:22 - Bus M0_DATA_LEFT_O_OBUF driven by bm_instance and > bm_instance has multiple active drivers. > > > This is not correct, as the O pins are external macro outputs! Is there > anyway to prevent this? > > Xilinx don't list any help for this Error. > > /Ian. What device are you targetting? Newer FPGA's don't have TBUF's anymore. CPLD's never did...Article: 85881
Hi Michael,
> I'm trying to build a new core that will use a IPIF PLB interface to
> connect to the PLB. Most of my logic is ready to roll and tested
> independantly, but when I came to add the IPIF interface I fell over at
> the first hurdle :(
Since you're talking about PLBs and things, I'm guessing that you must be
using the EDK somewhere along the line. The best place to look for
information about what you're trying to do is in the Embedded System Tools
Reference Manual, in the chapter entitled "Create and Import Peripheral
Wizard".
The "Wizard" in question is (fortunately) not one of those
two-clever-by-half wizards, but more of a does-the-scut-work-for-you sort of
guy. You run it once ("create") and answer some questions, and it spits out
a VHDL (or Verilog) skeleton, to which you can attach your custom code.
Then, you run it again ("import") and it picks up your design and rolls it
up into an EDK "pcore" which you can then instantiate in your EDK design.
I'm sure it's possible to achieve all the above manually without the wizard,
but I haven't seen any documentation describing that. Give us a shout if you
need any more pointers.
Cheers,
-Ben-
Article: 85882Have you got the "DRIVE DONE PIN HIGH" option selected for one of your designs in the Generate Programming File stage of ISE? John Adair Enterpoint Ltd. - Home of MINI-CAN. PCI and CAN Development Board. http://www.enterpoint.co.uk "gw" <guenter.wolpert@orsys.de> wrote in message news:1119011442.346145.82770@o13g2000cwo.googlegroups.com... > Hello, > > We use different Xilinx FPGAs (Spartan3, Virtex2, etc.). > When downloading the code, everything works fine except the > fact that the DONE pine is going high before the last data is > written (tested on XC2V250fg456 or XC3S50vc100: DONE goes high > after writing the N-13th byte). > If we check the ODNE pin after loading ALL bytes, everyhing is > still fine, but we would like to check the INIT pin during the > configuration process in order to determine CRC errors. > Has anyone experince with this, thus is it possible to determine > when the DONE pins must go high and is it possible to define > a point at the end of the configuration process where the INIT > pin can be checked for CRC errors? > > thanks for any comments.... > Guenter >Article: 85883
Antti Lukats wrote:
> ROTFL
> ROTFL
>
> this time really
>
> TOP 5 listed !!
>
> "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag
> news:42b292ea$1@clear.net.nz...
>
<snip>
>>
>> Looking at
>>
>
> http://www.altera.com/corporate/news_room/releases/products/nr-ultimate-products.html
>
>>The headline claims :
>>" Altera's HardCopy II Structured ASICs and MAX II CPLDs Named Ultimate
>>Products by eeProductCenter "
>>
>>Hmmm, not my choice for Ultimate Products, but let's read on....
>>
>>"Both AlteraŽ products were ranked in the top five in the logic and
>>programmable logic category."
>>
>>So "Ultimate" [1.Furthest or highest in degree or order; utmost or
>>extreme; 2.Being the last or concluding element of a series]
>>has suddenly spin-morphed to actually meaning - "Hey, we made the top
>
> FIVE!"
>
>>Now let's see, top five in the logic and programmable logic category ??
>>
>>So that could be, as an example that fits that claim :
>>1. Atmel
>>2. Actel
>>3. Lattice
>>4. Xilinx
>>5. Altera
>
>
> BIG ROTFL !!!
>
>
>>If it was any better, surely they would have said the top three, or top
>>two ?
>>
The "Ultimate" report is at
http://www.eeproductcenter.com/ultimate/default.html .
And (of no surprise to anyone who thought about it) the reason Altera
said "top five" is that it includes *both* the Hardcopy and Max II. The
rankings are:
1. Orange tree (C to VHDL tool)
2. Lattice (downloadable synthesis software)
3. Altera (Hardcopy II)
4. Cypress (PSOC 8-bit micro with configurable blocks)
5. Altera (Max II)
6. Actel (fpga starter kit)
7. Fairchild (tiny logic chips)
8. Celoxica (tools for image and video processing)
9. Exar (PCI bus UART)
10. Philips (tiny logic chips)
Of course, such a ranking is purely subjective and most people are going
to disagree about it - especially the word "ultimate". But I don't
think Altera marketing was doing anything unreasonable here.
>>And further on, we see
>>...described MAX II CPLDs as "as the industry's lowest-cost CPLD
>>available now," and "ideal for volume-driven, price-sensitive
>
> applications."
>
>>Reality check time - quick look at their own web site
>>
>
> http://www.buyaltera.com/scripts/partsearch.dll/showfilter?lookup=1,30,3074
>
>>shows the Cheapest MAX II is listed at $6.00 - lowest cost ? - hmm,
>>there are over 43 other CPLDs from Altera that clearly have
>>lower prices {and many over at Xilinx too... ) !?.
>>
>>So what can "lowest cost CPLD" actually mean ?
>>
>>-jg
>>
>
My guess is "lowest cost CPLD" means "lowest cost per macrocell". I
haven't checked the prices (except to note that the smallest MaxII is
both too big and too expensive to replace a Max3000 we are using), but
it is standard (though misleading) practice to talk about "lower cost"
when you mean "better value for money".
>
> all marketing BS
>
> MAX2 is nice non volatile version of Xilinx XC2K
>
> nothing in common what is considered CPLD (as Complex PLD)
>
> its really nice, but it doesnt at all compete in the low range PLD market
>
> the low range is 1USD and sub 1USD devices available from many vendors
>
> Antti
>
>
Article: 85884At least there is an external pull-up on the DONE pin. Anyway, even if the DONE pin is an open collector only, it shouldn't stop pulling low before the end of the data? The only thing with the open collector option is that DONE may come a little bit later than expected. One additional thing we observed is that the FPGA started to drive its outputs one clock before the DONE appeared. Therefore it seems that the configuration process is already over before all data is written to the FPGA. GuenterArticle: 85885
Dear Gabor, Thank you very much for your response. Actually, what you've said was the first thing i have asked before agreeing to accept this kind of project. But this never was met with enthusiasm... Managers stuff... I am going to try manual instantiation of ~300 I/O buffers... Good luck to me. Vladislav "Gabor" <gabor@alacron.com> wrote in message news:1118956538.511166.57090@g44g2000cwa.googlegroups.com... > > > Vladislav Muravin wrote: >> Hi ppl, >> >> I previously asked something similar. The thing is that I am integrating >> a >> design of somebody >> who's been using schematic design capture and his design is delivered in >> a >> generated VHDL code (or NGC as well). >> >> Now, the delivered design has already IBUFs / OBUFs inside, whereas my >> high-level code (the top module) does not. >> Consequently, I cannot do AND between two dsesigns, one with and one >> without >> IBUFs / OBUFs. >> If I turn on "Add I/O Buffers" option, I get an error, as the buffers are >> trying to be driven by another buffers inferred by the tool. >> If I turn off "Add I/O Buffers" option, all the logic is removed form >> design, as LOC constraints on the pins cannot be applied, >> because no buffers are inferred. >> >> As far as I understand the situation I have two choices: >> (*) I design this core by myself. >> (*) I manually add IBUFs / OBUFs in the top module and try synthesizing >> with >> "Add I/O Buffers" option turned off. >> >> Is there a way to enable / disable the option "Add I/O Buffers" in Xilinx >> per module / block? > > No. The Add I/O buffers only really affects the top level module > anyway. > If you need more control, turn it off and instantiate all your I/O > buffers (IBUF, IBUFG, OBUF, ughh...). > >> Is there a way to overcome this problem? >> > > Yes. > When you want to use another design as a black box, it should be built > without IO buffers. Only the top level design should have IO buffers. > Therefore you need two projects, one to build the black box (in your > case a schematic project) with add I/O buffers turned off. You don't > need to translate / map / place / route this project, just "synthesize" > (yes there's HDL under the hood of ECS schematics) to create the > ngc file. > > The second is your top level project (HDL in your case) with Add I/O > Buffers turned on. In this project you create an empty HDL module with > the i/o list from the schematic. If the schematic module connects to > pins, you'll need to add the connections from this module to the pins > in your HDL top-level code. > > Then just move the ngc file from the schematic project to the synthesis > directory (project directory) of the HDL project. Make sure the base > filename is the same as the module name in your HDL. XST will not try > to synthesize your empty HDL module, but will insert the compiled ngc > into the top level design. > >> Thank you all for your time and attention >> >> Sincerely, >> Vladislav >Article: 85886
The point is that DONE is not always an open drain drive. Have a look at this Xilinx answer http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=5865 and you might get a clearer understanding. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "gw" <guenter.wolpert@orsys.de> wrote in message news:1119014517.226639.8750@g47g2000cwa.googlegroups.com... > At least there is an external pull-up on the DONE pin. > Anyway, even if the DONE pin is an open collector only, > it shouldn't stop pulling low before the end of the data? > > The only thing with the open collector option is that DONE > may come a little bit later than expected. > > One additional thing we observed is that the FPGA started to > drive its outputs one clock before the DONE appeared. Therefore > it seems that the configuration process is already over before all > data is written to the FPGA. > > Guenter >Article: 85887
The text ALWAYS clearly states what the pricing timeframe and quantity are for the price. Engineers looking to design in a new part in large quantities are typically looking for production a little ways out. I would prefer to see 1H2006 pricing, but still... they make it clear. The pricing method is used by too many vendors so why should Xilinx say this snazzy new part is available for $XX now in small quantities when others are advertizing the "mature volume" pricing? If you know what the "typical markup" is for early adoption of a device or for small quantities of the part as purchased by your company, you can get a ballpark to the pricing without having to call for specifics. I'm surprised that the UWG makes illegal the practice of giving a price where the price is clearly marked with a note and that note supplies the timeframe and quantitiy. This is misleading why? We do have market realities to consider, after all. Kolja Sulimma wrote: > Xilinx is doing it again. > > http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=s3e_overview > "Spartan-3E FPGA devices with 100K system gates are available for under > US$2.00*" > Later in the text we learn that the pricing is for 2H2006. The current > price is higher. > > There are three correct formulations possible for these facts: > - The devices will be be available for under US$2. > - The devices are not available for under US$2. > - The devices are available for <insert real price> > > The formulation chosen by Xilinx marketing definetly is illegal in > Germany under UWG. (Last time these text were distributed in Germany by > distributors). And it probably is illegal in the US. > > I do not understand why a big company with a good product again and > againg ressorts to unfair and illegal marketing that is designed to > confuse customers? > This really is bad style. > > Kolja Sulimma > (Otherwise a happy Xilinx user)Article: 85888
On Fri, 17 Jun 2005 11:04:01 +0100, "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: >We have a product coming to assist in this area. Based on Spartan-3 in FG456 >it consists of a PGA style board with the Spartan-3 in the middle. This >module is aimed at hobby or small run board builders that don't want the >setup charges of BGA lines. Sounds like a really good idea - having started playing with the S3 devkit I keep having ideas of other fun, low-volume or 1-off things that I could use an FPGA for if it were more easily connect-to-able. Do you have a rough spec yet ? Number of pins, size, price etc. ? You may have already thought of some/all of these, but a few suggestions... Would be nice if the pinout is arranged such that you can easily trade off required number of layers needed on the host PCB against pins used, e.g useable on a 2-layer PCB if you don't need a lot of IO pins. Having a power connector on the board would be useful, to reduce the amount of big tracks you'd need (and allow a 2-layer host PCB for less demanding applications). Perhaps have JTAG and power connection pins along an edge with some perforations, so that can be snapped off if you want minimum module size, or left on to make it easier to use with simpler host boards. 1.5 and 2.5V regulators on board ? Any chance the footprint can be the same as one of the various PC CPUs, so sockets can be found cheaply ? Probably don't need seperately accessible connections to all of the IO bank supplies, but at least one seperately connectable bank would be nice for when you want a few 'odd' standards that need a different supply, e.g. lvds. Maybe have some solder-bridge type link options for this? Footprint for a user-fittable SMD oscillator module or two so high-speed clocks can stay on the module.Article: 85889
I would prefer to keep the group together. If one of the "little guys" comes up with a very marketable device, the buzz here will tend to get people interested. Knowing some of the issues in other devices helps to shape expectations when switching to that vendor's part. I *do* like the idea of moving the CPU stuff. There has been a huge amount of processor related traffic which doesn't really relate to the hardware but to the "core" used. I don't use any processors in my FPGA designs yet so the threads just clutter my FPGA experience here. I read comp.lang.verilog but don't bother with comp.lang.vhdl and subscribe to both. There's no reason someone designing with CPUs couldn't do both. Also, cross posting when a topic covers FPGA hardware AND the CPU is reasonable. I like to see the occasional posts here on DSP implementation when they refer to hardware yet wouldn't enjoy a diatribe on how to adapt coefficients. Hardware related DSP can be cross posted for those as well. I'd hate to see the vendor schism. Adam Megacz wrote: > I see a lot of posts here that are specific to a single vendor's > devices or that device-vendor's tools. I think it would make things a > bit more organized if we had a few subgroups beneath comp.arch.fpga > for the specific vendors (just like comp.os), and kept comp.arch.fpga > itself for vendor-agnostic (or vendor-comparative) discussions. > Traffic has been pretty high lately (~50 posts/day). <snip>Article: 85890
John_H wrote: > The text ALWAYS clearly states what the pricing timeframe and quantity > are for the price. > > Engineers looking to design in a new part in large quantities are > typically looking for production a little ways out. I would prefer to > see 1H2006 pricing, but still... they make it clear. > > The pricing method is used by too many vendors so why should Xilinx say > this snazzy new part is available for $XX now in small quantities when > others are advertizing the "mature volume" pricing? > > If you know what the "typical markup" is for early adoption of a device > or for small quantities of the part as purchased by your company, you > can get a ballpark to the pricing without having to call for specifics. > > I'm surprised that the UWG makes illegal the practice of giving a price > where the price is clearly marked with a note and that note supplies the > timeframe and quantitiy. This is misleading why? We do have market > realities to consider, after all. > It is clearly misleading to say " *are* available" for a particular price, when they are most definitely not available. Giving a 500k price for a year in the future is stretching "mature volume pricing" quite a bit, although it would not be unreasonable if the date and quantity were quoted in the text, rather than as a small-print footnote. I don't think anyone would consider the Altera Cyclone II press release to be misleading or illegal: <quote from Altera press release> Pricing and Availability The first member of the Cyclone II device family, the EP2C35 device, will be available in February 2005. Volume pricing for the EP2C35 will be $22 in 250,000 unit volumes. The web edition of Quartus II version 4.1 software supports the entire Cyclone II family and can be downloaded for free on www.altera.com/q2webedition. </quote> Now do you see the difference? I'm not claiming Altera's marketing people are perfect, and they are as happy as anyone else to omit useful information (there were no prices given in the Stratix II 180 press release!), but they are clear on what their price information actually is. mvh., David > > Kolja Sulimma wrote: > >> Xilinx is doing it again. >> >> http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=s3e_overview >> "Spartan-3E FPGA devices with 100K system gates are available for under >> US$2.00*" >> Later in the text we learn that the pricing is for 2H2006. The current >> price is higher. >> >> There are three correct formulations possible for these facts: >> - The devices will be be available for under US$2. >> - The devices are not available for under US$2. >> - The devices are available for <insert real price> >> >> The formulation chosen by Xilinx marketing definetly is illegal in >> Germany under UWG. (Last time these text were distributed in Germany by >> distributors). And it probably is illegal in the US. >> >> I do not understand why a big company with a good product again and >> againg ressorts to unfair and illegal marketing that is designed to >> confuse customers? >> This really is bad style. >> >> Kolja Sulimma >> (Otherwise a happy Xilinx user)Article: 85891
On Fri, 17 Jun 2005 11:36:40 +0200, Anton Erasmus <nobody@spam.prevent.net> wrote: >On Thu, 16 Jun 2005 22:08:13 -0700, "Jon Harris" ><jon_harrisTIGER@hotmail.com> wrote: > >>Are you taking pictures of stationary things from a stationary camera? That's >>what the astronomy case involves. But since you are concerned with a moving >>camera, I assumed you were talking about pictures taken with a hand-held camera. >If one scaled this down so that the "short" exposure time is in >milli-seconds or even micro-seconds depending on what the sensors can >do, then one can do the same thing just at a much faster scale. >What is the minimum exposure time for a current CMOS sensor before one >just see the inherant sensor noise ? Get real. You've got to read out the sensor, as well as merely exposing it. Unless you have a highly integrated CMOS imager with piles of memory on it, there is essentially only one (*) serial data path out of the device and you need to squeeze all the pixels through that. Shortening the exposure of a CCD sensor is easy; it's done all the time to control exposure time. But it is *very* hard to get the image OUT of a multi-megapixel CCD in less than a few milliseconds. There is precisely one way in which you CAN do this: it's called "Time Delay Integration" or TDI and it's been widely used for hi-res military sensors for ages. If you can arrange that the motion is at a constant speed along the sensor's Y axis, then you can organise the sensor's vertical shift clock so that it keeps in step with the motion, and a fairly long exposure can be perfectly sharp. Brilliant for taking aerial reconnaissance photos from a 'plane in flight. But it needs lots of smarts in the motion sensing and the camera readout electronics. If I read the OP's idea correctly, he wants to correct the picture for motion blurring after it's been exposed. This is perfectly possible if you know the exact behaviour of the motion. The OP should find out about "deconvolution". To take a simpler example: Suppose you have a stream of data, and before you get to see that data you know that it has been processed by a moving-average filter. How can you reconstruct the original data points, if you know the exact form of the moving-average filter function? (*) Some sensors have multiple serial output paths - see Dalsa's offerings, for example. The number of paths is never more than a small handful, though. Broadside readout of the lines into local on-chip memory is the only hope. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 85892
John Adair schrieb: > The point is that DONE is not always an open drain drive. Have a look at > this Xilinx answer and you might get a clearer understanding. > >>Answers Database >>Virtex, Virtex-II Configuration - The DONE pin goes High, but the device does >>not start up (I/Os are inactive/3-stated) Well, this points to a different topic. We don't have any problems after the done pin is high. We have the problem (?) that the DONE pin goes high earlier than expected. The loaded code works very well. Although I doubt that this is a problem, I'll go and check the bitstream option and the lower pull-up value (we use more than 330 Ohms). Can you confirm that the DONE only appears *after* all configuration data has been sent? GuenterArticle: 85893
Hello, I am trying to connect a FFT module generated with coregen to a microprocessor. The problem is that the microprocessor works with floating data in IEEE754 format and the xilinx FFT module accepts, fixed point and block-floating point. How can I convert the data from the microprocessor to one the core understand. Regards Javier CastilloArticle: 85894
Some time ago I wrote a loader to load the Xilinx Spartan2 but this should be the same for the Virtex2 and Spartan3 as far as I know and when I checked back than the signal behave the done should only go active after the whole bitstream was loaded and the crc was ok. You can control when it will go using the Startup Option (By default it come before the output are enable and the internal reset is released). If the reason you are concern about good CRC is that if it is bad you want to try and reload or maybe load different bitstream than what I did was once I ended loading the bitstream I let 16 clocks pass and than checked the done. I don't recall why I use 16 clock as the startup don't let you delay for so long and probably count to 6 should be enough but ... Have fun.Article: 85895
Hi - If we're going to split up the newsgroup--and I strongly suggest that we don't--here are some suggestions: .vendor-to-vendor-flames - FPGA vendor employees argue endlessly about whose performance claims are more specious, whose parts are less available, and whose manners are more uncouth. .homework-problems - Repeated questions about traffic lights and Coke machines, followed by "do it yourself" responses, "here's where to start looking" responses, and "here's how to do it" responses, the last of which guarantee that the stream of questions will never cease. .schematics-vs-hdl - Because we haven't quite beaten this one to death yet. .i-need-an-orcad-symbol - Well, I mean, *I* don't need an Orcad symbol. It's for a friend. .recruiters - Offers of fabulous FPGA design jobs that require you to relocate to the Falkland Islands or Faluja. Sign up before midnight tonight and get a free set of steak knives. .things-i-could-have-googled-for - Self-explanatory. Or maybe not. Bob Perlman Cambrian Design Works On Fri, 17 Jun 2005 02:34:48 -0700, Adam Megacz <megacz@cs.berkeley.edu> wrote: > >I see a lot of posts here that are specific to a single vendor's >devices or that device-vendor's tools. I think it would make things a >bit more organized if we had a few subgroups beneath comp.arch.fpga >for the specific vendors (just like comp.os), and kept comp.arch.fpga >itself for vendor-agnostic (or vendor-comparative) discussions. >Traffic has been pretty high lately (~50 posts/day). > >If you support this (or if you don't), please post in this thread. >Also let me know what vendors you'd like to see listed. Off the top >of my head, alphabetically, > > Actel > Altera > Atmel > Cypress > Lattice > Quicklogic > Xilinx > >I think it would be wise to keep the list short by limiting it to >vendors currently producing and selling chips, and which are available >from distributors at the retail level (ie EOL'ed or a specialty >device). > >If there is sufficient support, I will RFD the matter over on >news.announce.newgroups and reference this thread as justification. >The call for votes will be crossposted here. > >Thanks, > > - aArticle: 85896
now I will try to make it thanks too gaborArticle: 85897
Hi Ed, Thanks for ur info of that gsrd reference design is available for ml403. I have used it and run the treck tcp/IP stack. For me more interesting is running a simple webserver application using powerpc. Can you tell me how can I start implementing it on ml403 board. I have seen one webserver application using lwIP for virtex2pro in application notes 663 but how one can use the same for virtex 4 device on ml403. what kind of chages required to run the webserver application. please give me some hints or notes which help me to use the trimode ethernet MAC.. with regards RajeshArticle: 85898
Hi Ed I found echoserver application in EDK examples.. hope that will help me some extend to use the TMAC.. I come to u if I get any problems.. byeArticle: 85899
"Berty" <wooster.berty@gmail.com> wrote in message
news:1119024451.072046.217090@z14g2000cwz.googlegroups.com...
> Some time ago I wrote a loader to load the Xilinx Spartan2 but this
> should be the same for the Virtex2 and Spartan3 as far as I know and
> when I checked back than the signal behave the done should only go
> active after the whole bitstream was loaded and the crc was ok.
> You can control when it will go using the Startup Option (By default it
> come before the output are enable and the internal reset is released).
>
> If the reason you are concern about good CRC is that if it is bad you
> want to try and reload or maybe load different bitstream than what I
> did was once I ended loading the bitstream I let 16 clocks pass and
> than checked the done.
> I don't recall why I use 16 clock as the startup don't let you
> delay for so long and probably count to 6 should be enough but ...
>
> Have fun.
>
>
I too have written a loader for Spartan II, and I can confirm that DONE
becomes active before the correct number of bits is loaded. At one point my
load code stopped clocking when it saw DONE go high - but the fpga would
then not operate. I now always send the correct number of clocks and then
check DONE and everything is fine ...
Dave
Posted Via Nuthinbutnews.Com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.nuthinbutnews.com
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