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
Steve Baldwin wrote: > > Have you looked at Application Note 59 - Configuring FLEX 10K devices ? > > The datasheet mentions App note 39 - JTAG Boundary Scan testing in > Altera devices. I haven't seen that one but it sounds close. > > Steve. > > =================================================================== > Very funny Scotty. Now beam down my clothes. > ------------------------------------------------------------------- > TLA Microsystems Ltd. PO Box 15-680, New Lynn > Electronic Product Design Auckland, New Zealand > Microcontroller Specialists Ph. +64 9 820-2221 > steveb@kcbbs.gen.nz Fax. +64 9 820-1929 > =================================================================== AP NOte 39 covers all JTAG functions EXCEPT CONFIGURATION ! AP note 59 covers all config modes except via JTAG ! So these don't help at all. I have the Altera CDROM and I looked at all docs related to configuration or JTAG: there are no details about that topic. Any more hints ? Andreas -- Andreas Kugel, Karolinenstr. 4 76135 Karlsruhe, Germany Phone: (49) 721 377865, Fax (49) 721 937 49 12 E-mail: akugel@t-online.deArticle: 5651
We are glad to announce the release of VIS 1.2. Below is a description
of VIS and of the new features. VIS 1.2 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.2
* Introduction
** Release 1.2 of VIS improves VIS 1.1 in the following ways:
Over 10x performance improvement in model checking for many examples;
extended CTL syntax;
better access to the BDD parameters and statistics;
enhanced user interface;
improved portability and flexibility of configuration.
** Release 1.2 also introduces two new verification algorithms:
approximate_model_check: model checking of ACTL formulae for systems
that are too large for model_check;
res_verify: residue based verification of arithmetic circuits.
* Performance improvement in model checking
** We have changed image computation (the underlying operation of model
checking) to make the best use of don't care sets. The don't cares
arise from unreachable states, and using them appropriately reduces
the BDD sizes significantly, leading to improved performance of model
checking. In addition, we have fixed a performance bug that caused
repeated computation of simplified transition relations. We performed
a performance comparison with VIS 1.1 on a set of examples, and on
some cases we observed more than 30x performance improvement. In fact,
on some examples VIS 1.2 could finish model checking in about 26 secs
whereas VIS 1.1 took about 2400 secs.
** The model checking runs that use don't cares (-D option different
from 0) are those that benefit the most from the changes in VIS
1.2. In general it is not trivial to tell whether -D 1 or -D 0 will
produce the faster CPU time. An empirical approach consists of running
"compute_reach -t 300" (reachability for 5 minutes). Depending upon
the progress in reachable state computation, one can then invoke model
checking with -D 0 or -D 1.
* Approximate Model Checking
** VIS 1.2 includes a new command approximate_model_check, a
model checker that performs ACTL model checking on an abstracted and
flattened network. The command is designed to tackle the state
explosion problem we encounter when dealing with large and complex
circuits. Based on the initial size of the group (of latches), the
command constructs an over- or under-approximation of the transition
relation of the system. These approximations may not contain every
detail of the exact system. However they may contain enough
information to determine whether the formula is positive or negative.
Starting from an initial coarse approximation, the command makes its
effort to prove whether the given ACTL formula is true or
false. When the procedure fails to prove correctness of the formula
with initial approximations, it automatically refines the
approximations. It repeats the process until the algorithm produces a
reliable result or the available resources are exhausted. For
detailed description, refer to the relevant manual page ("help
approximate_model_check from" the VIS shell).
** approximate_model_check is faster than model_check for some of
the VIS 1.2 distribution examples. However, significant improvements over
the exact computation can be seen for even larger examples such as
s15850. The current version of the code does not perform any
refinements. The refinement techniques similar to the "machine by
machine" and "frame by frame" may be implemented in future
version. Furthermore, more aggressive reduction of the initial states
can be performed while proving whether the ACTL formula is
positive. The reduction of the initial states are made for each level
of the lattice of approximations in this version.
** The current version includes two distinct "grouping method". More
experiments are required to determine better grouping method(s).
** The current version only supports ACTL formulae.
* Residue Based Verification
** VIS 1.2 includes a new command "res_verify" for combinational
verification based on residue arithmetic. Residue-based verification
is especially suited to multipliers and other arithmetic circuits. See
below, however, for a discussion of the application of "res_verify" to
other circuits. This command is only available if VIS has been linked
with the cu library (default).
** The command res_verify takes two circuits (specification and
implementation) whose equivalence is to be established, and an order
for the outputs. The order for the outputs allows res_verify to
interpret the output vectors as integers. Based on this
interpretation, res_verify applies the Chinese remainder theorem to
the equivalence verification: the specification and the implementation
are equivalent if, for a suitable set of relatively prime numbers,
the residues of their outputs are equivalent. The residues are
computed by composing the two circuits into a function representing
the residue computation.
** res_verify allows the user to specify what pairs of outputs of the
circuits should be compared directly by building their BDDs, instead
of computing residues for them. The -d <n> option controls this
feature; n pairs of outputs, starting from the least significant bits
of the output vectors, are verified directly if -d n is specified.
** As a special case, the user can specify -d all. This causes
res_verify to directly verify all the output pairs, effectively
foregoing residue verification. This can be useful for non-arithmetic
circuits that are not suited to residue verification. In this case
res_verify works similarly to comb_verify, with a significant
exception: res_verify verifies one output at the time. This often
translates into reduced memory requirements and CPU times.
** res_verify can be applied to pairs of sequential circuits with the
same state encoding. Several options and VIS variables control the
detailed behavior of the command. Refer to the on-line documentation
for the details (help res_verify).
* Extended CTL Syntax
** Users can now write CTL fomulae using vector notation. Vector variables
have the form of var[i:j] and each bit can be written as either var<i>
or var[i]. For instance, the following formulae are valid.
counter[3:0] = 10
counter[3:0] = b1010
counter[3:0] = {1,2,10}
The formula in the last line is true if counter has one of the listed
values.
** Macros can be defined and used in CTL formulae to stand for subformulae.
For instance:
\define VALID_INPUT (a[3:0]=0 -> b=1)
defines the macro VALID_INPUT, which can be later used in a formula
like this:
AG(start=1 * \VALID_INPUT -> AF(res[7:0]=b10101010));
** The CTL parser allows users to write the following formulae:
var1 == var2
var1[i:j] == var2[k:l]
The first formula is equivalent to (var1=1) * (var2=1) + (var1=0) *
(var2=0) and currently is allowed only in the boolean domain. (It
cannot be used for variables of enumerated types.) The second formula
can be used if the lengths of two vectors match.
** AX:n(f) is allowed as a shorthand for AX(AX(...AX(f)...)), where n
is the number of invocations of AX. EX:n(f) is defined similarly.
* BDD manipulation
** VIS 1.2 incorporates Release 2.1.1 of CUDD and an improved version of
CAL. Improvements specific to CUDD and relevant to VIS are:
** All reordering methods preserve variable groups. Variable groups are
created by VIS to keep corresponding present and next state variables
adjacent. In VIS 1.1 only method "sift" retained the variable groups.
** CUDD determines the maximum size of the computed table based on the
amount of main memory available. On systems where getrlimit is
available, the datasize limit is used to determine how much memory is
available. CUDD allows the computed table to grow up to one fourth of
that amount. This feature allows VIS to self-calibrate for optimum
performance. The computed table will not necessarily grow to its
maximum value, and VIS is not guaranteed to stay within the memory
bound returned by getrlimit. If the datasize limit is not set, if
getrlimit is not available, or if it is available but does not
know about datasize, then a suitable default value is used
instead. The default value is normally 16MB. This value can be
changed at configuration time. Even a value as low as 16MB gives a
reasonably sized computed table for small-medium runs. However, for
large runs--hundreds of MB--the ability to set the memory limit may
produce much faster execution. The maximum computed table size can be
set also from within VIS with set_bdd_parameters.
** CUDD now provides access to the package parameters and statistics via
the commands bdd_print_stats and set_bdd_parameters. The parameters
that can be set control the sizing of CUDD's main data structures
(unique table and computed table) and many aspects of the variable
reordering algorithms. The parameters reported refer to memory
occupation, computed table (cache) performance, and variable
reordering.
** It is now possible to impose a limit on the number of variable swaps
performed during reordering.
* User Interface
** New VIS command "set_bdd_parameters".
The command "print_bdd_stats" prints two sets of data from the
underlying BDD package, parameters and statistics. The parameters can
be modified as follows. By using the "set" command, set the value of a
variable whose prefix is "BDD." and whose suffix is exactly the name
seen in the output of the command "print_bdd_stats", for example:
vis> set "BDD.Garbage collection enabled" no
Then, the command "set_bdd_parameters" reprograms the underlying BDD
core based on the values of the variables of this type.
** Readline Library.
The Readline library is a GNU package that provides command line
editing, command history, and file name completion capabilities. If
the system where VIS is built has this library and it is installed so
that the linker can use it, the configure script will detect this
situation and the executable will be linked with libreadline.a.
** Variable Interpolation.
The VIS shell now allows variable interpolation. For instance, typing
vis> echo $open_path
causes vis to echo the current value of open_path. Typing
vis> set open_path $open_path:/some/path
will append /some/path to open_path. Variable interpolation can be
used also to exchange parameters with scripts. This allows reliable
parameter passing even when "source" is called with options.
** PAGER
If the PAGER environment variable is set, VIS uses it to choose the
program used to display the help pages. If PAGER is not set, VIS uses
'more.'
** File Buffering.
The output of VIS when run in batch mode is now line buffered on
systems that provide setvbuf. This makes it more convenient to observe
the evolution of long-running jobs.
* Portability and Configuration
** VIS 1.2 runs on two new platforms: IBM RS6000 running AIX and
Intel Pentium running Windows95 with Gnu-Win32. The Gnu-Win32
environment (http://www.cygnus.com/misc/gnu-win32/) is a freely
available GNU environment for Windows 95 and Windows NT.
** This release of VIS has been tested with some native compilers
(Ultrix, Solaris, Digital Unix). In particular, when building with the
native compiler on a DEC Alpha running Digital Unix, the option is
provided to compile with 32 bit pointers. Please see the README file
for specific instructions on how to compile with the different native
compilers.
** The GLU library now provides portable functions for random number
generation and sorting that help make results reproducible across
different platforms.
** The GLU library now provides a function to read the available memory
(based on getrlimit). This function is currently used by the CUDD
package to choose the optimal size of data structures. For systems
without getrlimit a suitable default is provided and can be changed at
configuration time.
--
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: 5652
Hello to all ALTERA experts (and all other interested people),
I am just rolling my own BSCAN interface to
ALTERA MAX9560 and I have encountered some
inconsistencies between documentation (AN 039 v.3) and
device:
1. the data shifted out in the
the shift_ir phase is always the same and not the previous
instruction and it is different to the initial code
given in the docu. (it is 1010101010 for a MAX 9560 GC 280)
2. It seems that the first instruction bit is to be shifted in
in the transition from capture_it to shift_ir. This is
a conflict with the standard as I see it.
This is not the case with the data register.
3. It is not clear which bit has to be shifted in first from an
instruction. For instance if in the table is printed
0001010101 it is not clear whether to start with the '1' (LSB at the
right first?) or the '0' (just left to rigth how you read it).
4. It behaves as if some transitions (e.g. from update_ir) work
not as documented and required from the standard.
Has anyone details on these points (just wishful thinking)?
I am willing to share my (GFORTH-) code if it is debugged with the
community.
Andreas
--
---------------------------------------------------------------
Andreas Doering
Medizinische Universitaet zu Luebeck
Institut fuer Technische Informatik
Email: doering@iti.mu-luebeck.de
----------------------------------------------------------------
Article: 5653A free-core library would be great and I would love to borrow from it, but my company policies would prevent me from adding my own designs to the library (I'm not allowed to disclose Company proprietary information without a disclosure agreement). I'm sure you'll find this to be the norm with a lot of companies. You're best bet for a free-core library of Altera designs would be best sponsored by Altera (on Altera's website) to encourage usage of their parts. Naturally I would look on Altera's site for reference designs that could be downloaded, and I may trust them a litlle more also. evjapps@inet.uni-c.dk wrote: > > > glenn.carl@gsnetworks.gensig.com (Glenn Carl) writes: > > Hi All, > > > > Does anyone have any info on creating a Serial Communication Controller > > (Zilog/AMD 85C30)? Can this be implemented on a FPGA/CPLD? > > > > Thanks > > Glenn > > > > > >>>> > > Hi! > Please look at this copy of mail made by one of the FAE's from ACTE NC Norway: > > Hello all Altera designers! > > I would like to promote the idea of a FreeCore Library. The FreeCore > Library consists of free, parameterizable building blocks for Altera > programmable logic that can be used in your design for absolutely free! > > My first contribution is the parameterizable Compact UART. This is a > simple, complete and compact UART. An 8-bit UART may consume as little > as 63 logic cells in a FLEX 8000 or FLEX 10K architecture, including > transmitter, receiver and baud rate generator. > > The documentation and download page is available at: > > http://www.geocities.com/SiliconValley/Lakes/3656/ > > Please give me your feedback on the FreeCore philosophy. I plan to set > up a FreeCore site soon, and I hope that you, the designers and > application guys, would like to contribute to the library. > > What kind of functions would you like to see in the FreeCore library? > > I'm planning my next release soon: A single master I2C (I squared C) > controller. > > NOTE: > Although I work as a Field Application Engineer for one of the Altera > distributors, I would like to state that this is totally my personal > initiative. Altera is not involved in any way. > > Uffe Tyrsted Toft > ------------------------------------------- > ACTE NC Denmark A/S > E. V. J. Elektronik > Titangade 15 > DK 2200 Copenhagen N > Phone: +45 35 86 90 22 > Fax: +45 35 86 90 00 > E-mail: evjapps@inet.uni-c.dk > -------------------------------------------Article: 5654
> >WOW! That would be great! Warp2 when combined with SRAM FPGAs would be
> >fantastic for Universities! (For PLDs and CPLDs it is great,
> >but one time programmable parts are "problematical" for universities.)
>
> Don't forget Cypress FLASH370i ISR (In System Reprogrammable) devices
which
> are also supported by the WARP (v4.1).
> http://www.cypress.com/cypress/prodgate/cpld/flash370i.html
>
> >and VHDL (VITAL) out for post-synthesis simulation. No fuss, no muss
every
> >thing is there. Just add your favorite VHDL simulator (like Model Tech
> >V-System).
>
> Mmmh, 4000 pounds simulator with a 69 pounds synthesiser ;-) What I don't
> understand is why Cypress wrote such an impressive VHDL synthesiser and
then
> complements it with a horrible editor and a near useless simulator. There
are
> so many good shareware editors and simulators around which they could
possible
> interface to with very little effort.
The next version of warp will have a really cool editor with syntax
hi-lighting and all that usual stuff. It is in beta at the moment.
--
- h
Article: 5655
Can anyone recommend a good timing simulator that I can use with Cypress
Warp 4.1 that will run under Windows NT 4.0? I don't want to get a whole
new tool chain, I just need a compatible timing simulator, and I would
rather get one that someone else has tried, is using, and works with NT
4.0.
- h
Article: 5656Peter Alfke wrote: > > Erik de Castro Lopo wrote: > > > I'd agree with what Robert has to say. FPGAs and CPLD are just means of > > replacing 74XX series logic and small PALs (ie Lattice 22v10). > > > I would not agree with this statement. I worked at Fairchild in 1968 > when we introduced one TTL-SSI and -MSI circuit per week. That kind of > effort lasted until the early 'seventies. TTL-SSI and -MSI innovation > has stagnated since that time, when many of today's designers were still > in diapers. > > It's like saying: an automobile is nothing but a substitute for a > horse-drawn carriage, or a TV is a radio with pictures. > > I find it flattering that designers think of logic functions in TTL-MSI > terms. We must have done a good job back then, if designers, 25 years > later, still think of counters as 74161s and decoders as 74138s and ALUs > as 74181s. That's o.k., as long as that does not stifle the imagination. > TTL circuits were defined with one overriding constraint: the 14- or > 16-pin package, later stretched to 18 to 24 pins. Today, it would be > silly to consider the 7490 or the -much better- 74161 as the "standard" > counter. FPGAs and CPLDs offer much more exciting flexibility: wide > decoding, small RAMs, abundance of flip-flops, internal busses, > efficient identity comparators, novel ways to perform the > multiplications needed in DSP, etc. > > Yes, you can use FPGAs and CPLD as TTL-equivalent "garbage collectors". > But you can also use them for much more productive things > > Peter Alfke, Xilinx Applications Peter is absolutely correct! Everything evolves with added benefits... If you would pretend that you are a little older and try to claim that TTL logic is just a replacement for transistors, you would be incorrect. Integrated logic has additional benefits such as matched transistor characterics that would be difficult to duplicte with discrete parts. I would challenge anyone who claimed that FPGA's were just a replacement for 74XX series logic and PALs to build a few FPGA designs in discrete logic parts. Although it could be designed on paper and built in a lab (in spite of its unwieldy size), it would fail in practice because of noise, propagation delays and transmission line effects... especially at the high speeds that FPGAs promise. Instead, I like to think of FPGAs as replacement for micro-processors, micro-controllers and embedded firmware. Granted, it isn't feasible to replace the main processing core of any system, but many of the peripheral functions can be handled by FPGA's to off-load main processing overhead. Some advice for the future graduates: It's O.K. to think outside the lines. In an interview, if you were to tell me that FPGAs were just a replacement for 74XX and PALs, I probably wouldn't hire you. I would want you to be thinking about the future and what could you do "if..." "If" is always the key. Everytime I wonder if something is possible, I find some vendor willing to do or some product that meets my conditions of "If..." One last thing... FPGAs are the lifeblood of the low-volume embedded industry. Those of us who do not use the quantities necessary to design custom ASICs must rely on the FPGA for survival. Carl RockwellArticle: 5657
i've seen a number of posts on the viewlogic s/w with some having experience with 7.3 (currently i am at 7.2). now, is 7.3 an improvement over 7.2? we heard that it hasn't shipped to us because it is buggy and we should wait to 7.31. anybody have any thoughts on this? anybody know of a version that isn't buggy? :-) thanks for the help, rkArticle: 5658
Austin Cassidy wrote: developingsome teaching/labarotory materiel for MSc level work. Does anyone out there > know how to instantiate Xilinx elemnts directly into the VHDL code to add > elements like the osc4 (XC4000) library. The intention is then to run through > Mentor Autologic to synthesize the design.If anyone has an example of how to do this it would be great... austin, i noticed this was the second time you posted this query. do you have the "xilinx synthesis guidelines for autologic II", xilinx doc 0401465 E1? there's a discussion on component instantiation on page 3-6. the caveats are that the cell must be in al2's synth library and the target technology must be set prior to the synthesis step. according to the doc, you can then do a vhdl component instantiation without a vhdl configuration. component and2 port (...); end component; u1: and2 port map (...); most vhdl books have a section on "component instantiation" if you need info on the exact syntax. i've never passed structural vhdl thru al2 (we used mixed vhdl and schematics) so i can't vouch for this from personal experience. i'd suggest looking in your xc4k synth lib to make sure you get the names of the cells spelled correctly. you might also have to make sure that the port names match exactly with what's in the lib. hope this helps. ps. it would help if you could use carriage returns more often to make your lines shorter and your posts a little more readable :) -- Lance Gin "Off the keyboard, over the bridge Delco Systems-GM Hughes Electronics through the gateway, C43LYG@dso.hac.com nothing but NET!"Article: 5659
In article <01bc2205$c83b94a0$42f65ecf@drt1>, #darkroom@ix.netcom.com# says... > If the application has enough volume, or security is manditory, use a > hardwire after debugging the design. > > Austin Franklin > ..darkroom@ix.netcom.com. Actually, from my understanding, a "hardwire" version of FPGA is a rather standard gate array. These are rather straightforward to reverse engineer with conventional techniques, since all the connections and devices are hardwired. There are, in fact, service companies who will gladly perform the work for you. The conventional techniques are to "pop the lid" and map the devices (i.e. transistors/diodes), Rs, poly interconnect, metal interconnect, and vias. What you can't see from the "top view" is revealed by etching away, layer by layer, until the lower level features are revealed. I used to be in the semi house business, where we were very interested in protection from reverse engineering. It turns out that a programmable device is very effective against reverse engineering, as long as the "code" is well encrypted, compared to a hardwired device. -- Bob Elkind **************************************************************** Bob Elkind mailto:eteam@aracnet.com 7118 SW Lee Road part-time fax number:503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903 ****** Video processing, R&D, ASIC, FPGA design consulting *****Article: 5660
On 3 Mar 1997 00:16:39 GMT, ddecker@diablores.com (Dave Decker) wrote:
>Apology
>I did not respond to this query at first, because I thought some expert would
>respond with a compendium of applications from some survey. Since there has
>been little response, I now believe this is the survey. The following is
>simply my experience at one company over the past 6 years.
As I initiated the original thread I want to thank you for the
detailed answer!! My statistic study is getting better and better...
Thanks
Robert M. Muench
SCRAP EDV-Anlagen GmbH, Karlsruhe, Germany
--> Private answer to: r.m.muench+ieee.org <--
==>>> replace the + with @ <<<==
PGP-Fingerprint:
08 E9 EE 9F 33 ED 46 11 A5 CD BE FC 9D ED 75 14
Article: 5661> anybody know of a version that isn't buggy? :-) Yes, the DOS version 4.1 :) The only bug I have found in 5 years of use is that one cannot print direct to any printer, apparently because the developers only ever tested it with a remote (network-attached) printer! You have to print to a file called COM3 or COM4, and have a serial-attached printer. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 5662
Hi There
Does anybody know how to implement Altera`s LPM Function LPM_MUX
into a GDF File .
I dont know how to connect the input busses ( vive in my case ).
Thanks Nils Koehler
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ Nils Koehler +
+ Fa. IBT Nachrichtentechnik GmbH +
+ Tel. ++49-6074-8948-0 +
+ Fax. ++49-6074-8948-90 +
+ +
+ mailto://Nils.Keohler@T-Online.de +
+ +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Article: 5663I used 4.1 and used a direct connect parallel post script printer (QMS PS 410) with no problems... Your printer anomaly sounds strange.... Austin Franklin ..darkroom@ix.netcom.com. Peter <z80@dserve.com> wrote in article <331f3cf3.300343441@news.alt.net>... > > > anybody know of a version that isn't buggy? :-) > > Yes, the DOS version 4.1 :) > > The only bug I have found in 5 years of use is that one cannot print > direct to any printer, apparently because the developers only ever > tested it with a remote (network-attached) printer! You have to print > to a file called COM3 or COM4, and have a serial-attached printer. > > > Peter. > > Return address is invalid to help stop junk mail. > E-mail replies to z80@digiserve.com. >Article: 5664
I can only commend on ACTEL: Advantages: 1. Up to 100% utilization. (easy to obtain) 2. Pins can easily be constrained without sacrificing major timing delays. Will still route. Example 1280XL 160 pin : All pins assigned. 100% utilization. Routed. Design ran at 72.5 MHz. Very few , if any, other vendors can succeed in doing that. ACTEL got an abundant amount of routing resources to logic modules. This is typical of antifuse. Disadvantages One time programmable. (Advantage: Forces designer to simulate> Saves allot of time in the long run) QuickLogic is being sued by ACTEL for patent infringements. Cypress used to be a second source for QuickLogic. BDipert <bdipert@aol.com> wrote in article <19970224184300.NAA25021@ladder02.news.aol.com>... > I'm interested in hearing from those who have evaluated products from > antifuse vendors Actel and QuickLogic. How do they compare in terms of > power consumption, performance, usable gate count? What about development > tool robustness? Any other comments? Thanks in advance. > -- > Brian Dipert > Sacramento, California > bdipert@aol.com > Visit me at http://members.aol.com/bdipert > > The mass of men lead lives of quiet desperation > -Henry David Thoreau 'Walden' >Article: 5665
I am trying to view a design generated a few years ago. The problems is that is uses libraries that are different to the libraries I have access to. I am using Workview office 7.3. The design was probably done using Pro-series. LIBRARIES ORIGINALLY USED (Viewdraw.ini) xttl (xttl) x3000 (x3000) mx3000 (mx3000) x4000 (x4000) mx4000 (mx4000) LIBRARIES CURRENTLY TRIED (Viewdraw.ini) xc3000o (XC3000) xc3000 (XC3000) fxc3000 (fxc3000) builtin (builtin) xbuiltin (xbuiltin) WRONG SIZE: BUF INV COMPM8 OBUF IBUF FD OBSOLETE: INFF OUTFF MISSING: M2 MC16BCPR MC256BCR MFJK MFD MFDCR MFRS MFDR MFDC MGMUX MRD8CR MRD4 MRD8 MRS8R MRS4 MRS4CR Where can I find the correct libraries?. The design was done for a 3090.Article: 5666
In article <01bc29b0$14991190$2ef65ecf@drt1>, #darkroom@ix.netcom.com# says... > Bob, > > >…(paraphrased) easy to just pop the lid and reverse engineer a hardwire… > > > It turns out that a programmable device is very effective > > against reverse engineering, as long as the "code" is > > well encrypted, compared to a hardwired device. > > I don't understand what you mean by this. An FPGA that is programmed from > a serial prom, or even downloaded from a processor, still has a digital bit > stream, that *is* the entire design. It is so easy to just hook up a logic > analyzer and 'capture' the bit stream. > > Certainly a hardwire device is much more protection against reverse > engineering than an externally programmed part…. I do have a logic > analyzer I can just whip out, but I'll have to dust off my electron > microscope and my laser cutter to get at a hardwire… ;-) > > Could you elaborate on your intent for me please? The subject was "reverse engineer", not "copy". Copying the bitstream is indeed simple. Deducing the *design* of the device is not so simple. For a gate array, reverse engineering of the device to the extent of generating a flattened low-level netlist of devices and Rs is a known science. From there, you can literally run a logic simulation (using a switch-level simulator), complete with timing analysis. For an SRAM based FPGA, the problem is figuring out what all the lookup tables do. Unless you crack the bitstream, your chances of success in your lifetime are pretty darn slim. In sum, copying an SRAM-based FPGA is probably simpler than copying a gate array; and reverse engineering a gate array is probably simpler than reverse engineering an SRAM based FPGA. Does this make sense? -- Bob Elkind **************************************************************** Bob Elkind mailto:eteam@aracnet.com 7118 SW Lee Road part-time fax number:503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903 ****** Video processing, R&D, ASIC, FPGA design consulting *****Article: 5667
After researching further, I found Ms. Rohleder's information given below to be entirely correct. My apologies to Ms. Rohleder for doubting her accuracy and for any confusion this may have caused. Wayne In article <01bc16d5$34c4f760$97e12399@default>, "Rhondalee Rohleder" <Rhondalee_Rohleder@msn.com> wrote: >Actually, you're *both* right. The devices available in the Intel >FLEXlogic line at the time it was sold were EPROM-based. But Intel had >planned from the outset to convert the line to FLASH, beginning with the >introduction of subsequent devices -- Altera just followed through on >Intel's plans after acquiring the line. At the same time, the line was >renamed FLASHlogic to avoid confusion with FLEX. > >Rhondalee Rohleder >Pace Technologies (Scottsdale, AZ)Article: 5668
These older libraries are on your XactStep 6.0.1 CD, in the subdirectory named: \XBBS\OLDVLLIB The are probably also available via the BBS or FTP. Philip Freidin In article <01bc2969$2c31d720$1e0519c4@gateway.asic.co.za> "Willy" <willy@asic.co.za> writes: >I am trying to view a design generated a few years ago. The problems is >that is uses libraries that are different to the libraries I have access >to. > >I am using Workview office 7.3. The design was probably done using >Pro-series. > >LIBRARIES ORIGINALLY USED (Viewdraw.ini) > > xttl (xttl) > x3000 (x3000) > mx3000 (mx3000) > x4000 (x4000) > mx4000 (mx4000) > >LIBRARIES CURRENTLY TRIED (Viewdraw.ini) > > xc3000o (XC3000) > xc3000 (XC3000) > fxc3000 (fxc3000) > builtin (builtin) > xbuiltin (xbuiltin) > >WRONG SIZE: > > BUF > INV > COMPM8 > OBUF > IBUF > FD > >OBSOLETE: > > INFF > OUTFF > >MISSING: > > M2 > MC16BCPR > MC256BCR > MFJK > MFD > MFDCR > MFRS > MFDR > MFDC > MGMUX > MRD8CR > MRD4 > MRD8 > MRS8R > MRS4 > MRS4CR > >Where can I find the correct libraries?. The design was done for a 3090. > >Article: 5669
Has anyone had any experience using the PCI interface VHDL code supplied by Cypress with their parts? We are designing a simple PCI target and are leaning toward Cypress because of the low cost of the Warp development software. Any information would be greatly appreciated. Thank you. -- David Hoenig Student, Computer Engineering, University of Michigan ------------------------------------------------------Article: 5670
Henry Spencer wrote: > Does this realization mean that Xilinx will be releasing documentation on > the contents of its bit streams? (Fears of reverse engineering being the > standard excuse, in the past, for not doing so.) > > No, I'm not seriously expecting it, since it was always clear that this > was just an excuse, but it would be nice... I'm just curious. What would you do with it? (the bitsream information) - BradArticle: 5671
Henry Thomas wrote: > > Can anyone recommend a good timing simulator that I can use with Cypress > Warp 4.1 that will run under Windows NT 4.0? I don't want to get a whole > new tool chain, I just need a compatible timing simulator, and I would > rather get one that someone else has tried, is using, and works with NT > 4.0. Modeltec's V-System will do you just fine. (That's assuming that you can get VHDL with timing info out of the Cypress toolchain, can someone verify?). You'll need a rainbow dongle-mapper to run under NT, but that's OK. (It seems to coexist with all my other dongles, too). It's a good product, nice and stable, seems fast enough, etc. (an aside, does anyone have experience of getting Chronology's dead handy Timing Designer to run under NT4?) Steve -- Steve Wiseman, Senior Systems Engineer, SJ Consulting Ltd, Cambridge, UK Desk +44 1223 578524 (Fax 578524) Group +44 1223 578518 steve@sj.co.ukArticle: 5672
Actually, I believe that Cypress is the foundry for Quicklogic. This will be interesting with Cypress getting out og the antifuse market.Article: 5673
Bob, >…(paraphrased) easy to just pop the lid and reverse engineer a hardwire… > It turns out that a programmable device is very effective > against reverse engineering, as long as the "code" is > well encrypted, compared to a hardwired device. I don't understand what you mean by this. An FPGA that is programmed from a serial prom, or even downloaded from a processor, still has a digital bit stream, that *is* the entire design. It is so easy to just hook up a logic analyzer and 'capture' the bit stream. Certainly a hardwire device is much more protection against reverse engineering than an externally programmed part…. I do have a logic analyzer I can just whip out, but I'll have to dust off my electron microscope and my laser cutter to get at a hardwire… ;-) Could you elaborate on your intent for me please? Thanks, Austin Franklin darkroom@ix.netcom.comArticle: 5674
Wayne, Your kind apology accepted. I've been following the programmable logic market as an analyst for seven years so I just happen to remember a lot of this stuff! Some of it, admittedly, is market minutae but occasionally it comes in handy. :-) Rhondalee Wayne Turner <waynet@goodnet.com> wrote in article <5fk6bo$cf6$1@news.goodnet.com>... > After researching further, I found Ms. Rohleder's information given below to > be entirely correct. My apologies to Ms. Rohleder for doubting her > accuracy and for any confusion this may have caused. > > Wayne > > In article <01bc16d5$34c4f760$97e12399@default>, "Rhondalee Rohleder" > <Rhondalee_Rohleder@msn.com> wrote: > >Actually, you're *both* right. The devices available in the Intel > >FLEXlogic line at the time it was sold were EPROM-based. But Intel had > >planned from the outset to convert the line to FLASH, beginning with the > >introduction of subsequent devices -- Altera just followed through on > >Intel's plans after acquiring the line. At the same time, the line was > >renamed FLASHlogic to avoid confusion with FLEX. > > > >Rhondalee Rohleder > >Pace Technologies (Scottsdale, AZ) >
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