Messages from 12050

Article: 12050
Subject: Re: Cypress CPLDs
From: "Stephen Peddle" <smp@spam.com>
Date: Fri, 25 Sep 1998 18:35:39 GMT
Links: << >> << T >> << A >>


Dan Parent wrote in message <6ug9i8$h8v$1@news.itis.com>...
>I would like to here any comments/performance issues stemming from new
>designs using the Cypress CYC374i-66JC CPLD or related Cypress CPLD parts.
>
>We have just introduced a new product which utilizes the Cypress CPLD part
>and are looking at re-designing the pcb to add additional features.  One
>concern I had with the CPLD is the 5volt logic output only reaches
>aproximately 3.7 to 4volts due to a diode drop.  No negative side effects
>have been detected in the product's logic levels yet but we have only
>produced about 500 units.

Why do you want 5V?  Are you driving a CMOS input?  If the next stage is
TTL levels 3.7V should be plenty.  There are several standard logic families
out
there which intentionally restrict the output voltage swing in order to
reduce ground
bounce.  In fact, the original TTL logic never pulled all the way to 5Volts
either.


Steve

Article: 12051
Subject: Re: Cypress CPLDs
From: "Dan Parent" <dparent@itis.com>
Date: Fri, 25 Sep 1998 15:31:07 -0500
Links: << >> << T >> << A >>


Stephen Peddle wrote in message

>Why do you want 5V?  Are you driving a CMOS input?  If the next stage is
>TTL levels 3.7V should be plenty.  There are several standard logic
families
>out
>there which intentionally restrict the output voltage swing in order to
>reduce ground
>bounce.  In fact, the original TTL logic never pulled all the way to 5Volts
>either.
>
>
>Steve
>
>

You are correct - 5 volts is not absolutely necessary or possible.  But it
is nice to have a little noise margin above the 2.7v cmos threshold.

Dan

Article: 12052
Subject: VIS 1.3 Released
From: Fabio Somenzi <fabio@colorado.edu>
Date: 25 Sep 1998 14:34:28 -0600
Links: << >> << T >> << A >>

We are glad to announce the release of VIS 1.3. Below is a description
of VIS and of the new features. VIS 1.3 can be downloaded from the VIS
homepage at http://www-cad.eecs.berkeley.edu/~vis


DESCRIPTION

Formal verification system with Verilog HDL front end.  Computation
model is a set of synchronously communicating FSMs.  Emphasis is on
fair CTL (computation tree logic) model checking, with error trace
generation.  Supports, as proof of concept, cycle-based simulation,
combinational equivalence checking, and sequential equivalence
checking. Has links to the sequential synthesis tool, SIS.  Jointly
developed by Univ. of California at Berkeley, Univ. of Colorado at
Boulder, and Univ. of Texas at Austin.


RELEASE NOTES FOR VIS 1.3

* Introduction

Release 1.3 of VIS improves VIS 1.2 in the following areas:

** Approximate Reachability Don't Cares (ARDCs)
** High Density Reachability Analysis.
** On-the-Fly Invariant Checking.
** Seeding Reachability Analysis via Simulation
** Forward Model Checking
** Abstraction-refinement based Incremental CTL Verification
** Synthesis
** State Transition Graph Restructuring for Low Power
** Miscellaneous

* Approximate Reachability Don't Cares (ARDCs)

VIS-1.3 includes the use of ARDCs in model checking and reachability
analysis. The power of using reachable states as a care set (RDCs) is
well known; however, computing reachable states exactly is intractable
in many large designs.  ARDCs are an overapproximation of the
reachable states, which are then used as the care set.  Computing
ARDCs is much cheaper than computing RDCs while their effectiveness in
speeding up model checking is comparable to that of RDCs.  Therefore,
ARDCs are good for large designs, especially those in which exact
reachability analysis is intractable.  See: I.-H. Moon, J.-Y. Jang,
G. D. Hachtel, F. Somenzi, "Approximate reachability don't cares for
CTL model checking", ICCAD'98.

** Usage:
           model_check -D 3    : model checking with ARDCs
           compute_reach -A 2  : compute over-approximate reachable
                                 states 
	   compute_reach -D    : compute exact reachable states with 
                                 the help of ARDCs
           check_invariant -D  : check invariants with the help of
                                 ARDCs 
	   synthesize_network -r 3 : synthesize sequential network
                                     with ARDCs 

Also refer to: print_ardc_options


* High Density Reachability Analysis (HD)

HD is an alternate approach to performing exact reachability
analysis.  Using BDD subsetting techniques, the HD method tries to keep
the sizes of the BDDs small during the traversal.  This is intended to
keep the memory occupation under control as well as make the traversal
more efficient by manipulating smaller BDDs.

On large circuits, for which the default (breadth-first search) method
does not complete, HD is likely to find many more reachable states.
This is useful in invariant checking.
For mid-size circuits, HD is sometimes faster in completing
reachability analysis, but for smaller circuits, HD may result in too
much overhead.  It is recommended to use this option when the default
method for reachability analysis fails (runs out of memory or takes
very long).  Refer to Ravi and Somenzi, "High-density reachability
analysis", ICCAD'95.

HD analysis only works with the CUDD package.
 
** Usage:
           compute_reach -A 1: reachability analysis with HD approach.

Also refer to: print_hd_options


* On-the-Fly Invariant Checking 

Checking invariants is done by performing reachability analysis and
checking if all invariants hold in the reachable states.  VIS-1.3
does invariant checking during reachability computation (on-the-fly
verification).  Invariants that fail are reported early, along with the
counter examples if requested.

Since reachability analysis can be expensive, one may use HD in
invariant checking.  For circuits on which the default reachability
analysis runs out of resources, HD will typically explore more
reachable states, and more invariants may prove false.  However, the
counter examples provided by using HD may not be of shortest length.

HD invariant checking only works with the CUDD package.

** Usage:
           check_invariant -A 1 : check_invariant where HD is used for
				  reachability analysis

One may also start with an overapproximation of the reachable
states.  In this case, if all invariants hold on the overapproximation,
verification is successfully completed.  If not, the algorithm will
compute the exact reachable states as before, and check the
invariants that failed with the overapproximation.

** Usage:
           check_invariant -A 2 : check_invariant where over
                                  approximation is used for reachability
                                  analysis.

* Seeding Reachability Analysis via Simulation

A new option rch_simulate can be used to use simulation to augment the
set of initial states for reachability analysis. The value of the
variable is the number of random input vectors that are simulated. The
states reached in this way are considered as initial
states. Augmenting the set of initial states may sometimes lead to
faster reachability analysis, or may sometimes lead to better
underapproximations, when reachability analysis is not carried out to
completion. The commands affected by this option are compute_reach and
check_invariant.

