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 24825

Article: 24825
Subject: Re: Permanently programming FPGAs
From: "Elftmann" <elftmann@pacbell.net>
Date: Sat, 19 Aug 2000 19:48:41 -0700
Links: << >>  << T >>  << A >>
Hal,

I very much agree with you.  Peter is a very valuable resource to the group.
But smilies or no smilies (yes, I saw it), I felt that it was a cheap shot
and not needed.

"Hal Murray" <murray@pa.dec.com> wrote in message
news:8nnfqj$p72@src-news.pa.dec.com...
>
> > What a cheap shot Peter!
>
> I saw the smilies.  Didn't you?
>
> Peter's track record here is very good.  He's one of the best examples
> I can think of for a vendor contributing to a newsgroup.  I used to
> follow some network group where somebody from Cisco had a similar
> reputation.  It's pretty easy to spot if you follow a newsgroup for
> a while.
>
> I think he has been very fair when discussing other vendors products.
> If I've been missing things, please point them out in the future.
>
>
>
> > Good designers that follow a disciplined design flow have no problem
using
> > Antifuse based FPGAs.
> >
> > It is very unfortunate that the RE-PROGRAMMABLE DESIGN BY THE SEAT OF
YOUR
> > PANTS BIGOTs insist that the design community is not good enough to use
> > Antifuse based FPGAs.  Fortunately there are many good designers out
there
> > using this technology!
>
> Sounds to me like there are bigots on the other side too.  Shouting
> doesn't make your case any stronger.
>
> People build ASICs and fully custome chips too.  They are all
> various points on spectrum of cost, time to market, and speed/size
> availability space.
>
>
> I admit that I belong to the seat-of-the-pants school, but I'm
> willing to learn, or at least try.  Do you have suggestions for how
> to design a chip when the specs aren't firm?
>
>
> Being able reprogram a chip after the board has shipped has saved
> my ass a couple of times.  Both quirks involved fuzzy areas in the
> specs.  No amount of testing would have uncovered the problem.
> (Having another person working on the project and looking at that
> area might have found them.  But I'll bet I could have explained
> why I had done what I did.)
>
>
> > Perhaps this newsgroup should be renamed comp.arch.XILINX_FPGA, as most
of
> > the issues/problems that come up in this group are in regards to Xilinx
and
> > not Altera, Actel, Quicklogic, or Lattice/Vantis.
>
> Perhaps all the good designers are using non-Xilinx chips and don't have
> any questioms to ask here.  ;)
>
> I haven't seen any serious complaints about too much Xilinx traffic.
> I'll be glad to support creating another group if that's a real problem.
>
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.
>


Article: 24826
Subject: Re: Further FPGA metastability questions
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 20 Aug 2000 03:04:02 GMT
Links: << >>  << T >>  << A >>


Hal Murray wrote:

> I frequently see comments here about silicon getting faster
> so metastability is less of a problem.  Is that really correct?
>
> Are there other mechanisims that work the other way, such as
> chips getting bigger and clock cycle times getting shorter?
>

Chips getting bigger is irrelevant, since metastability is located in a
latch.
Clock cycle times getting shorter is, of course, a problem. But
flip-flops are getting faster more so than the clock rates do, simply
because interconnects become more dominant.
We are now measuring clock-to-Q as low as 200 ps, but the interconnect
delays are longer.

Why did I not repeat the 1988 experiments, now with Virtex?
I would love to. But in order to do the exponential extrapolation, I
must actually count metastable events with two frequencies ( the ratio
of 65,000 used to be helpful). Then I can measure something in minutes
and extrapolate to MTBFs of thousands of years. Log paper is great !
If I see NO metastable events within my attention span, then I cannot
extrapolate. Sad to say.

