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 24850

Article: 24850
Subject: Re: Metastability and antifuze
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 20 Aug 2000 19:06:09 GMT
Links: << >>  << T >>  << A >>


Elftmann wrote:

> Peter,
>
> The A40MX02 and A40MX04 devices still require the master/slave latch
> implementation, we call these CC-Flops.  While the A40MX family is not a
> qualified space environment device, it is interesting to note that the
> CC-Flops have traditionally had better "Single Event Upset" SEU
> characteristics versus the "hard-coded" flops in the RH1280 (same
> architecture as A42MX).

I believe that. SEU-tolerance gets better when there is a lot of "inertia" in
the latch, while fast metastable recovery needs a "nervous", very fast
feedback loop.

Peter Alfke

Article: 24851
Subject: Re: Arg! 8051 - 6502 and friends
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 20 Aug 2000 19:18:41 GMT
Links: << >>  << T >>  << A >>
As you may have read, Xilinx will put PowerPCs in the Virtex-II chips. That
might make part of this discussion moot. I don't like to sell futures or
sound like a marketeer, but this might be important information for the user
community.  This is public information, let's talk details in a few months...

Peter Alfke

Ben Franchuk wrote:

> Chris Hills wrote:
> >
> > Ben Franchuk <bfranchuk@jetnet.ab.ca> writes
> > >
> > > Why do all the design tutorials settle on 8 bit cpu's or
> > >16 bit RISC's or PDP-8's. Would not a medium sized project
> > >(24/32/36) be better examples to show both the power and the
> > >limitations of FPGA's. Or is it that the low cost/student development
> > >systems can only handle the low end (ie small) FPGA's.
> >
> > Because according to most industry figures I see the 8-bit embedded
> > industry is between 55 and 65% of the whole.  A small but significant
> > market is still the 4 -bit systems.  The 16-bit market is also large and
> > growing.  There is a small 64 bit market 2%?
> >
> > This leaves less than 15% of the market for 24/32/32 bit systems
> >
> > The architecture with by far the largest market share is the 8051 with
> > 20-30% of the WHOLE embedded market. No other single
> > architecture comes close.
> >
> > This not a technical argument but a simple commercial one. 8051 may
> > be a pig technically but it has the market.
>
> However the embedded industry is still simple control that a 59 cent
> real 8051 the can be used in aunt sandys washing machine. It does not
> make sense to use a $50 fpga in $49 modem.I am not sure what the main
> generic FPGA market is but it not low priced computer products.
> Ben.
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> "Octal Computers:Where a step backward is two steps forward!"
>  http://www.jetnet.ab.ca/users/bfranchuk/index.html

Article: 24852
Subject: Re: Metastability measurement
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Mon, 21 Aug 2000 07:44:02 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> I tried exactly that, 18 years ago, while at AMD. I used a neat feedback
> system, to force metastable event to occur all the time.
> I failed miserably.
> Well, that was then... I still like the idea.

I'd like to see two numbers :-

Metastability, and aperture time, which are often confused.

Metastability, as I define as a propogation of a Tsu,Th violation.

CLK ________________/======\________/=======\________/===
D  >________________/===============\_____________________
Qout _______________?????????????HHHH???????????LLLLL

If the ??? time extends to the NEXT clock edge,  you have
a metastability event.

You can force the ??? by Phase Skew of CLK and D. Suggested method
for this is Linear variable delay elements, simplest scheme I can think
of is differential Vdd skew on two Buffer Chains. This will allow phase
resolutions to the low pS, with a VHC14 device.

To test the ??? duration is harder - anyone tried the Digital Phosphor
Scopes
on this problem ?
The Multiple FLOPS suggested sounded a good idea.


Aperture time is that SKEW between two Tsu.Th times, that causes
a finite window where multiple Q's do not all follow the CLK.D

CLK ________________/======\_______/=======\_______
Da ________________/===============\_______________
Db ________________/===============\_______________
Qb.Qa 000000000000033333333333333333XXXXXXXXXXXXXXX

If Da,Db are derived from the SAME pin externally, there will be a
finite
Ck-D phase window, where the Qa.Qb outputs do not follow exactly.
( ie one follows, and one misses )
This divergence will last a whole clock cycle.
On a FPGA, routing delays can also worsen Aperture times.

In fully syncronous systems, both effects disappear.

- jg
Article: 24853
Subject: Re: Non-disclosures in job interviews, Round One
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 20 Aug 2000 19:51:19 GMT
Links: << >>  << T >>  << A >>
Many long postings, but I hope we all agree ( and should enforce ) Jon's
finishing sentence:

Jon Kirwan wrote:

>   I just don't see a proper place for NDAs hidden in
> visitor logs and explicitly required for the first-time interview.
>
> Peace,
> Jon

Peter Alfke
( who hasn't interviewed for a job in the past 12 years, but instead
interviewed hundreds of applicants...)


Article: 24854
Subject: Re: Metastability and antifuze
From: "Elftmann" <elftmann@pacbell.net>
Date: Sun, 20 Aug 2000 12:52:32 -0700
Links: << >>  << T >>  << A >>
"inertia" and "nervous", not exactly terms taught by the universities :<)

Rather than try to oversimplify the topic of SEU or go way off topic, those
interested can head to
Rich Katz's web page which has a good collection of papers and data on SEU:
http://rk.gsfc.nasa.gov/fpgas.htm#SEU-Hardening%20of%20Flip-Flops

