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

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

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

Custom Search

Messages from 104875

Article: 104875
Subject: Re: Chaos in FF metastability
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 08 Jul 2006 08:24:53 +1200
Links: << >>  << T >>  << A >>
rickman wrote:
> I don't know what is so different about the TTL FF because no one has
> explained why it is soooo "bad".

My Philips 74AHC1G79 data shows the internal circuit, of a modern CMOS 
FF (no reset). Philips 74AUP1G175 shows a variant with RESET.
My Fairchild 74AC74 datasheet, shows an older FF (TTL style) with 10 
nand gates.
-jg


Article: 104876
Subject: Re: Chaos in FF metastability
From: "Marc Reinig" <Marco@newsgroups.nospam>
Date: Fri, 7 Jul 2006 14:15:52 -0700
Links: << >>  << T >>  << A >>
Diagrams in data sheets are almost always meant to give a logical 
understanding of how the device functions, not an exact indication of how it 
is built or works.

Marco
________________________
Marc Reinig
UCO/Lick Observatory
Laboratory for Adaptive Optics

"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
news:44aec339$1@clear.net.nz...
> rickman wrote:
>> I don't know what is so different about the TTL FF because no one has
>> explained why it is soooo "bad".
>
> My Philips 74AHC1G79 data shows the internal circuit, of a modern CMOS FF 
> (no reset). Philips 74AUP1G175 shows a variant with RESET.
> My Fairchild 74AC74 datasheet, shows an older FF (TTL style) with 10 nand 
> gates.
> -jg
> 



Article: 104877
Subject: Re: Chaos in FF metastability
From: "Peter Alfke" <peter@xilinx.com>
Date: 7 Jul 2006 14:26:02 -0700
Links: << >>  << T >>  << A >>
Thanks Jim.
The CMOS design is really as simple as shown, each inverter-triangle
really consisting of 2 transistors, and the square transfer gate being
a single transistor.
Each of the many NAND gates in TTL, however, is each a complex
multi-transistor structure.
No wonder is has enough loop time to oscillate.

Nostalgia:
The 7474 dual flip-flop stems from 1969. Its improved brother, the
Fairchild 9024, was introduced a few weeks before I joined Fairchild in
CA in the summer of 1969, as part of the seemingly insane program to
introduce one new IC per week on a double-page spread in EETimes. We
continued for a whole year, even when it sometimes became a mad
scramble. Those were the days before the straight-laced types from
Motorola took over the company, and before the French then ruined it
"for good". Then NSC took over, and now Fairchild is re-born.
7474 in 2006, is this a fast-paced industry?...
Peter Alfke

Jim Granville wrote:
> rickman wrote:
> > I don't know what is so different about the TTL FF because no one has
> > explained why it is soooo "bad".
>
> My Philips 74AHC1G79 data shows the internal circuit, of a modern CMOS
> FF (no reset). Philips 74AUP1G175 shows a variant with RESET.
> My Fairchild 74AC74 datasheet, shows an older FF (TTL style) with 10
> nand gates.
> -jg


Article: 104878
Subject: Re: Chaos in FF metastability
From: "Peter Alfke" <peter@xilinx.com>
Date: 7 Jul 2006 14:35:44 -0700
Links: << >>  << T >>  << A >>
Marco, not at the simple level we are talking about here.
Lying about the physical structure, or using sophisticated abstractions
at these low levels, would become self-defeating. Remember, those
schematics are there to minimize support questions...
I remember explaining "ones-catching flip-flops" in those days..
Peter Alfke

==========
Marc Reinig wrote:
> Diagrams in data sheets are almost always meant to give a logical
> understanding of how the device functions, not an exact indication of how it
> is built or works.
> 
> Marco
>


Article: 104879
Subject: Re: Chaos in FF metastability
From: mk <kal*@dspia.*comdelete>
Date: Fri, 07 Jul 2006 21:53:25 GMT
Links: << >>  << T >>  << A >>
On 7 Jul 2006 14:26:02 -0700, "Peter Alfke" <peter@xilinx.com> wrote:

>the square transfer gate being a single transistor.

Are you sure ? Then why would you need the complement input ? I think
they are also made from two transistors but horizontally connected ie
shorted drains are input, shorted sources are output and gates get the
normal & complement of the control signal, no?

Article: 104880
Subject: Re: Chaos in FF metastability
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 07 Jul 2006 22:57:18 +0100
Links: << >>  << T >>  << A >>
On 7 Jul 2006 14:26:02 -0700, Peter Alfke <peter@xilinx.com> wrote:

>The CMOS design is really as simple as shown, each inverter-triangle
>really consisting of 2 transistors, and the square transfer gate being
>a single transistor.
>Each of the many NAND gates in TTL, however, is each a complex
>multi-transistor structure.
>No wonder is has enough loop time to oscillate.

See Daniel Lang's nice response to a query of mine earlier
in this thread, confirming my understanding that a loop of
2 CMOS inverters is pretty certain to be non-oscillatory.

>Nostalgia:
>The 7474 dual flip-flop stems from 1969. Its improved brother, the
>Fairchild 9024, was introduced a few weeks before I joined Fairchild in
>CA in the summer of 1969

Is that the same as the ??? 74xx9024 so-called "metastable-immune"
DFFs that Philips/Signetics introduced a decade or so later?  As
I recall, the Philips parts traded slower Tcq for a guarantee of
monotonic behaviour (not, of course, freedom from metastability).

> 7474 in 2006, is this a fast-paced industry?...

Well, I've certainly got a couple of tubes of 74F74s in the attic,
and I can probably find some vanilla 7474s if I look hard enough...
One day I must get around to throwing all those antiques in the
dumpster, but it's hard to part company with your own history.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 104881
Subject: Re: DDR Controller problems
From: "PeterSmith1954@googlemail.com" <PeterSmith1954@googlemail.com>
Date: 7 Jul 2006 15:13:22 -0700
Links: << >>  << T >>  << A >>
David wrote:
> Hi Peter, Nico, Saumyajit,
>
> Thanks for your replies. I was initially trying to use 100 MHz and I've tried slowing the OPB bus down to 66MHz - which EDK says is as slow as the Micron chip will go - but it still freezes on the memory test. The solder joints look fine to me but I'm just a Masters student - not exactly an expert!
>
> I checked the initialisation and found that it wasn't waiting 200 cycles after setting the mode register the second time so I fixed that but it had no effect. I checked the precharge - the period met the specifications - 7.8us. I haven't been able to check the clock relative to the commands as I only have a 100MHz scope - I can see that the signals are going up and down in roughly the right places but the time resolution is pretty lousy - I'm working on getting access to a better logic analyser.
>
> While I was checking the UCF for the pin configurations I noticed that in the mapper report I was getting this:
>
> | data<0> | IOB | BIDIR | SSTL2_I | | | OUTDDR | | | | | | | | ENFF2 |
>
> when according to the readme I should be getting this:
>
> | data<0> | IOB | BIDIR | SSTL2_I | | | INFF1 | | | | | | | INFF2 | | | | | | | OUTDDR | | | | | | | ENFF2 What do I need to set to get it to use the INFFs? (They aren't being used on the input pins either)
>
> Thanks again,
>
> David

In your mapper report, you are missing the IN FF [x] reports. This
might mean (I am no expert on these tools, although I use them... ;) ]
that the read functtionality is not being generated and has been
optimised out. That would certainly explain what you are seeing.

Did the compiler (synthesiser)  report have any such warnings? (Note
they may be buried in the noise on such a compile)

Cheers

PeteS


Article: 104882
Subject: Re: How much time does it need to sort 1 million random 64-bit/32-bit integers?
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 7 Jul 2006 16:28:34 -0700
Links: << >>  << T >>  << A >>
Hi,
I received a google warning message on key word "fastest sorting
algorithm" this afternoon.

The following is one of its message addresses:
http://groups.google.com/group/rec.games.programmer/browse_thread/thread/89b0b172e3772006/78ac42b8a1c00578?q=fastest+sorting+algorithm&rnum=8#78ac42b8a1c00578


"Why? It only takes that run to disprove your assertion.
You claimed that the radix sort is the fastest algorithm, this example
disproves that.

10 elements, qsort: ~2500 clocks, bucket: ~37500 clocks.

FYI, with 1000 values, the times were: ~275000 for bucket, ~435000 for
qsort."

Unit is in clocks, it is easier for everyone to compare different
sorting algorithms and I have a good taste on how fast a sorting
algorithm runs.

The message was in 1998, but it is still valid in the order. 

Weng


Article: 104883
Subject: Re: debouncing a switch (in hardware)
From: "Rob" <robnstef@frontiernet.net>
Date: Sat, 08 Jul 2006 03:33:52 GMT
Links: << >>  << T >>  << A >>
Jim,

Have you tried ALPS?  http://www3.alps.co.jp/alpscom/

I haven't looked to see if they carry what you want; but their name 
immediately came to mind upon hearing your request.

Rob


