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
name wrote in message <662ri3$bg9@news.Hawaii.Edu>... >I know that it is impossible to guarantee a legal value will be sampled, >but is there anything that can be done to minimize the effects? That is THE question. Consider a ball placed perfectly on the peak of a round topped hill. It must roll one way or the other (1 or 0), but how long will it take to get moving (Tmet) . . . . . before we decide which way it rolled (1 or 0)? And if there was an earthquake (system noise, alpha particle hit), the ball might roll back the other way after our sample (metastable failure). The best we can do "to minimize the effects" is to replace the round topped hill (slow flip-flop, 1 micron, synthesized from gates), with a steep, pointy topped hill (fast flip-flop, 0.35 micron, handcrafted hard D-flop), so that the ball gets moving really fast (min Tmet). >Is it possible to design into your system a graceful recovery? No, assuming that you have already taken the precaution to detect an event with a single observer hard D-flop, which is present for only one clock cycle, where Fclk and Fdata are minimized so that the MTBF is greater than your lifetime. >Can you even recognize that your sampled value is in the metastable region? A state machine that recognizes a fall-back on the next clock following an event-detect would indicate that "your sampled value is in the metastable region" John Birkner, QuickLogicArticle: 8251
Kenny Ranerup <kenny@axis.se> wrote in article <663tb9$9b6$1@gaia.axis.se>... > In article <01bcfeea$75f00d80$c584accf@default>, > "Richard B. Katz" <stellare_nospam@erols.com> writes: > > i think for 54lsxx flip-flops > > the setup-hold window was like 20 nS or so - and the actual window where > > metastability would hit was in the tens to perhaps a hundred or so > > picoseconds. > > It's unfortunately a bit more complex. The metastability window, or > failure window, is usually calculated with this formula: > > w(tstab) = A * exp(-B*tstab) > > Where A and B are implementation/process specific constants and tstab > is the time you want it to take for the flip-flop to stabilize. The > length of the window w(tstab) varies extremly with the value of > tstab. Example from one process I'm using today: > > w(10ns) = 4.8e-52 > w(5ns) = 3.1e-31 > w(2.5ns) = 7.7e-21 > > Kenny > > -- > Kenny Ranerup Phone@work: +46 46 2701848 > Axis Communications AB Phone@home: +46 46 139105 > Scheelevägen 16 Fax@work: +46 46 136130 > S-223 70 Lund, SWEDEN Email: kenny@axis.se > http://www.axis.com/ http://hem1.passagen.se/kranerup > hi, i think you missed my point; the time being discussed is the width of the window where the metastable state may be entered - not the time to get out of it, for a given probablility or overall system reliability. additionally, the discussion that the previous poster made was that the setup and hold time specifications do not matter, which is correct, it's the width of the windows or the parameters of the process for metastability. my example was for the 54lsxx series stuff, which, unfortunately, sort of dates me. anyways, the setup time + hold time of this device is 20 nS + 5 nS = 25 nS (t.i. data book, 54ls74, 1981) and i remembered that the critical window was low, < a few hundred pSecs. the point being that the tsu and th and what are needed to guarantee that a system won't have a metastable event, not the probability of having a metastable event. the tsu and th are designed so that all of the parts work, or at least enough of them so the part is producible. unfortunately, i couldn't find all my old notes in the basement, but i did dig up some stuff. mead-conway (1980) lists this window as approximately 30 picoseconds, consistent with my old gray matter. i had the app notes on the amd 29800 family which has some good info, but can't locate them, perhaps someone else can. a dusty old note from the archives by alfke & wu :-) estimate the window at 100 pSec. measurements i made myself showed the window, for 54lsxx technology, at <- 1 nSec (old scopes), for a demonstration for people who didn't actually believe that there was a metastable state, that "it either clocked a 1 or a 0." more recently, peter a. posted (since i didn't have my xilinx data book here at home, probably need to get another one): Look it up in the Xilinx data book, page 13-43. The modern devices recover surprisingly fast from metastability, so the effective window that might create a 2 ns delay is a tiny fraction of a picosecond wide. the sensitive window size is getting smaller, as peter's recent post points out, and this is reflected in the 'A' parameter above. 'B' is an indication of the gain-bandwith product and is proportional to the time of resolving the metastable state. and with the faster technologies and increasing 'B', this drives up the MTBF which is proportional to e^(Bt), where t is the maximum allowed additional delay, which shows how the system reliability if *very* non-linear with the alloted settling time. peter a. also adds: Metastability is an interesting phenomenon, but it has lost some of its sting since the CMOS flip-flops have gotten so much better. It's just a matter of the gain-bandwidth product in the tiny feedback circuit in the well, i agree, this was a bigger deal back in the '80s and i hope my memory is correct for the above stuff. metastable states are easier to avoid now - more people are aware of it and asynchronous interfaces can be minimized in the system design and more designs are done to be tolerant of them (i.e., healthy settling time) when you can't have everything synchronous. however, i still see these things pop up. one interesting case was when a designer had an asynchronous interface and the synthesis tool, for performance reasons most likely, put two flip-flips into an fpga where only one was intended - one positive true and the other negative true, saving a gate delay for the inversion with the obvious disaster. ------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 8252
John Birkner wrote: > >Is it possible to design into your system a graceful recovery? > > No, > assuming that you have already taken the precaution to > detect an event with a single observer hard D-flop, > which is present for only one clock cycle, > where Fclk and Fdata are minimized so that the > MTBF is greater than your lifetime. You can design your state machines so that every state leads eventually to a valid state. Prevents perminent lock up. Opinions expressed herein are my own and may not represent those of my employer.Article: 8253
Andreas Kugel <andreas.kugel@informatik.uni-mannheim.de> wrote:
:
:
:Adam Seychell schrieb:
:
:> Which manufacture of PGAs would make it possible for the hobbyist to
:> use this technology. Obviously the manufactures are mainly interested
:> in the big customers and so charge big bucks for their development
:> products. So far I've investigated Lattice, Altera & Xilinx and they
:> all have unrealistic prices for their design software. The cost of the
:> chips are relativly small ($10-$20 each). The cheapest design package
:> was around ($850 Australian). Maybe I haven't looked around enough,
:> but if anyone has managed to use re-programable PGAs for a home
:> project, then please direct me to a source.
:>
[snip]
:
: If you just want to play with reprogrammable logic then I'd recommend
:the Lattice isp1000
:parts (they are good for real apps too). The design tool is free, at
:least for the smaller devices.
Xilinx were (are?) running a promo here in Oz, with an entry-level
package called "Foundation Base Blaster Special" at $149.00
I bought the enhanced version for $699 (same features, plus VHDL
support).
It has schematic entry, & supports many (not all) XC4kE and XC95xx
parts.
-- Dave Brooks <http://www.iinet.net.au/~daveb>
PGP public key: finger daveb@opera.iinet.net.au
servers daveb@iinet.net.au
fingerprint 20 8F 95 22 96 D6 1C 0B 3D 4D C3 D4 50 A1 C4 34
What's all this? see http://www.iinet.net.au/~daveb/crypto.html
Article: 8254Roy McCammon wrote in message <3485D550.15FC@mmm.com>... > >You can design your state machines so that every state >leads eventually to a valid state. Prevents perminent lock up. > Good point . . . this method is described by Debora Grosse as "using a Gray code for the transitions" in "Keep metastability from killing your digital design" http://www.ednmag.com/ Design Feature: June 23, 1994Article: 8255
G. Herrmannsfeldt (gah@u.washington.edu) wrote: : Though I still don't know why the University bookstore carries VHDL : books, but verilog books are special order. That really is easy to answer - there are more low cost VHDL tools that Verilog tools. Two spring to mind. Warp 2 from Cypress ($99.00 for everyone). Altera Maxplus II. A free student edition (very nice). And even way back in the days of Intermetrics, VHDL tools were easier to acquire in Universities. Even early on when Viewlogic started to support an HDL, it was VHDL, so that was the first HDL many universities had access to. My theory :) Now that I have Model Tech V-System Professional I might just do a little Verilog in class... -Rich Auletta University of Colorado at Denver Electrical Engineering Email: rauletta@erebor.cudenver.edu URL: http://erebor.cudenver.edu Voice: 303-556-2357 Fax: 303-556-2383Article: 8256
Roy McCammon <rbmccammon@mmm.com> wrote in article <3485D550.15FC@mmm.com>... > John Birkner wrote: > > > >Is it possible to design into your system a graceful recovery? > > > > No, > > assuming that you have already taken the precaution to > > detect an event with a single observer hard D-flop, > > which is present for only one clock cycle, > > where Fclk and Fdata are minimized so that the > > MTBF is greater than your lifetime. > > You can design your state machines so that every state > leads eventually to a valid state. Prevents perminent lock up. > > > > Opinions expressed herein are my own and may not represent those of my employer. > agreed. recently i had to do an architecture with an event counter with a gate that were obviously asynchronous. so, a gray code counter was used, not only preventing lockup but it kept the error low. of course, with some fpga's, the limited number of low-skew clocks was a problem for the multiple counters. ------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) -------------------------------------------------------------Article: 8257
Rodrigo,
Take a look at http://www.xilinx.com/techdocs/2450.htm This tells you
how to import a Synopsys design into Viewlogic but Foundation should be
similar. Things to note, change part 1 about the part changing the bus
naming style to:
bus_naming_style = "%s<%d>"
bus_dimension_separator_style = "><"
bus_inference_style = "%s<%d>"
I belive Foundations uses angle brackets (<>) as bus separtors.
Also, the creation of the symbol would be slightly different but I do not
have the details on this. Do not beleieve it would be too hard to figure
out though.
I am guessing that the problem you were having before is maybe you did not
specify the -s switch when you ran syn2xnf specifying this is a
sub-module. Without the switch, SYN2XNF will place EXT records in the XFF
file and possibly cause the problems you were seeing.
-- Brian Philofsky
Xilinx Applications
Rodrigo Cesar de M. Tavares wrote:
> Hello everybody,
>
> I'm having some problems with the XSI (Xilinx synopsys Interface). I
> have the Synopsys and XSI installed on a Sun Workstation but the XACT6 /
> Foundation Series is installed on a PC. As I don't have the license to
> use VHDL from Xilinx, I'm using the Synopsys tools to implement the
> "modules" of my design. The documentation describes the whole process of
> implementing designs in Synopsys and how to export the XNF file
> generated (using syn2xnf, etc...) to the Xilinx tools, so that one can
> place and route the design. But it assumes that the design is a
> top-level one, that is, it contains PADS and the signals are connected
> in some way to the external pins. In my case, I want to generate blocks
> (known as "macros") and place them in my schematic (Foundation Series)
> so that I can make the interconnections mannualy.
> I can successfully import the xnf generated by Synopsys and translated
> by the SYN2XNF from XSI into the schematic, but when I try to Place and
> Route something goes wrong and I receive dozens of warnings and PPR
> errors.
>
> Please, if someone can help me, do it !
>
> Thanks,
>
> --
> //////////////////////////////////////////////
> // Rodrigo Cesar de Moraes Tavares //
> // e-mail: (mtavares@dcc.ufmg.br) //
> // Belo Horizonte - MG - Brasil //
> // Universidade Federal de Minas Gerais //
> //////////////////////////////////////////////
--
-------------------------------------------------------------------
/ 7\'7 Brian Philofsky (brian.philofsky@xilinx.com)
\ \ ` Xilinx Applications Engineer hotline@xilinx.com
/ / 2100 Logic Drive 1-800-255-7778
\_\/.\ San Jose, California 95124-3450 1-408-879-5199
-------------------------------------------------------------------
Article: 8258<HTML> <P>Josh, <P> I found this small snip it on how to add I/O pullups with Exemplar. I can not verify this to be corect but thought I would pass it along anyways. If you still have problems, Exemplar technical support should have an answer for you: <BR> <BR> <P>--------------------------------------- <BR>External Pullup/Pulldown: <BR>--------------------------------------- <BR> <BR>1. Using attribute: <BR> <BR>LIBRARY ieee; <BR>USE ieee.std_logic_1164.ALL; <BR>LIBRARY exemplar; <BR>USE exemplar.exemplar_1164.ALL; <BR> <BR>ENTITY test2 IS <BR> PORT ( inbus_a, inbus_b, inbus_c : IN std_logic; <BR> en_a, en_b, en_c : IN std_logic; <BR> stopit : IN std_logic; <BR> common : IN std_logic; <BR> outbus : OUT std_logic ); <BR> ATTRIBUTE pull: STRING; <BR> ATTRIBUTE pull OF inbus_a: SIGNAL is "pullup"; <BR> ATTRIBUTE pull OF inbus_b: SIGNAL is "pulldn"; <BR>END test2; <BR> <BR>ARCHITECTURE exemplar OF test2 IS <BR> <BR> SIGNAL int_bus : std_logic; <BR> <BR>BEGIN <BR> <BR> pullup(int_bus); <BR> <BR> -- RTL description <BR> int_bus <= inbus_a AND stopit WHEN en_a = '1' ELSE 'Z'; <BR> int_bus <= inbus_b AND stopit WHEN en_b = '1' ELSE 'Z'; <BR> int_bus <= inbus_c AND stopit WHEN en_c = '1' ELSE 'Z'; <BR> <BR> outbus <= common XOR int_bus; <BR> <BR>END exemplar; <BR> <BR>2. Using control file: <BR> <BR>LIBRARY ieee; <BR>USE ieee.std_logic_1164.ALL; <BR>LIBRARY exemplar; <BR>USE exemplar.exemplar_1164.ALL; <BR> <BR>ENTITY test2 IS <BR> PORT ( inbus_a, inbus_b, inbus_c : IN std_logic; <BR> en_a, en_b, en_c : IN std_logic; <BR> stopit : IN std_logic; <BR> common : IN std_logic; <BR> outbus : OUT std_logic ); <BR>END test2; <BR> <BR>ARCHITECTURE exemplar OF test2 IS <BR> <BR> <BR> SIGNAL int_bus : std_logic; <BR> <BR>BEGIN <BR> <BR> pullup(int_bus); <BR> <BR> -- RTL description <BR> int_bus <= inbus_a AND stopit WHEN en_a = '1' ELSE 'Z'; <BR> int_bus <= inbus_b AND stopit WHEN en_b = '1' ELSE 'Z'; <BR> int_bus <= inbus_c AND stopit WHEN en_c = '1' ELSE 'Z'; <BR> <BR> outbus <= common XOR int_bus; <BR> <BR>END exemplar; <BR> <BR> <BR>Control file: <BR> <BR>SET inbus_a pull pullup <BR>SET inbus_b pull pulldn <BR> <BR> <BR> <P>-- Brian Philofsky <BR> Xilinx Applications <BR> <P>joshua j potts wrote: <BLOCKQUOTE TYPE=CITE>I'm trying to turn on the pullup or pulldown ressitors in an IO pad <BR>on a Xilinx 4000e series fpga. I've done this successfully in schematic <BR>capture but can't find out how to do it in VHDL. I'm using Leonardo as <BR>my VHDL compiler. Any help would be greatly appreciated. <P>Thanks. <P>Josh Potts <BR>University of Illinois</BLOCKQUOTE> <PRE>-- ------------------------------------------------------------------- / 7\'7 Brian Philofsky (brian.philofsky@xilinx.com) \ \ ` Xilinx Applications Engineer hotline@xilinx.com / / 2100 Logic Drive 1-800-255-7778 \_\/.\ San Jose, California 95124-3450 1-408-879-5199 -------------------------------------------------------------------</PRE> </HTML>Article: 8259
PREP was a naive idea destroyed by aggressive marketing, especially by Altera. Peter Alfke, speaking from painful experience.Article: 8260
Richard B. Katz <stellare_nospam@erols.com> wrote in article <01bd0033$44180980$1482accf@default>... [lots of nifty metastability stuff snipped] > measurements i made myself showed the window, for 54lsxx technology, at <- > 1 nSec (old scopes), for a demonstration for people who didn't actually > believe that there was a metastable state, that "it either clocked a 1 or a > 0." While we're on the subject, is there a *simple* circuit to demonstrate metastability. I can rummage around in my junkbox for a slow flip-flop, say a 7474, or better yet, a 4013. - MichaelArticle: 8261
Has anyone succeeded in installing and running M1.3 on NT 4.0, with libraries and whatever else is required to implement an XC5200 design ? If so, please consider sharing your installation procedure. I hear that Xilinx will have this fully supported by M1.4, to be released sometime in January. However, I don't think that my clients would go for a two month delay. -- George Pontis (Replies to geo at z9 dot com.)Article: 8262
Hi, in the Xilinx primitives libs there are cells PULLUP and PULLDOWN. Instanciate them in your code. component PULLUP port (O: out std_logic); ... INST : PULLUP(extsignal); ...Article: 8263
In article <347ee0cf.193872273@news.netcomuk.co.uk> z80@ds.com (Peter) writes: >Hello, > >I have the hugely expensive and dongled XACT6, but I have received the >M1 update a few weeks ago, plus another one just now. >M1 is not dongled, and can be moved to another machine by editing the >volume serial number. This is a major step forward in preserving one's >tools for future maintenance of old projects. >But I wonder how good, and how bug-free, M1 is compared to XACT6. I >use only 3k and 4k devices as these are the cheapest for 100+ volumes. NOTE: all comments below are based on my experience with XactStep and M1, and are strongly influenced by my design style: Extensive floorplanning, exhaustive timespecs, intimate knowledge of the device capabilities, schematic based design, rigorous simulation. If your design style differs from mine then your millage will too :-) M1 is a less mature software product compared with XactStep 5.2.1/6.0.1 and so has a rather interesting set of new bugs, and in my opinion, gratuitous differences from the old software. Once you learn the differences, the product is useable. I have done several 4025E, 4028XL, and 4062XL designs with the M1.3.7 release, so I haven't found any absolute show-stopper bugs, but there have been some serious anoyances. The current version of M1 does not know about XC2000, XC3000, XC5200, XC6200, XC4000A, XC4000H, XC4000D. You will need to keep using the older software anyway for your 3K designs. A future release may remedy this situation. M1 currently seems to focus on the newest stuff from Xilinx, the XC9500, XC9500F and XC4000EX and XC4000XL products, although it also handles XC4000, XC4000L, XC4000E, and XC7300. Assuming you have the above mentioned version of XactStep, here are my recomendations: XC3000 XactStep, APR. Consider moving to XC3100A XC3100 XactStep, APR. Consider moving to XC3100A XC3000A XactStep, PPR. Consider moving to XC3100A XC3100A XactStep, PPR XC4000A, XC4000H, XC4000D Dont use for new designs XC4000, Xactstep, PPR or M1. I find that PPR works better on this family XC4000L, Xactstep, PPR or M1. I find that PPR works better on this family XC4000E, Xactstep, PPR or M1. I find that PPR works better on this family XC4000EX, M1 XC4000XL, M1 I don't use any of the XC7300 or XC9500 devices. I don't know what to do with devices with less tha 5000 gates :-) >I have to say I had no problems with the old APR, until I tried to fit >a dense design into a 3090, and APR could not manage anything better >than about 60% utilisation. That was why I got XACT6 - $3500! Hopefully you changed over to the 3190A and used PPR, as this should give better result. > >I use an old DOS Viewlogic 4 front end for circuit drawing and >simulation (XNF output), and CUPL -> PDS2XNF -> XNF for state >machines. >Any feedback much appreciated. >Peter. I have (with some effort) switched from the same VL you are using to the new viewlogic 7.31, and now use it daily, with only the occasional annoyance of features that do not exist in the new version. The improved integration with the rest of my system (under WIN-NT)has certainly reduced the number of times I reboot my system. Not worrying abot DOS-Extenders is a real blessing. NT-based dongles is a different story :-( The Antique PDS2XNF you are using is probably one of the worst ways to build state machines for Xilinx chips. I would highly recomend you look at schematic based, one hot state machines, for performance, density, and simultion with the rest of your design. All the best, Philip FreidinArticle: 8264
The .bit file format is not a published format, but .... First, the header is not fixed length! it is variable because it contains the filename, date, time, and partnumber. In parsers that I have written, I just look for the byte sequence: 0xFF, 0x20 and just start reading bitstream data from there to the end of the file. In article <65tc7u$gbg$1@vixen.cso.uiuc.edu> janovetz@ews.uiuc.edu (Jacob W Janovetz) writes: >Hello... > > Does anyone have the Xilinx .bit file format? It appears to be >the binary bitstream and some 67-byte header in front which includes >the part number, source (.ngd) file name, and date of creation. >Anyone have a technical description of this header? > > Cheers, > Jake > > >-- > janovetz@uiuc.edu | Once you have flown, you will walk the earth with > University of Illinois | your eyes turned skyward, for there you have been, > | there you long to return. -- da Vinci > PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.htmlArticle: 8265
Hi, We have an exisiting application on a 3000 series FPGA which was originally written using the old ViewLogic 4.1.3a (running under DOS). We now need to take the schematics etc. and edit them to run on a 4000 series device (we have access to M1 and ViewLogic WorkView Office). Can anyone advise on the simplest route to doing this ? (ie. is there an easy way to convert the schematics to 4000 blocks etc.) As we have a problem with our mail server at the time, please could you e-mail any responses to: c.cossar@elec.gla.ac.uk Best regards Calum CossarArticle: 8266
In article <01bd006e$c3525f80$12c4accf@mfc> "Michael F. Coyle" <mjcoyle@erols.com> writes:
> While we're on the subject, is there a *simple* circuit to
> demonstrate metastability. I can rummage around in my
> junkbox for a slow flip-flop, say a 7474, or better yet, a
> 4013.
Easy to demonstrate. Clock a 7474 with the clock applied to the D through
an adjustable delay set so the rising edge of the clock just trails a
transition on the D input. You will have to play with this but if you
get it just right, you will wonder who these things work at all! :-)
You may have to search for that low gain FF to get really bad performance.
I remember doing this many years ago. It was interesting. There was one
problem I had to troubleshoot that turned out to be due to a low gain 7474.
--- sam : Sci.Electronics.Repair FAQ: http://www.repairfaq.org/
Lasers: http://www.geocities.com/CapeCanaveral/Lab/3931/lasersam.htm
Usually latest (ASCII): http://www.pacwest.net/byron13/sammenu.htm
Article: 8267Joseph H Allen wrote: >... To get the second > flip-flop to also be in a meta-stable state requires that > the first flip-flop to transition within this small window > and so is a very unlikely event. It *sounds* very unlikely, but it isn't as unlikely as would be assumed at first glance. The assumption is made that a two-register synchronizer will allow a designer to more or less multiply each stage's MTBF to come up with a total synchronizer MTBF, but the fact is the math can't be done that way. > Adding extra nanoseconds won't make any difference except for the > effect of changing where you are on the exponential decay > probability curve. I completely disagree. If pushing out the clock edge of the second flip-flop by two nanoseconds decreases the MTBF by a factor of 100, then I'd say this is a difference. Yes, that means changing where you are on the curve, but it's an exponential slope, so the little change makes a BIG difference.Article: 8268
As part of a real-world industrial chipdesign, which
indeed did ship as a product in extremely high volume, I
confronted the following design problem. List readers
might enjoy working out the math for themselves.
PROBLEM STATEMENT:
--------------------------------------------------------------------
Each "foobar" IC contains 1 synchronizer subcircuit
Assume 300 million "foobar" IC's are deployed in the field (3.0e8)
A hand-optimized flipflop in the "foobar" IC technology
has the following metastability parameters:
Tzero = 74 picoseconds
Tau = 136 picoseconds
Clock-to-Q propagation delay for the flipflop = 1250 picoseconds
Clock cycletime = 3.000 nanoseconds (333.3 MHz frequency)
Asynchronous input data cycletime = 9.901 nsec (101.0 MHz frequency)
Design Objective:
Put N of these flipflops in series to make a synchronizer
megacell. Choose the number N so that the MTBF of the
synchronizer megacell is large enough so that
THE PROBABILITY THAT IN TEN YEARS OF CONTINUOUS
OPERATION, NONE OF THE 3E8 CHIPS EVER HAS A SINGLE
METASTABILITY INDUCED FAILURE, IS 60% OR GREATER.
--------------------------------------------------------------------
The MTBF equation used, is the standard Hohl formulation
MTBF = (1/fclock)*(1/fdata)*(1/Tzero)*exp(Tsettling/Tau)
where Tzero and Tau are properties of the flipflop used and
are in this case equal to 74 and 136 psec respectively.
The fun in the exercise it to figure out how to set up the
equations to handle 300 million chips (rather than one chip)
and to figure out how to convert a Tsettling into an N.
I hope you have some fun with it. Don't foist it off on
your graduate students, work it out for yourself. You'll
enjoy the counter-intuitive properties of the NONSYMMETRIC
probability density function involved in MTBF. It ain't
like gaussians Bubbah, no indeed.
--Mark Johnson
Article: 8269Philip Freidin wrote in message ... [ snip ] >The Antique PDS2XNF you are using is probably one of the worst ways to >build state machines for Xilinx chips. I would highly recomend you look >at schematic based, one hot state machines, for performance, density, and >simultion with the rest of your design. > I agree about using PDS2XNF for state machine designs. The XABEL product included with the more modern Xilinx releases also builds state machines using the one-hot method and uses standard ABEL language syntax. If you're building one-hot state machines from schematics, you may be interested in the library supplied by MEMEC Design Services. See http://www.memecdesign.com/tr03009.htm for more information. ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com -----------------------------------------------------------Article: 8270
Rodrigo Cesar de M. Tavares wrote: > > Hello everybody, > > I'm having some problems with the XSI (Xilinx synopsys Interface). I > <snip> > implementing designs in Synopsys and how to export the XNF file > generated (using syn2xnf, etc...) to the Xilinx tools, so that one can > place and route the design. But it assumes that the design is a > top-level one, that is, it contains PADS and the signals are connected > <snip> Use the -sub command line option with syn2xnf: syn2xnf -sub xxxx.sxnf This tells syn2xnf that the design is a subcircuit and not at the top level. -- Terry L. Graessle Lockheed Martin - Space Mission Systems NASA Code 521/ Microelectronics Systems Branch graessle@vlsiDOTgsfc.nasa.gov (301) 286-9698Article: 8271
The most important issue for a conversion of this type is which libraries you used for the design. Hopefully you used the unified libraries for the XC3000 design, and have lines in your viewdraw.ini file that look something like: DIR [p] . DIR [m] i:\libs\unified\xc3000 (xc3000) DIR [m] i:\libs\unified\xbuiltin (xbuiltin) DIR [m] i:\libs\unified\builtin (builtin) if you do, then changing the second line to the following: DIR [m] i:\libs\unified\xc4000 (xc3000) DIR [m] i:\libs\unified\xc4000 (xc4000) will get you most of the way there. The first line will match library elements that you have used in your schematics that still have the XC3000 library alias, but will now get them from the XC4000 library. The second line is required for things in those library elements that make references back into the library. If you plan to make edits to the design, and add new stuff, you should reverse the two lines, so any new stuff you add will be tagged with the xc4000 alias rather than the xc3000 alias. If you are using the older libraries X3000 and MX3000, you are hosed. Philip Freidin In article <01bd00c1$342d15e0$dab2d182@craigs-pc.elec.gla.ac.uk> "Craig Slorach" <craigs@elec.gla.ac.uk> writes: >Hi, > >We have an exisiting application on a 3000 series FPGA which was originally >written using the old ViewLogic 4.1.3a (running under DOS). We now need to >take the schematics etc. and edit them to run on a 4000 series device (we >have access to M1 and ViewLogic WorkView Office). > >Can anyone advise on the simplest route to doing this ? (ie. is there an >easy way to convert the schematics to 4000 blocks etc.) > >As we have a problem with our mail server at the time, please could you >e-mail any responses to: c.cossar@elec.gla.ac.uk > >Best regards > > >Calum Cossar >Article: 8272
What releases of ABEL for Xilinx 4K are around? The latest I have seen is 5.02, a DOS version.Article: 8273
I've got an up-down counter layout that can replace the Macro Generated up-down counter with considrable saving in speed, size, and usage of local busses for the Atmel 6k series. If anyone is interested please email or call me. Brad Smallridge 415-661-8068Article: 8274
I've been doing ASICs for the last several years and have
recently returned to the FPGA area. I have downloaded the
XC4000 libraries from the Xilinx web site and successfully
synthesized to a .db file with Synopsys. However, the
"replace_fpga" command fails to translate the generic flip flops
to their Xilinx equivalents. Haven't gotten anything useful
from either company at this point. Was wondering if any other
users have experienced a similar problem and have a solution
they might want to share.
The libraries that I use for the link and target libraries are:
link_library = {xdc_4000e-2.db xfpga_4000e-2.db xio_4000e-2.db
xgen_4000e.db xprim_4025e-2.db};
target_library = {xdc_4000e-2.db xfpga_4000e-2.db xio_4000e-2.db
xgen_4000e.db xprim_4025e-2.db};
symbol_library = {xc4000e.sdb};
Thanks,
Charles
--
Charles F. Shelor charles@efficient.com
Efficient Networks, Inc 'ATM for the Desktop'
4201 Spring Valley, Suite 1200 http://www.efficient.com/
Dallas, TX 75244 (972) 991-3884
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