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 3575

Article: 3575
Subject: INDUSTRY GADFLY "Why I Hate Wally"
From: jcooley@world.std.com (John Cooley)
Date: Fri, 28 Jun 1996 13:22:17 GMT
Links: << >>  << T >>  << A >>
     !!!     "It's not a BUG,                        jcooley@world.std.com
    /o o\  /  it's a FEATURE!"                              (508) 429-4357
   (  >  )
    \ - /             INDUSTRY GADFLY: "Why I Hate Wally"
    _] [_   (retitled as "Shattering A Corporate Illusion" in EE Times)

                      by John Cooley, EE Times Columnist

        Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222

   Like most Americans, I have a rather cynical view of CEOs.  These are
the guys either caught embezzling, cooking the books, or laying off
thousands -- all while giving themselves huge bonuses.  As an engineer,
I've seen too many Dilbertesque scenarios where key technical decisions
were made by technically incompetent CEOs.  Why should I care about
Mentor Graphics CEO Wally Rhines?

   Years ago, the management at Mentor actually believed that Object
Oriented programming, EDA frameworks, and tightly integrated products that
were incapable of operating outside of Mentor's framework was the way to go.
Mentor also suffered from serious Not Invented Here (NIH) syndrome.  "Why
buy it when we can completely miss the market window by taking years to
develop it ourselves *and* at 10 times the cost?"  When Mentor would
accidentally develop good technology (like its ATPG software), they'd get
those troublesome innovators (like John Waicukauski) out of Mentor and into
their own company (CheckLogic.)   This resulted in software that had the
unusual distinction of being big, slow, buggy, *and* overpriced.

   Wally came to Mentor in the fall of 1993 from Texas Instruments.  He
immediately had some technology damage control to do.  With the bulk of the
North American market demanding Verilog based products, Mentor had foolishly
become obsessed with offering either proprietary or VHDL-only products that
came in dead last in benchmarks.  At the same time he punted the NIH syndrome
by *buying* Model Tech so Mentor could sell standard Verilog and a far better
performing VHDL simulator.  Wally bought Exemplar to add Verilog to Mentor's
AutoLogics synthesizer, plus to pick up a strong presence in the FPGA
synthesis market.  Wally bought back CheckLogic, which by then had become the
best ATPG tool on the market, and he bought Anacad to bolster Mentor in
analog simulation.  Also, he made it a goal to have each Mentor product run
independently of any framework.

   Organizationally, Wally broke up the company into many small product teams
and told them: "Get close to your customer!  Innovate as rapidly as you
can!"  He set up rewards and punishments based on results not personalities.
Instead of hiring more software weenies to produce even more useless Object
Oriented framework code, Mentor now hires experienced ASIC designers to
produce tools that actually work.  While the old Mentor prevailed by
pulling out of Pete Waddell's annual PCB benchmark, Wally stopped Mentor
from pulling out of the ESDA Shootout with: "That's not the philosophy I'm
trying to foster here.  Winning or losing a benchmark is completely different
than running away from one."

   Wally has now kicked off a technology offensive by buying Microtec and
MetaSystems to get a beachhead in the promising hardware/software co-design
and verification markets.  He even snapped up 3Soft and Zeelan to jump into
the coreware and physical modeling markets.

   Now I hate Wally.  He spends 60 percent of his time on the road visiting
customers and at user conferences.  Company morale is up and the annual
August layoff is history.  He's shattered my middle class illusion that most
CEOs are these distant, self-serving, money grubbing boobs not worth what
they're paid.  Damn him!

-----------

John Cooley runs the E-mail Synopsys Users Group (ESNUG), is president of
the User Society for Electronic Design Automation (USE/DA) and works as a
contract ASIC/FPGA designer.  He loves e-mail from fellow engineers at
"jcooley@world.std.com" or call (508) 429-4357.    [ Copyright 1996 CMP ]


Article: 3576
Subject: sanity check for 100k gate DSP FPGA project (long)
From: mush@netgate.net (David Decker)
Date: Sun, 30 Jun 1996 05:57:00 GMT
Links: << >>  << T >>  << A >>
Greetings,

I am starting a 100k gate DSP design. Time is short, isn't it always?
I've never done a design this large. I have done many Xilinx designs,
some with DSP.  A nice DDS with about 5MHz output that used random
noise to reduce output spurs, I've done little box car filters, and
BitSyncs using accumulators. All with Xilinx 2000, 3000 and 4000 and
ViewLogic schematic capture/simulation on DOS/Windows.

I知 asking for a sanity check at the start of this large project, from
those of you who have been here, and done this.
Am I all wet? 
Would VHDL etc. make this a piece of cake?
Are there any third party tools for DSP that would make schematic
entry easier?
Is there another chip family/tool set intended for DSP designs, that
would make all this easier?

I'm thinking of using XC5215s for this design, because they seem to be
about half the cost per function as compared with say, 4025Es, with
the drawbacks being:
1) requires twice the board space
2) Limits the max clock speed to about half

Max clock speed = 25MHz. I'm assuming 6ea ~80% full 5215s.

(Low cost chips are important because I値l have to make at least 200ea
of these boards with programmable logic, before going to ASIC.)

