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
This is a multi-part message in MIME format.
--------------7B26476967E668C57805B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
See the attachment for a comparison of Win95 & Linux 2.0.27 on synthesis
of the same VHDL circuits.
--------------7B26476967E668C57805B
Content-Type: text/plain; charset=us-ascii; name="linux_leo.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="linux_leo.txt"
A modest comparison of Windows-95 against Linux 2.0.27
by John McCluskey, J-Squared Technologies. January 8, 1997
Email: J.McCluskey@ieee.org
This experiment started on Monday night (Jan 6), when after a phone call to
Exemplar Logic in California, they agreed to place the Linux version of
their Leonardo synthesis tool on their ftp site so I could grab it to test
it out. I spent the rest of the night (until 1 am) dialing and redialing my
ISP's modem pool, trying to latch onto a good modem that would hold the
modem carrier for more than a few minutes. After a lot of frustration, I
gave up and finished grabbing the rest of the gzipped tar file in the
morning. Finally, about 10 AM, I had succeeded in grabbing the 15 megabyte
file, gotten a license code from Exemplar, and I was ready to Rock & Roll!.
Leonardo is a VHDL/Verilog synthesis tool that compiles a source language
like VHDL or Verilog into a gate level netlist suitable for input into a
place & route tool that produces a final design ready for use. The place &
route tool might be for a CPLD (Complex Programmable Logic Device), or an
FPGA (Field Programmable Gate Array), or for a genuine ASIC (Application
Specific Integrated Circuit). Leonardo does them all, and currently runs on
HPUX, Solaris 2.5, SunOS 4.1.3, Windows 95/ WinNT, and now, LINUX! This is
a genuine industrial strength CAD tool. The graphical interface is TCL/Tk
based on ALL platforms. The user interface is extensible, since you can add
buttons or modify them by playing with the TCL scripts which generate the
GUI. Indeed, the whole synthesis process is driven by TCL scripts. I
generated a base TCL script for each test using the GUI, and then used the
script in batch mode to get my timing tests for Linux, SunOS 4.1.3, and
Win95. Regrettably, I didn't have time to test Windows NT4.0. This Linux
version of Leonardo was compiled on a Debian Linux distribution using GCC
2.72 or GCC 2.73. Note that Pentium specific optimization is NOT included
in these versions of GCC. (I think.)
The first test machine was a Sparc20 clone from Axil, dating from June 1995,
which has 128 Mb of RAM, and a 90 MHz Ross Hypersparc processor module with
1 Mb of cache. The disk subsystem is SCSI based, but this hardly matters,
since with 128 Mb of memory, it never swapped into the 256 Mb swap space.
The CPU is pretty slow compared to a Pentium. The sparcstation is useful as
a reference point since I was able to get a memory usage estimate from
'time', which gave me the working set size (wss). The second test machine
is a Pentium 120 PC, with an ASUS Triton 2 motherboard with 512K cache and
dual NEC 2Gb IDE disk drives. It was first tested with 32 Mb of 60 ns DRAM,
and then upgraded to 64 Mb. For some of the tests, memory makes a big
difference, since logic synthesis can be a CPU and memory hog of the worst
sort. On the Pentium PC, two operating systems were tested: Windows 95 vs
Linux with kernel 2.0.27 and a Slackware 3.1 (Slackware96) distribution.
For testing the compiler, I dug up some VHDL oinkers of extensible
proportions. In a VHDL compiler, compilation proceeds in 3 phases: Parsing,
Elaboration, and Optimization. Parsing is just about the same as a C++
compiler, but in Elaboration, the circuit design specified by the behavorial
VHDL code is translated into large parallel data structures that describe
the boolean behavior of the code. In elaboration, all loops are unrolled
and constants are propagated as far as possible. Memory usage often hits
the first peak during elaboration. The next phase, optimization, has the
job of compressing the vast parallel data structures into actual gates that
describe the same behavior. The objective in optimization is often to
minimize the circuit area (minimize gate count), but is often subject to a
constraint that the circuit delay be less than some specified minimum
(constrained synthesis). During optimization, memory usage can often spike
dramatically higher, depending on the algorithm being used. The optimizer
has 8 or 9 different algorithms at it's disposal, and standard procedure is
to run them all, and then save the best result. This can burn a lot of CPU
time.
Test #1 (Serpent) is a simple shift register for an ORCA 2C FPGA, but with a
twist. The length of the shift register is set by a parameter, and the
flip-flop elements are directly instantiated with a loop in the code. Each
flip-flop element has an attribute attached that directs the place & route
tool to place the flip-flop in a specified location on the FPGA die. The
code places the flip-flops so that the shift register is done with a
serpentine layout in a block of cells. Technically, this is known as
'floorplanning' and is usually done with a GUI tool. For reason's not yet
clear, this bit of code is an enormous memory hog, and uses memory in
proportion to the number of elements instantiated. The number of flip flops
is set to 640, which are placed in 160 separate locations This test does
elaboration only, since there is no point in optimization. The synthesis
script just loads the gate library, reads in and elaborates the code, then
just writes out the resulting netlist.
When compiled on the Sparcstation, this took 2 minutes 27 seconds of wall
time, and hit a working set size peak (memory usage) of 62 Megabytes. Under
Linux 2.0.27, with 32 Mb of RAM and a 96 Mb swap space, it thrashed badly
but still produced a result after 25 minutes and 30 seconds. Windows 95
died with an "Out of Memory" message after thrashing for 18 minutes and 54
seconds. Another 32 Mb of RAM was added to the Pentium and this was
repeated. Linux improved its time to 13 minutes even, while Windows 95
managed to get a result after 17 minutes, 20 seconds. Linux has a pretty
good advantage here, since the compiler can run without bothering to load X
windows, while under Win95, the compiler won't run unless the graphical
interface is up. The compiler can't run in DOS mode. For the Windows 95
tests, a DOS window was opened and the compiler batch file was run in that
window. Nothing else was running.
Test #2 (CRC) is a CRC (Cyclic Redundancy Code) calculation on a parallel
stream of data words. CRC calculation is usually done on a serial data
stream, but what if the data stream is a presented as a sequence of parallel
words? This design, targeted for Xilinx 4000E FPGA's, feeds the incoming
word to the address of lookup table which contains the bits needed to XOR
with the current CRC data word stored in a data register. This design is
also extensible, since both the CRC polynomial and the input data word width
are specified as parameters. I used the CRC-CCIT polynomial and a 12 bit
input data word. This generates a 4096x16 table in elaboration, which is
then collapsed down into a small number of gates in optimization. This
works because the table is sparse and has a low entropy. This design has
significant amounts of work to do in both elaboration and in optimization.
On the Sparc, this compiled in 6 minutes 11 seconds, using 25 Mb of RAM.
Linux on the Pentium 120 with 32 Mb RAM compiled in 4 minutes 37 seconds.
Windows 95 trailed at 7 minutes 18 seconds.
Test #3 (2901) is a design with not much elaboration, and mostly
optimization work to do. It is the venerable 2901 bit slice design,
snatched straight from the VHDL.ORG website. This is basically a 4 bit
processor slice that does addition, subtractions and other binary operations
on a 4 bit data path. I didn't write the code for this, and I would
certainly write it differently if I had the time for it. It does give the
compiler something to chew on when I compiled it for Altera Flex10K FPGA's.
On the Sparc, this took 17 minutes 37 seconds in 18.5 Mb of RAM, while Linux
chewed this up in 8 minutes, 53 seconds. Again, Windows 95 took second
place in 12 minutes and 37 seconds.
Table #1: The following table has the run times shown in seconds.
Test Sparc RAM Usage Sparc20 Windows 95 Linux 2.0.27
----------------------------------------------------------------------
#1 (Sparc-20) 62 Mb 147 sec
#1 PC 32 Mb RAM died 1530 sec
#1 PC 64 Mb RAM 1040 sec 780 sec
#2 CRC 25 Mb 371 sec 438 sec 277 sec
#3 2901 18.5 Mb 1057 sec 757 sec 533 sec
If you take the Windows 95 run-times and sum together, and then divide by
the sum of the Linux run-times, you get 1.405. What does this mean? Linux
is 40% faster than Windows 95. Or to put it another way, you can turn up
your effective clock speed by 40% when you run Linux. I like it. Does this
still hold true for Windows NT4.0? Good question. Stay tuned.
Conclusions: Linux looks very good as an alternative to Windows 95, but for
tough problems, you can never have too much RAM or Swap space! A Pentium
CPU easily beats the older Sparc CPU's and a Pentium Pro CPU should be able
to trounce all but the priciest of workstations. The price performance of a
Pentium Pro is probably unbeatable.
I called up Exemplar Logic and queried them further on their policies of
making the Linux binary available to their customers... It turns out that
anyone who buys a floating license can run on whatever platform they please,
whether it is an HP, Sparc, Win NT, Win95, or Linux, or all of the above.
The linux version can grab a license token from the server just like the HP
or Sparc version. (I've gotta try this!) Indeed, even the Win95 version can
grab a license token if it is configured properly. Linux can even be used
for the license server, since the FlexLM binaries work just fine. The only
platform not supported as a license server is Win95! :-)
Summary: Win95 bytes, Linux cruises to victory...
Next Up: The crusade for a Linux Place & Route tool begins.
To answer the final obvious question:
Where can I get a linux binary of Leonardo?
Answer: You can't. At least for a week while they complete the final
rebuilds of Leonardo 4.0.3 on all the platforms. The new version
should be on the (protected) FTP site by the end of January 97.
I'll post a notice when it's ready. If you have access to a Leonardo
license server, contact me and I'll put you on a mailing list to
get early access.
John McCluskey
J-Squared Technologies
J.McCluskey@ieee.org
--------------7B26476967E668C57805B--
Article: 5026
In message <32DA860A.2247@aspect.com>
"Thomas C. Jones" <tjones@aspect.com> writes:
> Does anyone know of a pin-compatible replacement to the PEEL22CV10A
> offering greater routing capacity and resources?
> -Tom
> tjones@aspect.com
Why not try the Philips PLC42VA12 or Lattice GAL6001/2. These are
both FPLA architecture and have less P-terms in total (64 for each)
but they are much more efficient for state machines and the 6001/2
have buried registers.
Geoff Bostock
(Author Programmable Logic Handbook and FPGAs & Programmable LSI -
PLD/FPGA Design Consultant)
Article: 5027Thomas C. Jones wrote: > > Does anyone know of a pin-compatible replacement to the PEEL22CV10A > offering greater routing capacity and resources? ICT do the PA7024I PEEL array, which, quoting from my '94 databook... "Most powerful 24-pin PLD available" (In 1994, believable) 20 I/Os, 2 Inputs / clocks, 40 registers / latches speeds to 17nS (In 1994. Now, who knows) blah blah blah (seems to offer all the funky bits of a PEEL22CV10A+, so looks like a fine device. ) Also, if you've been using ICTPLACE to code your designs, it's supported in there, so you get the simulator and the decent design tools. (Side note, that simulator is what gets me to design in ICT PLDs rather than generics. Well worth the effort, ICT, Thanks. (In fact the whole development environment for ICT is pleasant) SteveArticle: 5028
"James Fakas" <jjfakas@erols.com> wrote: >These are extremely good deals. They include a PC ISA FPGA test board board >along with the FOUNDATION software from XILINX! >Great deals!!! >Here are other kit prices: >APS-X84-FB X84 board with the Foundation Base Software....$650.00 >APS-X84-FBV same with VHDL............$1295.00 >APS-X84-FS X84 board with Foundation Standard Software....$1300.00 >APS-X84-FSV same with VHDL..............$2500.00 >The contacts are at I believe that the Xilinx Foundation software is actualy an evaluation copy, and it turns into a pumpkin after 250 uese.Article: 5029
Peter Trei wrote:
>
> In 1993, Michael J. Wiener of Bell-Northern Research, published a
> paper 'Efficient DES Keysearch', in which he gave a detailed
> description of such a keysearch engine, based on custom chips, which
> could search the entire keyspace in about 7 hours.
Is a gate-level netlist or a VHDL or Verilog description of this design
available somewhere ?
I'd like to try it, but don't really have the time to do a capture from
the article. Since it is public domain, surely somebody has it
(including the author of the article I guess).
Alain.
--
-----------------------------------------------------------------------
Alain RAYNAUD META SYSTEMS
Batiment Hermes
4, rue Rene Razel
Tel: (33) 01 69 35 10 16 91400 Saclay - FRANCE
E-Mail: Alain_Raynaud@mentorg.com Fax: (33) 01 69 35 10 10
-----------------------------------------------------------------------
Article: 5030ANNOUNCE: NEW MODEL AND TIP OF THE MONTH This month's model is: Simple RAM model in Verilog This month's tip is: Re-usable Functions You can find both at 'THE WINNING EDGE' http://www.doulos.co.uk You can also access previous Models and Tips of the Month from the same site. During 1996 these included: A to D converter Design for Debug How to avoid synthesising unwanted latches FIR filter .... and many more During 1997 Doulos will continue to develop THE WINNING EDGE to include more VHDL and Verilog tips, tricks, tutorials and models. Our aim is to make THE WINNING EDGE one of the most useful High Level Design sites out there. ____________________________________________________________________ Also *** NEW *** for this month are: Free CBT software for Verilog Additions to our Hardware Engineer’s Guide to VHDL series _____________________________________________________________________ DOULOS Church Hatch Tel: +44 1425 471 223 22 Market Place Fax: +44 1425 471 573 Ringwood BH24 1AW Email: webmaster@doulos.co.uk UK _____________________________________________________________________Article: 5031
The following information is also available at
http://www.dac.com/dac/grant.html
DAC DESIGN AUTOMATION GRADUATE SCHOLARSHIPS
The 34th Design Automation Conference is sponsoring up to four $12,000
scholarships to support graduate research and study in Design Automation,
with emphasis in electronic and computer design and test automation.
These scholarships are awarded directly to a university for the Faculty
Investigator to expend in accordance with the proposal.
The university receiving a scholarship is free to use this money in
direct support of one or more of its Design Automation graduate students
named in the proposal, in the manner outlined in its proposal, except
that the scholarship funds shall not be used to support indirect costs
or overhead.
The scholarship funds must only be used to support the student(s) and
project(s) named in the winning proposals. Because the award decisions
are made based on the scholastic achievements of the named student(s)
and the qualifications of the named project(s), no substitutions may
be made. The scholarship recipient must forfeit the award if the conditions
of the research proposal change. The Faculty Investigator of the project
receiving a scholarship award will be expected to submit a brief report
of the year's activities supported by the scholarship for publication
in the newsletters of the sponsoring organizations. This report should
be submitted at the conclusion of the year supported. Applications for
the scholarship, either new or renewal, should be submitted by the Faculty
Investigator or Department Chairperson and must include:
1. A brief (2 pages maximum) biography of the student(s) proposed for
the scholarship;
2. Transcripts of the graduate and undergraduate records of each of the
student(s) proposed for the scholarship;
3. A paragraph for each student proposed outlining his or her goals and
objectives;
4. A brief (5 pages maximum) proposal concerning the research to be
conducted and the way in which the scholarship is to be expended;
5. A brief statement (1 page maximum) of the impact of the scholarship
on the Design Automation Program at her or his institution;
6. A listing of all current and pending support for the student(s) and
project(s): who the support is from, the duration of the support,
and the dollar amount of the support.
7. A indication of any previous Design Automation Scholarships awarded
to the Faculty Investigator.
Scholarships will be awarded based on the following criteria:
* Academic credentials of the student(s);
* Quality and applicability of the proposed research;
* Impact of the award on the DA program at the institution. Preference
will be given to institutions which are trying to establish new DA
research programs.
* Need. Preference will be given to student(s) and project(s) that can
demonstrate financial need.
Scholarships can be awarded in support of new projects or for one renewal
of a DAC grant from the previous year. An application from the same student,
or faculty sponsor of a winner from the previous year is considered a
renewal application.
Original and two complete copies of all application materials must be
received by Friday, January 31, 1997 to
James P. Cohoon
University of Virginia
Department of Computer Science
Olsson Hall
Charlottesville, VA 22903
For further information contact James Cohoon at + (804) 982-2210 or by
email at cohoon@virginia.edu. Notification of the awards will be made by
mid-April, 1997.
Article: 5032I'm fairly ignorant of radiation issues and I have a few questions for anyone who might care to respond. I'm getting a little lost with all the qualitative responses I've seen posted to this thread and need a little reality check (ie numbers). - Approximately what failure rate would a non radhard FPGA die (100mm^2) experience at sea level? - At 50,000 feet? - In space? - What happens to the above rates if the device is radhard? - Why don't SRAM based FPGA manufacturers publish the expected rates? - What is the effect of shielding? - I've read that some cosmic rays contain as much energy as a well thrown rock. Do radhard devices tolerate such hits? If the expected rate is so low as to occur only infrequently, then some simple means might be used to insure system integrity by simply detecting the possibility of an error. - Is it possible to monitor the die to detect possible hits by looking at die leakage or other measurable parameters. If so, could one detect a possible hit and alert the system to reboot the FPGA? - Could the FPGA architecture be altered to allow parity be computed continously for config data to determine if it has been hit? Just wondering - Brad the system.Article: 5033
In comp.os.linux.development.apps "root@speedy.login.qc.ca" <root@speedy.login.qc.ca> wrote: : This is a multi-part message in MIME format. : --------------7B26476967E668C57805B : Content-Type: text/plain; charset=us-ascii : Content-Transfer-Encoding: 7bit : See the attachment for a comparison of Win95 & Linux 2.0.27 on synthesis : of the same VHDL circuits. : --------------7B26476967E668C57805B : Content-Type: text/plain; charset=us-ascii; name="linux_leo.txt" : Content-Transfer-Encoding: 7bit : Content-Disposition: inline; filename="linux_leo.txt" : A modest comparison of Windows-95 against Linux 2.0.27 : by John McCluskey, J-Squared Technologies. January 8, 1997 : Email: J.McCluskey@ieee.org : This experiment started on Monday night (Jan 6), when after a phone call to : Exemplar Logic in California, they agreed to place the Linux version of : their Leonardo synthesis tool on their ftp site so I could grab it to test : it out. I spent the rest of the night (until 1 am) dialing and redialing my : ISP's modem pool, trying to latch onto a good modem that would hold the : modem carrier for more than a few minutes. After a lot of frustration, I : gave up and finished grabbing the rest of the gzipped tar file in the : morning. Finally, about 10 AM, I had succeeded in grabbing the 15 megabyte : ... : Summary: Win95 bytes, Linux cruises to victory... : Next Up: The crusade for a Linux Place & Route tool begins. : To answer the final obvious question: : Where can I get a linux binary of Leonardo? : Answer: You can't. At least for a week while they complete the final : rebuilds of Leonardo 4.0.3 on all the platforms. The new version : should be on the (protected) FTP site by the end of January 97. : I'll post a notice when it's ready. If you have access to a : Leonardo : license server, contact me and I'll put you on a mailing list to : get early access. Has Leonardo some reference page? Some mail adress? Thanks -- Uwe Bonnes bon@elektron.ikp.physik.th-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 5034
In article <32DAF3D3.5EFA@dimensional.com> hamilton@dimensional.com writes: >> Peter Trei wrote: >> > >> > In 1993, Michael J. Wiener of Bell-Northern Research, published a >> > paper 'Efficient DES Keysearch', in which he gave a detailed > ^^^^^^^^^^^^^^^^^^^^^^^ > >Is this paper available on the net somewhere ?? http://www.aist-nara.ac.jp/Security/doc/ is one location. It's in postscript - you'll need the graphics. Peter Trei ptrei@acm.orgArticle: 5035
Are there any newsgroups for the discussion of ASICs and custom silicon, and ASIC vendors, VHDL libraries and design tools? Please copy any replies to me in email. Thanks in advance, - BrianArticle: 5036
Not true!!!! These prices are for the NO RUN LIMITS software Richard Schwarz Pres. APS timolmst@cyberramp.net wrote in article <5bg63k$s7d$2@newshost.cyberramp.net>... > "James Fakas" <jjfakas@erols.com> wrote: > > >These are extremely good deals. They include a PC ISA FPGA test board board > >along with the FOUNDATION software from XILINX! > > >Great deals!!! > > >Here are other kit prices: > > >APS-X84-FB X84 board with the Foundation Base Software....$650.00 > > >APS-X84-FBV same with VHDL............$1295.00 > > >APS-X84-FS X84 board with Foundation Standard Software....$1300.00 > > >APS-X84-FSV same with VHDL..............$2500.00 > > >The contacts are at > > I believe that the Xilinx Foundation software is actualy an evaluation > copy, and it turns into a pumpkin after 250 uese. > >Article: 5037
"Richard Schwarz" <aaps@erols.com> wrote: >Not true!!!! These prices are for the NO RUN LIMITS software >Richard Schwarz >Pres. >APS If you say so! If so, then these are great prices.Article: 5038
I think most people and designing and flying space systems would be very uncomfortable with the concept that a part would latch up and it would be "OK". Henry Spencer wrote: > > In article <01bc0161$d44246a0$6e0db780@Rich> "Rich K." <rich.katz@gsfc.nasa.gov> writes: > >...[DRAMs in space] But making this work > >(without too much trouble) requires two things: the device does not latchup > >up from single particles (SEL or single event latchup) and a faborable > >internal organization of the memory. For the first, fortunately, there are > >a number of available devices which are sufficiently immune to SEL... > > Actually, if memory serves, the first requirement isn't quite as stringent > as you might think: it is typically possible to power-cycle DRAM briefly > to break a latchup without losing the memory contents. (Particularly if > you are willing to do some testing and selection of parts, commercial DRAMs > generally exceed their specs for data retention and refresh interval by a > fairly wide margin.) Admittedly, you don't want to do it *too* often. > -- > "We don't care. We don't have to. You'll buy | Henry Spencer > whatever we ship, so why bother? We're Microsoft."| henry@zoo.toronto.edu -- Dave Erstad erstad@ssec.honeywell.com The views above are mine and are not necessarily Honeywell's.Article: 5039
Please find below the call for papers for the special issue of IEEE
Transactions on VLSI Systems on Recent Advances in FPGA Technology.
Also, please note that the preregistration deadline for the ACM/SIGDA
Symposium on Field-Programmable Gate Arrays is January 22nd, one week from
today. For more details, please see:
htttp://www.ece.nwu.edu/~hauck/fpga97
Scott Hauck
hauck@ece.nwu.edu
==================================================================
CALL FOR PAPERS
SPECIAL ISSUE ON RECENT ADVANCES IN FPGA TECHNOLOGY
IEEE TRANSACTIONS ON VLSI SYSTEMS
Field-Programmable Gate Arrays (FPGAs) have become an important
technology for the implementation of VLSI circuits and systems
due to the steady increase in FPGA density and speed. Aside from
main-stream use in reasonably high volume production, the field-
programmability and re-programmability of FPGAs enable many novel
and promising applications, including rapid system prototyping,
reconfigurable system designs, rapid system prototyping, circuit
emulation, and reconfigurable custom computing. This special is-
sue will be devoted to recent advances in all areas related to
the FPGA technology.
Topics of interest include, but not limited to:
o Advances in FPGA architectures, including design of programm-
able logic blocks, programmable interconnects, programmable I/Os,
and development of new FPGAs and field-configurable memories.
o Novel applications of FPGAs, including rapid prototyping, logic
emulation, reconfigurable custom computing, and dynamically
reconfigurable applications.
o New CAD algorithms and tools for FPGAs, including new algo-
rithms for sequential and combinational logic optimization,
technology mapping, partitioning, placement, routing, and de-
velopment of new FPGA synthesis or layout systems.
o Advances in field-programmable technology, including new pro-
cess and fabrication technologies, and field-programmable
analog arrays.
Authors of papers accepted for the 1997 ACM/SIGDA 5th Interna-
tional Symposium on Field-Programmable Gate Arrays (FPGA'97) are
especially encouraged to submit an extended version of their pa-
pers for possible inclusion in the special issue. Submissions of
relevant work not presented at FPGA'97 are also welcome. This
special issue is being coordinated by Guest Editors Jason Cong of
Univ. of California, Los Angeles (UCLA) and Carl Ebeling of Univ.
of Washington.
Prospective authors should submit postscript versions of their
papers electronically using the www no later than March 31, 1997,
and indicate they should be considered for this special issue:
http://microsys6.engr.utk.edu/~tvlsi
Alternatively, email may be used by contacting:
tvlsi@microsys6.engr.utk.edu
If neither of the electronic means is available to authors, trad-
itional paper manuscripts should be sent to:
IEEE Trans. on VLSI Systems
c/o Prof. Bing Sheu
Electrical Engineering
Powell Hall, Room 604
University of Southern California
Los Angeles, CA 90089-0271
==================================================================
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Scott A. Hauck, Assistant Professor |
| Dept. of ECE Voice: (847) 467-1849 |
| Northwestern University FAX: (847) 467-4144 |
| 2145 Sheridan Road Email: hauck@ece.nwu.edu |
| Evanston, IL 60208 WWW: http://www.ece.nwu.edu/~hauck |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 5040Uwe Bonnes <bon@hertz.ikp.physik.th-darmstadt.de> wrote: >Has Leonardo some reference page? Some mail adress? http://www.exemplar.com/leonardo060396.phtml -StefanArticle: 5041
Can anyone share some market share stats for the major ASIC/FPGA synthesis vendors (eg. Synopsys, Exemplar, Cadence, Mentor, etc.)? I'd be interested in either revenue or seat-based statistics. Separate stats for the ASIC and FPGA markets would be nice too. Thanks in advance. -- _______________________________________________________________________ Lance Gin "off the keyboard, over the bridge, Delco Systems-GM Hughes Electronics through the gateway, C43LYG@dso.hac.com nothing but NET!" _______________________________________________________________________Article: 5042
In article <32DCEAB8.6C1C@ssec.honeywell.com> David Erstad <erstad@ssec.honeywell.com> writes: >> Actually, if memory serves, the first requirement isn't quite as stringent >> as you might think: it is typically possible to power-cycle DRAM briefly >> to break a latchup without losing the memory contents... > >I think most people and designing and flying space systems would be very >uncomfortable with the concept that a part would latch up and it would >be "OK". Then they should brace themselves for some uncomfortable news: the new generation of designers are already flying systems which cope with latchup when it happens rather than jumping through hoops on parts selection to ensure it never does. For example, the Mars Observer Camera, launched in 1992 (and now en route to Mars, again, under a slightly changed name, on Mars Global Surveyor), uses non-latchup-proof DRAMs in its main memory. (In fact, the observation about power cycling without content loss comes from the MOC people.) -- "We don't care. We don't have to. You'll buy | Henry Spencer whatever we ship, so why bother? We're Microsoft."| henry@zoo.toronto.eduArticle: 5043
In article <01bc0161$d44246a0$6e0db780@Rich>, rich.katz@gsfc.nasa.gov says... > >In the near term, there will be an increasing number of NASA missions >flying DRAMs, including some long-term missions like Cassini to Saturn. > >The easiest codes to work with are the Hamming codes, with most >implementations correcting single-bit errors and detecting double-bit >errors. These codes permit easy correction on the fly and are very simple >to implement (and if one has time it can be done if FPGAs). >If not, then Reed-Solomon or some other code would be >required, which are more difficult to decode. Given the price of S/DRAM memories why not use a majority voting system such as TMR (Triple Modular Redundancy). The system can handle multiple bit upsets and is very easy to implement. I have currently a system running in an Actel1020 (17% used!). Of course the drawback is that you have to either triplicate your memory or add a statemachine to perform three memory read cycles per CPU read cycle. Hans Surrey Satellite Technology.Article: 5044
In article <32D3A689.70E9@item.uni-bremen.de>, beckmann@item.uni-bremen.de says... > >As far as I could find out, there is no rad hard Xilinx Device >available. > >The application of this was a satellite. > >Fritz > >* Friedrich Beckmann * >* University of Bremen TEL: +49 421 218 4079 * >* FB1 - Institute for Microelectronics FAX: +49 421 218 4434 * Just out of interest has anybody implemented a continuous checking watchdog on a Xilinx FPGA? Xilinx provides a configuration read back option, using the same device or some external CRC checker the system can continuously be checked for configuration errors due to SEU. The error latency will of course depends on the configuration size and read back speed (1 or 8MHz?). To improve on this the user can for example add redundant logic and boundary scan techniques. Total dose tolerance can be improved by different packaging techniques such as RADPACK (tm) and SEL can be addressed with a fast electronic fuse. The unknown of course in this system is, can you damage a Xilinx device by randomly changing configuration bits? Hans. Surrey Satellite TechnologyArticle: 5045
Lance Gin wrote: > > Can anyone share some market share stats for the major ASIC/FPGA > synthesis vendors (eg. Synopsys, Exemplar, Cadence, Mentor, etc.)? > > I'd be interested in either revenue or seat-based statistics. Separate > stats for the ASIC and FPGA markets would be nice too. Thanks in advance.> Try this: http://quote.pathfinder.com/money/quote/qc?symbols=CDN Best regards. Anatoli ============================================ Anatoli A. Ivanov, Application Engineer e-mail : anatoli@cadence.msk.su ============================================Article: 5046
Hello, If anybody is interested in an Integer Linear Programming formulation of the Scheduling Problem for Dynamically reconfigurable FPGAs, have a look at http://users.ox.ac.uk/~kebl0341/thesis.ps The idea is that scheduling shouldn't be done manually for FPGAs like: -XC6000 series of Xilinx -Pilkington series (licensed by Toshiba and Motorolla) -Atmel DR FPGAs because that can be too complex and will lead to non optimal results that may not meet the design speed criteria. An algorithm is set up in this thesis, using ILP. In fact just the ILP formulation is given. I have no time to write a paper. You might want to write it yourself! Please tell me what you think about it. I'd be glad to get some comments. Peter -- =================================================================== Peter Sels === Easics === ASIC Designer === VHDL-based ASIC design services === mailto:peter@easics.be =================================== Tel: +32-16-298 405 Kapeldreef 60, B-3001 Leuven, BELGIUM Fax: +32-16-298 319 http://www.easics.com personal homepage: http://users.ox.ac.uk/~kebl0341/Article: 5047
Last week, I posted a survey to ascertain the version of Linux
users have (or intend to use) for EDA tools.
I received 47 responses; 44 of which contributed survey data
(the other 3 just offered encouragement to support Linux for EDA usage).
The results are:
8.5% use Linux 1.2
85.1% use Linux 2.0
6.4% use Linux 2.1
The additional query about SunOS yielded the following distribution
for those who responded that they use Sun machines:
47.6% use SunOS 4.1
9.5% use SunOS 5.4 (Solaris 2.4)
42.9% use SunOS 5.5 (Solaris 2.5)
Much thanx to those who responded.
BTW, our company is very interested in developing the "right" tools for
Linux (et. al.)
platforms. Initially, the focus will be on tools to complement a
Synopsys Design Compiler
based synthesis flow:
1. GUI-based front end to Design Compiler which offers shrink-wrapped
capability
to perform true, easily controlled, hierarchical ASIC synthesis
with effective
budgeting techniques --- without writing one line of dc_shell
code.
(The tool also generates "scripts" which can be leveraged,
replayed w/o GUI !)
2. Write_script "preprocessor" which offers a very easy to use Tcl
(database/procedural) interface to massage
characterize/write_script constraints
before subsequent use. A useful set of predefined routines are
provided
(to coalesce bit/bus constraints, select AC/DC categories, ...).
3. Tcl (database/procedural) interface to a (post-synthesis) netlist
to provide
additional (directed) manipulations/optimizations (an infinitely
"programmable"
change-names, buffer insertion/removal, sizing, ...). Several
predefined routines
will be provided.
The company's (current) intent is to utilize the Internet as the sole
means of
distribution and support: i.e., the virtual EDA company.
Obviously, ease-of-use, quality documention, timely FAQs are important
to being
successful with this model.
Any comments, suggestions, etc. concerning these tools is welcome.
(Personal email may be more appropriate than posting to the newsgroups.
Summary responses may be posted, subsequently, unless massive "flames"
result.)
Thanx.
--
Synthesis Solutions, Inc.
http://www.ez-synthesis.com
vmail: (415) 431-6429
Article: 5048designs of this type have been done before and we called it a poor man's edac (and it was done when they had 1 kbit memories <- not a typo). didn't even need an fpga, the 54ls253 makes a great voter w/ only one half and by adding an inverter the other half can function as an error indicator. and the state machine wasn't tough and the read cycle had to be transformed into a read-modify-write; this was important for consistent software timing/verification in the presence of errors. rk p.s. and i did a 16-bit flow through edac in a 1020 which had the ability (when using x8 ram chips) to swap out failed chips in the real memory and use the spare edac memory for functioning; handy for when a whole chip gets busted, hamming codes won't fix that problem, but gotta keep going and don't have the room for 3 copies of memory. Hans Tiggeler <ees1ht@ee.surrey.ac.uk> wrote in article <5bkr0a$ru4@info-server.surrey.ac.uk>... > In article <01bc0161$d44246a0$6e0db780@Rich>, rich.katz@gsfc.nasa.gov says... > > > >In the near term, there will be an increasing number of NASA missions > >flying DRAMs, including some long-term missions like Cassini to Saturn. > > > >The easiest codes to work with are the Hamming codes, with most > >implementations correcting single-bit errors and detecting double-bit > >errors. These codes permit easy correction on the fly and are very simple > >to implement (and if one has time it can be done if FPGAs). > >If not, then Reed-Solomon or some other code would be > >required, which are more difficult to decode. > > Given the price of S/DRAM memories why not use a majority voting system such as TMR (Triple > Modular Redundancy). The system can handle multiple bit upsets and is very easy to implement. I > have currently a system running in an Actel1020 (17% used!). Of course the drawback is that you > have to either triplicate your memory or add a statemachine to perform three memory read cycles > per CPU read cycle. > > Hans > Surrey Satellite Technology. > > > >Article: 5049
well the xilinx guys just left the office and the amount of damage done internally by an illegal configuration they didn't know but i'll be following up at the factory with the contact number they left. a key element would be worst-case current densities so there is no metal migration problems. the standard for this is about 2E5 a/cm^2, if memory is correct, which is not as big as it looks when you compute the cross-sectional area of small metal lines. another case for damage would be that of an input cell turning into an output with a single bit-flip and that is obviously a concern. as far as continously checking the configuration, we discussed that and hope to test some of their devices fabricated on epi (to hopefully make latchup problems go away) and felt we could do a verify cycle in < 10 ms. it is planned to implement this and test it in an accelerator soon. of course you need a master copy of the program and where do you store that? and a sequencer to take care of things if there is a failure to verify. for the test i'd like to run, i'll just use a eprom and an actel a1020 :-) to do the work. as for the 'fast electronic fuse,' i'd be interested in seeing a good design for hi-rel apps that is testable. it's talked about a lot but difficult and bulky to do well. additionally, with any total dose radiation shielding, practical shielding materials/thickness/mass/configurations often limit the benefits of shielding, depending upon the environment. electrons are relatively easily to shield. protons are much more difficult and very soft commercial devices, even with thick shields, may not meet mission requirements. of interest is that shielding can even make matters worse for some particles depending upon the energy. it has been showed analytically that the shield will change the energy of particles that are not stopped by the shield (difficult to do for protons, for instance) with the lower energy causing more damage to the device. this was recently measured for several different types/thicknesses of shields using soft fpga's and for certain ranges of energies, the "shielded" parts were damaged faster than unshielded parts. rk Hans Tiggeler <ees1ht@ee.surrey.ac.uk> wrote in article <5bkroa$ru4@info-server.surrey.ac.uk>... > In article <32D3A689.70E9@item.uni-bremen.de>, beckmann@item.uni-bremen.de > says... > > > >As far as I could find out, there is no rad hard Xilinx Device > >available. > > > >The application of this was a satellite. > > > >Fritz > > > >* Friedrich Beckmann * > >* University of Bremen TEL: +49 421 218 4079 * > >* FB1 - Institute for Microelectronics FAX: +49 421 218 4434 * > > Just out of interest has anybody implemented a continuous checking watchdog on > a Xilinx FPGA? > > Xilinx provides a configuration read back option, using the same device or > some external CRC checker the system can continuously be checked for > configuration errors due to SEU. The error latency will of course depends on > the configuration size and read back speed (1 or 8MHz?). To improve on this > the user can for example add redundant logic and boundary scan techniques. > Total dose tolerance can be improved by different packaging techniques such as > RADPACK (tm) and SEL can be addressed with a fast electronic fuse. > > The unknown of course in this system is, can you damage a Xilinx device by > randomly changing configuration bits? > > Hans. > Surrey Satellite Technology > >
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