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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 1650

Article: 1650
Subject: Xilinx PROMs
From: John.Obenauf%aeup@msg.ti.com (John Obenauf)
Date: 10 Aug 1995 13:58:19 GMT
Links: << >>  << T >>  << A >>
Does anyone know of who makes alternative devices to Xilinx's PROMs?  
Specifically interested in the 1765 deivce.

Thanks;
   John.Obenauf%aeup@msg.ti.com



Article: 1651
Subject: Re: Xilinx PROMs
From: swam@adc.com (Steve Swam)
Date: 10 Aug 1995 15:33:28 GMT
Links: << >>  << T >>  << A >>
John Obenauf (John.Obenauf%aeup@msg.ti.com) wrote:
: Does anyone know of who makes alternative devices to Xilinx's PROMs?  
: Specifically interested in the 1765 deivce.

Atmel makes a series of replacement parts.  They are also reprogrammable.

sms


Article: 1652
Subject: SNUG Europe 1995 Invite & Registration
From: jcooley@world.std.com (John Cooley)
Date: Thu, 10 Aug 1995 17:42:46 GMT
Links: << >>  << T >>  << A >>
          SNUG Europe 1995 - Invitation and Registration
          Fourth Meeting, September 21, Brighton, England
          **********************************************

The Fourth Annual Synopsys European Users Group Conference (SNUG Europe)
will take place this year in Brighton on Thursday, September 21 during
EURO-DAC with EURO-VHDL 1995.

SNUG Europe will provide you with the opportunity to meet other Synopsys
users and share application ideas and experiences on your use of Synopsys
High-Level Design tools.   You will also have the chance to make an impact
on the development and direction of Synopsys technology by meeting and
discussing your methodology and tools needs with Synopsys managers,
research and development engineers and applications engineers.

Please note that EURO-DAC with EURO-VHDL '95 runs in Brighton from
September 18-21.  This event promises to build on the last three year's
success with a strong conference and tutorial programme, large vendor
exhibition and additional EDA events.   Justify your trip to SNUG Europe
with the added value of EURO-DAC and EURO-VHDL conference  and exhibition
participation.
______________________________________________________________________________

Conference Agenda Overview

The conference will be held over a single day. Throughout the day there
will be presentations from Synopsys users, semiconductor vendor partners as
well as tutorials to be given by Synopsys product specialists:

Thursday 21st - SNUG Europe '95
08:00-09:00 Registration

09:00-09:45 Welcome and Keynote Address
Synopsys Executive Q&A

10:00-12:15 Session 1
1A User Presentations - Deep Submicron
1B User Presentations - Verification
1C Tutorial I - Behavioral Synthesis
1D Tutorial II - COSSAP

12:15-13:15 Lunch

13:30-15:30 Session 2
2A User Presentations - Design Productivity
2B User Presentations - COSSAP
2C Semiconductor Vendor Partners I
2D Tutorial III - TestBench Solutions

15:30-16:00 Tea

16:00-18:00 Session 3
3A User Presentations - Behavioral Synthesis
3B Tutorial IV - Speed Opto
3C Semiconductor Vendor Partners II
3D Tutorial V - VHDL Synth. Method.

18:00-19:00 Cocktail Party

20:30-Late SNUG Europe Party - Brighton Sea-Life Centre
______________________________________________________________________________

Location

SNUG Europe '95 will be held at the Bedford Hotel, Brighton. This hotel is
approximately 300m away from the Metropole Hotel, where EURO-DAC with
EURO-VHDL '95 will be held.

Location details are as follows:
The Bedford Hotel
Kings Road, Brighton, Sussex BN1 2JF, Great Britain
tel: +44.1273.329.744, fax: +44.1273.775.877
______________________________________________________________________________

User Presentation Sessions

Design Productivity
The Design Productivity session includes papers describing synthesis flows
and methodologies, logic synthesis techniques and optimisation scripts,
HDL coding tricks, design for test, script automation.

Behavioral Synthesis
Papers included in this session describe how behavioral synthesis has been
integrated into existing design flows and discuss results in terms of
design productivity and quality of results.

Deep Submicron
The core theme incorporates methodology and techniques for dealing with
issues posed by designing to geometries of 0.6u and below. Papers in this
session discuss the essential requirement for linking synthesis to layout
and describe experiences and results using this flow.

Design Verification
The focal theme here is Verification and Simulation at all stages of the
design cycle. Subjects include system simulation tips, modelling
strategies, simulation sign-off procedure and pins-out verification

DSP Design with COSSAP
This session includes papers describing DSP system design and algorithmic
design using COSSAP. Also described are real system implementations using
COSSAP.
______________________________________________________________________________

Semiconductor Vendor Partner Session

