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 29675

Article: 29675
Subject: Re: Interfacing Xilinx 4003 to an IDE Hard Disk interface.
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 05 Mar 2001 00:46:12 +0000
Links: << >>  << T >>  << A >>


Eric Montreal wrote:

> AFAIK, Muzaffer Kal is right.
>
> The latest T13 document he references clarify the data rates / throughput
> http://www.t13.org/project/d1410r1a.pdf
>
> Look page numbered 400 (414 in acrobat reader) third paragraph,
> and you'll find the exact transfert speed for all modes.
>
> If you made a UDMA interface that runs a 16.67 Mhz, thus transferring
> 16.67 * 2[transfers per clock] * 2[bytes per transfert], then it's UDMA
> mode 4 (AKA UDMA66) and not UDMA33.
>
> If you plan to build a UDMA controller with a 33 Mhz clock, you're
> ahead of times and already building a UDMA133 interface.
> IOW, you will simply overclock your drive, and, as usual, that's pretty
> sure to work in the lab / fail in the field.
>
> The fastest established standard, UDMA100, uses a 25 Mhz clock
> to attain 25*2*2=100 MBytes per second.
>
> Double check the timing in table 57 ( page numbered 361  (375 in acrobat reader))
>
> "T2cyctyp" for UDMA mode 2 (AKA UDMA33) is 120 ns (8.33 Mhz) .
>
> "T2cyctyp" for UDMA mode 4 is 60 ns (16.67 Mhz) while Tcyc applies to either
> half clock period and is specified to allow for unequal High / Low clock times.
> Tcyc is *not* the clock cycle time.
>
> Hope this helps.
>
> Eric.
>
> -------------------------------------
>
>

I stand corrected. I was designing for mode 2 i.e UDMA33. But its such a long time ago
that I thought I'd designed the i/f around a 16.67 MHz clock & not an 8.33MHz one! In
fact, dependent on the speed the logic's clocked at, it will already handle a 16.67MHz
clock. This is great since I have to do practically no work to get the client's
requested UDMA66, I don't see any great problem with UDMA100, and for once I can get
ahead of the game and invent UDMA133 [mode 6 ?].

Once again apologies to all.


Article: 29676
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 05 Mar 2001 01:18:54 +0000
Links: << >>  << T >>  << A >>


"S. Ramirez" wrote:

> >Ray,
>      Sorry for not responding to you sooner.  I see that some others have
> responded.  I was out in my garage doing a fiberglass layup, and once I
> start it, I cannot walk away until it is finished!
>      I'm not sure if we are talking about the same thing, so let me
> elaborate.
>      The first flip flop, FF1, I am sure that everyone agrees it will meta
> when used as a synchronizing flip flop.  There is a certain probability, p1,
> for a particular FF1 to meta if the input signal changes within the
> setup/hold time violation window.  There is another probability, p2, of the
> time that FF1 spends in meta.  As that time increases, p2 decreases.  These
> two probabilities multiply and give the final probability in a simplisitic
> form.  If meta exists when FF2 samples FF1's output, then it will also have
> a probability of meta.  Usually the clock cycle time of the two flip flops
> is much greater than the time for p2 to be significant, because this cycle
> time is usually dealing with prop delays that affect register to register
> performance.  But as well know, a long cycle time does not guarantee that
> FF2 will not see meta.
>      I claim that one can make the state machine flip flops the FF2s.  As
> long as they don't see meta at their setup-hold time window, they will
> perform as intended.  With the probability of meta being in the range of
> years, decades, centuries, this is accepted as practice.  If one inserts FF2
> between FF1 and the state machine flip flops, then FF2 becomes subject to
> that meta.  It will in turn meta in a hundred years and introduce its own
> small probability (p1*p2) of affecting the state machine's flip flops.  In
> other words, inserting FF2 only decreases the probability of causing a
> problem at the state machine, because the probabilities multiply
> (p1*p2*p1*p2).  But I claim that multiple flip flops in a state machine can
> serve as FF2s and work correctly as long as one knows that they will meta
> some time in the distant future (p1*p2).  Introducing FF2 between FF1 and
> the state machine has the disadvantage of adding another cycle of delay
> along with decreasing the probability of the flip flops acting as flop
> flops.
>      Usually in a state machine, there are multiple flip flops that will get
> affected by this low probability of meta.  There are different ways of
> designing state machines, but I really don't know how to design a state
> machine where only one flip flop will be affected, or at least I don't
> design state machines that way.  I usually use one-hot encoding, but this
> doesn't guarantee that only one flip flop will be affected.  Along with the
> state encoding bits, there are state output bits that are a function of the
> present state and the inputs, meta included.  My state output bits are not
> the state encoding bits, so there are multiple flip flops there seeing the
> low probability of meta.
>      I have seen others use FF1 and FF2, but I always questioned why they
> used it.  We never really came into an agreement that either I was wrong or
> they were wrong.  If I am wrong, then I am capable of learning things.  But
> my theories come from two major defense contractors that did some work in
> this area and standardized their design methodologies using the state
> machine flip flops as FF2s.  Their design handbook included what I said
> above as well as other procedures.  An example of one of these procedures
> is if one is building a nuclear device that is controlled by an electronic
> circuit, then everything needs to be synchronous, with the exception of a
> very few and heavily studied signals.  On the other hand, if you are Saddam
> Hussein working on an asynchronous nuclear device and the U.N. inspectors
> are scheduled to see you in a week, and you don't have time to convert it to
> a synchronous design, then you take your chances, run BIST and test it now!
> Simon Ramirez, Consultant
> Synchronous Design, Inc.
> Oviedo, FL  USA

