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
2017JanFebMarApr2017

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 34225

Article: 34225
Subject: Re: Building a clock out of a PLD
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 16 Aug 2001 20:33:54 GMT
Links: << >>  << T >>  << A >>
Jim Granville wrote:
>  Because C555's are 'everywhere', they are a better education/prototype
> choice than TinyLogic, but I have seen designers swear they will never
> ship anything with a 555 in it :-)

Jim,

The main reason for not shipping something with a 555 in it is because
you've got to trim each and every one.  And once you trim it, how do you
know that it stays trimmed in the field?

--andy

Article: 34226
Subject: Re: Internal clock skew when using DLL
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Thu, 16 Aug 2001 21:47:42 +0100
Links: << >>  << T >>  << A >>
> In article <3B7AAEDB.47875520@xilinx.com>, Peter Alfke says...
> >
> >Since your two clock frequencies are fundamentally phase-coherent, albeit
> >perhaps with a certain unpredictable tolerance, you can cross the
clock-domain
> >boundary simply by using the opposite edge of the higher frequency clock.
This
> >does cut into your timing budget, but is safe otherwise.
> >

Is this caution needed if the HF clock is very lightly loaded
compared with the slow clock?





Article: 34227
Subject: Re: Virtex-II and 5V devices
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 16 Aug 2001 13:52:53 -0700
Links: << >>  << T >>  << A >>
just a different answer record

austin

Marc Battyani wrote:

> "Austin Lesea" <austin.lesea@xilinx.com> wrote
> > Marc,
> >
> > There is an answer record for this that suggests a 120 ohm reisistor to
> keep
> > the current into the io pin at less than 10 ms.
> >
> > I suggest you simulate the pair of chips in IBIS, no resistor at all could
> be
> > the result if the current is already less than 10 mA.
> >
> > Many 5V parts use a stacked nmos output structure for TTL compatibility,
> and
> > can not source much current at all.  If the output is full cmos, then a
> > resistor will be required.  Its value is related to the maximum source
> > current of the output at 3.3 V.  This is in the IBIS model as the IV
> curve,
> > and can be directly viewed for the strong/fast/cold operating
> > voltage/process/temperature corner, or used in the simulation
> automatically.
>
> Thanks, a resistor is fine for me. But why do you state in vtt002.pdf that :
> "Note: This does not apply to the Virtex-II family of devices, which are 3.3
> V compliant only."
>
> Is there another app note for the Virtex-II ?
>
> Marc


Article: 34228
Subject: Re: Virtex-II and 5V devices
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Thu, 16 Aug 2001 23:04:09 +0200
Links: << >>  << T >>  << A >>

"Andy Peters <andy [@] exponentmedia com >" <".> wrote

> There are a bunch of parts one can use to bridge the 5V <--> 3.3V gap.
> Basically, they're the usual sort of buffer types: '245, '541, '573,
> '573, '823.  They're in various logic families: LPT, FCT, etc.  See the
> Pericom or IDT web sites for examples.  Look for devices that have 3.3V
> power rails and are 5V tolerant.

Yes, but I have not found small devices. Well in fact there are small
devices (TVSOP48 for a X16 buffer) but they are still bigger than the device
I want to connect to the Virtex-II. And I don't have enough room on the
board to put them.
So I think I will stay with the resistor approach. I've found very small
resistor networks (4 in a 0804 package).

Thanks.

 Marc



Article: 34229
Subject: Re: Virtex-II and 5V devices
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 16 Aug 2001 22:26:40 +0100
Links: << >>  << T >>  << A >>


"Andy Peters

> Marc,
>
> There are a bunch of parts one can use to bridge the 5V <--> 3.3V gap.
> Basically, they're the usual sort of buffer types: '245, '541, '573,
> '573, '823.  They're in various logic families: LPT, FCT, etc.  See the
> Pericom or IDT web sites for examples.  Look for devices that have 3.3V
> power rails and are 5V tolerant.
>
> -andy
>

or, if you are not worried about wanting active drive, you could the
QuickSwitch style devices [originally from Quality semiconductor, now owned by
IDT] which are basically a bunch of pass transistors. Their impedance is near 0
until the driving side gets to within 0.7V of VCC and from there it rises
rapidly. Our practice is to use '245 pin compatible nominal 5V QS3245 with its
VCC taken down to 3V9 via a zener (they still work with VCC = 3V3). Pericom/TI
do an equivalent part.