** Usage:
	   set rch_simulate n : simulate n vectors prior to
				reachability analysis


* Forward Model Checking

VIS-1.3 includes the capability of forward model checking based on
H. Iwashita, T. Nakata, F. Hirose, "CTL model checking based on 
forward state traversal", ICCAD'96.  Standard "backward" CTL model
checking uses only preimage computations.  Forward model checking tries
to use image computations in place of preimage computations as much as
possible, because they are typically faster.
According to our experiments, forward model checking gives drastic
performance improvement in many designs, but we have also seen many
cases in which forward model checking does much worse.  Performance
depends on the design.

** Usage:
           model_check -F  : model checking based on forward traversal


* Incremental CTL Verification

The command "incremental_ctl_verification" (aliased to "icv")
performs verification of CTL formulas following the incremental
paradigm described in A. Pardo, G. Hachtel, "Incremental CTL model
checking using BDD subsetting", DAC'98.  The algorithm starts with an
initial simple approximation of the verification and then proceeds at
refining the different evaluations until the formula can be proved
conclusively.  The approximation technique currently adopted makes use
of BDD approximation techniques.  As implemented in release 1.3,
incremental_ctl_verification supports fairness constraints, but tends
to be less efficient than model_check when they are specified.

Incremental verification works only with the CUDD package.

** Usage:
	   incremental_ctl_verification [options] ctl_file


* Synthesis

VIS 1.3 includes a new command "synthesize_network" (aliased to
"synth") to transform both combinational and sequential circuits into
multi-level boolean networks using symbolic factorization based on
Zero-suppressed BDDs (ZDDs).  In the case of sequential circuits, only
the combinational part of the circuit is synthesized: state encoding
is not altered.  The emphasis of this algorithm is on the reduction of
the number of literals in the factored form of the network.  The final
multi-level circuit can be obtained in either the BLIF format or the
equation format.  Designs described in BLIF or BLIF-MV format can be
used as an input to this command.  However, multiple valued variables
are not supported.  Hence, signals in the designs described in BLIF-MV
need to be restricted to binary values.

Synthesis can be used only when VIS is linked with the CUDD package.

** Usage:
	   synthesize_network [options]

* STG Restructuring for Low Power 

VIS-1.3 includes a new command "restruct_fsm".  This command
implements a State Transition Graph (STG) restructuring algorithm
that exploits the existence of equivalent states to decrease power
dissipation, not necessarily by collapsing the equivalence states, but
by redirecting transitions in the graph.  This algorithm is based on
the monolithic transition relation.  The complexity of the algorithm
in general increases with an increase in the size of the state
transition graph, which depends on the number of state variables and
primary inputs.  The algorithm can handle circuits described in both
BLIF and BLIF-MV formats.  However, multi-valued variables are not
supported.  Also, the final synthesized circuit (network implementation
of the restructured STG) is available only in BLIF format.  The
sequential circuit should have a single initial state.  For more
details see, B. Kumthekar, I.-H. Moon, F. Somenzi, "A Symbolic
Algorithm for Low-Power Sequential Synthesis", ISLPED 97.

STG restructuring works only with the CUDD package.

** Usage:
	   restruct_fsm [options]

* Miscellaneous

** New versions of CUDD and CAL packages.
VIS-1.3 includes CUDD 2.3.0 and CAL 2.0.1.  Compared to the versions
that were included in VIS-1.2, the new packages have better
performance and improved statistics reporting.

** Changes in configure
Configure now defaults to using 32-bit pointers on DEC Alpha machines.  
To use 64-bit pointers, invoke "configure" with "--enable-64."

** gmake check
"gmake check" now consistently runs the local executable using the
examples in the master source directory.  Previously, there were
different versions for local-area and central-area checks.

** Native Compiler.
The configuration scripts now try to use the native C compiler (cc) by
default.  The use of gcc can be forced by running configure with the
option --enable-gcc.  On AIX and SunOS, however, only gcc is
supported.

As a result, the following configuration options have been removed

    --with-comp-mode=solaris
    --with-comp-mode=mips
    --with-comp-mode=alpha32
    --with-comp-mode=alpha64

Configure now defaults to using 32-bit pointers on DEC Alpha machines.  
To use 64-bit pointers, invoke "configure" with "--enable-64."

** Changes in supported platforms.
VIS-1.3 has been tested under IRIX 5.3 with both cc and gcc.
VIS-1.3 has been tested under HP-UX with cc. (Previously only gcc was
supported.)
VIS-1.3 linked with the CAL BDD package currently does not work under
CYGWIN32.  When the problems are fixed, we shall issue a patch.

** Uniformity across platforms.
VIS-1.3 provides enhanced architecture independence.  For the commands
model_check, approximate_model_check, compute_reach,
incremental_ctl_verification, check_invariant, and lang_empty, the runs
will be exactly the same on every platform with the same memory limits.
Previously, invocations of reordering, and hence BDD sizes could differ
from platform to platform.

** Changes to static_order.
The static_order command has changed substantially.  For combinational
circuits, VIS-1.2 and earlier releases effectively generated random
orders regardless of the method specified by the user.  (Sequential
circuits did not have this problem.) The randomness of the orders was
due to a bug that has been fixed in VIS-1.3.  For all
circuits---combinational and sequential---the default ordering method
is a new algorithm called "interleave."  The new default method is
substantially more memory efficient than the previous default method
(merge_left).  The quality of the resulting orders is comparable.

** New -v option for dynamic_var_ordering.
The option -v 1 can be specified to cause VIS to write a one-line
message whenever dynamic reordering is executed.  The message reports
the reduction in BDD or ZDD size, and on the time taken by reordering.
This option is only effective with CUDD.

** New -i option for comb_verify and seq_verify.
It is now possible to print statistics on BDD usage and performance
when running combinational or sequential verification.  This is done
by specifying the -i option for comb_verify and seq_verify.  It is
important to notice that these two commands use a local BDD manager,
which is destroyed before control is returned to the user.  It is not
therefore possible to use print_bdd_stats to inspect the statistics of
the BDD package when invoking either of the two commands.

** Default method for build_partition_mdds changed to inout.
The default method has been changed to inout, because this has been
found to produce better results than frontier in many cases.  The
frontier method can build the partition MDDs in more cases than the
inout method; the latter, however, tends to give better performance
during model checking.

