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 28100

Article: 28100
Subject: Metastability rant (was Re: dual port ram for altera)
From: murray@pa.dec.com (Hal Murray)
Date: 21 Dec 2000 04:05:22 GMT
Links: << >>  << T >>  << A >>

> This seems to be the season of metastability.
> Ok, so in the absolute worst case scenario the two conflicting simultaneous writes
> leave the cell in the metastable condition. Everybody agrees that it cannot stay
> there very long. I claim that 5 ns is extremely unlikely, 10 ns only once in our
> lifetime. So, unless you read that same location that you just wrote conflicting
> information into ( so you really shouldn't care whether it's a 1 or a 0) within a
> few ns again, everything will be calm and peaceful.

It's real easy to combine a dual-port RAM with some other logic such that
routing and/or logic delays eat up all of the cycle time.  That means that
effectively you ARE looking at the RAM within a few ns of the clock.

How hard would it be for tools to notice the different-clock case and
compute the settling time available?

Similarly, I'd like a tool that would raise a red flag if a signal
from a different clock goes to more than one FF.

The dual port ram case is more complicated.  That's the same clock,
but we only case if the addresses are the same.



> Phil and I have been friends ( and colleagues at AMD ) for the past 20 years. We
> just have this running battle over the practical ( not the philosophical !)
> aspects of metastability.  Let me establish the probabilities by testing Virtex-II
> in January.

All data in this area is very welcome.  Thanks for all your previous
contributions.

I hope you have time to measure what happens at non-typical Vcc and
temp too.



But speaking of the practical side...  I work on several types of gear.

One type is a one-shot hack in the lab.  I tinker until it works.
Metastability is lost in the noise of all the other confusion.

Another type is low volume with friendly users.  I want it to be
reasonably reliable but I probably know all the people who will
ever use it so I will get feedback if it isn't solid enough.  I'd
accept glitches like metastability might cause if they happen (say)
less frequently than once per year per box.  (I'd be embarrassed
with that level of flakiness, but might live with it in order to
work on something with higher payoff.)

Another type of gear is higher volume.  I'm not talking about
TV or cell-phone scale, but something like web servers.  One
failure that causes a system crash (or worse, corrupt data) per
my lifetime per installed system is too high - way too high.

  Say my lifetime is 100 years.  That gives 10 crashes per year per 1000
  systems in use.  Decent software is better than that.


Most of the time, it's easy to be conservative when crossing clocking
boundaries.  It just adds another cycle of latency - and that cycle
turns the failure rate into once per lifetime of the universe or
some other silly number so I can forget about it.

But every now and then, the delay is critical and I have to make a
tradeoff between time and reliability.  Can I get away with a half
cycle rather than a whole cycle?  Can I move some logic into that
slot?  Is sure would be nice to do that with engineering rather
than handwaving.

I'd also like to be able to double check the simple case and make
sure that the failure rate is astronomical rather than just waving
my hands and claiming it's good enough.



I find it somewhat amazing that this area hasn't received more
attention.  Do schools cover metastability?

I wonder how many projects have failed because they were just a
bit too flakey due to a metastability bug.




Just in case anybody thinks I'm picking on the digital world, try
reading the spec sheet for a linear regulator and then try to prove
to yourself that your design is stable.  It's as bad as GSR timings. :)



-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 28101
Subject: Re: FPGA and Board for Microprocessor Design?
From: "Tony Burch" <tony@BurchED.com.au>
Date: Thu, 21 Dec 2000 15:20:59 +1100
Links: << >>  << T >>  << A >>
Neil,

You are right-on!

We didn't need to put a higher frequency osc module
on the kit because of the Spartan II on-chip DLLs -
they are used to multiply up the clock on chip
if necessary.

No problem with the power supply, or supply decoupling.

Indeed, one of the reasons the 24MHz was chosen was
because of rationalising the inventory (a 24MHz osc module
is also included with the BED-FPGA-CPU-IO kit).  The
BED-FPGA-CPU-IO module can also plug onto the other
BED FPGA proto kits, which don't always have a 24MHz
oscillator on them.  So in alot of cases it is not redundant.

Please note that BurchED is a small enough company
that we will consider all requests such as "can you ship
the kit with a different frequency oscillator module?".  We
are always happy to receive requests - just email me.

Best regards and seasons greetings

Tony
www.BurchED.com.au

