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
Hi, I am looking for SystemC IP cores for some video/SoC applications (like MPEG4, mp3 decoder, etc.). Is it possible to get such SystemC cores for free from somewhere? thanks -sriniArticle: 58301
Also, be aware that ModelSim needs the initialisation data in generics, while XST needs it in attributes. So, if you plan to simulate (ModelSim) then synthesise (XST), you need to enter the data twice. "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote: :"James" <dinatouch@hotmail.com> wrote: : :> I cannot find a method to preload data to Block RAM (IDE enviroment is :Xilinx ISE 5). : :Go to "Help"; "Online Documentation"; "Libraries Guide" :Expand "Design Elements" :Scroll down to "RAMB4_Sn" or "RAMB4_Sm_Sn" :Double click on one of them. :In the document window, scroll down to the instantiation examples. :In the Verilog section you'll find something like: : :defparam user_instance_name.INIT_00 = 256_bit_hex_value; :defparam user_instance_name.INIT_01 = 256_bit_hex_value; :defparam user_instance_name.INIT_02 = 256_bit_hex_value; :defparam user_instance_name.INIT_03 = 256_bit_hex_value; :... : : :Is that what you were looking for?Article: 58302
Bob wrote: > I am trying to get the Leonardo synthesis tool to use the available > block ram within the FPGA. I have written a dual port RAM in VHDL and > I am trying to synthesize on a Virtex II pro FPGA, which contains > loads of available block RAM. Try this: http://groups.google.com/groups?q=edif.org+sync_ram -- Mike TreselerArticle: 58303
The issue with phase/frequamcy comparators is that they must work and correct the error under all circumstances, with both frequencies widely different, and also with identical frequenceis, but a small phase difference. That limits the playing field. Many decades ago, Motorola created a circuit (I think it was calle 4044 or something like it) that did this job beautifully. I once converted this design into FPGA land, see http://www.xilinx.com/xapp/xapp028.pdf. What you do with the bang-bang outputs is up to you. You can integrate them and feed a VCO, or control an up-down counter... Peter Alfke, Xilinx ============ Jay wrote: > > Hi all. > > I am attempting to design an All-Digital Phase Lock Loop for a motor > control application. I know it's been done before, and I might even find > an off the shelf part that does close to what I want, but some > particular requirements force me to use a CPLD/FPGA. > > Anyway, I've seen several phase-detector/frequency-detector circuits and > often see "Type I" or "Type IV". Is there any comprehensive list of > phase/frequency detectors and/or advantages/disadvantages? I've Googled > but I'm looking for some engineering insight from the people who've > "been there, done that". > > Essentially, what I think I need from the phase/frequency detector are > UP/DOWN signals to tell my system to get the counter-based NCO to run > slower or faster. Are these typically called "bang-bang" type? > > Thanks for your help! > Jay.Article: 58304
Many PCI chips have 3.3V IO but are '5V tolerant'. If they are, they will specifically say so. TC "Willem Oosthuizen" <willy@asic.co.za> wrote in message news:bf8ndu$f3l$1@ctb-nnrp2.saix.net... > PCI on PCs runs off 5V. Yet most FPGA runs at 3V3. What is a suggested > level translator to use? Does the use of level translators effect PCI > compatibility? > >Article: 58305
It depends on what you mean by 'disable'. If you want to make the device invisible to PCI plug-and-play configuration code then you want to disable the IDSEL pin to the PCI device. This will prevent the device from responding to ANY configuration transactions. By default PCI devices are not supposed to be able to become bus master devices, or respond to memory or IO transactions as a slave until configuration software enables them (via the bus master, memory enable and IO enable bits in the Command Register of the devices Configuration Register space). So if configuration software doesn't detect the device because the IDSEL pin is disabled then it will never set those bits and the device will be disabled. TC "Chris Harwood" <chryselwood@hotmail.com> wrote in message news:d6a7ba72.0307170602.4fdd6e42@posting.google.com... > I have a requirement to be able to enable/disable a pci card at the > board level. could someone tell me which pin would be the best to > interupt to accomplish this. I have tried using prsnt1 and prsnt2 open > but the card is still picked up. messing with pins such as IRDY and > TRDY causes the system not to boot. > > Thnx > > Chris HarwoodArticle: 58306
Hi, I am currelty using FPGA Express v3.51 and Max+PlusII to implement Altera CPLD. Accroding to the web page in Altera, if theFPGA Express be used with Quartus II , the version must be v.37. Does anyone know how to get this verison of FPGA Express? -- Patrick LiuArticle: 58307
Hi, I was wondering if anyone can help answer a few questions on CRC. Does FPGA use table lookups to do CRC calculation? Does it help to do so? Also is CRC64 considerably more expensive than CRC32 using FPGA implementation? What is the reasonable performance number for CRC32 or CRC 64? Thanks, JimmyArticle: 58308
In an attempt to create a fine frequency meter, I was drawn by a design from Xilinx. It was published in the Q299 32th XCELL edition and they describe a simple frequency meter design at RTL. My question is that the displayed frequency would be one that has been divided by 5 and gated at 0.5 S. Would this display the right frequency in HZ? Isnt frequency defined as 'number of cycles' per second. thanks for any help Jacques.Article: 58309
Hi, Would like to find out how we can perform a readback of configuration data using the RC100 board from Celoxica/Embedded Solutions Ltd. Regards, JHArticle: 58310
Unsing lookup tables for CRC in an FPGA isn't really worthwhile because it's really easier just to do it with hardware, and it takes less logic. If you are only processing one bit per cycle, then both CRC32 or CRC64 have pretty trivial implementations. You can run this type of circuit over 200MHz easily. If you are processing more than one bit per cycle, it becomes more difficult and you incur more levels of logic, but for a CRC of only five or six bits, I would estimate you could still process one byte per cycle at well over 100MHz (800Mbps). Some tricks can increase that speed. -Kevin "Jimmy Zhang" <crackeur@comcast.net> wrote in message news:WTnSa.89454$OZ2.19172@rwcrnsc54... > Hi, > > I was wondering if anyone can help answer a few questions on CRC. > > Does FPGA use table lookups to do CRC calculation? Does it help to do so? > > Also is CRC64 considerably more expensive than CRC32 using FPGA > implementation? What is the reasonable performance number for CRC32 or CRC > 64? > > Thanks, > Jimmy > >Article: 58311
"Jacques athow" <jaxlau@yahoo.com> wrote in message news:acc717b2.0307192037.76ec3db4@posting.google.com... > In an attempt to create a fine frequency meter, I was drawn by a > design from Xilinx. It was published in the Q299 32th XCELL edition > and they describe a simple frequency meter design at RTL. My question > is that the displayed frequency would be one that has been divided by > 5 and gated at 0.5 S. As the design is to operate at 400MHz input they need a prescaler. They get 5x from the first flipflops, which is good, but not easily readable. The gating time is 1/2 second, and thus during the gate time they get their decade counters incremented by 1/10 of the frequency, which IS easily readable. You might think that this was inaccurate, but if they are to measure frequencies above 10MHz, this makes little difference as the oscillator is highly unlikely to be better than 1 ppm anyway (they're running off a watch resonator). Not being a native english speaker I don't understand the expression 'fine frequency' - I assume you want a meter you can feel proud of? In that case, reciprocal counting is a useful mode to add, especially for frequencies <1MHz. You generate a window pulse of 0.1-100s, and synchronize it to the incoming signal. Then you synchronize that to the reference oscillator. And then you use the synced window pulses to gate a pair of counters. Finally compute inputcounter *reffrequency*prescaler / refcounter. And in this case the prescaler does not cause loss of resolution. That, however, is a somewhat complicated thing to do without a microprocessor, and wouldn't fit in the article.Article: 58312
I haven't used Xilinx parts so I don't know how an SRL is more reconfigurable than the Stratix's TriMatrix memories (ie M512, etc). Using a dual-port M512 in a design means I can use it as LUT and simultaneously reconfigure in through the other port. Why are you saying the SRL is the only reloadable LUT out there? -- Pete Ray Andraka <ray@andraka.com> wrote in message news:<3F15B57D.3ADB33F3@andraka.com>... > Before Stratix, Xilinx really did have the corner on DSP capability. > Stratix gives Altera its first real contender for heavy duty DSP. There > are still some things that Virtex does (notably the SRL16 capability) that > have no parallel in stratix, but then the casual user is not going to have > much access to those features anyway (to take full advantage, you need to > design specifically for those features). For example, the SRL16's can be > used as reloadable LUTs, which makes DA filters attractive for block > adaptive filters. This option is precluded going with a non-Xilinx chip > simply because there is no equivalent function. Stratix is a bit faster, > but you also have fewer multipliers for a given number of marketing > gates. Best to evaluate the chips on their merits as applied to your > target application. If you comfort zone is Altera, and you can make your > application work there without too much pain, it may be best to stay in > your comfort zone.Article: 58313
On 19 Jul 2003 13:52:52 -0700, srisurya@yahoo.com (Srisurya Konduri) wrote: >Thanks for the input, I understand what you are saying as in connect >the pld to SPP, but what I dont understand is what software to use or >code to start the communication and read the memory. I would real >appreciate if you can forward me any examples/codes/links. Typically you need a driver to access the printer port if you running one of the more recent Windows OSes. I have used port95nt successfully. Basically you use it to directly read and write the parallel port. follow the following thread: http://www.fpga-faq.com/archives/39400.html#39407 (to follow a thread, click on the ">>" after the "T" in the Links part of each headder. << >> << T >> << A >> ) The following is also appropriate: http://www.beyondlogic.org/porttalk/porttalk.htm http://www.beyondlogic.org/spp/parallel.htm http://www.beyondlogic.org/epp/epp.htm http://www.doc.ic.ac.uk/~ih/doc/par/ http://www.lvr.com/parport.htm Philip Freidin FliptronicsArticle: 58314
In article <5c4d983.0307200646.91aeaa9@posting.google.com>, Peter Sommerfeld <petersommerfeld@hotmail.com> wrote: >I haven't used Xilinx parts so I don't know how an SRL is more >reconfigurable than the Stratix's TriMatrix memories (ie M512, etc). >Using a dual-port M512 in a design means I can use it as LUT and >simultaneously reconfigure in through the other port. Why are you >saying the SRL is the only reloadable LUT out there? ALL Xilinx LUTs can be used as SRLs, therefore they ALL are reloadable! (until Spartan III, when only half are). -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 58315
You can do a LOT more than that at 100MHz - we have done CRC16 at 128bits per cycle at over 100MHz with no trouble at all (12.8Tbps) in a Virtex-II, slowest speed grade. For a CRC16 of 128 bits, each CRC bit is a function of a subset of the 128bits coming in and the 16 CRC bits from the previous calculation - the most complex bit contains about half the terms (so is the XOR of about 70 bits). Thus, the complete CRC calculator is 16 XOR trees each with less than 70 inputs. A CRC 32 would only be slightly slower, since the largest term would have slightly more inputs (probably closer to 78), so you would have 32 XOR trees each with less than 78 inputs - it would be slower, but not much slower. It would, however, consume more than twice the resources (which aren't tiny). Avrum "Kevin Neilson" <kevin_neilson@removethistextcomcast.net> wrote in message news:7DqSa.90603$wk6.25402@rwcrnsc52.ops.asp.att.net... > Unsing lookup tables for CRC in an FPGA isn't really worthwhile because it's > really easier just to do it with hardware, and it takes less logic. If you > are only processing one bit per cycle, then both CRC32 or CRC64 have pretty > trivial implementations. You can run this type of circuit over 200MHz > easily. If you are processing more than one bit per cycle, it becomes more > difficult and you incur more levels of logic, but for a CRC of only five or > six bits, I would estimate you could still process one byte per cycle at > well over 100MHz (800Mbps). Some tricks can increase that speed. > -Kevin > > "Jimmy Zhang" <crackeur@comcast.net> wrote in message > news:WTnSa.89454$OZ2.19172@rwcrnsc54... > > Hi, > > > > I was wondering if anyone can help answer a few questions on CRC. > > > > Does FPGA use table lookups to do CRC calculation? Does it help to do so? > > > > Also is CRC64 considerably more expensive than CRC32 using FPGA > > implementation? What is the reasonable performance number for CRC32 or CRC > > 64? > > > > Thanks, > > Jimmy > > > > > >Article: 58316
Hi, A small note of caution when using Peter's XAPP028 in Virtex II. As well as constraining the logic to the CLBs shown in the app note, make sure you specify a MAXSKEW attribute on the reference signal and feedback signal to the circuit. I use 100ps. Without this the circuit can occasionally malfunction depending on the place and route. (These are the signals called 'from VCO divided by N' and 'from reference frequency'.) There was no problem when this circuit was used on older FPGAs where the routing to the F and G lookup tables in a single CLB was guaranteed to have low skew. In Virtex II this is no longer the case and a single signal that goes to both the F and G inputs of a CLB can have significant skew if not constrained. This can cause the circuit of XAPP28 to misbehave. Of course it's not your fault Peter that those guys changed the routing from the original 3000 (I guess) design! Thanks for a good APP note I've used many times, maybe it needs a small update! HTH, Syms. p.s. I'm not sure which Xilinx families need the MAXSKEW, I use it always because it can't hurt. Also, make sure the signals don't connect anywhere else, or the MAXSKEW will fail. Replicate them if necessary. Peter Alfke <peter@xilinx.com> wrote in message news:<3F19DFA5.FA39F53B@xilinx.com>... > The issue with phase/frequamcy comparators is that they must work and > correct the error under all circumstances, with both frequencies widely > different, and also with identical frequenceis, but a small phase > difference. That limits the playing field. > Many decades ago, Motorola created a circuit (I think it was calle 4044 > or something like it) that did this job beautifully. > I once converted this design into FPGA land, see > http://www.xilinx.com/xapp/xapp028.pdf. > > What you do with the bang-bang outputs is up to you. You can integrate > them and feed a VCO, or control an up-down counter... > > Peter Alfke, Xilinx > ============ > Jay wrote: > > > > Hi all. > > > > I am attempting to design an All-Digital Phase Lock Loop for a motor > > control application. I know it's been done before, and I might even find > > an off the shelf part that does close to what I want, but some > > particular requirements force me to use a CPLD/FPGA. > > > > Anyway, I've seen several phase-detector/frequency-detector circuits and > > often see "Type I" or "Type IV". Is there any comprehensive list of > > phase/frequency detectors and/or advantages/disadvantages? I've Googled > > but I'm looking for some engineering insight from the people who've > > "been there, done that". > > > > Essentially, what I think I need from the phase/frequency detector are > > UP/DOWN signals to tell my system to get the counter-based NCO to run > > slower or faster. Are these typically called "bang-bang" type? > > > > Thanks for your help! > > Jay.Article: 58317
I'm trying to bring some internal signals out to FPGA pins in order to do some debug. Since I will be probing signals on an ad hoc basis, I don't want to carry them all the way up through to the top level. Is there some way to instantiate an output pad from within a lower level of the hierarchy? I'm using Verilog and a Vitex-II Pro part. I thought I found what I needed at Xilinx Answer Record #6085, telling me to instantiate an OBUF and an OPAD, but XST reports this error: ERROR:HDLCompilers:87 - BlockRAM_Interface.v line 251 Could not find module/primitive 'OPAD' Anyone have advice on how to do this?Article: 58318
Hey Austin, How about an App note/ Tech exclusive showing how to do configuration bitstream decompression using the ICAP present in some of your parts? The configuration stream first loads the FPGA with a small decompression engine. This engine then decompresses the rest of the bitstream and loads the rest of the FPGA through the ICAP. This way, you (Xilinx) get to demonstrate partial configuration and the ICAP. We (the customers) get a way to compress bitstreams if needed. You're not selling a tool, it's an app note. It also is better than a 'hard' solution, as you can update the decompression engine as new ideas are tried. You could start with run length encoding and add more complex stuff later. Users could develop their own, depending on their requirements. As mentioned on comp.arch.fpga passim, you can alter many bits with SEUs without affecting the logic design, this would imply to me significant compression is possible. cheers, Syms. Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F1462AB.B2CEE7A7@xilinx.com>... > Nick, > > It is really hard to sell a tool that only works sometimes (in fact, it does more > damage to do so, than to just not use that tool). > > Thus, until we have a really robust method of compression that works across > thousands of bitstreams, we will stick to the easy method that we use now > (suppressing unused frames from being in the .bit file). > > Austin > > "Nicholas C. Weaver" wrote: > > > In article <3F144161.242FBBAB@xilinx.com>, > > Austin Lesea <Austin.Lesea@xilinx.com> wrote: > > >Compression of bit streams.... > > > > > >Is a tricky business. Some bitstreams compress well, others do not compress > > >much at all. > > > > Right. But compression, in the worst case, offers no savings, but in > > the best case offers substantial savings. > > > > And I'd expect that there is generally a fair amount of savings, just > > from all the switchpoints which support a fairly large amount of > > fanout when most switches only have a small amount of fanout most of > > the time. > > -- > > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 58319
Well, I surprised myself by actually figuring this one out on my own! In order to get rid the the XST error message, I had to edit the file C:\XILINX\verilog\src\iSE\unisim_comp.v and add these lines: module OPAD (PAD); input PAD; endmodule // synthesis attribute BOX_TYPE of OPAD is "BLACK_BOX" To instantiate the pad, the following lines of code were necessary: OBUF tag12_obuf (.O(TAG12), .I(Poll_Now)); OPAD tag12_pad (.PAD(TAG12)); // synthesis attribute loc of tag12_pad is E23; (Poll_Now is the name of the internal signal I wanted to bring out, and TAG12 is the name of the pad.) I'm slightly embarrased to say that this took me about 3 hours to figure out. Hopefully this post will save someone else some time.Article: 58320
Antti, the EDK reference design for ML300 contains - 1 PPC 405 - 1 PLB DDR - 1 PLB bus with arbiter - 1 PLB2OPB bridge - 1 PLB BRAM controller with 32 KB BRAM attached - 1 OPB Uart - 2 OPB GPIO - 1 OPB 10/100 Ethernet (interrupt driven) - 1 OPB IIC - 1 OPB System ACE CF There is no touchscreen, PS/2, TFT, parallel port and AC97. Adding these peripherals to the design is planned for a later release that will most likely happen towards the end of the year. There is some documentation in the zip file that lists the peripherals and explains the design. Again, please contact your Xilinx FAE if you would like to get access to this design. Thanks, - Peter Antti Lukats wrote: > Peter Ryser <ryserp@xilinx.com> wrote in message news:<3F1846C0.776CD1F5@xilinx.com>... > > > > If you want to work with EDK please contact your FAE and ask him to get > > you access to the EDK reference design for ML300. He will be able to get you > > access to the design. > > Hi Peter, > > when we received the EDK + DDR project, I also asked to be notified > when a better EDK ref. design will be available, and so far have not > got any more info, could you please enlight us what additional cores > are available in the EDK ref. design you mentioned? > > ASFAIK TFT and Touchscreen are not implemented (or hopefully are now?) > I have still having trouble to get EDK to work correctly using the > obsoleted TFT ref. design - eg. display is looking in stripes 8 pixels > missing after 8 ok pixels - if the problem is fixed and ref design availabl > would be greate. > > anttiArticle: 58321
Peter Alfke wrote: > > The issue with phase/frequamcy comparators is that they must work and > correct the error under all circumstances, with both frequencies widely > different, and also with identical frequenceis, but a small phase > difference. That limits the playing field. > Many decades ago, Motorola created a circuit (I think it was calle 4044 > or something like it) that did this job beautifully. > I once converted this design into FPGA land, see > http://www.xilinx.com/xapp/xapp028.pdf. > > What you do with the bang-bang outputs is up to you. You can integrate > them and feed a VCO, or control an up-down counter... Yes, that'll be the 74HC4046 (also variants as 74HC7046). This device data has good phase detector info. Some comments on PLL detectors : Some designs use two, one for coarse (effectively Freq) lock, and one for fine (effectively phase) lock. If you are seriously worried about PLL/VCO sidebands, better PLL detectors have deliberate dead-band removal - this is extra logic that prevents a 'flat spot' in the phase/voltage curve, that can occur in simpler digital-state only designs. If in this class, you should use the FPGA OP to drive an analog switch, so the relatively noisy Vcc/Gnds do not appear on the VCO control voltage domain. -jgArticle: 58322
I'm eager to learn if there's a better way to do this myself. I'll tell you that the problem I ran into with various approaches is that bringing some signals out actually broke the design. The culprit --I think-- had to do with modified routing due to the monitoring path ... which created timing problems. I finally resorted to running any signal I want to monitor through a flip-flop clocked by the appropriate clock domain. I also had to ensure that the IOB property for that F/F was set to FALSE in order to have the F/F located close to the signal source and not the IOB. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Greg Nichols" <greg@nichols.nu> wrote in message news:ee7ec04.0@WebX.sUN8CHnE... Well, I surprised myself by actually figuring this one out on my own! In order to get rid the the XST error message, I had to edit the file C:\XILINX\verilog\src\iSE\unisim_comp.v and add these lines: module OPAD (PAD); input PAD; endmodule // synthesis attribute BOX_TYPE of OPAD is "BLACK_BOX" To instantiate the pad, the following lines of code were necessary: OBUF tag12_obuf (.O(TAG12), .I(Poll_Now)); OPAD tag12_pad (.PAD(TAG12)); // synthesis attribute loc of tag12_pad is E23; (Poll_Now is the name of the internal signal I wanted to bring out, and TAG12 is the name of the pad.) I'm slightly embarrased to say that this took me about 3 hours to figure out. Hopefully this post will save someone else some time.Article: 58323
"Avrum" <avrum@REMOVEsympatico.ca> wrote in message news:roBSa.539$1I5.79766@news20.bellglobal.com... > You can do a LOT more than that at 100MHz - we have done CRC16 at 128bits > per cycle at over 100MHz with no trouble at all (12.8Tbps) in a Virtex-II, > slowest speed grade. For a CRC16 of 128 bits, each CRC bit is a function of > a subset of the 128bits coming in and the 16 CRC bits from the previous > calculation - the most complex bit contains about half the terms (so is the > XOR of about 70 bits). Thus, the complete CRC calculator is 16 XOR trees > each with less than 70 inputs. > > A CRC 32 would only be slightly slower, since the largest term would have > slightly more inputs (probably closer to 78), so you would have 32 XOR trees > each with less than 78 inputs - it would be slower, but not much slower. It > would, however, consume more than twice the resources (which aren't tiny). The only 64 bit polynomial that I know of, (listed in Numerical Recipes if one is interested) has very few 1's, so should be convenient for implementing. -- glenArticle: 58324
> [ chop an example of `ifdef that would be trivial in the > traditional C programming world, but strains the capabilities > of Xilinx's Verilog tools] > > > I had to "touch" the test.v to force ISE to re-scan the relationship > > among test.v, mode0_proc.v, and mode1_proc.v. However, I have to "touch" > > so many files in different directories if these files all contained such > > "ifdef"... Is there any other way to solve it? > > I gave up on letting ISE itself deal with `ifdef. Now I run > all my Verilog through Icarus first (iverilog -E) using a Makefile, > and only then sic ISE on the preprocessed output. I agree the > real problem is in the dependency generator, the synthesizer > itself probably gets things right. > > - Larry > What is "iverilog"? I'd like to process the design using Makefile, but how? Is there any reference or example? Thank you! I couldn't believe the bad performance of dependency gnerator of ISE. I found the some files got the correct definition in `ifdef statement, but some files got the old definition if I forgot to "touch" them...
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