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

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

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

Custom Search

Messages from 24800

Article: 24800
Subject: Re: Fully contrained designs...
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Fri, 18 Aug 2000 13:10:52 -0700
Links: << >>  << T >>  << A >>
On Fri, 18 Aug 2000 17:31:52 GMT, beerbaron@my-deja.com wrote:

>Hi,
>
>I've been working a couple of designs and have heard that "your design
>really should be fully contrained" to acheive the best results.  Can
>someone give me a good definition of what fully constrained means?  Are
>they implying that I should provide timing contraints for every net in
>my design?
>

Hi - 

That's what it means to me: every path, "critical" or not, is covered
by a timing constraint.  In the Xilinx world, it means that, when you
run trce (the static timing analyzer) with the -u option, it reports
no unconstrained paths.

Why would anyone bother constraining paths that are completely
non-critical?  The idea is to avoid the embarrassing situation where
you overlook a single report of a path that doesn't meet timing
because it's buried amidst hundreds or thousands of reports of
unconstrained paths that don't matter.  Constraining all paths also
eliminates the possibility of the router creating a very, very long
delay on a path where just a long delay would have been OK.

Constraining all paths can be something of a pain in the butt, but
it's not as bad as it sounds.  You can often place constraints on
large sets of paths, rather than on individual paths.

Take care,
Bob Perlman



-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.cambriandesign.com
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 24801
Subject: Xilinx Xact & Alliance
From: Joe <ja.NOgallegosSPAM@boeing.com>
Date: Fri, 18 Aug 2000 21:05:03 GMT
Links: << >>  << T >>  << A >>
We have a number of legacy designs that incorporate Xilinx'x XC4000
series device. The new Alliance tools do NOT support the XC4000 series.
Any thoughts how I can persuade Xilinx to add XC4000 support to their
Alliance tools. Ironically, the data bitstreams generated from the old
XACT tools work in both the XC4000 and the new XC4000E series. Xilinx no
longer supports the old XACT tools. Seems like Xilinx have left many of
their customers in a bind.

Thanks in advance..

Article: 24802
Subject: Re: multiplying DLL in Virtex
From: "Alun" <alun101@DELETEtesco.net>
Date: Fri, 18 Aug 2000 22:42:14 +0100
Links: << >>  << T >>  << A >>
Multiply by 8x?
> The answer is NO.
> There are four DLLs in Virtex devices, but to multiply by 2 you need at
> least two BUFGs (if the source clock is external, one could be IBUFG).
> Because the CLKIN input of CLKDLL must be driven by a BUFG, you can
> only drive one more CLKDLL and you are out of BUFGs. Also keep in mind,
> that the frequency range for CLKIN of CLKDLL is 25-90MHz and for
> CLKDLLHF is 60-180MHz. Don't forget also the fact, that you can only
> use BUFGs to connect to CLKDLLs from the same side of the chip.

You can (I think, DLL rules are of Super-Byzantine complexity and they add
new constraints every 2 months or so) multiply by 2 or 4 on one side of the
Virtex and drive the resulting clock out on an OBUF and take it back in on
the other side to multiply by 4 or 2.
If you use Virtex-E you don't have to use a GCLK pin as a DLL clock input.
Watch the phase noise though, the spec is tight and every stage adds some
jitter. You may be out-of-spec doing x8.

Alun
Camdigital


Article: 24803
Subject: Re: Fully constrained designs...
From: "Austin Franklin" <austin@darkroom65.com>
Date: 18 Aug 2000 22:04:59 GMT
Links: << >>  << T >>  << A >>
Means the same thing to me too, Bob.  Well put.

Constraining the non-critical paths (like multi-cycle paths, or 'static'
signals, like a writeable register) will help routing, as the router will
know how hard it has to try on each net.

The other advantage of doing complete constraints is you do not need to do
timed simulation.  Providing your constraints are correct, and your design
meets this timing, your functional simulation will give you all the
simulation you need.

When constraining every net, you can group them, if you have one module
that every input or output to/from it have the same time spec, or every one
internal to that module, you can use a wild-card timing constraint like
FROM:FFS(FRED*):TO:FFS(FRED*) and that will constrain everything in that
block  to that TIMESPEC.  Or, FROM:FFS(FRED*):TO:FFS(*)...etc.

Yet another advantage, is you readily know what didn't make timing...


Bob Perlman <bobperl@best_no_spam_thanks.com> wrote in article
<fd5rps013bckun9rkjbpaobn976vq210ut@4ax.com>...
> On Fri, 18 Aug 2000 17:31:52 GMT, beerbaron@my-deja.com wrote:
> 
> >Hi,
> >
> >I've been working a couple of designs and have heard that "your design
> >really should be fully contrained" to acheive the best results.  Can
> >someone give me a good definition of what fully constrained means?  Are
> >they implying that I should provide timing contraints for every net in
> >my design?
> >
> 
> Hi - 
> 
> That's what it means to me: every path, "critical" or not, is covered
> by a timing constraint.  In the Xilinx world, it means that, when you
> run trce (the static timing analyzer) with the -u option, it reports
> no unconstrained paths.
> 
> Why would anyone bother constraining paths that are completely
> non-critical?  The idea is to avoid the embarrassing situation where
> you overlook a single report of a path that doesn't meet timing
> because it's buried amidst hundreds or thousands of reports of
> unconstrained paths that don't matter.  Constraining all paths also
> eliminates the possibility of the router creating a very, very long
> delay on a path where just a long delay would have been OK.
> 
> Constraining all paths can be something of a pain in the butt, but
> it's not as bad as it sounds.  You can often place constraints on
> large sets of paths, rather than on individual paths.
> 
> Take care,
> Bob Perlman

