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 25100

Article: 25100
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 25 Aug 2000 22:17:54 GMT
Links: << >>  << T >>  << A >>
I suspect it is process.  The SRAM FPGAs, specifically Xilinx use the same FAB
as RAM memory, which is to say that they are on the bleading edge of fab
technology.  Anti-fuse has additional process steps that don't allow as fast an
entry into the small geometries so size and speed suffer.  There's also the
issue of testing die.  An SRAM FPGA can be exhaustively tested with a set of
actual configurations,  How are you going to test all configurations of an
antifuse device?  

"S. Ramirez" wrote:
> 
>      This is on a similar thread running earlier (and now!).
>      If Actel and QuickLogic anti-fuse technology so small and quick, why
> aren't these two companies leapfrogging each other to make the biggest FPGA
> in the world?  I read in an Actel book once that anti-fuses are cheap,
> small, easy to make and very quick timing-wise.  These are all very good
> reason why they should be the biggest FPGAs out there.
>      Maybe anti-fuse technology has limitations that I don't know about.
>      I still stand by my statement that IO density and packaging will
> ultimately limit the non-reprogrammable market to the smaller devices.  This
> is because FBGAs are too hard to remove/replace and very dense sockets are
> relatively unreliable.  Maybe this is the REAL reason that Actel and
> Quicklogic aren't progressing as fast as Xilinx and Altera.
>      If there is an Actel or Quicklogic expert or representative in this
> newsgroup, maybe you can enlighten me on why these two companies have not
> dominated the "largest FPGA in the world" market.

-- 
-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: 25101
Subject: Re: PCI macros
From: Jim McManus <jim.mcmanus@xilinx.com>
Date: Fri, 25 Aug 2000 15:29:04 -0700
Links: << >>  << T >>  << A >>
If you are having any issues with your Xilinx PCI macro, we are happy to
help. The Xilinx Hotline is trained to support PCI and there are PCI
Applications Engineers backing up the Hotline Engineers. I have, over
the years, personally supported many of the Xilinx PCI customers. 

Jim McManus
Xilinx PCI-X Applications Engineer

jean-francois hasson wrote:
> 
> Hello,
> 
> I am considering using a PCI macro in an FPGA either Xilinx or Altera.
> I have no experience of macros but what I heard about the specific PCI
> macros is
> that there is no support for them that is if it fails (possible ???)
> nobody can help.
> If anyone has some experience with PCI macros I would be glad to know
> about it :
> what chip was used, was it difficult to use, were there unpleasant
> surprises (or
> good ones !?!).
> 
> Thank you in advance.
> 
> J.F. Hasson
Article: 25102
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 25 Aug 2000 15:33:01 -0700
Links: << >>  << T >>  << A >>
As applications guy with a "long-time-ago" antifuse manufacturer (Xilinx 8100 ,
abandoned for greener pastures), here is my aggressive response. Then we can
let Actel and Quicklogic shoot holes into it, for they are still in that game,
and must see a good reason for it:

1. With antifuse technolgy, you are always  one or more generations behind the
microprocessor, logic and "SRAM-based" FPGA manufacturers. One cannot afford
that generation gap. Too costly. The frontier is 0.13 micron today.

2. One-time programmable excludes you from re-configuration, and even from
design modifications.
BGA packages are a real pain to change.

3. Antifuse programming takes a very long time, many minutes at the modest
densities available today. How long at megagates ?

4. Manufacturing. Antifuse parts use fine granularity and large numbers of
programming elements. Can one manufacture a chip with 100+ million antifuses
and guarantee that all of them are good?

5. The "smaller and faster" story is largely fairytale.  Can they do 800 MHz
I/O, 400 MHz counters, 200+ MHz logic and RAMs, etc ?

6. So what's left is:
instant-on, easy security, somewhat better resistance to radiation.
That may be a comfortable niche for some, not big enough for the big guys.

Peter Alfke's personal opinions.
I'll read the flames in 3 weeks.



"S. Ramirez" wrote:

>      This is on a similar thread running earlier (and now!).
>      If Actel and QuickLogic anti-fuse technology so small and quick, why
> aren't these two companies leapfrogging each other to make the biggest FPGA
> in the world?  I read in an Actel book once that anti-fuses are cheap,
> small, easy to make and very quick timing-wise.  These are all very good
> reason why they should be the biggest FPGAs out there.
>      Maybe anti-fuse technology has limitations that I don't know about.
>      I still stand by my statement that IO density and packaging will
> ultimately limit the non-reprogrammable market to the smaller devices.  This
> is because FBGAs are too hard to remove/replace and very dense sockets are
> relatively unreliable.  Maybe this is the REAL reason that Actel and
> Quicklogic aren't progressing as fast as Xilinx and Altera.
>      If there is an Actel or Quicklogic expert or representative in this
> newsgroup, maybe you can enlighten me on why these two companies have not
> dominated the "largest FPGA in the world" market.

Article: 25103
Subject: Xilinx 18V02 Prom Parallel mode fails
From: Richard Lamoreaux <rdlamoreaux@west.raytheon.com>
Date: Fri, 25 Aug 2000 15:41:29 -0700
Links: << >>  << T >>  << A >>
I am using an 18V02 device with a Virtex FPGA. I can download via JTAG
with my Multilinx cable and get the PROM to program in serial mode.
When I reprogram it for parallel mode, the operation status says
"Setting parallel mode bit..done"

However, the PROM still puts out a 250millisecond serial bit stream on
DO and nothing on D1-D7.

I have the latest version of the WebPACK JTAG Programmer, 3.1WP2.x,
App version D.21.

Thanks,
Richard Lamoreaux
Raytheon

Article: 25104
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Fri, 25 Aug 2000 16:05:37 -0700
Links: << >>  << T >>  << A >>
Hi - 

Technical issues aside, I'd be curious about just how much demand
there'd be for an anti-fuse part that's as large as the biggest Xilinx
and Altera SRAM parts.  Although a good economic argument might be
made for using such parts, the cringe factor in throwing away
expensive parts during debug is not to be underestimated (the cost of
removing/replacing them is a good point, too).  Sure, it's cheaper
than spinning an ASIC.  But with an ASIC, at least you get a low
recurring cost.

Are there folks out there in FPGA Land who'd use such parts?  If so,
what's your application?

Take care,
Bob Perlman


On Fri, 25 Aug 2000 21:22:36 GMT, "S. Ramirez" <sramirez@cfl.rr.com>
wrote:

>     This is on a similar thread running earlier (and now!).
>     If Actel and QuickLogic anti-fuse technology so small and quick, why
>aren't these two companies leapfrogging each other to make the biggest FPGA
>in the world?  I read in an Actel book once that anti-fuses are cheap,
>small, easy to make and very quick timing-wise.  These are all very good
>reason why they should be the biggest FPGAs out there.
>     Maybe anti-fuse technology has limitations that I don't know about.
>     I still stand by my statement that IO density and packaging will
>ultimately limit the non-reprogrammable market to the smaller devices.  This
>is because FBGAs are too hard to remove/replace and very dense sockets are
>relatively unreliable.  Maybe this is the REAL reason that Actel and
>Quicklogic aren't progressing as fast as Xilinx and Altera.
>     If there is an Actel or Quicklogic expert or representative in this
>newsgroup, maybe you can enlighten me on why these two companies have not
>dominated the "largest FPGA in the world" market.
>

Article: 25105
Subject: Re: Is there any way to configure the Virtex BRAM outputs as direct,
From: Ray Andraka <ray@andraka.com>
Date: Fri, 25 Aug 2000 23:15:45 GMT
Links: << >>  << T >>  << A >>
John, as I understand it, the devil is in the details.  Peter Alfke or Bernie
New could give ou better answers.  In any event that's teh way it is.  What you
can do in situations like your buddy's is use a small distributed CLB) RAM in
conjuction with the BRAM on the read side to get the behavior you are looking
for.

"John L. Smith" wrote:
> 
>   What is the idea of making the read data outputs of the Virtex
> BlockRAM registered by the clock? This seems to be a time
> waster when using the BRAM as storage for an asynchronous
> fifo (or other possible applications).
> 
>   Consider the case where we use one port to write,
> and the other to read. If I write data in one side,
> then on the read side I must wait, not only until
> I've registered that there is data available in
> the memory, but an entire extra clock cycle after
> that, to apply a read clock to the device in
> order to get the data out of the memory.
> 
> The app note, XAPP130, states:
> "7 The output ports are latched with a self timed circuit to
> guarantee a glitch free read. The state of the output port
> will not change until the port executes another read or write
> operation."
> 
> I'd like to see the read port change when the write port
> operates, like the distributed ram behaves.
> 
>   Why is it necessary to latch the output ports for a 'glitch
> free read'? Shouldn't a stable read address be enough? In a
> dual port ram, there is no way to guarantee that a read at a
> given location will be completely valid if there is a
> simultaneous write to same location on the other port.
> (See arbitration/metastability discussions) So why not
> allow the read data to get out faster? Why hide it for
> a clock cycle behind an output register?
> 
>    I can see that having the registers built-in on the
> BlockRAM device may allow faster system clock, and thus
> greater throughput for some apps. But latency counts for
> something too. The registered output adds one clock cycle
> of latency, when the read address is already set-up. This
> may degrade applications (like fifos, or interprocess
> semaphores) where latency might be as important (or more
> so) than throughput.
> 
>    I'm sure the app note would mention it if there was,
> but ask the group anyway:  Is there any way to put the
> Virtex BlockRAM into a direct read mode?
> 
>  Registering the output data is something that should be
> optional, available to the designer either through a
> configuration option for the ram, or via regular CLB registers
> (how do the Virtex II BlockRAMs handle this?).
> 
> ( The main reason I ask is that a co-worker is trying
> to reproduce an obsolete discrete fifo, where the
> output data appeared after the write pulse, before
> any read command is issued. I suggested he could use
> the distributed ram rather than the block ram, but
> yet I want to eat my cake, and still to have it: it
> would be nice if the BRAM had direct outputs! I suppose
> BRAM throughput was the prime driver for the registered
> only outputs)
> 
> Thanks all for listening,
> John

-- 
-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: 25106
Subject: Re: Non-disclosures in job interviews, Round Two
From: "Spehro Pefhany" <speff@interlog.com>
Date: Fri, 25 Aug 2000 23:35:55 GMT
Links: << >>  << T >>  << A >>
In comp.arch.embedded Darin Johnson <darin@usa.net> wrote:
> rickman <spamgoeshere4@yahoo.com> writes:

>> I can see the potential need for all of these things even if I don't
>> agree that they should be used for employment screening.

> I don't see the need even.  A credit report?  I've heard places
> use this, but I can't imagine to what legitimate use it would
> be put.  Employability should have nothing to do with finances.
> If an interviewee has credit problems, so what?

People with a gambling problem, for example, have been known to ignore
their fiduciary duties. 

As far as the urine sample goes (as it were), at an interview? I'd be
tempted to leave it on the side of their headquarters. ;-)

Best regards,
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.BlueCollarLinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Article: 25107
Subject: Re: help -- of RAMs, FFs, latches, inverted clocks, and other curiosities
From: "Jan Gray" <jsgray@acm.org>
Date: Sat, 26 Aug 2000 00:16:43 GMT
Links: << >>  << T >>  << A >>
I wrote:
> >Like so many others, I am content to frolic in the happy low-skew-clock,
> >buffered-interconnect, perfect digital world abstraction provided by
FPGAs.

"Jonas Thor" <NoSpamthor@sm.luth.seNoSpam> wrote:
> I agree, except that I don't understand what the word "Frolic" means.
> Folic is the brand my dogs favourite snack.

Frolic. vi -- ... 2: to play and run about happily : ROMP

Perhaps it will help to see a form of the word used in context.
"
Narrator: Once upon a time, long, long ago, there lived in a valley far, far
away in the mountains, the most contented kingdom the world had ever known.
It was called 'Happy Valley', and it was ruled over by a wise old king
called Otto. And all his subjects flourished and were happy, and there were
no discontents or grumblers, because wise King Otto had had them all put to
death along with the trade union leaders many years before. And all the good
happy folk of Happy Valley sang and danced all day long. And anyone who was
for any reason miserable or unhappy or who had any difficult personal
problems was prosecuted under the 'Happiness Act':

(Sounds of laughter and giggling. A hammer strikes a gavel. Giggling
continues throughout)

Prosecutor: Gaspar Sletts, I put it to you that on February the Fifth of
this year, you were very depressed with malice aforethought, and that you
moaned quietly contrary to the Cheerful Noises Act.

Gaspar Sletts: I did.

Defense: May I just explain, m'lud, that the reason for my clients behavior
was that his wife had died that morning?

(This elicits big laughs. Judge bangs gavel again)

Judge: (laughing) I sentence you to be hanged by the neck until you cheer
up.

(More laughter)

Narrator: And whilst the good folk of Happy Valley TENACIOUSLY FROLICKED
away, ...
"
<http://www.montypython.net/scripts/fairytale.php3>

I hope that helped.  Now may this thread rest in peace.

Jan Gray