** set ctl_change_bracket [yes/no]
VIS-1.3 includes this set command option for the CTL parser.  VL2MV
automatically converts "[]" to "<>" in node names, therefore the CTL
parser does the same thing.  However, in some cases a user does not
want to change bracket type in the CTL formulas.  This can be
accomplished by setting this set command option to "no."  The default
is "yes". The commands affected are check_invariant, model_check,
approximate_model_check, and incremental_ctl_verification.

** Printing time for model checking
VIS-1.3 includes printing time for model checking.  If verbosity is set on,
then the model checking time for both each formula and total will be printed
out.

** Incremental reachability analysis and invariant checking.
In VIS-1.3 it is possible to perform reachability analysis
incrementally.  The -d option of compute_reach specifies how many
steps (image computations) should be performed at most before
returning control to the user.  If compute_reach is invoked more than
once with the -d option, each time reachability analysis starts from
the previous result.  If check_invariant is invoked after
compute_reach has been invoked with the -d option, the partial
reachability results are used to speed up verification.

** Completeness and determinism check in flatten_hierarchy
The check for completeness and determinism performed by
flatten_hierarchy that was previously optional is now always
performed. The -b option to flatten_hierarchy and init_verify has no
effect in VIS-1.3 and is retained for compatibility with existing
scripts. It may disappear in future releases. Users of VIS-1.3 will
observe modest increases in the time taken to flatten the
hierarchy.


-- 
Fabio Somenzi          | Phone: 303-492-3466
University of Colorado | Fax:   303-492-2758
ECE Dept.              | Email: Fabio@Colorado.EDU
Boulder CO 80309-0425  | WWW:   http://vlsi.colorado.edu/~fabio

Article: 12053
Subject: Re: Which FPGA tool is better
From: "Bob Deasy" <bobd@model.com>
Date: Fri, 25 Sep 1998 15:27:13 -0700
Links: << >> << T >> << A >>

Take a look at www.model.com

A closer look will help with your evaluation.

John Huang wrote in message <6uctfk$ht4$1@news.seed.net.tw>...
>I want to buy a FPGA tool, do you recommand which
>one is better, how about Accolade  and Aldec?
>
>John Huang
>
>
>

Article: 12054
Subject: Re: Efficient max-function architecture?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 25 Sep 1998 20:23:05 -0400
Links: << >> << T >> << A >>

I must admit, I've been hearing good things about Leonardo Spectrum.  I'll reserve
judgement until I have a chance to try it out (your point is good news).


Stuart Clubb wrote:

> >This is the same as a macro I use.  Synthesis won't create this structure
> >without alot of monkeying around.  With schematics it works just fine with a few
>
> BZZZT, so sorry.
>
> max_out <= data_a when data_a > data_b else data_b ;
>
> does just fine from Leonardo Spectrum.
>
> Nice carry chain, plus the mux, all rolled into one CLB.
> I get 5 CLBs for Xilinx as one would expect. No RLOCs, no FMAPs, just
> synthesis. :-)
>



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka

Article: 12055
Subject: Re: Efficient max-function architecture?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 25 Sep 1998 20:32:34 -0400
Links: << >> << T >> << A >>

Actually, if you have access to a high speed clock, the bit serial MSB first
comparison of all 16 streams will give a reasonably high performance design in a
very small footprint.  For 8 bit numbers, you should be able to handle a 25 MHz
data rate (thats a 200MHz bit rate) in the faster devices without too much
problem.  I won't bother going over the method again, someone already stated it
earlier in this thread.  Shouldn't take more than a few CLBs to do.  Most of the
work is in the state machine.

Gerald Coe wrote:

> Funnell <j.funnell@dmv.co.uk> writes
> >I'm trying to think of an efficient implementation of an max-function that
> >finds the largest from 16 unsigned 8-bit numbers.  The input format is not
> >specified (I decide parallel binary, serial LSB first, serial MSB first).
> >The max-function must signal which of its inputs was the largest and the
> >value of that input.  What can I do to mimise FPGA area used and maintain a
> >continuous flow of input data?  Is there anything clever I can do?  At the
> >moment I'm thinking in terms of a tree of two-input comparators and muxes
> >perhaps pipelined.  This may be too big.
> >
> Well if speed was an issue, you would not be suggesting that you could
> use a serial imput - So try this;
>
> Take an 8 bit latch - I used an 'HC273.
> Feed this with the result of an 8 bit comparator - I used a suitably
> programmed 27C512 EPROM, but a comparator followed by a mux would do the
> same job. The comparator gives as an output the highest value of its two
> inputs. One of those inputs is the output from the 'HC273, the other is
> the value for comparason. Clear the '273 before you start and then feed
> in your 16 values, one on each clk. The result will be the highest
> value.
> This should be straight forward to convert to an FPGA.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka

Article: 12056
Subject: Re: Design Security Question
From: Zoltan Kocsi <root@127.0.0.1>
Date: 26 Sep 1998 11:41:07 +1000
Links: << >> << T >> << A >>

madarass@cats.ucsc.edu (Rita   Madarassy) writes:

> Also, I never encountered an issue in the market with the 10 or 20 year
> retention time.  Frankly speaking,  I don't think anybody cares anymore.
> Thhe reprogramming can be part of a maintenance procedure after 10 years sinc
> most systems with an expected lifespan of 10 years or more should require
> maintenance.

Well, except if it is say built into a human's body, sent to outer space, 
set into concrete, etc. The big buzz about the Y2K problem is a result 
of nobady caring about what'll happen 10, 20, 30 years later. It turned 
out that there are devices and programs which are still in use after 20 
years. Noone ever cared to upgrade, fix i.e. 'maintain' them.

> Antifuse are a nightmare when it comes to prototyping.  A designer
> will probably burn 20 or 30 parts before getting to the final design.
> FAEs will  probably be nice and supply the designer with 2 or 3 parts
> for the average oportunity design but I bet they will never give 30
> or 40 spares to any ACTEL designer.

The worse I had was 4 chips. In every case it was my sloppynes, I did not
run enough tests through the simulator. Don't forget that people design
ASICs much larger than any FPGA and can make it work first time.
In addition, even if I have to burn 10, about $40 apiece, this is only $400. 
For a typical product we use them in the product design cycle is about 6-8 
months with an associated NRE cost of about half a million. The $400 is not 
really a very significant factor. 

The really dangerous thing with antifuse is when you discover a very 
subtle bug which pops up about half a year later you started to sell 
the product. Now changing 200+ pin TQFP chips en masse on the field or 
download the a fixed code to the EEPROM that boots them is indeed
somewhat different :-) and the associated cost difference is very 
significant.