I plan to use the Stand Alone Standard ViewLogic package 5.2/6.0
schematic capture and simulation package from Xilinx because I致e used
it for smaller designs. Having been advised by everyone I talk to at
Xilinx, not to use XBLOX, (bus twiddling is very tedious in XBLOX)
I値l stick with the Unified Library.

To get my feet wet, I've started this project by trying to capture one
of the biggest blocks, a 10bit, 21tap, 50Mps, 2s complement, FIR
filter with 10 bits out. (Representative, no feedback, easy to
understand, straight forward to test.) 

Well, lets see. There doesn稚 seem to be a nice parameterized FIR
block in the Unified library, where I just supply the coefficients.
Come back in 5 years, I guess.

Surely there is a parameterized constant multiplier block where I just
supply the data widths and multiply factor? No?

No adder that allows varying and disparate input data widths and that
allows the sum width to grow?

What about a multi bit multi tap shift register? No? Geeeezzzz!

This may take more years than I expected.

OK, I値l lower the clock rate to 25MHz by shifting in two taps worth
(20 bits) at once, into taps 0 and 1, and splitting the shift register
into two, odd taps and even taps. I値l only get every other output
sample, but that痴 OK since this is a low pass.

Shift is 21ea 16bit data registers. Of course, since I知 only using
10bits, the software gives lots of warnings about data widths not
matching. OK, I値l sign extend the input, carry 16 bits to the end,
and then not use the MSBs. Xilinx will discard the unused stuff.

Second step, add each symmetrical register pair. ie tap 0 and tap 20,
1 and 19, etc. Pull data off the 16bit shift reg buses with 10 bit
busses, just to be sure Xilinx kills the unused shift register bits.
This is fun! Each of 10 adders is the same. 10 bits in, 11 out.

Now, make sure none of  the coefficients has more than two or three
ones, so the multipliers will consist of only 1 or 2 adders.

One of the 11bit adder outputs must be multiplied by 3, so add the 11
bit number, to itself, shifted left by 1.  The shift is just wiring.
The trick here, is to minimize adder width and CLB count. Instead of
shifting the larger number left, shift the lower one right, so the LSB
falls off the end. That LSB will then be wired around the adder and
just wire merged with the sum bus exiting the adder. 

General purpose multipliers, if they existed, would be useless.
Besides being wasteful of CLBs, in the extreme, a design using them
would not even fit in the 5215 and would be slower.

Both inputs to the adder must be sign extended, and at the same time,
the smaller must be right shifted. 

To sign extend the unshifted one, just pull a net off the 11 bit input
bus and name it "input10," run it through a buf with a $array=5
attribute. Name the output of the buf array "input[15:11]" and feed it
back into the 11 bit input bus to create a 16 bit sign extended bus.
Of course, every single segment of every bus must be labled, or the
label will revert to 15:0. Connect to one input of a 16bit adder.

To shift the other bus, grab the 10 LSBs with a bus tap named 10:1.
Run this through a 10 bit buf array, labeling the output "in[9:0].
Then sign extend this with another buffer array to 15:0 and connect to
the other input of the 16bit adder. 

Label the output of the adder "output[16:1]." Using a net, tap the
input LSB, run it through a buf to rename it output0. Connect output0
to the adder output[16:1] to form output[16:0]. The output can be
another bus tap off this, named output[12:0]. Will it use more CLBs to
leave it 16 bits?

If you池e still with me, I apologize for the gory details, bit I
really wanted to show just how primitive my tools are for capturing a
simple multiply by 3. Each instance of a different coefficient value
or a different data width, must be crafted individually. Multipliers
with three ones in the coefficient have two adders, and require twice
as much bus twiddling. Each adder with different data widths must be a
different block with the sign extension done individually.

This entry method is extremely slow. Please tell me there is an easier
way to capture DSP circuits with low CLB counts. At least tell me
someone is working on it.

Thanks very much for sticking with me, and for any help you can offer.
I don稚 want to waste months of labor if there is a better way.

My email adr. is listed below, but I think the news group would be
interested in your post.

Dave Decker
Diablo Research Corp.
825 Stewart Dr.
Sunnyvale, CA 94087-4514
ddecker@diabloresearch.com
408 730 9555	voice
408 738 2370	FAX





Article: 3577
Subject: FPGA ==> ASIC (GA and/or Std Cell)
From: Bob Elkind <eteam@aracnet.com>
Date: Sun, 30 Jun 1996 15:30:16 +0100
Links: << >>  << T >>  << A >>
It's been too long since I last actively took an interest in
conversion from Xilinx and/or ATT/Lucent FPGAs into lower-cost ASICS
(including gate arrays).

If you have first-hand or second-hand experience with the several
vendors offering conversion services, please give me a holler.

Conversion service may be taken as broadly as you like; from either
schematic translation, netlist translation, or layout translation
through layout, ATPG, etc..

Conversion services may include consultants (e.g. Phil Freidin, John
Cooley, Ray Andrakas, et al), service bureaus, or semi vendors (e.g.
Orbit Semi, Temic, NEC, et al).