Last year you told us that you needed more information on the design flows
and support from particular semiconductor vendors. This year we have
invited a number of ASIC and FPGA vendor partners to present their design
flows. You have the opportunity to find out more about the support provided
by those vendors that are present and can participate through questions and
discussion.
______________________________________________________________________________

Tutorial Sessions

Behavioral Synthesis
This session is intended for any synthesis user interested in behavioral
synthesis. Hardware designers are frustrated with lengthy IC design cycles
for increasingly complex, data-intensive, algorithmic applications. This
tutorial will show you how to enter your design specifications at the
behavioral level and use Behavioral Compiler to explore implementation
alternatives and determine the optimal architecture. Examples in VHDL will
be presented.

DSP Design using COSSAP
This session reviews DSP basics and applications. It provides a good
overview of DSP issues and particularly focuses on the COSSAP design
methodology to solve these issues.

TestBench Solutions
This tutorial introduces high-level testbenches. Three areas which are
important to consider when assessing design productivity are specification,
verification and implementation. Whereas implementation productivity has
greatly increased with the introduction of VHDL and HLD, testbench
productivity has not improved to the same degree. Testbenches are still
developed on a low level. This tutorial introduces concepts and provides
examples of high-level VHDL testbenches which use methods similar to those
that have proven themselves in HLD. The techniques presented show how to
raise the abstraction level, reuse testbenches, and achieve higher quality
of results.

Speed Optimisation
This tutorial is intended for experienced synthesis users who are
interested in a comprehensive methodology for speed-based optimisation
using Design Compiler.

VHDL Synthesis Techniques
This tutorial will present a wide range of tricks and techniques that will
improve the participants' overall VHDL productivity. Caveats based on
real-world coding scenarios will be explored and innovative solutions to
these problems will be provided in full detail. Topics will be presented in
the following areas: efficient VHDL models, unexpected analyze errors,
unexpected simulation results and modelling recommendations.
______________________________________________________________________________

User Presentations

The following is a preliminary list of User Presentations:

- Paul van Oostende, Alcatel Bell Telephone,  "Timing Driven Design -
Prerequisites"
- M. Helard, CCETT, "A Computer Simulated Satellite Chain - Design and
Performance with COSSAP"
- Claus Christensen, DSC Denmark, "Floorplanning, Layout and Logic Opto
with Synopsys and LSI"
- Jan Decalwe, Easics, "Integrating Behavioral Synthesis in the Design Flow"
- Vincent Olive, CNET, "Codevelopment and Mixed Simulation of Complex
Microprocessor"
- Chris Wilson, HAL Computer Systems, "Design Methodology for Large
Standard Cell Chips"
- Wolfgang Roessel, PKI, "Design Management and Environment for Increasing
Productivity"
- C. Razzle, Philips, "Using C++ for Algorithm Simulation in COSSAP"
- Christian Berthet, SGS-Thomson, "RTL Verification using Synthesis and -
Emulation"
- A Leeb, Siemens AG Villach, "ISDN Transceiver Design - From System
Concept to Implementation"
- Joachim Priesnitz, Siemens Nixdorf AG, "Synthesis links to Layout"
- Yves Columbe', Consultant, "Development of Data Encryption Processor
F2T088-xx DEP Family using Behavioral Compiler"
- Aedan Coffey, Toucan Technology, "Testbench Verification for Chip in 
a System"
- Ake Harpenen, Nokia Mobile Communications, "Successful Chip Design with
Behavioral Synthesis"
- Ray Beechnoir, NMRC, "Behavioral Compiler in Action - Experiences and Plans"
- Schoellkopf, SGS-Thomson, Inmos, "Floorplanning and Logic Optimisation -
Design Experience"
______________________________________________________________________________

SNUG Europe Party

This year's SNUG cultural event will take place at Brighton's Sea Life
Centre, which is located beside the Brighton Pier. The party will start
with a reception in the courtyard followed by casual guided tours through
the centre, where you will be able to stroke the Manta Rays and walk
through the Shark Tunnel. This will be followed by dinner with an
international flavour, including a Suschi Bar. The evening will conclude
late with a jazz band and open bar. This will provide a relaxing
opportunity to meet other Synopsys users and members of the Synopsys team.

Bus transport will be provided from The Bedford Hotel to The Sealife Centre
between 20:15 and 21:00. Return buses will run at 23:30 and 00:45.
______________________________________________________________________________

Advance Registration

Please complete the Advance Registration form below and post or fax it to
Catherine Bienbeau at HBI (note that fees are only payable on-site in
Brighton - see below).

                                HBI Helga Bailey International GmbH
                                Stefan-George-Ring 2
                                D-81929 M|nchen
                                Germany
                                tel: +49-89-99-38-87 ext 26
                                fax: +49-89-930-24-45

If you wish to register by e-mail, please send the requested information to

                                100347.2352@compuserve.com

