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
I just came across this: http://www.starbridgesystems.com/release.html Any thoughts? -Arrigo -- Arrigo Benedetti o e-mail: arrigo@vision.caltech.edu Caltech, MS 136-93 < > phone: (626) 395-3695 Pasadena, CA 91125 / \ fax: (626) 795-8649Article: 14676
Arrigo Benedetti <arrigo@vision.caltech.edu> wrote: > I just came across this: > http://www.starbridgesystems.com/release.html > Any thoughts? Wow! A true advance in Hyper-BuzzWord-Marketing. The web pages are full of statements like "Superspecificity is also achieved by SBS through advanced artificial intelligence algorithms and techniques such as recursion, cellular autonoma, heuristics and genetic algorithms, which are incorporated into a single system which naturally selects the most efficient library element for achieving maximum specificity." It appears to be an array of 280 Xilinx chips and some software to program them. I doubt that anything that fits that description is worth $26 million. Maybe there's something there, but when they use blatently misleading numbers to compare themselves to other machines, it's clear that whatever is there is under big piles of doodoo. A machine that does 3.8 Trillion 16-bit integer additions per second is just not the same as a machine that does 3.9 Trillion floating point operations per second. Apparently, they get their number from the following formula: (20MHz clock) * (5472 CLB/chip) * (280 chips) / (8 CLB/Adder) = 3.83e+12 Adds/Sec Leaving no room for control circuitry. It would certainly be more impressive if they had an actual application running on the system and could give some real benchmark numbers.Article: 14677
> Wow! A true advance in Hyper-BuzzWord-Marketing. The web pages are full > of statements like > ... > It appears to be an array of 280 Xilinx chips and some software to program > them. I doubt that anything that fits that description is worth $26 million. Ah, come on. Don't be so brutal! At least they didn't have Internet and Java in their announcement. :-) > Maybe there's something there, but when they use blatently misleading numbers > to compare themselves to other machines, it's clear that whatever is there is > under > big piles of doodoo. A machine that does 3.8 Trillion 16-bit integer > additions > per second is just not the same as a machine that does 3.9 Trillion floating > point But we showed over and over again that FP can't be done efficiently in FPGAs and thus the numbers wouldn't be as impressive (but less bogus :-). I wonder if Xilinx just dumped their remaining XC6216 on them... StefanArticle: 14678
> Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
> Author: Austin Franklin <austin@dark9room.com>
> Unless you either type REALLY fast, and make NO mistakes in your HDL, and
> the tools behave right on (for the hour) AND the person you are competing
> against with schematics draws them with stone and chisel, drinks heavily,
> and bashes his/her thumb with the hammer, this just isn't how it's gonna
> play out. And your 'cost reduction' can take from a lot more time to
> never.
Sigh. A bit of verbal overkill, don't you think? I think I type in
VHDL faster than I draw schematics, I make mistakes in both, both tool
sets have gacks, I have never tried a stone and chisel (hmm, should
I??), I rarely drink more than a beer a day (hmm, should I??)... And
bashing my thumb with a hammer is something I plan on avoiding in the
future, having sometimes not avoided it in the past.
> I'm not talking about using 30 CLBs....that's hardly a real world test, and
> if, without much effort, an HDL can't keep up with schematic in a 30 CLB
> test case, that would call for immediate expulsion.
I agree that a 30 CLB circuit isn't a real world test. However,
circuits of that size is where the HDL tools should be the easiest to
beat. An experienced human can easily see the absolute best way to
solve such a problem. The tool isn't always going to find that exact
solution, but it should find a fairly good solution. For a large enough
problem, the human will be swamped with complexity and will fail to
produce a good solution in a realistic time, and the tool should still
provide a fairly good solution.
> How many times have you actually done this and seen the results you tout?
> In the dozen or more cases I have seen (and fixed), your belief just
> doesn't hold up.
I'm not the least bit surprised that you find clients with problems with
HDL FPGA design problems. The learning curve for FPGAs is still fairly
steep, and there is yet another steep learning curve for the HDL tools.
I'm quite sure you could fix their problems with some design conversion
to schematics, a little dab of reality and a kilo of floorplanning.
That's good, but that isn't the only way to solve such problems.
I've done about 6 FPGA designs with schematics (using ABEL for state
machines), and 5 FPGA designs with VHDL. My focus, as I hope I pointed
out, has been more on speed than on size or part cost. While VHDL tools
have lots of room for improvement (a short list follows), I like VHDL
better. I do think that I do a better job with VHDL than with
schematics.
My Major Wish list:
-----------------------------------------------
1) A high level floorplanner.
What I would like to do is to take a labeled statement (a process,
signal
assignment or instantiated lower level block) and put it into a
physical
form. The sorts of physical forms needed are both absolute and
relative,
and would range from the very general to the very specific, and both
technology dependent and technology independent forms would be
desired.
2) A better way of doing physical VHDL.
While vendor independence is nice, when pushing parts to the limit
one
must lose that to gain access to all the special features of a
part. It
would be ok if the silicon vendors would just set up and document a
full
set of physical VHDL "black boxes" for all of their logic elements.
3) Quality of Results.
It's not great yet, guys and gals of the tools world. It can get
better,
it should get better, it needs to get better.
--
Phil Hays
"Irritatingly, science claims to set limits on what
we can do, even in principle." Carl Sagan
Article: 14679
Hi:
I am designing an ASIC, there is question about I/O cell selection.
the vendor they provide Output pin driver cells include 0.1mA
2mA, 6mA, 8mA,12mA,24mA,
if the output pin it fan out to 2 general EPROM input pin, can I use
0.1mA
cell?
if the output pin that connected with 3 TTL input pin, which is the best
choice?
please give me some suggestions , thanks a lot
John
Article: 14680Hi, I have some troubles to implement a parity generation/ checking mechanism of a 36bit field for an Altera 10KE device at 66 MHz. When I describe the logic (via VHDL as cascaded exors) a huge amount of logic for that function(tpd for the critical path ~17ns) is generated (my synthesis tool implements the xor function with 3 or 4 ATBLs!!). Any suggestion or hints to solve that problem? I appreciate any input and Thank you advance ThomasArticle: 14681
Hi folks, Does anyone know if there are resources available for designing a PCMCIA interface in an ALTERA PLD ? Due to power consumtion restrictions also info about implementing such an interface in a Philips Cool Runner would help. -- -TomArticle: 14682
The person (Rune Baeverud) who is / was responsible for that page has left the company and is not working on that page anymore. *** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***Article: 14683
husby@fnal.gov (Don Husby) writes:
> Maybe there's something there, but when they use blatently misleading numbers
> to compare themselves to other machines, it's clear that whatever is there is under
> big piles of doodoo. A machine that does 3.8 Trillion 16-bit integer additions
> per second is just not the same as a machine that does 3.9 Trillion floating point
> operations per second.
Reality check: how do they get 50ns max. latency on 8-100GB of memory
(SRAM? the power consumption would indicate otherwise). Even so, the
machine needs a bandwith of 20TB/s to sustain 3.8T 16bit adds per
second (what's with those tiny disk and memory sizes?). When you give
each of the 280 Xilinx chips 4GB/s to play with (and that would be
spectacular) you're still short of that figure by a factor of 20.
Also check out:
http://www.acm.uiuc.edu/sigarch/rc/interview.html
http://www.ednmag.com/reg/1996/032896/07DFCOV.cfm
http://www.herring.com/mag/issue37/heavy.html
metalithic.com does not seem to exist anymore, even though the domain
is still listed in the whois database.
Achim Gratz.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone: +49 351 463 - 8325
Article: 14684Does anybody have the site archived or know how to contact Rune Baeverud? Perhaps we could move the contents to the The Programmable Logic Jump Station (http://www.optimagic.com). ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- "Håkan Pettersson" wrote in message ... >The person (Rune Baeverud) who is / was responsible for >that page has left the company and is not working on >that page anymore. > > > >*** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***Article: 14685
Sergio A. Cuenca Asensi wrote:
> Take a look at Xilinx programmable logic data book. In the paper
> "Configuration issues: Power-up, volatility,Security , Battery Back-up"
> they say that Xilinx keeps the interpretation of the bitstream closely
> guarded secret and it is virtually impossible to interpret the bitstream
> in order to undestand the design or make modifications on it.
I've read this too, but I question it greatly. I question it for several
reasons:
1. I doubt that the "FPGA based supercomputer"
(http://www.starbridgesystems.com/release.html)
uses Xilinx place/route/bitstream software. For a
computer like that to be remotely useful, they would need
something more integrated into their development tools.
2. Someone (I forget who) used a genetic algorithm to "program"
a Xilinx FPGA to detect two tones. This program basically
randomly generated xilinx bitstreams in a "genetic
permutation" way. But, before actually programming the
xilinx, the bitstream was checked for faults that would
have fried the chip (bus contention, etc.). So, this guy
would have had to know what the bitstream file did.
3. Xilinx has a "warning" on their web site about companies
that are doing some "rescreening" of their chips. Basically
they are retesting and sorting the FPGA's to upgrade them
from Commercial to Industrial or Military temperature/voltage
range. This warning didn't outright say it, but it implied
that these guys are playing around with the bitstream files.
While, this isn't hard evidence, it passes at least a
casual definition of "reasonable doubt", IMHO.
If the original poster really wants to protect his design,
I'd recommend using an antifuse based FPGA (I.E., Quicklogic)
or a CPLD. Once programed, it would be very difficult to
read back the program from the chip. Most of the time, you'd
have to open the chip up and inspect it visually-- way beyond
what almost everyone are capable of.
David Kessner
davidk@peakaudio.com
Article: 14686
John Huang wrote:
> Hi:
> I am designing an ASIC, there is question about I/O cell selection.
> the vendor they provide Output pin driver cells include 0.1mA
> 2mA, 6mA, 8mA,12mA,24mA,
> if the output pin it fan out to 2 general EPROM input pin, can I use
> 0.1mA
> cell?
> if the output pin that connected with 3 TTL input pin, which is the best
> choice?
>
> please give me some suggestions , thanks a lot
>
> John
John there is more to the selection of IO drive strength than
just what the chip has to drive in the final system. I just
finished a chip that has a very light system load, a few cmos
gates BUT the tester load at the ASIC foundry is 70 pf. I wanted
the tester to run at system speed which required me to increase
the drive strength of my buffers to drive the tester load. SO, consider
the tester load, and test clock rate.--
~~~ "It's not a BUG,
/o o\ / it's how I make my living"
( > )
\ ~ / Jerry English
_]*[_ FOE of Script Lords
Article: 14687Hi!, We are trying to take a schematic from Mentor and use Alliance to map it on the 4013E FPGA.First, I set up all the environment variables for Xilinx(Alliance tools) and then for Mentor.Then I use PLD_men2edif tool in Mentor to convert schematic to an edif file.Then I go to the Alliance tool, specify the edif file as an input.When I press the implement button,I always get the error:Error basnu 93: can't expand the nand2 component.My design has for nand2 components, and I get the same error message for all of them.I have tried to change the variables in my initialization files(which have paths for libraries lin MGC_GENLIB etc.)but have had no success.Has anyone done this successfully?If yes, can you please help us out?Thanks in advance. Mayank Gupta Northwestern University.Article: 14688
>>>>>>>> Job posting deleted by archive ownerArticle: 14689
Hallo,
ich habe hier folgendes vor:
Auf einer Schaltung ist ein mittlerweile recht komplex gefuellter FPGA
(mehrere Finite State Machines, Addierer,...) eingesetzt, den ich nun
pruefen muss.
Jedes Eingangssignal und alle Ausgaenge ueber einen Adapter zum Aufzeichnen
zu kontaktieren scheidet aus, jedoch hat der FPGA (ALTERA EPF6016) ja eine
JTAG Schnittstelle. Leider habe ich bisher noch keine Erfahrungen mit dieser
Schnittstelle, daher ein paar Fragen:
* Lt. ALTERA ann ich ueber die JTAG-IF alle Pinpegel seriell in einen
Rechner eintakten und somit quasi jeden Pin "messen". Ferner kann ich auch
Pegel als Eingangswert vorgeben. Kann ich nun auch interne Signale anzeigen
lassen, bspw. in welchem State die FSM jetzt gerade ist ?
* Gibt es spezielle Software, die ueber die JTAG Schnittstelle die
Auswertung macht, wenn ja wo und quanta kosta ?
* Wie werden Tests programmiert (evtl. auch in VHDL ?)
* Sind mit dieser Methode schnelle, automatisierte Tests moeglich
(Fertigungspruefung)
Besten Dank fuer alle Antworten,
--
Tschuessing, Carlhermann
ICQ #15820806
Mitglied im Club SIMCA Deutschland
--
***** ***** ***************************
* * * *
* ***** * Live long and prosper *
* * * *
***** ***** ***************************
Article: 14690Neocad reverse engineered the Xilinx bitstream completely, and reportedly with no help from Xilinx. Xilinx then bought them :) The obvious way to do it, as with any substitution cipher, is to change the plaintext and see which parts of the ciphertext change. IOW do a CLB-level design, then change one little bit of the design, and see what part of the bitstream has changed. If you can do chip probing then you can probably do it even quicker. I also think that the relationship between the bitstream and the physical layout of the die must be fairly straighforward; suggesting the contrary would imply that Xilinx deliberately routed their mux select signals criss-cross all over the chip - a huge waste of interconnections. So working out how the bitstream is made up is probably *very* straightforward for the most part, with a few little gotchas no doubt thrown in. I reckon you could make useful progress after just a few weeks at it. Looking at the price Xilinx paid for Neocad, reverse engineering the bitstream seems a relatively easy way to earn a few tens of millions of $ because Xilinx will then buy your company. (Just a joke). -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 14691
while we're talking about AHDL vs. VHDL: does anybody know about any tools to work on AHDL files more efficiently? like - source browsing tools or extensions to those (e.g. source navigator) - tags file generators (ctags/etags dont work on AHDL) - emacs ahdl mode i like to trace signals thru ahdl files more easily than just search for their names in emacs... any help is appreciated endricArticle: 14692
>>>>>>>> Job posting deleted by archive ownerArticle: 14693
John Huang wrote: > > Hi: > I am designing an ASIC, there is question about I/O cell selection. > the vendor they provide Output pin driver cells include 0.1mA > 2mA, 6mA, 8mA,12mA,24mA, > if the output pin it fan out to 2 general EPROM input pin, can I use > 0.1mA > cell? > if the output pin that connected with 3 TTL input pin, which is the best > choice? > > please give me some suggestions , thanks a lot > > John You will need to know input current for the EPROM and the TTL loads. Most TTL inputs are now actually CMOS and the input current will generally be < 10 uamps, but maybe not so you should check the data sheet for the max spec at temperature. Real TTL, weak pull-ups and pull-downs can load a 100 uamp driver so be careful. Then you need to consider the load and PCB capacitance and delay required. A 100 uamp driver will take 1,500 ns to charge a 50 pf load to 3V. (v=it/c; t=vc/i; 3V * 50 pf / 100 uA). My guess is the 2 mA driver is the way to go. Best Wishes, BradArticle: 14694
Hello Steven, Hello All, I'm still with you :) Actually - I left my old company to start working with Xilinx. It's obvious that I cannot actively support Altera anymore. It is still my opinion that the FreeCore Library belongs to the public domain, and I'm trying to figure out a way to keep it on the web. Regards, Rune Baeverrud Steven K. Knapp wrote in message <79utuc$5sb@sjx-ixn5.ix.netcom.com>... >Does anybody have the site archived or know how to contact Rune Baeverud? >Perhaps we could move the contents to the The Programmable Logic Jump >Station (http://www.optimagic.com). >Article: 14695
Hello,
Software: Xilinx Alliance v1.5i on Sun Solaris
Hardware: Xilinx XC4036XLA FPGA
I'm using Xilinx logiblox ROM's in a design and wonder if
it is possible to reconfigure the ROM contents AFTER successfully
routing the design.
e.g. changing the tap weights in a FIR filter implemented
using ROMs.
The routing phase takes a long time so I'd like to avoid rerouting
if possible.
Thanks,
Walt
Article: 14696Phil Hays wrote: > Sigh. A bit of verbal overkill, don't you think? ... Agreed. > I agree that a 30 CLB circuit isn't a real world test. However, > circuits of that size is where the HDL tools should be the easiest to > beat. An experienced human can easily see the absolute best way to > solve such a problem. The tool isn't always going to find that exact > solution, but it should find a fairly good solution. For a large enough > problem, the human will be swamped with complexity and will fail to > produce a good solution in a realistic time, and the tool should still > provide a fairly good solution. For many data path applications, the design does break down quickly into a collection of small circuits, mostly less than 30 CLBs. In Signal Processing, that collection is really a fairly small set, which fosters circuit reuse. As you say here, an experienced human can easily see the optimum solution, and too many times the HDL tools can't find it without a couple of good swift kicks, sweet talking, hand-holding and a couple of sweet-nothings or four letter words uttered. This is why I still advocate schematic entry for these types of problems. It would be really nice if it were a little easier to tell the HDLs exactly what you want constructed in cases like these. I've stated my schematic methodology here before (using a library of explicitly implemented and placed one and two bit objects to construct arbirtrary width data path elements) so I won't repeat it. For random logic, HDLs make alot of sense, at least when you are not trying to push the performance or density of the part. Still, a properly done hierarchical design should fairly simple circuits at its lowest level, certainly not more than that 30 CLBs you talked of. Using hierarchy and top-down design even the most complex circuits become a collection of simple circuits. The obvious exceptions are big decodes and large state-machines: these are also obvious candidates for an HDL entry. To be fair, I see as many clients with schematic FPGA design problems as I do with HDL design problems. Typically the problem is a lack of understanding of the device architecture (I've even seen schematics using 74xxx equivalent circuits). A common schematic problem is little or no use of hierarchy, something that is difficult to do in an HDL (good thing too!). Coding style is a common HDL problem. Floorplanning is still alot easier to do in schematics, and is with certain tools impossible in HDLs. For someone that wants to stay ignorant of the device architecture (which I think there is no excuse for), HDLs provide a better shot of making the goal. Still, if you insist on being ignorant, don't set the goal too high. The trick there is to use lots of registers to break up the logic. > I'm not the least bit surprised that you find clients with problems with > HDL FPGA design problems. The learning curve for FPGAs is still fairly > steep, and there is yet another steep learning curve for the HDL tools. > I'm quite sure you could fix their problems with some design conversion > to schematics, a little dab of reality and a kilo of floorplanning. > That's good, but that isn't the only way to solve such problems. > > I've done about 6 FPGA designs with schematics (using ABEL for state > machines), and 5 FPGA designs with VHDL. My focus, as I hope I pointed > out, has been more on speed than on size or part cost. While VHDL tools > have lots of room for improvement (a short list follows), I like VHDL > better. I do think that I do a better job with VHDL than with > schematics. > > My Major Wish list: > ----------------------------------------------- > 1) A high level floorplanner. > What I would like to do is to take a labeled statement (a process, > signal > assignment or instantiated lower level block) and put it into a > physical > form. The sorts of physical forms needed are both absolute and > relative, > and would range from the very general to the very specific, and both > technology dependent and technology independent forms would be > desired. > > 2) A better way of doing physical VHDL. > While vendor independence is nice, when pushing parts to the limit > one > must lose that to gain access to all the special features of a > part. It > would be ok if the silicon vendors would just set up and document a > full > set of physical VHDL "black boxes" for all of their logic elements. > > 3) Quality of Results. > It's not great yet, guys and gals of the tools world. It can get > better, > it should get better, it needs to get better. > > -- > Phil Hays > "Irritatingly, science claims to set limits on what > we can do, even in principle." Carl Sagan -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14697
THE FIRST NASA/DoD WORKSHOP ON EVOLVABLE HARDWARE
July 19 - 21, 1999
Jet Propulsion Laboratory
California Institute of Technology
Pasadena, California, USA
Sponsored by:
National Aeronautics and Space Administration (NASA)
Defense Advanced Research Projects Agency (DARPA)
Ballistic Missile Defense Organization (BMDO)
Hosted by:
Center for Integrated Space Microsystems (CISM), JPL
Center for Space Microelectronics Technology (CSMT), JPL
NASA Technology Program (NTP), JPL
The First NASA/DoD Workshop on Evolvable Hardware (EH'99) will be held at
the Jet Propulsion Laboratory in Pasadena, California. The purpose of this
workshop is to bring together leading researchers from the evolvable
hardware community, representatives of the programmable/reconfigurable
hardware community, technology developers, and end-users from the aerospace
community.
The emerging field of Evolvable Hardware is expected to have major impact
on deployable systems for space missions and defense applications that need
to survive and perform at optimal functionality during long duration in
unknown, harsh and/or changing environments. Examples of such applications
include outer solar system exploration, missions to comets and planets with
severe environmental conditions, long lasting space-borne surveillance
platforms, defensive counter-measures, long-term nuclear waste and other
hazardous environment monitoring and control. Evolvable hardware is also
expected to greatly enrich the area of commercial applications in which
adaptive information processing is needed; such applications range from
human-oriented hardware interfaces and internet adaptive hardware to
automotive applications.
The purpose of the workshop is to provide a forum for discussion on the
potential role of evolvable hardware in real-world applications, in
particular those related to space. The Workshop attendees will have the
opportunity to discuss the fundamental issues and state-of-the art of
evolvable hardware technology, plans for development of future devices and
hardware systems suitable for evolution, and needs related to space
applications. The outcome of this meeting is expected to be a technology
development roadmap that would lead to deployable evolvable hardware.
Topics to be covered include, but are not limited to:
- Evolutionary hardware design (including design of mechanical
systems,electronic circuits synthesis)
- Co-evolution of hybrid systems (including hybrids of wetwarre,
chemical, mechanical, and electronic components, etc.)
- Evolving hardware systems
- Intrinsic, and on-line evolution
- Hardware/software co-evolution
- Self-repairing hardware
- Embryonic hardware
- Morphogenesis
- Tools supporting evolvable hardware
- Novel devices and hardware platforms suitable for evolution
- Adaptive hardware, adaptive computing
- Adaptive flight hardware
- Real-world applications of evolvable hardware
SUBMISSION OF PAPERS
Prospective authors are invited to submit four copies of their paper (not
exceeding 10 pages) to the address below. The paper should be submitted in
single-spaced, 10 point type on a 8.5" X 11" or equivalent paper with 1"
margins on all sides. Each submission should contain the following items:
(1) title of paper, (2) author name(s), (3) first author physical address,
(4) first author e-mail address, (5) first author phone number, (6) a
maximum 200 words abstract. Accepted papers will be published in the
workshop proceedings; details on the publication including the style for
the camera-ready paper will be posted later at the workshop web site
(http://cism.jpl.nasa.gov/events/nasa_eh).
The papers should be sent to:
Adrian Stoica
EH'99 Workshop
Jet Propulsion Laboratory, MS 303-300
4800 Oak Grove Drive
Pasadena, CA 91109, USA
IMPORTANT DATES
Submission deadline: March 1, 1999
Author notification: April 2, 1999
Camera ready manuscript deadline: May 1, 1999
Workshop: July 19-21, 1999
Honorary Chair: John R. Koza, Stanford University
Chair: Adrian Stoica, Jet Propulsion Laboratory
Co-Chairs: Didier Keymeulen, Jet Propulsion Laboratory
Electrotechnical Laboratory
Jason Lohn, NASA Ames Research Center
Program Committee:
Leon Alkalai, Jet Propulsion Laboratory (USA)
Forrest H. Bennett III, Genetic Programming, Inc. (USA)
Gregory Cain, Victoria University (Australia)
Silvano P. Colombano, NASA Ames Research Center (USA)
Hugo de Garis, Advanced Telecommunication Research Lab (Japan)
Stuart J. Flockton, University of London (UK)
Terry Fogarty, Napier University (UK)
David B. Fogel, Natural Selection, Inc. (USA)
Inman Harvey, University of Sussex (UK)
Hitoshi Hemmi, NTT Communication Science Labs (Japan)
Tetsuya Higuchi, Electrotechnical Laboratory (Japan)
Lorenz Huelsbergen, Bell Labs, Lucent Technologies (USA)
Alan Hunsberger, National Security Agency (USA)
Rich Katz, NASA Goddard Space Fligth Center (USA)
Daniel Mange, Swiss Federal Institute of Technology (Switzerland)
Pierre Marchal, Centre Suisse d'Electronique et de Microtechnique SA
(Switzerland)
Julian Miller, Napier University (UK)
Eric Mjolsness, Jet Propulsion Laboratory (USA)
Jose Munoz, Defense Advanced Research Projects Agency (USA)
Masahiro Murakawa, University of Tokyo (Japan)
Edward Rietman, Bell Labs, Lucent Technologies (USA)
Justinian Rosca, Siemens Corporate Research (USA)
Mehrdad Salami, Victoria University (Australia)
Eduardo Sanchez, Swiss Federal Institute of Technology (Switzerland)
Moshe Sipper, Swiss Federal Institute of Technology (Switzerland)
Stephen Smith, Altera (USA),
Stephen Trimberger, Xilinx (USA)
Adrian Thompson, University of Sussex (UK)
Anil Thakoor, Jet Propulsion Laboratory (USA)
Benny Toomarian, Jet Propulsion Laboratory (USA)
R. S. Zebulum, University of Sussex (UK)
For further information please check the workshop web site or contact:
Adrian Stoica
Jet Propulsion Laboratory, MS 303-300
4800 Oak Grove Drive
Pasadena, CA 91109, USA
adrian.stoica@jpl.nasa.gov
Tel: +1 (818) 354-2190
Fax: +1 (818) 393-1545
Web: http://cism.jpl.nasa.gov/events/nasa_eh
Article: 14698Where can I look for VHDL source related with PCI?Article: 14699
Well, there are several ways to do parity in Altera. First is using the ripple form, in which each bit is XOR'd to the sum of the previous bits. Terribly slow for 36 bits unless you take advantage of the carry chain to do it (and since the carry chain is implemented as a 3-LUT, this can be done. In fact, each 3 lut takes care of two bits, so you only need 18 LE's in the chain. It is a little faster if you break the chain into 8 LE (1 LAB) segments and combine them in a single XOR (each LAB is then a 17 input XOR). Second way is to combine the sums in a tree of XORs. For this, you use the LEs as 4-LUTs, so the first layer reduces the 36 bits to 9, the second to 3 and the third to a single bit. is well suited to pipelining (pipeline it and it will synthesize the way you wanted). Third way is to use the EABs to realize 8 input XORs; arrange those in the tree. The tree of XORs, even without pipelining should get you to around 100MHz in a -3 part. This is slightly faster than using 8 LE carry chains combined in an XOR and is a little more space efficient. To get this performance, you'll want to use 5 LE's in a LAB to build a 16 input XOR. Use Cliques to keep them together. This forms the first 2 layers. Combine two 16:1 trees and a four input XOR with an additional 3 input XOR. Again use cliques to keep these in the same row. Regardless of the method used, you will want to use cliques to keep the logic in the same row. If I had to guess, you wound up with a ripple structure chaining 35 2input XORs together, probably using the carry chain. You will have to play around with your coding style to get the tree structure. Off-hand, I don't know what syntax will generate it for your particular VHDL elaborator. Thomas Zipper wrote: > Hi, > > I have some troubles to implement a parity generation/ checking > mechanism of a 36bit field for an Altera 10KE device at 66 MHz. When I > describe the logic (via VHDL as cascaded exors) a huge amount of logic > for that function(tpd for the critical path ~17ns) is generated (my > synthesis tool implements the xor function with 3 or 4 ATBLs!!). > Any suggestion or hints to solve that problem? > > I appreciate any input and > Thank you advance > > Thomas -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka
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