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
The problem is that there are many ways to define and design a FIFO, depending on the relative timing requirements for write and read. Very few FPGA designs are interested in a slow FIFO, and not too many want it restricted to a single clock. With independent asynchronous writing and reading at 40 to 80 MHz, you need arbitration, or asynchronous FULL/EMPTY detection, and you really need to watch the logic and the layout. FIFOs are very simple at the global and conceptual level, but quite demanding in their details, especially when implemented in silicon that is not infinitely fast. Peter Alfke, Xilinx ApplicationsArticle: 7476
Hi All, I don't understand why the big fuss about FIFOs. It seems to be a recurring topic on this newsgroup. Why not just model the FIFO in behavioural VHDL and let the synthesis tool worry about the details. It may have it's price to pay in terms of surface and performance but you could design your custom FIFO in a few hours tested and all. Or perhaps the optimisation is really necessary ? Sam FalakiArticle: 7477
Steve Gross wrote:
Message copied to comp.arch.fpga from comp.sys.mentor:
>
> Hi,
>
> I am doing Xilinx xc4k FPGA designs in Mentor Graphics. I do schematic
> capture in Design Architect, then use Enwrite to make an EDIF
> netlist which I feed to the Xilinx FPGA place-and-route tools.
>
> Before Xilinx released the M1 tools (I am using M1.3.7), I used
> the NeoCAD back-end tools upon which the M1 tools are based (to
> put it mildly).
>
> While making the transition from NeoCAD to M1, (and simultaneously
> retargeting my design for xc4ke parts rather than xc4k parts), I
> ran into a few problems. While sorting those problems out, I was
> looking carefully at the Xilinx xc4k symbol library vs. the xc4ke
> symbol library, and noticed something funny (which is probably
> unrelated to my problems, but curious nonetheless):
>
> The "primitive" symbols (e.g. inv, and2, ibuf, etc) in the xc4k
> library all have the __qp_prim property, as follows:
>
> __qp_prim = CASE (model)
> {(S:XC4000 :S:4:TRUE);
> (OTHERWISE :U:17:<UNDEFINED VALUE>); }
>
> While the corresponsing symbols in the xc4ke library have no such
> property.
>
> In my "old" EDIF netlists (made by the NeoCAD tools, from the xc4k
> symbols, targeting an xc4k FPGA), these primitives all had the
> __qp_prim property with a value of "TRUE."
>
> In my "new" EDIF netlists (made by the Xilinx tools, from the xc4ke
> symbols, targeting an xc4ke FPGA), these primitives had no __qp_prim
> property (as expected).
>
> But when I fed the "old" design (with xc4k symbols) into the "new"
> tools (again targeting the xc4ke FPGA), these primitives had the
> __qp_prim property set to the complicated CASE statement seen above.
>
> So, after this long preamble, the questions are:
>
> 1. What is the __qp_prim property used for
>
> 2. How should I parse the syntax of the CASE statement
>
> 3. How does Enwrite know to set the property to TRUE when targeting
> xc4k devices, but simply pass the whole CASE statement through
> when targeting xc4ke devices?
>
> I looked at the Mentor and Xilinx on-line docs, but couldn't find
> any real information.
>
> Thanks in advance,
>
> -Steve Gross gross@pa.msu.edu
Article: 7478hi sam, i use mostly the actels. and when generating a fifo (or any sram structure) in the 3200dx series, a macro generator with a simple form to be filled out is used to create a logic block properly configured with all of the logic done, flags, etc. no modelling or synthesizing is necessary and it takes just a few keystrokes and a minute or so to generate a correct, efficient implementation - even symbol generation is automagic. i'm pretty sure the other vendors have similar capabilities and i'm sure you'll be hearing from them. hope this helps, ------------------------------------------------------------ rk "there's nothing like real data to screw up a great theory," - me, modified from the slightly more colorful original ------------------------------------------------------------ Sam Falaki <Falaki@uqtr.uquebec.ca> wrote in article <341D780F.4772@uqtr.uquebec.ca>... > Hi All, > > I don't understand why the big fuss about > FIFOs. It seems to be a recurring topic > on this newsgroup. Why not just model the > FIFO in behavioural VHDL and let the synthesis > tool worry about the details. It may have > it's price to pay in terms of surface and > performance but you could design your custom > FIFO in a few hours tested and all. Or perhaps > the optimisation is really necessary ? > > Sam Falaki >Article: 7479
> Did you know that BookPool is selling your book and disk fort $36.00? > > Is it any different than what you or I are selling? Hi Richard, If it's "VHDL Made Easy!" then that's a good price. Of course it will almost certainly have last year's CD-ROM in it until Prentice Hall runs out of stock and reprints. What we are offering includes the new CD with more up-to-date simulator software. Of course, anyone who bought the book before and has the old demo simulator can and should go to www.acc-eda.com and download the latest version. Regards, DaveP -- David Pellerin -- Accolade Design Automation -- (800) 470-2686Article: 7480
FPGA `98
Call for Papers
1998 Sixth ACM International Symposium on
Field-Programmable Gate Arrays
DoubleTree Hotel, Monterey, California
February 22-25, 1998
http://www.ece.nwu.edu/~hauck/fpga98
==========================================================
As Field-Programmable Gate Arrays become more essential to the design of
digital systems there is increased pressure to improve their performance,
density and automatic design. This symposium follows the largest ever
gathering of this kind last year in Monterey at FPGA `97. For FPGA `98,
we are once again soliciting submissions describing novel research and
development in one or more of the following (or similar related) areas
of interest:
FPGA architecture: logic block & routing architectures, I/O structures
and circuits, new commercial architectures.
CAD for FPGAs: placement, routing, logic optimization, technology
mapping, system level partitioning, testing and
verification.
Interactions: between CAD, architecture, applications, and
programming technology.
Fast prototyping: for System level design, Multi-Chip Modules.
Applications: use of FPGAs in novel circuits, as emulators and
compiled accelerators.
Field-programmable interconnect chips and devices (FPIC/FPID.)
FPGA-based compute engines.
Field-programmable analog arrays.
==========================================================
Authors should submit 20 copies of their paper (12 pages maximum) by
September 26, 1997. Notification of acceptance will be sent by December 1,
1997. The authors of the accepted papers will be required to submit the
final camera ready copy by December 15, 1997. A proceedings of the accepted
papers will be published by ACM, and included in the ACM/SIGDA CD-ROM
publications. All submissions should be sent to:
Sinan Kaptanoglu
FPGA `98
Actel Corporation
955 East Arques Avenue,
Sunnyvale, CA 94086 USA
e-mail:sinan@actel.com
phone: (408) 522-4319
fax: (408) 522-8041
==========================================================
General Chair: Jason Cong, UCLA,
Financial Chair: Carl Ebeling, U. of Washington,
Program Chair: Sinan Kaptanoglu, Actel,
Publicity Chair: Scott Hauck, Northwestern U.
============================
Technical Program Committee:
============================
Michael Butts, Quickturn
Jason Cong, UCLA
Eugene Ding, Lucent
Carl Ebeling, U. of Washington
Scott Hauck, Northwestern U.
Dwight Hill, Synopsys
Brad Hutchings, BYU
Sinan Kaptanoglu, Actel
David Lewis, U. of Toronto
Fabrizio Lombardi, Texas A&M
Jonathan Rose, U. of Toronto
Rob Rutenbar, CMU
Malgorzata Marek-Sadowska, UCSB
Gabriele Saucier, IMAG
Martine Schlag, UCSC
Tim Southgate, Altera
Steve Trimberger, Xilinx
John Wawrzynek, UCB
Martin Wong, UT at Austin
============================================================================
Sponsored by ACM SIGDA, with support from Actel, Xilinx, Altera, and Lucent.
============================================================================
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Scott A. Hauck, Assistant Professor |
| Dept. of ECE Voice: (847) 467-1849 |
| Northwestern University FAX: (847) 467-4144 |
| 2145 Sheridan Road Email: hauck@ece.nwu.edu |
| Evanston, IL 60208 WWW: http://www.ece.nwu.edu/~hauck |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 7481
Hallo,
At the moment I am working on a prototype of an upgrade of a component
for which one of the major requirements is compatibility with its
predecessor (a full custom device with very old technology).
The prototype will consist out of 6 FPGAs, so a test board is being
developed also (prototype must run at speed (8MHz)).
Now I am facing with the following problem :
- I have a VHDL netlist which describes logically how the 6 FPGA's
are interconnected (and also what is inside each FPGA).
But for the board design I need to map these logical connections
towards physical pin numbers.
I would like to know if anybody of you knows a good way to bring the
"logical" information towards the "physical" pinnumbers.
If I look to a normal flow it is :
- first define interconnection (logically)
- assign physical pin number (to the logical pins)
- draw a schematic
- generate netlist for PCB (printed circuit board)
- place&route PCB.
Now the physical pin assignment depends on :
- placement of components on the board,
- optimal/good routability
- optimal/good pin assignment for internal routing of the FPGA
Has somebody had some experience with this, and wants to share this ?
Thanks
--
Koenraad SCHELFHOUT
Switching Systems Division http://www.alcatel.com/
Microelectronics Departement - VH14 _______________
________________________________________\ /-___
\ / /
Phone : (32/3) 240 88 93 \ ALCATEL / /
Fax : (32/3) 240 99 47 \ / /
mailto:ksch@sh.bel.alcatel.be \ / /
_____________________________________________\ / /______
\ / /
Francis Wellesplein, 1 v\/
B-2018 Antwerpen
Belgium
Article: 7482Hi, I'm having problems with an SDF back annotated VHDL netlist produced from the Xilinx M1 tools. The problem is with the minimum clock pulse width value annotated into the SDF file for input IOB flip-flops. The value is 6.4ns - basically what I want to know is whether this is correct, as the data sheets only quote a pulse width value for ouput IOB flip-flops - 3 ns. This also appears in the SDF file as 6.4 ns (hmm...) - hence the reason for querying the input value. If the SDF values are wrong (hopefully :-)) then what would be good values to put in instead? Cheers Dave -- David Storrar | In a vain attempt to stem the Development Engineer | tide of spam, my return address GEC-Marconi Avionics | has been "munged" (horrid word). E-Mail: david.storrar @ gecm.com | Remove the obvious bit to reply. --Article: 7483
Please note that the correct URL is http://www.plnv.com Sorry Murray DismanArticle: 7484
>We are redesigning a board with telecommunication stuff, that contains a >6809 processor. >The processor is being discontinued and we are looking for a way to >avoid major SW-rework. >Has anyone put this processor into an FPGA? >Are there estimations how many resources in an FPGA it would take >(Altera FPGAs)? >It seems that none of the IP-companies offers such a core at the present >time. We've asked Moto many times if they would license the patents they have on the 68xx family. So far they've said no... But if they are discontinuing the 6809, I know of several other companies who may also be interested, if we can get Moto to allow it... Please contact me and we can disuss further... -- Eric Ryherd eric@vautomation.com VAutomation Inc. Synthesizable VHDL and Verilog Cores 20 Trafalgar Sq. #443 http://www.vautomation.com Nashua NH 03063 (603) 882-2282 FAX:882-1587Article: 7485
Sun S1000 Chassis complete w/ (1) motherboard, 2X Mod 51 CPU 4x32Mb,4x 535Mb disks, CDROM,..................... $5,500 Sun S20 w/ 20" color (refurb), TX1, Mod 51, 64Mb,1Gb disk... $4,100 Sun Sparc 2, 4/75GX-32-P43 includes 501-2039 GXplus 365-1160 19" color, 32mb, 424mb disk.......... $900 Sun IPX, 4/50GX-16-P43, 365-1160 19" color,16Mb, 424Mb disk. $650 Sun Sparc 2 base: Chassis, PS, CPU, Floppy................... $200 Sun IPX base: Chassis, PS, CPU, Floppy......................... $175 Sun 501-2942 Ultra 2 167Mhz processor ......................... $900 Sun 501-1823 32Mb sbus memory for sparc 2................... $350 Sun 501-1910 printer card...................................... $195 Sun 501-2981 fast SCSI/ Ethernet ...............................$525 Sun 501-1931 serial parallel controller ........................$300 Sun X1008A serial parallel option (complete) ...................$650 Sun X6202A 14Gb, 8mm tape pack................................. $1,400 Sun X6254A 4-8Gb 4mm unipack ................................ $750 Sun 501-1845 ZX frame buffer .................................. $650 Sun 501-2634 single buffer Creator card ....................... $950 Sun 501-2253 TX4 frame buffer ................................ $650 Sun 501-2325 TX1 frame buffer ................................ $400 Sun 501-2039 GXplus frame buffer .............................. $250 Sun 365-1335 20" color monitors (unused) ..................... $900 Sun 365-1330 20" color monitors (unused) ...................... $850 Sun 365-1160 19" Sony Trinitrons .............................. $425 SGI Indigo 2 w/ 192Mb, 195Mhz R10,000, Maximum Impact Graph. 4Mb raster mem.,2Gb disk, 20" color ............ $15,900 SGI Indigo 2 w/ 64Mb, 150Mhz, Extreme Graph.., 2Gb , 20" color $4,650 SGI Indigo 2 w/ 64Mb, 100Mhz, XZ Graph., 2Gb disk, 17" color $2,975 (2000) Sun Sparc 5/ 20 disk drive brackets .................... $7ea (qty 100) $5ea -- Brandon Unger Recurrent Technologies, Inc. 3270 Keller Street #114 Santa Clara, CA 95054 Phone: 408-727-1122 Fax: 408-727-8002 http://www.recurrent.com/ brandon@recurrent.comArticle: 7486
I did a board very similar to yours (6 FPGA, Verilog through Synopsys, etc.) and we had a rough time with designing the board. Because we were prototyping, the board and the code had to _evolve_ together. We had a basic guess as to what the nets needed to look like, but we also had to be able to change when mistakes / problems arose. So, we provided lots of extra space for adding circuitry, but we also used things called dogbones. These are simply two vias connected by a surface trace. This way, if we needed to change the net, we could cut the trace and drop a wire into each hole to re-wire it. A variation is a "zero ohm resistor" which is a wire you drop and solder into the sockets (but that was two extra holes to solder for each net.) However, both of these approaches increase the size of the board tremendously. Another device (I think Xilinx provides one) that could be useful (but we didn't use) is a programable router. Basically you program the routing device like an FPGA and it connects up your nets. There are obvious timing concerns with this, but 8K seems slow enough... maybe. :) Other people I know have finalized their code and let the software determine the best pinout (in reguards to timing, routeing, etc.) THEN they design the board. What they would do was run several FPGA PPR (placement partition and routing) and pick the best (fewest CLBs used, Fastest time from pin to pin, etc.) and then take these pin placements and place them into the constraints file. Hope this helps, John PS> Do you know what size/family of FPGA you are going with? -- John ArchambeaultArticle: 7487
I'm not sure what you are talking about. What is Alliance v3.0? Are you using the Xilinx 3020 to generate an external ROM for a system you are working on? Are you asking about how to program a Xilinx 3020 with a ROM code, like from a PROM? - John >Hello! > >I am looking any information about XILINX 3020 >homemade programmer. Now, I am working with >Alliance v3.0 but I have not idea how generate >the external ROM. > >Please, write to ea3ghs@lleida.hnet.es > >eduardo alonso >http://lleida.hnet.es/~ea3ghs > >Thanks in advance -- John Archambeault Path: ix.netcom.com!tor-nx1.netcom.ca!news.sprintisp.com!sprintisp!ais.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!baron.netcom.net.uk!netcom.net.uk!rill.news.pipex.net!pipex!cold.news.pipex.net!pipex!lade.news.pipex.net!pipex!burn.news.pipex.net!pipex!hose.news.pipex.net!pipex!weld.news.pipex.net!pipex!gecm.com!usenetArticle: 7488
++++++++++++++++++++++++++++++++++++++++++++++++++ Papers due: October 10, 1997 ++++++++++++++++++++++++++++++++++++++++++++++++++ =========================================================== International Conference on Application of Concurrency to System Design (CSD'98) =========================================================== CALL FOR PAPERS =========================================================== March 23-26, 1998, Aizu-Wakamatsu, Japan Sponsored by: The IEEE Computer Society - VLSI-TC, The IEICE TG on Concurrent System Technology, The SICE TG on Discrete Event Systems, The IMACS scientific association In Cooperation With: IFIP WG 10.3, 10.5, The University of Aizu The UN University/IIST, Formal Methods Europe GENERAL CHAIR: Shoichi Noguchi - noguchi@u-aizu.ac.jp The University of Aizu, Japan PROGRAM CHAIRS: Wolfgang Reisig (theory) Humboldt Universitat zu Berlin, Germany reisig@informatik.hu-berlin.de tel.+49-30-20181219, fax:+49-30-20181221 Luciano Lavagno (application) Politecnico di Torino, Italy Cadence Berkeley Labs, USA lavagno@polito.it, luciano@cadence.com tel.+39-11-5644150, fax:+39-11-5644099 CONFERENCE CO-CHAIRS: Sadatoshi Kumagai - Osaka Univ., Japan kumagai@pwr.eng.osaka-u.ac.jp tel.+81-06-879-7693, fax:+81-06-875-2672 Alex Kondratyev - kondraty@u-aizu.ac.jp The University of Aizu, Japan tel.+81-242-372557, fax:+81-242-372744 PUBLICATION CHAIR: Masaru Naniwada - NEC Corp., Japan, naniwada@pepo.tmg.nec.co.jp PUBLICITY CHAIR: Tomohiro Yoneda - yoneda@cs.titech.ac.jp, Tokyo Institute of Technology, Japan FINANCE CHAIR: Kazuaki Yamauchi - yamauchi@u-aizu.ac.jp The University of Aizu, Japan LOCAL ARRANGEMENT CHAIR: Yuko Kesen - kesen@u-aizu.ac.jp The University of Aizu, Japan TUTORIAL/CAD BOOTH CHAIR: Alexander Taubin - taubin@u-aizu.ac.jp The University of Aizu,Japan INDUSTRY RELATIONS: Shinichi Honiden - Toshiba Corp., Japan, honiden@ssel.toshiba.co.jp Yoshihiro Ueda - OkI Electric, Japan ueda@wbg.telcom.oki.co.jp Naoshi Uchihira - Toshiba Corp., Japan, uchi@ssel.toshiba.co.jp The International Conference on Application of Concurrency to System Design is being organized as a forum for disseminating advanced research results on theory and practice of design of concurrent systems. While there are a few ``success stories'' in this field, there is a real need to provide practitioners with adequately sound and expressive tools, and researchers with real motivations and examples. The aim of this conference is to contribute towards this goal by bringing together experts in a wide variety of fields related to complex concurrent system design and analysis. TOPICS OF INTEREST: Formal and semi-formal models: Petri nets, Temporal Logics, Data Flow nets, Statecharts, Synchronous Languages, HDLs, etc. Formal methods for CAD and verification of concurrent systems: model checking, asynchronous design, high-level synthesis, hardware/software co-design, etc. Real-time and hybrid systems Case studies of concurrent systems design and verification Presentation of software tools supporting the above topics PAPERS: Submitted papers should be no more than 15 pages in 11-point font with a 60-word abstract, and should include a cover page with authors' physical and e-mail addresses, phone and FAX numbers. Prospective authors should submit six single-sided copies of the manuscript with a cover-page by October 10, 1997 to: (1) Theoretical papers: Wolfgang Reisig (CSD98), Humboldt-Universität zu Berlin, Institut für Informatik, Unter der Linden 6, 10099, Berlin, Germany (2) Application papers: Luciano Lavagno (CSD98), Cadence Berkeley Labs, 1919 Addison St. #303-304, Berkeley - CA 94704-1144, USA Accepted papers are intended to appear in series by the IEEE Computer Society Press. A limited number of travel grants will be available for conference contributors. INFORMATION: The University of Aizu: csd@u-aizu.ac.jp, Phone : (+81) 242 37 2557, Fax : (+81) 242 37 2744 On the World Wide Web at URL: http://www.u-aizu.ac.jp/csd98/ IMPORTANT DATES: Papers due: October 10, 1997 Notification of acceptance by: December 1, 1997 Final Version by: January 5, 1998 PROGRAM COMMITTEE: Gerard Berry (France) Manfred Broy (Germany) Roy Campbell (USA) Edmund Clarke (USA) Jordi Cortadella (Spain) Jorg Desel (Germany) Javier Esparza (Germany) Jean-Luc Gaudiot (USA) Kunihiko Hiraishi (Japan) Rene Jacquart (France) Tomasz Janowski (Macau) Timothy Kam (USA) Shmuel Katz (Israel) Michael Kishinevsky (Japan) Bob Kurshan (USA) Edward Lee (USA) Dong-Ik Lee (Korea) Shin-ichi Minato (Japan) Takashi Nanya (Japan) Mogens Nielsen (Denmark) Kenji Onaga (Japan) Carl Pixley (USA) Patrick Scaglia (USA) Fabio Somenzi (USA) Pasupathy Subrahmanyam (USA) Achim Sydow (Germany) P.S. Thiagarajan (India) Antti Valmari (Finland) Jim Woodcock (UK) Zhou Chaochen (Macau) -- Kind regards, Alexander Taubin THE UNIVERSITY OF AIZU phone +81-242-37-2572 (office) Tsuruga, Ikki-machi, Aizu-Wakamatsu City fax +81-242-37-2744 Fukushima, 965-80 Japan, e-mail taubin@u-aizu.ac.jpArticle: 7489
How to get Viewsim of delay file for Orca Cell like viewsim.var for postsimArticle: 7490
thank you
begin 600 Lucent Orca Fpga.nws
M1G)O;3H@(F%S;&EC(B \87-L:6- ='!T<S$N<V5E9"YN970N='<^#0I3=6)J
M96-T.B!,=6-E;G0@3W)C82!&<&=A#0I.97=S9W)O=7!S.B!C;VUP+F%R8V@N
M9G!G80T*4F5F97)E;F-E<SH@/#,T,34V03$T+C$V-T5",$4W0&5V<W@N8V]M
M/B \031!.#%$.#%"138T1# Q,4%#-#<P,#(P048T-C<W,#4Q,S-"-4- <V-R
M87 M<V5R=F5R/@T*365S<V%G92U)1#H@/# Q8F-C,S$X)#DR-V1F,34P)#8Y
M8S1A9CAB0&QE861E<CX-"E@M3F5W<W)E861E<CH@36EC<F]S;V9T($EN=&5R
M;F5T($YE=W,@-"XW,"XQ,34U#0H-"@T*2&]W('1O(&=E="!6:65W<VEM(&]F
M(&1E;&%Y(&9I;&4@9F]R($]R8V$@0V5L; T*;&EK92!V:65W<VEM+G9A<B!F
.;W(@<&]S='-I;0T*#0IR
`
end
Article: 7491Koenraad Schelfhout VH14 8993 wrote: > > Hallo, > > At the moment I am working on a prototype of an upgrade of a component > for which one of the major requirements is compatibility with its > predecessor (a full custom device with very old technology). > > The prototype will consist out of 6 FPGAs, so a test board is being > developed also (prototype must run at speed (8MHz)). > > Now I am facing with the following problem : > - I have a VHDL netlist which describes logically how the 6 FPGA's > are interconnected (and also what is inside each FPGA). > But for the board design I need to map these logical connections > towards physical pin numbers. > > I would like to know if anybody of you knows a good way to bring the > "logical" information towards the "physical" pinnumbers. > > If I look to a normal flow it is : > - first define interconnection (logically) > - assign physical pin number (to the logical pins) > - draw a schematic > - generate netlist for PCB (printed circuit board) > - place&route PCB. > > Now the physical pin assignment depends on : > - placement of components on the board, > - optimal/good routability > - optimal/good pin assignment for internal routing of the FPGA We have done this with Multiple PLDs, with good results You attack from both ends thus : Partition the design, and confirm that it FITS into X devices. A very rough 'felt pen' BUS flow block diagram helps select to appx 'package side' detail level. Do the PCB design - for this, we did not create a Schemtic, but used the PLD design NETLIST ( some manual generation here ). This was then Routed and PIN SWAPPED, to flip BUS orders, swap BUS sequences etc, to gice a very tight, well decoupled layout. Then, this new pinout was re-applied to the HDL, and re-compiled ( to ensure it still fitted ) We have written some SW, that takes a PCB netlist, and produces a HDL Pin assign header, to speed this stage. Mostly, things like swapping the order of BITS in a BUS, and some simple re-sequencing can make a big gain to routing the PCB, and hopefully have little impact on the FPGA route. -- ======= Manufacturers of Serious Design Tools for uC and PLD ========= = Optimising Modula-2 Structured Text compilers for ALL 80X51 variants = Reusable object modules, for i2c, SPI and SPL bus interfaces = Safe, Readable & Fast code - Step up from Assembler and C = Emulators / Programmers for ATMEL 89C1051, 2051, 89C51 89S8252 89C55 = *NEW* Bondout ICE for 89C51/89C52/89C55 = for more info, Email : DesignTools@xtra.co.nz Subject : c51ToolsArticle: 7492
Thanks for your answer,
1) size : it will be six XC4044XL devices (with some of them having
up to 200 used pins towards the other ones)
2) the main problem is that board design should start now, and that
for most of the modules, there is not yet a synthesizable version
available, so "good" pin assignment is not yet possible
--
Koenraad SCHELFHOUT
Switching Systems Division http://www.alcatel.com/
Microelectronics Departement - VH14 _______________
________________________________________\ /-___
\ / /
Phone : (32/3) 240 88 93 \ ALCATEL / /
Fax : (32/3) 240 99 47 \ / /
mailto:ksch@sh.bel.alcatel.be \ / /
_____________________________________________\ / /______
\ / /
Francis Wellesplein, 1 v\/
B-2018 Antwerpen
Belgium
Article: 7493I know this subject has been covered here before, but I am still not sure of one detail. Can a 3.3v xilinx chip (4000XL or 5200XL -series) safely drive 5v CMOS parts? The Oct '96 data book on page 6-2 suggests that "an external pull-up resistor to 5v on each such input will assure a sufficiently high input voltage" (i.e. > 3.5v). (However, it then warns that your 3.3v supply could be compromised by all the currents flowing back through the ESD protection on the 3.3v drivers.) I have contacted our local Xilinx support, and they sent me an email suggesting that we use TRISTATE outputs (drive low, hi-z for high). Are they implicitly suggesting that there is a problem with a simple pull-up? Has anyone actually tried this for real? Do you get a good enough drive for CMOS (with some noise margin)? Nick ============================================================================ Nick Gent Communications Measurements Division Email: nickg@sqf.hp.com Hewlett-Packard Telephone: +44 131 331 7644 South Queensferry EH30 9TG Fax: +44 131 331 7488 Scotland ============================================================================Article: 7494
I think comp.arch.fpga readers ought to see this from comp.arch.embedded: David Collier warns users of AMD PALs: > >PAL design change alert > >We are spitting mad. We have just found out that an AMD PAL we have been >using has been "improved", so that our designs no longer work with it. > >Basically, they have added a "pull-up/down detector" to the IO pins. This >observes the I/O pins during power-on, and then engages a weak pull-up or >pull-down to hold the pin in the state seen. The consequence of this is >that the guaranteed leakage figures have gone from +/-10uA to +/-100uA. >We have a circuit which drives a Maxim watchdog/reset device from a PAL >output. The input is three-mode - high, low and floating, and floating >disables the watchdog. Of course the new PALs make an arbitrary choice at >power-on, and pull their outputs high or low. So we get an immediate >watchdog time-out. Wonderful. > >It's called "bus-friendly" I/O, and there are details on the web at > > http://www.vantis.com > >apparently. > >Anyway I thought I'd post this here to alert others. The new circuit is >gradually being added to all AMD devices, so if your design is vulnerable, >you could be hit at any time. > >As far as we can see, Lattice GALs still work the old way. Once again, an upgrade/"improvement" has made things worse for some users. The main reference I found on the Vantis web site was application note "Evolution of Bus-Friendly Inputs and I/Os 19671" in the MACH section of the literature page (not in PAL section): http://www.vantis.com/literature/literature.html When I downloaded this document (9 pages of .pdf) I found it dated 1994, so this change has been going on for quite some time, and it's surprising that David Collier has only just come up against it. According to the Vantis FAQ on http://www.vantis.com/support/faqpage4.html bus-friendly parts will be so described in "Distinctive Characteristics" at the top of the data sheet. It says the only current PALs with this feature are: "New revs of PAL20V8" and "New revs of PALCE22V10 (H & I)" - so apppears all 16V8 doesn't yet have this. The "equivalent schematic" of for a PAL I/O shows a 100k pullup/down (although the change in current quoted by David Collier implies 50k rather than 100) being driven by a pin-sensing circuit and enabled by Vcc - so it is operative all the time, not just on power-up. The "fix" is therefore to add 180k (or lower) resistors to Vcc and Gnd, meaning that an IC change to get rid of resistors has actually increased the number needed. Mind you, I'd have been tempted to have two such resistors in the original design, if only to give a small amount of noise immunity - but then that is said with the benefit of 20/20 hindsight. Just goes to show, "pin, fuse and architecture equivalence" may not always mean genuinely drop-in replacement equivalence - and I'm sure almost everyone has examples of that. Tim Forcer tmf@ecs.soton.ac.uk Department of Electronics & Computer Science The University of Southampton, UK The University is not responsible for my opinionsArticle: 7495
Nick Gent wrote: > Can a 3.3v xilinx chip (4000XL or 5200XL -series) safely drive 5v CMOS > parts? The following paragraph from the new Xilinx App note XAPP080 (Supply-Voltage Migration 5 V to 3.3 V ) which is based on my article in ED of August 18, 97, page 70, says it more correctly: ."..Any active High 3.3-V output cannot be pulled higher, since the internal pull-up transistor represents a ~50 Ohm impedance for current in either direction. A pull-up resistor to 5 V is therefore meaningless. If the internal pull-up transistor is disabled (“open drain output”) the pin can be pulled higher, until the ESD clamp becomes conductive. The outputs on XC4000XL devices can thus be configured as open drain, and an external resistor can pull them all the way to 5 V, albeit with an RC speed penalty." Our European FAEs have come up with an improvement that maintains the fast rise time by keeping the pull-up transistor active during the first 3 V of the rising transition: Take the input signal inside the 3.3 V device coming from the pin that has to drive a 5-V device, and AND it internally with the data signal that drives the pin. Then use the output of this AND gate to 3-state the output driver. Or, if you prefer, use the output of the NAND gate to drive the Output Enable, same thing. Now the output transistor will be disabled only after it has done its job of pulling the output High, and the external pull-up resistor only has to pull the rest of the way, essentially only providing noise immunity. Clever idea, and almost for free. Peter Alfke, Xilinx ApplicationsArticle: 7496
And this is being done without any change to the device part number? Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiXYZserve.com but remove the XYZ.Article: 7497
Alfred Fuchs <alfred.fuchs@siemens.at> wrote: > We are redesigning a board with telecommunication stuff, that > contains a 6809 processor. The processor is being discontinued > and we are looking for a way to avoid major SW-rework. > Has anyone put this processor into an FPGA? Why not emulate the 6809 instead? You may even be able to find an emulator, possibly a PD emulator. Ask around on Amiga newsgroups. Good luck -- SteveArticle: 7498
Sounds like you were in the same situation we were. We defined the handful of nets we were _sure_ would be used, added some more nets for safety (room to expand) and then divided the rest and split them between the FPGAs. So, if we had say 70 extra pins on each FPGA, we would do the following for each FPGA: 10 nets routed to each of the other FPGAs (total of 50 nets). 10 nets routed to a backbone bus that went to all FPGAs. 10 nets routed to interface with logic / circuits that were external to the FPGA "pool of logic" (A/Ds, LEDs, etc.) Since you have the big FPGA with 200+ pins, I suggest you route almost all of them in the above fasion (perhaps leaving some to route to vias for later white-wiring.) But my point is you run out of line VERY quickly and it can be difficult to predict all the interconnections needed. I also suggest the dogbones. Unfortunately, this will increase the size of the board (especially the dogboning), so if your board is to deliver to customers, maybe this is not the way to go. Also, it is probably stupidly obvious, but because we hooked up so many nets with no clear purpose or name, we had to develop a naming convention. When we finally assigned these generic nets to specifc net names, it helped to keep track of them on a small chart next to the schematic. Again, obvious, but helpful. Good Luck, John -- John ArchambeaultArticle: 7499
Peter Alfke covered this recently in XAPP 080 V1.1 (available from xilinx.com) The problem with pulling up a normal 3.3V output to 5V is that the upper transistor is a low impedance to 3.3V in both directions when turned on. Hence the recommendation to use a tristate output in "open-drain" mode with an external pullup resistor, at the expense of the RC delay penalty. regards, tom Nick Gent wrote: (slightly edited) > > Can a 3.3v xilinx chip (4000XL or 5200XL -series) safely drive 5v CMOS parts? > > The Oct '96 data book on page 6-2 suggests that "an external pull-up resistor > to 5v on each such input will assure a sufficiently high input voltage" (i.e. > > 3.5v). (However, it then warns that your 3.3v supply could be compromised by > all the currents flowing back through the ESD protection on the 3.3v drivers.) > > I have contacted our local Xilinx support, and they sent me an email suggesting > that we use TRISTATE outputs (drive low, hi-z for high). Are they implicitly > suggesting that there is a problem with a simple pull-up? > > Nick
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