Be careful with the 3V ``QS'' parts though since they come in 2 flavours -
clamping & full-swing.



Article: 34230
Subject: Re: fpga with the smallest i/o setup and hold requirement
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Thu, 16 Aug 2001 22:28:35 +0100
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3B7BDCF2.91B16A95@xilinx.com...
> Dave,
>
> There is a whole range of designs/cores in process.
>
> See the TNF announcement:
>
>  http://www.xilinx.com/terabit/index.htm
>
> Every single interface to all of those company's logos (parts) are DDR.
>
> Austin

Pity the TNF isn't playing in Europe/Asia/Australasia/Antarctica...



Article: 34231
Subject: Re: Internal clock skew when using DLL
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 16 Aug 2001 15:31:45 -0700
Links: << >>  << T >>  << A >>
It depends on the direction of data flow.

Let's look at this in more general terms.
If you have two phase-coherent clocks - whether one is a frequency multiple or
not is really irrelevant - then you have to be careful when you transfer data
across the clock boundary.
If the data transmitting register is clocked a little later than the receiving
register, that is safe and you can most likely afford the slight loss in timing
margin.
If the data transmitting register is clocked a little early, you are rolling
dice with the devil, because you may or may not end up with a race condition,
where the receiver clocks data in on "the same" edge as the transmitter sent it.

It's the old story: Clock skew against the direction of data flow is safe, clock
skew in the direction of data flow is potentially dangerous ( but of course not
if it is only 200 ps ).
BTW, that's one of the questions I have asked every applicant for the last 15
years.
Some had it, some didn't...It doesn't require experience, just a sharp mind.

Peter Alfke, Xilinx Applications
=====================================
Tim wrote

> Is this caution needed if the HF clock is very lightly loaded
> compared with the slow clock?


Article: 34232
Subject: Foundation Series 3.1i ---> Foundation Series ISE 3.3i
From: vrezayev@hotmail.com (Vitali)
Date: 16 Aug 2001 16:16:16 -0700
Links: << >>  << T >>  << A >>
Hi All,

does anyone know how to convert my old Foundation Series 3.1i  .sch files
into Foundation Series ISE 3.3i .sch ? It is weird but ISE couldn't recognize
them.

Vitaliy.

Article: 34233
Subject: Re: Help with ACEX1K100 device
From: "Leon" <ldeboer@attglobal.net>
Date: Fri, 17 Aug 2001 08:10:47 +0800
Links: << >>  << T >>  << A >>
I am assuming you are using baseline for the device.
There selection as reserved pins or not is controlled through
assign -> select device -> device options -> Dual purpose configuration
pins.

Regards Leon


"Andrew Gray" <s9813479@student.up.ac.za> wrote in message
news:997947985.88785@nntp.up.ac.za...
> Hi
>
> Can anyone tell me what the following pins are used for when they are not
> used as user IO pins:
>
> nCEO
> CS
> nCS
> nRS
> nWS
> DEV_OE
> DEV_nCLR
> INIT_DONE
> RDY_nBSY
>
> Thank You
>
> Andrew Gray
>
>
>



Article: 34234
Subject: Re: Replication of FFs in Xilinx XC4000
From: Phil Hays <spampostmaster@home.com>
Date: Fri, 17 Aug 2001 00:46:15 GMT
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> Phil Hays wrote:
> 
> <snip of perfectly reasonable paranoia, possibly not enough even>

Oh my.  What did I miss?  Now I'm really paranoid!  ;-)


-- 
Phil Hays

Article: 34235
Subject: does anyone have a datasheet for a 18P8 PAL
From: jonwil@tpgi.com.au (Jonathan Wilson)
Date: 16 Aug 2001 17:54:15 -0700
Links: << >>  << T >>  << A >>
I am trying to get a datasheet on a 18P8 PAL.
If anyone can help that would be good.
None of the manufacturers sites I tried had one.

Article: 34236
Subject: Re: Internal clock skew when using DLL
From: qlyus@yahoo.com (qlyus)
Date: 16 Aug 2001 19:25:21 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> wrote in message news:<3B7C49D2.73953E9B@xilinx.com>...
> It depends on the direction of data flow.
> 
> It's the old story: Clock skew against the direction of data flow is safe, clock
> skew in the direction of data flow is potentially dangerous ( but of course not
> if it is only 200 ps ).
> BTW, that's one of the questions I have asked every applicant for the last 15
> years.
> Some had it, some didn't...It doesn't require experience, just a sharp mind.
> 