Article: 25108
Subject: Re: Is there any way to configure the Virtex BRAM outputs as direct,
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 25 Aug 2000 17:29:03 -0700
Links: << >>  << T >>  << A >>
The description is correct, you even give the reason, and there is nothing you can
do about it in Virtex or Virtex-E, except use parallel circuitry around the RAM.
That's all I can say today...
Peter Alfke

Ray Andraka wrote:

> John, as I understand it, the devil is in the details.  Peter Alfke or Bernie
> New could give ou better answers.  In any event that's teh way it is.  What you
> can do in situations like your buddy's is use a small distributed CLB) RAM in
> conjuction with the BRAM on the read side to get the behavior you are looking
> for.
>
> "John L. Smith" wrote:
> >
> >   What is the idea of making the read data outputs of the Virtex
> > BlockRAM registered by the clock? This seems to be a time
> > waster when using the BRAM as storage for an asynchronous
> > fifo (or other possible applications).
> >
> >   Consider the case where we use one port to write,
> > and the other to read. If I write data in one side,
> > then on the read side I must wait, not only until
> > I've registered that there is data available in
> > the memory, but an entire extra clock cycle after
> > that, to apply a read clock to the device in
> > order to get the data out of the memory.
> >
> > The app note, XAPP130, states:
> > "7 The output ports are latched with a self timed circuit to
> > guarantee a glitch free read. The state of the output port
> > will not change until the port executes another read or write
> > operation."
> >
> > I'd like to see the read port change when the write port
> > operates, like the distributed ram behaves.
> >
> >   Why is it necessary to latch the output ports for a 'glitch
> > free read'? Shouldn't a stable read address be enough? In a
> > dual port ram, there is no way to guarantee that a read at a
> > given location will be completely valid if there is a
> > simultaneous write to same location on the other port.
> > (See arbitration/metastability discussions) So why not
> > allow the read data to get out faster? Why hide it for
> > a clock cycle behind an output register?
> >
> >    I can see that having the registers built-in on the
> > BlockRAM device may allow faster system clock, and thus
> > greater throughput for some apps. But latency counts for
> > something too. The registered output adds one clock cycle
> > of latency, when the read address is already set-up. This
> > may degrade applications (like fifos, or interprocess
> > semaphores) where latency might be as important (or more
> > so) than throughput.
> >
> >    I'm sure the app note would mention it if there was,
> > but ask the group anyway:  Is there any way to put the
> > Virtex BlockRAM into a direct read mode?
> >
> >  Registering the output data is something that should be
> > optional, available to the designer either through a
> > configuration option for the ram, or via regular CLB registers
> > (how do the Virtex II BlockRAMs handle this?).
> >
> > ( The main reason I ask is that a co-worker is trying
> > to reproduce an obsolete discrete fifo, where the
> > output data appeared after the write pulse, before
> > any read command is issued. I suggested he could use
> > the distributed ram rather than the block ram, but
> > yet I want to eat my cake, and still to have it: it
> > would be nice if the BRAM had direct outputs! I suppose
> > BRAM throughput was the prime driver for the registered
> > only outputs)
> >
> > Thanks all for listening,
> > John
>
> --
> -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: 25109
Subject: Re: Non-disclosures in job interviews, Round One
From: "Matthew S. Staben" <mstaben@poboxes.com>
Date: Fri, 25 Aug 2000 19:22:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tue, 22 Aug 2000 20:00:08 -0700, Jon Kirwan wrote:

>On Tue, 22 Aug 2000 08:27:01 -0700, Neil Nelson <n_nelson@pacbell.net>
>wrote:
>
>>Your plan of action seems to be a recommendation that in the
>>case where a company requests written agreement to an NDA at
>>the interview that we do not take the interview.
>
>No.  Not quite the way I'd say it.
>
>If a company recommends an NDA agreement at the first interview, I'd
>recommend a careful reading of exactly what the NDA says.  If you
>don't feel you understand it, it if isn't clear and simple, then don't
>sign it.  In most cases, I'd guess that a careful reading *cannot* be
>properly done on a short moment's notice.  So they need to be prepared
>to give you a fair opportunity to read and understand its details and
>accept questions and discussion on its points.  I wouldn't do a single
>further thing with them until that was completed.  Nothing.

<snip>

>Why should anyone sign a blanket NDA on first contact, where the NDA
>takes nothing about the individual or their circumstances into
>account??  You still haven't bothered to answer that question, in
>spite on my bring it up several times.  Frankly, I'm beginning to
>believe you cannot.
>
>A company has no valid reason, none whatsoever, in confronting each
>and every person walking into their first interview, with an NDA to
>sign and worse, a blanket and non-specific NDA.  End of story.
>
>Jon

A legal document ultimately is tested in a court of law.  It is unfortunate that these 
days, with the apparent ignorance exhibited by the Lawmakers (eg. UCITA) this 
buffer may not offer much comfort.  Even so, signing a NDA for an interview seems 
at worst to me a non-enforceable agreement.  There is no paperwork, tax 
document, employment record, whatever, of the person being interviewed; just the 
NDA being the sole document that proves the interviewee was ever present.  And 
because of the lack of supporting evidence, there is no case.  If any of you out 
there can think of a situation where a certain judgement would be entered against 
the NDA-violating defendant, I'd like to hear about it.

I'm also of the opinion that a non-specific NDA would have less legal ground than 
one that is specific.  More to the point, I can imagine instances where perhaps due 
to the nature of an interview, a specific NDA could be a disastrous thing to sign.  
After all, the company suing for its perceived violation would be claiming that 
so-and-so must have "seen," or "heard" something under their roof.  There is 
again no time line that would lead any reasonable power to believe that the 
information being contested was gained in any other way unless perhaps the 
interview is taped with a clear acknowledgement that the interviewee knew he was 
being taped, and that he admits to signing the NDA prior to any business/specific 
conversation and the tape clearly identifies proprietary subjects.  

I am admittedly ignoring the possibility of being blacklisted, or whatever, but 
there's lots of ways around such possibilities -- deadly or otherwise -- and I think 
any reasonable employer will recognize such.

Regards,

Matthew Staben



Article: 25110
Subject: Re: Accessing internal signals and ports for writing to a file using testbench
From: somogyi@ee.ualberta.ca (Paul Somogyi)
Date: 26 Aug 2000 03:00:41 GMT
Links: << >>  << T >>  << A >>
Hello,

I didn't see the previous responses to this post... so here's my 2 cents.