"Peter Alfke" <palfke@earthlink.net> wrote in message
news:39A02C19.20190222@earthlink.net...
>
>
> Elftmann wrote:
>
> > Peter,
> >
> > The A40MX02 and A40MX04 devices still require the master/slave latch
> > implementation, we call these CC-Flops.  While the A40MX family is not a
> > qualified space environment device, it is interesting to note that the
> > CC-Flops have traditionally had better "Single Event Upset" SEU
> > characteristics versus the "hard-coded" flops in the RH1280 (same
> > architecture as A42MX).
>
> I believe that. SEU-tolerance gets better when there is a lot of "inertia"
in
> the latch, while fast metastable recovery needs a "nervous", very fast
> feedback loop.
>
> Peter Alfke
>
>


Article: 24855
Subject: Re: Permanently programming FPGAs
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 20 Aug 2000 21:46:26 GMT
Links: << >>  << T >>  << A >>
Right on, Eric!
-Simon

"Eric Braeden" <braeden@erinet.com> wrote in message
news:399fff62$0$62230$53a6afc1@news.erinet.com...
>
> Elftmann, It's not just hardware design managers that are blowing
> off design specs. I am always shocked and then sickened when
> a US Govt project leaders for software development worth $100K's and
> above refuse to write specs and refuse to pay for a spec to be
> written. Then when the project fails to meet schedule or fails to
> function as "imagined" they request more money to fix things.
> In the mean time all the project management team gets
> awards for view-graph presentations.
>
> These people should all be working at MacDonald's. That would
> be safe for me. I never go there!!
>
> Eric
>
>
>
>
>


Article: 24856
Subject: timing simulation vs functional one
From: erika_uk@my-deja.com
Date: Sun, 20 Aug 2000 22:08:01 GMT
Links: << >>  << T >>  << A >>
hey

i read once, on this news grp, that there is no need for timing
simulation if the design is well synchronised. the functional does the
job

my design contains plenty of FSM, and also the BRAM. if i use the
timing simulation, it works fine, whereas it fails for functional
simulation.

any help please


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24857
Subject: Re: Metastability measurement
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sun, 20 Aug 2000 15:19:55 -0700
Links: << >>  << T >>  << A >>
Jim, the problem is that your ??? time is not a fixed value, but can only be
measured in a statistical way.
For us to guarantee that ??? will hardly ever ( say, once per 1000 years)
exceed, say 2 ns , we must measure ??? values that occur reasonably often (
once per second, or minute ).
??? is then much less than 1 ns, perhaps in the 100 ps range.
That's where the problem lies...

Peter Alfke

Jim Granville wrote:

> Peter Alfke wrote:
> >
> > I tried exactly that, 18 years ago, while at AMD. I used a neat feedback
> > system, to force metastable event to occur all the time.
> > I failed miserably.
> > Well, that was then... I still like the idea.
>
> I'd like to see two numbers :-
>
> Metastability, and aperture time, which are often confused.
>
> Metastability, as I define as a propogation of a Tsu,Th violation.
>
> CLK ________________/======\________/=======\________/===
> D  >________________/===============\_____________________
> Qout _______________?????????????HHHH???????????LLLLL
>
> If the ??? time extends to the NEXT clock edge,  you have
> a metastability event.
>
> You can force the ??? by Phase Skew of CLK and D. Suggested method
> for this is Linear variable delay elements, simplest scheme I can think
> of is differential Vdd skew on two Buffer Chains. This will allow phase
> resolutions to the low pS, with a VHC14 device.
>
> To test the ??? duration is harder - anyone tried the Digital Phosphor
> Scopes
> on this problem ?
> The Multiple FLOPS suggested sounded a good idea.
>
> Aperture time is that SKEW between two Tsu.Th times, that causes
> a finite window where multiple Q's do not all follow the CLK.D
>
> CLK ________________/======\_______/=======\_______
> Da ________________/===============\_______________
> Db ________________/===============\_______________
> Qb.Qa 000000000000033333333333333333XXXXXXXXXXXXXXX
>
> If Da,Db are derived from the SAME pin externally, there will be a
> finite
> Ck-D phase window, where the Qa.Qb outputs do not follow exactly.
> ( ie one follows, and one misses )
> This divergence will last a whole clock cycle.
> On a FPGA, routing delays can also worsen Aperture times.
>
> In fully syncronous systems, both effects disappear.
>
> - jg

Article: 24858
Subject: Re: Metastability and antifuze
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sun, 20 Aug 2000 15:22:55 -0700
Links: << >>  << T >>  << A >>


Elftmann wrote:

> "inertia" and "nervous", not exactly terms taught by the universities :<)
>

I believe in explanations that are intuitively understandable.
Conceptual understanding comes first, math follows. Not everybody will agree.
:-)

Peter

Article: 24859
Subject: Re: timing simulation vs functional one
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Mon, 21 Aug 2000 00:42:18 GMT
Links: << >>  << T >>  << A >>
Can you give us a hint as to what failed?  We can't help you if you don't
give us the information.  What kind of error messages did you get?  What
tools are you using?  What FPGA vendor are you using?
-Simon Ramirez


<erika_uk@my-deja.com> wrote in message news:8npkro$fin$1@nnrp1.deja.com...
> hey
>
> i read once, on this news grp, that there is no need for timing
> simulation if the design is well synchronised. the functional does the
> job
>
> my design contains plenty of FSM, and also the BRAM. if i use the
> timing simulation, it works fine, whereas it fails for functional
> simulation.
>
> any help please
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 24860
Subject: Re: Metastability and antifuze
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Aug 2000 01:38:32 GMT
Links: << >>  << T >>  << A >>


Elftmann wrote:
> 
> Peter,
> 
> The A40MX02 and A40MX04 devices still require the master/slave latch
> implementation, we call these CC-Flops.  While the A40MX family is not a
> qualified space environment device, it is interesting to note that the
> CC-Flops have traditionally had better "Single Event Upset" SEU
> characteristics versus the "hard-coded" flops in the RH1280 (same
> architecture as A42MX).  Please note that the previous statement is
> no-longer true with the SX, RTSX, and SXA devices.
> 

