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
> I am designing a system using a Xilinx XC4K-XL part, and have a > few unused pins. I remember that there is some way to measure the junction > temperature using an unused pin, but I cannot find the reference. I thought > that Peter Alfke had posted something, but I could not find the post. > > Thanks for any replies- > > Alan Sieving > ars@quickware.com > I haven't gotten around to trying it on a Xilinx part yet, but here's what I did a while ago for a big power-hungry ASIC: Using a low current (< 1 mA) source, forward bias one of the input protection diodes relative to ground and measure the forward voltage. I used my Fluke DVM's diode check function, which is not quite a constant current, but close enough. Immerse the chip (with test leads attached) in a pot of cold water, along with a thermometer. Gradually raise the water temperature to boiling, stirring constantly to promote mixing. Every few degrees, record the temperature and associated voltage. If someone asks what you are doing, tell them you are making silicon soup and cackle maniacally. When you're done, you have a calibration curve. For my chip, the voltage dropped from 0.54V to 0.44V between 20 and 100C. Now, with calibration curve in hand, you can in principle measure temperature of the operating die by measuring forward voltage and looking up the corresponding temperature. With such low-level measurements, there is plenty of room for noise and other effects to mess up the measurements, for example if the chip is drawing lots of power (else why measure it?) there will be an internal ground shift due to bonding wire resistance, etc. which reduces the measured diode voltage (and increases the apparent temperature). To get around this you could configure a nearby IOB as a constant zero output, and use that as your ground reference, which should mostly cancel the effect. Also for Xilinx, your thermal test pin should be configured as an input - probably best to disable the default pullup resistor. I wrote up an internal memo on this procedure and related topics which can be found at http://www.drao.nrc.ca/~tburgess/n300.pdf (1.1M) Since I wrote it, I have begun to doubt that a die edge measurement really gives a good worst case die temperature measurement (I think it could be much hotter at the die center), but it's better than nothing, I suppose. ----------- Tom Burgess National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.ca Office: (250) 490-4360 Switch Board: (250) 493-2277 Fax: (250) 493-7767Article: 11876
Hello all: In frustration of finding a good small application to fit in for my final year project, I am posting this message. I am looking forward to do a small nifty application using FPGA as my hardware engine and necessary front end s/w or driver. I would be interested in some web sites to look at some other people's project and also get an idea what FPGA can or can not do. I will be working on XC3000 series. My interests are in some home automation like application or some computer interfacing type application. Any ideas or pointers will be greatly appreciated. Thanks much in advance. .:*~*:._.:*~*:._.:*~*:._.:*~*:._.:*~*:. Ankit Shah Texas A & M University ankit@tamu.edu .:*~*:._.:*~*:._.:*~*:._.:*~*:._.:*~*:.Article: 11877
Sometimes relative truth is better than no truth. Simon ===================================== Tom Burgess <tom.burgess@hia.nrc.ca> wrote: snurbled >I wrote up an internal memo on this procedure and related topics which >can be found at http://www.drao.nrc.ca/~tburgess/n300.pdf (1.1M) > >Since I wrote it, I have begun to doubt that a die edge >measurement really gives a good worst case die temperature >measurement (I think it could be much hotter at the die center), >but it's better than nothing, I suppose. > > >----------- >Tom Burgess > >National Research Council of Canada >Herzberg Institute of Astrophysics >Dominion Radio Astrophysical Observatory >P.O. Box 248, Penticton, B.C. >Canada V2A 6K3 > >Email: tom.burgess@hia.nrc.ca >Office: (250) 490-4360 >Switch Board: (250) 493-2277 >Fax: (250) 493-7767 Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.Article: 11878
Thanks John... spelling was never my forte! -Ed > That's Monte CarloArticle: 11879
http://www.dnai.com/~jfox/fpgakit.htm Simon =============================================================================== Ankit Shah <ankit@drillbit.tamu.edu> wrote: >Hello all: > >In frustration of finding a good small application to fit in for my final >year project, I am posting this message. I am looking forward to do a >small nifty application using FPGA as my hardware engine and necessary >front end s/w or driver. I would be interested in some web sites to look >at some other people's project and also get an idea what FPGA can or can >not do. I will be working on XC3000 series. My interests are in some home >automation like application or some computer interfacing type application. > >Any ideas or pointers will be greatly appreciated. > >Thanks much in advance. > > >.:*~*:._.:*~*:._.:*~*:._.:*~*:._.:*~*:. > Ankit Shah > Texas A & M University > ankit@tamu.edu >.:*~*:._.:*~*:._.:*~*:._.:*~*:._.:*~*:. > > Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.Article: 11880
I am relatively new to FPGA design but am observing something that seems odd or impossible. I am using IOB flip-flops in the 4020e. I have a analyzer probe on the board trace that will be the input of the IOB flip-flop and have brought the output of the flip-flop to another package pin using the Probe feature in the Xilinx tools. I see transitions for whole clock cycles and for less than a clock cycle on the output of the flip-flop but no transition on the trace or input to the flop. Is this a ground bounce or power droop problem I have read about? Has anyone witnessed this and discovered a way to control it? I have used capacitors at all +5v pins and have power and ground planes. I do not believe the reset pin is being toggled or changed as I haven't seen it transition. Thanks MikeArticle: 11881
Years ago, we used to simuluate our designs with VSS with option -coverage for such things. I don't know, wheter this option still exists.... BestBench (Diagonal Systems) does this at least in the Testbench, but unfortunately not for the unit under test, as far as I know. Regards, AntonArticle: 11882
What is the best choice for use with an XC4000XL FPGA: synchronous or asynchronous SRAM? What's the advantage of synchronous SRAM, anyway?Article: 11883
SNUG '99 Call For Papers Ninth Annual Synopsys Users Group March 29 - March 31, 1999** DoubleTree Hotel San Jose, California **IMPORTANT NOTE: Dates of this Conference have been changed to Monday, March 29th - Wednesday, March 31st due to Holiday conflicts. Following the Conference, Synopsys is offering all day Training Center classes on Thursday, April 1st - Friday, April 2nd. These classes will be held at the Synopsys Mountain View campus. An Invitation to Contribute Share your experiences ... The success of our users group depends on the active participation of users who are willing to share their experiences with others. If you have information on high-level design methodology or experiences with Synopsys tools that would be of interest to other users, you are encouraged to present in one of the sessions described below. Awards First, Second and Third place awards will be given for "Best Paper". The winners are selected by the User Conference attendees. Awards will also be given for "Best Success Story", which will be based on the written paper and judged by the SNUG'99 Technical Committee. Preliminary User Breakout Sessions These sessions are always the hit of the conference. Hear Synopsys users' experiences on specific topics. Each user breakout session will consist of three presentations, twenty-five minutes each, with another five minutes for questions and answers. Preliminary topics include: Synthesis/Design Productivity: Strategies, experiences, and best practices for design productivity with an emphasis on synthesis. Users share experiences with automation techniques for synthesis. High-Level Verification/Simulation Techniques using Behavioral Coding: The higher level a design is coded, the more complex the design becomes to verify. This session calls for papers on behavioral system modeling approaches when given design descriptions and performance goals. Further discussion includes the verification/simulation strategies to ensure design correctness. High-Level Verification/Simulation Techniques - (VCS): System-level strategies covering design functional verification using Verilog and VCS. Users share experiences in developing a test bed to verify combined hardware and software systems for large complex designs. High-Level Verification/Simulation Techniques - (VSS): System-level strategies covering design functional verification using VHDL and VSS. Users share experiences in developing a test bed to verify combined hardware and software systems for large complex designs. Higher Levels of Abstraction/Behavioral Synthesis: User experiences with using behavioral synthesis are explored in this session. Topics include high-level design techniques, behavioral scheduling, datapath synthesis, pipeline retiming, and integration with other ASIC design and verification tools. Other topics include the methodology for top-down design, and high-level techniques for DSP design. Hardware/Software Co-design: Authors are invited to submit original papers describing recent experiences in designing and verifying embedded processor-based ASIC/SOC systems. This includes the methodologies used and tools required to handle tasks of verifying both the hardware and software before physical prototypes are available for these systems. Authors are encouraged to share their insights on the use of the EAGLEtools, Cyclone, VSS, and VCS from Synopsys and the overall impact on the project. Explore system design objectives: Users experience with system development, verification and integration. Deep Submicron/Large Designs/Power/Physical Design: This session concentrates on the unique challenges of submicron and low power design techniques that may involve: large design, deep submicron and physical aspects. Low power & physical design sessions provide experience with automating scripts for submicron, special techniques for managing wireloading, floorplanning, over consumption, and non-linear delay modeling. Makefiles Methodology/Configuration Management: This popular session addresses the increased effort to automate and extend the synthesis process through scripting. The session includes case studies by users who have taken advantage of the power of Make and Perl to drive synthesis iterations, to extend DC Shell, and to manage complex designs. Design Reuse: This session includes a practical methodology for design reuse based on real-world experiences. Issues and guidelines are explored. Does anybody really have a working Design Reuse methodology in place? Let us know about it and how it works. FPGA & PLD Synthesis: Concentrating on the unique challenges of programable logic, the tricks and techniques used for designing and synthesizing FPGAs or PLDs will be presented. Incremental synthesis, fanout control, and floorplanning issues relative to FPGAs will also be part of this section. Test - DFT: This session focuses on strategies and real-world experiences implementing a manufacturing test strategy (DFT) for large SOC-type designs. Various SCAN and isolation techniques are explored in the context of core-based designs. Techniques used to interface a DFT solution (Full or Partial) with synthesis and power will be included. Protocol Compiler: User experiences with Protocol Compiler in system or ASIC design, explaining what the advantages and disadvantages are of using Protocol Compiler over conventional HDL methodologies. Users will discuss how Protocol Compiler's high abstraction level eases the designing of structured data streams. Module Compiler: This session explores the use of Module Compiler to achieve high performance datapath designs, focusing on effective datapath synthesis strategies, coding styles, and integration with other ASIC design tools. User experiences with datapath synthesis are shared. PrimeTime Techniques/Formal Verification: This session explores strategies and user experiences using a static verification flow, concentrating on highlights and lowlights of static timing analysis using Primetime and Formal Verification using Formality. Further Information Please check the SNUG Web site for the latest information on conference dates, logistics, registration and ways you can contribute. Look for the SNUG logo on the Synopsys home page. http://www.synopsys.com To present your experiences with a contribution in a user session: 1. Please forward a brief summary description and an outline of your idea to the conference Technical Committee, (snug_tech@synopsys.com), by November 2nd, 1998. 2. You will be notified of your acceptance by November 18th, 1998. 3. When an Author is selected, an assigned Technical Committee member will work with them to develop and review the paper and presentation. 4. Please review Author's Kit for details on paper format, deadlines, and structure. Look for the SNUG logo on the Synopsys home page. http://www.synopsys.com Important Dates Papers for review are due by January 12, 1999. Final papers are to be completed by February 3, 1999. Registration Information Registration information is not available at this time. Early registration will start December 1, 1998. Check the web site frequently for the latest information. Look for the SNUG logo on the Synopsys home page. http://www.synopsys.com Preliminary SNUG '99 Schedule Monday, March 29th Morning Tutorial Sessions Afternoon Tutorial Sessions Evening R&D Cocktail Party /Synopsys New Product Demos Tuesday, March 30th Morning Executive Status Mid-Morning User Breakout Sessions Afternoon User Breakout Sessions Evening Cocktail Party / Vendor Fair Wednesday, March 31st Morning Tutorial Sessions Afternoon Tutorial Sessions THIS YEAR, DUE TO USER FEEDBACK, SYNOPSYS IS OFFERING TRAINING SESSIONS FOLLOWING THE CONFERENCE: Thursday, April 1st All day Synopsys Training Center (**Classes TBD) **Held at Synopsys, Inc., Mountain View Please check back by December 1, 1998 for updated information and registration. Friday, April 2nd All day Synopsys Training Center (**Classes TBD) **Held at Synopsys, Inc., Mountain View Please check back by December 1st, 1998 for updated information and registration. Who to Contact Should you wish to discuss your potential contribution, please feel free to contact your local Synopsys applications engineering manager or the SNUG'99 Technical Committee via email at snug_tech@synopsys.com. All email sent to this alias will be reflected to the User Group Technical Chairperson and the Technical Committee. These addresses are not for basic information on attending the conference itself. SNUG North America '99 Technical Chairperson Don Mills 640 North 2200 West MS F1-J12 Salt Lake City, UT Phone: 801-594-3270 donald.r.mills@L-3com.com SNUG North America '99 Conference Manager Renae Cunningham 700 E. Middlefield Road Mtn. View, CA. 94043 Fax: 650-528-4987 renae@synopsys.com SNUG North America '99 Conference Chairpeople Bob Hauser and Woody Norwood 700 E. Middlefield Road Mtn. View, CA. 94043 Fax: 650-528-4987 hauser@synopsys.com woody@synopsys.com =========================================================================== Trying to figure out a Synopsys bug? Want to hear how 6,000+ 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: 11884
So am I going crazy or is a -3 Spartan part slower than a -4, whereas in the 4K series, the -3 was the faster part? Curiuosly, MatthewArticle: 11885
Matthew: Its a long story.... ~1985: -NN where NN was the flip flop toggle rate in MHz... BIGGER is faster. People complained that FF toggle rate didn't accurately forecast device performance. ~1990: -N where N was Tlo, aprox number of ns through a 4 var Lut. SMALLER is faster. Now, that was close to a fact..... then came sub 1ns delays so there were -09s and the future looking even more ugly. 1998: Spartan -N where N is just a number.... BIGGER is now faster again. 2001: Who the heck knows? :) They're trying.... I'd give them that. -- Ed McCauley Bottom Line Technologies Inc. http://www.bltinc.com Specializing Exclusively in Xilinx Design, Development and Training Voice: (500) 447-FPGA, (908) 996-0817 FAX: (908) 996-0817 Matthew Robinson wrote: > > So am I going crazy or is a -3 Spartan part slower than a -4, whereas in the > 4K series, the -3 was the faster part? > > Curiuosly, > MatthewArticle: 11886
Hi - On Wed, 16 Sep 1998 17:40:45 +0200, Stefan Rave <rave@LS12.cs.uni-dortmund.de> wrote: >What is the best choice for use with an XC4000XL FPGA: synchronous or >asynchronous SRAM? What's the advantage of synchronous SRAM, anyway? Synchronous, hands down. You don't have to generate write pulses. (As an exercise, try generating a write pulse that is guaranteed to meet all RAM timing requirements.) Synch SRAM was a wonderful addition to Xilinx parts; let's thank Xilinx by using it. Take care, Bob PerlmanArticle: 11887
Brian Dipert just did a good article featuring the Accolade and Synopsys Tools (Foundation uses Synopsys). The article is available on line at http://www.ednmag.com It shows what a great buy both of these tools are, and especially the Accolade tool in MULTIVENDOR version. Also when you include the simulator in with the PeakVHDL suite, you have to conclude that the Peak suite is the best overall multivendor buy. You can get great buys on the Accolade and Foundation tools at http://www.associatedpro.com -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President Associated Professional Systems Inc. (APS) email: richard@associatedpro.com web site: http://www.associatedpro.com Phone: 410-569-5897 Fax: 410-661-2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 11888
Aw, shucks, thanks Richard (and don't forget, the article included MINC's PLSynthesizer too). Feedback (positive AND negative) appreciated, everyone! You can find the article in the September 11, 1998 issue, and make sure to check out the addendum link on the web version of the article too..... On Wed, 16 Sep 1998 23:55:18 -0400, Richard Schwarz <aps@associatedpro.com> wrote: >Brian Dipert just did a good article featuring the Accolade and Synopsys >Tools (Foundation uses Synopsys). The article is available on line at >http://www.ednmag.com It shows what a great buy both of these tools are, >and especially the Accolade tool in MULTIVENDOR version. Also when you >include the simulator in with the PeakVHDL suite, you have to conclude >that the Peak suite is the best overall multivendor buy. You can get >great buys on the Accolade and Foundation tools at >http://www.associatedpro.com Brian Dipert Technical Editor: Graphics, Memory and Programmable Logic EDN Magazine: The Design Magazine Of The Electronics Industry 1864 52nd Street Sacramento, CA 95819 (916) 454-5242 (916) 454-5101 (fax) ***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY*** edndipert@NOSPAM.worldnet.att.net Visit me at <http://members.aol.com/bdipert>Article: 11889
Matthew Robinson wrote: > > So am I going crazy or is a -3 Spartan part slower than a -4, whereas in the > 4K series, the -3 was the faster part? > > Curiuosly, > Matthew Sorry Matthew, I have no information on your mental state. 8< -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 11890
Bob, thanks for the pointer, it is helpful for my understanding. But I don't quite understand your remark, > Synch SRAM was a wonderful addition to Xilinx parts; let's thank > Xilinx by using it. Are you talking about internal SRAM cells (using CLBs)? Or does Xilinx provide synch SRAM? -- My original question referred to _external_ memory. StefanArticle: 11891
Matthew Robinson wrote: > So am I going crazy or is a -3 Spartan part slower than a -4, whereas in the > 4K series, the -3 was the faster part? > > Curiuosly, > Matthew Relax, you are not going crazy, Xilinx is! Do not forget that an XCS20 is in fact equivalent to an XC4010 (10K Xilinx FPGA gates, not to be confused with Altera gates or ASIC gates). ;-) Catalin BaetoniuArticle: 11892
I would like to Use an Atmel configuration EEPROM for my Xilinx Spartan device in a deliverable product, and maintain the ability to reprogram the EEPROM after the Xilinx is booted through the use of an onboard microcontroller and a Compact Flash card that will contain the new MCS file for the new Xilinx configuration. Has anyone done this before, and if so, are there any things I need to be wary of? Does anyone have any C-code for a similar application they could share with me to get me started? Thanks. Steve Mitchell Senior Electrical Engineer eMERGE Vision Systems -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member ForumArticle: 11893
To all you battle-hardened experts out there, I'm about to start teaching some EE undergraduates a course on digital design with the emphasis on getting it right in the real world. As a case study for this course I've chosen to get the students to design a DRAM controller, interfacing a CPU to a DRAM module. The chosen CPU is a fairly elderly one (NS32CG16) because it has a nice, simple, leisurely sort of bus cycle and it's very easy to introduce wait states as needed. So far so good. To make the problem a bit more interesting I am artificially restricting the DRAM data width to 8 bits and requiring the students to use DRAM fast page mode and some data latches to widen 8-bit RAM to 16-bit CPU as efficiently as possible. Of course this is not a truly representative problem, but it covers a good range of design challenges without being outrageously complicated. It also provides an opportunity to look at some fun stuff like write posting and speculative prefetch. Here's my problem: I'm trying to encourage the students to follow strict FPGA-friendly fully synchronous design methods, but as a result the design will cycle the DRAM extremely slowly. There are lots of reasons, but to give just one example, suppose I remove /CAS on some particular clock edge. I can't safely use that same clock edge to strobe the DRAM read data into a register because the DRAM's spec for data hold after /CAS trailing edge is only 0ns! So a 'safe' design will need to extend /CAS by A FULL CLOCK CYCLE after the data is taken. There are several more examples of similar situations - guaranteeing row adrs hold time after /RAS leading edge, for example - where an extra clock cycle has to be introduced, just to meet some asynchronous timing spec of only a few nanoseconds. Now, I'm old enough to remember the days when people would use delay lines to deal with this kind of thing, but that's not very fashionable nowadays. What I seek from the NG is not a solution to this particular problem - I can think of lots of them! - but, rather, some idea of the guidelines, design rules or theory that you up-to-date practising designers use when coping with this kind of problem and that I could pass on to my students as a distillation of typical good practice. Many thanks in advance Jonathan Bromley Lecturer in Industrial Electronics Oxford Brookes University, England -- ----------------------------------------------------------------- Electronics is fun. If you want me to take it seriously, call and we'll talk consultancy rates. -----------------------------------------------------------------Article: 11894
In a previous post I wrote: > > To all you battle-hardened experts out there, and then illustrated my problem with *the wrong example*, sorry. Just goes to show how confused I was. Getting adequate data hold after /CAS trailing edge is easy - causality does the job for you. The problem _is_ important, however, when trying to guarantee validity of addresses (and write data) before and/or after a strobe edge. The basic question posed in my post stands; the example I used to illustrate it was faulty. Apologies. Jonathan Bromley -- ----------------------------------------------------------------- Electronics is fun. If you want me to take it seriously, call and we'll talk consultancy rates. -----------------------------------------------------------------Article: 11895
Stefan (another one), > thanks for the pointer, it is helpful for my understanding. But I don't > quite understand your remark, > > > Synch SRAM was a wonderful addition to Xilinx parts; let's thank > > Xilinx by using it. > > Are you talking about internal SRAM cells (using CLBs)? Or does Xilinx > provide synch SRAM? -- My original question referred to _external_ > memory. Bob was talking about INTERNAL SRAM in the CLBs. His comments about write pulses hold also for external SRAM. Sync RAMs (S or D) are much more convenient than async RAMs. With sync RAMs, you (only) have to handle the clock signal carefully, whereas with async RAMs, there are the write pulses, ras/cas and the address lines, which have to be delay matched. Regards, Stefan Ludwig Systems Research Center Compaq Computer Corporation 130 Lytton Ave Palo Alto, CA 94301-1044 USA Tel: ++1 650 853 2227 Fax: ++1 650 853 2235 mailto:ludwig@pa.dec.com http://www.research.digital.com/SRCArticle: 11896
Park Chan Ik <park@iris.snu.ac.kr> wrote: >I am looking for the lookup table method to accelerate the >multiplication and division. > Sure, since your name looks so familiar :) Karatsuba and Ofman's paper is a must read. W. Stenzel, W. Kubitz, and G. H. Garcia, ``A Compact High-Speed Multiplication Scheme,'' IEEE Transactions on Computers, vol. C-26, pp. 948--957, Oct. 1977. A. Karatsuba and Y. Ofman, ``Multiplication of multidigit numbers on automata,'' Soviet Physics -- Doklady, vol. 7, pp. 595--596, Jan. 1963. T.C. Chen, ``A Binary Multiplication Scheme Based on Squaring, ''IEEE Transactions on Computers, vol. C-20, pp. 678--680, June 1971. J. R. Logan, ``A square-summing, high-speed multiplier'' Computer Design, pp.~67--70, June 1971. H. Ling, ``High-Speed Computer Multiplication Using a Multiple-Bit Decoding Algorithm,'' IEEE Transactions on Computers, vol. C-19, pp. 706--709, Aug. 1970. H. Ling, ``An Approach to Implementing Multiplication with Small Tables,'' IEEE Transactions on Computers, vol. C-39, pp. 717--718, May 1990. Last but not the least: Milos D. Ercegovac and Pak K. Chan. On reducing storage requirements of table-lookup multiplication. In Proc. 16th Asilomar Conference on Circuits, Systems and Computers, pages~217--221, Pacific Grove, California, November 1984. ----------- Pak K. Chan, CaliforniaArticle: 11897
Jonathan Bromley wrote: > . . . > Here's my problem: I'm trying to encourage the students to > follow strict FPGA-friendly fully synchronous design methods, but > as a result the design will cycle the DRAM extremely slowly. > There are lots of reasons, but to give just one example, suppose > I remove /CAS on some particular clock edge. I can't safely > use that same clock edge to strobe the DRAM read data into a > register because the DRAM's spec for data hold after /CAS trailing > edge is only 0ns! So a 'safe' design will need to extend /CAS > by A FULL CLOCK CYCLE after the data is taken. There are several > more examples of similar situations - guaranteeing row adrs hold > time after /RAS leading edge, for example - where an extra clock > cycle has to be introduced, just to meet some asynchronous timing > spec of only a few nanoseconds. I would use a fast clock and fast fpga so that one clock cycle is not a big deal. Some fpgas have clock multipliers on-chip. > > Now, I'm old enough to remember the days when people would use > delay lines to deal with this kind of thing, but that's not very > fashionable nowadays. What I seek from the NG is not a solution > to this particular problem - I can think of lots of them! - but, > rather, some idea of the guidelines, design rules or theory that > you up-to-date practising designers use when coping with this kind > of problem and that I could pass on to my students as a > distillation of typical good practice. I agree that delay lines are evil. I think you are correct to encourage conservative design practices even if it costs some speed. Sounds like a good exercise, but you might mention that many CPUs have dram control built-in so that all you have to do is load the registers right at boot time. -Mike TreselerArticle: 11898
Use a PLL to crank the clock speeds. Instead of an FPGA use PALs - they are faster. And cheaper. Reserve FPGAs for problems for which only they are the solutions. PLLs are very interesting esp w/respect to filter theory. 100 MHz clocks and PLDs for slicing time ought to give you the resolution you want. And you can adjust the PLL freq so there is little or no wasted time. Use ACT logic for glue. ( some of those suckers will clock at 125 MHz.) Simon =============================================================== Jonathan Bromley <jsebromley@brookes.ac.uk> wrote: >To all you battle-hardened experts out there, > >I'm about to start teaching some EE undergraduates a course on >digital design with the emphasis on getting it right in the real >world. As a case study for this course I've chosen to get the >students to design a DRAM controller, interfacing a CPU to >a DRAM module. The chosen CPU is a fairly elderly one (NS32CG16) >because it has a nice, simple, leisurely sort of bus cycle and it's >very easy to introduce wait states as needed. So far so good. >To make the problem a bit more interesting I am artificially >restricting the DRAM data width to 8 bits and requiring the >students to use DRAM fast page mode and some data latches to >widen 8-bit RAM to 16-bit CPU as efficiently as possible. >Of course this is not a truly representative problem, but it >covers a good range of design challenges without being >outrageously complicated. It also provides an opportunity to >look at some fun stuff like write posting and speculative >prefetch. > >Here's my problem: I'm trying to encourage the students to >follow strict FPGA-friendly fully synchronous design methods, but >as a result the design will cycle the DRAM extremely slowly. >There are lots of reasons, but to give just one example, suppose >I remove /CAS on some particular clock edge. I can't safely >use that same clock edge to strobe the DRAM read data into a >register because the DRAM's spec for data hold after /CAS trailing >edge is only 0ns! So a 'safe' design will need to extend /CAS >by A FULL CLOCK CYCLE after the data is taken. There are several >more examples of similar situations - guaranteeing row adrs hold >time after /RAS leading edge, for example - where an extra clock >cycle has to be introduced, just to meet some asynchronous timing >spec of only a few nanoseconds. > >Now, I'm old enough to remember the days when people would use >delay lines to deal with this kind of thing, but that's not very >fashionable nowadays. What I seek from the NG is not a solution >to this particular problem - I can think of lots of them! - but, >rather, some idea of the guidelines, design rules or theory that >you up-to-date practising designers use when coping with this kind >of problem and that I could pass on to my students as a >distillation of typical good practice. > >Many thanks in advance > >Jonathan Bromley >Lecturer in Industrial Electronics >Oxford Brookes University, England >-- >----------------------------------------------------------------- >Electronics is fun. If you want me to take it seriously, >call and we'll talk consultancy rates. >----------------------------------------------------------------- Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.Article: 11899
Mike Treseler <tres@tc.fluke.com> wrote: > >Sounds like a good exercise, but you might mention that many CPUs have >dram control built-in so that all you have to do is load the >registers right at boot time. I like the Z80 in this regard. Simon Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
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