To tell you that there was no metastable event in an hour, when you
allow, say, 2 extra nanoseconds of settling time ( or even 1 ns ) is
worthless information. You want to know the probability of one
metastable excessive delay of a few ns once per thousand years. I don't
have the time or patience to measure that .   :-(

So, until I find a clever way to engage the DLL and increment the clock
delay in steps of 40 picoseconds, ( that may be possible!), I am not
sure that I can say more than: Common sense tells me that the new
flip-flops are much better than the old XC4000 ones in resolving
metastability.

But I know you want quantitative information, not arm-waving
generalities....

Peter Alfke
Article: 24827
Subject: Re: Further FPGA metastability questions
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 20 Aug 2000 03:07:15 GMT
Links: << >>  << T >>  << A >>
Good suggestions!
I don't want to sound defensive, although I am explaining a bad situation.

Peter Alfke

Hal Murray wrote:

> > Recently, we tried it with Virtex parts, and did not immediately get any
> > meaningful results, so we abandoned the tests for the time being. We
> > were not able to bring the measuring clock edge close enough to the
> > first clock. The flip-flops are just too fast in resolving
> > metastability.
>
> Perhaps it's time for a new approach.  We've got a lot of smart
> people here - many are interested in this problem.
>
> I think there are two issues.  One is social, the other is technical.
>
> Here are some technical suggestions/questions:
>
> Why can't we use two clocks rather than the rising/falling edge?
> I assume the problem is that there would be skew within the chip.
> Can we find a way to correct for that?  How about two runs, one with
> clock A ahead of clock B and the other with clock B ahead of clock A?
>
> Can we find a way to collect data faster?  There are a lot of FFs
> in a modern chip.  Maybe we could run 100s of copies of Peter's basic
> circuit.  Peter's recipe involved 1 second runs.  We could also set
> things up to run overnight - 10,000 seconds.
>
> What sort of clock difference do we need?
>
> What sort of delays can we get with a bit of hackery?  I'm thinking
> of tricks like running a signal through a chain of CLBs to
> make a short delay.  Adding or deleting a CLB would make a pretty
> fine adjustment.
>
> I can't quickly find or derive the equations to compute the
> K1 and K2 type parameters from a pair of Peter's test runs.
>
> There are two unknowns and two data points, so it seems like
> a reasonable match.  But suppose you are using two clocks
> rather than both edges.  How well will two clock distribution
> chains track in a modern chip?  Can we correct for any skew
> with a 3rd data point?  (3 unknowns need 3 data points)...
>
> Now for some social issues.
>
> What can we do to make vendors pay attention to this issue?
>
> Is there any good journal that would take a letter to the
> editor or a short editorial type article?
>
> What do ASIC vendors do in this area?
>
> Would any of the companies who make FPGA prototyping boards
> be willing to let this sort of test run overnight and on
> weekends, perhaps while burning in a board?  I'm just fishing
> for a way to collect a lot more data.
>
>   It might be neat to see if there are any trends.
>
> Is this an appropriate topic for an undergraduate thesis?
> Anybody know a school that would be interested in this
> area?  Anybody willing to donate a board?
>
> Anybody got any other ideas?
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.

Article: 24828
Subject: Re: Permanently programming FPGAs
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 20 Aug 2000 03:21:32 GMT
Links: << >>  << T >>  << A >>
> >      These good designers that follow a disciplined anti-fuse design
> >  flow better start getting it EXACTLY correct the very FIRST time,
> > in spite of design changes mandated by design specification
> > changes.  The reason I say this is because FPGA design jobs are
> > getting so big that they demand BGAs to handle the extremely
> > large IO.  If one of these really good designers does a BIG job
> > and blows it (not the anti-fuses), it's going to be tough getting
> > that anti-fuse FPGA BGA off that board and putting another on.
> > It can be done, but it's a big pain in the pad layout.
> >        Heck, he doesn't even have to blow it.  As I said earlier,
> > all that is needed is a change to the design specification.
> >      So these really good designers either are going to be stuck
> > doing small FPGA designs or they're going to have to have
> > really good design specifications, have lots of time to do
> > extremely good simulation up front, and get everything extremely
> > correct the FIRST time.
> >      It is no wonder that Actel is desperately looking into
> > reprogrammable parts that seem to be unobtainium.
> >      I agree that this newsgroup is dominated by Xilinx and Altera,
> > but so is the market pie.
> > -Simon Ramirez
> >
********************************************************************
> Simon,
>
> All good points.  Issues that ASIC designers have faced forever.
> When companies such as Juniper, RedBack, Nexabit/Lucent,
> Cisco, etc.... go to the investment community, they are not
> highlighting their FPGA designs, they are highlighting their ASIC
> designs.
> Which only proves that complex designs can be done correctly
> the first time and EXACTLY correct the very FIRST time.
>
> Of course none of this is possible if engineering management
> does not demand a solid design specification.  It is common
> sense practice for ASIC designs to have a detailed design
> specification locked down before the design is taped out.
>
> I spent 10 years designing ASICs with multiple first pass silicon
> success.  Each of these designs required and had a detailed
> specification.
>
> I then spent 5 years designing FPGAs and PLDs (Xilinx, Altera,
> Actel, Lattice, AMD), for which management never required any
> specification at all.  I always wrote one, but was later dinged on
> my performance reviews for having done so.  My teams designs
> also set new company standards for prototype hardware
> availability to the software team.  Sorry, but I think that it is the
> design engineer's responsibility to ensure that the design has a
> well defined and locked down specification, before venturing into
> the design!   It is unfortunate that Design management has
> decided that a specification is not needed for FPGA designs and
> that designers no longer see the value in a design specification.
>
> If your happy with only having two choices when you choose a
> device for a programmable design, so be it.  But I believe that the
> design community is better served by multiple vendors offering
> multiple technologies to the design community.  I know that the
> community of designers implementing designs for the space,
> avionics, military, and medical markets appreciate the fact that
> they have antifuse technology as a choice.
>
> All BGA devices offered by Actel and Quicklogic have a very
> easy to use socketing solution and with improving technologies
> for BGA soldering and removal
> (http://www.zephyrtronics.com/frameset.htm) designers do have
> workable technology choice and we as a design community need
> to think twice before discarding this viable technology choice.
>
> Yes, Actel is investing in differentiated re-programmable
> technologies and will deliver them to the design community when
> they are ready.   But they also continue to invest in antifuse
> technology, because in areas of hi-reliability, design security,
> and increasing speed demands designers do want a quick turn
> programmable ASIC solution.
>
> Quicklogic also continues to churn out very good differentiated
> products.
>
> Both of these companies continue to survive and turn a profit
> despite the best efforts of the two titans to discredit and eliminate
> antifuse technology.
>
************************************************************************
Eltmann,
    Likewise you make some good points in your dialogue above.
     I disagree, though, about ASICs always being EXACTLY right the first
time.  I have seen ASICs churned out after much simulation and still have
some bugs.  Usually it was because the design specification was "designed"
wrong.  The end result was that software had to overcome these bugs through
patches that made for awkward coding and usage.  Many products are churned
out with ASICs that have bugs.  I've used consumer electronics that had
quirks, and some of these quirks were related to ASIC bugs.
     In my experience, I've seen ASICs churned out after being simulated in
a system, i.e., the whole system was simulated -- ASICs, FPGAs, board,
interfaces, computer hardware, computer software, etc.  The simulations were
incredible and fascinating.  There is nothing like them to get it right the
first time.  The problem was that there turned out to be an error with
modeling some of the parts.  No one caught it until after the product was
well in production and being used by the end users.  They caught the errors.
Software patched them, and the system worked with quirks.
     I also agree with you that a solid design specification is a must for
good design methodology; however, with bean counters running the show and
managers counting design minutes until the next milestone, sometimes it is
hard to write a good design specification.  I am a consultant that often
walks in on something that has to be done yesterday.  I value and treasure a
good design specification, but sometimes it just isn't possible.  In this
case, it is better to use reprogrammable parts and live with design changes
and iterations.  I think that is why most engineers prefer reprogrammable
parts over one time programmable parts.
     And I do acknowledge that there is a lot of sloppy engineering going
on.  In fact, I am aware of companies where the engineers don't simulate!
Some of these guys use the excuse that simulation tools cost too much!  It's
obvious that these guys are going to blow their schedule and budget if they
start designing big parts.  I remember simulating 22V10s, for God's sake!
     I agree with you that there are some applications where anti-fuse
devices are the only solution.  You mentioned space and military
applications, and I have actually designed in Actel devices into such
applications.  But that was a while back when device densities were not as
great as they are today.  More importantly, the packaging issue that I
brought up earlier is catching up to the anti-fuse technology.  RK posted a
message saying that he hasn't tried out BGA sockets, but he may try them
later.  I would suggest that as IO densities increase, the reliability of
BGA, especially FBGA, sockets will suffer.  I personally do not like
interconnect problems interfering with my debugging.  I have seen
interconnect problems make me think that they were functional problems
inside the FPGA.  If you have interconnect problems and are trying to fix
them functionally, then a great amount of time will be wasted.  This is why
I am not a proponent of anti-fuse FBGA (and denser) technology.
     Finally, I agree with you that there should be several players in the
FPGA market.  Competition is what made today's FPGA vendors produce much
better parts than 1,2,3,4,5,6,7,8,9 and even 10 years ago.  There is room
for all the players today, or they wouldn't be profitable as you say.  But
the reality is that there are two big vendors out there taking the majority
of the market pie, and both of them are in the reprogrammable parts
business.  It is not a coincidence; it is a fact that designers today prefer
reprogrammable parts over one-time programmable parts.
     I do admire you for wanting all engineers to have good design
methodologies where the outcomes are genuinely good working parts the first
time.  This is a goal that I try to achieve, and I have achieved that goal
some but not always.  It seems that there are always design specification
changes, screw ups on my part (no pun intended), mounting pressure on
schedules that cause me to rush, and countless other reasons/excuses.
Sometimes when I am being rushed, I think back and remember when I flipped
the power switch on with my manager watching and it worked the first time!
I was not amazed, but he certainly was!  He had never seen that before.
     Good luck on all of your present and future designs.
-Simon Ramirez, Consultant


Article: 24829
Subject: Re: Permanently programming FPGAs
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 20 Aug 2000 03:35:39 GMT
Links: << >>  << T >>  << A >>

--------------8A8E646CF2D381CCD31263F4
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

C'mon you guys, loosen up.
This brouhaha started with Renzo Venturi inserting "Use Actel.." into a
discussion of how to get from a Xilinx download cable to Master Serial
programming. Pretty trivial problem.
And I gave a tongue-in-cheek reprimand " use :-) when you do this..."

Now this has blown up into something big. That was not my intent. I will fight
any commercials in this newsgroup, but we also must have a sense of humor, or
at least of perspective.

Engineering is fun, especially when you can fix your own mistakes, as well as
accommodate your boss's oversight, or the evolution of the marketplace, even
after the system has shipped. That's one of the reasons why I like it where I
am.
Others may be proud to have designed a million-gate system without a single
mistake, and exactly to spec.  Not my cup of tea. We are all different...
(Thank God!)

Have a nice weekend, and smile occasionally !

Peter Alfke
=================================================
Renzo Venturi wrote:

> "
> > Also, If any of you know some web-sites that could provide information on
> programming FPGAs with PROM that would be helpful too.
> >
> > Thanks,
> > Ramy
>
> Use Actel anti-fuse FPGA...
>
>
> Renzo Venturi

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
C'mon you guys, loosen up.
<br>This brouhaha started with Renzo Venturi inserting "Use Actel.." into
a discussion of how to get from a Xilinx download cable to Master Serial
programming. Pretty trivial problem.
<br>And I gave a tongue-in-cheek reprimand " use :-) when you do this..."
<p>Now this has blown up into something big. That was not my intent. I
will fight any commercials in this newsgroup, but we also must have a sense
of humor, or at least of perspective.
<p>Engineering is fun, especially when you can fix your own mistakes, as
well as accommodate your boss's oversight, or the evolution of the marketplace,
even after the system has shipped. That's one of the reasons why I like
it where I am.
<br>Others may be proud to have designed a million-gate system without
a single mistake, and exactly to spec.&nbsp; Not my cup of tea. We are
all different... (Thank God!)
<p>Have a nice weekend, and smile occasionally !
<p>Peter Alfke
<br>=================================================
<br>Renzo Venturi wrote:
<blockquote TYPE=CITE>"
<br>> Also, If any of you know some web-sites that could provide information
on
<br>programming FPGAs with PROM that would be helpful too.
<br>>
<br>> Thanks,
<br>> Ramy
<p>Use Actel anti-fuse FPGA...
<br><a href="http://www.actel.com/"></a>&nbsp;
<p>Renzo Venturi</blockquote>
</html>

--------------8A8E646CF2D381CCD31263F4--

Article: 24830
Subject: Re: Further FPGA metastability questions
From: Ray Andraka <ray@andraka.com>
Date: Sun, 20 Aug 2000 04:05:54 GMT
Links: << >>  << T >>  << A >>
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.

Hal Murray wrote:
> 
> I frequently see comments here about silicon getting faster
> so metastability is less of a problem.  Is that really correct?
> 
> Are there other mechanisims that work the other way, such as
> chips getting bigger and clock cycle times getting shorter?
> 
> Can we make a Moore's Law type graph?
> 
> --
> 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: 24831
Subject: Re: Further FPGA metastability questions
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Sun, 20 Aug 2000 04:08:21 +0000
Links: << >>  << T >>  << A >>
Phil Hays wrote:
> 
> Peter Alfke wrote:
> 
> > To tell you that there was no metastable event in an hour, when you
> > allow, say, 2 extra nanoseconds of settling time ( or even 1 ns ) is
> > worthless information. You want to know the probability of one
> > metastable excessive delay of a few ns once per thousand years. I don't
> > have the time or patience to measure that .   :-(
> 
> Thank you, Peter.  I was under the mistaken impression your excess delay was
> tens of ps rather than 1 or 2 ns, and you still were not seeing any events.
> With a designed excess delay of a few ns, I thought that might be useful
> information.
> 
> Wit and humor:  With 1 ns excess delay, 520 V3200E parts, and 10000 metastable
> measuring FFs per V3200E, and look for a week?  See no events, that would imply
> MTBF estimated to 10,000 years.  Practical to implement?  Probably not.
>

I see a big problem in the future is clock jitter.You still have 
metastability problems of a different sort as clock speeds get higher.
You data can be on time for set/hold requirements but if your clock
jitters too much there go the setup and hold times.
Ben.
Article: 24832
Subject: Re: Permanently programming FPGAs
From: murray@pa.dec.com (Hal Murray)
Date: 20 Aug 2000 04:19:24 GMT
Links: << >>  << T >>  << A >>

>      I also agree with you that a solid design specification is a must for
> good design methodology; however, with bean counters running the show and
> managers counting design minutes until the next milestone, sometimes it is
> hard to write a good design specification.

It's part of my job and yours to tell the bean-counters
to jump in a lake if they are asking for stupid things.

Writing code before you know what you are doing has a long history
of contributing to botched projects.

For anybody who wants a good read, the classic book for software
people is "The Mytical Man-Month" by Fred Brooks.  My copy says it
was initially published in 1975.  There is a 25th year aniversary
version with another chapter.

If you have problem with a bean counter, I suggest you give them
a copy.  (I'm talking cash out of your own pocket.)

My favorite paragraph is on page 47:

  "It is a very humbling experience to make a multimillion-dollar
  mistake, but it is also very memorable.  I vividly recall the night
  ...

(Remember, those were 1960-1970 dollars.)


Note that there are two types of specs - the ones you control
and the ones provided by external organizations.  You can't fix
the external ones.  They are often fuzzy and sometimes even buggy.

Reprogrammable devices are a just another tool.  Maybe not the answer to
every problem, but a nice option to have available.
-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 24833
Subject: Metastability and antifuze
From: murray@pa.dec.com (Hal Murray)
Date: 20 Aug 2000 04:38:26 GMT
Links: << >>  << T >>  << A >>

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.
Article: 24834
Subject: Re: Further FPGA metastability questions
From: murray@pa.dec.com (Hal Murray)
Date: 20 Aug 2000 04:59:52 GMT
Links: << >>  << T >>  << A >>

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.
Article: 24835
Subject: Arg! 8051 - 6502 and friends
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Sun, 20 Aug 2000 05:07:50 +0000
Links: << >>  << T >>  << A >>

> XESS Corp. is releasing the eighth section of its "myCSoC" tutorial for
> free downloading at http://www.xess.com/myCSoC-CDROM.html.  We will
> release a new section each week.
> Each section describes a design example for the Triscend configurable
> system-on-chip device (CSoC).  The Triscend TE505 CSoC integrates an
> 8051 microcontroller core with a programmable logic array to create a
> chip whose software and hardware are both reprogrammable.

 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.

Also a tutorial using  FPGA from different manufactures would be useful
too.What kind of designs map better to what style of hardware.
For example I am developing a 24 bit home-brew cpu on a low cost <$100
protyping board. The only FPGA that will meet my size requirements
is Altera's 10K10 and still be in a low cost PLCC package and have easy
to find development software.I would rather use Actel's 42MX09? 
but I am still waiting on the FPGA software

Ben.
Article: 24836
Subject: Re: Permanently programming FPGAs
From: Phil Hays <spampostmaster@sprynet.com>
Date: Sat, 19 Aug 2000 23:05:14 -0700
Links: << >>  << T >>  << A >>
Elftmann wrote:

> Good designers that follow a disciplined design flow have no problem using
> Antifuse based FPGAs.

It's hard to follow a disciplined design flow when you have two different
specifications (and both are incomplete!) for the same function, and both are
different from what the programmers claim the function does.  I had this joyful
task as part of my first FPGA design.  We were designing a replacement for
hardware designed in 1969.

The ability to upgrade both hardware and software without opening the box also
can be very useful.

I think that EEPROM, antifuse and SRAM based programable parts all have
advantages, and I expect that all of them will be around for quite a while.


-- 
Phil Hays
Article: 24837
Subject: Re: Non-disclosures in job interviews, Round One
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 20 Aug 2000 02:29:35 -0400
Links: << >>  << T >>  << A >>
Most of this sub-thread has gotten into things that I don't care to
discuss, but I want to respond to one part. 


Jon Kirwan wrote:
> 
> On Sat, 19 Aug 2000 15:05:48 -0700, Neil Nelson <n_nelson@pacbell.net>
> wrote:
> >If you actually need a job, you need to stop screwing yourself
> >and get politically savy.  And it is quite easy to search the
> >newsgroups by poster name to find out a person's attitudes and
> >opinions.
> 
> If acting like an obsequious sycophant, fawning for a job, is your
> idea of being "politcally savy" then I hope fewer are as savy.
> 
> I don't think anything that Rick Cole said comes even close to
> reducing his appeal to employers, not here in this thread and
> certainly not in his other excellent posts.  Do you think so?
> 
> >Otherwise, it has been a very interesting thread.
> 
> I agree.
> 
> Jon

I have had several people contact me about work from reading this
thread. So I don't think that I have scared anyone off my my "attitude".
On the other hand one of them indicated that I would have to sign a NDA
to interview with them.  :-)


-- 

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: 24838
Subject: Re: Further FPGA metastability questions
From: Phil Hays <spampostmaster@sprynet.com>
Date: Sat, 19 Aug 2000 23:29:42 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> To tell you that there was no metastable event in an hour, when you
> allow, say, 2 extra nanoseconds of settling time ( or even 1 ns ) is
> worthless information. You want to know the probability of one
> metastable excessive delay of a few ns once per thousand years. I don't
> have the time or patience to measure that .   :-(

Thank you, Peter.  I was under the mistaken impression your excess delay was
tens of ps rather than 1 or 2 ns, and you still were not seeing any events. 
With a designed excess delay of a few ns, I thought that might be useful
information.

Wit and humor:  With 1 ns excess delay, 520 V3200E parts, and 10000 metastable
measuring FFs per V3200E, and look for a week?  See no events, that would imply
MTBF estimated to 10,000 years.  Practical to implement?  Probably not.


-- 
Phil Hays
Article: 24839
Subject: Metastability measurement
From: murray@pa.dec.com (Hal Murray)
Date: 20 Aug 2000 07:03:55 GMT
Links: << >>  << T >>  << A >>

This might be a crazy idea, but then maybe I'll learn something
when it gets shot down.


Peter reports that he didn't get enough errors to measure.  How
about making errors happen (much) more often?

Suppose the input data isn't asynchronous but we adjust it to
have at the worst possible timing.  I'm thinking of a feedback
loop (PLL) to adjust the timing of the input data transition
so that the output follows it half the time and misses the other
half.

Is that likely to make enough errors to measure conveniently?
If the answer is still "no", would you believe there is no
longer a metastability problem?  1/2 :)

Note that you still need another mechanisim to adjust the
delay between the main clock and the clock for the FF
that catches the errors.  It might help to have a setup
where you can adjust the clock-high time and keep the period
fixed rather than adjust the clock frequency.

If we had data from this sort of setup, can we compute
the traditional mestability parameters?  Does the frequency
and/or PLL filter parameters matter, or do they drop out?


I think we could build that setup with a pair of analog
comparators.  The idea is to feed a sawtooth into one side
and adjust the DC (well filtered) signal going into the
other.  One comparator would generate the clock.  The other
would generate the data.  I'm thinking of a simple R-C filter.
We could generate the sawtooth input with a similar R-C filter
that has a much faster time constant.

-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 24840
Subject: tutorial on configurable system-on-chip design is available
From: Dave Vanden Bout <devb@xess.com>
Date: Sun, 20 Aug 2000 09:58:52 -0400
Links: << >>  << T >>  << A >>
XESS Corp. is releasing the eighth section of its "myCSoC" tutorial for
free downloading at http://www.xess.com/myCSoC-CDROM.html.  We will
release a new section each week.

Each section describes a design example for the Triscend configurable
system-on-chip device (CSoC).  The Triscend TE505 CSoC integrates an
8051 microcontroller core with a programmable logic array to create a
chip whose software and hardware are both reprogrammable.  The tutorial
examples show how the Triscend FastChip development software is used to
configure the TE505's programmable logic into peripheral functions that
cooperate with the microcontroller core.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||
Article: 24841
Subject: Re: Arg! 8051 - 6502 and friends
From: Chris Hills <chris@phaedsys.org>
Date: Sun, 20 Aug 2000 16:43:35 +0100
Links: << >>  << T >>  << A >>
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.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Article: 24842
Subject: Re: Metastability and antifuze
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 20 Aug 2000 15:55:42 GMT
Links: << >>  << T >>  << A >>
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.

Article: 24843
Subject: Re: Permanently programming FPGAs
From: "Eric Braeden" <braeden@erinet.com>
Date: Sun, 20 Aug 2000 11:56:10 -0400
Links: << >>  << T >>  << A >>

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: 24844
Subject: Re: Metastability measurement
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 20 Aug 2000 16:01:04 GMT
Links: << >>  << T >>  << A >>
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.

Peter Alfke
=============================
Hal Murray wrote:

> This might be a crazy idea, but then maybe I'll learn something
> when it gets shot down.
>
> Peter reports that he didn't get enough errors to measure.  How
> about making errors happen (much) more often?
>
> Suppose the input data isn't asynchronous but we adjust it to
> have at the worst possible timing.  I'm thinking of a feedback
> loop (PLL) to adjust the timing of the input data transition
> so that the output follows it half the time and misses the other
> half.
>
> Is that likely to make enough errors to measure conveniently?
> If the answer is still "no", would you believe there is no
> longer a metastability problem?  1/2 :)
>
> Note that you still need another mechanisim to adjust the
> delay between the main clock and the clock for the FF
> that catches the errors.  It might help to have a setup
> where you can adjust the clock-high time and keep the period
> fixed rather than adjust the clock frequency.
>
> If we had data from this sort of setup, can we compute
> the traditional mestability parameters?  Does the frequency
> and/or PLL filter parameters matter, or do they drop out?
>
> I think we could build that setup with a pair of analog
> comparators.  The idea is to feed a sawtooth into one side
> and adjust the DC (well filtered) signal going into the
> other.  One comparator would generate the clock.  The other
> would generate the data.  I'm thinking of a simple R-C filter.
> We could generate the sawtooth input with a similar R-C filter
> that has a much faster time constant.
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.

Article: 24845
Subject: Re: Metastability and antifuze
From: "Elftmann" <elftmann@pacbell.net>
Date: Sun, 20 Aug 2000 09:46:53 -0700
Links: << >>  << T >>  << A >>
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.

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.
>


Article: 24846
Subject: Re: Non-disclosures in job interviews, Round One
From: Neil Nelson <n_nelson@pacbell.net>
Date: Sun, 20 Aug 2000 10:09:40 -0700
Links: << >>  << T >>  << A >>
rickman wrote:

> Most of this sub-thread has gotten into things that I don't care to
> discuss, but I want to respond to one part.
>
> Jon Kirwan wrote:
> >
> > On Sat, 19 Aug 2000 15:05:48 -0700, Neil Nelson <n_nelson@pacbell.net>
> > wrote:
> > >If you actually need a job, you need to stop screwing yourself
> > >and get politically savy.  And it is quite easy to search the
> > >newsgroups by poster name to find out a person's attitudes and
> > >opinions.
> >
> > If acting like an obsequious sycophant, fawning for a job, is your
> > idea of being "politcally savy" then I hope fewer are as savy.
> >
> > I don't think anything that Rick Cole said comes even close to
> > reducing his appeal to employers, not here in this thread and
> > certainly not in his other excellent posts.  Do you think so?
> >
> > >Otherwise, it has been a very interesting thread.
> >
> > I agree.
> >
> > Jon
>
> I have had several people contact me about work from reading this
> thread. So I don't think that I have scared anyone off my my "attitude".
> On the other hand one of them indicated that I would have to sign a NDA
> to interview with them.  :-)
>
> --
>
> 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

All too often we are not very clear as to our objectives.  If, e.g.,
an objective requires a little fawning and we do not fawn sufficiently,
we will not reach our objective.  Or if, e.g., our objective requires
less fawning, and we fawn excessively, we will not reach our
objective.  If our primary objective is to not fawn (or fawn, as the
case may be), then any other secondary objective that is against
not fawning (the primary) will not be obtained.

We might speak of how we would like the world to work or how
the world should work if it was just or fair, but commonly we can
only deal with how the world actually does work.  Clearly we
should work for world we want and believe to be fair, but that
objective is usually not one we can effectively pursue and one
almost certainly at odds with what others want and believe to be
fair.  Though when those few occasions arise that will allow us to
make some headway for a world we want and believe to be fair let
us make the best of it that we can.

What is our current, primary objective?

Is it to make a political (what we think is socially fair) statement
about NDAs?

Is it to get a large number of job interviews?

Is it to stand up for equality between employers and employees?

Is it to denounce fawning and other ``suggested'' undesirable
behaviors?

Is it to get a good job?

If our primary objective is to get a good job, then we will need a
sufficient number of job interviews, but a large number of job
interviews alone will not get us a good job.  I.e., we could trash
every job interview and we would not receive a job offer.  We need
to get a good job offer from a good company that we are willing to
accept, and it would be better to have several good offers from good
companies within a closely spaced period of time that would allow us
to evaluate and choose the best.  (The best method of getting a job
will depend on a number of factors such that those I am (we are)
making should not be assumed to be standard.)

Now that we have properly determined a best success path to our
primary objective, how can we fit in our position on NDAs without
needlessly injuring the expected success of our primary objective?

I personally think that NDAs have negligible or no impact on the
opportunities of the job seeker.  Plus it would seem rather difficult
for a company to bring suit against a job seeker for violating an
NDA except in very extreme, obvious cases.  E.g., to violate an
NDA, the NDA company would need to divulge some unique,
significant knowledge about their company that the job seeker
could then take to another company, which the second company
could then use in a manner that would be apparent to the first
company that the specific information had been transferred by the
particular job seeker.  This would be a very hard case to prove
without showing with reasonable certainty facts that the first
company would not reasonably have.  I.e., when and to whom
in the second company did the job seeker give the NDA
information?  It would seem that only the job seeker and second
company have this information, and as they would be the
defendants, they would not easily make this information known.

Rather NDAs are a formalization of an expectation of trust and
loyalty that is a basic given of employment.  The practical effect
of an NDA is to keep in mind something we should already have
in mind that employers (just like individuals) do not want their
company specific (personal) information spread around.  The job
seeker or employee would want, as a given, to show respect for
the privacy of the companies and individuals they become privy
to in the routine course of performing their job seeking and
employment activities.

For example, when I worked at a hospital I became privy to
medical information for a large number of people that we would
naturally think is the hospital's responsibility to keep private and
is becoming more now a legal responsibility.  What should a
hospital do in a case where a job seeker or employee shows an
obvious disregard for this non-disclosure requirement?  I expect
NDAs (and perhaps a little fawning) have a rather different look
when _you_ are the one being protected (and perhaps fawned).

Regards,

Neil Nelson

Article: 24847
Subject: Re: Metastability measurement
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Sun, 20 Aug 2000 10:27:26 -0700
Links: << >>  << T >>  << A >>
Hi - 

Take a look at p. 121 of Johnson and Graham, which describes just such
a circuit.  I haven't tried it, though.

Bob Perlman


On Sun, 20 Aug 2000 16:01:04 GMT, Peter Alfke <palfke@earthlink.net>
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.
>
>Peter Alfke
>=============================
>Hal Murray wrote:
>
>> This might be a crazy idea, but then maybe I'll learn something
>> when it gets shot down.
>>
>> Peter reports that he didn't get enough errors to measure.  How
>> about making errors happen (much) more often?
>>
>> Suppose the input data isn't asynchronous but we adjust it to
>> have at the worst possible timing.  I'm thinking of a feedback
>> loop (PLL) to adjust the timing of the input data transition
>> so that the output follows it half the time and misses the other
>> half.
>>
>> Is that likely to make enough errors to measure conveniently?
>> If the answer is still "no", would you believe there is no
>> longer a metastability problem?  1/2 :)
>>
>> Note that you still need another mechanisim to adjust the
>> delay between the main clock and the clock for the FF
>> that catches the errors.  It might help to have a setup
>> where you can adjust the clock-high time and keep the period
>> fixed rather than adjust the clock frequency.
>>
>> If we had data from this sort of setup, can we compute
>> the traditional mestability parameters?  Does the frequency
>> and/or PLL filter parameters matter, or do they drop out?
>>
>> I think we could build that setup with a pair of analog
>> comparators.  The idea is to feed a sawtooth into one side
>> and adjust the DC (well filtered) signal going into the
>> other.  One comparator would generate the clock.  The other
>> would generate the data.  I'm thinking of a simple R-C filter.
>> We could generate the sawtooth input with a similar R-C filter
>> that has a much faster time constant.
>>
>> --
>> These are my opinions, not necessarily my employers.  I hate spam.

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.cambriandesign.com
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 24848
Subject: Re: Arg! 8051 - 6502 and friends
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Sun, 20 Aug 2000 18:02:57 +0000
Links: << >>  << T >>  << A >>
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: 24849
Subject: Re: Non-disclosures in job interviews, Round One
From: Jon Kirwan <jkirwan@easystreet.com>
Date: Sun, 20 Aug 2000 12:00:15 -0700
Links: << >>  << T >>  << A >>
On Sun, 20 Aug 2000 10:09:40 -0700, Neil Nelson <n_nelson@pacbell.net>
wrote:

>All too often we are not very clear as to our objectives.  If, e.g.,
>an objective requires a little fawning and we do not fawn sufficiently,
>we will not reach our objective.  Or if, e.g., our objective requires
>less fawning, and we fawn excessively, we will not reach our
>objective.  If our primary objective is to not fawn (or fawn, as the
>case may be), then any other secondary objective that is against
>not fawning (the primary) will not be obtained.

Hehe.  I love your way of writing all that!


>We might speak of how we would like the world to work or how
>the world should work if it was just or fair, but commonly we can
>only deal with how the world actually does work.  Clearly we
>should work for world we want and believe to be fair, but that
>objective is usually not one we can effectively pursue and one
>almost certainly at odds with what others want and believe to be
>fair.  Though when those few occasions arise that will allow us to
>make some headway for a world we want and believe to be fair let
>us make the best of it that we can.

This kind of "I'm practical about life" kind of argument justifies all
manner of behavior and explains little.  But I do also understand that
it is a common way of saying, "I'm doing what I have to."

We all do what we must, but in practice there are wide ranges of
behavior that such practical considerations allow us.  In the end,
what really helps better to make a better world is when each of us
takes small actions together.  Not when we allow others to divide and
split us into expedient behaviors, practical for the moment.  The neat
thing that's even better about that, is that it actually can work out
better in the long run too, from a personal perspective.