However, antifuse has its advantages. If your target market is in China, 
the copy protection can come as an issue. Do not forget that with an 
SRAM piece you can protect your IP but not the actual device from copying.
In addition, antifuse is ready when you apply power which makes it rather
useful for various reset-related functions. You save a bunch of GALs,
board space, etc. Very convenient. The 100% routability is quite 
advantageous too, you can fix the pins to the PCB designer's needs, so 
(s)he can actually route the board on 2 layers less - you saved a lot of
money. You change half of the chip midway through and the pins remain the 
same. Neat.

> Anyways, getting back to the security business.  Even CPLDs are impossible
> to break when it comes to security since it will require to look at all
> the layers of the silicon and that is practically impossible.

Nothing is impossible :-) There's some reference on the net about breaking 
smartcards (sorry, no URL - it was about 2 years ago). That showed that
given a university semiconductor lab's equipment, which students can 
access, you can read out anything you want from almost any commercially
available chip. Given the equipment in a semiconductor company's lab,
you can read out anything from anything made out of semiconductors, 
actually you can even watch it working and trace the data through.

You can read out an antifuse (and yes, even FLASH) chip if you are 
desperate. However, it requires much more effort than to copy a 
serial EEPROM.

I think the antifuse faces technological problems instead. The antifuse,
as far as I know, requires technologycal steps for those tungsten plugs
other than the normal chip manufactoring process. This makes it inherently
more complex to make. In additon, standard manufactoring shrinks processes 
quite often. I do not know is the same shrinking can easily be applied to 
those plugs. In addition, I wonder if you can at all burn an antifuse below 
a certain size. I may be totally off course with that, though.

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+

Article: 12057
Subject: Re: Design Security Question
From: Daniel K Elftmann <elftmann@ix.netcom.com>
Date: Sat, 26 Sep 1998 02:56:02 GMT
Links: << >> << T >> << A >>

>>
>>Don't forget that these CPLDs also have a maximum data retention time (10-20 years).  
>>If you look at security, cost, and total complexity of the solution the Antifuse FPGAs are the
>>best solution.  Careful about the gate range of the large CPLDs, the coarse grained architecture
>>can be very difficult to deal with above 10K gates and the deterministic delays of the old 22v10
>>architecture are not there anymore.  
>
>There is a good reason why antifuse parts are slowly losing popularity.
>Once companies like Actel or Quicklogic lose their juicy deals with the
>military they will be out of business in no time.  As a matter of fact
>there are already FPGA and CPLD parts in the military as well as in space.
>
>Also, I never encountered an issue in the market with the 10 or 20 year
>retention time.  Frankly speaking,  I don't think anybody cares anymore.
>Thhe reprogramming can be part of a maintenance procedure after 10 years sinc
>most systems with an expected lifespan of 10 years or more should require
>maintenance.

Avionics, Satelites, Space Exploration, Missles, Medical Electronics, etc.
I hope that Boeing cares, and not because I want to sell more antifuse, I fly in there planes on
occasion.

>
>Antifuse are a nightmare when it comes to prototyping.  A designer
>will probably burn 20 or 30 parts before getting to the final design.
>FAEs will  probably be nice and supply the designer with 2 or 3 parts
>for the average oportunity design but I bet they will never give 30
>or 40 spares to any ACTEL designer.
>
>Xilinx dropped out of the antifuse business because they saw it as
>a slow  growing market.  They would rather be a bit more rational
>and lose money with the CPLD business for a while instead.
>Maybe the Xilinx FAEs were getting sick of having to visit costumers
>

The reasoning that I've heard varies significantly, but I don't follow this group to bad mouth 
Xilinx.

>
>
>Anyways, getting back to the security business.  Even CPLDs are impossible
>to break when it comes to security since it will require to look at all
>the layers of the silicon and that is practically impossible.
>I would say it should be easier to bribe the designer!!! :)
>
I've met folks that pirate designs for a living, they love people that believe this.


Rita,

I did not mean to enflame you.  My apologies.  If you'd like to continue the discussion further
I'd be happy to talk with you at 978-244-3827.

I was a designer for 15 years before joining Actel as a Field Applications Engineer.  The last
company that I worked for used a lot of CPLDs (Altera 7K, 9K, Lattice 1032,1048, 2032, 2064, AMD
Mach 110s, 220s, 465s, you get the picture) as well as Actel, Quicklogic, Altera and Xilinx FPGAs. 
I have nothing against CPLD devices, they served me well.  They also gave me great headaches at
times.  

I find it very hard to believe that 20 to 30 spins of a programmable device would be the accepted
norm amongst programmable designers.  I believe that it can happen, but I certainly hope and
believe that there are still logic designers out there that practice sound engineering principles. 
I don't believe that most companies/projects will allow a designer the required time to hack his
way through designs at densities above 10K gates;  32, 64, or 128 macrocells maybe.

Yes, antifuse is one time programmable.  However, Antifuse has many very compelling advantages.  

Because of the small size of the Antifuse these devices offer better routability.  The small size
allows the antifuse vendors to offer alot more routing resources for a given die real estate.  It
is not unusual to find designs that will use 100% of the device (>95% is commonplace).  In CPLDs,
counting a macrocell as utilized when it is simply borrowing a product term to it's neighbor is
questionable accounting.

Antifuse devices are considerably lower power than large CPLDs and SRAM FPGAs.

I could go on but that's straying beyond the intent of this thread.

Security is an advantage of the Antifuse technology.  The techniques suggested in this thread are
good and completely valid, but why add extra work and cost if the design will fit into an antifuse
device.

Excerpt from: http://www.actel.com/events/protect_copyright.pdf

Antifuses do not have any residual electric or
magnetic fields to detect, nor is is there anything
visual that can be seen from the top or bottom of
the die to determine the programming state of the
antifuse device locations.
The only successful attempts at locating
programmed antifuses has been using a
Transmission Electron Microscope (TEM). This is a
destructive sample technique. It costs about $1,000
to do a TEM sample today. Since there are
approximately 500,000 antifuse sites on an antifuse
part it, would cost at least $500 million to capture a
design. Furthermore, to capture the design, 20,000
programmed antifuses would have to be known
exactly to copy or reverse engineer a design.

Daniel K. Elftmann
Actel Field Applications Engineer

Article: 12058
Subject: Re: CardBus CIS useless?
From: "Austin Franklin" <dar4kroom@ix.netcom.com>
Date: 26 Sep 1998 03:06:46 GMT
Links: << >> << T >> << A >>

