Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Messages from 13425

Article: 13425
Subject: Re: Interfaces to an Asynchronous SRAM
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Wed, 02 Dec 1998 10:46:47 -0500
Links: << >>  << T >>  << A >>
You don't say what the cycle time needs to be. Assuming you can use multiple
clock cycles to interface the ram.....

        __    __    __    __    __    __    __    __    __    __
CLK  __|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|

    ___  ________________  ________________  ________________  _
A/D ___{}________________{}________________{}________________{}_

     ________       ___________       __________________________
R/Wn         \_____/           \_____/

Cycle        WRITE1            WRITE2            READ1

This example uses 3 clocks/cycle, in your case 10 Mhz (100 ns) access. If this
is ok, this is a clean way to do it. If you don't mind using both rising and
falling edges in your design, here is another way that allows for 15 Mhz
access....

        __    __    __    __    __    __    __
CLK  __|  |__|  |__|  |__|  |__|  |__|  |__|  |

    ___  __________  __________  __________  _
A/D ___{}__________{}__________{}__________{}_

     _____       _____       _________________
R/Wn      \_____/     \_____/

Cycle     WRITE1      WRITE2       READ1

Hope this helps.


Louis Zhang wrote:... snip ...

> The problem of the asynchronous SRAM is with its write operation, where
> the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> address (and data) is stable, and deasserted ('1') "shortly" before the
> address (and data) changes.  In other words, R/Wn has to be deasserted
> ('1') when address or data change.
>
> The desired waveform looks like this:
>
> CLK= 30MHz
>
>           _______         _______         ________        ________
> CLK      |       |       |       |       |        |      |        |
>      ____|       |_______|       |_______|        |______|        |_____
>
> R/Wn _______           ______           _______________________________
>             |          |     |         |
>             |__________|     |_________|
>
> Addr -------------------------------------------------------------------
>       RA0 |     WA0        |    WA1        |     RA1        |   RA2
>           |                |               |                |
>      -------------------------------------------------------------------
>



--
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>


Article: 13426
Subject: Re: Is it normal to have to edit the xnf file???
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Wed, 02 Dec 1998 10:55:17 -0500
Links: << >>  << T >>  << A >>


ez wrote:

<some text deleted>

> Did the people that created FPGA Express ever used their
> own tools ????? It seems they like to click their mouse all
> the time, yes, when updating a design that contains errors,
> you have to click another design first and then click the
> updated design to see the errors. Oh, well, meanwhile you
> can always entertain yourself watching their beautiful
> 'Internet Explorer copy' flashing lamp to keep yourself from
> getting nervous.

 FPGA Express comes from Synopsis and is bundled by Xilinx. I agree it
sucks! Fortunately, the only thing I use it for is my grad course in
Verilog. At work we use a "real man's" synthesizer... Exemplar's
Leonardo.

Just in case Synopsis is listening, here are a few suggestions...

1) TCL scripting. Let the designers make a script that they can use over
and over instead of click, click, click, click..... click!
2) How about better reporting? Give us a clue as to how well the tool is
optimizing the design. How many levels of logic did the tool make?
3) A way to run everything from NT command line, so that synth and
back-end can all be run from batch file w/o user interaction.

--
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>


Article: 13427
Subject: Minimum clock freq reqd
From: shailbains007@my-dejanews.com
Date: Wed, 02 Dec 1998 16:36:13 GMT
Links: << >>  << T >>  << A >>
What factors would determine the *lowest* clock frequency that can drive a
given digital circuit? (I can very well understand the existence of a an
upper limit.)

I think this kind of limit doesn't exist on all digital circuits. Can you
come up with a possible scenario that would place a limit on the MINIMUM
clock freq reqd?

One possible scenario: DRAM circuitry would fail if the r/w clock freq is
less than the refresh rate.


Thanks in advance,
--shail

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Article: 13428
Subject: Re: XILINX FPGA reaches GHz speeds
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 02 Dec 1998 08:43:25 -0800
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:

> And are they planning on releasing the GHz speed existing 4000-series
> FPGA?
> No!  Instead they are going to release a large, but much slower new
> FPGA
> with this technology.  Oh well.
>  

Wise guy !
Where do you get all this wrong information from?
Why the bitching, especially when it's based on wrong assumptions?

And who says that Virtex is "much slower" or always large ?
Read the data sheet, it's available on the web.

Incidentally, I built and demonstrated a 6-digit frequency counter with
an input resolution of 420 MHz a year ago, using good old XC4002-09.  It
can be done, even with worst-case timing analysis.

All our devices are getting much faster. Don't worry, be happy.

Peter Alfke, Xilinx Applications
 

  

Article: 13429
Subject: Re: Interfaces to an Asynchronous SRAM
From: lzhang@eecg.toronto.edu (Louis Zhang)
Date: 2 Dec 98 17:15:05 GMT
Links: << >>  << T >>  << A >>
Hi Brian,

Thanks for your response.

Unfortunately, the cycle time needs to be 30MHz as well,
and I cannot use a 60MHz or 90MHz clock to produce the
30MHz clock.

Thanks.

-----------------------
Louis Zhang
lzhang@eecg.toronto.edu

On Wed, 2 Dec 1998, Brian Boorman wrote:

> You don't say what the cycle time needs to be. Assuming you can use multiple
> clock cycles to interface the ram.....
> 
>         __    __    __    __    __    __    __    __    __    __
> CLK  __|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|
> 
>     ___  ________________  ________________  ________________  _
> A/D ___{}________________{}________________{}________________{}_
> 
>      ________       ___________       __________________________
> R/Wn         \_____/           \_____/
> 
> Cycle        WRITE1            WRITE2            READ1
> 
> This example uses 3 clocks/cycle, in your case 10 Mhz (100 ns) access. If this
> is ok, this is a clean way to do it. If you don't mind using both rising and
> falling edges in your design, here is another way that allows for 15 Mhz
> access....
> 
>         __    __    __    __    __    __    __
> CLK  __|  |__|  |__|  |__|  |__|  |__|  |__|  |
> 
>     ___  __________  __________  __________  _
> A/D ___{}__________{}__________{}__________{}_
> 
>      _____       _____       _________________
> R/Wn      \_____/     \_____/
> 
> Cycle     WRITE1      WRITE2       READ1
> 
> Hope this helps.
> 
> 
> Louis Zhang wrote:... snip ...
> 
> > The problem of the asynchronous SRAM is with its write operation, where
> > the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> > address (and data) is stable, and deasserted ('1') "shortly" before the
> > address (and data) changes.  In other words, R/Wn has to be deasserted
> > ('1') when address or data change.
> >
> > The desired waveform looks like this:
> >
> > CLK= 30MHz
> >
> >           _______         _______         ________        ________
> > CLK      |       |       |       |       |        |      |        |
> >      ____|       |_______|       |_______|        |______|        |_____
> >
> > R/Wn _______           ______           _______________________________
> >             |          |     |         |
> >             |__________|     |_________|
> >
> > Addr -------------------------------------------------------------------
> >       RA0 |     WA0        |    WA1        |     RA1        |   RA2
> >           |                |               |                |
> >      -------------------------------------------------------------------
> >
> 
> 
> 
> --
> Brian C. Boorman
> Harris RF Communications
> Rochester, NY 14610
> XYZ.bboorman@harris.com
> <Remove the XYZ. for valid address>
> 
> 
> 
> 

Article: 13430
Subject: Re: Will XILINX survive?
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 2 Dec 1998 17:24:47 GMT
Links: << >>  << T >>  << A >>
> Also, it has been my case (having to complete
> designs for people who left) that how good the tools operate for you is
> directly related to how well you design the circuitry you want to fit.
Poor
> design practices makes for poor routing/timing in the final design.

Design practices are not the issue, I believe I'm quite well versed in
Xilinx design practices...;-)

The problem is a design that routed and made timing using the old tools,
now doesn't make timing using the new tools, using the same part.
 
> Last, as buggy as Epic is at times (both the Lucent and Xilinx versions),
the
> capability to go in and make tweaks during debug/integration is very
helpful.

Agreed, but NeoCAD didn't invent that.  In fact, XACT/XDE was the first
tool that was available for Xilinx FPGA design....back 10 years ago.  It
has been a standard tool since then, and is in all the tool sets.  EPIC is
a 'copy' of this tool, it is not a new idea.  The problem is, EPIC is more
difficult to use, and is missing some very useful features that the
previous Xilinx tool (XDE) had.

Austin

Article: 13431
Subject: Re: Minimum clock freq reqd
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 02 Dec 1998 09:40:57 -0800
Links: << >>  << T >>  << A >>
shailbains007@my-dejanews.com wrote:

> What factors would determine the *lowest* clock frequency that can
> drive a
> given digital circuit? (I can very well understand the existence of a
> an
> upper limit.)
>  

Circuits using static logic have no lower limit for their clock
frequency ( but even at a low frequency, the clock edges must be crisp
with short transition times, below 10 nanoseconds).
Some logic stores information not in static latches, but on capacitors,
where the data will leak away. DRAMs are the most widespread users of
this space-saving method. In that case, there is a max time between
refreshing clocks.
In non-DRAMs, such dynamic logic is rare, so most logic can be clocked
at zero frequency.
All Xilinx FPGAs and CPLDs are completely static, except for the serial
configuration input to the XC3000 devices, where CCLK must not be parked
Low.
Hope this helps.

Peter Alfke, Xilinx Applications

Article: 13432
Subject: Re: Interfaces to an Asynchronous SRAM
From: bob elkind <eteam@aracnet.com>
Date: Wed, 02 Dec 1998 11:06:53 -0800
Links: << >>  << T >>  << A >>
Louis,

1.  Data doesn't (usually) need to be stable *before* the assertion of
/WE,
    just needs to be stable (setup time) before *deassertion* of /WE.

    Many Async SRAM data sheets are misleading.

2.  Use CLK for *CE.  Assume CLK is generated off-chip.