"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
news:44ade255@clear.net.nz...
> Bob Perlman wrote:
>> Hi - Jack Ganssle has written extensively about this.  Here's a paper 
>> that
>> summarizes his findings and design suggestions:
>>
>> http://www.ganssle.com/debouncing.pdf
>
>  On this general subject, does anyone know of a LOW PROFILE microswitch
> action ( SPCO / SPDT ) switch ?
>  There are std microswitches, which tend to have a high profile, and
> couple of old ITT style snap switches, also ~10mm high, but nothing I have 
> found is close to a tact button, with SPCO ?
>
> -jg
> 



Article: 104884
Subject: Timing Error in edk 7.1i
From: "savs" <vidyutg@gmail.com>
Date: 8 Jul 2006 02:51:56 -0700
Links: << >>  << T >>  << A >>
hi all,
we are getting the following timing error...........the timing analyser
does not show any error ......

Asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.

--------------------------------------------------------------------------------
Constraint                                | Requested  | Actual     |
Logic
|            |            | Levels
--------------------------------------------------------------------------------
* TSCLK2CLK90_DDR_SDRAM_64Mx32 = MAXDELAY F | 2.500ns    | 2.543ns    |
1
ROM TIMEGRP         "OPB_Clk_DDR_SDRAM_64 |            |            |

Mx32" TO TIMEGRP         "Device_Clk90_in |            |            |

_DDR_SDRAM_64Mx32" 2.5 ns                 |            |            |

--------------------------------------------------------------------------------
TS_sys_clk_pin = PERIOD TIMEGRP "sys_clk_ | N/A        | N/A        |
N/A
pin" 10 ns HIGH 50%                       |            |            |

--------------------------------------------------------------------------------
TS_dcm_0_dcm_0_CLK0_BUF = PERIOD TIMEGRP  | 10.000ns   | 9.966ns    |
10
"dcm_0_dcm_0_CLK0_BUF" TS_sys_clk_pin     |            |            |

HIGH 50%                             |            |            |
--------------------------------------------------------------------------------
TS_dcm_0_dcm_0_CLK90_BUF = PERIOD TIMEGRP | 10.000ns   | 6.628ns    | 1

"dcm_0_dcm_0_CLK90_BUF"         TS_sys_c |            |            |

lk_pin PHASE 2.5 ns HIGH 50%              |            |            |

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


1 constraint not met.
INFO:Timing:2761 - N/A entries in the Constraints list may indicate
that the
constraint does not cover any paths or that it has no requested value.
Generating Pad Report.

All signals are completely routed.

Total REAL time to PAR completion: 12 mins 21 secs
Total CPU time to PAR completion: 11 mins 45 secs

Peak Memory Usage:  216 MB

Placement: Completed - No errors found.
Routing: Completed - No errors found.
Timing: Completed - 4 errors found.

thanx........


Article: 104885
Subject: Re: Fastest platform to run ISE?
From: "Alex Gibson" <news@alxx.org>
Date: Sat, 8 Jul 2006 19:52:03 +1000
Links: << >>  << T >>  << A >>

"JJ" <johnjakson@gmail.com> wrote in message 
news:1152230132.748774.228660@k73g2000cwa.googlegroups.com...
> Toms HW recently did a review on the DualCore D805 (around $150 or
> less) which can be highly overclockable from 2.6Ghz with stock fan to
> 3.6Ghz with Zalman cooler and even 4.1GHz with water cooling which was
> then able to beat out the >$1K Extreme edition 965 and the AMD Athlon
> 64 FX-60 on gaming benchmarks. That article lead to a good run of sales
> for that chip.
>
> http://www.tomshardware.com/2006/05/10/dual_41_ghz_cores/
> http://www.tomshardware.com/2006/06/12/your_diy_gaming_rig_for_720/
>
> Intel locked out cpu overclocking, but left in FSB modding. Nominal
> power is 90W, but at 4.1GHz it went to 200W, takes some nerve to try
> that.

But is it worth risking over clocking on this sort of work load ?

How do you know you are not getting errors in the generated bitstream ?
How do you know  what errors (if any) get introduced as the cpu is running 
out of spec?

Maybe fine overclocking your own home machine for gaming or whatever but not
a work machine.


Alex 



Article: 104886
Subject: Re: Can I use all 18bits of a BlockRAM?
From: "Jan Hansen" <someone@microsoft.com>
Date: Sat, 8 Jul 2006 12:58:14 +0200
Links: << >>  << T >>  << A >>

