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 4125

Article: 4125
Subject: manchester clock recovery
From: DGILL@priacc.com
Date: Mon, 16 Sep 1996 13:24:04 +1000
Links: << >>  << T >>  << A >>
Hello all,

I'm working on a project where I need to do manchester
code conversion.  Output is easy, but input clock recovery
is less than trivial.  I need to know if anyone has a reference design
for an fpga to do this across 2048 bits.

Thanks,

dan
Article: 4126
Subject: Re: Implement FPGA multiplier using VHDL synthesis
From: Kayvon Irani <kirani@cinenet.net>
Date: Sun, 15 Sep 1996 22:27:53 -0700
Links: << >>  << T >>  << A >>
orachat@imap2.asu.edu wrote:
> 
> Are there anybody having experiences on writing VHDL code for FPGA
> multiplier? I would like to get a suggestion or openion which
> multiplication arichitecture is appropriate for FPGA. If you have sample
> VHDL source code, it will be wonderful!

Some VHDL synthesis tools sush as Exemplar can handle the multiplier
operator (*). To see which FPGA may be more appropriate for this function
if you don't have access to Exemplar check out the September issue of APP
Review by Synario Design Automation. Hope this helps.
Article: 4127
Subject: FPGA'97: Papers due on 9/27/96 (11 days away)
From: hauck@eecs.nwu.edu (Scott A. Hauck)
Date: Mon, 16 Sep 1996 10:34:30 -0500
Links: << >>  << T >>  << A >>
FPGA'97: Call for Papers

1997 ACM/SIGDA Fifth International Symposium on
Field-Programmable Gate Arrays

Sponsored by ACM SIGDA, with support from Altera, Xilinx, and Actel

