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
Ray Andraka <ray@andraka.com> wrote: > Also, be aware that using a bonded IO and it's internal pullup for > this leaves an avenue to introduce emi into your design, as you have > a fairly high impedance antenna. Also, if you tie a signal to a pin, the optimizer won't recoginze it as a constant (VCC or GND) and can't optimize it away. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26151
Research Studentship available: Neural systems engineering for embedded machine vision Applications are invited for a fully-funded, three-year PhD studentship. The work will be researching future artificial neural network (ANN) architectures based on our neural hardware. The types of vision application which will form the basis for mass implementation over the next few years are those requiring the embedding of intelligent pattern recognition systems into industrial processes, instrumentation and portable systems. These systems will make extreme demands on the hardware, requiring the integration of traditional image processing with ANN techniques, and implemented in designs with small footprint and low power consumption. The project will research methods for the efficient embedding of imaging algorithms into hardware and neural arrays. A hardware implementation of the system will be developed. The work will be motivated by industrially relevant demonstrator applications, and will include collaboration with system developers and end users. The studentship is partly funded by AXEON Ltd who are developing novel processor systems. The student would join a lively and rapidly expanding novel architectures research group in the Department of Engineering. The funding of the studentship covers UK/EU tuition fees and a maintenance grant equivalent to standard Research Council rates. Applicants should have a good first degree (equivalent of UK 1st class or upper second) in electronic engineering, physics or computational science. Informal enquiries may be directed to Dr Alastair Allen. Email: a.allen@abdn.ac.uk. Tel: +44 1224 272501. Fax: +44 1224 272497. Application forms: Postgraduate Office, Department of Engineering, Fraser Noble Building, University of Aberdeen, Aberdeen, AB24 3UE, UK. Tel: +44 1224 272513. Fax: +44 1224 273895. Email: pgoffice@eng.abdn.ac.ukArticle: 26152
In article <8rfbre$oor$1@eol.dd.chalmers.se>, danielnilsson@REMOVE_THIShem3.passagen.se (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). Well, you can connect a 21065L to an Intel 82559 with a small CPLD/FPGA (about three-quarters of a Cypress 373i will do) and a couple of 16646 bus buffers. Oh, plus the clever VHDL and Sharc code to make it work :-) No more than minor variations are likely to be necessary for other Sharcs and Ethernet controllers, but those are what I used. -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 26153
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? > 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 > significant non-technical barrier for use of a new tool? > > I was talking to an Altera FAE who felt that going into competition with > Synplicity on synthesis via the GPL route would be no good because > customers are far too reluctant to switch tools. I suspect $$$ may have > something to do with this though. Any well put together tool should do > its best to fit in with the customer's existing tools. > > (The Altera connection was because the FAE thought Synplicity had access > to low-level FPGA data that even he did not have, 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). > > -- Jamie I think there are a lot of issues in the topic of open source tools. I don't know that users are any more reluctant to change tools than software developers are due to unfamiliarity of the new tool, cost, etc. But FPGA tools are unique due to several reasons. One is the fact that there is a much smaller market for the end use of the tool. So development costs a lot more when spread over the smaller user base. Certainly customers are sensitive to tools costs. 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. This makes it hard and expensive for both the commercial and any potential freeware/open source tools to be kept up to date. So even if the dollars were dropped as an issue, it is no small task to keep a toolset up to date with the new architectures in FPGAs. I for one would embrace open source tools if they work and can be used 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. A constantly changing open source toolset would not have any less "issues" than commercial tools and may be worse. One last note; the chip vendors are not really interested in open source tools since they feel that they will have to "support" any and all tools 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. In theory they are a hardware company and will have to provide this support to sell chips. Open source tools would be a can of worms for them if they really adopt this approach. 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. I think that tool and FPGA vendors have a large interest in reducing "support" which often means catering to the 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. Too bad that FPGA designers are not the same community as the software developers. 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? -- 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: 26154
It's not the $$$, Its the learning curve and effort to stay competent on yet another set of tools, and the inevitable generating test cases for tech support. Part of the problem with the state of the industry is the rate of change. The average FPGA user does about one FPGA design every 18 months, mostly because he is usually responsible for other things than just the FPGA. As the tools vendors, especially the synthesis guys have said, the only way to really get good results out of the tools is to know the tool well. Unfortunately, in the 18 months between FPGA designs, the designer is faced with a new FPGA generation that is significantly different than the last and new versions of the tools, not just a minor revision, but usually a whole new user interface. At that rate of use, the designer has a difficult time just getting competent on the tools much less mastering them. It would help if the user interfaces stayed more constant, but beyond that, I don't see any easy answers. My resistance to Amplify is that for the design method I have adopted, it offers very little if any added value. Even if the cost was not a quantum leap, the investment in time to master yet another tool is not warranted by the marginal incremental value it presents to me. On top of that, my current methodology has a better than even shot of translating to another tool (I use Synplicity), for example I know it will port to exemplar with very little additional effort, mostly just changing the names of a few synthesis attributes. If I were to use Amplify, I get further away from standard VHDL when doing placed designs and therefore lock myself into one tool. 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? > 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 > significant non-technical barrier for use of a new tool? > > I was talking to an Altera FAE who felt that going into competition with > Synplicity on synthesis via the GPL route would be no good because > customers are far too reluctant to switch tools. I suspect $$$ may have > something to do with this though. Any well put together tool should do > its best to fit in with the customer's existing tools. > > (The Altera connection was because the FAE thought Synplicity had access > to low-level FPGA data that even he did not have, 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). > > -- Jamie -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26155
Austin, Just curious - will there be any specific references to decoupling caps for BGA parts in the revision of XAPP158? This info would be very pertinent to the Spartan II design I am wrapping up. Regards, Bob Bauman Lynx Studio Technology "Austin Lesea" <austin.lesea@xilinx.com> wrote in message news:39D25202.7DECA224@xilinx.com... Martin, In our appnote 158 (re-write due to be released perhaps this week), we make a point of recommending a number of large capacitors precisely because we don't know what the frequency distribution is, and you probably are not sure either. AustinArticle: 26156
Hi there,
My university working group is just about to start designing vhdl 93/87
simulator. We are not sure yet about the status ( freeware probably ).
Our problem is that there are many cases found in praxis, that are not
described in LRMs. Here are a few cases :
1) different number ranges that some tools support
2) library ieee;
use std_logic_1164.all;
Most of simulators support this behaviour.
Could anyone share his/her experiences with these problems ?
Please include a short explanation about the non-standard
behaviour, and the tool name that supports it, if possible.
Any comments would be highly appreciated.
regards,
-------------------------------------------
- Domagoj -
- Domagoj@engineer.com -
-------------------------------------------
Article: 26157> After configuration I see that the 3.3V rail is supplying a portion of the power to the 2.5V rail throuht some unknown path.Currently I'm powering the 3.3V rail and 2.5V rail off a current limited bench supply. Eventually the current drawn from the 2.5v bench supply reaches 0mA and can be removed from the equation- 2.5V being maintained by the 3.3V supply through some unknown path. Have you connected the pins to another device (eg an unconfigured FPGA) with weak pull-ups to 3V3? AlunArticle: 26158
I'm wondering if the guidelines for simultaneous switching (max number of drivers of a certain type that can switch per power/gnd pair) is the limit for a specific power/ground pair (ex the drivers between VCC pad X and GND pad Y cannot simultaneously switch more than Z amount of curent) or do you simply sum up all simultaneous switching driver current and divide by the total number of power/ground pairs in the package. -TomArticle: 26159
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.Article: 26160
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 > significant non-technical barrier for use of a new tool? Of course ! GPL gives you a lot of benefit: you don't rely on the existence of the vendor, nor on its willing to help you with that particular tool version. You are not tied to a particular platform (Linux people would jump up and down for a GPL'd tool) and you can twist and turn the tools any way you like to suite your needs. The bug-elimination rate is way higher with free software than with commercial one. 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. Setting up a crosscompiling and debugging environment using gcc/gdb et al is not the same thing as running the Install Wizard and click on BuildProject then on FixBugs. On the other hand, gcc/gdb et al are usually much more flexible than the wizardish tools - this can come handy if you have to do something unorthodox. Never the less, the software development world seems to be quite happy about free tools. I, for one, would be quite happy to use GPL'd FPGA tools. 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. I don't know books on synthesis like the Dragon Book on compiling. This severely limits the developer base. In addition, the target audience is a much smaller lot than for software tools or general purpose programs. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 26161
rickman wrote: > Was this the super computer talking? Or Marvin the paranoid android? The computer called, I think, Deep Thought describing what was needed to calculate the question to which the answer was 42.Article: 26162
> > 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).
If it is just ethernet that you want, you can connect a CS8900a directly
to some general purpose I/O, or to the processors local bus with little
or no glue logic.
CU,
Kolja
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 26163I a current design I am using Xilinx Virtex FPGAs to implement various DSP functions. Most of the time the maximum frequency canbe increased quite a bit by using the floorplanner. The design is done using the express edition of Xilinx Foundation, and consist of several smaller entityes which are then used to create the whole system. What I would like to do is to florplan each of the smaller designs, and then use these as RPMs in the top level design. I have look in the manuals, on the xilinx website, and various other places on the net but have been unable to find out whether this is possible using the express edition, and how it is done. (I found a document descriing how to do use RLOCs in VHDL code, but that did not work with express. Does any one out there now whether this is possible in the express edition? If it is possible where can I find information on how this is done? Thanks, dines -- -------------------------------------------- Dines Justesen // dcj@rescom.dk --------------------------------------------Article: 26164
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. >Article: 26165
--------------B31760737222B2DE001B88AE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Friends: It is OK, but I think then for the radix point repositioning ( for multiplication with fractions) I need to do some division. If not then how can I do it? This thing is new for me. I need help in this. Regards, Ray Andraka wrote: > No hardware changes needed in the multiplier itself. All you have to do is > change the interpretation of the position of the radix point. It is equivalent > to scaling your input and output by 32 in your case. > > Vipan Kakkar wrote: > > > > Dear Friends: > > > > I would like to know that how to multiply e.g. 1100 with 0.0011. I > > already have an array multplier to multiply e.g. 1100 with 0110. But, > > now I want to multiply fractions (i.e. .0011) using the same multiplier, > > so what modifications should I do in the existing multiplier. > > > > Regards > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com or http://www.fpga-guru.com -- ____________________________________________________________________________ Vipan Kakkar (Research Assistant), Circuits & Systems Group, Dept. of Electrical Engineering, Delft University of Technology, Mekelweg 4, 2628 CD DELFT. The Netherlands. Tel: +31 62 8171782 --------------B31760737222B2DE001B88AE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Dear Friends: <p>It is OK, but I think then for the radix point repositioning ( for multiplication with fractions) I need to do some division. If not then how can I do it? This thing is new for me. I need help in this. <p>Regards, <br> <p>Ray Andraka wrote: <blockquote TYPE=CITE>No hardware changes needed in the multiplier itself. All you have to do is <br>change the interpretation of the position of the radix point. It is equivalent <br>to scaling your input and output by 32 in your case. <p>Vipan Kakkar wrote: <br>> <br>> Dear Friends: <br>> <br>> I would like to know that how to multiply e.g. 1100 with 0.0011. I <br>> already have an array multplier to multiply e.g. 1100 with 0110. But, <br>> now I want to multiply fractions (i.e. .0011) using the same multiplier, <br>> so what modifications should I do in the existing multiplier. <br>> <br>> Regards <p>-- <br>-Ray Andraka, P.E. <br>President, the Andraka Consulting Group, Inc. <br>401/884-7930 Fax 401/884-7950 <br>email ray@andraka.com <br><a href="http://www.andraka.com">http://www.andraka.com</a> or <a href="http://www.fpga-guru.com">http://www.fpga-guru.com</a></blockquote> <pre>-- ____________________________________________________________________________ Vipan Kakkar (Research Assistant), Circuits & Systems Group, Dept. of Electrical Engineering, Delft University of Technology, Mekelweg 4, 2628 CD DELFT. The Netherlands. Tel: +31 62 8171782</pre> </html> --------------B31760737222B2DE001B88AE--Article: 26166
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? MaciekArticle: 26167
Hi Kent, Thanks for your answer, > As I understand it, it *is* possible . . . you simply set your pair of > output pins such that one of the is logic '1', and the other one is > logic '0'. And then you invert them both. This gives you two > differential logic levels. > Yes I agree, this sounds possible. You drive the pins just like you do it in VHLD when you instantiate a LVDS driver. But ... > If I'm not mistaken, LVDS is 2.5v logic; I beleive that during the > JTAG test the LVDS outputs will be the same as the Vccio pins for that > I/O bank, so you should be safe there, too. ... the heart of the problem is here. LVDS is supplied in 2.5 V but it's not a 2.5 V logic. LVDS common mode voltage is 1.25 V , but differential voltage is 350 mV (or high voltage = 1.425 V, low voltage = 1.075 V). So, if during JTAG test the LVDS outputs will be the same as the Vcco pins for that I/O bank (as I beleive too), it won't work ! Moreover I wonder if doing the test after the configuration of the FPGA will change someting or not... will the pin be driven with LVDS voltage levels then ? Does JTAG uses the drivers as configured by VHDL ? > > Warning: You are going to run into a problem if your LVDS signals are > AC-coupled. JTAG is inherently slow; I find that our JTAG clock is > between 1 MHz and 5MHz maximum. Consider that you have to shift in > data for each pin of the FPGA every time you change the JTAG output > pins, then you can only toggle the output pins at a frequency less > than (1~5MHz / Pin Count). I'm guessing 15 KHz maximum. > Yes, that's true, but it's not a problem for us. We're doing some kind of interconnect test involving 3 boards. So signals are cathed by other BS cells but not directly. Gabriel Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26168
On Thu, 5 Oct 2000 23:43:16 +0200, "Domagoj" <domagoj@engineer.com> wrote: >Hi there, > My university working group is just about to start designing vhdl 93/87 >simulator. We are not sure yet about the status ( freeware probably ). >Our problem is that there are many cases found in praxis, that are not >described in LRMs. Here are a few cases : >1) different number ranges that some tools support >2) library ieee; > use std_logic_1164.all; > Most of simulators support this behaviour. > >Could anyone share his/her experiences with these problems ? >Please include a short explanation about the non-standard >behaviour, and the tool name that supports it, if possible. > >Any comments would be highly appreciated. Wrong newsgroup - try comp.lang.vhdl. What's Praxis? The LRM specifies 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. 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. EvanArticle: 26169
Jörg Ritter wrote:
> I'm using the fc2 under solaris2.6 and 2.7 (SunOS 5.6 and 5.7).
> Do you get window decorations when using KDE as the window manager ?
No, the window frames don't appear on the screen. I have to start
FC2 under CDE to resize the windows. Seems a common problem for some
tools, the previous Primetime showed the same behavior, with the newest
version it's gone.
Do you have any bugfix for that?
Lars
--
Address: University of Mannheim; B6, 26; 68159 Mannheim, Germany
Tel: +(49) 621 181-2716, Fax: -2713
email: larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/
Article: 26170No need for actual division, just implied division by a conceptual bit shift. FOr example: 7*5 is 0 1 1 1. x 0 1 0 1. --------------------- 1 0 0 0 1 1. while 7/8 * 5/7 is 0.1 1 1 x 0.1 0 1 ---------------------- .1 0 0 0 1 1 and 7/8 * 5 is 0.1 1 1 x 0 1 0 1 -------------------- 1 0 0.0 1 1 So you see the bits are always the same. What changes is our interpretation of the bit weights. In the logice then, if your weighting is always the same then you handle it by aligning your inputs and outputs to the implied radix point. Vipan Kakkar wrote: > > Dear Friends: > > It is OK, but I think then for the radix point repositioning ( for > multiplication with fractions) I need to do some division. If not then how can > I do it? This thing is new for me. I need help in this. > > Regards, > > > Ray Andraka wrote: > > > No hardware changes needed in the multiplier itself. All you have to do is > > change the interpretation of the position of the radix point. It is > > equivalent > > to scaling your input and output by 32 in your case. > > > > Vipan Kakkar wrote: > > > > > > Dear Friends: > > > > > > I would like to know that how to multiply e.g. 1100 with 0.0011. I > > > already have an array multplier to multiply e.g. 1100 with 0110. But, > > > now I want to multiply fractions (i.e. .0011) using the same multiplier, > > > so what modifications should I do in the existing multiplier. > > > > > > Regards > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com or http://www.fpga-guru.com > > -- > ____________________________________________________________________________ > Vipan Kakkar (Research Assistant), Circuits & Systems Group, > Dept. of Electrical Engineering, Delft University of Technology, > Mekelweg 4, 2628 CD DELFT. The Netherlands. Tel: +31 62 8171782 > > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26171
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? MarcArticle: 26172
rickman writes: > One is the fact that there is a much smaller market for the end use of > the tool. So development costs a lot more when spread over the smaller > user base. Certainly customers are sensitive to tools costs. The market gets larger when one considers that an open source tool is likely to target chip families from several vendors, eventually. There are already open source tools for ASIC design and synthesis. I'm not sure how good they are, but they are commercial supported. > 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. This makes it hard and expensive for both the > commercial and any potential freeware/open source tools to be kept up to > date. On the other hand, GCC has shown that when a tool is _designed_ for easy retargetting, the users are quite likely to do it themselves or pay someone they now to fine tune for a new target. Of course the ideal is that FPGA vendors are involved in the retargetting process because it helps them -- a good backend makes the new FPGA look good. > So even if the dollars were dropped as an issue, it is no small task to > keep a toolset up to date with the new architectures in FPGAs. I for one > would embrace open source tools if they work and can be used > efficiently. Would you pay for open source tools, if that payment led to the toolset being kept up to date with the FPGAs you use, and working with your preferred design approach? > 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. No kidding. Not just the FPGA PAR tools either -- synthesis tools, oh boy the Perl scripts I've had to write to modify netlists just to get one tool compatible with another are, shall we say, an indication of how disappointing "customer support" from the tool vendors can be. > A constantly changing open source toolset would not have any less > "issues" than commercial tools and may be worse. An open source toolset would have to respond to customer requirements to survive just like the commercial ones do (eventually). As you say, it's not $$$ at the end of the day, at least for the professional users. In the end what seems to count is having a good, dedicated support team who are able to respond to those "issues" and have the skill to fix them. That's the same as commercial offerings. However, open source does change the nature of the competition, so that if the support team aren't up to the job, anyone else interested can join in. Don't have the skills? Read the source and _learn_ the skills directly. > One last note; the chip vendors are not really interested in open source > tools since they feel that they will have to "support" any and all tools > 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. > In theory they are a hardware company and will have to provide this > support to sell chips. Open source tools would be a can of worms for > them if they really adopt this approach. How is this worse with open source? Now, if the users are randomly hacking the "Xilinx backend" of "GNU fpgatool", they'll be getting unusual designs out which will stretch FPGA vendors. This is a good thing, because the FPGAs are seeing applications and design techniques they weren't seeing before. The issue of dangerously erroneous bitstreams isn't an issue, because a properly written tool has a fairly small, indepdendent component to check the bitstream to make sure it doesn't cause contention. Customers have no need to change _that_ part. As for customers who are depending on potentially buggy timing information... well again, put the toolset together properly so there's a Xilinx-supplied "give you the timing from low level files" tool, which can always be run no matter what cunning changes customers are applying to their local toolchain. Not really a can of worms if you put together the tools with keeping down the cost of customer support in mind. More than likely, the homebrew level of tools _will_ be a problem for Xilinx et al. if they insist on supporting those users, because those tools will be buggy, poorly documented, based on incorrect documentation from FPGA vendors and guesses from reverse engineering etc. On the other hand, professionally assembled open source with support from the beginning from the FPGA vendors naturally has "keep down the cost of customer support" right in there as a design goal. That means making the tool a good one, robust in the face of internal bugs, and with top quality diagnostics. > 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. Exactly. > I think that tool and FPGA vendors have a large interest in reducing > "support" which often means catering to the 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. I think there is ample room for tool sellers to coexist in open source with the FPGA vendors and users. Most users don't want to write tools (though they might like to make local changes). FPGA vendors want to know the tool is well supported and professionally put together, but they want the economic burden of pleasing users due to tool issues to be someone else's problem. So there's a role for the tool supplier. What's missing at the moment is simply the lack of responsiveness by tool suppliers to users individual demands and the users' own creative input -- and that means lack of innovation in new designs. Not to mention fewer FPGAs sold. > Too bad that FPGA designers are not the same community as the software > developers. 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? First, people who program FPGAs are increasingly not hardware designers at all. They're parallel digital logic designers. How many people have you seen in this newsgroup discussing things like FIR filters etc., yet who (possibly) wouldn't know where to put termination resistors on the board? Second, there are hardware designers who can write compilers (software and hardware) and even GUIs. I'm one of them and I know I'm far from the only one. Anyone wants to fund open source FPGA tools, you know where to find me and we can put together a team.. Third, Zoltan Kocsi wrote: > 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. I don't know books on synthesis like > the Dragon Book on compiling. This severely limits the developer base. The Dragon Book is a bit dated for software compilers now too. Nevertheless, many techniques that apply to software also apply to hardware compilation, though particularly synthesis. The obvious stuff like eliminating unused logic, combining shared expressions, propositional logic and table-driven logic to reduce logic expressions etc. Dataflow analysis is surprisingly similar, though the control flow/data flow relationships are obviously a little different. More modern software compilation techniques are in some ways more applicable, because there is more and more emphasic on flow graphs and data relation graphs than before. (E.g. GVN on an SSA form (software compiler jargon) is a form of assembling a data relation graph). These techniques also apply, with a little sleight of hand, to hardware synthesis. That leaves the well known hard nuts of synthesising for an architecture's logic blocks, and fitting the whole thing. You're right, there's not a wealth of applicable literature. However, if you look at ASIC world, then you will even find a fair amount of free software oriented in that direction. What I'm saying is that the leap from one to another is not as great as you'd imagine, particular with more modern techniques, and particularly for the larger FPGA applications. (Those "system on a chip" things). Besides, good fitting, and fitting fast for dynamic designs, really _are_ hard nuts and to some extent, isn't it in the FPGA vendors interests to have pooled public research & development into these difficult problem? > In addition, the target audience is a much smaller lot than for > software tools or general purpose programs. There's a vicious circle here. Not many program FPGAs in comparison to say assembly language or C on microprocessors. But then, not many PC video cards use an FPGA to implement the 3d rendering algorithms... Not many high-speed network cards really use that FPGA to help the computer's applications. Not many supercomputer clusters are built from FPGAs. If the tools were available, then those sort of applications might become economic on FPGAs. There's no doubt in my mind that a cluster of high-speed FPGAs can out-compute a cluster of Pentium 4s for some problems. For one thing FPGAs are excellent communicators. Especially when FPGA compiler technology catches up with CPU compiler technology. Now that they're getting affordable, large, and not too power hungry, FPGAs are approaching the stage where they can seriously be applied to real computer problems like number crunching and dynamic web serving. (Compress video to match subscribers bandwidth and serve up, anyone?). But it's too hard to program them for anyone but hardware designers. Not least because to _learn_ to be a hardware designer requires time with tools that normal CS students will never see, and would never want to. Ok, this is a different topic from the open source one. But I do believe that until there are good open source FPGA programming solutions around, FPGAs aren't going to be used to their full potential as powerful processing devices. My 2p.. -- JamieArticle: 26173
(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. Details for these positions are pasted below. In addition to these specific positions, I have several others which require related skills and experience. Do you know of anyone who would be a good candidate for these positions? Please ask them to contact me immediately. Thanks very much. Brian Mason GateSource Partners brian@gatesource.com 703-502-8461 www.gatesource.com Title include: *Project Leader, Architecture Modeling *ASIC Architect, Network Processor *ASIC Design Manager *Senior Circuit Design and Analysis Engineer *Senior Applications Engineer Title: Project Leader, Architecture Modeling Location: Northern Virginia Compensation: Competitive Responsibilities: *To provide hands-on project leadership in development and maintenance of simulation models for high performance embedded network processors for communications applications. Qualifications Requires 4 years of experience in micro-architecture modeling using C/C++ or a high level hardware design language Experience with cycle accurate simulation modeling Experience with software engineering tools for managing large-scale software projects Additional Qualifications Knowledge of communication protocols Experience with mixed-level C/RTL simulation on a RTL simulator Knowledge of Verilog/VHDL. Title: ASIC Architect, Network Processor Responsibilities: * To develop ASIC architectures for high performance network processors. To provide ASIC architecture specifications to an ASIC implementation team. Qualifications: Requires 4 years of experience in ASIC and semi-custom micro-architecture development for submicron CMOS implementation Experience with pipelined and superscalar processor architectures Experience with hierarchical memory design using on-chip and off-chip memory technologies Experience with architectures in submicron CMOS operating above 100 mhz Additional Qualifications Hands-on experience with architecture modeling in C/C++ Hands-on experience with high performance logic design using Verilog/VHDL Knowledge of communication protocols Title: ASIC Design Manager Responsibilities: To provide hands-on leadership to communication ASIC implementation projects. Qualifications Requires 5 years of experience with ASIC design and implementation using logic synthesis, static timing analysis, equivalence checking, DFT tools and project management tools Experience with ASIC design and implementation using CMOS at .25micron and below, with operating speed at 100 mhz and above Experience with ASIC design and implementation using on-chip and off-chip memory technologies Experience with interfacing to physical design tools for placement and routing and achieving post-layout timing closure, Experience with interfacing with manufacturing teams for test development and package design Demonstrated managerial and leadership skills Additional Qualifications Direct experience in communications ASICs projects highly desirable Knowledge of communications protocols highly desirable Familiarity with top-down design and verification methodology using cycle-accurate high level simulation models and mixed-level simulation on RTL simulators Title: Senior Circuit Design and Analysis Engineer Responsibilities: To validate electrical and timing characteristics of an ASIC according to its specifications Qualifications Experience with circuit analysis and simulation in .25 micron and beyond, using 2D/3D physical extraction tools and Hspice Experience with design and analysis of I/O pad rings in .25micron CMOS and beyond, slew rate analysis, noise analysis, power consumption analysis Experience with critical path analysis and crosstalk analysis in .25 micron CMOS and beyond Additional Qualifications Experience providing guidelines and constraints to the physical design process Experience with phase-locked loop designs and analysis Experience with high speed SRAM designs and analysis Experience with signaling techniques such as LVDS Title: Senior Applications Engineer Responsibilities: To design communication boards for router/switch applications based on the company's communication ASICs and embedded software packages Qualifications Hands-on experience with designing and debugging communication boards for router/switch applications and communications protocols Experience with embedded real-time software packages in communications applications Experience with system interfaces to framers and switch fabrics Proven professional and interpersonal communication skills Additional Qualifications FPGA design using Verilog/VHDL and logic synthesis Experience with high speed board design for high performance memory subsystems My client US headquarters is in Northern Virginia. Company profile is pasted below. Thanks. Brian Brian Mason GateSource Partners brian@gatesource.com 703-502-8461 www.gatesource.com My client is a privately held company, specializes in the design and manufacturing of high-performance CMOS Application Specific Integrated Circuits (ASIC) for data communication network equipments. The company chip sets target ATM, Frame Relay and IP applications in the area of access devices, multiservice platforms, network interface cards, and edge/core switches and routers with gigabit bandwidth requirements. Their innovative chip set solutions are based on proprietary and patented technologies developed over the last decade by the key founding members, including real-time multithread processing, hierarchical traffic scheduling and shaping, and high-performance low-power circuit design techniques, serving as a basis for Acorn Networks' baseline communications processor architecture for OC-48c wirespeed operation, and readily scalable to OC-192c and beyond. The company has been funded by the DoD since August 1995 to develop advanced chip sets for ATM Segmentation and Reassembly at 2.5 Gbps and 10 Gbps. My client has also developed proof-of-concept prototypes using its own proprietary chip sets for high-end video transport over the WAN. In the first quarter of 2000, they raised its first round from MCI Worldcom Venture Fund, TechFarm, Chase Capital Partners and Capitol Ventures. Please email your resume immediately to: Brian Mason GateSource Partners brian@gatesource.com 703-502-8461 Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26174
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 -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 16 rue du Moulin des Bruyeres Tel +33 1 46 67 51 11 F-92400 COURBEVOIE - FRANCE Fax +33 1 46 67 51 01 http://www.IPricot.com/
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