Really?  I do see it requires experience.   And, it is quite
foundamental and straightforward if one understands what
Setup/Hold/Skew really mean.

Article: 34237
Subject: Re: I need help disassembling a JEDEC .jed file from a PLHS18P8A
From: "Peter Ormsby" <faepetedeletethis@mediaone.net>
Date: Fri, 17 Aug 2001 03:17:58 GMT
Links: << >>  << T >>  << A >>
You might give this utility from the Altera FTP site:

ftp://ftp.altera.com/pub/utils/eau018.exe

It converts the jedec file into AHDL.  Even if you're not using AHDL, you
should be able to read the equations and translate them to whatever format
you need.

-Pete-

Jonathan Wilson <jonwil@tpgi.com.au> wrote in message
news:aa5d502.0108150556.2ceb06ba@posting.google.com...
> I have a JEDEC file that identifies itself as a Signetics(Philips)
> PLHS18P8A and I need to know how I would convert that file back into
> logic equasions.
> It says it was generated by BP-1200/84/SM48D if that means anything to
> anyone...
> If there is any way to get the logic equasions out of this file please
> let me know.
> I dont have access to the origonal PAL chip from which the .jed file
> came.




Article: 34238
Subject: Re: PCI Postcode Display
From: "Austin Franklin" <austin@darkroom99.com>
Date: Thu, 16 Aug 2001 23:28:37 -0400
Links: << >>  << T >>  << A >>
> Is it required to implement Configuration? I guess the only problem
> without configurarion is that the system won't be able to tell if
> there is a PCI device on the bus.

No, it is not a requirement to implement configuration, if you are only
responding to a specific hard coded address as far as I am concerned.  You
aren't operating specifically as a PCI device in your description (POST Code
Display), so you really need nothing PCI configuration offers.  You are
doing nothing but "sniffing" the bus.  Now, the only issue that could come
up is if some bridge chip decides to only allow addresses it knows are for
that particular PCI segment through...

> Now,I am converting a lagacy ISA I/O card to PCI card (no need for
> plug-n-play). But It uses Interrupt. Do I have to implement
> Configurarion and let the system to assign a ramdon interupt or I can
> assign it myself? It would be great if I can fix #INTA to a specific
> IRQ. Because I would like to keep the exsiting software driver
> untouched and let it handle the interrupt. Is there a way of doing so.

It is BIOS dependant.  Some BIOSs allow you to specify what interrupt goes
to what PCI slot...but you can not count on that unless you have control of
the motherboard.




Article: 34239
Subject: hardware damage to a Virtex or Spartan-II?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 16 Aug 2001 21:53:17 -0700
Links: << >>  << T >>  << A >>
On the MPGA page it is stated:

    Please be warned that YOU CAN BLOW UP YOUR EXPENSIVE HARDWARE if you
    aren't careful with the MPGA as it is now. It's all too easy to
    download a design with (unintended) combinatorial loops in it, there
    is no DRC, no warning.

        http://ce.et.tudelft.nl/~reinoud/mpga/README.html

Can a combinatorial loop cause hardware damage to a Virtex or Spartan-II?
I thought the only internal condition that was potentially damaging was
an internal driver conflict.  I thought logic like:


           --------------+-----------
          |              |
          |              |
          |     |\       |
           -----| >O-----
                |/

would probably not work too well, but can it actually cause damage?

Eric

Article: 34240
Subject: Re: Help with ACEX1K100 device
From: "Andrew Gray" <s9813479@student.up.ac.za>
Date: Fri, 17 Aug 2001 08:20:59 +0200
Links: << >>  << T >>  << A >>
Thank You

That application note helped allot.

Andrew


"Gerald B" <mdesigns@ipa.net> wrote in message
news:QDQe7.1678$Ya7.367655@nntp1.onemain.com...
> I recently worked on a Acex 1K30 design.  I found Altera's app. note AN116
> "Configuring APEX 20K, FLEX 10K, & FLEX 6000 Devices" to be very helpful.
I
> have not looked at AN116 for the last few months, but the version I last
> down loaded had not been updated for the ACEX family yet.  This app. note
is
> still helpful since ACEX is basically the same as the FLEX 10K parts.
Table
> 24 in the AN116 indicates whether or not the pins are available in User
> Mode.  http://www.altera.com/literature/an/an116.pdf
>
> Hope this helps.  Gerald
>
> "Andrew Gray" <s9813479@student.up.ac.za> wrote in message
> news:997947985.88785@nntp.up.ac.za...
> > Hi
> >
> > Can anyone tell me what the following pins are used for when they are
not
> > used as user IO pins:
> >
> > nCEO
> > CS
> > nCS
> > nRS
> > nWS
> > DEV_OE
> > DEV_nCLR
> > INIT_DONE
> > RDY_nBSY
> >
> > Thank You
> >
> > Andrew Gray
> >
> >
> >
>
>



