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
2017JanFebMarApr2017

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 3025

Article: 3025
Subject: Electronic Packaging Technologies Course in San Francisco
From: course@garnet.berkeley.edu ()
Date: 15 Mar 1996 19:20:12 GMT
Links: << >>  << T >>  << A >>
University of California (Berkeley) Extension announces

"Electronic Packaging Technologies: BGA,
CSP, Flip Chip and MCM-L"

May 6-8, 1996 San Francisco Airport Area, California

a comprehensive three-day course with an experienced 
world authority and author, Dr. John Lau. Lau is founder/
President of Express Packaging Systems, an author 
of over 100 technical publications and author/editor
of nine books. The has 25 years of R&D Experience and
was a technical editor of ASME Transactions, Journal
of Electronic Packaging, and IEEE  transactions on 
Components, Packaging and Manufacturing Technology.
His books "Ball Grid Array Technology" and "Flip Chip
Technologies", both published by McGraw-Hill Book
Company and more than 300 pages of course notes will
be provided to each enrolled participant. 

You will be able to apply material in this course
in practical situations, and choose the right cost-
effective high-performance packaging technique for
your interconnection systems.  

Bring your technical problems to the seminar.

Topics covered include IC trends, chip-level 
interconnects,  conventional packages, emerging
packages:BGAs, advanced packages:CSPs, Flip
Chip Technologies (FTC), Multichip Module 
Technologies, future packaging directions,
open discussions. 

Further information:  For a brochure describing
this course, send your postal address to


Article: 3026
Subject: experience with Actel Act2 family
From: "David F. Spencer" <starfire2@earthlink.net>
Date: 16 Mar 1996 00:18:56 GMT
Links: << >>  << T >>  << A >>
Hi everyone.

We're using the Actel Act2 family of FPGAs and I was wondering if anyone 
had any experiences with them (good or bad).  The chip we're  
specifically using is the 1240A.  It seems to be fairly capable but it 
has a lot of drive limitations, etc.  Are these typical of other FPGA 
vendors?

Any responses would be appreciated.

Thanks.

Dave Spencer
starfire2@earthlink.net




Article: 3027
Subject: Re: INDUSTRY GADFLY: "From Beirut To Bosnia" + Reader Response
From: jwill@netcom11.netcom.com (John Williams)
Date: Sat, 16 Mar 1996 09:01:53 GMT
Links: << >>  << T >>  << A >>
Thanks, John.

We should learn our lesson from Quebec and not push the Verilog thing too
hard. Still, I think, like Quebec, there will be more VHDL users who are
bilingual.

						John Williams


Article: 3028
Subject: Re: Pointers?
From: Brad Taylor <blt@emf.net>
Date: Sat, 16 Mar 1996 10:52:02 -0800
Links: << >>  << T >>  << A >>
Mike Butts wrote:
>
> Examples like little arithmetic functions are well and good,
> but real C programs have pointers.  Pointers that can be
> assigned to at run time, with run-time-computed values.
> I'm certainly not a compiler expert, but those who are cite
> pointer aliasing as a substantial impediment to automatic
> parallelization of old code.
> 

I agree, code with pointers will never be able to be fully 
parallelized.  The situation is not entirely bleak however.


It may be necessary to run old code (with pointers) on a FPGA based
processor.  This will be the case when it (the FPGA processor) is the
only hardware available to run the code, and when real world 
constraints require you to run a pre-existing program.  New code can
simply avoid using global pointers.

When pointers are used, there are a few things that can be done.
- The sequential program might be accelerated up to the speed of 
   a single memory port.  This in itself can be a pretty agressive goal.
- The width of the memory can be increased
- The speed of the memory can be increased.
- Caching can be implemented
Sounds like as CPU eh.

The main thing about pointers is that they physically refer to the 
address lines of a RAM.  Everthing is fine as long as only one
pointer is enabled at any point in time.  This can be enforced by the 
C compiler.  Of course multiple independent C programs can run 
concurrently, but ideally we want to have multiple memories, or pointers
running concurrently within the same program.

In is important to note that if the range of pointers could be 
restricted to a discrete memory space, then multiple pointers could be 
accessing different banks of memory at the same time.
But C has no method of restricting pointer range except possibly 
that no pointer can point to data not declared 
as memory space, or malloced. If memory is malloced, then the pointer 
range is known if it can be traced to the pointer returned by malloc().

Array are not a problem, and they can usually be used instead of 
pointers in new code.  This is because arrays have their range known
at compile time. Thus the code 

int out[0x100][0x100][0x100];
int in0[0x100][0x100][0x100];
int in1[0x100][0x100][0x100];
.....
 out[x][y][z]=in0[xx][yy][zz]+in1[xxx][yyy][zzz];
 
can run in one clock(pipelined) if out,in0 and in1 were allocated by the 
user-linker-compiler to be in different physical banks of memory.

A common use of pointers is for indexing into tree structures.
statements such as "a=****b;" are found.  If the range of each pointer
can be restricted,  then this statement can be physically implemented 
in a set of 4 linked memories.  When pipelined, the structure can run 
very fast.

In summary, worst case is that pointers force a program to run at the 
speed of a single bank of memory, best case is that a system with N banks
can run them all concurrently.  You might note that a Quad Alpha using 
pointers into DRAM will run about as fast as a 286.  If the FPGA 
based system has multiple banks of DRAM, it at least has a chance of 
running faster.
Of course none of these issues have  really been worked out and won't
until we really do the work of writing a real C compiler for FPGA
based systems.

By the way, global pointers are a good example of a coding practice
that generate a lot of unnecessary bugs. 

I hope I haven't bored you -

Brad Taylor


/===============================<>=================================\
|            Brad Taylor                          blt@emf.net      |  
\===============================<>=================================/


Article: 3029
Subject: pointers and fpgas
From: Maya Gokhale <maya@Sarnoff.COM>
Date: Sun, 17 Mar 1996 23:05:01 GMT
Links: << >>  << T >>  << A >>
MB> Did I read someplace that Java has no pointers?

Java doesn't have explicit pointers. It has object references and 
automatic memory management via heap and garbage collection. I looked at 
the Java Virtual Machine for a while, trying to figure out whether it was 
worthwhile to build an FPGA-based interpreter for Java. I concluded that 
it probably wasn't because of the complexity of the memory management- 
everything is dynamically allocated and all accesses are through 
pointers. 

BLT>It may be necessary to run old code (with pointers) on a FPGA based
BLT>processor.  This will be the case when it (the FPGA processor) is the
BLT>only hardware available to run the code, and when real world 
BLT>constraints require you to run a pre-existing program.  New code can
BLT>simply avoid using global pointers.

I think it is an unlikely scenario (even for us hard core FPGA types :-) 
that an FPGA processor is the only one available. There will *always* be 
a 2/3/486 somewhere. I also don't hold out much hope for running dusty 
deck C code on an FPGA if you want performance. 

Optimization in the presence of general unrestricted pointers is not a 
solved problem, though there was a flurry of interest in the compiler 
community about this topic 5-6 years ago. I think a more interesting (and 
tractable) but still difficult problem  is to actually generate the hardware 
that pipelines a loop, so that memory read/compute/write occur concurrently.
Are there any C-to-hardware compilers out there that do that?

Maya

----------------------------------------------------------
Maya B. Gokhale             David Sarnoff Research Center
maya@sarnoff.com            CN5300
                            Princeton, NJ 08543
                            609-734-3119
----------------------------------------------------------