"Neil Franklin" <neil@franklin.ch.remove> wrote in message
news:6uelz2rfvb.fsf@chonsp.franklin.ch...
> sulimma@my-deja.com writes:
>
> > In article <3A3FA329.C726271@jetnet.ab.ca>,
> >   Ben Franchuk <bfranchuk@jetnet.ab.ca> wrote:
> > > Simon Gornall wrote:
> > > > I'll need to figure out how easy/stable it is when you get rid of
> > the
> > > > 24MHz clock. Presumably there's a good reason why they've crippled
> > it
> > > > like this
>
> Cheaper clock chip? This is after all only the default "good for most
> users" chip, which can be replaced by "we want max power" users.
>
> Also don't forget that the XC2S chips like the XCV have 4 on-chip DLLs
> which can do f*2 and of which pairs can be cascaded (App note says
> so). So you can go up to 96MHz with that default Osc.
>
>
> > > This could be for VGA output. One clock does all.
> > As would a 48 MHz or 96 Mhz or 144 MHz Clock. So they really might
> > have a problem with the power supply or similar.
>
> The post from Burch also mentioned expansion boards. One of these has
> an VGA connector and 3*4bit DACs on it. That board also has an second
> 24MHz Osc (and an 3.xxxMHz for the RS 232 on it). So the 24MHz on the
> main board is not for VGA.
>
> Hmmm. Having 24MHz for the VGA board would make reducing inventory
> positions an further reason for an 24MHz default. Given that Burch
> seems to be aiming for absolute minimal cost that could be it.
>
>
> --
> Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
> Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic



Article: 28102
Subject: Re: Hand Soldering a PQ208 - It looks tough to do
From: "Steve W." <natpress@sprint.ca>
Date: Wed, 20 Dec 2000 23:22:27 -0500
Links: << >>  << T >>  << A >>
Good site Harvey. A couple of comments though...

1) If people are after this sort of info. I'd recommed
the NG sci.electronics.design, which is probably more
suitable than an fpga site.

2) Never use sharp tweezers? I've been working for years
in the industry and it was because of SMT that people went
to sharp tweezers. You don't stab the devices with the sharp
points but you need the narrow tips improved precision to
grab those little parts. Are the tweezers you're talking about
smooth on the gripping surface or ribbed?

3) The use of 2% silver solder is not that common for reel type
solder and I certainly I have seen lots of SMT done without it.
What is the reason for it?

4) I think tin-plating is generally good and I'd recommend it.
I guess it depends on what kind of junk you let get in the solution
and whether you have control of the source. You could have a
virgin bottle and a used bottle so that you don't degrade the whole
lot at once. Typically I find that the solution becomes very ineffective
but doesn't contaminate. I've gone from old, used solution that took
20 minutes to plate to new, fresh solution that plated instantaneously
when dropped in the solution.

5) With tin plating you can typically place the part flat and then solder.
However, if you don't do plating you can follow the technique you
described. However, I don't quite agree with your interpretation
of the commercial pcb vendors overcoming the problem. They do
solve the problem but typically the boards they build are not hand
soldered and thus not subject to the sinking problem of one pin being
soldered
before the other. In commercial operation you typically use solder paste
and go through an IR-relflow oven. If not, you glue the part down and
go through a molten wave-solder machine. The HASL finish (hot air solder
leveling) is to make sure that the large fine pitch multi-pin devices sit
flat
before they are soldered. As I've moved into very big and even finer pitch
BGA devices HASL is sometimes found to be not flat enough and
hence the move to gold electro-plate finishes (but HASL keeps improving).

5) You say that capacitors have no identification marks at all. Well that
isn't
always true and there many smt caps I've used with codes. However, they
are not as easy to read as the resistors or the old through-hole caps. They
use a cryptic alpha numeric code. The first letter is the vendor (k= kemet)
and then a alpha-numeric pair that requires a decoding table to figure out
the value. If I find a table on the kemet site (or other) I'll post a link.

Steve

harveytwyman@my-deja.com wrote in message <91q1s5$mag$1@nnrp1.deja.com>...
>Being involved with student projects, the ability to handle the latest
>SMT devices has been essential.
>
>I've developed techniques over the last few years that are successful
>for beginners as they only require simple hand tools.
>
>My Web Page below describes these techniques in detail:
>
>http://www.Makaton-Signs.org.uk/PCB-Techniques
>
>    ___________________________________________
>===|                                           |===
>===|        H A R V E Y    T W Y M A N         |===
>===| ----------------------------------------- |===
>===| Department of Electronics,                |===
>===| University of Kent.                       |===
>===| Canterbury. U.K.                          |===
>===| ----------------------------------------- |===
>===| ABOUT ME: http://www.Twyman.org.uk/CV.htm |===
>===| ----------------------------------------- |===
>===| EMAIL ME: H.E.Twyman@ukc.ac.uk            |===
>===|___________________________________________|===
>
>
>
>Sent via Deja.com
>http://www.deja.com/



Article: 28103
Subject: Re: 3V -> 5V clock signal level conversion
From: Nial Stewart <nials@sqf.hp.com>
Date: Thu, 21 Dec 2000 10:02:15 +0000
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> WOrks as long as 1) you can tolerate the ringing that inevitably occurs when the
> driver shuts off,

Ray,

I clearly saw this effect on a 'scope when experimenting with
different configurations for driving the op. As you might expect
it gets worse as the DRIVE attribute is increased.

It's actually very hard to properly terminate the track whilst
pulling the line high as hard as possible.


Nial.