I agree basically with Simon. What we have for an FF whose input has change has
violated the su/hld spec is a probability distribution p(t) which give the
probability that the output will be in a legal state at time t after the clock
edge. So the calculation is: find the value of t, call it Tok for which this
probablility is within you acceptable limits. If Tok + routing time + next FF
setup time is < the clock period then Simon's argument holds. If not then you
need another FF. The worst case is where the device is sufficiently slow that
even with a 0 routing time this sum cannot be met. You are then really into
stats and need a chain of FFs. If Tcyc is the clock period you then need N FFs
so that p(Tcyc)**N < your acceptable failure level.

Now the problem becomes one of practicalities: what is p(t) ? Very few
manufacturers give it - not even Xilinx for the Virtex & Virtex-E. Given this
lack of information I use a rule of thumb culled from the ASIC world. De-rate
the Tco of the domain crossing FFs by some multiple, say 6, of the unrouted
delay. Then set up constraints like this:

TIMESPEC TSSync = FROM FFS(FF1) TO FFS(*) TCyc - 5*Tco;

If it won't route to this with FF1 fanning out to many FFs then its time for a
double level synchoniser.

If anybody can suggest a better practical rule I'd really love to hear it.


Article: 29677
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Mon, 05 Mar 2001 14:23:07 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> My detailed answers are below.
> But first I want to agree with Jim, that there is a difference between the time
> delay until the flip-flop has stabilized, and the exact moment when it makes a
> change.
> The second flip-flop will only go metastable if the first flip-flop's delay plus
> routing exactly ( down to the picosecond !) hits the second flip-flops
> funny-bone metastability point.
> Otherwise the second flip-flop will reflect the right or wrong info coming from
> the first.
> In other words: You might transfer wrong data, but it is borderline impossible
> to transfer the act of going metastable.

<snip interesting stuff on Metastable Devices > 

> When I measured it with random input times ( incoherent clock and data ) I
> counted the times metastability exceeded a certain value.  I think you can
> calculate the width of the input window from that. It is extremely narrow.
> Perhaps even femtoseconds. let me know once you figured it out. I'm in a hurry
> right know.

The 'incoherent' clock/data approach I always feel uneasy about 
- just HOW inchoerent are they, and in the real world they may not be. 
Plus, the 'hit rate' decreases with improving process, as you have
observed.

I have thought of a way to both measure this, and stimulate metastable
outputs
more directly, and in a directly measurable way ( Physical )

Technique : 
 Construct a coarse delay line in Logic
 Construct a fine delay, by a sliding physical contact on a stripline, 
ideally slid under vernier control.

 From my memory of cables of ~200m/us that maps down to 200mm/ns, or 
~5pS/mm, so you can probably control / reproduce to around 50
femtoseconds, 
with a low cost test bench.

 This will give a quick method to track both the window, and how it
varies with
Temperature, and maybe even give enough control to see if you can hit
the
jackpot of 2nd 'flip-flops funny-bone metastability point.'

 Perhaps the next generation of FPGA Eval PCBS could have a
clock-vernier
delay strip-line along one edge :-)

-jg

Article: 29678
Subject: Re: Actel's FPGA : A54SX32A
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Mon, 05 Mar 2001 01:26:21 GMT
Links: << >>  << T >>  << A >>

"Timothy R. Sloper" <trs@mpinet.net> wrote in message
news:3lxo6.44388$nL5.2679174@news3.aus1.giganews.com...
> I'm an FAE for a distributor of Actel. As Philip stated the devices are
OTP.
> There are no inherent problems with the SX/SXA families but if you want to
> be successful on the first pass (this applies to any vendor/technology)
> budget time for proper simulation.
>
> Tim

Tim,

     Simulation with OTP devices is even more important than with SRAM
based, reprogrammable devices.  This is especially true of higher density
OTP devices involving BGAs, where success on the first pass is paramount.
To get more IO density, BGAs are required, and this is an anathema to OTP
devices, at least in the "first time around" type of design.  I remember
socketing Actel FPGAs many years back, but this is next to impossible with
BGAs and sockets.  Reliability decreases as interconnections increase, and
this means you may be chasing interconnection problems instead of
functiional problems.  I'll be glad when Actel gets the Gatefield line
working.
     Good luck to you in your FAE role.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  32765



