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, Thanks for lending a sympathetic ear to my cause here! I did check the IOB in the FPGA editor and the signal is routed through a delay element as expected. On an another note-; So, you are responsible for the service packs Xilinx puts out, I suggest you stop finding bugs because I can't keep up with all this service packs......by the time I install SP#xxx, SP#xxx+1 is allready out! jakab Andy Peters wrote: > Jakab, > > I've always found that when I need to be clear on what the tools are > REALLY doing, I open the design in FPGA Editor. If have a concern > regarding whether the input NODELAY attribute got used, I look at that > IOB and I get my answer immediately. > > As far as Xilinx tech support, most of my recent calls to them have > involved things like, "I've found a bug in the tool. It's repeatable. > Please fix it." > > -andy > > Jakab Tanko wrote: > >> I really dont't want to get into this again, but just for arguments >> sake;- >> If you are so sure that the software implements that >> stinking attribute then why is it that the timing analyser >> shows me a setup time of 9ns and why did you say >> in one of your replays that , and I quote: >> "I have discovered that the timing report will not give a very clear >> picture >> as to whether the NODELAY attribute took effect.".............. How >> can that >> be????. The timing analyser is not working or the attribute did not >> take >> effect???Which one is it? >> Best regards, >> jakab >> >> Kamal Patel wrote: >> >>> Since I was the engineer working on this case I would like to >>> clear things up. I apologize, Jakab, for not being able to find >>> out what the issue with your software was, but after verifying >>> that the constraint was accepted in your design on my machine, >>> I can state for sure that the Alliance tool does not refuse to >>> implement this attribute. You will see the NODELAY attribute >>> for the register in your MAP report as you say you did. To verify >>> it was indeed implemented, you can look into the IOB in FPGA >>> Editor to see if the signal is routed through a delay element or >>> not. >>> >>> I offered you the opportunity for me to guide you through the steps, >>> >>> and only closed the case upon your request. I can re-open it for >>> you at any time if you are not satisfied with my service. Please >>> do not let our miscommunication reflect on all of Xilinx Support. >>> >>> Thank you for your time. >>> >>> Jakab Tanko wrote: >>> >>>> Just a note on Xilinx support;- I had a problem recently with >>>> an 4000xla type device NODELAY attribute for some critical >>>> inputs on my design. The problem was (and still is) that the >>>> Alliance >>>> tool refuses to implement this attribute; it is all good up to the >>>> mapper >>>> but on the next step which is the PAR, the attribute is not there >>>> anymore. >>>> Now, you would think that this is a pretty-strait-forward, >>>> specific problem >>>> that should be a no-brainer for a Xilinx application engineer.. >>>> but not so fast;- after 4 days of trying to get the Xilinx support >>>> to give me >>>> an answer I simply gave up...It seems to me that they have a >>>> two-tier system >>>> where you get the top-notch support if you pay for it, but if you >>>> just "another >>>> customer" then you get the co-op student to solve your problems >>>> and you might as well >>>> try to solve them yourself, >>>> But again this is just my oppinion and I could be wrong, >>>> jakab >>>> >>>> Peter Alfke wrote: >>>> >>>>> serebr@my-deja.com wrote: >>>>> >>>>>> It's permanent trade-off: Xilinx provides instant and very high >>>>>> quality >>>>>> support but Altera's devices are mostly available in stock >>>>>> (I mean in comparison with the Spartan-II availability). >>>>>> >>>>> Thanks for the friendly words about Xilinx support. >>>>> And regarding availability: >>>>> Please don't give all of Xilinx a black eye for the very special >>>>> situation with >>>>> Spartan-II. We expect that to clear up very soon. Let me tell >>>>> you, there is no >>>>> lack of attention on this case ! >>>>> Peter Alfke >>>>>Article: 29276
I agree with most of what the others have said. You should note that a ray tracer like POVRAY spends almost all its time doing a very simple intersection calculation (does the current ray intersect X ?). The amount of time spent doing subsequent calculations is usually of little consequence - all the effort goes into the initial pruning, and this is where you can get the biggest gains. Note also that the calculations do not have to be very accurate - as long as they always detect a hit, it matters little if they sometimes throw up a false 'hit', as long as the subsequent processing weeds it out. Its been a while since I played with this stuff, but IIRC some of the intersection calculations have simple forms if everything is 'on axis' - so one approach that might well work out with fpga hardware is to have part of your pipeline a 4 x 4 matrix 'rotater' to transform everything going through the hit/miss pipeline. You will get the best results if you really understand the ray trace algorithms - if you just try to blindly implement a fast fpu a lot of your effort will be wasted and you will grow several grey hairs ! regards Dave "Matt Billenstein" <mbillens@mbillens.yi.org> wrote in message news:mHAh6.13554$ra.1279071@typhoon.kc.rr.com... > Well, thanks to everyone for the good information... I'm trying to > accelerate a ray tracing application (POVRay) using digital hardware. My > guess is that I do not have to be strictly IEEE compliant in my > implementation, but the numbers I hand back to the have to be in double > precision format. > > I'm counting on everything being heavily pipelined and I am looking into > CORDIC for implementing the trancendentals. The board I'm using hangs off > the memory bus, so I'd like everything to be synchronous to the 66 or 100 > MHz SDRAM clock. > > I'm doing this for a research project for school, so no worry of me bidding > it too low :) > > Matt > > > > Matt Billenstein > mbillens (at) one (dot) net > http://w3.one.net/~mbillens/ > > > "Matt Billenstein" <mbillens@mbillens.yi.org> wrote in message > news:6L2h6.1820$xh3.173569@typhoon.kc.rr.com... > | All, > | > | I've taken on a project where I'll be implementing a number of math > | functions on IEEE double precision floating point types (64 bit). > | Multiplication, division, addition, and subtraction are fairly straight > | forward. I'll need to do cosine, exponential (e^x), and square roots. > Any > | advice/pointers/book titles would be appreciated. I'll be implementing in > | VHDL targeting a large Xilinx VirtexE device (XCV1000E). Hopefully at 66 > or > | 100 MHz. > | > | Thanks, > | > | Matt > | > | > | -- > | > | Matt Billenstein > | REMOVEmbillens@one.net > | REMOVEhttp://w3.one.net/~mbillens/ > | > | > | > | > >Article: 29277
Actel did an app note dated Oct. 1998 entitled "Implementing an 8b/10b Encoder/Decoder for Gigabit Ethernet in the Actel SX FGPA Family" that should tell you all you need to know. (the only error I found was that D24.6 is a "flip" and not a "same"). I think that a lot of what is said in the artical would probably not be used anymore, as they tell you how to build a gate type implementation, where as todays block ram in an fpga offers a much easier solution. S. Ramirez <sramirez@deletethis.cfl.rr.com> wrote in message news:C_ag6.107098$8V6.14816145@typhoon.tampabay.rr.com... > Does anyone know where I can find some Internet information on 8B/10B > encoding? > Thank you very much in advance. > Simon Ramirez, Consultant > Synchronous Design, Inc. > Oviedo, FL USA > >Article: 29278
--------------21200DEE3993C09CF1A9A4DA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xilinx PAR-tool crashes with core dump when using guide file (booth on NT and UNIX). Has anyone the same experience? I'am usin Alliance 3.1i service pack 6. /Patrik Eriksson -- Patrik Eriksson | patrik.eriksson@netinsight.net Net Insight AB | phone: +46 8 685 04 89 Västberga Allé 9 | fax: +46 8 685 04 20 SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.net --------------21200DEE3993C09CF1A9A4DA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <pre>Xilinx PAR-tool crashes with core dump when using guide file (booth on NT and UNIX). Has anyone the same experience?</pre> <pre>I'am usin Alliance 3.1i service pack 6.</pre> <pre>/Patrik Eriksson</pre> <pre>-- Patrik Eriksson | patrik.eriksson@netinsight.net Net Insight AB | phone: +46 8 685 04 89 Västberga Allé 9 | fax: +46 8 685 04 20 SE-126 30 STOCKHOLM, Sweden | <A HREF="http://www.netinsight.net">http://www.netinsight.net</A></pre> </html> --------------21200DEE3993C09CF1A9A4DA--Article: 29279
Hi Gil,
I do the following...
- use a PDF viewer and copy the pinout tables from the
datasheet to a text file. xpdf under Linux works well
for this, I haven't tried acrobat.
- use a tool like Perl/Tcl/awk to format the ascii table
into a .XNF file with each pin that look like:
EXT,name,IO,,pin
you can use a text editor if you're only doing one file.
- under OrCad/Windows I then use the "Generate Part" feature
to read the XNF file and create a new part. You'll need to
put a header on the XNF file and a EOF at the end, to make it
parse OK.
- under OrCad split the part into multiple part/package for
logic, configurtion and power sub-parts. You might need to
create a new part and then copy/paste the pins into it. This
makes it more managable, since you usually have different
pages for power/logic etc... anyway. Once they are in sub-parts
I organize the pins into whatever makes sense for the project,
i.e. Logical order vs. physical pin order.
There are probably other pin list formats that will work for the
Generate Part tool. I'm familiar with XNF format, so I went with that.
Hope this helps.
See ya, -ingo
In article <3A83BE21.7FF9A0FD@sony.de.REMOVE_THIS>,
Gil Golov <golov@sony.de.REMOVE_THIS> wrote:
>Does anybody have this symbol for Orcad capture?
>
>Thanks very much in advance.
>
>Gil Golov
>
>
--
/* Ingo Cyliax, cyliax@ezcomm.com, Tel/Fax: 812-{391-0895,333-4852} */
Article: 29280hi, block ram is so expensive for my design i can use cyclic chained SRL, but is there any more appropriate way ? moreover, the person who does not want to answer my question, better for him to SHUT HIS MOUTH, rather than showing his skills with a beginner like me --Karen In article <3A86D3B1.A937BEC1@nospamplease.erols.com>, rk <stellare@nospamplease.erols.com> wrote: > karenwlead@my-deja.com wrote: > > > > hello, > > > > thanks to you all for the reply. I have to mention that it's not a > > homework... > > OK, it looks like homework. > > I would still suggest looking up the references. > > Good luck! > > ---------------------------------------------------------------------- > rk We had dodged bullets before, but > stellar engineering, ltd. this time we caught one in midair and > stellare@erols.com.NOSPAM spit it out. > Hi-Rel Digital Systems Design -- Gene Kranz after Apollo 5 > Sent via Deja.com http://www.deja.com/Article: 29281
Despite my exotic, LFSR based design not being too popular ;-), here is another one that does your timing (including the 255 vs 256 problem). http://www3.sympatico.ca/erv/spctimgen.gif the design should use (once logic is trimmed) : - 16 Flops - 12 LUTs That's 4 Virtex CLBs. That's how I would do it, but there certainly is a more optimized / more efficient / faster (?) version. Here are the waveforms : http://www3.sympatico.ca/erv/spctimgensim.gif Good luck with your (whatever)-work ! Eric --------------------------------------------------- karenwlead@my-deja.com wrote: > hello, > > thanks to you all for the reply. I have to mention that it's not a > homework... > > Now, how can i generate those 7 waveforms EFFICIENTLY > > waveform 1 > ---------- > 0 from 0-->4 cycles and 1 from 5-->255 > > waveform 2 > ---------- > 0 from 0-->3 cycles and 1 from 4-->255 > > waveform 3 > ---------- > 0 from 0-->2 cycles and 1 from 3-->255 > > waveform 4 > ---------- > 0 from 0-->1 cycles and 1 from 2-->255 > > waveform 5 > ---------- > "1" from 0-->251 cycles and "0" from 252-->255 > > waveform 6 > ---------- > 1 from 0-->252 cycles and 0 from 253-->255 > > waveform 7 > ---------- > 1 from 0-->253 cycles and 0 from 254-->255 > > i can use what you suggested, many comparators in //, but the problem > of fan out occurs. As i can duplicate the counter. but is there any > more appropriate way to do it ? > > thanks > > In article <3A86B54B.D8BAEC41@nospamplease.erols.com>, > rk <stellare@nospamplease.erols.com> wrote: > > Peter Alfke wrote: > > > > > > How about when the counter counts? > > > > > > > > > > > 01111111 > > > > 10000000 > > > > > > > > Hint for the h-work kid: look up static hazard in your logic book. > > > > > > Yes. > > > > It would be interesting to see if they take off on H-Work assignments > > for a pulse that has potential glitches in it. > > > > > Why go to the trouble of using exotic schemes, > > > like LFSR, when a binary > > > solution is actually simpler, and also equally fast. > > > > <rk shrugs> Lots of solutions to this one. Very simple H-Work > problem. > > > > > Also, unless you know the tricks, an LFSR divides > > > by 255, not 256. > > > > Hints for the H-Work kid: > > > > 1. _The Art of Electronics_, Horowitz and Hill > > > > 2. _HDL Chip Design_, Smith. > > > > ---------------------------------------------------------------------- > - > > rk A designer has arrived at perfection > > stellar engineering, ltd. not when there is no longer anything > > stellare@erols.com.NOSPAM to add, but when there is no longer > > Hi-Rel Digital Systems Design anything to take away - Bentley, 1983 > > > > Sent via Deja.com > http://www.deja.com/Article: 29282
Hi! Where can I find Xilinx Virtex (XCV600BG432) Symbols for eDesigner/Viewdraw? Thanx for any URL (email), Ingo _______________________________ Ingo Purnhagen (Dipl.-Ing.) OHB-System GmbH Abt. Hardware Universitaetsallee 27-29 28359 Bremen, Germany Fon: +49 421 2020 702 Fax: +49 421 2020 610 mailto:purnhagen@ohb-system.de http://www.ohb-system.deArticle: 29283
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:964ipk$90m@gap.cco.caltech.edu... > How fast does it really need to be, expecially for divide, cos, > exp, sqrt? If it doesn't need to be super fast you could implement > a relatively simple processor and a ROM control unit. For the more > complicated functions, you will probably want this, anyway. Is there still a reason to use hardware for division these days? Given the availability of really fast multiply-accumulate units, you can implement a quadratic-convergence division from primitive operations (normalisation, initial reciprocal estimate from table lookup etc.) pretty fast. That is the direction IA-64 has taken. Can the linear-time hardware methods (SRT etc.) now be regarded as obsolete?Article: 29284
In article <9697p7$b4r$1@cam-news1.cambridge.arm.com>, Al Grant <tnarga@arm.REVERSE-NAME.com> wrote: >"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message >news:964ipk$90m@gap.cco.caltech.edu... >> How fast does it really need to be, expecially for divide, cos, >> exp, sqrt? If it doesn't need to be super fast you could implement >> a relatively simple processor and a ROM control unit. For the more >> complicated functions, you will probably want this, anyway. > >Is there still a reason to use hardware for division these days? >Given the availability of really fast multiply-accumulate units, you >can implement a quadratic-convergence division from primitive >operations (normalisation, initial reciprocal estimate from table >lookup etc.) pretty fast. That is the direction IA-64 has taken. >Can the linear-time hardware methods (SRT etc.) now be >regarded as obsolete? If so, they always were :-) Yes, the modern fast multiply-accumulate units make a difference, but the older systems had the problem that the divide unit used so much logic that other things had to be cut to get it in. I doubt that there has been much of a change, which doesn't mean that it isn't time for a rethink. My belief is that the main obstacle to this one is the fact that the primitives are designed for fast, complete operations on a few fixed-sized units. You neally need a slightly more flexible set of primitives if you want to build up divide, square root etc. from them. And, of course, you need access to the basic primitives rather than just the completed instructions. As you know, I would favour taking that line - only a lot more radically - and merging the integer and floating-point units, with the basic primitives exported to the programmer. Not for performance on existing benchmarks, but for flexibility and simplicity. Perhaps it's infeasible, but my gut feeling is that it is merely out of fashion. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679Article: 29285
Wed, 07 Feb 2001 17:59:20 GMT eml@riverside-machines.com.NOSPAM Hi, Evan! What problems you wants to decide by means of the JTAG? I began from experiments with the JAM-player from ALTERA. http://www.jamisp.com/ But is quickly disillusionned. Shorter, has done an own software in the manner of libraries. V4J - Boundary Scan Test (BST) - - See on my homepage. Two examples: - Show of current status (on operation under power). - Testing the interconnects in montage (on PCB). 2ALL: Anyone knows Free and Low-Cost Software for JTAG? >Anyone know how to drive JTAG manually for debugging? I've got a 9572 >with an 8-bit instruction register, and an ADI device with a 3-bit >register, in series. Ideally, I'd like to put them both in bypass, and >just clock bits through to make sure that they get from TDI to TDO (or >something else very simple if it would be better). I've got Xilinx's >programmer, so I can set TDI and TMS, and then generate a TCK. Best regards! Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm [Team RaceTerrapin] [Team LEXX] ===Article: 29286
Oh, that was exactly my idea... I have no intention of trying to compete with a fast processor in terms of just making a generic FPU to directly implement fundamental functions. As others have suggested, I probably don't even need to consider much of the IEEE spec (rounding modes and such) so I'll probably just end up implementing what I need for my application. Thanks to everyone for the feedback, it is highly appreciated. Matt -- Matt Billenstein mbillens (at) one (dot) net http://w3.one.net/~mbillens/ <kolja@prowokulta.org> wrote in message news:968kf5$roj$1@nnrp1.deja.com... | Hi | | For something like raytracing I would suggest that you implement some | kind of vector processer. This means that you for example give one | command to add N pairs of numbers instead of just one. | This way you can do very heavy pipelining and almost allways keep the | pipeline full. This would require vectorization of the loops in POVRay. | This is not hard to do, and would for sure make it easier to get high | troughpout from your hardware. | | Read the user manuals of Motorola DSP96002. They only implemented | addition, subtraction, comparison and multiplication and a 8-bit | division approximation. | | The same tradoff is probably true for FPGA as well. The results might be | better if you spend more time on getting the basic operation really fast | with a lot of pipelining instead of having specialized hardware for | everything. Maybe you can even run multiple instances of the basic | operations in parallel from internel blockrams. These can than be used | to implement the transcendentals. | | The user manual of DSP96002 contains assembler code to emulate the other | operations. They are only a little slower than hardware iterations. | | 1/X takes 6 instructions | 1/SQRT(X) takes 11 instructions using newton-raphson approximation | SQRT(X) is just X/SQRT(X) and takes 12 instructions | SIN/COS is done with cordic. | | Analog Devices SHARC Manuals also contain a lot of assembler code. | | In article <mHAh6.13554$ra.1279071@typhoon.kc.rr.com>, | "Matt Billenstein" <mbillens@mbillens.yi.org> wrote: | > Well, thanks to everyone for the good information... I'm trying to | > accelerate a ray tracing application (POVRay) using digital hardware. | My | > guess is that I do not have to be strictly IEEE compliant in my | > implementation, but the numbers I hand back to the have to be in | double | > precision format. | > | > I'm counting on everything being heavily pipelined and I am looking | into | > CORDIC for implementing the trancendentals. The board I'm using hangs | off | > the memory bus, so I'd like everything to be synchronous to the 66 or | 100 | > MHz SDRAM clock. | > | > I'm doing this for a research project for school, so no worry of me | bidding | > it too low :) | | | Sent via Deja.com | http://www.deja.com/Article: 29287
It reason you can't run bitgen for a V300 is because you are using an extremely old version of software. 1.5.17 is the M1.5 release. There have been three major releases since then (1.5i, 2.1i, and 3.1i) not to mention lots of service packs. If you want to use a new architecture like Virtex, using the newest software is your best bet. HTH, MikeArticle: 29288
"Al Grant" <tnarga@arm.REVERSE-NAME.com> writes: >"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message >> How fast does it really need to be, expecially for divide, (snip) >Is there still a reason to use hardware for division these days? >Given the availability of really fast multiply-accumulate units, you >can implement a quadratic-convergence division from primitive >operations (normalisation, initial reciprocal estimate from table >lookup etc.) pretty fast. That is the direction IA-64 has taken. >Can the linear-time hardware methods (SRT etc.) now be >regarded as obsolete? This is the algorithm that the 360/91 implemented 34 years ago. Given the hardware multiply, it shouldn't be hard to add the hardware to do this algorithm, and iterate though the multiplier. One thing that was noted for the 91 was that it rounded instead of truncated so it was more accurate but didn't follow the S/360 definition of FP divide. I don't know if this is a problem in IEEE or not. Does IEEE require specific rounding rules for division? -- glenArticle: 29289
glen herrmannsfeldt wrote: > One thing that was noted for the 91 was that it rounded instead of > truncated so it was more accurate but didn't follow the S/360 > definition of FP divide. I don't know if this is a problem in IEEE > or not. Does IEEE require specific rounding rules for division? Is the Pope a Catholic? Yes, IEEE does require fdiv to follow _all_ the rules, which means returning the exact same results as all other conforming implementations, for all possible in-range inputs. The only leeway you've got is what you do when faced with a denormalized result, and/or a number that could result in double rounding. Terje -- - <Terje.Mathisen@hda.hydro.com> Using self-discipline, see http://www.eiffel.com/discipline "almost all programming can be viewed as an exercise in caching"Article: 29290
Hello, I have made a multiplier and I want to use the dedicated carry logic in a XC4000 FPGA. How can I do this using Xilinx Foundation tools 2.1i? Have I to modify my vhdl code?Article: 29291
Hi, Today I was working on our own PCI arbiter and I decided to look at a QuickLogic example to see how they solved a problem. Basically an arbiter can only assert a GNT_ to one device and simultaneously deassert the first GNT_ if the PCI bus is not Idle. Using this signal in an FPGA is difficult because of the setup times of FRAME_ and IRDY_. In the QuickLogic example they write Bus_busy = !frame_ , they simple forget IRDY_ and ignore the setup time. But it even gets better. While reading the Verilog it seemed the author did not fully understand the concept of rotating priority. As long as FRAME_ is asserted the GNT_ is given to another device each clock cycle, even if the REQ_ do not change. I thought I misunderstood the strange Verilog code, but no, on page 4 of QAN24.pdf it is documented that way. This is not rotating priority, but a time driven random generator. This is probably one of the worst application notes ever. The errors in the code are typical of errors being made by students. This code has certainly never been used in a real PCI bus. J.P. Smeets J.P. Smeets business: Ellips Woenselsestr 352A 5623 EG Eindhoven tel: +31-40-2456540 fax: +31-40-2467183 email: jeanpaul@ellips.nl home: Loondermolen 23 5612 MH Eindhoven tel: +31-40-2465105 email: jpsmeets@xs4all.nlArticle: 29292
His key phrase is in the third paragraph: "But for a minority of FPGA adepts" is enough for me. Why would a multimillion dollar, nay, almost Billion dollar company make a product that frankly a few "technical whizzes" are going to design into products that ship a few hundred (or even thousand) a year? I suspect that true "on-the-fly" (fast as you could possibly do it) reconfigurability would be rather fraught. To do it "perfectly" you might wish to have the old bit-stream already programmed in (as the device operates) and then load the new bitstream into a buffer to be instantly flipped over at some given point in time. That would makes it an expensive chip for a feature few will ever use. Xilinx and Altera are both spot-on (IMHO) in adressing a marketspace that has seen ASIC vendors scrambling to put more and more on a die, charge even greater NRE's and impose even higher minimum order values on a shrinking customer base. Once the technology is delivered there will be a lot of happy volume users. I don't envy the support overhead for these products once they get into the wild through the distribution channel though! Cheers Stuart On Sun, 11 Feb 2001 18:08:23 GMT, "Dan" <daniel.deconinck@sympatico.ca> wrote: >EET Feb 5,2001 Ron Wilson argues that on-the-fly reprogrammable FPGAs are >much better an architecture than SoC. > >The leading FPGA companies are going full speed into SoC / platform FPGAs. > >How valid is Ron's point of view ? > >Dan > > > > > For Email remove "NOSPAM" from the addressArticle: 29293
--------------867FD92FB602067E69D6258A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matt, One of the best reference texts on the transcendental functions is by Cecil Hastings, Approximations for Digital Computers . I found several copies at www.bookfinder.com Clyde Matt Billenstein wrote: > All, > > I've taken on a project where I'll be implementing a number of math > functions on IEEE double precision floating point types (64 bit). > Multiplication, division, addition, and subtraction are fairly straight > forward. I'll need to do cosine, exponential (e^x), and square roots. Any > advice/pointers/book titles would be appreciated. I'll be implementing in > VHDL targeting a large Xilinx VirtexE device (XCV1000E). Hopefully at 66 or > 100 MHz. > > Thanks, > > Matt > > -- > > Matt Billenstein > REMOVEmbillens@one.net > REMOVEhttp://w3.one.net/~mbillens/ --------------867FD92FB602067E69D6258A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Matt, <p>One of the best reference texts on the transcendental functions is by Cecil Hastings, <u>Approximations for Digital Computers</u> . <p>I found several copies at www.bookfinder.com <p>Clyde <p>Matt Billenstein wrote: <blockquote TYPE=CITE>All, <p>I've taken on a project where I'll be implementing a number of math <br>functions on IEEE double precision floating point types (64 bit). <br>Multiplication, division, addition, and subtraction are fairly straight <br>forward. I'll need to do cosine, exponential (e^x), and square roots. Any <br>advice/pointers/book titles would be appreciated. I'll be implementing in <br>VHDL targeting a large Xilinx VirtexE device (XCV1000E). Hopefully at 66 or <br>100 MHz. <p>Thanks, <p>Matt <p>-- <p>Matt Billenstein <br>REMOVEmbillens@one.net <br>REMOVEhttp://w3.one.net/~mbillens/</blockquote> </html> --------------867FD92FB602067E69D6258A--Article: 29294
I have just started learning how to design for CPLDs using VHDL. Now I want to try out using a real life problem by actually programming a chip (a CPLD like say XESS, in order to program or can I make my own JTAG cable with circuit say XESS, in order to program or can I make my own JTAG cable with circuit diagram from Xilinx web site and use Webpack software? Even if this means buying the chip from, say Insight, I figure it still cheaper. I am on a tight budget here since this is just for my hobby. Thanks. Pratip Mukherjee pratipm@hotmail.comArticle: 29295
On Tue, 13 Feb 2001 03:58:27 GMT, pratipm@hotmail.com (Pratip Mukherjee) wrote: >I have just started learning how to design for CPLDs using VHDL. Now I want to >try out using a real life problem by actually programming a chip (a CPLD like >say XESS, in order to program or can I make my own JTAG cable with circuit >say XESS, in order to program or can I make my own JTAG cable with circuit >diagram from Xilinx web site and use Webpack software? Even if this means >buying the chip from, say Insight, I figure it still cheaper. I am on a tight >budget here since this is just for my hobby. >Thanks. > >Pratip Mukherjee >pratipm@hotmail.com You can build your JTAG Cable yourself. Look for the schematics of the Parallel Cable III on the Xilinx web site. The original cable however is not so expensive (about 100 $). The Webpack software is needed in any case. Have fun Klaus Falser Klaus R&D Electronics Department Company : Durst Phototechnik AG Vittorio Veneto Str. 59 I-39042 Brixen Voice : +0472/810235 : +0472/810111 FAX : +0472/830980 Email : kfalser@IHATESPAMdurst.itArticle: 29296
This is a multi-part message in MIME format. --------------F28B8417099F8773A74A4039 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Xilinx application notes XAPP 164 http://www.xilinx.com/xapp/xapp164.pdf and XAPP 165 http://www.xilinx.com/xapp/xapp165.pdf cover this topic when using Synplicity or Exemplar for synthesis. I suggest taking a look at these to possibly answer some of your questions. -- Brian Sang-hee Lee wrote: > Hi, all. > > To reduce the implementation time, > I'm about to use the guide files in XIlinx foundation 2.1i. > However, I couldn't exactly understand what they are and when they can be > used. > May I ask how the implementation time can be saved > when I made minor modifications in my design. > For instance, the usage of the slices in my design is about 15% and > I want to change one line in a HDL source file. > Do I have to wait for more than 30 minutes for this ? > > Alan. --------------F28B8417099F8773A74A4039 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 --------------F28B8417099F8773A74A4039--Article: 29297
"Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message news:3A8849B1.B9BA65F6@hda.hydro.com... > glen herrmannsfeldt wrote: > >Does IEEE require specific rounding rules for division? > > Is the Pope a Catholic? > Yes, IEEE does require fdiv to follow _all_ the rules, which means > returning the exact same results as all other conforming > implementations, for all possible in-range inputs. There's some interesting papers from Intel (look for Cornea-Hasegan) about how they proved the IA-64 division and square root rounded correctly in all four IEEE rounding modes - by separating the cases into those which can be proved by looking at error bounds and those (a much smaller set) which needed to be tested exhaustively. Makes you wonder how everyone else does it.Article: 29298
V R <ipickledthefigsmyself@mrbourns.com> wrote in message news:965uqn$31s$1@news.utdallas.edu... > Sorry for the off-topic and cross-post but I was curious (since we have > the attention of so many now) if more "intelligent" floating point scheme > exists (i.e. non-IEEE 754/854)? I know computers performed math before > Intel's spec so of course there will be dozens of proprietary formats... > > It feels like manipulation of floating point data in the 754/854 formats > is more cumbersome than it needs to be. Any there any other schemes that > are "simpler" (besides fixed point, etc) and/or easier to implement? Any > implementations that nicely lend themselves to FPGAs? Obviously one will > have to make a trade offs such as bit-size vs. precision, etc. but I'm > inquiring about a general schemes... > > Thanks! > VR.Article: 29299
Hi, all. To reduce the implementation time, I'm about to use the guide files in XIlinx foundation 2.1i. However, I couldn't exactly understand what they are and when they can be used. May I ask how the implementation time can be saved when I made minor modifications in my design. For instance, the usage of the slices in my design is about 15% and I want to change one line in a HDL source file. Do I have to wait for more than 30 minutes for this ? Alan.
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