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
Does anyone know of who makes alternative devices to Xilinx's PROMs? Specifically interested in the 1765 deivce. Thanks; John.Obenauf%aeup@msg.ti.comArticle: 1651
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. smsArticle: 1652
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: 1653AT&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 MicroelectronicsArticle: 1654
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: 1655In 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 26Article: 1656
<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-9Article: 1657
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.comArticle: 1658
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.comArticle: 1659
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
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
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: 1662In 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 4119Article: 1663
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
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.comArticle: 1665
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> 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.sgArticle: 1667
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 disclaimerArticle: 1668
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
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 InternationalArticle: 1670
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
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: 1672In 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 UKArticle: 1673
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 UKArticle: 1674
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:
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