Article: 28104
Subject: synchronize and split reset
From: pinhas@my-deja.com
Date: Thu, 21 Dec 2000 10:47:10 GMT
Links: << >>  << T >>  << A >>
If you use VIRTEX than it is recommended not to
use GSR. This way the software will do a static
timing for you.
RESET is usually very loaded. Not all FF devices
need to have their RESET de-asserted at the same
clock. You may consider doing it sequentially:
For instance control first and data-path next.
Given that RESET is asserted for quite a long
time  a few cycles  than you need to worry only
for the RESET de-assertion synchronization.
Suppose a case where FF A drives FF B. In that
case the cycle time must be greater than:
1. RESET de-assert to q time +
2. Routing delay time +
3. Logic delay time +
4. FF B setup time.




In article <3a37e67f@news.datacomm.ch>,
  "Martin Heimlicher" <heimlicher@scs.ch> wrote:
> Dear all,
>
> This is a very basic and general FPGA question:
>
> How do I assure that an externally supplied
reset signal connected to some
> sort of GSR (global set/reset) net releases all
registers simultaneously (in
> the same clock cycle) and reliably (no
metastability) ?
>
> Do I need to synchronize the external reset
signal through one or two
> registers before feeding it to the GSR net ?
>
> If yes, what do I do in the case of multiple
clocks in a design ? Can I use
> the GSR net only to reset registers clocked by
one clock and using other
> routing ressources to reset registers clocked
by the other clocks ?
>
> If I am worrying to much about this issue: How
do FPGAs circumvent these
> problems ?
>
> Regards,
>   Martin Heimlicher, Supercomputing Systems AG,
Switzerland
>
>



Sent via Deja.com
http://www.deja.com/

Article: 28105
Subject: Re: Help with encoder/decoder
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Thu, 21 Dec 2000 04:22:57 -0700
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM wrote:
> I hadn't noticed the 1ns receiver-receiver jitter - you obviously
> won't get anywhere near this with a digital PLL. You also mentioned a
> DLL, but this isn't any use for data recovery of a PCM waveform, since
> it's irregular. You could use a DLL if you were willing to have a
> separate clock line, but I agree that 1 ns is going to be a real
> problem unless you put in an adjustable delay line.
> 
> Evan
Quicklogic  makes a 2.5 Gb/s fiber encoder/decoder's so something in that line
may
be useful for ideas of what is available.
http://www.quicklogic.com/devices/QuickFC
 
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk

Article: 28106
Subject: Simple clock and reset on an Ikos VLE-5M box
From: Jon Schneider <jms@geriatrix.circlesquared.cXoXm>
Date: 21 Dec 2000 11:55:40 +0000
Links: << >>  << T >>  << A >>
I want to do a straightforward simulation of a design one on of these
boxes using an internally generated clock and reset. Memories are
being preloaded so the cpu will run (hopefully).

It seems however that to get a simple reset you need to use one of the
user bits, physically loop that back to the design's reset input, then
give vrun come options to make it generate the clock even though it
might not have (I/O having been enabled).

Surely somebody has solved this rather fundamental problem ?

        Jon

Article: 28107
Subject: Re: Help with encoder/decoder
From: "markp" <map@nospam_dial.pipex.com>
Date: Thu, 21 Dec 2000 13:02:36 -0000
Links: << >>  << T >>  << A >>

"Javier SERRANO" <Javier.Serrano@cern.ch> wrote in message
news:3A3E05DF.8D1904FE@cern.ch...
> Hi,
>
> I am looking for an encoder/decoder pair to transmit serial data through
> long distances. There will be one emitter and many receivers, and the
> system cannot accept more than one nanosecond of jitter among receivers,
> that is there can be absolute delay differences from one receiver's
> decoder output to another's, but those differences have to be stable to
> within one ns. On the other hand, I would not like to buy a commercial
> pair of encoder/decoder but rather design my own with an FPGA (I might
> have to give support for many years). I assume that to get that kind of
> accuracy, I will have to use either an on-chip or an on-board PLL/DLL.
> Does someone know where I can get schematics or text-based designs for
> simple encoders like Manchester or biphase mark? Any good books or URLs
> on the subject?
>
> Thank you very much.
>
> Javier

This is a very tight spec indeed. The the tolerance of the refractive index
of the transport media itself (fibre optic or whatever) can introduce
changes of speed of propagation that over large distances that will possibly
swamp this tolerance. A high speed serial receiver can lock to an incoming
data stream with quite high accuracy, but you seem to be talking about
controlling changes in absolute propagation time across large distances.

Mark.

P.S. Cypress do some simple high speed (400Mbit/sec) serial transmitter and
receivers ('Hotlink'). They may not be of use to you, but there are app
notes full of interesting stuff regarding jitter.
http://www.cypress.com/hotlink/hotlinkappnotes.html



Article: 28108
Subject: Re: Question about Xilinx pins at high-frequency
From: "Pascal C." <>
Date: Thu, 21 Dec 2000 05:19:39 -0800
Links: << >>  << T >>  << A >>
The pins on which I am trying to reduce the drive are LVTTL.  I've constrained them to a Clock to out of 6 ns, to allow some setup time (the clock is 131M, so clock period is about 7.8ns).  Under 12 mA, it tells me it can't possibly meet a clock to out of 6 ns.  And fails.  