Article: 24804
Subject: Re: multiplying DLL in Virtex
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 18 Aug 2000 17:28:11 -0700
Links: << >>  << T >>  << A >>
Christophe,

It seems to be a waste of the resources, not to mention to use of most of
the global clock buffers, but there is no rule against cascading  X2
DLL's until you run out of routing resources.

Resultant output jitter from each stage is not strictly additive (jitter
never is, unless you have a poorly designed element).

Jitter tends to add as the square root of the sum of the squares (to a
first approximation).  The input jitter tolerance allows for this kind of
cascading.

We do try to think of all possible uses, no matter how strange or useless
they appear to us initially.  My 10 years on the US ATIS T1X1 Committee
as a synchronization and timing expert gives me some insight into the
problems of phase noise (jitter, wander).

Since the DLL has been introduced, we have characterized its ability to
track phase buildouts (as in switching between two clock sources of
slightly differring frequncies as filtered by a preceding PLL), and
looked at its ITU-T Jitter tolerance, jitter transfer, and residual
jitter spectral energy (e.g. G823,824, etc) for our telecoms customers.

For further details please contact me (email) directly at
austin.lesea@xilinx.com.  The DLL's span of input/output frequencies is
so wide that no equipment exists to make the measurements we require, so
we have to do these tests on a case by case basis with highly specialized
setups.  Customers tend to use many different 'magic' frequencies: 32.768
MHz, 38.88 MHz, 33 MHz, 66 MHz, 100 MHz, 133 MHz, 77.76 MHz, 155.52 MHz,
to name only a few.

Austin

Christophe Heyert wrote:

> Hi all,
>
> I was wondering if it is possible to use the Virtex Dll's to create a
> clock multiplied by a factor 8.
> The application notes only discuss clocks multiplied by 2 or 4.
> Thanks...
>
> Christophe

Article: 24805
Subject: Re: Xilinx Xact & Alliance
From: Ray Andraka <ray@andraka.com>
Date: Sat, 19 Aug 2000 00:43:35 GMT
Links: << >>  << T >>  << A >>
I run into this from time to time with customers.  You can't blame Xilinx for
not wanting to re-write the software to support old chips they no longer sell,
and haven't in about 5 years. (the M tools are a completely different set of
code than the old XACT tools, even to the point that they were done by entirely
different groups).  

That said, Xilinx has been touting one of the benefits of using SRAM based FPGAs
in products is that it  extended the tail end of the product lifecycle by
allowing upgrades to fielded products.  Can't do that too well if you don't
maintain the tools to modify the design.  Basically, that means keeping a
machine, the software and the dongles on hand for older designs if you
anticipate doing maintenance on them after the chip family expires on the
marketplace. The extended lifecycle is real, but it ain't free and it does
require you to have some foresight when you archive it as you are now finding
out.  At some point, it becomes cheaper to spin a new product based on new
parts.  When that point occurs depends on your threshold of pain.

Still, it would be nice for them to continue to make available software along
with minor upgrades to allow it to work on current machines (even if in a DOS
box).  



Joe wrote:
> 
> We have a number of legacy designs that incorporate Xilinx'x XC4000
> series device. The new Alliance tools do NOT support the XC4000 series.
> Any thoughts how I can persuade Xilinx to add XC4000 support to their
> Alliance tools. Ironically, the data bitstreams generated from the old
> XACT tools work in both the XC4000 and the new XC4000E series. Xilinx no
> longer supports the old XACT tools. Seems like Xilinx have left many of
> their customers in a bind.
> 
> Thanks in advance..

-- 
-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: 24806
Subject: Virtex BEL constraints--do they really do anything?
From: Ray Andraka <ray@andraka.com>
Date: Sat, 19 Aug 2000 04:05:20 GMT
Links: << >>  << T >>  << A >>
I haven't had any luch making these work, and sure as heck haven't found *ANY*
documentation on them.  Bret, care to give use more details, pointers to the
documentation or anything?  Can these be put in the netlist instead of in a UCF
(they are next to useless in the UCF)??


in article <394A5A8D.E26477CC@xilinx.com>,
 Bret Wade  <bret.wade@xilinx.com> wrote:
 >Hello Jon,
 >
 >Version 3.1i supports a BEL constraint for Virtex. Here's and example of
 >UCF syntax:
 >
 >INST inst_name BEL = {F, G, FFX, FFY, XORF, XORG} ;
 >
 >You  use RLOC/LOC/BLKNM etc. to determine the slice used and the BEL
 >constraint to determine the BEL within the slice.
 >
 >Regards,
 >Bret
 >