Some folks will just fold their cards on the first push.  They can
make it worse for themselves and others, being so easy.  Luckily, we
do live in a day and age in the US where we actually *can* take a hike
from a company that's asking everyone to sign a visitor's log that is
also a sneaky contract and not look back.  Wasn't always that way.

I was born to a very poor family.  My dad died at 31 and we had very
little to live on.  I understand deeply the need to "do what one
must," since I've had to live on free dried bread from stores that
couldn't sell it and milk and sugar to add taste.  (I got to like it,
actually.)  And I'm glad for the efforts others have taken that allow
me to live a wonderful life today, work on wonderful projects, and not
to be treated poorly in spite of my meager beginnings.  I owe a lot to
the efforts of others.


>What is our current, primary objective?
>
>Is it to make a political (what we think is socially fair) statement
>about NDAs?
>
>Is it to get a large number of job interviews?
>
>Is it to stand up for equality between employers and employees?
>
>Is it to denounce fawning and other ``suggested'' undesirable
>behaviors?
>
>Is it to get a good job?

Well, just to be argmentative while staying truthful, my primary
objective is to work on interesting projects with good quality teams
of people.  I care about learning and I can't do that if I'm their
better resource, so I look for teams that have some folks who are
better than I am, smarter, more talented and love teaching others.  I
also look for projects that are, themselves, likely to educate me
about nature (physics) in some way, though they can be interesting in
other ways, too.

