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 75

Article: 75
Subject: Re: Proprietary Configuration Data
From: ard@siva.bris.ac.uk (PDP11 Hacker .....)
Date: Wed, 10 Aug 1994 21:41:00 GMT
Links: << >>  << T >>  << A >>
In article <776540488snz@rhizik.demon.co.uk>, john@rhizik.demon.co.uk writes...
> 
>On the same grounds that CPLD/FPGA manufacturers should
>keep configuration information hidden, Microprocessor
>manufacturers should presumably also hide details of the
>architectures and instruction sets of their chips,
>and build chips with encrypted instruction streams

And while we're about it, we'd better not publish the character code - it would
encourage the use of unreliable, non-standard printers. We'd better not publish
the OS routines, either. It would encourage non-approved software...

[In other words, I agree 100%]

>[Dallas actually make an 8051 clone that does this].

Ah, but doesn't that chip let _you, the user_ program the encryption key? I
have no problem with that.

> 
>Clearly a processor with a documented, unencrypted
>instruction stream permits reverse engineering of programs
>written for that processor.  What's the problem ? The program
>is still copyright.  And anyway how many of these chips really
>doing something so clever that having a good look at the system-
>level design won't give away what the chip is doing ?

Virtually none :-). Techniques to stop reverse engineering tend to fail when
put against a group of pirates armed with test equipment, electon microscopes,
and chip fab equipement....

Given that you could, I guess, even work out how the _chip_ worked, and thus
how the bitstream was interpreted.

[More good points that I agree with deleted]

How about some manufacturer making 2 lines of devices. One encrypted. The other
not. The 'professionals' can try and hide their design. We can make our
reconfigurable circuits. 

>I'm sure the manufacturers are perfectly happy to supply the formats
>of their configuration data to anyone who will sign an NDA and
>promise them a lot of revenue.

And what's to sat they're not the priates hoping to rip off my new design.
After all, that wouldn't break an NDA - they haven't disclosed the information,
just used it.

> 
>[Stir, Stir, Stir]
>-- 
>John Vickers

-tony

Bristol University takes no responsibility for the views expressed in this
posting. They are the personal views of the user concerned.



Article: 76
Subject: Re: How pricey is FPGA development?
From: ard@siva.bris.ac.uk (PDP11 Hacker .....)
Date: Wed, 10 Aug 1994 21:50:00 GMT
Links: << >>  << T >>  << A >>
In article <DEREKN.94Aug9110426@vw.ece.cmu.edu>, derekn@vw.ece.cmu.edu (Derek B. Noonburg) writes...
>In article <326u0k$qqo@search01.news.aol.com>, billatt@aol.com (Billatt) writes:
> 
>> In article <DEREKN.94Aug8172233@vw.ece.cmu.edu>,
>> derekn@vw.ece.cmu.edu (Derek B. Noonburg) writes:
> 
>>> I've heard several bogus arguements as to why the programming
>>> algorithms/bit allocations are not published
> 
>(I didn't actually say this, I just quoted it, but I do agree with it.)

Actually, I said the original statement.

> 
>> Borland does not publish its c++ compiler algorithms because it
>> feels its algorithms are better then Microsofts.
> 
>Borland sold their first compiler for $49.95.  Also, they were trying
>to sell just software, not software and computers, whereas Xilinx, et
>al. are (presumably) trying to sell both software and chips.

No, Borland do not publish the algorithms in their compilers. But, the source
language (C) and the output (80x86 machine code) are both documented. I can
either buy the compiler and use it, or I can write the raw machine code myself,
in binary. Or, I can develop my own tools to make the latter easier. I don't
_have_ to buy the compiler if I think I can do better.

I don't think we're asking the FPGA manufacturers to publish the algorithms in
their placement/routing software. Just the 'object code'.

> 
>That's exactly what I was suggesting.  I (and I think most hobbyists
>would agree) would be happy with software that's limited like this.

Well I wouldn't be, for 2 reasons

a) I want to try a self-modifying design. I like playing about with useless (?)
circuits just for the fun of it....

b) I'm not sure I trust the compiler to do _exactly_ what I want in all
conditions. If I buy a C or Pascal compiler for my PC (and I have bought both),
I can use assembly language if I want to for some bits. I might want to use
_specific_ parts of the chip for some obscure reason.

How do I _know_ that the compiler is not putting in extra circuitry to cause me
problems about once a week? Just so I have to pay for tech support or the more
expensive compiler....

