Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. SteveArticle: 12051
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. DanArticle: 12052
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: 12053Take 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
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/~randrakaArticle: 12055
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/~randrakaArticle: 12056
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
>> >>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 EngineerArticle: 12058
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. AustinArticle: 12059
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 SaganArticle: 12060
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
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
>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
------------------------------------------------------
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: 12064We 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 AllianceArticle: 12065
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
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.comArticle: 12067
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: 12068Our "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
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
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
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
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
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.ukArticle: 12074
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
Threads starting:
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