-- 
-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: 24807
Subject: Re: Xilinx design flow with Mentor
From: eml@riverside-machines.com.NOSPAM
Date: Sat, 19 Aug 2000 11:04:45 GMT
Links: << >>  << T >>  << A >>
On Fri, 18 Aug 2000 08:27:04 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:

>eml@riverside-machines.com.NOSPAM wrote:
>> 
>> On Wed, 16 Aug 2000 16:30:45 -0500, Paul Smith <ptsmith@indiana.edu>
>> wrote:
>> 
>> >It looks like the Mentor FPGA Advantage suite (Renoir, ModelSim, and
>> >Leonardo) will work for me.  Anyone out there have experience with this
>> >toolset for the Spartan II target?
>> >
>> >I assume I also need the Xilinx Alliance software?
>> 
>> You can't go wrong with ModelSim and Spectrum but, as for Renoir,
>> forget it unless you're a masochist and you've got lots of spare time.
>> If you need schematics, try to find a proper schematic tool you can
>> fit into your design flow. You'll need Foundation or Alliance as well.
>> 
>> Evan
>> 
>> PS: Ok, Mr. Mentor, that wasn't too bad, was it? I trust you won't be
>> mailing me about this....   :)
>
>I take it from the PS that you have gotten mail from someone at Mentor
>about your newsgroup postings? Have you had unpleasant experiences using
>the Mentor toolset?

Someone complained in comp.lang.vhdl recently that Mentor had tracked
him down from a newsgroup posting, and then complained to his
employer. Very dubious, to say the least. I haven't personally had any
problems. I've got no gripes with the toolset, apart from the one I
mentioned above.

Evan
Article: 24808
Subject: Re: Fully contrained designs...
From: eml@riverside-machines.com.NOSPAM
Date: Sat, 19 Aug 2000 11:05:20 GMT
Links: << >>  << T >>  << A >>
On Fri, 18 Aug 2000 13:10:52 -0700, Bob Perlman
<bobperl@best_no_spam_thanks.com> wrote:

>On Fri, 18 Aug 2000 17:31:52 GMT, beerbaron@my-deja.com wrote:
>
>>Hi,
>>
>>I've been working a couple of designs and have heard that "your design
>>really should be fully contrained" to acheive the best results.  Can
>>someone give me a good definition of what fully constrained means?  Are
>>they implying that I should provide timing contraints for every net in
>>my design?
>>
>
>Hi - 
>
>That's what it means to me: every path, "critical" or not, is covered
>by a timing constraint.  In the Xilinx world, it means that, when you
>run trce (the static timing analyzer) with the -u option, it reports
>no unconstrained paths.

And remember that, in general, it's not possible to get trce to report
"100% coverage" even if there aren't any unconstrained paths.

Evan
Article: 24809
Subject: Xilinx Student Edition Floorplanning
From: "T.SWIFT" <NOSPAMeconspeak@quinnet.com>
Date: Sat, 19 Aug 2000 22:03:28 GMT
Links: << >>  << T >>  << A >>
    Does anyone know how to do floorplanning using the Xilinx Student
Edition software? I am trying to improve the performance of a HDL design I
am working on using an Xess FPGA board.

Thanks,

T.Swift


Article: 24810
Subject: Re: Non-disclosures in job interviews, Round One
From: Neil Nelson <n_nelson@pacbell.net>
Date: Sat, 19 Aug 2000 15:05:48 -0700
Links: << >>  << T >>  << A >>
rickman wrote:

> Darren Kuhn wrote:
> >
> > "Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in message
> > news:966555960snz@amleth.demon.co.uk...
> > > In article <8ngv2n$o0l$1@news.drenet.dnd.ca>
> > >            qn42@hotmail.com "Darren Kuhn" writes:
> > >
> > >
> > > > I find this all kinda interesting considering I find myself on the
> > opposite
> > > > end of the scale, if I was to go for an interview I wouldn't be able to
> > talk
> > > > much about my abilities/areas of work because of the security issues
> > > > involved in my present work...and I doubt they would sign a NDA from me.
> > >
> > > Should you be talking about such issues without authorisation from your
> > > current employer? So, if you cannot talk about your current work how do
> > > you convince someone else you are worth employing?
> > >
> >
> > I wouldn't know as I haven't been looking for a change of venue.  What I do
> > know is that I can tell you the software/hardware systems that I work on,
> > just not what I do with them.
>
> I have done a lot of government work over the last 20 years and I have
> never been restriced in discussing the technical issues of my job. Only
> the application and system level issues which may reveal application
> details.
>
> This is in contrast to the commercial jobs I have had where the high
> level stuff is very much open and the details are often confidential.
>
> To Paul,
> Darren said NDA, not NSA  ;')
>
> --
>
> 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

Although I empathize with your discomfort about the NDAs, there
are many additional issues in interviews and employments
that one could be uncomfortable about.  The basic result is that
if you are interviewing with a well-regarded company, which
appears to be the case, this behavior over NDAs will go against
your chances of being employed by that company.  Frankly, if
you are interviewing with good companies, do not worry about it.
Expecting your interviewers to hand you documents of what
should not be disclosed seems a particularly counter-productive
effort.