"Ray Andraka" <ray@andraka.com> wrote in message
news:vlUqg.62411$ZW3.52247@dukeread04...
> PeterSmith1954@googlemail.com wrote:
>
>
> >
> > The last time I used *9 / *18 / *36 mode block rams, I instantiated
> > them as such and they exposed themselves as those *8 + the parity bit.
> > Look for the instantiation template and you'll see what I mean.
> >
> > Just assign your ninth bit (for each block ram) to the parity bit.
> >
> > Cheers
> >
> > PeteS
> >
> The primitives have the bits separated off as parity bits, but other
> than the addressing considerations if you have different depths on the
> dual ports, they are no different than the data bits.  It may be easier
> to deal with if you make a wrapper for the Xilinx primitives that bring
> in/out an 18 bit bus.

I belive the parity bits is physically located as the MSB's. In a 18 bit
RAM-config, the "left-hand-bit" is the parity bit for the left-hand byte,
and the second bit on the left is the parity bit for the right-hand byte.
But you can use all  bits as ordinary data-bits if you wish, as others have
mentioned before.



Article: 104887
Subject: Re: Fastest platform to run ISE?
From: "Jan Hansen" <someone@microsoft.com>
Date: Sat, 8 Jul 2006 13:12:43 +0200
Links: << >>  << T >>  << A >>
I have switched from an Intel Pentium 4 1.4 Ghz  0.5 GB RAM to an AMD Athlon
64 dual core 2 GHz 2GB RAM, and processing  time for my project vent down
from about 17 min  to about 4 min.....! And it lookes like ISE utillises
both cores, according to task manager the load are about 50% om each core
during processing...that leaves enough proc. power to read the news without
degrading XST performance. Multiple cores is the future  !

"MM" <mbmsv@yahoo.com> wrote in message
news:4h5aaoF1ocjtaU1@individual.net...
> Hi all,
>
> I was wondering which PC upgrades can make ISE to run faster? For example,
> can it take advantage of dual CPU, and/or dual-core Xeon, etc.? I am
> currently running at 2.6 GHz P4 with HT, 2GB 400MHz RAM, 800FSB  and it is
> too slow...
>
>
> Thanks,
> /Mikhail
>
>



Article: 104888
Subject: Re: Fastest platform to run ISE?
From: "Leon" <leon.heller@bulldoghome.com>
Date: 8 Jul 2006 05:48:31 -0700
Links: << >>  << T >>  << A >>

MM wrote:
> Hi all,
>
> I was wondering which PC upgrades can make ISE to run faster? For example,
> can it take advantage of dual CPU, and/or dual-core Xeon, etc.? I am
> currently running at 2.6 GHz P4 with HT, 2GB 400MHz RAM, 800FSB  and it is
> too slow...

I'm using a dual-core Athlon 64 3400 with 1 Gb RAM (WinXP Home). It's
*very* fast running WebPack on all the designs I've tried it on,
although I haven't tried it on anything really big. The system wasn't
expensive, my local computer shop built it to my requirements.

Leon


Article: 104889
Subject: Re: Fastest platform to run ISE?
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 08 Jul 2006 13:13:33 GMT
Links: << >>  << T >>  << A >>
"MM" <mbmsv@yahoo.com> wrote:

>Hi all,
>
>I was wondering which PC upgrades can make ISE to run faster? For example,
>can it take advantage of dual CPU, and/or dual-core Xeon, etc.? I am
>currently running at 2.6 GHz P4 with HT, 2GB 400MHz RAM, 800FSB  and it is
>too slow...

Getting the constraints right and reducing the clock speed for parts
that don't need high speed clocks works much better to get a design
routed fast.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 104890
Subject: Re: Chaos in FF metastability
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 8 Jul 2006 08:08:46 -0700
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> On 7 Jul 2006 14:26:02 -0700, Peter Alfke <peter@xilinx.com> wrote:
>
> >The CMOS design is really as simple as shown, each inverter-triangle
> >really consisting of 2 transistors, and the square transfer gate being
> >a single transistor.
> >Each of the many NAND gates in TTL, however, is each a complex
> >multi-transistor structure.
> >No wonder is has enough loop time to oscillate.
>
> See Daniel Lang's nice response to a query of mine earlier
> in this thread, confirming my understanding that a loop of
> 2 CMOS inverters is pretty certain to be non-oscillatory.

I don't agree with his analysis or at least his wording.

"2 gain stages with single pole RC roll-off will have a maximum
additional phase shift of -180 degrees."