It can be done with some simulators.  I've used Cadence leapfrog/ncsim,
and looked at internal signals using the C library interface.  If you're
using this simulator, start "openbook" and under the product guide will
be the C library interface.  That documentation describes how to write a
shared library (Sun or HP) that the simulator can use.  In particular,
you can write the implementation of a VHDL procedure in C.

What you want to do only requires one function call from the C code into
the simulator: there is a call to propogate one signal onto another one;
these signals can be located anywhere in the design.  So I just created
signals in my testbench of the same types as the internal signals, and
used this VHDL/C function call to "assign" the internal signals to the
testbench ones (note that you don't have any normal VHDL drivers for
the testbench signals).

To do this purely in VHDL is impossible.

Paul


Nestor (nestor@ece.concordia.ca) wrote:
> Hi Everyone.

> Does anyone know how to access an internal signal or a port in VHDL when
> doing a simulation with a VHDL testbench?  I have instantiated a block
> within my top level VHDL design and I would like to monitor some of its
> internal signals and some of its ports.  My aim is to write the observed
> values to a file using a VHDL testbench since it will be easier for me to
> compare the results in a spreadsheet program.  I am already able to write
> the inputs and outputs for the top level design instantiated as a
> unit-under-test (UUT) in the VHDL testbench (all the ports are visible and I
> can assign them to a signal that I declare in the testbench).

> My problem is how to access signals internal to that UUT.  I am able to
> access these internal signals within the simulator's graphical view, but I
> cannot export that information in a readable format using the simulator's
> menus.  Is there a way to achieve what I want using the VHDL syntax directly
> within the VHDL testbench?

> Thanks in advance for your help.

> Nestor


Article: 25111
Subject: Newbie question about Xilinx Spartan PGCLK
From: Antonio Pasini <pasini@elca-elettronica.it>
Date: Sat, 26 Aug 2000 08:43:53 GMT
Links: << >>  << T >>  << A >>
I'm at my first design with an FPGA; I'm in doubt about the better
way to handle a clock problem.

In my board (frame grabber), I have a clock (LLC, 29.5 Mhz) on pin
PGCK1.
On the P03 pin I have CREF, a clock qualifier. 

All my internal logic needs to clock on rising edges of LLC, 
WHEN CREF IS HIGH.

In my first attempt, I connected a BUFGP on LLC clock, 
and propagate the clock qualifier on CE inputs all over.

That works, but I'd like to "think" in terms on a single clock, 
at half rate. That will simplify design and schematic..
I think I won't need the original clock in my design.
All happens at LLC/2 rate. 

What I'd like to do is gating (bleurgh!) the LLC clock with 
CREF, then distribute the result with a global clock connection. 

Externally, I have connected an I/O pin (P28) to PGCK2 (P27).

I could derive my qualified clock, output it on P28, 
re-entering on PGCK2, and use that as global clock.

But it's ugly.. I'd prefer an internal routing connection.

I tried to connect a BUFGP to the gated clock, putting LOC=P27 on 
the BUFGP. In fact, it compiles ok, but the timing analyzer warns me 
that the resuling gated clock doesn't use dedicated resources, and warns
me to use "-skew" argument in order to calculate clock skew. 
Seems I am in search for trouble...
But the mapper tells me that I'm using 2 of the 4 dedicated clock
routings.


What's the better way to handle this ?

1) Work with original clock, and use clock qualifier all over the
design. 
Just annoying and error-prone. 

2) Get a LLC/2 clock, gating the original one; putting it on output,
re-entering, and using that clock.
Hardware allows that, but it's horrible, I suppose.

3) Doing the same, using internal routing resources. How ??


I'd like some tips from you experienced guys!

Many thanks!
Article: 25112
Subject: Vacancy at European Space Agency
From: jgais@ws.estec.esa.nl
Date: Sat, 26 Aug 2000 13:27:05 +0200
Links: << >>  << T >>  << A >>

OK folks, if anyone ever wanted my job - here is your chance!

I will be leaving ESA by the end of the year to pursue a
mixed academic/consulting career, and we need some talented
person to replace me. The vacancy notice can be found at:

http://www.esa.int/hr/VN/281.html

Feel free to contact me if you need more information.
Note that only citizens from the ESA member states can
be considered.

For those of you interested in the LEON project: don't
worry, I will be continuing working on it as before. We
are now testing the new AMBA version and next release is
expected in September.

Regards, Jiri Gaisler.

---------------------------------------------------------------------
Jiri Gaisler, ESA/ESTEC, Box 299, 2200 AG Noordwijk, the Netherlands
email: jgais@ws.estec.esa.nl voice:+31-71-5654880  fax:+31-71-5654295 
ERC32 home page at http://www.estec.esa.nl/wsmwww/erc32
LEON home page at http://www.estec.esa.nl/wsmwww/leon
---------------------------------------------------------------------
Article: 25113
Subject: Problem instantiating Xilinx primitives in FPGA Express
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Sat, 26 Aug 2000 08:47:08 -0700
Links: << >>  << T >>  << A >>
Hi - 

For reasons too complicated to explain, I temporarily took leave of my
senses and agreed to synthesize a VHDL design in FPGA Express (I
usually rely on Synplicity and Verilog).  Because FPGA Express has
some problems with building latch enables sensibly, I decided to
directly instantiate the latches, as follows:

architecture RTL of mystery_module is

component LDCE
   port(
      Q        :	out   STD_LOGIC;
      D        :	in    STD_LOGIC;
      G        :	in    STD_LOGIC;
      GE       :	in    STD_LOGIC;
      CLR      :	in    STD_LOGIC);
end component;
  .
  .
  .
begin
  .
  .
  .
    r_nw_latch: LDCE port map (Q => R_nW, 
                               D  => io_dr, 
                               G => iosd_set, 
                               GE => r_nw_latch_ge, 
                               CLR => r_nw_clr);

All of my signals are declared std_logic.

When I run "update," the line with the LDCE instantiation throws error
VSS-543 (Actual designator not of correct type - STD_ULOGIC expected).

Here's where I get confused.  Absolutely every direct instantiation
example I've encountered in the Xilinx documents suggests that modules
for primitives use data types std_logic and std_logic_vector; that's
why I declared the component as I did.  However, when I look in
Xilinx's VHDL-related unisim files--unisim_VCOMP.vhd and
unisim_VPKG.vhd--it appears as if the LDCEs in those files expect
input and output types STD_ULOGIC.   (I'm not including these files in
my compiles; I just used them as a reference.)

Can someone tell me what I'm doing wrong?

Thanks,
Bob Perlman




Article: 25114
Subject: Re: Non-disclosures in job interviews, Round Two
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 26 Aug 2000 12:00:38 -0400
Links: << >>  << T >>  << A >>
Neil Nelson wrote:
> 
> 
> Rick Collins,
> 
> Very good.  An obvious reason why I want names is that if you
> have a complaint about a company and express the complaint it
> helps to know what company you are complaining about.