Article: 34241
Subject: Re: Virtex-II and 5V devices
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Fri, 17 Aug 2001 09:04:59 +0200
Links: << >>  << T >>  << A >>

"Rick Filipkiewicz" <rick@algor.co.uk> wrote

> > There are a bunch of parts one can use to bridge the 5V <--> 3.3V gap.
> > Basically, they're the usual sort of buffer types: '245, '541, '573,
> > '573, '823.  They're in various logic families: LPT, FCT, etc.  See the
> > Pericom or IDT web sites for examples.  Look for devices that have 3.3V
> > power rails and are 5V tolerant.
> >
> or, if you are not worried about wanting active drive, you could the
> QuickSwitch style devices [originally from Quality semiconductor, now
owned by
> IDT] which are basically a bunch of pass transistors. Their impedance is
near 0
> until the driving side gets to within 0.7V of VCC and from there it rises
> rapidly. Our practice is to use '245 pin compatible nominal 5V QS3245 with
its
> VCC taken down to 3V9 via a zener (they still work with VCC = 3V3).
Pericom/TI
> do an equivalent part.

> Be careful with the 3V ``QS'' parts though since they come in 2 flavours -
> clamping & full-swing.

Very interesting. I will use this for fast signals.

Thanks

Marc



Article: 34242
Subject: Re: star-wars ascii-animation:)
From: "David L. Jones" <dljones@ozemail.com.au>
Date: Fri, 17 Aug 2001 18:00:20 +1000
Links: << >>  << T >>  << A >>
Russell Shaw <rjshaw@iprimus.com.au> wrote in message
news:3B7B401E.E90A0168@iprimus.com.au...
> http://www.asciimation.co.nz

Someone has way too much free time on their hands!

BTW, the relevance to electronics is? (oh that's right - it's ASCII)

Dave :)



Article: 34243
Subject: Re: hardware damage to a Virtex or Spartan-II?
From: Reinoud <dus@wanabe.nl>
Date: Fri, 17 Aug 2001 11:43:17 +0200
Links: << >>  << T >>  << A >>
Eric Smith wrote:
> 
> On the MPGA page it is stated:
> 
>     Please be warned that YOU CAN BLOW UP YOUR EXPENSIVE HARDWARE if you
>     aren't careful with the MPGA as it is now. It's all too easy to
>     download a design with (unintended) combinatorial loops in it, there
>     is no DRC, no warning.
> 
>         http://ce.et.tudelft.nl/~reinoud/mpga/README.html
> 
> Can a combinatorial loop cause hardware damage to a Virtex or Spartan-II?
> I thought the only internal condition that was potentially damaging was
> an internal driver conflict.  I thought logic like:
> 
>            --------------+-----------
>           |              |
>           |              |
>           |     |\       |
>            -----| >O-----
>                 |/
> 
> would probably not work too well, but can it actually cause damage?
> 
> Eric

Eric,

The same paragraph on that page explains:

    Resulting oscillations may cause widespread high frequency
    switching and this may draw more power than your hardware was
    designed to handle.

A circuit like you have drawn above will oscillate at a fairly high
frequency.  If there are many loops, or if a lot of logic is driven
at high frequency by such loops, this may draw a lot of power.  Many
boards out there with large FPGAs were not designed to handle such
power.  This is not a flaw of Virtex (actually, Xilinx documents
power issues quite clearly), it's more a board/system design issue
with current generation (high power density) chips.

- Reinoud

Article: 34244
Subject: Re: Internal clock skew when using DLL
From: What Order <nospam@newsranger.com>
Date: Fri, 17 Aug 2001 10:11:12 GMT
Links: << >>  << T >>  << A >>
Peter and Ray,

what order of the skew is, if it is still~200 ps i don't see where the problem
can happend sinc FlipFlop Clk-Out~1ns

any comments

