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
I started using the Analog devices AD7814 and I'm having trouble understanding how to interface it to the Spartan 3 board. :( Does anyone have any suggestions to get me started? I could REALLY use the help!! Thanks!!Article: 82851
I wrote: > I'm *very* happen with Subversion. Should have been "I'm *very* happy with Subversion." I think I was very "happen" even before Subversion. :-)Article: 82852
Rudolf Usselmann wrote: > > yes, it is possible to replace the GUI with a script. At least > for ISE. I have not been able to figure out hot to do the same > for EDK (yet). > Assuming you are on Linux... (though presumably this should also work on Windows) The EDK project is run by a makefile, named system.make. So you can can build the project by typing commands like: make -f system.make netlist which builds the bitfile from HDL code, and make -f system.make program which compiles C code and inserts it into the bitfile. Those are about the only two EDK commands I use. I never use the EDK GUI. A list of commands is available with: make -f system.make Actually, I create a symbolic link ln -s system.make makefile which means I don't need to type out the "-f system.make" stuff. Of course, that doesn't get you the project in the first place. In general, I take an existing project that is similar to what I want, copy it over, and start modifying.Article: 82853
Andy Peters wrote: > ... > Complain complain complain. A directory structure like the following > would be nice: > > projroot\src <- target-independent HDL sources here > \testbench <- testbench sources and project here > \fitter <- fitter "project" (source list, constraint) here > \fitter\report <- report files and other sorta-usefuls > \result <- build result (.jed or whatever) > \temp (or work) <- intermediate delete-able crap > > So the question: what files in a Xilinx ISE project are necessary for a > successful build, and what files, if deleted, will be automagically > reconstructed the next time the toolchain is run? In other words, I > want to put my project into revision control and check it out anywhere > on any machine with the tools installed and rebuild my chip. The only necessary files for standard ISE projects are the project.ucf and project.npl files. The npl files actually determines the project structure completely. And this file recognises relative paths to all source files. So for example, put your source in the "src" directory as you want and then create your ISE project in the fitter directory. When you go to adding source, navigate to the src directory, and add the files. That's all there is to it. ISE will a project file named fitter.npl, and put it and all generated files into the fitter directory. While that does not separate out the different report/result files, it at least separates out all the source files. By the way, the npl file is plain text, so take a look at it. Here is one of mine: JDF G // Created by Project Navigator ver 1.0 PROJECT bfpq_ise DESIGN bfpq_ise DEVFAM spartan2e DEVFAMTIME 0 DEVICE xc2s200e DEVICETIME 0 DEVPKG pq208 DEVPKGTIME 0 DEVSPEED -6 DEVSPEEDTIME 0 DEVTOPLEVELMODULETYPE HDL TOPLEVELMODULETYPETIME 0 DEVSYNTHESISTOOL XST (VHDL/Verilog) SYNTHESISTOOLTIME 0 DEVSIMULATOR Other SIMULATORTIME 0 DEVGENERATEDSIMULATIONMODEL VHDL GENERATEDSIMULATIONMODELTIME 1102115550 SOURCE ../databuf.vhd SOURCE ../bfpq_fpga.vhd SOURCE ../pack.vhd SOURCE ../pack_p.vhd SOURCE ../ctrl.vhd SOURCE ../bfpq_pkg.vhd SOURCE ../sim.vhd SOURCE ../expgen.vhd DEPASSOC bfpq_fpga ../bfpq_fpga.ucf [Normal] p_AutoGenFile=xstvhd, spartan2e, Implementation.t_genImpactFile, 1102120478, True p_ChainDescFile=xstvhd, spartan2e, Implementation.t_genImpactFile, 1102119882, /home/design/bfpq/bfpq_fpga/bfpq_fpga_prom.cdf xilxNgdbldMacro=xstvhd, spartan2e, Implementation.t_placeAndRouteDes, 1102116271, .. [STATUS-ALL] bfpq_fpga.bitFile=WARNINGS,1105674959 bfpq_fpga.ncdFile=WARNINGS,1105674864 bfpq_fpga.ngcFile=WARNINGS,1105674611 bfpq_fpga.ngdFile=WARNINGS,1105674842 expgen.nc1File=ERRORS,0 expgen.ngcFile=WARNINGS,1102118954 [STRATEGY-LIST] le=False Normal=TrueArticle: 82854
Duane Clark wrote: > > The only necessary files for standard ISE projects are the project.ucf > and project.npl files. Oops, also the *.cdf files for running Impact, if you save Impact configurations.Article: 82855
Spartan 3E should help with this. The smallest Spartan 3E starts at under $2 in quantity (and fits a small MicroBlaze system) for an effective MicroBlaze cost of $.48 [1]. You may need a larger device to get everything you want, but I did want to point out that the $10 is a little high if one is going primarily for cost. It is not fair to compare the entire cost of the FPGA to just a hard processor and then use the rest of the FPGA for other stuff. In this case the FPGA is doing a lot more than the hard processor. As far as the benefits of a soft processor. MicroBlaze is highly configurable. You can turn on the features you need: instruction cache, data cache, FSL, XCL, FPU. See http://www.xilinx.com/ise/embedded/mb_ref_guide.pdf for more information on MicroBlaze v4.00.a. The other huge advantage of soft processors is the FPGA architecture itself. EDK has an FSL wizard to allow easy creation of accelerators. With careful acceleration of one's application, one can obtain performance that no hard processor can touch. EDK also includes a lot of other IP allowing one to build a System On a Chip (SoC) out of the box. It is a great deal for the price. Personally, I also find debugging on an FPGA a lot easier. One can simulate the EDK system and get a ton of information. I find ChipScope a lot more convenient than a logic analyzer and one can dig a lot deeper. Tracking down a bus issue on a hard processor can be a pain. On both sides there are lots of good tools if you want to spend the money, but I think the costs may be more reasonable on the FPGA side. If you have the need, Xilinx will sell the MicroBlaze source code for you to customize as you see fit. Try doing that at a reasonable price on a hard processor. I am not in marketing or sales, but I have no problem listing some of the advantages of soft processors. This post is my own opinion, and not an official Xilinx post. Reverse domain and remove the NOSPAM from e-mail address to respond by e-mail. [1] Xilinx. Xilinx Shatters Price/Density Barrier For Low Cost FPGAs With New Spartan-3E Family Starting At Less Than $2.00. http://www.xilinx.com/prs_rls/silicon_spart/0531s3e.htm Eric wrote: > Cost!!!! > > That is the main reason why Hard CPU's are still used. They are > cheaper.... a Phillips Arm 7 32 bit CPU is about $3.50 in quantity. An > FPGA with a similar size softcpu like a Microblaze is about $10. > > Soft CPU's are used for performance. They take advantage of the FPGA's > logic and use parallelizm to speed up operatiations (ie multipuly two > 32 bit numbers in a single clk cycle). A hard CPU would take 4 or more > clk cycles to multiply two 32bit numbers. > > So SoftCPU's used with FPGA logic can have a higher performance than an > equivelent hardCPU. > > So it totally depends on your application to whether a soft or hard CPU > is for you. > > EricArticle: 82856
All, From the GPD folks: The Spartan-3E has the same CLB and same process as Spartan-3 and therefore the majority of the timing numbers are expected to be the same. There are improvements to the I/O, DCMs, clocks, and multipliers, which may result in some minor improvements in performance in those areas. The reason for the difference right now is that these are the advanced (preliminary, whatever) numbers, which are based on simulations. The "real" speeds file will come later, after the part is fully characterized. Austin LeseaArticle: 82857
I posted this about a month ago, but I have a dos script that is easily modified for any script based os available for download on my website. Lots of advantages of script based flow, including solving a bunch of the problems that you enumerate. [1] Once one or more .edf netlists are available, I never use the GUI for backend synthesis. This is handled by the script. Inputs are .edf netlists and .ucf file. Therefore, the whole backend synthesis flow is repeatable and archiveable as a .txt file. [2] File paths customizable. [3] Synthesis directory is erased each execution. Rogue files from previous runs don't corrupt the current synthesis. [4] Archiving a design is now simply archiving .v/.vhdl files, .ucf file, and script. As a habit. I also archive .bit files so I can backup to a checkpoint without rebuilding. Files needed to recreate .bit file are pretty minimal. -- Regards, John Retta Owner and Designer Retta Technical Consulting Inc. email : jretta@rtc-inc.com web : www.rtc-inc.com "Andy Peters" <Bassman59a@yahoo.com> wrote in message news:1113861022.293528.264200@f14g2000cwb.googlegroups.com... > My quick seach shows that this question comes up occasionally but never > seems to get a decent answer. > > First, though, an observation: revision/source control systems are an > absolute necessity for any FPGA design of reasonable (and > unreasonable!) size. So, why do all of the FPGA vendors GUI toolsets > have rigid but stupid directory structures? I mean, why do the tools > dump compile results, report files, constraint files and the "project > file" all into the same directory? Why aren't we able to set up > reasonable directory structures? For instance, I want my HDL sources > in one directory, separate from the fitter tool's project directory. > (Maybe I want to try the same source with different vendor parts?) > Fitter reports should go into a directory of their own. Build results > -- the .jed or .pof or whatever results from the fitting -- should go > in their own directory. For that matter, what's with hard-coded paths? > > Complain complain complain. A directory structure like the following > would be nice: > > projroot\src <- target-independent HDL sources here > \testbench <- testbench sources and project here > \fitter <- fitter "project" (source list, constraint) here > \fitter\report <- report files and other sorta-usefuls > \result <- build result (.jed or whatever) > \temp (or work) <- intermediate delete-able crap > > So the question: what files in a Xilinx ISE project are necessary for a > successful build, and what files, if deleted, will be automagically > reconstructed the next time the toolchain is run? In other words, I > want to put my project into revision control and check it out anywhere > on any machine with the tools installed and rebuild my chip. > > Thanks, gang, > -a >Article: 82858
It's a tough call, I was in your position a couple of years ago. I accepted the offer, I'm glad I did. I'm assuming you're in your mid 20's.... So you have 40+ years of being an engineer and building your career. You can make the big bucks on your second job after you get a few years experience. Don't let your desire to make big bucks right out of college, cause you to pass up a good job offer. You'll be worth more after a couple of years. That's my 2 cents, EricArticle: 82859
In article <d418u5$5c9$1@lnx107.hrz.tu-darmstadt.de>, Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: >Eric Smith <eric@brouhaha.com> wrote: >> Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> writes: >> > They should talk to Codeweavers. I guess for the money Xilinx spends >> > on WindU, they could have Codeweavers weed out a lot of Problems in >> > Wine (and perhaps some in the Xilinx code) so that ISE would run >> > flawless in Wine. No more need for a WindU license and a single source >> > tree... > >> But running ISE in Wine is about 10x slower than running the Linux version >> with Wind/U. It's actually slower than running the Windows version under >> VMware, which surprised me. > >You probably run a kernel before 2.6.10. A fix for the communication between >the GUI and the worker programms was introduced with 2.6.10. This is good to know and it seems like a reasonable explanation... Turns out I'm running 2.6.3. I'll try rebooting with my old 2.4.something kernel when I get a chance. > >> Apparently the Wind/U royalties aren't that big a problem, since they're >> giving out Webpack for Linux now. I'd much rather have Wind/U than use >> Wine (either normally or with Wine code linked into ISE). > >And Wind/U is the only X Program that doesn't like my DISPLAY variable >":0.0" and insists on ":0"... I think that part was OK in my case. PhilArticle: 82860
In article <in8861dlu0347p98ce9f9m5uetqaf0rrr5@4ax.com>, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On 18 Apr 2005 10:27:29 -0700, shuss3@yahoo.com wrote: > >>I just got my first job offer with a semiconductor company. I am yet to >>sign the paperwork. I am hoping to get more offers in the forthcoming >>month. I am wondering if the paperwork that I sign for this company can >>be used against me if I turn down the position for a different one, say >>in a month? Is the paperwork legal and binding? My start date is not >>until July 1st. Thanks in advance for your inputs. > > >Are you in the USA? Slavery is no longer legal here; nobody can force >you to work at a job for one minute longer than you wish. > >If you want to be ethical, tell them you haven't made up your mind >yet, and request a few more weeks to decide. If you don't care about >that sort of thing, just fill in the forms and don't show up if you >get a better deal. The only person who really cares about the ethics >of your behavior is you. > And the hiring manager that you will have stiffed. If s/he's still the hiring manager in a few years when you approach him resume-in-hand s/he's not goint go give you the time of day. PhilArticle: 82861
Sometimes they turn up on eBay but they are described as an Altera Parallel Port or Printer Interface card - sometimes you have to read between the lines. I haven't seen any recently. Depending on the device you might be able to find a third party programmer.Article: 82862
If there's nothing seriously wrong with the offer, in todays economy take it, they can be more picky than you. You still got your career in front of you with the yet to come possibility of outsourcing later on making it harder for you. 20yrs ago the foot was on the other shoe, you could easily get 5 offers in quick succession and not worry too much about holding up 1st offer. While you are waiting it might not hurt to bone up about the company and products you will be in, if you are 1 of many fresh intakes, you can make a pretty good impression by getting in earlier with more knowledge than the other freshers. regards JJArticle: 82863
The best thing to do is to add the lower level EDIF file as an input file in the Synplify Project. Synplify will then be able to use the contents of the EDIF file as a timing model and an interface spec. The timing model will help Synplify optimize the logic around the EDIF instantiation. Ken McElvain Synplicity, Inc williams wrote: > Hello guys, > > I am working on a project which contain some IP core which is avaiable > to me in EDF netlist form. I am having the following doubt > I synthesis my verilog code in synplify and implementing this EDF in > the ISE. Now since i have my design in EDF format , how can i > instantiate a new IP core which in EDF format in my design which is > also in EDF file. > > Is there a way by which i can instantiate the netlist of IP core in by > verilog code. If so how do i do that? > waiting for your reply, > Thanks and regards > williamsArticle: 82864
You can implement X-modem protocol in your code at the microblaze and transfer datablocks with hyperterminal (or a better program: CRT). In these programs you can choose to transfer a file by using the X-modem protocol. In your program at the microblaze you only have to store the datablocks at the right place... Frank <kittyawake@gmail.com> wrote in message news:1113840801.505151.248480@z14g2000cwz.googlegroups.com... > Hi, > Yeah if any body has any idea of how this thing can be done please > share your views.I am stuck at this point and cannot proceed till i > solve this problem of getting data into microblaze from outside(say > using UART). > Thanx. > > Herb T wrote: >> Dan Henry wrote: >> > kittyawake@gmail.com wrote: >> >> Hi Dan, >> Can you give us some more specific details how to do it (or anyone > that >> knows ;-)? It would be a great help. >> Thanks, >> -HT >Article: 82865
austin wrote: > All, > > From the GPD folks: What's GPD btw ? SylvainArticle: 82866
Andy, I suggest you drop the GUI and start working with the command line tools. The GUI is OK for getting started and playing around a bit, but it has many limitations that make me feel very unproductive when I happen to use it. All of the command line tools have options for specifying the location of input and output file, so they need not be in the same directory. Some also provide a -dd option for intermediate files (the development system reference guide is your friend here). For my projects, I use the following structure : /src /work ../synth ..../out ../translate ..../tmp ..../out ../map ..../out ../par ..../out ../bitgen ..../out What you have to do to use these tools (they have names like ngdbuild, map, par, bitgen) is set up a build script calling each tool one after the other, with the right options. I use a PERL script for this, but a batch file will also do it at first. You could also have a look at XFLOW, which is a Xilinx tool for automating implementation steps. Once you are done with this, put your /src directory with all the source files, the /work directory structure (only the directories, not the output files), and your build script under version control. This should be enough to allow you to rebuild your project on any machine after checking it out. Hope this helps, Guy. Andy Peters wrote: > My quick seach shows that this question comes up occasionally but never > seems to get a decent answer. > > First, though, an observation: revision/source control systems are an > absolute necessity for any FPGA design of reasonable (and > unreasonable!) size. So, why do all of the FPGA vendors GUI toolsets > have rigid but stupid directory structures? I mean, why do the tools > dump compile results, report files, constraint files and the "project > file" all into the same directory? Why aren't we able to set up > reasonable directory structures? For instance, I want my HDL sources > in one directory, separate from the fitter tool's project directory. > (Maybe I want to try the same source with different vendor parts?) > Fitter reports should go into a directory of their own. Build results > -- the .jed or .pof or whatever results from the fitting -- should go > in their own directory. For that matter, what's with hard-coded paths? > > Complain complain complain. A directory structure like the following > would be nice: > > projroot\src <- target-independent HDL sources here > \testbench <- testbench sources and project here > \fitter <- fitter "project" (source list, constraint) here > \fitter\report <- report files and other sorta-usefuls > \result <- build result (.jed or whatever) > \temp (or work) <- intermediate delete-able crap > > So the question: what files in a Xilinx ISE project are necessary for a > successful build, and what files, if deleted, will be automagically > reconstructed the next time the toolchain is run? In other words, I > want to put my project into revision control and check it out anywhere > on any machine with the tools installed and rebuild my chip. > > Thanks, gang, > -aArticle: 82867
Since its your first job.. I would take it! You may not get a better offer.. but with some work experience you will always get a better offer. If the job fits with your ethics then there is no problem, if you work there for a year or two you are probably doing better than most Americans (so I've been told :-) It will give you time to work out what you really want to do ... and find a job you really want to do. and not to menton the bucks for toys. Simon "Phil Tomson" <ptkwt@aracnet.com> wrote in message news:d41tm311anu@enews3.newsguy.com... > In article <in8861dlu0347p98ce9f9m5uetqaf0rrr5@4ax.com>, > John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >On 18 Apr 2005 10:27:29 -0700, shuss3@yahoo.com wrote: > > > >>I just got my first job offer with a semiconductor company. I am yet to > >>sign the paperwork. I am hoping to get more offers in the forthcoming > >>month. I am wondering if the paperwork that I sign for this company can > >>be used against me if I turn down the position for a different one, say > >>in a month? Is the paperwork legal and binding? My start date is not > >>until July 1st. Thanks in advance for your inputs. > > > > > >Are you in the USA? Slavery is no longer legal here; nobody can force > >you to work at a job for one minute longer than you wish. > > > >If you want to be ethical, tell them you haven't made up your mind > >yet, and request a few more weeks to decide. If you don't care about > >that sort of thing, just fill in the forms and don't show up if you > >get a better deal. The only person who really cares about the ethics > >of your behavior is you. > > > > And the hiring manager that you will have stiffed. If s/he's still the > hiring manager in a few years when you approach him resume-in-hand s/he's > not goint go give you the time of day. > > PhilArticle: 82868
On Mon, 18 Apr 2005 09:42:27 -0700, "Symon" <symon_brewer@hotmail.com> wrote: >"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote [...] >> 7x oversampling is *just* about enough >> to be able to do this easily > >It's easy enough with just 4 times oversampling. XAPP224 shows how to do it >at 400Mb+ data rates. OK. I was recalling bad memories of an attempt to do DPLL with only 4x oversampling in a system where the cheap-and-nasty fibre optic transceivers introduced rather a lot of pulse width distortion, which made it a whole lot more difficult. Thanks for the reference. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 82869
buchty@atbode100.lrr.in.tum.de (Rainer Buchty) writes: > Consultant job in the NYC metro area as a freshly graduated PhD, ~100K/yr > A Friend of mine is working at LLNL (after a Postdoc year at Cornell), ~120K/yr Here in Oslo, Norway a newspaper delevery person working 29-39 hours a week can make $126K/yr (NOK 800K). No PhD required :-) Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 82870
Phil Tomson <ptkwt@aracnet.com> wrote: > > > >> But running ISE in Wine is about 10x slower than running the Linux > >> versionwith Wind/U. It's actually slower than running the > >> Windows version under VMware, which surprised me. > > > >You probably run a kernel before 2.6.10. A fix for the communication > >between the GUI and the worker programms was introduced with 2.6.10. > This is good to know and it seems like a reasonable explanation... Turns > out I'm running 2.6.3. I'll try rebooting with my old 2.4.something > kernel when I get a chance. Then apply the patch found with google and "FIONREAD Bonnes" to patch that bug. 2.4 had the same problem like 2.6 before 2.6.10 -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 82871
I gather some file from this machine, but I was only able to save it in binary format. What I need is in plain text so that I can correlate with my simulator. Anyone can give a pointer?Article: 82872
"Benjamin J. Stassart" <benjamin.stassart@MxAnPiSlOiNx.com> wrote in message news:<426457E4.3070600@MxAnPiSlOiNx.com>... > Spartan 3E should help with this. The smallest Spartan 3E starts at > under $2 in quantity "*500K unit volume, second half 2006" !!! plus you have to factor in the cost of: - the configuration prom - extra regulators that you wouldn't need with most micros - analog peripherals - possibly an oscillator - possibly some external RAM It's not quite a simple as multiple cost-per-LUT by the number of LUTs used. Cheers, JonArticle: 82873
In article <877jiztd2b.fsf@filestore.home.gustad.com>, Petter Gustad <newsmailcomp6@gustad.com> writes: |> Here in Oslo, Norway a newspaper delevery person working 29-39 hours a |> week can make $126K/yr (NOK 800K). No PhD required :-) Does that give any idea about the rent for a single one-room apartment and the average costs for food? Or is that newspaper delivery just an alibi job for some other, lesser legal delivery going on below the surface? :) RainerArticle: 82874
"Symon" <symon_brewer@hotmail.com> wrote in message news:<4263e34f@x-privat.org>... > "Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message > news:ft8761tdcb22fop7o910lkc8l5qlirhueg@4ax.com... > > If you don't have access to the original 16MHz clock, you can > > either try to recover it by locking a digital PLL on to the > > data transitions (7x oversampling is *just* about enough > > to be able to do this easily) > > It's easy enough with just 4 times oversampling. XAPP224 shows how to do it > at 400Mb+ data rates. > Cheers, Syms. Please correct me if I got the problem wrong. Is it right that I could define a counter (clocked with 125MHz) and define one counter position as the sample point which is located in the middle position neighborhood of the bit to sample ? The counter would be quasi started if the first transition is recognized. This transition could be recognized with a two stage flip flop chain in the 125Mhz clock domain. The problem would be that the following sample points would walk because 125/16 is a fraction number. Is that right ? Could that sample point walk even then if the oversample factor 125/x would be an integer number for example 120MHz/12MHz when 120MHz having 0.05% tolerance and 20MHz having 0.02% tolerance ? If I have 7 times oversampling would I need then an input stage with seven stages (XAPP224)? What additional clocks would I need then ? Or are four clocks sufficient? Thank you in advance. Rgds André
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