I finally got an answer from Xilinx TechSup.  They told me I had two choices: a) ease off the constraints so that PAR will complete, or b) change all pins manually.

For the TRIs, the OEs on the IOBs are active-high, and so were my OE signals.  I guess I'll investigate this the next time it comes up + try to use different tools.

Article: 28109
Subject: Re: Help with encoder/decoder
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Thu, 21 Dec 2000 15:42:22 GMT
Links: << >>  << T >>  << A >>
> > I am looking for an encoder/decoder pair to transmit serial data through
> > long distances. There will be one emitter and many receivers, and the
> > system cannot accept more than one nanosecond of jitter among receivers,
> > that is there can be absolute delay differences from one receiver's
> > decoder output to another's, but those differences have to be stable to
> > within one ns. On the other hand, I would not like to buy a commercial
> > pair of encoder/decoder but rather design my own with an FPGA (I might
> > have to give support for many years). I assume that to get that kind of
> > accuracy, I will have to use either an on-chip or an on-board PLL/DLL.
> > Does someone know where I can get schematics or text-based designs for
> > simple encoders like Manchester or biphase mark? Any good books or URLs
> > on the subject?
> >
> > Thank you very much.
> >
> > Javier
>
> This is a very tight spec indeed. The the tolerance of the refractive
index
> of the transport media itself (fibre optic or whatever) can introduce
> changes of speed of propagation that over large distances that will
possibly
> swamp this tolerance. A high speed serial receiver can lock to an incoming
> data stream with quite high accuracy, but you seem to be talking about
> controlling changes in absolute propagation time across large distances.
>
> Mark.
>
> P.S. Cypress do some simple high speed (400Mbit/sec) serial transmitter
and
> receivers ('Hotlink'). They may not be of use to you, but there are app
> notes full of interesting stuff regarding jitter.
> http://www.cypress.com/hotlink/hotlinkappnotes.html

Mark and Javier,
    It sounds to me that your very tight jitter spec has nothing to do with
the tolerance of the refractive index of the transport media.  I am assuming
that that transport media is steady in its prop delay of the signals.  I am
also assuming that the system is designed with this in mind.  If this is the
case, then it sounds to me that the clock is the only thing that will affect
the jitter spec.
     For example, assume that there is a 7.345 ns difference in delay
between two receiver inputs.  Javier says that this is okay.  What he
doesn't want is a jitter in this delay greater than 1 ns.  In order to meet
this spec, the sending clock must have a jitter spec that is better than
this.  If Javier uses a PLL or DLL, then this device will add jitter to the
basic clock.  I would use a very stable clock circuit that meets the jitter
spec.
    Now if these cables are swinging in the wind, then I can see where that
kind of phenomena can affect the prop delay and introduce jitter.  But
Javier has this under control, since he is only asking about circuits.  If
transmission lines are held perfectly still and still introduce variations
in prop delay, then this is new to me and I am wrong here.
Simon Ramirez, Consultant
Synchronous Design, Inc.





Article: 28110
Subject: Re: really fast counter in SpartanXL?
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 21 Dec 2000 15:46:37 GMT
Links: << >>  << T >>  << A >>
On Wed, 20 Dec 2000 10:53:14 -0800, Peter Alfke
<peter.alfke@xilinx.com> wrote:

>Hal Murray wrote:
>
>>
>> Could you get an extra half bit of resolution by clocking things
>> on the other edge of the clock too?
>>
>> I think that requires that both the clock-enable (pulse being measured)
>> and the clock be be routed to 2 CLBs with matching routing delays.
>>
>
>Come to think of it:
>Why limit yourself to just two edegs? You can create a bunch of increasingly
>longer clock delays with perhaps 100 ps granularity, and use all of them.
>
>Peter Alfke

This reminded me of a Vernier caliper. I did a quick search and came
up with:

http://www.lecroy.com/lrs/pubs/p48/P48.htm