That's what a "good job" is, I think.


>If our primary objective is to get a good job, then we will need a
>sufficient number of job interviews, but a large number of job
>interviews alone will not get us a good job.  I.e., we could trash
>every job interview and we would not receive a job offer.

Accurately said.  "Sufficient number" is by definition necessary, of
course.

Problem is that you go on to smoothly add in "but a large number
of..." as though "large number" is implied by "sufficient number."
Sufficient could be just one.  But "1" is rarely seen as a "large
number."

So sufficient, yes.  That's a good premise.  But "large number" does
not logically follow this assumption, so your reasoning appears to be
slipping.  If you are now going to draw further conclusions from this
departure from sound logic, such conclusions will also be unsound.


>We need
>to get a good job offer from a good company that we are willing to
>accept, and it would be better to have several good offers from good
>companies within a closely spaced period of time that would allow us
>to evaluate and choose the best.  (The best method of getting a job
>will depend on a number of factors such that those I am (we are)
>making should not be assumed to be standard.)

I like this point.  It is better to have a choice between good
choices.  Life is complex and there are a variety of factors, unspoken
and explicit, to match up.  No choice will be perfect, so having more
means there is a better chance to find a more healthy and mutual match
up.

<snip>


>I personally think that NDAs have negligible or no impact on the
>opportunities of the job seeker.