No surprise there.  The feedback time, which translates into your FF's GBW
product determinines to a large degree your resistance to SEU as well as your
susceptability to metastable events.  Unfortunately, faster flip-flops, good for
metastability and for high clock rate systems don't fare as well as slower flip
flops for SEU.  Antoher way of looking at that is that you need a certain amount
of energy to get the flip-flop to toggle.  The higher the GBW< the less energy
needed, and nece the smaller the window where metastable events will happen, but
that also means it doesn't take as much energy to upset the applecart either.

> The A42MX, SX, RTSX, and SXA devices all have "hard-coded" flip-flops.
> 
> Actel set out on the same mission to characterize metastability
> characteristics in our newer devices, but ran into the same problem as the
> Xilinx team did.  I'll check back with Product Engineers next week and see
> where it sits on the priority list these days.  As a result of past
> discussions in this group I continue to push on Product Engineering to make
> metastability characterization standard operating procedure.
> 
> "Peter Alfke" <palfke@earthlink.net> wrote in message
> news:399FFF7A.CF624270@earthlink.net...
> > Metastability is caused by the (limited) gain bandwidth product of the
> > master latch in the flip-flop. As such it has nothing to do with the
> > programming technology. Xilinx ( and Altera :-) ) flip-flops are
> > hard-implemented, optimized structures that contain no programming
> > elements in the critical path.
> > I suppose the same is true of most ASICs. The original Actel devices
> > composed their latches out of multiplexers, and we always pointed out
> > their (theoretically) poor metastable performance. I assume that Actel
> > now also has "hard-coded" flip-flops. (?)
> > So the physics is the same. It's just that SRAM-based FPGAs are easier
> > to "play with".
> >
> > Peter Alfke
> > =======================================
> > Hal Murray wrote:
> >
> > Hal Murray wrote:
> >
> > > What sort of metastability data is available for antifuze parts?
> > >
> > > How do they measure it?  Any reason that technique can't be
> > > applied to SRAM based parts?
> > >
> > > How do ASIC vendors get metastability data?
> > > --
> > > These are my opinions, not necessarily my employers.  I hate spam.
> >

-- 
-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: 24861
Subject: Re: Further FPGA metastability questions
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Aug 2000 01:49:57 GMT
Links: << >>  << T >>  << A >>
That's fine for a design run through usign the big green pushbotton mentality. 
However when you start carefully architecting the design for the utmost
performance I'll bet you are bumping into the metastability thing again.  

I think the real cause might just be the lack of ability to effectively measure
it anymore.  First, by using programmable logic, we are dealing with internal
signals and clocks.  The IO on current chips is slower than the internals, so
direct measurement from outside is likely to be skewed significantly from what
is actually happening inside.  That in turn tells us that we need to put at
least part of the meausurement circuit inside the chip, which means working with
the same type of resources we are trying to measure.  Now, at least in
evaluating radar, and I suspect the same is true here, you really would like
your test equipment to have an order of magnitude or more resolution than the
unit under test so that you can resolve the results suffienctly.  I suspect this
is the case with metastability measurements in the FPGA.  Peter, maybe you can
expound on this (or you could tell me I'm off picking flowers in left field).

Hal Murray wrote:
> 
> In article <399F587E.7C0F4A56@andraka.com>,
>  Ray Andraka <ray@andraka.com> writes:
> > I don't buy the metastability is becoming a non-issue thing at all.  Not one
> > little bit.  As the filpflops get faster, so do the clock rates.  Sure, if you
> > are keeping the same clock rate the metastability problem diminishes.  If
> > however you are pushing the performance of these parts to the edges of the
> > envelope, metastability is waiting behind every turn waiting to bite you in the
> > behind.  It all comes down to the clock speed, therate of change of the async
> > data and the gain BW of the flip flops.  push up the clock and/or the rate of
> > change high enough and you can gt yourself into problems period.
> 
> It sure isn't a non-issue, not with all the recent traffic on the subject. :)
> 
> But Peter reports that he couldn't measure it, so something interesting has
> changed.
> 
> I suspect there is a parameter that we aren't considering yet - some
> way to look at the problem that will give us some insight.
> 
> What's the ratio of raw FF speed to typical cycle time, even if
> we consider the cycle time when pushing the envelope?
> 
> Do modern chips spend more time in routing relative to
> the routing for the FF-FF pattern needed for a synchronizer?
> 
> Has the basic design of the master latch improved?
> 
> --
> These are my opinions, not necessarily my employers.  I hate spam.

-- 
-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: 24862
Subject: Re: timing simulation vs functional one
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Aug 2000 02:02:31 GMT
Links: << >>  << T >>  << A >>
YIKES! That's scary.  It probably means you have parts of the design that are
depending on the delays through logic.  If that is the case then you'd best head
back to the drawing board because it is likely to bite you hard when you get it
into production.

On the other hand it could be a simple cockpit problem with your simulation. 
For example, is your simulation switching inputs right at the clock edge?  In a
timing simulation you'll probably get away with that because the delays are
modeled.  In a functional simulation, it might be getting the data into the
input flip-flops on the same clock edge the clock is changing on.  I've seen
that happen, and it can cause some headscratching until you figure out what you
did wrong in the setup.  If you have a design that mixes instantiated clocked
primitives with inferred registers you might also want to turn off the
TimingChecksOn Generic on the unisim library elements (I'm arrogantly assuming
xilinx for the moment).  I've had occasional trouble in the past if I left them
on in a functional simulation.


erika_uk@my-deja.com wrote:
> 
> hey
> 
> i read once, on this news grp, that there is no need for timing
> simulation if the design is well synchronised. the functional does the
> job
> 
> my design contains plenty of FSM, and also the BRAM. if i use the
> timing simulation, it works fine, whereas it fails for functional
> simulation.
> 
> any help please
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-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: 24863
Subject: Re: Metastability measurement
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Mon, 21 Aug 2000 14:34:56 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Jim, the problem is that your ??? time is not a fixed value, but can only be
> measured in a statistical way.
> For us to guarantee that ??? will hardly ever ( say, once per 1000 years)
> exceed, say 2 ns , we must measure ??? values that occur reasonably often (
> once per second, or minute ).
> ??? is then much less than 1 ns, perhaps in the 100 ps range.
> That's where the problem lies...
> 
> Peter Alfke

 True, that's why I said : To test the ??? duration is harder.

One measurement, I thought of that is indirect, would be to clock off 
the Failing Q, then use the FPGA to analyse results, looking for
multiple
edges on Q following a Clock. 
 This method assumes that multiple edges will occur as a by product 
of some metastable settlings, and would allow limits on the Delay 
Skew to be found, thus giving some values for the metastable window.

 The FPGA could be coded for a ratio test, so that you can state
'We had >100,000 metastable settlings, and in XX of these did the event
NOT settle in a sample times of YY ns'

 - jg
Article: 24864
Subject: Re: Further FPGA metastability questions
From: Peter Alfke <palfke@earthlink.net>
Date: Mon, 21 Aug 2000 03:20:03 GMT
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> you really would like
> your test equipment to have an order of magnitude or more resolution than the
> unit under test so that you can resolve the results suffienctly.  I suspect this
> is the case with metastability measurements in the FPGA.  Peter, maybe you can
> expound on this (or you could tell me I'm off picking flowers in left field).
>

Well, it may not be as bad as you think. But the test circuit sure has to be weird and
not something anybody would do normally. I am thinking of giving up on the frequency
method ( because a half period of any manageable frequency is too long ) and go to an
external phase shifter or delay element. Maybe it is possible, with a little help from
the DLL and some realistically-sized R and variable C to achieve the delay changes
that allow measurement. It's a bit murky still, and I will be gone until
mid-September, but there is at least a ray ( no pun intended! )of hope...

Peter Alfke

Article: 24865
Subject: Re: Arg! 8051 - 6502 and friends
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Mon, 21 Aug 2000 04:08:11 +0000
Links: << >>  << T >>  << A >>
Jan Gray wrote:

> The XSOC/xr16 articles/kit [1] builds a 16-bit RISC because
> 
> 1) 16-bits is often a better fit for a small embedded system.  Smaller
> pointers, smaller code addresses => smaller memory footprint.

Baring the fact that we all are entrenched in 8 bit wide memory
chips - the same could be said of 18 bits.

> 2) 16-bits adequately demonstrates all of the design issues of FPGA CPU+SoC
> development.  A 32-bit processor would not have been more educational.