Which is a LeCroy paper on how they built a chip to do this. The idea
is obvious (that didn't stop them applying for a patent, though): you
use a delay line as the high-precision scale, with 10 delay steps
taking up 9 clock periods, and you measure progress through the delay
line together with the clock count. So, if you've got a clock count of
4, say, and 3 delay elements have switched, then your delay is 4.3
clocks. You can calibrate the delay line using random measurements,
which takes 'a few minutes' in their case. Their target was 50ps
resolution.

Evan

Article: 28111
Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ?
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 21 Dec 2000 15:47:01 GMT
Links: << >>  << T >>  << A >>
On 21 Dec 2000 02:40:38 GMT, murray@pa.dec.com (Hal Murray) wrote:

>
>> They always get set/reset by GSR - the SR input is just an optional
>> additional term.
>
>Thanks.  Is that in the documentation someplace?  I don't remember
>seeing it and it's the sort of detail I think I would remember.

I just had a look at the online docs, and it's pretty much all covered
in the first few pages of:

Synthesis and Simulation Design Guide
 Chapter 4: Designing FPGAs with HDL
  Using Dedicated Global Set/Reset Resource

>> BTW, the last time I checked both the Virtex and the 4K data sheets
>> there were no relevant skew timings on GSR. None of the important
>> numbers are documented.
>
>Why are you interested in skew?  Suppose the skew is 1 ns but the
>prop time is somewhere between 0 and 20.  How do I use GSR if my clock
>time is 10 ns?

I just meant delay specs in general - 'skew' was a bad choice of word.

>My copy of the VirtexE data sheet has some GSR data: GSR to Pad,
>is on the bottom of the IOB Output Switching, Table 21.  There is
>a similar number a few pages earlier for GSR to IQ on the input
>side.
>
>Yes, similar data for CLBs and RAMs would be helpful.

Not to mention a setup/hold parameter to the clock. I don't think it
matters, though - you can still use GSR effectively with some extra
messing around.

Evan

Article: 28112
Subject: Re: Help with encoder/decoder
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 21 Dec 2000 15:47:30 GMT
Links: << >>  << T >>  << A >>
On Wed, 20 Dec 2000 22:27:31 GMT, eml@riverside-machines.com.NOSPAM
wrote:

> Xilinx have an app note on Manchester
>coding, but I don't think it covers the digital PLL, which is the only
>part of the design which requires any thought.

I hadn't noticed the 1ns receiver-receiver jitter - you obviously
won't get anywhere near this with a digital PLL. You also mentioned a
DLL, but this isn't any use for data recovery of a PCM waveform, since
it's irregular. You could use a DLL if you were willing to have a
separate clock line, but I agree that 1 ns is going to be a real
problem unless you put in an adjustable delay line.

Evan

Article: 28113
Subject: testbench generation tool
From: "hiro" <takehiro@rr.iij4u.or.jp>
Date: Fri, 22 Dec 2000 01:03:03 +0900
Links: << >>  << T >>  << A >>
Dear all,

 I'm sorry for issuing a kind of advertisement to this groupe, but let us
intruduce our new product.
 We has just released testbench generation tool named "TBassistant" for
$55.00.
 Please visit our site at
http://www.din.or.jp/~yagiyagi/HTML/index_english.htm and click
 products button on the page.

Sicerely,

hiro
FLEMO Inc.


Article: 28114
Subject: Re: Metastability rant (was Re: dual port ram for altera)
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 21 Dec 2000 09:32:39 -0800
Links: << >>  << T >>  << A >>
Hal,
I think we would agree that the goal should be an MTBF of >10,000 years, so that 1000
systems running concurrently produce only one "crash" per 10 years. And "crash" may not
involve loss of life, in which case we should add more zeros.
I am itching to start the test with Virtex-II.
Peter Alfke
===============================
Hal Murray wrote:

> <snip>
> Another type of gear is higher volume.  I'm not talking about
> TV or cell-phone scale, but something like web servers.  One
> failure that causes a system crash (or worse, corrupt data) per
> my lifetime per installed system is too high - way too high.
>
>   Say my lifetime is 100 years.  That gives 10 crashes per year per 1000
>   systems in use.  Decent software is better than that.
>
> Most of the time, it's easy to be conservative when crossing clocking
> boundaries.  It just adds another cycle of latency - and that cycle
> turns the failure rate into once per lifetime of the universe or
> some other silly number so I can forget about it.
>
> But every now and then, the delay is critical and I have to make a
> tradeoff between time and reliability.  Can I get away with a half
> cycle rather than a whole cycle?  Can I move some logic into that
> slot?  Is sure would be nice to do that with engineering rather
> than handwaving.
>
> I'd also like to be able to double check the simple case and make
> sure that the failure rate is astronomical rather than just waving
> my hands and claiming it's good enough.
>
> I find it somewhat amazing that this area hasn't received more
> attention.  Do schools cover metastability?
>
> I wonder how many projects have failed because they were just a
> bit too flakey due to a metastability bug.
>
> Just in case anybody thinks I'm picking on the digital world, try
> reading the spec sheet for a linear regulator and then try to prove
> to yourself that your design is stable.  It's as bad as GSR timings. :)
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.


Article: 28115
Subject: Re: 3V -> 5V clock signal level conversion
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Thu, 21 Dec 2000 10:33:39 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> markp wrote:
> 
> > In my experience series terminating clocks is superior to other forms of
> > clock termination, but I'll leave that can of worms to another thread!
> >
> 
> Series termination is great for signals that go from one source to one
> destination.
> Since the drive impdance is adjusted to match the transmission line Z0, a
> half-amplitude signal travels down the line, is reflected at the unterminated
> far end to become a full signal "instantaneously", then travels back to the
> source, where it is swallowed up in the output impedance = Z0.
> 
> Neat trick. It USES the reflection instead of FIGHTING it.
> 
> But beware: Never ever (NEVER EVER!) use series termination for a signal that
> has to travel to multiple destinations. All but the farthest of these
> destinations will see the half-amplitude signal for some time, which is the
> worst level possible. Poor noise immunity, double-triggering etc. Ugly stuff.

Actually -- you can get away with series termination for something
driving multiple loads IFF you pay strict attention to the layout (keep
all arms the same length, etc etc etc).  Simulation of the PCB with
something like Hyperlynx is required.

I know it works because I just did an XC4013XLA SRDAM controller design.
The FPGA talked to four SDRAM devices.  The series terminations (the CTS
four-banger SMT jobs) were installed as close as we could get them to
the FPGA.  Two of the SDRAMs were on the top of the board; the other two
were on the bottom.  We also made sure line lengths were equal, and the
SDRAM and FPGA clocks were all driven by a zero-delay PLL clock buffer
chip.  Works fine (the board runs at 80 MHz) and looking at the signals
on a fast 'scope (with proper probing, etc etc) shows real clean signals
for everything.
 
> The best way to terminate a clock that drives multiple loads is to have a
> strong ( low-impedance ) driver, then terminate the farthest end of the clock
> "snake" with a resistor (=Z0) in series with a capacitor to ground. (RC in
> SERIES, and this combination used as a parallel termination)
> Make the RC larger than the transition time, but smaller than the clock High or
> Low time.
> 50 Ohm and 100 pF is a proven combination for all but the very fastest clocks.

But only use AC termination for 50% duty-cycle signals like clocks.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."

Article: 28116
Subject: Re: HOT AREAS IN FPGAs
From: "x-guy@hotmail.com" <x-guy@hotmail.com>
Date: Thu, 21 Dec 2000 17:35:24 GMT
Links: << >>  << T >>  << A >>
Check www.ezchip.com and www.broadcom.com and www.bluetooth.com

Saqib wrote:

> It is said that the three areas of DSP, Communications and Networking
> are very hot in FPGAs designs. DSP is ok...but what specifically is
> meant by "communications"..does it include products like Encryptors,
> Forward error correction products (Viterbi , RS codecs),Modems...or it
> means telecommunications..if yes what are specific cores that are
> suitable for FPGA implementation...
> And what does NETWORKING mean..what are specific networking products
> implemented in FPGAs?
> Thanx
>
> --
> --saqib yaqub--
>
> Sent via Deja.com
> http://www.deja.com/


Article: 28117
Subject: Re: Metastability rant (was Re: dual port ram for altera)
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 21 Dec 2000 10:16:09 -0800
Links: << >>  << T >>  << A >>


Hal Murray wrote:

>
> It's real easy to combine a dual-port RAM with some other logic such that
> routing and/or logic delays eat up all of the cycle time.  That means that
> effectively you ARE looking at the RAM within a few ns of the clock.

But don't forget:
The potential problem occurs only when you read very soon (!) from the SAME location
that you just wrote conflicting information to. You can read any other location any
time without any problem.

Metastability seems to be a neat excuse for indulging in way-out fantasies.    :-)
But, as we agreed, we are looking for an MTBF of >10,000 years, so we should let our
fantasy run wild...
Peter Alfke

