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 29 Nov 1998 09:40:31 +0100, Anonymous <nobody@replay.com> wrote: >This thought should be worrying not only XILINX shareholders, >but also, - XILINX users, who have invested a lot of efforts >and money into mastering XILINX tools. ===snip====== >Good bye XILINX ... And this from a company whose CEO stated, in print, "Software is a core competancy of Xilinx". Mind you he was new to the job then..... -- Gavin Melville gavin@cypher.co.nzArticle: 13351
Le mer Michel wrote in message <364FE560.77003750@ago.fr>... >ovilup wrote: > >> Hello ! >> >> I am working on an I2C controller. Now, I am designing the >> internal clock generator. I have an 1.5 MHz internal clock, >> from which I have to generate the 100 KHz, 90 KHz, 44 KHz >> 1.5 KHz SCL clocks. >> >> Any examples of such an clock generator would be appreciated ! >> >> Thank you in advance. >> OL > >Hello > >I do not know exactly what it is but I heard about the direct numeric >synthesis. It is use in the signal generators to privide a wave of a >specific frequency. > >Bye. >Michel. > I did an i2c controller and used the "programmble counter" approach. The logic around it was kind of messy, partly because (at least for a full i2c implementation) you need to be able to run at *any* frequency depending on the mode e.g. master xmit/rcv, slave xmit/rcv. I am not very familiar with the approach using the accumulator, but depending on the application you may not have the luxury of using processor resources for the i2c port. Good luck.Article: 13352
I was wondering if someone could provide an objective comparison between Altera and Xilinx. Not just from a technical standpoint (regarding their products), but also from a business standpoint. Which company (Altera or Xilinx) from the viewpoint of the readers of this news group is a superior/better company with the brightest future. (I thought this might be an interesting topic to discuss. After all, we all want to use the chips of the company that will be around the longest, or in other words is long-term viable.) -EKCArticle: 13353
What an absolute crock of shit. Save this crap for misc.invest.stocks where somebody might buy into it. By the way, Marshall doesn't sell Altera either. Do you think that's by choice you moron? Anonymous wrote: > > This thought should be worrying not only XILINX shareholders, > but also, - XILINX users, who have invested a lot of efforts > and money into mastering XILINX tools. > > Why should we expect XILINX shutdown in the foreseeable future? > > 1) XILINX has started as successful innovative company and won > essential part of the market. But that's in the past ... > Recent history of XILINX is a sequence of disastrous failures > to deliver satisfactory quality at reasonable price. > Remind heart-breaking stories with 8000, 6200, 5200 series! > Lacking new ideas, XILINX is trying to sell their old 4000 > series wrapped into Spartan envelope. And now Virtex becomes > too late answer on Altera designs. > > 2) XILINX applies tremendous efforts to reduce the price and ... > the quality of its development tools. > It was reported by many customers in this particular newsgroup > that XILINX Foundation is worse than XACT, and each subsequent > version of Foundation is worse than previous. > Currently the quality of development tools is so bad that XILINX > almost gave up any attempts to fix endless stream of bugs. > The bugs are just stored until next version of Foundation : > > 3) XILINX support service became some sort of psychoanalyst to > keep users calm and to avoid bodily damage (and chip damage) > caused by desperate customers. XILINX is afraid to reveal > an obvious thing: there is no support for ALDEC software > that constitutes the principal part of Foundation (design flow, > schematics and simulation). > > 4) And now the last news: > MARSHALL does not sell XILINX chips any more. > Obviously, they are feeling where the things go. > > Good bye XILINX ... > > ************* -- --------------------------- real addr: rsefton_@_home.com (remove the underscores) ---------------------------Article: 13354
It is somewhat interesting to note that the revenue of both companies has been relatively flat at about $150 mil/Q for nearly the last 2 years. Could this indicate that the programmable logic market has topped out? It would make some sense that much of the growth of the programmable logic market over the last ten years has been due to the consolidation of designs from smaller discrete logic chips to larger programmable logic chips. If this process has reached saturation, then the question is, from where will further growth in this market to come? FPGAs are moving up into ASIC territory while designs themselves are growing. So the growth in size of the FPGA parts may not result in a larger market. At the same time, the cost per gate of FPGAs is dropping which will offset any increase in revenue due to the larger parts. It would seem that just moving to ever larger FPGAs will not provide future growth. Anyone have any insight into where these companies are headed? Personally, I don't agree with the original poster at all in the evaluation of Xilinx support and tools. I have had very good results with the Foundation tools while I failed terribly with third party tools. alpha wrote: > > I was wondering if someone could provide an objective comparison between > Altera and Xilinx. Not just from a technical standpoint (regarding their > products), but also from a business standpoint. Which company (Altera or > Xilinx) from the viewpoint of the readers of this news group is a > superior/better company with the brightest future. (I thought this might be > an interesting topic to discuss. After all, we all want to use the chips of > the company that will be around the longest, or in other words is long-term > viable.) > > -EKC -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13355
According to Xilinx, their latest and greatest CPLDs and FPGAs are delicate flowers which should not be socketed so as to avoid the consequential extra inductance in signal lines, and decoupling should be extensive - surface-mount 0.1uF AND 0.01uF at EVERY power pin is stated to be essential, along with 10uF per IC. However, the XS40 (FPGA) and XS95 (CPLD) boards produced by XESS Corp (see <http://www.xess.com/fpga/ho02000.html>) use socketed ICs with relatively sparse decoupling. Similarly, the Xilinx documentation on in-system programming implies that one should use the Xilinx download systems. These have sophisticated line driving/terminating circuitry in their active "pods", and are not as simple to clone as, say, the straightforward and well-documented Lattice isp system. Once again, the XESS Corp boards use simple drive and termination arrangements and plain cables - no slew-limiting capacitors, no padder resistors, not even pullups on most lines, and some have no buffer. Does anyone have experience of producing an isp system who can advise whether to be very careful and precise (as per Xilinx) or take a more relaxed approach (as per XESS) in designing the environment for these ICs? -- Tim Forcer tmf@ecs.soton.ac.uk Department of Electronics & Computer Science The University of Southampton, UK The University is not responsible for my opinionsArticle: 13356
Anyone know of an arbitration scheme that can use the "serial numbers" of devices on a master-less 2 wire (clock & data) serial bus? The objective is to avoid the complexity of a formal two pass give-to-next- higher setup. Any selection sequence will work as long as each device is chosen equally. The devices will be implemented on a board holding both an MCU and a CPLD. Consequently, there is a variey of tools, but not much free room on either. Suggestions on texts that deal with arbitration of this type would be a help also. Thanks, Hul htytus@iglou.comArticle: 13357
Rick Filipkiewicz wrote: > > I'm looking for a reasonably priced Verilog simulator to add to our > Xilinx Foundation+Express package. > So far I can see VeriWell, Chronologic, QuickTurn. Anybody have any > comments on these or others. We could go to $5000 which I assume writes > off Cadence. > > Also looking for a Verilog PCI testbench suite. try another tools www.dolphin.fr smash free download , support verilog,vhdl,spice -- peterLin 林春敏 cmlin@topro.com.tw www.topro.com.tw 130,Szewei rd,Hsin-chu,Taiwan Fax 886-3-5251596 << 人生就是無止境的追求真理 >>Article: 13358
Hul Tytus wrote: > Anyone know of an arbitration scheme that can use the "serial > numbers" of devices on a master-less 2 wire (clock & data) serial bus? The > objective is to avoid the complexity of a formal two pass give-to-next- > higher setup. Any selection sequence will work as long as each device is > chosen equally. CANbus uses a neat arbitration scheme (there's no clock line, but that doesn't affect the method) based on sending an arbitration priority most- significant-bit-first, using any signalling scheme which has "wire-or" behaviour: - multiple drivers are OK - N drivers sending identical levels gives that level - N drivers sending different levels, the dominant level wins (dominant=0 in CANbus, but that's a matter of taste) Each node tries to send by first sending a dominant-level start bit. Any other node seeing the start bit will accept that it lost the race and will back off until the current message has completed. But if two nodes send start bits simultaneously, each believes it was successful! So the next thing you send is an arbitration number, MSB first. As long as the two nodes send identical arbitration numbers, both think they are alone and successful. But as soon as you come to a bit where the arbitration numbers differ, the node sending the dominant level succeeds (and carries on, ignorant of the other node) and the node attempting to send a recessive level sees that it has failed (dominant level appears on the line) and immediately ceases its attempt - and retries later. This technique gives zero-cost arbitration (the winner doesn't even know he was involved in an arbitration contest) and is very easy to implement on a bus with an explicit clock line, but of course it calls for: (1) unique arbitration numbers per node (2) EITHER acceptance of fixed arbitration priority among nodes (as used by CANbus) OR some devilish cunning method of rotating priorities to ensure fairness in a heavily- loaded system IIRC this MSB-first wire-OR arbitration trick first saw the light of day in part of the Futurebus spec, bus grant arbitration or something - but maybe I'm wrong? I suspect that your stipulation "each device chosen equally" is incompatible with an entirely symmetrical peer-to-peer network which arbitrates without negotiation. Anything that guarantees perfect symmetry in the choice process will lead to deadlock in some situations. You have to break the symmetry somehow; fixed-per-node arbitration numbers is just the easiest way to do it. See Dijkstra's dining-philosophers problem for more info! Jonathan BromleyArticle: 13359
This question is not exactly FPGA related, but this is the only newsgroup I can find that deals with programmable logic. I am looking for the diagnostic programs for the Logical Devices AllPro (40) or AllPro 88 programmer. The diagnostic programs provided with the AllPro 88 are called DIAG1, DIAG3, and DIAG4.EXE and are located in directories named DIAG1, 3, and 4, according to the service manual. I am trying to use an AllPro programmer that I found in an internet auction. Before I bid on it I contacted Logical Devices about support. They told me I could get a service manual from them that would provide all the information I would need to verify the machine was working before buying the programming software. I understood this to mean it would contain either program listings or programming information which I could use to exercise the hardware. I ordered the manual and find it does not contain the details I need. It covers a newer model (AllPro 88) and while the schematics it contains are similar to the hardware in my unit, there are no PAL equations and no schematics of the pindriver circuits. I have figured out the circuitry up to the pindrivers but don't want to go further till I know whether it is possible to turn on more than one source in a pindriver. I don't want to accidentally connect 25V at 1A to a TTL output or a FET to ground! Logical Devices says the AllPro 88 software recognizes the older AllPro model and will do all devices up to 40 pins (the 88 has 88 pindrivers, the old model has 40). Ellis Easley Jr. ehowell.easley@worldnet.att.netArticle: 13360
> 1. My implementation times now are only a few minutes, ten or twenty times > faster than in the "good old days". Thanks ..... Microsoft. Microsoft? Why Microsoft? They haven't made their software (that does nothing but get in the way, I call it a virus, they call it an OS) any faster, in fact, it's nothing but VASTLY SLOWER. Their saving grace has been faster processors.... If you want to thank anyone for the GUI, for which Microsoft did nothing but copy, thank Xerox and Apple. Microsoft just copied it. Austin Franklin darkroom@ix.netcom.comArticle: 13361
Rickman wrote: > > It is somewhat interesting to note that the revenue of both companies > has been relatively flat at about $150 mil/Q for nearly the last 2 > years. Could this indicate that the programmable logic market has topped > out? The entire semiconductor market has been soft for the last two years. It's a cyclic business. Programmable logic is projected to be the fastest growing segment of the semiconductor market for years to come. It would make some sense that much of the growth of the > programmable logic market over the last ten years has been due to the > consolidation of designs from smaller discrete logic chips to larger > programmable logic chips. If this process has reached saturation, then > the question is, from where will further growth in this market to come? > As size and speed increase and the development tools get better these parts will find plenty of new applications. Use you imagination. > > FPGAs are moving up into ASIC territory while designs themselves are > growing. So the growth in size of the FPGA parts may not result in a > larger market. At the same time, the cost per gate of FPGAs is dropping > which will offset any increase in revenue due to the larger parts. The cost per gate of ALL semiconductors goes down as processes shrink. Look at microprocessors. Intel has managed to stay afloat under these market conditions, and Xilinx and Altera combined probably have a more dominant position in the programmable logic market than Intel does in the microprocessor market. > It would seem that just moving to ever larger FPGAs will not provide > future growth. Anyone have any insight into where these companies are > headed? > IMHO they'll both thrive for many years to come. > Personally, I don't agree with the original poster at all in the > evaluation of Xilinx support and tools. I have had very good results > with the Foundation tools while I failed terribly with third party > tools. I agree. The tools have come a long way, but of course they still have some shortcomings. The diversity in the target applications of the parts and of the customer base (and design environments) that these companies have to serve makes it impossible to please everyone. --------------------------- real addr: rsefton_@_home.com (remove the underscores) ---------------------------Article: 13362
Jonathan Bromley wrote: > > Hul Tytus wrote: > > Anyone know of an arbitration scheme that can use the "serial > > numbers" of devices on a master-less 2 wire (clock & data) serial bus? The > > objective is to avoid the complexity of a formal two pass give-to-next- > > higher setup. Any selection sequence will work as long as each device is > > chosen equally. > > CANbus uses a neat arbitration scheme (there's no clock line, but that > doesn't affect the method) based on sending an arbitration priority most- > significant-bit-first, using any signalling scheme which has "wire-or" > behaviour: > - multiple drivers are OK > - N drivers sending identical levels gives that level > - N drivers sending different levels, the dominant level > wins (dominant=0 in CANbus, but that's a matter of taste) > > Each node tries to send by first sending a dominant-level start bit. > Any other node seeing the start bit will accept that it lost the > race and will back off until the current message has completed. ...snip... This sounds much like the "arbitration" scheme used in ISA bus Plug-N-Play device identification. They use the same, "everybody reply" with an ID number, one bit at a time, with one polarity dominating. This process continues with "losers" dropping off the bus until only one guy is left standing at the end where you have received his ID number and he is ready to receive configuration instructions. I am not sure, but I believe PCI also works this way. Sounds like a good way to go if you can afford the time to shift out the ID number. But then if you are on a serial bus, it is a moot point. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13363
Only a PUTZ posts such an opinion wtih an anonymous signature. I wouldn't give this guy two cents of credibility. --- Tom Curran Memec Design Services -- Boston url: www.memecdesign.com email: tom_curran@memecdesign_dot_comArticle: 13364
Anonymous <nobody@replay.com> wrote: > This thought should be worrying not only XILINX shareholders, > but also, - XILINX users, who have invested a lot of efforts > and money into mastering XILINX tools. Translation: "I just sold short on Xilinx stock and I'm under the illusion that real investors will take my dimwitted reasoning seriously. > 4) And now the last news: > MARSHALL does not sell XILINX chips any more. > Obviously, they are feeling where the things go. Xilinx dumped Marshall. Obviously, they are feeling where the things go?Article: 13365
This is probably exactly what Intel are trying to do - maintain pressure on the competition by introducing lots of different products. This strategy should be successful, in the short term at least, but only if the company pushing it is big enough to start with. >Remind heart-breaking stories with 8000, 6200, 5200 series! >Lacking new ideas, XILINX is trying to sell their old 4000 >series wrapped into Spartan envelope. And now Virtex becomes >too late answer on Altera designs. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13366
>It is somewhat interesting to note that the revenue of both companies >has been relatively flat at about $150 mil/Q for nearly the last 2 >years. Could this indicate that the programmable logic market has topped >out? It would make some sense that much of the growth of the >programmable logic market over the last ten years has been due to the >consolidation of designs from smaller discrete logic chips to larger >programmable logic chips. If this process has reached saturation, then >the question is, from where will further growth in this market to come? > >FPGAs are moving up into ASIC territory while designs themselves are >growing. So the growth in size of the FPGA parts may not result in a >larger market. At the same time, the cost per gate of FPGAs is dropping >which will offset any increase in revenue due to the larger parts. > >It would seem that just moving to ever larger FPGAs will not provide >future growth. Anyone have any insight into where these companies are >headed? I cannot see how the continued push towards ever larger FPGAs matches with what people actually design. I can see why the vendors do this: they have absolutely nowhere else to go, except keep reducing prices on existing parts until they all go bust. But very few designs are 100k+ gates. Sure, the newsletters are full of such examples, but those are invariably very high cost low volume products where the device cost was almost immaterial. I know quite a few people who design FPGAs for a living, and several firms who use X. devices in very large numbers, and most of the designs are under 10k gates. Anything in the 100k-1M gate region would represent a massive project (in man-years), unless the device is stuffed with RAM or some other regular structure. I don't know what the sales breakdown of FPGAs is but I would bet that bulk of X's profits come from their sub-10k-gate parts, mostly the old XC3000 and XC4000. These, especially 4K, represent probably the most futureproof family around. If your firm uses these in fairly large numbers, say 1k-10k/month, you get such low prices (via a direct account) that it makes no sense to change to another family - one which will probably vanish at the next whim of the X. Marketing Dept. I don't think Xilinx will go bust. They have had a damn good near-monopoly run for 10-15 years, selling silicon at nice high prices and devt s/w at totally exorbitant prices (nipping the "problem" company Neocad in the bud) and every good thing has to come to an end. They will just have to share the market with others, rather more than has been the case. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13367
It depends mostly on how many outputs you plan to be switching at once. If you are switching many fast slew rate outputs together, you better have good decoupling or you're going to have a bear of a time getting it all working. If you are socketing it, or worse doing a wirewrapped design with an adapter and are thus forced to have poor bypassing, then extraordinary efforts should be made to reduce the number of outputs switching simultaneously (it can be done, but it ain't pretty). For the download, the critical thing is to have a clean clock. The CCLK is not very tolerant of ringing and other garbage. Tim Forcer wrote: > According to Xilinx, their latest and greatest CPLDs and FPGAs are > delicate flowers which should not be socketed so as to avoid the > consequential extra inductance in signal lines, and decoupling should be > extensive - surface-mount 0.1uF AND 0.01uF at EVERY power pin is stated > to be essential, along with 10uF per IC. > > However, the XS40 (FPGA) and XS95 (CPLD) boards produced by XESS Corp > (see <http://www.xess.com/fpga/ho02000.html>) use socketed ICs with > relatively sparse decoupling. > > Similarly, the Xilinx documentation on in-system programming implies > that one should use the Xilinx download systems. These have > sophisticated line driving/terminating circuitry in their active "pods", > and are not as simple to clone as, say, the straightforward and > well-documented Lattice isp system. Once again, the XESS Corp boards > use simple drive and termination arrangements and plain cables - no > slew-limiting capacitors, no padder resistors, not even pullups on most > lines, and some have no buffer. > > Does anyone have experience of producing an isp system who can advise > whether to be very careful and precise (as per Xilinx) or take a more > relaxed approach (as per XESS) in designing the environment for these > ICs? > > -- > Tim Forcer tmf@ecs.soton.ac.uk > Department of Electronics & Computer Science > The University of Southampton, UK > > The University is not responsible for my opinions -- -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: 13368
I still think that M1 is a serious backwards step for power users. The only thing it buys is a faster compile time. However, floorplanning is broken when compared to floorplanning in Xact6; Certain valid CLB mappings are not handled by M1 so designs compiled successfully under xact6 may not compile or fit under M1. When possible, I still use Xact6. Unfortunately, that is becoming less and less often, as Xact6 does not handle any of the newer. larger devices. Jan Gray wrote: > Complaints: > > 1. If I recall correctly, XACT 5.2 could map 2 FMAPs + 1 (independent > 3-input) HMAP driving a FDCE, RLOC constrained, into a single CLB. Today a > tech support call confirmed that M1.x does not support this. > > In my current XC4005E design, I have had to scrap four "free" columns of > HMAP 2-1 multiplexor+registers, sharing CLBs with other FMAP logic, and > replace them with two expensive columns of FMAP ones. The absence of M1 map > support for independent 3-input HMAPs renders my datapath 28% larger than > otherwise necessary and reduces remaining area for other stuff by 33%. > > (I know, I could make four different hard macros using EPIC...no thank you.) > > 2. EPIC can't print!? > > Praise: > > 1. My implementation times now are only a few minutes, ten or twenty times > faster than in the "good old days". Thanks Intel, Xilinx, and Microsoft. > > 2. M1, just as XACT before it, provides convenient, explicit control over > technology mapping and placement (FMAPs, RLOCs), and timing driven > optimization, and, for now, it still accepts XNF! > > Count your blessings. Let us give thanks. > > Jan Gray -- -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: 13369
Hej, I have a Xilinx Foundation schematic based design which I need to simulate with a VHDL simulator (ModelSim). The schematic design has no Reset port. So when the schematics is exported to VHDL I can't simulate the the reset on configuration. One way to get around this is to change all the schematic sheets and wire the reset to the top-level and then export to VHDL. Before mapping I can then tie the reset pin to ground. However since I am lazy I would prefer not to do this. It should be possible to drive a global signal in VHDL testbench...? Any ideas? Thanks, Jonas Thor thor@sm.luth.se.NoSpam (remove NoSpam, when replying)Article: 13370
> Similarly, the Xilinx documentation on in-system programming implies > that one should use the Xilinx download systems. These have > sophisticated line driving/terminating circuitry in their active "pods", > and are not as simple to clone as, say, the straightforward and > well-documented Lattice isp system. The parallel Cable is nearly as simple as Atmel's ISP cable, we duplicated them without any Problems. Worked also fine in a breadboard approach. I agree with serial cable - but parallel cables would fail with NT ? -- Bertram Geiger, bgeiger@EUnet.at HTL Bulme Graz-Goesting - AUSTRIAArticle: 13371
>... and the development tools get better Hum. Any idea when that's gonna happen? There is a 'perception' that the tools 'may' have gotten better, but when comparing apples to apples, they are far worse. If you compare the old tools with an old part, and the new tools with a new part, the new tools/new part win. Changing two variables in an equation hardly provides a valid test. In fact, it is misleading.... But....it does provide a data point, none the less, when used with the next test: When you take old tools/old part, and new tools/old part, old tools/old part win by a wide margin. I don't know about you, but to me, this is not better tools. I believe the conclusion is, the parts are better, the tools are worse. AustinArticle: 13372
(nipping the "problem" > company Neocad in the bud) I disagree that NeoCAD was a problem. They (again) created a perception of making a better router. Well, it really was only better under certain circumstances....but when used with a design that was floorplanned, it was NO better, in fact, sometimes worse. They designed it to handle regular structures, and the Xilinx router did not handle them at all. All the rest of the NeoCAD tools were not really very good (say, the EPIC editor.....). The NeoCAD 'vision' was to make a universal set of tools for all programmable logic, NOT just 'another' tool for the Xilinx parts. I don't believe their 'vision' was ever going to materialize, and the acquisition of NeoCAD by Xilinx was most fortunate for NeoCAD. I believe it was a most unfortunate move for the Xilinx users, since, now, we are stuck with this set of inferior tools, at least for the foreseeable future.... Damn. Austin As a note, in no way am I meaning to demean or belittle NeoCAD, they have some excellent engineering talent, and probably could have a great product, BUT the fact is, the current tools ARE inferior to the previous Xilinx 5.2/6 tool set. They, and Xilinx, need to own up to that.Article: 13373
Call for position statements and complete papers SLIP'99: workshop on System-Level Interconnect Prediction The workshop on System-Level Interconnect Prediction (SLIP'99) is a new forum for the exchange of ideas related to estimation of interconnect design parameters in VLSI CAD applications. The workshop will take place April 10 and 11, 1999 in Monterey (the weekend before the International Symposium on Physical Design). You are all invited to submit a position statement for informal discussion and/or complete paper. The call for papers follows at the end of this message. SLIP web page: http://www.elis.rug.ac.be/~dstr/SLIP.html More information: dstr@elis.rug.ac.be --------------------------------------------------------------------------- SLIP'99: Workshop on System-Level Interconnect Prediction April 10-11, 1999, Embassy Suites Hotel, Monterey, CA The Workshop on System-Level Interconnect Prediction is a new forum for the exchange of ideas related to estimation of interconnect design parameters in VLSI CAD applications. All aspects of interconnect design parameter estimations and their applications to CAD and computer architecture evaluation are in the scope of the workshop. This year, special interest goes to Rent's rule. Also, while most research on interconnection length and topology estimations has been performed in the a posteriori (i.e., post-layout) regime, this workshop seeks to promote research on a priori and on-line (i.e., pre-layout and during layout) estimations since these will be fundamental to the development of future convergent design methodologies. Interconnection length estimates also provide deeper insight in the placement properties of circuits on different carriers, e.g. three-dimensional architectures with optical channels used for the third dimension of interconnect. The 1999 SLIP workshop will provide an informal context for discussions of key new directions in the field, as well as an opportunity to present leading-edge theoretical and experimental contributions. Contributed papers will be printed as unpublished workshop notes, and will also be invited for submission to an edited volume and/or a journal special issue devoted to interconnect parameter estimation in VLSI CAD. Other elements of the workshop include invited presentations that provide attendees with reviews of background and leading-edge research; a tutorial review of Rent's rule and interconnection length estimations will also be organized. Sponsorship by DA-related organizations is anticipated. Two types of contributions are solicited for the workshop notes: - position statements, and - complete papers. Topics of interest include but are not limited to: Rent's rule and its applications in VLSI CAD A priori, on-line, or a posteriori estimation of interconnect design parameters such as interconnection length, area occupancy, signal delay, power dissipation, etc. Theoretical estimation techniques Estimation algorithms Applications of interconnect parameter estimations in CAD, e.g., floorplanning, placement, routing Applications of interconnect parameter estimations for system architecture evaluation Interconnect parameter estimations for ASIC's, MCM's, and FPGA's IMPORTANT DATES Submission of position statements -- January 15, 1999 Submission of complete (camera-ready) papers -- January 15, 1999 Acceptance notification for complete papers -- February 15, 1999 SUBMISSION OF POSITION STATEMENTS Anyone seeking to contribute to informal discussions on topics related to the workshop theme may submit a position statement (1 page up to a maximum of 3 pages). The position statements will be used as a basis for round-table discussions. SUBMISSION OF COMPLETE PAPERS Authors should submit full-length, original papers (CAMERA-READY, maximum 6 pages double-column format, 10pt font) containing Title of the paper Author names, affiliations and contact information Abstract of at most 200 words Paper text High-quality papers that are concurrently submitted for publication in conferences/journals may be considered by SLIP provided that the concurrent submission is clearly indicated. SUBMISSION INSTRUCTIONS Electronic submission via uuencoded e-mail is encouraged and is the preferred submission mode. Please email a single postscript file, formatted for a 8 1/2" x 11" or A4 paper size, compressed with Unix "compress" or "gzip" to dstr@elis.rug.ac.be Alternatively, you may send four (4) hardcopies of the paper to: Dr. Dirk Stroobandt SLIP'99 RUG-ELIS, room S6 Sint-Pietersnieuwstraat 41 B-9000 Gent Belgium WORKSHOP INFORMATION To obtain information regarding the Workshop or to be added to the Workshop mailing list, please send e-mail to dstr@elis.rug.ac.be The SLIP web page is at http://www.elis.rug.ac.be/~dstr/SLIP.html WORKSHOP ORGANIZATION Prof. Andrew B. Kahng (University of California at Los Angeles, USA) Dr. Dirk Stroobandt (University of Ghent, Belgium) WORKSHOP TIP Combine your participation to this workshop with the ISPD symposium (same place, next day). Mail your comments to: dstr@elis.rug.ac.be. -- ************************************************************ Dr. Dirk Stroobandt Postdoctoral Fellow of the Fund for Scientific Research (F.W.O.) at the University of Ghent, ELIS Department RUG-ELIS Room S6 Phone: +32 (0)9 264 34 01 St.-Pietersnieuwstraat 41 Fax: +32 (0)9 264 35 94 B-9000 Gent, Belgium E-mail: dstr@elis.rug.ac.be URL: http://www.elis.rug.ac.be/~dstr/dstr.html ***********************************************************Article: 13374
This was taken a little out of context, Austin. I never said the tools were great. But I've been using Xilinx tools for a long time now and the period of time after ppr replaced apr (the start of the XACT series tools I guess) was pretty grim. The XACT tools have had 5-6 years to mature now. I have to admit I haven't run into a major problems with the M1 tools yet and all in all I like them much better than XACT. The thing that HAS burned me to some extent is the recent tendency of Xilinx to release optimistic speed files which degrade with each release. I saw a post here recently that claimed the opposite (that Xilinx is conservative), but that wasn't my experience when the XL family was first released. I think the M1 tools with steadily improve and will become as stable and much more usable than the XACT tools. The conversion was something Xilinx had to do because, despite your (and my) affinity for ppr, the old tools could never have supported the new larger devices. Bob Austin Franklin wrote: > > >... and the development tools get better > > Hum. Any idea when that's gonna happen? > > There is a 'perception' that the tools 'may' have gotten better, but when > comparing apples to apples, they are far worse. > > If you compare the old tools with an old part, and the new tools with a new > part, the new tools/new part win. Changing two variables in an equation > hardly provides a valid test. In fact, it is misleading.... > > But....it does provide a data point, none the less, when used with the next > test: > > When you take old tools/old part, and new tools/old part, old tools/old > part win by a wide margin. I don't know about you, but to me, this is not > better tools. > > I believe the conclusion is, the parts are better, the tools are worse. > > Austin -- --------------------------- real addr: rsefton_@_home.com (remove the underscores) ---------------------------
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