No problem with that, why cloud the issue with trivial details, providing
your cpu does not require pre/post op bytes in the design link some
nameless cpu's.
 
> 3) the prototype board (the XESS XS40 [2]) provided only 8-bit-wide RAM.
> (The XSOC design reads a byte on each clock edge).  A 32-bit instruction or
> data word machine would have required 2-4 clock cycles per
> instruction/load/store and constrained the performance of the machine.

Ah bus limitations.

> 
> 4) XSOC fits in a very small FPGA (an XC4005XL).  It is quite possible to
> build a 32-bit RISC in about half of an XC4010XL, there was the j32 [3], and
> the presently unreleased xr32, which will run fine (but for the 8-bit RAM
> problem just mentioned) in an XC4010XL in the XESS XS40-010XL.  With enough
> care it is possible to build a 32-bit RISC in an XC4005XL!  (Hint:
> architecture width need not equal datapath implementation width.)

True but full alu width will save on control states.
 
> The current Xilinx Foundation Student Edition 1.5i supports chips up to
> XC4010XL and XCS40 (comparable to a XC4020XL).  So there's plenty of
> headroom.  For example, it is quite possible to build a 2-processor 32-bit
> pipelined RISC using the current student tools.  I understand there is a new
> version of Student Ed. on the way that may provide support for small Virtex
> devices.

$#%@! Software limitations!.

> A 24-bit machine (12-13 CLBs tall) would fit naturally in an XC4005XL or
> Spartan 10 (14x14 CLBs).

My alu design needs B,A+B,A-B,-A+B,A^B,A|B,A&B,shift right(A),shift left(B).
About 6 CLB's no matter how you slice it per bit.
Since the memory for the register set is single port, there is
no advantage to me to pipeline my alu thus my cycle times are longer
but they do it all. My alu is strongly influenced by the 2901 bit slice.
With the Altera software for the 10k10 I can use the TTL macro library
to create easy schematic cause I think better in those terms rather than
a textual description in a high level language. Once I get the first revision
working I then can fine tune the design. I am using the Altera 10k10 because
that is what hardware/software I can get here in the middle of the bald 
prairie at the price I can afford.
 
> Jan Gray
> Gray Research LLC
> 
> [1] http://www.fpgacpu.org/xsoc/cc.html
> [2] http://www.xess.com/prod004.html
> [3] http://www3.sympatico.ca/jsgray/homebrew.htm

Arg!!! More great web sites to surf.:)
Ben.
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"Octal Computers:Where a step backward is two steps forward!"
 http://www.jetnet.ab.ca/users/bfranchuk/index.html
