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
I remember there is some function like CONV_INTEGER (UNSIGN ***) Dont remember exactly but there are such functions to turn the std_logic_vector to integer Jim Patterson <jpatters@stny.rr.com> wrote in message news:T4XK5.99848$JS3.15201591@typhoon.nyroc.rr.com... > Just starting at the VHDL so be gentle. I am doing a simple ALU for my > class. Having trouble with the various types in VHDL. I am trying to do a > case statement on the control input (opcode). When I get to the code that > says to add, subtract, and, or, etc. I get errors. The errors are usually > type mismatches. It seems like some operations (add, subtract) what the > inputs to be integers while other operations (and, or) what them to be > bit_vectors or std_logic_vectors. How can I do this? I have tried several > different things and can't get it going. I know this is simple and I am > just missing something (I hope). Thanks a bunch. > > -- > Jim Patterson > jpatters@stny.rr.com > >Article: 27026
Jerry Avins wrote: > > Michael Barr wrote: > > > > I have just posted the article "NP Complete: An Introduction to Network > > Processing" to the Netrino website. It can be found at the following URL: > > > > http://www.netrino.com/Articles/NetworkProcessors/ > > > ... > > Michael, > > A good pun is priceless! I hope, though, that you don't mean to imply > that Network Processing is isomorphic to the Traveling Salesman Problem. Draw your own conclusion. ;-) Cheers, MichaelArticle: 27027
"Qian Zhang" <qianz@cae.wisc.edu> wrote: > >Here I have a signal-- REALCONTROL, > it changes at the rising clock cycle, >and if it changes, the next following clock cycle >other signals need to be changed correspondingly >so I use > elsif REALCONTROL'event then > CHANGEC:='1'; > elsif REALPHASE'event then > CHANGEP:='1'; > end if; >end process COUNTER_Gen; >However sysopsis told me >Checking... > Error L139/C0 : #0 Error: The 'event or 'stable attribute ( on line 139 ) > is supported only when the attribute is used in conformance with the style >described in the Synopsys manual for the VHDL compiler. (VHDL-2160) > 1 error(s) 0 warning(s) found >Can anyone do me a favor to tell me how to fix it? >Thank you very very much! > For design compiler to recognize a register, you have to code it in a certain way. I am not sure why you are checking REALCONTROL'event twice above but assuming that's a typo, here is what you should do: process (REALCONTROL) begin if REALCONTROL'event and REALCONTROL = '1' then CHANGEP <= '1'; endif; endprocess; If you want a reset, you can do this: process (REALCONTROL, rst) begin if rst = '1' then CHANGEP <= '0'; elsif REALCONTROL'event and REALCONTROL = '1' then CHANGEP <= '1'; endif; endprocess; Muzaffer http://www.dspia.comArticle: 27028
I'm working on designing a low level packet filter on an FPGA. Since it needs run at very high speeds, which would be more advisable to use, PLL or a DLL? -- Anshuman Sharma Georgia Institute of TechnologyArticle: 27029
Tim Jaynes <tim.jaynes@xilinx.com> writes: > Macros can only be used if you have a schematic flow- > If you had a supported schematic tool you could use them in an HDL flow by > creating a netlist w/ hierarchical ports and instantiating that in your code, > but as of now schematic entry in WebPACK only supports CPLDs. Does this mean that I can't use RAM in my VHDL designs when using WebPACK? That would seem like quite a limitation.Article: 27030
Hi Muzaffer Thank you very much! However I still am not very clear, here what if the REALCONTROL='0'? Which means I dont care what REALCONTROL is, only if it changes, I can let CHANGEC<=1. Thanks again in advance > wrote in message news:5tig0ts23g06hknbd8t811jnf95e75evj4@4ax.com... > "Qian Zhang" <qianz@cae.wisc.edu> wrote: > > > >Here I have a signal-- REALCONTROL, > > it changes at the rising clock cycle, > >and if it changes, the next following clock cycle > >other signals need to be changed correspondingly > >so I use > > elsif REALCONTROL'event then > > CHANGEC:='1'; > > elsif REALPHASE'event then > > CHANGEP:='1'; > > end if; > >end process COUNTER_Gen; > >However sysopsis told me > >Checking... > > Error L139/C0 : #0 Error: The 'event or 'stable attribute ( on line 139 ) > > is supported only when the attribute is used in conformance with the style > >described in the Synopsys manual for the VHDL compiler. (VHDL-2160) > > 1 error(s) 0 warning(s) found > >Can anyone do me a favor to tell me how to fix it? > >Thank you very very much! > > > > For design compiler to recognize a register, you have to code it in a > certain way. I am not sure why you are checking REALCONTROL'event > twice above but assuming that's a typo, here is what you should do: > > process (REALCONTROL) begin > if REALCONTROL'event and REALCONTROL = '1' then > CHANGEP <= '1'; > endif; > endprocess; > > If you want a reset, you can do this: > > process (REALCONTROL, rst) begin > if rst = '1' then > CHANGEP <= '0'; > elsif REALCONTROL'event and REALCONTROL = '1' then > CHANGEP <= '1'; > endif; > endprocess; > > Muzaffer > http://www.dspia.comArticle: 27031
> > > Use logiblox or coregen to set a constant. > > > > Why not use a buf and tie power/ground on the input side to what ever > your > > constant wants to be? > > This works just fine, but for large numbers the buffers take up a lot of > room on the schematic sheet. Also, a logiblox constant is more readable > from a documentation perspective. That would not be an 'optimal' way to implement what I suggested. I would make a symbol, and put the bufs etc. under the symbol...and that documents it pretty well if you put a number in the middle of the symbol, and name the symbol something 'intelligent'. Hierarchy should be part of any well drawn schematic, especially with FPGAs, and making re-usable modules (such as constants, registers etc.) will make your designs easier to do and easier to read.Article: 27032
Thank You, but I know, How can I do it (encoding of internal states in VHDL). I performed many test with encoding and I need some literature to comparing my results to other. And the second reason is that I need some cross-references into my diploma thesis about this problem. MICHAL yuryws@my-deja.com wrote: > Look at chapter "Synthesis and Simulation Design Guide" after following > the link below: > http://toolbox.xilinx.com/docsan/2_1i/ > > In article <3A06C0EB.A4BCDFB6@asicentrum.cz>, > Michal Prokes <michal.prokes@asicentrum.cz> wrote: > > Hello, > > I'm student and I'm interested in encoding of internal states in FSMs > > (finite state machine) in relation to realization these FSMs to Xilinx > > FPGA. > > I try to use different encoding of internal states (binary, gray, > > johnson, onehot, twohots, fanin ... etc) and I woud like to find out > > some relations between encoding and number of used CLBs, etc.. > > > > So, could you send me some tips to literature or www links (about > this)? > > > > Thanks, > > > > MICHAL (michal.prokes@asicentrum.cz) > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 27033
"Frank Z.F Xie" wrote:
>
> These days I failed to connect www.xilinx.com from here, does anybody have
> the same experience?
>
Me too. Cannot connect since yesterday...
--
+------------------------------------------------------------+
| Jean-Marie Bussat - Dept. of physics, Princeton University |
| CERN/EP - Bldg. 15-S-012 - CH-1211 GENEVA 23 - Switzerland |
| Email: bussat@cern.ch |
| Tel: (41 22) 767 32 41 Fax: (41 22) 767 32 41 |
+------------------------------------------------------------+
http://suncmspri1.cern.ch:800/~bussat
Article: 27034"Frank Z.F Xie" <frank.xie@latticesemi.com> wrote in message news:8uaa0m$int$1@info.sta.net.cn... > These days I failed to connect www.xilinx.com from here, does anybody have > the same experience? I've been trying to download the latest service pack for the last few days, but can't seem to get better than 1k bytes/sec transfer rate. MHArticle: 27035
It seems that it strongly depends on time and location. I had no problem downloading the new servies pack 5 which has approx. 50MB within serveral minutes yesterday afternoon (CET) from Germany. Dirk "Frank Z.F Xie" schrieb: > These days I failed to connect www.xilinx.com from here, does anybody have > the same experience? > > -- > > Zhengfan Xie -- +----------------------------------+----------------------------------+ | Dirk Galda | | | | | | TU Hamburg-Harburg | | | Department of Telecommunications | Phone: (++49)-40-42878-2745 | | Eißendorfer Straße 40 | Fax: (++49)-40-42878-2281 | | 21073 Hamburg | mailto:galda@tu-harburg.de | | Germany | http://www.et2.tu-harburg.de | +----------------------------------+----------------------------------+Article: 27036
Bitgen has an option to load a 8 character hexidecimal number into the "User ID Register" whatever the heck that is. I've been looking through the Xilinx docs and can't find an answer. It might be a JTAG thing, and not something inside the Virtex/Spartan which I can read once the device is programmed. Someone privately suggested to me that you could put the serial number in the config prom after the config data, and use an external mux on cclk to milk the bits out ot the config prom and into an I/O pin. I'm concerned about the MTBF reduction caused by using a low-tech part in such a critical area, though it only has to work once, at power up... -- Gary Watson gary2@nexsan.com Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.com "Hal Murray" <murray@pa.dec.com> wrote in message news:8ua6pd$57s@src-news.pa.dec.com... > > > Is there any possibilty to create a bistream for a Xilinx spartan XCS30 with > > a unique serial nr (e.g. in a register or hardwired)? > > > > I need approx 25000 systems/year and can not afford an extra component like > > the Dallas serial nr components. > > Somebody else asked the same thing on another thread. > > This seems like a good topic for a Xilinx APP note. > > > It sounds like a reasonably straight forward thing to do. Just put > the serial number in a ROM. You can either re-run the Xilinx tools > to make the special bit stream for each device or you can work out > how to do modify the basic bitstream. > > If I wanted to do it myself, I'd do something like this: > > Put all 0s in the ROM. Make your bits. > > Change the ROM contents to 1. Make the bits again and see which > bit(s) changed. > > Repeat for all the other bits on the ROM. > > The bit stream may have a CRC to complicate things. I couldn't find > the details in the Virtex data sheet. You can probably just XOR > those changed bits too. (CRCs are nice that way.) > > > But you should really think about doing this. You now have to make > a separate bit stream for each device. You have to make sure you get it > right. How bad is it if you get it wrong, for example by shipping two > boxes with the same serial number? > > Also look into Ethernet HostID ROMs. > > > -- > These are my opinions, not necessarily my employers. I hate spam. >Article: 27037
Hi, Can anyone tell me how to instantiate dpram by using renoir as entry programs. I mean how can I infer the package for the Altera ACEX in renoir. Thanks. RolandArticle: 27038
Dear colleagues, I am looking for a good introductory document for doing boundary scan via JTAG. I am intending to implement self-testing functionality on embedded system comprising XILINX FPGA and TI DSP. So, I can not use "of the shelf" hardware/software solution, and should start from the very beginning: sequences of JTAG signals, JTAG command codes, ... Where can I find such basic information? Thanks, Alex SherstukArticle: 27039
Hi,
I've instaled WebPack 3.2 on Silicon Graphics computer with Win NT4.0
(Service Pack 4) adn when I try to synthesize design I get information
about some errors
ERROR : VHP__3024 Cannot read library unit jc2_top. It has been stored
before the predefined library
unit std_logic_1164 of library
ieee. Clean your dump directory and recompile your
design again.
I don't know what to do to avoid this error.I'm waiting for your help
Thanks
Wojciech Madejski
Article: 27040In article <8ubslk$1btff$1@ID-27424.news.dfncis.de>, "Alex Sherstuk" <sherstuk@iname.com> wrote: > Dear colleagues, > > I am looking for a good introductory document for doing boundary scan via > JTAG. I am intending to implement self-testing functionality on embedded > system comprising XILINX FPGA and TI DSP. So, I can not use "of the shelf" > hardware/software solution, and should start from the very beginning: > sequences of JTAG signals, JTAG command codes, ... > Where can I find such basic information? > > Thanks, > Alex Sherstuk > http://www-s.ti.com/sc/psheets/ssya002c/ssya002c.pdf Regards, Dave Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27041
I have a problem concerning the global buffers (BUFG) in a xc4062xla fpga from xilinx. I have 2 clocks signals using them in a design (the second clock is internal). I can see these buffers in the xnf netlist. During Place & Route the design manager gives me a warning saying that my internal clock is using non-dedicated resources. Can somebody help me? ThanksArticle: 27042
--------------20355C97D5FCEB4DF06F691F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anshuman, The DLL is not a PLL. A PLL is not the DLL. They both have their advantages and disadvantages. Thanks for the opportunity to respond on this topic. Virtex Family DLL's The DLL's in Virtex is an all digital device with a state machine, and tapped delay line. The result of using it is always predictable, and it will always be the same on any chip ever manufactured. It is unaffected by voltage, temperature, and process due to its design. The jitter out of the CLK0 output is a fixed known amount +/- one tap (~40 ps). DLL's do not filter out the input jitter, they pass it through. The jitter input tolerance is as stated in the data sheet, and if exceeded, the device will not assert the LOCK signal, or it will lose LOCK if it locks at all. All outputs (0, 90 degrees, 180 degrees, 270 degrees, 2X, CLKDV) behave in this precise predictable digital fashion. The absolute phase error of the DLL is constrained to a tap, combined with the error in matching the two inputs (in and feedback) to the DLL (also very small because the of the physical layout). The DLL is designed to run as fast as the global clock buses, so speed inside the FPGA is not an issue (can't go any faster). The input range of the DLL is much larger than that of a PLL. PLL's A phase locked loop is an analog device with a voltage or current controlled oscillator (RC, LC, inverter ring, crystal, etc), a phase detector, and a loop filter. Each one is unique, and there may be significant variations in lot to lot, and part to part. It is not unusual to change components to make PLL's work on the production floor. PLL's are directly affected by voltage, temperature, process (and some claim phases of the moon). PLL's may have a lot, or no input jitter tolerance. You have to look a Bode Plot of the loop response to see if it is stable, and perform a number of jitter tolerance and transfer tests on a number of units over temperature and voltage. You never really know if a PLL is locked (its analog!) The jitter out of a PLL can be extremely small (a few ps), or very very gross (~90 ps). It depends entirely on the design, filter, oscillator chosen, and how much of the digital signals disturb the operation of the PLL's loop. PLL's are able to filter out input jitter if designed properly. PLL's have no outputs other than the oscillator output, which may be running a twice the intended frequency to yield 180 degrees, or even higher if more phases are required. The phase error of the PLL varies with voltage, temperature, and process, and is difficult to contrain when trying to de-skew clock signals. It is often unspecified due to the extreme difficulties in characterization and test. PLL's can run at arbitraily high speeds (GHz), but offer narrow ranges of operation. Which to use? If you are dealing with digital signals, in the digital domain, and you are processing and modifying these signals, then the DLL is a natural choice. If you need to filter jitter, then you may have to use the PLL. If that is the case, an off-chip PLL, where you can use your own filter, and oscillator may be the only way to go. PLL's that are co-located with other digital logic tend to add as much jitter as they are trying to remove. If you are in a communications system, with carrier frequencies, IF's, up converters, and down converters, you will be using many PLL's, and be miserable for it....always waiting for that phone call: "line down, PLL's not locking, again!" Austin Lesea Principal Engineer, FPGA Lab Xilinx Anshuman Sharma wrote: > I'm working on designing a low level packet filter on an FPGA. Since it > needs run at very high speeds, which would be more advisable to use, PLL > or a DLL? > > -- > Anshuman Sharma > Georgia Institute of Technology --------------20355C97D5FCEB4DF06F691F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Anshuman, <p>The DLL is not a PLL. A PLL is not the DLL. They both have their advantages and disadvantages. Thanks for the opportunity to respond on this topic. <p><b>Virtex Family DLL's</b> <p>The DLL's in Virtex is an all digital device with a state machine, and tapped delay line. The result of using it is always predictable, and it will always be the same on any chip ever manufactured. <p>It is unaffected by voltage, temperature, and process due to its design. <p>The jitter out of the CLK0 output is a fixed known amount +/- one tap (~40 ps). DLL's do not filter out the input jitter, they pass it through. <p>The jitter input tolerance is as stated in the data sheet, and if exceeded, the device will not assert the LOCK signal, or it will lose LOCK if it locks at all. <p>All outputs (0, 90 degrees, 180 degrees, 270 degrees, 2X, CLKDV) behave in this precise predictable digital fashion. <p>The absolute phase error of the DLL is constrained to a tap, combined with the error in matching the two inputs (in and feedback) to the DLL (also very small because the of the physical layout). <p>The DLL is designed to run as fast as the global clock buses, so speed inside the FPGA is not an issue (can't go any faster). The input range of the DLL is much larger than that of a PLL. <p><b>PLL's</b> <p>A phase locked loop is an analog device with a voltage or current controlled oscillator (RC, LC, inverter ring, crystal, etc), a phase detector, and a loop filter. Each one is unique, and there may be significant variations in lot to lot, and part to part. It is not unusual to change components to make PLL's work on the production floor. <p>PLL's are directly affected by voltage, temperature, process (and some claim phases of the moon). <p>PLL's may have a lot, or no input jitter tolerance. You have to look a Bode Plot of the loop response to see if it is stable, and perform a number of jitter tolerance and transfer tests on a number of units over temperature and voltage. You never really know if a PLL is locked (its analog!) <p>The jitter out of a PLL can be extremely small (a few ps), or very very gross (~90 ps). It depends entirely on the design, filter, oscillator chosen, and how much of the digital signals disturb the operation of the PLL's loop. PLL's are able to filter out input jitter if designed properly. <p>PLL's have no outputs other than the oscillator output, which may be running a twice the intended frequency to yield 180 degrees, or even higher if more phases are required. <p>The phase error of the PLL varies with voltage, temperature, and process, and is difficult to contrain when trying to de-skew clock signals. It is often unspecified due to the extreme difficulties in characterization and test. <p>PLL's can run at arbitraily high speeds (GHz), but offer narrow ranges of operation. <p><b>Which to use?</b><b></b> <p>If you are dealing with digital signals, in the digital domain, and you are processing and modifying these signals, then the DLL is a natural choice. <p>If you need to filter jitter, then you may <i>have</i> to use the PLL. If that is the case, an off-chip PLL, where you can use your own filter, and oscillator may be the only way to go. <p>PLL's that are co-located with other digital logic tend to add as much jitter as they are trying to remove. <p>If you are in a communications system, with carrier frequencies, IF's, up converters, and down converters, you will be using many PLL's, and be miserable for it....always waiting for that phone call: <b><i>"line down, PLL's not locking, again!"</i></b> <p>Austin Lesea <br>Principal Engineer, FPGA Lab <br>Xilinx <p>Anshuman Sharma wrote: <blockquote TYPE=CITE>I'm working on designing a low level packet filter on an FPGA. Since it <br>needs run at very high speeds, which would be more advisable to use, PLL <br>or a DLL? <p>-- <br>Anshuman Sharma <br>Georgia Institute of Technology</blockquote> </html> --------------20355C97D5FCEB4DF06F691F--Article: 27043
This is a multi-part message in MIME format. --------------ACFD1FAC06600901C0C3498A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I suggest looking at the Xilinx Boundary Scan/JTAG Technical Tips page at: http://support.xilinx.com/support/techsup/journals/jtag/index.htm Click on the "Getting Started" Link and hopefully many of your questions can be answered there. -- Brian Alex Sherstuk wrote: > Dear colleagues, > > I am looking for a good introductory document for doing boundary scan via > JTAG. I am intending to implement self-testing functionality on embedded > system comprising XILINX FPGA and TI DSP. So, I can not use "of the shelf" > hardware/software solution, and should start from the very beginning: > sequences of JTAG signals, JTAG command codes, ... > Where can I find such basic information? > > Thanks, > Alex Sherstuk --------------ACFD1FAC06600901C0C3498A Content-Type: text/x-vcard; charset=us-ascii; name="brian.philofsky.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brian.philofsky.vcf" begin:vcard n:Philofsky;Brian tel;work:1-800-255-7778 x-mozilla-html:TRUE url:http://www.xilinx.com org:Xilinx, Inc.;Software Marketing adr:;;2300 55th Street;Boulder;CO;80301;USA version:2.1 email;internet:brianp@xilinx.com title:Sr. Technical Marketing Engineer fn:Brian Philofsky end:vcard --------------ACFD1FAC06600901C0C3498A--Article: 27044
hi, is it right than the PLL is able to deliver also any ratio...but the Dll just integer or integer+0.5 --Erika In article <3A09918E.246A77FF@xilinx.com>, Austin Lesea <austin.lesea@xilinx.com> wrote: > > --------------20355C97D5FCEB4DF06F691F > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Anshuman, > > The DLL is not a PLL. A PLL is not the DLL. They both have their > advantages and disadvantages. Thanks for the opportunity to respond on this > topic. > > Virtex Family DLL's > > The DLL's in Virtex is an all digital device with a state machine, and > tapped delay line. The result of using it is always predictable, and it > will always be the same on any chip ever manufactured. > > It is unaffected by voltage, temperature, and process due to its design. > > The jitter out of the CLK0 output is a fixed known amount +/- one tap (~40 > ps). DLL's do not filter out the input jitter, they pass it through. > > The jitter input tolerance is as stated in the data sheet, and if exceeded, > the device will not assert the LOCK signal, or it will lose LOCK if it locks > at all. > > All outputs (0, 90 degrees, 180 degrees, 270 degrees, 2X, CLKDV) behave in > this precise predictable digital fashion. > > The absolute phase error of the DLL is constrained to a tap, combined with > the error in matching the two inputs (in and feedback) to the DLL (also very > small because the of the physical layout). > > The DLL is designed to run as fast as the global clock buses, so speed > inside the FPGA is not an issue (can't go any faster). The input range of > the DLL is much larger than that of a PLL. > > PLL's > > A phase locked loop is an analog device with a voltage or current controlled > oscillator (RC, LC, inverter ring, crystal, etc), a phase detector, and a > loop filter. Each one is unique, and there may be significant variations in > lot to lot, and part to part. It is not unusual to change components to > make PLL's work on the production floor. > > PLL's are directly affected by voltage, temperature, process (and some claim > phases of the moon). > > PLL's may have a lot, or no input jitter tolerance. You have to look a Bode > Plot of the loop response to see if it is stable, and perform a number of > jitter tolerance and transfer tests on a number of units over temperature > and voltage. You never really know if a PLL is locked (its analog!) > > The jitter out of a PLL can be extremely small (a few ps), or very very > gross (~90 ps). It depends entirely on the design, filter, oscillator > chosen, and how much of the digital signals disturb the operation of the > PLL's loop. PLL's are able to filter out input jitter if designed properly. > > PLL's have no outputs other than the oscillator output, which may be running > a twice the intended frequency to yield 180 degrees, or even higher if more > phases are required. > > The phase error of the PLL varies with voltage, temperature, and process, > and is difficult to contrain when trying to de-skew clock signals. It is > often unspecified due to the extreme difficulties in characterization and > test. > > PLL's can run at arbitraily high speeds (GHz), but offer narrow ranges of > operation. > > Which to use? > > If you are dealing with digital signals, in the digital domain, and you are > processing and modifying these signals, then the DLL is a natural choice. > > If you need to filter jitter, then you may have to use the PLL. If that is > the case, an off-chip PLL, where you can use your own filter, and oscillator > may be the only way to go. > > PLL's that are co-located with other digital logic tend to add as much > jitter as they are trying to remove. > > If you are in a communications system, with carrier frequencies, IF's, up > converters, and down converters, you will be using many PLL's, and be > miserable for it....always waiting for that phone call: "line down, PLL's > not locking, again!" > > Austin Lesea > Principal Engineer, FPGA Lab > Xilinx > > Anshuman Sharma wrote: > > > I'm working on designing a low level packet filter on an FPGA. Since it > > needs run at very high speeds, which would be more advisable to use, PLL > > or a DLL? > > > > -- > > Anshuman Sharma > > Georgia Institute of Technology > > --------------20355C97D5FCEB4DF06F691F > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: 7bit > > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > <html> > Anshuman, > <p>The DLL is not a PLL. A PLL is not the DLL. They both have > their advantages and disadvantages. Thanks for the opportunity to > respond on this topic. > <p><b>Virtex Family DLL's</b> > <p>The DLL's in Virtex is an all digital device with a state machine, and > tapped delay line. The result of using it is always predictable, > and it will always be the same on any chip ever manufactured. > <p>It is unaffected by voltage, temperature, and process due to its design. > <p>The jitter out of the CLK0 output is a fixed known amount +/- one tap > (~40 ps). DLL's do not filter out the input jitter, they pass it > through. > <p>The jitter input tolerance is as stated in the data sheet, and if exceeded, > the device will not assert the LOCK signal, or it will lose LOCK if it > locks at all. > <p>All outputs (0, 90 degrees, 180 degrees, 270 degrees, 2X, CLKDV) behave > in this precise predictable digital fashion. > <p>The absolute phase error of the DLL is constrained to a tap, combined > with the error in matching the two inputs (in and feedback) to the DLL > (also very small because the of the physical layout). > <p>The DLL is designed to run as fast as the global clock buses, so speed > inside the FPGA is not an issue (can't go any faster). The input > range of the DLL is much larger than that of a PLL. > <p><b>PLL's</b> > <p>A phase locked loop is an analog device with a voltage or current controlled > oscillator (RC, LC, inverter ring, crystal, etc), a phase detector, and > a loop filter. Each one is unique, and there may be significant variations > in lot to lot, and part to part. It is not unusual to change components > to make PLL's work on the production floor. > <p>PLL's are directly affected by voltage, temperature, process (and some > claim phases of the moon). > <p>PLL's may have a lot, or no input jitter tolerance. You have to > look a Bode Plot of the loop response to see if it is stable, and perform > a number of jitter tolerance and transfer tests on a number of units over > temperature and voltage. You never really know if a PLL is locked > (its analog!) > <p>The jitter out of a PLL can be extremely small (a few ps), or very very > gross (~90 ps). It depends entirely on the design, filter, oscillator > chosen, and how much of the digital signals disturb the operation of the > PLL's loop. PLL's are able to filter out input jitter if designed > properly. > <p>PLL's have no outputs other than the oscillator output, which may be > running a twice the intended frequency to yield 180 degrees, or even higher > if more phases are required. > <p>The phase error of the PLL varies with voltage, temperature, and process, > and is difficult to contrain when trying to de-skew clock signals. > It is often unspecified due to the extreme difficulties in characterization > and test. > <p>PLL's can run at arbitraily high speeds (GHz), but offer narrow ranges > of operation. > <p><b>Which to use?</b><b></b> > <p>If you are dealing with digital signals, in the digital domain, and > you are processing and modifying these signals, then the DLL is a natural > choice. > <p>If you need to filter jitter, then you may <i>have</i> to use the PLL. > If that is the case, an off-chip PLL, where you can use your own filter, > and oscillator may be the only way to go. > <p>PLL's that are co-located with other digital logic tend to add as much > jitter as they are trying to remove. > <p>If you are in a communications system, with carrier frequencies, IF's, > up converters, and down converters, you will be using many PLL's, and be > miserable for it....always waiting for that phone call: <b><i>"line down, > PLL's not locking, again!"</i></b> > <p>Austin Lesea > <br>Principal Engineer, FPGA Lab > <br>Xilinx > <p>Anshuman Sharma wrote: > <blockquote TYPE=CITE>I'm working on designing a low level packet filter > on an FPGA. Since it > <br>needs run at very high speeds, which would be more advisable to use, > PLL > <br>or a DLL? > <p>-- > <br>Anshuman Sharma > <br>Georgia Institute of Technology</blockquote> > </html> > > --------------20355C97D5FCEB4DF06F691F-- > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27045
In article <8uaap3$gao$1@news.doit.wisc.edu>, qianz@cae.wisc.edu (Qian Zhang) wrote: > Here I have a signal-- REALCONTROL, > it changes at the rising clock cycle, > and if it changes, the next following clock cycle > other signals need to be changed correspondingly > so I use > elsif REALCONTROL'event then > CHANGEC:='1'; > elsif REALPHASE'event then > CHANGEP:='1'; > end if; > end process COUNTER_Gen; > However sysopsis told me > Checking... > Error L139/C0 : #0 Error: The 'event or 'stable attribute ( on line > 139 ) > is supported only when the attribute is used in conformance with the > style > described in the Synopsys manual for the VHDL compiler. (VHDL-2160) > 1 error(s) 0 warning(s) found > Can anyone do me a favor to tell me how to fix it? > Thank you very very much! Many features of VHDL are designed for simulation, and you are restricted in a synthesis context. Synthesis can only use 'event to infer clocks, so you need something like, signal last_control : std_logic; if CLK'event and CLK = '1' then -- infers a +ve clock if REALCONTROL /= last_control then CHANGEC <= '1'; else CHANGEC <= '0'; end if; last_control <= REALCONTROL; -- infers a register end if; -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 27046
Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qhbsvrhzm6.fsf@ruckus.brouhaha.com...
> Tim Jaynes <tim.jaynes@xilinx.com> writes:
> > Macros can only be used if you have a schematic flow-
> > If you had a supported schematic tool you could use them in an HDL flow
by
> > creating a netlist w/ hierarchical ports and instantiating that in your
code,
> > but as of now schematic entry in WebPACK only supports CPLDs.
>
> Does this mean that I can't use RAM in my VHDL designs when using
> WebPACK? That would seem like quite a limitation.
No, I have found two ways of using BlockRAM.
1. Inferring it -- write VHDL code that the compiler recognizes and turns
into a BlockRAM (if you're lucky). The WebPACK compiler turns this into a
512x8 single-port BlockRAM:
entity ent is
...
end ent;
architecture arch of ent is
type regfiletype is array (511 downto 0) of std_logic_vector (7 downto 0);
signal regfile : regfiletype;
signal file_we : boolean;
signal file_din : std_logic_vector (7 downto 0);
signal file_dout : std_logic_vector (7 downto 0);
signal file_addr : std_logic_vector (8 downto 0);
signal ra : std_logic_vector (8 downto 0);
begin
regfile_reg: process (clk)
begin
if rising_edge(clk) then
ra <= file_addr;
if file_we then
regfile (conv_integer(file_addr)) <= file_din;
end if;
end if;
end process;
file_dout <= regfile (conv_integer(ra));
end arch;
2. Instantiating a primitive. The compiler will warn about an unknown
macro, but it will turn it into a BlockRAM. I guess that the reason it
works is that RAMB4_S8 is a primitive and not a macro. I have only tried
instantiating the RAMB4_S8, but I suppose that you can instantiate all the
library elements mentioned as primitives at
http://toolbox.xilinx.com/docsan/3_1i/data/common/lib/chap02/lib02003.htm .
In this way you can also specify initialization values with INIT_0x
attributes.
entity ent is
...
end ent;
architecture arch of ent is
component ramb4_s8
port (
we : in std_logic;
en : in std_logic;
rst : in std_logic;
clk : in std_logic;
addr : in std_logic_vector (8 downto 0);
di : in std_logic_vector (7 downto 0);
do : out std_logic_vector (7 downto 0));
end component;
signal ram_we : std_logic;
signal ram_en : std_logic;
signal ram_rst : std_logic;
signal ram_clk : std_logic;
signal ram_addr : std_logic_vector (8 downto 0);
signal ram_di : std_logic_vector (7 downto 0);
signal ram_do : std_logic_vector (7 downto 0);
begin
U1: ramb4_s8 port map (ram_we, ram_en, ram_rst, ram_clk, ram_addr, ram_di,
ram_do);
end arch;
Regards,
Karl Olsen
Article: 27047Austin Lesea <austin.lesea@xilinx.com> wrote: >... DLL's do not filter out the input jitter, they pass it through. Is this really true ? Depending on how you decide to switch from tap to tap, you can filter the input jitter to a degree. Effectively it still depends on your loop filter which makes this decision. Muzaffer http://www.dspia.comArticle: 27048
Hi, I am developping an prototype board that is interfaced with PC-104 bus. It works well but after 5 minutes I begin to read 0xFFFF on my board and bizarre caracters appear on my screen.. Some bizarre caracters display when the PC is booting (without my program running) My board use 0x220 to 0x23F in I/O space with no interrupts. all my VCC and GND are connected with decoupling capacitors and unused pins (TIE) are connected to GND. Any hint for me? Thanks in advance Simon Bilodeau HTRC Paper Technologies.Article: 27049
prc wrote: > > I have a problem concerning the global buffers (BUFG) in a xc4062xla > fpga from xilinx. I have 2 clocks signals using them in a design (the > second clock is internal). I can see these buffers in the xnf netlist. > During Place & Route the design manager gives me a warning saying that > my internal clock is using non-dedicated resources. Are you using both edges of the clock? I found a bug with FPGA Express v3.4. If it sees that you are using both edges of the clock, it stupidly infers an CLB inverter on the clock, and runs that through a BUFGLS, whose output drives the flops clocked on the opposite edge. Since at that point, the tools think the clocks are unrelated, they complain about skew problems. The non-dedicated resource is the inverter in the CLB. FPGA Express should use the polarity-select mux that's part of EVERY flip-flop in the XLA part, but it doesn't. There's no work-around, except maybe going back to a previous version, or buying a real synthesis tool. V3.3 did not seem to have this problem. See http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10127 for Xilinx' lame answer. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."
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