Article: 29679
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: Ray Andraka <ray@andraka.com>
Date: Mon, 05 Mar 2001 02:32:12 GMT
Links: << >>  << T >>  << A >>
I'm not as concerned with the second flop going metastable, as I am with making
sure multiple FF's in the state machine see the same value.  If the first FF
went metastable and takes some time to recover, you can end up with a situation
where, depending on relative prop delays, the FF's in the state machine see
different levels even though neither goes metastable.  Again this depends
heavily on your clock period.  My contention is that with a single FF feeding a
state machine, you are likely to be using a global period constraint, so the
routing delay plus the requisite LUT delay ahead of the state machine FFs could
be using up most or all of your available clock cycle leaving very little time
for metastability recovery.  Unless you are floorplanning your sync FF **AND**
the part of the state machine affected by the signal or you provide a timing
constraint for the synchronized signal path that leaves a large enough margin,
you can get yourself into trouble easily.

Rick Filipkiewicz wrote:
> 
> "S. Ramirez" wrote:
> 
> > >Ray,
> >      Sorry for not responding to you sooner.  I see that some others have
> > responded.  I was out in my garage doing a fiberglass layup, and once I
> > start it, I cannot walk away until it is finished!
> >      I'm not sure if we are talking about the same thing, so let me
> > elaborate.
> >      The first flip flop, FF1, I am sure that everyone agrees it will meta
> > when used as a synchronizing flip flop.  There is a certain probability, p1,
> > for a particular FF1 to meta if the input signal changes within the
> > setup/hold time violation window.  There is another probability, p2, of the
> > time that FF1 spends in meta.  As that time increases, p2 decreases.  These
> > two probabilities multiply and give the final probability in a simplisitic
> > form.  If meta exists when FF2 samples FF1's output, then it will also have
> > a probability of meta.  Usually the clock cycle time of the two flip flops
> > is much greater than the time for p2 to be significant, because this cycle
> > time is usually dealing with prop delays that affect register to register
> > performance.  But as well know, a long cycle time does not guarantee that
> > FF2 will not see meta.
> >      I claim that one can make the state machine flip flops the FF2s.  As
> > long as they don't see meta at their setup-hold time window, they will
> > perform as intended.  With the probability of meta being in the range of
> > years, decades, centuries, this is accepted as practice.  If one inserts FF2
> > between FF1 and the state machine flip flops, then FF2 becomes subject to
> > that meta.  It will in turn meta in a hundred years and introduce its own
> > small probability (p1*p2) of affecting the state machine's flip flops.  In
> > other words, inserting FF2 only decreases the probability of causing a
> > problem at the state machine, because the probabilities multiply
> > (p1*p2*p1*p2).  But I claim that multiple flip flops in a state machine can
> > serve as FF2s and work correctly as long as one knows that they will meta
> > some time in the distant future (p1*p2).  Introducing FF2 between FF1 and
> > the state machine has the disadvantage of adding another cycle of delay
> > along with decreasing the probability of the flip flops acting as flop
> > flops.
> >      Usually in a state machine, there are multiple flip flops that will get
> > affected by this low probability of meta.  There are different ways of
> > designing state machines, but I really don't know how to design a state
> > machine where only one flip flop will be affected, or at least I don't
> > design state machines that way.  I usually use one-hot encoding, but this
> > doesn't guarantee that only one flip flop will be affected.  Along with the
> > state encoding bits, there are state output bits that are a function of the
> > present state and the inputs, meta included.  My state output bits are not
> > the state encoding bits, so there are multiple flip flops there seeing the
> > low probability of meta.
> >      I have seen others use FF1 and FF2, but I always questioned why they
> > used it.  We never really came into an agreement that either I was wrong or
> > they were wrong.  If I am wrong, then I am capable of learning things.  But
> > my theories come from two major defense contractors that did some work in
> > this area and standardized their design methodologies using the state
> > machine flip flops as FF2s.  Their design handbook included what I said
> > above as well as other procedures.  An example of one of these procedures
> > is if one is building a nuclear device that is controlled by an electronic
> > circuit, then everything needs to be synchronous, with the exception of a
> > very few and heavily studied signals.  On the other hand, if you are Saddam
> > Hussein working on an asynchronous nuclear device and the U.N. inspectors
> > are scheduled to see you in a week, and you don't have time to convert it to
> > a synchronous design, then you take your chances, run BIST and test it now!
> > Simon Ramirez, Consultant
> > Synchronous Design, Inc.
> > Oviedo, FL  USA
> 
> I agree basically with Simon. What we have for an FF whose input has change has
> violated the su/hld spec is a probability distribution p(t) which give the
> probability that the output will be in a legal state at time t after the clock
> edge. So the calculation is: find the value of t, call it Tok for which this
> probablility is within you acceptable limits. If Tok + routing time + next FF
> setup time is < the clock period then Simon's argument holds. If not then you
> need another FF. The worst case is where the device is sufficiently slow that
> even with a 0 routing time this sum cannot be met. You are then really into
> stats and need a chain of FFs. If Tcyc is the clock period you then need N FFs
> so that p(Tcyc)**N < your acceptable failure level.
> 
> Now the problem becomes one of practicalities: what is p(t) ? Very few
> manufacturers give it - not even Xilinx for the Virtex & Virtex-E. Given this
> lack of information I use a rule of thumb culled from the ASIC world. De-rate
> the Tco of the domain crossing FFs by some multiple, say 6, of the unrouted
> delay. Then set up constraints like this:
> 
> TIMESPEC TSSync = FROM FFS(FF1) TO FFS(*) TCyc - 5*Tco;
> 
> If it won't route to this with FF1 fanning out to many FFs then its time for a
> double level synchoniser.
> 
> If anybody can suggest a better practical rule I'd really love to hear it.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 29680
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: Peter Alfke <palfke@earthlink.net>
Date: Mon, 05 Mar 2001 07:13:23 GMT
Links: << >>  << T >>  << A >>