The maximum RC phase shift of 180 degrees will occur with high
frequency which will also be attenuated and likely reduce the gain
below unity.  But that ignores the phase shift from the delay in the
transitors themselves.  However, if it is known that the RC is large
enough compared to the transistor delay, then at the frequencies that
would have 360 phase shift, the gain will be below unity.  In essense
the RC acts as a low pass filter and makes the loop stable.  The cost,
of course, is slower FFs since the RC is in the loop and must be
settled before the clock goes away.  So the CMOS FF may not oscillate
when driven to metastability, but the setup time is longer because of
this stability.


Article: 104891
Subject: Re: Chaos in FF metastability
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 8 Jul 2006 08:46:33 -0700
Links: << >>  << T >>  << A >>
Rickman, it seems to me that you do agree with the analysis and the
wording. But you point out that the price for monotonicity might be a
longer recovery time.
Longer than what? As I measured, the recovery time is usually 1 or 2
ns, seldom 3 ns.
We did not slow it down deliberately, it just "came naturally". The
pass transistor circuit is slower than the inverter. There was nothing
we could or wanted to do about that.

Instability is often the price for high agility. There are fighter
planes that are inherently unstable and cannot be kept under control by
the pilot. A computer is needed. But they are very agile, which is what
the military wanted...

Peter Alfke
========================
rickman wrote:
> Jonathan Bromley wrote:
> > On 7 Jul 2006 14:26:02 -0700, Peter Alfke <peter@xilinx.com> wrote:
> >
> > >The CMOS design is really as simple as shown, each inverter-triangle
> > >really consisting of 2 transistors, and the square transfer gate being
> > >a single transistor.
> > >Each of the many NAND gates in TTL, however, is each a complex
> > >multi-transistor structure.
> > >No wonder is has enough loop time to oscillate.
> >
> > See Daniel Lang's nice response to a query of mine earlier
> > in this thread, confirming my understanding that a loop of
> > 2 CMOS inverters is pretty certain to be non-oscillatory.
>
> I don't agree with his analysis or at least his wording.
>
> "2 gain stages with single pole RC roll-off will have a maximum
> additional phase shift of -180 degrees."
>
> The maximum RC phase shift of 180 degrees will occur with high
> frequency which will also be attenuated and likely reduce the gain
> below unity.  But that ignores the phase shift from the delay in the
> transitors themselves.  However, if it is known that the RC is large
> enough compared to the transistor delay, then at the frequencies that
> would have 360 phase shift, the gain will be below unity.  In essense
> the RC acts as a low pass filter and makes the loop stable.  The cost,
> of course, is slower FFs since the RC is in the loop and must be
> settled before the clock goes away.  So the CMOS FF may not oscillate
> when driven to metastability, but the setup time is longer because of
> this stability.


Article: 104892
Subject: Re: Chaos in FF metastability
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 08 Jul 2006 18:48:05 +0200
Links: << >>  << T >>  << A >>
rickman schrieb:
> Jonathan Bromley wrote:
> But that ignores the phase shift from the delay in the
> transitors themselves.  However, if it is known that the RC is large
> enough compared to the transistor delay, then at the frequencies that
> would have 360 phase shift, the gain will be below unity.  
Hmm. What is a transistor delay?
The CMOS Level-0 model for contains no delay, and I do not see were a
delay above a picosecond should come from in higher level models.

What you have is internal capacitances that add to the output
capacitance. You stay with your first order RC filter with just a little
bit higher C.
And by the way, all the RC delays you mentioned actually are IC delays
most of the time.

Kolja Sulimma




Article: 104893
Subject: Re: Chaos in FF metastability
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 8 Jul 2006 10:00:46 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Rickman, it seems to me that you do agree with the analysis and the
> wording. But you point out that the price for monotonicity might be a
> longer recovery time.

No, I disagree with his wording which I expect was somewhat less than
precise.

"2 gain stages with single pole RC roll-off will have a maximum
additional phase shift of -180 degrees."

This is saying that the entire loop has a maximum phase shift of 180
degrees and so can not oscillate.  But that is not accurate.  The phase
delay depends on the frequency and is made up of two components.  One
component is the total delay of the two RC circuits which is less than
180 degrees, highest at high freq and lowest at low freq.  The other
component is the time delay through the inverters.  The sum of the two
*will* reach 360 degrees at higher frequencies.  So one criteria for
oscillation is met.  The other criteria is unity gain.  If, and only
if, the RC component has an attenuation greater than the gain of the
inverters will the gain be less than unity at the frequency of 360
degree phase shift.

The analysis was not complete as written.  But obviously the result is
that the RC is "dominant" as you say and keeps the circuit in a stable
region.

