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
VHDL International Users' Forum (VIUF) Fall 1995 Conference and Exhibition Preliminary CALL FOR PAPERS, PANELS, WORKSHOPS AND TUTORIALS Newton Marriott Hotel, Boston, MA October 1-4, 1995 VHDL In Use: Tales from the World of System Design and Programmable Logic The Fall 1995 VIUF Conference continues the tradition of the past 15 semi- annual VHDL users meetings by providing a forum for collecting, discussing, and disseminating technology on the use of VHDL. This time, the focus will be on experience accounts of VHDL users in the System Design arena in general and Programmable Logic in particular. Proactive participation is expected from a broad range of disciplines including design, prototyping, test, methodology, logistics, manufacturing, and more. Tool developers, designers, foundry people, as well as system designers, are encouraged to participate in one or more of the various parts of the program. The aim of this meeting is to exchange ideas and gather information needed to successfully exploit todays' increasing complexity of large systems implemented in deep sub-micron technologies. The event will be comprised of technical paper presentations, panel sessions, mini-workshops, tutorials, a keynote general session, vendor sessions, focus birds-of-a-feather meetings, and product exhibits. A VHDL design contest will be held as well (see separate Call for Participation to obtain more information). TECHNICAL PROGRAM The technical program will consist of technical paper sessions. Papers will be distributed in a bound proceedings book at the meeting. Potential authors are encouraged to participate by submitting an extended abstract to the Technical Program Chair for consideration. Topic areas of particular interest include (but not limited to): - System & FPGA design with VHDL - VHDL style and coding guidelines - Modeling, Simulation & Synthesis - Formal methods and verification - Standards and Interoperability - Education - Foundry use of VHDL - Testing issues in VHDL Extended abstracts for technical papers are invited for consideration. Descriptions of technical development, research, user experience, and other VHDL related discussions are requested. Submissions should include the key ideas, major technical contributions, advantages, limitations, results, and directions for future work, as appropriate to the subject matter. Each abstract will be reviewed by the program committee which includes internationally distinguished VHDL experts. Authors whose abstracts are accepted will be required to submit a completed full length paper in advance for review of content and format. Submit your abstract by May 15, 1995 to the Technical Program Chair at the address below. Electronic submissions of material in RTF, Postscript, or 7- bit ASCII are strongly encouraged. Please accompany any RTF or Postscript submission with a 7-bit ASCII version. PANELS AND MINI-WORKSHOPS Special attention is given to attendee participation. The objective is to foster proactive involvement and experience sharing. Two types of participatory sessions will be offered: 1. Panels - A group of industry experts will prepare brief position statements followed by Q&A among panelists and audience. 2. Mini-Workshops - A moderator will direct an interactive discussion among all participants, using guidelines that will be distributed in advance of the session. Each panel and mini-workshop will focus on a well defined issue or challenge related to the inherent characteristics of VHDL, its related applications, or any other suitable topic of interest to VHDL practitioners in industry and in academia. Abstracts for panels or mini-workshops are invited for consideration. Authors whose proposals are accepted will be required to submit a complete session plan/outline and list of participants in advance for review of content and format. Submit your panel or mini-workshop proposal by May 22, 1995 to the Panels & Workshops Chair at the address below. Electronic submissions of material in RTF, Postscript, or 7-bit ASCII are strongly encouraged. Please accompany any RTF or Postscript submission with a 7-bit ASCII version. TUTORIALS The tutorial program provides in-depth presentations specifically designed for VHDL beginners and for advanced or expert VHDL practitioners. Several tutorials will be offered on a parallel track basis. Proposals for full or half day introductory, advanced and expert level tutorials on any VHDL- related topic are encouraged. Abstracts for tutorials are invited for consideration. Authors whose proposals are accepted will be required to submit a completed tutorial presentation in advance for review of content and format. Submit your tutorial abstract by May 22, 1995 to the Tutorial Chair at the address below. Electronic submissions of material in RTF, Postscript, or 7- bit ASCII are strongly encouraged. Please accompany any RTF or Postscript submission with a 7-bit ASCII version. RESPONSE DATES Abstract Submission Deadline 15 May, 1995 Panel & Workshop Proposal Deadline 22 May, 1995 Tutorials Submission Deadline 22 May, 1995 Notification of Acceptance 12 June, 1995 Final Submissions Deadline 24 July, 1995 Presentations 1-4 October, 1995 FOR SUBMISSIONS AND MORE DETAILS ADDRESS... Technical Program Chair Panels & Workshops Chair Tutorials Chair J. Bhasker Yvonne Ryan Pam Rissmann AT&T Bell Laboratories Ryan & Ryan Proxy Modeling 1247 S. Cedar Crest Blvd. 953 Mt. Carmel Drive 1580 Washington Blvd. Allentown, PA 18103 San Jose, CA 95120 Fremont, CA 94539 USA USA USA +1 610-712-3983 +1 408-997-6028 +1 510-440-8435 +1 610-712-2773 (FAX) +1 408-997-7481 (FAX) +1 510-440-8852 (FAX) email jb7@mhcnet.att.com email yryan@vhdl.org email pamr@vhdl.org FOR GENERAL INFORMATION... Conference Chair Program Coordination Chair Conference Management Hillel Ofek Steve Carlson CMS Dyna Logic Corp. Escalade Corporation 407 Chester Street 1255 Oakmead Pkwy 1210 E. Arques Avenue Menlo Park, CA 94025 Sunnyvale, CA 94086 Sunnyvale, CA 94086 USA USA USA +1-415-329-0510 +1 408-481-3120 +1-408-481-1305 +1-415-324-3150 (FAX) +1 408-481-3136 (FAX) +1-408-481-1313 (FAX) email hillelo@vhdl.org email steve@escalade.com email jillj@vhdl.orgArticle: 1151
In article <1995May2.182307@fpga.ee.byu.edu>, wirthlim@fpga.ee.byu.edu (Michael J. Wirthlin) writes: |> You need to be careful when testing your algorithm, however, because |> a faulty bitstream compression/decompression scheme can easily burn or destroy |> your FPGA. I would recommend extensive testing on your |> compression/decompression *off-line* before attempting it on the FPGA. I suggest a CRC on the bit stream before it gets compressed. A CRC is a good idea even without compression. File systems occasionally make errors.Article: 1152
murray@src.dec.com (Hal Murray) writes: >In article <1995May2.182307@fpga.ee.byu.edu>, wirthlim@fpga.ee.byu.edu (Michael J. Wirthlin) writes: >|> You need to be careful when testing your algorithm, however, because >|> a faulty bitstream compression/decompression scheme can easily burn or destroy >|> your FPGA. I would recommend extensive testing on your Absolutely. I would go further, and *in every case*, after compressing your bitstream, run it through the expander and verify it against the original, before letting it near your fpga hardware. >|> compression/decompression *off-line* before attempting it on the FPGA. >I suggest a CRC on the bit stream before it gets compressed. >A CRC is a good idea even without compression. File systems occasionally >make errors. -- David R. Brooks <daveb@perth.DIALix.oz.au> Tel/fax. +61 9 434 4280 "Government is not reason. It is not eloquence. It is a force. Like fire, a dangerous servant and a fearful master." - G. WashingtonArticle: 1153
msnook@armltd.co.uk (Mark Snook) wrote: > > > What I would like to see is a program that scans a number of *.rpt > files looking for the pin placement section in order to find > trends. The output could be a table with pin number and number of > occurances of each signal on that pin. It would then help if the > format was suitable for generating the constraints file without too > much editing. I wrote a simple script using grep that collated the > information, but then sorted it out manually. > > I'm sure there's an awk or perl hack out there who could do this in a > matter of minutes. A section of the report file looks like this: > Which version of XACT you are using ? rpt file has CST file style information in the current version. It's pretty cool in the sense that you can just cut and paste from rpt to .cst file for locking IO. In addition the report file has a lot of new interesting information. -bond.Article: 1154
Hi Gideon! If it's lsil info that you want , try the following: lsil.apps.tech. Also, If you're interseted in 500K technology (0.5u 3.3V), send email to: majordomo@bgs1.lsil.com with subscribe fug in the body of the message. have fun! yaron --- ************************************************************************ * Yaron Kretchmer LSI Logic ISRAEL ------ * * Phone +972-3-5403741 Sokolov 40 LSI | LOGIC| * * Fax +972-3-5403747 Ramat Hasharon | | * * Israel 47100 | | * * P.O.Box 1331 -------- * * email yaron@lsi-logic.co.uk or (outside LSI) * * * * * * * * disclaimer: these views are mine, only mine * ************************************************************************Article: 1155
randraka@ids.net wrote: : In Article <D7pHAy.4u1@bbc.co.uk> : matthew@rd.bbc.co.uk (Matthew Marks) writes: : >If you use a Xilinx chip (and no doubt many other types as well) you can : >store the look-up tables in the same ROM as the configuration, so no extra : >chips needed. Yes. But if it is any equation that can convert this forth and back, it should be better. : If you can afford the larger accumulator, add the signals first then scale the : result (a simple way of doing this is to just take the 14 msbs of the : result). Your quantizing noise will be lower by adding first. : : A better soultion than simply taking the 14 msbs is to set up a pseudo AGC to : track the average magnitude of the result over a fixed time period and use : that result to select which 14 bits to take from the accumulator. The : selector can include logic to realize saturating arithmetic so that the : signal clips if it exceeds the range of the 14 selected bits rather : than getting the 2's comp wrap around. I've used the AGC and : saturating arithmetic method for some radar signal processing work. : The hardware is fairly simple and can be made very fast. The AGC value : could also be determined as a function of the number of participants in : the conference. Could you explain this AGC circuit for me in detail? Best Regards, Wichai TangArticle: 1156
David Evans (david.evans.cnv666@nt.com) wrote: : One little hint...Don't just add all the talkers together and then divide-- : It will sound bad. Add only the two loudest. I'll leave the details as : an exercise for the student. How can I do with the overflow signals ? Best Regards, Wichai TangArticle: 1157
I have the task of determining which FPGA vendor's tools that the company should invest in. My background in this area is limited, so I would appreciate some basic help. Some examples of the sort of functionality that we would like to place into an FPGA are as follows: 1. 18 bit counter running at 60MHz; 18 bit comparator also running at 60MHz; 1k x 20 bit FIFO at roughly 1MHz; 18 bit adder running also at roughly 1MHz; state machine of approx 10 states running at 60MHz. 2. As above, but without the FIFO and with 32 bits instead of 18. 3. State machine of 20 states running at 60MHz; 1k x 10 bit FIFO at 20MHz; 8 bit counter at 20MHz; several asynchronous latches. 4. One 32 bit adder, two 16 bit adders, four 16 bit multipliers and 4k ROM all running at 30MHz. Are these sorts of designs feasible? Am I being overly optimistic in any of these examples? Can anyone offer advice as to which FPGA family might achieve this, particularly in light of the fairly high data rates? Any help appreciated. -- Jon Schutz Senior Systems Engineer MRad Pty Ltd Ph: 61-8-2608942 Innovation House West Fax: 61-8-2608980 Technology Pk E-mail: jon@mrad.com.au South Australia 5095Article: 1158
TOWARDS EVOLVABLE HARDWARE:
AN INTERNATIONAL WORKSHOP
October 2-3, 1995
Swiss Federal Institute of Technology, Lausanne (EPFL)
Logic Systems Laboratory (LSL)
Lausanne, Switzerland
Speakers
========
Hugo de Garis
ATR Lab, Brain Builder Group, Kyoto
Dario Floreano
University of Stirling
Frederic Gruau
Stanford University
Inman Harvey
COGS, University of Sussex
Tetsuya Higuchi
Electrotechnical Laboratory, MITI
Daniel Mange
Swiss Federal Institute of Technology, Lausanne
Pierre Marchal
Centre Suisse d'Electronique et de Microtechnique
Francesco Mondada
Swiss Federal Institute of Technology, Lausanne
Adrian Thompson
COGS, University of Sussex
Purpose
=======
In the last few years the idea of producing hardware in a biological-like
manner, that is by using concepts derived from natural evolution in place of
traditional design methods, has received an increasing amount of attention.
There are few advanced groups in the world doing promising research in the
field and, to date, contributions have been appearing in a scattered way at
evolutionary algorithms and artificial life conferences. We believe that time
is ripe to determine the current state of the art in evolvable hardware
research through a dedicated forum. This will facilitate communication of
current research in the field and foster collaboration between active groups.
Program Schedule
================
Monday, October 2, 1995
08:15 A.M. - 09:00 A.M. Seminar Registration
09:00 A.M. - 09:15 A.M. Welcome
09:15 A.M. - 10:30 A.M. Embryonics: the birth of synthetic life
P. Marchal
10:30 A.M. - 10:45 A.M. Pause
10:45 A.M. - 12:00 Noon Embryonics: development of a new family of
coarse-grained FPGA with the properties of self-
repair and self-reproduction
D. Mange
12:00 Noon - 02:00 P.M. Lunch
02:00 P.M. - 03:15 P.M. Unconstrained evolution and hard consequences
I. Harvey, A. Thompson
03:15 P.M. - 03:30 P.M. Pause
03:30 P.M. - 04:45 P.M. Artificial morphogenesis in optimization and
compilation
F. Gruau
04:45 A.M. - 06:00 P.M. Posters - Demos
Tuesday, October 3, 1995
09:15 A.M. - 10:30 A.M. CAM-BRAIN: the evolutionary engineering of a
billion neuron artificial brain by 2001 which
grows/evolves at electronic speeds inside cellular
automata machines
H. de Garis
10:30 A.M. - 10:45 A.M. Pause
10:45 A.M. - 12:00 Noon Evolvable hardware with genetic learning
T. Higuchi
12:00 Noon - 02:00 P.M. Lunch
02:00 P.M. - 03:15 P.M. Evolution and autonomous mobile robotics
F. Mondada, D. Floreano
03:15 P.M. - 03:30 P.M. Pause
03:30 P.M. - 04:30 P.M. General discussion
Contents
========
CAM-BRAIN : The evolutionary engineering of a billion neuron artificial brain
by 2001 which grows/evolves at electronic speeds inside cellular automata
machines.
Hugo de Garis
The states of cellular automata (CA) cells can be stored cheaply in RAM, so
too the CA state transition rules. By using state-of-the-art CA machines
(e.g. MIT's CAM8 machine, which can update 200 million CA cells per second),
it becomes possible to grow/evolve neural networks based on cellular automata.
Since giga-bytes of RAM are not too expensive, and the development of
"superCAMs" (i.e. Cellular Automata Machines) which are thousands of times
faster than CAM8 are achievable within a few years, it becomes realistic to
develop artificial brains with a billion artificial neurons by 2001. This is
the aim of the CAM-Brain Project at ATR Labs in Kyoto, Japan. Three
dimensional CA based neural circuits are grown and evolved to perform desired
functions, even though how they perform their function is not understood. By
evolving thousands of such circuits and their interconnections, a new field
and probably a new industry called "brain building" may be born.
Artificial morphogenesis in optimization and compilation
Frédéric Gruau
In order to create systems made by many cells working in parallel, nature
uses a developmental process. The development starts with a single cell which
divides and divides again, generating a coherent parallel distributed system.
We show how this simple idea of cell division can be exploited using
computers, either for doing optimization or for compilation. In both case,
the object being generated is a parallel distributed system.
Unconstrained evolution and hard consequences
Inman Harvey and Adrian Thompson
Artificial evolution as a design methodology frees many of the conventional
constraints normally imposed to make design by humans tractable. When
evolving for hardware, we can relax such constraints as strict
synchronization to a global clock, enforced decomposition into modules with
simple interactions, and the use of high level abstractions such as Boolean
logic, to name a few. However this freedom comes at some cost; there are a
whole new set of issues relating to evolution that must be considered.
Evolution is largely the dynamics of adaptation to a changed environment,
which lends itself in artificial evolution to incremental increase in task
complexity. Standard Genetic Algorithms are often not appropriate for this,
and need to be specially tailored.
The main cost of an evolutionary approach is the large number of trials that
are required. Attempted shortcuts through simulations raises further issues,
and often robustness in the presence of noise or hardware faults is a crucial
factor. To illustrate this a physical piece of hardware evolved in the
real-world will be presented. A simple asynchronous digital circuit directly
takes echo-pulses from a pair of left/right sonars, and drives the two motors
of a real robot, so that it exhibits a wall-avoidance behavior. The complete
sensorimotor control system (no pre- or post-processing) consists of just 32
bits of RAM and a few flip-flops, and is tolerant to single-stuck-at faults
in the RAM. The rationale behind this experiment applies to many other kinds
of system, including Field-Programmable Gate Arrays (FPGA's).
Evolvable hardware with genetic learning
Tetsuya Higuchi
This paper describes Evolvable Hardware (EHW) and its applications to pattern
recognition and fault-tolerant systems. EHW can change its own hardware
structure to adapt best to the environment whenever environmental changes
(including hardware malfunction) occur. EHW is implemented on PLD
(Programmable Logic Device)-like device whose architecture can be altered by
programming the architecture bits. Through genetic algorithms, EHW finds the
best architecture bits which adapt to the environment, and changes its
hardware structure accordingly.
Two applications are described: the exclusive-OR problem for pattern
recognition and the V-shape ditch tracer with fault-tolerant circuit.
First we show the exclusive-OR circuit can be learned by EHW successfully.
This suggests that EHW may work as a hard-wired pattern recognizer with
robust performance like neural net. The result is compared with neural net,
classifier system, and adaptive logic network. The second application is the
V-shape ditch tracer as part of a prototypical welding robot. EHW serves as
backup of the control logic circuit for the tracing, although the EHW is not
given any information about the circuit. Once a hardware error occurs, EHW
takes over the malfunctioning circuit. The EHW architecture implemented on
gate arrays is also described.
Embryonics: development of a new family of coarse-grained FPGA endowed with
the properties of self-repair and self-reproduction
Daniel Mange
Embryonics (embryological electronics) is a research project aimed at the
realization of a new kind of electronic components which borrow three
fundamental characteristics from living organisms: multicellular
organization, cellular differentiation, and cellular division. These
components will thus be endowed with properties heretofore restricted to
living organisms: self-reproduction and self-repair.
Within this framework, we will present a new family of coarse-grained
Field-Programmable Gate Arrays. Each cell is a binary decision machine whose
microprogram represents the genome, and each part of the microprogram is a
gene whose execution depends on the physical position of the cell in the
network, i.e., on its coordinates.
We will show a prototype of such a cell and use it to realize a cellular
digital clock, capable of repairing and reproducing itself.
Embryonics: the birth of synthetic life
Pierre Marchal
The field of Artificial Life is divided into three research axis. The first
axis - Virtual Life - investigates simulation worlds (ants, worms, and so
on...). The second axis - Alternative Life - addresses wetware developments
of non-carbon-chain life. The third axis - Synthetic Life - synthesizes
developmental and evolutionary concepts and applies them to engineering
science.
Recent advances in the field of biology (evolutionary theory and
developmental biology together with their engineering counterparts, genomic
architectures and programmable devices) enable the birth of synthetic life.
The Embryonics project is our humble contribution to this field of increasing
interest. The project will be described as it developed since 1992. Both
developmental and evolutionary VLSI will be described. Life-like properties
as self-repair and self-configuration will be demonstrated and exemplified.
Finally, open avenues and future developments will be presented and discussed.
Evolution and autonomous mobile robotics
Francesco Mondada and Dario Floreano
Autonomous mobile robotics is a very promising but complex field. Autonomous
vacuum cleaners, surveillance robots, automatic demining vehicles and many
other large scale applications are included under this designation. But
despite its name, this domain is very different from "classical robotics"
that we are used to see in big factories, and very few applications are in
use. The problem comes from the very large and robust autonomy that this kind
of mobile robots need and the incredible complexity of the environment in
which the robots act.
The robot that we are used to see in car factories has an autonomy restricted
to a repetitive task executed in a very simple and limited environment.
On the contrary, autonomous mobile robots very often face an unknown world
with a high degree of complexity (shapes, textures, colors...) and operate
in a very large working area. The interaction between the robot, its control
system and the environment in which the robot acts, play here a very important
role. This has been clearly demonstrated by some examples proposed, for
instance, by Franceschini, Dickmanns, Brooks.... However it is still difficult
to design a control structure that fits very well with the hardware of the
robot and to design a sensory-motor system that fits perfectly with the task
and the environment in which the robot moves. In fact the exact
characteristics of all these elements are often unclear or unknown.
The evolutionary approach can play an essential role at this level: the
coevolution of the control structure and the hardware in the real environment
under the control of a task supervisor provides a coherent solution. Waiting
for an evolvable robot body, some experiments already show that the evolution
of control algorithms in a conventional robot body generate a near-to-optimum
exploitation of all sensory-motor possibilities.
General Information
===================
Site
This seminar will be held at the Swiss Federal Institute of Technology,
Lausanne, Switzerland. A map will be sent to registered participants.
Accommodation
Participants must take care of their own hotel reservation. They may find
convenient to contact the Lausanne Tourist Office, Case postale 49, CH-1000
Lausanne 6 (Fax: +41 21 616 8647).
Lunches are included in the registration fees.
Fees
300.- Swiss Francs
Please send your Registration Fees to:
Banque Cantonale Vaudoise
Case Postale 2172
CH-1015 Lausanne, Switzerland
LSL Account No. 903.29.00
Before : September 1st, 1995.
Registration
Prospective participants should complete and return the enclosed registration
form. Deadline : September 1st, 1995.
Posters and demos
A poster/demo session is scheduled in the program: registered participants
are invited to present their research work.
Official Language
English is the official workshop language
Seminar Co-ordinators
Prof. Eduardo Sanchez Dr. Marco Tomassini
EPFL CSCS (Manno) and EPFL
Logic Systems Laboratory Logic Systems Laboratory
IN - Ecublens IN - Ecublens
1015 Lausanne, Switzerland 1015 Lausanne, Switzerland
Fax: (+41 21) 693 3705 Fax: (+41 21) 693 3705
Email: sanchez@di.epfl.ch Email: tomassini@di.epfl.ch
============================================================================
TOWARDS EVOLVABLE HARDWARE:
AN INTERNATIONAL WORKSHOP
Registration Form
Please fill in information and address this card to:
Marlyse Taric
EPFL - LSL
IN - Ecublens
1015 Lausanne
Switzerland
taric@di.epfl.ch
or fax it to (+41 21) 693 3705
Family name
First Name
Street address
Postal code, Town
State, Country
Telephone No.
Fax No.
Company
Position
Date
Signature
I will present: a poster a demo
Deadline for Registration: September 1st, 1995.
--
Eduardo Sanchez
Swiss Federal Institute of Technology
EPFL - LSL
IN - Ecublens
1015 Lausanne
Switzerland
Tel: (+41 21) 693 2672
Fax: (+41 21) 693 3705
sanchez@di.epfl.ch
Article: 1159Applicants are sought for engineering positions at Glenayre in Vancouver, BC. Senior Staff Engineer - experience in current RF and DSP products needed. Digital Hardware Engineer - experience with 3 & 5 volt logic families, FPGA or ASIC design. DSP Engineers - develop high speed RF modems and DSP products. For descriptions of the positions, a narrative about Glenayre, and a forms-based job application, point your web client to http://www.synernet.com/glenayre. ----------------------------------------- url: http://www.synernet.com/glenayre ------------------------------------------Article: 1160
The short float format was introduced by Nabeel Shirazi shirazi@pequod.ee.vt.edu, Al Walters and Peter Athanas at the IEEE symposium on FPGAs for Custom Computing Machines (FCCM '95). The name of the paper is "Quantitaive Analysis of Floating Point Arithmetic on FPGA Based Custom Computing Machines" It outlines 16 and 18 bit short floating point formats and gives some VHDL code that implements floating point multiplies and add/subtract routines. I think that FCCMs need to implement these functions as floating point is one of big stumbling blocks in this field. Steve CasselmanArticle: 1161
jon@zeppo.mrad.com.au (Jon Schutz) writes: >I have the task of determining which FPGA vendor's tools that the >company should invest in. My background in this area is limited, so I >would appreciate some basic help. I've used Xilinx 3000, 4000 and AT&T ORCA parts. These have some features that you're looking for. These parts are arrays of hundreds of small function blocks. A funtion block on the X4000 chip can be a 2-bit arithmetic unit, or a 16x2 or 32x1 RAM. It can also do any arbitrary function of 5-bits (i.e. ROM) and some other functions as big as 9-bits. The ORCA function unit is similar, except that it can do 4-bit arithmetic, 16x4 memory, and functions up to 11-bits. Function blocks can have registered and/or combinatorial outputs. The biggest problem with Xilinx and ORCA is the un-predictability of routing. Typically, routing delay is about 2 to 10ns per logic level or about 40% of the total delay in a well-optimized route. For the ORCA, a logic block has a 4ns propagation delay, a 2ns setup to clock (through function generator), a clock-to output of 3ns, and a 1.5ns carry propagate time. > 18 bit counter running at 60MHz; No problem. AT&T is better at wide arithmetic functions. It can do a 20-bit counter with ~14ns cycle time (4ns prop + 3ns carry + 2ns setup + 3ns ck-out + 2ns routing) Tricks with pre-scalers, etc. can bring the speed to over 100MHz. > 18 bit comparator also running at 60MHz; Same as above for arithmetic comparison. Allow extra time to route data to comparator. An identity comparator could be much faster and more routable if implemented in a 2-level pipeline. > 1k x 20 bit FIFO at roughly 1MHz; Difficult: Requires more than 320 logic blocks in ORCA and twice as many for Xilinx. Best to add external RAM, especially for such slow speeds. > 18 bit adder running also at roughly 1MHz; Piece of cake. > state machine of approx 10 states running at 60MHz. Easy if logic levels are kept to 1 or 2 levels. Probably requires hand placement. > As above, but without the FIFO and with 32 bits instead of 18. Pretty close, but tricks would have to be used- the counter's carry should be pipelined at the first logic level. The comparator should be pipelined. > State machine of 20 states running at 60MHz; Depends on the state machine. If you have to go to more than 1 logic level (11-bit functions), you're in trouble. > 1k x 10 bit FIFO at 20MHz; This would take about half of a $400 AT&T 2C12. Again, best to use external RAM. > 8 bit counter at 20MHz; several asynchronous latches. Jelly bean. > One 32 bit adder, two 16 bit adders Pretty easy. > four 16 bit multipliers Oops. Probably not possible at any reasonable speed. > 4k ROM all running at 30MHz. Nope. Not unless the ROM table can be reduced to a much smaller logic function of 12 variables. I've implemented a few high speed designs. You can pull postscript copies of three of them via anon-ftp at esesrv0.fnal.gov:/pub/xilinx BERT.ZIP 64 MHz Bit Error Rate Tester (uses Xilinx 3142 and external RAM) LEVEL.ZIP 50 MHz load leveling buffer manager (48 buffers) (uses ORCA 2C12 with external cache RAM) SWITCH.ZIP 25 MHz 4x4 routing switch. (uses ORCA 2C12 and implements 16 24-bit FIFOs on one chip)Article: 1162
Have a look at AT&T's ORCA, they have the very good Ex-Neocad Map, Place & Router with a number of different entry points to reduce evaluation costs. However they are pitching for the higher end of the market where users will often migrate to Workstation solutions with third party design entry tools. I only say this to warn you that if you're looking for $1000 solutions for low volumes of Silicon, AT&T will probably not want to scrabble about with some of the other FPGA vendors. (My personal opinion only.) The Silicon is excellent and would certainly allow you to generate the functions below, but so would many others, its usually a trade off between area, speed & pipeline depth. However in my biased opinion ORCA is about as good as you get for this type of FPGA. In article <JON.95May8134213@zeppo.mrad.com.au>, Jon Schutz (jon@zeppo.mrad.com.au) writes: > >I have the task of determining which FPGA vendor's tools that the >company should invest in. My background in this area is limited, so I >would appreciate some basic help. > >Some examples of the sort of functionality that we would like >to place into an FPGA are as follows: > > 1. 18 bit counter running at 60MHz; 18 bit comparator also > running at 60MHz; 1k x 20 bit FIFO at roughly 1MHz; 18 bit > adder running also at roughly 1MHz; state machine of approx > 10 states running at 60MHz. > > 2. As above, but without the FIFO and with 32 bits instead of > 18. > > 3. State machine of 20 states running at 60MHz; 1k x 10 bit > FIFO at 20MHz; 8 bit counter at 20MHz; several asynchronous > latches. > > 4. One 32 bit adder, two 16 bit adders, four 16 bit > multipliers and 4k ROM all running at 30MHz. > >Are these sorts of designs feasible? > >Am I being overly optimistic in any of these examples? > >Can anyone offer advice as to which FPGA family might achieve this, >particularly in light of the fairly high data rates? > >Any help appreciated. > > > >-- > >Jon Schutz Senior Systems Engineer > >MRad Pty Ltd Ph: 61-8-2608942 >Innovation House West Fax: 61-8-2608980 >Technology Pk E-mail: jon@mrad.com.au >South Australia 5095 > Regards, Ian Packer. Bytech Electronics Ltd.Article: 1163
jon@zeppo.mrad.com.au (Jon Schutz) wrote:
>I have the task of determining which FPGA vendor's tools that the
>company should invest in. My background in this area is limited, so I
>would appreciate some basic help.
>
>Some examples of the sort of functionality that we would like
>to place into an FPGA are as follows:
>
> 1. 18 bit counter running at 60MHz; 18 bit comparator also
> running at 60MHz; 1k x 20 bit FIFO at roughly 1MHz; 18 bit
> adder running also at roughly 1MHz; state machine of approx
> 10 states running at 60MHz.
WOW. If you get any takers on 60Mhz I like to know. I supose you could get 60Mhz on a 18 bit
path in a small part or where this part of the circuit is clocked with a different clock than
the system clock. In my experiences, 25-40Mhz SYSTEM speeds are real. By SYSTEM I mean every
FF clocked by one clock in a synchronus system. Most FPGA's have a dedicated clock tree to aid
in a universal clock.
> 2. As above, but without the FIFO and with 32 bits instead of
> 18.
This just makes it harder. Traditionally the bigger the design the harder and thus longer the
routes internal. This equates to more propigation delay and thus slower speed.
> 3. State machine of 20 states running at 60MHz; 1k x 10 bit
> FIFO at 20MHz; 8 bit counter at 20MHz; several asynchronous
> latches.
Well, no FPGA that I know of has that much INTERNAL ram. You may be able to pipeline the data
flow to external ram to design this. However, again 60Mhz is a bit high.
> 4. One 32 bit adder, two 16 bit adders, four 16 bit
> multipliers and 4k ROM all running at 30MHz.
I've done 16 bit adders at 25Mhz, but no 32 bit stuff..
Most of my experience is with ALTERA and Xilinx parts....
Stan
===============================================
Name: Stan Hodge | Watch this space for
E-mail: stb@dnaco.net | interesting
Date: 05/08/95 | things
Time: 19:49:56 | to come!
===============================================
Article: 1164In <TIMSC.95May2120723@bmw.hwcae.az.Honeywell.COM>, timsc@bmw.hwcae.az.Honeywell.COM (Tim Schneider) writes: > >we're using Altera here to do a PCI bus interface. >I believe there is an app note out that explains the details. > >from the altera express service it looks like its document #'s > >5830 and 5831 > >1-800-5-ALTERA > > -tim > There is a fairly well written article on using FPGAs as a PCI interface in the April 1995 issue of Integrated System Design magazine, starting on page 32. ----------------------------------------------------------------------- Robb Cole | Fax 607-751-6732 e-mail rmcole@lfs.loral.com | -----------------------------------------------------------------------Article: 1165
Does Latice have an ftp site ? If so could someone give me the address. Thanks DominicArticle: 1166
wirthlim@fpga.ee.byu.edu (Michael J. Wirthlin) wrote: #In article <idr.798883860@sycamore>, idr@ee.ed.ac.uk (Iain Rankin) writes: #|> Hi, #|> #|> Does anyone know of, or can anyone suggest, a simple compression (s/w PC) #and #|> decompression (Altera FLEX8000 devices) algo that i could use. #|> #|> I am interested in coding byte streams to increase my through put to #|> an FPGA interface (RIPP10 - supplied by Altera) from a PC. #|> #|> Cheers, #|> #|> Iain # #You can use a simple run length coding scheme to get significant bit-stream #compression. Most bit-streams have long strings of 1's or 0's (very little #relative information). Yes, Run-Length coding is a very simple compression algorithm providing quite good results. An improved version of that algo is the ATRL from A. Leon-Garcia & H. Tanaka : Efiicient Run-Length Encoding, IEEE Trans. on Information Theory, vol. 28, no 6, pp. 880-889, November 1982. wirthlim@fpga.ee.byu.edu (Michael J. Wirthlin) also wrote: #You need to be careful when testing your algorithm, however, because #a faulty bitstream compression/decompression scheme can easily burn or destroy #your FPGA. I would recommend extensive testing on your #compression/decompression *off-line* before attempting it on the FPGA. # #-Mike So, the FPGA could easily be burned due to a faulty comp/decomp scheme ? HOW ??? Maybe I am blind, but I really would like to see it ! I think, at least with a faulty scheme, some (or the whole) information would be lost. Anyway, I wouldn't like to meet that killing bitstream ... daveb@perth.DIALix.oz.au (David Brooks) gave a good idea about the test: # ... / ... / ... after compressing #your bitstream, run it through the expander and verify it against the #original, before letting it near your fpga hardware. murray@src.dec.com (Hal Murray) suggested a CRC to improve reliability : #I suggest a CRC on the bit stream before it gets compressed. # #A CRC is a good idea even without compression. File systems occasionally #make errors. Yes a CRC is a good idea but I am not sure a CRC has some efficiency to recover errors in the discussed scheme (if it's placed before the compression stage). The problem usually arises with Variable Length Coding (VLC) schemes: if a bit in the compressed bitstream changes its value, synchronization is lost in the decompressing stage for the following data. The information is then badly decompressed. To avoid this problem, some synchronization flags must be inserted at times during compression (or words with a synchronizing prefix, for example). I am interested by compression/decompression algorithms ... So, reactions or comments are welcome. Post here or e-mail. Etienne WOUTERS. e-mail: wouters@dice.ucl.ac.be ------------------------------Article: 1167
New Updates to WWW Site for DAC '95 (http://www.dac.com/dac.html)
-----------------------------------------------------------------
The 32nd Annual Design Automation Conference (DAC) will be held at the
Moscone Center in San Francisco, California, on June 12-16, 1995. You can
use this WWW site to get more information about the Conference and download
the registration forms for conference attendance, hotel reservations, "Free
Monday" exhibits pass, and a DACnet account. The site includes pointers to
sights and events in San Francisco and a link to EE Times-interactive Design
Automation Special Edition (http://techweb.cmp.com/eet/eda), created
specifically for the EDA community during the crucial period leading into
and just following the Design Automation Conference.
Recent additions to the site include
5/8/95: Link to EE Times On-Line DAC Focus Section
5/4/95: Tech Brief: ESDA methodologies at DAC
5/4/95: Tech Brief: Evolving Role of Synthesis at DAC
5/4/95: Tech Brief: Physical Design at DAC
5/4/95: Tech Brief: Designer Track at DAC
5/1/95: Summary Schedule
4/29/95: Exhibitor What's New Page
4/15/95: Moscone Area Map
4/13/95: San Franciso Traveler's Services
This site will be continually updated through the end of the conference
with the latest information on meetings and events scheduled for this year's
DAC. A detailed overview of the site follows.
32nd Design Automation Conference
June 12-16, 1995, Moscone Center, San Francisco
Conference Information - Highlights
* Summary Schedule
* Technical program and Designer Track program
* Friday Tutorials
* Proceedings and Best paper info
* Exhibits, Exhibitors, and Exhibitor Presentations
* Show Hours
* Cruisin' - the DAC Party
* Meetings at DAC
+ ACM-SIGDA
+ Birds of a Feather (BOF)
* Contacting convention management services
Registration and Reservations
* Conference
* Hotel
* Air transportation
* Travel grant information
* DACnet accounts
* Spouse and guest registration
The People Behind DAC
* Executive Committee
* Program Committee
* EDA Industry Committee
San Francisco
* Ground transportation and Airport shuttle service
* Traveler's services
* Digital Restaurant Guide to San Francisco
* Moscone Convention Center area map
* Sites to see / Things to do
* San Francisco Chronicle -- Datebook Entertainment listings
* Weather
Sponsoring And Cooperating Organizations
The Association for Computing Machinery (ACM) Membership Info
The ACM Special Interest Group for Design Automation (SIGDA).
The Electronic Design Automation Companies(EDAC)
The Insititute for Electrical and Electronics Engineers (IEEE)
The IEEE Circuits and Systems Society (IEEE-CAS)
Other Web Sites of Interest to the DA Community
The SIGDA WWW server has a plethora of DA information, including a
comprehensive list of DA Conferences at http://kona.ee.pitt.edu/
Electrical Engineering World Wide Web Hotlist at http://www.e2w3.com/
EE Times is running an online Design Automation Special Edition
around DAC at http://techweb.cmp.com/eet/eda
________________________________________________________________________
Posted for 32nd DAC by Sean Murphy, Leader-Murphy, Inc.
http://www.l-m.com/l-m.html
Article: 1168|> #You need to be careful when testing your algorithm, however, because |> #a faulty bitstream compression/decompression scheme can easily burn or destroy |> #your FPGA. I would recommend extensive testing on your |> #compression/decompression *off-line* before attempting it on the FPGA. |> # |> #-Mike |> |> So, the FPGA could easily be burned due to a faulty comp/decomp scheme ? |> HOW ??? Maybe I am blind, but I really would like to see it ! |> I think, at least with a faulty scheme, some (or the whole) information would be lost. |> Anyway, I wouldn't like to meet that killing bitstream ... |> |> I mis-understood the original posting. I presumed the original post suggested compressing the bitstream of an FPGA. As such, I suggested using extra care when decompressing the bitstream back into the FPGA. If the faulty comp/decomp scheme is used for a bitstream, who knows what will happen within the FPGA. I have had my fair share of loading invalid bitstreams into FPGAs with *surprising* results. Because the original post discussed implementing compression/decompression *within* the FPGA, a faulty comp/decomp scheme poses no such problems if all the appropriate FPGA vendor tools are used to generate the bitstream. As stated above, a faulty comp/decomp scheme will only destroy the information used, and the FPGA will remain safe. I do feel, however, that FPGAs provide a nice platform for improving software versions of custom comp/decomp algorithms. Sorry about the confusion. -- Michael J. Wirthlin Brigham Young University - Electrical Engineering Department Reconfigurable Logic Laboratory (801) 378-7206Article: 1169
>>>>> On 10 May 1995 13:07:26 GMT, wouters@dice.ucl.ac.be ( Wouters Etienne ) said:
W> So, the FPGA could easily be burned due to a faulty comp/decomp scheme ?
W> HOW ??? Maybe I am blind, but I really would like to see it !
W> I think, at least with a faulty scheme, some (or the whole) information would be lost.
W> Anyway, I wouldn't like to meet that killing bitstream ...
Cooking an FPGA is pretty easy. On some FPGAs, all you need to do
is load a bitstream that consists of all `ones.' This will usually
turn on all of the drivers to all wires, power consumption goes
through the roof and the FPGA gets hot and dies. Loading all ones
is an easy mistake to make by the way, EPROMs are all ones
in the unprogrammed state, right? Load in an unprogrammed EPROM
and cook the FPGA.
Here is a riddle.
Q: Why are FPGA programmers good at typing with either hand?
A: Because they need to keep one finger on the FPGA (to see if it
is getting hot).
This sounds funny but it turns out to be true for my lab.
--
Brad L. Hutchings - (801) 378-2667 - hutch@ee.byu.edu
Brigham Young University - Electrical Eng. Dept. - 459 CB - Provo, UT 84602
Reconfigurable Logic Laboratory
Article: 1170hutch@timp.byu.edu (Brad Hutchings) writes: >Q: Why are FPGA programmers good at typing with either hand? >A: Because they need to keep one finger on the FPGA (to see if it >is getting hot). >This sounds funny but it turns out to be true for my lab. Brad Taylor of GigaOps showed me a very neat feature of their XMOD boards at FCCM. They have a cheap little temperature sensor, an op-amp to amplify it, and a cheap little $5 microcontroller (PIC, I believe) that will shut it all down if things get too toasty. Good engineering. -- Mike Butts, Portland, Oregon mbutts@netcom.comArticle: 1171
>>>>> "Brad" == Brad Hutchings <hutch@timp.byu.edu> writes:
Brad> Q: Why are FPGA programmers good at typing with either hand?
Brad> A: Because they need to keep one finger on the FPGA (to see
Brad> if it is getting hot).
You can type with two hands with your XC4000 parts if you:
a) turn on the bitstream CRC feature in makebits
b) hook up an LED driver to /INIT
Then your LED will light up if/when your bitstream doesn't CRC check.
This bit of trivia is from the Oct 1994 Xilinx App Note "FPGA
Configuration Guidelines"
Kelly
--
Kelly Hall <hall@lal.cs.byu.edu>
http://lal.cs.byu.edu/people/hall.html
Article: 1172
>>>>> On 10 May 1995 13:28:23 -0600, hall@lal.cs.byu.edu (Kelly Hall) said:
KH> NNTP-Posting-Host: puma.cs.byu.edu
KH> X-Newsreader: (ding) Gnus v0.65
>>>>> "Brad" == Brad Hutchings <hutch@timp.byu.edu> writes:
Brad> Q: Why are FPGA programmers good at typing with either hand?
Brad> A: Because they need to keep one finger on the FPGA (to see
Brad> if it is getting hot).
KH> You can type with two hands with your XC4000 parts if you:
KH> a) turn on the bitstream CRC feature in makebits
KH> b) hook up an LED driver to /INIT
KH> Then your LED will light up if/when your bitstream doesn't CRC check.
KH> This bit of trivia is from the Oct 1994 Xilinx App Note "FPGA
KH> Configuration Guidelines"
This is pretty useless, really. CRC checks only verify that the
bitstream is legal. Legal bitstreams can cook FPGAs just as easily as
illegal ones. This *is* hardware afterall and you can easily create
the equivalent of a short circuit on the FPGA. FPGAs will usually
tolerate quite a few shorts in a circuit but if you get too many, the
power consumption and the resulting heat will damage the device. In
addition, in any real system you will have a mix of memories with
multiple FPGAs. Bad timing or design screwups can result in bus
conflicts between memories or other FPGAs and FPGAs can be damaged
that way as well. So, while hooking the init line to an LED is cute,
it is not all that helpful. We read ours through software anyway. We
still keep our fingers at the ready, though :-) GigaOps (as Mike Butts
notes in a later message) dealt with the problem with a little sensor.
I agree with Mike, that is a good feature. It really shows that they
have had a lot of experience with FPGAs. I like the sensor idea
because it is really hard to keep your fingers on more than a couple
of FPGAs at a time. After about 4 FPGAs, we have to bring in more
graduate students :-)
--
Brad L. Hutchings - (801) 378-2667 - hutch@ee.byu.edu
Brigham Young University - Electrical Eng. Dept. - 459 CB - Provo, UT 84602
Reconfigurable Logic Laboratory
Article: 1173The Altera FLEX 8000 devices have a built in CRC checker for the configuration data. Therefore a faulty compression routine which corrupts the data would not be able to damage the part. The device when it detects an error will signal an error and then sit by idly, unconfigured.Article: 1174
2. GI / ITG Workshop
Anwenderprogrammierbare Schaltungen
===================================
22. - 23. Juni 1995
Karlsruhe
GI / ITG Fachgruppen
"Methoden des Entwurfs und der Verifikation digitaler
Schaltungen und Systeme"
"CAD-Umgebungen fuer den Entwurf integrierter Schaltungen
und Systeme"
in Zusammenarbeit mit dem FZI Karlsruhe, der TU Muenchen,
der "elektronik industrie" und der ISDATA GmbH
Vorsitzender des Programmkomitees:
Prof. Dr.-Ing. K. Antreich, TU Muenchen
Organisation / Tagungsleitung:
Prof. Dr. Ing. W. Rosenstiel, FZI
Dr. A. Ditzinger, ISDATA
Donnerstag, 22.06.1995
======================
10.30 Eroeffnung
Grusswort des Tagungsleiters
10.40 Architekturen I
Sitzungsleitung: K. Antreich
10.40 "Gate Array Prototyping fuer 100K Gates mit Hilfe von
Embedded Programmable Logic Devices"
B. Niedermeier, ALTERA
11.00 "In-System programmierbare Logik"
W. Voldan, Lattice
11.30 "Logic Block and Routing Considerations in the XC5000
FPGA Architecture"
P. Alfke, B. Fawcett, D. Tavana, W. Yee, S. Young, Xilinx
11.50 "Analoge FPGAs schliessen die Luecke zur Systemintegration"
R. Luft, Professional Engineering
12.10 "Umfrageergebnisse zu den Anforderungen an
CPLD/FPGA Designsysteme"
U. Harreiss, K. Ronge, FhG IIS Erlangen
12.30 Mittagspause
14.00 Werkzeuge I
Sitzungsleitung: E. Barke
14.00 "K-Way Partitioning for Multiple Type FPGAs"
B. Riess, H. Giselbrecht, B. Wurth, TU Muenchen
14.20 "Automatische Bausteinauswahl fuer die System-
implementierung in FPGAs"
U. Weinmann, FZI Karlsruhe
14.40 "FSM-Synthese durch lineare Partitionierung fuer Lookup-
Table basierte FPGAs"
K. Feske, S. Mulka, G. Franke, M. Koegst, FhG IIS Dresden
15.00 "Pipelines and Power Budget on FPGAs"
E. I. Boemo, S. López-Buedo, G. González de Rivera,
J. M. Meneses, Universidad Politécnica de Madrid
15.20 Kaffeepause
16.00 Anwendungen I
Sitzungsleitung: H. Ritzl
16.00 "Einsatz von FPGAs fuer einen Zustandsklassen-Monitor"
E. Thurner, Siemens AG
16.20 "ATM-Switch Prototyping mit LCAs"
B. Lang, C. Frankenfeld, V. Pietzuch, MAZ Hamburg GmbH
16.50 "Enable++: Ein Hochleistungs-Prozessorsystem auf FPGA-
Basis mit komfortabler Entwicklungsumgebung"
H. Hoegl, A. Kugel, J. Ludvig, R. Maenner, K. H. Noffz,
R. Zoz, Universitaet Mannheim
17.10 "FPGAs as Reconfigurable Computing Elements"
B. Fawcett, P. Alfke, Xilinx
17.30 "Anwenderprogrammierbare Steuerungssysteme"
B. Klose, W. Lang, A. W. Wieland, Universitaet
Gesamthochschule Siegen
20.00 Abendveranstaltung
Sitzungsleitung: A. Ditzinger
20.00 "Der Unterschied zwischen Seeblick und Sea of Gates"
ISDATA laedt zu geselliger Runde mit Abendbueffet.
Freitag, 23.06.1995
===================
8.30 Werkzeuge II
Sitzungsleitung: D. Schmid
8.30 "Entwicklung und Implementierung eines Algorithmus
zur parametergesteuerten Generierung von Zaehlernetzlisten"
S. Riedel, H.-J. Brand, D. Mueller, TU Chemnitz-Zwickau
8.50 "Structured Design Implementation - Eine Implemen-
tierungsstrategie fuer Datenpfade auf FPGAs"
A. Koch, TU Braunschweig
9.10 "Bibliotheksorientierte Technologieabbildung synthe-
tisierter Datenpfade"
T. Kuhn, P. Thole, E. Schubert, W. Rosenstiel,
Universitaet Tuebingen, U. Kebschull, FZI Karlsruhe
9.30 "FPGA-ASIC Umsetzung aus der Sicht des Systementwurfs"
A. Fabricius, M. Seifert, Thesys
9.50 "Voraussetzungen fuer erfolgreiche FPGA Synthese"
A. Ditzinger, ISDATA
10.20 Kaffeepause
11.00 Architekturen II
Sitzungsleitung: W. Voldan
11.00 "FPGAs fuer den Einsatz in portablen Applikationen"
D. Rudolf, Actel
11.20 "An Software angepasste Hardware"
J. Rosenberg, A. Hesener, Atmel
11.40 "Vom Entwurf zum fertigen FPGA" oder "Dichtung und Wahrheit"
M. Haeusing, Bodenseewerk Geraetetechnik GmbH
12.00 Kaffeepause
12.30 Anwendungen II
Sitzungsleitung: U. Kebschull
12.30 "Erfahrungen mit FPGAs in der digitalen Bildsignalverarbeitung"
H. Krahn, C. Stredicke, M. Talmi, Heinrich-Hertz-Institut
fuer Nachrichtentechnik GmbH, TU Berlin
13.00 "Rapid Prototyping von Video-Applikationen unter
Echtzeitbedingungen"
S. Tamme, SICAN GmbH
13.20 "Praktische Erfahrungen bei der Entwicklung von EPLDs
mit Hilfe von VHDL am Beispiel eines Bus-Controllers"
K. Schwan, Array Electronic
13.40 "DSP Funktionen mit FLEX8000"
B. Niedermeier, ALTERA
Vorfuehrungen:
==============
An beiden Tagen stehen Experten von Halbleiter- und Software-
firmen fuer Fragen und Vorfuehrungen zur Verfuegung.
Veranstaltungsort:
==================
"Kuehler Krug", Wilhelm-Baur-Str. 3, 76135 Karlsruhe,
Tel: 0721/ 85 54 86
Teilnahmebedingungen:
=====================
Je Teilnehmer DM 220,- inkl. Mehrwertsteuer
Universitaetsangehoerige und GI-Mitglieder DM 170,- inkl. Mehrwertsteuer
Die Gebuehr enthaelt die Teilnahme an den Sitzungen, den Tagungsband, die
Verpflegung an beiden Tagen und die Teilnahme an der Abendveranstaltung.
Um den Verwaltungsaufwand gering zu halten, fuegen Sie Ihrer Anmeldung bitte
einen Verrechnungsscheck bei. Sie erhalten eine quittierte Rechnung.
Anmeldeschluss:
===============
Bitte melden Sie sich schnellstmoeglich an. Sie sichern sich so Ihre
Teilnahme und erleichtern uns die Planung. Letzter Anmeldetermin ist der
14. Juni 1995. Die Abmeldung ist bis 14. Juni 1995 kostenfrei moeglich,
danach wird die Tagungsgebuehr faellig.
Hotel:
======
Ein Kontingent Hotelzimmer ist bei Buchung bis zum 08. Juni 1995
(Stichwort "ISDATA") zu Sonderpreisen verfuegbar:
Queens-Hotel, 76137 Karlsruhe, Ettlinger Str. 23
Tel. 0721 / 3727-0, Fax: 0721 / 3727-170
* zentral gelegen, Naehe Hauptbahnhof und Innenstadt, bei Bahnanreise zu empfehlen
DM 155,- + DM 22,- Fruehstuecksbueffet
Scandic Crown, Beim Runden Plom, 76275 Ettlingen
Tel. 07243 / 71-0, Fax: 07243 / 71-666
* bei Anreise mit PKW zu empfehlen
DM 155,- inklusive Fruehstueck
Sonstige Hotelvermittlung kostenfrei ueber
HOTLINE Hotelvermittlung
Stichwort: ISDATA
Tel: 0721 / 885022
Fax: 0721 / 882723
Anfahrt per Kfz:
================
Autobahn Abfahrt "Karlsruhe-Mitte"; weiter auf der Suedtangente Richtung Landau;
Abfahrt "Gruenwinkel" Richtung Pforzheim; der "Kuehle Krug" liegt unmittelbar an
der Abfahrt.
Mit oeffentlichen Verkehrsmitteln:
==================================
Ab Hauptbahnhof Strassenbahnlinie 3 oder 4 (Richtung Europaplatz ueber Karlstrasse)
bis Haltestelle Mathystrasse, Strasse ueberqueren, links in Mathystrasse einbiegen,
von dort mit Strassenbahnlinie 5 (Richtung Rheinhafen) bis Haltestelle "Kuehler Krug"
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