I would say it is a common truism that people in business
managment are much more paranoid (whether justified or not)
about these things than the typical employee and that NDAs
among many other things are merely an expression of that
paranoia.  There is likely some correlation between high-paying
companies and degree of reasonable management paranoia.  I.e.,
economic advantage is, by definition, something that you have
that other people do not, and hence these businesses are trying
to keep what they have to maximize their economic advantage.
The critical period for these kinds of agreements occurs after you
have been employed for a while and actually find out the
interesting details.  If the paranoia holds true-to-form, you may
expect additional consideration based on the business' need to
minimize the likelihood of your movement to another, say,
competing company.  But you have to get employed first.

You might be God's gift to mankind for your particular skill area,
but your attitude seems to be a bit combative and arrogant, and
it will restrict your employment opportunities to the less desirable
jobs in terms of pay and status.  It is a common failing of technical
employees.  Also, the good jobs will tend to appear early in an
interviewing cycle with those less desireable trailing behind.  Plus
you commonly only get one slim chance with each company.

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.

Otherwise, it has been a very interesting thread.

Regards,

Neil Nelson


Article: 24811
Subject: Re: Further FPGA metastability questions
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Sat, 19 Aug 2000 22:08:24 +0000
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?
> 

Have we come full circle with computers?
In the 1950's you had large boxes connected with slow
cables. The logic in the boxes was tiny but fast. Memory
was slow random access or sequential delay line or drum.
Word length was long with very simple addressing modes -
direct,memory indirect,or stack to a single accumulator.

With ps logic and ns routing delays in FPGA's we are back to
fast logic but small amounts. Risc archtecture has the style
of the early machines with 3 operand fields. Static memory
is slow ( compared to the internal speed of the chip). Cache
memory loading from dram reminds me of a small drum.

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: 24812
Subject: Re: Xilinx Student Edition Floorplanning
From: Ray Andraka <ray@andraka.com>
Date: Sat, 19 Aug 2000 22:42:25 GMT
Links: << >>  << T >>  << A >>
i'm not sure if the graphical floorplanner is in the student edition or not.  If
it is, you'll find floorplanner.exe under the bin directory.   If it is, then
just run floorplanner and have fun.  If not, then you'll have to do
floorplanning the old fashioned way with graph paper and putting RLOCs in your
source or in a UCF (constraints) file.  The constraints are documented in the
libraries guide in the on-line documentation.  

"T.SWIFT" wrote:
> 
>     Does anyone know how to do floorplanning using the Xilinx Student
> Edition software? I am trying to improve the performance of a HDL design I
> am working on using an Xess FPGA board.
> 
> Thanks,
> 
> T.Swift

-- 
-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: 24813
Subject: Re: Xilinx Student Edition Floorplanning
From: "Jan Gray" <jsgray@acm.org>
Date: Sat, 19 Aug 2000 22:45:44 GMT
Links: << >>  << T >>  << A >>
"T.SWIFT" <NOSPAMeconspeak@quinnet.com> wrote in message
news:QuDn5.558$gM4.197667@dfiatx1-snr1.gtei.net...
>     Does anyone know how to do floorplanning using the Xilinx Student
> Edition software? I am trying to improve the performance of a HDL design I
> am working on using an Xess FPGA board.

I assume you are using F1.5i.

If you use schematics, you can attach RLOC attributes to primitives like
FDCE, to gate expressions via an FMAP, and to macros built up of same.

Since you use synthesis, you are out of luck.  That version of FPGA Express
doesn't pass attributes.  Later versions (e.g. in F2.1i, e.g. FPGA Express
3.x for some x) do, but they unhelpfully absorb FMAPs (see
www.fpgacpu.org/usenet/rope_pushing.html).  (Has this been fixed yet?)

In the Verilog version of the XSOC/xr16 project (www.fpgacpu.org/xsoc) that
is built with XSE F1.5i FPGA Express, I studied the XNF coming out of FPGA
Express, observed that registers and RAMs were given repeatable names, and
floorplanned those parts of my design using an external UCF file.  For
example:

INST vga_sr_reg<0> LOC=CLB_R14C1;
INST vga_pending_reg<0> LOC=CLB_R14C2;
INST p_dp_aregs_r0 LOC=CLB_R14C3;
INST p_dp_areg_reg<0> LOC=CLB_R14C3;
INST p_dp_bregs_r0 LOC=CLB_R14C4;
INST p_dp_breg_reg<0> LOC=CLB_R14C4;
INST p_dp_a_reg<0> LOC=CLB_R14C5;
INST p_dp_b_reg<0> LOC=CLB_R14C6;
INST p_dp_dout_reg<0> LOC=CLB_R14C7;
INST p_dp_pcs_r0 LOC=CLB_R14C12;
INST p_dp_ret_reg<0> LOC=CLB_R14C12;
INST vga_sr_reg<1> LOC=CLB_R14C1;
INST vga_pending_reg<1> LOC=CLB_R14C2;
INST p_dp_aregs_r1 LOC=CLB_R14C3;
INST p_dp_areg_reg<1> LOC=CLB_R14C3;
etc. for another 200 lines or so.

It was a kludge but it helped.  This partial floorplanning shaved several ns
off the cycle time, but it was still 25% slower than the properly
floorplanned schematic version.