> Longer than what? As I measured, the recovery time is usually 1 or 2
> ns, seldom 3 ns.
> We did not slow it down deliberately, it just "came naturally". The
> pass transistor circuit is slower than the inverter. There was nothing
> we could or wanted to do about that.

I didn't say anyone "slowed" it down.  But this circuit is slower than
a similar circuit that does not use pass transistors.  A pair of NAND
gates will do the same job and should be faster since the RC is much
smaller.  Or you can even build a circuit with just the two inverters
and use a lower resistance driver to overdrive the inverters to set the
latch.  But there are also parameters in the circuit you have described
that can be varied such as the size of the pass transistor which will
vary its resistance and the speed.

> Instability is often the price for high agility. There are fighter
> planes that are inherently unstable and cannot be kept under control by
> the pilot. A computer is needed. But they are very agile, which is what
> the military wanted...

Exactly!  I thought of this analogy also.  There are many tradeoffs in
circuit design and this is one of them.  I don't actually see the
concern with oscillation.  If the circuit is metastable, why is a
momentary oscillation more of a problem than just a delayed output
transition?  Either way the circuit will be corrupt.


Article: 104894
Subject: Re: Chaos in FF metastability
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 8 Jul 2006 10:06:05 -0700
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:
> rickman schrieb:
> > Jonathan Bromley wrote:
> > But that ignores the phase shift from the delay in the
> > transitors themselves.  However, if it is known that the RC is large
> > enough compared to the transistor delay, then at the frequencies that
> > would have 360 phase shift, the gain will be below unity.
> Hmm. What is a transistor delay?
> The CMOS Level-0 model for contains no delay, and I do not see were a
> delay above a picosecond should come from in higher level models.
>
> What you have is internal capacitances that add to the output
> capacitance. You stay with your first order RC filter with just a little
> bit higher C.
> And by the way, all the RC delays you mentioned actually are IC delays
> most of the time.

I don't know where you get your models, but there are transport delays
in all transistors.  That is the stated reason that P-channel FETs are
slower than N-channel FETs, or so I have read.  The mobility of holes
is lower than electrons, so N-channel FETs have lower delay.

Not everything that happens inside a transistor comes from R, C and L
effects.


Article: 104895
Subject: Re: Fastest platform to run ISE?
From: "JJ" <johnjakson@gmail.com>
Date: 8 Jul 2006 12:32:39 -0700
Links: << >>  << T >>  << A >>

Alex Gibson wrote:
> "JJ" <johnjakson@gmail.com> wrote in message
> news:1152230132.748774.228660@k73g2000cwa.googlegroups.com...
> > Toms HW recently did a review on the DualCore D805 (around $150 or
> > less) which can be highly overclockable from 2.6Ghz with stock fan to
> > 3.6Ghz with Zalman cooler and even 4.1GHz with water cooling which was
> > then able to beat out the >$1K Extreme edition 965 and the AMD Athlon
> > 64 FX-60 on gaming benchmarks. That article lead to a good run of sales
> > for that chip.
> >
> > http://www.tomshardware.com/2006/05/10/dual_41_ghz_cores/
> > http://www.tomshardware.com/2006/06/12/your_diy_gaming_rig_for_720/
> >
> > Intel locked out cpu overclocking, but left in FSB modding. Nominal
> > power is 90W, but at 4.1GHz it went to 200W, takes some nerve to try
> > that.
>
> But is it worth risking over clocking on this sort of work load ?

Depends, these days a cpu lasts what 18 months before a replacement
cycle esp in high end engineering. If you "Burn" a cpu by overclocking
you possibly reduce the full unused lifetime from several years down a
bit, but still it should easily make it through the first 18 months.

>
> How do you know you are not getting errors in the generated bitstream ?
> How do you know  what errors (if any) get introduced as the cpu is running
> out of spec?
>

One can always diff the files for test cases compiled on a slow normal
and overclocked cpu. assuming 2 different cpus should create the exact
same bitfile for same setup.

Actually it isn't really running out of spec. If you read the 1st
article (it was a very long article though 40+ never ending pages) you
would see that most of the cores for these Intel Duo core cpus are very
similar and have some varying margin. Intel has to sell the same basic
design at different price points so for some families they fix the
clock multiplier to prevent cheapskates from overclocking while selling
the same basic design in the Extreme edition with a few more options.
The article explains exactly why the FSB can be so easily overclocked,
it starts off at 133MHz instead of 200MHz or 266Mhz in the higher
priced parts. The multiplier seems to be in fractions with 7 or 8 steps
to double it to the top of the line case. As long as the DDR ram is
also 533MHz. To get past the Zalman cooler at 3.6Ghz, they rigged the
voltage as well as water cooled, thats way past my comfort level.

