1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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

Custom Search

# Messages from 2925

Article: 2925
Subject: SYNARIO tool for CPLD and FPGA ?
From: Sebastien SALAS <sebas@aime.insa-tlse.fr>
Date: Fri, 01 Mar 1996 14:57:24 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Languages for reconfigurable computing.
From: drg@cs.toronto.edu (Dave Galloway)
Date: 1 Mar 96 14:38:50 GMT
Links: << >>  << T >>  << A >>
    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

#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
Subject: Re: High Level Languages
Date: 01 Mar 1996 15:25:59 GMT
Links: << >>  << T >>  << A >>
>>>>> "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

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
Subject: Re: Languages for reconfigurable computing.
Date: 01 Mar 1996 16:39:55 GMT
Links: << >>  << T >>  << A >>
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 Subject: Re: High Level Languages From: hutch@timp.ee.byu.edu (Brad Hutchings) Date: 01 Mar 1996 16:42:37 GMT Links: << >> << T >> << A >> 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 Subject: Re: Comp.Arch.FPGA From: peter@xilinx.com (Peter Alfke) Date: 1 Mar 1996 18:11:15 GMT Links: << >> << T >> << A >> 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, Xilinx  Article: 2931 Subject: Re: ORCA and 3.3V logic From: peter@xilinx.com (Peter Alfke) Date: 1 Mar 1996 21:13:28 GMT Links: << >> << T >> << A >> 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?
>
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 Applications


Article: 2932
Subject: Reconfigurable Computing Languages
From: sc@vcc.com (Steve Casselman)
Date: Fri, 1 Mar 1996 21:42:42 GMT
Links: << >>  << T >>  << A >>
> 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 Casselman


Article: 2933
Subject: Re: JEDEC Specification?
From: Andy Gulliver <andy.gulliver@crossprod.co.uk>
Date: Fri, 01 Mar 1996 14:14:02 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: ORCA and 3.3V logic
From: husby@fnal.gov (Don Husby)
Date: 1 Mar 1996 22:30:48 GMT
Links: << >>  << T >>  << A >>
peter@xilinx.com wrote:
>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
Subject: Re: Comp.Arch.FPGA
From: lazzaro@snap.CS.Berkeley.EDU (John Lazzaro)
Date: 2 Mar 1996 00:33:10 GMT
Links: << >>  << T >>  << A >>
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.

--
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

Xref: netcom.com comp.arch.fpga:3089

Article: 2936
Subject: Re: Comp.Arch.FPGA
From: jma@ (Jeffrey Arnold)
Date: 3 Mar 1996 01:30:50 GMT
Links: << >>  << T >>  << A >>

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


Article: 2937
Subject: Re: High Level Languages
From: ejessen@ix.netcom.com (Erik Jessen)
Date: Sun, 03 Mar 1996 08:45:26 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: ORCA and 3.3V logic
From: ejessen@ix.netcom.com (Erik Jessen)
Date: Sun, 03 Mar 1996 08:48:46 GMT
Links: << >>  << T >>  << A >>
husby@fnal.gov (Don Husby) wrote:

>peter@xilinx.com wrote:
>>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 Jessen


Article: 2939
Subject: Re: Reconfigurable Computing Languages
From: ejessen@ix.netcom.com (Erik Jessen)
Date: Sun, 03 Mar 1996 08:54:13 GMT
Links: << >>  << T >>  << A >>

>> 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 Jessen


Article: 2940
Subject: Re: Reconfigurable Computing Languages
From: sc@vcc.com (Steve Casselman)
Date: Sun, 3 Mar 1996 20:27:57 GMT
Links: << >>  << T >>  << A >>

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

>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

>#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
Subject: Re: Reconfigurable Computing Languages
Date: 04 Mar 1996 15:07:36 GMT
Links: << >>  << T >>  << A >>
>>>>> "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,

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
Subject: Re: Languages for reconfigurable computing.
From: Richard Lazarus <rblazarus@tasc.com>
Date: Mon, 04 Mar 1996 09:14:05 -0800
Links: << >>  << T >>  << A >>
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

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.

Regards,
Rich

--
Richard B. Lazarus
rblazarus@tasc.com


Article: 2943
Subject: Re: Languages for reconfigurable computing.
From: billms@nixon.icsl.ucla.edu (Bill Mangione-Smith)
Date: Mon, 4 Mar 1996 19:39:14 GMT
Links: << >>  << T >>  << A >>
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.

Bill


Article: 2944
Subject: Re: Reconfigurable Computing Languages
From: drg@cs.toronto.edu (Dave Galloway)
Date: 4 Mar 96 21:55:41 GMT
Links: << >>  << T >>  << A >>
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

>#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: 2945
Subject: Re: Comp.Arch.FPGA
From: Paul Franklin <paul@cs.washington.edu>
Date: Mon, 4 Mar 1996 22:15:35 GMT
Links: << >>  << T >>  << A >>
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.

--Paul


Article: 2946
Subject: Re: Xilinx is NOT specified MINIMUM delay -
From: peter@xilinx.com (Peter Alfke)
Date: 4 Mar 1996 23:51:05 GMT
Links: << >>  << T >>  << A >>
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
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.

Peter Alfke, Xilinx Applications


Article: 2947
Subject: Re: ORCA and 3.3V logic
From: peter@xilinx.com (Peter Alfke)
Date: 5 Mar 1996 00:01:04 GMT
Links: << >>  << T >>  << A >>
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 Alfke  Article: 2948 Subject: PDW'96 From: robins@.cs.Virginia.EDU (Gabriel Robins) Date: Tue, 5 Mar 1996 04:10:08 GMT Links: << >> << T >> << A >>  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
Subject: Re: Reconfigurable Computing Languages
From: vcc <vcc@netcom.com>
Date: Tue, 5 Mar 1996 04:56:29 GMT
Links: << >>  << T >>  << A >>
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:)