Jim Granville wrote:

> The 'incoherent' clock/data approach I always feel uneasy about
> - just HOW inchoerent are they, and in the real world they may not be.
> Plus, the 'hit rate' decreases with improving process, as you have
> observed.
>
> I have thought of a way to both measure this, and stimulate metastable
> outputs
> more directly, and in a directly measurable way ( Physical )
>
> Technique :
>  Construct a coarse delay line in Logic
>  Construct a fine delay, by a sliding physical contact on a stripline,
> ideally slid under vernier control.
>
>  Been there, done that 20 years ago at AMD!
> We bought a thing called a trombone, which was just that, an adjustable delay line.
> Never got any meaningful results. And that was with bipolar circuits, notorious for
> their bad metastability behavior.
> So, I am a burnt child.
> If others want to try, be my guest, and, please, keep me informed.
> I'll stick with two external crystal oscillators with uncorrelated frequencies,
> then use the fine phase adjustment in Virtex-II ( 50 ps granularity) to search for
> different MTBFs.
>
> Peter Alfke


Article: 29681
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: Peter Alfke <palfke@earthlink.net>
Date: Mon, 05 Mar 2001 07:19:52 GMT
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

>
>
> I agree basically with Simon. What we have for an FF whose input has change has
> violated the su/hld spec is a probability distribution p(t) which give the
> probability that the output will be in a legal state at time t after the clock
> edge.

I have a problem with this "legal state" expression.
Aside from the crazy oscillations in bipolar circuits, the output is always at a
legal state. Even at an acceptable state, since by definition either a 0 or a 1 is
equally acceptable when you are right at the edge.
The bad thing with a metastable flip-flop is not its logic state, but the fact
that it will ( might ) change this state at a time that you have no control over,
strictly statistically determined.
That's what you have to fight: timing, not right or wrong levels.
There is no right or wrong...

Peter Alfke


Article: 29682
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Mon, 05 Mar 2001 07:25:49 -0000
Links: << >>  << T >>  << A >>
It should be possible to tickle the metastability point with a 
PLL setup too.

I had a convenient board a while ago so I tried it.  It didn't
work.  The PLL I had shifted too fast.  It bounced from one
stable case to the other.  Rock solid.

I was using one of the standard all-included clock buffer PLL
chips.  The chip I had was designed to track spread-spectrum
clocks so it wasn't what I wanted.  (That's a hack for EMI.)

It might be possible to make the right setup with a chip that
needs external filter components.

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


Article: 29683
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: Peter Alfke <palfke@earthlink.net>
Date: Mon, 05 Mar 2001 08:03:24 GMT
Links: << >>  << T >>  << A >>
This is really tricky stuff. That's why I like the randomized
approach. It gave very repeatable results years ago. Let's see what
Virtex-II gives me later this month. We now have an evaluation board
ready with Virtex-II ( the littlest XC2V40 ) Building hundreds of
boards to give to our FAEs...

Peter Alfke, Xilinx Applications ( will be in Europe, this coming week
only )
================
Hal Murray wrote:

> It should be possible to tickle the metastability point with a
> PLL setup too.
>
> I had a convenient board a while ago so I tried it.  It didn't
> work.  The PLL I had shifted too fast.  It bounced from one
> stable case to the other.  Rock solid.
>
> I was using one of the standard all-included clock buffer PLL
> chips.  The chip I had was designed to track spread-spectrum
> clocks so it wasn't what I wanted.  (That's a hack for EMI.)
>
> It might be possible to make the right setup with a chip that
> needs external filter components.
>
> --
> These are my opinions, not necessarily my employeers.  I hate spam.


Article: 29684
Subject: Re: Bad Xilinx bitstream=big bang?
From: Peter Alfke <palfke@earthlink.net>
Date: Mon, 05 Mar 2001 08:06:09 GMT
Links: << >>  << T >>  << A >>
Joel, I am very sorry about your mishap, and I
have inserted my comments in the
appropriate places in your story.
The gist is:
Virtex parts do check for CRC errors, but not for
formatting errors. And you
sent a legitimately CRC-protected file, just the
wrong format... Horrendous
amount of internal contention.

Joel Kolstad wrote:

> We have some PCI cards at work that we recently upgraded -- for both price
> and performance reasons -- to use Xilinx XCV600E parts instead of the XCV400
> parts that the old board used.  We've found out the hard way that Very Bad
> Things happen if you attempt to load the old bitstream for the XCV400 onto
> the XCV600E board.  In particular:
>
> -- <snip>

>
> Now what I want to know is... I had always thought that there was some CRC
> checking in the FPGA bitstream files, and that you could pretty much feed
> the FPGA random gibberish and be very unlikely to actually get the thing to
> accept the bitstream