Neil,

You still have not told me *WHY* you think it "helps to know what
company you are complaining about". Why Neil? Why? Please tell me
Why!!!! 

 
> As to an assertion that no one is reading the thread, I would
> say that fewer people are contributing to the thread.  As to
> whether they are reading it I could not say, except if you
> are assuming a correlation of contributing with reading.  You
> have implied some reason associated with me as to why they are
> not reading.  If you have an argument to make, make it.

No I have been told by some people that they have stopped reading it!!!
No one has told me they are still reading it other than you. You are
making an assumption about other's thinking processes which is not
evident. You make this mistake a lot in this thread. 

 
> It would appear there are areas of agreement, which at first
> may seem hard to find, between many of us--even you and I--such
> that a recommended policy that would be supported by most of us
> could be given.  E.g., I would agree, as a part of the policy,
> to Jon's and other's recommendations that all documents a company
> requests to be signed be read carefully and not signed if there
> were sufficiently undesirable aspects to them of which some we
> may wish to detail.  Also a marking of those documents for modifi-
> cations and corrections could be done.  I think there may be
> better ways and additional considerations that may be addressed
> for this issue, but I will sign-on to that policy.


At this point I don't really care about a "recommended policy". I doubt
that I or anyone else is going to do what we might suggest. 

I am just curious as to why it is so hard to get you to focus on a few
points and answer a simple question such as "Why do you need to know the
names?"


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 25115
Subject: Balls!
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Sat, 26 Aug 2000 11:04:29 -0700
Links: << >>  << T >>  << A >>
Well, I want to do a really cool image-processing gadget, and I'll
need an FPGA with 300 I/O pins or so. Peter Alfke was kind enough to
send me a couple of sample Xilinx BGA parts. I showed them to my
manufacturing people and actually escaped with my life.

So, if any of you have experience with BGAs, I'd appreciate some help:

1. Is it necessary to go with gold-plated (or maybe bare copper) pads
to ensure planarity? Anybody having success with regular FR-4,
solder-coated SMOBC stuff?

2. Assuming I send the boards out for assembly, I'd still like to
verify that all the BGA soldering is intact. I could code up a special
FPGA design to just configure the chip as a lot of I/O latches, and
then run test patterns (from the uP that configures and supervises the
FPGA). Clearly, I can detect shorts between pins this way. Any ideas
on how to detect open ball-to-PCB solder joints?

3. What sorts of PCB line/spacings are needed for something like a
460-ish pin 1.27 mm BGA?

4. Any other advice or cautions?


Thanks,

John



Article: 25116
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 26 Aug 2000 15:22:19 -0400
Links: << >>  << T >>  << A >>
What about using both technologies in the same way you use SRAM FPGAs to
prototype ASICs? I do not make ASICs, nor do I program anti-fuse parts.
But if it is so much trouble and expense to program and replace
anti-fuse parts as part of development, why not treat the anti-fuse part
as an ASIC. Make a board with an SRAM FPGA for debug. Then when you have
the design working properly, you can respin the board for the (hopfully)
lower cost anti-fuse FPGA? Then you get the best of both worlds. 

This will even let you address bugs by going back to the SRAM FPGA for
verification and fix. Then any new boards you produce can have the fix
on them. 

This gives you the speed to market of the FPGA, the development
flexibility of the SRAM FPGA and the low cost of the anti-fuse FPGA. 



Bob Perlman wrote:
> 
> Hi -
> 
> Technical issues aside, I'd be curious about just how much demand
> there'd be for an anti-fuse part that's as large as the biggest Xilinx
> and Altera SRAM parts.  Although a good economic argument might be
> made for using such parts, the cringe factor in throwing away
> expensive parts during debug is not to be underestimated (the cost of
> removing/replacing them is a good point, too).  Sure, it's cheaper
> than spinning an ASIC.  But with an ASIC, at least you get a low
> recurring cost.
> 
> Are there folks out there in FPGA Land who'd use such parts?  If so,
> what's your application?
> 
> Take care,
> Bob Perlman
> 
> On Fri, 25 Aug 2000 21:22:36 GMT, "S. Ramirez" <sramirez@cfl.rr.com>
> wrote:
> 
> >     This is on a similar thread running earlier (and now!).
> >     If Actel and QuickLogic anti-fuse technology so small and quick, why
> >aren't these two companies leapfrogging each other to make the biggest FPGA
> >in the world?  I read in an Actel book once that anti-fuses are cheap,
> >small, easy to make and very quick timing-wise.  These are all very good
> >reason why they should be the biggest FPGAs out there.
> >     Maybe anti-fuse technology has limitations that I don't know about.
> >     I still stand by my statement that IO density and packaging will
> >ultimately limit the non-reprogrammable market to the smaller devices.  This
> >is because FBGAs are too hard to remove/replace and very dense sockets are
> >relatively unreliable.  Maybe this is the REAL reason that Actel and
> >Quicklogic aren't progressing as fast as Xilinx and Altera.
> >     If there is an Actel or Quicklogic expert or representative in this
> >newsgroup, maybe you can enlighten me on why these two companies have not
> >dominated the "largest FPGA in the world" market.
> >

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 25117
Subject: Re: Balls!
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 26 Aug 2000 15:52:30 -0400
Links: << >>  << T >>  << A >>
I have used the 256 pin BGA on standard HASL - SMOBC coated boards. I am
not a board engineer (I don't know if there are any, but there are
others are much more experienced than I), but I have been told that the
leveling is only an issue for the fine pitch quad flatpacks, not BGAs of
any type. 

The BGAs have a ball of solder on each pin of the package and you can
also apply solder paste to the pads on the board. I would expect in that
case that you will not have much of a problem with planarity issues if
you can support standard quad flat packs (25 mil pitch). 

Do you manufacturing people have any experience with BGAs? I have found
that there are manufacturing house which do BGAs easily and there are
houses which can not do them at all. I don't think there is much in the
middle as it is largely a matter of experience. Once they bite the
bullet and give it a go, it is not too hard to master. 

I don't know about the fine pitch BGAs like the ones they use in the
Spartan II line. They may be harder to work with. I have stayed away
from the really fine pitch parts like the CS144 and CS280 (< 1mm pitch).
But the problem was in the board features having to go down to 5 mil and
below for the microvias. No one has told me that we need to go to
special techniques for any leveling problems. 