Article: 3030
Subject: Re: Xact6.o too slow
From: fliptron@netcom.com (Philip Freidin)
Date: Mon, 18 Mar 1996 01:26:39 GMT
Links: << >>  << T >>  << A >>
Per the Subject line, several people have found parts of the XACT 6.0
system too slow. Here is some info and observations. I am not an employee
of Xilinx, and so am clearly NOT speaking for them. I was an alpha and
beta tester for this release and prior releases, and have some insight
into how some of this stuff works. That info is covered by an NDA that I 
have signed with Xilinx, and I will not be drawing upon that info, nor is 
it relevant to this message. The info I present here is based on my own
observations.

All the below is with regard to the PC version, using the Viewlogic 
schematic capture, and simulation software, not the UNIX version. The 
WIR2XNF program metioned below is unique to the viewlogic version, ORCAD 
and other sch/sim packages do not use it.

1) Xilinx's goal for XACT STEP 6.0 seems to have been to make it far
easier for a new user to get started with the tools, and focused on having
everything run under windows. 

2) a significant part of the software is still DOS based, and runs in
dos-boxes under windows.

3) the prior two releases of XACT were V5.1 and V5.1.1.  V5.1 had
significant functionality improvements over V5.0, and V5.1.1 was
primarilly the release that added the windows based Viewlogic ProSeries
software. 

4) underlying the XACT STEP 6.0 release is the V5.2 version of the
programs, which include bug fixes and functionality improvements over the
V5.1 release. (I am not aware of any such changes between 5.1 and 5.1.1)

5) as an active user of these systems (I designed over 150 FPGAs for my
clients last year), it may be interesting to note that I ignored the 5.1.1
release of the software because I could not tollerate the drop in
productivity that it caused. I feel the same way about the 6.0 release,
but NOT the underlying V5.2 executables (except for WIR2XNF)

6) the drop in productivity (for me, not necessarilly for others) is a
side effect of my design methodology, and project management style, not
the execution time of the programs. Given the way I do designs, the V5.2
executeables all run about the same time as their prior V5.1 version,
except for WIR2XNF. I do not use the XDM program, or the 6.0 design
manager, because they do not give me the control I want over the tools,
and the batch capabilities of building designs (multiple at a time) from
automated scripts, including source control, simulation, timing analysis,
and some automated documentation generation. My scripts also include some
of my own sw that is used in intermediate stages of the flow. Typical
users of the Xilinx products find the Xilinx provided automatic flows
quite sufficient to produce good results. My mileage is different (and for
me, better).

Now.... on with the subject at hand....

Pierre Cluzel wrote:
> I've been using XACT step 6.0.0 for one month ( XACT 4.0 for several
> years) and my first work has been to test the software with the tutorial
> example CALC.1.
> 	I have never experienced crashes during schematic editing but the
> implementation software is very VERY SLOW . My machine configuration is
> : Processor Intel 486 DXII 66 MHz, RAM 32 Mb , dos version 6.2, Windows
> Version 3.1.
> 	PPR running with DOS (xdm) takes about 2-3 min. to implement the
> tutorial calc.1 into a 3020APC68 , and more than 1 hour 30 min. to do
> the same job in the Windows version...!!

Georg Acher responded
>Maybe you had just bad luck, PPR never does the same routing again
>(except you set the seed=... option). If PPR is swapping all the time,
>your disk cache (SMARTDRV) is maybe too big, so there's not much memory
>left for PPR, that can cause 'trashing'... Then you should set the DOS-box
>priority to 90-100, if you really want quick results. 

Philip Freidin writes:
Actually, PPR does do the same routing unless the control variable
   router_effort
is set to 3 ( or maybe 4, I'm not sure). The default is 2, and that
will route the same way each time, given the same design and placement. 
it is not seed dependent.

The swapping is a MUCH more likely scenario. This unfortunately is highly 
dependent on how you setup a DOS extended memory manager. for example, if 
you are using QEMM, it will try and supply both EMS and XMS services, and 
will default to 8 megabytes of XMS, regardless of whether you have 16Mb 
or 32 Mb of memory. I was unable to get the combination of Windows For 
Workgroups (WFW V3.11) , XACT STEP 6.0, and QEMM (V6, V6.02, V7, V7.5, I 
will never buy QEMM again, they can go shove their V8.0 upgrade offer 
where the sun doesnt .. ... ..) to work togther well enough to do any 
worthwhile testing. It ran extremely slow, like your 3 minute job that 
now takes an hour. I run WFW 3.11 and XACT STEP 6.0 with the himem.sys 
and emm386.exe and the the long place and route times went away and it 
ran in pretty much the same time as the older V5.1 programs. 

Georg's suggestion about thrashing is also possible. I like using the
command
   mem /c
to find out whats happening to my memory. This can also be real 
informative inside a DOS box in windows.

Pierre Cluzel wrote:
> Is my machine badly configured or Xactstep is really too slow ?
Georg wrote
>The new WIR2XNF.EXE is deadly slow, it takes about 5-10 times longer to
>convert the files than in V5.1. My harddisk is heavy accessed (sounds like
>the seek-tests...) and nothing helps to speed it up, no matter whether I
>use DOS, WINDOS, even SMARTDRIVE with 16MB cache didn't help :-( No I use
>the old WIR2XNF ;-)

Philip Freidin writes:
I found EXACTLY the same behaviour with WIR2XNF, 10 times slower than the 
prior version. As I said above, only WIR2XNF has this problem, the rest 
of the programs run about the same as the prior versions (which for me is 
acceptable). I also have solved the problem by continuing to use the V5.1 
version of WIR2XNF. During the beta testing of the 6.0/5.2 version of the 
software, this was not the case, but unfortunately there were other 
issues that caused a change to the way WIR2XNF was built, and this change 
caused the execution time problem. I reported it to Xilinx, but 
unfortunately the CDs were already in mass production. 

Georg writes
>That's my general complaint about the XACT-tools: They are too slow. Even
>on a Pentium/100 it takes about 30-40 seconds from starting PPR until it
>starts with placing. XNFPREP always needs 40s, no matter if it's just a
>design with one gate or 4000 gates. The funny colorfull new 'flow manager'
>is a nice gimmick, but when I have my makefile, I run it from DOS with
>xmake, because it's faster... 

Philip Freidin writes:
I have learnt to live with the start up times, and like Georg, i run my 
stuff under DOS, with batch files (which is fairly similar to xmake, only 
faster).

Mike Siersema writes:
>We used Xact 6.0 windows version and we discovered that it is too slow.  
>Upon the advice of industry experts utilizing FPGA's, we do not compile 
>our designs in the windows version because it is too slow.

Philip Freidin writes:
Who are these experts??? I want to meet some  :-)

Mike Siersema writes:
>Futhermore, ProSim is not usable.  Simulating in ProSim is a nightmare. 
>Some of our functional simulations (simulations done before routing) would
>take 20 minutes to update on the screen and if you wanted to print the
>waveform of zoom in to a specific time period, that would take another 20
>minutes to update.  I called the Xilinx support line to confirm that this
>windows version is too slow and they agreed. 

Philip Freidin writes:
Prosim and Procapture are the V5.1.1 escape (sorry, release) that I 
mentioned above that I dont use. Much of the problems I had with Prosim 
were related to the above mentioned memory problems. When I fixed the 
memory problems, I found that Prosim ran almost exactly the same as the 
prior DOS version of the software (Viewlogic's version 4.13, released by 
Xilinx in V5.0, V5.1).

Mike Siersema writes: 
>The solution to your problem is to use Workview 5.1.0 dos version for
>your functional simulations and Procapture for your schematic capture. 
>You can use any dos editor for your ABEL files. You can compile and merge
>in any dos version of Xact. 

