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
Hamilton hamilton@dimensional.com wrote: >Does anyone know what this chip is??? > @M <-- Motorola Logo > SC419510FU > F66Y > HLKH9518 >This chip is inside a Sony Playstation memory cartridge next to >a AT29LV010 eeprom. This is the Hedgehog (HLKH) chip. It supplies the internal rodents with nutritive pellets. The "SC" prefix indicates it's optimized for the Sonic Hedgehog.Article: 4726
Hamilton wrote: > > Does anyone know what this chip is??? > > @M <-- Motorola Logo > SC419510FU > F66Y > HLKH9518 > > This chip is inside a Sony Playstation memory cartridge next to > a AT29LV010 eeprom. > > thanks Doesn't look like an FPGA, Motorola's fpga's are MPA1016, MPA1036, MPA1064, and MPA1100, according to my Motorola databook. Eeproms are used for other things besides programming FPGA's, the chip you're looking at is possibly some sort of custom uP. Try posting to sci.electronics.components. -- John L. Smith, Pr. Engr. | Sometimes we are inclined to class Univision Technologies, Inc. | those who are once-and-a-half witted 6 Fortune Dr. | with the half-witted, because we Billerica, MA 01821-3917 | appreciate only a third part of their wit. jsmith@univision.com | - Henry David ThoreauArticle: 4727
phony@see.sig.for.real wrote: : fliptron@netcom.com (Philip Freidin) wrote: : >In article <E1y6pA.Bv6@nonexistent.com> kardos@mail.matav.hu writes: : >> Hi! : >> : >> Have anybody ever heard of a circuit named 74hc0324 or 74hco324 ? Or does anybody know, : >>where to search for it ? (AltaVista couldn't find it.) : >> Please answer in e-mail too ! Thanks for any hint. : > : >Yes, I know what this chip is. It is the control chip inside a software : >security block (dongle), right next to a 93C46K ( a serial EEPROM), and an : >HC00 (quad CMOS nand gate). There are also 17 surface mount resistors, 7 : >capacitors, and 4 diodes near by. I hope you aren't trying to crack it. : > : Hacking aside, is that chip a custom part for that specific dongle, : or a merchant part produced for general sale? If the latter, it might : have wider application than just security blocks. We have a huge CDROM data base (about a hundred CDs), and I was unable to find any reference to it. Among other places, it is used in the PADS PCB layout program key. Of course, PADS is such a perverse program, there is no use in bothering to try to copy the key unless one is a glutton for punishment. But I suspect it is used elsewhere as well. Bob.Article: 4728
In article <32A7C7D7.5D81@cinenet.net>,
Kayvon Irani <kirani@cinenet.net> wrote:
> Just wondering if anyone out there has first hand experience or
> cares to comment
Lack of first hand experience never stopped me before.
> on the use of ASICs and FPGAs in safety critical applications such
> as in
> passanger airplanes. Are the FPGAs more prone to failure by their
> virtue of
> being "programmable" and because they have unused dangling gates
> on the silicon?
Well, the one-time programmable gate arrays are much less reliable,
because of the fuses/antifuses - several orders of magnitude according
to [1].
As for dangling gates possibly causing problems, of course! There are
not just dangling gates, but all the configuration logic/memory that
can go wrong. Figure on a factor of 10 or more just for the
difference in logic density. It's more than that, though, because
memories (even SRAM) are less reliable. The electronics and
diagnostics people at Rome Labs do a lot of this stuff, such as [2].
They're the ones who put out the (discontinued) 217 component
reliability handbook.
Jackie.
--
1. Low, S., Tandem Computers. Personal communication.
2. Kwiat, K., S. Hariri, and W. Debany. "FPGA-Based Selective Fault
Tolerance," IEEE International Workshop on Embedded Fault-Tolerant
Systems, Dallas, September 1996.
Article: 4729Kayvon Irani wrote: > > Hi everyone: > > Just wondering if anyone out there has first hand experience or cares to comment > on the use of ASICs and FPGAs in safety critical applications such as in > passanger airplanes. Are the FPGAs more prone to failure by their virtue of > being "programmable" and because they have unused dangling gates on the silicon? > Any one used any particular FPGAs on FAA certified equipment? > > > Regards, > Kayvon Irani > Los Angeles, ca The dangling gates can be tied to a power supply, but I don't think it's ever been shown to be a problem to let them float. It does seem like FPGAs should fail more frequently due to their higher complexity, but I don't know if they actually do. The fab process for FPGA's might be more characterized and less prone to failure. I can't really comment on measured failure rates, but I've seen some data from Xilinx, which show very low FITs (Failures in Time) for the old 3K parts. There is however, the issue of testing. SRAM based FPGAs can in theory be 100% tested, since every internal node and data path is accessable. ASICs are impossible to fully test, although massive numbers of test vectors can reduce the possibility of remaining errors to nill. But with the test vector approach, you never really know. You have to trust that the guy who wrote the test vectors did a thorough and 100% error free job. And the test vectors are never really applied in system. Marginal failures might occur under very specific conditions of temp, voltage, input noise coupled to specific data patterns. A more insideous failure is where individual device differences cause the parts to fail for your design. At least with an ASIC, the functional devices can be tested. With FPGAs you test it one way, and only download the program in system. The programmed FPGA never gets tested. On the other hand, these types of errors should never occur because the tools are supposed to be perfect. If you use tested parts, static timing, fully synchronous methods and conservative synchronization timing, the possiblity of errors due to individual FPGA timing differences will be reduced to near O (asssuming perfect tools). Then there is the possiblilty that the FPGA's SRAM state will mysteriously change state causing something like an active high bus enable to become active low causing massive current draws, system failures and general mayhem. But I don't believe the SRAM cells are any more prone to flipping state than a regular D flipflop and ASICs are full of those. There is another interesting possibility for FPGA failure though. If a software bug causes an FPGA to be loaded with the wrong file, all kinds of bad stuff can happen. The old 3K parts would kind of pop and die, the Xilinx 4K FPGAs just kind of get real hot and desolder themselves, but seem to survive the adventure. I can't say what happens to Altera parts. I'd like to know though. Another interesting concept is that if a potential functional or timing problem is found in installed ASICs, it can be very difficult to respin the ASIC, remove the installed parts and fix the problem. I don't think you'd enjoy telling your boss that your new ASIC, which has been installed on hundreds of airplanes might have a serious but infrequent problem. With an SRAM based FPGA, at least you can fix the bug and change the program. - In general, the less you think about error mechanisms, the better. Ignorance is bliss. - BradArticle: 4730
In article <580u7r$hsd@niaomi.iscm.ulst.ac.uk>, joe@iscm.ulst.ac.uk says... > Hi > I'm using Xilinx 5.1 version with Viewlogic as my schematic editor. I am > designing neural networks and implementing them on a XC4013 FPGA. However I > am having trouble with memory requirements. When I go and run XMAKE on my > schematic, I get an error during the X-BLOX routine stating that X-BLOX > cannot process the design due to > Error 20244: Out of memory > > I have about 600K of conventional memory available and 24M of RAM. Is this > not enough?? This may come as a shock to you, but 64M is arguably a *minimum* for doing 4013 design. It used to be 32M in the good old DOS days; but if you consider WinNT's "needs" (i.e. 16M to crawl, 32M to *run*), then "just do it". Look, you're spending several $K on the development SW. It *will* run faster with more RAM, and RAM is cheap, and your time *is* worth something. 64M costs about $375 these days. It's a bargain vs. the time lost. If you struggle along with 32M, your "savings" are arguably an illusion. We can save the Win95 vs. NT discussion for some other time, but that is another issue waiting to hit many of us on the head (if it hasn't already). Sheesh, the prospect of discussing ViewLogic's NT vs. W95 pricing strategy should be good for some strong points of view. By the way, Lucent is dropping factory support for Win3.x and DOS, for their toolset. W95 and NT from here on out. Go for it. -- Bob Elkind **************************************************************** Bob Elkind mailto:eteam@aracnet.com 7118 SW Lee Road part-time fax number:503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903 ****** Video processing, R&D, ASIC, FPGA design consulting *****Article: 4731
bob elkind wrote: > > In article <580u7r$hsd@niaomi.iscm.ulst.ac.uk>, joe@iscm.ulst.ac.uk says... > > Hi > > I'm using Xilinx 5.1 version with Viewlogic as my schematic editor. I am > > designing neural networks and implementing them on a XC4013 FPGA. However I > > am having trouble with memory requirements. When I go and run XMAKE on my > > schematic, I get an error during the X-BLOX routine stating that X-BLOX > > cannot process the design due to > > Error 20244: Out of memory > > > > I have about 600K of conventional memory available and 24M of RAM. Is this > > not enough?? > > This may come as a shock to you, but 64M is arguably a > *minimum* for doing 4013 design. It used to be 32M in the > good old DOS days; but if you consider WinNT's "needs" > (i.e. 16M to crawl, 32M to *run*), then "just do it". > > Look, you're spending several $K on the development SW. > It *will* run faster with more RAM, and RAM is cheap, and your > time *is* worth something. 64M costs about $375 these days. > It's a bargain vs. the time lost. If you struggle along with > 32M, your "savings" are arguably an illusion. > > We can save the Win95 vs. NT discussion for some other time, > but that is another issue waiting to hit many of us on the > head (if it hasn't already). Sheesh, the prospect of > discussing ViewLogic's NT vs. W95 pricing strategy should > be good for some strong points of view. > > By the way, Lucent is dropping factory support for Win3.x > and DOS, for their toolset. W95 and NT from here on out. Lucent may be dropping support for Win3.x and DOS, but so far that's all Xilinx supports. Amazingly, Win95 and WinNT support isn't here yet (Yes, I know parts of XACT are supposed to run under Win95 and NT, but I haven't had any luck with it.) Regards, ScottArticle: 4732
Hello all, In the past I've seen people discuss using the XChecker cable, so I'm hoping someone will have experience doing what I'm trying to do. Basically I want to write and read to the serial port on my unix box and directly control and read signals on the XChecker cable, including TCK,TMS, and TCK. Ultimately I want to be able to send JTAG bound. scan commands to a compliant LCA sitting in a FPGA demo board. I would appreciate it if anyone could provide info on doing this or point me to specific documentation on cable control. Many thanks in advance. Tony Ambardar Please reply to: tonya@ee.ubc.caArticle: 4733
I've been observing this group with great interest as an amateur mathematician and electronics sub-novice... Can anyone suggest how I could start implementing alternative numeric formats and the arithmetic operations to support them, if I can define the operations using state tables or C code? Is there software that would help me emulate then build an FPGA device by simply spelling out, for example, the results of adding 8- or 16-bit parallel operands?Article: 4734
=============================================================================
Call for Papers
1997 International Symposium on Physical Design
April 14-16, 1997
Napa Valley, California
Sponsored by the ACM SIGDA in cooperation with
IEEE Circuits and Systems Society
The International Symposium on Physical Design provides a forum to
exchange ideas and promote research on critical areas related to the
physical design of VLSI systems. All aspects of physical design, from
interactions with behavior- and logic-level synthesis, to back-end
performance analysis and verification, are within the scope of the
Symposium. Target domains include semi-custom and full-custom IC, MCM
and FPGA based systems.
The Symposium is an outgrowth of the ACM/SIGDA Physical Design
Workshop. Following its five predecessors, the symposium will
highlight key new directions and leading-edge theoretical and
experimental contributions to the field. Accepted papers will be
published by ACM Press in the Symposium proceedings. Topics of
interest include but are not limited to:
1. Management of design data and constraints
2. Interactions with behavior-level synthesis flows
3. Interactions with logic-level (re-)synthesis flows
4. Analysis and management of power dissipation
5. Techniques for high-performance design
6. Floorplanning and building-block assembly
7. Estimation and point-tool modeling
8. Partitioning, placement and routing
9. Special structures for clock, power, or test
10. Compaction and layout verification
11. Performance analysis and physical verification
12. Physical design for manufacturability and yield
13. Mixed-signal and system-level issues.
IMPORTANT DATES: Submission deadline: December 20, 1996
Acceptance notification: February 1, 1997
Camera-ready (6 page limit) due: March 1, 1997
SUBMISSION OF PAPERS:
Authors should submit full-length, original, unpublished papers
(maximum 20 pages double spaced) along with an abstract of at most
200 words and contact author information (name, street/mailing address,
telephone/fax, e-mail).
Electronic submission via uuencoded e-mail is encouraged (single
postscript file, formatted for 8 1/2" x 11" paper, compressed with
Unix "compress" or "gzip''). Email to:
ispd97@ece.nwu.edu
Alternatively, send ten (10) copies of the paper to:
Prof. Majid Sarrafzadeh
Technical Program Chair, ISPD-97
Dept. of ECE, Northwestern University
2145 Sheridan Road, Evanston, IL 60208 USA
Tel 847-491-7378 / Fax 847-467-4144
SYMPOSIUM INFORMATION:
To obtain information regarding the Symposium or to be added to the
Symposium mailing list, please send e-mail to ispd97@cs.virginia.edu.
Information can also be found on the ISPD-97 web page:
http://www.cs.virginia.edu/~ispd97/
SYMPOSIUM ORGANIZATION:
General Chair: A. B. Kahng (UCLA and Cadence)
Past Chair: G. Robins (Virginia)
Steering Committee: J. Cohoon (Virginia), S. Dasgupta (Sematech),
S. M. Kang (Illinois), B. Preas (Xerox PARC)
Program Chair: M. Sarrafzadeh (Northwestern)
Keynote Address: T. C. Hu (UC San Diego) & E. S. Kuh (UC Berkeley)
Special Address: R. Camposano (Synopsys)
Publicity Chair: M. J. Alexander (Washington State)
Local Arrangements Chair: J. Lillis (UC Berkeley)
Technical Program Committee: C. K. Cheng (UC San Diego)
W. W.-M. Dai (UC Santa Cruz)
J. Frankle (Xilinx)
D. D. Hill (Synopsys)
M. A. B. Jackson (Motorola)
J. A. G. Jess (Eindhoven)
Y.-L. Lin (Tsing Hua)
C. L. Liu (Illinois)
M. Marek-Sadowska (UC Santa Barbara)
M. Sarrafzadeh (Northwestern)
C. Sechen (Washington)
K. Takamizawa (NEC)
M. Wiesel (Intel)
D. F. Wong (Texas-Austin)
E. Yoffa (IBM)
=============================================================================
Article: 4735Thanx for the answers ! Of course, the chip is in the PADS dongle. We bought three of them, and I was wondering how they work, so I opened them. I saw the serial EEPROM, the HC00, and this chip, and I thought that the key is too easy to duplicate, and that PADS Software is stupid because they applied a so primitive key. But now I see from your answers, I wasn't right. Besides, if I would want to crack the PADS, I would buy a 50$ SW packet from a certain Canadian firm, which removes the protection from the .EXE files. Thanx again! ***************************** Botond Kardos kardos@mail.matav.hu phone/fax: (36 1) 268-0934Article: 4736
Dear All,
I am configuring a XC4010E-4PQ160 in slave serial mode. My data
book
(7/96 pg 4-69) assures me that I can clock the configuration data into
the
device at 10 Mbits/second. The clock that I am using is bursty at a peak
frequency of 8.25 MHz and I have checked that I'm meeting the setup and
hold
requirements. I'm also meeting the high and low times for the clock.
The data for the configuration originally come from a PC which
passes a
byte at a time to some circuitry which converts these byte-wide data to
serial
bits. This results in bursts of eight clocks (at 8.25 MHz) and eight
data bits
being sent every 4 us. The clock is left high between bursts. This all
works
fine. However, when a faster PC is used the gap between bursts reduces
somewhat
so that the data are sent in bursts only 2.5 us apart. This stops the
device
configuring. The clock rate during 8 bit bursts remains the same, the
only
difference is in the gap between bursts. Note that there is always some
gap
between bytes, the bursts never become coincident. When you look at the
configuration data which are passed to DOUT the first few bytes are
passed
through, but then no more data appears on DOUT even though more goes
into DIN.
I have worked around this problem at the moment by adding some delays
between
bytes in the PC software. However, this should not be necessary
according to the
data book. Please help me understand what is going on!
thanks.
yours, Symsx.
Article: 4737Dear everyone. I rode (is it the past of read? I think but...) a book about all the plds, so I know the technicals difference between epld and fpga. But I would like to know "in use" what is the real difference you can make between an FPGA and a high density epld? I just see the better integration for some fpga, but for the others?? Thank Bellec Raphael. bellecr@esiee.frArticle: 4738
Per your request, I am reposting the announcement along with general
information about the software and update information about version 0.2
Thanks very much for your interest.
Sincerely,
The POLIS Team
ORIGNIAL ANNOUNCEMENT
---------------------
Dear colleague,
It is our pleasure to announce the public availability of POLIS-v0.2
co-design environment for control-dominated embedded systems.
POLIS offers an integrated interactive environment for specification,
co-simulation, formal verification, and synthesis of embedded systems
implemented as a mix of hardware and software components.
Version 0.2 offer many add features, including brand new microcontroller
resource library handling and ptolemy simulation debugging. Please see
REL_NOTES for more detail.
Most of the information about POLIS, including pointers to source and
object code (for various CPUs and OSes) is available at our WEB site
http://www-cad.eecs.berkeley.edu/Respep/Research/hsc/abstract.html
The software is available under the usual copyright rules of the
University of California
(see also http://www-cad.eecs.berkeley.edu:80/copyright.html).
If you are interested, but do not have WEB access, please contact us via
e-mail at polis-questions@ic.eecs.berkeley.edu.
Best regards,
the POLIS team
(currently including Felice Balarin, Massimiliano Chiodo, Alberto
Ferrari, Paolo Giusto, Harry Hsieh, Attila Jurecska, Marcello Lajolo,
Luciano Lavagno, Claudio Passerone, Claudio Sansoe', Ellen Sentovich,
Marco Sgroi, Kei Suzuki, Bassam Tabbara, Reinhard von Hanxleden, and
Alberto Sangiovanni-Vincentelli)
GENERAL INFORMATION
-------------------
Motivation for HW/SW Co-Design
Embedded controllers for reactive real-time applications are implemented
as mixed software-hardware systems. These controllers utilize
Micro-processors, Micro-controllers and Digital Signal Processors but
are neither used nor perceived as computers. Generally, software is used
for features and flexibility, while hardware is used for performance.
Some examples of applications of embedded controllers are:
Consumer Electronics: microwave ovens, cameras, compact disk
players.
Telecommunications: telephone switches, cellular phones.
Automotive: engine controllers, anti-lock brake controllers.
Plant Control: robots, plant monitors.
Design of embedded systems can be subject to many different types of
constraints, including timing, size, weight, power consumption,
reliability, and cost.
Current methods for designing embedded systems require to specify and
design hardware and software separately. A specification, often
incomplete and written in non-formal languages, is developed and sent to
the hardware and software engineers. Hardware-software partition is
decided a priori and is adhered to as much as is possible, because any
changes in this partition may necessitate extensive redesign. Designers
often strive to make everything fit in software, and off-load only some
parts of the design to hardware to meet timing constraints. The problems
with these design methods are:
Lack of a unified hardware-software representation, which leads to
difficulties in verifying
the entire system, and hence to incompatibilities across the HW/SW
boundary.
A priori definition of partitions, which leads to sub-optimal
designs.
Lack of a well-defined design flow, which makes specification
revision difficult, and directly impacts time-to-market.
There are many different academic approaches to try to solve the problem
of embedded system design. In our opinion, none of them address
satisfactorily the issues of unbiased specification and efficient
automated synthesis for control-intensive reactive real-time systems.
Therefore, we are developing a methodology for specification, automatic
synthesis, and validation of this sub-class of embedded systems (that
includes the examples described above). Design is done in a unified
framework, POLIS, with a unified hardware-software representation, so as
to prejudice neither hardware nor software implementation. This model is
maintained throughout the design process,
in order to preserve the formal properties of the design.
Introduction to POLIS
The POLIS system is centered around a single Finite State Machine-like
representation. A Co-design Finite State Machine (CFSM), like a
classical Finite State Machine, transforms a set of inputs into a set of
outputs with only a finite amount of internal state. The difference
between the two models is that the synchronous communication model of
classical concurrent FSMs is replaced in the CFSM model by a finite,
non-zero, unbounded reaction time. This model of computation can also be
described as Globally Asynchronous, Locally Synchronous. Each element of
a network of CFSMs describes a component of the system to be modeled.
The CFSM specification is a priori unbiased towards a hardware or
software implementation. While both perform the same computation for
each CFSM transition, hardware and software exhibit different delay
characteristics. A synchronous hardware implementation of CFSM can
execute a transition in 1 clock cycle, while a software implementation
will require more than 1 clock cycle. CFSMs are also a synthesizable and
verifiable model, because many existing theories and tools for the FSM
model can be easily adapted for CFSM.
The design flow that is currently implemented in the POLIS system is
described more in detail below.
1.High Level Language Translation
In POLIS, designers write their specifications in a high level
language (e.g., ESTEREL, graphical FSMs, subsets of Verilog or VHDL)
that can be directly translated into CFSMs. Any high level language with
precise semantics based on extended FSMs can be used to model individual
CFSMs.
2.Formal Verification
The formal specification and synthesis methodology embedded within
POLIS makes it possible to interface directly with existing formal
verification algorithms that are based on FSMs. POLIS includes a
translator from the CFSM to the FSM formalism which can be fed directly
to verification systems (e.g. VIS). In addition to uncovering bugs in a
design, we also use formal verification to guide the synthesis process.
Since the abstract CFSM model covers the behavior of all possible
hardware-software implementations at once, it is possible to refine the
specification base on the output of formal verification. Formal
verification tools today still have problems with complexity. We have
developed a methodology which incorporates a set of abstraction and
assumption rules specific to POLIS and CFSMs. With this formal
verification methodology we are able to verify designs which are larger
than is previously possible.
3.System Co-simulation
System level HW-SW Co-simulation is a way to give designers
feedback on their design choices. These design choices include HW-SW
partitioning, CPU selection, and scheduler selection. Fast timed
co-simulation (up to millions of clock cycles per second on a
workstation) is possible in POLIS thanks to the software synthesis and
performance estimation techniques described below. We currently utilize
PTOLEMY as a simulation engine, but we are not limited to PTOLEMY. VHDL
code including all the co-simulation information is also an output of
the system, so any commercial VHDL simulator can be adapted for this
purpose.
4.Design Partitioning
By design partitioning we mean making system-level design decisions
such as HW-SW partitioning, target architecture selection, and scheduler
selection. These decisions are based heavily on design experience and
are very difficult to automate. We therefore provide the designer with
an environment to quickly evaluate any such decision through various
feedback mechanisms from either formal verification or system
co-simulation.
5.Hardware Synthesis
A CFSM sub-network chosen for HW implementation is implemented and
optimized using logic synthesis techniques from SIS. Each CFSM,
interpreted as a Register-Transfer Level specification, can be mapped
into BLIF, XNF, VHDL or Verilog.
6.Software Synthesis
A CFSM sub-network chosen for SW implementation is mapped into a
software structure that includes a procedure for each CFSM, together
with a simple Real-time Operating System:
1.CFSMs. The reactive behavior is synthesized in a two-step
process:
Implement and optimize the desired behavior in a
high-level, processor-independent representation of the decision process
similar to a control/data flow graph.
Translate the control/data flow graph into portable C code
and use any available compiler to implement and optimize it in a
specific, micro-controller-dependent instruction set.
A timing estimator quickly analyzes the program and reports
code size and speed characteristics. The algorithm uses a formula, with
parameters obtained from benchmark programs, to compute the delay of
each node in the control/data flow graph for various micro-controller
architectures (characterization data for MIPS R3000 and Motorola 68HC11
and 68332 are already available). The precision of the estimator, with
respect to true cycle counting, is currently on the order of plus or
minus 20 percent.
The estimator allows one to obtain accurate estimates of
program execution times for any characterized target processor, by first
appending to each statement in the C code generated from the
control/data flow graph instructions that accumulate clock cycles, then
compiling and execute the software on the host workstation. The same
method is used to synchronize hardware and software blocks within the
PTOLEMY-based co-simulation environment.
2.Real-time Operating System. An application-specific OS,
consisting of a scheduler (e.g. Rate-Monotonic and Deadline-Monotonic)
and I/O drivers, is generated for each partitioned design.
7.Interfacing Implementation Domains
Interfaces between different implementation domains
(hardware-software) are automatically synthesized within POLIS. These
interfaces come in the form of cooperating circuits and software
procedures (I/O drivers) embedded in the synthesized implementation.
Communication can be through I/O ports available on the
micro-controller, or general memory mapped I/O.
RELEASE NOTES 0.2
-----------------
Version 0.2 December 2, 1996
Main changes from version 0.1 (for more information, look at the
relevant
sections iof the User's Manual):
- restructured the processor resource library; moved modeling files from
polis_lib/os to polis_lib/ptl and peripheral programming files to
polis_lib/sw
- replaced "is_SW" implementation attribute in ptolemy simulation
with "implem" (string with values HW, SW, BEHAV)
- added debugging feature to ptolemy simulation (-g option to
write_pl and debug parameter of stars)
- added I/O port hand-customization capability to gen_os command
- added some features to ease handling of data flow components
(await tick works in esterel, CFSMs can wait on a SET of events or
single events)
- standard Makefile in project directories now accepts "make help"
Main bug fixes (see CHANGES for more details):
- several problems in peripheral programming library and interrupt
handling component of RTOS have been fixed
- decoding at the HW side of HW/SW interface now is correct
- read_library now works correctly
- VHDL files generated by the blif2vst and sg_to_vhdl commands are
syntactically correct
Article: 4739I would like to use a serial EEPROM to configure a XILINX fpga. ( Master Serial Mode ), so I can have the possibility of re-writing the configuration data in the field. Has anyone had any success finding/using a compatible serial eeprom ? Any comments/suggestions welcome! Steve Sutherland M4COM Ltd. QED center Treforest Est. CF37 5YR UK scs@m4com.demon.co.ukArticle: 4740
Steve Sutherland wrote: > > I would like to use a serial EEPROM to configure a XILINX fpga. ( > Master Serial Mode ), so I can have the possibility of re-writing the > configuration data in the field. > > Has anyone had any success finding/using a compatible serial eeprom > ? See Atmel @ http://www.atmel.com/ Regards, ScottArticle: 4741
(Francais suivra)
Thank you for taking the time to answer this Poll.
Please send your replies via e-mail.
Your e-mail addresses will not be used for any other mean except the
reception of your reply, nor will they be communicated to any entity.
Please specify the Newsgroup you are replying from.
-------------------------------------------------------------------------
Q1: Did you ever encounter the problem of having to communicate your
NEW e-mail address because you changed your Internet Service Provider
(ISP)?
A1: 1. YES.
2. NO.
-------------------------------------------------------------------------
Q2: Are you planning to change your ISP in the coming futur?
A2: 1. No.
2. In the coming month.
3. In the coming 6 months.
4. In a year.
5. Other (please specify).
-------------------------------------------------------------------------
Thank you for your time.
Claude Klimos
klic@odyssee.net
========================================
========================================
== F R A N C A I S ==
========================================
========================================
Merci de prendre le temps de repondre a ce sondage.
Veuillez envoyer vos reponses par courrier electronique.
Votre adresse electronique ne sera utilisee pour aucune autre raison
que la reception de votre reponse, et ne sera communiquee a aucune
autre entite.
Veuillez specifier le Newsgroup duquel vous repondez.
Q1: Avez-vous deja eu le probleme d'avoir a re-communiquer votre
NOUVELLE adresse electronique parce que vous avez changer de
Fournisseur de Services Internet (FSI)?
R1: 1. OUI.
2. NON.
-------------------------------------------------------------------------
Q2: Est-ce que vous planifiez changer de FSI dans le futur?
R2: 1. Non.
2. Dans un mois.
3. Dans 6 mois.
4. Dans un an.
5. Autre (specifiez s'il vouz plais).
-------------------------------------------------------------------------
Merci pour votre temps.
Claude Klimos
klic@odyssee.net
Article: 4742I have been programming SGS GALS 16V8 for a long time using my old GAL STARTER KIT. Now I need programming a PALCE16V8 from AMD but it refuses. Does anybody know why? Many thanx. Francesco Iovine fj@iol.itArticle: 4743
Kayvon Irani <kirani@cinenet.net> wrote:
>Just wondering if anyone out there has first hand experience or cares to comment
>on the use of ASICs and FPGAs in safety critical applications such as in
>passanger airplanes. Are the FPGAs more prone to failure by their virtue of
>being "programmable" and because they have unused dangling gates on the silicon?
>Any one used any particular FPGAs on FAA certified equipment?
Kayvon, I can tell you that the medical electronics community tends to frown
on FPGAs for reliability issues. I was once consulting on a project that
had a problem that could have been easily fixed with an Altera based
design and when I suggested it they burst out laughing. I'm not exactly
sure of the details, but the jist of it was that they'd be open to
all sorts of liability if they used any part not on the "approved" list.
And, apparently, there's a HELL of a lot of red tape involved with getting
new parts on the "approved" list. It created kind of an odd design
environment where the engineers knew of better solutions but were forced
to use only the "safe" approaches (very challenging in it's own way.)
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 4599 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Article: 4744Engineering positions at Alex Computer Systems Inc. Founded in 1988, Alex Informatics has grown into a strong and profitable organization, with a turnover of $35M and offices in Montreal, Canada; Ithaca, NY; and Annecy-le-Vieux, France. The Alex group specializes in high performance parallel and distributed computing systems. Whether it is speech recognition, virtual reality, simulation, image processing, industrial control or modeling applications, parallel processing is being realized in every industry. This new technology allows the application of today's most advanced computing systems to address the challenges of tomorrow. Based in Ithaca, NY, Alex USA is responsible for developing solutions for high-performance embedded applications, such as industrial and medical imaging, sonar, radar, and communications. We recently launched a range of innovative software and hardware products based on the Analog Devices SHARC DSP. Alex Computer Systems Inc. is looking to recruit talented individuals to work in the following areas: * Application engineers: working with customers both before and after a sale, giving technical support, and developing custom applications. Good presentation skills, a broad technical & scientific background, and ability to program in C are required. * Software engineers with an expert knowledge of C and C++, and experience of any of the following: * GUI development under Windows 95 or NT * Real-time or embedded systems * Parallel or distributed processing * Digital signal processing (DSP) * Low-level programming of VME, PCI or SCSI bus devices * UNIX or Windows device drivers * Hardware/firmware engineers with experience of designing high speed logic in FPGAs or ASICs. Low level software programming in C is a requirement for this position. * Technical author with experience of writing end-user documentation for complex computer products. Some experience of computer hardware or software design is required. Please vist our web-site at http://www.Alexusa.com. Please send resumes to: Richard Stephens Alex Computer Systems, Inc. 204 Babcock Hall 118 Prospect St. Ithaca, NY 14850 Tel: (607) 277-0678 Fax: (607) 277-0682 Email: richard@alexusa.comArticle: 4745
Some fifo's are built with single port memories. They have read and write pointers, and some type of arbiter to chose whether to do a read or write. They are recognizeable by having "wait" lines as well as the normal set of lines (output-available, input-ready). These can usually only be used reliably in fully synchronous systems, with both read and write sides using the same clock signal. This is because the vendors STUPIDLY do not include metastability information about their arbiter, to allow the designer to decide what they are willing to tollerate in terms of fifo failures. Some fifo's are built with dual port memories, also with read and write pointers. These fifo's do not need an arbiter, but the flag logic can still go metastable or generate glitches, if the input and output are in different clock domains. Tragically, this behaviour is not characterized, and so can cause problems for the unsuspecting designer. Some fifo's are built out of an array of registers, with each register having a validity flag (i.e. the register has valid data in it). These registers are cascaded together (sort of like a shift register), and they autonomously move data from one register to the next, if the current register has valid data and the next does not. the data therefore ripples through the array. All this logic is self clocking. The output basically looks at the last registers validity flag, and the input uses the first registers validity flag. If designed right, this type of fifo does not have metastability issues, unless it includes additional status flags. The set of validity flags, and their control logic is what you were asking about: "the token chain". Philip Freidin. In article <587rq2$l96@serv.hinet.net> flxchen@smtp.dlink.com.tw (Felix K.C. CHEN) writes: >Dear Friends, > >I read the terminology "token chain" in an article, but >I do not know waht it is? That article is about the >FIFO control mechanism. > >Could anyone give me a reference or explanation? > >Best wishes, > >Felix K.C. CHENArticle: 4746
Kayvon Irani wrote: > > Hi everyone: > > Just wondering if anyone out there has first hand experience or cares to comment > on the use of ASICs and FPGAs in safety critical applications such as in > passanger airplanes. Interesting question, which I'll comment. I saw recently (read between now and the airplane crash near NY last summer) a report on TV about black-boxes in airplanes. They were showing how they open them, how they read them etc. As they were opening a box, I saw a big XILINX chip on a single board with a flat cable going to the rest of the box. It seemed to be a hardwired one as there was no PROM of XCHECKER cable, but maybe it got its load from somewhere else? So I guess they don't fear putting them in critical apps. Martin -- | Martin d'Anjou | tel: (613) 765-3058 | | Nortel | fax: (613) 763-9535 | | P.O. Box 3511, Station C | email: mdanjou@nortel.ca | | Ottawa, Ontario, CANADA K1Y 4H7| My opinions, not Nortel's | | http://www.nortel.com/ | Mes opinions, pas celles de Nortel |Article: 4747
CALL FOR PAPERS Fourth International Workshop on Computer Architecture for Machine Perception (CAMP Œ97) October 20 - 22, Boston, Massachusetts, USA Sponsored by IEEE Computer Society, PAMI, TCCA, TCPP In Cooperation with ACM SIGARCH CONFERENCE GOALS CAMP '97 is the fourth in a series of workshops initiated with CAMP '91 in Paris and followed by CAMP '93 in New Orleans and CAMP '95 in Como Italy. The CAMP workshops represent a continuation of the very successful IEEE CAPAMI (Computer Architectures for Pattern Analysis and Machine Intelligence) workshops held during the 1970's and 1980's. The purpose of these meetings is to bring together researchers who seek to improve the performance of machine perception systems through cutting edge hardware enhancements or a combination of specialized hardware and software. TOPICS The following topics are suggested; however other topics are also welcome. Architectures for image understanding, sound recognition, and other senses Signal and image processing architectures Configurable and FPGA-based perception architectures Parallel architectures and algorithms for machine perception Coprocessors and Instruction Set Architecture extensions Smart sensors and sensor fusion Inference engines and machine intelligence architectures Rule-based systems and knowledge-based machines VLSI perception systems Embedded use of perception systems Architectural performance evaluation Distributed processing for perception systems Languages, software environments and programming tools Neural network and genetic algorithm applications in machine perception Vision and multisensor perception SUBMISSION OF PAPERS Four copies of an extended abstract (12 point type, double-spaced, not exceeding 10 pages) should be submitted to the Conference Chair at the address above. Abstracts should be received by April 15, 1997. Authors will be notified of acceptance/rejection by July 1, 1997. Accepted manuscripts will be due by August 1, 1997. WORKSHOP ENVIRONMENT A city rich in history and culture, Boston is one of the most popular visitor destinations in the world. Through its role as an international center for education, high technology, finance, architecture and medicine, Boston maintains its reputation as a world-class city. Attractions include: the Boston Common, Fenway Ballpark, the Museum of Fine Arts, the Museum of Science, and the New England Aquarium, as well as numerous historical sites. Many visitors come during October simply to view the area's beautiful fall foliage. The conference will take place at the Royal Sonesta Hotel. Boston's Logan Airport is serviced by nearly all domestic and international airlines. CAMP '97 ON LINE Information about CAMP '97 is accessible via the world wide web at http://www.cs.umass.edu/~camp97Article: 4748
kardos@mail.matav.hu wrote: : Thanx for the answers ! : Of course, the chip is in the PADS dongle. We bought three of them, and I was wondering : how they work, so I opened them. I saw the serial EEPROM, the HC00, and this chip, and I thought : that the key is too easy to duplicate, and that PADS Software is stupid because they applied : a so primitive key. But now I see from your answers, I wasn't right. : Besides, if I would want to crack the PADS, I would buy a 50$ SW packet from a certain Canadian : firm, which removes the protection from the .EXE files. The important part of your statement is that PADS Software is stupid. Brain dead is another description that comes to mind. It is the worst, most annoying PCB layout tool I have ever used. It is very obvious that the software was developed by people with only half an idea of what is required in real world board layout. We even found that we had to go back to the original PADS Perform, because their new POWER PCB is slow and buggy. Bob.Article: 4749
John Cooley wrote:
>
> Kayvon Irani <kirani@cinenet.net> wrote:
> >Just wondering if anyone out there has first hand experience or cares to comment
> >on the use of ASICs and FPGAs in safety critical applications such as in
> >passanger airplanes. Are the FPGAs more prone to failure by their virtue of
> >being "programmable" and because they have unused dangling gates on the silicon?
> >Any one used any particular FPGAs on FAA certified equipment?
>
> Kayvon, I can tell you that the medical electronics community tends to frown
> on FPGAs for reliability issues. I was once consulting on a project that
> had a problem that could have been easily fixed with an Altera based
> design and when I suggested it they burst out laughing. I'm not exactly
> sure of the details, but the jist of it was that they'd be open to
> all sorts of liability if they used any part not on the "approved" list.
> And, apparently, there's a HELL of a lot of red tape involved with getting
> new parts on the "approved" list. It created kind of an odd design
> environment where the engineers knew of better solutions but were forced
> to use only the "safe" approaches (very challenging in it's own way.)
>
> - John Cooley
> Part Time EDA Consumer Advocate
> Full Time ASIC, FPGA & EDA Design Consultant
>
I had heard that the medical instrument industry is a tough one...
However, I KNOW that after one of the airline disasters of recent years,
CNN showed a shot of an FAA "Black-Box" flight recorder with a XILINX
QFP mounted conspicuously on the inside of the removable end panel.
Makes ME wonder...
I have had 5-6 years working with the XILINX FPGA family, and my
experience is that if the chip powers-up properly, it will work properly
(remember that these devices are SRAM-based, and need to be "programmed"
each time power is applied).
The next question is obviously "how often do they not power-up
correctly?" That depends almost entirely on the quality of the board
design. However, even a good board design will have a higher rate of
failure at power-up than "hard-wired" logic.
========================================================================
Steven E. Raasch Graduate Student Research Assistant
University of Michigan, Ann Arbor
mailto:sraasch@umich.edu Office: EECS 2001B
http://www.eecs.umich.edu/~sraasch (313) 764-9363
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