The best way to verify the soldering is via X-RAY of the board. Every
house that claims BGA capability has one around and uses it at least
initially. If you want an electrical test, I would suggest that you look
into boundry scan. This can be applied to every board that is produced
and should be very cost effective. You should be able to check for opens
by testing connections to the other chips on the board. 

Our board used 5/5 design rules, but I have been told that my layout
house was full of it and I could have gotten by with two less layers and
6/7 or even 7/7 design rules. They are not my design house anymore. A
1.27 mm pitch on the BGA is equivalent to 0.05" pitch such as an SO
package. These parts have been used for years with ease. The only
problems with this pitch in BGA is the fact that you can't visually
inspect them and the "mystique" with using a new technology.

So take the plunge and find an assembly house that has BGAs well under
your belt. You won't have any real problems. 


John Larkin wrote:
> 
> Well, I want to do a really cool image-processing gadget, and I'll
> need an FPGA with 300 I/O pins or so. Peter Alfke was kind enough to
> send me a couple of sample Xilinx BGA parts. I showed them to my
> manufacturing people and actually escaped with my life.
> 
> So, if any of you have experience with BGAs, I'd appreciate some help:
> 
> 1. Is it necessary to go with gold-plated (or maybe bare copper) pads
> to ensure planarity? Anybody having success with regular FR-4,
> solder-coated SMOBC stuff?
> 
> 2. Assuming I send the boards out for assembly, I'd still like to
> verify that all the BGA soldering is intact. I could code up a special
> FPGA design to just configure the chip as a lot of I/O latches, and
> then run test patterns (from the uP that configures and supervises the
> FPGA). Clearly, I can detect shorts between pins this way. Any ideas
> on how to detect open ball-to-PCB solder joints?
> 
> 3. What sorts of PCB line/spacings are needed for something like a
> 460-ish pin 1.27 mm BGA?
> 
> 4. Any other advice or cautions?
> 
> Thanks,
> 
> John

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 25118
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: daniel_elftmann@my-deja.com
Date: Sat, 26 Aug 2000 22:03:13 GMT
Links: << >>  << T >>  << A >>
In article <39A6EA29.4CB2@designtools.co.nz>,
jim.granville@designtools.co.nz wrote:
> S. Ramirez wrote:
> >
> >      This is on a similar thread running earlier (and now!).
> >      If Actel and QuickLogic anti-fuse technology so small and
quick, why
> > aren't these two companies leapfrogging each other to make the
biggest FPGA
> > in the world?  I read in an Actel book once that anti-fuses are
cheap,
> > small, easy to make and very quick timing-wise.  These are all very
good
> > reason why they should be the biggest FPGAs out there.
> >      Maybe anti-fuse technology has limitations that I don't know
about.
> >      I still stand by my statement that IO density and packaging
will
> > ultimately limit the non-reprogrammable market to the smaller
devices.  This
> > is because FBGAs are too hard to remove/replace and very dense
sockets are
> > relatively unreliable.  Maybe this is the REAL reason that Actel and
> > Quicklogic aren't progressing as fast as Xilinx and Altera.
> >      If there is an Actel or Quicklogic expert or representative in
this
> > newsgroup, maybe you can enlighten me on why these two companies
have not
> > dominated the "largest FPGA in the world" market.
>
> I can think of three reasons : ISP, Testing, and Yields ?
>

ISP is definitely a valid point, many design houses do require ISP
devices in todays market.

By testing I assume you mean device level testing.  To my knowledge
this is not an issue in going to larger Antifuse based devices.

Yields:  It is not easy to achieve high yields with antifuse devices
(Xilinx can attest to that), but we do achieve very good yield with the
current devices.  Because of the non-standard fabrication process it
does require much more effort and coordination between the vendor and
the fab to achieve acceptable yields.

> Last time I looked anti-fuse devices were not ISP, and had quite slow
> pgm times.
>

You are correct none of the Actel antifuse devices are ISP.  The
programming times can be quite long for larger Antifuse devices, this
is probably one of the most significant factors in getting higher
density antifuse devices.  A significant amount of effort and research
is currently focused on this area to improve the programming times.

>  I can imagine it's quite easy (well, fast) to test a RAM based
> device, but how do you test your brand new, OTP device ?
> PGM a bundle with a swag of test patterns ..

The logic modules in the Actel antifuse devices are all tested via
dedicated circuitry, which designers can also utilize for real time
debug.  Designers can access internal nodes in the device after
programming via the Silicon Explorer tool without having to further
program the device.  Silicon Explorer has saved the day in many cases
in my personal experience as an Actel FAE.  All Actel antifuse devices
offer two probe pins.  Via these probe pins the output of all logic
modules can be observed at the probe pins.  When needed for user I/O
these two probe pins can also be used in the customers design.  This
same circuitry is utilized during the testing of un-programmed devices
to guarantee 100% functionality of the modules in the device prior to
shipment of the blank devices.

>
>  Then you have fault analysis issues - was that a one-0ff fail, or do
we
> need to fix the mask.
>
>  Lastly, I believe the really big SRAM devices are getting some form
> of redundancy, to help yields.
>  With an OTP device, you cannot test it until you pgm it, so you have
> only yield indicators, and the customer handles your yield fall out..
>

