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
You also might be interested in following link : http://home.freeuk.com/fpgaarcade/pac_main.htm It has a very simple vga-interface implemented in VHDL. Might be enough to kickstart your design.Article: 60251
How are you connecting your FPGA to your PC ? Do you use any Development Kit ? Which? Is your FPGA in a PCI board, directly accesing the PCI bus from your PC? Are you using the serial interface to communicate with your FPGA? As you can see, there are a lot of open questions to start solving your issues. However, I am nearly sure that you have no easy way of synchronizing the two clocks (unless you clock your FPGA with the same clock that clocks your CPU...), so will have to go to handshake mechanisms to transfer data from one to the other. Give more info out, we'll put some answers out TechCon.Article: 60252
In <bjk17o$jamfg$1@ID-185326.news.uni-berlin.de> leon qin wrote: > http://www.xilinx.com/ise/marketing/new.htm Thanks for that. Unfortunately it looks like this isn't available in the WebPack version for at least another month. Anyone got any other suggestions until then? > "James Fitzsimons" <jamesfit@nospam.paradise.net.nz> wrote in message > news:20030909182654617+1200@news.paradise.net.nz... >> >> > xilinx has released the native linux version. >> >> Could you give me a link?Article: 60253
James <jamesf@intergen.co.nz> wrote: : Hi all, : I have managed to get the Xilinx command line tools running on linux : under wine, however last night while trying to program my device I hit : a bit of a wall. After reading the archives of this group, I see that : that the iMPACT tool won't run under linux. : I have a home made parallel III cable and am trying to program an : XC9536 CPLD. : How are other people doing this? NAXJP http://www.nahitech.com/nahitafu/naxjp/naxjp-e.html can help. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 60254
Sander Vesik <sander@haldjas.folklore.ee> writes: > john jakson <johnjakson@yahoo.com> wrote: > > > > Until recently I was under the impression that CMOS sensors were junk > > and were of low resolution & quality typically 320.240 used in $0-50 > > cameras. I have an old Connectix webcam device thats is all green that > > demonstrates that. > > I believe all present digtal cameras use CMOS. That includes monsters > in the 16Mpixel range. Nope. CMOS sensors are found in cheap cameras up to about 1Mpixel and up to about $100. Above that it is all CCD sensors. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 60255
Hi, I thought I would let you know that I have now got Linux booting and running a sash shell on the serial console. I use the Microblaze serial driver, a little of the Mind patches (however I had to rewrite the interrupt controller driver because of the swapped registers and fix other bits) and stuff I have written myself. This runs on stock 2.4.21, not the Montavista kernel. There are a few issues like busybox having problems because of a bug in the page table code which causes problems for shared binaries. I had to implement a fix for the Xilinx TLB errata and a few other bits and I think this has introduced a subtle bug somewhere. More info when the port is complete at which point I will post a link. Jon.Article: 60256
wait,wait,wait "James Fitzsimons" <jamesfit@nospam.paradise.net.nz> wrote in message news:20030909224829859+1200@news.paradise.net.nz... > In <bjk17o$jamfg$1@ID-185326.news.uni-berlin.de> leon qin wrote: > > http://www.xilinx.com/ise/marketing/new.htm > > Thanks for that. Unfortunately it looks like this isn't available in the > WebPack version for at least another month. Anyone got any other > suggestions until then? > > > "James Fitzsimons" <jamesfit@nospam.paradise.net.nz> wrote in message > > news:20030909182654617+1200@news.paradise.net.nz... > >> > >> > xilinx has released the native linux version. > >> > >> Could you give me a link?Article: 60257
Hi Isaac ! I guess the best thing is to use a kind of "elastic buffer" working with different clock speeds as "asynchronous FIFOs". This will synchronize the data to your FPGA clock. Just write to this FIFO with the maximum clocking speed you can reach by your interface (don't forget to think about handshaking) - maybe an implementation as FSM is usefull. For reading use a different clock. This read clock will be the same as you use it in your FPGA design. Guess, you can find some nice hints at the Xilinx website how to build up a circuit like this. Greets, PeterArticle: 60258
"Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> wrote in message news:<bjiivv$oae1@cliff.xsj.xilinx.com>... > When using Spartan-3 FPGAs in an 3.3V LVTTL or LVCMOS application, the > output voltage, VCCO, must be within the "narrow" voltage range defined in > the EIA/JEDEC JESD8-B specification, namely 3.15V to 3.45V, with a nominal > 3.3V value. > > The primary consideration on Spartan-3 I/Os is to keep the voltage at the > pin below the 3.75V absolute maximum specification. Going above 3.75V > doesn't immediately destroy the device, but prolonged exposure degrades > device lifetime. If the voltage remains below 3.75V, there is no > degradation. > > So, if VCCO should be below 3.45V, how can the voltage at the pin possible > reach 3.75V? Mismatched impedance can cause overshoot and undershoot, > raising the voltage on the pin by hundreds of millivolts. Properly > terminating a trace eliminates or reduces the over/undershoot to acceptable > limits. Application note XAPP659 describes some of the techniques to > guarantee that signals stay under 3.75V. Although written for the Virtex-II > Pro family, these same techniques apply to Spartan-3 FPGAs. > > Using 3.3V I/O Guidelines in a Virtex-II Pro Design. > http://www.xilinx.com/bvdocs/appnotes/xapp659.pdf > Steve, keep in mind I am talking about the reflected signal on an output only. I was provided the following link from Xilinx. Does this refer to the S3 devices as well, as it conflicts with your original responce? http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=11001 Problem Description: Keywords: FPGA, overshoot, undershoot, reliability Urgency: Standard General Description: Does ringing (overshoot and undershoot) compromise the reliability of an FPGA device? Solution 1: For all FPGA families, ringing signals are not a cause for reliability concerns. To cause such a problem, the Absolution Maximum DC conditions need to be violated for a considerable amount of time (seconds). Keep in mind, however, that ringing can create many functional issues, causing glitches, double- clocking, setup/hold errors, etc.Article: 60259
I am fine . Thankyou . I am using Xilinx ISE 5.2 i and Aldec Inc Software . I am using HW2000 Inc .. PCI FPGA Development Board. Having four XCV600 xilinx chip with packaging HQ240. I am using API function to Communicate with the Board. The Bus width is 32 bit and I have 36 bits input to FPGA. Thats why I want to send and store data sequentially in chunk of 3 bits or I could send 18 bits at a time in two clock cycle . As you said I might have to look for handshake mechanism and I have to do something like Interreput Request. If you have any idea then please tell me . Waiting for response. Rgds Isaac. TechnologyConsultant@gmx.ch (Technology Consultant) wrote in message news:<a307051a.0309090243.75974cb8@posting.google.com>... > How are you connecting your FPGA to your PC ? > > Do you use any Development Kit ? Which? > > Is your FPGA in a PCI board, directly accesing the PCI bus from your PC? > > Are you using the serial interface to communicate with your FPGA? > > > As you can see, there are a lot of open questions to start solving > your issues. However, I am nearly sure that you have no easy way of > synchronizing the two clocks (unless you clock your FPGA with the same clock > that clocks your CPU...), so will have to go to handshake mechanisms > to transfer data from one to the other. > > Give more info out, we'll put some answers out > > TechCon.Article: 60260
On 9 Sep 2003 00:20:14 -0700, john_mc_miller@yahoo.com (John McMiller) wrote: >Hi. >I have a xc2v8000 design (70% utilization). > >With the same EDIF netlist the Xilinx routability changes dramatically >with frequency: > >Clock constraint: 25 MHz -> routed design >Clock constraint: 50 MHz -> 1200 un-routed wires >Clock constraint: 100 MHz -> 60000 un-routed wires > >Unfortunately 100 MHz is my target frequency... First run a timing analysis after mapping, before P&R, at 100 MHz (or even faster). This tells you the maximum speed you can expect with infinitely good routing. If there are any paths failing to meet timing, you need to modify the design to remove the timing bottleneck (reduce logic levels between registers), and generate a new EDIF file. Improving the EDIF file will also work to improve the speed of placed/routed designs, but you also have other options, such as floorplanning, to improve the placement (which simplifies the routing problem by ensuring related logic is placed together) - BrianArticle: 60261
All, A reflection back to an output should not cause a problem, as the nmos is ON, or the pmos is ON, effectively clamping the IOB pin to either gnd or Vcco. If, however, the reflections have enough current to pump up the Vcco, then you have to be careful you do not exceed the max Vcco voltage. It is not recommended to have poor signal integrity (ie unterminated fast edge rate signals) in any design, let alone S3. Austin lecroy wrote: > "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> wrote in message news:<bjiivv$oae1@cliff.xsj.xilinx.com>... > > When using Spartan-3 FPGAs in an 3.3V LVTTL or LVCMOS application, the > > output voltage, VCCO, must be within the "narrow" voltage range defined in > > the EIA/JEDEC JESD8-B specification, namely 3.15V to 3.45V, with a nominal > > 3.3V value. > > > > The primary consideration on Spartan-3 I/Os is to keep the voltage at the > > pin below the 3.75V absolute maximum specification. Going above 3.75V > > doesn't immediately destroy the device, but prolonged exposure degrades > > device lifetime. If the voltage remains below 3.75V, there is no > > degradation. > > > > So, if VCCO should be below 3.45V, how can the voltage at the pin possible > > reach 3.75V? Mismatched impedance can cause overshoot and undershoot, > > raising the voltage on the pin by hundreds of millivolts. Properly > > terminating a trace eliminates or reduces the over/undershoot to acceptable > > limits. Application note XAPP659 describes some of the techniques to > > guarantee that signals stay under 3.75V. Although written for the Virtex-II > > Pro family, these same techniques apply to Spartan-3 FPGAs. > > > > Using 3.3V I/O Guidelines in a Virtex-II Pro Design. > > http://www.xilinx.com/bvdocs/appnotes/xapp659.pdf > > > > Steve, keep in mind I am talking about the reflected signal on an > output only. I was provided the following link from Xilinx. Does > this refer to the S3 devices as well, as it conflicts with your > original responce? > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=11001 > > Problem Description: > > Keywords: FPGA, overshoot, undershoot, reliability > > Urgency: Standard > > General Description: > Does ringing (overshoot and undershoot) compromise the reliability of > an FPGA device? > > Solution 1: > > For all FPGA families, ringing signals are not a cause for reliability > concerns. To cause such > a problem, the Absolution Maximum DC conditions need to be violated > for a considerable > amount of time (seconds). > > Keep in mind, however, that ringing can create many functional issues, > causing glitches, double- > clocking, setup/hold errors, etc.Article: 60262
Hi guys, Does anybody have any idea or any link or code for Additive White Gaussian Noise in VHDL ? Or any body have written it or not ? Also how to generate Random Number's in VHDL? Thanks Rgds MacieArticle: 60263
James Fitzsimons wrote: >In <bjk17o$jamfg$1@ID-185326.news.uni-berlin.de> leon qin wrote: > > >>http://www.xilinx.com/ise/marketing/new.htm >> >> > >Thanks for that. Unfortunately it looks like this isn't available in the >WebPack version for at least another month. > The ISE 6.1i WebPACK will be release at the end of September, but will not include Linux support. ISE BaseX, Alliance and Foundation do include native Linux, but only support the Multilinx cable until the 6.2i release in February. > Anyone got any other suggestions until then? > Use a Windows machine for download. Steve > > > >>"James Fitzsimons" <jamesfit@nospam.paradise.net.nz> wrote in message >>news:20030909182654617+1200@news.paradise.net.nz... >> >> >>>>xilinx has released the native linux version. >>>> >>>> >>>Could you give me a link? >>> >>>Article: 60264
"GB" <donotspam_grantbt@jps.net> wrote in message news:ZMJ6b.2615$PE6.812@newsread3.news.pas.earthlink.net... > It's just a still picture (not a movie). Which means that you may be able, after all, to do the whole thing with a micro - if you can tolerate very long image readout times (~2 second). CCDs *can* output their pixels very fast - they *must* do so for video applications, because you have to be able to read out all 2M-ish pixels in one frame time - but they don't *have* to. The image sensor manufacturer probably specs some stupid-fast minimum pixel rate, but you don't need to believe that. They simply don't want the hassle of testing the things at low data rates. Very, very low data rates will degrade the image because of leakage of charge in the CCD transfer registers, but only if you go to stupid-long readout times. So here's the deal: Using your micro.... (1) Pulse the frame transfer clock just once, like it says in the data sheet for the beginning of a frame. This transfers all the accumulated photo-optical charge from imaging cells (pixels) to transfer cells in the CCD. The now-empty imaging cells immediately start to accumulate photo-charge, but you can suppress this process by using the CCD's "electronic shutter" feature - typically, this involves pulling the anti-blooming gates to a special voltage so that any new photo-charge is spilled off into the anti-blooming drain. (2) Wiggle the vertical AND horizontal transfer clocks TOGETHER using your micro. Yes, I know the manufacturer's data doesn't tell you to do this. All you're trying to do here is to clean out the transfer registers as quickly as you can. The video output will be garbage during this process. Keep going until you have clocked the vertical transfer at least twice as many times as there are video lines; remember that your camera has been exposing for a very long time before all this business began, so there's a lot of photo-charge sloshing around that needs to be cleared out thoroughly. Anyway, you need only around two thousand cycles of the clock, and you don't need to DO anything on those cycles - just keep on clocking! (?) It's probably a good idea to do (1) and (2) once more, particularly if the camera has been idling in a high light level for a long time. (3) Stop all the clocks, to keep the camera nice and quiet. Open the electronic shutter so that exposure can begin. (If you prefer, you could have opened the shutter at any time during (2). This makes the process a bit more complicated, but quicker). Time your exposure, then: (4) Hit the frame transfer to get your desired image into the transfer registers. Then you can close the electronic shutter again, so that any further illumination does no harm. (5) Now you need to get the image out of the camera. You can do this at leisure, but you should follow the camera manufacturer's *sequencing* of vertical and horizontal clocks to the letter. Because you're in no hurry, software can do this. Digitise the resulting outgoing video, capture it through the micro, and you're done. As slowly as you like. To reduce shutter latency, it's better to loop around steps (1) and (2) continuously so that the camera is always ready for a new exposure in no more than the time it takes to do (2). Details will vary dramatically between cameras, but this is do-able with any interline transfer CCD and it greatly reduces the hardware requirements - at terrible cost of image capture rate, of course. You'll be doing well if you can get an image out within a second. It's probably no use to you, but it's worth a thought if you are hardware-averse. -- 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, Hampshire, 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: 60265
would like to know which is the best algorithm to make a pipelined divider in hardware. newton raphson, goldshmit .. srt(is it possible?) if i have space as much as to have as much as 5 radix-4 srt dividers in a xilinx v2 fpga.. thanks in advance--Article: 60266
> BTW, the discussion on metastability may appear to be a waste of > "bandwidth", but it is an important discussion since most people seem to > learn about it here rather than in school or elsewhere. I know there > were a great many things that were never even mentioned in school that > turned out to be essential to designing good circuits in the "real > world". > > -- > > Rick "rickman" Collins I agree. Luiz CarlosArticle: 60267
"Martin Euredjian" <0_0_0_0_@pacbell.net> writes: > "Petter Gustad" <newsmailcomp5@gustad.com> wrote in message [snip] > > You might have a problem in your jtag chain. If your tdo does not > > propagate through the XC2V1000 or to the final tdo pin (connected to > > your programmer), your sprom could be programmed but the output check > > fails. > > > > I can program the FPGA (in the same chain) without any problems whatsoever. That would rule out the mentioned potential problem. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 60268
> Peter Alfke, just back from Lisbon. > I gladly missed all the discussions on how to "eliminate" metastability. > What a waste of engineering effort and internet bandwidth... Peter, se você quiser, nós podemos rediscutir o assunto. Que tal começarmos pelas figuras enviadas pelo Philip? Luiz CarlosArticle: 60269
Hi I am using EDK 3.2 and I have the Memec board MB1000 with the P160 communication module. I would like to send and receive Ethernet frames. Has anyone have any luck doing this? What should I setup (in code that is)? Best Regards TerryArticle: 60270
MACEI'S wrote: > Hi guys, > > Does anybody have any idea or any link or code for Additive White > Gaussian Noise in VHDL ? Or any body have written it or not ? > > Also how to generate Random Number's in VHDL? > > > Thanks > > Rgds > > Macie For random numbers try this package: http://www.janick.bergeron.com/wtb/packages/random1.vhd MPJBArticle: 60271
Luiz Carlos wrote: >> Peter Alfke, just back from Lisbon. >> I gladly missed all the discussions on how to "eliminate" >> metastability. What a waste of engineering effort and internet >> bandwidth... > > Peter, se você quiser, nós podemos rediscutir o assunto. Que tal > começarmos pelas figuras enviadas pelo Philip? > > Luiz Carlos Le mot juste...Article: 60272
You might inquire with these folks for their experience using Nios/Cyclone for their combat robot (http://www.maccanikill.com) in their recent "CycloneBot" project. If I remember correctly, there is a Nios Cyclone dev board spinning around in there :) That particular robot operates with two large motors, each driving a single wheel (both wheels are 180 degrees apart). The CPU (and associated FPGA logic) was used to control not only rotational speed, but full movement (turning, fwd/reverse, side to side motion, etc.), at varying speeds of rotation. As for resource utilization: Nios by itself is pretty small. A 16-bit Nios and basic peripheral set can use as little as 1500LEs for a working system, but this will obviously go up if you want to use features such as an SDRAM controller, accelerated multiplication, caches, etc. Planning on 2000-2500LEs is reasonable for a 32-bit Nios-based system. Again, its all dependant on which peripherals (and how many of them) you need to design in. Jesse Kempa Altera Corp. jkempa at altera dot com > > I had similar decision to make - using DSP processor for DSP and Control > or using DSP functions is FPGA and FPGA softcore RISC for control, my > choice was FPGA XC2S200 or S300 and is still fit, but Xilinx Microblaze > while being pretty small still takes considerable amount of FPGA (low cost > ones) so I dont have very much left for DSP (hopefully enough). > > Altera NIOS could be used in 16 bit mode on Cyclone, but here I can not > say what the resource utilization is. > > antti > http://www.graphord.com/forumArticle: 60273
So what is wrong with telling folks that fixing metastability is a myth and waste of time? It is similar to the patent office not considering perpetual motion machines. The basic physics of it is well understood, and that is that..... Austin Tim wrote: > Luiz Carlos wrote: > >> Peter Alfke, just back from Lisbon. > >> I gladly missed all the discussions on how to "eliminate" > >> metastability. What a waste of engineering effort and internet > >> bandwidth... > > > > Peter, se você quiser, nós podemos rediscutir o assunto. Que tal > > começarmos pelas figuras enviadas pelo Philip? > > > > Luiz Carlos > > Le mot juste...Article: 60274
Hi, Yes, you can simulate Nios using the Quartus II simulator. For more advanced simulation (if you want to view code execution, for example), there is additional simulation support built into the Nios kit for using ModelSim (both ModelSim OEM version which comes with a Quartus subscription), or the full version. Please have a look at Altera app note 189 (http://www.altera.com/literature/an/an189.pdf) for instructions & a couple of simulation tutorial designs with Nios & ModelSim. Jesse Kempa Altera Corp. jkempa at altera dot com jwing23@hotmail.com (J-Wing) wrote in message news:<d6e7734d.0309071814.7df06db8@posting.google.com>... > what ways and approaches are there to do system level simulation? > i have a nios system module and a user logic which have been connected > together via the avalon bus. can simulation be done using quartus II?
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