Correct. If there were a CRC error, the part would
recognize this. But there
was no CRC error...

> and go through power-on initialization.

No, no. power-on initialization is done much
earlier, right after you applied
Vcc. This has nothing to do with CCLK. The parts
use their own internal
oscillator for that purpose.

> In fact, we're
> manually bit-banging the CClk line on the FPGA (we're using serial slave
> mode), so there aren't even enough clock pulses provided to the 600E to make
> it think it should even _consider_ going through power-on initiailization,

see above. It has done this sucessfully long before.

>
> since the 600E requires about two hundred thousand extra bits (and CClks)
> than what the 400 file would provide it with (we stop generating CClk when
> we're out of configuration data bits).
>
> With our current setup it's difficult to probe around on the board and try
> to figure out exactly _when_ the overcurrent condition starts.  Loading the
> 400 file takes a couple of seconds, and the 145W PC will power down within a
> couple of seconds after that.  My suspicion is that the overcurrent
> condition has already started long before we're gotten anywhere near to
> finishing the transmission of the 400's bitstream.

Yes. The internal logic becomes active as you feed
in the data.
( I may stand corrected here. I carry too much
XC4000 bagage in my head, and I
am at home, no access to other experts. But Austin
can jump in, while I am gone
for the coming week. Seminars in Europe)

>
> So... does anybody have any experience with this?  The possibility that
> feeding a 600E a 400 bitstream causes it to draw massive currents seems
> awfully remote to me.

No, it's ugly, but not surprising. The part
considers this a garbage bitstream
, but with legitimate CRC. I know this is not
ideal, but that's the way it is.

> The LT1575/dual FET power supply can put out 2A all
> day long (this was its design goal -- we're dissipating 1.5V*2A=3W or
> 1.5W/FET in this case), I would wager it can put out 4A for many minutes,
> and to physically blow up both FETs I would have to think that it's passing
> at least 10A for a little while.  Strange, very strange.

Not so strange. Consider the very large number of
internal nodes, let's say
over 50,000.
Let's assume that, through nonsense configuration,
10% are driven by contending
levels on both sides of the wire. And let's assume
a realistic 5 mA per
contention: 5000 times 5 mA = 25 A !
This distributed nature of the current also shows
why the Virtex part ( most
likely ?) survived. The current is more or less
evenly spread over the whole
die, which is more than a square centimeter in area.

I am not making excuses, just describe the
phenomenon, which is quite rational,
albeit not desirable.

Ask Austin whether Virtex-II is protected against
this kind of mishap.

Peter Alfke, Xilinx Applications (Friday-night
emergency services)

Article: 29685
Subject: Parallel Port EPP
From: Marc Reinert <reinert@tu-harburg.de>
Date: Mon, 05 Mar 2001 10:11:55 +0100
Links: << >>  << T >>  << A >>
I' like to use a CPLD/FPGA (Xilinx) to receive data from the parallel
port (EPP-mode) of my PC.

Is it a good style to react direct on the edges of the port signals (e.
g. adress/data strobes) or would it be better to use a fast PLD-Clock to
sample the port and then to evaluate the signals in a clocked logic?

Marc



Article: 29686
Subject: Re: Parallel Port EPP
From: V R <alphabetagamma@alphabetagammadeltasigma.com>
Date: Mon, 5 Mar 2001 12:58:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
Marc Reinert <whothehelllikesspam?rei??ne??rt@tu??-h?ar??bu??rg.de> wrote:
> I' like to use a CPLD/FPGA (Xilinx) to receive data from the parallel
> port (EPP-mode) of my PC.

It has been done before. It can fit in a CPLD if your CPLD isn't going to
do too much. I think you'll chew about 5-7 FFs for your state machines and
4-8 FFs for synchronizing(mealy, synchronizing, etc).

> Is it a good style to react direct on the edges of the port signals (e.
> g. adress/data strobes) or would it be better to use a fast PLD-Clock to
> sample the port and then to evaluate the signals in a clocked logic?

I just started a nice long thread on exactly this subject. I think the
unanimous opinion is to use *two* D-flip-flops hooked in series. For the
EPP interface, since you have two strobes, you will have two sets of these
dual flip-flops to synchronize with. 

Use a system clock to synchronize your incoming nAddressActive and
nAddress Strobe through the dual flip-flops(one set of FFs per strobe); it
helps a lot to use this same clock for your statemachine, so do that if
possible.

My design had one statemachine (with two states I think) to recognize the
four-phase portion of the EPP interface, and then other statemachines to
act on the data.

Good luck!
VR.
(the above e-mail address is invalid).

Article: 29687
Subject: URGENT HELP REQ......
From: Ramanathan S <aadityas@MailAndNews.com>
Date: Mon, 5 Mar 2001 09:24:01 -0500
Links: << >>  << T >>  << A >>
Hi friends,

Is it possible to convert a guide file (with a .ncd extension, used by the 
place and route tool) to be converted to another device of the same family ?

Warm regards
rama


Article: 29688
Subject: Re: Metastability
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Mon, 05 Mar 2001 09:54:41 -0500
Links: << >>  << T >>  << A >>
Muzaffer Kal wrote:
> 
> On 04 Mar 2001 00:25:08 +0100, Magnus Homann
> <d0asta@mis.dtek.chalmers.se> wrote:
> 
> >Ray Andraka <ray@andraka.com> writes:
> >
> >[Simons wisdom deleted]
> >
> >> Simon failed to point out that using the state machine as the second
> >> flip flop should only be done if the possibly metastable signal
> >> affects only one flip-flop in the state machine.  If if affects more
> >> than one flip-flop, there is a potential for a metastable event to
> >> be detected as different levels by the multiple flip-flops that
> >> depend on its condition.  Simon, I'm sure this was your intention, I
> >> just wanted to make sure your short response didn't mislead anyone.
> >
> >Really? Hmm, the idea is that FF1 would settle within the cycle
> >time. Now, if it doesn't, does it really matter if one or several of
> >the statemachines FFs wil go into metastability?
> >
> >The idea is that the cycle time will be enough for all metastability
> >to vanish. If it hasn't, is there anything you can do to save your FSM
> >from running amok?
> >
> >Your advice might be god, but probably mostly due to the fact that having
> >only one FF after FF1  usaully reduces the routing delay, and
> >hence increases the available settling time (iff you have the same
> >cycle time in both cases).
> >
> >Comments invited.
> >
> >Homann
> 
> I think that "two FFs" was just a rule of thumb which ensured a
> certain MTBF under certain conditions (which are probably not valid in
> < .25u processes anymore). You can further reduce the probability of
> metastability by adding more FFs. The metastability never vanishes
> completely. There is always a non-zero probability that the metastable
> event will pass through all the FFs. It can be made arbitrarily small
> though. That's where the MTBF comes from.
> 
> Muzaffer

Homann and Muzaffer,

The factor that settles metastability is not FFs, but rather time. The
need for the second FF is a function of the speed of the clock. As
Homann says, using the second FF separates the metastability settling
time from the time used for routing and logic prop delay. So you get the
entire clock cycle for settling. 

If your clock is slow enough, you can put the logic after the first FF
and not worry about it. The slack time in the clock cycle will allow a
metastable state to settle. 

The need to add a second FF comes only with faster clocks. If the clock
speed is trully fast, then you may need to add a third FF just to get
the extra settling time of a second clock cycle. But everything I have
read about the current process technology (mainly Xilinx) indicates that
using two FFs (one clock cycle) works well up to a couple of hundred
MHz. But once you get past a hundred MHz, you might want to get the data
on your part and do the calculations yourself. 


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 29689
Subject: Re: Spartan II power
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Mon, 05 Mar 2001 11:12:46 -0500
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Rick,
> 
> The kick is not intended to be in parallel.  There is no reason that this can not be used
> with a switcher, in fact, that is even better from an efficiency point of view: the micro
> power comparator/reference (is in the tiny package I gave dimensions for) would be used to
> hold off the switcher for the 2.5 Vdc until the cap ahead of it was charged up.  Most
> switchers can be set to integrate the current limiting so they can supply a transient of
> many times what they can supply continuously.
> 
> The LDO is bigger than what I said, but I was assuming it was already there.
> 
> You make an excellent point about the smaller packages: they can't dissipate much power at
> all without glowing in the dark.  I know people want to use them, but cs144, fg256 style
> packages are not really good at getting rid of the heat.  One should always run thru the
> power estimator excrcise -- especially in these thermally challenged packages!
> 
> Austin

Thanks Austin, this makes it much clearer. Holding the regulator in
standby mode and using a large input capacitor is only useful if the
power source to the regulator is not capable of supplying the full
current you need at startup. 

In my application, I expect that the power source to the board will have
ample umpf (that's a technical term I learned in school :). The limiting
factor is the on-board regulator that provides power to all of the
FPGAs. I have a very limited amount of space on the board for this
regulator. I also feel that I need to limit the current to a safe level
to prevent the regulator from overheating in case of a failure on the
board. So providing 2.5 Amps of surge capacity is not easy to do without
compromising one of these requirements. 

I am using a integrated controller for the regulator. It has an external
series sense resistor to limit current. With a value of 0.030 ohms, it
will require a large cap to hold off the current limit while the FPGAs
are starting up. This again uses more space. I will have to take a look
at the regulator data sheet to see what can be done. 


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 29690
Subject: Re: Spartan II power
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Mon, 05 Mar 2001 11:25:02 -0500
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Rick,
> 
> I think you may have misunderstood my comment.  The original thinking was 'Virtex thinking'
> for larger parts -- which breaks down completely for smaller parts!  I agree with you.
> 
> 1 watt for 4 2S15's split between all of the IO's at 3.3 Vdc, and the cores at 2.5 Vdc is a
> real challenge, I admit.  If in the steady state, 1 watt is plenty to operate the four
> parts, that leaves us with the startup issue.
> 
> I admit that for -40C, worst case is 2 amperes (right now, as we don't have enough 2S15
> silicon to characterize the -40C number, so we have to go with what we know from larger
> parts -- it could be less).  The thought of having to supply 8 amperes to start them up at
> 2.5 Vdc is a little (lot) daunting.
> 
> Is there any way to use a larger part, rather than four separate smaller parts?  I suppose
> that isn't a very smart question, as you probably already optimized your system
> architecture, but I have to ask.

Actually, I am glad you asked. Because this is a question you can answer
for me. My design uses the FPGAs as configurable interfaces for IO
modules. My system design allows for runtime identification of the
modules and configuration of the FPGAs to match. This works a little
like Plug and Play (PnP). 

I would love to put all of these designs into a single part to save
board space, chip cost, power and save on procurement and assembly cost.
But to make my system work, I will need supported, partial
reconfiguration. I would need to load a portion of the chip with a main
(static) function, and four modules to match the IO connected to the
board. 

I know that JBITs exists and that it can help me with the task. But I
have not heard anyone say that it is really the solution to this
problem. How close is Xilinx to providing true partial reconfiguration
as part of the main development software? 

 
> Ultimately, one could design an 8 amp peak switcher than would deliver the 8 amps for at
> least 1 ms to get them all started.  If you could tolerate a 500 mV dip in the 3.3 volts
> running the DC to DC switcher, the input capacitor has to be I*dt/dv, or 8 * .001/.5 = 4,000
> uF.  That isn't all that obscene, as 4,700 uF at 6.3 wv is still a pretty small component.
> I would go with 10,000uF as at -40 C the capacitor (if it is the proper one engineered for
> -55C in the data sheet) will have 40% of its room temperature value.  Do not use a standard
> -40C capacitor, as they have 0 capacitance at -40C (really, I measure them all of the time
> to prove this to the disbelievers!).
> 
> The capacitor specifications refer to damage, not operation, and since they are electrolytes
> (i.e. there is water in there), it just makes sense that at really low temperatures they are
> not a capacitor any more.
> 
> I am not recommending staging, or sequencing, but rather hitting them all at the same time.
> Any attempt to mess with the program pin is doomed to failure in Virtex and Spartan II.  As
> I have said, the chip doesn't even know its name yet at 0.7 to 1 V where the pop is needed.
> Any attempt to slow down the ramp is doomed to fail as well.  The 4K parts had decreasing
> current with increasing ramp, and some dependency of current on the pins, but not
> Virtex/Spartan II.
> 
> Ultimately, there may be a better way to solve the problem, as you state, as there are
> always alternatives.
> 
> By the way, the board is almost built.
> 
> Austin



-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 29691
Subject: Re: webpack ISE synthesis fails with exit code: 0002
From: Andy Peters <"apeters <"@> noao [.] edu>
Date: Mon, 05 Mar 2001 10:02:18 -0700
Links: << >>  << T >>  << A >>
Eric Smith wrote:
> 
> I'm trying to use WebPACK ISE to build a microprocessor core model
> using an XC2S200.  I can't get the data path to compile; the synthesizer
> exits with the message:
> 
> Done: failed with exit code: 0002.

Just a guess, 'cause I'm not sure...but does the Webpack stuff support
that particular part?

-a

Article: 29692
Subject: Re: Bad Xilinx bitstream=big bang?
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Mon, 05 Mar 2001 17:31:38 +0000
Links: << >>  << T >>  << A >>
On 03 Mar 2001 15:44:07 -0800, Eric Smith
<eric-no-spam-for-me@brouhaha.com> wrote:

>Peter Alfke <palfke@earthlink.net> writes:
>> The gist is:
>> Virtex parts do check for CRC errors, but not for formatting errors. And you
>> sent a legitimately CRC-protected file, just the wrong format... Horrendous
>> amount of internal contention.
>[...]
>> Correct. If there were a CRC error, the part would recognize this. But there
>> was no CRC error...
>
>Is there some reason why the part doesn't ALSO recognize that the bitstream
>is too short?  I wouldn't think it would expect the CRC until it had filled
>all of the RAM cells.
>
Anything to do with partial reconfiguration maybe?
Like, is it possible to generate a _valid_ short bitstream to reprogram
part of the device but leaving the remainder unchanged?

- Brian

Article: 29693
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 05 Mar 2001 18:55:23 +0100
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:
> 
> Jim Granville wrote:
> 
> > The 'incoherent' clock/data approach I always feel uneasy about
> > - just HOW inchoerent are they, and in the real world they may not be.
> > Plus, the 'hit rate' decreases with improving process, as you have
> > observed.
> >
> > I have thought of a way to both measure this, and stimulate metastable
> > outputs
> > more directly, and in a directly measurable way ( Physical )
> >
> > Technique :
> >  Construct a coarse delay line in Logic
> >  Construct a fine delay, by a sliding physical contact on a stripline,
> > ideally slid under vernier control.

Sounds a little bit ancient ;-))

