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
Hi, I am using the Spartan-3 development kit from Memec. I can't find my cd and need to use the USB. Can anyone send me the drivers. The file is supposed to be CP2101.exe or CP2101_Drivers.exe on the CD. Thanks in advance, Robert.Article: 91326
>> First of all I have tried to download the reference design for the ML403 >> twice today with no luck. The download page is completely empty. Could >> somebody at Xilinx please fix this? > > Were you at : > http://www.xilinx.com/products/boards/ml403/powerpc_microblaze_demos_refsys.htm > No, from the home page I went to Silicon Devices, Virtex-4 MultiPlatform FPGA, Development Boards, Virtex-4 ML403 Embedded Platform, ML403 Demos and Reference Designs which is still a blank page. This is the dead end link: http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=null&sSecondaryNavPick=null&category=&iLanguageID=1&key=HW-V4-ML403-USA Your link works well thank you Newman. And, in response to the Xilinx website flame by the Jim G I find the Xilinx website very satisfying. The only reason I post my gripes to the group is that the I don't like the formalities of creating a Xilinx case. Can anybody help me, or has anybody seen, the other issue about the opening the UART IP ? Brad Smallridge at aivision dot comArticle: 91327
I recently got some ChipScope stuff to work..and I am pretty sure there are many people in this group who are using ChipScope. So anyways the question is where exactly r u stuck. I dont use a ML 401 but I dont think so that matters..If you can e-mail me the exact problem then probably I can help you out.. -- ParagArticle: 91328
You're all too kind! The reason why I'm asking these starter-questions is that my read-only SPI sometimes misses a byte. And it's using both flanks of a clock. It worked ok without so much other stuff in there, but after a while it started to act strange. I've, almost, built a complete SoC (CPU,SPI,Mem-Manager and GPU) and there is so much going on in here that I really had no clue where to start looking for the SPI problem. As a test I now let the part that handled the SPI run on a 12.5Mhz clock instead of a 25Mhz and now it's stable again. If I'd had a timing report generated that would have told me the delays for the relevant path's I might have discovered this sooner. Alas, I've started to read how the constraints works. This probably isn't the "right" way to learn things, but I'd like to see results fast whenever I do something, which means missing basic "how it works" stuff until problems pops up. Good thing I'm not building houses... My todo list: - Learn Constraints - Implement/learn DCM - Taking a bl**dy electronics course These new cheap "Fogs" are the coolest thing! Can't remember when I had this much fun before... Thanks to you all! ((miceArticle: 91329
"Robert" <robertsolanki@gmail.com> schrieb im Newsbeitrag news:1131034844.173053.146390@f14g2000cwb.googlegroups.com... > Hi, > I am using the Spartan-3 development kit from Memec. I can't find my cd > and need to use the USB. Can anyone send me the drivers. The file is > supposed to be CP2101.exe or CP2101_Drivers.exe on the CD. > > Thanks in advance, > Robert. > when you buy memec kits you also have kit serial number that can be used access memec rdc site there is the driver available anttiArticle: 91330
Martin Ellis wrote: > Thomas Reinemann wrote: > >> I suspect, the total IP coded in VHDL/Verilog is three to four orders > >> of magnitude less. > > > May be, but it uses the hardware very efficiently > > Isn't that what people said about assembly language? And GOTO statements? Isn't that what people said about Schematic based designs when HDLs popped up? The reality is the HLLs targeting reconfigurable computing on FPGAs get very good fits already, just as HDLs do simply because the back end optimizers in the tool chains for space/time traceoffs, partitioning, mapping, and routing yield the same benefits for HLLs. The biggest differences is that most HLLs hide implementation details that create design risks, which are considered expert tools for HDL users, thus allowing coders with less hardware experience the ability to realize functional designs with a small performace penalty. Given that the speed ups from a RISC/CISC architecture CPU to FPGAs that can be obtained where there is parallism, are often one to three orders of magnitude, this small efficiency loss is completely mouse nuts. To gain that extra effieciency would require an experienced HDL coder and sigificant delays in the development schedule, each of which have marginal cost benefit gains in comparison to the huge gains made by using reconfigurable computing with FPGAs. Heck, Impulse C is said to use VHDL as the netlist technology to optimize the fit. FpgaC even has some experimental code that uses Verilog as the netlist technology instead of XNF. Even the XNF outputs allow for respresenting the output design as basic gates or packed LUTs with equations allowing the user to decide which will do the best technology mapping. Each of these choices gives the backend tool chain considerable room to optimize the HLL produced netlist for the target technology, just as VHDL and Verilog designs expect. > It's not like using a HLL for FPGA design is only useful for hobbyists > anyway. Celoxica C and Impluse C are becoming thriving products with expensive high value tool chains. Others are likely to become successful as well, and it's very likely that Xilinx or Altera or other FPGA company will offer a C HLL/HDL as their flagship tool chain as reconfigurable computing takes off and drives the high end FPGA revenues. Some expect that may be in the form of System C if that techology really takes off as a system level design specification tool. Doesn't matter. There are few low cost C HLL/HDL tools available for students, hobbyists, and low budget design shops. The total cost of the Celoxica tool chain for a modest sized development team can easily run the cost of several engineers for the multiple licenses needed. Small 1-10 man shops like mine simply can not afford Celoxica licenses, so I've used a mix of TMCC and Verilog for several projects to meet my budget. There are several interesting specialty C HLL/HDL research tools that knock your socks off. Several data flow C compilers have been presented at conferences that would be awesome for some projects if they ever became a real product that was affordable or released GPL (search for ROCCC and PiCoGA projects, and work by Oskar Mencer). Sarah's partial evaluation C compiler called HARPE generates some awesome logic optimizations which coupled with her Async work would make a killer tool to add to ones tool chain for certain types of projects (see http://findatlantis.com/syncpe_paper.pdf). And Mihai Budiu's research at CMU which produced the ASH tool chain (see http://www.cs.cmu.edu/~mihaib/research/research.html ) Other projects like SA-C at ColoState.edu (see http://www.cs.colostate.edu/cameron/) and Spark at UCSD (see http://mesl.ucsd.edu/spark/) and a few dozen others are all exploring and showing good solid gains in how to map HLLs to FPGA and win big. C as an HLL to netlist toolchain is here to stay, and probably only get better with time. C as an HDL (in the form of Handel-C by Celoxica) is clearly here.Article: 91331
Brian, your older comments must have fallen on good ears. The S3e500-based evaluation board uses a two-row 100-pin connector with (almost) one whole row dedicated to Ground. Plus two legacy connectors that are much smaller. 2 x 16 character LCD display, rotary shaft encoder input, USB connector, plus other goodies... The manual is still being written, and I offered some help. December is the month... Peter Alfke, XilinxArticle: 91332
Robin Bruce wrote: > >Never, since most of them think in sequential algorithms and don't > >understand the advantages of hardware. > > What are you saying? That people who don't understand hardware don't > make good hardware designs? That's essentially it. Let's define "good" hardware designs: best use of hardware resources with highest performance (clock speed). > Why would that make VHDL better than a HLL-to-VHDL tool? Because VHDL and Verilog are designed from the ground up to take advantage of the parallelism inherent in hardware designs. Sequential programming languages such as C are not, and much hackery has to happen for C to map well to hardware. As an example, think about how you could implement a FIR filter in C for a DSP, and then think about how you could implement the same filter on an FPGA. I suppose one could write a tool that's smart enough to translate the C description of a FIR filter into efficient hardware but one presumes that sufficient restraints would need to be put into the "hardware C" for the tools to work well. But if the intent is to take high-level C developed by a software guy and have it map to hardware as well as it runs on a DSP, well, I just think you'll leave a lot of FPGA peformance on the table. > I could just as easily say that people who've never heard of algorithms > don't understand the advantages of a microprocessor, therefore > assembler is better than C. It's a non sequitur... You could, but the statement is irrelevant. -aArticle: 91333
Martin Ellis wrote: > Jim Granville wrote: > >> How about some examples, of some real applications, that can be coded >>in either, and the resulting source examples, and the FPGA resource >>mapping that results ? > > > Here's a reference that was posted here a while ago and I'm just following > up just now: > > "Survey of C-based Application Mapping Tools for Reconfigurable Computing" > http://klabs.org/mapld05/program_sessions/session_c.html > > On p14, the C-based implementation performs faster than the VHDL > implementation, despite the VHDL being developed after 'semester-long > endeavor into algorithm?s parallelism'. <snip> Thanks, very interesting link. I like this oxymoron, on p5 : " * Companies create proprietary ANSI C-based language * Languages do not have all ANSI C features and this very important point * Must adhere to specific programming “style” for maximum optimization " The benchmarks are usefull - and show the choice is very much a lottery. One benchmark they did not give, was just what results were if Generic C, from a generic graduate, was thrown at these tools. Source snippets are important, because these solutions are not C, but C-based. The devil is in the details.... -jgArticle: 91334
I'm afraid if you throw generic C at these tools, it won't compile...Article: 91335
Hi checked their design center, I found the documentation on the JTAG cable (last in the list) but not the USB drivers I am looking for. Can you send me a link to that? Thanks, Robert.Article: 91336
After loooong waiting the CoreConsole tool can now be downloaded from Actgel website. It allows to create ARM based SoCs for the PA3/E Flash FPGA's. Current version doesnt yet allow creation of custom peripherals what is promised in next releas(es). Also the distributors (at least in Gemany) do not have and ARM7 ready silicon to ship from stock. On my email inquiry I was asked to call back. I called and asked my question again "do have some silicon to ship" what as usual ended up in long discusssion what is what I need why I need it, do I want support. My question about availability remained unanswered still. Anyway its some progress... Actel has been trying to push their ARM7 for some time without the actual support for it in the tools available, now the software supports at least seems to be avaialble. Antti DIY - FPGA Logic Analyzer: http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=5826253867Article: 91337
"Robert" <robertsolanki@gmail.com> schrieb im Newsbeitrag news:1131041752.243659.217280@g47g2000cwa.googlegroups.com... > Hi checked their design center, I found the documentation on the JTAG > cable (last in the list) but not the USB drivers I am looking for. > > Can you send me a link to that? > > Thanks, > Robert. > sure, here it is: http://legacy.memec.com/solutions/reference/xilinx/downloads/cp2101.zip Antti DIY - FPGA Logic Analyzer: http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=5826253867Article: 91338
Andy, firstly, you've misunderstood my post. The previous poster seemed to suggest that there was some kind of link between people not understanding hardware and HLLs being inferior to VHDL. I didn't see what the level of experience of people who use HLLs has to do with whether or not HLLs are superior to HDLs. This was what led to my intentionally fatuous comment: > I could just as easily say that people who've never heard of algorithms > don't understand the advantages of a microprocessor, therefore > assembler is better than C. It's a non sequitur... OK, as for your other comments: >> much hackery has to happen for C to map well to hardware. well, much 'hackery' obviously has happened, as there are tools that map C well to hardware. We're not talking about what might happen, we're talking about what is happening. >I suppose one could write a tool that's smart enough to >translate the C description of a FIR filter into efficient hardware but >one presumes that sufficient restraints would need to be put into the >"hardware C" for the tools to work well. Check slide 13 of Brian Hollands presentation from MAPLD, you'll find all 3 HLL tools tested beat the VHDL for FIR implementation: >But if the intent is to take >high-level C developed by a software guy and have it map to hardware as >well as it runs on a DSP, well, I just think you'll leave a lot of FPGA >peformance on the table. Who said that's what we're trying to do? We're talking about high-level languages not so we can compile legacy code. We're doing it so we can rapidly infer reliable hardware using a more concise expression than that achieved using HDLs while paying a minimal price in lost potential performance.Article: 91339
Jim Granville wrote: > I like this oxymoron, on p5 : > " * Companies create proprietary ANSI C-based language > * Languages do not have all ANSI C features I don't think that's an oxymoron. Just because a language is proprietary, it does not mean it can't be based on ANSI C. Sure it might read a bit funny - but we've all tried to cram too much onto slides before. > and this very important point > * Must adhere to specific programming ?style? for maximum optimization Yes. That's a very important point. > The benchmarks are usefull - and show the choice is very much a lottery. > One benchmark they did not give, was just what results were if Generic > C, from a generic graduate, was thrown at these tools. I think you've got the wrong end of the stick there. This isn't about taking arbitrary C code and compiling it to an FPGA. You simply can't do that. Reason: It's possible to write architecture specific code (that is, code specific to a particular ISA) in C. Self-modifying code and dynamic code generation are examples of this. For example, linkers and JIT compilers modify code which is then executed. You couldn't compile that efficiently to an FPGA - it would need the re-synthesis every time code was modified.. Another reason is that a compiler can't guess which inner loops are program 'hot-spots', and thus good candidates for synthesis. Such information is application-domain specific. Concisely: the aim isn't to be able to take a program written by someone who knows nothing about hardware (at least, not yet). The aim is to be able to develop hardware acceleration for a given algorithm. One advantage of C-based languages is that when trying to accelerate an algorithm, it might not be clear which parts to synthesise - this requiring some trial-and-error for difficult problems, and also being dependent on some rather arbitrary parameters. It's easier to move a computation unit from software to hardware, or vice-versa, if the languages are similar. There's also a whole raft of software based optimisations that can be applied before the hardware optimisations even get a look in. Another, is that for some projects, a C simulation is developed to check the algorithms anyway. For example, Timothy Miller did a software model for the OpenGraphics project. The practise isn't uncommon. > Source snippets are important, because these solutions are not C, but > C-based. The devil is in the details.... For the reasons above, it is - in general - necessary to provide a compiler with some pragmas or other hints that describe what code would be a good candidate for synthesis. However, the solutions are often close enough to C that it's possible to execute the program entirely in software, as well as compile to a object code/bitstream target. That's useful for the intended applications. Nobody's pretending C-based synthesis is a complete replacement for HDL, only that for some applications/projects it's a very compelling alternative. MartinArticle: 91340
Eric Smith wrote: > Still, if you're going to use reconfigurable computing, surely each > configuration is a hardware design, and much better expressed in a > language optimized for hardware design, rather than a language optimized > for strictly sequential operation. Actually, Handel-C (Celoxica), Impulse-C (derivative of StreamsC), ASH, SA-C, HarPE, Spark, and even FpgaC all take a subset of the language and to various degrees present extensions to the language to be a language optimized for hardware design, some much more rigorous than others. Celoxica's long term goal is to compete 1 on 1 with VHDL/Verilog and they are doing pretty well at it so far. Impules-C with it's VHDL backend is ment to take communication based designs (AKA RPC or MPI or other cluster based communication library) and use FPGA's as computing nodes with clearly defined streams to build pipelined system designs. The use of the VHDL backend leaves lots of room to optimized the resulting design at a low level. SA-C and ASH are clearly targeting high performance designs, actually large high performance designs, with the intent to get as good a hardware fit as VHDL/Verilog or better by picking a specification language higher than VHDL/Verilog and lower than a full C/C++ which is highly optimizable to give a better design yield than mid-level experienced coders would get with VHDL/Verilog. Actually all the C HLL offerings pretty much share this goal of trying to do better than the average VHDL/Verilog coder. ASH and HarPE go after optimizations that even a skilled VHDL/Verilog coder are likely to miss, or even decide to avoid in the effort to leave the VHDL/Verilog code readable and maintainable.Article: 91341
Martin Ellis wrote: > This isn't about taking arbitrary C code and compiling it to an FPGA. > You simply can't do that. Actually you could, and in the future when a few million luts are cheaper than a fairly fast CPU, some people probably will by using mixed technologies inside the FPGA ... a combination of application specific cpu cores and generic netlists. Already Xilinx is targeting that market with PPC cores and micro blaze cores as an addition to the FPGA logic synthesis. > Another reason is that a compiler can't guess which inner loops are program > 'hot-spots', and thus good candidates for synthesis. Such information is > application-domain specific. Actually, that is only partially true. It's been common for some time to use profiler input from actual runs to guide the compiler optimations for later builds. This happens to be one sweet spot that lcc exploits to beat gcc and pcc executables. See http://www.cs.princeton.edu/software/lcc/doc/linux.html > However, the solutions are often close enough to C that it's possible to > execute the program entirely in software, as well as compile to a > object code/bitstream target. That's useful for the intended applications. Actually, it's very easy to write C to the subset implemented by a particular C to netlist HDL, that with a few #ifdef's is usable in either environment, and can accellerate development testing and debugging by doing most, if not all, the high level debugging in a well structured source code debugging environment. Others take it a step farther, and use rigourous type checking combined with super "lint" tools that provide verifiable correct construction checking. In a lot of ways, the original C++ development was exactly that, and was implemented as a front end preprocessor for standard C which was specifically ment to be only lightly typed so that it was a productive low level systems programming language only marginally higher level than PDP-11 assembly language. It's actually fairly easy to code in C++ with abstract types that directly implement (IE emulate) the abstract hardware types that would result after synthesis to yield a strict HLL development environment with strict typing and verifiable designs and still translate to a subset dialect of C (or Verilog) for synthesis. > Nobody's pretending C-based synthesis is a complete replacement for HDL, > only that for some applications/projects it's a very compelling > alternative. Choke, cough .... ummmm ... Celoxica, ASH, and a few other projects really have that goal. Celoxica has very clear guidelines, just as VHDL and Verilog have, to allow the coder to understand just what registers and logic will be instantiated. When you stop and think about it ... there is very little difference between the coding syntax of Handel-C and a subset of Verilog.Article: 91342
Peter Alfke <peter@xilinx.com> wrote: ... > December is the month... Which year ;-) -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 91343
"Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> schrieb im Newsbeitrag news:dkdroi$si4$1@lnx107.hrz.tu-darmstadt.de... > Peter Alfke <peter@xilinx.com> wrote: > ... >> December is the month... > > Which year ;-) > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Uwe, December is the month every year, but its 2005 to get real Christmas presents from Xilinx. S3e is WAY best FPGA around, so if we have to wait a little more lets try todo wait in piece, this goes more tomyself and my kinda angry comments about s3e availability, I am sometimes like a boy who wants its presents too early. AnttiArticle: 91344
air_bits@yahoo.com wrote: > Martin Ellis wrote: >> This isn't about taking arbitrary C code and compiling it to an FPGA. >> You simply can't do that. > > Actually you could, and in the future when a few million luts are > cheaper than a fairly fast CPU, some people probably will by using mixed > technologies inside the FPGA ... a combination of application specific cpu > cores and generic netlists. Already Xilinx is targeting that market with > PPC cores and micro blaze cores as an addition to the FPGA logic > synthesis. Um. Go back to the self-modifying code example and you'll see that it can't always work. To some extent, I agree with you, but the programs *have* to be sensible and well behaved (type safe to some extent). And that excludes *arbitrary* C. >> Another reason is that a compiler can't guess which inner loops are >> program 'hot-spots', and thus good candidates for synthesis. Such >> information is application-domain specific. > It's been common for some time to use profiler input from actual runs to > guide the compiler optimations for later builds. Yes, I know about this technique, and I thought about mentioning it here, but didn't for brevity. I don't call that fully automatic though. You need to seed it with some appropriate test data. >> However, the solutions are often close enough to C that it's possible to >> execute the program entirely in software, as well as compile to a >> object code/bitstream target. That's useful for the intended >> applications. > > Actually, it's very easy to write C to the subset implemented by a > particular C to netlist HDL, that with a few #ifdef's is usable in either > environment, and can accellerate development testing and debugging by > doing most, if not all, the high level debugging in a well structured > source code debugging environment. That's exactly what I'm arguing. Why are you arguing with me? <!-- Snip further stuff about type-safety and C++ --> >> Nobody's pretending C-based synthesis is a complete replacement for HDL, >> only that for some applications/projects it's a very compelling >> alternative. > Choke, cough .... ummmm ... Celoxica, ASH, and a few other projects > really have that goal. Celoxica has very clear guidelines, just as VHDL > and Verilog have, to allow the coder to understand just what registers and > logic will be instantiated. As far as I know, Celoxica's products and similar offerings only target digital designs for FPGAs. I'm not aware of any C-based language that was intended to cover ASIC manufacture, or that would cover, say the 'Standard VHDL Analog and Mixed-Signal Extensions' for example. I could be very wrong there, and I'd be interested to know if they do intend to target those aspects of HDLs though, if you can point me at any references. > When you stop and think about it ... there is very little difference > between the coding syntax of Handel-C and a subset of Verilog. Sure. The syntax is very similar, but syntax is normally the least interesting part of a language. MartinArticle: 91345
Robin Bruce wrote: <snip> > >>But if the intent is to take >>high-level C developed by a software guy and have it map to hardware as >>well as it runs on a DSP, well, I just think you'll leave a lot of FPGA >>peformance on the table. > > > Who said that's what we're trying to do? We're talking about high-level > languages not so we can compile legacy code. We're doing it so we can > rapidly infer reliable hardware using a more concise expression than > that achieved using HDLs while paying a minimal price in lost potential > performance. Which has a lot in common with the ASM-HLL debates on microcontrollers. The best solutions will come from a mix of tools - but the sad reality is marketing dept drive is to push the hot new thing, as a silver bullet, and any suggestions or examples of mixing HLL/HDL, might be seen as admitting that their hot-new-thing is not actually the universal new tool.... There is another, more recent shift in FPGA's, which means a 'Sea of DSP' deployed in the FPGA, and that is missing from this link: "Survey of C-based Application Mapping Tools for Reconfigurable Computing" http://klabs.org/mapld05/program_sessions/session_c.html The HLL -> HDL path, misses the alternative of HLL -> FPGA Running HLL amd the best tool set, will be one that allows a softer migration between Opcodes and Registers. The next generation FPGA will be interesting to watch, as we are steadily getting more coarse & complex blocks, in BlockRAM and DSP-able blocks, with each release. This may outflank the efforts to create C -> registers ? -jgArticle: 91346
Does anyone have reference on how to use the second ppc405 in virtex-II pro? I'm trying to write an application on each ppc, and see how two processors work together. xilinx reference manual didn't talk about how to use the second ppc, from what i read. any pointer is appreciated. Thanks. -EricArticle: 91347
Summary of this thread :
Peter Alfke wrote:
> I promised an answer. The digging took a bit longer...
>
> The good news is that Xilinx has many thousands of S3e100 in TQ144, and
> hundreds in vq100 packages, as well as many S3500 in several packages.
> The bad new is that -today- these parts are still ES ("early silicon")
> which distribution hates to touch, because the parts will become
> obsolete very soon, once the production version becomes available.
>
> If you need them immediately, order them through your distributor or
> your Xilinx sales folks. And realize that "6 to 8 weeks" is often
> exaggerated.
Or the Xilinx web store ? - All that infrastructure, going to waste....
>
> Production S3e100 and 500s are expected this month, and 1600 soon
> after. And the distis will love to sell them (which they consider their
> job, even in Europe !).
And they WILL be on the fast track to the Web-Store (surely?) ?
>
> I have held the almost final version of the S3e500-based evaluation
> board in my hand. It is dynamite, loaded with features and peripherl
> circuits, compatible with a slew of inexpensive Digilent add-on boards.
> Availability starts in December. Well before that, there will be a
> business-card-size eval board, packaged in a DVD-case, meant as a
> super-low-cost S3e100 demonstrator.
"Well before" December is March, so I guess now we are in November,
i.e. "really close' to December, the info on that nice sounding
super-low-cost S3e100 demonstrator, is being posted on the web
as I write ? - Photos, users manuals, actual Prices, usual stuff....
-jg
Article: 91348Robin Bruce wrote: > I think we have to accept that high-level languages are going to be the > future for FPGAs. Not to say that HDLs will be replaced entirely, but > they'll be largely supplanted by the HLLs. Algorithms are easier to <snip> > First generation tools are far from perfect, but they will see use > because they significantly decrease development time. Your HLL-designed > system may not be as efficient as the best possible VHDL design, but if > it's good enough and you get to market months before the competition, > you'll come out on top. Or cynically speaking, we may just get bigger, faster and cheaper FPGAs, so that it doesn't really *matter* how efficient you are, merely that you're in the ballpark. I think this has happened to a certain extent in the software world anyway... JeremyArticle: 91349
Hey Marco, I dont even know the conversion rates in Italy. But in US with your profile one can command anywhere from 60K-75K depending on location, type of company, your ranking of school etc. This in Dollors so in Euros it would be 50000Euros to 62000 Euro. Ofcourse a lot of other factors come into picture but this is just a ball park figure I am quoting. Good luck with the job.
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