In article <3B7C49D2.73953E9B@xilinx.com>, Peter Alfke says...
>
>It depends on the direction of data flow.
>
>Let's look at this in more general terms.
>If you have two phase-coherent clocks - whether one is a frequency multiple or
>not is really irrelevant - then you have to be careful when you transfer data
>across the clock boundary.
>If the data transmitting register is clocked a little later than the receiving
>register, that is safe and you can most likely afford the slight loss in timing
>margin.
>If the data transmitting register is clocked a little early, you are rolling
>dice with the devil, because you may or may not end up with a race condition,
>where the receiver clocks data in on "the same" edge as the transmitter sent it.
>
>It's the old story: Clock skew against the direction of data flow is safe, clock
>skew in the direction of data flow is potentially dangerous ( but of course not
>if it is only 200 ps ).
>BTW, that's one of the questions I have asked every applicant for the last 15
>years.
>Some had it, some didn't...It doesn't require experience, just a sharp mind.
>
>Peter Alfke, Xilinx Applications
>=====================================
>Tim wrote
>
>> Is this caution needed if the HF clock is very lightly loaded
>> compared with the slow clock?
>



Article: 34245
Subject: Re: Virtex Pro Info
From: "Dave Feustel" <dfeustel1@home.com>
Date: Fri, 17 Aug 2001 11:22:01 GMT
Links: << >>  << T >>  << A >>
Good Stuff! Thanks for the pointer.

Dave Feustel