>
>


Article: 28118
Subject: Re: Help with encoder/decoder
From: "markp" <map@nospam_dial.pipex.com>
Date: Thu, 21 Dec 2000 18:17:57 -0000
Links: << >>  << T >>  << A >>

>
> Mark and Javier,
>     It sounds to me that your very tight jitter spec has nothing to do
with
> the tolerance of the refractive index of the transport media.  I am
assuming
> that that transport media is steady in its prop delay of the signals.  I
am
> also assuming that the system is designed with this in mind.  If this is
the
> case, then it sounds to me that the clock is the only thing that will
affect
> the jitter spec.

<snip>

>     Now if these cables are swinging in the wind, then I can see where
that
> kind of phenomena can affect the prop delay and introduce jitter.  But
> Javier has this under control, since he is only asking about circuits.  If
> transmission lines are held perfectly still and still introduce variations
> in prop delay, then this is new to me and I am wrong here.
> Simon Ramirez, Consultant
> Synchronous Design, Inc.


I have to admit I'm a little out of my depth here. I had assumed that the
receivers themselves were a 'long distance' apart. Let's say 100m for
arguments sake - this translates to around 500ns or so in delay. I assumed
also that there are very slight changes in the refractive index in the
cables due to expansion and other physical phemomenon. These changes are
very small and won't cause much dispersion to the light passing through it,
but their effect is cumulative on the absolute delay through the whole
fibre. If you had two of these fibres next to each other and subjected them
to different temperatures, would the light propagate down them to within 1ns
at the receiving end? I don't really know, but my gut feeling is there would
be a difference, and that this might be greater than 1ns. I've tried to find
refractive index tolerances for fibres but so far failed. Any ideas?

Mark.



