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: 1653
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 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: 1655
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 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.eduArticle: 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: 1662
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 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: 1672
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 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