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
On Wed, 14 Feb 2001 14:56:52 +0100, "Pascal Delouche" <pascal.delouche@getris.com> wrote: >Hi all! > >I'm using pipelined divider in my design. >Parameters are : > Dividend 16 bits > Divisor 14 bits > Clk/div 8 > Signed > Frequency 100MHz >Latency is given by : Dividend width+remainder width+4=34 in datasheet >Vdhl simulation respect this output latency but in post-implementation >simulation, result data >arrives 6 clock before. > >How to explain difference between datasheet and signal observed after >post-implementation ? > >Pascal Delouche Are you trying the dividend which would cause the largest delay ? If you aren't, the correct output would seem to appear early. Try the largest dividend/smallest divisor which will not cause an overflow. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 29326
"Matthias Fuchs" <matthias.fuchs@esd-electronics.com> wrote in message news:3A8A8EE5.E0ADB6E@esd-electronics.com... > Hi, > > I took a look at my Xilinx Foundation translation logfile and found a > warning about "duplicate definitions" of timing constraints. I do not > know where one of the duplicates come from. The definition, that is kept > is from my .ucf file. But where does the other come from ? How can I > turn off the other spec ? This is just a wild guess, but could it be coming from your synthesis tool? Synplicity, for example, can write a constraints file for the target's tools. In your case, perhaps you have specified a clock period in the synthesis tool, which is being written to a .ncf, which is a duplicate of something in your .ucf. You can turn off this feature in Synplicity, but I personally prefer removing the constraint from the .ucf since there may be other useful constraints in the .ncf, especially if you are using floorplanning in Amplify. Cheers, JamieArticle: 29327
Newsbrowser wrote: > >The Mentor tools seem really good. However, their front-end tool is > >something called Renoir. At first glance it looks like a really cool > >tool, and I'm sure that there are people out there who love it. I am > >not one of them. > > We have Mentor Tools here also. I think basically that any graphical > entry tool is crap and is mainly for beginners at vhdl or too lazy to > figure it out. I totally ignored Renoir and would call it mainly a > time waster. I'm a contracting FPGA developer and so I feel I _should_ keep abreast of any new developments in case they can help my productivity/ usefulness to clients. I've been thinking about graphical entry and its benefits. The argument that it is self documenting is fair enough and it might be _slightly_ faster for implementing state machines etc, but these must then be integrated with the rest of the design (I presume) which will take more time. I came to the conclusion that if graphical entry was the way forward the software industry would have adopted it years ago. Nial.Article: 29328
How are people handling the large (500 mA) startup current for a Spartan II device? The data sheet implies this can be reduced by ramping the power supply up over 50 mS, but doesn't say what the startup current will be reduced to. Is anyone doing this? Also, maybe I'm not looking in the right place, but I can't find anything about how to estimate the power needed for a running device. There must be some algorithm that lets one estimate this based on clock frequency and percentage of device switching? Paul Smith Indiana University PhysicsArticle: 29329
Mathias Could be Express is adding timing to constraints to the NCF file (iser4_1.ncf). Try from Project Manager -> Synthesis -> Options and turn "Export Timing Constraints" to OFF. Cheers Dan Matthias Fuchs wrote: > Hi, > > I took a look at my Xilinx Foundation translation logfile and found a > warning about "duplicate definitions" of timing constraints. I do not > know where one of the duplicates come from. The definition, that is kept > is from my .ucf file. But where does the other come from ? How can I > turn off the other spec ? > > Here is the logfile: > > ------ > Release 3.3.06i - ngdbuild D.25 > Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved. > > Command Line: ngdbuild -p xcs40xl-4-pq208 -uc iser4_1.ucf -dd .. > D:\FPGA\ISER4_1\iser4_1.edf iser4_1.ngd > > Launcher: Executing edif2ngd "D:\FPGA\ISER4_1\iser4_1.edf" > "d:\fpga\iser4_1\xproj\ver1\iser4_1.ngo" > Release 3.3.06i - edif2ngd D.25 > Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved. > Reading NCF file "D:/FPGA/ISER4_1/iser4_1.ncf"... > Writing the design to "d:/fpga/iser4_1/xproj/ver1/iser4_1.ngo"... > Reading NGO file "d:/fpga/iser4_1/xproj/ver1/iser4_1.ngo" ... > Reading component libraries for design expansion... > Loading design module "D:/FPGA/ISER4_1/ts_counter24.ngc"... > > Annotating constraints to design from file "iser4_1.ucf" ... > > Checking timing specifications ... > WARNING:Ngd:706 - Duplicate definitions found for "TS_LCLK". > Keeping definition: PERIOD LCLK 40.000 nS HIGH 20000.000000 pS > Ignoring definition: PERIOD "LCLK" 40000.000000 pS HIGH 20000.000000 > pS ; > WARNING:Ngd:706 - Duplicate definitions found for "TS_P2P". > Keeping definition: FROM PADS TO PADS 27.000 nS > Ignoring definition: FROM "PADS" TO "PADS" 40000.000000 pS ; > > Checking expanded design ... > > NGDBUILD Design Results Summary: > Number of errors: 0 > Number of warnings: 0 > > Writing NGD file "iser4_1.ngd" ... > > Writing NGDBUILD log file "iser4_1.bld"... > ----- > > Thanks > Matthias > > -- > ------------------------------------------------- > \ Matthias Fuchs \ > \ esd electronic system design Gmbh \ > \ Vahrenwalder Straße 205 \ > \ D-30165 Hannover \ > \ email: matthias.fuchs@esd-electronics.com \ > \ phone: +49-511-37298-0 \ > \ fax: +49-511-37298-68 \ > --------------------------------------------------Article: 29330
Someone wrote: > 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... It depends on how you want to do it, and how fast. Personally, I still think that the IBM S/370 base 16 floating point would work well in an FPGA. To do FP add/subtract fast in hardware, you need a barrel shifter for normalization, which is a lot of logic in an FPGA. You need three fewer levels of barrel shift logic. For multiply/divide the fraction multipier and divider will take a lot of the logic, and only a small amount of post normalization is needed, anyway. S/370 also includes prenormalization, but if you require normalized input then you don't need that. S/370 also doesn't include all the NaN, +/- infinity, etc., that IEEE has. But you might not need those, anyway. Base 16 gives pretty much the same range and accuracy as binary, though more bits are needed for fraction and fewer for exponent. -- glenArticle: 29331
Paul Smith schrieb: > > How are people handling the large (500 mA) startup current for a Spartan > II device? > The data sheet implies this can be reduced by ramping the power supply > up over 50 mS, but doesn't say what the startup current will be reduced > to. Is anyone doing this? AFAIK the current decreases as startup time increases. So 500mA and 5ms?? -> 50mA 50ms > > Also, maybe I'm not looking in the right place, but I can't find > anything about how to estimate the power needed for a running device. > There must be some algorithm that lets one estimate this based on clock > frequency and percentage of device switching? There is a power estimator exel sheet an the xilinx homepage. Its designed for Virtex, but should work with Spartan 2 too. And there is a tool called Xpower, which lets you analyze the power consumtion. It also makes a nice looking 3D chart of the power distribution on the chip. But you have to change the input frequencies of your design by hand (At least I couldn get the tool to use the timingconstraints in my UCF). Up to now I had no possibility to check the quality of these estimations. -- MFG FalkArticle: 29332
"Andy Peters noao [.] edu>" <"apeters <"@> wrote in message news:96bvvk$uph$2@noao.edu... > Austin Franklin wrote: > > > > Typically, people make custom symbols, separated into functional groups, > > with actual signal names on the pins, not one generic XCV2000E-BG560C > > symbol... At least that's the way I've been doing it, and everyone else, > > but one person I know has been too... > > I'm with Austin on this. > > If someone gave me a D-size schematic shrunk down to B-size with a > 560-pin FPGA plopped down in the middle, and a rat's nest of lines going > every which way, I'd use the schematic to line the cat box. It's that > useful. Thanks Andy, I love your comment ;-) What I also do, as well as my schematic symbol...is make an Excel spreadsheet/graphic representation of the chip that does reflect the exact pin layout of the device from the TOP view. This way, I can layout my pinout so it follows some reasonable order...typically making sure I group signals, make PCB routing reasonable, and a host of other good things this time consuming process helps me do... I have been after Xilinx for years to provide something like this... It might be neat if I knew how to do it...to write an Excel macro to generate the Viewlogic symbol from the spreadsheet. Anyone know how to do this?Article: 29333
You can also try this page. It gets automatically updated when a new submission is added to the FTP site. This is just index list of the files in that area. ftp://ftp.xilinx.com/pub/documentation/xcell/00_index.htm The other location is maintained manually and may take few days to pass our internal web editors. gazit@my-deja.com wrote: > > In article <3A6DE0C8.D4EE4F7A@xilinx.com>, > peter.alfke@xilinx.com wrote: > > Will be fixed next week. > > It sometimes helps to complain to the newsgroup. :-) > > Peter Alfke > > Yet, Nothing new @ http://www.xilinx.com/xcell/xcell.htm > Did I miss something ? > > ------------------------------------------- > Rotem Gazit > mailto:rotemg@mysticom.XYZ-REMOVE.com http://www.mysticom.com > ------------------------------------------- > > Sent via Deja.com > http://www.deja.com/ -- / 7\'7 Paulo Dutra (paulo@xilinx.com) \ \ ` Xilinx hotline@xilinx.com / / 2100 Logic Drive (800) 255-7778 \_\/.\ San Jose, California 95124-3450 USAArticle: 29334
hi We are trying to configure Xilinx FPGA using SPROM and for some reason data frame error has occured and INIT signal continues to stay low. I have posted the same message and got a reply from chris asking me to refer to one of the xilinx sites.We would really appreciate you if u could let us know how to configure the FPGA using JTAG xchecker . thanx radhikaArticle: 29335
"Austin Franklin" <austin@dark99room.com> wrote: > >It might be neat if I knew how to do it...to write an Excel macro to >generate the Viewlogic symbol from the spreadsheet. Anyone know how to do >this? > Viewlogic supports OLE Automation so it is very possible to do exactly what you want. Actually I wrote some Perl Script code to generate Viewlogic schematics. Excel supports VB Script so it is the same task. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 29336
You may want to verify the start sequence during configuration. If you use a logic analyzer or possibly even an o-scope, you can check the bit pattern going into the fpga on din. This should match the start sequence in the data book for whatever part you are using. Jtag is far easier. Use the RD pin as TDO and be aware that the Xchecker cable has a chip on it which needs 5V. If you are targetting a 3.3V device, you may be able to apply 3.3V and it will work, but this is not guarenteed. It would be recomended that you get the xchecker power adapter if you are interfacing with 3.3V devices Best regards, Chris Dunlap RADHIKA wrote: > hi > We are trying to configure Xilinx FPGA using SPROM and for some reason data frame error has occured and INIT signal continues to stay low. I have posted the same message and got a reply from chris asking me to refer to one of the xilinx sites.We would really appreciate you if u could let us know how to configure the FPGA using JTAG xchecker . > thanx > radhikaArticle: 29337
"Ulf Samuelsson" <ulf@atmel.dot.com> writes: > The Atmel "Secure-FPSLIC" will have the configuration memory > internally and this is used both for the AVR and the FPGA portion. > Issue closed :-) You don't have price estimates on those, do you? I asked our distributor three weeks ago and he got back to me today with little more than a shrug. -KentArticle: 29338
Jabari, You seem to advocate non-pipelined designs but with the exception of non-ECB mode encryption there is no advantage to a non-pipelined design. In Xilinx VitexE-8 FPGAs DES/3DES as well as AES pipelined designs can run at speeds of 150-200MHz (incuding key schedule) with one block processed every cycle. This leads to levels of performance at least an order of magnitude higher than the ones you describe (including the GaAs asynchronous design). A pipelined design will get you either a faster or at the same speed a smaller design compared to a non-pipelined implementation, which is just an inneficient use of the hardware. Catalin Baetoniu jzakiya@mail.com wrote: > In article <qhhf28a7vv.fsf@ruckus.brouhaha.com>, > Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote: > > jzakiya@my-deja.com writes: > > > I'm cofounder of a startup, > > > > > > ---- 3rdeye Technology, LLC ---- > > > > > > We have patent-pending IP cores > > > that can do a number of encryption > > > algorithms as logic gate functions, > > > meaning, completely non-sequentially. > > > (DES, AES, Twofish, RC6, Serpent, SHA-1) > > > Thus, we can perform these algorithms > > > in just one process (clock) cycle, > > > versus multiple sequential cycles. > > > > Sure, one SUFFICIENTLY LONG clock cycle. Care to quote cycle times > > for real FPGAs (or ASIC processes)? > > > > For most applications a pipelined implementation is much preferred, > > as you get much higher total throughput. The exception is usually > > when you have a single stream of data to be encrypted in a feedback > > mode. > > > > I have no doubt that you'll get a patent (it's possible to get a > > patent on *anything*), but I'm curious as to what aspect of the > > encryption implementation you're patenting. Surely you don't think > > that simply expanding the equations into a large combinatorial > function > > is in any way novel? For instance, there have been many DES chips > > that implemented a single round combinatorially. If you try to > flatten > > two rounds into a sum-of-products, it gets completely unmanageable, > > but you can simply chain multiple single-round combinatorial circuits > > to get what you describe. It's just not particularly better than > > doing it the conventional way, with pipeline registers between the > > rounds. > > ------------------------------- > We have compiled and simulated a 1DES design which can > both encipher/decipher in ECB mode in one device. > It was fitted in an EPF10K100EQC-208-1 and was simulated > with Altera Maxplus II 9.6 almost a year ago. It had a > worse case total propagation delay (TPD) for a complete block > of 155 ns. With current Altera and Xilinx devices, and > using newer (better) synthesis and place and route tools, > we can do under 100 ns in their small devices, and better > in their bigger devices. > > We were able to briefly use a gallium-arsenide ASIC library to > compile a full 1DES design, and its worse case TPD was under > 20 ns (~18 ns) (>50 MBlocks/s -> 3.2Gbits/s). This, again > is without pipelining, which allows these cores to easily > implement various design modes (ECB, CBC, ect) with the > minimalist amout of control logic and with the lowest > possible power consumption. > > A full 3DES design in an Altera or Xilinx (currently the > FPGA device families with the largest gate count chips) > should have a 3DES TPD of < 150 ns, based on their device > specifications. ASIC designs in even .25 micron families > should do < 75-100 ns. and with .18-.13 micron CMOS devices > we project full 3DES TPDs around 50-75 ns. > > AES was a very good selection by NIST (National Institute of > Standards and Technology) as the AES algorithm from a > hardware implementation viewpoint. Since it only requires > 10, 12, or 14 rounds (for 128, 192, and 256 bit keys) it > is relatively faster than DES, even though it's blcoksize > is twice as wide (128 vs 64 bits) and its key schedule is > much more involved. > > The full encipher/decipher chip for a 128-bit key which can > compile (unoptimized) into an Altera EP20K1500 device had a > simulated worse case TPD of about 200 ns with Quartus 2000.9 > With the claimed better synthesis and place and route tools > of Quartus II, it should not only compile to be faster, but > we may also be able to compile a full 128-256 bit key design > in one device. > > But you must also realize, when I say **FULL** design, I mean > not only the cipher arithmetic is done non-sequentially, but > also the full key expansion (for AES) for each keysize is also > done non-sequentially, ALL IN ONE DEVICE! > > Our devices are the simplest encryption devices to design with, > requiring the least amount of external control logic to interface > to, which enables systems to be made with less parts (which lowers > total system costs), using less power, and which are faster than > all other sequential design EXCEPT highly pipelined designs, which > have all their attendant problems. In fact, you can pipeline our > design at the block level, versus the single cipher round function > level, and get better perfermance too. > > Also, for special purpose applications, such as for MACs, where > you only need the encipher function, we can make even faster devices > which will fit in smaller chips. We can also strip out the key > expansion logic for AES if desired, if that function can be done > in software. > > The point is, their is a science to performing these algorithms > non-sequentially which is much more involved than stringing a > bunch of XOR gates together. And just like many things are > "obviious" AFTER someone has done it, our design methodology is > not very "obvious" especially since no one has done any of the > algorithms we have implemented in the manner we have AND with > their efficiency and utility. > > Again, for parties interested in learning more about our > technology and IP portfolio, please feel free to contact me. > > Jabari Zakiya > 3rdeye Technology, LLC > 703-608-9233 > jzakiya@hushmail.com > > Sent via Deja.com > http://www.deja.com/Article: 29339
hi chris! Thank you for the information.I am sorry to trouble you again - in our configuration we found that INIT signal is initially going low during configuration and when it is switching to high both the LDC and the DONE pins are going high indicating configuration of FPGA.But we find that the output is erroneous.We would appreciate if you could help us. sincerely radhikaArticle: 29340
On Tue, 13 Feb 2001 09:43:47 -0500, "Pratip Mukherjee" <pratip.mukherjee@fmr.com> wrote: >Perhaps I did not make myself clear in the message. What I want to know is >whether a home made JTAG cable is OK to use or perhaps you need special >cable made with say shielded flat ribbon cable and some other critical >construction method, for it to be used reliably. >Thanks. > >Pratip Mukherjee >pratipm@hotmail.com > I'm using only the original cable and I can not see anything special. Using a shielded cable between the parallel port and the small PCB with the drivers is always a good idea, since it is about 2 m long, but there are only a few lines, data rate is low ( 100 KB/s ?? ) and line impedance does not matter. A round cable works well. The JTAG lines are best kept short, so they have not to be shieled. Hope this helps you better. 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: 29341
Hi All, Does anybody know where to find synthesazable Verilog code of K-bus core interface (ISO-9141) or a documentation of it. thaks in advance, DmitryArticle: 29342
Matt Billenstein a écrit : > > 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. It does not answer your question but I give you my opinion on this. 1) I worked a lot on hardware acceleration of ray tracing. You can work with fixed point with no visible difference. One way of achieving this is by using projective geometry. It avoids a lot of divisions, allows natural rescaling and gives the same results as 64 bits floating point with only 32 bits fixed point. 2) Ray-primitives intersection represents about 80% of the total computation power. It's even lower when you use complex textures (procedural textures, for instance). So, If your hardware accelarates only this part of the whole algorithm and if it accelarates, let's say, by a factor of 10 (not bad), then you accelerate the complete algorithm by a factor of 3.6 only. 3) Most ray tracers (not the modelers) work with triangular facets. It you design dedicated hardware for triangular facets and others primitives (spheres, cylinders, cones, Bezier patches, etc.) you'll save a lot of memory, memory bandwidth and computation power. Regards, -- Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13 Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pacalet@enst.frArticle: 29343
I have trouble understanding the generation of the configuration file of a Spartan20XL device. As I am using serial slave mode (configuration is not time critical, and mastered by a microcontroller), I started from a HEX file, generated by the PROM File Formatter (Version 1.5.25). This gives a HEX file of 44790 bytes, containing the 22395 configuration bytes I expect (as each character in the file represents a HEX character, only 4 configuration bits are represented in one HEX file byte). So far, no problem. But trying to configure my FPGA failed. However, INIT pin did not go down. I found out (but this took me a while) that I had to send (22561 * 8) bits (0x583F * 8 in hexadecimal notation) instead of the expected (22395 * 8) bits (0x577B * 8 in hexadecimal notation), although all the information is already in the first (22395 * 8) bits. I just have to clock the XCLK line (196 * 8 ) times more. Why is this? By looking further, I have found in the PROM File Formatter program this value 0x583F: File > Prom Properties > Data Streams > End Address. Why this value, and not 0x577B ? Also the first 5 bytes of my configuration file look quite strange to me: FF 2 02C1F9 F where I expect FF 2 00577B F. Am I correct? Kind regards, Geert Van DoorselaerArticle: 29344
On Mon, 12 Feb 2001 21:36:10 +0300, Dmitry Kuznetsov <dkuzn@orc.ru> wrote: >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? Thanks, but I gave up when everything mysteriously started working. This has prompted me to submit an entry for the upcoming FAQ: FAQ section 1: "Help! I can't configure through JTAG." Q1: JTAG Programmer fails with a message about checking power supplies and connections. What's wrong? A1: This is a well known software bug. The error message is incorrect; it should read: "this software has now expired; download today's version. See FAQ A2 for further details." Q2: I didn't get that error message, but I still can't configure. What's wrong? A2: Your software is out of date. It doesn't matter if you downloaded it only 2 weeks ago, or if your hardware's 10 years old, your software is certainly out of date. Get **todays** 10Mbyte download. Q3: Ok, that didn't fix it. What now? A3: Try the following: (a) pull out all cables (b) plug in all cables (c) power everything down (d) power everything up (e) download a circuit diagram for the parallel III cable. Take the top off, peer around, put the top back on again. (f) identify all powered components and cables in your system. Create a matrix which defines all possible sequences for removing and re-applying power, together with all combinations for cable connection and disconnection. Execute exhaustively. (g) Repeat steps (a) through (f), in a random order, until you can't take any more. Q4: Ok, that didn't work either. What now? A4: If you're one of those saddos who posts to NGs, then mail to comp.arch.fpga complaining that JTAG programming doesn't work. Please use the subject line "Help! I can't configure through JTAG" to keep down the traffic. You will be referred to a FAQ entry entitled "Help! I can't configure through JTAG". When you get down to Q4, please do *not* repeat this step. Q5: Ok, that didn't help. What now? A5: Forget it; go home. It'll work in the morning. EvanArticle: 29345
On Sun, 11 Feb 2001 22:00:55 GMT, "Jan Gray" <jsgray@acm.org> wrote: >There's a nice example of a Virtex-carry-chain-optimized n-bit comparator in >VHDL from Arrigo Benedetti in the fpga-cpu list archive, at >http://groups.yahoo.com/group/fpga-cpu/message/73. > >Jan Gray, Gray Research LLC Nice code - does the synth efficiently implement the xor part? To put a more structural spin on all this, a carry chain can be used to combine the outputs of multiple LUTs. The chain can implement an AND function, as coded in Arrigo's code, or an OR function, by doing the obvious De Morganising. One thing that you can put in a 4-in LUT is a 2-in compare (2 xnor's combined with an AND gate). The simple way to do this is to instantiate a LUT with an INIT attribute of 9009. A wide n-in compare can therefore be implemented in n/2 LUTs, with an AND-type carry chain. My own personal preference is to do this sort of thing (ie. basic components) completely structurally, to leave the synth and the mapper the minimum opportunity to de-optimise your code. EvanArticle: 29346
Hi, I would like to know what I can get in a Spartan II if I set the attribute "bubble_tristate" to TRUE in Leonardo Spectrum. Thank you.Article: 29347
In article <9699p7$4jq$1@pegasus.csx.cam.ac.uk>, Nick Maclaren <nmm1@cus.cam.ac.uk> wrote: >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. Let us add to this fixed point (not integer). I consider it a misnomer to call the present form "double precision"; it should be called single precision and the present single from half precision. Even on the RS/6000, where there is a multiply and add instruction, doubling the precision is difficult. Of course, requiring that floating point be normalized greatly adds to this, and also to the representation of multiple precision numbers. Also, Boolean operations on "real" numbers are useful. >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. I see no reason why it should be infeasible; it is out of fashion, partly because of the programming languages. A floating point unit only does several fixed point instructions, but does not make any of the intermediate results available. Multiplication naturally produces a double-length product, and division naturally produces a quotient and a remainder. The amount of "real estate" needed for the flexibility is no greater than that needed to have separate instruction sets. Flexible hardware will to be used if the users know about it, and if the languages do not put obstacles in the way. It seems that there is a great reluctance on the part of those in the computer industry, especially software people, to enable this. -- This address is for information only. I do not claim that these views are those of the Statistics Department or of Purdue University. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558Article: 29348
Pratip Mukherjee schrieb: > > Perhaps I did not make myself clear in the message. What I want to know is > whether a home made JTAG cable is OK to use or perhaps you need special > cable made with say shielded flat ribbon cable and some other critical > construction method, for it to be used reliably. There is no problem, we did that often with "off the shelf" parts without any problem. Just take care about exact and clean power supply Bertram -- Bertram Geiger, bgeiger@aon.at HTL Bulme Graz-Goesting - AUSTRIAArticle: 29349
Location: Kanata, Ontario, Canada Description: Alpha Job Consulting Inc.’s client is a fabulous provider of innovative Networking IC's using advanced logic/memory technologies, aimed at the Classification, Encryption, and Switching markets. These devices combine unique architectures, with millions of gates of logic and extremely high bandwidth embedded DRAMs, SRAM's and CAMs, to achieve unparalleled system performance and integration levels. We use a complete ASIC/Full-Custom RTL to GDSII design flow, with in-house ATE and Product engineering capabilities to achieve optimum performance and time-to-market. Duties: The ASIC Physical Design Engineer will work as a member of an engineering team implementing high density and high-speed multi-million gates ASICs in deep sub-micron technologies. Responsibilities will include floor planning, placement, routing and timing closure of ASIC designs. Education & Skills Requirements: Minimum 3 years experience as a Physical Design Engineer. You will use Cadence Design Planner and Cadence Silicon Ensemble suite of tools on Unix Workstations. Knowledge of CADENCE Silicon Ensemble and/or AVANT! Apollo timing driven layout. Experience with Static Timing Analysis tools such as PrimeTime. Have solid understanding of synthesis, timing driven layout, and post-layout time closure of deep sub-micron designs. Knowledge of parasitic extraction and back annotation of delays. Bachelor Degree in Electrical Engineering, Computer Science or equivalent. Desirable skills related to large ASIC devices including hierarchical routing, chip-level assembly including verification – DRC, ERC, LVS and other necessary checks. Must Have Skills · Physical Design Engineer · Cadence Silicon Ensemble · Bachelors Degree EE or CS
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