Please mention services provided/not provided, turnaround time,
quality of service/support, and final outcome (e.g. did it work?).
Anecdotes are always welcome, but if I reserve rights to edit to
good taste and manners if I'm summarising and re-posting.

If you prefer to remain anonymous, please e-mail to me, and I will
summarize and post a summary.

No confidential information, please.  Vague warnings are OK, but don't
violate confidences.

Thank you kindly,

Bob Elkind

**************************************************************************
Bob Elkind                email:eteam@aracnet.com             CIS:72022,21
7118 SW Lee Road                         part-time fax number:503.357.9001
Gaston, OR 97119                     cell:503.709.1985   home:503.359.4903
******** Video processing, R&D, ASIC, FPGA design consulting *************


Article: 3578
Subject: Using XC4000 Primary Clocks from Verilog
From: Ehud Reshef <admi@ccsg.tau.ac.il>
Date: Sun, 30 Jun 1996 18:43:25 -0700
Links: << >>  << T >>  << A >>
Hi.
Is there a way to use primary clock buffers on a XC4K device 
starting from verilog (Cadence) without inserting a BUFGP symbol
on the composer schematic?


Article: 3579
Subject: Re: sanity check for 100k gate DSP FPGA project (long)
From: Jonathan Griffitts <jcg@qadas.com>
Date: Sun, 30 Jun 1996 21:15:53 -0600
Links: << >>  << T >>  << A >>
In article <4r55en$ok5@ss.netgate.net>, David Decker <mush@netgate.net>
writes
  . . .
>I'm thinking of using XC5215s for this design, because they seem to be
>about half the cost per function as compared with say, 4025Es, with
>the drawbacks being:
>1) requires twice the board space
>2) Limits the max clock speed to about half
>
>Max clock speed = 25MHz. I'm assuming 6ea ~80% full 5215s.
  . . .

I just wanted to comment on 5200 family vs. 4000 family, because I've
recently used both families:

1)  It appears from your discussion that you will be using a lot of
adders.  You should be aware that adders take up 50% more space in a
5200 family than in a 4000.  If adders make up a significant fraction of
your gate count you may not want to use a 5200.

2)  My recent experience also seems to show that PPR auto-placement
works much more poorly for the 5200 family than it does for the 4000.
When I started using 5200 devices, I wound up doing a lot more
floorplanning than I have been accustomed to do for the 4000 on a
similar design.  This seems odd to me and I would emphasize the standard
"your mileage may vary" disclaimer -- but it might be something to
consider.  The designs I am talking about were about 5K-10K gates in
size, and targeted 4008, 4010, 4013, 5206, and 5210.

If you have any part of your design roughed out already, you might want
to do a trial PPR run for both 4000 and 5200 family, and compare the
results.
-- 
                        Jonathan Griffitts
AnyWare Engineering                             Boulder, CO, USA
voice/fax: 303 442-0556                      email jcg@qadas.com


Article: 3580
Subject: Re: sanity check for 100k gate DSP FPGA project (long)
From: Kate Meilicke <katem@xilinx.com>
Date: Mon, 01 Jul 1996 09:15:17 -0400
Links: << >>  << T >>  << A >>
Hi David,

You are right...somebody has done work with DSP using Xilinx.
Check out www.xilinx.com under Product Information, Applications
Notes, DSP Solutions.  There is an app. note on how to
do a 16 Tap 8 bit FIR filter. It takes advantage of the
RAM in a 4KE to do the multiplication.  If you have any other
questions, send an e-mail to dsp@xilinx.com.  There is
group at Xilinx that supports DSP designs.

Kate Meilicke
Xilinx




Article: 3581
Subject: Re: Need recommendation for PCI interface on 68332
From: Kate Meilicke <katem@xilinx.com>
Date: Mon, 01 Jul 1996 09:24:46 -0400
Links: << >>  << T >>  << A >>
Check out http://www.xilinx.com/apps/pci.htm for more info
on the Xilinx PCI LogiCore solution.  Since I work for Xilinx
I am partial to this solution.  The advantage of Xilinx
is that it is a tested macro and has already been
used in several designs.

Kate Meilicke
Xilinx




Article: 3582
Subject: Re: REQ:Old Picture of Bus
From: Ray Andraka <randraka@ids.net>
Date: 1 Jul 1996 14:19:29 GMT
Links: << >>  << T >>  << A >>
alderucc@brc.uconn.edu (Dean Alderucci) wrote:
>
> For various reasons, I need to find a block diagram or schematic showing a
> standard bus with CPU and peripherals hanging off of it.  (Yes, its that
> simple)  
> 
> +---+ +---+ +---+
> |   | |   | |   |
> +---+ +---+ +---+
>   |     |     |
>   |     |     |
> ----------------------
> 
> Something like the above, but the picture has to be old (at least ten
> years old).  Clearly, there should be hundreds of references that fit this
> description, but all my books are too new, and I have to show someone that
> this setup has been around for a while.(though its been around forever)
> 
> I don't think the first edition of "Computer Architecture" by Hennessy and
> Patterson goes back that far, but I could be wrong.
> 
> Please email your reply.  Thanks.
> 
> Dean
> alderucc@brc.uconn.edu
> 
> -- 
> Dean Alderucci
> alderucc@brc.uconn.edu
Why don't you dig up an old 8080 or MCS8085 databook.  
I'm sure there's still one around somewhere and those date 
back to the late '70s.  Check school technical libraries.