Article: 24866
Subject: Re: Further FPGA metastability questions
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Aug 2000 04:41:13 GMT
Links: << >>  << T >>  << A >>
I was thinking while I was writing my post "what if you put signals you could
adjust the phasing between into two adjacent pins...."   well looks like that is
what you are taling about here.  I suppose if you could guarantee the paths were
virtually identical, then you might have something that would work there.  Still
it is not clear how you'd generate the small phase delay differences required
without it getting swamped by parasitics and stray signals.  I think as soon as
you are outside of the chip, you open a whole new can of worms when you are
dealing with the very small metastable trigger window which sounds like is a
very small number of ps wide.  I'd think breathing near it would be enough to
shift your test signal pahse difference away from the window.  Well, I thinks
you got your work cut out for you, and it does sound like it would make fodder
for a good FPGA2001 paper.  (You got till Sept 29 to get your paper in, think
you can do it on your vacation?)

Peter Alfke wrote:
> 
> Ray Andraka wrote:
> 
> > you really would like
> > your test equipment to have an order of magnitude or more resolution than the
> > unit under test so that you can resolve the results suffienctly.  I suspect this
> > is the case with metastability measurements in the FPGA.  Peter, maybe you can
> > expound on this (or you could tell me I'm off picking flowers in left field).
> >
> 
> Well, it may not be as bad as you think. But the test circuit sure has to be weird and
> not something anybody would do normally. I am thinking of giving up on the frequency
> method ( because a half period of any manageable frequency is too long ) and go to an
> external phase shifter or delay element. Maybe it is possible, with a little help from
> the DLL and some realistically-sized R and variable C to achieve the delay changes
> that allow measurement. It's a bit murky still, and I will be gone until
> mid-September, but there is at least a ray ( no pun intended! )of hope...
> 
> Peter Alfke

-- 
-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: 24867
Subject: Re: Metastability measurement
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Aug 2000 04:50:40 GMT
Links: << >>  << T >>  << A >>
That assumes the metastability generates multiple edges.  I've seen it do that -
had a case a number of years ago that made a nice high frequency (well over 100
MHz) burst with very short turn on and off times on a TTL LS374 -- the radar
guys upstairs would have killed for a circuit that could do that reliably. I
still got the scope picture of that floating around here somewhere. I've also
seen cases where the flip-flop just got incredibly  slow, the change was pretty
much monotonic, but the transition time would driven anything short of a schmitt
trigger bonkers.  Not sure what the behavior of the flip-flops in the FPGA are,
and if it is an oscillation there's an even shot you wouldn't see it anywhere
observable since it would have to pass thorugh some logic that normally won't
handle the type of frequencies it is likely to generate.

Jim Granville wrote:
> 
> Peter Alfke wrote:
> >
> > Jim, the problem is that your ??? time is not a fixed value, but can only be
> > measured in a statistical way.
> > For us to guarantee that ??? will hardly ever ( say, once per 1000 years)
> > exceed, say 2 ns , we must measure ??? values that occur reasonably often (
> > once per second, or minute ).
> > ??? is then much less than 1 ns, perhaps in the 100 ps range.
> > That's where the problem lies...
> >
> > Peter Alfke
> 
>  True, that's why I said : To test the ??? duration is harder.
> 
> One measurement, I thought of that is indirect, would be to clock off
> the Failing Q, then use the FPGA to analyse results, looking for
> multiple
> edges on Q following a Clock.
>  This method assumes that multiple edges will occur as a by product
> of some metastable settlings, and would allow limits on the Delay
> Skew to be found, thus giving some values for the metastable window.
> 
>  The FPGA could be coded for a ratio test, so that you can state
> 'We had >100,000 metastable settlings, and in XX of these did the event
> NOT settle in a sample times of YY ns'
> 
>  - jg

-- 
-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: 24868
Subject: Re: Distributor attitude !!
From: "Kang Liat Chuan" <kanglc@agilis.st.com.sg>
Date: Mon, 21 Aug 2000 12:54:36 +0800
Links: << >>  << T >>  << A >>
> I would like to know the nature of the relationship that others have
> experienced with the licensed FPGA distees.
>
> Sincerely
> Daniel DeConinck
> High Res Technologies, Inc.

Recently, I was told by Insight (Singapore) that they will not support small
quantity order. Neither are they willing to give samples. We tried other
electronic suppliers and still could not get our hands on just a few simple
fpgas (Xilinx XC4000E series), and we finally ordered them through the
Internet.

Despite several attempts to report this matter to Insight/Memec/Xilinx, it
didn't help.

Regards,
Kang Liat Chuan
Agilis Communication Technologies


Article: 24869
Subject: Re: Non-disclosures in job interviews, Round One
From: murray@pa.dec.com (Hal Murray)
Date: 21 Aug 2000 07:12:49 GMT
Links: << >>  << T >>  << A >>

> NDAs have a purpose, of course.  I hope nothing I've said suggests I
> think otherwise.  I just don't see a proper place for NDAs hidden in
> visitor logs and explicitly required for the first-time interview.

I'm pretty sure I've seen reasonable boiler-plate stuff on sign in
logs, but it was anti-NDA rather than NDA.  The visitor promised not to
tell any of his secrets unless a real NDA was signed.

The idea was to keep a visitor/vendor who was a small time inventor
from claiming the big company stole his ideas when they both
invented something at roughly the same time.

-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 24870
Subject: Re: fifo;s
From: jamil.khatib@pmail.net
Date: Mon, 21 Aug 2000 08:02:21 GMT
Links: << >>  << T >>  << A >>
try to loook at my FIFO design at
http://www.geocities.com/Siliconvalley/Pines/6639/ip/memory_cores.html

it has a single clock but you can easiely modify it.
it is customizable core and does not depend on the target FPGA, you can
replace a dual port core for specific technology or remove the reset
from the dual port memory to use the on FPGA memory blocks (altera and
Xilinx).


Please let me know if you use it or modify it.

feel free to ask

Regards
Jamil Khatib

In article <399A3044.1901EF20@quest-innovations.com>,
  Richard Meester <rme@quest-innovations.com> wrote:
> Hello all,
>
> I need to implement small fifo's, with 2 diiferent clock domains. They
> need to be 4 bit wide, and 16 deep. Can anyone suggest how to
implement
> these fifo's without waisting lots of ram using the blockram devices,
> since they com in 4096bit, and i only have 12 of them, and i need more
> than 12 fifo's. I have looked at the xilinx site, but they only have
> notes subscribing the use of blockram, and the other notes using
single
> ram, have the same clock domains.
>
> Regards,
>
> Richard.
>
> Ps. the device i am targeting is a spartan2.
>
> --
> Quest Innovations
> tel: +31 (0) 227 604046
> http://www.quest-innovations.com
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24871
Subject: Re: Non-disclosures in job interviews
From: gyles@nortelnetworks.com (Gyles Harvey)
Date: 21 Aug 2000 09:09:43 GMT
Links: << >>  << T >>  << A >>
In article <39988E05.562512B2@yahoo.com>,
rickman  <spamgoeshere4@yahoo.com> wrote:
>I am interviewing for jobs and I am finding more than one company that
>wants me to sign a non-disclosure (ND).

For more discussion on this, see slashdot:

http://slashdot.org/article.pl?sid=00/08/18/1833229

Gyles.

-- 
gyles@nortelnetworks.com
All opinions expressed are my own, not those of Nortel Networks.
Article: 24872
Subject: Some notes on metastability
From: Philip Freidin <philip@fliptronics.com>
Date: Mon, 21 Aug 2000 02:40:37 -0700
Links: << >>  << T >>  << A >>
This is an informational (I hope) posting, hopefully giving some additional
insight to the behavior of metastables.

The following is an edited version of some of my postings to
sci.electronics.design, during May of 2000.

Since this is quite long, here is a quick guide to the contents of this message:

1) The original poster asked people to look at his WWW page, where he had
a schematic for a claimed metastable free design. Several people pointed out
his error, including me. My response includes some historical notes, as well as
a list of observed metastable behavior. The original poster never responded.