Philip Freidin writes:
Unfortunately Procapture has some functional problems that I cant live 
with. These are in the domain of the 'save as' command (previously the 
'writeto' command) and the importing of design databases from prior 
versions. both of these are fundamentally broken. So I use the 4.13 
(Xilinx V5.1) Viewdraw and viewsim, together with the V5.2 programs from 
the 5.2/6.0 release, all under DOS.

Mike Siersema writes: 
>The real question is how will Xilinx create a more user friendly FPGA
>compile and simulation system without compromising too much speed.  If
>they do not create better software, somebody will. 

I believe all the speed issues are DOS/Windows configuration related, and
the actual run times are within a few percent of each other (except
WIR2XNF). I am far more worried about the loss of functionality for the
power user who relies on complex project scripts and other tools, as well
as the management of legacy designs. I dont particularly want to keep a
copy of each and every release around, because as the software is (like 
in hollywood) dumbed-down to make it easier for new users to use, mission 
critical capabilities are going by the wayside (i.e. batch control, 
backward compatibility, execution performance, ...)


Lance Gin wrote:
>bonjour pierre,
>we are a new xilinx customer and are about to embark on the design of an
>XC4025E (a relatively large xilinx device). i can't give you any details
>since we don't have any experience yet. however, i can tell you that when
>i called the xilinx tech hotline and asked for a platform recommendation,
>they told me that they highly recommend we use xact 5.2 (unix) rather than
>xact 6.0 (PC). apparantly, some customers have been experiencing performance
>problems on P5 PC's with 64mb+ RAM. I do believe xilinx is recommending a
>minimum of 64Mb RAM (don't know details on swap setup). hope this helps.

Philip Freidin writes (again)
And my recomendation is for a new user to use 6.0 to get familiar with 
the tools, and if it works for you, then keep going. if not then the 5.2 
programs under DOS are also an option. I have done a 4025E designs on a 
Pentium (tm) 90MHz, with 32MB ram. I used 80% of the chip, almost no I/O
and it took about an hour to place and route. it used 22MB of dynamic 
memory, ontop of the 3MB of baseline memory. Your mileage will vary. 64MB 
on a sun is probably somewhat safer. I dont have a 64MB PC to let you 
know how well the sw runs.


Is this the longest article I have written???



Article: 3031
Subject: Re: Xact6.o too slow
From: comtech@freenet.ufl.edu (Robert Bachus)
Date: Mon, 18 Mar 1996 02:58:35 GMT
Links: << >>  << T >>  << A >>
ecla@world.std.com (alain arnaud) wrote:

>Pierre Cluzel (cluzel@ipnl.in2p3.fr) wrote:
>: I've been using XACT step 6.0.0 for one month ( XACT 4.0 for several
>: years) and my first work has been to test the software with the tutorial
>: example CALC.1.
>: 	I have never experienced crashes during schematic editing but the
>: implementation software is very VERY SLOW . My machine configuration is
>: : Processor Intel 486 DXII 66 MHz, RAM 32 Mb , dos version 6.2, Windows
>: Version 3.1.
>: 	PPR running with DOS (xdm) takes about 2-3 min. to implement the
>: tutorial calc.1 into a 3020APC68 , and more than 1 hour 30 min. to do
>: the same job in the Windows version...!!
>: Is my machine badly configured or Xactstep is really too slow ?
>: Could some people do the same test and reply me the result for
>: comparision and eventually modify my configuration files.

>	The max difference in performance between running under dos or
>	or window should be between 10-15%. that is xact5.2 under dos will
>	be that much faster on average than xact 6.0 under windows.

>	this seems that the problem is probably due to either low
>	conventional memory or a small swap space. Initial beta versions
>	of XACT 6.0 were 30% slower than xact5.2 but that got fixed before
>	the production release.

>	--Alain Arnaud

Please tell me more, this guy has 32M Ram installled, so what
conventional memory are you refering to, since Xilinx has always used
memory extenders? We too have had to put version 6.0 away because it
was so slow. So please tell me what machine and what your settings
were/are to get performance that is only 10-15% slower. BTW, just for
grins explain why it's acceptable to have it (version 6.0) run slower
under any conditions. Thanks.



Article: 3032
Subject: Re: experience with Actel Act2 family
From: ecp@focus-systems.on.ca (Eric Pearson)
Date: Mon, 18 Mar 1996 05:01:37 GMT
Links: << >>  << T >>  << A >>
In article <4id1dg$caj@bolivia.it.earthlink.net>,
David F. Spencer <starfire2@earthlink.net> wrote:
>Hi everyone.
>
>We're using the Actel Act2 family of FPGAs and I was wondering if anyone 
>had any experiences with them (good or bad).  The chip we're  
>specifically using is the 1240A.  It seems to be fairly capable but it 
>has a lot of drive limitations, etc.  Are these typical of other FPGA 
>vendors?
>

Hi David...

I have had good experiences with the Act2 parts. Once you get over the
hurdle of "non-reprogramable", they are an excellent workhorse part.

We often use 100% of the logic modules and implement brand new designs 
into fixed PCBs (no pinout problems). The P&R software works well.

The simple cell structure (4 input mux) is easy to optimize your design
for. Although we only push the parts to 40+ Mhz, there is lots of
headroom especially with their new XL parts (half the price, twice the
speed ;)..

We did spend some upfront work on dealing with the long input hold and
output delay timing. Turns out that a minimum pin2pin path closely
tracks the clock tree prop delay. Using a cheap PLL gives us an easily
integratable part (but puts bounds on freq range).

Guess I'm an advocate

Eric Pearson.

	  
>


-- 
Eric Pearson -- Focus Systems -- Waterloo, Ontario
     ecp@focus-systems.on.ca  (519) 746-4918
    "We Engineer Innovative Imaging Solutions"


Article: 3033
Subject: Re: Reconfigurable Computing Languages
From: guccione@xilinx.com (Steve Guccione)
Date: 18 Mar 1996 13:17:46 GMT
Links: << >>  << T >>  << A >>
In article <4hnr7o$svp@solaris.cc.vt.edu>,
>Has anyone considered C's bit-field members?  Sure, they're only valid in struct
>declarations, but if the user is going to explicitly code for 13-bit values, he/she
>can cope with accessing a structure's member.
>
>The following is valid ANSI C code:
[...]

I always thought that Ada covered this area very well.  It even
permits specification of floating AND fixed point.  See Chapter 13 of
the Ada LRM.

-- Steve
-- 3/18/96




Article: 3034
Subject: Re: Reconfigurable Computing Languages
From: guccione@xilinx.com (Steve Guccione)
Date: 18 Mar 1996 13:35:17 GMT
Links: << >>  << T >>  << A >>
In article <4hnpp3$ems@fs7.ece.cmu.edu>,
Herman Schmit <herman@galant.ece.cmu.edu> wrote:
>Steve Casselman (sc@temp.vcc.com) wrote:
>: > From: ejessen@ix.netcom.com (Erik Jessen)
>: > 
>: > 1) Try implementing everything in VHDL, 
>
>: This is fine for new programs but I want to be able to port the
>: "billions and billions" of lines of code already out there.
>
>Steve,
>
>Abandon all hope of porting compute-intensive code to reconfigurable
>machines.  I've looked at a lot of integer-oriented, compute-intensive
>algorithms, and although you can often get whiz-bang speed-ups using
>FPGAs, you can't do it from the C code written for a CPU.  The more
>compute-critical something is, the more people pound on it, and the
>more machine-specific the code gets.
[...]