That's your opinion, but the facts in my own life argue strongly
against this.

Most folks coming out of college and going to a work-a-day situation
will go from one employer to another.  If there are any troubles in
the process, it just winds up being on the shoulders of their prior
employer and their current one.  The employee can just let the "big
boys" settle these details amongst themselves.  They are, after all,
just a lowly employee.  They can't be expected to understand these
things.

For example, agreements about intellectual property rights are often
simply, "you own nothing and the company owns anything and everything
you think or do."  Close enough, anyway.  So, this employee now takes
another job, with a similar agreement.  Well, the employee has never
owned any of their ideas anyway, since every company they have worked
for has always had some similar agreement.  They have nothing to
protect and shouldn't care in the least if they sign one more of them.
Their new employer and the their old ones can work out amongst
themselves who owns what, if it should ever come to loggerheads.  But
the employee knows for sure that he/she simply doesn't care.  They own
nothing, no matter how it plays out.

But I've been self-employed most of my adult life.  I do have my own
interests, skills, ideas, and prior and existing relationships to
protect.  I have a past, in other words, and I actually own part of my
past, too.  I can't just sign a standard intellectual property
agreement.  Every case I've seen so far has required significant
modification -- and that includes those from Intel to much smaller
companies I've worked with.  Sometimes, the company figures it's not
worth the negotiation.  Sometimes, they figure otherwise.