The large SRAM devices can and do take advantage of redundancy to help
in achieving higher yields (I'll let Peter comment on just how much).

Again with an antifuse device you can test the logic modules without
programming the device.  What we cannot test is the programming of each
and every antifuse element.  Typical programming yields are between 90-
99%, however customers do not necessarily handle the yield fall out due
to programming.  Devices which fail to program are simply replaced.
Most customers do not directly program the devices, except during the
prototyping phase of their design.  High volume production programming
is typically done via programming centers (ala Source), Distribution
programming centers (Arrow, Pioneer, Unique), or Actel's in house
programming (IHP).  Therefore, in essence customers see 100% yield and
receive the device just like they would an ASIC.

> -jg
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25119
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: daniel_elftmann@my-deja.com
Date: Sat, 26 Aug 2000 22:11:15 GMT
Links: << >>  << T >>  << A >>
In article <39A6EFFC.83B87C0D@andraka.com>,
  Ray Andraka <ray@andraka.com> wrote:
> I suspect it is process.  The SRAM FPGAs, specifically Xilinx use the
same FAB
> as RAM memory, which is to say that they are on the bleading edge of
fab
> technology.  Anti-fuse has additional process steps that don't allow
as fast an
> entry into the small geometries so size and speed suffer.  There's
also the
> issue of testing die.  An SRAM FPGA can be exhaustively tested with a
set of
> actual configurations,  How are you going to test all configurations
of an
> antifuse device?

I think I addressed testing sufficiently in my reply post to Jim, and
won't replicate that here.

The only additional note that I'll make here is that antifuse devices
do tend to lag the SRAm devices in geometry because it is not as simple
as an SRAM process, however the higher speeds achievable in the
antifuse technologys means that a .45u antifuse technology can achieve
speeds equal to a .35u SRAM technology, or .35u antifuse technology
vs .25u SRAM technology.  Currently Actel is shipping devices at a .22u
geometry.
>
> "S. Ramirez" wrote:
> >
> >      This is on a similar thread running earlier (and now!).
> >      If Actel and QuickLogic anti-fuse technology so small and
quick, why
> > aren't these two companies leapfrogging each other to make the
biggest FPGA
> > in the world?  I read in an Actel book once that anti-fuses are
cheap,
> > small, easy to make and very quick timing-wise.  These are all very
good
> > reason why they should be the biggest FPGAs out there.
> >      Maybe anti-fuse technology has limitations that I don't know
about.
> >      I still stand by my statement that IO density and packaging
will
> > ultimately limit the non-reprogrammable market to the smaller
devices.  This
> > is because FBGAs are too hard to remove/replace and very dense
sockets are
> > relatively unreliable.  Maybe this is the REAL reason that Actel and
> > Quicklogic aren't progressing as fast as Xilinx and Altera.
> >      If there is an Actel or Quicklogic expert or representative in
this
> > newsgroup, maybe you can enlighten me on why these two companies
have not
> > dominated the "largest FPGA in the world" market.
>
> --
> -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
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25120
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: daniel_elftmann@my-deja.com
Date: Sat, 26 Aug 2000 22:18:33 GMT
Links: << >>  << T >>  << A >>
In article <5budqsg18fb94j1onn30a4n17kvj23fec4@4ax.com>,
  Bob Perlman <bobperl@best_no_spam_thanks.com> wrote:
> Hi -
>
> Technical issues aside, I'd be curious about just how much demand
> there'd be for an anti-fuse part that's as large as the biggest Xilinx
> and Altera SRAM parts.  Although a good economic argument might be
> made for using such parts, the cringe factor in throwing away
> expensive parts during debug is not to be underestimated (the cost of
> removing/replacing them is a good point, too).  Sure, it's cheaper
> than spinning an ASIC.  But with an ASIC, at least you get a low
> recurring cost.

Low recurring cost?  Only if you can get an ASIC vendor to give you a
significant break on the NRE.  Plus the time between spins is
significantly longer.  Initial prototypes can be received rather
quickly, but volumes typically lag significantly.

>
> Are there folks out there in FPGA Land who'd use such parts?  If so,
> what's your application?

In applications requiring high reliability and non-volatility I would
say yes.  Designs that require security also would like a larger
antifuse based device, at least that's what I've seen in my travels as
an FAE.
>
> Take care,
> Bob Perlman
>
> On Fri, 25 Aug 2000 21:22:36 GMT, "S. Ramirez" <sramirez@cfl.rr.com>
> wrote:
>
> >     This is on a similar thread running earlier (and now!).
> >     If Actel and QuickLogic anti-fuse technology so small and
quick, why
> >aren't these two companies leapfrogging each other to make the
biggest FPGA
> >in the world?  I read in an Actel book once that anti-fuses are
cheap,
> >small, easy to make and very quick timing-wise.  These are all very
good
> >reason why they should be the biggest FPGAs out there.
> >     Maybe anti-fuse technology has limitations that I don't know
about.
> >     I still stand by my statement that IO density and packaging will
> >ultimately limit the non-reprogrammable market to the smaller
devices.  This
> >is because FBGAs are too hard to remove/replace and very dense
sockets are
> >relatively unreliable.  Maybe this is the REAL reason that Actel and
> >Quicklogic aren't progressing as fast as Xilinx and Altera.
> >     If there is an Actel or Quicklogic expert or representative in
this
> >newsgroup, maybe you can enlighten me on why these two companies
have not
> >dominated the "largest FPGA in the world" market.
> >
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25121
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 26 Aug 2000 22:38:16 GMT
Links: << >>  << T >>  << A >>
In article <8o9eqo$gh5$1@nnrp1.deja.com>,  <daniel_elftmann@my-deja.com> wrote:
>The large SRAM devices can and do take advantage of redundancy to help
>in achieving higher yields (I'll let Peter comment on just how much).

	When I asked Steve Trimburger if there was any redundancy used
in the Virtex E (when looking at the die for the XCV2000E), he said
that they did not use any redundancy in the design!
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 25122
Subject: Re: Metastability and antifuze
From: "Elftmann" <elftmann@pacbell.net>
Date: Sat, 26 Aug 2000 16:13:55 -0700
Links: << >>  << T >>  << A >>
Rich,

I was able to stop into the product engineering group at Actel this week to
see how the metastability characterization was going.  I'm happy to report
that the characterization has been completed for the .45u (MX), .35u(SX),
.25u/.22u(SXA) and the RTSX devices.  This report is now in the hands of the
marketing folks to turn it into an application note.  I will continue
pushing on it to insure it is posted to the web site as soon as possible.

"rk" <stellare@nospamplease.erols.com> wrote in message
news:39A5D52C.3B54A8A7@nospamplease.erols.com...
> Hal Murray wrote:
>
> > > [1] "Metastability Report for FPGAs," Quicklogic Data
> > >     Book, 1994, pp. 523-526.
> >             ^^^^
> >
> > > [2] Actel Data Book, 1992, pp. 5-1 to 5-2.
> >                        ^^^^
> >
> > Ugh.  Maybe it's a conspiracy to make Xilinx look good.  :)
>
> While I am almost alway a believer in conspiracy theories, I can't say
> that I know of one here.  I just had some old books laying around the
> study.  Now, I don't recall any of the newer books having any more
> update to date information.  Perhaps Dan or John can chime in.
>
> I did try and hunt for more information on various www sites to update
> things but couldn't find anything relevant.  Help, anyone?
>
> Have a nice evening,
>
> rk
>
>


Article: 25123
Subject: Re: Non-disclosures in job interviews, Round Two
From: Neil Nelson <n_nelson@pacbell.net>
Date: Sat, 26 Aug 2000 17:39:30 -0700
Links: << >>  << T >>  << A >>

--------------624B5227847CADEC218E8DB5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rick Collins wrote:

> Neil,
>
> You still have not told me *WHY* you think it "helps to know what
> company you are complaining about". Why Neil? Why? Please tell me
> Why!!!!
>
> > As to an assertion that no one is reading the thread, I would
> > say that fewer people are contributing to the thread.  As to
> > whether they are reading it I could not say, except if you
> > are assuming a correlation of contributing with reading.  You
> > have implied some reason associated with me as to why they are
> > not reading.  If you have an argument to make, make it.
>
> No I have been told by some people that they have stopped reading it!!!
> No one has told me they are still reading it other than you. You are
> making an assumption about other's thinking processes which is not
> evident. You make this mistake a lot in this thread.

I make assumptions according to the evidence I have.  Is your meaning
that they have told _us_, you and I, or that, as you have written, they
have told _you_?

I should likely apologize for not explaining in more detail why I think
names are important, but I have explained that at length and was thinking
when I wrote the above that the reasons are so fundamental as to go with-
out further discussion.  However, perhaps the following will make this
more clear.

We have sent the child out into the yard again on our hunt for hard
evidence, and shortly the child comes back and we notice the child's
clothes are smudged, in disarray, the face of the child seems bruised
and scratched, and the child is crying.  The mother of the child is
on-hand, and I expect we all know what the mother is going to say ...

The mother demands, ``What happened?''

The child sobs, ``A big boy hit me and pushed me down!''

Now assuming that, say, the assault is serious, what do we think the
mother will say and do?  Will finding out the name of this boy be of
significant or little relevance?  Do we want to find this boy and
make our displeasure clear?  Do we want to find his parents and let
them know it is their responsibility to correct and prevent this
behavior?  The purpose of a name is to make a (relatively) unique
identification that is a major component of assigning responsibility.

I have been thinking about an interesting argument in which the
utility of information in the wide sense is best exemplified by
names, but I will not trouble you with that though it might be
interesting for an information technology news-group like this.

Whether or not anyone else has the determination to continue and
attempt to move the discussion forward, to perhaps work toward a
more coordinated solution speaks to their commitment. I am here.
I have not bailed out.

Regards,

Neil Nelson

--------------624B5227847CADEC218E8DB5
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Rick Collins wrote:
<blockquote TYPE=CITE>Neil,
<p>You still have not told me *WHY* you think it "helps to know what
<br>company you are complaining about". Why Neil? Why? Please tell me
<br>Why!!!!
<p>> As to an assertion that no one is reading the thread, I would
<br>> say that fewer people are contributing to the thread.&nbsp; As to
<br>> whether they are reading it I could not say, except if you
<br>> are assuming a correlation of contributing with reading.&nbsp; You
<br>> have implied some reason associated with me as to why they are
<br>> not reading.&nbsp; If you have an argument to make, make it.
<p>No I have been told by some people that they have stopped reading it!!!
<br>No one has told me they are still reading it other than you. You are
<br>making an assumption about other's thinking processes which is not
<br>evident. You make this mistake a lot in this thread.</blockquote>
<tt>I&nbsp;make assumptions according to the evidence I have.&nbsp; Is
your meaning</tt>
<br><tt>that they have told _us_, you and I, or that, as you have written,
they</tt>
<br><tt>have told _you_?</tt><tt></tt>
<p><tt>I&nbsp;should likely apologize for not explaining in more detail
why I think</tt>
<br><tt>names are important, but I have explained that at length and was
thinking</tt>
<br><tt>when I wrote the above that the reasons are so fundamental as to
go with-</tt>
<br><tt>out further discussion.&nbsp; However, perhaps the following will
make this</tt>
<br><tt>more clear.</tt><tt></tt>
<p><tt>We have sent the child out into the yard again on our hunt for hard</tt>
<br><tt>evidence, and shortly the child comes back and we notice the child's</tt>
<br><tt>clothes are smudged, in disarray, the face of the child seems bruised</tt>
<br><tt>and scratched, and the child is crying.&nbsp; The mother of the
child is</tt>
<br><tt>on-hand, and I expect we all know what the mother is going to say
...</tt><tt></tt>
<p><tt>The mother demands, ``What happened?''</tt><tt></tt>
<p><tt>The child sobs, ``A big boy hit me and pushed me down!''</tt><tt></tt>
<p><tt>Now assuming that, say, the assault is serious, what do we think
the</tt>
<br><tt>mother will say and do?&nbsp; Will finding out the name of this
boy be of</tt>
<br><tt>significant or little relevance?&nbsp; Do we want to find this
boy and</tt>
<br><tt>make our displeasure clear?&nbsp; Do we want to find his parents
and let</tt>
<br><tt>them know it is their responsibility to correct and prevent this</tt>
<br><tt>behavior?&nbsp; The purpose of a name is to make a (relatively)
unique</tt>
<br><tt>identification that is a major component of assigning responsibility.</tt><tt></tt>
<p><tt>I have been thinking about an interesting argument in which the</tt>
<br><tt>utility of information in the wide sense is best exemplified by</tt>
<br><tt>names, but I will not trouble you with that though it might be</tt>
<br><tt>interesting for an information technology news-group like this.</tt><tt></tt>
<p><tt>Whether or not anyone else has the determination to continue and</tt>
<br><tt>attempt to move the discussion forward, to perhaps work toward
a</tt>
<br><tt>more coordinated solution speaks to their commitment. I am here.</tt>
<br><tt>I&nbsp;have not bailed out.</tt><tt></tt>
<p><tt>Regards,</tt><tt></tt>
<p><tt>Neil Nelson</tt></html>

--------------624B5227847CADEC218E8DB5--

Article: 25124
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 27 Aug 2000 12:52:36 +1200
Links: << >>  << T >>  << A >>
daniel_elftmann@my-deja.com wrote:
<snip> 
> >  I can imagine it's quite easy (well, fast) to test a RAM based
> > device, but how do you test your brand new, OTP device ?
> > PGM a bundle with a swag of test patterns ..
> 
> The logic modules in the Actel antifuse devices are all tested via
> dedicated circuitry, which designers can also utilize for real time
> debug.  Designers can access internal nodes in the device after
> programming via the Silicon Explorer tool without having to further
> program the device.  Silicon Explorer has saved the day in many cases
> in my personal experience as an Actel FAE.  All Actel antifuse devices
> offer two probe pins.  Via these probe pins the output of all logic
> modules can be observed at the probe pins.  When needed for user I/O
> these two probe pins can also be used in the customers design.  This
> same circuitry is utilized during the testing of un-programmed devices
> to guarantee 100% functionality of the modules in the device prior to
> shipment of the blank devices.

 Interesting, so there is a bundle of latch/shift elements 'behind' the
user
resource. ( does nudge the die area up towards RAM designs, but you can
read a cell in a lot fewer latch elements than needed to configure it )

 Is this access Read only, or can you Read/Write ?

 Can you address READ the elements in any way, or is it just 
a very-long-bitstream ?

-jg


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