3.  Use CLK input (rising edge) to fpga to register ADDR/DATA/*WE.

4.  ADDR/DATA/*WE will be delayed (hold time with respect to *CE) by
    CLK->Q->pin min prop delay through, which should be greater than
    the SRAM's min HOLD time req. for ADDR/DATA/*WE.

5.  ADDR/DATA/*WE will be setup *prior* to *CE (or CLK[low]) by CLK(hi)
width,
    less max prop delay of CLK->Q->pin path through FPGA.

    Pick a combination of SRAM speed and FPGA speed that suits timing
    constraints 4 and 5.  SRAM will need to be faster than 15nS access,
    but these are readily available in 1Mb ($3 US, roughly) and 4Mb
sizes.

6.  Make sure you "manage" onboard interconnect skews for
CLK/ADDR/DATA/*WE.

7.  If you want to read from SRAM, don't assert *WE.  *WE is the output
of
    a normal on-chip FF, clocked by CLK(^), with same timing as
ADDR/DATA.

          _______         _______         _______         _______
CLK      |       |       |       |       |       |       |       |
*CE  ____|       |_______|       |_______|       |_______|       |_____
                                                                           
*WE  _______                                 __________________________
            |                               |
            |_______________________________|

Addr -------------------------------------------------------------------
Data    RA0 |     WA0       |    WA1        |     RA1        |   RA2
            |               |               |                |
     -------------------------------------------------------------------

ANOTHER OPTION:

-- Use one of Brian's multi-cycle schemes, and make the data path to the
SRAM
double/triple wide to maintain bandwidth.

Hope one of these suggestions helps...

Bob Elkind, FPGA design consulting, etc. etc. etc.
eteam@aracnet.com


Louis Zhang wrote:
> 
> Hi Brian,
> 
> Thanks for your response.
> 
> Unfortunately, the cycle time needs to be 30MHz as well,
> and I cannot use a 60MHz or 90MHz clock to produce the
> 30MHz clock.
> 
> Thanks.
> 
> -----------------------
> Louis Zhang
> lzhang@eecg.toronto.edu
> 

Brian's excellent suggestions on using multi-cycle acccess were
"snipped" - be

> > > The problem of the asynchronous SRAM is with its write operation, where
> > > the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> > > address (and data) is stable, and deasserted ('1') "shortly" before the
> > > address (and data) changes.  In other words, R/Wn has to be deasserted
> > > ('1') when address or data change.
> > >
> > > The desired waveform looks like this:
> > >
> > > CLK= 30MHz
> > >
> > >           _______         _______         ________        ________
> > > CLK      |       |       |       |       |        |      |        |
> > >      ____|       |_______|       |_______|        |______|        |_____
> > >
> > > R/Wn _______           ______           _______________________________
> > >             |          |     |         |
> > >             |__________|     |_________|
> > >
> > > Addr -------------------------------------------------------------------
> > >       RA0 |     WA0        |    WA1        |     RA1        |   RA2
> > >           |                |               |                |
> > >      -------------------------------------------------------------------

Article: 13433
Subject: Xilinx Guided par
From: Steve Gross <gross@pa.msu.edu>
Date: Wed, 02 Dec 1998 16:37:22 -0500
Links: << >>  << T >>  << A >>
Conceptually, Xilinx's guided par seems like a great way to reduce par
run 
time when making a small change (read "bug fix") in a design.  But when
I tried it
recently, it actually introduced new bugs into my design.  I was using
it in the
mode where you copy the n-1 version design information into the project
clipboard in
Design Mangler and use that as guide files for version n.  After a few
iterations of
this, I started seeing various problems in testing the hardware.  Doing
a "clean slate"
par of the same EDIF cleared up the problems.  Has anyone else had
problems with
guided par?  I would really like to cut down on the par run times (2+
hours on a SPARC
for several of my 4028XL designs) when just adding an inverter or
whatnot.  And, yes,
I know that:

	(a) designs "should" be synchronous (these are)
	(b) I can add an inverter in EPIC (and remember to add it to the
schematic also)

Thanks,

-Steve Gross

Article: 13434
Subject: Re: XILINX FPGA reaches GHz speeds
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 02 Dec 1998 14:16:16 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
<snipped>
> All our devices are getting much faster. Don't worry, be happy.
> 

Assuming that the power dissipation problems can be solved, the
other major barrier to high-speed FPGA operation is I/O limitations.
Any chance of getting differential I/O with LVPECL or LVDS levels from
FPGAs this century? I could really use an FPGA or even CPLD with
LVDS I/O options right now. Low power, so much easier to terminate,
and ground bounce becomes a virtual non-issue.

 
Tom Burgess
-- 
Digital Engineer
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: 13435
Subject: Re: Interfaces to an Asynchronous SRAM
From: lzhang@eecg.toronto.edu (Louis Zhang)
Date: 2 Dec 98 22:24:55 GMT
Links: << >>  << T >>  << A >>
Hi Bob,

Thanks a lot for your help.  I was actually thinking about exactly
the same thing last night.  :-) 

However, when using the CLK for *CE, there is a little problem with the
read cycle.  The Xilinx FPGA needs to register the read data and the
register is clocked by the delayed version of "CLK" (CLK go through a
Clock Buffer).  We call this CLK_delayed.

During a read cycle, we deassert the *CE ('1') when clock goes to high,
then data starts to be tri-stated after a CE high to High Z (Tchhz)
delay.  The data goes through an input pad delay (Tipad) and setup time
(Tsetup). If the (Tipad + Tsetup + Tchhz) < Clock Skew, where the clock
skew is the from CLK to CLK_delayed, then we will have a hold time 
problem.

Xilinx has some nice feature which allows you to add some additional
delay (full delay or partial delay) at the input path.  Unfornately,
the read data also needs to be clocked by a custom ASIC which does not
have this feature.  So the clock skew, if is big (6ns?), can be less 
than (Tipad + Tsetup + Tchhz).  If this happens, then the read cycle
won't work.

Thanks for any suggestions again.

-----------------------
Louis Zhang
lzhang@eecg.toronto.edu

On Wed, 2 Dec 1998, bob elkind wrote:

> Louis,
> 
> 1.  Data doesn't (usually) need to be stable *before* the assertion of
> /WE,
>     just needs to be stable (setup time) before *deassertion* of /WE.
> 
>     Many Async SRAM data sheets are misleading.
> 
> 2.  Use CLK for *CE.  Assume CLK is generated off-chip.
> 
> 3.  Use CLK input (rising edge) to fpga to register ADDR/DATA/*WE.
> 
> 4.  ADDR/DATA/*WE will be delayed (hold time with respect to *CE) by
>     CLK->Q->pin min prop delay through, which should be greater than
>     the SRAM's min HOLD time req. for ADDR/DATA/*WE.
> 
> 5.  ADDR/DATA/*WE will be setup *prior* to *CE (or CLK[low]) by CLK(hi)
> width,
>     less max prop delay of CLK->Q->pin path through FPGA.
> 
>     Pick a combination of SRAM speed and FPGA speed that suits timing
>     constraints 4 and 5.  SRAM will need to be faster than 15nS access,
>     but these are readily available in 1Mb ($3 US, roughly) and 4Mb
> sizes.
> 
> 6.  Make sure you "manage" onboard interconnect skews for
> CLK/ADDR/DATA/*WE.
> 
> 7.  If you want to read from SRAM, don't assert *WE.  *WE is the output
> of
>     a normal on-chip FF, clocked by CLK(^), with same timing as
> ADDR/DATA.
> 
>           _______         _______         _______         _______
> CLK      |       |       |       |       |       |       |       |
> *CE  ____|       |_______|       |_______|       |_______|       |_____
>                                                                            
> *WE  _______                                 __________________________
>             |                               |
>             |_______________________________|
> 
> Addr -------------------------------------------------------------------
> Data    RA0 |     WA0       |    WA1        |     RA1        |   RA2
>             |               |               |                |
>      -------------------------------------------------------------------
> 
> ANOTHER OPTION:
> 
> -- Use one of Brian's multi-cycle schemes, and make the data path to the
> SRAM
> double/triple wide to maintain bandwidth.
> 
> Hope one of these suggestions helps...
> 
> Bob Elkind, FPGA design consulting, etc. etc. etc.
> eteam@aracnet.com
> 
> 
> Louis Zhang wrote:
> > 
> > Hi Brian,
> > 
> > Thanks for your response.
> > 
> > Unfortunately, the cycle time needs to be 30MHz as well,
> > and I cannot use a 60MHz or 90MHz clock to produce the
> > 30MHz clock.
> > 
> > Thanks.
> > 
> > -----------------------
> > Louis Zhang
> > lzhang@eecg.toronto.edu
> > 
> 
> Brian's excellent suggestions on using multi-cycle acccess were
> "snipped" - be
> 
> > > > The problem of the asynchronous SRAM is with its write operation, where
> > > > the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> > > > address (and data) is stable, and deasserted ('1') "shortly" before the
> > > > address (and data) changes.  In other words, R/Wn has to be deasserted
> > > > ('1') when address or data change.
> > > >
> > > > The desired waveform looks like this:
> > > >
> > > > CLK= 30MHz
> > > >
> > > >           _______         _______         ________        ________
> > > > CLK      |       |       |       |       |        |      |        |
> > > >      ____|       |_______|       |_______|        |______|        |_____
> > > >
> > > > R/Wn _______           ______           _______________________________
> > > >             |          |     |         |
> > > >             |__________|     |_________|
> > > >
> > > > Addr -------------------------------------------------------------------
> > > >       RA0 |     WA0        |    WA1        |     RA1        |   RA2
> > > >           |                |               |                |
> > > >      -------------------------------------------------------------------
> 
> 

Article: 13436
Subject: Re: Interfaces to an Asynchronous SRAM
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Wed, 02 Dec 1998 17:50:55 -0500
Links: << >>  << T >>  << A >>


Well, then you might have to resort to tricks. There at one time was an App Note
from Xilinx on clock doubling.  If you look in an older data book you should be able
to find it.(My interpretation is below) The caveat is that while frequency is
double, high time pulse width may not be constant as it depends on routing delays.
Anyways, use the rising edge of clk for address/data, and falling edge of 2xCLK for
R/W.....

           _____       _____       _____       _____       _____       _____
___
CLK   ____|     |_____|     |_____|     |_____|     |_____|     |_____|     |_____|

           __    __    __    __    __    __    __    __    __    __    __    __
__
2xCLK ____|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|
|

      ____  __________  __________  __________  __________  __________  __________
__
A/D
____{}__________{}__________{}__________{}__________{}__________{}__________{}__

      _______       _____       _________________
______________________________
R/W          |_____|     |_____|                 |_____|

Cycle        Write1       Write2      Read1       Write3      Read2        Read3


As for the clock doubler.....

                      ___________________________________________
                     |                                           |
                     |                   |\                      |
                     |                   | \      _________      |
                     O-------------------|  |O---| D     Q |-----O
                     |       _____       | /     |         |
                     |______|     |      |/      |         |
                            |     |              |         |
                            | XOR |----o---------|>        |
30Mhz Clock  _______________|     |    |         |         |
                            |_____|    |         |_____R___|
                                       |   Reset_______|
                                       |______________________________________>
2xCLK

Be very careful to ensure that the high pulse meets your device minimum pulse width
requirements. The sum of the Flip-Flop Clock-to-Q delay, route delay Q-to-Xor, and
prop delay through Xor, total of these three will be your 2xCLK high time.

Hope that helps :-)

Louis Zhang wrote:

> Hi Brian,
>
> Thanks for your response.
>
> Unfortunately, the cycle time needs to be 30MHz as well,
> and I cannot use a 60MHz or 90MHz clock to produce the
> 30MHz clock.
>
> Thanks.
>
> -----------------------
> Louis Zhang
> lzhang@eecg.toronto.edu
>
> > Louis Zhang wrote:... snip ...
> >
> > > The problem of the asynchronous SRAM is with its write operation, where
> > > the write enable (R/Wn) has to be asserted ('0') "shortly" after the
> > > address (and data) is stable, and deasserted ('1') "shortly" before the
> > > address (and data) changes.  In other words, R/Wn has to be deasserted
> > > ('1') when address or data change.
> > >
> > > The desired waveform looks like this:
> > >
> > > CLK= 30MHz
> > >
> > >           _______         _______         ________        ________
> > > CLK      |       |       |       |       |        |      |        |
> > >      ____|       |_______|       |_______|        |______|        |_____
> > >
> > > R/Wn _______           ______           _______________________________
> > >             |          |     |         |
> > >             |__________|     |_________|
> > >
> > > Addr -------------------------------------------------------------------
> > >       RA0 |     WA0        |    WA1        |     RA1        |   RA2
> > >           |                |               |                |
> > >      -------------------------------------------------------------------
> > >
> >
> >
> >
> > --
> > Brian C. Boorman
> > Harris RF Communications
> > Rochester, NY 14610
> > XYZ.bboorman@harris.com
> > <Remove the XYZ. for valid address>
> >
> >
> >
> >



--
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>





Article: 13437
Subject: Re: Interfaces to an Asynchronous SRAM
From: bob elkind <eteam@aracnet.com>
Date: Wed, 02 Dec 1998 15:02:00 -0800
Links: << >>  << T >>  << A >>
1. Do the
math
(arithmetic)
on the
data input
vs. CLK
input
setup/hold
  
requirements. 
With the
Xilinx
FPGA you
might be
OK.

For the
2nd "load"
on the
SRAM data
output
(the
ASIC):

2. Get the
registered
data from
the Xilinx
FPGA
rather
than
directly
   from
the SRAM
(consumes
IO
pins),  
OR

3. Add
discrete
registers
on the
board to
clock the
SRAM DOUT.
   (e.g.
'646,
'373,
'374,
etc.). 
This would
work for
Data going
   to FPGA
as well as
ASIC.

For the
diehard
engineer:

 Route the
CLK
daisy-chain
to
   
First: 
the FPGA
and ASIC
CLK inputs
for
registering
the SRAM
DOUT
   
Second:
the SRAM
*CE inputs
(add xx nS
of trace
delay to
provide
timing
margin)
   
Third: 
the FPGA
CLK input
for
registering
the
Addr/*WE/Write.Data
(add xx nS
of trace
delay to
provide
timing
margin)

Trace
delay is
appr.
1.8-2.0 nS
per foot. 
Don't know
what that
is in
meters or
furlongs.

** If this
is a
school
project**,
I really
hope we
aren't
"doing
your
homework
for you";
part of
your
training
is to
explore
all the
possibilities
and
consider
the
strengths
and
weaknesses
of
each/all.

-- Bob
Elkind,
yada yada
yada FPGA
design
consulting,
etc.
eteam@aracnet.com

Louis
Zhang
wrote:
> 
> Hi Bob,
> 
> However, when using the CLK for *CE, there is a little problem with the
> read cycle.  The Xilinx FPGA needs to register the read data and the
> register is clocked by the delayed version of "CLK" (CLK go through a
> Clock Buffer).  We call this CLK_delayed.
> 
> During a read cycle, we deassert the *CE ('1') when clock goes to high,
> then data starts to be tri-stated after a CE high to High Z (Tchhz)
> delay.  The data goes through an input pad delay (Tipad) and setup time
> (Tsetup). If the (Tipad + Tsetup + Tchhz) < Clock Skew, where the clock
> skew is the from CLK to CLK_delayed, then we will have a hold time
> problem.
> 
> Xilinx has some nice feature which allows you to add some additional
> delay (full delay or partial delay) at the input path.  Unfornately,
> the read data also needs to be clocked by a custom ASIC which does not
> have this feature.  So the clock skew, if is big (6ns?), can be less
> than (Tipad + Tsetup + Tchhz).  If this happens, then the read cycle
> won't work.
> 
> Louis Zhang
> lzhang@eecg.toronto.edu
> 
> On Wed, 2 Dec 1998, bob elkind wrote:
> 
> > Louis,
> >
> > 1.  Data doesn't (usually) need to be stable *before* the assertion of /WE,
> >     just needs to be stable (setup time) before *deassertion* of /WE.
> >
> >     Many Async SRAM data sheets are misleading.
> >
> > 2.  Use CLK for *CE.  Assume CLK is generated off-chip.
> >
> > 3.  Use CLK input (rising edge) to fpga to register ADDR/DATA/*WE.
> >
> > 4.  ADDR/DATA/*WE will be delayed (hold time with respect to *CE) by
> >     CLK->Q->pin min prop delay through, which should be greater than
> >     the SRAM's min HOLD time req. for ADDR/DATA/*WE.
> >
> > 5.  ADDR/DATA/*WE will be setup *prior* to *CE (or CLK[low]) by CLK(hi) width,
> >     less max prop delay of CLK->Q->pin path through FPGA.
> >
> >     Pick a combination of SRAM speed and FPGA speed that suits timing
> >     constraints 4 and 5.  SRAM will need to be faster than 15nS access,
> >     but these are readily available in 1Mb ($3 US, roughly) and 4Mb sizes.
> >
> > 6.  Make sure you "manage" onboard interconnect skews for CLK/ADDR/DATA/*WE.
> >
> > 7.  If you want to read from SRAM, don't assert *WE.  *WE is the output of
> >     a normal on-chip FF, clocked by CLK(^), with same timing as ADDR/DATA.
> >
> >           _______         _______         _______         _______
> > CLK      |       |       |       |       |       |       |       |
> > *CE  ____|       |_______|       |_______|       |_______|       |_____
> >
> > *WE  _______                                 __________________________
> >             |                               |
> >             |_______________________________|
> >
> > Addr -------------------------------------------------------------------
> > Data    RA0 |     WA0       |    WA1        |     RA1        |   RA2
> >             |               |               |                |
> >      -------------------------------------------------------------------

Article: 13438
Subject: Re: Interfaces to an Asynchronous SRAM (repost)
From: bob elkind <eteam@aracnet.com>
Date: Wed, 02 Dec 1998 15:52:39 -0800
Links: << >>  << T >>  << A >>
1. Do the math (arithmetic) on the data input vs. CLK input setup/hold  
requirements. With the Xilinx FPGA you might be OK.

For the 2nd "load" on the SRAM data output (the ASIC): 

2. Get the registered data from the Xilinx FPGA rather than directly
   from the SRAM (consumes IO pins),   OR

3. Add discrete registers on the board to clock the SRAM DOUT.
   (e.g. '646, '373, '374, etc.).  This would work for Data going
   to FPGA as well as ASIC.

For the diehard engineer:

 Route the CLK daisy-chain to   
   First:  the FPGA and ASIC CLK inputs for registering the SRAM DOUT
   Second: the SRAM *CE inputs (add xx nS of trace delay to provide timing margin)
   Third:  the FPGA CLK input for registering the Addr/*WE/Write.Data (add xx nS of trace delay to provide timing margin)

Trace delay is appr. 1.8-2.0 nS per foot.  Don't know what that is in meters or furlongs.

** If this is a school project**, I really hope we aren't "doing your homework for you"; part of your training is to explore all
the possibilities
and consider the strengths and weaknesses of each/all.

-- Bob Elkind,    yada yada yada FPGA design consulting, etc.
eteam@aracnet.com

Louis Zhang wrote:
> 
> Hi Bob,
> 
> Thanks a lot for your help.  I was actually thinking about exactly
> the same thing last night.  :-)
> 
> However, when using the CLK for *CE, there is a little problem with the
> read cycle.  The Xilinx FPGA needs to register the read data and the
> register is clocked by the delayed version of "CLK" (CLK go through a
> Clock Buffer).  We call this CLK_delayed.
> 
> During a read cycle, we deassert the *CE ('1') when clock goes to high,
> then data starts to be tri-stated after a CE high to High Z (Tchhz)
> delay.  The data goes through an input pad delay (Tipad) and setup time
> (Tsetup). If the (Tipad + Tsetup + Tchhz) < Clock Skew, where the clock
> skew is the from CLK to CLK_delayed, then we will have a hold time
> problem.
> 
> Xilinx has some nice feature which allows you to add some additional
> delay (full delay or partial delay) at the input path.  Unfornately,
> the read data also needs to be clocked by a custom ASIC which does not
> have this feature.  So the clock skew, if is big (6ns?), can be less
> than (Tipad + Tsetup + Tchhz).  If this happens, then the read cycle
> won't work.
> 
> Thanks for any suggestions again.
> 
> -----------------------
> Louis Zhang
> lzhang@eecg.toronto.edu
> 
> On Wed, 2 Dec 1998, bob elkind wrote:
> 
> > Louis,
> >
> > 1.  Data doesn't (usually) need to be stable *before* the assertion of /WE,
> >     just needs to be stable (setup time) before *deassertion* of /WE.
> >
> >     Many Async SRAM data sheets are misleading.
> >
> > 2.  Use CLK for *CE.  Assume CLK is generated off-chip.
> >
> > 3.  Use CLK input (rising edge) to fpga to register ADDR/DATA/*WE.
> >
> > 4.  ADDR/DATA/*WE will be delayed (hold time with respect to *CE) by
> >     CLK->Q->pin min prop delay through, which should be greater than
> >     the SRAM's min HOLD time req. for ADDR/DATA/*WE.
> >
> > 5.  ADDR/DATA/*WE will be setup *prior* to *CE (or CLK[low]) by CLK(hi) width,
> >     less max prop delay of CLK->Q->pin path through FPGA.
> >
> >     Pick a combination of SRAM speed and FPGA speed that suits timing
> >     constraints 4 and 5.  SRAM will need to be faster than 15nS access,
> >     but these are readily available in 1Mb ($3 US, roughly) and 4Mb sizes.
> >
> > 6.  Make sure you "manage" onboard interconnect skews for CLK/ADDR/DATA/*WE.
> >
> > 7.  If you want to read from SRAM, don't assert *WE.  *WE is the output of
> >     a normal on-chip FF, clocked by CLK(^), with same timing as ADDR/DATA.
> >
> >           _______         _______         _______         _______
> > CLK      |       |       |       |       |       |       |       |
> > *CE  ____|       |_______|       |_______|       |_______|       |_____
> >
> > *WE  _______                                 __________________________
> >             |                               |
> >             |_______________________________|
> >
> > Addr -------------------------------------------------------------------
> > Data    RA0 |     WA0       |    WA1        |     RA1        |   RA2
> >             |               |               |                |
> >      -------------------------------------------------------------------
> >
> > ANOTHER OPTION:
> >
> > -- Use one of Brian's multi-cycle schemes, and make the data path to the SRAM
> > double/triple wide to maintain bandwidth.
> >
> > Hope one of these suggestions helps...
> >
> > Bob Elkind, FPGA design consulting, etc. etc. etc.
> > eteam@aracnet.com

Article: 13439
Subject: Re: Interfaces to an Asynchronous SRAM
From: lzhang@eecg.toronto.edu (Louis Zhang)
Date: 3 Dec 98 00:40:51 GMT
Links: << >>  << T >>  << A >>

Thanks for Bob and Brian for your excellent suggestions.

We are sort of beyond our duty doing a test board for the 
300,000-gate ASIC that two of us designed for a Grad course 
ealier this year.  So now this is really the homework that we 
assigned for ourselves that bears NO grade/mark.  :-)

The real product that this ASIC will go into later on has a 
higher frequency clock that we can use for the programmable 
clock to mask the R/Wn that I mentioned. However, the IC tester 
that this simple board will be tested with does not have this 
luxury. 

Again, thanks for your kind helps.

-----------------------
Louis Zhang
lzhang@eecg.toronto.edu

Article: 13440
Subject: Re: Interfaces to an Asynchronous SRAM
From: murray@pa.dec.com (Hal Murray)
Date: 3 Dec 1998 01:13:16 GMT
Links: << >>  << T >>  << A >>
> We are try to build an Xilinx FPGA to read and write to an asynchronous 
> SRAM (due to the design requirement, we can only use asynchronous SRAM, 
> not synchronous SRAM nor ZBT SRAM)
> 
> The problem of the asynchronous SRAM is with its write operation, where
> the write enable (R/Wn) has to be asserted ('0') "shortly" after the 
> address (and data) is stable, and deasserted ('1') "shortly" before the 
> address (and data) changes.  In other words, R/Wn has to be deasserted
> ('1') when address or data change.

I've never found a really clean and simple way to do this.  Here is the
way I think about that problem area.

You have to generate a write pulse from the clock signal and various
gates.  The leading edge has to be after the new address gets there and
the trailing edge has to go away before the address changes.

There are two ways to make that pulse - from the front half of the clock
signal or the back half.

If you are working with the front half of the clock, then you have to
make sure there is enough delay in the write pulse to meet the address
setup time but not so much delay that the trailing edge overlaps into
the next cycle.  This gets into minimum delays so expect to do some
handwaving.  If you put in too much delay the max times will bite you
on the trailing edge.  This works OK if you have lots of time.


If you want to use the back half of the clock pulse, then you need an
early (gate delay or two) verison of the clock to work with.  A real
delay line might work to push the front half late into the clock cycle
but trying to do that with gates doesn't work for me.  One of the PLL
clock chips would probably work too.

My straw man is to use a PAL for the master clock generator on the
board.  I call the outputs of the PAL preClock so I can call the signal
inside the FPGA (after the clock buffer) clock.  That seems to be the
easiest way for me to think about things.  I compute all times relative
to "clock" and that seems to result in the least arithmetic.

Suppose you use one of the PAL terms as an AND gate with the enable
signal coming from a FF in the FPGA to make your write pulse.  The
write pulse will terminate when the clock goes into the FPGA so you
have all of the FPGA delay less the PAL skew for hold time.  That's
clearly positive.  You have to get the write enable to the PAL very
early in the cycle - you start with a half cycle but you have to
subtract off the PAL delay and the FPGA clock-out delay.

You may be able to push the PAL into the FPGA.  I describe it
externally since I think that makes things easier to understand
or describe.  Remember that you have to keep the skew low.  I do
the wiring and placement by hand, making sure that some "smart"
software doesn't through away the dummy CLB that I need to make
the timing on the preClock paths match the timing on the write
pulse.


-- 
These are my opinions, not necessarily my employers.

Article: 13441
Subject: Re: Interfaces to an Asynchronous SRAM
From: bob elkind <eteam@aracnet.com>
Date: Wed, 02 Dec 1998 17:14:03 -0800
Links: << >>  << T >>  << A >>
Good luck on your project.

As you can tell, there is usually more than one way to solve a design problem such as this.

You have an advantage in that you are (presumably) building only one device, and you can hand-tweak
the FPGA on-chip routing/timing, and select fast or slow parts as needed.  The wind is at your
backs, so to speak.  Your odds of success are good, especially with the care for details that
you have obviously given.

-- Bob Elkind

Louis Zhang wrote:
> 
> Thanks for Bob and Brian for your excellent suggestions.
> 
> We are sort of beyond our duty doing a test board for the
> 300,000-gate ASIC that two of us designed for a Grad course
> ealier this year.  So now this is really the homework that we
> assigned for ourselves that bears NO grade/mark.  :-)
> 
> The real product that this ASIC will go into later on has a
> higher frequency clock that we can use for the programmable
> clock to mask the R/Wn that I mentioned. However, the IC tester
> that this simple board will be tested with does not have this
> luxury.
> 
> Again, thanks for your kind helps.
> 
> -----------------------
> Louis Zhang
> lzhang@eecg.toronto.edu

Article: 13442
Subject: Re: XILINX FPGA reaches GHz speeds
From: jhallen@world.std.com (Joseph H Allen)
Date: Thu, 3 Dec 1998 02:01:55 GMT
Links: << >>  << T >>  << A >>
In article <3665BC30.BCBC08B7@hia.nrc.ca>,
Tom Burgess  <tom.burgess@hia.nrc.ca> wrote:
>Peter Alfke wrote:

><snipped>
>> All our devices are getting much faster. Don't worry, be happy.

>Assuming that the power dissipation problems can be solved, the
>other major barrier to high-speed FPGA operation is I/O limitations.
>Any chance of getting differential I/O with LVPECL or LVDS levels from
>FPGAs this century? I could really use an FPGA or even CPLD with
>LVDS I/O options right now. Low power, so much easier to terminate,
>and ground bounce becomes a virtual non-issue.

I would love to see fast PECL I/O on an SRAM-based FPGA.  I recently did a
600MHz ECL/FPGA design, and would have loved to have been able to rid of all
those 'ELT22s and 'ELT21s.

What is LVPECL and LVDS?  I've heard of LVTTL, but not any of these others. 
Are they ASIC I/O options or something?  I think the I/O really needs to be
ECL or PECL since there are well established ECL logic families, ECL
oscillators/PLLs and ECL A/D and D/A converters.  There must be some way to
make ECL-compatiable drivers and receivers with MOSFETs on CMOS FPGAs.  They
did it with GaS.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 13443
Subject: Xilinx FPGA configuration problems... Help!
From: Olivier Hebert <hebert01@gel.ulaval.ca>
Date: Thu, 03 Dec 1998 02:37:50 GMT
Links: << >>  << T >>  << A >>
Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm
having problems configuring the device. I'm using a master serial
configuration (I'm trying to use the XChecker cable now, and a serial
PROM later).

When I first power up the board, if I probe the CCLK pin with a scope, I
get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak.
When I try to configure the device using an XChecker cable, the
frequency of the CCLK signal goes up to something like 7 MHz, even
though I'm using slow configuration. When I hit the PROG button on the
board, the frequency goes back to it's normal rate (900 kHz). Of course,
the hardware debugger says something is wrong when I try to program the
device!

Is there something I'm doing wrong? Could the device be bad? I really
need help on this one!

Thanks,

OH

(Forward reply via email too please)

Article: 13444
Subject: Xilinx FPGA configuration problems... Help!
From: Olivier Hebert <hebert01@gel.ulaval.ca>
Date: Thu, 03 Dec 1998 02:38:19 GMT
Links: << >>  << T >>  << A >>
Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm
having problems configuring the device. I'm using a master serial
configuration (I'm trying to use the XChecker cable now, and a serial
PROM later).

When I first power up the board, if I probe the CCLK pin with a scope, I
get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak.
When I try to configure the device using an XChecker cable, the
frequency of the CCLK signal goes up to something like 7 MHz, even
though I'm using slow configuration. When I hit the PROG button on the
board, the frequency goes back to it's normal rate (900 kHz). Of course,
the hardware debugger says something is wrong when I try to program the
device!

Is there something I'm doing wrong? Could the device be bad? I really
need help on this one!

Thanks,

OH

(Forward reply via email too please)

Article: 13445
Subject: Xilinx FPGA configuration problems... Help!
From: Olivier Hebert <hebert01@gel.ulaval.ca>
Date: Thu, 03 Dec 1998 02:38:34 GMT
Links: << >>  << T >>  << A >>
Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm
having problems configuring the device. I'm using a master serial
configuration (I'm trying to use the XChecker cable now, and a serial
PROM later).

When I first power up the board, if I probe the CCLK pin with a scope, I
get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak.
When I try to configure the device using an XChecker cable, the
frequency of the CCLK signal goes up to something like 7 MHz, even
though I'm using slow configuration. When I hit the PROG button on the
board, the frequency goes back to it's normal rate (900 kHz). Of course,
the hardware debugger says something is wrong when I try to program the
device!

Is there something I'm doing wrong? Could the device be bad? I really
need help on this one!

Thanks,

OH

(Forward reply via email too please)

Article: 13446
Subject: Re: Xilinx FPGA configuration problems... Help!
From: fliptron@netcom.com (Philip Freidin)
Date: Thu, 3 Dec 1998 09:53:19 GMT
Links: << >>  << T >>  << A >>
For use with Xchecker, you must set the FPGA to Slave serial. What you 
are seeing is the contention of two drivers both trying to drive the CCLK 
pin.


In article <3665FA54.F6F59967@gel.ulaval.ca> Olivier Hebert <hebert01@gel.ulaval.ca> writes:
>Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm
>having problems configuring the device. I'm using a master serial
>configuration (I'm trying to use the XChecker cable now, and a serial
>PROM later).

You will need Master serial with the PROM, Slave serial for xchecker. The 
codes are 111 and 000, so you can tie the 3 mode pins together, and 
select the two modes with one jumper.

>
>When I first power up the board, if I probe the CCLK pin with a scope, I
>get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak.

This is the FPGA driving the CCLK pin 900KHz, and the xchecker is driving 
a continuous low (or high) and is in contention.

>When I try to configure the device using an XChecker cable, the
>frequency of the CCLK signal goes up to something like 7 MHz, even
>though I'm using slow configuration.

This is Xchecker driving the CCLK, but it is in contention with the FPGA 
which is still driving the pin (with 900KHz). The configuration clock 
rate only affects Serial Master, and since the XChecker is designed to 
run with the FPGA in serial slave, it can use any rate it likes, upto 
about 10MHz.

> When I hit the PROG button on the
>board, the frequency goes back to it's normal rate (900 kHz). Of course,
>the hardware debugger says something is wrong when I try to program the
>device!

Xchecker has gone IDLE, and the chip is still trying to send CCLKs to a 
prom that isn't there.

>Is there something I'm doing wrong? Could the device be bad? I really 
>need help on this one!
>Thanks,

Your Welcome.

Philip Freidin



Article: 13447
Subject: Re: Xilinx FPGA configuration problems... Help!
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 03 Dec 1998 09:20:56 -0500
Links: << >>  << T >>  << A >>
You need to use master serial for prom, slave serial for the xchecker.  One
connects all the mode bits to '1' the other is all '0'.  CCLK is sourced by
the FPGA for master serial and by the xchecker for slave serial.   You need
to disconnect the xchecker when programming from a PROM to avoid
contention.  The configuration speed only effects the master serial's CCLK.

Olivier Hebert wrote:

> Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm
> having problems configuring the device. I'm using a master serial
> configuration (I'm trying to use the XChecker cable now, and a serial
> PROM later).
>
> When I first power up the board, if I probe the CCLK pin with a scope, I
> get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak.
> When I try to configure the device using an XChecker cable, the
> frequency of the CCLK signal goes up to something like 7 MHz, even
> though I'm using slow configuration. When I hit the PROG button on the
> board, the frequency goes back to it's normal rate (900 kHz). Of course,
> the hardware debugger says something is wrong when I try to program the
> device!
>
> Is there something I'm doing wrong? Could the device be bad? I really
> need help on this one!
>
> Thanks,
>
> OH
>
> (Forward reply via email too please)



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 13448
Subject: Re: Minimum clock freq reqd
From: milostnik@my-dejanews.com
Date: Thu, 03 Dec 1998 14:32:08 GMT
Links: << >>  << T >>  << A >>
In article <36657B63.280B640F@xilinx.com>,
  peter.alfke@xilinx.com wrote:
> shailbains007@my-dejanews.com wrote:
> > What factors would determine the *lowest* clock frequency that can
> > drive a given digital circuit? [..]
>
> All Xilinx FPGAs and CPLDs are completely static, except for the serial
> configuration input to the XC3000 devices, where CCLK must not be parked
> Low.

I seem to recall that the 4K series has a miminum frequency of
operation, if you use any embebbed kind of RAM.

> Hope this helps.

Bye

> Peter Alfke, Xilinx Applications

Matija

In chaos all things are possible.
Matija Milostnik, RDHW, IskraTEL, Ljubljanska 24a, SI-4000 Kranj, Slovenia
Tel: +386 64 27 2125, Fax: +386 64 221 552, Email: milostnik@iskratel.si
www.IskraTEL.si: Building the world of telecommunications


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Article: 13449
Subject: Re: Minimum clock freq reqd
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 03 Dec 1998 09:33:02 -0500
Links: << >>  << T >>  << A >>
On Xilinx 4K there is also the restriction on the high time for the CLB RAM
write clock (max 1ms).  Depending on your design, this may put a lower limit
on the clock frequency.  The restriction is due to excessive power
dissipation while the clock is high.

Peter Alfke wrote:

> shailbains007@my-dejanews.com wrote:
>
> > What factors would determine the *lowest* clock frequency that can
> > drive a
> > given digital circuit? (I can very well understand the existence of a
> > an
> > upper limit.)
> >
>
> Circuits using static logic have no lower limit for their clock
> frequency ( but even at a low frequency, the clock edges must be crisp
> with short transition times, below 10 nanoseconds).
> Some logic stores information not in static latches, but on capacitors,
> where the data will leak away. DRAMs are the most widespread users of
> this space-saving method. In that case, there is a max time between
> refreshing clocks.
> In non-DRAMs, such dynamic logic is rare, so most logic can be clocked
> at zero frequency.
> All Xilinx FPGAs and CPLDs are completely static, except for the serial
> configuration input to the XC3000 devices, where CCLK must not be parked
> Low.
> Hope this helps.
>
> Peter Alfke, Xilinx Applications



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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