Article: 3583
Subject: Re: REQ:Old Picture of Bus
From: benst@stuyts.nl (Ben Stuyts)
Date: Mon, 1 Jul 1996 18:07:33 GMT
Links: << >>  << T >>  << A >>
In article <alderucc-2806962345040001@patents.connix.com>,
Dean Alderucci <alderucc@brc.uconn.edu> wrote:
> For various reasons, I need to find a block diagram or schematic showing a
> standard bus with CPU and peripherals hanging off of it.  (Yes, its that
> simple)  
> 
> +---+ +---+ +---+
> |   | |   | |   |
> +---+ +---+ +---+
>   |     |     |
>   |     |     |
> ----------------------

Something like that appears various times in Bit-Slice Microprocessor Design
from John Mick and Jim Brick. ISBN 0-07-041781-4, and it's from 1980. But as
another poster replied, there must be lots of these references around.
Perhaps an old Apple-II manual from around 1976? I have some very old 6502
manuals at work from Rockwell, maybe it's in them too.

Best regards,
Ben
-- 
Ben Stuyts
Stuyts Engineering BV        Haarlem, The Netherlands
Phone: +31 (0)23 5324609     Email:   ben@stuyts.nl
Fax:   +31 (0)23 5421988     (NeXT/MIME Mail OK)


Article: 3584
Subject: WANTED: SOME HELP PLEASE
From: Corporate1@notes.techni-source.com (Technisource)
Date: 1 Jul 1996 19:11:17 GMT
Links: << >>  << T >>  << A >>
SORRY TO BOTHER YOU GUYS, BUT I AM HAVING A VERY HARD TIME FINDING A 
SOLID FPGA DESIGNER.  PLEASE DIRECT ME TO A RESUME BANK/NEWS GROUP THAT 
MIGHT BE OF SOME HELP TO ME.  THIS IS FOR A VERY GOOD JOB IN CENTRAL 
FLORIDA.  PLEASE RESPOND TO vvirga@notes.techni-source.com
I WOULD APPRECIATE ANY HELP,  THANKS.



Article: 3585
Subject: Re: REQ:Old Picture of Bus
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 1 Jul 1996 21:47:09 GMT
Links: << >>  << T >>  << A >>
>From article <DtvMCL.DoJ@stuyts.nl>, by benst@stuyts.nl (Ben Stuyts):
> 
> Something like that appears various times in Bit-Slice Microprocessor Design
> from John Mick and Jim Brick. ISBN 0-07-041781-4, and it's from 1980. But as
> another poster replied, there must be lots of these references around.
> Perhaps an old Apple-II manual from around 1976?

I sent E-mail suggesting that the original poster check the configuration
diagrams in one of the DEC small computer handbooks or minicomputer
handbooks.  Both the PDP-8 and PDP-11 handbooks from 1970-1974 include
these kinds of diagrams, relative to the OMNIBUS and UNIBUS respectively.

The OMNIBUS machines were built using exactly the kind of backplane-bus
that many people later learned about through playing with S-100 or
late-model PDP-11 hardware.  The original UNIBUS based PDP-11 systems had a
tighter bus design, from a logical viewpoint, but the initial physical
structure was less obviously bus based because the modules that were bussed
were 4x6 slot miniature custom wire-wrapped backplane modules.

Nonetheless, all DEC PDP-8 and PDP-11 handbooks from the early 1970's had
nice bus diagrams.

Also of interest from a slightly later period would be configuration
pictures of the STD bus -- an early industrial microcomputer bus that was
far tighter than the S-100 standard.

				Doug Jones
				jones@cs.uiowa.edu


Article: 3586
Subject: Re: HELP:Foundation VHDL on WIN95
From: jimbrakefd@aol.com (JimBrakefd)
Date: 1 Jul 1996 21:09:05 -0400
Links: << >>  << T >>  << A >>
Seems to run on my machine.
Takes alot of disk however (~300Mb)



Article: 3587
Subject: XUMA Digest #9
From: ecla@world.std.com (alain arnaud)
Date: Tue, 2 Jul 1996 02:37:20 GMT
Links: << >>  << T >>  << A >>
Xilinx Users Mailing List
Digest 9
7/02/96

	1. Subject: XNF Format

======================================================================

Hello Everyone,

Where can I find documentation describing the Xilinx Netlist Format
(XNF) ? I need something that explains all the keywords, specific
formats etc...in the format.

Thanks.

Bassam Tabbara

==============================================================================
EMAIL YOUR ARTICLE OR POST TO xuma@ecla.com

XUMA is an independent mailing list for users of Xilinx devices and tools.

To subscribe send an email to xuma_request@ecla.com

Would you like to contribute an article?
Share an experience, good or bad, with xilinx parts or tools, 
Describe a bug,
or need some help, have a question or just a comment:

then, post an article, send an email to xuma@ecla.com

The digests are archived at http://www.ecla.com