"Philip Freidin" <philip@fliptronics.com> wrote in message
news:o89ontca74uce1g200lv9v6esnk208u1hq@4ax.com...
> Go to http://www.xilinx.com/events/seminars/xtremedsp.htm
>
> Follow the link to "Go to Video On Demand Page*"
>
>    (you will need to be registered, it's free)
>
> Then download the PDF for section 7. The last bunch of pages
> covers V-II-P
>
> Philip
>
> On Thu, 16 Aug 2001 14:16:27 GMT, "Dave Feustel" <dfeustel1@home.com> wrote:
> >Is there any publically available info on
> >Xilinx's upcoming Virtex Pro series of FPGAs?
> >
> >Thanks.
> >
>
> Philip Freidin
> Fliptronics



Article: 34246
Subject: Re: WinMe installation
From: =?iso-8859-1?Q?Pawe=B3?= J. Rajda <pjrajda@uci.agh.edu.pl>
Date: Fri, 17 Aug 2001 13:45:54 +0200
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------B062B15214CD7E1D53EA13FD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

jimmy wrote:

> Dear all,
>     I want to install the xilinx 3.3i ISE under winme platform. After the
> successful installation and re-boot the computer, I can't find the project
> navigator in the programs file on the start up menu. Also I cannot find this
> file on the xilinx directory. Also I have added the path on the autoexec.bat
> file , it still not work too.
> So can you give some suggestions to me to overcome this problem.
> Thank you very much

I had the same problem on WinNT. Our local FAE told me to change
International Settings to English (US) prior to installation. After it you
can change it back. Looks stange, but... works!!!

--
Regards,
Pawel J. Rajda


--------------B062B15214CD7E1D53EA13FD
Content-Type: text/x-vcard; charset=us-ascii;
 name="pjrajda.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Paweł J. Rajda
Content-Disposition: attachment;
 filename="pjrajda.vcf"

begin:vcard 
n:Rajda;Pawel J.
tel;fax:+48 12 633 2398
tel;home:+48 12 634 0653
tel;work:+48 12 617 3980
x-mozilla-html:FALSE
org:AGH Technical University
version:2.1
email;internet:pjrajda@uci.agh.edu.pl
title:PhD EE
adr;quoted-printable:;;Dept. of Electronics=0D=0AAl. Mickiewicza 30;Krakow;;30-059;POLAND
x-mozilla-cpt:;26368
fn:Rajda, Pawel J.
end:vcard

--------------B062B15214CD7E1D53EA13FD--


Article: 34247
Subject: Atmel CPLD - JEDEC to ABEL
From: Pedley@talk21.com (M Pedley)
Date: 17 Aug 2001 05:05:32 -0700
Links: << >>  << T >>  << A >>
Is it possible to convert a JEDEC file for an Atmel 15xx CPLD back to
ABEL or any other CPLD language?

Matt

Article: 34248
Subject: Re: Internal clock skew when using DLL
From: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
Date: Fri, 17 Aug 2001 15:02:16 +0200
Links: << >>  << T >>  << A >>
Hi,

it seems that I have a different problem. That's my situation:

I am using a SpartanII device "between" a PCI bridge and some ZBT RAMs.
The bridge interface uses a 33MHz
clock. The Xtal is connected directly to the bridge and FPGA. Inside the
FPGA I have two clock domains: 33MHz and 66MHz doubled by a DLL.

Below you can see the DLL part of my design. In most cases it is
working, but some memory locations generate read/write errors when I try
to access the RAMs through the pci bridge. Since only some (without a
sheme) memory location make problems, I think that this might be a
timing problem, that could have something to do with my DLL stuff.

These are the signals used:

LCLK		: 33 MHz clock from xtal
MEM_CLK		: 66MHz clock output to the RAMs
MEM_CLK5	: 66MHz clock feedback (externally connected to MEM_CLK)
clklocal	: clocks internal 33MHz domain (handshaking with the pci bridge
is done syncronous to this clock)
clkdouble	: clocks internal 66MHz domain (all signals to the RAMs are
syncronized by this clock)

I_dll_int : CLKDLL
	port map(
		clkin => LCLK,
   	        clkfb => clkdouble,
		locked => dll_locked_int,
    		rst => reset,
    		clk2x => clk2x_prebuf,
    		clk0 =>clk1x_prebuf
		);

local : BUFG
  	port map (
		I => clk1x_prebuf,
   		O => clklocal
		);

double : BUFG
   	port map (
		I => clk2x_prebuf,
    		O => clkdouble
		);

zbt_fb_ibufg : IBUFG
	port map (
		I => MEM_CLK5,
		O => zbt_fb_clk
		);

I_dll_zbt : CLKDLL
    	port map (
		clkin => LCLK,
	    	clkfb => zbt_fb_clk, 
    		locked => dll_locked_ext,
    		rst => reset,
    		clk2x => mem_clk_ext
		);

zbt_ext_clk : OBUF
   	port map (
		I => mem_clk_ext,
    		O => MEM_CLK
		);


Do I make this right ?

Matthias


-- 
--------------------------------------------------------------------------

                             _/_/_/_/   Matthias Fuchs
                            _/_/_/_/   Dipl.-Ing.
                           _/_/_/_/   matthias.fuchs@esd-electronics.com

       _/_/_/   _/_/_/_/_/_/_/      esd electronic system design gmbh
     _/   _/  _/             _/    Vahrenwalder Str. 207
    _/   _/    _/_/_/   _/   _/   D-30165 Hannover
    _/             _/  _/   _/   Phone: +49-511-37298-0
     _/_/_/_/_/_/_/   _/_/_/    Fax:   +49-511-37298-68

--------------------------------------------------------------------------

Article: 34249
Subject: Re: Internal clock skew when using DLL
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 17 Aug 2001 09:35:18 -0400
Links: << >>  << T >>  << A >>
This brings me back to my original question of whether or not the software
can account for this. Generally speaking, if two clocks are synchronous but
skewed, you can provide P&R with a constraint, and it will ensure that
setup/hold times are respected, regardless of the direction of data
transfer.

Since the second clock is being generated internally, couldn't the software
use its timing model to calculate the skew between the two clock nets, and
then account for it? I know one person replied that they didn't think the
software did this, and I agree, but I haven't gotten a conclusive answer. It
really would simplify my job if I didn't have to clock parts of the design
on the falling edge, etc..

It doesn't help that I've also heard claims from certain Xilinx personnel
that their internal flip-flops are virtually metastable-proof...

Cheers,
Jamie

"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3B7C49D2.73953E9B@xilinx.com...
> It depends on the direction of data flow.
>
> Let's look at this in more general terms.
> If you have two phase-coherent clocks - whether one is a frequency
multiple or
> not is really irrelevant - then you have to be careful when you transfer
data
> across the clock boundary.
> If the data transmitting register is clocked a little later than the
receiving
> register, that is safe and you can most likely afford the slight loss in
timing
> margin.
> If the data transmitting register is clocked a little early, you are
rolling
> dice with the devil, because you may or may not end up with a race
condition,
> where the receiver clocks data in on "the same" edge as the transmitter
sent it.
>
> It's the old story: Clock skew against the direction of data flow is safe,
clock
> skew in the direction of data flow is potentially dangerous ( but of
course not
> if it is only 200 ps ).
> BTW, that's one of the questions I have asked every applicant for the last
15
> years.
> Some had it, some didn't...It doesn't require experience, just a sharp
mind.






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
2017JanFebMarApr2017

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