I wouldn't ever recommend overclocking on a part that has no margins
such as top of the line chips. Overclocking has always been done on
parts that were marketed as low end chips that were much closer to high
end chips than Intel let on, although the cache might be smaller in
that case. Some of the first Celerons were classic overclockers.

> Maybe fine overclocking your own home machine for gaming or whatever but not
> a work machine.
>
>
> Alex

Ordinarily I'd agree with that, I would rather have quiet than turbo
jet so I haven't done this yet. In an office situation, I wouldn't
recomend water cooling under most peoples desks, but a shared server
machine with half the compute time might be tempting.

If a cheap solution can actually blow past the top of the line Intel or
AMD models which have no further room, I am open. The benchmarks
although gaming related, suggest upto 2x the performance with the water
rig, which is much better than the raw 2.66 to 4.1 suggests. The
performance is coming from the FSB speedup. That might well follow for
FPGA jobs as well. I wonder if we will ever know.

John Jakson


Article: 104896
Subject: Re: Can I use all 18bits of a BlockRAM?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 8 Jul 2006 14:13:03 -0700
Links: << >>  << T >>  << A >>
I wish we had never called them "parity bits". They are just extra bits
(above the traditional power of two) that can be used for anything.
Parity is just one of the popular applications, nothing more..
Peter Alfke

Jan Hansen wrote:
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:vlUqg.62411$ZW3.52247@dukeread04...
> > PeterSmith1954@googlemail.com wrote:
> >
> >
> > >
> > > The last time I used *9 / *18 / *36 mode block rams, I instantiated
> > > them as such and they exposed themselves as those *8 + the parity bit.
> > > Look for the instantiation template and you'll see what I mean.
> > >
> > > Just assign your ninth bit (for each block ram) to the parity bit.
> > >
> > > Cheers
> > >
> > > PeteS
> > >
> > The primitives have the bits separated off as parity bits, but other
> > than the addressing considerations if you have different depths on the
> > dual ports, they are no different than the data bits.  It may be easier
> > to deal with if you make a wrapper for the Xilinx primitives that bring
> > in/out an 18 bit bus.
>
> I belive the parity bits is physically located as the MSB's. In a 18 bit
> RAM-config, the "left-hand-bit" is the parity bit for the left-hand byte,
> and the second bit on the left is the parity bit for the right-hand byte.
> But you can use all  bits as ordinary data-bits if you wish, as others have
> mentioned before.


Article: 104897
Subject: Xilinx Xcell Journal received damaged
From: gavin@allegro.com (Gavin Scott)
Date: Sat, 08 Jul 2006 21:36:22 -0000
Links: << >>  << T >>  << A >>
So I've been on the mailing list for Xilinx's Xcell Journal glossy 
magazine for a year or two now, and something I've noticed is that
EVERY issue I've received is trashed to one degree or another.  The
covers are torn, the corners crushed or completely folded over, etc.

After 4-5 issues I'm starting to get suspicious that Xilinx has a
problem with their mailing house rather than that I've just had 
really bad luck or the postal service is run by Altera or something.

Issue 57 showed up in the last couple weeks, and while attempting to
browse through it (something made difficult by several parts of the
cover missing, the lower right corner folded over, and the bottom and
right middle edges smashed in), I notice that on what's left of the
"Letter from the Publisher" page, the post office has applied a large
red stamp mark that reads "Received in damaged condition".  This 
suggests to me that the problem happened before the magazine reached
the post office.

So, I thought I would come and ask if this is just me that's gotten
unlucky or whether other people are having similar issues (pun not
intended, well, ok, maybe a little).

G.

Article: 104898
Subject: Re: Chaos in FF metastability
From: Austin Lesea <austin@xilinx.com>
Date: Sat, 08 Jul 2006 15:03:16 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> Kolja Sulimma wrote:
> 
>>rickman schrieb:
>>
>>>Jonathan Bromley wrote:
>>>But that ignores the phase shift from the delay in the
>>>transitors themselves.  However, if it is known that the RC is large
>>>enough compared to the transistor delay, then at the frequencies that
>>>would have 360 phase shift, the gain will be below unity.
>>
>>Hmm. What is a transistor delay?
>>The CMOS Level-0 model for contains no delay, and I do not see were a
>>delay above a picosecond should come from in higher level models.
>>
>>What you have is internal capacitances that add to the output
>>capacitance. You stay with your first order RC filter with just a little
>>bit higher C.
>>And by the way, all the RC delays you mentioned actually are IC delays
>>most of the time.
> 
> 
> I don't know where you get your models, but there are transport delays
> in all transistors.  That is the stated reason that P-channel FETs are
> slower than N-channel FETs, or so I have read.  The mobility of holes
> is lower than electrons, so N-channel FETs have lower delay.
> 
> Not everything that happens inside a transistor comes from R, C and L
> effects.
> 