> 
>Which companies are doing this?
> 
>- Derek

-tony

Bristol University takes no responsibility for the views expressed in this
posting. They are the personal views of the user concerned.



Article: 77
Subject: Wanted: Literature on Reconfigurable Systems..
From: pagey@ECE.Concordia.CA (Sandeep Pagey)
Date: Thu, 11 Aug 1994 03:54:12 GMT
Links: << >>  << T >>  << A >>
Hi,

I am looking for literature/references/pointers on the design of reconfigurable
systems using FPGAs. I have read about some reconfigurable communication
systems designed using FPGAs, but no details. I am specifically looking for
reconfigurability from fault-tolerant computing point of view.

Thanks,
Sandeep.
pagey@vlsi.concordia.ca
pagey@ece.concordia.ca


Article: 78
Subject: Re: Proprietary Configuration Data
From: adyer@MCS.COM (Dru)
Date: 11 Aug 1994 00:05:45 -0500
Links: << >>  << T >>  << A >>
Just as a fun twist in this whole thing - has anybody looked at the
Atmel "Cache Logic" reconfigurable FPGAs?  Is the actual configuration
bitstream open or is it just that given their tools you can generate
multiple bitstreams to reconfigure the logic?


Article: 79
Subject: Would you like a free C to netlist compiler?
From: chris@lslsun7.epfl.ch (Christian Iseli)
Date: 11 Aug 1994 08:00:54 GMT
Links: << >>  << T >>  << A >>
(Sorry if you see this twice. I tried to send it yesterday, but
it didn't seem to go through)

As a part of the Spyder project (the development of a reconfigurable
processor using FPGAs), a student here has written a compiler that
translates a subset of C (only one data type, functions, for loops and
conditionals) into a netlist for ViewLogic (a wirelist file) but it
should be relatively easy to produce another netlist format. If there
is enough interest, I'd be willing to release the sources of this
compiler under the GNU GPL.

Some work is still needed to make the compiler really usable. In
particular a base library of symbols needs to be created, but that is
neither very long, nor very difficult. I'd say this is an alpha
version...

The only documentation at this time is the student report (in French)
and the source code...

The interest to describe circuitry in C lies, for me, in the fact of
being able to simulate it (or better said, to emulate it) as part of a
larger C++ (or C) program. That's why this compiler came into being.

I'd still have to clean up things a little before releasing this,
that's why I ask if it is worth my time to do it. My hope, if this is
released, is that some other people might be able to improve it so
that it would become a better tool.

So, folks, let's hear from those that are interested!!

-- 

					Christian Iseli
					LSL-DI-EPFL
					Lausanne, Switzerland


Article: 80
Subject: Re: Wanted: Literature on Reconfigurable Systems..
From: jma@b117d.super.org (Jeffrey M. Arnold)
Date: Thu, 11 Aug 1994 12:09:08 GMT
Links: << >>  << T >>  << A >>
In article <CuCquD.GpH@newsflash.concordia.ca> pagey@ECE.Concordia.CA (Sandeep Pagey) writes:
   I am looking for literature/references/pointers on the design of reconfigurable
   systems using FPGAs. I have read about some reconfigurable communication
   systems designed using FPGAs, but no details. I am specifically looking for
   reconfigurability from fault-tolerant computing point of view.

We are slowly putting together a FAQ list for this newsgroup, but this
seems to be the number one FAQ.  Various people have bibliographies of
papers and books related to reconfigurable computing that they might
be willing to share.  In the meantime, if you have access to a WWW
client, you might check out:

	ftp://super.org/pub/www/FPGA/caf.html

This is the beginning of a home page for this news group.  It contains
a pointer to a list of reconfigurable machines maintained by Steve
Guccione (U Texas) and pointers to some papers on our own work on the
Splash and Splash 2 reconfigurable systems.  As soon as we start to
get a bibliography together it too will appear in that page.

I do not have any references specifically related to reconfigurability
for fault tolerant computing.



Article: 81
Subject: Microprocessors implemented with FPGAs
From: hutch@timp.ee.byu.edu (Brad Hutchings)
Date: 11 Aug 1994 11:23:32 -0600
Links: << >>  << T >>  << A >>

Hi,

I remember an earlier thread where there was some discussion about
microprocessors implemented with FPGAs. I was wondering what else
was out there. I am specifically interested in any work regarding
microprocessors implemented on a single FPGA. I have already looked
at the following:
"FPGA Implementation of a Reconfigurable Processor", Davidson, J.
"Flexible Processors: a promising application-specific processor design approach"
(by Andrew Wolfe and John P. Shen)
I also have the list from Guccione.

I am interested in *any* reports of microprocessor-like applications
implemented on FPGAs. 

Thanks,

-- 
Brad L. Hutchings
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-2667

-- 
Brad L. Hutchings
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-2667



Article: 82
Subject: Re: Proprietary Configuration Data
From: hutch@timp.ee.byu.edu (Brad Hutchings)
Date: 11 Aug 1994 11:32:37 -0600
Links: << >>  << T >>  << A >>

In article <32cbj9$ptb@Mercury.mcs.com>, adyer@MCS.COM (Dru) writes:
|> Just as a fun twist in this whole thing - has anybody looked at the
|> Atmel "Cache Logic" reconfigurable FPGAs?  Is the actual configuration
|> bitstream open or is it just that given their tools you can generate
|> multiple bitstreams to reconfigure the logic?
|> 

Yes we have looked at it. The bitstream is not open. To the best of
my knowledge, their tools do *not* readily support cache logic. The
idea appears to be in the conjectural stages.

-- 
Brad L. Hutchings
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-2667

-- 
Brad L. Hutchings
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-2667



Article: 83
Subject: Actel Act3 Speeds (measured?)
From: pfile@sun23.cs.wisc.edu (Rob Pfile)
Date: 11 Aug 1994 19:35:24 GMT
Links: << >>  << T >>  << A >>

We're working on an FPGA design which has at it's heart a tag-check
operation. Actel's FPGAs seem to be generally the densest and fastest
out there; we're looking at using the A1460-2. The FPGA is going to
sit on a sparc MBUS, and as such, is going to be clocked at
50MHz. We're not sure if it's actually capable of these speeds,
but the literature indicates that it should be able to implement
modestly complex state machines and work at this speed.

The critical path is the tag lookup operation. We need to latch the
address from the mbus, strip some bits, and drive it back off the chip
to index a tag SRAM, then latch the data from the SRAM and make a
decision based on the state. Using the preliminary data from the 1994
actel manual for the 1460-1 part, i did a rough calculation for
getting on and then back off the chip, through an input FF and
output FF. One number i'm not sure of is an average routing delay thru
the chip. They give IO pad delay times based on the fan-out, and logic
block to logic block delays based on fan-out, but I'm not sure these
numbers are really relevant. Obviously the routing delay is going to
be highly variable based on intervening logic blocks, etc, but I'm
looking at coming onto the chip thru a FF, then driving straight
through to the other side thru an output FF or output buffer.

So, has anyone measured these parts and come up with an average pad to
pad time thru FFs and using only IO buffers?

I talked to some of my friends in the physics department that use Act2
series parts, and they say that their ActionProbe reports IO pad
delays that are 3x that in the manual. This is bad news for us if the
accuracy of all of the published numbers is that bad.

thanks

rob
pfile@cs.wisc.edu


Article: 84
Subject: Re: Proprietary Configuration Data
From: benzene@neocad.com (Dave Bennett)
Date: Thu, 11 Aug 1994 20:43:44 GMT
Links: << >>  << T >>  << A >>
FPGA vendors all feel that their programming bitstreams reveal information
about their chips' architectures that they'd rather keep to themselves.
Do you think that if Intel could do this they wouldn't?  They've tried as
hard as they could (legally and by other means) to keep others from distri-
buting clones of their chips, but there's only so much they can do.  If
they could somehow avoid publishing the instruction set they surely would.  To
ascribe altruistic goals to Intel or sinister ones to Xilinx would be
unfair; they're both trying to do business in the way they think will have
the greatest positive effect on their stock price.  Their businesses are
sunstantially different, which gives them different options.


Article: 85
Subject: Re: Would you like a free C to netlist compiler?
From: jwills@coolpro.melpar.esys.com (Jeff Wills)
Date: Thu, 11 Aug 1994 20:50:50 GMT
Links: << >>  << T >>  << A >>
chris@lslsun7.epfl.ch (Christian Iseli) writes:

>As a part of the Spyder project (the development of a reconfigurable
>processor using FPGAs), a student here has written a compiler that
>translates a subset of C (only one data type, functions, for loops and
>conditionals) into a netlist for ViewLogic (a wirelist file) but it
>should be relatively easy to produce another netlist format. If there
>is enough interest, I'd be willing to release the sources of this
>compiler under the GNU GPL.

YES. I would be very interested in a release of this work.  My
interest is similar to yours -- I need to simulate (emulate) HW/SW
systems.

>The interest to describe circuitry in C lies, for me, in the fact of
>being able to simulate it (or better said, to emulate it) as part of a
>larger C++ (or C) program. That's why this compiler came into being.

>					Christian Iseli
>					LSL-DI-EPFL
>					Lausanne, Switzerland

Jeffrey Wills
E-Systems, Inc., Melpar Div.
Ashburn, VA
jwills@melpar.esys.com



Article: 86
Subject: Re: Wanted: Literature on Reconfigurable Systems..
From: lbarroso@pollux.usc.edu (Luiz Andre' Barroso)
Date: 11 Aug 1994 16:44:54 -0700
Links: << >>  << T >>  << A >>
pagey@ECE.Concordia.CA (Sandeep Pagey) writes:

Here at USC we are implementing a hardware emulator for entire
multiprocessor systems based on FPGAs. A technical report that
describes the project and its goas is available for anonymous
ftp from "usc.edu:pub/CENG" (tech rep. = CENG-94-15.ps.Z).

Title and abstract follows. If you are interested in further
information please contact Prof. Michel Dubois (dubois@paris.usc.edu)
or myself.

--Luiz Barroso (barroso@paris.usc.edu)

***********************************************************************
File: CENG-94-15.ps.Z
 
Title: The USC Multiprocessor Testbed Project: Project Overview
Authors: Michel Dubois, Luiz Barroso, Sassan Iman, Jaeheon Jeong, Koray
         Oner, Krishnan Ramamurthy
Technical Report No. CENG-94-15
 
Abstract: (the report does not have an abstract. The following is extracted
           from the introduction)
 
Because multiprocessors are complex and powerful the correctness of a design
and its expected performance are very difficult to evaluate before the machine
is built. Traditionally two approaches have been taken to verify a design:
breadboard prototyping and software simulation. A prototype is costly, takes
years to build and explores a single or a few design points. Discrete-event
simulation is very flexible but very slow if the design is simulated in details
and is subject to validity problems. The parallelization of discrete-event
simulation is an ad-hoc procedure and usually exhibits poor speedup. Because
the code (either source or binary) must be instrumented, itis difficult to run
interesting workloads, other than multitasked scientific programs.
 
The major research goal of this project is to build a common, configurable
hardware platform to emulate faithfully the different models of MIMD systems
with up to 8 processors. Emulation is orders-of-magnitude faster than
simulation and therefore an emulator can run problems with the real data set
sizes (the ones for which the target machine is designed). Emulation is more
faithful to the target implementation than simulation and therefore more
reliable performance evaluation and design verification can be done with
emulation. Finally, an emulator is a real computer with its own I/O and the
code running on the emulator is not instrumented. As a result, the emulator
"looks" exactly like the target machine to the programmer and runs any binary
including binaries from production compilers, operating systems, and software
utilities.
***********************************************************************


Article: 87
Subject: Re: Would you like a free C to netlist compiler?
From: ylin@nthu.edu.tw (Youn-Long Lin)
Date: 12 Aug 1994 00:35:19 GMT
Links: << >>  << T >>  << A >>
Christian Iseli (chris@lslsun7.epfl.ch) wrote:
> (Sorry if you see this twice. I tried to send it yesterday, but
> it didn't seem to go through)

...

> So, folks, let's hear from those that are interested!!

Yes, I'll be interested in it.


-Youn-Long Lin
 Tsing Hua University
 Taiwan


Article: 88
Subject: Re: Proprietary Configuration Data
From: cgtscha@afterlife.ncsc.mil (Christopher G. Tscharner)
Date: Fri, 12 Aug 1994 02:29:22 GMT
Links: << >>  << T >>  << A >>
References: <776540488snz@rhizik.demon.co.uk> <32cbj9$ptb@Mercury.mcs.com>
Sender: 
Followup-To: 
Distribution: 
Organization: US Dept. of Defense
Keywords: 

In article <32cbj9$ptb@Mercury.mcs.com> adyer@MCS.COM (Dru) writes:
>Just as a fun twist in this whole thing - has anybody looked at the
>Atmel "Cache Logic" reconfigurable FPGAs?  Is the actual configuration
>bitstream open or is it just that given their tools you can generate
>multiple bitstreams to reconfigure the logic?
>

I believe what makes the Atmel FPGAs unique among SRAM FPGAs is the ability
to reprogram only a portion of the total device while the rest remains 
configured, allowing for "self (same device) modifying designs".  I don't
know how they feel about their bitstream.  It stands to reason, however,
that they would probably be the best to approach about getting a bitstream
spec if one wanted to do experimentation with such designs.  If they saw
a good proposal requiring the bitstream spec and saw HW money in it, giving out
the bitstream spec might be an option.  Recall that they are definitely in the
second string if only FPGAs are considered, the Atmel FPGAs gained from 
Concurrent when that company couldn't remain viable on its own.  Capitalizing
on the unique features of their architecture may be their best hope for 
turning a profit on FPGAs.

Chris Tscharner
Sr. Electronic Engineer
DoD
(301) 688-5503 (voice)
(301) 688-1112 (FAX)


Article: 89
Subject: Re: Microprocessors implemented with FPGAs
From: devb@char.vnet.net (David Van den Bout)
Date: 12 Aug 1994 08:55:10 -0400
Links: << >>  << T >>  << A >>
In article <1994Aug11.111527@timp.ee.byu.edu>,
Brad Hutchings <hutch@timp.ee.byu.edu> wrote:

>microprocessors implemented with FPGAs. I was wondering what else
>was out there. I am specifically interested in any work regarding
>microprocessors implemented on a single FPGA. I have already looked

The last four chapters of my book describe a simple 4-bit microcontroller
implemented in an Intel FLEXlogic FPGA using 61 of the 80 available
macrocells.  The PLDasm HDL file for the design is on the ftp server
ftp.intel.com.  The file is stored in the directory
pub/pld_fpga/designs/fpga_workbook/gnome3.pds (or something like that).
If you can't find it, I'll e-mail it to you.  It's not long -- less
than 200 lines with comments.


-- 

||  Dave Van den Bout  ||
||  Xess Corporation   ||


Article: 90
Subject: Re: Proprietary Configuration Data
From: hutch@timp.ee.byu.edu (Brad Hutchings)
Date: 12 Aug 1994 12:41:46 -0600
Links: << >>  << T >>  << A >>


|> I believe what makes the Atmel FPGAs unique among SRAM FPGAs is the ability
|> to reprogram only a portion of the total device while the rest remains 
|> configured, allowing for "self (same device) modifying designs".  I don't
|> know how they feel about their bitstream.  It stands to reason, however,

|> Chris Tscharner
|> Sr. Electronic Engineer
|> DoD
|> (301) 688-5503 (voice)
|> (301) 688-1112 (FAX)


We use the National version of the Atmel device (CLAy) here in our lab
which is more or less the same thing as the Atmel device. It supports
partial configuration; however, that is not the same thing as 
"self-modifying" hardware. That would require an internally addressable
configuration store. The configuration store of the Atmel device can
only be addressed *externally*. Thus all configuration data must come
from a source external to the FPGA.
Of course, there is nothing fundamental preventing
one from designing an FPGA with an internally addressable configuration
store that could be used to implement self-modifying hardware. I am
not aware of any commercial offerings that support internal addressing
of the configuration store.

-- 
Brad L. Hutchings
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-2667

-- 
Brad L. Hutchings
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-2667



Article: 91
Subject: John Cooley is looking for FPGA/Synth Benchmarks
From: ep520mi@pts.mot.com (MARK INDOVINA Xxxxx Ppppp)
Date: Fri, 12 Aug 1994 20:23:42 GMT
Links: << >>  << T >>  << A >>
I received this in the mail yesterday and thought the group might
be able to reply to John with some useful information.

!!!!!  PLEASE DON'T REPLY TO ME !!!!!
ALL REPLY'S SHOULD BE FORWARDED TO: jcooley@world.std.com

>From jcooley@world.std.com Thu Aug 11 17:57:32 1994
>Received: from pobox.mot.com by pts.mot.com (5.0/SMI-4.1)
	id AA12604; Thu, 11 Aug 1994 17:53:15 +0500
Date: Thu, 11 Aug 1994 17:54:14 -0400
From: jcooley@world.std.com (John Cooley)
To: mark_indovina@pts.mot.com
Subject: For EDN Article - Call For FPGA/Synth Benchmarks
Content-Type: text
Content-Length: 2747


 CALL FOR BENCHMARKS INVOLVING FPGA's & SYNTHESIS FOR EDN ARTICLE

    For quite some time FPGA synthesis companies have been howling on how
 difficult it is for any customer to benchmark their FPGA synthesis tool and,
 hence, benchmarking is an evil to be avoided.  I get responses from the
 vendors like: "It depends on the user's expertise with *our* tool; they
 mess up and *we* gotta live with a bad benchmark." and "Some FPGA/CPLD
 architectures are synthesis-friendly while others are downright synthesis
 hostile."

    Instead of taking the FPGA synthesis vendor's word at this, I'd like to
 put out a call for benchmarks that people have done using various FPGA
 synthesis tools.  (It's for a feature article in EDN magazine.)  My goal
 isn't to have one synthesizer "win" in the benchmarks -- but to explore
 how five different people came up with five completely different rankings
 of FPGA synthesizers because they approached the process from slightly
 different angles.  That is, let's see if the FPGA synthesis benchmarking
 process is as fickle as the vendors like to claim!

    Overall for this article, I'd like to take the Oklahoma state motto
 "Show Me" approach.  Is one benchmarking user ranking the tools A, B, C, D
 while another unrelated benchmarking user ranking them C, B, A, D with
 a third user seeing D, C, B, A -- all because of minor variances in
 benchmarking methodologies?   Let's see!

    As always, I'm more than willing to use anonymous sources on this because
 of the political problems involved.  But my gut hunch is that EDA vendors
 won't be hostile, though, if there is as much benchmarking variability as
 they like to claim.  (If there really isn't that much variability in
 benchmarks, that will make for an even more interesting story, too!) So,
 please, if you have something, e-mail "jcooley@world.std.com" or phone me at
 (508) 429-4357 soon -- got press deadlines to keep!


                              - John Cooley
                                riffraff EDA Consumer Advocate
                                (and the ESNUG guy, too!)

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3074 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."



-- 
/* Mark A. Indovina,     mark_indovina@pts.mot.com                        */
/* Motorola, Inc.,  Applied Research, Advanced IC Technology Laboratory   */
/* Mail Stop 63, 1500 Gateway Avenue, Boynton Beach, FL 33436-8292 USA    */
/* phone, 1-407-364-2379,   fax,   1-407-364-3904                         */


Article: 92
Subject: Re: Would you like a free C to netlist compiler?
From: mikelh@zonta.ping.de (Michael Hasselberg)
Date: Sat, 13 Aug 1994 10:25:46 GMT
Links: << >>  << T >>  << A >>
chris@lslsun7.epfl.ch (Christian Iseli) writes:


>As a part of the Spyder project (the development of a reconfigurable
>processor using FPGAs), a student here has written a compiler that
>translates a subset of C (only one data type, functions, for loops and
>conditionals) into a netlist for ViewLogic (a wirelist file) but it
>should be relatively easy to produce another netlist format. If there
>is enough interest, I'd be willing to release the sources of this
>compiler under the GNU GPL.



>So, folks, let's hear from those that are interested!!
 
I am *very* interested
 Mike
-- 
==============================================================================
| Michael Hasselberg            |    Tel.(voice/fax/modem): +49 2335 61220   |
| Grundschoetteler Str. 125b    |    Email: mikelh@zonta.ping.de             |
| 58300 Wetter                  |    CompuServe: 100303,1044                 |


Article: 93
Subject: Re: Response to Emulation Systems
From: mbutts@netcom.com (Mike Butts)
Date: Sat, 13 Aug 1994 21:49:14 GMT
Links: << >>  << T >>  << A >>
>My name is Ken Reiter; I am a 
>Emulation Specialist with Quickturn Design Systems, 
>based in Dallas, Texas.

>I am sorry that any requested information from
>our Mt. View office was not sent to you.

>THIS IS A OPEN OFFER -

>ANYONE WHO WOULD LIKE INFORMATION ON QUICKTURN's
>PRODUCTS MAY CALL OR EMAIL ME FOR THE INFORMATION.

>Ken Reiter 
>Emulation Specialist
>Quickturn Design Systems
>214-516-3831

Ken's email address is ken@qcktrn.com

       --Mike

-- 
Mike Butts, Portland, Oregon   mbutts@netcom.com



Article: 94
Subject: FPGA Hobbyist and their software/programmer/hardware
From: mcgett@xilinx.com (Ed McGettigan)
Date: Sat, 13 Aug 1994 21:55:00 GMT
Links: << >>  << T >>  << A >>
I'm getting a bit confused over some of the concerns that want-to-be 
FPGA Hobbyist are having.  I think it boils down to the following:

  1. First you need to have a design that takes up a lot of gates
     somewhere above a 1000 at least, before you would even want to
     look at FPGAs like the XC3000 or XC4000 series.  If you have
     smaller designs check out a PLD manufacture like Xilinx, Lattice
     Atmel, etc ..  Usually the (E/C)PLD place/route/program software
     is given away. 

  2. Now you need a design entry system. Do you want entry to be a 
     schematic based system or a HDL system (ABEL, VHDL, Verilog, ..)
     and the design entry system needs to support the target technology
     libary.  This is usually not much of a problem as you can get the
     data for the cells out of a databook.  But this software can range
     from VERY Expensive to Shareware with no support.  The FPGA house
     rarely provide a DES as we believe that 3rd party vendors can do
     this much better than we can.

  3. You need a dynamic simulator that interfaces with your DES.  You   
     should be able to get one from your DES source.  Again you will     
     need a support library.  This also ranges from very expensive to
     shareware.

  4. You need a place and route tool that can read the output from 
     your DES.  This is the most compilicate of them all and the one 
     that is usually supplied by the FPGA House.  The only notable 
     exception to this is NEOCAD which supports a number of different 
     vendors and has a high price.  This is the most important piece 
     of software to develop as you need detailed information about the 
     chip architecture and design rules to do anything.

  5. You need a static timing analyzer that interfaces with you P&R
     to determine how fast the chip will run and what the I/O timing
     interface is like.  This is sometimes provided by the FPGA house
     or their P&R will allow back annotation of timing values into a
     3rd party vendor tool.

  6. Finally you need to generate the programming bit stream from the
     P&R. 

  7. You need a programmer to program the chip.  This isn't a big 
     deal for SRAM based devices, but for Anti-Fused based devices
     it certainly is, but I doubt most hobbyists would used an anti-fuse
     chip so that isn't very important.


The FPGA houses will provided at a bare minimum the place and route tool
and the programming software and some version of a timing analyzer. But
all of this requires a great deal of time and money to develop and support.

Yes, you can argue that once a piece of software is written that the cost
per copy is negligible ~$15.00 or so with all of the manuals.  But the biggest
cost is in support for the product.  If the FPGA house sold the software to
anyone with $50-$100 and a programmer for another $20 the resulting support
calls would dwarf any profit that would generated by the hobbyist.  So there
is no driving economic force to drop the price below $1000.  Note: In a recent
EE Times a Distributor had an ad for the Xilinx Basic Development Kit for $995 
and if you could guess the number of chips in the jar it was FREE. (NO I 
don't know the answer.)

If some group could develop all of the pieces for a shareware design system.
I'm sure the FPGA houses would be willing to unbundle the part that actually
generates the programming stream.  


BIG TIME DISCLAIMER: This post is my own personal opinion on this topic and 
                     is NO way endorsed or supported by Xilinx.

-- 
+----------------------------------------------------------------------+
|Edward McGettigan  | Xilinx Inc.  "The Programmable Logic Company" sm | 
|mcgett@xilinx.com  | FPGA Applications Engineer (408)879-4772         |
+----------------------------------------------------------------------+


Article: 95
Subject: translator needed
From: cho@balboa.eng.uci.edu (Jae Cho)
Date: 13 Aug 1994 22:34:44 GMT
Links: << >>  << T >>  << A >>
Hi;

I am looking for a free or very inexpensive translator
that will translate XILINX design to a structural Verilog
or EDIF netlist.  I have tried Viewlogic's EDIF translator,
but it contains not only the primitive elements but also
the simulation related delays and so on.  My intent is to
be able to simulate a design with multiple XILINX devices
using Verilog XL (for the functionality for the time being).
If anyone knows such SW, please let me know.

Thank you very much.

Sincerely,

Jae Cho.


Article: 96
Subject: Re: FPGA Hobbyist and their software/programmer/hardware
From: yuri@shimari.cmf.nrl.navy.mil (Yuri Trifanov)
Date: 14 Aug 1994 15:37:10 GMT
Links: << >>  << T >>  << A >>

> If some group could develop all of the pieces for a shareware design system.
> I'm sure the FPGA houses would be willing to unbundle the part that actually
> generates the programming stream.  

rather a chicken and egg problem isn't it? what group of public domain
implementors would bother working on the necessary pieces without knowing
for sure that it would do them some good in the end.

> Yes, you can argue that once a piece of software is written that the
> cost per copy is negligible ~$15.00 or so with all of the manuals.
> But the biggest cost is in support for the product.  If the FPGA
> house sold the software to anyone with $50-$100 and a programmer for
> another $20 the resulting support calls would dwarf any profit that
> would generated by the hobbyist.

so sell it without support.

I realize you have a huge investment in the software..but to a lot of
us wanting to work at a low level and generate designs ourselves, and
don't think it's reasonable to buy and manage a DOS PC to run a node-locked
software system on...your chips are nearly useless, nice as they are



Article: 97
Subject: Re: FPGA Hobbyist and their software/programmer/hardware
From: pclink@qus102.qld.npb.telecom.com.au (Rick)
Date: Mon, 15 Aug 1994 00:10:50 GMT
Links: << >>  << T >>  << A >>
mcgett@xilinx.com (Ed McGettigan) writes:

>Yes, you can argue that once a piece of software is written that the cost
>per copy is negligible ~$15.00 or so with all of the manuals.  But the biggest
>cost is in support for the product.  If the FPGA house sold the software to
>anyone with $50-$100 and a programmer for another $20 the resulting support
>calls would dwarf any profit that would generated by the hobbyist.  So there

	1.	Sell it without support.  Jeez, the reason we do hobby type
		stuff is because we are smart and self motivated.  If we can't
		figure out how to operate a piece of software, we don't
		belong in the game.
	2.	Sell the software cheap but charge for support.  Those that
		can figure it out for themselves are happy, those who can't
		pay for the knowledge and are happy, and the house is happy.

Rick.
-- 
Rick "JT" Lyons   | C/C++/x86/X           | What claim?  Dis claim!
Telecom Australia | Unix/DOS/Novell       | Usenet before net uses you.
ACN 051 775 556   |                       | 
work:pclink@qus102.qld.npb.telecom.com.au | play:rick@razorback.brisnet.org.au


Article: 98
Subject: Re: FPGA Hobbyist and their software/programmer/hardware
From: jsmith@red-branch.MIT.EDU ()
Date: 15 Aug 1994 01:19:43 GMT
Links: << >>  << T >>  << A >>
Yuri Trifanov (yuri@shimari.cmf.nrl.navy.mil) wrote:

: > If some group could develop all of the pieces for a shareware design system.
: > I'm sure the FPGA houses would be willing to unbundle the part that actually
: > generates the programming stream.  

: rather a chicken and egg problem isn't it? what group of public domain
: implementors would bother working on the necessary pieces without knowing
: for sure that it would do them some good in the end.

SO find out WHO would be willing to unbundle the part that generates the 
programming streams ahead of time, ie before jumping into development of
the software.

Hrm.. I'll even volunteer to organize such a venture if there are enough 
people interested in putting forward time and effort into such a thing.


: > Yes, you can argue that once a piece of software is written that the
: > cost per copy is negligible ~$15.00 or so with all of the manuals.
: > But the biggest cost is in support for the product.  If the FPGA
: > house sold the software to anyone with $50-$100 and a programmer for
: > another $20 the resulting support calls would dwarf any profit that
: > would generated by the hobbyist.

: so sell it without support.

: I realize you have a huge investment in the software..but to a lot of
: us wanting to work at a low level and generate designs ourselves, and
: don't think it's reasonable to buy and manage a DOS PC to run a node-locked
: software system on...your chips are nearly useless, nice as they are




Jonathan Smith


Article: 99
Subject: synopsys fpga libraries prices
From: yaron@xvnews.unconfigured.domain (yaron kretchmer)
Date: 15 Aug 1994 09:20:09 GMT
Links: << >>  << T >>  << A >>
Does anybody know the prices of FPGA libraries for synopsys
(i.e XILINX,QUICKTURN,ATMEL etc.)



---
************************************************************************
*  Yaron Kretchmer                   LSI Logic ISRAEL          ------  *
*  Phone  +972-3-5403741                 Sokolov 40       LSI | LOGIC| *
*  Fax    +972-3-5403747                 Ramat Hasharon       |      | *
*                                        Israel 47100         |      | *
*                                        P.O.Box 1331         -------- *
*  email  yaron@lsi-logic.co.uk or      (outside LSI)                  *
*								       *
*								       *
*								       *
*	disclaimer: these views are mine, only mine		       *
************************************************************************







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