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
Do Xilinx synthesis tool support std_logic_signed / unsigned? Björn LindegrenArticle: 21001
Bob Baman wrote: > > Ray, > > Since you are in the subject of optimization, how is fmax affected for > better or worse by FPGA Express versus Synplify synthesis? fpga_express doesn't even take fmax into account when it does it synthesis. Synplicity does. -- David W. Bishop INTERNET: dbishop@vhdl.org ( \ ) US MAIL: Hilton NY 14468-9101 A Long time ago, \__\/ PHYSICAL: 43:17:17N 77:47:37W 281' In a Galaxy far, far away... | | For Supernova info: http://www.ggw.org/asras/snimages | | For VHDL/Synthesis info: http://www.vhdl.org/siwg _/___\_ All standard disclaimers apply. [_______]Article: 21002
Hi. Would anyone know the intricate details of how the Delay-Locked Loop (DLL) in Virtex devices is implemented? Is it asynchronous using a tapped-delay line? Aside from the appnote (xapp132) and general DLL information in the Xilinx databook, I couldn't find anything more specific. I am very interested in building a DLL, but if not possible, at least gain a very good understanding of this new device. I thought I would start with xilinx since they have already implemented it in their FPGAs. I would greatly appreciate any information on the topic of DLLs, including any recent references on the subject. Thanks in advance to all who can help. NestorArticle: 21003
Björn Lindegren wrote in message
<8AAv4.3428$yw1.7286@nntpserver.swip.net>...
>Do Xilinx synthesis tool support std_logic_signed / unsigned?
FPGA Express does ('cause it's a Synopys product). however, you shouldn't
use those libraries.
--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 21004Harald Simmler wrote: > > Hi > > I have a design where 4 ORCA 3T125 chips communicate together > ( programmed in VHDL ). All four designs should run at arond 20 MHz. > At least the P&R tools calculates that frequency on internal delays. > > But the highest frequency on the board is only 8MHz. > The FPGAs are directly connected by wires, so I think that this > should not be the problem. I think that the PIO blocks which are > programmed as input add an delay block at the > input ( per default ? ) which has to be added to the internal > tPD. And the output is set to slow ( also per default ? ). > > Has anyone an idea what reduces the frequency and does anyone > know how to disable the input delay or change the settings for the PIO > blocks during P&R ( constrains in the CHDL code or in a constrains file > )?? > > Any help is needed. > Thanks in advance. > > H. Simmler I would agree with Peter's comment that the input delay should not be the cause of your problem. Also, this delay is only added when you are using the input FF in the PIC (IOB in Xilinx terms). You did not say anything about your design. This is very possibly the cause of your problems. By working in VHDL, you may well have a great deal of logic in the input or output paths. This is much more likely the cause of your problem. You should be using timing constraints on your design on both internal paths as well as input and output paths. Lucent has recently improved the utility of the input format for timing constraints so that this is much easier to do. I believe that the current version of the back end tools (Foundry) is 9.4. I am still using 9.35 which has the same capability, but uses an intermediate file for some forms of constraints. If you don't have version 9.4, I suggest that you get it. It should be much easier to use in this regard. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21005
Don Husby wrote: > > Ray Andraka <randraka@ids.net> wrote: > > I thought the point to using a DLL was to get away from the analog circuit. > > Speculating about the Lucent chip, I think they chose a tapped-delay DLL/PLL > because it uses the best features of an analog/digital implementation. > The tapped delay allows a coarse adjustment while allowing the analog > part to operate with a small dynamic range. The analog can then > be implemented in a standard digital process. Since it's in the feedback > path, it doesn't have to be terribly linear, and it's probably just as > tolerant of power and temperature fluctuations as a strictly digital DLL. > Since the analog provides a fine adjustment, the digital part can have > fewer taps (32), and doesn't have to spend a lot of effort on keeping > individual tap delays within a tight tolerance. > > -- > Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby > Fermi National Accelerator Lab Phone: 630-840-3668 > Batavia, IL 60510 Fax: 630-840-5406 I am jumping into this thread rather late, but I think the point of the DLL is not the taps themselves, but that they can be used without a VCO. Is that correct? If you still have a VCO it seems to me that you don't get rid of all of the analog circuitry. I also don't think that tolerance is a problem with the digital delay taps. I expect that they don't have to be held tightly to an exact value, but they simply need to be kept to a small value to allow fine adjustments. These delays are in the feedback path and any tolerance variation would be corrected for just like an analog non-linearity. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21006
You could try the IBM patent server http://www.patents.ibm.com - Try ((delay) AND ( (Xilinx) <in> PA)) in the search field. US05815016 looks like a possible implementation. Also try searching just for (delay locked loop). This returned 82 matches, many of which look relevant. regards, tom Nestor wrote: > > Hi. > > Would anyone know the intricate details of how the Delay-Locked Loop (DLL) > in Virtex devices is implemented? Is it asynchronous using a tapped-delay > line? Aside from the appnote (xapp132) and general DLL information in the > Xilinx databook, I couldn't find anything more specific. > > I am very interested in building a DLL, but if not possible, at least gain a > very good understanding of this new device. I thought I would start with > xilinx since they have already implemented it in their FPGAs. I would > greatly appreciate any information on the topic of DLLs, including any > recent references on the subject. > > Thanks in advance to all who can help. > > Nestor -- Tom Burgess -- Digital Engineer Dominion Radio Astrophysical Observatory Penticton, B.C. Canada V2A 6K3Article: 21007
Rickman wrote: > > > I also don't think that tolerance is a problem with the digital delay > taps. I expect that they don't have to be held tightly to an exact > value, but they simply need to be kept to a small value to allow fine > adjustments. These delays are in the feedback path and any tolerance > variation would be corrected for just like an analog non-linearity. > > -- > The issue is the amount of jitter. A purely digital VCO will never be right on frequency, and the delay of each stage will vary with temperature and voltage. This must be continuously adjusted, since the timing error would be cumulative. So you would end up with a lot of jitter = one stage delay, almost each clock period. This would be so ugly that, to my knowledge, nobody uses a purely digital PLL. A mixed digital/analog VCO would be less ugly, but what does it do when the analog correction has reached its limit and demands a digital step correction? How fast can the analog circuit correct the new and different digital delay? During the time of adaption, there is a large phase error = jitter. Interesting subject. Peter AlfkeArticle: 21008
Hi I am looking for 1st-hand comment from users of Atmel AT40K FPGA tools and devices. - What are the shortcomings? - How does it compare to eg. Xilinx? - How does architecture rate compared to other FPGA offerings out there? - What is the "sweet-spot" in terms of price, performance,etc? - Any other observations / tips appreciated Thanks for all your input Pete FennArticle: 21009
My stock answer: It depends on the application. The 40K's Achilles heel is the fact it has no fast carry logic. That really cripples its arithmetic performance/density when compared to Xilinx. If you don't need a carry chain (unfortunately, I can only think of a few applications that don't benefit there), it's not all that bad a device. I truthfully have not looked at their software in a few years. I would hope that it has been improved. Previously they were using Figaro, which was dreadfully slow, especially when you tried to do any edits. I think they still give away the software for free. You might test drive it to see what you think. Peter Fenn wrote: > Hi > I am looking for 1st-hand comment from users of Atmel AT40K FPGA tools and > devices. > - What are the shortcomings? > - How does it compare to eg. Xilinx? > - How does architecture rate compared to other FPGA offerings out there? > - What is the "sweet-spot" in terms of price, performance,etc? > - Any other observations / tips appreciated > > Thanks for all your input > Pete Fenn -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21010
On Thu, 2 Mar 2000 19:54:19, gzs@clark.net (George) wrote: > > I have a multi-clock design I am doing in a Virtex XCV1000 device. > All four global clock inputs are used and the I/O bank where one of > the clock inputs enters the chip is SSTL2. Xilinx tells me to make > the clock be an SSTL2 signal. This is no problem. The FAE also tells > me that I should not try to use this particular clock to clock any of > the internal logic of the device, only the IO pads of the banks which > are also SSTL2. > > This is very hard for me to believe. Does anyone know of any type of > restriction on the uses of the global clocks depending on the Select > IO types used for the clock inputs? If this is true I'm truely screwed! I'd like a clarification here too. I'm using LVPECL clock generators and am planning to use these clocks for the entire chip. Note that I am playing games with the clocks because I couldn't get Virtex-E parts on a reasonable schedule. If these games come back to bite... ---- KeithArticle: 21011
I'll admit to being a novice at FPGA/s and Xilinx in particular, but I can't have missed this much. I'm doing a board with a SpartanXL (XCS40XL-256BG) part and a Virtex (will go to -E when I can get them). I'm using Synplify as the design tool and then into Alliance. Alliance is taking *forever* to to Place-N-Route. I started with a 56% or so full device (both Synplify and Alliance agreed within reason) and then went to wire. After *hours* it gave up saying that I had hundreds of un-routed nets. After tweaking the design (it was very crude) down to where I now have less than 25% used, it still takes *hours* to P&R with rather unsatisfactory results. I have to put it through the re-entrant roter to get it to wire at all. I left affter two hours of this today (it's a PII-333 running NT). This is a *simple* design. 1) What the hell am I doing wrong? Is this normal? 2) If I can extrapolate this to my Virtex (XCV600-FG680, btw) design, I'll grow foot-long fingernails waiting for routing (if I don't bite them off first). Is Spartan not routable? Is Virtex better? (good grief, I hope so!) 3) Can I make simple changes (pinouts and such) without re-routing completely? 4) Or, am I all wet, and pushing the wrong buttons? It would be nice to be able to tell Alliance to use the re-entrant router from the beginning, and then go home. Oh, my head hurts! I've had full head of grey hair for 20 years, but me think's it's coming out now! ---- KeithArticle: 21012
Peter Alfke <peter@xilinx.com> wrote: >The issue is the amount of jitter. A purely digital VCO will never be right on >frequency, and the delay of each stage will vary with temperature and voltage. >This must be continuously adjusted, since the timing error would be cumulative. So >you would end up with a lot of jitter = one stage delay, almost each clock period. > >This would be so ugly that, to my knowledge, nobody uses a purely digital PLL. I don't think this is true. There are pure digital ways of subdividing the delay of a single stage. I have seen at least two papers relating to this subject. The idea is to control the rise time of a signal in one of the stages. One way to do this is to have a very large load at the output of multiple tri-state drivers. The more drivers you enable the faster the rise time. This can be implemented with a standard cell library and can be characterized with spice after AP&R. Look at recent ISSCC papers.Article: 21013
Hi Steve, The information given in XAPP131 is correct. The comments refer to the FALLING edges of the Empty and Full flags, i.e. the Empty signal may stay high (empty) for one more clock cycle after the first word has been written to the FIFO. However, the same does NOT apply to the rising edges. In other words, the Empty flag will always be high when the FIFO is actually empty but it may delay flagging the non-empty status by one clock cycle. Hope this helps, Manfred Kuhland ------------------------------------------------------------------------ Atlantek Microsystems Pty Ltd, Innovation House, Technology Park, Mawson Lakes, SA, 5095, AUSTRALIA Tel: +61-8-8260-8990 Fax: +61-8-8349-4286 E-mail: man@atlantek.com.au Internet: http://www.atlantek.com.au ------------------------------------------------------------------------ Steve Charlwood wrote: > Hi all, > > I'm using a FIFO design based on Xilinx's synchronous FIFO with > independent clocks, described in XAPP131. In this, it states that in the > worst-case scenario (due to the asynchronous nature of the READ and > WRITE clocks), the FULL and EMPTY flags would simply stay active one > cycle longer and that this would _not_ generate an error. > > I have a simulation in which EMPTY goes low, indicating that there is > data to be read from the FIFO, and then, due to the clock edges from the > two different domains coinciding, the signal is forced into an unknown > state, which could be high or low. In the case where the signal is > actually interpreted as low, the FIFO would indicate that it was not > empty, when in fact it might be. This causes a problem when trying to > read data from the FIFO using the EMPTY signal as the read enable: for > each occurence, and additional word may be inserted into the data > stream. > > Does anyone know of a solution to this problem (apart from avoiding the > use of multiple clock domains!). > > Cheers, > > Steve > > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > Heterogeneous, Parallel & Reconfigurable Architectures Group > School of Electronic & Electrical Engineering > University of Birmingham, Edgbaston, Birmingham, B15 2TT > e-mail: s.m.charlwood@bham.ac.uk > tel: +44 (0)121-414-4340 (shared)/fax: +44 (0)121-414-4291 > > Signal Processing & Imagery Department > Defence Evaluation & Research Agency (DERA) > DERA Malvern, St. Andrews Road, Malvern, Worcs., WR14 3PS > e-mail: charlwood@signal.dera.gov.uk > tel: +44 (0)1684-895452 (shared)/fax: +44 (0)1684-894389 > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/Article: 21014
I just got back a board the other day with a Virtex XCV50FG256-4 FPGA running largely at 40 MHz... And I'm using most of the available 180 user i/o. The thing that always mistified me about the decoupling of the device was simply the number and size of the caps. Xilinx recommends a total of 10 47uF low ESR Tantalum caps as well as a 470uF tantalum to decouple the Vccint and Vcco power pins of the device... as well as a 0.1uF cap per Vccint and Vcco pin as I recall... Well as some of you might also be experiencing, I'm having trouble finding *any* tantalum caps in the footprint that I needed for this design, so I decided to try and bring up the board without any of the 10 47uF caps and also without the 470uF cap. I only had the 0.1uF caps in house to populate the board. Turns out that the design appears to work flawlessly without any of these decoupling caps and I'm standing here wondering why I sacrificed board space for all of these damn caps... I see very little (if any) ground bounce or ripple on the power planes... Just some advice for those of you attemping similar designs... m Matt Billenstein 2373 Rohs Street Cincinnati, OH 45219 Home: 513-651-2376 Work: 513-573-6832 http://w3.one.net/~mbillens/ mbillens@one.netArticle: 21015
"Keith R. Williams" wrote: > Alliance is taking *forever* to to Place-N-Route. > I started with a 56% or so full device (both Synplify and > Alliance agreed within reason) and then went to wire. After > *hours* it gave up saying that I had hundreds of un-routed nets. > After tweaking the design (it was very crude) down to where I now > have less than 25% used, it still takes *hours* to P&R with > rather unsatisfactory results. I have to put it through the > re-entrant roter to get it to wire at all. I left affter two > hours of this today (it's a PII-333 running NT). This is a > *simple* design. > 1) What the hell am I doing wrong? Is this normal? Without looking at your design I can't be sure of exactly what you are doing wrong, however it seems too common that the first FPGA design turns into this sort of disaster. What I suspect is that you have logic that needs some restructuring and I suspect you probably need to do a little floorplanning. After doing one or both, your run time will be much shorter. > 2) If I can extrapolate this to my Virtex (XCV600-FG680, btw) > design, I'll grow foot-long fingernails waiting for routing (if I > don't bite them off first). Is Spartan not routable? Is Virtex > better? (good grief, I hope so!) The Virtex is rather more routable. You still may need to floorplan to improve the design's speed. > 3) Can I make simple changes (pinouts and such) without > re-routing completely? It is probably best to re-route every time. > 4) Or, am I all wet, and pushing the wrong buttons? It would be > nice to be able to tell Alliance to use the re-entrant router > from the beginning, and then go home. You can write a simple batch, make or script file that will do a re-entrant route from the beginning. I don't know how to do this from the GUI. -- Phil Hays "Are you willing to vote for funding the completion of the third report of the IPCC"? Ask the question!Article: 21016
I was following an earlier thread on multipliers IIRC that used a lot of non ripple adders. In this type of application, wouldn't the Atmel parts do well since they are a finer grained architecture? They should be able to provide more bits for the buck since they have a simpler structure and lend themselves well to an ordered array with direct interconnect. Again, IIRC systolic or array logic is about the only area where they show well. Ray Andraka wrote: > > My stock answer: It depends on the application. > > The 40K's Achilles heel is the fact it has no fast carry logic. That really > cripples its arithmetic performance/density when compared to Xilinx. If you > don't need a carry chain (unfortunately, I can only think of a few > applications that don't benefit there), it's not all that bad a device. I > truthfully have not looked at their software in a few years. I would hope > that it has been improved. Previously they were using Figaro, which was > dreadfully slow, especially when you tried to do any edits. I think they > still give away the software for free. You might test drive it to see what > you think. > > Peter Fenn wrote: > > > Hi > > I am looking for 1st-hand comment from users of Atmel AT40K FPGA tools and > > devices. > > - What are the shortcomings? > > - How does it compare to eg. Xilinx? > > - How does architecture rate compared to other FPGA offerings out there? > > - What is the "sweet-spot" in terms of price, performance,etc? > > - Any other observations / tips appreciated > > > > Thanks for all your input > > Pete Fenn > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21017
Matt Billenstein wrote: > > I just got back a board the other day with a Virtex XCV50FG256-4 FPGA > running largely at 40 MHz... And I'm using most of the available 180 user > i/o. The thing that always mistified me about the decoupling of the device > was simply the number and size of the caps. Xilinx recommends a total of 10 > 47uF low ESR Tantalum caps as well as a 470uF tantalum to decouple the > Vccint and Vcco power pins of the device... as well as a 0.1uF cap per > Vccint and Vcco pin as I recall... Well as some of you might also be > experiencing, I'm having trouble finding *any* tantalum caps in the > footprint that I needed for this design, so I decided to try and bring up > the board without any of the 10 47uF caps and also without the 470uF cap. I > only had the 0.1uF caps in house to populate the board. Turns out that the > design appears to work flawlessly without any of these decoupling caps and > I'm standing here wondering why I sacrificed board space for all of these > damn caps... I see very little (if any) ground bounce or ripple on the > power planes... Just some advice for those of you attemping similar > designs... > > m > > Matt Billenstein > 2373 Rohs Street > Cincinnati, OH 45219 > Home: 513-651-2376 > Work: 513-573-6832 > http://w3.one.net/~mbillens/ > mbillens@one.net Hey, if some is good and more is better... then too much is just enough! If they (Xilinx) don't know what you are putting in the chip, then they really can't tell you how to decouple it. So they are very conservative in saying to use lots and lots of microfarads. There was a thread here a few weeks ago on this very topic. I believe there was a reasonable concensus that the app notes are a bit of overkill. In particular, I have read some good app notes from the cap manufacturers as well as an article in EDN or Electronic Design IIRC, that discussed decoupling in great detail. It had a lot of eye opening info for me that I had never heard before. For example, at the frequencies of interest (typically > 100 MHz even for designs with slow clocks) all caps, including the high freq ceramics, are inductive! But that does not matter as long as the impedance is still low. With a lot of ceramic caps around the power plane, the effective impedance can be quite low. The tantalum caps that everyone uses on their boards are really only needed for low frequency effects and placement largely does not matter (unless you are using traces for power instead of power planes). So the dozen or so that Xilinx is recommending will most likely never be needed. One poster discussed a unique design method that isolated regions of the power plane (not the ground plane) to form "islands" of noise isolation. One ceramic cap per island was enough to do the job according to the theory. I would like to learn more about this technique, but I don't have the time just now to write to the professor that was listed as a resource. My current method is to use a 0.1 uF ceramic cap on each power/gnd pin pair. I keep the leads fanatically short and never use a cap for more than one chip although I sometimes connect two adjacent pins to one cap. It seems to work well so far. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21018
Keith R. Williams wrote: > I'll admit to being a novice at FPGA/s and Xilinx in particular, > but I can't have missed this much. I'm doing a board with a > SpartanXL (XCS40XL-256BG) part and a Virtex (will go to -E when I > can get them). I'm using Synplify as the design tool and then > into Alliance. Alliance is taking *forever* to to Place-N-Route. > I started with a 56% or so full device (both Synplify and > Alliance agreed within reason) and then went to wire. After > *hours* it gave up saying that I had hundreds of un-routed nets. > After tweaking the design (it was very crude) down to where I now > have less than 25% used, it still takes *hours* to P&R with > rather unsatisfactory results. I have to put it through the > re-entrant roter to get it to wire at all. I left affter two > hours of this today (it's a PII-333 running NT). This is a > *simple* design. > > 1) What the hell am I doing wrong? Is this normal? Please check if there is any patch available in Xilinx. Search Xilinx on-line documents carefully. There might be information regarding XCS40XL-BG256. Please post to the newsgroup, the condition, where the tool runs mostly. For example, a few months ago, an engineer told here that when the tool is trying to route PWR/GND signals it is found it takes too much time to route PWR/GND. AFAIK it is found that PWR/GND distribution has to be done per module basis or not from the same sources. The engineer had given us the place of the report where the tool runs mostly. Have you given UCF correctly? You must give: - clock constraints - offset constraints - multiple clock domain constraints Sometimes forgetting these parameters by unchance might lead excessive routing times. > 2) If I can extrapolate this to my Virtex (XCV600-FG680, btw) > design, I'll grow foot-long fingernails waiting for routing (if I > don't bite them off first). Is Spartan not routable? Is Virtex > better? (good grief, I hope so!) Virtex and Virtex-E devices have very rich routing resources. Some engineer told here that he achieved more than 90% routing resource usage of Virtex. I know another engineer personally who showed me that their team have successfully used 94% routing resources of Virtex XCV1000. > 3) Can I make simple changes (pinouts and such) without > re-routing completely? Probably no. > 4) Or, am I all wet, and pushing the wrong buttons? It would be > nice to be able to tell Alliance to use the re-entrant router > from the beginning, and then go home. As Phil stated, "make" under UNIX might help you very much. There is no way in GUI to perform batches. It is a must to get rid of GUI to perform batch for these tools. > Oh, my head hurts! I've had full head of grey hair for 20 years, > but me think's it's coming out now! Hope this helps. Utku -- I feel better than James Brown.Article: 21019
Phil Hays <Spampostmaster@sprynet.com> wrote in message news:38BCA455.75197C0B@sprynet.com... > henry wrote: > > > i was wondering if a delay line could be made easily in an fpga and if so > > are there any > > limitations ie. max delay, max frequency. > > The main limitation is accuracy. A range exceeding three to one should be > expected over process, temperature and voltage. Example: if the longest delay > is 30 ns, the shortest would be less than 10 ns. > > A better way to handle the same problem is a digital delay of some sort. > Perhaps a high frequency clock runs a counter for the number of cycles that > makes up the delay. > > > -- > Phil Hays thanks for all the replies, chears henryArticle: 21020
Why can't we use it?
Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in message
news:89mnlc$13nf$1@noao.edu...
> Björn Lindegren wrote in message
> <8AAv4.3428$yw1.7286@nntpserver.swip.net>...
> >Do Xilinx synthesis tool support std_logic_signed / unsigned?
>
> FPGA Express does ('cause it's a Synopys product). however, you shouldn't
> use those libraries.
>
>
> --
> -----------------------------------------
> Andy Peters
> Sr Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) noao \dot\ edu
>
> "Money is property; it is not speech."
> -- Justice John Paul Stevens
>
>
>
Article: 21021You might want to look around in Texas Instruments web site for app notes on line drivers and transmission theory. http://www.ti.com/cgi-bin/sc/search.cgi I'm in no way connected to TI. Its just that they had some really good app notes in this area. regards Jerry Sherdyn wrote: > It may not be appropriate to pose this question here but I do hope that > someone may be able to tell me what would be the maximum transmission rate > for a 1 meter ribbon cable length distance. > > sherdynArticle: 21022
Rickman <spamgoeshere4@yahoo.com> wrote: > I am jumping into this thread rather late, but I think the point of the > DLL is not the taps themselves, but that they can be used without a VCO. > Is that correct? If you still have a VCO it seems to me that you don't > get rid of all of the analog circuitry. Instead of a fully-analog VCO, the lucent chips implement a Voltage-Controlled delay line. Again, this seems to offer the best of both worlds: Tap selection sets the coarse frequency- easy to implement becuse there are fewer taps, and you don't need to match path delays to the nearest picosecond. Fine adjustments are made within a limited linear range- easy to implement because you can implement it with the same transistors that you use for the digital part. You don't need to use extreme analog design rules. > I also don't think that tolerance is a problem with the digital delay > taps. I expect that they don't have to be held tightly to an exact > value, but they simply need to be kept to a small value to allow fine > adjustments. You have to make sure that the delay from tap N is not greater than the delay from tap N+1. If you're talking a few picoseconds per tap, and hundreds of taps, this is not easy. > These delays are in the feedback path and any tolerance > variation would be corrected for just like an analog non-linearity. Not true. See above. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 21023
Keith R. Williams wrote in message ... > >I'll admit to being a novice at FPGA/s and Xilinx in particular, >but I can't have missed this much. I'm doing a board with a >SpartanXL (XCS40XL-256BG) part and a Virtex (will go to -E when I >can get them). I'm using Synplify as the design tool and then >into Alliance. Alliance is taking *forever* to to Place-N-Route. > I started with a 56% or so full device (both Synplify and >Alliance agreed within reason) and then went to wire. After >*hours* it gave up saying that I had hundreds of un-routed nets. >After tweaking the design (it was very crude) down to where I now >have less than 25% used, it still takes *hours* to P&R with >rather unsatisfactory results. I have to put it through the >re-entrant roter to get it to wire at all. I left affter two >hours of this today (it's a PII-333 running NT). This is a >*simple* design. > >1) What the hell am I doing wrong? Is this normal? > How much memory does your machine have? I had a design that fit nicely in a 4085 that could not complete the route before the MTBF of the machine with 256M of memory, but routed in about an hour on a machine with 1024M of memory... (ouch, $$$) Monte <snip>Article: 21024
Thanks. I am looking at it right now. Nestor -- > You could try the IBM patent server http://www.patents.ibm.com - > Try ((delay) AND ( (Xilinx) <in> PA)) in the search field. > US05815016 looks like a possible implementation. Also try searching > just for (delay locked loop). This returned 82 matches, many of which look > relevant. > > regards, tom > > -- > Tom Burgess > -- > Digital Engineer > Dominion Radio Astrophysical Observatory > Penticton, B.C. Canada V2A 6K3
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