2) Another poster also responded, and assumed that metastables only occur
as an oscillation (a pulse running around a loop). My response details the
internal mechanism for metastables, and also discusses some old TTL
technology.

3) The poster in (2) followed up my post, and I replied again. In this post,
we discussed oscillation versus delayed output. I made my case that I
believe at the system level, both are just as bad, and so tricks that
convert an oscillation metastable into a delayed output metastable are
of no use.

In particular, I comment that the signals that we are worried about going
metastable are signals that connect to the D pin of flip-flops. As such,
oscillation or delayed transition are both a disaster.

Signetics (a division of Philips (no relation))  used to claim they had a
metastable immune flip-flop. The 74F50109 description includes the following:

" The 74F50109 is designed so that the outputs can never display a
metastable state due to setup and hold time violations. If setup and hold
times are violated the propagation delays may be extended beyond the
specifications but the outputs will not glitch or display a metastable state.
Typical metastability parameters for the 74F50109 are: t < .2 ns,
T0 = 10us, and h=3.8 ns."

Absolutely incredible!


The names have been changed to protect the lack of an NDA.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Hi XXXX,
        I've seen two posting that both describe the path that
shows that when fdiv_2 is low, the async signal goes all the
way through to the final flipflop.

The topic of designing circuits for dealing with metastability is a very 
well researched area. The now widely held belief is that it is impossible 
to design such a circuit. Indeed, ALL claimed metastable free circuits 
have been proven not to be. Usually the only thing achieved by complex 
circuits that try and deal with all sorts of special cases, is that they 
obscure the metastable mode during analysis. The best way to deal with 
the metastable problem (the synchronization of an asynchronous signal 
feeding into and affecting a synchronous system) is to synchronize the 
signal with a multi stage synchronizer, comprizing of no more than 2 or 
more flipflops, connected as a shift register, and clocked by the clock 
of the destination domain.

Even such circuits as a three stage synchronizer, with the first and third
flipflop clocked on the rising edge of the clock and the middle flipflop
clocked on the falling edge, are less effective than a simpler two stage 
synchronizer, with both clocked on the rising edge.

While much of the really good literature on the topic has been written by 
Fred Rosenberger and Thomas Chaney, as early as 1966 , many others 
have also written on the topic.

B. I. Strom of Bell Labs wrote in 1979 "Proof of the equivalent 
realizability of a time-bounded arbiter and a runt-free inertial delay"
Which basically shows that both are un-realizable. The guts of an arbiter 
is the desired metastable-free flipflop. 

In 1977, E. G. Wormald published a note in the IEEE transactions on 
computing, march 1977, page 317, claiming to have designed a metastable 
free flipflop. At the core of the design, it used a Schmitt trigger to 
try and avoid metastability. In IEEE trans. on comp. Oct 1979, page 802, 
Thomas Chaney commented on the Wormald design.

He explained that Schmitt triggers can them selves go metastable.
He built a circuit as per Wormald'd note, and demonstrated that it went 
metastable. He closed with the following:

"In closing, there is a great deal of theoretical and experimental 
evidence that a region of anomalous behavior exists for every device
that has two stable states. The maturity of this topic is now such that 
papers making contrary claims without theoretical or experimental support 
should not be accepted for publication".

Wormald's response to Chaney (same issue) includes the following:

"Hopefully, the discussion will discourage further attempts to eliminate 
this unavoidable characteristic"