Rick,

Agreed.  So far everything you have said on this topic is 100% correct.

Austin

Article: 104899
Subject: Re: component instantiation ISE7.1
From: "gary" <rgarik@yahoo.com>
Date: Sat, 08 Jul 2006 18:02:41 -0500
Links: << >>  << T >>  << A >>
>Gary,
>
>It seems you are thinking as if you were writing software. VHDL is a
>hardware description language. You need to understand what hardware you
are
>trying to create. You have a separate write and read processes, which
>essentially describe behaviour of a bunch (because you have more than a
>single bit) of D flip-flops. The write process describes what is applied
to
>the D input and the read process what happens to the Q output. Thus,
when
>you see slv_reg in the write process on the left side of the assignment
it
>represents the D-input of the flip-flop, while when you see it on the
right
>side in the read process it represents the Q output of the same
flip-flop,
>i.e. stored content of the register.
>
>/Mikhail
>
>
>
>
>
>
>
>"gary" <rgarik@yahoo.com> wrote in message
>news:3LWdnRqUwL34_zHZnZ2dneKdnZydnZ2d@giganews.com...
>> >Gary,
>> >
>> >h doesn't have a source in your code. You need to add something like
>> this:
>> >h <= slv_reg0;
>> >Or just use slv_reg0 instead of h as input to your inverter and in
the
>> read
>> >process.
>> >
>> >/Mikhail
>> >hey,
>>       In user_ip.vhd file i used the following instantation in user
logic
>> implementation
>>  h<=slv_reg0;
>>  k<=slv_reg1;
>> again synthesis is going on well but the same errors what i posted in
my
>> first message are coming again.
>>
>> And in the second method i disabled h & k signals directly i assigned
>> portmap(slv_reg0,slv_reg1) in following way
>> ------------
>> component inverter
>> port( s : in std_logic_vector(0 to 31);
>>            t : out std_logic_vector(0 to 31));
>>  end component;
>>
>>    ---attribute box_type : string;
>>     --attribute box_type of inverter : component is "black_box";
>>
>> begin
>>
>> we: inverter
>>   port map(slv_reg0,slv_reg1);
>> ----------------------------
>> while synthesis following errors are generated....
>>
>> ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
<slv_reg1<9>>
>> Sources are:
>>    Output signal of OBUF instance <we/t_9_OBUF>
>>    Output signal of FDRE instance <slv_reg1_9>
>>
>> ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
>> <slv_reg1<13>>
>> Sources are:
>>    Output signal of OBUF instance <we/t_13_OBUF>
>>    Output signal of FDRE instance <slv_reg1_13>
>>
>> ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
>> <slv_reg1<21>>
>> Sources are:
>>    Output signal of OBUF instance <we/t_21_OBUF>
>>    Output signal of FDRE instance <slv_reg1_21>
>>
>> ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
>> <slv_reg1<27>>
>> Sources are:
>>    Output signal of OBUF instance <we/t_27_OBUF>
>>    Output signal of FDRE instance <slv_reg1_27>
>> ----------------for all 0 to 31----------------------------
>> /gary
>>
>>hi mikhael,
             sorry iam a beginner, thanks for ur information.In my
user_ip.vhd there are 2 process one for read & another for write, now i
want to access my inverter i.e one i/p & one o/p. so i have to write like
this (h<=slv_reg0;) in write process and (k<=slv_reg1;)in read process
because iam intended to connect the h to my i/p(s) of inverter and k to
o/p(t) of my inverter.
Can u tell me is this right?

If this is right when i synthesized my code like this following warning
msg is appearing:
WARNING:Xst:646 - Signal <k> is assigned but never used.
And while implementing same errors as before are appearing.


Before in my user_ip.vhd i used to write my logic (inverter) and when i
used to download it on my board and see it on the hyper terminal it works
fine. But when the same logic is added like a (ip core)i.e component
instantiation, i stucked at the above problems.

So can you guide me in this task.

thanks
gary

>>
>>
>>
>
>
>





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

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

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

Custom Search