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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 14675

Article: 14675
Subject: Supercomputer uses 280 Xilinx FPGAs
From: Arrigo Benedetti <arrigo@vision.caltech.edu>
Date: 10 Feb 1999 09:52:52 -0800
Links: << >>  << T >>  << A >>
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-8649
Article: 14676
Subject: Re: Supercomputer uses 280 Xilinx FPGAs
From: husby@fnal.gov (Don Husby)
Date: Wed, 10 Feb 1999 19:40:15 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Supercomputer uses 280 Xilinx FPGAs
From: ludwig@pa.dec.com (Stefan Ludwig)
Date: 10 Feb 1999 20:28:39 GMT
Links: << >>  << T >>  << A >>
> 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...

Stefan

Article: 14678
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: Phil Hays <spampostmaster@sprynet.com>
Date: Wed, 10 Feb 1999 22:41:22 -0800
Links: << >>  << T >>  << A >>
> 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
Subject: Current of I/O driver
From: "John Huang" <hungi@tpts4.seed.net.tw>
Date: 11 Feb 1999 07:00:07 GMT
Links: << >>  << T >>  << A >>
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: 14680
Subject: Parity and flex10k
From: Thomas Zipper <thomas.zipper@mchp.siemens.de>
Date: Thu, 11 Feb 1999 08:32:55 +0100
Links: << >>  << T >>  << A >>
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
Article: 14681
Subject: Q: PCMCIA Interface For ALTERA
From: "Thomas Ebert" <te@wiese.de>
Date: Thu, 11 Feb 1999 09:27:41 +0100
Links: << >>  << T >>  << A >>
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.

-- 

-Tom


Article: 14682
Subject: Altera freecore library ?
From: chakanp@hotmail.com ("Hkan Pettersson")
Date: Thu, 11 Feb 1999 04:12:27 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Supercomputer uses 280 Xilinx FPGAs
From: Achim Gratz <gratz@ite.inf.tu-dresden.de>
Date: 11 Feb 1999 13:15:51 +0100
Links: << >>  << T >>  << A >>
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: 14684
Subject: Re: Altera freecore library ?
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Thu, 11 Feb 1999 07:39:15 -0800
Links: << >>  << T >>  << A >>
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).

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------

"Hkan 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
Subject: Re: Xilinx de-compiler
From: David Kessner <davidk@peakaudio.com>
Date: Thu, 11 Feb 1999 09:13:55 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Current of I/O driver
From: jerry english <jenglish@planetc.com>
Date: Thu, 11 Feb 1999 11:30:09 -0500
Links: << >>  << T >>  << A >>
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: 14687
Subject: Mentor-Alliance Interface
From: m-gupta@nwu.edu
Date: Thu, 11 Feb 1999 19:00:26 GMT
Links: << >>  << T >>  << A >>
Hi!, 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
Subject: FPGA - Ground Unit Design Engineering
From: "GOVJOBS.COM" <submitresume@govjobs.com>
Date: 11 Feb 1999 11:28:12 PST
Links: << >>  << T >>  << A >>
>>>>>>>> Job posting deleted by archive owner


Article: 14689
Subject: JTAG Test fuer FPGA
From: carlhermann.schlehaus@t-online.de (Carlhermann Schlehaus)
Date: Thu, 11 Feb 1999 21:40:08 +0100
Links: << >>  << T >>  << A >>
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: 14690
Subject: Re: Xilinx de-compiler
From: z80@ds2.com (Peter)
Date: Thu, 11 Feb 1999 20:43:14 GMT
Links: << >>  << T >>  << A >>

Neocad 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
Subject: Re: AHDL VS. VHDL
From: Endric Schubert <endric@axiscorp.com>
Date: Thu, 11 Feb 1999 13:21:10 -0800
Links: << >>  << T >>  << A >>
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

endric

Article: 14692
Subject: GOVJOBS.COM - JOB BANK - private sector opportunities in high-technologies only!
From: "GOVJOBS.COM" <submitresume@govjobs.com>
Date: 11 Feb 1999 13:29:09 PST
Links: << >>  << T >>  << A >>
>>>>>>>> Job posting deleted by archive owner


Article: 14693
Subject: Re: Current of I/O driver
From: Brad Taylor <blt@cmln.com>
Date: 11 Feb 1999 14:47:49 PST
Links: << >>  << T >>  << A >>


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,
Brad
Article: 14694
Subject: Re: Altera freecore library ?
From: "Rune Baeverrud" <fpga@iname.com>
Date: Fri, 12 Feb 1999 00:01:46 -0000
Links: << >>  << T >>  << A >>
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
Subject: reconfiguring Logiblox ROM's
From: wbax@doe.carleton.ca (Walt Bax)
Date: 12 Feb 1999 00:23:29 GMT
Links: << >>  << T >>  << A >>
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: 14696
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: Ray Andraka <randraka@ids.net>
Date: Thu, 11 Feb 1999 20:25:33 -0500
Links: << >>  << T >>  << A >>


Phil 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/~randraka


Article: 14697
Subject: 2nd CFP: THE FIRST NASA/DoD WORKSHOP ON EVOLVABLE HARDWARE
From: Jason Lohn <jlohn@removethis.ptolemy.arc.nasa.gov>
Date: Thu, 11 Feb 1999 17:26:24 -0800
Links: << >>  << T >>  << A >>
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: 14698
Subject: help to look for VHDL source related with PCI.
From: "ȯ" <jhlim@telpia.etri.re.kr>
Date: Fri, 12 Feb 1999 10:56:30 +0900
Links: << >>  << T >>  << A >>
Where can I look for VHDL source related with PCI?


Article: 14699
Subject: Re: Parity and flex10k
From: Ray Andraka <randraka@ids.net>
Date: Thu, 11 Feb 1999 21:05:10 -0500
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search