While your design does not use Schmitt triggers, it has been shown that 
there is a path that allows the asynch signal to feed the final flip 
flop, and therefore it can go metastable.

Unfortunately, simulation is NOT sufficient proof of metastable free 
behavior. For a good example of someone who has fooled themself (and the 
patent office) see 4,999,528 . Spice does not have infinite precision, 
and the problems of rounding and convergence are well known.

Also let me state that there are a few lost souls who think that the only 
way a metastable presents itself is as an oscillation on the output. This 
is not the case. Metastable outputs can be

1)	Oscillations from Voh to Vol, that eventually stop.
2)	Oscillations that occur (and may not even cross) Voh and Vol
3)	A stable signal between Voh and Vol, that eventually resolves.
4)	A signal that transitions to the opposite state of the pre clock
	state, and then some time later (without a clock edge) transitions
	back to the original state.
5)	A signal that transitions to the oposite state later than the
	specified clock-to-output delay.
6)	Probably some more that I haven't remembered.

I would suggest a change in the title of your web page  :-)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

YYYY posted the following (indented by ">"), and I responded
>I have thought about this problem for a while. The point that becomes
>clear is that any digital solution simply moves the hazard to the next
>level.

I agree.

>I think there may well be a solution, but it lies with the analog
>behavior of the gates in use, and related to stability criteria used in
>feedback theory. 

I totally disagree (sorry), see my article above.

>Think of a D flip-flop as two cascaded latches, open alternately on the
>clock high and low state. 
> 
>First of all, the latches must have mux hazard protection:
>
> Q = (D & LE) # (Q & !LE) # (D & Q);
>
>Logic compilers typically throw away the last term as "redundant", but
>in reality  !(LE) != !LE , so it's not redundant. !LE is inverted AND
>DELAYED from LE, or the other way around.
>
>Next, the latch loop gain must meet stability criteria. If the latch
>loop delay is more than about half the slew time, there is a hazard of
>metastability. Metastability is when the a latch feedback loop thrashes
>on and off, chasing itself. 

That's only one of it's failure modes. Another is when the loop assumes 
an (almost stable) analog level between the two normal '1' and '0' states.

Here's how it fails. The latch, when closed effectively comprises two 
inverters in a loop. If the input to the first is '0', its output is '1', 
and there fore the output of the second inverter is '0', which was 
driving the input of the first inverter. It is therfore latching the 
value. The opposite state is also possible.

To load the latch, the loop is opened, and a '0' or a '1' is connected to 
the input of the first inverter. The output of the second inverter will 
with time become the same level, and when the loop is closed, the output 
of the second inverter is reconnected to the input of the first.

The inverters are basically high gain inverting amplifiers. If you apply 
an analog signal to the input, there is a region of the input range for 
which the output is a value other than the desired '0' or '1' levels.

For example, lets have an inverter running at 5V, with rail to rail 
outputs, and the middle of its switching theshold is 2.0V, and it has a 
gain of 20. (for simplicity I will assume a linear monotonic transfer 
characteristic for the analog region)

INPUT  OUTPUT
0        5
1        5
1.8      5
1.9      4.5
1.95     3.5
2.0      2.5
2.01     2.3
2.02     2.1
2.025    2.0
2.03     1.9
2.04     1.7
2.05     1.5
2.1      0.5
2.2      0
3        0
4        0
5        0

Somewhere between 2.02 and 2.025 volts input, the output will be the same 
value. I leave it as an exercise for the reader to determine the value.

If I have two such inverters in series, and the output of the second is 
connected to the input of the first, then the loop will be stable (for 
some time) at this intermediate value.

Even if the two inverters are not identical, there is still some analog 
value that when placed on the input of the first inverter, will cause an 
output which when fed to the second inverter will cause its output to 
assume a value that matches the input to the first inverter.

This is true of ALL bistable circuits.

The loop does not need to be made of inverters.

This is independent of the loop gain (other than it must be greater than 1).

This is independent of loop delay.

How does this analog level get into our "digital" systems? Take a step
back and think about the way the latch is made to "track" the input
signal, while the latch is open. The loop is opened, and the input signal
charges and discharges the input node of the first inverter. The charging
and discharging depends on the size of the capacitance of the node, and
the impedance of the input signal source and the interconnect to the first
inverter. The input can not instantaneously change from the '0' to '1'
levels. It must transition through the analog region where the output is
transitioning through its analog region. See the table above. The charging
stops and the loop is closed when the clock signal transitions. If this 
happens at just the wrong time, the value on the input of our first 
inverter meets the criterion for the loop to be in the metastable state, 
of being neither a '0' or a '1'.

The quality of a device to minimize how often it goes metastable, and how
long it may stay that way depends on the loop gain, and the signal
transition rates. Improving both these characteristics will minimize the 
region for which the inputs and outputs are in the analog region.

>If the loop delay is 10nS, a 5nS pulse can race around the loop until
>slew asymmetry wipes out one side of the wave. This is why TTL, which is
>highly asymmetric, is "less prone" to metastability. In fact, such
>storms in TTL logic simply move quickly to a "0" because the pull down
>is always a lot stronger than the pull up.

Unfortunately, this is not true either. Since there are two gates in the
loop, even if you did have a pulse racing around the loop, what one gate
would make shorter, the other gate would make longer. One of the worst
devices for metastability is the 74S74. Almost all other 74xxx74 devices
behave better. Your assertion that TTL quickly resolve to '0' is also
incorrect. A device in a metastable condition has equal likelihood of 
resolving to a '0' or a '1'.


>
>In analog terms, a "single dominant pole" in the latch feedback should
>mean that the latch will produce, at worst, a single pulse, if any. 

See below for a list of the ways that a metastable can be seen.