I agree that using "dusty deck" code may not be a good idea.  But one
of the interesting aspects of reconfigurable logic based computing is
that you don't have to map an algorithm to a sequence of arbitrary
operations (instructions).  You can start with the high level (and
hopefully simple) algorithm, and map it directly to the hardware.

The "sound bite" here is that you can map the architecture to the
algorithm.  Instruction set processors require that you map the
algorithm to the architecture.  The former should be simpler and more
efficient.

-- Another Steve
-- 3/18/96


Article: 3035
Subject: Problems with Altera Bitblaster
From: klindwor@tech17.informatik.uni-hamburg.de (Andre Klindworth)
Date: 18 Mar 1996 15:32:35 GMT
Links: << >>  << T >>  << A >>

We have a couple of small design projects where we use the 
in-circuit reconfigurable CPLDs MAX9320 and MAX9560 from
Altera. Everything works fine until we are trying to download
the design data via the Bitblaster. It seems like the download 
is extremely sensible to noise since we observed that only 1
out of 5 download attempts succeed (as reported by post-download verification
of the MAX+plusII v6.0 programmer). We allready added small
capacitors to the download wires (50 pF) and - as suggested by
Altera support - also added pull-up/pull-down and serial resistors.
None of these measures improved the robustness of the download
procedure. Naturally, we tried several devices and boards so that
device or board defects are not to blame for the troubles.

Has anybody faced this kind of problem before or has an idea
what may cause the problems?

Thanks,
Andre'
-- 
---------------------------------------------------------------------------
Andre' Klindworth                       Universitaet Hamburg, FB Informatik
klindwor@informatik.uni-hamburg.de      Vogt-Koelln-Str.30, D-22527 Hamburg
http://tech-www.informatik.uni-hamburg.de/Personal/klindwor/Klindworth.html


Article: 3036
Subject: Re: Xact6.o too slow
From: sheynin@fp.co.nz (OS)
Date: Mon, 18 Mar 1996 13:23:47
Links: << >>  << T >>  << A >>
I know Xilinx people read/participate here regularly. Would they like 
to comment on the issue discussed please?
  ---------------------------------------------------
  Oleg Sheynin           |Fisher & Paykel
  sheynin@fp.co.nz       |Production Machinery Ltd.
                         |PSC Section
  Phone +64-9-535 0676   |P.O. Box 58-223, Greenmount
  Fax   +64-9-535 0661   |Auckland, New Zealand
  ---------------------------------------------------



Article: 3037
Subject: Re: Problems with Altera Bitblaster
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 19 Mar 1996 02:24:18 GMT
Links: << >>  << T >>  << A >>
In article <4ijvmj$ado@rzsun02.rrz.uni-hamburg.de> klindwor@tech17.informatik.uni-hamburg.de (Andre Klindworth) writes:
>
>We have a couple of small design projects where we use the 
>in-circuit reconfigurable CPLDs MAX9320 and MAX9560 from
>Altera. Everything works fine until we are trying to download
>the design data via the Bitblaster. It seems like the download 
>is extremely sensible to noise since we observed that only 1
>out of 5 download attempts succeed (as reported by post-download verification
>of the MAX+plusII v6.0 programmer). We allready added small
>capacitors to the download wires (50 pF) and - as suggested by
>Altera support - also added pull-up/pull-down and serial resistors.
>None of these measures improved the robustness of the download
>procedure. Naturally, we tried several devices and boards so that
>device or board defects are not to blame for the troubles.
>Thanks,
>Andre'

Go get a fast scope (500 MHz DSO), ground it with a very short line to 
the chip ground, and then look at the rising AND falling edges of the 
configuration clock signal, at the chip pins. Set the scope fast enough 
to see 2 to 4 nS weirdness during the rising and falling edges. If you 
see anything other than monotonic transitions, then this is where to 
start. You may need to either terminate the clock line, or buffer it 
locally to the CPLD. You should also check the data transitions, with 
regard to setup and hold to the clock's rising edge. Check also any pin 
that starts or resets the programming function, and make sure they dont 
have glitches on them. Also check VCC and make sure it is clean, and 
within spec. Monitor it (at the chip) during configuration.

Good luck
	Philip Freidin




Article: 3038
Subject: Troubles with Altera Bitblaster
From: klindwor@tech17.informatik.uni-hamburg.de (Andre Klindworth)
Date: 19 Mar 1996 09:27:41 GMT
Links: << >>  << T >>  << A >>

We use Altera MAX9000 CPLDs for a couple of designs, but have
a lot of troubles with downloading the configuration data via
the Bitblaster. On average, only one out of 5 programming attempts
succeed. 80% of the downloads end up with a "Device not in socket"
or verification errors. We allready added small capacitors (50 pF)
an serial as well as pull-up/pull-down transistors to the download
wires, but none of these measures increased the robustness of the
programming procedure.

Naturally, we tried different boards to exclude device or board
errors.

Has anybody experienced similar problems or has an idea what may
go wrong? Any help/suggestions appreciated.

Cheers, Andre'.

-- 
---------------------------------------------------------------------------
Andre' Klindworth                       Universitaet Hamburg, FB Informatik
klindwor@informatik.uni-hamburg.de      Vogt-Koelln-Str.30, D-22527 Hamburg
http://tech-www.informatik.uni-hamburg.de/Personal/klindwor/Klindworth.html


Article: 3039
Subject: Re: Sq. Roots and Languages
From: drg@cs.toronto.edu (Dave Galloway)
Date: 19 Mar 96 15:34:46 GMT
Links: << >>  << T >>  << A >>
Last week, Herman Schmit <herman@galant.ece.cmu.edu> posted an article with
a simple integer square root function written in C and Verilog.  Just for
fun, I thought I'd try the C version out with the Transmogrifier C compiler.

I made the minimal changes necessary to re-write it in tmcc's subset of C.
The modified source is below.  I then had to fix not one, but two bugs in
the compiler (good example, Herman!).

I compiled the program for 3 different sizes of inputs and outputs, and
used Altera's MaxPlus 6.0 to fit the netlist into one of their new 10K50
parts.  These are the results, according to MaxPlus:

Input bits/Output bits	LCs	FFs	cycle time (ns)

	32/16		1275	263	278
	16/8		 626	135	172
	 8/4		 289	 71	127

An LC is what Altera calls a 4 bit lookup table and FF combination.
Approximately one half of a Xilinx 4000 CLB.