Unfortunately it is awkward to floorplan synthesized *logic* and to apply
timespecs (tpthrus) to certain *nets* that get turned to mush by synthesis.
Sometimes you can place the code in question in a separate module,
synthesize retaining hierarchy, and then use wildcard 'INST base/mod/*
LOC=<range>' to lock a module down to a certain region.

Jan Gray
Gray Research LLC
www.fpgacpu.org



Article: 24814
Subject: Re: Non-disclosures in job interviews, Round One
From: Jon Kirwan <jkirwan@easystreet.com>
Date: Sat, 19 Aug 2000 16:25:19 -0700
Links: << >>  << T >>  << A >>
On Sat, 19 Aug 2000 15:05:48 -0700, Neil Nelson <n_nelson@pacbell.net>
wrote:

>Although I empathize with your discomfort about the NDAs, there
>are many additional issues in interviews and employments
>that one could be uncomfortable about.

This is true, of course.  However, high tech folks usually aren't
lawyers, as well.  And I've once experienced what perceptions over an
NDA can do to otherwise good relationships in a circumstance where,
without the NDA, the results would have been far better for all.

NDAs at interview time seem unnecessary to me.  There is little reason
for this kind of "preemptive salvo" on the part of the potential
employer -- since they don't even know the interviewee, yet.  They
have no evidence that this person has anything other than good intent.
And they are perfectly capable of, and should be, of controlling the
interview so that their proprietary concerns are not revealed on their
first contact.

If there is a follow-up, and if they are serious at that point and
believe that getting closure necessarily entails a disclosure, they
can sit down beforehand and write up a short list of those things they
intend to cover that they think is important to help the interviewee
make final decisions in their favor.  It is good practice, in fact, to
think these things out a little beforehand, in any case.  And once
that thought takes place, it is relatively easy to then transfer that
information onto an addendum of an NDA that provides a precise
expectation.

Precisely written expectations and understandings should be required
before signing a legal document, anyway.


>The basic result is that
>if you are interviewing with a well-regarded company, which
>appears to be the case, this behavior over NDAs will go against
>your chances of being employed by that company.

If that is the only company you intend to pursue, you'd want to do
everything in your power to "make them happy."  I'm certain that's
true.  But that is not the place an interviewee should be at, on first
contact.  They aren't bending over backwards to get approval at any
cost.  They should be in a position of balanced negotiation.  Frankly,
I'm sure that Rick Cole is no one's idiot and is not in a position of
begging for a handout.  He should act as an equal, not a beggar with
hat in hand.

It is irrelevant if something "goes against your chances."  If that's
the case, and it may be, it's just not your problem.  It's theirs.

Once you place yourself in the position of doing whatever it takes to
make everyone else happiest without self-regard, you will be a slave.
May as well put the shackles on and be done with it.


>Frankly, if
>you are interviewing with good companies, do not worry about it.

There is truth to this.  Most good companies aren't going to go
"ballistic" over trivia.  But I've seen too many times where some
within otherwise good companies can easily "get a bee in their bonnet"
over some perceived harm where none was likely or intended.  And it
soured much in the process, where 20-20 hindsight showed me that it
was an unnecessary waste.

Never underestimate how easily hurt feelings can arise over nothing at
all and what irrational actions that pain can engender.  There's no
real need to start out by creating a vague document that allows such
to occur, particularly when there's nothing going on in the interview
to require such protections.  Don't forget that Rick mentioned that
the 1st interviewer noted that they didn't intent to disclose
information requiring protection.  I believe that, too.  But the
document could possibly be interpreted by others who weren't present
at the interviews, later and in different circumstances, as making
Rick out to be a "bad guy."

For an initial interview, this kind of creation of risk just isn't
needed.  At least, I've not seen a case yet in my 30 years experience
where I believe so.  Perhaps you could make a case for it?


>Expecting your interviewers to hand you documents of what
>should not be disclosed seems a particularly counter-productive
>effort.

Why, exactly?  They do not have to hand over detailed descriptions of
the exact disclosures.  But an interviewee has every right to expect a
very clear understanding of exactly what a company intends to discuss
that it will later consider important, if they should go to court.
How can an interviewee properly protect their interests if it isn't
spelled out?  Can they read minds?

No.  There is exactly no counter-production in insisting on clarity.
I'm speaking from direct experience in these matters, as I suppose you
are.  But I cannot see why an addendum cannot be prepared, if there is
material to protect.

In any case, interviewers are in a position of power.  They have the
attorneys prepare the NDA for their own protection, they are
considering the offer of substantial paychecks and this means that
they have the potential of significantly directly impacting your life,
and they often are vested with far more resources than the
interviewee.  They may also have proprietary interests to protect,
sometimes more than the interviewee does (although I have to say that
I've had to prepare documents to protect my own interests before
joining companies, as well.)  They can afford the bit of thought it
takes to provide a fair statement of expectations that are clear
enough that the interviewee can properly adhere to them.  Blanket
statements won't cut it.


