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
It is curious that for years it was assumed that a small inventor would be totally overwhelmed in court by a large corporation. Then, around the mid-70's, the courts became alarmed by patent infringement by FOREIGN companies. I guess it was ok when it was a US corporation that was screwing the small guy. Patents then became an essential defense against a foreign technology onslaught. The small guys started getting more leverage in court, meaning they could actually win cases. I remember a very large patent case about the original inventor of the laser. His original lab notebooks were classified, and other companies started building lasers after the technology was declassified. This guy, however, was denied a patent because by the time his lab notebooks were declassified the tecnology was considered to be in the public domain. Well, he sued the USPTO and won. After getting his patent, he went on to sue EVERY laser manufacturer that refused to license his patent, winning every suit AFAIK. Now, the tables seem to have turned. Nowadays, you hear mostly sympathy for the large corporations: http://www.detnews.com/apps/pbcs.dll/article?AID=/20051225/BIZ04/512250301/1001/BIZ Does anyone have a hanky? Hey, if you don't like the law then change it. Tom SeimArticle: 93701
Paul, Drive strength sets the worst case minimum current that will be available. Worst case is measured at hottest temperature, worst (slowest) process, and lowest IO voltage. So, for example, if we are designing ICs that have to meet mil spec (125C), over all process, and over +/- 10% IO voltage variation, the actual current at 25C, nominal process, and nominal IO voltage will be substantially larger. If you use DCI, you can actually set the output resistance by setting the drive impedance with the external resistors....but Spartan 3 does not have DCI, so that won't help you there. Sorry. DCI (digitally controlled impedance) is a useful feature offerred in the Virtex line, but not in the Spartan line. So, all you have to play with is drive strength (you could set it to 2 mA, or the lowest setting), and the Vcco voltage. By setting the drive to the lowest possible setting for the highest possible Vcco (eg 2 mA at 3.3 V) by lowering the voltage to 2.5V, you will now be much lower current than the operation at 3.3V (and the IOB will still work just fine, as the difference between 3.3V and 2.5V IO standards is how many transistors to turn on in parallel: it takes more to drive the same current at lower voltages). The brightness will vary with chip to chip (process variations) and also will vary with chip temperature. Austin PS: did you know that the Christmas Lights video that went around recently was done in Cincinnati, Ohio, and used Spartan 3 demo kits to control banks of triacs? What some people have time to do is amazing! http://www.snopes.com/photos/arts/xmaslights.asp Paul Boven wrote: > Hi everyone, > > I'm building a circuit that will be driving quite a few (>100) LEDs, > multiplexed into 3 or 4 groups, so up to 40 at the same time. > Can I use the Spartan 3 'Current drive' option to limit drive current to > these LEDs to e.g. 24 mA ? I'm hoping to limit the number of external > components that I'll need. > I've set the IO standard of the ports in question to LVCMOS33 and set > 24mA, but the port drives at least 70mA trough a LED and amp-meter > connected to ground. Setting a lower value for drive current does > decrease the drive, but it stays significantly above the value I set - > and I'd rather not ruin my LEDs or, even worse, FPGA. > > So I'm probably misunderstanding the way 'drive limit' is set or > supposed to be used. Could anyone enlighten me? > > Regards, Paul Boven.Article: 93702
I looked at doing a conversion of the game, but the main problem is the CPU. Having done most of the debugging work on the T80 core, which required running a real cpu in parallel with the soft core and triggering the analyser when they went separate ways - I can assure you it is a lot of work to get it cycle accurate. I am going to release the source of the Namco customs I have reverse engineered some time soon, some of them are on the Pole Position board which may help. Cheers, MikeJ www.fpgaarcade.com "ajcrm125" <ajcrm125@gmail.com> wrote in message news:1135447235.214449.17090@o13g2000cwo.googlegroups.com... > I collect classic arcade games and am looking to do a remake of the > troublesome Pole Position boardset. I then stumbled on this page: > www.fpgaarcade.com > > and loved the idea. The PPI and PPII boardsets are Z8000 based. > -Adam > ================ > www.onecircuit.com > ================ >Article: 93703
Hi Austin, Can you spell this out for me a little clearer. I am a little slow. I went to the FPGA editor to look at the inputs. There is a connection from the N input to the P input. And an ouput of the P going off to the rest of the fabric. Going into the P input, I see a mark next to LVDS_25 and DIFF_TERM FALSE. Should DIFF_TERM be TRUE? The software would not allow me to make a change. I can not find LVDS_DT in the ISE7.1 online documentation libraries guide. Thanks for your help. This has been an issue for several days now. Brad Smallridge aivision.com "Austin Lesea" <austin@xilinx.com> wrote in message news:dourq1$h8e1@xco-news.xilinx.com... > Brad, > > If the part has them (look in data sheet, or keep reading), it would be > the LVDS_DT IO primitive. > > LVDS_DT_p for the + terminal, LVDS_DT_N for the - terminal of the diff > input pair. > > Or, you should be able to see the button in FPGA Editor to turn the > termination ON (if it is in the part you have). > > The ML402 is for the Virtex 4, and all V4 parts have the DT option. > > Austin > > Brad Smallridge wrote: > >> How do you turn the 100 ohm resistor on for an LVDS input? >> I am using the HDR2 header on an ML402 dev board. >> >> Brad Smallridge >> aivision.comArticle: 93704
Peter Alfke wrote: > Source termination is great if you have one source driving a single > destination. Just put a series-terminating resistor right at the > driver, and let the isgnal bounce up to full amplitude at the openended > destination. But never (never!) use source termination when you are > drving multiple detinations along a clock trace. The half-amplitude > signal travelling along the line will cause you lots of grief. > Peter Alfke Hey guys, Thanks a lot for your posts... Frequency does not matter - I did not know that. Thanks for the lesson. Still no easy answer to the Master or Slave configuration flexibility, but maybe I will just have to choose one or the other right now in order to terminate CCLK properly. I may also throw on the parallel termination on both ends and only populate one set, depending on which configuration mode I choose. It is only 1 Virtex-4 SX FPGA being configured, but I will have a PROM and another FPGA (Spartan-III) attached to the CCLK line. Most likely, the Spartan or the PROM will drive the CCLK, but I definitely do want the ability for either one to drive it. Sounds like parallel termination, then, near the Virtex-4 would be my best bet.. I assume that source termination at both the PROM and the Spartan is out of the question since one will act like an additional destination when the other is driving CCLK? Thanks, mike.Article: 93705
Energy consumption is rapidly eclipsing original product acquisition cost when doing a total life-time cost analysis. For each Watt the IC consumes, an additional 2-3 Watts are consumed in power conditioning, conversion and cooling. Tom SeimArticle: 93706
Austin Lesea wrote: > If you use DCI, you can actually set the output resistance by setting > the drive impedance with the external resistors....but Spartan 3 does > not have DCI, so that won't help you there. Sorry. DCI (digitally > controlled impedance) is a useful feature offerred in the Virtex line, > but not in the Spartan line. Spartan 3 does have DCI ... SylvainArticle: 93707
Are you running 8.1? I still have 7.1 and PACE tells me I have thes LVDS options: LVDS_25 LVDS_25_DCI LVDSEXT_25 LVDSEXT_25_DCI Brad "Sean Durkin" <smd@despammed.com> wrote in message news:41gfgfF1dt07oU1@individual.net... > Sean Durkin wrote: >> You either need to instantiate IBUFDS_LVDS25_DT in your HDL-Code >> (instead of just IBUFDS) or attach the IOSTANDARD-attribute to your >> IBUFs, with the value LVDS25_DT. The _DT switches on the differential >> termination. > Sorry, my mistake: it either must be a IBUFDS_LVDS_25_DT in the HDL or > the attribute value LVDS_25_DT. The link I posted earlier doesn't > mention V4, but it should be the same for that. > > And I just read that there's a new attribute "DIFF_TERM" for V4, that > should work as well. You'd have to check the Xilinx Constraint Guide in > the ISE Documentation for that. I suppose you need to set it to "TRUE" > or something. > > cu, > SeanArticle: 93708
Oops...I couldn't find it on the data sheet, Austin Sylvain Munaut wrote: > Austin Lesea wrote: > > >>If you use DCI, you can actually set the output resistance by setting >>the drive impedance with the external resistors....but Spartan 3 does >>not have DCI, so that won't help you there. Sorry. DCI (digitally >>controlled impedance) is a useful feature offerred in the Virtex line, >>but not in the Spartan line. > > > > Spartan 3 does have DCI ... > > > SylvainArticle: 93709
Another excellent reason why the lowest power device is preferable. Austin soar2morrow@yahoo.com wrote: > Energy consumption is rapidly eclipsing original product acquisition > cost when doing a total life-time cost analysis. For each Watt the IC > consumes, an additional 2-3 Watts are consumed in power conditioning, > conversion and cooling. > > Tom Seim >Article: 93710
Paul Boven schrieb: > Hi everyone, > > I'm building a circuit that will be driving quite a few (>100) LEDs, > multiplexed into 3 or 4 groups, so up to 40 at the same time. > Can I use the Spartan 3 'Current drive' option to limit drive current to > these LEDs to e.g. 24 mA ? I'm hoping to limit the number of external > components that I'll need. In a spartan-3 you have a hell lot of logic. So if it is just the number of external components that you want to minimize, you can do the following: - connect the vcc side of all leds together and connect them to vcc via a common resistor. Add a large capacitor to the common node. - use differential input pair, a resistor and a capacitor to build a sigma delta ADC to measure the voltage at the common node. The voltage drop on the resistor is proportional to the current. - use a delta sigma or PWM modulator on the LED-pins to set the current to the desired value for a single LED times the number of LEDs that is currently turned on. This approach uses only 4 external discrete components in addition to the LEDs. Kolja SulimmaArticle: 93711
Right, One termination, only at the end of the line. Can not do both (maybe you could, but you would have to simulate the driver to see if it is strong enough). I like your idea of being able to select the end you want terminated. Either just place the resistors at the 'end' that is really the end (of the line), or solder them at the 'beginning' if that turns out to really be the end (of the line). Austin shogmic wrote: > Peter Alfke wrote: > >>Source termination is great if you have one source driving a single >>destination. Just put a series-terminating resistor right at the >>driver, and let the isgnal bounce up to full amplitude at the openended >>destination. But never (never!) use source termination when you are >>drving multiple detinations along a clock trace. The half-amplitude >>signal travelling along the line will cause you lots of grief. >>Peter Alfke > > > Hey guys, > > Thanks a lot for your posts... Frequency does not matter - I did not > know that. Thanks for the lesson. > > Still no easy answer to the Master or Slave configuration flexibility, > but maybe I will just have to choose one or the other right now in > order to terminate CCLK properly. I may also throw on the parallel > termination on both ends and only populate one set, depending on which > configuration mode I choose. > > It is only 1 Virtex-4 SX FPGA being configured, but I will have a PROM > and another FPGA (Spartan-III) attached to the CCLK line. Most likely, > the Spartan or the PROM will drive the CCLK, but I definitely do want > the ability for either one to drive it. Sounds like parallel > termination, then, near the Virtex-4 would be my best bet.. I assume > that source termination at both the PROM and the Spartan is out of the > question since one will act like an additional destination when the > other is driving CCLK? > > Thanks, > mike. >Article: 93712
> Thanks a lot for your posts... Frequency does not matter - I did not > know that. Thanks for the lesson. Well it is the frequency that's important, it's just not the fundamental frequency so much as the harmonics. With decreasing rise and fall times the amplitudes of the harmonics become more pronounced, and there are more of them which contribute to the overall waveshape. This means that any distortion of these harmonics will result in a much degraded waveshape. This is why termination effects are more important as the fundamental frequency increases, because the harmonics are situated at higher frequencies also and more likely to be interfered with by the impedance mismatches. > Still no easy answer to the Master or Slave configuration flexibility, > but maybe I will just have to choose one or the other right now in > order to terminate CCLK properly. I may also throw on the parallel > termination on both ends and only populate one set, depending on which > configuration mode I choose. If you're only driving the line from one end then you could add parallel terminations at each receiving node (to bring the total impedance seen by the driver to it's nominal impedance). For a 50Ohm driver and infinite impedance receiving nodes the parallel impedances should be 70.7Ohms I believe. If several nodes may drive the line then you might get away with simply adding a combination of parallel and series terminations.Article: 93713
Hey Bob, I have looked at that document. It tells how to use the EDK to generate the embedded system and then import that into Synplify. This INCLUDES the user IP from the system. Then it explains how you can add other logic around the processor subsystem. But the user IP is STILL synthesized using XST. I do not want to use XST except for the Xilinx IP synthesis. I am trying a couple of different things, but haven't had any luck yet. Thanks though, TomArticle: 93714
OK. You add this to your UCF file: INST cam1_x0_ibufd_inst DIFF_TERM = TRUE; INST cam1_x1_ibufd_inst DIFF_TERM = TRUE; INST cam1_x2_ibufd_inst DIFF_TERM = TRUE; INST cam1_x3_ibufd_inst DIFF_TERM = TRUE; INST cam1_xclk_ibufd_inst DIFF_TERM = TRUE; "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:11r5ris939gc844@corp.supernews.com... > How do you turn the 100 ohm resistor on for an LVDS input? > I am using the HDR2 header on an ML402 dev board. > > Brad Smallridge > aivision.com >Article: 93715
Well after all that what I needed to do was to add some of these to the UCF file: INST my_xn_ibufd_instantiation DIFF_TERM = TRUE; That will turn on the differential resistor inside the chip. What was confusing was how much signal got through without the termination. That UCF constraint has to be added to IBUFDs only. I tried to add it to a wizard generated dcm with external differential inputs and got an error. I wonder if Xilinx knows about this. But you can run the xclk into an IBUFD, and run that output into an internal single-ended dcm clock input, no problem. Probably cleaner that way because it's broken down into primitives. Thanks to Rob, Sean, and Avishay for helping me piece the problem together. Brad Smallridge aivision.com "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:11r0jedsghr3me0@corp.supernews.com... > Hello, > > Having trouble with some LVDS signals coming from a Camera Link interface. > I expect to see from steady signals coming from this line camera. DVAL=1. > But it's not there. And the LVAL, line valid, only comes on for maybe one > clock, and I expect it to come on for 2K clocks. > > I am using IBUFDS as inputs. The UCF file loc the pins but that is all. > Do I need something more to drop the 100 ohm termination resitance? > > Brad Smallridge > aivision.com >Article: 93716
> I am thinking about implementing a real-time compression scheme on an FPGA > working at about 500 Mhz. I'm currently working on something similar ... simple predictive schemes (like the 4th predictor from jpeg or MED (from jpeg-ls)) look promising ... they require storage of one line entropy coding: huffman and multilevel arithmetic coding require a lot of ressources (that easily ends up above 1kbit even for a table of probabilities) binary arithmetic coding would be able to code less than 1bit/cycle (which ends up at >5 cyles/pixel which is too slow in my case) I'm currently investigating different schemes of golomb-rice codes (static, adaptive or even context-adaptive like in jpeg-ls) ... so far they look promising ... jpeg-ls: the concept looks nice and quite powerful for a pipelined encoder (like for fpgas) - unfortunately the decoder would require a large feedback-loop (and pipelining is almost impossible) ... jpeg-ls is only symmetric for software implementations :-( I'm still curious how you plan to achieve 500MHz even on a Virtex4 (I would say something like 200MHz could be possible) bye, MichaelArticle: 93717
Hi,everybody. I have some questions about pci interface on Cyclone.Would someone help me? First,Which pins of PCI should be pull-up or pull-down on the board? Second,Do some resistors(33ohms or 50ohms) to be series between EP1C6 and PCI? Thanks.Article: 93718
Bevan Weiss wrote: > > Well it is the frequency that's important, it's just not the fundamental > frequency so much as the harmonics. > With decreasing rise and fall times the amplitudes of the harmonics > become more pronounced, and there are more of them which contribute to > the overall waveshape. This means that any distortion of these > harmonics will result in a much degraded waveshape. > This is why termination effects are more important as the fundamental > frequency increases, because the harmonics are situated at higher > frequencies also and more likely to be interfered with by the impedance > mismatches. Bevan, your description is not totally wrong, but it is misleading. Obviously, any given repetitive event can be correctly described either in the time domain or in the frequency domain. You prefer the frequency domain, bur I say that the time domain is more meaningful in this case. The user has control over the repetition rate (the fundamental frequency) but not over the rise and fall times. And these two phenomena are really not ineterrelated. If you change the fundamental frequency, the rise and fall times do not change, and neither does the damage caused by these rise and fall times. It is thus misleading to describe them as harmonics (although technically they are). If you change the fundamental frequency by an order of magnitude, the problems caused by the sharp transition times do not change at all. That's why we say: The problem is the transition time, not the fundamental frequency. Peter Alfke > >Article: 93719
Paul Hartke wrote: > Was the attempt with 8.1 successful? I can try it as well... > > Paul > After getting a reply from Xilinx, it turns out that there is a problem if you install their software in a path that has embedded spaces, such as "C:\Program Files\Xilinx71". That is where I have it installed. They suggested that I re-install in a top level (C:\xilinx) directory. This is rather involved in that I have to re-install it and then re-install the service pacs. As soon as I have done this, I will post whether it fixed the problem. ChrisArticle: 93720
Brad Smallridge wrote: > Hi Austin, > > Can you spell this out for me a little clearer. I am a little slow. > > I went to the FPGA editor to look at the inputs. There is a > connection from the N input to the P input. And an ouput > of the P going off to the rest of the fabric. > > Going into the P input, I see a mark next to LVDS_25 > and DIFF_TERM FALSE. Should DIFF_TERM be TRUE? > The software would not allow me to make a change. > > I can not find LVDS_DT in the ISE7.1 online documentation > libraries guide. > > Thanks for your help. This has been an issue for several days now. Howdy Brad, Not surprising that you were confused by this. The below answer record mentions that "DT" is available on V2Pro and V4. Except that on the V4 it is invoked in an entirely different way than it is was on the V2Pro: http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=17244 As you can see, you must use LVDS_25_DT for V2Pro, and you must use DIFF_TERM attribute on your LVDS_25 on V4 - so if a design is retargetted from V2Pro to V4, it would run into the exact same problem that you did. Have fun, MarcArticle: 93721
OK, I lied! The article does mention using Synplify to synthesize user IP, but it also says a future article will be available specifically addressing that issue. I guess I would like to see that article. It seems that the app note hints that a user IP can be synthesized from the user_logic level down, black-box imported into the project, wrapped and instantiated in the IP_name.vhd file, and then synthesized using XST in the end. So the user_logic is as far up the module as you can go. I would agree with that. Trying to synthesize the IP_name.vhd file results in having to reference a TON of other files associated with the opb_bus IP. And I never got that to work anyways. Also, it could work to change to a custom make file for the synthesis, point to different scipts for each IP, and then use Synplify that way, but that seems like a lot of work.Article: 93722
peter halford wrote: >I have tried dividing my incoming 25MHz clock by 2 and voilla! >everything works, albeit 50% slower... > >So now I guess I will have to divide the incoming clock by 2, multiply >it and re-divide it. > >Any ideas why this could be happening? If you can run the clock at a slower speed and everything works, then you might have one of several problems. My first suspection would be: There is a logic path longer than the normal time between clocks. I assume you have a period constrant. Yes? Do you have all FFs in the IOBs? And/or checking setup time on all inputs? Do you have any asynchronous sets or resets? -- Phil HaysArticle: 93723
Hallo, I'm developing a microcontroller based on Virtex-4FX. This system should send text to a USB printer. I think to use Cypress 67300 usb microcontroller. In what way could I send text to printer? I must use a RTOS like VxWorks to have usb driver support? Many Thanks MarcoArticle: 93724
"Marco T." <marcotoschi@nospam.it> schrieb im Newsbeitrag news:dp060n$s04$1@nnrp.ngi.it... > Hallo, > I'm developing a microcontroller based on Virtex-4FX. > This system should send text to a USB printer. > > I think to use Cypress 67300 usb microcontroller. > > In what way could I send text to printer? > > I must use a RTOS like VxWorks to have usb driver support? > > Many Thanks > Marco Xilinx ML40x boards have a demo that does work with usb printer v4 and 67300 are used on the board look there antti
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