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
eml@riverside-machines.com.NOSPAM wrote: > What's Praxis? Practice, or practical experience. German. Thus do we unmask those who would conceal their nationality behind a .com address :-) Jonathan BromleyArticle: 26176
Jonathan Bromley wrote: > eml@riverside-machines.com.NOSPAM wrote: > > What's Praxis? > > Practice, or practical experience. German. > > Thus do we unmask those who would conceal their > nationality behind a .com address :-) > > Jonathan Bromley ... or someone who did to much Marxism in their youth.Article: 26177
Nicolas Matringe wrote: > Marc Reinert a écrit : > > > > Hi > > > > when I try to download my program on a FPGA (XC4003) via JTAG-port > > there is no reaction of my hardware. > > > > To test this function I'm using a demoboard (XC4000). My testprogram > > asserts some LED on this board. It works fine when I download the > > program with the Hardware Programmer (using D/P, DIN, CCLK, /PROG) - > > but it doesn't work when I try to use the JTAG-Port (TDI, TDO, TCK, > > TMS). > > Hi > Are you using the same .bit file in both cases? > I had a similar problem with a Virtex some time ago: I had to use the > JTAG clock as the Startup Clock (run bitgen with the -g > startupclock=jtagclock option) or it wouldn't work. > I don't know if it's the same with XC4000 parts > This issue comes up so often it seems like everybody in this newsgroup has been bitten by it at least once, I certainly was. The problem is that the documentation doesn't put this info anywhere obvious like on page 1 of the JTAG programmer manual in large red letters. This is compounded for those using the GUI since they probably would not have worked their way through the bitgen part of the manual - that's how I eventually figured it out. In fact it would be easy enough to get the programmer to check the .bit file to see if the JTAG clock had been selected for start-up. It may even be a rare case for one of those usually irritating ``OK'' pop-ups to ask whether you want to change the start-up clock.Article: 26178
In article <39DC9ABB.E21D986C@soton.sc.philips.com>, Iwo.Mergler@soton.sc.philips.com (Iwo Mergler) wrote: > Daniel Nilsson wrote: > > > > Hi. I wonder what it would take to make a sharc dsp to pci controller > > (I > > only need very basic pci functionality, enough to control a pci > > ethernet > > card, with dma). > > PLX or AMCC make the stuff you need... > > http://www.plxtech.com/ > http://www.amcc.com/ Unless things have changed recently, they don't quite provide the complete answer. You need some additional glue for all the PCI controllers I've seen. (There's an AD app note describing how to use the PLX 9080/9054.) For the very simple case in the original posting, it's expensive overkill to use one of these all-singing, all-dancing controllers. There are a /lot/ of shortcuts you can take when you're effectively doing a point-to-point channel. -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 26179
brian13074@my-deja.com wrote: > > (Project Leader, Architecture Modeling) > > I'm a headhunter who specializes in Engineering, > ASIC, ATM and related fields. > > I currently have opportunities available for ASIC Design Engineer > professionals with a dynamic company. [snip all the other stuff] Last I checked, this newsgroup was called comp.arch.fpga. Dig? -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 26180
i had also some problems when itried to configure my FPGA PROM from jtag programmer, i found sommw answers in xilinx database, and from them i understood i had to do some combination of prom programer +jtag programmer and also tou use the jtag programmer 3.1 from xilinx webpack site about 10mb file ! and of course i had to register and registration didn't work cause i also registerd on the foundation but from some reason it wasn'nt good for this registration so i had to register again and finally every thing worked - surprisiingly. In article <39DDD56A.864F61A0@tu-harburg.de>, Marc Reinert <reinert@tu-harburg.de> wrote: > Hi > > when I try to download my program on a FPGA (XC4003) via JTAG-port there > is no reaction of my hardware. > > To test this function I'm using a demoboard (XC4000). My testprogram > asserts some LED on this board. It works fine when I download the > program with the Hardware Programmer (using D/P, DIN, CCLK, /PROG) - but > it doesn't work when I try to use the JTAG-Port (TDI, TDO, TCK, TMS). > > What I did first is to start the JTAG-Programmer. Then I can see my > devices a the right *.bit is shown in that window. After that I select > "program". It seems to work but no LEDs are asserted. > > My Log-File says: > > "JTAG Programmer Started 2000/10/06 14:14:40 > Loading Boundary-Scan Description Language (BSDL) file > 'C:/Programme/Fndtn/xc4000e/data/xc4003e_pc84.bsd'.....completed > successfully. > Checking boundary-scan chain integrity...done. > Verifying device positions in boundary-scan chain... > Verification completed. > Boundary-scan chain validated successfully. > 'light(Device1)': Checking boundary-scan chain integrity...done. > 'light(Device1)': Reading bit-stream file...done. > 'light(Device1)': Programming device...done. > 'light(Device1)': Programming completed successfully." > > I've selected all possibilities of the mode-settings but it didn't work. > What's wrong? > > Marc > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26181
Andy Peters wrote: > brian13074@my-deja.com wrote: > > > > (Project Leader, Architecture Modeling) > > > > I'm a headhunter who specializes in Engineering, > > ASIC, ATM and related fields. > > > > I currently have opportunities available for ASIC Design Engineer > > professionals with a dynamic company. > > [snip all the other stuff] > > Last I checked, this newsgroup was called comp.arch.fpga. Dig? > Isn't it amazing how few static companies full of amateurs there are ?Article: 26182
Hi, > > "Gary Cook" <gary_cook@ntlworld.com> a écrit dans le message news: > > 39DCFE2C.82E5AF94@ntlworld.com... > > > Running Maxplus 9.64 and am having problems getting > > > internal errors during fitting ... sometimes during > > > partitioner and even 1% through netlist compiler. It's I have the same problem but in my case it only seems to affect the newer devices such as the ACEX 1K range - its a pain though as my design is using an ACEX 1K30 and its a worry to see numerious crashes of the compiler. Christopher FairbairnArticle: 26183
I am facing the same problem, but I could not get the solution till now In article <39DDD56A.864F61A0@tu-harburg.de>, Marc Reinert <reinert@tu-harburg.de> wrote: > Hi > > when I try to download my program on a FPGA (XC4003) via JTAG-port there > is no reaction of my hardware. > > To test this function I'm using a demoboard (XC4000). My testprogram > asserts some LED on this board. It works fine when I download the > program with the Hardware Programmer (using D/P, DIN, CCLK, /PROG) - but > it doesn't work when I try to use the JTAG-Port (TDI, TDO, TCK, TMS). > > What I did first is to start the JTAG- Programmer. Then I can see my > devices a the right *.bit is shown in that window. After that I select > "program". It seems to work but no LEDs are asserted. > > My Log-File says: > > "JTAG Programmer Started 2000/10/06 14:14:40 > Loading Boundary-Scan Description Language (BSDL) file > 'C:/Programme/Fndtn/xc4000e/data/xc4003e_pc84.bs d'.....completed > successfully. > Checking boundary-scan chain integrity...done. > Verifying device positions in boundary-scan chain... > Verification completed. > Boundary-scan chain validated successfully. > 'light(Device1)': Checking boundary-scan chain integrity...done. > 'light(Device1)': Reading bit-stream file...done. > 'light(Device1)': Programming device...done. > 'light(Device1)': Programming completed successfully." > > I've selected all possibilities of the mode- settings but it didn't work. > What's wrong? > > Marc > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26184
I dont have any problem running on either platform. In article <8rk35d$kbm$1@ccpntc8.in2p3.fr>, "JPC" <cachemi@cppm.in2p3.fr> wrote: > I'm running on NT and have a similar problem. > As I haven't any reply from Altera's support on this issue, I solved it in > reinstalling the 9.5 version. > Works fine now. > > Jean-Pierre > > "Gary Cook" <gary_cook@ntlworld.com> a écrit dans le message news: > 39DCFE2C.82E5AF94@ntlworld.com... > > Running Maxplus 9.64 and am having problems getting > > internal errors during fitting ... sometimes during > > partitioner and even 1% through netlist compiler. It's > > not consistant at all ... I can run fine for a while and > > then bang! all of a sudden I can't compile a thing. > > Altera support aren't much help and the web-site mentions > > a similar error but doesn't give much help either ... > > just wondering if anyone here's got any info that could > > help... > > > > not sure if it's an os thing ... running it on nt and get no > > problems, running on win98 and get problems ... ??? > > > > Cheers, > > > > Gary Cook. > > > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26185
Hi there,
<eml@riverside-machines.com.NOSPAM> wrote in message
news:39dda3e0.7605609@news.dial.pipex.com...
> On Thu, 5 Oct 2000 23:43:16 +0200, "Domagoj" <domagoj@engineer.com>
> wrote:
> Wrong newsgroup - try comp.lang.vhdl. What's Praxis? The LRM specifies
I tried comp.lang.vhdl, but got no answer... :( . Sorry for praxis,
i tought it was an english expression...
> a minimum range for integers and reals, and you're free to increase
> the range if you want. You'll probably want to increase the integer
> range by at least 1, but this will probably lead to non-portable
> behaviour. Std_logic isn't defined in the LRM because it's simply an
> extra enumerated type, which users have agreed on. However, you will
> need to put in acceleration for standard packages such as
> std_logic_1164, numeric_std, VITAL, and so on.
Thanks. But I meant of more subtle things, that might make problems
in vhdl parsing. For example : if there are two subprograms with the same
signature visible within some architecture, Ashenden states that
neither one of them is visible. On the other side, some simulator
manuals state that if there are two subprograms with the same signature,
some programs prefer the explicit one (if another is implicit). I didn't
understand that one pricesly. The manual stated that this case is found
in practise. I wanted to know what other deviations from LRM could
be find in practise.
> You'll find that some simulators interpret bits of the LRM
> differently, and you'll have to find out for yourself which bits they
> are. A good place to start would be the documentation for the
> 'compatibility' flag on Cadence's Leapfrog, or possibly NC.
> Good luck! You'll need it.
> Evan
Thanks. Regards,
-------------------------------------------
- Domagoj -
- Domagoj@engineer.com -
-------------------------------------------
Article: 26186Been there, done that. My solution (all homebrewed) can be seen at http://members.iinet.net.au/~daveb/tricks/fpga-ldr/loader.html s_sharma@my-deja.com wrote: :I am facing the same problem, but I could not get :the solution till now : :In article <39DDD56A.864F61A0@tu-harburg.de>, : Marc Reinert <reinert@tu-harburg.de> wrote: :> Hi :> :> when I try to download my program on a FPGA :(XC4003) via JTAG-port there :> is no reaction of my hardware. :> [snip]Article: 26187
Hi all, I need to implement an interface to a TMS320C54x (TI Fixed-Point DSP) in a Spartan-II FPGA, and want to map the FPGA as a memory to enable fast access time. I am looking for a Ref design, tip or App Note that will help me to get started on this. Any comment will be highly appreciated. Thanks in advance, Mike. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26188
Maciek, There is a known compatibility problem of SRP3 and localized OS. We just got the patch (some XML files from Xilinx)for our Hebrew enabled Windows. You should contact your local FAE about that. Good luck, Rotem Gazit. In article <39DD975A.925549F5@fuw.edu.pl>, Maciek Kudla <kudla@fuw.edu.pl> wrote: > After installation sp3 for Foundation 3.1 (Win98) I can not implement > any vhdl code. > Project menager stops with following message: > *** > Reading component libraries for design expansion... > Annotating constraints to design from file "race.ucf" ... > Checking timing specifications ... > Checking expanded design ... > The XML Parser environment is incorrectly set up, preventing it from > finding its text transcoding files. Normally these will be located > via the ICU_DATA environment variable, or located relative to the > XML4C2 DLL (or SharedLib.) Please check your installation > *** > Sombody knows what it is? > > Maciek > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26189
I absolutely agree about the lack of documentation on this subject (also had this problem...). An elegant workaround for GUI (and command line) users is to edit the .UT file that is automatically generated in every project directory. Rotem. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26190
In article <39D65306.42F19CF5@andraka.com>, Ray Andraka <ray@andraka.com> wrote: > best I could tell, synplify pro just has a bunch of bells and whistles I wasn't > going to use anyway. I'm sticking to 6.0 plus the RTL analyst. It looked like > pro gives you the analyst as part of the package, plus a different GUI, the > ability to sprinkle pipeline registers inside multipliers (Big Fat Hairy Deal if > you construct the logic you need anyway), ability to have two designs open at > once and a few other little things. Nothin I could see there justified the big > price difference. It does support the wire probe feature, which comes in very handy when you have to debug a design and have some spare IOs available. Basically, the feature allows you to tag any net in your hierarchy for probing on a pin. This gets around the nasty "push the signal up through the hierarchy" method. Granted, it's a high price to pay, but considering the alternatives... I'm more than happy to pay a higher price for Synplicity (Pro or not) than for FEXP. Synplify is simple to use, gets the job done and their staff is very helpful. Stefan Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26191
Warning, newbie post: a) I am new to FPGAs, still trying to get up to speed, find out what I need to do it, get the tools; no actual design or experience yet. b) I am still recovering from the shocking realisation, that I can not simply download GNU gvhdl and type out some first-project.vhdl, compile it, get a board from someone like XESS and let it run. rickman <spamgoeshere4@yahoo.com> writes: > Jamie Lokier wrote: > > > > Ray Andraka writes: > > > ... doesn't require my customer to have the extras to support the design. > > > > Is it principally due to $$$, or training & tool familiarity? For hobbyists [1] new to the game it is partly financial cost and far bigger part the need to run an non-open source operating system, just to develop FPGAs (what? not my trusty editor and source code managment tools I use for C?). [1] in the eyes of some an irrelevant market, because of low volume/person chip sales. But these are those who may make FPGAs their next (or after next) job, when they get fed up with writing yet another web application. And there are a lot of hobbyist out there looking for new interesting stuff to get into. Familiarity is irrelevant to new users (they are not familiar with anything yet). And there are more new users to come than presently around (time looks for that). > > Specifically, if there was a really good GPL synthesis tool (no license > > fee + you have the source), and the tool suited your style of work, > > would you use it for customer project? Even if there were an really crappy, limited, one chip only tool the "early adopters" of the open source scene would simply hack it up until it is good for their personal use. Then as it is a bit better someone else continues hacking, then another, ..., and all of a sudden it is quite an decent tool, sort of. Linux 0.01 really did suck, only 2 possible hard disk types, one video card, no graphics, no mouse, ..., around 0.95 it got usable. 2.2 still has next to no USB (only keyboard/mouse) and no Firewire. > > Or would there still be a > > significant non-technical barrier for use of a new tool? Consultants may have problems getting their customers to accept that they are not using "the best professional stuff", as open source users software had up until last year. Only 2 years ago Bob metcalfe (Inventor of Ethernet) said that Linux users were "like lemming jumping off the cliff of well engineered professional software". > > I was talking to an Altera FAE who felt that going into competition with > > Synplicity on synthesis via the GPL route No need for Altera or Xilinx or any other chip vendor to make an GPLed program. Simply release _to_anyone_who_wants_it_ (translate: put on your web site) _all_ the bitstrem format information that todays tool vendors get. Leave it to the open source people to come up with their tools. Intel did not make Linux, they just gave everyone (including Linus Torvalds) the documentation on how 80x86 binary format looks like. Then the open source hobbyists strook. Yes, this did then take a few years until people could use Linux for production jobs (I switched 1994). Better than no Linux at all. > > customers are far too reluctant to switch tools. Given the present situation on the FPGA market, which reminds me of to the 1960s and early 1970s mini computer market, today users are a very small subset of the FPGA programming population that could be in a few years, if an personal hardware revolution similar to the personal computing revolution of the late 1970s happens. There still are a few PDP-11s running and a few people programming them, but the majority of todays programmers started their careers on PCs. Just think of an large (millions of units per year) market for premade FPGA containing boards. Then of 100'000s of programmers shaping them to their uses. > > (The Altera connection was because the FAE thought Synplicity had access > > to low-level FPGA data that even he did not have, Bitstream format? How are them bits scattered to the controlling SRAMs in the chip? Synplicity has to know this to create bitstreams. This is the equivalent of knowing the 80x86 code to write an C compiler (which Intel publishes). Does the FAE have that info? The general FPGA programming public has not. At least I have not managed to find it on any FPGA vendors web site (I have tried Actel, Altera, Atmel, Gatefield, Lattice, Lucent and Xilinx so far). I only keep on seeing "get out tool". > > and despite saying > > that Altera are 100% a hardware company they still won't be making it > > easy for third parties to develop good bitstream-level optimisers). Actually impossible to even make an bad bitstream generator, so long the format is not publically known. > One is the fact that there is a much smaller market for the end use of > the tool. The market for 8080s in 1975 was no larger than todays FPGA market. If anything a lot smaller. And Intel thought it was all about control systems. Then the hobbyists made the PC revolution. Since then there is a huge market for PC programming tools, commercial and open source. > So development costs a lot more when spread over the smaller > user base. Certainly customers are sensitive to tools costs. Think zero cost. Just web download. 1975 there were only floppys to exchange 8080 code and the PC revolution still happened. 199x we got the Internet and the open source revolution happend. FPGAs should be capable of exploding just the same, if we can get at them. > Another is the fact that the target of the tools seem to change a lot > more extensively and quickly than the CPUs that are the targets of SW > development tools. Methinks, you have never experienced the PC video-card-chip-of-the-month phenomena, and how the Linux/XFree team supports many cards within 1/2 year. > This makes it hard and expensive for both the > commercial and any potential freeware/open source tools to be kept up to > date. If enough "someones" want the new chip supported, one of them will add support for it. Just look at the Linux hardware database. 10 years ago it was empty today it is large. So you may not find support for the newest family or model, but you rarely need that. And if you do want to live on the bleeding edge of technology, then you will have the choice to use commercial tools, just as some use commercial video drivers (wider and faster card support) on Linux. > efficiently. Even though the vendors charge for their tools, that is not > the real cost of using them. The big bucks are spent dealing with all > the design "issues" that they create. For hobbyist time != bucks. And for newbies, they will have to learn some tool and chip anyway. > A constantly changing open source > toolset would not have any less "issues" than commercial tools and may > be worse. Leave that to the users to choose. But for that they need to have an choice. :-) > that are used to program their parts. I know that Peter Alfke from > Xilinx has stated on more than one occasion that Xilinx would want to > support customers regardless of how they were generating the bitstream. Very honourable from him. But I can assure you, that Intel does not support people who have just done gcc broken-code.c and had it fail on them. So why should Xilinx help with gvhdl broken-design.vhdl? For that we have newsgroups and mailing lists and FAQ websites. The gvhdl projects back end writer may need help (just like the gcc 80x86 back end writer), but that would be no different for Xilinx than if the Synpicity back end writer having problems. > In theory they are a hardware company and will have to provide this > support to sell chips. Intel is also a hardware company. They sell lots of chips without supporting every single user (or even just every programmer). > Open source tools would be a can of worms for > them if they really adopt this approach. They don't need to adopt this approach. DEC only supported their VAX customers if a problem showed under VMS. If it was Unix-only it was up to the customer to fix it (or fix Unix to work around it, just as VMS must be doing). If someone wants hand holding, then they can chose an commercial development system, or take the service of an FPGA equivalent of a firm like Red Hat or Suse. > Personally I think that open source tools could be a major boon to the > FPGA community. Especially if it fosters innovation in how the tools > work and the user interfaces. A far more important boon will be drawing in lots of self-taught new programmers, who will naturally use FPGAs to solve problems. Just look at the embedded Linux guys (MP3 Players, set top boxes, Cobalt Qube). > lowest common denominator. The results are tools that "get in the way" > in many respects in order to offer a minimal learning curve to > beginners. Not that this is bad. But I would like to see what happens if > tools are developed by the tool users rather than the tool sellers. Then you get an gvhdl that is just like an gcc. Somewhat primitive (what GUI?), but very powerfull. And it will support calling from "make" for ever. > Too bad that FPGA designers are not the same community as the software > developers. They could be. FPGA bitstreams are no different than CPU binaries. Both are the result of writing instructions in an source file and compiling them. Just different programming task, different languages, different tools. Anyone who can learn C can learn VHDL. Many will - if they can get systems to do it on. > Carpenters make tools out of wood. Machinists make tools out > of metal. Software developers make tools out of software. What tools do > hardware designers make? FPGA users are not all hardware designers (assuming pre-made FPGA boards), no more than C users are all hardware designers (one off the shelf computers were available). They will be mainly programmers (they program FPGAs to perform an specific job). FPGAs are really just an type of highly parallel CPU, with the program distributed over chip space, not over execution time. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, MysticArticle: 26192
Zoltan Kocsi <root@127.0.0.1> writes: > Jamie Lokier <spamfilter.oct2000@tantalophile.demon.co.uk> writes: > > > Specifically, if there was a really good GPL synthesis tool (no license > > fee + you have the source), and the tool suited your style of work, > > would you use it for customer project? Or would there still be a > > (Linux people would jump up and down for a GPL'd tool) You can bet your life on that. > There's a drwaback as well: free tools usually come with no > glossy docs and idiot proof GUI frontends with buttons to mail > to customer support. Who needs that? Open source users like tools that are written by programmer for themselves. Mostly because open source users are programmers. > Never the less, the software development world seems to be quite happy > about free tools. They work :-). > I, for one, would be quite happy to use GPL'd FPGA tools. So would I. Preferably open source from the grond up, not an old closed source program opened up. > The problem I see is that logic synthesis is a rather hard nut. Not > many people know the intricate details of optimally mapping logic > onto arbitrary cell structures. Not many know how to map C code to 80x86 binary code. Thanks to the few who do know, in the gcc team, most do not need to. Early PCs needed assemble programming, modern ones have left the "write assembler" phase long ago. Present FPGAs need flooplanning, future ones will leave the "floorplan" phase, once the neccessary knowledge has been put into an gvhdl. > I don't know books on synthesis like > the Dragon Book on compiling. Not enough people with the knowledge and not enough readers. Just make the information available and they will appear. > This severely limits the developer base. Scatter information, let people learn. > In addition, the target audience is a much smaller lot than for > software tools or general purpose programs. The audience was also small for microprocessors in 1975. Just let the personal hardware revolution happen and it will change. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, MysticArticle: 26193
Don't tell me! Tell Xilinx! There is nothing I can do about their policies. Try contacting them. We all know that open source tools would be interesting if not useful. But we are all just shouting into the wind until Xilinx allows the bitstream info out. This is not without precedent. A startup company called NeoCad originially started by reverse engineering the bitstream. After some sucess at selling third party tools, Xilinx cooperated and gave them the bitstream and support. A couple years later Xilinx bought Neocad. Who knows what Xilinx will do if they are asked nicely enough? Or you could reverse engineer the bitstream yourself and be the pioneer of GVHDL! Oh, by the way, Xilinx has announced that they are releasing a set of free tools later this month... Neil Franklin wrote: > > Warning, newbie post: > > a) I am new to FPGAs, still trying to get up to speed, find out what I > need to do it, get the tools; no actual design or experience yet. > > b) I am still recovering from the shocking realisation, that I can not > simply download GNU gvhdl and type out some first-project.vhdl, compile > it, get a board from someone like XESS and let it run. > > rickman <spamgoeshere4@yahoo.com> writes: > > > Jamie Lokier wrote: > > > > > > Ray Andraka writes: > > > > ... doesn't require my customer to have the extras to support the design. > > > > > > Is it principally due to $$$, or training & tool familiarity? > > For hobbyists [1] new to the game it is partly financial cost and > far bigger part the need to run an non-open source operating > system, just to develop FPGAs (what? not my trusty editor and source > code managment tools I use for C?). > > [1] in the eyes of some an irrelevant market, because of low > volume/person chip sales. But these are those who may make FPGAs their > next (or after next) job, when they get fed up with writing yet another > web application. And there are a lot of hobbyist out there looking for > new interesting stuff to get into. > > Familiarity is irrelevant to new users (they are not familiar with > anything yet). And there are more new users to come than presently > around (time looks for that). > > > > Specifically, if there was a really good GPL synthesis tool (no license > > > fee + you have the source), and the tool suited your style of work, > > > would you use it for customer project? > > Even if there were an really crappy, limited, one chip only tool the > "early adopters" of the open source scene would simply hack it up > until it is good for their personal use. Then as it is a bit better > someone else continues hacking, then another, ..., and all of a sudden > it is quite an decent tool, sort of. > > Linux 0.01 really did suck, only 2 possible hard disk types, one video > card, no graphics, no mouse, ..., around 0.95 it got usable. 2.2 still > has next to no USB (only keyboard/mouse) and no Firewire. > > > > Or would there still be a > > > significant non-technical barrier for use of a new tool? > > Consultants may have problems getting their customers to accept that > they are not using "the best professional stuff", as open source users > software had up until last year. > > Only 2 years ago Bob metcalfe (Inventor of Ethernet) said that Linux > users were "like lemming jumping off the cliff of well engineered > professional software". > > > > I was talking to an Altera FAE who felt that going into competition with > > > Synplicity on synthesis via the GPL route > > No need for Altera or Xilinx or any other chip vendor to make an GPLed > program. Simply release _to_anyone_who_wants_it_ (translate: put on > your web site) _all_ the bitstrem format information that todays tool > vendors get. Leave it to the open source people to come up with their > tools. > > Intel did not make Linux, they just gave everyone (including Linus > Torvalds) the documentation on how 80x86 binary format looks like. > Then the open source hobbyists strook. > > Yes, this did then take a few years until people could use Linux for > production jobs (I switched 1994). Better than no Linux at all. > > > > customers are far too reluctant to switch tools. > > Given the present situation on the FPGA market, which reminds me of to > the 1960s and early 1970s mini computer market, today users are a very > small subset of the FPGA programming population that could be in a few > years, if an personal hardware revolution similar to the personal computing > revolution of the late 1970s happens. > > There still are a few PDP-11s running and a few people programming > them, but the majority of todays programmers started their careers on > PCs. Just think of an large (millions of units per year) market for > premade FPGA containing boards. Then of 100'000s of programmers > shaping them to their uses. > > > > (The Altera connection was because the FAE thought Synplicity had access > > > to low-level FPGA data that even he did not have, > > Bitstream format? How are them bits scattered to the controlling SRAMs > in the chip? Synplicity has to know this to create bitstreams. This is > the equivalent of knowing the 80x86 code to write an C compiler (which > Intel publishes). > > Does the FAE have that info? The general FPGA programming public has > not. At least I have not managed to find it on any FPGA vendors web > site (I have tried Actel, Altera, Atmel, Gatefield, Lattice, Lucent > and Xilinx so far). I only keep on seeing "get out tool". > > > > and despite saying > > > that Altera are 100% a hardware company they still won't be making it > > > easy for third parties to develop good bitstream-level optimisers). > > Actually impossible to even make an bad bitstream generator, so long > the format is not publically known. > > > One is the fact that there is a much smaller market for the end use of > > the tool. > > The market for 8080s in 1975 was no larger than todays FPGA market. If > anything a lot smaller. And Intel thought it was all about control > systems. Then the hobbyists made the PC revolution. Since then there > is a huge market for PC programming tools, commercial and open source. > > > So development costs a lot more when spread over the smaller > > user base. Certainly customers are sensitive to tools costs. > > Think zero cost. Just web download. 1975 there were only floppys to > exchange 8080 code and the PC revolution still happened. 199x we got > the Internet and the open source revolution happend. FPGAs should be > capable of exploding just the same, if we can get at them. > > > Another is the fact that the target of the tools seem to change a lot > > more extensively and quickly than the CPUs that are the targets of SW > > development tools. > > Methinks, you have never experienced the PC video-card-chip-of-the-month > phenomena, and how the Linux/XFree team supports many cards within 1/2 year. > > > This makes it hard and expensive for both the > > commercial and any potential freeware/open source tools to be kept up to > > date. > > If enough "someones" want the new chip supported, one of them will add > support for it. Just look at the Linux hardware database. 10 years ago > it was empty today it is large. > > So you may not find support for the newest family or model, but you > rarely need that. And if you do want to live on the bleeding edge of > technology, then you will have the choice to use commercial tools, > just as some use commercial video drivers (wider and faster card > support) on Linux. > > > efficiently. Even though the vendors charge for their tools, that is not > > the real cost of using them. The big bucks are spent dealing with all > > the design "issues" that they create. > > For hobbyist time != bucks. And for newbies, they will have to learn > some tool and chip anyway. > > > A constantly changing open source > > toolset would not have any less "issues" than commercial tools and may > > be worse. > > Leave that to the users to choose. But for that they need to have an > choice. :-) > > > that are used to program their parts. I know that Peter Alfke from > > Xilinx has stated on more than one occasion that Xilinx would want to > > support customers regardless of how they were generating the bitstream. > > Very honourable from him. But I can assure you, that Intel does not > support people who have just done gcc broken-code.c and had it fail > on them. So why should Xilinx help with gvhdl broken-design.vhdl? > > For that we have newsgroups and mailing lists and FAQ websites. > > The gvhdl projects back end writer may need help (just like the gcc > 80x86 back end writer), but that would be no different for Xilinx than > if the Synpicity back end writer having problems. > > > In theory they are a hardware company and will have to provide this > > support to sell chips. > > Intel is also a hardware company. They sell lots of chips without > supporting every single user (or even just every programmer). > > > Open source tools would be a can of worms for > > them if they really adopt this approach. > > They don't need to adopt this approach. DEC only supported their VAX > customers if a problem showed under VMS. If it was Unix-only it was up > to the customer to fix it (or fix Unix to work around it, just as VMS > must be doing). > > If someone wants hand holding, then they can chose an commercial > development system, or take the service of an FPGA equivalent of a > firm like Red Hat or Suse. > > > Personally I think that open source tools could be a major boon to the > > FPGA community. Especially if it fosters innovation in how the tools > > work and the user interfaces. > > A far more important boon will be drawing in lots of self-taught new > programmers, who will naturally use FPGAs to solve problems. Just look > at the embedded Linux guys (MP3 Players, set top boxes, Cobalt > Qube). > > > lowest common denominator. The results are tools that "get in the way" > > in many respects in order to offer a minimal learning curve to > > beginners. Not that this is bad. But I would like to see what happens if > > tools are developed by the tool users rather than the tool sellers. > > Then you get an gvhdl that is just like an gcc. Somewhat primitive > (what GUI?), but very powerfull. And it will support calling from "make" > for ever. > > > Too bad that FPGA designers are not the same community as the software > > developers. > > They could be. FPGA bitstreams are no different than CPU binaries. Both > are the result of writing instructions in an source file and compiling > them. Just different programming task, different languages, different > tools. Anyone who can learn C can learn VHDL. Many will - if they can get > systems to do it on. > > > Carpenters make tools out of wood. Machinists make tools out > > of metal. Software developers make tools out of software. What tools do > > hardware designers make? > > FPGA users are not all hardware designers (assuming pre-made FPGA > boards), no more than C users are all hardware designers (one off the > shelf computers were available). They will be mainly programmers (they > program FPGAs to perform an specific job). FPGAs are really just an > type of highly parallel CPU, with the program distributed over chip > space, not over execution time. > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 26194
The bitstream can be reverse engineered, or actually there is no need for a bitstream format just to translate VHDL to a FPGA. The intermediate format is EDIF and the back end tools are supplied by the chip vendor. So where are all the open source VHDL compilers? I believe I have heard of a project or two. But none of these are what many people would call useful. If GPL'd tools are so good, why aren't there more of them in the FPGA world? Neil Franklin wrote: > > Zoltan Kocsi <root@127.0.0.1> writes: > > > Jamie Lokier <spamfilter.oct2000@tantalophile.demon.co.uk> writes: > > > > > Specifically, if there was a really good GPL synthesis tool (no license > > > fee + you have the source), and the tool suited your style of work, > > > would you use it for customer project? Or would there still be a > > > > (Linux people would jump up and down for a GPL'd tool) > > You can bet your life on that. > > > There's a drwaback as well: free tools usually come with no > > glossy docs and idiot proof GUI frontends with buttons to mail > > to customer support. > > Who needs that? Open source users like tools that are written by > programmer for themselves. Mostly because open source users are > programmers. > > > Never the less, the software development world seems to be quite happy > > about free tools. > > They work :-). > > > I, for one, would be quite happy to use GPL'd FPGA tools. > > So would I. Preferably open source from the grond up, not an old > closed source program opened up. > > > The problem I see is that logic synthesis is a rather hard nut. Not > > many people know the intricate details of optimally mapping logic > > onto arbitrary cell structures. > > Not many know how to map C code to 80x86 binary code. Thanks to the > few who do know, in the gcc team, most do not need to. > > Early PCs needed assemble programming, modern ones have left the > "write assembler" phase long ago. Present FPGAs need flooplanning, > future ones will leave the "floorplan" phase, once the neccessary > knowledge has been put into an gvhdl. > > > I don't know books on synthesis like > > the Dragon Book on compiling. > > Not enough people with the knowledge and not enough readers. Just make > the information available and they will appear. > > > This severely limits the developer base. > > Scatter information, let people learn. > > > In addition, the target audience is a much smaller lot than for > > software tools or general purpose programs. > > The audience was also small for microprocessors in 1975. Just let the > personal hardware revolution happen and it will change. > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 26195
I am presently working at a ASIC consulting company and we have a huge
backlog of
work. We need help and will pay well. We have a great office and have
very flexible hours. We are looking for Verilog and/or VHDL experience.
Synthesis and/or Mixed Signal a plus. If you are interested in a Good Job
e-mail me at barry61s@optonline.com
Hope to hear from you.
Sincerely,
Barry
PS: We have needs in: Commack, Long Island New York,
Hazlet, New Jersey
Bethlehem, Pennsylvania.
Article: 26196Hi - I just have to know--what is Long Island Verilog? Is it to Verilog what Long Island iced tea is to iced tea, i.e., vaguely similar in appearance but more intoxicating? Is there a reference manual? Thanks for your help, Bob PerlmanArticle: 26197
Neil Franklin wrote: > > Warning, newbie post: > > ... > > [1] in the eyes of some an irrelevant market, because of low > volume/person chip sales. But these are those who may make FPGAs their > next (or after next) job, when they get fed up with writing yet another > web application. And there are a lot of hobbyist out there looking for > new interesting stuff to get into. > > ... > > No need for Altera or Xilinx or any other chip vendor to make an GPLed > program. Simply release _to_anyone_who_wants_it_ (translate: put on > your web site) _all_ the bitstrem format information that todays tool > vendors get. Leave it to the open source people to come up with their > tools. > I suspect that some of the biggest customers (or hoped-for customers) for FPGAs are also encouraging the manufacturers not to publish bitstream format and to keep the tools expensive. The customers I am thinking of are the makers* of set-top boxes and other conditional access devices who wish to keep useful information and tools away from "time != money" hackers who would like to generate means of accessing unencrypted digital video. See the "arms race" that has occurred with Smart Cards and PIC micros - where, of course, lots of info and cheap tools are available. * actually those who control the licences. AndyArticle: 26198
> I suspect that some of the biggest customers (or hoped-for customers) > for FPGAs are also encouraging the manufacturers not to publish > bitstream format and to keep the tools expensive. The customers I am > thinking of are the makers* of set-top boxes and other conditional > access devices who wish to keep useful information and tools away from > "time != money" hackers who would like to generate means of accessing > unencrypted digital video. The friend I know who works in that area gives me the impression that they are seriously paranoid - probably enough so to keep them from using FPGAs even if the bit stream hadn't been reverse engineered yet. -- These are my opinions, not necessarily my employers. I hate spam.Article: 26199
Stefan Ludwig wrote: > > > It does support the wire probe feature, which comes in very handy when > you have to debug a design and have some spare IOs available. Basically, > the feature allows you to tag any net in your hierarchy for probing on a > pin. This gets around the nasty "push the signal up through the > hierarchy" method. Granted, it's a high price to pay, but considering > the alternatives... > Even this can be done, with a bit of effort, by a Perl preprocessor.
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