>I would say it is a common truism that people in business
>managment are much more paranoid (whether justified or not)
>about these things than the typical employee and that NDAs
>among many other things are merely an expression of that
>paranoia.  There is likely some correlation between high-paying
>companies and degree of reasonable management paranoia.  I.e.,
>economic advantage is, by definition, something that you have
>that other people do not, and hence these businesses are trying
>to keep what they have to maximize their economic advantage.
>The critical period for these kinds of agreements occurs after you
>have been employed for a while and actually find out the
>interesting details.  If the paranoia holds true-to-form, you may
>expect additional consideration based on the business' need to
>minimize the likelihood of your movement to another, say,
>competing company.  But you have to get employed first.

It's also often that, not understanding the technology all that well,
they think everything under the sun is theirs and theirs alone and
that they have to fight tooth and nail in a competitive arena where
all the gloves are off.  They are probably right about that part of
it.  But many business managers have no idea what is "theirs" and what
isn't and they think that if anyone decides against them as an
employer and then joins one of their competitors, that they must
disclose important details as a course of doing their job there.  They
assume that since they themselves would certainly "do what was
necessary" and "cheat and steal", that others would intentionally do
so too.  Or that if they don't do it on purpose, that they will
accidently do it.  So they then decide they have to pre-emptively
bring suit just to prevent the very employment, to mitigate their
risks.

It's nasty, the human ability to feel that others are disloyal or out
to get you.  But it's also not uncommon, it seems.  Starting out with
a blanket NDA without precision and a clear expression of expectations
is a sure fired way to help fire up these feelings at some point.
Clarity helps a lot to keep a clearly defined and rather objective set
of criteria that both sides can keep to.  There is no harm at all in
struggling to get that understanding.  My own feeling is that the 1st
interview is NOT the place for that extra effort, though.  Perhaps
when the first hurdle is crossed and it's a matter of getting closure
on the decision to employ, then the effort is worth doing.  But in all
cases, precision makes sense.


>You might be God's gift to mankind for your particular skill area,
>but your attitude seems to be a bit combative and arrogant, and
>it will restrict your employment opportunities to the less desirable
>jobs in terms of pay and status.

I didn't see any arrogance in Rick's comments at all.  He was very
considerate, in fact.  He was watching out for his own interests, a
bit, asking for an addendum to be included later.  But this is more
than reasonable.

If it is your belief that an interviewee should be unreasonably
deferential, passive, meek, and obsequious, I think you are asking far
too much.  There is a limit to such pandering.


>It is a common failing of technical
>employees.

There is balance in everything, of course.  Some technical employees
are as obnoxious as anyone can be.  But you don't prejudge them.  You
let their own characteristics let you know who they are.  Same is true
for the companies, as well.  Some are obnoxious, but you should not
start out with a chip on your shoulder when you go in to interview.
Each side must let the qualities of the other tell them who they are.
Not prejudice.

So, it is no more a common failing of technical employees than it is
of technical employers.  To suggest otherwise, is simple prejudice.


>Also, the good jobs will tend to appear early in an
>interviewing cycle with those less desireable trailing behind.  Plus
>you commonly only get one slim chance with each company.

So, what are you suggesting?  That an interviewee cow-tow and kiss the
feet of anyone who deigns to allow them an interview just so they can
"get the more desirable jobs?"

I'm currently working with a company I like a lot, but where I told
the VP of Engineering that so long as she had any control over the
projects she wanted me working on, I would refuse to consider working
on them.  It was the first time in my life where I got to that point,
frankly.  I'm naturally very easy to get along with and I enjoy what I
do a lot, teaching and working with people, and learning from others.
No one has ever told me that I'm hard to get along with or that I
don't care deeply about their own needs.

But she pushed all of my limits and I finally made a decision this
wasn't going to continue anymore.  It was the right decision, then and
after the fact.  I got a call from them a few years later, letting me
know she had left the company and wondering if I'd consider them.  The
result is a very good relationship with a deep and mutual respect and
an understanding of each other and what we need and care about.  One
of the better business and personal arrangements I have, now.  I'm
glad I said something, then.

Relationship is everything in business.  And signing any random NDA on
1st blush is a way of jeopardizing both existing and future ones
almost without a care.  I take my relationships far too seriously to
just sign such a thing and perhaps later hurt a relationship I already
have or may later develop and care about.

You have to stand up and not take your relationships in a cavalier,
casual and perhaps careless way.  Signing blanket NDAs on 1st meeting,
signing a visitor's log which effects similar things, is just such
carelessness that I'm mentioning.  You do such things only in a well
considered way.  And if a business insists that you act in a hasty,
reckless, and irresponsible fashion like that, then an interviewee is
only exercising their better concerns by walking carefully into them.

Rick acted well, with love and care and concern.  Not arrogance as you
suggest.  I think that same company would want him to act as well if
he were an employee but later looking elsewhere.

Relationship is everything.  And you don't show good concern by
showing reckless disregard.


>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
Article: 24815
Subject: Re: Non-disclosures in job interviews
From: murray@pa.dec.com (Hal Murray)
Date: 19 Aug 2000 23:27:42 GMT
Links: << >>  << T >>  << A >>

[Interesting discussion.]


[Beware of signing NDA snipped.]

> If the company asked you to describe how, for example, you'd design a
> data logger, what comeback would you have if they later used your
> ideas in one of their designs?

What's the big deal.  Let them use your ideas.