Article: 3588
Subject: ISSPA 96
From: Abdelhak Zoubir <a.zoubir@qut.edu.au>
Date: Tue, 2 Jul 1996 05:58:41 GMT
Links: << >>  << T >>  << A >>

               4th International Symposium		
         on Signal Processing and its Applications
                      ISSPA 96

         August 25-30, Royal Pines Hotel, Goal Coast

ISSPA 96 is the 4th in a series of international symposia on theory
and applications of signal processing.  It has established itself as
the premium Signal Processing event in the Asian/Pacific region. It
provides a forum for engineers and scientists engaged in research and
development to discuss specific problems and potential solutions using
signal processing tools. The symposium is organised by the Signal
Processing Research Centre, Queensland University of Technology, and
is sponsored by the IEEE Qld. Section.

The symposium will be of interest to a wide cross-section of
scientists, researchers, and engineers involved in the different
aspects of signal processing and its applications, including
communications signal processing, speech and audio analysis, image &
video processing, machine vision, radar, sonar, biomedical signal
processing, and other industrial applications.  Over 300 delegates are
expected to attend the symposium this year.

We invite you to participate in the symposium and to look at this
event as a means of interacting with other colleagues from all over
the world and benefiting from each other's experiences. Please contact
isspa96@qut.edu.au or the address given below for your copy of the
ISSPA'96 REGISTRATION BOOKLET AND ADVANCE PROGRAM.

We look forward to seeing you at the symposium.

B Boashash
Chair, ISSPA 96 Steering Committee

N Harle
Chair, Organising Committee

A M Zoubir
Chair, Technical Committee


Plenary Sessions
----------------
The technical program is highlighted by three plenary sessions. Prof. M.
Kaveh from University of Minnesota, USA will present "Array signal
processing: recent accomplishments and future opportunities", Dr. Garry
Newsam from Defence Science and Technology Organisation, Australia will
speak on "Image Registration in Defence", and Dr. Peter Kroon from AT&T Bell
Labs, USA will present "Speech Coding: Applications, Challenges and New
Directions".


Tutorials
---------
The symposium will be preceded by 3 tutorials on 25 August. Prof. M.G. Amin
from Villanova University, USA, will speak about "Application of
Time-frequency Analysis in Spread Spectrum Communications Systems", Prof. S.
Furui from NTT Human Interface Laboratories and Tokyo Institute of
Technology, Japan, will present "Robust Speech Recognition", and Dr. A.
Bouzerdoum from University of Adelaide, Australia, will give a talk about
"Image Processing Applications of Self-Organising Networks".


Robotics & Robot Vision Workshop
--------------------------------
ISSPA 96 will continue its tradition and host a specialised workshop.  The
workshop on "Robotics and Robot Vision" will take place on 29 and 30 August
1996 and is being organised by Assoc/Prof. K. Youcef-Toumi from MIT, USA.
As one of the keynote speakers he will present a talk about "Modelling,
Design and Control Integration for Precision Electromechanical Systems".
Other keynote speakers are Dr. S. Venkatesh from Curtin University who will
speak about  "Close Encounters with Active Vision" and Dr. P. Allen,
Columbia University, USA with "Visual Control for Robotic Hand Eye
Coordination".


Exhibits
--------
There will be an industry exhibit during the symposium covering vendors of
hardware, software, systems, and publications. Vendors/companies interested
in exhibits or symposium sponsorship need to contact urgently the symposium
secretariat.



For more information, contact 
-----------------------------
ISSPA 96 Symposium Secretariat, P.O. Box 3496, South Brisbane Business
Centre, Qld 4101, Australia, Phone: +61 7 3844 1138, Fax: +61 7 3844 0909,
Email: isspa96@qut.edu.au, WWW Homepage:
http://www.eese.qut.edu.au/~sprc/isspa96.html


