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
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. 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). EricArticle: 82826
<shuss3@yahoo.com> wrote in message news:1113845249.689554.28780@g14g2000cwa.googlegroups.com... > 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. > You are only as good as your reputation. BobArticle: 82827
On Wed, 13 Apr 2005 21:56:38 +0200, Reinier <usenet@NO_SPAM.nl> wrote: >Hi, > >I'm looking for a freeware or low cost program do document and >illustrate the signal processing flow in my FPGA design. I'd like to >use building blocks like adders, multipliers, memory, busses etc. What >do you guys use to make some nice looking pictures? I don't want to >spend days learning Corel Draw or something huge like that. > >Thanks, >Reinier I have released a program called Circuit Scribe that is designed to produce decent looking circuit/schematic drawings, as well as netlisting (downloadable from http://www.cjseymour.plus.com/software.htm, which also has sample drawings and online help) You could create a custom library of your building blocks, with pins defined for the inputs/outputs to suit your flow chart requirements. Then if you want to rearrange the blocks, the interconnections will be rubber-banded. Drawing programs that don't do this are a real pain. Colin SeymourArticle: 82828
In article <d412dg$2kr$1@lnx107.hrz.tu-darmstadt.de>, Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: >Phil Tomson <ptkwt@aracnet.com> wrote: > >> Isn't it interesting how fast some Xilinx guys (FAEs?) jumped on the >> other thread about Spartan 3E being slower than Spartan 3, but we've >> heard nary a peep out of them about this thread? > >No theory of conspiration, please, No conspiracy theories here... > >Those guys (always helpfull and responsive) come from different areas then >the guys responsible for programming... Ah, makes sense. I do hope Xilinx is listening. It would be great to have a native Linux ISE 7.x in the future that works well on the platform and we're just trying to help them get there. PhilArticle: 82829
In article <qhis2j7smz.fsf@ruckus.brouhaha.com>, 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. I haven't tried it under Wine yet. However, I can tell you that the WindU version is unusable for me as it takes several _minutes_ to start up and then it takes minutes to respond to mouse clicks on various GUI elements. I have no idea why it would be that slow - it seems rather strange. I am not running anything like seti, either. My machine is a bit dated (800MHz Duron) but it shouldn't be _that_ bad. I suspect that running the windows version under Wine should be faster. > >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). But wasn't there some indication that they were moving to a native toolkit? PhilArticle: 82830
So, the 8 x 1uF capacitors aren't actually required regardless of how many MGTs are being used which seems to be the meaning in the UG ver 2.5? If I've got a XC2VP2 and am only using 2 RIOs, do I only need 1 x 1uF then? Thanks, Roger. "Ed McGettigan" <ed.mcgettigan@xilinx.com> wrote in message news:4263EAFA.9070408@xilinx.com... > jean-francois hasson wrote: >> I work on a project involving the rocketios. I have read the user guide >> and among other things notcied the decoupling advised : a very big >> capcitor at the output of the LDO (330 uF) and several smaller ones (1 >> uF). The user guide advises eight 1 uF. Are that many capacitors >> necessary especially when not all the rocketios (2 for instance in my >> case) are used ? Moreover I looked at the ML300 board design and I did >> not see these 1 uF capacitors so what is the right move here ? Any advice >> ? > > We did a rewrite of this section in the user guide (page 110) to clarify > this, but when I reviewed it again today it's still not clear. What it > should state is 1.0 uF for every 2 MGTs that are used and these should be > placed near the ferrite beads, which should be placed near the FPGA. > > If you are looking for an example of how Xilinx created a board that > uses the RocketIO, the ML300 is not a good choice as this was done > very early and is missing some of the final design recommendations. > > The ML310, ML321, ML323 and ML325 are better examples in this area > http://www.xilinx.com/ml310 > http://www.xilinx.com/ml321 > > EdArticle: 82831
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. JohnArticle: 82832
Roger wrote: > So, the 8 x 1uF capacitors aren't actually required regardless of how many > MGTs are being used which seems to be the meaning in the UG ver 2.5? > > If I've got a XC2VP2 and am only using 2 RIOs, do I only need 1 x 1uF then? That's right, a single 1 uF in addition to the 330 uF near the LDO. EdArticle: 82833
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. > 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"... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 82834
Phil Tomson <ptkwt@aracnet.com> wrote: > I haven't tried it under Wine yet. However, I can tell you that the > WindU version is unusable for me as it takes several _minutes_ to start > up and then it takes minutes to respond to mouse clicks on various GUI > elements. I have no idea why it would be that slow - it seems rather > strange. I am not running anything like seti, either. My machine is a > bit dated (800MHz Duron) but it shouldn't be _that_ bad. I suspect that > running the windows version under Wine should be faster. Probably there is someting wrong with your setup. One minute seems much too long. > > > >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). > But wasn't there some indication that they were moving to a native > toolkit? There were rumors about a QT port and some people (like me) spread them. No Xilinx insider objected however.... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 82835
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: 82836Hi, I tried to install ISE 7.1 machine and ran into some problem. But now my project which was in the folder C:/Xilinx is also missing. I am missing the folders that I added in this directory, and I don't know why???? Anyone has run into this problem or have any idea how to retrieve these folders, please help!!! I have re-install 6.1 back but still no luck :-( Thanks, ALArticle: 82837
Hi all, Have people had reasonable success getting samples of Spartan3E parts? The XS3S100E, for example. I ask this because I got burned by the slow rollout of Spartan XC3S400s. BradArticle: 82838
"Brad" <brad1@tinyboot.com> wrote in message news:1113861401.050628.69820@l41g2000cwc.googlegroups.com... > Hi all, > > Have people had reasonable success getting samples of Spartan3E parts? > The XS3S100E, for example. I ask this because I got burned by the slow > rollout of Spartan XC3S400s. > > Brad The XC3S100E engineering samples were quick to come through the rep (requested a month in advance of need). We do a lot of business with Xilinx so I'm not sure if our treatment was standard. The parts are alive.Article: 82839
gupta.gaurav@gmail.com wrote: > Somebody published nice tutorial on FPGAs. Describes architecture, > logic blocks and routing in common FPGAs. > > http://www.tutorial-reports.com/computer-science/fpga/index.php > > > best wishes > Gaurav > Thanks.Article: 82840
Phil Tomson wrote:
> But wasn't there some indication that they were moving to a native
> toolkit?
Uwe Bonnes wrote:
> There were rumors about a QT port and some people (like me) spread them.
AFAIK, all that anyone from Xilinx has said is that they are "moving away
from a GUI toolkit that is encumbered with a per-seat license fee."
(Neil Glenn Jacobson, on 18-Aug-2004):
http://groups-beta.google.com/group/comp.arch.fpga/msg/2d2521a183d89fea
That statement can be interpreted several ways. Not necessarily as a
"native" toolkit, though that would seem to make sense.
Possibly they are moving to a different toolkit, but haven't yet
released a version with the new toolkit, and decided to pay the
royalties on Linux Webpack downloads until that release.
Or possibly they've negotiated a new license for Wind/U that lets them
offer WebPack with a reduced (or zero) royalty, which is in the vendor's
interest since they will keep getting royalties on ISE.
Note that Qt still would have per-seat license fees, so I don't think
it's even in the running. There's a GPL license for Qt as well, but
Xilinx presumably doesn't want to GPL their tools.
> No Xilinx insider objected however....
But surely you don't expect to preannounce such things?
Eric
Article: 82841Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> writes: > And Wind/U is the only X Program that doesn't like my DISPLAY variable > ":0.0" and insists on ":0"... That's silly, but it doesn't seem like a big problem in practice. I have a simple wrapper script I use for invoking all the Xilinx tools, which sets up environment variables and such. It just sets DISPLAY to :0, and everything works fine. EricArticle: 82842
"Andy Peters" <Bassman59a@yahoo.com> writes: > revision/source control systems are an > absolute necessity for any FPGA design of reasonable (and > unreasonable!) size. [...] why do the tools > dump compile results, report files, constraint files and the "project > file" all into the same directory? What source control system are you using for which that causes problems? I use CVS and Subversion, and neither has any trouble with generated files (intermediate or final) being put in the same directory as the sources. > 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. That would be nice, but I don't feel to strongly about it. > (Maybe I want to try the same source with different vendor parts?) And Xilinx' motivation to help you with that would be...? EricArticle: 82843
Andy Peters <Bassman59a@yahoo.com> 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?
VLGPATH and VLGINCDIR should help you to keep sources and output
separate. However both option have been screwed up for many ISE revisions,
at least when running the GUI, and I am not sure abut their present
status. Any definite word word for Xilinx? Answer record 18495 still has the
option "Kladderadatsch" ('2. Another solution is to bring all your HDL files
in the directory where your ".npl" file is located. In this case, you can
just write `include "file.v".') still mentioned before the VLGPATH/VLGINCDIR
option...
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 82844Hi Mr. Mercury, "George Mercury" <george.mercury@gmail.com> wrote in message news:1113736584.049291.128540@o13g2000cwo.googlegroups.com... > Hello guys, > I just made a quick speed test in ISE 7.1 with a Spartan 3E device. A > 32-bit counter runs at 129 MHz in XC3S500E-4, but in a Spartan 3 > XC3S400-4 at a higher 168 MHz. Also checked a few other desings, like > DDR SDRAM controller, and they all run about 20% slower on Spartan 3Es. > I don't get it, isn't 3E series supposed to have the same core as the > Spartan 3? > > Best Regards > George You are correct that Spartan-3E FPGAs use the same general logic design as Spartan-3 FPGAs, are manufactured on the same 90 nm process technology as Spartan-3 FPGAs, and use the same manufacturing facilities. So why are Spartan-3E speeds files slower? The current Spartan-3E speed file is strictly based on conservative simulation results. Once silicon and manufacturing characterization is complete, the values are typically improved to better match real silicon. In theory, Spartan-3E FPGAs will be about the same performance as Spartan-3 FPGA. However, in theory, theory and practice are identical but in practice they are usually different. :-) We're just being conservative until characterization is complete. Also, look for improved performance for some architectural elements. The new Spartan-3E multiplier has additional pipelining options that boost performance. Likewise, there is new differential DDR circuitry (not to be confused with DDR SDRAM) that relaxes the critical timing path by 2X. In specific, we fully expect a Spartan-3E -4 speed grade to support DDR266 SDRAMs, just like a Spartan-3 -4 speed grade. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 82845
Hi Geoffrey,
What speed are you targetting? Virtex2 has embedded
Multipliers Only. The add has to be in Fabric. The MAC will get
inferred from your code and it should use whatever multiplier and
adder resources it needs in the xc2v3000. The key will be
your speed requirements - as that will determine whether or
not you will need to use pipeline registers in fabric between the
multiply and the final accumulator, as well as input/output
registers.
There is a trade-off between speed and register usage.
A single clock cycle MAC in VirtexII is one end of the
spectrum. At the other end in Virtex4 -12 with the built
in input/output and mutiply pipeline registers you can get
500MHz operation in the DSP48 (which also has much
lower power dissipation because of reduced fabric and
routing usage).
- Vic
Article: 82846Hi all, I had problems with the XCR3064.. finally was directed to a patch by Xilinx Answer 21168. Cheers, AlexArticle: 82847
Eric Smith wrote: > "Andy Peters" <Bassman59a@yahoo.com> writes: > > revision/source control systems are an > > absolute necessity for any FPGA design of reasonable (and > > unreasonable!) size. [...] why do the tools > > dump compile results, report files, constraint files and the "project > > file" all into the same directory? > > What source control system are you using for which that causes problems? > I use CVS and Subversion, and neither has any trouble with generated > files (intermediate or final) being put in the same directory as the > sources. Subversion and Visual Source (Un)Safe. It's not that the revision control systems have any problem dealing with the generated files -- it's just that there's no reason for that cruft to be in the repository at all. -aArticle: 82848
I wrote: > What source control system are you using for which that causes > problems? I use CVS and Subversion, and neither has any trouble with > generated files (intermediate or final) being put in the same > directory as the sources. "Andy Peters" <Bassman59a@yahoo.com> writes: > Subversion and Visual Source (Un)Safe. It's not that the revision > control systems have any problem dealing with the generated files -- > it's just that there's no reason for that cruft to be in the repository > at all. As I said, I'm using Subversion. And none of that cruft makes it into my repository. The repository only gets the files on which you do a "svn add". My sympathies on having to use SourceSafe. At least I assume you're forced to do so; no sane person would use it otherwise. I once worked for a company at which some of the developers were unhappy that CVS didn't have a GUI. I tried to explain that there were multiple GUIs available for them to choose from, but apparently they didn't like that and wanted there to be one "official" GUI. (Kinda like management wanting to buy commercial software so that there is "someone to sue".) Anyhow, they prevailed and we switched to SourceSafe. What a disaster! Before we made the switch, I read up on it a bit on Microsoft's web site. They were bragging about the features of the latest version, and one of those features was a tool to repair corrupted repositories. Huh? I've never *had* a corrupted repository with CVS. But they were common with SourceSafe. The details on that recovery tool pointed out that sometimes it couldn't completely repair the repository in one run, and you had to run it again. What, can't the tool tell when it's done? Typical MS brain damage. I'm *very* happen with Subversion. EricArticle: 82849
Uwe Bonnes wrote: > Eric Smith <eric@brouhaha.com> wrote: > > >>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. > And the other thing to make sure of is that you are using a Windows native version of msvcrt.dll. That can make a dramatic difference on ISE.
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