This is a job interview, right?  Aren't you willing to give an hour
of free consulting time to somebody in return for a good faith attempt
to get to know eachother better?

I consider job interviews to be hard work and very important, and
that holds for both sides.  You are going to be working with eachother,
hopefully for a long time.  An hour is cheap if you get good information.

You might also establish your reputation for future consulting work
or meet eachother again later on.



If somebody asked me to sign an NDA, I'd try to find out what's going
on.  Common sense and good faith are probably as important as the legal
fine print.  If they can't explain why they want you to sign the NDA in
ways that make sense, they probably won't be able to explain other policy
issues either, and I probably don't want to work for/with them.  (I'll take
a lot of "trust me on this one" type answers, but only from people who
have established that trust over en extended period of time.)

If there are legitimate NDA issues involved, I'd probably try to break
the interview into two stages - before and after signing the NDA.  I'd
be willing to make a second trip if the pre-NDA stage looked promising.



There are several types of information that can be protected by NDAs.
One is schedule and marketing plans - product launch is Oct 12th.
Another is stratigic shifts - we are going into the medical business
sector.  There are also technical ideas.

A signed NDA covers the clean/obvious cases - you would be asking for
troubles if you sold sensitive information to a competitor.  But there
is also a lot of good faith involved.  The usual paperwork includes
something like "until you learn it from other sources".  If you know
a secret, it's a lot easier to keep an eye out for information that is
relevant and/or interpret what you learn correctly.

I have asked friends/partners "How much can I tell others?  What do
you want kept quiet?".  One reasonable answer is "nothing/everything",
but in that case, they won't get any leads/referals from me.


Some technical ideas are patentable.  These have to be kept secret
until the patent is filed.  An NDA for this makes sense, but only if
you have to discuss that area.  I'd expect most of an interview could
avoid discussing patentable ideas.

Some technical ideas are just engineering details.  There are probably
many solutions to the problem, you just have to find one that works well.
I'm thinking of a good chip for the job, or a "trick" for clocking,
the type of things that get discussed on newsgroups.  I'm generally
willing to give away my "consulting time" on things like that.  It's
a way to get to know people and let them get to know you.  I'd put
the data logger example above into this category - at least the initial
BSing about the problem.

Silicon Valley is amazingly small at times.  The guy you help today
might return the favor tomorrow, perhaps with a technical tidbit or
perhaps with a lead on a job.

Of course, somebody might be trying to rip you off for some
free consulting disguised as a job interview.  I guess I'm willing
to take that risk.  It's probably costing them a lot of time and
effort to go through their half of the interview process too.
-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 24816
Subject: Re: Further FPGA metastability questions
From: murray@pa.dec.com (Hal Murray)
Date: 19 Aug 2000 23:53:18 GMT
Links: << >>  << T >>  << A >>

> I, as a customer of Xilinx, care about getting information on metastability. 
> Crossing clock domains is something that can't be avoided.  Should I have told
> the salesman when we ordered a small pile of XCV3200E's today that metastability
> information is important?  Would that help?


Me too.

And I want the info for worse case conditions, not just typical.

I'll take better-than type numbers if things are hard to measure.

-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 24817
Subject: Re: Further FPGA metastability questions
From: murray@pa.dec.com (Hal Murray)
Date: 20 Aug 2000 00:07:21 GMT
Links: << >>  << T >>  << A >>

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.
Article: 24818
Subject: Re: Non-disclosures in job interviews
From: Jon Kirwan <jkirwan@easystreet.com>
Date: Sat, 19 Aug 2000 17:19:23 -0700
Links: << >>  << T >>  << A >>
On 19 Aug 2000 23:27:42 GMT, murray@pa.dec.com (Hal Murray) wrote:

>
>[Interesting discussion.]
>
>
>[Beware of signing NDA snipped.]
>
>> If the company asked you to describe how, for example, you'd design a
>> data logger, what comeback would you have if they later used your
>> ideas in one of their designs?
>
>What's the big deal.  Let them use your ideas.
>
>This is a job interview, right?  Aren't you willing to give an hour
>of free consulting time to somebody in return for a good faith attempt
>to get to know eachother better?

I think this is an excellent point.  The company is distracting
otherwise good employees because they need to find other good ones,
and the process is a two way street.  Both may have something the
other wants.  If neither side can afford the time to talk, they just
shouldn't be talking at all.


>I consider job interviews to be hard work and very important, and
>that holds for both sides.  You are going to be working with eachother,
>hopefully for a long time.  An hour is cheap if you get good information.

Yup!


>You might also establish your reputation for future consulting work
>or meet eachother again later on.

Yes.  But don't forget that signing a blank-check NDA may actually
cause trouble for a future and more important relationship, where
there is only emotional and irrational feelings hurt that could have
been avoided.

It doesn't usually present a problem, of course.  But why sign an
imprecise legal document protecting one side and risking feelings of
this or some future contact (or past one), all over a 1st interview
which may go nowhere?

Frankly, I don't need an NDA to prevent me from talking about what I
hear in a way that could cause harm.  It's not good business, anyway.
But if they don't trust my judgement or if they somehow need to be
absolutely sure that some things I don't realize should be protected
are, in fact, explicitly protected then they probably need to write it
down, anyway.  Just so I truly do understand.