The cycle time is pretty long, since the compiler is trying to cram these three
cascaded additions, a subtraction and an optional addition all into the
same cycle:

    n = (u + u + v) << l2;
    n += u2;
    if (n <= N) {
      u += v;

I also tried adding some statements to the program to break up that long
combinational path, hoping to decrease the cycle time (while increasing
the number of cycles).  That version of the code is also below, and the
results are:

Input bits/Output bits	LCs	FFs	cycle time (ns)

	32/16		1249	298	155
	16/8		 610	154	 96
	 8/4		 283	 82	 60

In the first, minimally modified version, the circuit does a square root in
roughly 2 * log2(input) cycles.  In the second version, the circuit takes
roughly 4 * log2(input) cycles.

So now, does anyone have a Verilog compiler that can handle Herman's Verilog
version ?  The only Verilog compiler I can find here is a rather old one
of Exemplar's, and it won't synthesize while statements.  I'd be interested
in any results.

Here is the tmcc code for the first version of the circuit, in the 32/16 size
(32 bit arguments, 16 bit results):

/****************************************************************************
 *
 *  Filename: binomial.c
 *  Original Author: Peter Heinrich, Dr Dobbs Journal, April 1996.
 *
 *****************************************************************************/

#pragma intbits 16

int
sqroot(N)
#pragma intbits 32
	int N;
{
  int l2, t, u, v, u2, n;

  if (2 > N)
    return N;

  t = N;
  l2 = 0;
  while (t >>= 2)
    l2++;

  u = 1 << l2;
  v = u;
  u2 = u << l2;
  while (l2--) {
    v >>= 1;
    n = (u + u + v) << l2;
    n += u2;
    if (n <= N) {
      u += v;
      u2 = n;
    }
  }
  return (u);
}

main() {
  int i,t;
  
	outputport(t);

	while(1) {
		i = 4;
		while(i<50) {
	    		t = sqroot(i);
			i++;
			}
		t = sqroot(0xffffffff);
	}
}

Here is the modified version with a faster clock, but more clock cycles:

/****************************************************************************
 *
 *  Filename: binomial.c
 *  Original Author: Peter Heinrich, Dr Dobbs Journal, April 1996.
 *
 *****************************************************************************/

#define TICK	while(0);

#pragma intbits 16

int
sqroot(N)
#pragma intbits 32
	int N;
{
  int l2, t, u, v, u2, n;

  if (2 > N)
    return N;

  t = N;
  l2 = 0;
  while (t >>= 2)
    l2++;

  u = 1 << l2;
  v = u;
  u2 = u << l2;
  while (l2--) {
    v >>= 1;
    n = (u + u + v) << l2;
    TICK;
    n += u2;
    TICK;
    if (n <= N) {
      u += v;
      u2 = n;
    }
  }
  return (u);
}

main() {
  int i,t;
  
	outputport(t);

	while(1) {
		i = 4;
		while(i<50) {
	    		t = sqroot(i);
			i++;
			}
		t = sqroot(0xffffffff);
	}
}

And here, in case anyone wants to try a Verilog compiler, is Herman's Verilog:

module main;

   function [15:0] sqroot;
      input [31:0] N;
      
      reg [31:0] l2, t, u, v, u2, n;

      if (2 > N)
       sqroot = N[15:0];
      else
       begin
	  l2 = 0;
	  t = N;
	  t = t >> 2;
	  while(t > 0)
	   begin
	      l2 = l2 + 1;
	      t = t >> 2;
	   end
	  u = 1 << l2;
	  v = u;
	  u2 = u << l2;
	  while (l2>0)
	   begin
	      l2 = l2 - 1;
	      v = v >> 1;
	      n = (u + u + v) << l2;
	      n = n + u2;
	      if (n <= N)
	       begin
		  u = u + v;
		  u2 = n;
	       end
	   end
	  sqroot = u[15:0];
       end
   endfunction

   reg [31:0] i,t;
  
   initial
    begin
       for(i= 4; i<50; i=i+1)
         begin
	    t = sqroot(i);
	    $display("%d\t%d", i, t);
	 end
       $display("%d\t%d\n", 32'hffffffff, sqroot(32'hffffffff));
    end
      
endmodule 

Tmcc web page: http://www.eecg.toronto.edu/EECG/RESEARCH/tmcc/tmcc


Article: 3040
Subject: Re: Multiple FPGA Partitioning
From: David Pashley <david@fpga.demon.co.uk>
Date: Tue, 19 Mar 96 18:12:46 GMT
Links: << >>  << T >>  << A >>
In article <826915707.26778@codemast.demon.co.uk>
           RichAp@codemast.demon.co.uk "Richard Aplin" writes:

"ejessen@ix.netcom.com (Erik Jessen) wrote:
"
">Altera has software that will do the auto-partitioning for you.
"
"Hmmm. I did a design about 3-4 years ago that used an Altera EPM7256, and
"eventually overflowed it. The software routed it onto two chips, but the bugger
"_never_ worked. I spent ages hand-wiring a new 2-chip prototype, about three
"times longer triple-checking EVERY connection, and it simply did nothing. It
"wasn't a speed problem, it wasn't a race condition, I even got some other guys
"in the states to build one, and I never did find out what the problem was. The
"solution? I re-did the whole thing using Actel FPGAs, which got it all on one
"chip, ran faster, and saved the project.
"
"Never bothered with Altera for anything except glue logic since. Mind you, the
"FLEX series might be ok.
"
"Just my $0.02.
"
I don't think you're being fair to Altera. Working on this 
unforgiving basis, most people would run out of vendors quite early 
in their careers! 

Auspy looks to be a good partitioning system for Xilinx. Other 
vendors are MINC (IST) who do good partitioning for Xilinx, Actel, 
Altera FLEX, AMD MACH and Crosspoint; and ACEO, who I don't know 
much about. 

The main problem with partitioning is that the pin-to-logic ratio of 
today's FPGAs is too small, so don't expect to get the high device 
utilization that a single device solution affords, since the 
partitioner runs out of IO pins way before other device resources. 
However, in situations where filling isn't really an issue (such as 
ASIC prototyping), it's a valuable technique. 

David Pashley 



Article: 3041
Subject: Re: SYNARIO tool for CPLD and FPGA ?
From: Adam Zilinskas <aez@data-io.com>
Date: Tue, 19 Mar 1996 18:57:10 GMT
Links: << >>  << T >>  << A >>
Yves Bernard wrote:
> En ce moment, je suis en train d'évaluer ce produit pour des applications
> avec PLD de la compagnie ATMEL comme la famille 750 et 1500.
> 
> J'ai effectué des tests pour voir si le même projet conçu graphiquement
> (Senario) ou par des équations (ABEL-HDL) aurait les mêmes résultats.
> <snip summary ABEL good for little PLDs, Schematics may be good for FPGA>
> 
> Néanmoins, il y a une chose qui m'a beaucoup choqué du produit: La
> librairie de gates ne comprenait pas d'inverseur tri-state ou de "CMOS
> transmission GATE" aussi appelé "complementary pair"

Pardon responding in English, my French is too rusty and whatever I
say may be quite unreadable.

I work on Synario and submitted an enhancement request based on my translation:
=========================
Bug BUGno12572                     synario10                Enclosure 1 of 1
                                   Library

Found off comp.arch.fpga 3/15/96

Yves Bernard <elexrnd@CAM.ORG

Neanmoins, il y a une chose qui m'a beaucoup choque du produit: La
librairie de gates ne comprenait pas d'inverseur tri-state ou de "CMOS
transmission GATE" aussi appele "complementary pair"

Loosely translated with my rusty old french:

There is one large problem with the product: The
library of gates does not have tri-state inverters or the "CMOS
 transmission gate" also called "complementary pair"
=======================
I can't promise you when the libares will be corrected, but we heard you.

We presently have the following systems available in Synario
  Schematics
  ABEL
  VHDL

You can mix them somewhat, that is, you can have a hierarchical set of
 schematics with VHDL or ABEL modules in them.

I consider ABEL to be like Assembly language, it was designed for PLDs
 and has all sorts of tricks in it to handle the types of feedbacks 
 and logic seen in PLDs as you have mentioned.