Why not using a PLL and doing a phase modulation?? This would give VERY
reliable and repeatable results.
And its free of mechanical wearout.

-- 
MFG
Falk

Article: 29694
Subject: Re: webpack ISE synthesis fails with exit code: 0002
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 05 Mar 2001 10:02:27 -0800
Links: << >>  << T >>  << A >>
I wrote:
> I'm trying to use WebPACK ISE to build a microprocessor core model
> using an XC2S200.  I can't get the data path to compile; the synthesizer
> exits with the message:
> 
> Done: failed with exit code: 0002.

Andy Peters <"apeters <"@> noao [.] edu> writes:
> Just a guess, 'cause I'm not sure...but does the Webpack stuff support
> that particular part?

Yes.  That's the only part I have an eval board for, so it's the only
part I've targetted.  The simple LED-flasher design worked fine.

Article: 29695
Subject: Re: Bad Xilinx bitstream=big bang?
From: krw@btv.ibm.com (Keith R. Williams)
Date: Mon, 05 Mar 2001 18:06:41 GMT
Links: << >>  << T >>  << A >>
On Mon, 05 Mar 2001 17:31:38 +0000, Brian Drummond
<brian@shapes.demon.co.uk> wrote:

>On 03 Mar 2001 15:44:07 -0800, Eric Smith
><eric-no-spam-for-me@brouhaha.com> wrote:
>
>>Peter Alfke <palfke@earthlink.net> writes:
>>> The gist is:
>>> Virtex parts do check for CRC errors, but not for formatting errors. And you
>>> sent a legitimately CRC-protected file, just the wrong format... Horrendous
>>> amount of internal contention.
>>[...]
>>> Correct. If there were a CRC error, the part would recognize this. But there
>>> was no CRC error...
>>
>>Is there some reason why the part doesn't ALSO recognize that the bitstream
>>is too short?  I wouldn't think it would expect the CRC until it had filled
>>all of the RAM cells.
>>
>Anything to do with partial reconfiguration maybe?
>Like, is it possible to generate a _valid_ short bitstream to reprogram
>part of the device but leaving the remainder unchanged?