Article: 28119
Subject: Re: Help with encoder/decoder
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Thu, 21 Dec 2000 18:43:35 GMT
Links: << >>  << T >>  << A >>
> I have to admit I'm a little out of my depth here. I had assumed that the
> receivers themselves were a 'long distance' apart. Let's say 100m for
> arguments sake - this translates to around 500ns or so in delay. I assumed
> also that there are very slight changes in the refractive index in the
> cables due to expansion and other physical phemomenon. These changes are
> very small and won't cause much dispersion to the light passing through
it,
> but their effect is cumulative on the absolute delay through the whole
> fibre. If you had two of these fibres next to each other and subjected
them
> to different temperatures, would the light propagate down them to within
1ns
> at the receiving end? I don't really know, but my gut feeling is there
would
> be a difference, and that this might be greater than 1ns. I've tried to
find
> refractive index tolerances for fibres but so far failed. Any ideas?
>
> Mark.

Mark and Javier,
     If you laid down to fibers next to each other and subjected them to
different temperatures, then the prop delay of one fiber would change
differently than the prop delay of the other fiber, as you said above.  But
Javier isn't worried abot this.  According to his email, he is designing the
circuitry, not the transmission media.  For a tight spec like what he
quoted, the transmission media guys would have to control temperature
differences, movement, etc., in order to keep the overall jitter spec within
tolerance.
     Javier's job is to design the circuitry, i.e., implement an
encoder/decoder pair such that there is less than 1 ns of jitter at the
decoder output.  This jitter is a sum of the "jitter" in the transmission
media as well as the jitter of the encoder/decoders, so he must take the
transmission jitter into account if significant.  Javier needs to ask the
transmission media guys what that jitter is, so that he can subtract it from
his total 1 ns jitter.  The remainder is what he has to design to.
     Also, since the temperatures and movements of the transmission media
are likely to cause slow changes in the difference between the prop delay,
then it may not even be a problem, i.e., it may not be considered "jitter."
For example, if the top cable is exposed to the sun more than the bottom
cable, then it would swing slowly every 24 hours.  Is this considred
"jitter."  Only Javier knows.
     I think Javier needs to nail down this transmission media contribution,
but he really needs to look at the encoder clock as well as the decoder
clock, however he plans to derive it.  A serial decoder can extract the
clock (self clocking), but there is jitter there.  He can transmit the clock
from the encoders, but skew problems can arise.
     Javier, can you tell us more about your transmission media and/or your
clocking scheme?
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA



Article: 28120
Subject: Re: Help with encoder/decoder
From: Greg Neff <gregneff@my-deja.com>
Date: Thu, 21 Dec 2000 18:51:33 GMT
Links: << >>  << T >>  << A >>
In article <91th4k$hd1$1@lure.pipex.net>,
  "markp" <map@nospam_dial.pipex.com> wrote:
(snip)
>
> I have to admit I'm a little out of my depth here. I had assumed that
the
> receivers themselves were a 'long distance' apart. Let's say 100m for
> arguments sake - this translates to around 500ns or so in delay. I
assumed
> also that there are very slight changes in the refractive index in the
> cables due to expansion and other physical phemomenon. These changes
are
> very small and won't cause much dispersion to the light passing
through it,
> but their effect is cumulative on the absolute delay through the whole
> fibre. If you had two of these fibres next to each other and
subjected them
> to different temperatures, would the light propagate down them to
within 1ns
> at the receiving end? I don't really know, but my gut feeling is
there would
> be a difference, and that this might be greater than 1ns. I've tried
to find
> refractive index tolerances for fibres but so far failed. Any ideas?
>
> Mark.
>
>

Try posting in sci.optics.fiber


--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com
http://www.deja.com/

Article: 28121
Subject: XC18V02 programming with xsvf file
From: alexboyer@my-deja.com
Date: Thu, 21 Dec 2000 20:16:14 GMT
Links: << >>  << T >>  << A >>
Hello,
   I used the algorithm in the xapp058 from Xilinx to load a serial
eeprom XC18V02 with a xsvf file and it is not working. The support at
Jtag said this algorithm is not working with proms, that this algo is
for fpgas or cpld and they were few changes to do to this algorithm to
make it works with proms.

   Is any of you know what are the expected changes? They should not be
much but I don't know were it could be...

Thank you


Sent via Deja.com
http://www.deja.com/

Article: 28122
Subject: Parallel clock termination (Was: 3V -> 5V clock signal level conversion)
From: "Marc Klingelhofer" <marckEATSSPAM@omneon.com>
Date: Thu, 21 Dec 2000 20:44:42 GMT
Links: << >>  << T >>  << A >>
Peter and all,

    I'll jump in here quickly and then go away because I have a
different perspective on the value of the capacitor for a parallel RC
termination. Refer to Johnson and Graham's "High-Speed
Digital Design, A Handbook of Black Magic." I just did to check
my reasoning.

    In a nutshell, the R is chosen to equal Z0. The requirement
for C is that its impedance should be negligible compared to Z0.

    Remember that it's the edge that we're terminating, and what
we'd all do if it didn't take so much static power is have a simple
R (= Z0) to a termination voltage. The C is a substitute for
that voltage source, and should present a very low impedance.
What's a "very low impedance"? Z0/10? Z0/100? You're the
engineers, I'll let you decide. The voltage source's output
impedance would ideally be 0 ohms. Keep in mind the
frequencies you use to calculate C's impedance: it's not the
signal's repetition rate, it's the frequencies present in the
edge. A 100MHz clock with a 1ns rise/fall has the same
termination requirement as a 1MHz clock with a 1ns rise/fall
time. According to the previously mentioned book, for a 1ns
rise/fall time and an impedance of 1 ohm you'd need C = 318pf.

    Here's where most people get confused. The termination
