Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 7475

Article: 7475
Subject: Re: HELP: FIFO's on an FPGA
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 15 Sep 1997 17:27:23 +0000
Links: << >>  << T >>  << A >>



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 Applications


Article: 7476
Subject: Re: HELP: FIFO's on an FPGA
From: Sam Falaki <Falaki@uqtr.uquebec.ca>
Date: Mon, 15 Sep 1997 18:01:51 GMT
Links: << >>  << T >>  << A >>

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: 7477
Subject: Mentor, __qp_prim, and Xilinx symbol libraries
From: Steve Gross <gross@pa.msu.edu>
Date: Mon, 15 Sep 1997 14:24:58 -0400
Links: << >>  << T >>  << A >>

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: 7478
Subject: Re: HELP: FIFO's on an FPGA
From: "Rich K." <rich.katz-nospam@gsfc.nasa.gov>
Date: 15 Sep 1997 20:16:57 GMT
Links: << >>  << T >>  << A >>

hi 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
Subject: Re: pellerin@seanet.com
From: David Pellerin <pellerin@seanet.com>
Date: Mon, 15 Sep 1997 14:54:05 -0700
Links: << >>  << T >>  << A >>

> 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-2686




Article: 7480
Subject: FPGA'98: Papers due on 9/26
From: hauck@ece.nwu.edu (Scott A. Hauck)
Date: Mon, 15 Sep 1997 17:11:21 -0500
Links: << >>  << T >>  << A >>

                                 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
Subject: Choosing a good pin assignment for multiple-xilinx prototype.
From: Koenraad Schelfhout VH14 8993 <ksch@sh.bel.alcatel.be>
Date: Tue, 16 Sep 1997 09:00:48 +0200
Links: << >>  << T >>  << A >>



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: 7482
Subject: Clock Pulse Width for IFFs
From: david.storrar@gecm.REMOVEMETOREPLY.com (David Storrar)
Date: 16 Sep 1997 10:09:23 GMT
Links: << >>  << T >>  << A >>

Hi,


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
Subject: Re: Programmable Logic News Site Update
From: Murray <mdisman@ix.netcom.com>
Date: 16 Sep 1997 15:34:48 GMT
Links: << >>  << T >>  << A >>
Please note that the correct URL is

http://www.plnv.com

Sorry 

Murray Disman

Article: 7484
Subject: 6809 discontinued
From: Eric Ryherd <"vauto@tiac.net"@tiac.net>
Date: Tue, 16 Sep 1997 12:07:02 -0400
Links: << >>  << T >>  << A >>

>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-1587
Article: 7485
Subject: SPECIALS SUN & SGI
From: Brandon Unger <brandon@recurrent.com>
Date: Tue, 16 Sep 1997 13:41:14 -0700
Links: << >>  << T >>  << A >>

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.com
Article: 7486
Subject: Re: Choosing a good pin assignment for multiple-xilinx prototype.
From: johna@dvorak.amd.com (John Archambeault)
Date: 16 Sep 1997 22:33:11 GMT
Links: << >>  << T >>  << A >>



	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 Archambeault
Article: 7487
Subject: Re: how generate xilinx 3020 EPROM?
From: johna@dvorak.amd.com (John Archambeault)
Date: 16 Sep 1997 22:38:57 GMT
Links: << >>  << T >>  << A >>

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!usenet

Article: 7488
Subject: 2nd CALL FOR PAPERS-Application of Concurrency to System Design (CSD'98)
From: Alexander Taubin <ttaubin@u-aizu.ac.jp>
Date: 16 Sep 1997 18:42:42 -0700
Links: << >>  << T >>  << A >>





++++++++++++++++++++++++++++++++++++++++++++++++++
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.jp
Article: 7489
Subject: Lucent Orca Fpga
From: "aslic" <aslic@tpts1.seed.net.tw>
Date: 17 Sep 1997 03:20:32 GMT
Links: << >>  << T >>  << A >>





How to get Viewsim of delay file for Orca Cell
like viewsim.var for postsim




Article: 7490
Subject: Viewsim.var help
From: "aslic" <aslic@tpts1.seed.net.tw>
Date: 17 Sep 1997 03:22:06 GMT
Links: << >>  << T >>  << A >>



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: 7491
Subject: Re: Choosing a good pin assignment for multiple-xilinx prototype.
From: jim granville <Jim.Granville@xtra.co.nz>
Date: Tue, 16 Sep 1997 21:45:17 -0700
Links: << >>  << T >>  << A >>

Koenraad 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 : c51Tools


Article: 7492
Subject: Re: Choosing a good pin assignment for multiple-xilinx prototype.
From: Koenraad Schelfhout VH14 8993 <ksch@sh.bel.alcatel.be>
Date: Wed, 17 Sep 1997 08:53:15 +0200
Links: << >>  << T >>  << A >>



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: 7493
Subject: Can 3.3v Xilinx drive CMOS?
From: nickg@hpqt0220.sqf.hp.com (Nick Gent)
Date: 17 Sep 1997 07:12:53 GMT
Links: << >>  << T >>  << A >>

I 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
Subject: Re: AMD PAL design change
From: Tim Forcer <tmf@ecs.soton.ac.uk.nojunk>
Date: Wed, 17 Sep 1997 14:08:41 +0100
Links: << >>  << T >>  << A >>



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 opinions
Article: 7495
Subject: Re: Can 3.3v Xilinx drive CMOS?
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 17 Sep 1997 16:05:17 +0000
Links: << >>  << T >>  << A >>
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 Applications
 

Article: 7496
Subject: Re: AMD PAL design change
From: z80@ds.com (Peter)
Date: Wed, 17 Sep 1997 18:49:28 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: 6809 in FPGA?
From: spp@bob.eecs.berkeley.edu
Date: 17 Sep 1997 19:38:00 GMT
Links: << >>  << T >>  << A >>
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 --

Steve
Article: 7498
Subject: Re: Choosing a good pin assignment for multiple-xilinx prototype.
From: johna@dvorak.amd.com (John Archambeault)
Date: 17 Sep 1997 19:39:56 GMT
Links: << >>  << T >>  << A >>

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 Archambeault
Article: 7499
Subject: Re: Can 3.3v Xilinx drive CMOS?
From: Tom Burgess <tburgess@drao.nrc.ca>
Date: Wed, 17 Sep 1997 14:23:45 -0700
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search