Alternatively, registration is possible via the World-Wide-Web, through the
Events section of the Synopsys Home page on url:

http://www.synopsys.com/events.html

Advance Registration closes on Wednesday 13th September but Registration
and Payment will be possible on Wednesday 20th at the Bedford Hotel lobby
from 16:00 to 18:30 or  otherwise on the day.

Fees

Registration fees are ONLY payable on-site in Brighton. The fee will be
payable EITHER as cash or EuroCheque for UK PDS 100 (including VAT at
17.5%). - OR - by American Express, Master Card or VISA credit card payment
for US $160 (including VAT at 17.5%).
______________________________________________________________________________

SNUG Europe 1995 Advance Registration Form

Personal Details (Please duplicate this form for multiple attendees):

Name:           _________________________________
Title:          _________________________________
Company:        _________________________________
Address:        _________________________________
                _________________________________
                _________________________________

Phone:  ______________  Fax:    ______________  e-mail :  ________________

Please indicate your session preferences - (select one track per time slot):

10:00-12:15 Session 1
1A User Presentations - Deep Submicron
1B User Presentations - Verification
1C Tutorial I - Behavioral Synthesis
1D Tutorial II - COSSAP

13:30-15:30 Session 2
2A User Presentations - Design Productivity
2B User Presentations - COSSAP
2C Semiconductor Vendor Partners I
2D Tutorial III - TestBench Solutions

16:00-18:00 Session 3
3A User Presentations - Behavioral Synthesis
3B Tutorial IV - Speed Opto
3C Semiconductor Vendor Partners II
3D Tutorial V - VHDL Synth. Method.


Please indicate whether you will attend the SNUG 95 evening event -  YES   NO

Please indicate wheter you would like your name to appear on the SNUG
Europe '95 attendee list -  YES  NO


===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3661 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: 1653
Subject: Re: AT&T ORCA: Using register input mux?
From: fjk@nozone.cnet.att.com (f.j.koons)
Date: Thu, 10 Aug 1995 21:07:51 GMT
Links: << >>  << T >>  << A >>

AT&T is shipping v7.0 of Foundry. Contact an AT&T Sales Rep to arrange to upgrade
from 6.1.1 to v7.0.

Fred Koons
AT&T Microelectronics


Article: 1654
Subject: Re: VHDL/FPGAs/PLDs help
From: jcooley@world.std.com (John Cooley)
Date: Fri, 11 Aug 1995 00:25:50 GMT
Links: << >>  << T >>  << A >>
ravi@gpu.utcc.utoronto.ca (r. bansal) writes:
>What are the best books/internet resources to learn about VHDL/FPGA/PLDs etc.
>I have university-level knowledge of digital electronics but never took

<harrah1@ibm.net> wrote:
>	There is a VHDL book by Fred Perry that is pretty good, I think
>it is called 'VHDL Design'.

I'm going from memory as I'm at a client site, but I think the book
was by Doug Perry, who used to work at Redwood Design Automation
before it was bought by Cadence.  (I'm not try to pick nits here,
it's just that if Ravi goes to a book store to request this VHDL
book and uses the wrong name it can be a hassle to find the book.)

                           - 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 3443 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: 1655
Subject: Re: external connections for efficient internal routing
From: koch@eis.cs.tu-bs.de (Andreas Koch)
Date: Fri, 11 Aug 1995 11:07:25 GMT
Links: << >>  << T >>  << A >>
In article <40cv0k$5o7@btmpjg.god.bel.alcatel.be>,
Yuce Beser  <yuce@sh.bel.alcatel.be> wrote:
>george@cmf.nrl.navy.mil (George Schmitt) wrote:
>>
>>
>>Suppose I have an FPGA (xilinx 4005 specifically) with a 32
>>bit data path entering and a 16 bit data path exiting.  Data
>>enters, is "processed" and then exits.  The processing is
>>nothing more than a few pipelined registers and perhaps some
>>bit shifting and masking.  Would the internal routing of the
>>design be more efficient if the external connections were 
>>very regular (i.e. 16 IPADs clustered near each other and 
>>16 OPADs clustered near each other) or irregular (PADs just
>>"randomly" placed all around the chip).
>
>If you have critical time constraints that are difficult to be achieved, then
>it is better to specify these time constraints and leave the placement of IOs
>to the router. For some designs, it is not possible to satisfy both the time
>constraints and fixing the locations of IOs. If you leave it to the router, it
>usually ends up placing the data bus irregularly, and ends up with better
>delays. But, first I would try to achieve both, as regularity (as you define)
>helps board design be simple, and testing easier.
>
>
>Yuce Beser
>"speaking for myself"
>

