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
In article <v28gs5g1c1mkbc@corp.supernews.com>, austin@da98rkroom.com says... > Hi Keith, > > > For dataflow, no. For state machines, I don't think HDLs can be > > beat. > > Well, it depends. If you have a schematic library that allows you to draw a > flow diagram and makes it drag and drop, it's REALLY easy...and easy to > do...and easy to read. Doesn't that make it more of an HDL rather than schematic? There is some "synthesis" going on then. Perhaps I don't understand your tool. > > > The design is simply too large > > to make it practical though. > > There is NO design that is "simply too large to make it practical", as it > depends on how you draw your schematics. You actually think 1000 pages of > TEXT is "easier"??? You snipped the rest of my paragraph: > > I'm working on a custom logic design right now. It's done in > > VHDL and is very hard to follow, since many signals have > > different names depending on where they are. It's taken me > > *hours* to trace simple registers about a few muxes. I *wish* I > > had a schematic generating tool. The design is simply too large > > to make it practical though. I believe that generating schematics from this VHDL would be impractical. For example, the entity for the unit I'm responsible for (verification) is roughly 1000 lines of INs/OUTs (comments not included). That's going to make some rather large schematic blocks. I *highly* doubt even 1000 pages would contain this design. Add a zero and it still would likely not make it. OTOH, since it's text I can grep the files and trace signals between components rather quickly. I was a long time schematic bigot but I did the FPGA designs in VHDL, primarily as a learning exercise. If I had it to do over I'd likely do a mixed schematic/VHDL design and mix it along the dataflow/control logic line. I'd strongly consider a schematic tool that output VHDL netlists. Though I doubt I'll get the chance to play again. > > > > * Time consuming > > > > > > I'd argue that....as well > > > > Again, schematics are nice for dataflow. I very much dislike > > schematics for state machines. > > It depends on how it's drawn. Any tool can be abused, or used properly. > Fought with, or worked with. Very true. I'd like to learn some of the tools you work with. Perhaps I'd be an easy convert. > > With the "proper library" I'd rule the world. > > Bingo, and that is why I DO rule the world ;-) I guess I can't argue with that. > > > Er, actually, that is not true. It IS used for very large designs that > have > > > high clock frequencies. > > > > VHDL is too. ;-) > > Er, yeah. That's why the fast PCI cores are done in schematics ;-) PCI is fast?! > > > For most designs, it is better to simply use what you are most > comfortable > > > with. > > > > I'll dissent here. Documentation means something. My comfort > > isn't everything. > > Hum. I think we strap you to a chair, and make you drink four 2L bottles of > Diet Coke and see you say that after a few hours... Gee, you work in a nice relaxed atmosphere. I could get to enjoy such enlightened management. ;-) > > I document my VHDL to the nines (mostly > > because even I can't remember what I did last month). I find it > > hard to document schematics to the same degree. > > As I've said, a tool is only as good as the person using it. I have no > problem documenting schematics, and far better than I've seen HDLs > documented. And, as you've said, data path is just obvious...and therefore > would require much less documentation. It even has a built-in block > diagram. Again, I'd like to see your schematics. I'm always open to new ways of doing things. I get bored with the old ones. ;-) > > > As with any thing engineering, any tool can be used exceptionally as > > > well as poorly. > > > > Poor tools tend to be used poorly. Good tools may not be any > > better, but there is at least a chance. ;-) > > Well, then...DON'T USE ORDAD! Ordad? Tell us how you really feel! Don't hold it in! I used it for the board schematics. Orcad's output fit well into the fabs tool chain and it sorta did what I wanted it to do and the schematics worked well for debug. I certainly wasn't going to venture into the FPGAs with Orcad. One of the best decisions I made was to go with the Synplicity tools. ---- KeithArticle: 51476
Michael, > Basically, schematic entry tools are still in use only because people > without a software background are still allowed into a FPGA design > field. Your statement is just simply so foolish I have to believe you simply are not serious. If you are in fact serious, please let me know, so I can 'splain to you just how foolish such a statement is, for so many, many reasons. AustinArticle: 51477
Ann wrote: > Hello > My name is Ann and I'm student from Poland. I have to make a presentation > about Virtex, Virtex II and Virtex II Pro devices. I've got a few questions. > What is a slice and what for it was developed? > What are the major differences between Virtex, Virtex II and Virtex II Pro > devices? > If you have any presentation about those devices I would be very grateful > for sending it to me. > Thank you very much! > Ann > > > > > Hi Ann, the "official" info is on:http://support.xilinx.com/xlnx/xweb/xil_publications_index.jsp Some presentations and student materials are at: http://university.xilinx.com/univ/xup/labsfnd/downld.htm -- Tullio Grassi ====================================== Univ. of Maryland - Dept. of Physics College Park, MD 20742 - US Tel +1 301 405 5970 Fax +1 301 699 9195 ======================================Article: 51478
In article <MPG.188e2e7468c2d13198989d@enews.newsguy.com>, Keith R. Williams <krw@btv.ibm.com> wrote: >> Well, it depends. If you have a schematic library that allows you to draw a >> flow diagram and makes it drag and drop, it's REALLY easy...and easy to >> do...and easy to read. > >Doesn't that make it more of an HDL rather than schematic? There is >some "synthesis" going on then. Perhaps I don't understand your tool. When I had to do a moderate complexity state-machine oh-so-many years ago for a class project (a MIDI synthesizer), I decomposed it into a high level one-hot machine with a series of counter-driven steps within each superstate, coupled to a textual representation to guide my hand-translation. It actually worked fairly well, producing something which was reasonable to debug and modify. That style of design wasn't TOO bad. And you had to be clever when the class project was a Midi Synthesizer in a 4005, we didn't have much area budget in the FPGA. I LIKED that project. >> > VHDL is too. ;-) >> >> Er, yeah. That's why the fast PCI cores are done in schematics ;-) > >PCI is fast?! Some of the timing loops, when you consider that even 33 MHz PCI goes through I/O and that people had to get it to work on a Gen1 Virtex/Spartan II (or even a late generation 4000 series), its not easy. And with new ones being 133 MHz at 64 bit, PCI-X ain't trivially slow either. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51479
"Peter Alfke" <peter@xilinx.com> wrote in message news:3E233518.FDC1C675@xilinx.com... > My question is a big: WHY? > Yes, you might grow your own. When I was a kid we grew our own potatoes and > vegetables and made butter and slaughtered a pig every year. But that was out > of necessity, not choice. > Now I much rather make a decent salary and buy most of these things, and for > a hobby do some gardening, just for the fun of it.... > The benefit of the closed FPGA architecture ( and the intense competition > between "you know who") is an almost unbelievable rate of progress in > capabilities and ease of design. > Does anybody really want to go back to XC3000 and EXACT-like tools? > > For the user, the FPGA should just be a device that gets the job done with a > minimum of fuss and headache, sweat, risk, delay and money. Only for Xilinx > and Altera (plus a few others) is it the raison d'etre, but we are a small > community that gets their kicks ( and salary ) out of this effort. If you are > so eager to design an FPGA, come and join us and help us speed up progress > even more ! > But none of this griping about "open bitstreams". That's not where the real > progress could possibly be! > The exciting progress is in innovative FPGA applications. > End of soapbox. > (snip) First, I haven't actually done it yet, but I believe that Jbits is as close to open as just about anyone needs. It should be enough that one could write all the tools to generate bitstreams. But second, If you follow the argument above, Intel should distribute their processors without documenting the instruction set. If we all program in high-level languages we should never need to know it. Maybe that day will come, but it isn't here yet. If that did happen, we would not have things like Linux or FreeBSD which require at least a small amount of assembly code in the lowest level device drivers. (I doubt the competition between Xilinx and Altera is comparable to that between Intel and AMD.) Someone should define a file format containing all the information that is necessary to program the device, and write a Jbits calling program to generate the bits from such a file. )Though the challenge is to come up with a file format allowing forward compatability.) Then open source design tools could be written to generate such files. -- glenArticle: 51480
In article <Sm_U9.73636$3v.13458@sccrnsc01>, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >First, I haven't actually done it yet, but I believe that Jbits is >as close to open as just about anyone needs. It should be enough >that one could write all the tools to generate bitstreams. Actually, I say that .xdl is more important. Jbits replaces the back-end bitgen with a published API. But .xdl allows one to snip into the flow between placement and routing as well as between routing and bitgen/timing analysis, keeping everything else. Or to bypass mapping and construct your own mapper, with output to the router (no RLOC's however at this point, unfortunatly). It's much nicer to be able to rely on everything else in the flow. >But second, If you follow the argument above, Intel should >distribute their processors without documenting the instruction >set. If we all program in high-level languages we should never >need to know it. Maybe that day will come, but it isn't here yet. >If that did happen, we would not have things like Linux or FreeBSD >which require at least a small amount of assembly code in the >lowest level device drivers. (I doubt the competition between >Xilinx and Altera is comparable to that between Intel and AMD.) Intel documents the ISA, but it doesn't document a lot of internal instructions used in developing/testing. >Someone should define a file format containing all the information >that is necessary to program the device, and write a Jbits calling >program to generate the bits from such a file. )Though the >challenge is to come up with a file format allowing forward >compatability.) Then open source design tools could be written to >generate such files. Open source tools would do better targeting .xdl, and then someone writing an .xdl to bit translator with JBits if one wants to completely bypass the xilinx flow. I don't think anyone's done the logical experiment: Take a bunch of designs, pass them through Xilinx placement and an academic placement tool (eg, VPR) hacked to place Xilinx slices, then route with Xilinx's router. But I'd bet money that, on a large benchmark set and comparable effort (time), Xilinx will win if the academic placer is also simulated annealing based. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51481
hi,
1)wats wire-bond BGA and flip chip?
2)wat r other bit stream converters other than UART? i mean most
used bit-strem coverters?
3)concept of single data rate (SDR) and double data rate (DDR
I/O BLOCKS?
regards
naveen
Andrew Rogers <andrew@rogerstech.co.uk> wrote in message news:<3E21E328.10105@rogerstech.co.uk>...
> naveen wrote:
> > hi,
> > i would like to know the
> > concept of "BALL GRID ARRAY" used in the fpga technology.
> > thnax
> > naveen
>
> It's the method of soldering used. Cirular pads are fabricated on both
> the chip package and PCB. Small balls of solder are sandwiched between
> the chip package and the PCB.
>
> Regards
> Andrew Rogers
Article: 51482Hi, I am using ISE 4.2i webpack on a PC, OS is Windows ME. From the XST user's manual, it says it support command line mode. How to run a script file "xst -ifn script_file_name [-ofn] log_file_name"? In a DOS shell? I have tried, but it needs to setup new path. Where is the guide instruction about these settings if there were? The second question is about XFLOW. I searched the *.opt files and found they are only under epld and xc9500xl/xv directory. No *.opt files under fpga directory. And like the above question, in which shell to run XFLOW? Thanks in advance.Article: 51484
HI, iam working with the xilinx virtex 2 fpga board. can u tell me the sites where i can download the software on my PC. thanx naveenArticle: 51485
Well, I go back to my "WHY?" If somebody can prove that Xilinx sits as a hindrance between smart ideas and their implementation in a Xilinx FPGA, then I might cave in. Like the tasteless commercial tomatoes that enticed me to grow my own. But just based on some ill-founded wild conspiracy theory, coupled with complete disregard for the required effort and economic realities in a very fast moving field, I don't think it makes sense to argue for open-source FPGAs. There are much better things to get excited about. Peter Alfke ========================= "Nicholas C. Weaver" wrote: > In article <Sm_U9.73636$3v.13458@sccrnsc01>, > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > >First, I haven't actually done it yet, but I believe that Jbits is > >as close to open as just about anyone needs. It should be enough > >that one could write all the tools to generate bitstreams. > > Actually, I say that .xdl is more important. Jbits replaces the > back-end bitgen with a published API. > > But .xdl allows one to snip into the flow between placement and > routing as well as between routing and bitgen/timing analysis, keeping > everything else. Or to bypass mapping and construct your own mapper, > with output to the router (no RLOC's however at this point, > unfortunatly). > > It's much nicer to be able to rely on everything else in the flow. > > >But second, If you follow the argument above, Intel should > >distribute their processors without documenting the instruction > >set. If we all program in high-level languages we should never > >need to know it. Maybe that day will come, but it isn't here yet. > >If that did happen, we would not have things like Linux or FreeBSD > >which require at least a small amount of assembly code in the > >lowest level device drivers. (I doubt the competition between > >Xilinx and Altera is comparable to that between Intel and AMD.) > > Intel documents the ISA, but it doesn't document a lot of internal > instructions used in developing/testing. > > >Someone should define a file format containing all the information > >that is necessary to program the device, and write a Jbits calling > >program to generate the bits from such a file. )Though the > >challenge is to come up with a file format allowing forward > >compatability.) Then open source design tools could be written to > >generate such files. > > Open source tools would do better targeting .xdl, and then someone > writing an .xdl to bit translator with JBits if one wants to > completely bypass the xilinx flow. > > I don't think anyone's done the logical experiment: Take a bunch of > designs, pass them through Xilinx placement and an academic placement > tool (eg, VPR) hacked to place Xilinx slices, then route with Xilinx's > router. But I'd bet money that, on a large benchmark set and > comparable effort (time), Xilinx will win if the academic placer is > also simulated annealing based. > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51486
Peter Alfke wrote: > Well, I go back to my "WHY?" > If somebody can prove that Xilinx sits as a hindrance between smart ideas and > their implementation in a Xilinx FPGA, then I might cave in. I'd like partial reconfiguration on rectangular regions, rather than entire columns... pretty please? :) JohnArticle: 51487
Yeah, about the same time schematics are history, HDL will be so easy to use that monkeys will do most of the designs. I guess you better start eating more bananas. Got to keep that software background up to date. :-) "Michael S" <already5chosen@yahoo.com> wrote in message news:f881b862.0301141000.6baec97c@posting.google.com... > Basically, schematic entry tools are still in use only because people > without a software background are still allowed into a FPGA design > field. The day management will finally realize how much money can be > saved by keeping these people (a.k.a. hardware engineers) out of all > but the simplest FPGA designs - the time of the schematics will be > over. > These HW guys can't spell "version control" !!! Enough said. >Article: 51488
Off topic question...but I suspect many will have some insight... Looking for a good single board computer/passive backplane in a rack mount. Can anyone suggest a good company to deal with, that just may be around in a few years to come? Thanks, Bruce bp22@cornell.eduArticle: 51489
In article <3E248F61.77E1748E@cornell.edu>, Terry Herter <tlh10@cornell.edu> wrote: >Off topic question...but I suspect many will have some insight... > >Looking for a good single board computer/passive backplane in a rack >mount. > >Can anyone suggest a good company to deal with, that just may be around >in a few years to come? How small/what backplane? Eg, Via makes a nice all-in-one PC motherboard (C3 processor, chipset, video, audio, 100 mb ethernet, USB2, firewire) which retails for <$150 with a 900 MHz processor, <$130 for a FANLESS 600 MHz processor, and is 17cm x 17cm in dimension (mini-ITX form factor) http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51490
"Peter Alfke" <peter@xilinx.com> wrote in message news:3E2480C5.3B181E45@xilinx.com... > Well, I go back to my "WHY?" > If somebody can prove that Xilinx sits as a hindrance between smart ideas and > their implementation in a Xilinx FPGA, then I might cave in. I'd be ecstatic if the mapper no longer decided what was irrevocably grouped together before the P&R phase "took over" and I'd be ever so humbled if the router could actually produce critical routes the same as or better than what I get in FPGA editor with my "stumble around" approach to manual routing. I don't want to "thank god" every time I use the directed route constraints because I shouldn't have to go there in the first place. The whole concept of "critical path routing" has fallen on deaf ears over the years. Estimates can be made based on supplied constraints as to what the best achievable times are for certain paths then those paths prioritized in the placement and routing. The worst case paths are routed first, slowly filling up the part until only the paths with greatest slack are left. One thing I expect this would require is an ability to remap as suggested above. The silicon is ecellent, only desiring better propagation delays here or there (BlockRAM enable setup and clock to out times or delays to get on and off carry chains, for instance). The tools just don't seem to want to let us get the most out of the beautifully engineered devices. - another JohnArticle: 51491
Hi, What exactly is the error message that you get ? I had this problem with the APEX development board (Professional Version) from Altera. Then I found out that the COM port was being used by a backup power supply software on my computer. I uninstalled the s/w and it worked. The error message should help you out. bye, Prashant satchit_h@hotmail.com (satchit) wrote in message news:<ddf018f6.0301131035.4364f1c3@posting.google.com>... > Hi, > > I am trying to port a Nios-32 system on the SOPC Development board > with the Apex "EP20k1500EBC652-1X" chip. I am using the simple UART > core provided in Altera's Nios Development Kit to interface with the > RS-232 DTE interface provided on the board. But I can't get it to > work. Does anybody have a solution to this problem? > > thanks in advance. > > regards, > SatchitArticle: 51492
See earlier thread about signal (net, language) naming conventions. There is a reason that we use them! You may consider doing just that; pick a naming convention, and start cleaning up the code. It will make it much easier for the -next- bug. Couple of perl scripts, emacs with vhdl-mode, and a fair amount of time. SH Keith R. Williams <krw@attglobal.net> wrote in message > > I'm working on a custom logic design right now. It's done in > VHDL and is very hard to follow, since many signals have > different names depending on where they are. It's taken me > *hours* to trace simple registers about a few muxes. I *wish* I > had a schematic generating tool. The design is simply too large > to make it practical though. >Article: 51493
Austin Franklin wrote > For most designs, it is better to simply use what you are most comfortable > with. As with any thing engineering, any tool can be used exceptionally as > well as poorly. I can see how you can mimic the functionality of a schematic in a programming language. But the other way round seems tough.Article: 51494
John_H wrote: > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3E2480C5.3B181E45@xilinx.com... > > Well, I go back to my "WHY?" > > If somebody can prove that Xilinx sits as a hindrance between smart ideas > and > > their implementation in a Xilinx FPGA, then I might cave in. > > I'd be ecstatic if the mapper no longer decided what was irrevocably grouped > together before the P&R phase "took over" This is planned for our next major release. > and I'd be ever so humbled if the > router could actually produce critical routes the same as or better than > what I get in FPGA editor with my "stumble around" approach to manual > routing. I'll need some more info on this. Did the design meet timing? That is the goal of our tools, not getting the best route for each net. > I don't want to "thank god" every time I use the directed route > constraints because I shouldn't have to go there in the first place. > > The whole concept of "critical path routing" has fallen on deaf ears over > the years. Estimates can be made based on supplied constraints as to what > the best achievable times are for certain paths then those paths prioritized > in the placement and routing. The worst case paths are routed first, slowly > filling up the part until only the paths with greatest slack are left. Even if we routed a net first, there is no guarantee that the router wouldn't rip it up to meet timing on another net. The current router is constantly making tradeoffs to improve the overall design. > One > thing I expect this would require is an ability to remap as suggested above. > > The silicon is ecellent, only desiring better propagation delays here or > there (BlockRAM enable setup and clock to out times or delays to get on and > off carry chains, for instance). The tools just don't seem to want to let > us get the most out of the beautifully engineered devices. On the other hand, if the silicon had twice as many routing resources, we wouldn't have to make so many tradeoffs in the software. Routing is a difficult task. I would guesstimate that we have over 60 man years of effort into the router. The placer has even more. Does somebody really want to take this project on? Steve > > > - another JohnArticle: 51495
I posted this afew days ago. Nobody answered, possibly out of compassion for my ignorance. But the truth will (may?) set me free so I am still interested in a clarification. BTW, I know that the DLLs are really in the corners of the die. At least I _think_ I know that :-) Peter Alfke wrote > We always distribute the global clock(s) on one or two horizontal "backbones" > across the chip, but we gate off any vertical "rib" or "branch" that is not > used. This is done automatically without any user intervention. It means that > vertically oriented clocked logic draws less power than horizontally oriented > one. And the carry structure always groups counters and accumulators > vertically. :-) This is probably a nomenclature confusion, but if I go into fpga_editor, it looks as if the backbones are vertical, with horizontal distribution spines feeding all the flops in a quarter of a row. I always assumed that it is these horizontal lines which are turned off to minimize power. This is with Virtex/E.Article: 51496
In article <3E24A539.2A9E34B8@xilinx.com>, Steve Lass <lass@xilinx.com> wrote: >> I'd be ecstatic if the mapper no longer decided what was irrevocably grouped >> together before the P&R phase "took over" > >This is planned for our next major release. Thats very good. >> and I'd be ever so humbled if the >> router could actually produce critical routes the same as or better than >> what I get in FPGA editor with my "stumble around" approach to manual >> routing. > >I'll need some more info on this. Did the design meet timing? That is the >goal of our tools, not getting the best route for each net. I've personally noticed that, without turning on maximum effort routing, there is a noticable drop-off in performance even for a fully laid out datapath. This always struck me as strange, as most of the connections in the design were direct horizontal/vertical alignment and the critical path was being defined by one of these connections to an ajacent BlockRAM. >On the other hand, if the silicon had twice as many routing >resources, we wouldn't have to make so many tradeoffs in the >software. Routing is a difficult task. I would guesstimate that we >have over 60 man years of effort into the router. The placer has >even more. Does somebody really want to take this project on? However, I think someone can do a lot better than the placer for datapath designs. Is it the responsibility of the synthesis tool (which can easily infer the datapath but throws this away) or the placer? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51497
"Nicholas C. Weaver" wrote: > In article <3E24A539.2A9E34B8@xilinx.com>, Steve Lass <lass@xilinx.com> wrote: > >> I'd be ecstatic if the mapper no longer decided what was irrevocably grouped > >> together before the P&R phase "took over" > > > >This is planned for our next major release. > > Thats very good. > > >> and I'd be ever so humbled if the > >> router could actually produce critical routes the same as or better than > >> what I get in FPGA editor with my "stumble around" approach to manual > >> routing. > > > >I'll need some more info on this. Did the design meet timing? That is the > >goal of our tools, not getting the best route for each net. > > I've personally noticed that, without turning on maximum effort > routing, there is a noticable drop-off in performance even for a fully > laid out datapath. This always struck me as strange, as most of the > connections in the design were direct horizontal/vertical alignment > and the critical path was being defined by one of these connections to > an ajacent BlockRAM. > > >On the other hand, if the silicon had twice as many routing > >resources, we wouldn't have to make so many tradeoffs in the > >software. Routing is a difficult task. I would guesstimate that we > >have over 60 man years of effort into the router. The placer has > >even more. Does somebody really want to take this project on? > > However, I think someone can do a lot better than the placer for > datapath designs. Is it the responsibility of the synthesis tool > (which can easily infer the datapath but throws this away) or the > placer? It's currently the job of the placer. Physical synthesis may change that. Steve > > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51498
Sorry...should have been more informative. Looking for a 19" rackmount system...with a passive backplane and a single board computer...6U type size...etc. Desktop PCI in a more rugged frame... Thanks. "Nicholas C. Weaver" wrote: > In article <3E248F61.77E1748E@cornell.edu>, > Terry Herter <tlh10@cornell.edu> wrote: > >Off topic question...but I suspect many will have some insight... > > > >Looking for a good single board computer/passive backplane in a rack > >mount. > > > >Can anyone suggest a good company to deal with, that just may be around > >in a few years to come? > > How small/what backplane? > > Eg, Via makes a nice all-in-one PC motherboard (C3 processor, chipset, > video, audio, 100 mb ethernet, USB2, firewire) which retails for <$150 > with a 900 MHz processor, <$130 for a FANLESS 600 MHz processor, and > is 17cm x 17cm in dimension (mini-ITX form factor) > > http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51499
"Jeff" <dsfdsaf@hotmail.com> wrote in message
news:4b%U9.3017$%W2.514607@news20.bellglobal.com...
> Hi,
> I am using ISE 4.2i webpack on a PC, OS is Windows ME. From the XST user's
> manual, it says it support command line mode.
> How to run a script file "xst -ifn script_file_name [-ofn] log_file_name"?
> In a DOS shell? I have tried, but it needs to setup new path. Where is the
> guide instruction about these settings if there were?
>
All You need to do is :
[1] Add the system variable XILINX and set to the top level webpack install
directory.
On my PC this is C:\xilinx_webpack.
[2] Add to Path variable : %XILINX\bin\nt.
To modify, go to control panel .... system ... Advanced .... environment
variables.
I am not sure where these were defined in documention. Good luck.
--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
303-926-0068
email : jretta@rtc-inc.com
web : www.rtc-inc.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