Article: 3589
Subject: Re: INDUSTRY GADFLY "Why I Hate Wally"
From: gehring@inf.ethz.ch (Stephan Gehring)
Date: 2 Jul 1996 08:43:21 +0200
Links: << >>  << T >>  << A >>
In article <Dtpp56.J2n@world.std.com>,
John Cooley <jcooley@world.std.com> wrote:
>     !!!     "It's not a BUG,                        jcooley@world.std.com
>    /o o\  /  it's a FEATURE!"                              (508) 429-4357
>   (  >  )
>    \ - /             INDUSTRY GADFLY: "Why I Hate Wally"
>    _] [_   (retitled as "Shattering A Corporate Illusion" in EE Times)
>
>                      by John Cooley, EE Times Columnist
>
>        Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222

...

>
>   Years ago, the management at Mentor actually believed that Object
>Oriented programming, EDA frameworks, and tightly integrated products that
>were incapable of operating outside of Mentor's framework was the way to go.
>Mentor also suffered from serious Not Invented Here (NIH) syndrome.  "Why
>buy it when we can completely miss the market window by taking years to
>develop it ourselves *and* at 10 times the cost?"  When Mentor would
>accidentally develop good technology (like its ATPG software), they'd get
>those troublesome innovators (like John Waicukauski) out of Mentor and into
>their own company (CheckLogic.)   This resulted in software that had the
>unusual distinction of being big, slow, buggy, *and* overpriced.

Yes, but has the situation changed? I'd say no. Tools have become bigger,
slower, contain at least as many bugs as they used to do. Perhaps the bigger
market has made the tools a *little less* overpriced, but otherwise the
situation essentially stays the same.
  I still believe that integrated, but *extensible*, frameworks are a way to
go for speedier tools. Integration by itself doesn't imply anything about
user interfaces, or openness for other vendor's tools but merely that
communication between tools is more efficient than simply via ASCII files.
  For me, the imbalance between FPGAs reconfigurable within milli-seconds and
tools that take hours to place and route seems very inappropriate. Tools should
allow user interaction at all stages of the design, rather than offer push-
button solutions. This, of course, requires fast tools which, I believe, well
integrated tools can offer more easily than loosely coupled ones.

Opinions?

-- Stephan

M.Reiser: Software is getting slower faster than hardware is getting faster.

------------------------------------------------------------------------------
Stephan Gehring                            Email:  gehring@inf.ethz.ch
Institute for Computer Systems             Phone:  +41 1 632 73 15
ETH-Zentrum                                FAX:    +41 1 632 13 07
CH-8092 Zurich, Switzerland


Article: 3590
Subject: Using MAX+plusII under UNIX
From: klindwor@tech17.informatik.uni-hamburg.de (Andre Klindworth)
Date: 2 Jul 1996 09:05:56 GMT
Links: << >>  << T >>  << A >>

Some weeks ago, we received version 6.1 of Altera's MAX+plusII
development tool and were very keen on installing it immediately.
The installation procedure had been as easy as it used to be,
but the software doesn't run correctly. The major problem is that
windows like the file browser are not refreshed. E.g. when selecting
the item Project-Name from the File menu, the browser window
initially appears to be empty, although clicking here and there
the expected listboxes and buttons appear.

Has anybody experienced similar problems and could suggest a remedy?

BTW: We run X-Windows (X11R5) under SunOS 4.1.4 and my preferred 
     window manager is mwm. 

Any help appreciated.

Read ya,
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: 3591
Subject: Re: XUMA Digest #9
From: trev@ss11.wg.icl.co.uk (Trevor Hall)
Date: 2 Jul 1996 11:58:51 GMT
Links: << >>  << T >>  << A >>

>Hello Everyone,
>
>Where can I find documentation describing the Xilinx Netlist Format
>(XNF) ? I need something that explains all the keywords, specific
>formats etc...in the format.
>
>Thanks.
>
>Bassam Tabbara

>From XILINX. You will however have to sign a non disclosure agreement (unless XILINX
have changed the rules).

T.H.






Article: 3592
Subject: Advanced Network Products, Top UK Co., to c55k, Southern England - ECM
From: Topjob <topjob@ecmsel.demon.co.uk>
Date: Tue, 2 Jul 1996 14:30:54 +0100
Links: << >>  << T >>  << A >>
Subject: Ref:1275 - Advanced Network Products,Top UK Co., to c55k,
SOUTHERN ENGLAND

                       ADVANCED NETWORK PRODUCTS

                        Negotiable to c55,000

PLEASE QUOTE REF: 1275.

With one of the UK's most exciting, high-growth companies engaged in
the research and product development of 'next generation' computer
communication & network technologies.

These new appointments, reporting at Board level, are created as part
of a planned development programme.

SOFTWARE DEVELOPMENT MANAGER

Responsible for all aspects of Software Product Development, from
concept to release, for both stand alone and PC based products.

You should have a sound background gained in lifestyle Software       
Development - ideally for Network Management, Switching or related    
products, coupled with excellent Project Management skills and the    
ability to manage and motivate a team of c12 software specialists.    
                                                                      
HARDWARE DESIGN MANAGER                                               
                                                                      
To take responsibility for Product Hardware Design & Innovation.      
                                                                      
Ideally you should have a strong background in the design of digital  
products for medium/high volume manufacture, coupled with excellent   
Team Leadership & Design Management skills.  Experience with ASIC/FPGA
based Network, Bridges, Switches, Graphics plug-ins or related        
products would be particularly valuable.                              
                                                                      
SOFTWARE & HARDWARE ENGINEERS                                         
20k -45k                                                    
                                                                      
Additionally we seek six top-calibre Software & Hardware Specialists -
from fresh Graduate to Technical Specialist - to work at the forefront
of high-speed networking technology.                                  
                                                                      
Ideally you should have an excellent academic track record, enjoying  
the challenge of working at the forefront of technology and have      
experience of either low-level Embedded Asynchronous Device Driver, or
similar software, or digital FPGA-based hardware design. A knowledge  
of Ethernet, Token Ring or ATM Networking; IP routing; PBX Core       
Switching; DPNSS; ITU Qxxx or Hxxx Standards; QSIG or related         
technologies would be a significant plus.                             
                                                                      
The importance placed upon Product Innovation as the key to continued 
market leadership is indicated by the Upper Echelon Salaries,         
Comprehensive Benefits Package, excellent Facilities and Career       
Development Opportunities which are offered.                          
 

-- 
For further information on ECM visit www.ecmsel.co.uk

Please contact us by Email (Cvs in plain ASCII text - not coded!)
topjob@ecmsel.co.uk  ------ Alternatively Snail, Fax or Phone:
ECM Selection Ltd, The Maltings, Burwell, Cambridge, CB5 0HB.
Tel:  01638 742244                      Fax:  01638 743066



Article: 3593
Subject: LCA to Schematic
From: mscott5@ede.sanders.lockheed.com (Michael D. Scott)
Date: 2 Jul 1996 13:45:49 GMT
Links: << >>  << T >>  << A >>
Hi,
	I have an LCA file for XACT 5.0 which was spun off a 
Viewlogic schematic.  This chip had a few flaws so we made a few
changes directly in the LCA file without really documenting the changes
(I know, it's bad practice but it is done).  Is there a way to convert this
LCA file back into a schematic in either Viewlogic or Mentor without having
to go through by hand?  What software packages would be needed?  It is
strictly for documenting purposes.

Thanks

Please email response to
mscott5@ede.sanders.lockheed.com


Article: 3594
Subject: Re: Need recommendation for PCI interface on 68332
From: Jim_Sackman@usa.racal.com (Jim Sackman)
Date: Tue, 2 Jul 1996 07:18:57
Links: << >>  << T >>  << A >>
In article <4r1ihk$2ph@nadine.teleport.com> coffin@teleport.com (Eric Coffin) writes:
>Path: news.internetMCI.com!newsfeed.internetmci.com!news.cloud9.net!newsfeed.direct.ca!nntp.teleport.com!usenet
>From: coffin@teleport.com (Eric Coffin)
>Newsgroups: comp.arch.fpga
>Subject: Re: Need recommendation for PCI interface on 68332
>Date: 28 Jun 1996 21:24:04 GMT
>Organization: Teleport - Portland's Public Access (503) 220-1016
>Lines: 9
>Message-ID: <4r1ihk$2ph@nadine.teleport.com>
>References: <Dtnyw5.7s8@stuyts.nl> <4qv6kb$3ol@reader1.reader.news.ozemail.net>
>NNTP-Posting-Host: linda.teleport.com


>: Are Actel and Xilinx the most likely candidates for this? Any others?

>Lucent Technologies (formerly AT&T Microelectronics) offers a family of
>parts in the ORCA series which are PCI compliant.

>Eric (an employee of Lucent Technologies)
>--
>coffin@teleport.COM  Public Access User -- Not affiliated with Teleport
>Public Access UNIX and Internet at (503) 220-1016 (2400-28800, N81)


A company named Tundra (previously Newbridge Microelectronics) offers 68K to 
PCI bridge devices off the shelf.

Jim Sackman
Jim_Sackman@usa.racal.com


Article: 3595
Subject: Re: REQ:Old Picture of Bus
From: ws@shore.net (William Stallings)
Date: Tue, 02 Jul 1996 10:14:31 -0500
Links: << >>  << T >>  << A >>

> alderucc@brc.uconn.edu (Dean Alderucci) wrote:
> >
> > For various reasons, I need to find a block diagram or schematic showing a
> > standard bus with CPU and peripherals hanging off of it.  (Yes, its that
> > simple)  
> > 
> > +---+ +---+ +---+
> > |   | |   | |   |
> > +---+ +---+ +---+
> >   |     |     |
> >   |     |     |
> > ----------------------
> > 
> > Something like the above, but the picture has to be old (at least ten
> > years old).  Clearly, there should be hundreds of references that fit this
> > description, but all my books are too new, and I have to show someone that
> > this setup has been around for a while.(though its been around forever)
> > 
> > I don't think the first edition of "Computer Architecture" by Hennessy and
> > Patterson goes back that far, but I could be wrong.
> > 

The first edition of my book, Computer Organization and Architecture goes
back about 10 years and devotes the better part of a chapter to this
organization.

In the book

Computer Structures: Readings and  Examples
Bell & Newell
McGraw-Hill, 1971

there are several examples. Some technical libraries should still have a copy.

Bill

|                | Descriptions, errata sheets and discount order info |
| Bill Stallings |              for my current books and               |
|  ws@shore.net  |       information on my forthcoming books at        |
|                |        http://www.shore.net/~ws/welcome.html        |
Article: 3596
Subject: Re: INDUSTRY GADFLY "Why I Hate Wally"
From: jcooley@world.std.com (John Cooley)
Date: Tue, 2 Jul 1996 15:48:52 GMT
Links: << >>  << T >>  << A >>
Stephan Gehring <gehring@inf.ethz.ch> wrote:
>Yes, but has the situation changed? I'd say no. Tools have become bigger,
>slower, contain at least as many bugs as they used to do. Perhaps the bigger
>market has made the tools a *little less* overpriced, but otherwise the
>situation essentially stays the same.
>  I still believe that integrated, but *extensible*, frameworks are a way to
>go for speedier tools. Integration by itself doesn't imply anything about
>user interfaces, or openness for other vendor's tools but merely that
>communication between tools is more efficient than simply via ASCII files.

Stephan, I think the fundamental reason why frameworks failed *was* because
they were many times implemented such that the user could never see ASCII
files.  That is, to make for faster execution times, these bloated frameworks
would transfer data between various tools via proprietary binary databases
which were hell for engineers to work with when they found bugs.  To this
day I *still* have to use something like Perl or NAWK to massage files going
to and from various EDA tools.  I accept it as the price for using "hot"
tools that can do things that weren't doable a year before.

                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 4488 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


Article: 3597
Subject: Re: INDUSTRY GADFLY "Why I Hate Wally"
From: clw@hprnd.rose.hp.com (Carl Wuebker)
Date: 2 Jul 1996 17:05:05 GMT
Links: << >>  << T >>  << A >>
John Cooley (jcooley@world.std.com) wrote:
> Stephan, I think the fundamental reason why frameworks failed *was* because
> they were many times implemented such that the user could never see ASCII
> files.  That is, to make for faster execution times, these bloated frameworks
> would transfer data between various tools via proprietary binary databases
> which were hell for engineers to work with when they found bugs.  To this
> day I *still* have to use something like Perl or NAWK to massage files going
> to and from various EDA tools.  I accept it as the price for using "hot"
> tools that can do things that weren't doable a year before.

     For once, I agree with John... except that I claim that ASCII databases
are useful independent of whether the associated tools are part of a framework
or not.  The current EDA bug rate means that ASCII databases are a *must* to
allow users, EDA support and EDA factory support people to discover & fix
problems.

     Now, given an ASCII database, users & 3rd parties can create "add on"
tools to a vendor's framework, making that framework more attractive to
existing users and new customers.

Thanks,
    Carl Wuebker * HP Roseville * clw@f.rose.hp.com * (916) 785-4296
Article: 3598
Subject: Re: INDUSTRY GADFLY "Why I Hate Wally"
From: pickle@nocturne.cs.ucla.edu (Patrick Madden)
Date: 2 Jul 1996 10:26:14 -0700
Links: << >>  << T >>  << A >>
Stephan Gehring <gehring@inf.ethz.ch> wrote:
>>  I still believe that integrated, but *extensible*, frameworks are a way to
>>go for speedier tools. Integration by itself doesn't imply anything about
>>user interfaces, or openness for other vendor's tools but merely that
>>communication between tools is more efficient than simply via ASCII files.

In article <DtxALG.D5M@world.std.com> jcooley@world.std.com (John Cooley)
writes:
>[frameworks failed...]
>..  That is, to make for faster execution times, these bloated frameworks
>would transfer data between various tools via proprietary binary databases
>which were hell for engineers to work with when they found bugs.

Frameworks might make sense if we needed to do a few seconds of
computation with tool X, and then send a large portion of the
circuit to tool Y.  I don't think this is common (anyone have a good
example otherwise?).  In general,
            t(compute) >> t(read+write)
TimberWolf takes a couple of hours to do place and route--the 2
minutes it takes to read/write the circuit doesn't make much of a
difference.  Having a framework might save me 1 of those 2 minutes,
but being able to read and write the files easily is worth more to me.

IMO, what we need is a handful of standard flat file interfaces (I
don't think anything can be all things to all people), and a few
standard protocols for tool communication.  There were a couple of
papers in this years DAC that go in that direction.  I doubt that CFI
will succeed, while EDIF seems to have a decent chance.

I don't see any real advantages in a framework, while there are a lot
of disadvantages.  Faster execution times might be possible, but the
difference would be slight.  The only real plus is that maybe you
could prevent your customer from using someone elses tool....  But no
one would have a framework for that reason, would they? :-).


Patrick
pickle@cs.ucla.edu
"Now I guess I'll have to tell 'em     That I've got no cerebellum
 Gonna get my PhD                      I'm a teenage lobotomy"


Article: 3599
Subject: ANNOUNCE: New Tip of the Month - Deferred constants
From: Rob Hurley <rob@doulos.co.uk>
Date: Tue, 02 Jul 1996 17:53:29 GMT
Links: << >>  << T >>  << A >>
ANNOUNCEMENT: Immediate Release


		 Tip of the Month
		==================

This month's model is:

	
	Using Deferred Constants in VHDL

You can find it at http://www.doulos.co.uk. 

You can also access previous Models and Tips of the Month from the 
same site.
____________________________________________________________________

Also *** NEW *** for this month are:

	MODEL of the MONTH:  16 bit ADC in Verilog HDL
	
	The Doulos HLD Information Centre

	Additions to our 'Hardware Engineers Guide to VHDL' series
	
____________________________________________________________________

Also visit the Doulos site for:
	
	
	VHDL Quick Reference Card
	
	VHDL 93 Update Reference Card


_____________________________________________________________________

Also details of the latest Doulos VHDL and Verilog training
courses and how to get a FREE online VHDL tutorial.

	'TRAINING THAT GIVES YOU THE WINNING EDGE'

Tim Pagden
DOULOS
Church Hatch				Tel: +44 1425 471 223
22 Market Place				Fax: +44 1425 471 573
Ringwood BH24 1AW			Email: info@doulos.co.uk
UK

_____________________________________________________________________





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