tom picard <tomp@pvinc.com> wrote in article
<6uggea$3mp@caribe.pdx.oneworld.com>...
> >CardBus IS PCI.  The CardBus devices are configured by the BIOS just
like
> >PCI devices, they have exactly the same configuration space (except the
> >aforementioned CIS stuff...) and exactly the same bus pins and protocol
> >(with the excepetion of power and a few information pins).  All a
CardBus
> >controller is, effectively, is a PCI bridge chip (though most CardBus
> >interface chips also recognize PCMCIA cards, and configure the slots bus
> >accordingly...PCMCIA is almost identical to ISA, and will not contain
the
> >configuration etc. that CardBus cards do).
> 
> All the above is the same as I understand it, ( well, no BIOS I am aware
of
> actually configures the cards, OSR2+   does it).

The BIOS does fill in the configuration space, especially the base address
registers, and also enables other features, per the PCI configuration space
spec.  It has to, or the card wouldn't have any resources allocated to it. 
The OS configuration is completely different, that is a software
configuration, as opposed to the BIOS hardware resource configuration.

> >As far as power goes, that is determined by pins on the CardBus card,
and
> >the card instructs the slot to power the card accordingly.  You can not
> >change this.
> 
> 
> My understanding is that there is a pointer in PCI config space that MUST
> point to the CIS.
> If this pointer is NULL, the OS will make its best guess what the voltage
> the card requires, and program the controller accordingly. (maybe it
guesses
> a lower voltage so as not to damage the card, by a wrong guess).
> maybe there is a new spec wherein the voltages are specified thru the
pins
> on the card, but i don't understand how it works..

There are 4 pins on a CardBus slot that are used to determine both the type
(16 bit PC Card, aka PCMCIA, or CardBus PC Card) and the cards voltage,
CVS1, CVS2, /CCD1 and /CCD2.

If you want to understand CardBus hardware, go to the TI web site, and get
the 1130 or the 1220 CardBus controller spec.  It has all this information
in it about voltage selection and how it works, etc.

Austin

Article: 12059
Subject: Re: FPGA information -- maybe
From: Phil Hays <spampostmaster@sprynet.com>
Date: Fri, 25 Sep 1998 21:05:08 -0700
Links: << >> << T >> << A >>

Daniel K Elftmann wrote:

> Phil must have something against Actel.  Sorry, just hate being 
> left off the list.

No, I don't have anything against Actel.  I also didn't mention Lucent,
Vantis and surely others as well.

-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan

Article: 12060
Subject: Re: Design Security Question
From: murray@pa.dec.com (Hal Murray)
Date: 26 Sep 1998 05:27:34 GMT
Links: << >> << T >> << A >>

In article <m3emsztzv0.fsf@tade.bendor.com.au>, Zoltan Kocsi <root@127.0.0.1> writes:

> Nothing is impossible :-) There's some reference on the net about breaking 
> smartcards (sorry, no URL - it was about 2 years ago). That showed that
> given a university semiconductor lab's equipment, which students can 
> access, you can read out anything you want from almost any commercially
> available chip. Given the equipment in a semiconductor company's lab,
> you can read out anything from anything made out of semiconductors, 
> actually you can even watch it working and trace the data through.


http://www.cl.cam.ac.uk/users/rja14/tamper.html

Tamper Resistance - a Cautionary Note

Ross Anderson and Markus Kuhn.  Great paper.


-- 
These are my opinions, not necessarily my employers.

Article: 12061
Subject: Re: Design Security Question
From: nospam_ees1ht@ee.surrey.ac.uk (Hans)
Date: 26 Sep 1998 09:46:43 GMT
Links: << >> << T >> << A >>

In article <6ugg8j$ig8@darkstar.ucsc.edu>, madarass@cats.ucsc.edu says...
>
>
>There is a good reason why antifuse parts are slowly losing popularity.
>Once companies like Actel or Quicklogic lose their juicy deals with the
>military they will be out of business in no time.  As a matter of fact
>there are already FPGA and CPLD parts in the military as well as in space.

Perhaps you should look into these parts before making statements like this. 
Currently the SRAM parts are a long way away compared to Actel parts when it 
comes to space usage. Have you ever looked at using an SRAM part in space? I do 
agree that more and more companies are starting to produce SRAM based FPGA for 
space but in my opinion they will always be several generation behind fusible 
link parts both in density and significantly! in price. Honeywell is currently 
working on a space qualified Atmel 6010 which I belief will be in production in 
the year 2000. This part is only 6000 gates (marketing value), not sure were 
Actel will be in that year but certainly not at 6000 gates (current highest 
density space qualified FPGA is 14K gates). Xilinx recently announced their 
space qualified 4000XL series but for a reasonable SEU immunity you have to put 
three of them together with a majority voter (Actel J) on the bitstream. This 
majority voter is, in my understanding, not that straightforward since you have 
to read the bit stream back from all three devices (constantly -> power 
consumption?), invert certain sections and then compare them. If you do find an 
error (fault latency, contention?) you have to reset one or all when the 
circuit is not used (glue logic?) There are others, there is a CMOS/SONOS based 
circuit consisting of 4K gates,  SPEC offers a GaAs (price!) very fast 2K gates 
FPGA. So my conclusion is that Actel parts are far ahead of the game and I 
belief they always will be. I do agree that for re-configurable logic in space 
you have to resort to these devices, however, many cases of re-configurable 
requirements can be argued.

>Antifuse are a nightmare when it comes to prototyping.  
Nonsense. I would argue the opposite, an SRAM part will give the designer a 
"lets try to see if it works" opportunity rather than simulating the design 
properly and working out the spec before burning the chip. For student project 
I would certainly recommend one time programmable parts to avoid issues like 
this. Also the one time programmable parts are not that expensive. I belief 
that the 14K gates (marketing value) SX16 can be purchased for less than $30 in 
a PLCC84 package. How many times do you have to load your SRAM FPGA before you 
get it right?

A designer
>will probably burn 20 or 30 parts before getting to the final design.
Ough, perhaps a good test bench checker good be useful for this designer 
(assuming the error is in the FPGA and not in the surrounding logic).  I am 
also not sure if burning 30 Actel parts is significant compared to the man-hour 
cost.  Sure SRAM parts can be re-programmed in-situ but as one would say horses 
for courses.

>FAEs will  probably be nice and supply the designer with 2 or 3 parts
>for the average oportunity design but I bet they will never give 30
>or 40 spares to any ACTEL designer.
If there is one thing I like about Actel and that's is their support, yes I 
have received free parts and in some cases they were enough to finish the 
design J.

