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
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
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
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.caArticle: 78
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
(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, SwitzerlandArticle: 80
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
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-2667Article: 82
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-2667Article: 83
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.eduArticle: 84
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
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.comArticle: 86
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: 87Christian 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 TaiwanArticle: 88
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
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
|> 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-2667Article: 91
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: 92chris@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
>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
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: 95Hi; 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
> 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 areArticle: 97
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.auArticle: 98
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 SmithArticle: 99
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:
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