Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
!!! "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: 3576Greetings, 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’m 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’ll 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’ve 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’ll 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’t 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’ll 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’ll only get every other output sample, but that’s OK since this is a low pass. Shift is 21ea 16bit data registers. Of course, since I’m only using 10bits, the software gives lots of warnings about data widths not matching. OK, I’ll 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’re 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’t 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 FAXArticle: 3577
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
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
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: 3580Hi 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 XilinxArticle: 3581
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 XilinxArticle: 3582
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
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
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
>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.eduArticle: 3586
Seems to run on my machine. Takes alot of disk however (~300Mb)Article: 3587
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.comArticle: 3588
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: 3589In 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, SwitzerlandArticle: 3590
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>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: 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: 3593Hi, 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.comArticle: 3594
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.comArticle: 3595
> 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
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
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
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: 3599ANNOUNCEMENT: 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:
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