>
>Xilinx dropped out of the antifuse business because they saw it as
>a slow  growing market.  
I heard a different story, Actel spend 10 years refining the process which even 
for a giant like Xilinx was difficult to re-produce in a short time.

They would rather be a bit more rational
>and lose money with the CPLD business for a while instead.
>Maybe the Xilinx FAEs were getting sick of having to visit costumers

Funny!

I am not saying that fusible link parts are better than SRAM and vice versa but 
as I said before horses for course and for space applications there is nothing 
like fusible link FPGA's.

Hans
University of Surrey.

Article: 12062
Subject: Re: Design Security Question
From: Daniel K Elftmann <elftmann@ix.netcom.com>
Date: Sat, 26 Sep 1998 12:35:30 GMT
Links: << >> << T >> << A >>

>Zoltan wrote

>I think the antifuse faces technological problems instead. The antifuse,
>as far as I know, requires technologycal steps for those tungsten plugs
>other than the normal chip manufactoring process. This makes it inherently
>more complex to make. In additon, standard manufactoring shrinks processes 
>quite often. I do not know is the same shrinking can easily be applied to 
>those plugs. In addition, I wonder if you can at all burn an antifuse below 
>a certain size. I may be totally off course with that, though.
>

The Actel MX family (ONO Plice fuse) is at .45u, while the SX family (M2M fuse) is at .35u with .25u
material being tested in the factory right now.  Quicklogic is at .35u as well with the Pasic3
family.

Article: 12063
Subject: Free FPGA/HDL Newsletter Announcement
From: APS <resp@associatedpro.com>
Date: Sat, 26 Sep 1998 13:38:00 -0400
Links: << >> << T >> << A >>



              ------------------------------------------------------
               APS Newsletter Interim Announcements
               ------------------------------------------------------


The next APS EDA Newsletter is about to be released. In this issue we
will cover:


SPECIAL FEATURE ARTICLE:
Using the XILINX Core Generator to Implement and Test a Correlator on
the APS-X208 Board.


VHDL Tips and Techniques:
Using a modified Hungarian Notation for VHDL Language Elements


Soon to be released low COST APS-X240 FPGA Board ---HOT---
    PC-104/ISA/STAND
    SPARTAN/4000E/XL/XLA 5200 series FPGAs
    256K SRAM options
    on board oscillator socket
    prom or isa download
    Available with Foundation Kit Options
New APS-X208 FPGA Test Board Announcements
New APS-X84 Kits Announcements
New XILINX Foundation Software Announcements
SYNOPSYS FPGA Express Announcements
New Accolade VHDL Suite Announcements



Those who wish to subscribe to the newsletter may send an email with the
word SUBSCRIBE in the SUBJECT HEADER to subscribe@associatedpro.com


For those who wish to view the APS FPGA tools and Solutions now, the
following websites apply:


APS HOME PAGE:
http://www.associatedpro.com


APS-Tech Solutions Pages:
http://www.associatedpro.com/Tech_Solutions/aps_tech.html
APS VHDL On Line Tutorial : http://www.associatedpro.com/aps/x84lab/
APS SUPPORT: http://www.associatedpro.com/aps_sup.html
APS PRODUCTS PAGE: http://www.associatedpro.com/apsprods.html



APS X208 Board Pages:
X208 information page:
http://www.associatedpro.com/x208/prod/x208_product.html
X208 Application Information Page:
http://www.associatedpro.com/x208/prod/X208stuff.html
On Line Manual: http://www.associatedpro.com/x208/support/apsx208.pdf
Download X208 Software:
http://www.associatedpro.com/x208/support/x208soft.zip


APS-X84 Board Pages
http://www.associatedpro.com/x84/prod/x84_ds.html


APS-Foundation Software Pages
http://www.associatedpro.com/found/prod/fndprod.html


APS- Accolade Peak VHDL Software Suite
http://www.associatedpro.com/synthall/prod/accolade.html



APS-Portable 100 Mhz Logic Analyzer POD Pages
http://www.associatedpro.com/pod/prod/pod.html


APS DDS DIRECT DIGITAL SYNTHESIS PROGRAMMABLE CLOCK MODULE
http://www.associatedpro.com/dds/prod/dds_prod.html


Pricing Information:
http://www.associatedpro.com/apsprice.html

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Article: 12064
Subject: Keynote, Sangiovanni-Vincentelli
From: sbaker@best.com (Stan Baker)
Date: Sat, 26 Sep 1998 17:54:59 GMT
Links: << >> << T >> << A >>

We are very excited to inform you that the keynote speaker at the 
October 7th Worldwide Member Meeting of the VSI Alliance will be

Prof. Alberto Sangiovanni-Vincentelli of U.C. Berkeley.

The professor is a world-renowned expert on Design Automation, 
not only as an educator but as a highly regarded consultant to
industry.

We look forward to his presentation about system-level 
chip design and design reuse with great anticipation.

For more information about this one-day meeting in silicon valley,
check the web at http://www.vsi.org or email nancy@vsi.org.  

I hope to see you at this valuable meeting.

Stan Baker
Executive Director
VSI Alliance

Article: 12065
Subject: Re: shareware
From: edick@hotmail.com (Richard Erlacher)
Date: Sat, 26 Sep 1998 18:12:31 GMT
Links: << >> << T >> << A >>

On Thu, 24 Sep 1998 20:50:40 GMT, msimon@tefbbs.com wrote:

>Several FPGA companies have low cost (<$100) starter packages.
>
>   XESS has a nice logic development package for $139
>
>   Ultra Technology has a processor development board set for $555
>                             http://wwwdnai.com/~jfox/fpgakit.htm
>
>Simon
>===============================================================
>"adria.bofill" <adria.bofill@imag.fr> wrote:
>
>>I am a newbie in vhdl-fpga.
>>
>>Does Anyone know free/shareware for fpga design?
>>
>>Thanx
>>
>>Adria Bofill
>
===============================================================
Try the ALTERA web site before you pay for anything.  They have a
no-cost limited-license version of their software for you to use.  It
handles their CPLD's and smaller FPGA's

			<www.altera.com>

Article: 12066
Subject: ANNOUNCE: Xilinx FPGA / CPLD and CODEC Demo Boards
From: sja@gte.net (Steven J. Ackerman)
Date: Sat, 26 Sep 1998 18:19:55 GMT
Links: << >> << T >> << A >>

Insight Electronics Xilinx FPGA / CPLD and CODEC Demo Boards
Developed by ACS, Sarasota, FL

see them on the Web at: http://www.acscontrol.com/fpgacpld.htm

Xilinx FPGA / CPLD Demo Board
-----------------------------
Features:

Test moderate complexity FPGA / CPLD designs without building a
prototype
All user I/O pins brought out to labeled 0.1" pin dual-row headers for
easy access, expansion
3" x 5" form factor.

Xilinx XC9536-VQ44 In System Programmable CPLD
36 Macrocells with 800 usable gates
34 I/O pins available on 40 pin header

Xilinx Spartan XCS30-VQ100 FPGA
1368 Logic cells with 30,000 gates
74 I/O pins available on two 40 pin headers

Xilinx XC17S30 Serial Configuration PROM (Optional)
Installable in socket for external programming

Dallas DS1075 Programmable Oscillator
200KHz - 100MHz
Installed in socket for external programming

Eight User LEDs
2 Red, 2 Orange, 1 Yellow, 1 Green, 1 White, 1 Blue
Connected to XC9536 CPLD via 40 pin header

Two User Push Button Switches
Connected to CPLD 40 pin header

JTAG Programming Connector
Daisy-chained to both CPLD / FPGA

FPGA / CPLD Vcc Jumpers
Allows current consumption monitoring

D.C. Power and Battery Connectors
Supplied with 9VDC wall-mounted transformer

Burr Brown REG1117-5v Low Dropout Regulator


CODEC Demo Daughter Board
-------------------------
Features:

Stacks on FPGA/CPLD Demo Board headers for Power and Digital I/O
Provides line level and stand-alone audio I/O on standard jacks
When used with the Elanix Software provides Draw / Compile / Download
DSP capabilities
3" x 4" form factor

Burr Brown PCM3000 CODEC
18-bit Monolithic Delta-Sigma ADC and DAC
16 or 18-bit I/O Data
Stereo ADC with 64x Oversampling
Stereo DAC with 8x Oversampling Digital Filter
Digital De-emphasis
Digital Attenuation with 256 steps
Soft Mute
Analog Loop Back
Multiple sample rates

Atmel AVR AT90S1200
1K In System Programmable Flash memory
64 bytes EEProm
1 MHz operation, most instructions single-cycle
Sets CODEC PCM Format, Attenuation
Installed in socket for external programming
AVR ISP connector provided

Microphone Pre-amplifier
3.5mm Monaural Microphone Jack
Optional bias power jumper
Jumperable to either or both channels

Audio Line-Level Input / Output Jacks
RCA Phono Jacks

Stereo Head Phone Amplifier
3.5mm Stereo Jack


Steven J. Ackerman, Consultant
ACS, Sarasota, FL
sja@gte.net
http://www.acscontrol.com

Article: 12067
Subject: Digital/ASIC/FPGA Eng...Needed
From: mdelaney@servtech.com (Mike DeLaney )
Date: Sat, 26 Sep 1998 13:59:55 -0500
Links: << >> << T >> << A >>

TITLE:  Hardware Eng (Digital/FPGA/ASIC)


REQUIREMENTS: 2+ yrs designing and developing hardware circuitry for
electronic imaging systems.  Work with SW and workstation HW to develop new
technology methods benchmark/evaluations and integration including
improving the technology transfer. Exp in electronic design with design CAD
tools.  Knowledge of digital ASIC and electronic design. UNIX, C, shell and
script programming, VHDL language, Synopsys is a plus.

LOCATION: NY-upstate -  other areas available too...call me to find out more

If this position doesn't fit your requirements, call me with your specific
search criteria.
___________________________________________________________

Call:      Mike DeLaney:   
        800-248-7020  x260      
         Fax 800-838-8789 ATTN: Mike
     National Engineering Search   
        http://www.nesnet.com    

    "Engineers placing Engineers"

Email (text resume) to: mdelaney@servtech.com
____________________________________________________________
See what your skills are worth...CALL for a FREE salary survey.
____________________________________________________________

