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
> my final smile :) to all of you 5 bucks? Hmmm. I'm smiling too :) ZoleeArticle: 88376
On 15 Aug 2005 09:58:49 -0700, "Andy Peters" <Bassman59a@yahoo.com> wrote: >bret.wade@gmail.com wrote: >> Hi Antti, >> >> You would have had your solution a day earlier if you'd put a little >> more effort into the Answers search. Something like "7.1i add external >> pin" works for this case. You can't always depend on your posting being >> read by the person who wrote the Answer Record. >> >> There is another FPGA Editor issue that you may run into: >> http://www.xilinx.com/xlnx/xil _ans_display.jsp?getPagePath=21667 > >I've opened a handful of web cases where the response was, "In Answer >Record 655321, you'll find your answer ..." > >Which is all well and good, but I still find it tough to hit on the >magic search incantation that will lead me to the pot of gold at the >end of the rainbow. > >-a Same here. I make a serious effort to find things in the Answer Record database before filing a web case. And yet sometimes I'm told that the answer, or something in the neighborhood, was already written up. Those offering support on the web--and by no means am I limiting myself to Xilinx--would profit from periodic useabiliity studies. Having someone come to your place of business and search for things on your web site while you watch would be a useful way to improve data organization and search capabilities. Just make sure there's nothing near the computer that the subject can throw. Bob Perlman Cambrian Design WorksArticle: 88377
On Tue, 16 Aug 2005 16:18:45 GMT, james <george@washington.edu> wrote: >On Tue, 16 Aug 2005 09:06:10 -0400, Bob <bob@notrealmail.com> wrote: > >>+<Hi does anybody have a design example of an image sensor connected to >>+<programmable logic with HDL code? >>+< >>+<I want to try this. I have not committed any hardware yet so a working >>+<example would be a great starting point. >>+< >>+<Mostly concerned with the physical connections and image sensor low >>+<level interface code. >****** > >FIrst off you are ging to have to decide on type. Frame Transfer, >progressive scan or CMOS imager. Each one has their advantages and >disadvantages. External clock generation will differ with each. FOr >the most part the Frame Tranfer Imagers, mostly TI, have large gate >capacitances and the clock source for these chips are not drivable >from a FPGA. Peak currents to the SAG and IAG of the TI chips can be >in the range of 1 amp. > >All imagers will clock each pixel out serially, that analog output is >then fed to an ADC. You can bin adjacent pixels to form larger pixels >and even bin rows to increase pixel size. SOme imagers allow this to >be done internal to the chip. > >Then you need to determine what application this camera is used for. >Still pictures using fast integration times, slow integration times, >or video and how many FPS you want. > >Each type of imager requires it own unique interface. So decide from >which type depending on apllication needs and then start thinking of >what circuits are needed around the imager. > >james I am looking for somthing realativly simple. I would like to keep the power and complexity low. Frame rate is not very important to me. I mostly want to learn so books, design examples app notes or your own finished designs woould be great. so simple cheep low power and low cost would be the driving factors. I have found some stuff with google and am reading it now. I looked at kodak and Micron web sites, but they dont have pricing or avalibility on their sensors so other than looking at data sheets they were not much help.Article: 88378
Bob wrote:
> I have found some stuff with google and am reading it now.
> I looked at kodak and Micron web sites, but they dont have pricing or
> avalibility on their sensors so other than looking at data sheets they
> were not much help.
http://www.google.com/search?q=image+sensor+reference+design+fpga
-- Mike Treseler
Article: 88379John Larkin wrote: > On 15 Aug 2005 19:15:42 -0700, ScreamingFPGA@yahoo.com wrote: > > >John Larkin wrote: > >> On 15 Aug 2005 17:48:35 -0700, ScreamingFPGA@yahoo.com wrote: > >> > >> >John Larkin wrote: > >> >> > >> >> You might try banging some extra dummy bits; sometimes that helps. > >> >> > >> >> John > >> > > >> >Thanks John, > >> > > >> > The Configuration file _does_ load, though. I think dummy bits > >> >might help if the DONE line didn't go high. But it does. The FPGA > >> >starts, but the problem is that the INIT line goes low subsequent > >> >to the DONE line going high. > >> > There are apparently differences in configuration programming > >> >between the Virtex/Spartan-2, and the Virtex-2/Spartan-3 that > >> >I don't understand well enough. Especially the CRC / AutoCRC > >> >differences. I've been studying the doc's, but at this point I'm > >> >just confused... > >> > > >> >Thanks for the suggestion though. > >> > > >> >-Scott > >> > > >> >b > >> > >> > >> We just take a .RBT file from ISE and pass it through a little program > >> that packs it verbatum into our ROM image as binary stuff, up above > >> the uP code (sort of a linker, sort of.) At powerup we bit-bang this > >> into the FPGAs in slave serial mode, plus maybe 32 extra bits for > >> luck. This has worked every time so far, on 4000's and S2's and S3's. > >> > >> Does the INIT thing matter? > >> > >> John > > > > Yeah, that's what we do too, just bang out the bit file verbatim. > > > > Maybe it doesn't matter. I checked my older designs, and see that I > >never > >monitored the INIT line, so the S2's could be behaving the same > >way, and I wouldn't know it. Ignorance is bliss? Maybe I should > >check... > > > > I noticed that the Parallel Programmer 6 pin interface adaptor > >doesn't use the INIT pin either. That says something... > > > > It only matters in that: > >1) The fpga is complaining. I'd hate to get bit by it later on > > (no pun intended). > >2) In this design I use INIT (a dual purpose pin) as an input > > after config, but it persists as an output. I guess I could > > cut and jumper, but it would be nice to sort it out and save > > a board rev. > > > > As a practical matter, maybe I should just ignore it for the time > >being. File it in the conundrum bin and move on... > > > >Again, thanks for the fresh perspective. > > > > -Scott > > Are you pulling up INIT? > > John John I _really_ should have ruled out the obvious before jumping to the conclusion that there was some exotic problem... I had come to the conclusion that the fpga was driving the pin low with a 'galvanic skin resistance' pull-up plus scope probe. Didn't budge from ground, though adjacent inputs pulled-up. Should have been a bit more systematic in that test... Being a bit more thorough, I just tacked in a 4.7K pull-up, and saw that it (INIT) behaves as it should during config, but only pulls up to ~1/4 VCCO after config. A 1.5K brings it up to ~3/4 VCCO. It is clear now that there is no config problem and I've been barking up the wrong tree here. Seem's the input is unhappy after config, but the reason is probably a board short, or at worst a stressed IOB. I've been poking and probing it for days, so maybe I induced some ESD damage on the IOB. In any case, no config problem. A million thanks John, for getting me to look in the right place. I feel a bit foolish for letting myself get out on the configuration tangent... Thanks. -ScottArticle: 88380
Antti Lukats wrote: > Hi all > > I am regret to inform you all that this the last time I either post or reply > to comp.arch.fpga newsgroup. This decision was triggered by an reply from an > Xilinx employee to one of my postings. If someone wants to look up that > posting then its around the sentence: "This may have been a mistake" - I do > understand that I may have understand the original intentions of that > posting and that sentence and the context wrong, but that doesnt make any > difference to my decision which is final. <snip> Whoa... Antti - you must have a very thin skin, or give up easily (which I would not have expected ) ? Don't let any single person's posting bother you: it is important to keep a view of the big picture, and keep your sense of humour intact. Better to judge people by their long term nett contribution, and whether they genuinely try to help, than by their etiquette. Throwing the toys out of the cot has some dramatic appeal, but will have little effect. -jgArticle: 88381
it includes PCI-Express ,too.Article: 88382
ScreamingFPGA@yahoo.com wrote: > Hello All, > I'm three days into this configuration problem, > so I think it's time to consult the experts. > Problem's like this usually seem trivial in > retrospect, but I've usually been looking in > the wrong places... > > Briefly, INIT line goes low one CCLK pulse after > DONE line goes high. Configuration loads and runs, > but INIT line low indicates a CRC error. The signals > look quite reasonable on a scope. > > Specifics: > On a new prototype board I'm trying to congigure > a Spartan-3 3s1000-5fg456 using a 3.3V IO micro- > controller driving the fpga's config lines. Dedicated > config lines have serial resistor (100 ohm), as > per recommendation for 3.3V tolerant config. > > I'm using slave-serial mode to write config file, > which is stored on the micro's flash memory. I've > used the same micro and method successfully in other > products (but using Spartan-2). > > I send all data frames ( FFFFFFFF , AA995566 , > ... 20000000 ) start to end of file. > > I'm not sure exactly _where_ the DONE line should > go high. It would seem that it should go high at some > point after the last 32-bit configuration frame, but > in fact DONE transitions on the 7th CCLK pulse of the > (N-4)th configuration frame. XAPP452 shows this as being > [CMD Write Packet Data(DESYNC)] frame. The INIT line > goes low on the 8th CCLK pulse, Fpga operation commences > on the 9th CCLK pulse. > > All design tweaks (resistor value changes) and clock/ > data timing tweaks result in the same behavior. I would > have thought that the CRC error would have prevented > startup of the fpga (CRC is _not_ disabled in bitgen), but > I guess this is not the case... > > If the DONE line _is_ going high early, I suppose this > would mean that extra CCLK transitions were seen by > the FPGA, pointing perhaps towards signal integrity > issues, but this would puzzle me, as under different > circumstances, the transitions happen at the same > points. > > The bit file is being generated by ISE6.2.02. > > Sorry, this post is longwinded, I'm hoping that someone > in the group has encountered a similar situation and can > perhaps point me in the right direction. > > Thanks in advance... > > Scott@sdeviation.com Thanks All For your considerations and patience. Problem solved. Mea Culpa. IIFI. A comedy of errors: Configuration worked perfectly from the get-go. I was convinced there was a config problem because my little 'hello world' LED- BLINKY-THINGY that I had dropped into the top level of the design wasn't causing the LED to blink. I noticed the INIT line was low and became convinced I had a configuration problem. I chased that for a couple of days. By chance I left the proto powered for a couple of hours and noticed the LED had turned on. Checked the design and noticed I had miscalculated the clock divisor for the LED blinker by a few orders of magnitude and it was blinking once every 4 hours, instead of once every second. DOH! By then I had fixated on the INIT line being low, and was ensconced in my theory that the config logic was driving it there, as it 'shoudn't' have been low, by design. My post-config use of the INIT pin was as an input. However my design wasn't using this particular input at this stage of the proto. The synthesis tool re-defined it as an unused pin. I had asked bitgen to pull unused pins low. It all makes sense now. Thanks again all for humoring me. -ScottArticle: 88383
Hello everyone, The EP2C8 device pin-out file (http://www/literature/dp/cyclone2/ep2c8.pdf) displays information for all available packages. There is a row for each pin and the information in the column for the device package specifies the package pin number. If the pin does not appear in a specific package, the corresponding spreadsheet cell is left blank. The pin in question has an optional function LVDS13p and is identified by pin number 8 for the Q208 package and pin number F5 for the F256 package. As mentioned earlier in the thread, the negative pair LVDS13n is available only in the Q208 package displayed as pin 10 and is intentionally left blank for the F256 package indicating that this pin was not bonded out to the package. The Quartus II software issues an error message if you assign a pin with a differential I/O standard to pin number F5. I agree it's not clear that pin number F5 (optional function LVDS13p) only supports single-ended I/O standards. The current version of the pin-out file relies on readers to notice that there is no pin with an optional function LVDS13n in the F256 package. To help clarify this issue, I have requested a footnote be added to an upcoming version of the pin-out documents. As Ben suggested, the footnote will indicate pin number F5 is available only as a single-ended I/O standard because the negative pin for the LVDS channel 13 is not available. By the way, if you use the Quartus II Pin Planner or Timing Closure Floorplan Editor when planning your FPGA IOs, you can turn on Show Differential Pin Pair Connections (View menu) to display a connection between the members of each differential pin pair. Albert Chang Senior Applications Engineer Altera CorporationArticle: 88384
On 16 Aug 2005 13:52:16 -0700, ScreamingFPGA@yahoo.com wrote: >John Larkin wrote: >> On 15 Aug 2005 19:15:42 -0700, ScreamingFPGA@yahoo.com wrote: >> >> >John Larkin wrote: >> >> On 15 Aug 2005 17:48:35 -0700, ScreamingFPGA@yahoo.com wrote: >> >> >> >> >John Larkin wrote: >> >> >> >> >> >> You might try banging some extra dummy bits; sometimes that helps. >> >> >> >> >> >> John >> >> > >> >> >Thanks John, >> >> > >> >> > The Configuration file _does_ load, though. I think dummy bits >> >> >might help if the DONE line didn't go high. But it does. The FPGA >> >> >starts, but the problem is that the INIT line goes low subsequent >> >> >to the DONE line going high. >> >> > There are apparently differences in configuration programming >> >> >between the Virtex/Spartan-2, and the Virtex-2/Spartan-3 that >> >> >I don't understand well enough. Especially the CRC / AutoCRC >> >> >differences. I've been studying the doc's, but at this point I'm >> >> >just confused... >> >> > >> >> >Thanks for the suggestion though. >> >> > >> >> >-Scott >> >> > >> >> >b >> >> >> >> >> >> We just take a .RBT file from ISE and pass it through a little program >> >> that packs it verbatum into our ROM image as binary stuff, up above >> >> the uP code (sort of a linker, sort of.) At powerup we bit-bang this >> >> into the FPGAs in slave serial mode, plus maybe 32 extra bits for >> >> luck. This has worked every time so far, on 4000's and S2's and S3's. >> >> >> >> Does the INIT thing matter? >> >> >> >> John >> > >> > Yeah, that's what we do too, just bang out the bit file verbatim. >> > >> > Maybe it doesn't matter. I checked my older designs, and see that I >> >never >> >monitored the INIT line, so the S2's could be behaving the same >> >way, and I wouldn't know it. Ignorance is bliss? Maybe I should >> >check... >> > >> > I noticed that the Parallel Programmer 6 pin interface adaptor >> >doesn't use the INIT pin either. That says something... >> > >> > It only matters in that: >> >1) The fpga is complaining. I'd hate to get bit by it later on >> > (no pun intended). >> >2) In this design I use INIT (a dual purpose pin) as an input >> > after config, but it persists as an output. I guess I could >> > cut and jumper, but it would be nice to sort it out and save >> > a board rev. >> > >> > As a practical matter, maybe I should just ignore it for the time >> >being. File it in the conundrum bin and move on... >> > >> >Again, thanks for the fresh perspective. >> > >> > -Scott >> >> Are you pulling up INIT? >> >> John > >John > > I _really_ should have ruled out the obvious before jumping to the >conclusion that there was some exotic problem... > > I had come to the conclusion that the fpga was driving the pin >low with a 'galvanic skin resistance' pull-up plus scope probe. >Didn't budge from ground, though adjacent inputs pulled-up. >Should have been a bit more systematic in that test... > > Being a bit more thorough, I just tacked in a 4.7K pull-up, and >saw that it (INIT) behaves as it should during config, but only >pulls up to ~1/4 VCCO after config. A 1.5K brings it up to ~3/4 VCCO. > > It is clear now that there is no config problem and I've been >barking up the wrong tree here. Seem's the input is unhappy after >config, but the reason is probably a board short, or at worst >a stressed IOB. I've been poking and probing it for days, so maybe >I induced some ESD damage on the IOB. In any case, no config problem. > > A million thanks John, for getting me to look in the right >place. I feel a bit foolish for letting myself get out on the >configuration tangent... > >Thanks. > >-Scott Hey, this stuff is complex and it's easy to miss a detail. We had one board with a Spartan 2E that wouldn't configure. Everything looked right, and the board was nearly identical to others we've done. If we probed the config lines at the uP, everything looked right but still no success. But then we probed CCLK *at the fpga* for the duration of a load, and it worked! Seems the scope probe capacitance made it work, but no amount of analysis ever hinted why. So we added a 33 pF cap. to the board. JohnArticle: 88385
John, your problem was caused by the fact that th FPGA CCLK pin (although the driving output) is also the input from which the FPGA itself counts the pulses. An extra glitch at this point, and FPGa and PROM get out-of-synch. Most designers investigate the CCLK line only at the PROM end, and miss the glitch on the FPGA end. I have explained this at least a hundred times, ever since the XC3000 days... Peter Alfke, Xilinx ApplicationsArticle: 88386
On 16 Aug 2005 19:28:56 -0700, "Peter Alfke" <alfke@sbcglobal.net> wrote: >John, >your problem was caused by the fact that th FPGA CCLK pin (although the >driving output) is also the input from which the FPGA itself counts the >pulses. An extra glitch at this point, and FPGa and PROM get >out-of-synch. Sure, but the signal at the FPGA pin was perfect, even if checked with a 500 MHz scope with a fet probe. It's a slow cmos chip driving a short trace. And the board is no different from a dozen similar designs. But the cap fixed it. I'm an engineer: I don't have to understand it, I only have to make it work. JohnArticle: 88387
Hi, Check http://www.xess.com/ho03000.html Digital Camera Interface "Bob" <bob@notrealmail.com> a écrit dans le message de news:i5p3g154hbjm2msumgpsetip5gbnal44pn@4ax.com... > Hi does anybody have a design example of an image sensor connected to > programmable logic with HDL code? > > I want to try this. I have not committed any hardware yet so a working > example would be a great starting point. > > Mostly concerned with the physical connections and image sensor low > level interface code.Article: 88388
500 MHz (reduced further by the probe) may no longer be sufficient for analyzing such problems. You mentioned that the probe eliminated the problem. That indicates a substantial capacitance. "Slow CMOS chips" are not really slow anymore... My question is: How many design are out there in the world, functioning with minimal margins? Attention to Signal Integrity is important like it has never been before. Peter AlfkeArticle: 88389
Hello everyone Does anyone where I can find a simple VHDl code example based on evolutionary algorithms.I am doing a project on evolvable hardware. This will help me get a start on the implementation of Evolvable Hardware. Ankit Parikh Manukau Institute Of TechnologyArticle: 88390
Hallo, I have made a small system based on microblaze. I have made a opb peripheral with register support to transfer data to bus. I connected exernal signal to registers. There is way, into C software to know if data into register is changed? Something similar to an hardware acknowledge signal, but software. Or the only way is to read from register at a certain time interval? Many Thanks MarcoArticle: 88391
Have you tried to install QuartusII version 5.0 ? When I had 4.2 installed I sometimes got a similar abnormal abortion when trying to open my programmer. Rgds Andr=E9 Nial Stewart schrieb: > > I will be obliged if anybody can help me to solve my problem. > > Please let me know if more information needs to be provided. > > Thanks in advance. > > Monica, > > Monica, > > The best place for NIOS problems is.... > > http://www.niosforum.com/index.htm > > > The forums are read by NIOS developers and experienced users. > > You can also search to see if others have had the same problems. > > > Nial. > > ------------------------------------------------------------- > Nial Stewart Developments Ltd > FPGA and High Speed Digital Design > www.nialstewartdevelopments.co.ukArticle: 88392
>But the cap fixed it. I'm an engineer: I don't have to understand it, >I only have to make it work. Usually, you have to understand things in order to make sure that a fix like adding a cap is a solid fix or a just-barely-this-time type fix that might come back to bite you (again) tomorrow. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 88393
Hi friends, I am new to this forum...and found that you guys are really helpful to each other with strong knowledge on FPGAs. So i thought to get your help. So i would really appreciate you guys if you can help me.. I am a graduate student and going to start my MS final project in this fall semester. My interest lies in FPGA-based designs. These can be either in cosumer, broadcast, medical, automotive etc. industries.... So i need your help to find an interesting, new project topic (for FPGA-based design) for me on whicd i can do some research and make some thing new... So i hope you guys would share your opinions.... thanks muchArticle: 88394
whats about this evolvable hardware?Article: 88395
I'm looking for an easy-to-use USB2.0 hi-speed device solution with the minimum of software work required to get a lot of data from a device into a PC. I've found https://www.quickusb.com/ which looks to be exactly what I want, providing DLL calls to use at the PC end to get chunks of data, but it seems somewhat expensive ($150), especially with their connector break-out board ($79 for a PCB with 5 connectors on it!) If that's the only thing around, I'll use it, but was wondering if anyone knows of anything similar that would be worth a look (lower priced would be nice..) Also, does anyone have any feedback on this product & the company ( can't say I'm impressed so far after emailing an ordering enquiry 2 days ago with no reply yet...). This is initially for a 1-off project, but as I may well need USB2 for future production projects, it would be useful to get familiar with something that had a price more viable for production use.Article: 88396
dear chip scope pro users Problem with VIO occurred in ChipScope Pro, ISE6.3. i am (still -: ) exercising VIO,IlA with "asynchronous reset, asynchronous enable, 4 bit counter" It works fine in ILA. That is the signal changes " 0 1 2 3 4 ...." Problem is that, in VIO console, the signal behavior is not the same as ILA. That is the signal changes " 2 9 3 0 9 7 ...", which is unexpected. I am not still sure that this behavior in VIO is problematic or not. BTW, during implementation, following warnings occured. (1) and (3) seem to be okay to ignore, but (2) seems to be problematic. Does anyone has this experience? Why the signal behavior in VIO is different from ILA? ---------------------------- (1)WARNING:Timing:2666 - Constraint ignored: PATH "FROM U_CLK TO D_CLK" TIG ; (2)WARNING:Timing:2665 - clk does not clock any primary output (3)WARNING:Timing:2666 - Constraint ignored: OFFSET = IN 5 nS BEFORE COMP "clk" ; All constraints were met. ---------------------------- ############################ ### UCF file ############################ NET "clk" LOC = "AJ15"; NET "cnt<0>" LOC = "AD13"; NET "cnt<1>" LOC = "AD12"; NET "cnt<2>" LOC = "AD11"; NET "cnt<3>" LOC = "AD10"; NET "clk" TNM_NET = "clk"; TIMESPEC "TS_clk" = PERIOD "clk" 10ns HIGH 50 %; OFFSET = IN 5 ns BEFORE "clk"; OFFSET = OUT 6 ns AFTER "clk";Article: 88397
Antii, I agree with Jim, and I really hope you change your mind. Luiz CarlosArticle: 88398
Hi All, I'm trying to persuade xilinx ISE to display on a remote machine. ISE is installed on a solaris box, and I want to display the GUIS on a linux box. I've got X11 forwarding over SSH working fine. but for some reason the project navigator just will not display. Both coregen and floorplanner pop up fine. I've got a feeling that Project Navigator is just refusing to work with a $DISPLAY set to anything other than :0 Has anyone else had this problem. Or better still, has anyone been able to get Project Navigator to display on a linux box over a remote connection from a solaris Box. ISE 6.3i Solaris 9 Gentoo Many thanks Andy -- Dr. Andrew Greensted Department of Electronics Bio-Inspired Engineering University of York, YO10 5DD, UK Tel: +44(0)1904 432379 Mailto: ajg112@ohm.york.ac.uk Fax: +44(0)1904 433224 Web: www.bioinspired.com/users/ajg112Article: 88399
Andrew Greensted wrote: > I've got X11 forwarding over SSH working fine. but for some reason the > project navigator just will not display. If use use the xhost system, and manually set $DISPLAY project navigator works. So perhaps it just doesn't like the way SSH tunnels the X stuff. Shame, I'd have preferred doing it over ssh (BTW, I've spotted the comedy subject typo, too keen to get help I guess) Andy -- Dr. Andrew Greensted Department of Electronics Bio-Inspired Engineering University of York, YO10 5DD, UK Tel: +44(0)1904 432379 Mailto: ajg112@ohm.york.ac.uk Fax: +44(0)1904 433224 Web: www.bioinspired.com/users/ajg112
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