Using a language like VHDL allows you to write more complex systems
 but at the exspense of having less control over the details (like writing
 in C++.

Schematics tend to be a mixed bag. We support libraries to map designs
 directly to particular FPGA devices. But if you use our "Generic" library,
 you may lose some fine tuning of details but we can ususally remap 
 your design quickly to a totally different FPGA architectures.

We are in a constant cycle of improving our system and we gladly 
accept enhancement requests like these.

You could submit ideas etc directly to us at  dsa@data-io.com
We also have a web page http://www.data-io.com that is presently 
undergoing a rebuild but you can request a 30-day evaluation system
through it.
(its our true shipping product with a limited-time security key).

		Adam Zilinskas
		aez@data-io.com
		http://www.data-io.com/~aez/


Article: 3042
Subject: PDW'96 registration deadline is near
From: robins@.cs.Virginia.EDU (Gabriel Robins)
Date: Tue, 19 Mar 1996 23:32:28 GMT
Links: << >>  << T >>  << A >>

Dear Colleagues,

   Enclosed below is the advance program for the 1996 ACM/SIGDA
Physical Design Workshop, which is co-sponsored the U.S. National
Science Foundation.

   This year's workshop will emphasize deep-submicron and
high-performance issues, and will also feature a special track on
micro electromechanical systems (MEMS), chaired by Ken Gabriel of ARPA.

   Please note that the the hotel room reservation deadline is March 24
so please reserve your hotel room soon.

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
                General Chair, PDW'96
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

  Interconnect Layout Optimization by Simultaneous Steiner Tree
  Construction and Buffer Insertion, T. Okamoto and J. Cong (UC Los Angeles)

  Simultaneous Routing and Buffer Insertion for High Performance
  Interconnect, J. Lillis, C.-K. Cheng and T.-T. Lin (UC San Diego)

  Timing Optimization by Redundancy Addition/Removal, L. Entrena, E. Olias
  and J. Uceda (U. Carlos III of Madrid and U. Politecnica of Madrid) 

  Open Commentary - Moderators: D. Hill (Synopsys),
                                P. Suaris (Interconnectix)

10:00am-10:20am: Break

10:20am-12:00pm: Session 2, Interconnect Optimization

  Optimal Wire-Sizing Formula Under Elmore Delay Model, 
  C. P. Chen, Y. P. Chen and D. F. Wong (U. Texas Austin)

  Reducing Coupled Noise During Routing, A. Vittal and M. Marek-Sadowska 
  (UC Santa Barbara) 

  Simultaneous Transistor and Interconnect Sizing Using General
  Dominance Property, J. Cong and L. He (UC Los Angeles)

  Hierarchical Clock-Network Optimization, D. Lehther, S. Pullela, 
  D. Blaauw and S. Ganguly (Somerset Design Center and Motorola) 

  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

  Physical Design for Surface Micromachined MEMS, Gary K. Fedder and
  Tamal Mukherjee (Carnegie-Mellon U.)

  Physical Design Support for MCNC/MUMPS, R. Mahadevan (MCNC)

  Synthesis and Extraction for MEMS Design, E. Berg, N. Lo and 
  K. Pister (UC Los Angeles)

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  (Design Manager, Intel) 
    T. Yin (VP R&D, Avant!) 

=============================================================================
                          TUESDAY, APRIL 16
=============================================================================

8:30am-9:50am: Session 7, Partitioning



  VLSI Circuit Partitioning by Cluster-Removal Using Iterative Improvement 
  Techniques, S. Dutt and W. Y. Deng (U. Minnesota and LSI Logic)

  A Hybrid Multilevel/Genetic Approach for Circuit Partitioning,
  C. J. Alpert, L. Hagen and A. B. Kahng (UC Los Angeles and Cadence)

  Min-Cut Replication for Delay Reduction, J. Hwang and A. El Gamal
  (Xilinx and Stanford U.)

  Open Commentary - Moderators: J. Frankle (Xilinx),
                                L. Scheffer (Cadence)

9:30am-10:10am: Break

10:10am-11:50am: Session 8, Topics in Hierarchical Design

  Two-Dimensional Datapath Regularity Extraction, R. Nijssen and 
  J. Jess (TU Eindhoven)

  Hierarchical Net Length Estimation, G. Zimmermann (U. Kaiserslautern)

  Exploring the Design Space for Building-Block Placements Considering
  Area, Aspect Ratio, Path Delay and Routing Congestion,  H. Esbensen and 
  E. S. Kuh (UC Berkeley)

  Genetic Simulated Annealing and Application to Non-Slicing Floorplan
  Design, S. Koakutsu, M. Kang and W. W.-M. Dai (Chiba U. and UC Santa Cruz) 

  Open Commentary

11:50pm-1:30pm: Lunch


1:30pm-3:00pm: Session 9, Poster Session

  Physical Layout for Three-Dimensional FPGAs, M. J. Alexander, J. P.
  Cohoon, J. Colflesh, J. Karro, E. L. Peters and G. Robins (U. of Virginia)

  Efficient Area Minimization for Dynamic CMOS Circuits, B. Basaran
  and R. Rutenbar (Carnegie-Mellon U.)

  A Fast Technique for Timing-Driven Placement Re-engineering,
  M. Hossain, B. Thumma and S. Ashtaputre (Compass Design Automation)

  Computer  Aided Micro-Machining for Wet Etch Fabrication,
  M. K. Long, J. W. Burdick and T. J. Hubbard (Caltech)

  Over-the-Cell Routing with Vertical Floating Pins, I. Peters, P. Molitor
  and M. Weber (U. Halle and Deuretzbacher Research GmbH)

  Congestion- Balanced Placement for FPGAs, R. Sun, R. Gupta and C. L. Liu 
  (Altera and U. Illinois)

  Fanout Problems in FPGA, K.-H. Tsai, M. Marek-Sadowska and S. Kaptanoglu
  (UC Santa Barbara and Actel)

  An Optimal Pairing and Chaining Algorithm for Layout Generation,
  J. Velasco, X. Marin, R. P. Llopis and J. Carrabina (IMB-CNM
  U. Autonoma de Barcelona, Philips Research Labs Eindhoven)

  Clock-Delayed Domino in Adder and Random Logic Design, G. Yee and 
  C. Sechen (U. Washington)


3:00pm-4:00pm: Session 10, Manufacturing/Yield Issues I

  Layout Design for Yield and Reliability, K. P. Wang, M. Marek-Sadowska 
  and W. Maly (UC Santa Barbara and Carnegie-Mellon U.)

  Yield Optimization in Physical Design, V. Chiluvuri (Motorola) 
  (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)

  A Gridless Multi-Layer Channel Router Based on Combined Constraint Graph
  and Tile Expansion Approach, H.-P. Tseng and C. Sechen (U. Washington)

  A Multi-Layer Chip-Level Global Route, L.-C. E. Liu and C. Sechen
  (U. Washington)

  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)
    R. Rohrer (Chief Scientist, Avant!)
    P. Sandborn (VP, Savantage)

=============================================================================
                         WEDNESDAY, APRIL 17
=============================================================================

8:30am-9:50am: Session 13, Performance-Driven Design

  A Graph-Based Delay Budgeting Algorithm for Large Scale Timing-Driven
  Placement Problems, G. Tellez, D. A. Knol and M. Sarrafzadeh 
  (Northwestern U.)

  Reduced Sensitivity  of Clock Skew Scheduling to Technology Variations,
  J. L. Neves and E. G. Friedman (U. Rochester) 

  Multi-Layer Pin Assignment for Macro Cell Circuits, L.-C. E. Liu and
  C. Sechen (U. Washington)

  Open Commentary

9:50pm-10:10pm: Break

