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
Andy Peters <andy@exponentmedia.deletethis.com> writes: > Do yourself a favor, and don't directly use the Crystal > MCLK/LRCLK/BCLK/data outputs to drive a converter. Use a FIFO in > between, and generate your clocks locally. You'll cut the jitter down. I wrote: > And potentially introduce slips, since your sample rate may not match > the source. :-( Andy Peters <andy@exponentmedia.deletethis.com> writes: > No, you clock your incoming data into a FIFO, and you have a > local-generated clock on the read side that runs at the same frequency > as the recovered clock, but it's from an oscillator and not a PLL, so > the hope is that the jitter on the clock feeding your DAC (the only > place you really need to worry about jitter) should be lower. Oh. When you said "generate your clocks locally", I thought you meant a local oscillator completely asynchronous to the incoming data stream. Now a stupid question: Assuming that the incoming AES data stream is from a source with reasonable timing (i.e., crystal locked), why is generating a local clock with a PLL expected to have better jitter performance than the clock recovered from the AES stream? For instance, a CD player already times its output based on a crystal clock, by using a FIFO between the CD demodulator/decoder and the DAC & digital outputs. They servo the spindle motor speed to the FIFO depth, so with a reasonable FIFO size the motor speed control doesn't have to be extremely precise. Why would there be much more jitter in the digital output than you have if you used a PLL and FIFO to reclock the data at the receiving end?Article: 36001
Bertram Geiger wrote: > > > could anybody say me where to find a simple free GAL (especially 16V8) > > compiler for MS-DOS? > > > search for "easyAbel", might be its still somewhere around on the web or > ask on the university > Its simple and works fine up to 22v10 Looking into this, has good news There is a DOS c 1992 Abel, also called Ez-ABEL. it supports a ABEL subset, relevent today are 16V8/20V8/22V10 and bad news.. It gags on some newer ABEL files, seems it is a subset ABEL ( not surprising c 1992 :) It could still have uses, BUT the .PLA output files, from AHDL2PLA.EXE, are encrypted. If it could create readable PLA files, it could have a place in the tool box. Anyone know about getting usable PLA files, from this tool chain ? -jgArticle: 36002
Gunther May wrote: > > Hello, > > could anybody say me where to find a simple free GAL (especially 16V8) > compiler for MS-DOS? > > Thank you in forward, > Gunther May The ATMEL WinCUPL, has the CUPL engine in the /shared directory, and that runs from the DOS prompt / command line. This supports 16V8/20V8/22V10/750 and 150x via .PLA and fitters. I think it's 32 bit, so an ancient DOS may have problems? -jgArticle: 36003
Does anyone have experience debugging FPGA designs in BGA packages at the board-level? Since there are no pins, what have people found that works? Any ideas are greatly appreciated, including advice on DFT at the board level (unused I/O routed to test pins, SignalTap/ChipScope, etc.). Thanks, DonArticle: 36004
C A L L F O R P A P E R S THE TENTH ANNUAL IEEE SYMPOSIUM ON FIELD PROGRAMMABLE CUSTOM COMPUTING MACHINES Napa Valley, California April 21 - April 24, 2002 http://www.fccm.org Note the return to Napa Valley! For details, please visit our web site. PURPOSE: To bring together researchers to present recent work in the use of reconfigurable logic as computing elements. This symposium will focus primarily on the current opportunities and problems in this new and evolving technology for computing. Contributions are solicited on all aspects of custom computing, including but not limited to: Architecture of reconfigurable computing devices and systems, including coprocessors, attached processors, reconfigurable systems-on-chip and hybrids. Languages, compilation techniques, tools, and environments for programming and run time support; Applications of reconfigurable computing, including the use of reprogrammable logic in mobile communications, network infrastructure and other embedded systems; Implications of nanotechnology and reconfigurable computing on one another, possible forms, system implications; Novel use of reconfigurability, including evolvable hardware; Prototyping for system modeling and architecture emulation. SUBMISSIONS: FCCM has a tradition of presenting both full length papers and high quality posters. Authors are invited to send submissions for either full length papers (10 page maximum) or extended abstracts (2 page maximum) for posters by January 11, 2002, to Jeffrey Arnold. Please indicate whether you seek consideration as a full paper or as a poster. Notification of acceptance will be sent by the beginning of March. Final papers and poster abstracts will be due on the first day of the Symposium. The proceedings will be published following the Symposium. Authors are encouraged to submit PDF or Postscript manuscripts by FTP. Format and submission instructions are available on the FCCM web page (www.fccm.org), or authors can contact Jeffrey Arnold (jmarnold@znet.com). Authors are also encouraged to bring demonstrations of their work. Space will be made available during the demo event to be held Monday, April 22. Details will be available on the web page. SPONSORSHIP: The IEEE Computer Society and the Technical Committee on Computer Architecture. CO-CHAIRS: Kenneth L. Pocek Intel Mail Stop RN6-18 2200 Mission College Boulevard Santa Clara, California 95052 Voice: 408-765-6705 Fax: 408-765-5165 kenneth.pocek@intel.com Jeffrey M. Arnold Adaptive Silicon, Inc. 985 University Ave., Suite 31 Los Gatos, CA 95032 Voice: 408-335-2712 Fax: 408-899-8905 jarnold@adaptivesilicon.com PROGRAM COMMITTEE: Peter Athanas, Virginia Tech. Donald Bouldin, University of Tennessee, Knoxville Duncan Buell, University of South Carolina Michael Butts, Cadence Steve Casselman, Virtual Computer Corp. Andre DeHon, California Institute of Technology Apostolos Dollas, Technical Univ. of Crete Philip Friedin, Fliptronics Scott Hauck, University of Washington Brad Hutchings, Brigham Young Univ. Tom Kean, Algotronix, Ltd. Phil Kuekes, HP Labs. Philip Leong, Chinese University of Hong Kong Wayne Luk, Imperial College John McHenry, NSA Robert Parker, Institute for Information Sciences Viktor Prasanna, University of Southern California Herman Schmit, Carnegie Mellon University Mark Shand, Compaq System Research Center Satnam Singh, Xilinx Stephen Smith, QuickSilver Technology Roger Woods, The Queen's University of BelfastArticle: 36005
This is too much of a coincidence. I have two new topics in my
newsreader, one immediately after the other, both beginning with 2/3 and
totally unrelated to each other. They say anything will happen
eventually but today?
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
To contribute your unused processor cycles to the fight against cancer:
http://www.intel.com/cure
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////
Article: 36006Andy Peters <andy@exponentmedia.deletethis.com> writes: >glen herrmannsfeldt wrote: >> >> The original question asked about asynchronous logic, which doesn't >> have a metastability problem. Asynchronous logic, also called self >> timed logic, runs as fast as gates can change. Look up self-timed >> logic somewhere. >OK, so you've traded potential metastability in synchronous logic for >potential race conditions in asynchronous logic. >pick yr poison. I thought self-timed logic didn't have a race condition problem. Note that 'asynchronous logic' can have other meanings, including ones that have race conditions, so I prefer the term 'self-timed logic.' I believe that self-timed logic can't have race conditions. As previously stated, though, it is sensitive to glitches. If a gate input changes, but the gate output is independent of that change, the gate output should not glitch. An FPGA lookup table representing a gate with more than two inputs, does not necessarily have this property. I will try a simple description of self-timed logic, as it was explained to me about twenty years ago, and someone can correct it if I am too far off. Each signal has three states, normally represented with two wires. The third state is the indeterminate state, when the final value isn't yet known. It only goes to the final state when the final value is known, so no race conditions. Hysteresis is applied in the right place to eliminate race conditions, such that each signal must go through the indeterminate state before it can go to the final state. The result is that without a clock, and without race conditions, each output gets to its final value as fast as the signals can propagate through the logic. If a flip-flop goes metastable the rest of the logic waits until it goes to a stable state. A web search came up with: http://www.theseus.com/PDF/japan_paper.pdf which seems to have a reasonable description. -- glenArticle: 36007
Ray Andraka wrote: > YOu can buy a little more margin by synthesizing a 175 MHz clock enable > in the 350 MHz clock domain, then using that to effectively sample the > 175 MHz data in the middle of the sample. The synthesized clock enable > has to be synchronized to your 175 MHz clock, obviously. To do that, > sample your 175 MHz clock with the falling edge of the 350 MHz clock, > then retime that to the rising edge. These 2 flip-flops should be > floorplanned so that the delay between them does not exceed your allowed > time. This is a variation on what you are doing in alternative #2, > except here you have only one signal with the really tight timing. > > Another consideration is to either not use single ended I/O on the same > IO Bank as the clock. Single ended I/Os on the same bank seem to add a > considerable amount of jitter to the internal clock because of the I/O > rail fluctuations, especially for outputs. > > hamish@cloud.net.au wrote: > > 3. Generate an enable signal at 175 MHz and sample it using > > the falling edge of the 350 MHz. Same problem as #2, > > but with only 1-2 bits. I did try this, with hand placement > > of the FFs, and got the delay down to 1.41 ns, which is > > impressive (effectively over 700 MHz performance), but > > probably not enough. Using the enable signal, the data > > bits have a full 350 MHz period of setup and hold (less skew). Thanks for the suggestion. Actually, this is what I had tried in suggestion #3 (which I quoted above). It's my preferred solution, but the best I could do with hand-placement was 1.41 ns from rising(175) to falling(350) to rising(350), and after adding jitter, probably doesn't make 350. cheers, Hamish -- Hamish Moffatt Email: hamish_moffatt@agilent.com R&D Engineer, Phone: +61 3 9210 5782 (T210-5782) Advanced Networks Division Fax: +61 3 9210 5550 Agilent Technologies Web: http://www.agilent.com/Article: 36008
An EDA company is researching user's requirements for implementing DSP on FPGAs. If you have completed a signal processing design on FPGAs, or are now working on one, we'll pay you $100 to participate in a telephone interview. During the interview, we will ask you to discuss: * How many DSP on FPGA designs you have done * Why you chose to use FPGAs instead of standard DSP chips * What tools are you using and how well they are working * How current tools could be improved If you are interested, send an email to dsp@tactics.com with this information: * Your name * The phone number to reach you * The best time to reach you at that phone number If you have any questions, please feel free to send them to the same address. PLEASE DO NOT RESPOND ON THE NEWS GROUP! In return for your time and opinions, we will send $100 to all participants who complete the interview. We are an engineering market research firm that has been retained by an EDA company to help them develop new tools. Your opinions will be delivered straight to the team developing the new product. In the end, the result will be better tools that work the way you want them to. Thank you for your time.Article: 36009
Need some opinions: I've been using ISE3.1/FPGA Express on a PC. I'm about to upgraded to ISE4.1 but I'm not sure which way to go. There is a Solaris version, which would be great in many ways, but there is no FPGA Express for Unix, only XST. So, I'd like information on the performance of XST compared to FPGA Express. Thanks, DavidArticle: 36010
And how long is the inteview. If it is an all day thing (extreme example, I
know) it is hardly worth the stipend you are offering.
Dave Millman wrote:
> An EDA company is researching user's requirements for implementing DSP
> on FPGAs. If you have completed a signal processing design on FPGAs, or
> are now working on one, we'll pay you $100 to participate in a telephone
> interview.
>
> During the interview, we will ask you to discuss:
>
> * How many DSP on FPGA designs you have done
> * Why you chose to use FPGAs instead of standard DSP chips
> * What tools are you using and how well they are working
> * How current tools could be improved
>
> If you are interested, send an email to dsp@tactics.com with this
> information:
>
> * Your name
> * The phone number to reach you
> * The best time to reach you at that phone number
>
> If you have any questions, please feel free to send them to the same
> address. PLEASE DO NOT RESPOND ON THE NEWS GROUP!
>
> In return for your time and opinions, we will send $100 to all
> participants who complete the interview. We are an engineering market
> research firm that has been retained by an EDA company to help them
> develop new tools. Your opinions will be delivered straight to the team
> developing the new product. In the end, the result will be better tools
> that work the way you want them to.
>
> Thank you for your time.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 36011Hi - On 24 Oct 2001 02:18:47 GMT, gah@ugcs.caltech.edu (glen herrmannsfeldt) wrote: >Bob Perlman <bob@cambriandesign.com> writes: > >>You can build glitch filters with tapped delay lines and majority >>detection logic, but with an important caveat. These filters will >>eliminate pulses shorter than X ns and pass pulses longer than Y ns, >>but X and Y aren't the same number. In between X and Y, the circuit >>can misbehave; there's a range of pulse durations that can produce >>glitches at the output of the filter. > >>If there were such a thing as a perfect glitch filter, we could build >>a metastable-proof flip-flop by filtering out runt pulses. Were it >>that it were. > >The original question asked about asynchronous logic, which doesn't >have a metastability problem. Asynchronous logic, also called self >timed logic, runs as fast as gates can change. Look up self-timed >logic somewhere. I wasn't responding to the original question (this is Usenet, after all), but to the comment about building glitch filters from tapped delay lines. Nor was I claiming that self-timed logic was inherently susceptible to metastability. What do I think of self-timed logic? Read this: http://www.isdmag.com/editorial/2000/feedback0007.html Bob PerlmanArticle: 36012
Hi...
Device : XCV400E
Purpose: Xlinix In-system programming using an embedded micom...
I am in trouble..so I have some question.
I make a XSVF file from SVF file according to APPLICATION NOTE.
but XSVF file format doesn't use a program source.
Program source is described by ARRAY.
for example...
-------------------------
example ------------------------------------------------
const unsigned char dataFpga[] = {
255,255, 98,125,
22,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,2
55,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,2
55,255,255,255,255,
0, 0, 6, 34, 0, 0, 0, 98, 0, 34, 4, 0, 0, 0, 4, 98, 0, 34, 4,
0, 0, 0, 0, 98, 0, 98, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0,
0, 34, 0, 0, 0, 0, 0, 0,252,
0, 0, 0, 64, 0, 0, 0, 0, 0, 64, 2, 0, 0, 0, 2, 0, 0, 64, 2,
0, 0, 0, 0, 64, 0, 64, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 2, 0,
0, 64, 0, 0, 0, 0, 0, 0,152,
0, 0, 0, 0, 2, 64, 0, 0, 2, 0, 0, 64, 0, 64, 0, 0, 2, 0, 0,
64, 0, 64, 2, 0, 2, 0, 2, 0, 2, 64, 2, 64, 0, 0, 2, 64, 2, 0,
2, 0, 2, 64, 2, 64, 0, 0,252,
0, 0, 2, 66, 2, 64, 2, 64, 2, 64, 2, 66,
}
----------------------------------------------------------------------------
---------
I wanna that format.
I have used the MAX+ tool supporting that funtionality.
you know? How do I get the data?
APPLICATION NOTE say to me that most embedded processor development system
software automatically converts included binary files to the appropriate
format.
but Tornado(VxWorks)system including even ElftoHex funtionality doesn't have
that.
plz...help me...
Article: 36013On Thu, 25 Oct 2001 11:41:05 -0700, Austin Lesea <austin.lesea@xilinx.com> wrote: >Continuing, > >The max skew in a 2V6000 is 200 ps, but as Peter points out, smaller devices have >smaller skew in relation to their size. A 2V1000 is ~ .4 times less skew (~85 ps) >One can guess at the dimension ratio by examining the X by Y size of the CLB's >(96x88 vs 40x32, or .41 times less skew). Hi Austin, Is this skew between different loads on a single BUFG, or is that skew between different BUFGs? Is there any guaranteed value for skew between different BUFGs, given that those BUFGs are driven from the same DCM? Thanks, Allan. >Actual measurements confirms these values, but we tend to use the largest value in >the data sheet, rather than specify eveything per device. The per device >information is reserved for the speeds files when appropriate. > >In Virtex II we actually turn off parts of the clock tree that are unused, so there >is a major power savings if the 350 MHz clock tree is constrained to a local area >(perhaps using RLOC's). If all CLB's and IOB's can be localized, the power savings >is quite real. If everything must run at 350 MHz, you better invest in a serious >heatsinking solution! > >Use of clock enable saves less power, as everything is switching right up, and >including logic, into the heart of the CLB. > >Austin > >Peter Alfke wrote: > >> Here are some thoughts: >> >> hamish@cloud.net.au wrote: >> >> > In a design I'm working on at the moment, I have new data on every >> > rising edge of a 175 MHz clock and I need to transfer it to >> > be synchronous to a 350 MHz clock. No uncertainty in the >> > 350 MHz data is acceptable. >> > >> > To generate the clocks, I have an external 350 MHz source, >> > and I'm using the CLK0 and CLKDV (divided by 2) outputs on >> > a DCM. I'm using a Xilinx 2V6000-5. >> > >> > I have global buffers for each clock, but I expect there >> > will be some skew between the clocks, since the 350 MHz >> > clock is lightly loaded (200-300 FFs), compared to the >> > 175 MHz clock (2500 FFs). So I might violate the hold >> > time on the 350 MHz FFs if I'm not careful. >> >> I think the loading ( if it has any effect at all ) would help you: It would >> move the 175 MHz data a little later. When the source clock is late and the >> receive clock is early, you avoid all hold time issues, but you lose >> performance. So, no hold-time issues here. >> >> I would run everything off the 350 MHz clock and generate a 175 MHz clock enable >> off that clock, and use it for the "175 MHz" portion. >> Global clock distribution skew has always been good, but is very good in >> Virtex2. Count on less than 200 ps, perhaps even less than 100 ps. >> >> One obvious drawback to this suggestion of using 350 MHz clock for the many >> slower places, is increased power consumption. >> >> Peter Alfke >> >> > >> > >Article: 36014
Hi, From my experience, this book is very useful especially if eventually, you will use Xilinx FPGA. Introductory VHDL from Simulation to Synthesis by Sudhakar Yalamanchili. Best regards, Basuki E. Priyanto E-mail: basuki@ieee.org ICQ: 79534411 ________________________________________________ Don't judge the book from the cover :-----Original Message----- :From: Srinivasan Venkataramanan :[mailto:srinivasan@siliconsystems.co.in] :Posted At: Thursday, 25 October, 2001 6:09 PM :Posted To: fpga :Conversation: Recommend a book :Subject: Re: Recommend a book : : :Hi Adrian, : Try: : :Vhdl for Programmable Logic :by Kevin Skahill, : :ISBN: 0805895736 : :It is a great book for beginners in VHDL and has couple of chapters on :Programmable logic (which to be honest I skipped as I am in ASIC :domain). : :HTH, :Srinivasan : :-- :Srinivasan Venkataramanan :ASIC Design Engineer :Software & Silicon Systems India Pvt. Ltd. (An Intel company) :Bangalore, India, Visit: http://www.simputer.org) : : :"Noddy" <g9731642@campus.ru.ac.za> wrote in message :news:1003995752.528025@turtle.ru.ac.za... :> Hi, :> :> Could anyone give any advice as to which book to get to learn about :> programming FPGA's. I have Ashenden's 'The Designer's Guide to :VHDL'. This :> is good for learning VHDL, but isn't very instructive as to :programming :> FPGA's with VHDL. I have been designing only with schematics as it :is more :> intuitive than VHDL if you don't have much reference material. :> :> Thanks :> :> Adrian :> :> :> : :Article: 36015
On 25 Oct 2001 14:12:41 -0700, Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote: >Andy Peters <andy@exponentmedia.deletethis.com> writes: >> Do yourself a favor, and don't directly use the Crystal >> MCLK/LRCLK/BCLK/data outputs to drive a converter. Use a FIFO in >> between, and generate your clocks locally. You'll cut the jitter down. > >I wrote: >> And potentially introduce slips, since your sample rate may not match >> the source. :-( > >Andy Peters <andy@exponentmedia.deletethis.com> writes: >> No, you clock your incoming data into a FIFO, and you have a >> local-generated clock on the read side that runs at the same frequency >> as the recovered clock, but it's from an oscillator and not a PLL, so >> the hope is that the jitter on the clock feeding your DAC (the only >> place you really need to worry about jitter) should be lower. > >Oh. When you said "generate your clocks locally", I thought you meant >a local oscillator completely asynchronous to the incoming data stream. > >Now a stupid question: > >Assuming that the incoming AES data stream is from a source with reasonable >timing (i.e., crystal locked), why is generating a local clock with a PLL >expected to have better jitter performance than the clock recovered from the >AES stream? For instance, a CD player already times its output based on >a crystal clock, by using a FIFO between the CD demodulator/decoder and >the DAC & digital outputs. They servo the spindle motor speed to the >FIFO depth, so with a reasonable FIFO size the motor speed control doesn't >have to be extremely precise. Why would there be much more jitter in the >digital output than you have if you used a PLL and FIFO to reclock the >data at the receiving end? If we have a signal that has come from a clean clock, and it's already been through 1 PLL, why will adding another PLL make it better? The jitter / phase noise at the output of a PLL has two components. 1. There is intrinsic jitter. This is the jitter at the output that is present even when there is no input jitter. This will come mostly from the VCO. The feedback in the PLL will tend to suppress this jitter, but only within the loop bandwidth of the PLL. The PLL acts as a high pass filter for this jitter. 2. There is jitter transfer. This is the transfer function from jitter at the input to jitter at the output of a PLL. This will usually be approximately a 2nd order low pass filter response, with the cutoff freq at the PLL loop bandwidth. There's a zero as well, so it might approximate a 1st order lowpass over some of its (jitter) frequency range. Consider the clock recovery in the S/PDIF rx chip. (I guess) this will have an on-chip PLL using a ring osc or perhaps a DLL. These aren't particularly low noise devices. The loop bw will be fairly wide so that it can lock quickly and track incoming jitter. So the clock at the output of the rx chip can be expected to have some jitter on it, because (1) it's inherently noisy (because of the type of oscillator), and (2) it doesn't do much to suppress that noise (because of the wide loop bw). Consider the second PLL, the one we're putting on the output of the FIFO. It can use a VCXO as the oscillator. These can be made with incredibly low jitter (although you have to pay a lot for the really low noise ones). You can also make the loop bandwidth of this PLL (almost) arbitrarily low, so that the intrinsic jitter at the output is basically the same as the open loop VCXO jitter, and the jitter from the input clock is suppressed (at frequencies higher than the loop bw). I have to say that I've never built an S/PDIF interface, but I have designed a few ISDN and SONET/SDH interfaces. The jitter behaviour is much the same, even if the numbers are a bit different. Regards, Allan.Article: 36016
"David Rogoff" <david@therogoffs.com> schrieb im Newsbeitrag news:3d47gocr.fsf@therogoffs.com... > > Need some opinions: > > I've been using ISE3.1/FPGA Express on a PC. I'm about to upgraded to > ISE4.1 but I'm not sure which way to go. There is a Solaris version, > which would be great in many ways, but there is no FPGA Express for > Unix, only XST. So, I'd like information on the performance of XST > compared to FPGA Express. I used FPGA Express and Alliance3.1i on PC. I now did all my designs with FPGA Express 3.6.1 and ISE4.1i AND with XST and ISE4.1i. The XST synthesis maps better to xilinx technology and one design used "only" 66% LUTs instead of 81% with FPGA Express. The timing performance is the same. (In all cases my constraints were met. I can not tell you how the max. reachable frequency differs.) Design using the Xilinx PCI core with XST synthesis are very tricky since this flow is not officially supported by xilinx. But it's possible. Be aware that the XST synthesis has problems with tri-state IO buffers that are inferred in a hierarchical submodule. You have to allow XST to flatten the design to get error-free results. But ... it's free and it's good !! TobiasArticle: 36017
Ray Andraka <ray@andraka.com> wrote: > I know of no source for the old sw. You might find someone with a used copy, > but you'll have to make sure you get the dongle, and a valid license file. Dongle does not sound good. I don't want to spend a lot of time for looking for somebody with an old sw with dongle.Article: 36018
Hello, I've installed Xilinx Foundation v3.3.8 on Windows XP (as an experiment). I installed V3.1 first and then apply the Service Pack 8. If I install the MultiLNX cable support, Windows XP will boot up with a blue screen of error, and must be boot to "last known good configuration". (WinXP crashes at boot up - A problem has been detected and Windows has been shut down to prevent damage to your computer. ... Technical information: *** STOP: 0x0000007E (0xc0000005, 0xF78A8CB5, 0xF7AFB8C0, 0xF7AFB5C0).) If I install with only the parallel port support without MulitLNX, there is no problem. Are there anyone else with similar experience? Regards, Simon Leung The University of Queensland, Australia.Article: 36019
> the hope is that the jitter on the clock feeding your DAC (the only > place you really need to worry about jitter) should be lower. I don't feed the signal to a DAC :-) It's going to a noiseshaper and then a PWM. (And a 'swiching' poweramp after that, so the audio stays 'digital' until a LP in front of the speaker) The jitter thing is kinda 'religiously' theme for some audio people. But for me, it's ok as long the jitter (to the 'DAC') stays withing (the equal to) 1/2 - 1 LSB of my signal. )RST(Article: 36020
Don Stauffer wrote: > Does anyone have experience debugging FPGA designs in BGA packages at > the board-level? Since there are no pins, what have people found that > works? Any ideas are greatly appreciated, including advice on DFT at > the board level (unused I/O routed to test pins, SignalTap/ChipScope, > etc.). > > Thanks, > DonArticle: 36021
Hi, I suggested that you learn about the JTAG interface of IC's. A good place to start is the texas instruments web site (www.ti.com) and look for the downloadedable book ' The JTAG Primer' there. Ben Don Stauffer wrote: > Does anyone have experience debugging FPGA designs in BGA packages at > the board-level? Since there are no pins, what have people found that > works? Any ideas are greatly appreciated, including advice on DFT at > the board level (unused I/O routed to test pins, SignalTap/ChipScope, > etc.). > > Thanks, > DonArticle: 36022
Hi I am in the process of purchasing ILA CHIPSCOPE DEBUG KIT (with MULTILINX cable) and was wondering what type of connector I need to design into the board? I assume this uses the JTAG port. Is there a recommended JTAG connector or is a convential non-shrouded header acceptable?? I would also like to get some feedback from users of ILA CHIPSCOPE. Thanks in advance BillArticle: 36023
Hey all. Does Foundation 4.1ISE support any more devices than Foundation 3.1I + SP8 (or whatever the latest service pack is)? What are the feelings on XST synthesis vs. Synplicity Synplify Pro 6.24? Thanks, VR.Article: 36024
Hi everybody.
At first, i thanks the person who send me a answer about mixing two
clk.
My problem is :
I've written a generic code vhdl and I have wanted to transform it to
use the characterics about XILINX FPGA.
I have used the IOPAD about I/O from chips. But when I want to
generate Post-Map Simulation Model, I have the following error message
:
ERROR:NgdBuild:466 - bidirect pad net 'd<0>' has illegal connection
I use the WEBPACK XILINX VERSION 4.1
Anybody can help me ?
Thanks.
Olivier.
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