Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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/tmcc
Article: 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: 2930In 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: 2935In 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.net
Article: 2937I 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: 2942We 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/tmcc
Article: 2945If 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 Applications
Article: 2947In 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: 2949Brad 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