National Engineering Search (http://www.nesnet.com) is a technical
recruiting firm, staffed with experienced engineers, dedicated exclusively
to placing Engineers nationwide.  

€ What makes us better...We understand the technology.

Article: 12068
Subject: Sweat equity engineer needed for consumer electronics hardware
From: hank777@aol.com (Hank777)
Date: 27 Sep 1998 00:09:51 GMT
Links: << >> << T >> << A >>


Our "garage" startup is developing a new piece of home based consumer
electronics hardware. We are looking for an engineer to do some simple FPGA
work and board layout work. We need some assistance in order to make certain
timelines on this product. Your work would be to assist us in finishing some
add on functionality to our product. I would estimate the actual number of
hours required being in the range of 80-120 man hours. You should have access
to facilities for board testing and FPGA programming. The FPGA is fairly
simple, but you should be familiar with a high level RTL such as VHDL or
Verilog, because the code will ultimately be used in an ASIC. You should also
be available to start almost immediately.

The product we are developing is in the set top box/digital television space
though it is not a set top box.

This project has not yet been venture funded. You would be offered defered cash
compensation and an equity position in the project.

Our company has several patents pending and believes the product's technology
will be one of the core elements in the next generation of digital home
technology.
If you have the resources to work uncompensated for a period of time, and the
inclination to work on something amazingly cool, drop me a line at
hank777@aol.com.

Article: 12069
Subject: Re: Design Security Question
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 27 Sep 1998 02:04:57 -0400
Links: << >> << T >> << A >>

Zoltan Kocsi wrote:
...snip...
> I think the antifuse faces technological problems instead. The antifuse,
> as far as I know, requires technologycal steps for those tungsten plugs
> other than the normal chip manufactoring process. This makes it inherently

Someone correct me if I am wrong, but I thought that the links were low
conductance poly-si, rather than tungsten, and were blown shorted when
programmed. Isn't this why they are called "anti-fuse"?

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 12070
Subject: Re: Design Security Question
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 27 Sep 1998 02:15:15 -0400
Links: << >> << T >> << A >>

Hans wrote:
> >Xilinx dropped out of the antifuse business because they saw it as
> >a slow  growing market.
> I heard a different story, Actel spend 10 years refining the process which even
> for a giant like Xilinx was difficult to re-produce in a short time.

I hate to be a nit picker, but Xilinx did not develop their own
anti-fuse technology in a hurry. They bought Plus logic which was in
competition with Actel. Although I don't know why Xilinx quit the
anti-fuse market, I doubt that it was because the Plus Logic technology
was inherently inferior. Most likely it was because of inferior market
prospects compared to other products they could make.

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 12071
Subject: Re: A Johnson counter
From: edick@hotmail.com (Richard Erlacher)
Date: Sun, 27 Sep 1998 15:34:04 GMT
Links: << >> << T >> << A >>

On Mon, 31 Aug 1998 10:07:42 -0400, Ray Andraka
<no_spam_randraka@ids.net> wrote:

>A johnson counter is a ring counter (A shift register counter whose feedback is
>the last register inverted).  Three flip-flops make a divide by six which
>produces this sequence
>000
>001
>011
>111
>110
>100
>000
>There are two illegal states, 010 and 101.  Good design practice includes a trap
>to capture and escape from the illegal condition.  The johnson counter is useful
>where high count speeds are required (simple feedback means low propagation
>delays and simple routing).  These counters also have the advantage of producing
>a glitch free symmetric (50% duty) output once per cycle on each of the bits.
>These outputs are separated by equal phase angles, so the johnson counter is
>nice for generating split phase clocks
>
>
>Reza Bohrani wrote:
>
>> I was wondering, if anyone could tell me what a divide-by-six Jonson counter
>> is and to what it is used?
>>
>> Sincerely
>> Reza Bohrani
>
>
>
>--
>-Ray Andraka, P.E.
>President, the Andraka Consulting Group, Inc.
>401/884-7930     Fax 401/884-7950
>email randraka@ids.net
>http://users.ids.net/~randraka
>
>
======================================
I'm not so sure that is what a "johnson counter" really is, though it
is close.  Take a look at the Motorla data book for their 14017
Johnson counter.  It generates ten mutually exclusive one-count pulses
at each of its outputs in addition to which it produces a divide-by-5
output when you let it run its full cycle, but each of its outputs
aside from the divide-by-5 has a duration of one clock cycle.  

While this looks somewhat like a shift register with inverting
feedback, it is not.  If you imagine a presettable parallel-output
shift register ten bits long with its first stage preset to one, and
the others cleared, that is more like what the 14017 produces.  

It is a decoded counter, with purportedly glitch-free outputs, which
would certainly be a characteristic of the shift register I mentioned
before.  I'm not at all certain that the divide-by-five output is an
essential characteristic of a Johnson counter.

Its applications are legion, i.e. limited only by your imagination.
You could use it anywhere you require a decoded counter.  What's
interesting and nice about the 14017, aside from the fact it's
available in an HC version which is quite fast, is that it has a
positive going reset, which, for those applications which will
tolerate the transient effects, can be driven by the terminal count in
sequences shorter than the full counter length.

BTW, there's also an 8-count version, the 14022.

Article: 12072
Subject: Re: A Johnson counter
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 27 Sep 1998 12:15:46 -0400
Links: << >> << T >> << A >>

Richard Erlacher wrote:
> 
> On Mon, 31 Aug 1998 10:07:42 -0400, Ray Andraka
> <no_spam_randraka@ids.net> wrote:
> 
> >A johnson counter is a ring counter (A shift register counter whose feedback is
> >the last register inverted).  Three flip-flops make a divide by six which
> >produces this sequence
> >000
> >001
> >011
> >111
> >110
> >100
> >000
...snip...
> ======================================
> I'm not so sure that is what a "johnson counter" really is, though it
> is close.  Take a look at the Motorla data book for their 14017
> Johnson counter.  It generates ten mutually exclusive one-count pulses
> at each of its outputs in addition to which it produces a divide-by-5
> output when you let it run its full cycle, but each of its outputs
> aside from the divide-by-5 has a duration of one clock cycle.
> 
> While this looks somewhat like a shift register with inverting
> feedback, it is not.  If you imagine a presettable parallel-output
> shift register ten bits long with its first stage preset to one, and
> the others cleared, that is more like what the 14017 produces.
> 
> It is a decoded counter, with purportedly glitch-free outputs, which
> would certainly be a characteristic of the shift register I mentioned
> before.  I'm not at all certain that the divide-by-five output is an
> essential characteristic of a Johnson counter.
> 
> Its applications are legion, i.e. limited only by your imagination.
> You could use it anywhere you require a decoded counter.  What's
> interesting and nice about the 14017, aside from the fact it's
> available in an HC version which is quite fast, is that it has a
> positive going reset, which, for those applications which will
> tolerate the transient effects, can be driven by the terminal count in
> sequences shorter than the full counter length.
> 
> BTW, there's also an 8-count version, the 14022.

You are confusing the Motorola implementation which uses a ring counter
with the ring counter itself. The Motorola chip has a 5 FF, 10 count
ring counter followed by ten state decoders. The divide by 5 output is
just one of the FF stages. If you consider the differences between a 10
FF shift register and a 5 FF ring counter, you will see that a separate
counter would be required to generate the divide by 5 output if the
shift register were used, or at very least a 5 input OR gate and another
FF to prevent glitching. 

The beauty of a ring counter vs. a binary or gray counter is that not
only can it be decoded glitch free, any single state or any set of
consecutive states can be decoded with a single two input AND gate. So
it requires very minimal decoding logic for many applications. 

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 12073
Subject: NEW ENGINEERING PAGE: Please Visit
From: Scott Paul Johnston <metad@globalnet.co.uk>
Date: Sun, 27 Sep 1998 11:19:17 -0700
Links: << >> << T >> << A >>

http://www.users.globalnet.co.uk/~metad/eee.htm

Containing:
Introduction to EEE
Resources (over 100 web links)
Employment Statistics and newspaper excerpts
Engineering Poems, Quotations and Humour
EEE at Glasgow University

In addition my homepage (http://www.users.globalnet.co.uk/~metad/)
contains:

A section about me
My CV
A James Bond Section
A guestbook
500+ cool links in the "new look" bookpage
Cool background MIDI and graphics
Literary quotations
Photo Album
Student Resources & humour
Awards Page
Poems...

Basically, something for everyone!

PLEASE VISIT VIA MY MAIN HOMEPAGE ADDRESS!

Please send you comments via the guestbook or by Email (containing
your full name and Email and webpage addresses) and visit via 
http://www.users.globalnet.co.uk/~metad/.

Thanks 
Scott Johnston
metad@globalnet.co.uk

Article: 12074
Subject: NFX780, where to get?
From: khortonBLOCK@iquest.net (Kevin Horton)
Date: Sun, 27 Sep 1998 21:07:28 GMT
Links: << >> << T >> << A >>

Is it possible to get the NFX780-series of chips any more?  I've looked around 
and cannot seem to find these for sale anywhere any more.  I would really like 
to get my hands on several more of this chips (say, 2-10 or more depending on 
price) for my own projects.  If I cannot get these any more, is there another 
similar part I can use?  I already have the "dev system" for these parts 
(read: PLDshell and a parallel port :-) and this chip is perfect for my needs 
and budget.

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

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