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
There are three levels of PCI compliance. The first is electrical, ie. capacitance, second is timing, ie. setup and hold, and third is cycle to cycle protocol timing. For an FPGA, the chip determines the first and most of the second. The third is determined by the design. I have used the Xilinx 4xxxE series very successfully in both target only and target/master implementations. Xilinx has quite a lot of app notes on PCI. I developed my own PCI design, and did not use theirs, although theirs is not bad. Be aware that some vendors claim PCI compliance, but they do not have the internal resources to implement a decent size design, or do not really make the timing. 33mhz is really not all that easy in something as complicated as a PCI interface, but it can be done with carefull design and floorplanning. Austin Franklin darkroom@ix.netcom.comArticle: 4351
In article <01bbbc56$3faf8f20$0fd9e426@pmw> "Peter McLeod Wilcox" <pmw@techatl.com> writes: >As with most things, it depends :). The XC4000s have 4 primary and 4 >secondary global buffers, all of which are good choices for internal clocks >(secondaries have a few nSecs more skew). The secondary global clocks have more initial delay, but the end point skews are the same as for the primaries. The clock tree has a significant delay (device specific, but 7 to 15 ns, primarilly a function of device size) from the source (bufgp or bufgs) to the clock distribution lines in each column but these are all ballanced. The clock signal starts at the bufgp/gs (in a corner), and is hard wired to the center of the chip where it is then distributed horizontally in the central routing channel. In each column there are 4 clock lines (vertical, reserved for clock ONLY), and from these there are connections to the clock pins of the CLBs. Both primaries and secondaries use the same topology, except the mapping from the secondaries in the central channel to the clock lines in the columns is more flexible. This adds between .5 and 1 nS for the distribution of the secondaries (depending on 4000 or 4000E, and speed grade). The SKEW between the thousands of potential endpoints is always less than a nanosecond, and is always less than the clock to out of the flip flops which is why the clock nets are what you should be using for distributing clocks. >The secondary global buffers may >be sourced by internal logic, and not just the I/O pin, so your devide by >two could be generated inside the FPGA. The choice is going to depend on >the frequency of the clock and your maximum allowable skew. A problem with dividing a clock by two and distributing it is that the divided clock from the flip flop will have not only been divided by two, but also it will be delayed in phase by the clock yo out time of the flip flop. If your design had the initial clock on a bufgp/gs clock net, and you used a divide by 2 FF in a corner, which you routed to the bufgs in the same corner, then the skew between these two clocks is going to be quite significant! It is the clock distribution delay (7 to 15 nS depending on device size and speed grade) plus Tcko (3 to 5 nS) plus routing to the bufgs (another 1 or 2 nS). This looks pretty icky to me, so I would want to figure out another way. Almost certainly clock this FF from the clock pin directly, rather than the global clock net (will save most of the 7 to 15 nS). Or be more creative. A far better way to do this is to have all the FFs on the same clock net (the non divided clock), and use the divided by 2 clock to connect to the CE pins of the FFs you want to run at half speed. If there are many of these, then this idea may not be too good either. As with most problems of this type, we are trying to help an initial poster who failed to give enough info for us to be able to give good specific help. Are the two clock domains synchronous or not with each other. What is their phase relationship. How fast are these clocks. How much logic runs at each frequency. Why are there two clock domains. Is there another clock running twice as fast as the faster clock. . . . >It should also >be noted that the secondary global buffers use global routing resources - >I've had designs that would not route when I assigned a signal to a BUFGS >because it (the clock) hogged the long lines. Well this isn't true. The bufgs does not use long lines, only clock lines. The router when it gets desperate has been known to use the bufgs resource for non clock signals as a last ditch attempt to route a design and if your design was in that state, using the bufgs remove that escape path for the router. Usually some floor planning of the design will make routing much easier, and so such desperate measures will not be needed. > >If you can provide some more information on frequency and timing >requirements I might be able to give a better answer. > Me too. :) Philip FreidinArticle: 4352
In article <5470mg$jcq@news.iastate.edu> Shawn Lee <lxd@iastate.edu> writes:
>Another question: Who knows the actual size of the XC3164A and XC4000E.
>I can not find them on the web.
>Shawn Lee
>lxd@cpre1.ee.iastate.edu
>lxd@iastate.edu
The XC3164A is this big (I am holding up my right hand, and thumb and
first finger are "this" far apart).
The XC4000E is "this" big (same thing).
Are you asking:
Package size
CLBs
gates
die size
market share
.
.
.
Note: the XC4000E is a familly of a dozen different parts.
The 3164A comes in many different packages and speed grades.
Philip.
Article: 4353I would agree that the VHDL tools have improved significantly over the past few years, but you will never be able to get the speed and density with any HDL as you can with schematic. VHDL is not a very good tool for data path. Most people like to see a data flow, and an HDL does not lend it self to visualization like schematics do. For state machines, and random logic, an HDL is certainly much easier to follow and understand than a schematic. With Viewlogic (may be other schematic tools too) it is quite easy to do schematics mixed with HDL (VHDL, XABEL I don't know about Verilog). Since someone has to maintain the design (usually) and it's (usually) not the original designer, anything that can be done to make the design self explanitory is good in my book. Also, in Viewlogic, you can simulate the entire design (schematic, VHDL/XABEL) with no difficulty. You don't even need to compile it! This only gives unit delay simulations, but if you make all your static timing numbers (TIMESPECs) then full timed simulation becomes an option. Another thing, at least for FPGA designs, it is real good to do floorplanning of data path. If you leave the data path unfloorplanned, if it gets a bad placement (usually all the time) it will use up many more routing resources, and have much longer delays. If you have an internal bus, with TBUFs and registers, schematics make it easier to get consistent names to these elements, and therefore place them. VHDL gives kind of random names, different for each compile, unless you spend a lot of time massaging the VHDL to give you consistent names. A good number of contracts I have had have involved cleaning up a VHDL FPGA design that did not fit in the part (obese) or was too slow. I had to either re-do the VHDL so we could floorplan the design to make timing, or re-doing most of the design in schematic (even some state machines/control logic). This is only my humble opinion based on my experiences. Austin Franklin darkroom@ix.netcom.comArticle: 4354
Actually there is a much more complete solution found in the Xilinx Solutions Database: http://www.xilinx.com/techdocs/902.htm There are more steps to be done than just installing the Rainport driver. Following these steps should get people running with the DOS version (5.2.1) of the XACTstep software in either Windows NT 3.51 or 4.0. david. David Dye Technical Applications Engineer Xilinx, Inc., San Jose, CA ph> (408) 879-5370 email> david.dye@xilinx.comArticle: 4355
=============================================================================
Call for Papers
1997 International Symposium on Physical Design
April 14-16, 1997
Napa Valley, California
Sponsored by the ACM SIGDA in cooperation with
IEEE Circuits and Systems Society
The International Symposium on Physical Design provides a forum to
exchange ideas and promote research on critical areas related to the
physical design of VLSI systems. All aspects of physical design, from
interactions with behavior- and logic-level synthesis, to back-end
performance analysis and verification, are within the scope of the
Symposium. Target domains include semi-custom and full-custom IC, MCM
and FPGA based systems.
The Symposium is an outgrowth of the ACM/SIGDA Physical Design
Workshop. Following its five predecessors, the symposium will
highlight key new directions and leading-edge theoretical and
experimental contributions to the field. Accepted papers will be
published by ACM Press in the Symposium proceedings. Topics of
interest include but are not limited to:
1. Management of design data and constraints
2. Interactions with behavior-level synthesis flows
3. Interactions with logic-level (re-)synthesis flows
4. Analysis and management of power dissipation
5. Techniques for high-performance design
6. Floorplanning and building-block assembly
7. Estimation and point-tool modeling
8. Partitioning, placement and routing
9. Special structures for clock, power, or test
10. Compaction and layout verification
11. Performance analysis and physical verification
12. Physical design for manufacturability and yield
13. Mixed-signal and system-level issues.
IMPORTANT DATES: Submission deadline: December 20, 1996
Acceptance notification: February 1, 1997
Camera-ready (6 page limit) due: March 1, 1997
SUBMISSION OF PAPERS:
Authors should submit full-length, original, unpublished papers
(maximum 20 pages double spaced) along with an abstract of at most
200 words and contact author information (name, street/mailing address,
telephone/fax, e-mail).
Electronic submission via uuencoded e-mail is encouraged (single
postscript file, formatted for 8 1/2" x 11" paper, compressed with
Unix "compress" or "gzip''). Email to:
ispd97@ece.nwu.edu
Alternatively, send ten (10) copies of the paper to:
Prof. Majid Sarrafzadeh
Technical Program Chair, ISPD-97
Dept. of ECE, Northwestern University
2145 Sheridan Road, Evanston, IL 60208 USA
Tel 847-491-7378 / Fax 847-467-4144
SYMPOSIUM INFORMATION:
To obtain information regarding the Symposium or to be added to the
Symposium mailing list, please send e-mail to ispd97@cs.virginia.edu.
Information can also be found on the ISPD-97 web page:
http://www.cs.virginia.edu/~ispd97/
SYMPOSIUM ORGANIZATION:
General Chair: A. B. Kahng (UCLA and Cadence)
Past Chair: G. Robins (Virginia)
Steering Committee: J. Cohoon (Virginia), S. Dasgupta (Sematech),
S. M. Kang (Illinois), B. Preas (Xerox PARC)
Program Chair: M. Sarrafzadeh (Northwestern)
Keynote Address: T. C. Hu (UC San Diego) & E. S. Kuh (UC Berkeley)
Special Address: R. Camposano (Synopsys)
Publicity Chair: M. J. Alexander (Washington State)
Local Arrangements Chair: J. Lillis (UC Berkeley)
Technical Program Committee: C. K. Cheng (UC San Diego)
W. W.-M. Dai (UC Santa Cruz)
J. Frankle (Xilinx)
D. D. Hill (Synopsys)
M. A. B. Jackson (Motorola)
J. A. G. Jess (Eindhoven)
Y.-L. Lin (Tsing Hua)
C. L. Liu (Illinois)
M. Marek-Sadowska (UC Santa Barbara)
M. Sarrafzadeh (Northwestern)
C. Sechen (Washington)
K. Takamizawa (NEC)
M. Wiesel (Intel)
D. F. Wong (Texas-Austin)
E. Yoffa (IBM)
=============================================================================
Article: 4356I'm interested to hear opinion on Actel's new SPGA devices... Also - Does anyone have an indication of pricing & availability of these? Peter FennArticle: 4357
I would like to use Lattice's ispLSI2032LV CPLD in my design. It is a ISP 3.3V supply CPLD and the input signal can be either 3.3V or 5V. Anyone has experience in using it before? Please let me know whether there is any problem this chip. Thanks in advance. -- ****************************************************************************** * Wong Man Kit 黃文傑 * ****************************************************************************** * Email address * 96kwong@alumni.ee.ust.hk * 電郵地址 * * Home page * http://eelindc1.ee.ust.hk/~eekwong * 網頁 * ******************************************************************************Article: 4358
96kwong@uxmail.ust.hk (Wong Man Kit) wrote: >I would like to use Lattice's ispLSI2032LV CPLD in my design. It is a ISP >3.3V supply CPLD and the input signal can be either 3.3V or 5V. Anyone >has experience in using it before? Please let me know whether there is any >problem this chip. >Thanks in advance. >-- >****************************************************************************** >* Wong Man Kit 黃文傑 * >****************************************************************************** >* Email address * 96kwong@alumni.ee.ust.hk * 電郵地址 * >* Home page * http://eelindc1.ee.ust.hk/~eekwong * 網頁 * >****************************************************************************** While I haven't used the LV variant of the 2032, I have done several designs using the isp2032 and isp2064. I recommend the Data I/O Synario toolset instead of the Lattice PDS. I suggest that you simulate your design if at all possible and lock your pinouts afterwards. Depending upon what changes you may make later, it may or may not be possible to route to the same pinouts if the design tends to fill the device. I got burned by fixing the pinout on a design to make my board layout easier and then couldn't route to those pins after finishing the design. Steven J. Ackerman Consultant ACS, Sarasota, FL sja@gte.net http://www.acscontrol.comArticle: 4359
Workview Office Student Edition is now available! The Student Editon provides students and universities with industry's premier design tools for obtaining real world design solutions. A complete product description can be obtained from our web page, http://www.prenhall.com. For other information contact, Prentice Hall customer service, 1-800-374-1200. Tom Robbins Prentice HallArticle: 4360
Hi, Does anyone have the experience with Altera flex 10K device? I have encountered some very strange phenomenon with it. I use a Flex 10K50, setting it at PS mode as described at the databook. Each time I powered on the system, the CONFIGURE_DONE pin will go to "1". Then I set the nCONFIG pin to low, this should make the CONFIG_DONE pin to go to "0" as described by the databook. However, it remains a "1" on CONFIG_DONE. Does anyone have any idea about the possible cause except that the device is bad? Feng Yun Computer Engineering UCSCArticle: 4361
Call Altera at 1-800-800-EPLD the hot line is VERY helpful !!! > Does anyone have the experience with Altera flex 10K device?Article: 4362
Austin, I thought I would never hear anyone say this. Having tried to get into VHDL myself, I feel exactly the same way about it. But there is so much hype in the press, and so many people are trying to use it for applications for which good old schematic entry would have been far more appropriate. On top of that, a schematic can compile only into *one* netlist (assuming no bugs in the netlister). But an HDL program can itself have bugs in it, just like any other programming language. And my feeling on VHDL is that its syntax has a few too many "suprises". I do probably 3-4 fairly big FPGA designs each year, and one needs to do more just to keep fluent in this language. Peter. >I would agree that the VHDL tools have improved significantly over the past >few years, but you will never be able to get the speed and density with any >HDL as you can with schematic. > >VHDL is not a very good tool for data path. Most people like to see a data >flow, and an HDL does not lend it self to visualization like schematics do. > For state machines, and random logic, an HDL is certainly much easier to >follow and understand than a schematic.Article: 4363
It would be a miracle if you can get $2 on just 10k, and certainly not *including* the NRE. In 1987-89 this sort of pricing would have been commonplace, but not now. I recently did an ASIC, ~2500 gates, and this is $3 in 100k qty. >Looking for a rough coast estimate, to convert a 3020 fpga to an asic. >Quantity would be 10,000. Need a piece price under $2.00, excluding all >NRE and setup cost. > > >JimCArticle: 4364
Yun Feng wrote: > Does anyone have any idea about the possible cause except that > the device is bad? It could be that you are not asserting the nCONFIG for long enough time. -- Rune Baeverrud <r@acte.no> Field Application Engineer |\ _,,,---,,_ ScandComp, ACTE NC Norway AS ZZzz /,`.-'`' -. ;-;;,_ P.O. Box 190, N-2020 Skedsmokorset, Norway |,4- ) )-,_..;\ ( `'-' Tel: +47 6389 8969 Fax: +47 6389 8979 '---''(_/--' `-'\_)Article: 4365
Peter, > I thought I would never hear anyone say this. > > Having tried to get into VHDL myself, I feel exactly the same way > about it. But there is so much hype in the press, and so many people > are trying to use it for applications for which good old schematic > entry would have been far more appropriate. > > On top of that, a schematic can compile only into *one* netlist > (assuming no bugs in the netlister). I've never seen a bug in my netlister, but I've seen plenty of bugs in the libraries! Cheers, ScottArticle: 4366
A number of problems exist with HDLs in general. One is you don't know exactly what the code is going to compile down to... Kind of like the difference between a C program and assembly code..., though I would hardly consider a good hierarchical schematic assembly code. C is great for fast proccessors with lots of memory (ASICs), but for a small slow micro (FPGAs) it's not as good. In an HDL, a case statement can become this really obese thing checking for every possible condition for each branch... I certainly believe you can do pretty well with some finely crafted HDL code, if you know exactly what it is going to compile down to. Second is controlability. It is much harder to floorplan an HDL design. Much harder... I find that floorplanning is the real key to resource utilization and speed, especially for FPGAs. Personally, I like to mix both...but schematics is really the way to go for the best speed and resource utilization. I do schematics with my own libraries of n bit registers, tbufs, counters, muxes. They are device independent, and require very little library work to add a new device. You may save time writing with HDL up front, but if it is for a fast/dense design, you will spend a great amount of time massaging it, rewriting it, or you may not even be able to use it at all, or spend a lot more money on a larger, faster part. I have some clients who I told them they would only have to pay me what I save them. For one, I converted their VHDL to schematics, went down two part sizes, and two speed grades, saving $46 per board, and the volume is in the thousands! Austin Franklin darkroom@ix.netcom.comArticle: 4367
There are two C -> Xilinx netlisters I know of, and I am curious if anyone has any experience with them, or any others. The first I know of is called NLC, developed by Christian Iseli at the System Logic Lab of the Federal Polytechnical School of Lausanne, Switzerland. The second I know of was developed by the networking group of Digital in California. Thanks, Austin Franklin darkroom@ix.netcom.comArticle: 4368
Anyone making use of links via my EHW/Evolutionary Electronics Resources
web page please note a change of host
*from* kmi.open.ac.uk/~monty/EHW.html, evolelec.html etc
*to* watson.open.ac.uk/~monty/EHW.html, evolelec.html etc
thanks
monty
--------------------------------------------------------------------------
All opinions etc etc...
--------------------------------------------------------------------------
| Tony Hirst ("Monty") | e-mail: A.J.Hirst@open.ac.uk
-------------------------------------------------------------------
Article: 4369To whom it concerns: There is free evaluation copy of a VHDL aware editor called Setanta ED. It runs on Win 3.x, Win95 and Windows NT This editor can: -highlight keywords -template expansions -free VHDL models for commonly used components -integrated to work with Model Technologies Vsystem and Accolade Design Inc. PeakVHDL -No limit to buffer or file size. -Fully user configureable, including menus and the ability to write macro functions. - Also supports C,C++, pascal, HTML, JAVA and up to 20 other languages! For details and your free download, see http://www.vhdl.com.au -John Maher VHDL System Solutions P/L 128 Lt. Lonsdale St. Melbourne Victoria Australia +61 419 897 789Article: 4370
extra z to stop junk mail (zz80@digiserve.com) wrote: : Austin, : I thought I would never hear anyone say this. : Having tried to get into VHDL myself, I feel exactly the same way : about it. But there is so much hype in the press, and so many people : are trying to use it for applications for which good old schematic : entry would have been far more appropriate. : Peter. Agreed 100%. Unfortunately, it is very difficult to work with both tools. I don't know any vendor that provides good integration between schematic entry and an HDL ( I still prefer to write state machines using HDL and not schematic). GeorgeArticle: 4371
Viewlogic does. It is *REAL* easy to do. In ViewDraw, make a symbol for the VHDL code, change the attributes on the symbol to get it to use the VHDL and voila! you have VHDL and schematics. You have to write the VHDL code too... You can do unit delay simulation directly. To compile the chip, and do timed simulation, use any VHDL compiler that supports .xnf output, so when you run xnfmerge it will find the compiled VHDL code... Austin Franklin darkroom@ix.netcom.com > > Agreed 100%. Unfortunately, it is very difficult to work with both > tools. I don't know any vendor that provides good integration between > schematic entry and an HDL ( I still prefer to write state machines > using HDL and not schematic). > > George >Article: 4372
George Noten wrote: (snip) > > Agreed 100%. Unfortunately, it is very difficult to work with both > tools. I don't know any vendor that provides good integration between > schematic entry and an HDL ( I still prefer to write state machines > using HDL and not schematic). > > George mentor graphics provides the ability to capture/simulate mixed vhdl/schematic designs with their qv-pro system (although i've been using qv-pro primarily in all-vhdl mode so far. my "vhdl/xilinx" pet peeves are more with regard to: 1. xilinx not officially supporting xnf netlists synthesized by mentor's autologic II which forces me to use SG to synthesize schematics before going to the XACT backend. 2. lack of xilinx synthesis documentation to support non-synopsys users. this is a crime because many vhdl/fpga users are new to synthesis (as pointed out by someone else in this thread). synopsys won the asic synthesis market, but the fpga market is still up for grabs (eg. exemplar, synplicity). 3. ppr's limited ability to do incremental layout (ala guide file mechanism) when the design is mostly hdl-based. the guide option relies on net names as reference points (but synthesis keeps changing them). i wish xilinx would ressurect some of the neat place/route technology they developed for their ill-fated antifuse family (which was marketed as being "synthesis-friendly"). the 8100 place/route program supposedly performed incrementally not by matching net names, but by performing topological comparison. a cool idea. -- _______________________________________________________________________ Lance Gin "off the keyboard Delco Systems - GM Hughes Electronics over the bridge, OFC: 805.961.7567 FAX: 805.961.7739 through the gateway, C43LYG@dso.hac.com nothing but NET!" _______________________________________________________________________Article: 4373
Austin Franklin wrote: (snip) > > Second is controlability. It is much harder to floorplan an HDL design. > Much harder... I find that floorplanning is the real key to resource > utilization and speed, especially for FPGAs. especially when CLB arrays are involved. i've done standard-cell and structured-custom layout (where physical resources are admittedly often less scarce and not fixed). in each of these paradigms, one reason the place/route problem is less complex than CLB's is because there are fewer primitives to deal with. a 32-bit counter is floorplanned as a *single* (sometimes malleable) entity. but in a CLB array, the floorplanner is confronted with a myriad of primitives which make up the counter! who wants to deal with a bunch of individual F, G, H, and DFF primitives for each single *bit*?! (well, possibly the fpga consultants who make money by "rescuing" fpga projects for a living) ;) add on top of that the effort required to correlate your hdl code to the synthesized instance/net names that appear in the floorplanner and you've got yourself a nice challenge. -- _______________________________________________________________________ Lance Gin "off the keyboard Delco Systems - GM Hughes Electronics over the bridge, OFC: 805.961.7567 FAX: 805.961.7739 through the gateway, C43LYG@dso.hac.com nothing but NET!" _______________________________________________________________________Article: 4374
In article 2da8b8cd@drt1, "Austin Franklin" <darkroom@ix.netcom.com> writes: >A number of problems exist with HDLs in general. One is you don't know >exactly what the code is going to compile down to... Synthesis is a deterministic process! >it's not as good. In an HDL, a case statement can become this really obese >thing checking for every possible condition for each branch... In In IEEE Standard Logic 1164 there is a dontcare value and in HDLs there is something like 'others' or 'default' statements ... >believe you can do pretty well with some finely crafted HDL code, if you >know exactly what it is going to compile down to. Same with schematics, only finely crafted schematics... >Second is controlability. It is much harder to floorplan an HDL design. >Much harder... I find that floorplanning is the real key to resource >utilization and speed, especially for FPGAs. HDL has nothing to do with floorplanning, you have to floorplan a schematic and a HDL design. >Personally, I like to mix both...but schematics is really the way to go for >the best speed and resource utilization. I do schematics with my own >libraries of n bit registers, tbufs, counters, muxes. In VHDL there are generics for this, and you can create also small libraries with registers, counters AND in a non-fixed width! >They are device independent, This one of the big advantage of HDLs. With one HDL DEscription I can do a FPGA from XILINX, ACTEL or what you want AND an ASIC. The only thing you need is the appropriate setup file and the technology libs. But only one HDL description. and require very little library work to add a new device. You >may save time writing with HDL up front, but if it is for a fast/dense >design, you will spend a great amount of time massaging it, rewriting it, Why? When the counter will get bigger i have to change only a generic . Is this a great amount? >I have some clients who I told them they would only have to pay me what I >save them. For one, I converted their VHDL to schematics, went down two >part sizes, and two speed grades, saving $46 per board, and the volume is >in the thousands! I bet, optimization of the VHDL to better VHDL had saved more than $46! Andreas
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