>If the second latch of the DFF is not open for some delay after the
>closure of the first, then this pulse is not seen at the DFF output.

Unfortunately, the duration of the metastable state in the first latch is 
unbounded, and so there is no guarantee that it will be resolved by the 
time the second latch is opened. Delaying the opening of the second latch 
cannot guarantee hiding the metastability, and would also adversely 
affect the clock to output time of the circuit.

>The
>second latch must also close before the first opens (on the falling
>clock), ie: 
>
>LE1= !clock & !LE2;
>LE2=  clock & !LE1;
>
>A latch uses positive feedback, not negative, but you can see that if
>the loop gain is high at the frequency = 1/loop_delay, wrt DC gain, the
>latch can oscillate for a time before stabilizing.  
>Cheers,
>YYYY

Sorry for the bad news YYYY,
Cheers anyway  :-)
Philip

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

YYYY responded (indented by ">") and I replied:
>I was thinking that it might be possible for a circuit to meta-stabilize
>faster than the general response, and so hiding the problem, but as you
>point out the meta-unstable time can be unbounded.
>
>A couple ideas:
>
>1. If the failing loop is followed by a third gate who's threshold is
>off from the point of equilibrium, then this static condition becomes a
>1 or 0.  For this reason, I think, in many cases, a static failure mode
>does not translate to the kinds of system failure that oscillating does.
>This leaves us with the dynamic case I was interested in. A strategy
>aimed at damping oscillation would be useful, even if it does nothing
>for the static case.
> 
>Cheers,
>Steve

Although oscillation and delayed transition are two of the several ways a 
metastable can manifest itself (see my previous article for some other 
failure modes), what you are suggesting above will basically turn the 
oscillation mode into the delayed output mode.

(

In fact, I suspect this is what actually happens in the delayed output
case, or something similar. Here are two scenarios: 

a) Internal latch oscillates with a small swing. The output of the latch 
is buffered, and the buffer has a threshold that is outside of the peak 
to peak swing of the oscillation. When the oscillation stops, and the 
latch takes on a stable '1' or '0' state, the following buffer then 
'reports' the result, but with late clk-to-q problem.

b) Internal latch oscillates with large swing. The output of the latch is
buffered, and the buffer is slow (or is slowed by its load), and the high
frequency oscillations dont get seen on the buffer's output. When the
oscillation stops, and the latch takes on a stable '1' or '0' state, the
following buffer then 'reports' the result, but with late clk-to-q problem. 

)

While you characterize the oscillating and delayed outputs as two 
different failure modes (you call them dynamic and static), to me they 
are the same thing: The flipflop does not behave as per the data sheet, 
and valid Q is late.

Here's some info about my digital design style which may help to 
understand my position:

I do digital design that is fully synchronous. ALL flipflops are clocked
by one master clock signal. Clocks are never gated. Async reset or set are
only used for system initialization. Clock enables (mux in D path,
recirculating Q ) for flipflops that need to have their clock disabled 
for some cycles. Async inputs are handled in carefully designed circuits 
that minimize the occurence of metastables getting into the main design.

From  a timing point of view, all async paths within the design start at a 
flipflop, go through some cloud of logic, and end at a flipflop. Since 
all flops are clocked by the same clock signal, all logic paths have the 
same worstcase delay requirements, which is clock period minus flipflop 
output time minus flipflop setup time. This can be exhaustively analyzed 
by a static timing analyzer. The design only needs functional (unit 
delay) simulation, and timing simulation is un-needed.

If the system must have more than 1 master clock, i.e. data arrives from 
a source with a 50MHz clock, and is processed and leaves with a 27.5MHz 
clock, then I break the design into two sub-designs, that are each 
totally synchronous, and great care is applied at the point where the 
data moves between the two domains. FIFOs, dual port memories, 
semaphores/flags, and carefully designed synchronizers all help to cross 
the chasm.

So in my systems, the signals that can go metastable, are signals that in 
the limit always have D pins as their destinations. Never clock pins. So 
whether it oscillate and then goes stable, or just goes to a stable state 
at a later time, it is still violating the clock-to-Q spec of the data 
sheet, and this value was used to guarantee system timing during static 
timing analysis.

I am unable to imagine a scenario where a signal that could go metastable 
is used as a clock to a flipflop, and where the difference between 
oscillating or delayed signal would make a difference.


Philip Freidin

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>



Philip Freidin

Mindspring that acquired Earthlink that acquired Netcom has
decided to kill off all Shell accounts, including mine.

My new primary email address is    philip@fliptronics.com

I'm sure the inconvenience to you will be less than it is for me.
Article: 24873
Subject: OpenTech cdrom new release
From: jamil.khatib@pmail.net
Date: Mon, 21 Aug 2000 11:03:47 GMT
Links: << >>  << T >>  << A >>
OpenTech cdrom new release is available now.

The new release has some new open hardware designs and many new open
source eda tools.
The OpenTech cdrom will provide solution to many hardware designers who
want reference designs and can not afford the expensive eda tools

For more information visit
http://www.opencores.org/OIPC/projects/OpenTech

Best regards
Jamil Khatib


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24874
Subject: OpenTech cdrom new release
From: jamil.khatib@pmail.net
Date: Mon, 21 Aug 2000 11:11:33 GMT
Links: << >>  << T >>  << A >>
OpenTech cdrom new release is available now.

The new release has some new open hardware designs and many new open
source eda tools.
The OpenTech cdrom will provide solution to many hardware designers who
want reference designs and can not afford the expensive eda tools

For more information visit
http://www.opencores.org/OIPC/projects/OpenTech

Best regards
Jamil Khatib


Sent via Deja.com http://www.deja.com/
Before you buy.


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