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/~fabioArticle: 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: 5653
A 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. -- - hArticle: 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. - hArticle: 5656
Peter 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 14Article: 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: 5663
I 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