10:10am-11:30am: Session 14, Topics in Layout

  Constraint Relaxation in Graph-Based Compaction, S. K. Dong, P. Pan,
  C. Y. Lo and C. L. Liu (Silicon Graphics, Clarkson U., Lucent, U. Illinois)

  An O(n) Algorithm for Transistor Stacking with Performance Constraints,
  B. Basaran and R. Rutenbar (Carnegie-Mellon U.)

  Efficient Standard Cell Generation When Diffusion Strapping is Required,
  B. Guan and C. Sechen (Silicon Graphics and U. Washington)

  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 "1996 Physical Design Workshop" (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 Latex and postscript versions of this advanced program may be
obtained from http://www.cs.virginia.edu/~pdw96/
=============================================================================



Article: 3043
Subject: Low-power FPGA or EPLD
From: kjhass@sandia.gov (Joe Hass)
Date: Wed, 20 Mar 1996 14:34:42 GMT
Links: << >>  << T >>  << A >>

I'm looking for an FPGA or EPLD to replace about a dozen CMOS
MSI and SSI parts.  I expect to need about 40 I/Os. A very
important requirement is that the power consumption falls to
typical static CMOS levels (tens of microamps) when the clock
is stopped.  I've noticed that the Altera Classic EP910 and
EP1810 seem to meet this requirement (in non-turbo mode), but
I'm wondering if there are others I should consider.

Availability of bare die and a few Schmitt inputs would be
significant bonuses, too.

Any suggestions are appreciated.

Thanks,
Joe

-- 
Joe Hass               | library clever_sigs;          | My opinions are my own
kjhass@sandia.gov      | use rock_and_roll.verses.ALL; |   not Sandia's and
Sandia National Labs   | use lineprinter.art.ALL;      |   not the DOE's


Article: 3044
Subject: Re: Xact6.o too slow
From: twcoll@aol.com (TWColl)
Date: 20 Mar 1996 11:02:22 -0500
Links: << >>  << T >>  << A >>
My experience is with Altera. Typically I see the 8K designs compile and
place and route in about 10-15 minutes for an 81188. (somewhere between an
4010 and a 4013). The SW is a real 32-bit application on the PC.  I have a
P90 and 32 Mbyte of RAM, with a 32 Mbyte swap space, running NT. For me,
time is money.

T


Article: 3045
Subject: CFP - ICSPAT / DSP World Expo. Reminder ! (1 month to deadline)
From: dspadmin@dspnet.dspnet.com ()
Date: 20 Mar 1996 19:19:38 GMT
Links: << >>  << T >>  << A >>

IMPORTANT NEWS Re: DSP World Expo & Data Acquisition Expo. '96
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Due to the continued growth and success of DSP World Expo. and
Data Acquisition Expo. significant changes have been made in the
schedule for the '96 event, and in our organization.

New Dates and Location for ICSPAT'96 & DSP World Expo.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ICSSPAT'96 - DSP World Expo. and Data Acquisition Expo. '96
October 8-10, 1996  in Boston, MA
World Trade Center

To lern more about these developments you can reference the press
release on DSPnet.   http://www.dspnet.com under the events section

--------------------------------------------------------------------
                    Call for Papers
____________________________________________________________________


Technical Review Committee: |	        ***** CALL FOR PAPERS *****
__________________________  |
      			    |
Dr. David Almagor	    |			ICSPAT 96	
National Semiconductor, USA |
      			    |       The 7th International Conference on
			    |    Signal Processing Applications & Technology
Dr. Filiz Basbug            |
Coherent Comm. Systems, USA |			featuring
      			    |
Mr. John Carbone	    |	   DSP WORLD EXPO & Data Acquisition Expo
Orincon, USA		    |			          
      			    |
Dr. Sathish Chandran,	    |		       Boston MA, USA
Univ. of Nottingham, UK     |	
			    |
Dr. Aziz Chihoub	    |
Siemens Corp. Research, USA |	Application Areas:
			    |	~~~~~~~~~~~~~~~~~
Dr. Prabhakar Chitrapu	    |
Dialogic Corp., USA	    |  Active Noise Control, Adaptive DSP Algorithms,
      			    |  Advanced TV Technology, Aerospace, ASIC DSPs,
Mr. Jerry Doty		    |  Audio, Automotive, Biomedical, Comm & Telephony
DSP Software Eng., USA      |  Consumer Products, Data Acquisition, Data Comm.
			    |  Digital Filter Implementation, DSP Algorithms,
Mr. John Edwards	    |  DSP Architectures, DSP Machines, DSP Software
Loughboro Sound Images, UK  |  Tools, DSP Technology, Geophysical, HLL Tools,
			    |  Image Analysis, Image Coding, Image Understand-
Dr. Mohammed El-Sharkawy    |  ing, Industrial Applications, Industrial Control
Purdue University, USA	    |  Instrumentation & Testing, Multi-processor Arch
			    |  Multimedia, Native Signal Processing, Neural Net
Mr. Jose Fridman	    |  Parallel Processing, Radar, Radio SATCOM & NAV,
Northeastern Univ., USA	    |  Rapid Prototyping, Robotics, Soft. Programming,
			    |  Software Tools, Specialized Applications, Speech
Dr. Mark Grosen		    |  Processing,Transportation, Underwater/SONAR,
Spectron Microsystems,USA   |  Virtual Reality, VLSI Architectures.
      			    |  ...... and more.
Dr. Pierre Jouvelot	    |
ENSMP, France               |   Mail, Fax, email 400-word abstract
      			    |   by April  22, 1996  to:
Mr. James M. Kresse	    |
JKJ Associates, USA	    |
			    |		Miller Freeman
Dr. Sen Kuo		    |		600 Harrison Street
Northern Illinois Univ, USA |		San Francisco,CA 94107
			    |		Tel: (415)356-3391
Mr. Noam Levine		    |		Fax: (415)905-2220
Analog Devices, USA	    |		E-mail: dsp@mfi.com
			    |
Dr. Jian Lu		    |		Attention: Megan Forrester
L. Livermore Lab., USA      |
			    |         
Mr. Stuart McGarrity	    |   To be eligible for consideration, abstracts must	
3L LTD, UK                  |   include the name, address, telephone, fax and e-mail 
      			    |   (when available) of each author.
Dr. Peter Nagy		    |	
Nat'l Def. Res. Est. Sweden |   E-mail submissions should come in simple text format
      			    |   (not encoded)
Mr. Jay Reimer              |
Texas Instruments, USA      | 
      			    |	Please include suggested application area:
Dr.Hemchandra Shertukde     |
University of Hartford, USA |	(If your abstract is accepted, the final area
      			    |	 of applications will be determined by the
Mr. Peter Siy		    |    technical review committee)
White Mountain DSP, USA	    |
      			    |
Dr. Tarun Soni		    |
NASA-Ames Res. Ctr.., USA   |   Papers presented in conference will be published
      			    |   in ICSPAT's Proceedings.
Dr. Tomohiko Taniguchi	    |
Fujitsu Labs. Ltd., Japan   |   -----------------------------------------------
			    |
Mr. Theodore C. Tanner, Jr. |
National Semiconductor, USA |		   ICSPAT - DSP World EXPO
                            |
Mr. Jonathan Thorn          |		      World Trade Center
Texas Instruments, USA      |
      			    |		      October 7-10, 1996
Mr. Vojin Zivojnovic,       |
Aachen Univ. of Tec. Ger.   |		       Boston, MA   USA



Article: 3046
Subject: Re: Xact6.o too slow
From: baldwins@fp.co.nz (Steve Baldwin)
Date: Wed, 20 Mar 1996 12:24:13
Links: << >>  << T >>  << A >>
In article <sheynin.119.000D65E4@fp.co.nz> sheynin@fp.co.nz (OS) writes:
>From: sheynin@fp.co.nz (OS)
>Subject: Re: Xact6.o too slow
>Date: Mon, 18 Mar 1996 13:23:47

>I know Xilinx people read/participate here regularly. Would they like 
>to comment on the issue discussed please?

Since this was posted two days ago, I assume they are waiting for a job to 
finish routing before responding.

:-)

