Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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
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
Subject: Re: High Level Languages
From: hutch@timp.ee.byu.edu (Brad Hutchings)
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 
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
Subject: Re: Languages for reconfigurable computing.
From: hutch@timp.ee.byu.edu (Brad Hutchings)
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?
>
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 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:
>Well, if you had implemented that design in any Xilinx XC4000 device,
>there would be no problem. All XC4000 and XC4000E devices can drive, and
>can be driven by, any 3.3 V chips, even under worst-case conditions.

Well, If I used XC4000, I wouldn't be able to make my 16ns clock cycle
requirements, would I?

Perhaps this is true that X4000 is 3.3V compatible, but it doesn't say 
anywhere in the data sheets that XC4000 will not drive its outputs past 3.6V.
Where is this written?

On the subject, I found a good application note on the Quality Semiconductor
web site that tells how to use their quickswitch product as a 5V-to-3V
bi-directional translator with almost zero proapgation delay:
       http://www.qualitysemi.com/applications.html Application note AN-11.



Article: 2935
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.





-- 
-------------------------------------------------------------------------------
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: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
jma@radix.net





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:
>>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 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
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
Subject: Re: Reconfigurable Computing Languages
From: hutch@timp.ee.byu.edu (Brad Hutchings)
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,
    >> please... :-)

    SC> I say fix it. Don't throw out the baby with the bath water.

Not using VHDL *is* throwing out the baby with the bathwater.

    >> So, why do people seem to dislike it so much?

    SC> Can you say COBAL?

Perhaps a better analogy is ADA. But if the only complaint people can
come up with is verbosity, than VHDL must otherwise be pretty good,
right? Sure VHDL is a 2-hump camel but C with when-wait-whatever is
probably a 3-hump camel. :-) And, there is *no* installed base of
C-to-hardware synthesis tools. Don't we want to leverage VHDL
synthesis tools that are already out there? We currently have some
decent synthesis capability that has taken *over* 10 years to appear.
If we try and do this again with yet another language, we would have
years to wait before tools start to appear.

I'm still waiting to hear what people *don't* like about VHDL.



Article: 2942
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 
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.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
    >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: 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
. 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: 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:)




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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