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
I am newbie to the FPGA world and a friend of mine asks me that SYNARIO from DATA I/O was better than the other tools. One of the big advantage is to choose the family at the end of the design (ALTERA or XILINX). I would like to know if somebody have use SYNARIO tool ? I am interested in any information. Regards Sebastien SALAS ________________________________________________________________________ ___ AIME - Campus INSA - /\ | |\ /| Complexe Scientifique de Rangueil ____/__\|__|_\/_|________ 31077 TOULOUSE CEDEX / | | | / |\ | | Tel. +33 61 55 98 85 Fax. +33 61 55 98 70 / | \| |____ E-mail: sebas@aime.insa-tlse.fr ________________________________________________________________________Article: 2926
From: herman@galant.ece.cmu.edu (Herman Schmit) Date: 27 Feb 1996 15:29:48 GMT Of course, there are zillions of people who, when they have a clever idea for an application, start doodling C code on the back of envelopes. We can't ignore this installed base of brains and think they're all going become Verilog/VHDL hackers. But the big bugger problem with "C" is that its types are CPU machine types. You have to do everything with 32 bit integers, characters, and single and double precision floating point. That's a big deal for configurable computing because a lot of the win in FPGAs come when the types of data in the algorithm don't match the types in the available CPUs. I've written a HDL compiler for a subset of C called Transmogrifier C (tmcc for short). The tmcc compiler lets you specify the length of each integer variable by using a C pragma statement. You can specify a 13 bit addition this way: #pragma intbits 13 int a, b, c; c = a + b; Another, somewhat better way of doing it would have been to define new integer types: int13 a, b, c; This would make it easier to compile and test a program with an ordinary C compiler, by using typedefs to define all of the funny types. Tmcc web page: http://www.eecg.toronto.edu/EECG/RESEARCH/tmcc/tmccArticle: 2927
>>>>> "SC" == Steve Casselman <sc@vcc.com> writes: In article <1996Feb28.185457.2043@super.org> sc@vcc.com (Steve Casselman) writes: >> : High level languages like C and fortran are naturally "time >> aware." >> >> : Steve Casselman : Virtual Computer Corporation >> >> Steve, >> >> Hunh? >> >> I'm not going to say that Verilog/VHDL are THE languages for >> configurable computing, but I think that I can boldly say, >> anything you can do in "C" I can do in Verilog better (with a >> couple of Third, Verilog and VHDL are much more "time aware", >> or maybe "time acknowledging" than C and Fortran. SC> When I say "time aware" I don't mean "timing aware" I mean in SC> standard HLLs first you do one subroutine then you do SC> another. You bring in your program from the outside world and SC> you execute it over a period of time. If I write a million SC> lines of HLL I can execute it. In HDLs if I write a million SC> lines of code I end up with one big part. With HLLs I time SC> share a piece of hardware with HDLs I create a design that has SC> to exist at the same time. VHDL supports sequential execution of subroutines just as C does but that is not the core issue. Temporal execution over time is not a function of 'C' but is a function of how C is translated into an executable as a series of instructions. You could also compile VHDL into a series of sequential instructions; indeed, that is what happens when you simulate VHDL on your workstation. Thus, the idea of sharing hardware over time is a *mapping* issue and not a language issue in so far as C and VHDL are concerned. This is not to say that you might not want to develop a language to explore RTR issues. But this is a separate discussion from the debate over the utility of C as a configurable computing language. >> The big bugger limitation with Verilog that it is a real pain >> to describe mathematical functions that aren't unsigned two's >> complement. This is just a limitation of Verilog. You can do this handily with overloading in VHDL. SC> HDLs describe hardware HLLs describe algorithms. HDLs are just languages and VHDL is just a concurrent language with some additional constructs directed at supporting some of the things that go on when you organize hardware. As languages, VHDL describes algorithms just fine. VHDL supports subroutines, procedures, loops, etc., all of the features that you expect to see in conventional programming languages. I use functions and procedures all the time when I synthesize to hardware. VHDL is not that hard to learn. For most people already familiar with C or Pascal, for example, it is just a matter of figuring out the differences between syntax (the syntax is usually just a direct map) and learning about concurrency. The syntax differences are easy to learn, concurrency is a bit more of a challenge but is still no big deal. Writing synthesizable VHDL is more challenging and requires experience. But this is not a language issue; it is more a process of learning how the synthesis tool works. This would be an issue anytime you employ automated software to realize a higher-level abstraction as a hardware implementation. Lest I be misinterpreted, let me state again that I am not advocating VHDL as *the* language for CCMs. I'm just using it to argue against C. :-) :-)Article: 2928
Note: This may be a repost. My system people just informed we have been offline for some time now. Apologies for duplications. >>>>> "HS" == Herman Schmit <herman@galant.ece.cmu.edu> writes: In article <4gv81c$802@fs7.ece.cmu.edu> herman@galant.ece.cmu.edu (Herman Schmit) writes: HS> Steve Casselman (sc@vcc.com) wrote: HS> : VHDL and verilog are out since they are only : 2D (you can HS> specify timing but you end up with a time wise flat : HS> design)... HS> : High level languages like C and fortran are naturally "time HS> aware." HS> : Steve Casselman : Virtual Computer Corporation HS> Steve, HS> Hunh? I also say, Huhhhh? HS> I'm not going to say that Verilog/VHDL are THE languages for HS> configurable computing, but I think that I can boldly say, HS> anything you can do in "C" I can do in Verilog better (with a HS> couple of caveats, see below). First, Verilog/VHDL have all Here, here. While I am not advocating VHDL/Verilog as reconfigurable computing languages, they support concurrency and C does not. That makes them much more appropriate from a "time-awareness" point of view. Configurable computing systems need to be programmed with *parallel* programming languages (this is true for other computers, as well. --oops, there goes my unbiased opinion :-)). Steve may have been making a different point though, see below. HS> The big bugger limitation with Verilog that it is a real pain HS> to describe mathematical functions that aren't unsigned two's HS> complement. What if I want to do signed-magnitude, or HS> signed-two's complement? You can't use the "*" or "+" and do HS> that. I guess VHDL is more capable of that, but I staked my HS> tent on the Verilog side of that war too long ago to change HS> now. This can be done in VHDL with overloading. This is where the data abstraction in VHDL can come in quite handy. Unfortunately, VHDL is almost as verbose as COBOL. Not quite, but close. And, yes, I must admit that I actually wrote a little COBOL years ago :-P. That certainly looks wierd on my resume, I suppose. COBOL/Univac 11-08 and VHDL synthesis. But I digress... HS> hackers. But the big bugger problem with "C" is that its HS> types are CPU machine types. You have to do everything with HS> 32 bit integers, characters, and single and double precision HS> floating point. That's a big deal for configurable computing HS> because a lot of the win in FPGAs come when the types of data HS> in the algorithm don't match the types in the available CPUs. HS> Anybody who's written bit-oriented computations in C knows HS> what a pain that can be. Before VHDL was around I wrote quite a bit of bit-oriented stuff in C and C++. What a pain that was. It was also quite slow. Now, I use VHDL for that sort of stuff and it is great for describing bit-level ops, systolic stuff, etc. Don't make me go back to C for hardware description/simulation, pleeeaaaaaaseeeeee... :-) HS> What's the solution? We've been playing with the idea that HS> you use some syntactic sugar from C++ to solve the type HS> problem with C. Create classes that simulate, using standard HS> types like ints and chars, the behavior of a wide variety of HS> data types. You can use operator overriding so designers can If I understand your approach, this is similar to the DEC PRL stuff and I think a number of other people have also advocated similar approaches. How do you really simulate this without writing your own event-driven simulator? A functional event-driven simulator is not a big deal but it seems that you would need something along those lines, right?. You are still dealing with a non-concurrent language, so how do you simulate a general concurrent description? Overall, I think that it is a reasonable approach. It has worked for a number of people. And besides, who *simulates* FPGA designs, anyway? :-) BTW, There *is* a problem with the specification of VHDL for RTR (run-time reconfigurable) systems. VHDL is statically linked (well, elaborated, anyway). There is no elegant way to describe hardware that will be paged in at run-time with VHDL. Here at BYU we work on systems that are demand-paged. That is, the FPGA hardware does not know beforehand what circuit modules will be loaded. That is a function of the application software and the data set. However, if you wanted to describe such a system in VHDL, you would need to enumerate all modules that *may* be loaded so that the entire system can be elaborated prior to simulation (every circuit module would need to be included in the elaboration step). One work-around is to generate a new VHDL model from the software part of the application that incorporates only those circuit modules that are referenced in the software. This is still painful though. Dynamic linking may be of some use (similar to what conventional linkers can do) --it could resolve function calls to hardware at link time. Even this is overkill, I suppose. Just because a module is referenced in the software does not mean it will be loaded at run-time (it may be data dependent). At any rate, the static elaboration of VHDL is what makes it a bad fit for demand-paged hardware. Note that serial languages such as C or C++ don't help either. The demand-paged approach really cries out for a language with some form of lazy evaluation. Let me see, lazy evaluation, parallel programming, hmmm, starts sounding like a functional programming language. :-) One final thing I wanted to ask was, why does VHDL (and even Verilog), in general, get such a bad rap? Again, I'm not saying they are the be-all, end-all of configurable computing languages, but they can be quite effective under the right circumstances. And, my own experience with the relative efficiency is that VHDL synthesis does a decent job. Yeah, I know it is expensive and many cannot afford it. But, ignoring the cost issue (which I think will be solved over time), VHDL works surprisingly well for the things that I do. So, why do people seem to dislike it so much?Article: 2929
Note: this may be a repost. My system people inform me that we have been offline for awhile. Apologies for duplication. >>>>> "SC" == Steve Casselman <sc@vcc.com> writes: In article <1996Feb28.185457.2043@super.org> sc@vcc.com (Steve Casselman) writes: >> : High level languages like C and fortran are naturally "time >> aware." >> >> : Steve Casselman : Virtual Computer Corporation >> >> Steve, >> >> Hunh? >> >> I'm not going to say that Verilog/VHDL are THE languages for >> configurable computing, but I think that I can boldly say, >> anything you can do in "C" I can do in Verilog better (with a >> couple of Third, Verilog and VHDL are much more "time aware", >> or maybe "time acknowledging" than C and Fortran. SC> When I say "time aware" I don't mean "timing aware" I mean in SC> standard HLLs first you do one subroutine then you do SC> another. You bring in your program from the outside world and SC> you execute it over a period of time. If I write a million SC> lines of HLL I can execute it. In HDLs if I write a million SC> lines of code I end up with one big part. With HLLs I time SC> share a piece of hardware with HDLs I create a design that has SC> to exist at the same time. VHDL supports sequential execution of subroutines just as C does but that is not the core issue. Temporal execution over time is not a function of 'C' but is a function of how C is translated into an executable as a series of instructions. You could also compile VHDL into a series of sequential instructions; indeed, that is what happens when you simulate VHDL on your workstation. Thus, the idea of sharing hardware over time is a *mapping* issue and not a language issue in so far as C and VHDL are concerned. This is not to say that you might not want to develop a language to explore RTR issues. But this is a separate discussion from the debate over the utility of C as a configurable computing language. >> The big bugger limitation with Verilog that it is a real pain >> to describe mathematical functions that aren't unsigned two's >> complement. This is just a limitation of Verilog. You can do this handily with overloading in VHDL. SC> HDLs describe hardware HLLs describe algorithms. HDLs are just languages and VHDL is just a concurrent language with some additional constructs directed at supporting some of the things that go on when you organize hardware. As languages, VHDL describes algorithms just fine. VHDL supports subroutines, procedures, loops, etc., all of the features that you expect to see in conventional programming languages. I use functions and procedures all the time when I synthesize to hardware. VHDL is not that hard to learn. For most people already familiar with C or Pascal, for example, it is just a matter of figuring out the differences between syntax (the syntax is usually just a direct map) and learning about concurrency. The syntax differences are easy to learn, concurrency is a bit more of a challenge but is still no big deal. Writing synthesizable VHDL is more challenging and requires experience. But this is not a language issue; it is more a process of learning how the synthesis tool works. This would be an issue anytime you employ automated software to realize a higher-level abstraction as a hardware implementation. Lest I be misinterpreted, let me state again that I am not advocating VHDL as *the* language for CCMs. I'm just using it to argue against C. :-) :-)Article: 2930
In article <1996Feb29.183450.18760@super.org>, sc@vcc.com (Steve Casselman) wrote: > I've had talks about the newsgroup comp.arch.fpga (computer > architectures based on fpgas) about all this talk about > PLDs, converting fpgas into asics, antifuse parts and such. > The above subjects do not belong in this news group! A agree that the range of subjects has become much broader than may have been the original intent. But the total amount of traffic is still so low, usually less than 100 contributions per month, that I suggest we forget purity and stay with the broader range of subjects. I don't think that the original subject, using FPGAs for innovative computer architectures, alone could support an interesting newsgroup. Who wants to keep looking for something that has one contribution per week ? I vote for diversity. Peter Alfke, XilinxArticle: 2931
In article <4h4sud$c99@fnnews.fnal.gov>, husby@fnal.gov (Don Husby) wrote: > I have an existing ORCA 2C06 design that needs to be modified to work with a > 3.3V memory chip. Has anyone tried driving 3.3V logic (bi-directional > data bus) with 5V ORCA chips? > Well, if you had implemented that design in any Xilinx XC4000 device, there would be no problem. All XC4000 and XC4000E devices can drive, and can be driven by, any 3.3 V chips, even under worst-case conditions. Peter Alfke, Xilinx ApplicationsArticle: 2932
> A truly useful language for a reconfigurable computer should also be one > that many potential users are already familiar with or provides little > resistence to learn/apply. Thus, the ability to use C or C++ would > provide an advantage over VHDL/Verilog. > > As part of our parallel programming research, we are developing a high > level language (HLL) source code converter to an acyclic directed graph > representation. Current HLLs include C, C++, and F77. The directed graph > explicitly identifies inherent parallelism in the source code/algorithm > and identifies all computational units required in a time-ordered > fashion. > > To take advantage of FPGA implementation efficiencies such as fixed > bit-size or bit-oriented operations, new types or classes could be > defined in the C++ code and captured in the graph representation. > Additionally, we can extend the C++ language for reconfigurable computer > programming and add these language features to our C++ grammar. > > Let me hear your opinion. > Rich > Then Erik Says: > I'm not trying to slam you; it's just that if you're capable of > tackling what you've proposed, you're smart enough that I want to see > your efforts focused in the most productive way. I expect to be doing > reconfigurable computing in a couple of years, and I want to see it > have the best possible tools/languags it can. > There was a project in australia where they took C profiled it and then cut the hardware target out made a bit stream complied the rest of the code to the target CPU recombined the hardware image with the software image. This is what I'm talking about. A unified solution. Steve CasselmanArticle: 2933
Pete Becker wrote: > > Where can I find the JEDEC Specification? > > ================================================= > Disclaimer: My comments are not necessarily the > opinion of my employer, myself, or anyone else. > ------------------------------------------------- > Peter Becker > peb@trsvr.tr.unisys.com > ================================================= It ain't quite that easy! JEDEC is an organisation which has defined a number of specifications - largely related to semiconductor device packaging ISTR. -- Regards AndyG "Any opinions expressed herein are entirely my own and may or may not have any connection with reality, virtual or otherwise."Article: 2934
peter@xilinx.com wrote: >Well, if you had implemented that design in any Xilinx XC4000 device, >there would be no problem. All XC4000 and XC4000E devices can drive, and >can be driven by, any 3.3 V chips, even under worst-case conditions. Well, If I used XC4000, I wouldn't be able to make my 16ns clock cycle requirements, would I? Perhaps this is true that X4000 is 3.3V compatible, but it doesn't say anywhere in the data sheets that XC4000 will not drive its outputs past 3.6V. Where is this written? On the subject, I found a good application note on the Quality Semiconductor web site that tells how to use their quickswitch product as a 5V-to-3V bi-directional translator with almost zero proapgation delay: http://www.qualitysemi.com/applications.html Application note AN-11.Article: 2935
In article <peter-0103961016190001@appsmac-1.xilinx.com>, Peter Alfke <peter@xilinx.com> wrote: >Who wants to keep looking for something that has one contribution per week ? I do. Comp.lsi is exactly what this group should resemble: comp.lsi has a few postings a day by people who actually design chips. Comp.arch.fpga should have a few postings a day by researchers in reconfigurable logic for computing -- and a new group should be set up for the majority of posters using FPGAs for glue logic. -- ------------------------------------------------------------------------------- John Lazzaro My Home Page: http://http.cs.berkeley.edu/~lazzaro lazzaro@cs.berkeley.edu Chipmunk CAD: http://www.pcmp.caltech.edu/chipmunk/ ------------------------------------------------------------------------------- Xref: netcom.com comp.arch.fpga:3089Article: 2936
Just to add fuel to the debate (without taking sides :) here's the charter of this group as it was originally approved 22 July 1994: CHARTER The unmoderated newsgroup comp.arch.fpga will be open to discussions on all topics related to the use of reconfigurable Field Programmable Gate Arrays (FPGAs) as computational engines. Appropriate topics include, but are not limited to, system architecture FPGA device architecture languages and compilation techniques tools software environments applications -jeff ----- Jeffrey M. Arnold jma@radix.netArticle: 2937
I know C, C++, Verilog and VHDL. I would definitely say that VHDL is easier to learn than C++. There are a number of mathematical algorithms available in VHDL, at various sites. I'd recommend that you go browse them (look in the comp.lang.vhdl FAQ), and see what you think. I look at VHDL as being a concurrent (multithreaded) programming language. I can do anything in it that I can do in C, but it has much better constructs for describing inter-process communications than C does.Article: 2938
husby@fnal.gov (Don Husby) wrote: >peter@xilinx.com wrote: >>Well, if you had implemented that design in any Xilinx XC4000 device, >>there would be no problem. All XC4000 and XC4000E devices can drive, and >>can be driven by, any 3.3 V chips, even under worst-case conditions. >Well, If I used XC4000, I wouldn't be able to make my 16ns clock cycle >requirements, would I? > Not to get too bit a dig in, but the Altera 10K family has the IO ring designed so you can run it at 3V or 5V supply. Even at 3V supply, it can drive/receive 5V inputs (though, of course, you don't get the really high-level outputs). Also, the entire Altera product line is 3V compatible, as I recall. This is just to keep the discussion balanced - I hate to see marketing tossed into this newsgroup. I have no financial interest in Altera, and I have used both Altera and Xilinx. Erik JessenArticle: 2939
>> Then Erik Says: >> I'm not trying to slam you; it's just that if you're capable of >> tackling what you've proposed, you're smart enough that I want to see >> your efforts focused in the most productive way. I expect to be doing >> reconfigurable computing in a couple of years, and I want to see it >> have the best possible tools/languags it can. >> >There was a project in australia where they took C profiled it >and then cut the hardware target out made a bit stream complied >the rest of the code to the target CPU recombined the hardware image >with the software image. This is what I'm talking about. A unified solution. >Steve Casselman Well, OK, you can develop a new language. But a lot of the simulators these days allow you to cosim VHDL and C. You can even plug in a cycle-accurate model of your CPU, and actually watch it execute code, if you really want accuracy. I've done all of the above; it works really well. That's why I haven't been convinced of the need for a new language. If you're concerned about the hardware/software partitioning problem, that needs some research. But as a practical matter, it looks like people generally do a quick estimate of gatecounts & CPU clock cycles, and then implement the function in whichever is cheaper. So, what's needed is good gatecount estimators and CPU cycle estimators. I'm just an engineer, not a researcher, so I'm looking for reasonable results in a short time. Erik JessenArticle: 2940
In the following I have cut out much of the responces for the sake of bandwidth if things are taken out of context please correct me:). What I'm proposing is a language I call "V". Which 1) Contains "C"(or C++ in the case of V++) as a subset. 2) Contains extentions to the language -- loosely as follows. A bit level type, "bit", a bit vector would be bit myvector[13]; Concepts stolen form VHDL and verilog such as: Wait (VHDL and verilog) When (VHDL) Always (verilog) 3) Has a complier that understands there is a reconfigurable or Parallel resource availble. It is important that V be transportable to systems that do not have reconfigruable resources since I would like to define the language in such a way that non-reconfigurable programmers would use it also in say a symmetric multiprocessor system. The agruments for a V language have more to do with the economics of porting the large current base of programs as anything else. I want to be able to sell somebody by going up and saying "put in my board and recomplie and you will get 2x improvement. Rewrite a little of the old code and get 10x. And by the way this new code will still run on the old machine." If V can be defined in such a way that addresses MPP and symmetric multiprocessing systems then reconfigruable computing will have a much easier time becomming a mainstream computing paradigm. >hardware over time is a *mapping* issue and not a language issue in so in other words its a complier issue. >VHDL describes algorithms just fine. ok I'll buy that. It is just that there are so many more algorithms described in C than in verilog and VHDL. >Lest I be misinterpreted, let me state again that I am not advocating >VHDL as *the* language for CCMs. I'm just using it to argue against >C. :-) :-) >Here, here. While I am not advocating VHDL/Verilog as reconfigurable >computing languages, they support concurrency and C does not. I agree here I REALLY am arguing for a language that leverages the hugh base of C and the best of both VHDL and verilog >Unfortunately, VHDL is almost as verbose as COBOL. To quote "Here, Here" >Don't make me go back to C for hardware description/simulation, please... :-) But you'll have your favorite parts of VHDL ;) >You are still dealing with a non-concurrent language, so how I say fix it. Don't throw out the baby with the bath water. >So, why do people seem to dislike it so much? Can you say COBAL? >From: ejessen@ix.netcom.com (Erik Jessen) >Subject: Re: High Level Languages >I look at VHDL as being a concurrent (multithreaded) programming >language. I can do anything in it that I can do in C, but it has much >better constructs for describing inter-process communications than C >does. VHDL does not have any libraries to, say, write a line on the screen. I may be able to write the code to do a mandelbrot but I'm can't display the results on the screen. I don't want to have to write mouse drivers in VHDL. >these days allow you to cosim VHDL and C. You can even plug in a It not a really good idea to write a large program in two languages. It gets done sometimes but then you have to deal with two complier.. >I've done all of the above; it works really well. That's why I >haven't been convinced of the need for a new language. But your a very good engineer that understands hardware and software how many times have we heard people say "I don't care what it runs on I just want to write code"? >I've written a HDL compiler for a subset of C called Transmogrifier C >(tmcc for short). The tmcc compiler lets you specify the length of each >integer variable by using a C pragma statement. You can specify a 13 bit >addition this way: >#pragma intbits 13 > int a, b, c; > > c = a + b; > >Another, somewhat better way of doing it would have been to define new >integer types: > > int13 a, b, c; Wouldn't it be better just to say bit a[13], b[13], c[13]; Then I could write c[5] = a[2] & b[3] ; To end with I'm not saying I know better than anyone else about what a reconfigurable language should be. I just think we could leverage an old language with new constructs that would be good even for programming non-reconfigurable machines. Since there is no accepted languages for programming parallel machines (not to mention reconfigruable computers) I feel we could make an impact on the furture of computer languages since the hardware programmers have addressed many of the issues of parallel and concurrent machines. I'm hoping its reconfigurable computing that lights the way. Steve Casselman Virtual Computer Corp.Article: 2941
>>>>> "SC" == Steve Casselman <sc@vcc.com> writes: In article <1996Mar3.202757.15726@super.org> sc@vcc.com (Steve Casselman) writes: SC> In the following I have cut out much of the responces for the SC> sake of bandwidth if things are taken out of context please SC> correct me:). SC> What I'm proposing is a language I call "V". Which 1) Contains SC> "C"(or C++ in the case of V++) as a subset. 2) Contains SC> extentions to the language -- loosely as follows. A bit level SC> type, "bit", a bit vector would be bit myvector[13]; Concepts SC> stolen form VHDL and verilog such as: Wait (VHDL and verilog) SC> When (VHDL) Always (verilog) 3) Has a complier that SC> understands there is a reconfigurable or Parallel resource SC> availble. You can't swing a dead cat and not hit some C-variant that supports bit vectors and concurrency. My point is that this has been done before; over and over. And it has not caught on nearly as well as VHDL and Verilog. >> hardware over time is a *mapping* issue and not a language >> issue in so SC> in other words its a complier issue. Thats what I said. SC> I agree here I REALLY am arguing for a language that leverages SC> the hugh base of C and the best of both VHDL and verilog >> Don't make me go back to C for hardware description/simulation, >> please... :-) SC> I say fix it. Don't throw out the baby with the bath water. Not using VHDL *is* throwing out the baby with the bathwater. >> So, why do people seem to dislike it so much? SC> Can you say COBAL? Perhaps a better analogy is ADA. But if the only complaint people can come up with is verbosity, than VHDL must otherwise be pretty good, right? Sure VHDL is a 2-hump camel but C with when-wait-whatever is probably a 3-hump camel. :-) And, there is *no* installed base of C-to-hardware synthesis tools. Don't we want to leverage VHDL synthesis tools that are already out there? We currently have some decent synthesis capability that has taken *over* 10 years to appear. If we try and do this again with yet another language, we would have years to wait before tools start to appear. I'm still waiting to hear what people *don't* like about VHDL.Article: 2942
We have approached this topic from a compiler perspective for a number of reasons. One (unrelated to reconfigurable computing languages) is our long standing research into formal software analysis tools. Compiling HLLs into an intermediate acyclic directed graph representation has some distinct advantages over VHDL/Verilog approaches. This approach is independent of the input HLL. Thus, legacy FORTRAN and C programs can be compiled for these new reconfigurable architectures. While multithreading information may or may not be present in the HLL, our data flow graph representation "automatically" identifies independent execution threads. While C++ may not be considered a multithreaded language, there exist class libraries that provide constructs for multithreading and synchronization. Additionally, HLLs are evolving towards providing increasing levels of multithreading and parallel execution support. In contrast to VHDL/Verilog, HLLs have the advantage of great portability and widely available tools for programming and debugging. It is our objective that user intervention after compilation will be minimal (assuming the program has been verified using a traditional HLL compiler). While VHDL/Verilog can be learned (as with any language), it will also require that developers and companies support an additional suite of development tools. Our product/compiler/crosscompiler could be bundled with the reconfigurable computer unit. I appreciate your comments. Regards, Rich -- Richard B. Lazarus rblazarus@tasc.comArticle: 2943
In article <313B24DD.4DF0@tasc.com> Richard Lazarus <rblazarus@tasc.com> writes: Compiling HLLs into an intermediate acyclic directed graph representation has some distinct advantages over VHDL/Verilog approaches. VHDL and Verilog are both HLLs. I'm curious how you translate general code with cyclic dependencies into acyclic dags. While VHDL/Verilog can be learned (as with any language), it will also require that developers and companies support an additional suite of development tools. Our product/compiler/crosscompiler could be bundled with the reconfigurable computer unit. I suspect that VHDL/Verilog tools could also be bundled with hardware. BillArticle: 2944
I said: >I've written a HDL compiler for a subset of C called Transmogrifier C >(tmcc for short). The tmcc compiler lets you specify the length of each >integer variable by using a C pragma statement. You can specify a 13 bit >addition this way: >#pragma intbits 13 > int a, b, c; > > c = a + b; > >Another, somewhat better way of doing it would have been to define new >integer types: > > int13 a, b, c; Steve Casselman said: Wouldn't it be better just to say bit a[13], b[13], c[13]; Then I could write c[5] = a[2] & b[3] ; I think it depends on what you want to use Transmogrifier C for. If you want to do a 13 bit addition, then having a 13 bit integer is clearer. If you want to do a lot of twiddling of individual bits, then having a bit vector type would be useful. In reconfigurable computing, I suspect that 13 bit adds are more common, and that individual bit twiddling is less common. I want to stick with standard C as much as possible, and I don't want to add features unless they are really going to help. The whole argument behind using a C-based language is the large base of C programmers and C programs, and anything that takes us away from that has to be well justified. If you change the language too much, you might as well use Verilog or VHDL. Tmcc web page: http://www.eecg.toronto.edu/EECG/RESEARCH/tmcc/tmccArticle: 2945
If you guys are really serious about setting up another fpga group... The trick will be in coming up with two group names which are clear enough that people won't pick the wrong one. If you see comp.arch.fpga, it's not immediately obvious that it's the wrong group to post about using FPGA's for glue logic (if that's the category you're trying to exclude). Otherwise, people who just scan the list of newsgroups to look for something applicable to FPGA's are likely to post to both, or to the wrong one. --PaulArticle: 2946
In article <313518AD.6C08@emf.net>, Brad Taylor <blt@emf.net> wrote: > Not being an IC designer, I might be going out on a limb, but I would > say that it must be possible for a chip manufacture to guarantee > something like 3ns min delay. MINs I apologize for this long posting, but it may be of interest to some. I feel a bit lonely as the sole defender of the IC industry against reasonable-sounding requests from the user community. You have my empathy, IÕve been on your side. Here is some good news: First: Xilinx guarantees that the min values for any delay parameter is always more than 25% of the max value for that same parameter, as published for the fastest speed grade offered at any time. You will not like the last part of that sentence, but it allows us to Òdown-binÓ, a vital need in our business. Second: Many parameters have been reduced significantly over the years, but the clock delay has not: Comparing the fastest available XC3020 in 1988 ( -70 ) with the fastest available XC3020A today ( -6 ): logic delays (TILO) were reduced from 9 ns to 4.1 ns output-to-pad delays from 10 ns to 5.0 ns internal-clock-to-output pad from 13 ns to 7.0 ns The internal speed has thus more than doubled, but the worst-case clock distribution delay went from 6.0 ns to 5.7 ns. Or compare XC3120-5 to XC3120-09: logic delay moves from 4.1 to 1.5 ns, Global Clock delay moves from 5.4 ns to 3.2 ns. That is what saves most of your chip-to-chip interfaces. Much as we try to reduce the internal clock-distribution delay, especially on larger chips, the laws of physics work against us: As device geometries shrink, the resistance per unit length of a metal clock line obviously goes up, but its capacitance does not go down proportionally, since it is dominated by fringe effects. An intelligent tree structure helps us to keep the clock skew very low, but we are fighting an exasperating battle to speed up the clock networks which are lagging behind the improvements in logic delay. You can take advantage of our dilemma and rely on clock distribution delays that remain longer than 2 ns, even for fast devices at high Vcc and low temperature. That means you can rely on a clock-to-pad delay of more than 3 ns. So the question is not whether we have a min 3 ns clock-to-out delay ( we have, except for very fast and very small parts, like EPLDs ) but rather, whether we are willing to guarantee it, while at the same time our designers are using all their ingenuity and skill to reduce its dominating ingredient, the on-chip clock distribution delay, albeit with limited success. This problem is not Xilinx-specific, all IC manufacturers struggle with this issue. And a third piece of good news: In our newest family, XC4000EX, we offer a hierarchy of clock buffers. Four are very fast, but each serve only the I/O on half of one edge. Four others are sightly slower, but can serve one quadrant of the chip, while the slowest four clock buffers can serve the whole chip. You can use the fastest clock to capture incoming data, and you can choose between 3 different set-up-time-delay adders, to protect against hold-time requirements. You can then use any clock to transfer the data into the input flip-flop. The input logic has (optionally ) a capture latch in front of the flip-flop, with separate clock inputs for latch and flip-flop . This gives you additional freedom to adjust your input-data capture window independent from the globally clocked logic inside the chip. See page 21 of our brand-new XC4000 Series Product Description, version 0.91 under ÒWhatÕs NewÓ on the web, ( www.xilinx.com ). Of course, there are no min specs. Use your judgment and our statements about 70% tracking and 25% for min. We try to match your needs with our requirement to publish honest specs that we can test and guarantee for years to come. Please interpret these specs as an engineer, not like a lawyer or like some simulators would do. Without on-chip PLLs, there can never be a zero-ns clock-to-output delay. The laws of physics are on your side. Sorry for the longwindedness, but I thought I had your attention. Peter Alfke, Xilinx ApplicationsArticle: 2947
In article <4hbmel$amp@cloner4.netcom.com>, ejessen@ix.netcom.com (Erik Jessen) wrote: > This is just to keep the discussion balanced - I hate to see marketing > tossed into this newsgroup. Agreed, we should keep marketing out of this, but a somewhat surprising technical statement ( correct and verified by simulation, modeling and bench-testing, but not yet supported by a number in the data sheet ) is just that, technical information, not marketing propaganda. Just the facts, ma'am. Peter AlfkeArticle: 2948
Dear Colleagues, Below is the advance program for the 1996 ACM / SIGDA Physical Design Workshop (both in ASCII and in Latex formats). For more information, please see our WWW home page at: http://www.cs.virginia.edu/~pdw96/ Please pass along this advance program to your collagues. Thanks, Gabe ====================================================== Name: Prof. Gabriel Robins U.S. Mail: Department of Computer Science Thornton Hall University of Virginia Charlottesville, VA 22903-2442 Phone: (804) 982-2207 FAX: (804) 982-2214 E-mail: robins@cs.virginia.edu WWW: http://www.cs.virginia.edu/~robins/ ====================================================== ============================================================================= ADVANCE PROGRAM Fifth ACM/SIGDA Physical Design Workshop April 15-17, 1996 - The Sheraton Reston Hotel, Reston, Virginia USA http://www.cs.virginia.edu/~pdw96/ The ACM/SIGDA Physical Design Workshop (PDW'96) provides a relaxed atmosphere for exchange of ideas and promotes research in critical subareas of physical design for VLSI systems. This year's workshop emphasizes deep-submicron and high-performance issues, and also provides a special focus on opportunities in CAD for micro electromechanical systems (MEMS). There are four outstanding panel sessions: (1) future needs and directions for deep-submicron physical design, (2) physical design needs for MEMS, (3) manufacturing and yield issues in physical design, and (4) critical disconnects in design views, data modeling, and back-end flows (e.g., for physical verification). There are also many outstanding technical paper sessions. Free-flowing discussion will be promoted through the limited workshop attendance, the poster session and the "open commentary" mechanism in each technical session, as well as a concluding open problems session. During the workshop, a benchmarks competition will occur in the areas of netlist partitioning and performance-driven cell placement. ============================================================================= SUNDAY, APRIL 14 ============================================================================= 6:00pm-8:30pm: Registration (the registration desk will also be open 8:00am-5:00pm on Monday and 8:00am-12:00pm on Tuesday) 7:00pm-8:30pm: Reception (refreshments provided) ============================================================================= MONDAY, APRIL 15 ============================================================================= 8:30am-8:40am: Welcome 8:40am-10:00am: Session 1, Timing-Driven Interconnect Resynthesis T. Okamoto and J. Cong (UC Los Angeles), Interconnect Layout Optimization by Simultaneous Steiner Tree Construction and Buffer Insertion J. Lillis, C.-K. Cheng and T.-T. Lin (UC San Diego), Simultaneous Routing and Buffer Insertion for High Performance Interconnect L. Entrena, E. Olias and J. Uceda (U. Carlos III of Madrid and U. Politecnica of Madrid), Timing Optimization by Redundancy Addition/Removal Open Commentary - Moderators: D. Hill (Synopsys), P. Suaris (Interconnectix) 10:00am-10:20am: Break 10:20am-12:00pm: Session 2, Interconnect Optimization C. P. Chen, Y. P. Chen and D. F. Wong (U. Texas Austin), Optimal Wire-Sizing Formula Under Elmore Delay Model A. Vittal and M. Marek-Sadowska (UC Santa Barbara), Reducing Coupled Noise During Routing J. Cong and L. He (UC Los Angeles), Simultaneous Transistor and Interconnect Sizing Using General Dominance Property D. Lehther, S. Pullela, D. Blaauw and S. Ganguly (Somerset Design Center and Motorola), Hierarchical Clock-Network Optimization Open Commentary - Moderators: D. Hill (Synopsys), M. Lorenzetti (Mentor) 12:00pm-2:00pm: Lunch Workshop Keynote Address: Prof. C. L. Liu, U. of Illinois Algorithmic Aspects of Physical Design of VLSI Circuits 2:00pm-2:45pm: Session 3, A Tutorial Overview of MEMS Speaker: K. Gabriel (ARPA) 2:45pm-3:00pm: Break 3:00pm-4:15pm: Session 4, Physical Design for MEMS Gary K. Fedder and Tamal Mukherjee (Carnegie-Mellon U.), Physical Design for Surface Micromachined MEMS R. Mahadevan (MCNC), Physical Design Support for MCNC/MUMPS E. Berg, N. Lo and K. Pister (UC Los Angeles), Synthesis and Extraction for MEMS Design 4:15pm-4:30pm: Break 4:30pm-6:00pm: Session 5, Panel: Physical Design Needs for MEMS Moderator: K. Pister (UC Los Angeles) Panelists include: S. Bart (Analog Devices) G. Fedder (Carnegie-Mellon U.) K. Gabriel (ARPA) I. Getreu (Analogy) R. Grafton (NSF) R. Mahadevan (MCNC) J. Tanner (Tanner Research) 6:00pm-8:00pm: Dinner 8:00pm-9:30pm: Session 6, Panel: Deep-Submicron Physical Design: Future Needs and Directions Panelists include: T. C. Lee (former VP Eng, SVR; President/CEO, Neo Paradigm Labs) L. Scheffer (Architect, Cadence) W. Vercruysse (UltraSPARC III CAD Manager, Sun) M. Wiesel (CAD Manager, Intel) T. Yin (VP R&D, Avant!) ============================================================================= TUESDAY, APRIL 16 ============================================================================= 8:30am-9:50am: Session 7, Partitioning S. Dutt and W. Y. Deng (U. Minnesota and LSI Logic), VLSI Circuit Partitioning by Cluster-Removal Using Iterative Improvement Techniques C. J. Alpert, L. Hagen and A. B. Kahng (UC Los Angeles and Cadence), A Hybrid Multilevel/Genetic Approach for Circuit Partitioning J. Hwang and A. El Gamal (Xilinx and Stanford U.), Min-Cut Replication for Delay Reduction Open Commentary - Moderators: J. Frankle (Xilinx), L. Scheffer (Cadence) 9:30am-10:10am: Break 10:10am-11:50am: Session 8, Topics in Hierarchical Design R. Nijssen and J. Jess (TU Eindhoven), Two-Dimensional Datapath Regularity Extraction G. Zimmermann (U. Kaiserslautern), Hierarchical Net Length Estimation H. Esbensen and E. S. Kuh (UC Berkeley), Exploring the Design Space for Building-Block Placements Considering Area, Aspect Ratio, Path Delay and Routing Congestion S. Koakutsu, M. Kang and W. W.-M. Dai (Chiba U. and UC Santa Cruz), Genetic Simulated Annealing and Application to Non-Slicing Floorplan Design Open Commentary 11:50pm-1:30pm: Lunch 1:30pm-3:00pm: Session 9, Poster Session M. J. Alexander, J. P. Cohoon, J. Colflesh, J. Karro, E. L. Peters and G. Robins (U. of Virginia), Physical Layout for Three-Dimensional FPGAs B. Basaran and R. Rutenbar (Carnegie-Mellon U.), Efficient Area Minimization for Dynamic CMOS Circuits M. Hossain, B. Thumma and S. Ashtaputre (Compass Design Automation), A Fast Technique for Timing-Driven Placement Re-engineering K. Hahn and R. Bruck (U. Dortmund), An Approach to Layout and Process Verification for Microsystem Physical Design M. K. Long, J. W. Burdick and T. J. Hubbard (Caltech), Computer Aided Micro-Machining for Wet Etch Fabrication I. Peters, P. Molitor and M. Weber (U. Halle and Deuretzbacher Research GmbH), Over-the-Cell Routing with Vertical Floating Pins R. Sun, R. Gupta and C. L. Liu (Altera and U. Illinois), Congestion- Balanced Placement for FPGAs K.-H. Tsai, M. Marek-Sadowska and S. Kaptanoglu (UC Santa Barbara and Actel), Fanout Problems in FPGA J. Velasco, X. Marin, R. P. Llopis and J. Carrabina (IMB-CNM U. Autonoma de Barcelona, Philips Research Labs Eindhoven), An Optimal Pairing and Chaining Algorithm for Layout Generation G. Yee and C. Sechen (U. Washington), Clock-Delayed Domino in Adder and Random Logic Design 3:00pm-4:00pm: Session 10, Manufacturing/Yield Issues I K. P. Wang, M. Marek-Sadowska and W. Maly (UC Santa Barbara and Carnegie-Mellon U.), Layout Design for Yield and Reliability V. Chiluvuri (Motorola), Yield Optimization in Physical Design (invited survey paper) 4:00pm-4:15pm: Break 4:15pm-5:45pm: Session 11, Panel: Manufacturing/Yield Issues II Panelists include: V. Chiluvuri (Motorola) I. Koren (U. Massachusetts Amherst) J. Burns (IBM Watson Research Center) W. Maly (Carnegie-Mellon U.) 5:45pm-7:30pm: Dinner 7:30pm-9:30pm: Session 12, Panel: Design Views, Data Modeling and Flows: Critical Disconnects A Talk by C. Sechen (U. Washington) H.-P. Tseng and C. Sechen (U. Washington), A Gridless Multi-Layer Channel Router Based on Combined Constraint Graph and Tile Expansion Approach L.-C. E. Liu and C. Sechen (U. Washington), A Multi-Layer Chip-Level Global Route Panelists include: W. W.-M. Dai (UC Santa Cruz, VP Ultima Interconnect Technologies) L. Jones (Motorola) D. Lapotin (IBM Austin Research Center) E. Nequist (VP R&D, Cooper & Chyan) C. Sechen (U. Washington, TimberWolf Systems) ============================================================================= WEDNESDAY, APRIL 17 ============================================================================= 8:30am-9:50am: Session 13, Performance-Driven Design G. Tellez, D. A. Knol and M. Sarrafzadeh (Northwestern U.), A Graph-Based Delay Budgeting Algorithm for Large Scale Timing-Driven Placement Problems J. L. Neves and E. G. Friedman (U. Rochester), Reduced Sensitivity of Clock Skew Scheduling to Technology Variations L.-C. E. Liu and C. Sechen (U. Washington), Multi-Layer Pin Assignment for Macro Cell Circuits Open Commentary 9:50pm-10:10pm: Break 10:10am-11:30am: Session 14, Topics in Layout S. K. Dong, P. Pan, C. Y. Lo and C. L. Liu (Silicon Graphics, Clarkson U., Lucent, U. Illinois), Constraint Relaxation in Graph-Based Compaction B. Basaran and R. Rutenbar (Carnegie-Mellon U.), An O(n) Algorithm for Transistor Stacking with Performance Constraints B. Guan and C. Sechen (Silicon Graphics and U. Washington), Efficient Standard Cell Generation When Diffusion Strapping is Required Open Commentary - Moderator: A. Domic (Cadence) 11:30am-12:00pm: Session 15, Open Problems Moderators: A. B. Kahng (UC Los Angeles), B. Preas (Xerox PARC) 12:00pm-2:00pm: Lunch (and benchmark competition results) 2:00pm: Workshop adjourns ============================================================================= TRAVEL AND ACCOMODATIONS ============================================================================= PDW '96 is being held at the Sheraton Reston in Reston, Virginia, near Washington, D.C. The hotel is minutes from Dulles International Airport (IAD), and 24-hour courtesy shuttles are available from the airport to the hotel. The area is also served by Washington National Airport (DCA), about 20 miles away, and Baltimore-Washington International Airport (BWI), about 50 miles away. The Sheraton Reston is located at: 11810 Sunrise Valley Drive Reston, Virginia 22091 phone: 703-620-9000 fax: 703-860-1594 reservations: 800-392-ROOM *** Please make your room reservation directly with the Reston *** *** Sheraton hotel. *** Driving directions from Dulles Airport: take the Washington Dulles Access and Toll Road (route 267) to the Reston Parkway Exit (3). Turn right at the light after paying toll. Take the next left onto Sunrise Valley Drive, and continue for a couple blocks to the Sheraton (on your left). A block of rooms is being held for the nights of Sunday through Wednesday (April 14 through April 17). Room rates are $95 per night for single occupancy, and $105 per night for double occupancy. The number of rooms available at these rates is limited, and they are only being held through March 24 (so early registration is highly recommended). The Washington D.C. weather tends to be chilly in April, so warm dress is suggested for the outdoors. ============================================================================= SIGHTSEEING AND ATTRACTIONS ============================================================================= The Nation's Capitol offers much in the way of sightseeing. The most popular destinations are located in downtown Washington D.C., surrounding several square miles of park area known as the "National Mall." There is no charge to visit the National Memorials located on the Mall, which include the Washington Monument, where you may ascend 555 feet to an observation post; the Lincoln Memorial, whose design adorns the back of the US penny; the Jefferson Memorial, which includes a 19-foot bronze statue of Thomas Jefferson; and the Vietnam Memorial, a long wall of black Indian granite dedicated in 1982. The Smithsonian Institution (telephone (202) 357-2700) operates a number of superb museums that flank the National Mall, including: Freer Gallery of Art (Asian and 19th and 20th-century American art) Hirshhorn Museum and Sculpture Garden (modern and contemporary art) National Air and Space Museum (history of aviation and space exploration) National Museum of African Art (collection and study of African art) National Museum of American Art (paintings, graphics, and photography) National Museum of American History (technology and culture in America) National Museum of Natural History (history of the natural world) National Portrait Gallery (portraits of distinguished americans) National Postal Museum (history of postal communication and philately) Sackler Gallery of Asian art (from ancient to present) Other attractions and tours around the D.C. area include (please call the numbers below for schedules): Arlington National Cemetary (703) 697-2131 Bureau of Engraving and Printing (202) 622-2000 Congressional buildings (202) 225-6827 FBI Headquarters (202) 324-3447 Library of Congress (202) 707-5000 National Aquarium (202) 482-2825 National Archives (202) 501-5000 National Zoological Park (202) 673-4821 The Pentagon (703) 695-1776 Supreme Court (202) 479-3030 Treasury Department (202) 622-2000 The White House (202) 456-7041 There are a number of reasonably priced eating places on the Mall; the East Wing of National Gallery and the Air and Space Museums offer good food and a place to sit down after sightseeing. Provisions will be made for low-cost transportation to and from the Mall and downtown Washington D.C., so bring your camera and strolling shoes and enjoy our Nation's Capital! ============================================================================= WORKSHOP ORGANIZATION ============================================================================= General Chair: G. Robins (U. of Virginia) Technical Program Committee: C. K. Cheng (UC San Diego) J. P. Cohoon (U. of Virginia) J. Cong (UC Los Angeles) A. Domic (Cadence) J. Frankle (Xilinx) E. Friedman (Rochester) D. Hill (Synopsys) L. Jones (Motorola) A. B. Kahng (UC Los Angeles, Chair) Y.-L. Lin (Tsing Hua) K. Pister (UC Los Angeles) M. Marek-Sadowska (UC Santa Barbara) C. Sechen (Washington) R.-S. Tsay (Avant!) G. Zimmermann (Kaiserslautern) Steering Committee: M. Lorenzetti (Mentor Graphics) B. Preas (Xerox PARC) Keynote Address: C. L. Liu (Illinois) Benchmarks Co-Chairs: F. Brglez (NCSU) W. Swartz (TimberWolf Systems) Local Arrangements Chair: M. J. Alexander (U. of Virginia) Treasurer: S. B. Souvannavong (HIMA) Publicity Chair: J. L. Ganley (Cadence) Sponsors: ACM / SIGDA U.S. National Science Foundation Avant! Corporation ============================================================================= WORKSHOP REGISTRATION ============================================================================= Fifth ACM/SIGDA Physical Design Workshop April 15-17, 1996 - The Sheraton Reston Hotel, Reston, Virginia USA Name: _______________________________________________________________ Company/University: _________________________________________________ Title: ______________________________________________________________ Address: ____________________________________________________________ City: _________________________________________ State: ______________ Phone: ____________________________ Email: __________________________ Registration Fees (Includes All Meals) Advance (Through April 1) Late (After April 1/On-Site) ACM Members __ $355 __ $440 Non-ACM __ $455 __ $540 Students __ $250 __ $250 ACM Membership Number: _____________________________ Dietary restrictions, if any: ______________________ Special needs: _____________________________________ The registration fee includes the workshop proceedings and all meals (i.e., 3 breakfasts, 3 lunches, and 2 dinners), refreshments during breaks, and a reception on Sunday evening. The total number of attendees is limited (registrations will be returned if the workshop is oversubscribed). *** Note: Hotel reservations must be made directly with the Sheraton *** *** (see above). *** The only acceptable forms of payment are checks (personal, company, and certified/bank checks) in US funds drawn on a US bank and made payable to "Physical Design Workshop 1996" (credit cards will not be accepted). Payment must accompany your registration. No FAX or Email registrations will be processed. Please mail your payment (checks only) along with this registration form to: Sally Souvannavong, Treasurer 1996 ACM/SIGDA Physical Design Workshop Department of Computer Science Thornton Hall University of Virginia Charlottesville, VA 22903-2442 USA Phone: (804) 982-2200 Email: pdw96@cs.virginia.edu Cancellations must be in writing and must be received by March 31, 1996. ============================================================================= The following is a Latex version of the PDW '96 advance program. ============================================================================= \documentstyle{article} \def\NewSession#1#2#3#4#5#6{{\large #3: {\bf Session #1: #2}} \\ #4: #5 (#6)} \def\NewSessionN#1#2#3#4#5#6{{\large #3: {\bf Session #1: #2}}} % \def\hsep{\rule{6.5in}{0.01in}} \def\hsep{\vspace{0.1in} \hrule height 1pt \vspace{0.1in}} \def\dsep{\vspace{0.1in} \hrule height 3pt \vspace{0.1in}} \def\mylist{\begin{list}{$\bullet$}{\parsep0pt \topsep0pt \itemsep5pt\partopsep0pt}} \def\myevent#1#2#3{{\large #1: {\bf #2} #3}} \def\mybreak#1{\myevent{#1}{Break}{(refreshments provided)}} \def\mydinner#1#2{\myevent{#1}{Dinner}{#2}} \def\mylunch#1#2{\myevent{#1}{Lunch}{#2}} \def\mypaper#1#2#3{\item {\em #3} \\ #1, #2} \def\mybox{$^{\fbox{}}~$} \def\progspace{\vspace{0.16in}} \def\header#1{\centerline{{\Large\bf #1}}} \addtolength{\textwidth}{140pt} \addtolength{\textheight}{140pt} \addtolength{\topmargin}{-70pt} \addtolength{\evensidemargin}{-70pt} \addtolength{\oddsidemargin}{-70pt} \columnsep 10.5pt \columnseprule 0pt \parindent0pt \parskip5pt \addtolength{\baselineskip}{0pt} \begin{document} $~$ \vspace{-0.0in} \header{Advance Program} \begin{center} \vspace{0.1in} {\Large\bf Fifth ACM/SIGDA Physical Design Workshop} \\ \vspace{0.1in} {\large April 15--17, 1996 --- The Sheraton Reston Hotel, Reston, Virginia USA} {\tt\large http://www.cs.virginia.edu/$_{\large\bf\tilde{~}}$pdw96/} \end{center} \progspace The ACM/SIGDA Physical Design Workshop (PDW'96) provides a relaxed atmosphere for exchange of ideas and promotes research in critical subareas of physical design for VLSI systems. \progspace This year's workshop emphasizes deep-submicron and high-performance issues, and also provides a special focus on opportunities in CAD for micro electromechanical systems (MEMS). There are four outstanding panel sessions: (1) future needs and directions for deep-submicron physical design, (2) physical design needs for MEMS, (3) manufacturing and yield issues in physical design, and (4) critical disconnects in design views, data modeling, and back-end flows (e.g., for physical verification). \progspace There are also many outstanding technical paper sessions. Free-flowing discussion will be promoted through the limited workshop attendance, the poster session and the ``open commentary'' mechanism in each technical session, as well as a concluding open problems session. During the workshop, a benchmarks competition will occur in the areas of netlist partitioning and performance-driven cell placement. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \dsep \header{Sunday, April 14} \dsep \myevent{6:00pm--8:30pm}{Registration}{} (the registration desk will also be open 8:00am-5:00pm on Monday and 8:00am-12:00pm on Tuesday) \myevent{7:00pm--8:30pm}{Reception}{(refreshments provided)} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \dsep \header{Monday, April 15} \dsep \myevent{8:30am--8:40am}{Welcome}{} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{1}{Timing-Driven Interconnect Resynthesis}{8:40am--10:00am} {Session Chair}{XXX}{XXX} \mylist \mypaper{T. Okamoto and J. Cong}{UC Los Angeles} {Interconnect Layout Optimization by Simultaneous Steiner Tree Construction and Buffer Insertion} \mypaper{J. Lillis, C.-K. Cheng and T.-T. Lin}{UC San Diego}{Simultaneous Routing and Buffer Insertion for High Performance Interconnect} \mypaper{L. Entrena, E. Olias and J. Uceda}{U. Carlos III of Madrid and U. Politecnica of Madrid}{Timing Optimization by Redundancy Addition/Removal} \item Open Commentary -- Moderators: D. Hill (Synopsys), P. Suaris (Interconnectix) \end{list} \progspace \mybreak{10:00am--10:20am} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \newpage \progspace \NewSessionN{2}{Interconnect Optimization}{10:20am--12:00pm} {Session Chair}{XXX}{XXX} \mylist \mypaper{C. P. Chen, Y. P. Chen and D. F. Wong}{U. Texas Austin}{Optimal Wire-Sizing Formula Under Elmore Delay Model} \mypaper{A. Vittal and M. Marek-Sadowska}{UC Santa Barbara}{Reducing Coupled Noise During Routing} \mypaper{J. Cong and L. He}{UC Los Angeles}{Simultaneous Transistor and Interconnect Sizing Using General Dominance Property} \mypaper{D. Lehther, S. Pullela, D. Blaauw and S. Ganguly}{Somerset Design Center and Motorola}{Hierarchical Clock-Network Optimization} \item Open Commentary -- Moderators: D. Hill (Synopsys), M. Lorenzetti (Mentor) \end{list} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \mylunch{12:00pm--2:00pm}{} {\large {\bf Workshop Keynote Address}: {\bf Prof. C. L. Liu}, U. of Illinois\\ {\em Algorithmic Aspects of Physical Design of VLSI Circuits}} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{3}{A Tutorial Overview of MEMS}{2:00pm--2:45pm}{Speaker} {K. Gabriel}{ARPA} \progspace \mybreak{2:45pm--3:00pm} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{4}{Physical Design for MEMS}{3:00pm--4:15pm}{Session Chair} {K. Gabriel}{ARPA} \mylist \mypaper{Gary K. Fedder and Tamal Mukherjee}{Carnegie-Mellon U.} {Physical Design for Surface Micromachined MEMS} \mypaper{R. Mahadevan}{MCNC}{Physical Design Support for MCNC/MUMPS} \mypaper{E. Berg, N. Lo and K. Pister}{UC Los Angeles} {Synthesis and Extraction for MEMS Design} \end{list} \progspace \mybreak{4:15pm--4:30pm} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{5}{Panel: Physical Design Needs for MEMS}{4:30-6:00pm} {Moderator}{K. Pister}{UC Los Angeles} Panelists include: \mylist \item S. Bart (Analog Devices) \item G. Fedder (Carnegie-Mellon U.) \item K. Gabriel (ARPA) \item I. Getreu (Analogy) \item R. Grafton (NSF) \item R. Mahadevan (MCNC) \item J. Tanner (Tanner Research) % \item S. Senturia (MIT) \end{list} \progspace \mydinner{6:00pm--8:00pm}{} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \newpage \progspace \NewSessionN{6}{Panel: Deep-Submicron Physical Design: Future Needs and Directions}{8:00pm--9:30pm} {Moderator}{XXX}{XXX} Panelists include: \mylist \item T. C. Lee (former VP Eng, SVR; President/CEO, Neo Paradigm Labs) \item L. Scheffer (Architect, Cadence) \item W. Vercruysse (UltraSPARC III CAD Manager, Sun) \item M. Wiesel (CAD Manager, Intel) \item T. Yin (VP R\&D, Avant!) \end{list} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \dsep \header{Tuesday, April 16} \dsep \progspace \NewSessionN{7}{Partitioning}{8:30am--9:50am} {Session Chair}{XXX}{XXX} \mylist \mypaper{S. Dutt and W. Y. Deng}{U. Minnesota and LSI Logic}{VLSI Circuit Partitioning by Cluster-Removal Using Iterative Improvement Techniques} \mypaper{C. J. Alpert, L. Hagen and A. B. Kahng}{UC Los Angeles and Cadence}{A Hybrid Multilevel/Genetic Approach for Circuit Partitioning} \mypaper{J. Hwang and A. El Gamal}{Xilinx and Stanford U.}{Min-Cut Replication for Delay Reduction} \item Open Commentary -- Moderators: J. Frankle (Xilinx), L. Scheffer (Cadence) \end{list} \progspace \mybreak{9:50am--10:10am} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{8}{Topics in Hierarchical Design}{10:10am--11:50am} {Session Chair}{XXX}{XXX} \mylist \mypaper{R. Nijssen and J. Jess}{TU Eindhoven}{Two-Dimensional Datapath Regularity Extraction} \mypaper{G. Zimmermann}{U. Kaiserslautern}{Hierarchical Net Length Estimation} \mypaper{H. Esbensen and E. S. Kuh}{UC Berkeley}{Exploring the Design Space for Building-Block Placements Considering Area, Aspect Ratio, Path Delay and Routing Congestion} \mypaper{S. Koakutsu, M. Kang and W. W.-M. Dai}{Chiba U. and UC Santa Cruz}{Genetic Simulated Annealing and Application to Non-Slicing Floorplan Design} \item Open Commentary % XXX -- Moderators: \end{list} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \mylunch{11:50pm--1:30pm}{} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{9}{Poster Session}{1:30pm--3:00pm} {Session Chair}{XXX}{XXX} \mylist \mypaper{M. J. Alexander, J. P. Cohoon, J. Colflesh, J. Karro, E. L. Peters and G. Robins}{U. of Virginia}{Physical Layout for Three-Dimensional FPGAs} \mypaper{B. Basaran and R. Rutenbar}{Carnegie-Mellon U.}{Efficient Area Minimization for Dynamic CMOS Circuits} \mypaper{M. Hossain, B. Thumma and S. Ashtaputre}{Compass Design Automation}{A Fast Technique for Timing-Driven Placement Re-engineering} \mypaper{K. Hahn and R. Bruck}{U. Dortmund} {An Approach to Layout and Process Verification for Microsystem Physical Design} \mypaper{M. K. Long, J. W. Burdick and T. J. Hubbard}{Caltech} {Computer Aided Micro-Machining for Wet Etch Fabrication} \mypaper{I. Peters, P. Molitor and M. Weber}{U. Halle and Deuretzbacher Research GmbH}{Over-the-Cell Routing with Vertical Floating Pins} \mypaper{R. Sun, R. Gupta and C. L. Liu}{Altera and U. Illinois}{Congestion-Balanced Placement for FPGAs} \mypaper{K.-H. Tsai, M. Marek-Sadowska and S. Kaptanoglu}{UC Santa Barbara and Actel}{Fanout Problems in FPGA} \mypaper{J. Velasco, X. Marin, R. P. Llopis and J. Carrabina}{IMB-CNM U. Autonoma de Barcelona, Philips Research Labs Eindhoven}{An Optimal Pairing and Chaining Algorithm for Layout Generation} \mypaper{G. Yee and C. Sechen}{U. Washington}{Clock-Delayed Domino in Adder and Random Logic Design} \end{list} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{10}{Manufacturing/Yield Issues~I}{3:00pm--4:00pm} {Session Chair}{XXX}{XXX} \mylist \mypaper{K. P. Wang, M. Marek-Sadowska and W. Maly}{UC Santa Barbara and Carnegie-Mellon U.}{Layout Design for Yield and Reliability} \mypaper{V. Chiluvuri}{Motorola}{Yield Optimization in Physical Design} (invited survey paper) \end{list} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \mybreak{4:00pm--4:15pm} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{11}{Panel: Manufacturing/Yield Issues~II}{4:15pm--5:45pm}{Moderator}{XXX}{XXX} Panelists include: \mylist % XXX missing names / affiliations here: \item V. Chiluvuri (Motorola) \item I. Koren (U. Massachusetts Amherst) \item J. Burns (IBM Watson Research Center) \item W. Maly (Carnegie-Mellon U.) \end{list} \progspace \mydinner{5:45pm--7:30pm}{} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSession{12}{Panel: Design Views, Data Modeling and Flows: Critical Disconnects}{7:30pm--9:30pm}{A Talk by}{C. Sechen}{U. Washington} \mylist \mypaper{H.-P. Tseng and C. Sechen}{U. Washington}{A Gridless Multi-Layer Channel Router Based on Combined Constraint Graph and Tile Expansion Approach} \mypaper{L.-C. E. Liu and C. Sechen}{U. Washington}{A Multi-Layer Chip-Level Global Route} \end{list} \newpage Panelists include: \mylist \item W. W.-M. Dai (UC Santa Cruz, VP Ultima Interconnect Technologies) \item L. Jones (Motorola) \item D. Lapotin (IBM Austin Research Center) \item E. Nequist (VP R\&D, Cooper \& Chyan) \item C. Sechen (U. Washington, TimberWolf Systems) \end{list} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \dsep \header{Wednesday, April 17} \dsep \NewSessionN{13}{Performance-Driven Design}{8:30am--9:50am}{XXX}{XXX}{XXX} \mylist \mypaper{G. Tellez, D. A. Knol and M. Sarrafzadeh}{Northwestern U.}{A Graph-Based Delay Budgeting Algorithm for Large Scale Timing-Driven Placement Problems} \mypaper{J. L. Neves and E. G. Friedman}{U. Rochester}{Reduced Sensitivity of Clock Skew Scheduling to Technology Variations} \mypaper{L.-C. E. Liu and C. Sechen}{U. Washington}{Multi-Layer Pin Assignment for Macro Cell Circuits} \item Open Commentary % -- Moderator: XXX \end{list} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \mybreak{9:50pm--10:10pm} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{14}{Topics in Layout}{10:10am--11:30am}{XXX}{XXX}{XXX} \mylist \mypaper{S. K. Dong, P. Pan, C. Y. Lo and C. L. Liu}{Silicon Graphics, Clarkson U., Lucent, U. Illinois}{Constraint Relaxation in Graph-Based Compaction} \mypaper{B. Basaran and R. Rutenbar}{Carnegie-Mellon U.}{An $O(n)$ Algorithm for Transistor Stacking with Performance Constraints} \mypaper{B. Guan and C. Sechen}{Silicon Graphics and U. Washington}{Efficient Standard Cell Generation When Diffusion Strapping is Required} \item Open Commentary -- Moderator: A. Domic (Cadence) \end{list} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \NewSessionN{15}{Open Problems}{11:30am--12:00pm}{XXX}{XXX}{XXX} Moderators: A. B. Kahng (UC Los Angeles), B. Preas (Xerox PARC) \progspace \mylunch{12:00pm--2:00pm}{(and benchmark competition results)} \progspace \myevent{2:00pm}{Workshop adjourns}{} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% { %\addtolength{\textwidth}{20pt} %\addtolength{\textheight}{20pt} %\addtolength{\topmargin}{-10pt} %\addtolength{\evensidemargin}{-10pt} %\addtolength{\oddsidemargin}{-10pt} \newpage $~$ \vspace{-0.0in} \dsep \header{Travel and Accommodations} \dsep PDW '96 is being held at the Sheraton Reston in Reston, Virginia, near Washington, D.C. The hotel is minutes from Dulles International Airport (IAD), and 24-hour courtesy shuttles are available from the airport to the hotel. The area is also served by Washington National Airport (DCA), about 20 miles away, and Baltimore-Washington International Airport (BWI), about 50 miles away. The Sheraton Reston is located at: \begin{quote} 11810 Sunrise Valley Drive \\ Reston, Virginia 22091 \\ phone: 703--620--9000 \\ fax: 703--860--1594 \\ reservations: 800--392--ROOM \end{quote} {\bf Please make your room reservation directly with the Reston Sheraton hotel.} Driving directions from Dulles Airport: take the Washington Dulles Access and Toll Road (route 267) to the Reston Parkway Exit (3). Turn right at the light after paying toll. Take the next left onto Sunrise Valley Drive, and continue for a couple blocks to the Sheraton (on your left). A block of rooms is being held for the nights of Sunday through Wednesday (April 14 through April 17). Room rates are \$95 per night for single occupancy, and \$105 per night for double occupancy. The number of rooms available at these rates is limited, and they are only being held through {\bf March 24} (so early registration is highly recommended). The Washington D.C. weather tends to be chilly in April, so warm dress is suggested for the outdoors. % XXX Check the average D.C. weather with some weather bureau! - GR %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \dsep \header{Sightseeing and Attractions} \dsep The Nation's Capitol offers much in the way of sightseeing. The most popular destinations are located in downtown Washington D.C., surrounding several square miles of park area known as the ``National Mall''. There is no charge to visit the National Memorials located on the Mall, which include the Washington Monument, where you may ascend $555$ feet to an observation post; the Lincoln Memorial, whose design adorns the back of the US penny; the Jefferson Memorial, which includes a 19-foot bronze statue of Thomas Jefferson; and the Vietnam Memorial, a long wall of black Indian granite dedicated in 1982. The Smithsonian Institution (telephone (202) 357-2700) operates a number of superb museums that flank the National Mall, including: \mylist \item Freer Gallery of Art (Asian and 19th and 20th-century American art) \item Hirshhorn Museum and Sculpture Garden (modern and contemporary art) \item National Air and Space Museum (history of aviation and space exploration) \item National Museum of African Art (collection and study of African art) \item National Museum of American Art (paintings, graphics, and photography) \item National Museum of American History (technology and culture in America) \item National Museum of Natural History (history of the natural world) \item National Portrait Gallery (portraits of distinguished americans) \item National Postal Museum (history of postal communication and philately) \item Sackler Gallery of Asian art (from ancient to present) \end{list} Other attractions and tours around the D.C. area include (please call the numbers below for schedules): \mylist \item Arlington National Cemetary (703) 697-2131 \item Bureau of Engraving and Printing (202) 622-2000 \item Congressional buildings (202) 225-6827 \item FBI Headquarters (202) 324-3447 \item Library of Congress (202) 707-5000 \item National Aquarium (202) 482-2825 \item National Archives (202) 501-5000 \item National Zoological Park (202) 673-4821 \item The Pentagon (703) 695-1776 \item Supreme Court (202) 479-3030 \item Treasury Department (202) 622-2000 \item The White House (202) 456-7041 \end{list} There are a number of reasonably priced eating places on the Mall; the East Wing of National Gallery and the Air and Space Museums offer good food and a place to sit down after sightseeing. Provisions will be made for low-cost transportation to and from the Mall and downtown Washington D.C., so bring your camera and strolling shoes and enjoy our Nation's Capital! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \progspace \dsep \header{Workshop Organization} \dsep \def\s{0.04in} \def\ss{0.04in} \def\sss{0.05in} \begin{center} \fbox{ \parbox{3.5in}{ \begin{tabbing} Al\= Al\= \kill {\bf General Chair:} \\[\s] \> G. Robins {\it (U. of Virginia)} \\[\sss] {\bf Technical Program Committee:} \\[0.07in] \> C. K. Cheng {\it (UC San Diego) } \\[\ss] \> J. P. Cohoon {\it (U. of Virginia)} \\[\ss] \> J. Cong ({\it UC Los Angeles}) \\[\ss] \> A. Domic {\it (Cadence) }\\[\ss] \> J. Frankle {\it (Xilinx) }\\[\ss] \> E. Friedman {\it (Rochester)} \\[\ss] \> D. Hill {\it (Synopsys)} \\[\ss] \> L. Jones {\it (Motorola)} \\[\ss] \> A. B. Kahng {\it (UC Los Angeles, Chair)} \\[\ss] \> Y.-L. Lin {\it (Tsing Hua) } \\[\ss] \> K. Pister {\it (UC Los Angeles) } \\[\ss] \> M. Marek-Sadowska {\it (UC Santa Barbara)} \\[\ss] \> C. Sechen {\it (Washington)} \\[\ss] \> R.-S. Tsay {\it (Avant!)} \\[\ss] \> G. Zimmermann \ {\it (Kaiserslautern) } \end{tabbing} } $~~~~~$ \parbox{3.5in}{ \begin{tabbing} Al\= Al\= \kill {\bf Steering Committee:} \\[\s] \> M. Lorenzetti {\it (Mentor Graphics) } \\[\ss] \> B. Preas {\it (Xerox PARC) } \\[\sss] {\bf Keynote Address:}\\[\s] \> C. L. Liu {\it (Illinois)} \\[\sss] {\bf Benchmarks Co-Chairs:}\\[\s] \> F. Brglez {\it (NCSU)}\\[\s] \> W. Swartz {\it (TimberWolf Systems)}\\[\sss] {\bf Local Arrangements Chair:}\\[\s] \> M. J. Alexander {\it (U. of Virginia)}\\[\sss] {\bf Treasurer:}\\[\s] \> S. B. Souvannavong {\it (HIMA)}\\[\sss] {\bf Publicity Chair:}\\[\s] \> J. L. Ganley {\it (Cadence)}\\[\sss] {\bf Sponsors:}\\[\s] \> ACM / SIGDA \\[\s] \> U.S. National Science Foundation \\[\s] \> Avant! Corporation \\[\s] \end{tabbing} } } \end{center} %\vspace{0.1in} %\begin{center} %{\tt\large http://www.cs.virginia.edu/$_{\large\bf\tilde{~}}$pdw96/}\\ %{\tt\large pdw96@cs.virginia.edu} %\end{center} } %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \newpage $~$ \vspace{-0.5in} \header{Workshop Registration} \begin{center} {\Large\bf Fifth ACM/SIGDA Physical Design Workshop} \\ \vspace{0.1in} {\large April 15--17, 1996 --- The Sheraton Reston Hotel, Reston, Virginia USA} \end{center} \vspace{-0.05in} Name: \rule{5in}{0.01in} \\ \vspace{-0.05in} Company/University: \rule{4.1in}{0.01in} \\ \vspace{-0.05in} Title: \rule{5.07in}{0.01in} \\ \vspace{-0.05in} Address: \rule{4.9in}{0.01in} \\ \vspace{-0.05in} City: \rule{3in}{0.01in} State: \rule{1.65in}{0.01in} \\ \vspace{-0.05in} Phone: \rule{2in}{0.01in} Email: \rule{2.48in}{0.01in} \vspace{0.3in} \header{Registration Fees (Includes All Meals)} \begin{center} \begin{tabular}{ccc} \vspace{0.1in} & Advance (Through April 1) & Late (After April 1) and On-Site \\ \vspace{0.1in} ACM Members & \mybox \$355 & \mybox \$440 \\ \vspace{0.1in} Non-ACM members & \mybox \$455 & \mybox \$540 \\ \vspace{0.1in} Students & \mybox \$250 & \mybox \$250 \end{tabular} \end{center} \vspace{0.1in} ACM Membership Number: \rule{4.15in}{0.01in} \vspace{0.01in} Dietary restrictions, if any: \rule{4.18in}{0.01in} \vspace{0.01in} Special needs: \rule{5.0in}{0.01in} \\ The registration fee includes the workshop proceedings and all meals (i.e., 3 breakfasts, 3 lunches, and 2 dinners), refreshments during breaks, and a reception on Sunday evening. The total number of attendees is limited (registrations will be returned if the workshop is oversubscribed). {\bf Note: Hotel reservations must be made directly with the Sheraton (see above).} The only acceptable forms of payment are checks (personal, company, and certified/bank checks) in US funds drawn on a US bank and made payable to ``Physical Design Workshop 1996'' (credit cards {\bf will not} be accepted). Payment must accompany your registration. No FAX or Email registrations will be processed. {\bf Please mail your payment (checks only) along with this registration form to: } \begin{quote} Sally Souvannavong, Treasurer\\ 1996 ACM/SIGDA Physical Design Workshop \\ Department of Computer Science \\ Thornton Hall \\ University of Virginia \\ Charlottesville, VA 22903-2442 USA \\ $~$\\ Phone: (804) 982-2200 \\ Email: pdw96@cs.virginia.edu \end{quote} Cancellations must be in writing and must be received by March 31, 1996. \end{document} =============================================================================Article: 2949
Brad Hutchings wrote: > > Not using VHDL *is* throwing out the baby with the bathwater. > > Perhaps a better analogy is ADA. But if the only complaint people can > come up with is verbosity, than VHDL must otherwise be pretty good, > right? Sure VHDL is a 2-hump camel but C with when-wait-whatever is > probably a 3-hump camel. :-) And, there is *no* installed base of > C-to-hardware synthesis tools. Don't we want to leverage VHDL > synthesis tools that are already out there? We currently have some > decent synthesis capability that has taken *over* 10 years to appear. > If we try and do this again with yet another language, we would have > years to wait before tools start to appear. > > I'm still waiting to hear what people *don't* like about VHDL. I disagree when it comes to languages that compile to an exacutable, VHDL and verilog are not even on the list. I think its that third hump you have to get over. Like VHDL and verilog are just local minima. Even if you could write a whole program in VHDL and compile it and link it to an operating system there are no provisions for passing VHDL varibles to other system calls. Talk about waiting for something to happen when do you suppose synopsys will support linking a VHDL "program" to some operating system. Synthesis tools can be put together fast enough (ala synplicity (sp)) that it would not take any more than two years for a company with resources to pulg synthesis into C. What I don't like about VHDL is the user base is 10,000 if your lucky and might be 25,000 by the year 2000. I don't have to tell you how many C programmers there are. I'm not proposing C-to-hardware I proposing C-that-understands-hardware. Something that complies to an executable that a user can run that a programmer can program and use all the routines laying around. Try and open a file in VHDL or put red on the screen. Don't happen might never happen. Steve Casselman Virtual Computer The views expressed are those of my employer since I am he:)
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