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
> 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: 11877Sometimes 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: 11884So 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: 11888Aw, 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 Treseler
Article: 11898Use 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