voltage is not important from a signal integrity standpoint. It
can be 0V, 3.3V, even 100V. Of course, you then need to
assess the signal's drive capability into R and such a voltage.
Because of this, if it's not a drive issue, C can be arbitrarily large.
For that same reason, the signal's frequency and duty cycle are
not factors, UNTIL YOU NEED TO CONSIDER THE DRIVE
CAPABILITIES OF THE SOURCE.


                Marc


"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
 news:3A412F6A.ACE1B0D6@xilinx.com...
>
>
> markp wrote:
>
> > In my experience series terminating clocks is superior to other forms of
> > clock termination, but I'll leave that can of worms to another thread!
> >
>
> Series termination is great for signals that go from one source to one
> destination.
> Since the drive impdance is adjusted to match the transmission line Z0, a
> half-amplitude signal travels down the line, is reflected at the
unterminated
> far end to become a full signal "instantaneously", then travels back to
the
> source, where it is swallowed up in the output impedance = Z0.
>
> Neat trick. It USES the reflection instead of FIGHTING it.
>
> But beware: Never ever (NEVER EVER!) use series termination for a signal
that
> has to travel to multiple destinations. All but the farthest of these
> destinations will see the half-amplitude signal for some time, which is
the
> worst level possible. Poor noise immunity, double-triggering etc. Ugly
stuff.
>
> The best way to terminate a clock that drives multiple loads is to have a
> strong ( low-impedance ) driver, then terminate the farthest end of the
clock
> "snake" with a resistor (=Z0) in series with a capacitor to ground. (RC in
> SERIES, and this combination used as a parallel termination)
> Make the RC larger than the transition time, but smaller than the clock
High or
> Low time.
> 50 Ohm and 100 pF is a proven combination for all but the very fastest
clocks.
>
> Peter Alfke, Xilinx Applications
>



Article: 28123
Subject: Re: FPGA and Board for Microprocessor Design?
From: msimon@xta.com (M. Simon)
Date: Thu, 21 Dec 2000 21:12:30 GMT
Links: << >>  << T >>  << A >>

Take a look at my site below:


Let me know if you have questions.




M. Simon  Space-Time Productions http://www.spacetimepro.com
              Free CNC Machine Control Software
              Free Source Code
              Control the World From a Parallel Port

Article: 28124
Subject: Re: Help with encoder/decoder
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 21 Dec 2000 21:16:16 GMT
Links: << >>  << T >>  << A >>
On Thu, 21 Dec 2000 15:42:22 GMT, "S. Ramirez"
<sramirez@deleet.cfl.rr.com> wrote:

>Mark and Javier,
>    It sounds to me that your very tight jitter spec has nothing to do with
>the tolerance of the refractive index of the transport media.  I am assuming
>that that transport media is steady in its prop delay of the signals.  I am
>also assuming that the system is designed with this in mind.  If this is the
>case, then it sounds to me that the clock is the only thing that will affect
>the jitter spec.
>     For example, assume that there is a 7.345 ns difference in delay
>between two receiver inputs.  Javier says that this is okay.  What he
>doesn't want is a jitter in this delay greater than 1 ns.  In order to meet
>this spec, the sending clock must have a jitter spec that is better than
>this.  If Javier uses a PLL or DLL, then this device will add jitter to the
>basic clock.  I would use a very stable clock circuit that meets the jitter
>spec.
>    Now if these cables are swinging in the wind, then I can see where that
>kind of phenomena can affect the prop delay and introduce jitter.  But
>Javier has this under control, since he is only asking about circuits.  If
>transmission lines are held perfectly still and still introduce variations
>in prop delay, then this is new to me and I am wrong here.

In practice, I think that the clock jitter could be a very small part
of the total jitter. This'll depend on exactly how he implements the
system. Attenuation and dispersion, and other second order effects,
will cause significant changes in the waveform down the line. On the
systems I've worked on, the eye diagram at the receiver has generally
been more closed than open. This is a direct measure of (best case)
jitter on the line. In typical systems, you could easily get a jitter
of 50% or more of the unit interval.

Given this, I think there are a number of potential problems:

(1) If Javier has cables of different lengths, then the receivers will
be looking at different points in the pulse train, with different
frequency components, and different (maybe very different?)
instantaneous jitter

(2) The receivers will have different receive thresholds, and so
they'll be sampling their eye diagrams at different points

(3) The receivers will have different terminations, and different
asymmetries in their propagation delays. This'll affect the sampling
threshold and the decision.

I don't do a lot of this, but I think Javier's going to have to do
some hard work unless he has short cables compared to the unit
interval, a very clear eye diagram, tightly controlled receiver
tolerances, and a good PLL.

Evan

PS - ignore what I said about delay lines in the last post - too much
coffee...



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