Monterey Beach Hotel, Monterey, California
February 9-11, 1997
(Web page: http://www.ece.nwu.edu/~hauck/fpga97)

The annual ACM/SIGDA International Symposium on Field-Programmable Gate Arrays
is the premier conference for presentation of advances in all areas
related to the FPGA technology.  The topics of interest of this symposium
include, but are not limited to:

o Advances in FPGA architectures, including design of programmable logic blocks,
    programmable interconnects, programmable I/Os, and development of new
    FPGAs and field-configurable memories.

o New CAD algorithms and tools for FPGAs,  including new algorithms for
    sequential and combinational logic optimization, technology mapping,
    partitioning, placement, routing, and development of new FPGA synthesis or
    layout systems.

o Novel applications of FPGAs, including rapid prototyping, logic emulation,
    reconfigurable custom computing, and dynamically reconfigurable
    applications.

o Advances in field-programmable technology, including new process
    and fabrication technologies, and field-programmable analog arrays.

Authors should submit 20 copies of their original work by September 27, 1996.
Each submission should include an 100-250 words abstract, and is limited
in length to 12 pages (including figures and tables, minimum point size 10).
Notification of acceptance will be sent by November 18, 1996.
A proceedings of accepted paper will be published by ACM.
Authors must assign copyright of their accepted papers to ACM as a condition
of publication. Final versions of accepted papers will be limited
to seven pages, and must be submitted by December 6, 1996.
All submissions should include the e.mail addresses of the authors, as all
correspondence with authors will be done via e.mail.

Submissions should be sent to:

Prof. Jason Cong
FPGA'97 Program Chair
UCLA Computer Science Department
4711 Boelter Hall
Los Angeles, CA 90095
Phone: (310) 206-2775,  Fax: (310) 825-2273, E.mail:  fpga97@cs.ucla.edu

Organizing Committee:

General Chair:    Carl Ebeling, University of Washington
Program Chair:    Jason Cong, UCLA
Publicity Chair:  Scott Hauck, Northwestern University
Finance Chair:    Jonathan Rose, University of Toronto
Local Chair:      Pak Chan, UC Santa Cruz

Program Committee:

Michael Butts           Quickturn
Pak Chan                UCSC
Jason Cong              UCLA
Carl Ebeling            U. Washington
Masahiro Fujita         Fujitsu Labs
Scott Hauck             Northwestern Univ.
Dwight Hill             Synopsys
Brad Hutchings          BYU
Sinan Kaptanoglu        Actel
David Lewis             U. Toronto
Jonathan Rose           U. Toronto
Richard Rudell          Synopsys
Rob Rutenbar            CMU
Gabriele Saucier        Imag
Martine Schlag          UCSC
Tim Southgate           Altera
Steve Trimberger        Xilinx
Martin Wong             UT Austin
Nam-Sung Woo            Lucent Technologies
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|               Scott A. Hauck, Assistant Professor                         |
|  Dept. of ECE                        Voice: (847) 467-1849                |
|  Northwestern University             FAX: (847) 467-4144                  |
|  2145 Sheridan Road                  Email: hauck@ece.nwu.edu             |
|  Evanston, IL  60208                 WWW: http://www.ece.nwu.edu/~hauck   |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 4128
Subject: Good Starting points to learn FPGA for hobbyist?
From: cilibrar@ugcs.caltech.edu (Rudi Cilibrasi)
Date: 16 Sep 1996 18:02:23 GMT
Links: << >>  << T >>  << A >>
Hi there,

I've worked with PAL's and GAL's before, but never FPGA's.  I would
like to learn how to use them for hobbyist-type electronic projects.
Can anyone suggest good starting points for me?  i.e., any cheap or
free software that can be used, places to find information on fuse-file
formats (or whatever the equivalent is in FPGA's), websites, or books
that would be helpful in starting out?  I have a working 68hc11 interfaced
to my computer already, and can download code to it, so was hoping that
I might be able to use this as a programmer instead of shelling out more
$$$ for a hardware programmer in addition to whatever other costs are
involved in FPGA design.

Any tips (followup or through email) would be greatly appreciated,

-Rudi
Article: 4129
Subject: Re: Good Starting points to learn FPGA for hobbyist?
From: rauletta@erebor.cudenver.edu (Richard J. Auletta)
Date: 16 Sep 1996 22:42:46 GMT
Links: << >>  << T >>  << A >>
Rudi Cilibrasi (cilibrar@ugcs.caltech.edu) wrote:
: Hi there,

: I've worked with PAL's and GAL's before, but never FPGA's.  I would
: like to learn how to use them for hobbyist-type electronic projects.
: Can anyone suggest good starting points for me?  i.e., any cheap or
: free software that can be used, places to find information on fuse-file
: formats (or whatever the equivalent is in FPGA's), websites, or books
: that would be helpful in starting out?  I have a working 68hc11 interfaced
: to my computer already, and can download code to it, so was hoping that
: I might be able to use this as a programmer instead of shelling out more
: $$$ for a hardware programmer in addition to whatever other costs are
: involved in FPGA design.

: Any tips (followup or through email) would be greatly appreciated,

Pick up a copy of "VHDL for Programmable Logic" by Kevin Skahill which
includes for $49.95 the Warp2 software that will synthesize and place and
route to Cypress Semiconductor's C38X FPGA (and PLDs and CPLDs).
While simulation is only for PLDs and CPLDs (Nova JEDEC simulator)
if you have access to a VHDL or Verilog or Viewlogic simulator you can
do pre and post synthesis simulation.

Note the C38X family is one time programmable, most of the PLDs and CPLDs
are flash programmable and the C37X series of CPLDs are flash and
are also in circuit reprogrammable. Application notes and a PC to board
cable are available. The CPLDs get quite large and might be sufficient
for your needs.

-Rich Auletta
Article: 4130
Subject: Re: manchester clock recovery
From: hobart@rain.org (Kirk Hobart)
Date: Tue, 17 Sep 1996 05:35:39 GMT
Links: << >>  << T >>  << A >>
DGILL@priacc.com wrote:
>I'm working on a project where I need to do manchester
>code conversion.  Output is easy, but input clock recovery
>is less than trivial.  I need to know if anyone has a reference design
>for an fpga to do this across 2048 bits.

Clock recovery is usually done with an analog phase-locked loop. There
are several easy-to-use PLL chips that work over various frequency
ranges. I have had good luck with the AT&T T703X-series parts from
10MHz-100MHz.

Your comments about easy output and 2048 bits make no sense to me.
Please rephrase!
_________________________________________________________
Kirk Hobart   Santa Barbara, California   hobart@rain.org
Article: 4131
Subject: Inaccrate Xilinx simulations ???
From: sjadam@trog.dra.hmg.gb ()
Date: 17 Sep 1996 10:55:51 GMT
Links: << >>  << T >>  << A >>
I am currently evaluating Xilinx software tools and have built
a board with two XC4010 devices on it so that I can check for
hardware performance against that deduced by timing simulations.
The design which I decided to test first of all is an array of
fifteen up counters which are cascaded on to each other such 
that the output goes high when all fifteen counters have
completed. 
My design entry is VHDL and I used Mentor's Autologic 2 to 
synthesise the design. From here I generated a schematic and then
an xnf file for entry into the Xilinx PPR, etc. On completion
of place and route I observed that the XDelay tool figured that
the worst clock-to-setup delay was about 106nS i.e. 9.4MHz. I 
ran a full timing simulation on Mentor's Quicksim and sure enough
the maximum speed at which I could run the design before timing
violations was about 9.4MHz. My problem: when I configured a 
single XC4010 (which was fairly highly utilised) and increased
the system clock speed the design worked quite happily at over
20MHz before some of the counter elements  failed to operate as
required. 
Has anyone else had similar experiences of inaccuracies with the
Xilinx gate and layout delays or could you suggest what I might
be doing wrong. My devices are speed grade 4 and I've double
checked that I've set the synthesis tool and the Xilinx tools
up for this. I've also went straight to an xnf file from 
Autologic 2 i.e. without generating a schematic, and this made
no difference to XDelay results.
As it is I find these inaccurate estimations  intolerable for
forecasting device operating speed.

Thanks in advance

David Rennie
  
Article: 4132
Subject: Re: ? C to FPGA
From: ray@rucus.ru.ac.za (Ray Heasman)
Date: 17 Sep 1996 13:05:02 GMT
Links: << >>  << T >>  << A >>
roger gook (rgook@parsys.co.uk) wrote:
: > Mark Smotherman (mark@hubcap.clemson.edu) wrote:on the 4th Sept
: > : I would like to get pointers to any work on custom computing
: > : machines that transform selected C (or Fortran) routines into
: > : FPGA netlists.  I have found papers and links to PRISM-II, being
: > : done at the Lab for Engineering Man/Machine Systems at Brown
: > : University.  Are there other configuration compilers available,
: > : either at universities or from vendors?

Have a look for the BRASS and IRAM pages at Berkeley. They are working with
Stanford to make such compilers.

Cheerio,
Ray
--
             _/_/_/   ""\ ""\    ""\ ""\ """""""\ ""\   _/_/_/_/_/_/_/_/_/_/_/
           _/_/_/   """"\ """\  """\ ""\ ""\      """"\   _/ StarWriter  /  _/
         _/_/_/   ""\ ""\ ""\"""\""\ ""\ ""\ """\ ""\ ""\   _/    Genisys   _/
_/_/_/ _/_/_/   """"""""\ ""\ "\ ""\ ""\ ""\  ""\ """"""""\   _/            _/
 _/_/_/_/_/   ""\     ""\ ""\    ""\ ""\ """""""\ ""\     ""\   _/_/_/_/_/_/_/
   _/_/_/             Amiga - The canvas of the Gods.                













Article: 4133
Subject: Re: Inaccrate Xilinx simulations ???
From: Scott Kroeger <Scott.Kroeger@mei.com>
Date: Tue, 17 Sep 1996 08:36:03 -0500
Links: << >>  << T >>  << A >>
sjadam@trog.dra.hmg.gb wrote:
> 
> I am currently evaluating Xilinx software tools and have built
> a board with two XC4010 devices on it so that I can check for
> hardware performance against that deduced by timing simulations.
> The design which I decided to test first of all is an array of
> fifteen up counters which are cascaded on to each other such
> that the output goes high when all fifteen counters have
> completed.
> My design entry is VHDL and I used Mentor's Autologic 2 to
> synthesise the design. From here I generated a schematic and then
> an xnf file for entry into the Xilinx PPR, etc. On completion
> of place and route I observed that the XDelay tool figured that
> the worst clock-to-setup delay was about 106nS i.e. 9.4MHz. I
> ran a full timing simulation on Mentor's Quicksim and sure enough
> the maximum speed at which I could run the design before timing
> violations was about 9.4MHz. My problem: when I configured a
> single XC4010 (which was fairly highly utilised) and increased
> the system clock speed the design worked quite happily at over
> 20MHz before some of the counter elements  failed to operate as
> required.
> Has anyone else had similar experiences of inaccuracies with the
> Xilinx gate and layout delays or could you suggest what I might
> be doing wrong. My devices are speed grade 4 and I've double
> checked that I've set the synthesis tool and the Xilinx tools
> up for this. I've also went straight to an xnf file from
> Autologic 2 i.e. without generating a schematic, and this made
> no difference to XDelay results.
> As it is I find these inaccurate estimations  intolerable for
> forecasting device operating speed.


The deviation between the estimated and actual speed of your device is
due to Xilinx' guardbanding of timing specifications.  The timing
analysis is worst case, your part could be best case.  I'd be quite
angry if my hardware pooped out at the simulated maximum frequency. 
What assurance would I have that over temperature, voltage and process
variations my design would continue to work at that frequency?

Regards,
Scott
Article: 4134
Subject: How can I make my XILINX design faster?
From: Detlef Justen <justen@zess.uni-siegen.de>
Date: Tue, 17 Sep 1996 15:57:19 +0200
Links: << >>  << T >>  << A >>
Hello fpga users,

I made a projekt on an XC 4005-5 PC84 device. The schematic is structured. One of the hiraichal 
drawings works with about 20MHz Clock-Frequenzy and the rest only with 5MHz. The FPGA works fine. 
When I insert now a new Register or anything else into any file, I get timing problems. How can I 
solve this problem. Is there a posibility to say, that XILINX handle a spezific file or part of the 
projekt carefully and put all marked parts close together?

Thanks for help.

----------------------------------------
Name:    Detlef Justen
Company: Center for Sensor Systems
         University of Siegen
EMail:   justen@zess.uni-siegen.de
----------------------------------------
Article: 4135
Subject: FPGA'97: New due date, papers to appear in special issue of TVLSI
From: hauck@eecs.nwu.edu (Scott A. Hauck)
Date: Tue, 17 Sep 1996 10:21:50 -0500
Links: << >>  << T >>  << A >>
The due date for papers has been extended to October 4, 1996 (though
papers must ARRIVE by that date).  Also, selected papers from FPGA'97 will
appear in a special issue of IEEE Transactions on VLSI Systems.  See the
revised call for papers below for details.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1997 ACM/SIGDA Fifth International Symposium on
Field-Programmable Gate Arrays

Sponsored by ACM SIGDA, with support from Altera, Xilinx, and Actel

Monterey Beach Hotel, Monterey, California
February 9-11, 1997
(Web page: http://www.ece.nwu.edu/~hauck/fpga97)

The annual ACM/SIGDA International Symposium on Field-Programmable Gate Arrays
is the premier conference for presentation of advances in all areas
related to the FPGA technology.  The topics of interest of this symposium
include, but are not limited to:

o Advances in FPGA architectures, including design of programmable logic
    blocks, programmable interconnects, programmable I/Os, and development of
    new FPGAs and field-configurable memories.

o New CAD algorithms and tools for FPGAs,  including new algorithms for
    sequential and combinational logic optimization, technology mapping,
    partitioning, placement, routing, and development of new FPGA synthesis
    or layout systems.

o Novel applications of FPGAs, including rapid prototyping, logic emulation,
    reconfigurable custom computing, and dynamically reconfigurable
    applications.

o Advances in field-programmable technology, including new process
    and fabrication technologies, and field-programmable analog arrays.

Authors should submit 20 copies of their original work to the program
chair, with papers arriving no later than October 4, 1996.
Each submission should include an 100-250 words abstract, and is limited
in length to 12 pages (including figures and tables, minimum point size 10).
Notification of acceptance will be sent by November 18, 1996.
A proceedings of accepted papers will be published by ACM.
Authors must assign copyright of their accepted papers to ACM as a condition
of publication.  Final versions of accepted papers will be limited
to seven pages, and must be submitted by December 6, 1996.
All submissions should include the e.mail addresses of the authors, as all
correspondence with authors will be done via e.mail.

In addition, a special issue of selected papers presented in the
symposium will be published by IEEE Transactions on VLSI Systems in
the March issue.  The symposium authors will be invited to submit an
extended journal version of their work by March 31, 1997 for review
for publication in the special issue.  Notification of accepted papers
will be given by Sept. 15, 1997.

Submissions should be sent to:

Prof. Jason Cong
FPGA'97 Program Chair
UCLA Computer Science Department
4711 Boelter Hall
Los Angeles, CA 90095
Phone: (310) 206-2775,  Fax: (310) 825-2273,  E.mail: fpga97@cs.ucla.edu

Organizing Committee:

General Chair:    Carl Ebeling, University of Washington
Program Chair:    Jason Cong, UCLA
Publicity Chair:  Scott Hauck, Northwestern University
Finance Chair:    Jonathan Rose, University of Toronto
Local Chair:      Pak Chan, UC Santa Cruz

Program Committee:

Michael Butts           Quickturn
Pak Chan                UCSC
Jason Cong              UCLA
Carl Ebeling            U. Washington
Masahiro Fujita         Fujitsu Labs
Scott Hauck             Northwestern Univ.
Dwight Hill             Synopsys
Brad Hutchings          BYU
Sinan Kaptanoglu        Actel
David Lewis             U. Toronto
Jonathan Rose           U. Toronto
Richard Rudell          Synopsys
Rob Rutenbar            CMU
Gabriele Saucier        Imag
Martine Schlag          UCSC
Tim Southgate           Altera
Steve Trimberger        Xilinx
Martin Wong             UT Austin
Nam-Sung Woo            Lucent Technologies
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|               Scott A. Hauck, Assistant Professor                         |
|  Dept. of ECE                        Voice: (847) 467-1849                |
|  Northwestern University             FAX: (847) 467-4144                  |
|  2145 Sheridan Road                  Email: hauck@ece.nwu.edu             |
|  Evanston, IL  60208                 WWW: http://www.ece.nwu.edu/~hauck   |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 4136
Subject: Re: Inaccrate Xilinx simulations ???
From: eteam@aracnet.com (bob elkind)
Date: Tue, 17 Sep 1996 17:22:15 +0100
Links: << >>  << T >>  << A >>
Phil and Peter and others, it's about time I took one of these
questions... You've been carrying the major load, so this time
it's your time to relax...   :-)

David,

You're vexed because the Xilinx timing verifier said your design
would work at up to 9.4 MHz, but in fact you run your design on
one instance of the target FPGA at up to 20MHz.

I'm afraid you'll have to learn to live with this problem, both
with regard to Xilinx and all the other semi mfrs out there.

The timing verifier is there to give the designer an accurate
estimate of the *worst-case* delays (or operating frequency)
for any instance of the part/speed grade which passes the mfr's
production tests, whilst operating under the worst-case operating
conditions over which the AC specs are guaranteed in the data
book.

CMOS is notorious, actually *NOTORIOUS* for exhibiting wild
swings in AC performance (relative to bipolar, for example)
over process variations, junction temperature, and voltage.
The process variations can be largely factored out by the
mfr's production tests, but the worst case operating junction
temperature and operating voltage will have a significant effect
on the product's AC performance.

Were you running the device at low-voltage, with a weenie
plastic package (i.e. worst-case thermal properties), with
high on-chip power levels (to help warm up the junctions),
at elevated ambient air temperatures (like in an unvented
chassis) ?  And did you let the device warm up for a while
before you checked it at 20 MHz ?

My guess is that you were relatively easy on the device, but
a lot of Xilinx (and Lucent and Altera and TI and Moto and ...)
customers depend on the devices operating at rated speed under
these conditions, and these conditions are *not* all that
unrealistic.

And then the mfr will add some "error margin" to the timing
verification tool, or to the device testing, to ensure that
miscellaneous and/or unanticipated factors plu normal
measurement errors don't result in customers' products which
fail in the field.

There's a balance between being aggressive on spec'ing the
device speed and being meticulour/conservative on reliability.

Also, as process geometries shrink and average AC performance
vs. yield improves, there may not be enough fall-out parts
from the -3 speed grade bin to fill the demand for -4 (slower)
parts, so you may get a part that would qualify for -3 when
you order a -4 part (which will be *marked* as -4).

Xilinx, et al will guarantee absolute maximum delays, but not
absolute minimum delays. Guaranteeing minimum delays for
digital logic devices is very rare, and is usually found in
the bipolar (not CMOS) world, particularly ECL and/or
AS logic families.

There have been appnotes written for derating CMOS FPGA
AC performance vs. Junction Temp and VCC, and I believe
Xilinx and Lucent both include such charts, or their
equivalent, in their data books.  You can use the same charts
for "uprating" as well as "derating" performance, although
you should be careful and conservative when you do so.
The charts aren't guaranteed beyond the worst case "envelope"
described in the data books.

And by the way, you will sometimes see significant differences
between different manufacturers' versions of
worst-case operating conditions over which they'll guarantee
minimum AC performance.

So you won't be too happy using the timing verifier to predict
the min delays of your 4010-4.  But here's what *will* work...
You can use the timing verifier to accurately guage the
relative differences in performance between variations in your
design, run on the one instance of the 4010-4.  If the
timing verifier says 5 MHz instead of 9.4 MHz, you can be sure
that there will be a commensurate change in performance from
the 20 MHz you realised, as long as you test under the same
operating conditions.

Whew, I think I beat this one to death.  All those weeks of
reading posts instead of answering have resulted in excessive
accumulation of verbiage.

-- Bob Elkind

In article <51m03n$a7u@trog.dra.hmg.gb>, sjadam@trog.dra.hmg.gb says...
> I am currently evaluating Xilinx software tools and have built
> a board with two XC4010 devices on it so that I can check for
> hardware performance against that deduced by timing simulations.
> The design which I decided to test first of all is an array of
> fifteen up counters which are cascaded on to each other such 
> that the output goes high when all fifteen counters have
> completed. 
> My design entry is VHDL and I used Mentor's Autologic 2 to 
> synthesise the design. From here I generated a schematic and then
> an xnf file for entry into the Xilinx PPR, etc. On completion
> of place and route I observed that the XDelay tool figured that
> the worst clock-to-setup delay was about 106nS i.e. 9.4MHz. I 
> ran a full timing simulation on Mentor's Quicksim and sure enough
> the maximum speed at which I could run the design before timing
> violations was about 9.4MHz. My problem: when I configured a 
> single XC4010 (which was fairly highly utilised) and increased
> the system clock speed the design worked quite happily at over
> 20MHz before some of the counter elements  failed to operate as
> required. 
> Has anyone else had similar experiences of inaccuracies with the
> Xilinx gate and layout delays or could you suggest what I might
> be doing wrong. My devices are speed grade 4 and I've double
> checked that I've set the synthesis tool and the Xilinx tools
> up for this. I've also went straight to an xnf file from 
> Autologic 2 i.e. without generating a schematic, and this made
> no difference to XDelay results.
> As it is I find these inaccurate estimations  intolerable for
> forecasting device operating speed.
> 
> Thanks in advance
> 
> David Rennie
>   

-- 
**************************************************************************
Bob Elkind                mailto:eteam@aracnet.com            CIS:72022,21
7118 SW Lee Road                         part-time fax number:503.357.9001
Gaston, OR 97119                     cell:503.709.1985   home:503.359.4903
******** Video processing, R&D, ASIC, FPGA design consulting *************
Article: 4137
Subject: Re: Good Starting points to learn FPGA for hobbyist?
From: scanner@dial.pipex.com (Peter)
Date: Tue, 17 Sep 1996 18:28:46 GMT
Links: << >>  << T >>  << A >>

>: I've worked with PAL's and GAL's before, but never FPGA's.  I would
>: like to learn how to use them for hobbyist-type electronic projects.

I missed the original post, but I would recommend only RAM-based FPGAs
for this requirement. OTP parts will be too much hassle. Especially if
one is learning VHDL (or some dialect of) at the same time.

Furthermore, the cost of place-route software will probably rule out
Xilinx, which is a pity because they do good parts.

Peter.
Article: 4138
Subject: Re: manchester clock recovery
From: scanner@dial.pipex.com (Peter)
Date: Tue, 17 Sep 1996 18:28:47 GMT
Links: << >>  << T >>  << A >>

>I'm working on a project where I need to do manchester
>code conversion.  Output is easy, but input clock recovery
>is less than trivial.  I need to know if anyone has a reference design
>for an fpga to do this across 2048 bits.

You can do it with a one-shot. I can't remember the circuit, but it is
very simple. It should take only a few mins to work out.

The problem with a one-shot is that it needs to be accurate, which is
hard to do at high data rates. I was trying to do it at 10mbits/sec,
and it was hairy. I vaguely remember that the one-shot had to be set
to between 55 and 70% of the bit period, or something like that. It
was used as a pulse width discriminator.

A digital PLL is the normal way. I have done it with an analog PLL but
you have to be careful, because Manchester contains both F and 2F
components, and a simple analog PLL will lock onto either. I am sure
this can be overcome, but you need to watch this. You also need to
make sure there is enough preamble (which you can afford to lose) to
get things started.

You are right about encoding being trivial, normally it is just one
XOR gate, gating the clock and the data. But this gives you slightly
unequal bit widths, and there is a more ingenious circuit which is
normally used, which is better for higher data rates. This was
supplied to me years ago by Zilog, who apparently use it in their
85c30 SCC. A pity they also didn't give me the DPLL decoder from the
85c30, which is very good.

Peter.
Article: 4139
Subject: Re: How can I make my XILINX design faster?
From: Ray Andraka <randraka@ids.net>
Date: Tue, 17 Sep 1996 13:18:12 -0700
Links: << >>  << T >>  << A >>
Detlef Justen wrote:
> 
> Hello fpga users,
> 
> I made a projekt on an XC 4005-5 PC84 device. The schematic is structured. One of the hiraichal
> drawings works with about 20MHz Clock-Frequenzy and the rest only with 5MHz. The FPGA works fine.
> When I insert now a new Register or anything else into any file, I get timing problems. How can I
> solve this problem. Is there a posibility to say, that XILINX handle a spezific file or part of the
> projekt carefully and put all marked parts close together?
> 

1. Floorplan.  If you're using Xact 6, the graphical floorplanner makes 
this pretty easy.  If not, you need to delve into your reference guides 
that came with your earlier XACT software to learn how to floorplan. 

2. Use level compression. This means limiting the number of levels in 
your logic between registers to an appropriate amount.  As a rough rule 
of thumb, figure the prop delay to be twice the delay through the CLB to 
account for routing, then leave a bit of slack.  At 20 Mhz, you should be 
OK with less than 3 levels.

3. Design to the architecture.  Tailor your design to take advantage of 
the small fan-in and large number of ffs, the carry chains and the wide 
decodes.
Article: 4140
Subject: Re: manchester clock recovery
From: klee@mistress.informatik.unibw-muenchen.de (Herbert Kleebauer)
Date: Tue, 17 Sep 1996 14:32:48
Links: << >>  << T >>  << A >>
In article <323e355f.1976311@news.rain.org> hobart@rain.org (Kirk Hobart) writes:
>From: hobart@rain.org (Kirk Hobart)
>Subject: Re: manchester clock recovery
>Date: Tue, 17 Sep 1996 05:35:39 GMT

>DGILL@priacc.com wrote:
>>I'm working on a project where I need to do manchester
>>code conversion.  Output is easy, but input clock recovery
>>is less than trivial.  I need to know if anyone has a reference design
>>for an fpga to do this across 2048 bits.


Instead of the manchester code you can use a selfclocking code.
For this code you don't need a clock recovery (the delayed
input signal is the clock).


uncoded     coded data            received data
D7....D0    start-msb..lsb-stop   d7..d0-neg-stop    D7....D0

00000000    1-001001001001-00     00000000-0-0       00000000
00000001    1-001001001010-00     00000001-0-0       00000001
00000010    1-101101101011-00     11111101-1-0       00000010
   .                .                  .                .
   .                .                  .                .
   .                .                  .                .
11111110    1-001001001011-00     00000001-1-0       11111110
11111111    1-101101101101-00     11111111-0-0       11111111
   

DELAY must delay the signal 1.5 T (T is the transfer time for one Bit).

         +-----+     +----------------------+
       +-+DELAY+----->clock                 |
       | +-----+     | 5 Bit Shift Register |
       +-------------+data                  |
       |             +-----+--+--+--+--+----+
       |                   |  |  |  |  |             for di (0<=i<8):
       |                  neg d1 d3 d5 d7
       |                                               +-----+
       |                                            di-+     |
Din ---+                                               | xor +- Di
       |                                           neg-+     |
       |                                               +-----+
       |                 stop d0 d2 d4 d6
       |                   |  |  |  |  |
       | +-----+     +-----+--+--+--+--+----+
       +-+DELAY+O---->clock                 |
       | +-----+     | 5 Bit Shift Register |
       +-------------+data                  |
                     +----------------------+



For the byte synchronization a 5-counter (or for higher speed a 5 bit
shift register) is used. The automatic synchronization of the counter
with the datastream can be done with

- the stopbit (which must be always 0 for a correct synchronization)
  (shift the synchronization by 1 if the stopbit is 1)

- if there are more then 6 0-bits received (sender pause) the counter
  is reset

Because of the 2 stopbits you have 2 clock cycles to store the received
byte.

Article: 4141
Subject: Re: Inaccrate Xilinx simulations ???
From: daveb@iinet.net.au
Date: Tue, 17 Sep 1996 22:01:29 GMT
Links: << >>  << T >>  << A >>
sjadam@trog.dra.hmg.gb () wrote:
[snip]
>the worst clock-to-setup delay was about 106nS i.e. 9.4MHz. I 
>ran a full timing simulation on Mentor's Quicksim and sure enough
>the maximum speed at which I could run the design before timing
>violations was about 9.4MHz. My problem: when I configured a 
>single XC4010 (which was fairly highly utilised) and increased
>the system clock speed the design worked quite happily at over
>20MHz before some of the counter elements  failed to operate as
>required. 

 Remember that XDELAY always uses the worst-case parameters for its
calculations. You are guaranteed at least the speed indicated by
XDELAY. Practical designs do normally run much faster, however Xilinx
don't guarantee it.

--  Dave Brooks <http://www.iinet.net.au/~daveb>
PGP public key: finger  daveb@opera.iinet.net.au
                servers daveb@iinet.net.au
    fingerprint 20 8F 95 22 96 D6 1C 0B  3D 4D C3 D4 50 A1 C4 34
 What's all this? see http://www.iinet.net.au/~daveb/crypto.html

Article: 4142
Subject: Re: manchester clock recovery
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 17 Sep 1996 18:05:19 -0700
Links: << >>  << T >>  << A >>
That's easy.
I published a design in XCELL, the Xilinx quarterly journal, issue 17, 
2nd quarter 1995, page 30.
The design assumes an eight-times clock, which of course can be 
asynchronous to the incoming data. The clock must be faster than 5 times 
the incoming bit rate, and slower than 12 times. So there is plenty of 
margin.
The design takes three CLBs and has been simulated to operate in excess 
of 200 MHz clock rate, i.e. 25 MHz data rate, when implemented in an 
XC3120-2. ( It uses less than 5 percent of the available resources in 
that part ).

I can fax the schematic to anybody who requests it. 
( Proud father syndrome ).

Peter Alfke, Xilinx Applications
Article: 4143
Subject: Wanted: Verilog, Synopsys, ASIC
From: "Rensheng Horng" <rexhorng@pichon.stanford.edu>
Date: 18 Sep 1996 06:42:23 GMT
Links: << >>  << T >>  << A >>
A small public company located in Sunnyvale, CA, is 
looking for a candidate who

1. has strong ASIC design experience, 3+ year prefered,
2. is very familiar with Synopsys synthesis and 
   Verlog.

Knowledge with MPEG and video compression is a plus.

Please fax resume to 408-727-6275. H.R. Dept.

Our company offers very competetive salary and stock
option.
Article: 4144
Subject: A Survey on Design Errors
From: movahed@tumlis.lis.e-technik.tu-muenchen.de (M. Movahedin)
Date: 18 Sep 1996 08:45:31 GMT
Links: << >>  << T >>  << A >>



Dear ASIC/FPGA Designers,

hereby we would like to introduce the "A Survey on Design Errors"  WWW-server:

	http://www.lis.e-technik.tu-muenchen.de/DEP/

and invite all of you to visit it.

This server is installed to collect the opinions of ASIC and/or FPGA designers
regarding the concept of design errors and problems they can cause.  Our final
goal is to develop special technology extensions and synthesis algorithms that
allow the  designers to correct  their  mistakes even  after chip fabrication.
(This capability is named Correctability) These mistakes are principally those
design errors that  are made during  the design development steps and have not
been  found in  verification phases.   In order to get more familiar with this
subject, you can refer to:

	"Modeling of VHDL Design Errors and Methods for their Correctability",
	M.R. Movahedin, P. Kindsmüeller, W. Stechele,
	VHDL International Users' Forum, Spring 1996 (VIUF'96).

or get its postscript version from the server.

This survey will help us to  find out  what kind of  design errors  have to be
concentrated more on, and which imaginable ones are less important.

We  appriciate your efforts in filling out  this questionnaire,  and will send
you a copy of the processed results, if you provide us with an E-mail address.




Thank you  for taking time to 
visit and fill out the survey

Institute for Integrated Circuits
Technical University of Munich
Munich, Germany

For any question or further information, feel free to drop us a message:
	M_Movahedin@lis.e-technik.tu-muenchen.de

IMPORTANT: A e-mail version of the survey is available too. please contact us
	to send it for you by e-mail.

##############################################################################

The survey includes two groups of questions:

In the first group, some general questions about your experiences in ASIC/FPGA
design and the concept of design errors are asked.

The second part of the   questionnaire concentrates on a   (V)HDL design error
model.  This model is mainly based on the usually used synthesizable subset of
VHDL, but you can answer the questions, even if you are a Verilog user.

This model  deals mainly with the mistakes  made during the development of the
design  HDL description, and are  propagated to  gate level by  a synthesizer,
resulting  in a  flawed chip. In  view  of  the  fact  that  a  quite complete
simulation  and/or  verification of  a large design takes  a long time  and is
practically  impossible ,  those  flaws  could  not  be  detected  before chip
fabrication  and  only  after the chip  takes effect in the whole system, they
would be detected by observing the system malfunctions. Thus, a redesign, i.e.
rewriting the  HDL description and correcting its mistakes,  will be necessary
to achieve to a flawless chip.

The answer to the question why  these errors have happened and not detected in
verification phases is beyond  this questionnaire, and depends strongly on the
designers'  design  methodology.  But it can not be  forgotten that no one can
claim that his/her  design is quite  error free.  The  VLSI history shows that
even   large   powerful   companies   have   designed  and  fabricated  flawed 
microprocessors and their mistakes are first detected after a very long while.



Article: 4145
Subject: Re: Inaccrate Xilinx simulations ???
From: david@fpga.demon.co.uk (David Pashley)
Date: Wed, 18 Sep 96 09:46:26 GMT
Links: << >>  << T >>  << A >>
Failure to account for things like delay reconvergence, multicycle 
paths and asynchronous elements also come to mind as potential 
reasons for a pessimistic static timing analysis. 

Has anyone compared Xdelay results with tools such as Motive or 
Designtime?

-- 
David Pashley 

Article: 4146
Subject: CHDL '97
From: lsanchez@yeti.dit.upm.es (Luis Sanchez Fernandez)
Date: 18 Sep 1996 14:11:07 GMT
Links: << >>  << T >>  << A >>

Dear Sir/Madam,

please find below the Call for Papers for the CHDL'97 conference. You 
can also get more information about this event in the following URL:

http://www.it.uc3m.es/~ifip/chdl97/

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

Call for Papers

CHDL '97

XIII IFIP WG 10.5 Conference on Computer Hardware Description Languages and
Their Applications 1997

                               Silver Jubilee

                                  [Toledo]

              Hotel Beatriz - Toledo, Spain - 20-25 April 1997

----------------------------------------------------------------------------
CHDL has been held every other year since 1973, rotating between locations
in Europe, North America and Asia. The conference originated under IEEE/ACM
sponsorship and since 1981 has been organized by IFIP Working Group 10.2
(now WG 10.5).

The topic has had a significant history with over 100 HDLs published in the
1970s. Since the mid-1980s, HDLs have become commonplace in system design
and VLSI. This can be attributed to many factors including:

   * the advancing complexity of digital electronics, leading to more
     sophisticated modeling, simulation, and verification tools.
   * the migration of VLSI design to high-level synthesis based on HDLs
   * advances in microelectronics CAD toward support of system-level design
   * the increasing prevalence of generic and programmable components, of
     software-hardware and mixed digital-analog hybrid designs.

Presently, we are in a consolidation phase, in which languages and standards
are increasingly being used, at the same time as the scope is being
broadened to additional application areas (such as analog, microwave or
system-level design).

CHDL'97 will present the latest developments in the area in the form of
tutorials, invited talks, panel sessions and reviewed papers. In 1997, CHDL
will be celebrating its Silver Jubilee, and this will be a very special
occasion to learn from the past and look forward to what we might expect
from the future.

CHDL'97 will be held in conjunction with other workshops on closely related
areas:

   * the Spring '97 Working Conference of the VHDL Forum for CAD in Europe
   * the Esprit NADA workshop (about New Hardware Design Methods).
   * the Workshop on Libraries, Component Modelling and Quality Assurance

An exhibition will be held in parallel to these events.
----------------------------------------------------------------------------

Topics

The topics of CHDL include several emerging design methods and technologies
based on HDLs, including

   * Hardware Description Languages, Standards
   * Formal Methods
   * Verification and Validation
   * Design Analysis and Test
   * System-Level Specification and Design
   * High-Level Synthesis
   * Design Systems and Tools
   * New Application Areas

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

Submission of Papers

Contributions on these or related topics are solicited. Papers on original
research, experiences, reviews, and tutorial articles are welcome. Proposals
for special sessions are also invited (please contact the Program Chair).
Accepted papers will appear in proceedings published by Chapman & Hall. A
best-paper award will be given.

Papers (6 copies) should be submitted by 1 October 1996 to the Program
Chair. A cover page should specify

  1. title;
  2. authors and affiliation;
  3. mailing address, phone and fax numbers, and e-mail address of the
     primary author;
  4. a brief abstract; and
  5. one or two topics from the list to which the paper belongs.

Submissions should use A4 or 8.5" x 11" paper and be at most 20 pages in
length (minimum line spacing 1 1/2). Submission by e-mail to the Program
Chair <chdl97@iro.umontreal.ca> of PostScript files is preferred, but since
there may be printing or transmission problems, it is suggested that paper
copies be also sent by regular mail.

Important dates:

   * Submission deadline: 1 October 1996
   * Notification of acceptance/rejection: 29 November 1996
   * Camera-ready version: 22 December 1996
   * Conference: 20-25 April 1997

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

Toledo

Toledo is without doubt one of the cities with the greatest density of
monuments in the world. Nearly all the different stages of Spanish art are
represented in Toledo, which has Moorish-Mudejar-Jewish buildings, such as
the Transito and Santa Maria la Blanca Synagogues; Gothic structures, such
as the splendid cathedral; and Renaissance buildings. In the 16th century,
the city became home to El Greco, and Toledo has many of his paintings,
among which is "The Burial of the Count of Orgaz", his masterpiece, which is
housed in the Mudejar Church of Santo Tome. Among its many museums, of
special note is the one located in the old Santa Cruz Hospital.

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

General Chair

Prof. Dr. Carlos Delgado Kloos
Universidad Carlos III de Madrid
C/Butarque, 15
E-28911 Leganes (Madrid/Spain)

Tel: (+34-1) 624-9979
Fax: (+34-1) 624-9430
E-mail: ifip@it.uc3m.es

Program Chair

Prof. Dr. Eduard Cerny
Dept. IRO
Universite de Montreal
C.P. 6128, Succ. Centre-Ville
Montreal (Quebec)
Canada H3C 3J7

Tel: (+1-514) 343-7472
Fax: (+1-514) 343-5834
E-mail: chdl97@iro.umontreal.ca

Exhibition Chair

Dr. Serafin Olcoz Yanguas
TGI - Tecnologia y Gestion de la Innovacion
C/Velazquez, 134 bis
E-28006 Madrid (Spain)

Tel: (+34-1) 396-4925
Fax: (+34-1) 396-4841
E-mail: sera@www.tgi.es

Local Arrangements

Natividad Martinez Madrid
Ingenieria Telematica
Universidad Carlos III de Madrid
C/Butarque, 15
E-28911 Leganes/Madrid (Spain)

Tel: (+34-1) 624-9903
Fax: (+34-1) 624-9430
E-mail: nmadrid@it.uc3m.es

Asia-Pacific Representative

Prof. Masaharu Imai
Department of Computer Science
Graduate School of Engineering Science
Osaka University
1-3 Machikane-yama, Toyonaka, Osaka, Japan 560

Tel & Fax: (+81-6) 850-6623
E-mail: imai@ics.es.osaka-u.ac.jp, m.imai@ieee.org

Program Committee

   * David Agnew, Canada
   * François Anceau, France
   * Przemyslaw Bakowski, France
   * Mario R Barbacci, USA
   * Howard Barringer, UK
   * Graham Birtwistle, UK
   * Dominique Borrione, France
   * Raul Camposano, USA
   * Eduard Cerny, Canada
   * Luc Claesen, Belgium
   * Edmund M Clarke, USA
   * Francisco Corella, USA
   * Werner Damm, Germany
   * Carlos Delgado Kloos, Spain
   * Nikil D Dutt, USA
   * Hans Eveking, Germany
   * Norbert Fristacky, Slovakia
   * Masahiro Fujita, Japan
   * Ganesh Gopalakrishnan, USA
   * Werner Grass, Germany
   * Rainer Hartenstein, Germany
   * Graham Hellestrand, Australia
   * Masaharu Imai, Japan
   * Steven D Johnson, USA
   * Thomas Kropf, Germany
   * David C Luckham, USA
   * Paul Menchini, USA
   * Jean Mermet, France
   * Wolfgang Nebel, Germany
   * Adam Pawlak, Germany
   * Robert Piloty, Germany
   * Paolo Prinetto, Italy
   * Franz Rammig, Germany
   * Peter Schwarz, Germany
   * Jørgen Staunstrup, Denmark
   * P A Subrahmanyam, USA
   * Flavio Wagner, Brazil
   * Ronald Waxman, USA
   * Akihiko Yamada, Japan
   * Michael Yoeli, Isreal

Article: 4147
Subject: Cypress FPGA/Warp2--Any Good?
From: Sam <skue@chasind.com>
Date: Wed, 18 Sep 1996 10:35:04 -0500
Links: << >>  << T >>  << A >>
I would like to know if anyone have used
Cypress FPGA parts (e.g., 8K gates)and Warp2/3 
$99 Design Kits. Especially, I would like to know
1) if I can get high percentage of usable gates
   out of these parts,
2) whether I can use the design kit to read in
   existing VHDL code that was written for
   Model Technology simulator (and someone else
   synthesis and P/R tools),