Steve.

----------------------------------------------------------
Very funny Scotty ! Now beam down my clothes.

Steve Baldwin               At work : baldwins@fp.co.nz
Development Engineer        in life : steveb@kcbbs.gen.nz
Fisher & Paykel PSC
4/18 Fencible Dr, Howick    ph. +64 9 535-0679
Auckland, New Zealand      fax. +64 9 535-0661

I speak for myself. The company thinks my opinions suck.
----------------------------------------------------------



Article: 3047
Subject: Re: Low-power FPGA or EPLD
From: Scott Kroeger <scott.kroeger@mei.com>
Date: Wed, 20 Mar 1996 16:56:44 -0600
Links: << >>  << T >>  << A >>
Joe Hass wrote:
> 
> I'm looking for an FPGA or EPLD to replace about a dozen CMOS
> MSI and SSI parts.  I expect to need about 40 I/Os. A very
> important requirement is that the power consumption falls to
> typical static CMOS levels (tens of microamps) when the clock
> is stopped.  I've noticed that the Altera Classic EP910 and
> EP1810 seem to meet this requirement (in non-turbo mode), but
> I'm wondering if there are others I should consider.
> 

Xilinx XC3000L (3.3V) family parts have the lowest spec'd Q currents 
I've seen (30uA max), and unlike the Altera EPxxx parts, their operating 
currents are a product of gate count and the switching frequency of 
those gates (like CMOS MSI and SSI).  XC3000A (5V) are around 500uA Q.

The Altera parts actually turn themselves off after some period (100ns 
or so I think) of inactivity on all inputs.  When any input changes 
state, the entire part comes back to life at full operating current.  So 
if you have a single input clocking at 10MHz the part will draw full 
rated power, even if the rest of the device is quiet.

Altera does have SRAM based FPGA's similar in nature to the Xilinx 
parts, but I don't know their Q currents.

There are some true "zero-power" PALS out there, but they aren't as 
dense as you require.

Actel's antifuse parts are also low/linear power consumers, but I think 
(not sure) their Q currents are similar to XC3000A.  QuickLogic may be 
in the same class.

In general you will find that SRAM and (Anti)Fuse based FPGA's have low 
Q currents and EPROM/Flash based FPGA's do not.

Remember that the SRAM based parts must be loaded from some external 
source and that's another Q current you must consider.  Xilinx has app 
notes describing how to unpower the configuration PROM after 
configuration, so it's Q current can be eliminated.

If you find something else in the range of the XC3000L let me know, I 
have interest in ultra-low power designs as well.

Regards,
Scott


Article: 3048
Subject: Re: Sq. Roots and Languages
From: husby@fnal.gov (Don Husby)
Date: 20 Mar 1996 23:05:42 GMT
Links: << >>  << T >>  << A >>
drg@cs.toronto.edu wrote:
> Last week, Herman Schmit <herman@galant.ece.cmu.edu> posted an article with
> a simple integer square root function written in C and Verilog.  Just for
> fun, I thought I'd try the C version out with the Transmogrifier C compiler.
>
> I made the minimal changes necessary to re-write it in tmcc's subset of C.
> The modified source is below.  I then had to fix not one, but two bugs in
> the compiler (good example, Herman!).
>
> I compiled the program for 3 different sizes of inputs and outputs, and
> used Altera's MaxPlus 6.0 to fit the netlist into one of their new 10K50
> parts.  These are the results, according to MaxPlus:
>
> Input bits/Output bits  LCs     FFs     cycle time (ns)
>
>        32/16           1275    263     278
>        16/8             626    135     172
>         8/4             289     71     127

On the other hand, if you spend a couple of hours to analyze the
algorithm and code it in a form that works well with FPGAs,
you get a circuit (for the 16/8 case) that fits into 12 PFUs
(about 48 Altera LCs) in an ORCA chip and can run at 20ns cycle
times.  Here is a register shorthand summary of the circuit.
It consists of a 4-bit counter, a 24-bit registered mux, an 8-bit register, 
and a 10-bit subtracter.  A C-language coding of the algorithm
is at the end of this article.

Bit[3:0] := Count4 <Reset=LOAD> <Clken=/Bit3>   // Hold at count==8
N[15:0]  := LOAD ? Din[15:0] : N[13:0],0,0	// 16-bit mux
N[23:16] := Carry ? Sub[7:0] : N[21:14]		// 8-bit mux
R[7:0]   := R[6:0],Carry;
            <Reset=LOAD> <Clken=/Bit3>		// 8-bit register
Sub[9:0] == N[23:14] - R[7:0],0,1;  <Cout=Carry>// 10-bit subtract

What does this demonstrate?  Many people have suggested that a goal
is to compile "dusty-deck" code into FPGAs and capitalize on the
zillions of lines of C that already exist.  I think that it's very
unlikely that this is a useful goal.  I think most people will be
willing to do substantial work to make their algorithms run
much-much faster.
  Eperiments on theoretical physicists have shown them willing to
learn new programming languages (C instead of FORTRAN) and re-code
their algorithms if the speed up is significant.


Here is the C code:

#include <stdio.h>

void Printb(char *S, long A)     // Bit print function for diagnostics
{ int I;
  for (I=32; I--;) if (A&(1L<<I)) putchar('1'); else putchar('0');
  printf(" %8lx %s\n",A,S);
}

int Root(unsigned int N)
{ int   Bit=8;		// Bit counter
  long  N_reg= N;	// Simulate 24-bit N register
  long  R_reg=0; 	// Simulate 10-bit Root register as bits 23:14
  long  Tmp;		// Temporary
  long  Rt=0;		// Root

  while (Bit--)
  { R_reg = (Rt<<16)|0x4000;  // Note this is for free in FPGA
    Tmp= (N_reg-R_reg);       // Note only 10-bit subtractor (23:14) needed
    if (Tmp >= 0)             // If next bit is a 1 (carry-out of subtractor)
    { N_reg= Tmp << 2;	      // Accept subtraction and shift N_reg
      Rt= (Rt << 1)|1;  }     // Shift 1 into result
    else
    { N_reg= N_reg<<2;	      // Ignore subtraction, but shift
      Rt= (Rt << 1)  ;  }     // Shift 0 into result
  }
  return (Rt);
}

main()
{ unsigned int I,R;
  for (I=255; I--;)
  { R= Root(I*I);
	 if (I>=30 && I<40) printf("I= %3d I*I= %6d R=%3d\n",I,I*I,R);
	 if (R != I) printf("Error: Root was %d should be %d\n",R,I);     }
}



Article: 3049
Subject: Re: Sq. Roots and Languages
From: husby@fnal.gov (Don Husby)
Date: 21 Mar 1996 15:22:22 GMT
Links: << >>  << T >>  << A >>
I wrote:
> On the other hand, if you spend a couple of hours to analyze the
> algorithm and code it in a form that works well with FPGAs,
> you get a circuit (for the 16/8 case) that fits into 12 PFUs
> (about 48 Altera LCs) in an ORCA chip and can run at 20ns cycle
> times.

And if you're willing to risk looking like a complete geek, you
might observe that you could completely unroll the loop and come up
with a circuit that uses 24 ORCA PFUs and computes the full 16/8-bit
square root in 87 ns.

(This circuit relies heavily on the ORCA FE-MUX and would translate
to about 140 Altera LCs or 70 Xilinx-4000 CLBs)





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
2017JanFebMarApr2017

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