But either way, I can't just sign a blind document.  I have a life.

And getting back to your "no impact" point, the fact is that NDAs *do*
have an impact.

I've been involved in such a case only a few years ago, where one
company sought to block me from contract work they had no business
attempting to halt.  After spending much time on the phone with their
president it simply boiled down to "they felt that my skills working
for this new company would significantly hamper their ability to
compete in the market and that their NDA allowed them to prevent me
from working there, because I might accidently spill something they'd
talked to me about."  However, I didn't intend on working on any
competing products there and that potential client of mine had no
intention of asking me to do so, either.

I had to get a lawyer involved to point out to them what I'm sure
their own lawyers had already told them -- that they had no case at
all.  But the real pain in this is that I had only the best feelings
for these people.  I liked them and wanted them to succeed.  I still
do and I wouldn't do anything to harm them.  More, the new company I
wanted to work for also had their interests honestly in mind too, in
spite of the fact that there was a slight competitive overlap, and had
explicitly told me that they would not ask me to get anywhere near any
of their projects that might be considered competitive.

This president and his company proceeded to destroy their working
relationships with several companies in the process, as well as their
ability to continue working with me, over a perception of harm that
simply didn't exist and still doesn't exist.  And when I talked to the
president later, all he could point to was his own perception of words
in the NDA and what power he felt it should entitle him to (and it
didn't.)

NDAs sometimes destroy, not for what they legally are, but for what
they emotionally represent.  I cannot ever forget that fact.


>Plus it would seem rather difficult
>for a company to bring suit against a job seeker for violating an
>NDA except in very extreme, obvious cases.  E.g., to violate an
>NDA, the NDA company would need to divulge some unique,
>significant knowledge about their company that the job seeker
>could then take to another company, which the second company
>could then use in a manner that would be apparent to the first
>company that the specific information had been transferred by the
>particular job seeker.
>
>This would be a very hard case to prove
>without showing with reasonable certainty facts that the first
>company would not reasonably have.  I.e., when and to whom
>in the second company did the job seeker give the NDA
>information?  It would seem that only the job seeker and second
>company have this information, and as they would be the
>defendants, they would not easily make this information known.

Few things actually reach a court of law.  As I mentioned above, that
case didn't reach court.  But relationships were destroyed, anyway.


>Rather NDAs are a formalization of an expectation of trust and
>loyalty that is a basic given of employment.  The practical effect
>of an NDA is to keep in mind something we should already have
>in mind that employers (just like individuals) do not want their
>company specific (personal) information spread around.  The job
>seeker or employee would want, as a given, to show respect for
>the privacy of the companies and individuals they become privy
>to in the routine course of performing their job seeking and
>employment activities.

There remains no reasonable basis I can imagine now, where a company
needs to disclose NDA-quality information on their first interview.
It's almost silly to imagine a company so reckless as to start
disclosing proprietary information to each and every applicant the
first time they see them.

I am still waiting for you to clarify a situation where such would be
appropriate and necessary.


>For example, when I worked at a hospital I became privy to
>medical information for a large number of people that we would
>naturally think is the hospital's responsibility to keep private and
>is becoming more now a legal responsibility.  What should a
>hospital do in a case where a job seeker or employee shows an
>obvious disregard for this non-disclosure requirement?  I expect
>NDAs (and perhaps a little fawning) have a rather different look
>when _you_ are the one being protected (and perhaps fawned).

Again, as a first interview, I rather doubt a responsible employer
would start disclosing such information.  An employee should be
responsible, of course.  But you are mixing logical elements here.
We've been discussing the case of NDAs for first time applicant
interviews.  Not NDAs, generally.

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.

Peace,
Jon


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