3) if the technical support from Cypress is
   acceptable...

Any comments on the above will be greatly
appreciated.

take
Article: 4148
Subject: Re: Inaccrate Xilinx simulations ???
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 18 Sep 1996 12:56:18 -0700
Links: << >>  << T >>  << A >>
I agree with Scott, but let me add some specifics about guardbanding:

We actually test all commercial devices at 4.75 V and 85 degree 
temperature. The tests take only a few seconds and create very little 
power dissipation, so we preheat the devices to slightly more than 85 
degrees C and then perform the test. Junction temperature is then only 
very little above case temperature, which is 85 degrees centrigrade.

A device that fails any ( even a single ) test limit under these 
conditions is rejected for this speed grade and is then tested for a 
slower speed grade.

We have measured the temperature coefficient of delay parameters, and we 
assume it to be between 0.25 and 0.35% per degree C.
The voltage dependence of the delay parameters is roughly inversely 
proportional. 
( Not all parameters behave the same way, because there are several 
different physical phenomena involved here. That's why we cannot test at 
room temperature and just calculate the worst-case values. We actually 
test under the guaranteed worst-case operating conditions )

You can expect a 5% improvement in performance when you run at 5.00 V, 
and a 15 to 20% improvement when you run at room temperature and low 
power consumption, i.e. a junction temperature close to 25 degrees. 
When you multiply 0.95 times 0.80 you get 0.76 for the delay, or 1.316 
for the clock rate.