Hmm, I can relate a different story. Our student labs include
the design & implementation of a simple 16-bit RISC processor on a
XC3090. On more than one occasion, a design that could not be
implemented using floating IOBs (even without the -y option for APR)
passed thru P&R after the regular components (data & address bus)
were IOB-locked in a regular fashion. Not only that, but APR run-times
decreased markedly.

- Andreas Koch

-- 
Andreas Koch                                   Email  : koch@eis.cs.tu-bs.de
Institut f"ur theoretische Informatik          Phone  : x49-531-391-2384
Abteilung Entwurf Integrierter Schaltungen     Phax   : x49-531-391-5840
Gaussstr. 11, D-38106 Braunschweig, Germany    Telex  : 95 25 26


Article: 1656
Subject: Re: VHDL/FPGAs/PLDs help
From: walton@emc.com (John Walton)
Date: 11 Aug 1995 11:13:50 GMT
Links: << >>  << T >>  << A >>
<harrah1@ibm.net> wrote:
>	There is a VHDL book by Fred Perry that is pretty good, I think
>it is called 'VHDL Design'.

VHDL
Douglas L. Perry
McGraw-Hill, Inc.
1991
ISBN 0-07-049433-9


Article: 1657
Subject: Re: VHDL/FPGAs/PLDs help
From: salix@clark.net (Dan Simpkins)
Date: 11 Aug 1995 08:40:15 -0400
Links: << >>  << T >>  << A >>
In article <40fe1e$if8@ns0.emc.com>, John Walton <walton@emc.com> wrote:
><harrah1@ibm.net> wrote:
>>	There is a VHDL book by Fred Perry that is pretty good, I think
>>it is called 'VHDL Design'.
>
>VHDL
>Douglas L. Perry
>McGraw-Hill, Inc.
>1991
>ISBN 0-07-049433-9


The book is actually in its second edition.  That should be:

VHDL (second edition)
Douglas L. Perry
McGraw-Hill, Inc.
1994
ISBN 0-07-049434-7  <-- Note new ISBN

I've only recently begun reading/using the book (it was recommended by our 
VHDL tool supplier) so I can't give an opinion yet.

Regards,

Michael Coren
Staff Engineer
SALIX Technologies, Inc.
9400 Key West Ave, Suite 275
Rockville, MD  20850
Tel: (301) 738-8284
Fax: (301) 738-8289
mikec@salixtech.com



Article: 1658
Subject: Re: Xilinx PROMs
From: rxjf20@email.sps.mot.com (Doug Shade)
Date: 11 Aug 1995 16:35:51 GMT
Links: << >>  << T >>  << A >>
In article <40d39r$5hk@mksrv1.dseg.ti.com>
John.Obenauf%aeup@msg.ti.com (John Obenauf) writes:

> Does anyone know of who makes alternative devices to Xilinx's PROMs?  
> Specifically interested in the 1765 deivce.

Microchip sells 37LV65 and 37LV128 (64K & 128k, 8 pin)
Motorla sells MPA1765 and MPA17128 (64K & 128k, 8 pin)

Support on Logical Devices, System General and DATA I/O programmers
will be available next releases (or sooner on BBS services). 

Doug Shade
rxjf20@email.sps.mot.com


Article: 1659
Subject: Re: VHDL/FPGAs/PLDs help
From: nsoria@joule.elee.calpoly.edu (Nelson Soria)
Date: 11 Aug 1995 16:55:21 GMT
Links: << >>  << T >>  << A >>
In article <DD4EJ2.GLD@world.std.com>,
John Cooley <jcooley@world.std.com> wrote:
>ravi@gpu.utcc.utoronto.ca (r. bansal) writes:
>>What are the best books/internet resources to learn about VHDL/FPGA/PLDs etc.
>>I have university-level knowledge of digital electronics but never took
>
><harrah1@ibm.net> wrote:
>>	There is a VHDL book by Fred Perry that is pretty good, I think
>>it is called 'VHDL Design'.
>
>I'm going from memory as I'm at a client site, but I think the book
>was by Doug Perry, who used to work at Redwood Design Automation
>before it was bought by Cadence.  (I'm not try to pick nits here,
>it's just that if Ravi goes to a book store to request this VHDL
>book and uses the wrong name it can be a hassle to find the book.)
>
>                           - John Cooley
>                             Part Time EDA Consumer Advocate
>                             Full Time ASIC, FPGA & EDA Design Consultant
>
>===========================================================================