I suspect NDAs may make sense, on the closing interview where an offer
will be discussed and considered and where more details may be needed
to make a final decision.  But by that time, both sides are closer and
more effort has been spent and the effort in forging a specific NDA
will make more sense to both sides.


>If somebody asked me to sign an NDA, I'd try to find out what's going
>on.  Common sense and good faith are probably as important as the legal
>fine print.  If they can't explain why they want you to sign the NDA in
>ways that make sense, they probably won't be able to explain other policy
>issues either, and I probably don't want to work for/with them.  (I'll take
>a lot of "trust me on this one" type answers, but only from people who
>have established that trust over en extended period of time.)

Yes.  I wouldn't slam my fist on first seeing an NDA.  But I would
probably look very closely at why, if it came up on a 1st interview.
And good sense is good sense.  There's no arguing with that.


>If there are legitimate NDA issues involved, I'd probably try to break
>the interview into two stages - before and after signing the NDA.  I'd
>be willing to make a second trip if the pre-NDA stage looked promising.

Yes.  This is an excellent approach and one I've been pushing for,
here.

<snip>


>Some technical ideas are patentable.  These have to be kept secret
>until the patent is filed.  An NDA for this makes sense, but only if
>you have to discuss that area.  I'd expect most of an interview could
>avoid discussing patentable ideas.

I'd think the 1st one certainly could!  If the company is in the
routine business of disclosing their ideas to every applicant on the
1st interview, so that they have to have a visitor's log with an NDA
built into every page and where they have all applicants sign a
separate one, too --  hehe, they probably aren't keeping any secrets.
Just scaring some folks.

<snip>


>Silicon Valley is amazingly small at times.  The guy you help today
>might return the favor tomorrow, perhaps with a technical tidbit or
>perhaps with a lead on a job.

It's small, also in part, because everyone is out for themselves with
a fervor and shift jobs almost as they might change dog food brands.
Few mentally invest in each other.


>Of course, somebody might be trying to rip you off for some
>free consulting disguised as a job interview.  I guess I'm willing
>to take that risk.  It's probably costing them a lot of time and
>effort to go through their half of the interview process too.

Yeah, it's worth the risk.  If you can't take that kind of risk, you
might as well just stay at home.

Jon
Article: 24819
Subject: Re: Permanently programming FPGAs
From: "Elftmann" <elftmann@pacbell.net>
Date: Sat, 19 Aug 2000 17:43:56 -0700
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message
news:399B274C.57D28844@xilinx.com...
>
>
> Renzo Venturi wrote:
>
> > "Use Actel anti-fuse FPGA...
> >
>
> You forgot the :-)
> Otherwise we are going to let out the secret about all the Antifuse FPGAs
used
> up in the debugging process.  :-)
>
> Peter Alfke
>
>

What a cheap shot Peter!

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!

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.


Article: 24820
Subject: Re: Further FPGA metastability questions
From: murray@pa.dec.com (Hal Murray)
Date: 20 Aug 2000 00:48:40 GMT
Links: << >>  << T >>  << A >>

> 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: 24821
Subject: Re: Permanently programming FPGAs
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 20 Aug 2000 01:19:00 GMT
Links: << >>  << T >>  << A >>
> > Renzo Venturi wrote:
> > > "Use Actel anti-fuse FPGA...
> > You forgot the :-)
> > Otherwise we are going to let out the secret about all the Antifuse
FPGAs
> used
> > up in the debugging process.  :-)
> > Peter Alfke
*********************************************************
> What a cheap shot Peter!
> 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!
> 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.
**************************************************************

     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



Article: 24822
Subject: Re: Permanently programming FPGAs
From: rk <stellare@nospamplease.erols.com>
Date: Sat, 19 Aug 2000 22:06:16 -0400
Links: << >>  << T >>  << A >>
"S. Ramirez" wrote:

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

I haven't tried them out yet, but there are BGA sockets that fit onto the same
pads where you would solder the device.

===========================================

>       Heck, he doesn't even have to blow it.  As I said earlier, all that
> is needed is a change to the design specification.

That is the biggest reason that I have encountered for device changes with good
designers on the job.

Hopefully we can all keep the flames toned down just a tad.  For the Silicone
Valley guys, aren't all of your sales and stock prices up?  Take a nice weekend
off and relax!

:-)

rk

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

"S. Ramirez" <sramirez@cfl.rr.com> wrote in message
news:8mGn5.29521$9T1.222871@typhoon.tampabay.rr.com...
> > > Renzo Venturi wrote:
> > > > "Use Actel anti-fuse FPGA...
> > > You forgot the :-)
> > > Otherwise we are going to let out the secret about all the Antifuse
> FPGAs
> > used
> > > up in the debugging process.  :-)
> > > Peter Alfke
> *********************************************************
> > What a cheap shot Peter!
> > 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!
> > 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.
> **************************************************************
>
>      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.




Article: 24824
Subject: Re: Permanently programming FPGAs
From: murray@pa.dec.com (Hal Murray)
Date: 20 Aug 2000 02:29:39 GMT
Links: << >>  << T >>  << A >>

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


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

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

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

Custom Search