So the first 32% of the extra performance you got were due to your more 
benign operating conditions.
The next 25% of extra performance may have been due to luck, because you 
may have gotten a part that was almost a speed grade better than its 
marking.
The remaining 25% of extra performance come courtesy of the conservative 
test and characterization methodology used by Xilinx.

Most users don't complain when parts are faster than the worst-case 
spec, but all hell would break loose if they were slower.

By the way, all semiconductor manufacturers also reserve the right to 
"downbin", i.e. to mark a fast part with a slower speed grade than it 
really is, when the market demand is higher for slower parts.

Designers should assume that a device can be up to four times faster 
than the worst-case spec ( that also covers ambient conditions ), but 
never slower than the worst-case spec.

I have seen working designs where combinatorial delays deliberately 
exceeded the clock period. These designs worked until the temperature 
got cold, or until faster devices were plugged in. The original designer 
had wisely departed, so he could not be lynched, but somebody else had 
to clean up the mess.
Never rely on the slowness of an integrated circuit !

I hope this was not too rambling.
Enjoy your fast Xilinx devices.

Peter Alfke, Xilinx Applications
Article: 4149
Subject: *** finding datasheets and chipmakers on the web ***
From: Gray Creager <gcreager@scruznet.com>
Date: Wed, 18 Sep 1996 13:01:42 -0700
Links: << >>  << T >>  << A >>
Just a reminder,

I maintain a well-used, but not well-publicized, listing of chipmaker
website URLs. I have recently
revamped it so that you can view just a brief listing of URLs, or a
listing URLs with a summary of the chips made by each company.

http://www.scruznet.com/~gcreager/hello5.htm

Use the above URL to choose between the two sites. You can print out
either listing in hardcopy format (I've made versions with colors that
are "printer friendly") and post it on your wall, or just bookmark
whichever webpage you like best. 

I've added a growing engineer humor page as well (some funny stuff there
actually).

I am constantly updating this listing and it is the most up-to-date that
you'll find anywhere. I will soon be adding some investor links as well
(for those who invest in semi stocks).

Use it as much as you like and tell others about it.

-- 

Gray Creager


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