Perhaps you've just stepped on another reason the tools don't support
partial reconfiguration? Two _valid_ short bitstreams may create many
drivers on the same wire.

----
  Keith



Article: 29696
Subject: Re: Bad Xilinx bitstream=big bang?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 05 Mar 2001 10:07:40 -0800
Links: << >>  << T >>  << A >>
I wrote:
> Is there some reason why the part doesn't ALSO recognize that the bitstream
> is too short?  I wouldn't think it would expect the CRC until it had filled
> all of the RAM cells.

Brian Drummond <brian@shapes.demon.co.uk> writes:
> Anything to do with partial reconfiguration maybe?
> Like, is it possible to generate a _valid_ short bitstream to reprogram
> part of the device but leaving the remainder unchanged?

Having looked over the XAPP 176 appnote on configuration and readback of
the Spartan II over the weekend, I now have a better appreciation
for how the config process works.  I think your hypothesis is correct.

I guess the thing that still surprises me is that each size of FPGA
needs a different frame size in the bitstream (table 4 on page 15,
XC2S200 not specified), so the parts should have been able to detect the
wrong frame size, even if they can't detect the wrong total image size.

Article: 29697
Subject: Re: Full Time - No contractors
From: steve (Steve Rencontre)
Date: Mon, 5 Mar 2001 18:45 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <NLto6.31387$68.5690704@typhoon.tampabay.rr.com>, 
sramirez@deletethis.cfl.rr.com (S. Ramirez) wrote:

> "Embedded Head" <chilln@gte.net> wrote in message
> news:OKco6.3179$sC4.237266@paloalto-snr1.gtei.net...
> > Mixed Signal Engineer
> > Will work as a member of our Test Engineering team to design, test and
> > troubleshoot our next generation of test equipment.  We are a rapidly
> > expanding, progressive company with excellent benefits and friendly
> > atmosphere.
> > Qualifications
> > BSEE (required)
> > 2+ years experience in C/C++ and VHDL or  FPGA (required)
> > 2+ years experience with analog hardware (required)
> > Schematic design software experience (required)
> > DSP experience preferred
> > Send or Fax resume to:
> > "Mixed Signal Engineer Web"
> > 3629 Vista Mercado
> > Camarillo, CA 93012
> > FAX:      (805) 383-1838
> > EMAIL:   humanresources@a-m-c.com
> 
> 
> 
>      Your BULLET_P.gif is quite enlightening.

That's why they don't want no smart-arse consultants :-)))

Now, back to learning the company song...

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>


Article: 29698
Subject: Re: Bad Xilinx bitstream=big bang?
From: Mike <none@null.net>
Date: Mon, 5 Mar 2001 11:04:39 -0800
Links: << >>  << T >>  << A >>
In case Austin doesn't want to jump in here, I can say with complete positivity that Virtex-II is protected against this kind of mishap.  Virtex-II has an extra configuration register called the ID register.  Each device in the family has a different ID, and before any "real" configuration data is loaded, this ID register is loaded, and checked against an internal constant.  If it passes, you know for certain you're loading the right kind of bitstream into the right part.  If it fails, INIT will go low and configuration will stop.

Mike
Xilinx Applications

Article: 29699
Subject: ROM-based FSM implementation
From: vkode77@hotmail.com
Date: 5 Mar 2001 19:50:49 GMT
Links: << >>  << T >>  << A >>

Can anyone please post a VHDL implementation of a ROM-based FSM
implementation,or point me to links on the web where I might get some help. I
Have the Block Diagram, but I am having trouble realizing that in VHDL.

Thanks in Advance


 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net



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