Messages from 11875

Article: 11875
Subject: Re: measuring junction temperature
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Tue, 15 Sep 1998 17:50:42 -0700
Links: << >> << T >> << A >>

> 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-7767

Article: 11876
Subject: NEED: ideas on small project
From: Ankit Shah <ankit@drillbit.tamu.edu>
Date: Tue, 15 Sep 1998 19:58:55 -0500
Links: << >> << T >> << A >>

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
Subject: Re: measuring junction temperature
From: msimon@tefbbs.com
Date: Wed, 16 Sep 1998 01:45:08 GMT
Links: << >> << T >> << A >>

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
Subject: Re: ASIC -> FPGA async issues
From: Ed McCauley <emccauley@bltinc.com>
Date: Tue, 15 Sep 1998 21:46:37 -0400
Links: << >> << T >> << A >>

Thanks John... spelling was never my forte!


-Ed

> That's Monte Carlo

Article: 11879
Subject: Re: NEED: ideas on small project
From: msimon@tefbbs.com
Date: Wed, 16 Sep 1998 03:23:02 GMT
Links: << >> << T >> << A >>


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
Subject: Strange switching inside 4020e
From: mike mcginn <mrma@digital.net>
Date: Wed, 16 Sep 1998 02:40:53 -0400
Links: << >> << T >> << A >>

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
Mike

Article: 11881
Subject: Re: Code coverage tools
From: Scherer Anton <a.scherer@fh-aargau.ch>
Date: Wed, 16 Sep 1998 12:38:03 +0200
Links: << >> << T >> << A >>

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,
Anton

Article: 11882
Subject: sync or async SRAM?
From: Stefan Rave <rave@LS12.cs.uni-dortmund.de>
Date: Wed, 16 Sep 1998 17:40:45 +0200
Links: << >> << T >> << A >>

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
Subject: SNUG '99 Call For Papers, DATE CHANGE, & Prelim Schedule
From: jcooley@world.std.com (John Cooley)
Date: Wed, 16 Sep 1998 20:42:49 GMT
Links: << >> << T >> << A >>


                        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
Subject: Xilinx Spartan and 4K speed grades
From: "Matthew Robinson" <NOSPAMmprREMOVE@dolby.com>
Date: Wed, 16 Sep 1998 15:16:59 -0700
Links: << >> << T >> << A >>

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

Article: 11885
Subject: Re: Xilinx Spartan and 4K speed grades
From: Ed McCauley <emccauley@bltinc.com>
Date: Wed, 16 Sep 1998 21:47:13 -0400
Links: << >> << T >> << A >>

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,
> Matthew

Article: 11886
Subject: Re: sync or async SRAM?
From: bob@nospam.thanks (Bob Perlman)
Date: Thu, 17 Sep 1998 01:50:02 GMT
Links: << >> << T >> << A >>

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 Perlman

Article: 11887
Subject: Good EDN article on FPGA Synthesis
From: Richard Schwarz <aps@associatedpro.com>
Date: Wed, 16 Sep 1998 23:55:18 -0400
Links: << >> << T >> << A >>



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
Subject: Re: Good EDN article on FPGA Synthesis
From: edndipert@NOSPAM.postoffice.worldnet.att.net (Brian Dipert)
Date: 17 Sep 1998 05:23:23 GMT
Links: << >> << T >> << A >>

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
Subject: Re: Xilinx Spartan and 4K speed grades
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 17 Sep 1998 01:54:49 -0400
Links: << >> << T >> << A >>

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
Subject: Re: sync or async SRAM?
From: Stefan Rave <rave@LS12.cs.uni-dortmund.de>
Date: Thu, 17 Sep 1998 12:57:17 +0200
Links: << >> << T >> << A >>

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.

Stefan

Article: 11891
Subject: Re: Xilinx Spartan and 4K speed grades
From: Catalin <no@spam.com>
Date: Thu, 17 Sep 1998 09:18:30 -0400
Links: << >> << T >> << A >>

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 Baetoniu

Article: 11892
Subject: Onboard reprogramming of config EEPROM
From: sam@palmnet.net
Date: Thu, 17 Sep 1998 14:57:40 GMT
Links: << >> << T >> << A >>

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 Forum

Article: 11893
Subject: Help a confused teacher
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Thu, 17 Sep 1998 16:36:27 +0100
Links: << >> << T >> << A >>

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
Subject: Re: Help a confused teacher
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Thu, 17 Sep 1998 17:27:43 +0100
Links: << >> << T >> << A >>

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
Subject: Re: sync or async SRAM?
From: ludwig@pa.dec.com (Stefan Ludwig)
Date: 17 Sep 1998 17:08:31 GMT
Links: << >> << T >> << A >>

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/SRC

Article: 11896
Subject: Re: lookup table for mult/div
From: pak@cse.ucsc.edu (Pak K. Chan)
Date: 17 Sep 1998 17:26:11 GMT
Links: << >> << T >> << A >>

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, California

Article: 11897
Subject: Re: Help a confused teacher
From: Mike Treseler <tres@tc.fluke.com>
Date: Thu, 17 Sep 1998 10:41:16 -0700
Links: << >> << T >> << A >>



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: 11898
Subject: Re: Help a confused teacher
From: msimon@tefbbs.com
Date: Thu, 17 Sep 1998 19:15:39 GMT
Links: << >> << T >> << A >>

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
Subject: Re: Help a confused teacher
From: msimon@tefbbs.com
Date: Thu, 17 Sep 1998 19:17:29 GMT
Links: << >> << T >> << A >>

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

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

Custom Search