Dauglas L. Perry
 VHDL--2nd ed.
 ISBN 0-07-049434-7

 TK7885.7.p47 1993  (This is the call number if you want to go to your lib.

Publisher:  McGraw-Hill, Inc.
            1221 Avenue of the Americas
            New York, NY 10020

Price:  $50.00

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

Nelson Soria
nsoria@joule.calpoly.edu




Article: 1660
Subject: Re: Clocking methods - which is prefered?
From: ksteele@silcom.com
Date: 11 Aug 1995 20:54:36 GMT
Links: << >>  << T >>  << A >>
I/O mapped ISA interfaces are seldom done sync to BCLK..
your second method should be fine..............

/*******************************************************
    Kevin Steele                             Motion Engineering, Inc
    ksteele@silcom.com                      Santa Barbara  CA
/*******************************************************



Article: 1661
Subject: Re: Xilinx PROMs
From: ksteele@silcom.com
Date: 11 Aug 1995 21:05:37 GMT
Links: << >>  << T >>  << A >>
In <40d8s8$pod@ingate.adc.com>, swam@adc.com (Steve Swam) writes:

>John Obenauf (John.Obenauf%aeup@msg.ti.com) wrote:
>: Does anyone know of who makes alternative devices to Xilinx's PROMs?  
>: Specifically interested in the 1765 deivce.
>
>Atmel makes a series of replacement parts.  They are also reprogrammable.


What Atmel parts are you referring to, specifically?




/*******************************************************
    Kevin Steele                             Motion Engineering, Inc
    ksteele@silcom.com                      Santa Barbara  CA
/*******************************************************



Article: 1662
Subject: Re: Xilinx PROMs
From: chan_isd@ix.netcom.com (Scott Evans)
Date: 12 Aug 1995 06:19:02 GMT
Links: << >>  << T >>  << A >>
In article <40ggn1$41o@ocean.silcom.com>, ksteele@silcom.com wrote:
>In <40d8s8$pod@ingate.adc.com>, swam@adc.com (Steve Swam) writes:
>
>>John Obenauf (John.Obenauf%aeup@msg.ti.com) wrote:
>>: Does anyone know of who makes alternative devices to Xilinx's PROMs?  
>>: Specifically interested in the 1765 deivce.
>>
>>Atmel makes a series of replacement parts.  They are also reprogrammable.
>
>
>What Atmel parts are you referring to, specifically?
>
>
>
>
>/*******************************************************
>    Kevin Steele                             Motion Engineering, Inc
>    ksteele@silcom.com                      Santa Barbara  CA
>/*******************************************************
>
AT17C65
AT17C128

fpga@atmel.com
408 436 4119


Article: 1663
Subject: Re: external connections for efficient internal routing
From: fliptron@netcom.com (Philip Freidin)
Date: Sat, 12 Aug 1995 08:13:44 GMT
Links: << >>  << T >>  << A >>
In article <GEORGE.95Aug9103953@halibut.cmf.nrl.navy.mil> george@cmf.nrl.navy.mil writes:
>
>
>Suppose I have an FPGA (xilinx 4005 specifically) with a 32
>bit data path entering and a 16 bit data path exiting.  Data
>enters, is "processed" and then exits.  The processing is
>nothing more than a few pipelined registers and perhaps some
>bit shifting and masking.  Would the internal routing of the
>design be more efficient if the external connections were 
>very regular (i.e. 16 IPADs clustered near each other and 
>16 OPADs clustered near each other) or irregular (PADs just
>"randomly" placed all around the chip).

The ANSWER is .... it depends  :-)

The number one rule in the docs from ALL fpga vendors is
'don't lock the pins'.  I believe the reason is that this is
the easy answer from the vendors, because they can't be bothered
explaining how to lock down pins in a safe manner. ( Some one
find an app note to prove me wrong  :-)  ).  If you lock the
I/O pins without regard for what's inside the chip, the results
tend to be tragic, unless you happen to be very lucky ( like
picking lotto numbers, only the payoff is not as great). Here
is some of what you need to know, and some guidelines for the
XC3000, XC3100, XC3000A, XC3100A, XC4000, XC4000A, XC4000H, and
XC4000E families of FPGAs.

All these devices have horizontal longlines with tbufs on them
(2 per row of the chip) and the XC4000? families have additional 
horizontal long lines without tbufs (2 or 4 more). All these devices
have vertical long lines (depending on product, from 3 to 10 of them).

The horizontal line are good for distributing data horizontally across 
the chips (whether you use or not the tbufs). By this I mean that on a
given row, there is one or two bits of each element that is connected
to the data path. Data path functions are 'thin' vertical structures
that are at right angles to the data flow (left-right). These data
path structures are placed side by side, with their equivalent bits
on the same row. For most applications with any XC3K or XC4K device,
the logic can be arranged as two bits per tile (or CLB). So if I have
two 16 bit registers that feed 16 muxes (each a 2 input 1 output mux),
and that feeds a 16 bit adder, which feeds a register, the output of
which feeds the other input of the adder, then my floor plan might be
a datapath block that is 8 rows high (16 div 2), and 5 column wide,
one column for each of the 3 registers, and one for the muxes, and
another for the adder. (in reality, I could pack this into 3 columns
but that would confuse this explanation too much. ) By convention I
almost always build my datapaths with the LSB at the bottom, (and big
surprise, the MSB at the top).

The vertical lines are good for distributing control signals like 
mux-sel, FF-CE, FF-CLK, FF-RD, TBUF-OE, RAM-ADDR, RAM-WE, RAM-PORT-SEL. 
Clearly (is this clear?), the above described data path would benefit
from these control signals using the vertical long lines.

Given the above, you could now allocate (and lock) pins on the left
or right side of the chip, and if you do it with reasonable care,
you might even use the appropriate I/O pads that are adjacent to 
the end of each row. In all the above listed families, (except the
XC4000H and devices that are in low-pin count packages) there are
two I/O pads on the left side and two more on the right side of
each row of logic, so this aligns well with 2 bits per row topology.

Now let's look at your example.
You have 32 bits in, 16 out and your data path includes registers,
masking, and shifting, and the target is the old XC4005.
The XC4005 is a 14 by 14 chip, so there is a challenge here. On the
other hand, your data path sounds trivial, so the XC4005 is probably
overkill.
Here are some more interesting items: data path elements fall into
two distinct categories, those that communicate between the bits
such as counters, adders and shifters, and those that have basically
independent bits such as muxes, registers, and rams.
Unfortunately you don't indicate how you are getting from 32 inputs
to 16 outputs. Here are two possible ways: Way #1: input bits 0,1 are
used to gen output 0, inputs 2,3 gen output 1, .... inputs 30,31 gen
output 15. Way #2: inputs 0,16 -> out 0, in 1,17 -> out 1, ...
in 15,31 -> out 15.
The other issue is where the shifter is in the data path, and
how many bit positions can it shift. Usually a shifter in a data path
may be as simple as wires, or muxes (if different shift ammounts).

Since I am assuming that your data path is as simple as described
above, I will assume also that the shift is by either 0 or 1 bit
position, and the 32 to 16 merge is Way 1. I have chosen these so I
can describe a pinout for you, and end this long article soon. If
the above assumptions are not correct, then the following will need
to be modified.
The big suprise is that after explaining all the above neat stuff
for horizontal and vertical longlines, and how to lay out a data
path, I don't think it is relevant to this example. That's because
of:
	1) 32 bit data path needs 16 rows, but XC4005 only has 14
	2) the inter communication between bits within data path
	   elements is very light (only in the shifter, and a
	   little in the 32 to 16 merge)
	3) the data path is trivial.

Let's assume that we treat the whole thing as a bit-slice structure.
first identify the number of bits per slice, then the I/O.
Ans: slices are 2 bits wide, because of 32 to 16 merge.
External I/O is 2 inputs and 1 output.
Inter-Slice I/O is 1 bit for the shifter (when it is doing a shift
by 1. Unused when shifting by 0.)

So for this now hypothetical design, I would build this slice,
and place them in sequence around the perimeter of the chip, and
lock three I/O pins near each one, two inputs and an output.
The performance of the design will be quite high (near the limit
of what the silicon can do), and the router will have no trouble
with it either. Unfortunately your PCB will have to deal with
having the two busses interwoven, but at least they are both in
bit order, and on a 4 layer board or better, it is no big deal.

>Thanks.
>
>-George
> george@cmf.nrl.navy.mil
>

I would appreciate email indicating if these long articles that I
post are helping people or just using too much bandwidth. The above
took me about an hour to type in and correct and re-read and change
and there are other things I could have done with the hour, if these
long post are just annoying people.

Philip Freidin,		fliptron@netcom.com

I once read a story of a techie-guru guy who's idea of an ideal work 
environment would be if he won the lottery (or was otherwise 
independently wealthy) and had access to a high tech firms sw/eng dept. 
He would sneak in at night and work on other peoples designs and do
really great (remember, he's a guru) stuff and fix things and make a
really great contribution, and never have to do reviews, attend
meetings, or have to deal with managers  :-) 
Thats almost what I do at Fliptronics, except I'm not independently
wealthy, and I still have to attend meetings and reviews, and deal
with managers.  :-)


Article: 1664
Subject: Re: external connections for efficient internal routing
From: george@cmf.nrl.navy.mil (George Schmitt)
Date: 12 Aug 1995 13:59:31 GMT
Links: << >>  << T >>  << A >>

Everyone, thanks for the replies so far.  Even if I 
havent responded to them individually yet, I have been
reading them and learning from them.

-George

> I would appreciate email indicating if these long articles that I
> post are helping people or just using too much bandwidth. The above
> took me about an hour to type in and correct and re-read and change
> and there are other things I could have done with the hour, if these
> long post are just annoying people.
> 
> Philip Freidin,		fliptron@netcom.com


Article: 1665
Subject: Re: Clocking methods - which is prefered?
From: jhallen@world.std.com (Joseph H Allen)
Date: Sat, 12 Aug 1995 14:05:47 GMT
Links: << >>  << T >>  << A >>
In article <40avle$4gc@sake.wwa.com>, Alan Weir <aweir@onsys.com> wrote:
>If one were to implement an ISA interface (for example) which includes an
>IOW- signal with lots of data setup and hold prior to/following the 
>rising edge, which would be the prefered implementation of a write 
>register.

>o - Use the IOW- signal as the register clock and the Register Select 
>    signal as the Clock Enable.

I usually use the IOW signal as the ram or register clock line. If you need
to syncronize to an internal clock, it is easy to have IOW and IOR trigger a
flip flop which pulls the wait line low until the your logic is ready.  Then
after your logic releases READY, you must wait until IOW is returned high
(this requires that you synchronize IOW to your clock with two FF in series
to avoid metastability problems).  This works if your clock is higher than
BCLK and is simplified (only need 1 FF to synchronize IOW) if you can use
BCLK for your own clock.  It gets really tricky though if your clock is
slower than BCLK: by the time you're done waiting for IOW to return high, it
may have gone low again before you're quite ready to handle it.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}


Article: 1666
Subject: Re: Xilinx PROMs
From: jothi@singnet.com.sg
Date: Sat, 12 Aug 95 09:50:33 PDT
Links: << >>  << T >>  << A >>

> Does anyone know of who makes alternative devices to Xilinx's PROMs?  
> Specifically interested in the 1765 deivce.
>    John.Obenauf%aeup@msg.ti.com
> 

Hi, 
I heard that ATMEL is making a chip which can replace the XC1756D and is
reprogamable too.

Thanks
Baskaran K
jothi@singnet.com.sg



Article: 1667
Subject: verilog to fpga ?
From: muzok@msn.com (muzo)
Date: Sun, 13 Aug 1995 02:48:33 GMT
Links: << >>  << T >>  << A >>
hi,
what tools are available for converting verilog code to specific programmable
device codes ? Also are there any tools to convert fpga designs to verilog ?

thanks ahead

muzo

standard disclaimer



Article: 1668
Subject: Re: Xilinx PROMs
From: jeff_cunningham@fostex.com (Jeff Cunningham)
Date: 13 Aug 1995 20:18:30 GMT
Links: << >>  << T >>  << A >>
In article <40g0t7$oo3@newsgate.sps.mot.com>
rxjf20@email.sps.mot.com (Doug Shade) writes:

> In article <40d39r$5hk@mksrv1.dseg.ti.com>
> John.Obenauf%aeup@msg.ti.com (John Obenauf) writes:
> 
> > Does anyone know of who makes alternative devices to Xilinx's PROMs?  
> > Specifically interested in the 1765 deivce.
> 
> Microchip sells 37LV65 and 37LV128 (64K & 128k, 8 pin)
> Motorla sells MPA1765 and MPA17128 (64K & 128k, 8 pin)

AT&T makes a reprogrammable version of xilinx type serial PROMs. I
don't recall what sizes they have.


Article: 1669
Subject: Re: Xilinx PROMs
From: mharris@quadrant.com (Michael R. Harris)
Date: Sun, 13 Aug 1995 14:27:58 LOCAL
Links: << >>  << T >>  << A >>
In article <40d39r$5hk@mksrv1.dseg.ti.com> John.Obenauf%aeup@msg.ti.com (John Obenauf) writes:
>From: John.Obenauf%aeup@msg.ti.com (John Obenauf)
>Subject: Xilinx PROMs
>Date: 10 Aug 1995 13:58:19 GMT

>Does anyone know of who makes alternative devices to Xilinx's PROMs?  
>Specifically interested in the 1765 deivce.

>Thanks;
>   John.Obenauf%aeup@msg.ti.com

I've seen some alternatives for the smaller parts... but I'm using the 
17C256?
Any alternatives for this one?

Mike Harris
Quadrant International



Article: 1670
Subject: Re: Xilinx FPGAs ---> Xilinx EPLDs
From: daveb@perth.DIALix.oz.au (David Brooks)
Date: 14 Aug 1995 07:38:03 +0800
Links: << >>  << T >>  << A >>
randraka@ids.net writes:

>In Article <DD299t.ILH@serval.net.wsu.edu>
>aguyer@eecs.wsu.edu (Al Guyer) writes:
>>We have designs using the XC4003 and have tested and perfected (to a
>>limited extent ;)  ) our design.  We have heard that it is possible to
>>take the bitstream for the XC4003 and write it to a Xilinx EPLD.
>>
>>Is this for real?  We sure could use such an option, since it would
>>help immensely with our final design.


>No, you can't put the bitstream into the EPLDs.  There are two options that are
>open to you however:
>  1.  Use a hardwire part, which is a mask programmed version of the SRAM FPGA. 
>      Since this has to be done in fabrication of the part, it only makes sense 
>      if you volume supports the nre.

>  2.  Assuming you used the unified libraries, you can change the library and
>      to the EPLD you are targeting and re-run PPR.  This won't get you the
>      same timing or layout, but it is better than starting from scratch. 
>      If your design is tight in terms of performance or size, you may need to 
>      do some redesign to tailor it to the EPLD architecture to improve it.  
>      While not a magic cure-all, the use of the unified library can be 
>      helpful in circumstances like yours.
>-Ray Andraka

[snip]
A third option is to go to third-party vendors (Orbit Semiconductor 
certainly, and I believe there are others). They can take your XNF files 
and compile them into a gate-array. Orbit's entry quantities are much 
lower than Xilinx hardwire. You provide simulation data from which the 
gate array design is validated.
-- 
David R. Brooks <daveb@perth.DIALix.oz.au>    Tel/fax. +61 9 434 4280
There is no subversive/criminal/steganographic message hidden in this sig
(Do you believe that?)


Article: 1671
Subject: Need information on MACH,FLEXlogix,ISPlsi
From: albo@pi.net (Alfred Bos)
Date: Mon, 14 Aug 1995 12:08:29 GMT
Links: << >>  << T >>  << A >>
Who can tell me where I can find information about INTEL/ALTERA's
FLEXlogix, AMD's MACH and Lattice's ISPlsi. 

Free sotfware or text files or whatever.
Greetings,
     Alfred Bos (albo@pi.net)




Article: 1672
Subject: Re: Xilinx xc4013 routing problems ??
From: John Forrest <jf@ap.co.umist.ac.uk>
Date: 14 Aug 1995 15:21:11 GMT
Links: << >>  << T >>  << A >>
In article <08-08-1995.66392@dilleng> Tom Dillon, tom@dilleng.wa.com
writes:
>>I'm a fairly new user of Xilinx FPGAs.
>>I'm having a few problems with my current design using a Xilinx xc4013
>>FPGA. With only around 84% CLB utlilzation and under 40% flip-flop
>>utilization, the XACT software is crashing on routing. It always ends up
>>with 70 unroutes.
>>
>>I'm sure I'm not pushing it to more than available routing resources when
>>the CLB utilization is not filled.
>>
>>Handrouting all the signals is the last thing that I'm opting for.
>>
>>Any help is well appreciated
>
>That is a very high usage for a 4013. It would be more confortable around 60 to 65%.
>

I'm used to getting above 85% utilisation on 4010s - does this mean that
utilisation under 4013s is nothing like as good? 

_____________________________________________________________
Dr John Forrest           Tel: +44-161-200-3315
Dept of Computation       Fax: +44-161-200-3321
UMIST                  E-mail: jf@ap.co.umist.ac.uk
MANCHESTER M60 1QD
UK


Article: 1673
Subject: Timespecs in XNF format
From: John Forrest <jf@ap.co.umist.ac.uk>
Date: 14 Aug 1995 15:22:46 GMT
Links: << >>  << T >>  << A >>
Does anyone know the format of timespecs in Xilinx XNF v5. I want to
include
some in a handwritten xnf file.

Even an example would help.

John

_____________________________________________________________
Dr John Forrest           Tel: +44-161-200-3315
Dept of Computation       Fax: +44-161-200-3321
UMIST                  E-mail: jf@ap.co.umist.ac.uk
MANCHESTER M60 1QD
UK


Article: 1674
Subject: Question about intro. Xilinx software
From: "Ingo Cyliax" <cyliax@cs.indiana.edu>
Date: Mon, 14 Aug 1995 11:55:19 -0500
Links: << >>  << T >>  << A >>

Has anyone used the Xilinx Viewlogic base software as advertised by DigiKey
for $1000 ? How useful is it ? It claims it can target XC4000-4003 and
XC3000-3042 devices and has Viewlogic libraries. Does it have provisions for
reading *.xnf netlists ? Also, can it generate EPROM images that can be used
to programm serial EPROMs as well as 8bit parallel EPROMs ?

I already have a CAD package (from Phase III) and libraries that can
generate .xnf netlists and am wondering whether buying this kit will provide
me with enough functionality to design some simple to medium complexity
Xilinx FPGAs for evaluation and prototyping. I was also hoping to write a
backend to chipmunk's diglog for generating XNF files, if I have time.

If this package isn't very useful, what would be the cheapest/best software
solution to evaluate Xilinx FPGAs.

Thanks, -ingo
-- 
/* Ingo Cyliax, cyliax@cs.indiana.edu, +1 812 333 4854, +1 812 855 6984 (day) */




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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search