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
Eli Hughes wrote: > The QFP devices (VQ100, TQ144 and PQ208) are do-able with some practice > with a standard soldering iron and some wick. How thin should the soldering iron be? > Your best best is to get a development board to experiment. If you need > a standard alone module check out the Avnet Virtex 4 Mini module or the > devices from Xess. The problem with the standard development board, is that they are expensive (starting from 150 dollar or something). But I think I will buy one. And I was also thinking of the feature, I want to be able to make my own devices, and using start kits for a final devices isn't right. PaulArticle: 98601
Paul van der Linden <msn@paultjuh.org> wrote: > Hi, > I'm very new to fpga, just came interrested in these things. > The only problem I think I will have is the soldering. > How to solder fpga's on the boards? I'm a student so I don't have money > for very expensive machines. > I want to be able to solder the whole range of packages of Xilinx > spartan 3e, will that be possible with not to expensive tools? > Package types: > Table 121: Xilinx Package Mechanical Drawings > Package Web Link (URL) > VQ100 / VQG100: http://www.xilinx.com/bvdocs/packages/vq100.pdf > CP132 / CPG132: http://www.xilinx.com/bvdocs/packages/cp132.pdf > TQ144 / TQG144: http://www.xilinx.com/bvdocs/packages/tq144.pdf > PQ208 / PQG208: http://www.xilinx.com/bvdocs/packages/pq208.pdf > FT256 / FTG256: http://www.xilinx.com/bvdocs/packages/ft256.pdf > FG320 / FGG320: http://www.xilinx.com/bvdocs/packages/fg320.pdf > FG400 / FGG400: http://www.xilinx.com/bvdocs/packages/fg400.pdf > FG484 / FGG484: http://www.xilinx.com/bvdocs/packages/fg484.pdf All VQ/PQ/TQ packages can be soldered by hand with decent equipment. Serveral Websites give sort of tutorials. You can also inspect all contacts easily. All CP/FG package require much more expensive printed circuits boards, can only be solder with much more expensive equipment and are hard to inspect after solder. Nothing for the beginner. But for the start, buy some development board, so you don't need to solder the FPGA at all. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 98602
Hi, for self-soldering BGAs have a look at http://www.lrr.in.tum.de/~acher/bga/ German only, but maybe helpful anyway. Nothing seems to be impossible ;) Andre Benjamin Todd wrote: > Hi Paul, > > You might manage the flat pack stuff with a tiny soldering iron and a bit of > luck, but the bgas are a different story. Even the 'professionals' mess up > when soldering these. > - aligning the BGA almost perfectly to the grid on the PCB is tricky > - Soldering these needs an oven with a compatible heat-curve, which changes > from lead-free to leaded components. > > Just last week I had two s2 200s that had to go to be x-rayed, turned out > they weren't soldered at the right temperature... > > So I wonder what your motivation is for this? If you're starting out, try > and get your hands on some starter kits, they're really good value, and you > can learn loads from them. > > If you're a student then go nag the electronics department, they should be > pleased you're taking an interest, and might have some stuff lying around, > plus if you could get some university-modules under your belt it would look > nice on your CV. > > Mind you, there's so much to be said for just doing things as you become > interested. > > I have to be honest and say that one of the big things that these Xilinx and > Altera chaps are missing out on is the hobbyist engineer-type. If only they > had that in mind when they built some of these starter kits, they'd sell > them by the shed-load. > > Ok, just my 2p. > BenArticle: 98603
how about a BGA to DIP converter socket? or, a BGA part pre-soldered to a board with through-holes for attaching connectors, wires, etc? spartan3 + power supply + SRAM on a stamp-sized board with breadboard type connectors on it? I know breadboard spartan3 dev boards are available, but it would be cool to get something tiny, cheap, and easily connected to. minus the switches, LEDs, 7segment LEDs, etc.Article: 98604
"fpga" <hy34@njit.edu> wrote in message news:1142274505.422868.6160@e56g2000cwe.googlegroups.com... > Thank you very much for the clever solution, John. But I think the 9 > dual-port RAM configuration can only give me 3 rd/wr ports. Where the > other read port comes from ? > > I think the configuration for the 9 dual-port RAM is like this: form > ram0 to ram8. Port A write to RAM0,1,2 and read from 0,3,6; portB write > to RAM3,4,5 and read from RAM1,4,7; PortC write to RAM6,7,8 and read > from RAM2,5,8. Then all the ports of the dual port RAM has been used > and we got 3 rd/wd portA,B,C. Where can I put the other read port? Did > I miss something? > Thanks a lot. The RTL (Verilog or VHDL) can take care of instantiating the correct number of dual-port RAMs. if( WeA ) MemA[AddrA] <= MemB[AddrA]^MemC[AddrA]^DinA; if( WeB ) MemB[AddrB] <= MemA[AddrB]^MemC[AddrB]^DinB; if( WeC ) MemC[AddrC] <= MemA[AddrC]^MemB[AddrC]^DinC; ... assign RdA = MemA[AddrA]^MemB[AddrA]^MemC[AddrA]; assign RdB = MemA[AddrB]^MemB[AddrB]^MemC[AddrB]; assign RdC = MemA[AddrC]^MemB[AddrC]^MemC[AddrC]; assign RdD = MemA[AddrD]^MemB[AddrD]^MemC[AddrD]; In this configuration you have 3 read/write ports using the same address for either read or write and you have a 4th read-only memory. The counting of memories needed to implement your n-port memory is only for resource determination; your synthesizer will - in the example above - need 4 memories to support RdB: a single port at MemB (which is shared with other dual ports) and two dual-ports with the other write addresses for the input and the read address for the output.Article: 98605
A BGA S3E to DIL is on the list. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk <aiiadict@gmail.com> wrote in message news:1142275608.445179.253990@z34g2000cwc.googlegroups.com... > how about a BGA to DIP converter socket? > > or, a BGA part pre-soldered to a board with > through-holes for attaching connectors, wires, > etc? > > spartan3 + power supply + SRAM on a stamp-sized > board with breadboard type connectors on it? I know > breadboard spartan3 dev boards are available, but > it would be cool to get something tiny, cheap, and easily > connected to. minus the switches, LEDs, 7segment > LEDs, etc. >Article: 98606
Paul van der Linden wrote: > Hi, > I'm very new to fpga, just came interrested in these things. > The only problem I think I will have is the soldering. > How to solder fpga's on the boards? I'm a student so I don't have money > for very expensive machines. > I want to be able to solder the whole range of packages of Xilinx > spartan 3e, will that be possible with not to expensive tools? Contrary to others experience, I've done BGA parts pretty successfully in "hobby mode", as well as with professional rework equipment. I've developed a few "tricks" that help. First, solder paste is very difficult to manage with hand placement. Instead, use water soluable flux on the board pads, and push a large solder ball over all the boards pads till you have a small shinny solder mound on each pad with a fairly uniform size to attach the BGA with. Clean the board well to remove the used flux, and apply fresh flux to both the board and the BGA balls. Second, position the BGA part on top of the pcb pads. It's very useful at this point to have a silk screened outline of the package to center the part with, that is very close to the real package size. Third, carefully place in a preheated convection oven, and bake. The correct time for this takes some practice and calibration of YOUR setup. Visually verify that the balls have a uniform "squat" on all four sides ... this generally means the parts wetted fine, and the part settled down on the balls at reflow temp. Read the lit about recommended profiles for various packages ... you may not be able to exactly do those profiles, but you can come close with some practice. I've had pretty good luck using several different table top forced air "convection ovens" with digital controls. These are fairly inexpensive, and typically can regulate temps within 10 degrees F or so. Their problem, is uneven air flow which may result in uneven board heating if you do not give this some thought. Two of the ovens I used, required setting the board on a soda can near the center of the oven, with the turn table removed. A third oven required fashioning a foil air duct to make sure the hot air flow evenly covered the board. I suggest getting a non-contact IR thermometer with a spot capability ... these can be had fairly cheaply from a number of discount sources, including Harbor frieght. Using a salvage pcb of similar size and mass as your "test board" you can experiment with your "profile". I would suggest starting with the oven preheated to about 10-25F higher than your expected solder temp, quickly inserting your test board, and letting it bake for 2-3 minutes, open the door and quickly read several spots on the test board with the IR thermometer before the cool air drops the temp too much. Let the test board cool back to room temp, and repeat several times increasing the bake time about a minute each time. When you find the point where the board just reaches the solder temp, you can then program the oven to turn off 2 min after reaching that temp, and slowly cool the board back down without thermal shocking the BGA. Another process, is to pickup some slavage BGA parts with a similar package, and make a test board with the on die thermal diode brought out to test points, so you can run the wires out the door and monitor the die temp as you develop your thermal profile. You can also do this with your own board and FPGA's. You can also epoxy attach several thermal diodes to a test board, and monitor the profile in real time at several points. Pickup some Solderquik reballing preforms for the parts you plan to use. That way you can clean off your mistakes, and reball the parts to try again. The one thing you do not want to do, is get the newer BGA's too hot, or thermal shock them with cold air. Older parts in BG432 and BG560 packages are much more forgiving. I would suggest learning this process with XC4K, Virtex, or Virtex-E parts in BG432/BG560 packages, and once mastered move on to newer high density packages.Article: 98607
I think "Architecture and CAD for Deep-Submicron FPGAs" by V. Betz, J. Rose and A. Marquardt is a good reference that you might like to check out. I am not sure whether it covers topics like clock tree synthesis and testing of FPGAs though. -Shyam Dominik F. wrote: > hi folks, > > can you recommend a book on FPGA design implementation, that touches the > following issues: > > -floorplanning (methodologies, tools) > -p&r > -clocking tree synthesis > -test > > thanks in advance. > > regards, > dominikArticle: 98608
Bob Perlman wrote: > On Mon, 13 Mar 2006 09:09:33 -0800, Tim Wescott <tim@seemywebsite.com> > wrote: > > >Jake Janovetz wrote: > > > >> Is there some internal Xilinx conspiracy against source code management > >> like SVN (subversion) and CVS? Or is it that the Xilinx guys don't use > >> version control to understand the goals? > >> > >> ISE 6.x used ".npl" files to contain the project information. These > >> were text-based making them at least somewhat SCM-friendly, but they > >> changed each and every time you saved the project even if nothing > >> changed. Some date code changed. Thus requiring an update... > >> > >> ISE 7.x came along and, even when the rest of the world was switching to > >> XML because of all the problems with binary config files, Xilinx decided > >> to move to a binary format ".ise" from it's .npl files. Now, each SCM > >> checkin required the whole binary file to be checked in each time rather > >> than just diffs (like the ISE 6.x days). > >> > >> ISE 8.x came along and the conspiracy became clearer. Xilinx held on to > >> its binary format but has apparently added a LOT more to the file. Now, > >> it's almost 1 MB!!! This means that my SCM repository grows by 1 MB > >> EACH TIME I do a checkin if I include the ISE file. That's ridiculous! > >> > >> > >> PLEASE Xilinx, be learn about CVS, SVN, and others, and how to design > >> file formats for SCM. Also, place all temporary files in a temp > >> directory and stop spamming my project directory. Oh, and one more > >> thing -- it would be nice to know which files from a CORE are necessary > >> to the project. Each CORE generates almost a dozen files and I'd rather > >> not add all of them to SCM. > >> > >> Jake > > > >I don't know if it's possible with the 8.x tools, but I detest IDE's so > >I figured out how to do it all with the command line tools. Thus, no > >npl files, no weirdo unexpected file changes, clean checkins, etc., > >etc., etc. > > I agree: I use the command line tools, which leaves me free to use any > source control system I want. > > A question for the many folks who use the IDE: what does it really buy > you that the command tools don't? > > Bob Perlman > Cambrian Design Works Ease of use, click and compile. Very simple and no trouble. I guess I am a newbie, but back when I had my 386SX I used DOS (no Win3.1 for me :) ) so command lines really are not a detterent for me. Plus I hate looking up command line parameters to perform a certain function, it becomes a pain. -IsaacArticle: 98609
I, too, prefer command line tools for many things. Unfortunately, when
I moved to Windows out of necessity (CAD software mainly), I realized
that the environment is just CL-hostile.
Customers and clients like to get nicely packaged projects that are easy
to startup and rebuild. IDEs favor that.
Also, I've taken a new appreciation to well-designed IDEs. They can
save a lot of time for those of us that spend our day shuffling among
dozens of tools. I just don't have the bandwidth any more to learn all
the options and remember them for so many tools and languages. A good
IDE is nice. Xilinx ISE tools are by far the worst tools I use at the
moment.
They should completely ditch their ISE line and build an Eclipse plugin
for their stuff. Eclipse is a fantastic environment.
Jake
> I agree: I use the command line tools, which leaves me free to use any
> source control system I want.
>
> A question for the many folks who use the IDE: what does it really buy
> you that the command tools don't?
>
> Bob Perlman
> Cambrian Design Works
>
Article: 98610sachink321@gmail.com wrote: > thers no problem with synthesizer nor simulation results > infact simulation results show the output in high impedance > but when i check(using logic probe) that on hardware its not in high > impedance Ummmm, how is the logic probe supposed to know that the pin is tristated? -aArticle: 98611
Paul van der Linden wrote: > Eli Hughes wrote: > > The QFP devices (VQ100, TQ144 and PQ208) are do-able with some practice > > with a standard soldering iron and some wick. > How thin should the soldering iron be? Look at the range of Metcal tips. A drag-hoof tip works best for QFPs and TQFPs. > > Your best best is to get a development board to experiment. If you need > > a standard alone module check out the Avnet Virtex 4 Mini module or the > > devices from Xess. > The problem with the standard development board, is that they are > expensive (starting from 150 dollar or something). But I think I will > buy one. A decent (read: Metcal) soldering tool and proper tips will run double the $150. > And I was also thinking of the feature, I want to be able to make my own > devices, and using start kits for a final devices isn't right. Then you'll definitely need to invest in the proper tools now. -aArticle: 98612
Paul-
We (www.opalkelly.com) routinely solder the QFPs by hand. Your best bet
is to get a solder paste syringe from DigiKey and a hot air pencil. You
can also use an iron, but the paste melts really well under hot air.
Apply a very thin line (just enough to avoid separating the line as you
draw it) just inside the outer edge of the pads, then plop the part
down. Using an iron, solder a couple corners to make sure the part
doesn't move. Then use hot air.
We do not do BGA by hand -- too costly. Although most contract
manufacturers consider BGA more reliable and easier to do than QFP
because they self-center better. Of course, with the new RoHS stuff,
many will need to do costly temp profiling until they nail the processes.
Of course, you could also buy smallish integration modules like what we
sell. They're more expensive than just a raw chip, but will save you a
lot of time. Ours also include a software API and USB connectivity
which is more than just the "chip on a board" eval boards have.
Cheers,
Jake
Paul van der Linden wrote:
> Hi,
> I'm very new to fpga, just came interrested in these things.
> The only problem I think I will have is the soldering.
> How to solder fpga's on the boards? I'm a student so I don't have money
> for very expensive machines.
> I want to be able to solder the whole range of packages of Xilinx
> spartan 3e, will that be possible with not to expensive tools?
>
> Package types:
> Table 121: Xilinx Package Mechanical Drawings
> Package Web Link (URL)
> VQ100 / VQG100: http://www.xilinx.com/bvdocs/packages/vq100.pdf
> CP132 / CPG132: http://www.xilinx.com/bvdocs/packages/cp132.pdf
> TQ144 / TQG144: http://www.xilinx.com/bvdocs/packages/tq144.pdf
> PQ208 / PQG208: http://www.xilinx.com/bvdocs/packages/pq208.pdf
> FT256 / FTG256: http://www.xilinx.com/bvdocs/packages/ft256.pdf
> FG320 / FGG320: http://www.xilinx.com/bvdocs/packages/fg320.pdf
> FG400 / FGG400: http://www.xilinx.com/bvdocs/packages/fg400.pdf
> FG484 / FGG484: http://www.xilinx.com/bvdocs/packages/fg484.pdf
Article: 98613
Andy Peters wrote:
> Paul van der Linden wrote:
>> Eli Hughes wrote:
>>> The QFP devices (VQ100, TQ144 and PQ208) are do-able with some practice
>>> with a standard soldering iron and some wick.
>> How thin should the soldering iron be?
>
> Look at the range of Metcal tips. A drag-hoof tip works best for QFPs
> and TQFPs.
We have the Metcal irons and a drag-hoof tip. Although I've only had
success with paste and the hoof tip, I've seen techs that are able to
wet the tip and drag it on the pins nicely. Definitely something I
don't have the hands for.
But the hot air pencils are pricey -- around $200-$400 on eBay for a
Hakko 851.
Jake
Article: 98614
aiiadict@gmail.com wrote:
> how about a BGA to DIP converter socket?
>
> or, a BGA part pre-soldered to a board with
> through-holes for attaching connectors, wires,
> etc?
>
> spartan3 + power supply + SRAM on a stamp-sized
> board with breadboard type connectors on it? I know
> breadboard spartan3 dev boards are available, but
> it would be cool to get something tiny, cheap, and easily
> connected to. minus the switches, LEDs, 7segment
> LEDs, etc.
>
Our XEM3010 product is similar to that, though using 0.8mm connectors to
another board. We sell the BRK3010 as a breakout board to bring the
pins out to lower-density breadboard sort of thing.
Jake
Article: 98615
Jake Janovetz wrote:
> Is there some internal Xilinx conspiracy against source code management
> like SVN (subversion) and CVS? Or is it that the Xilinx guys don't use
> version control to understand the goals?
>
> ISE 6.x used ".npl" files to contain the project information. These
> were text-based making them at least somewhat SCM-friendly, but they
> changed each and every time you saved the project even if nothing
> changed. Some date code changed. Thus requiring an update...
>
> ISE 7.x came along and, even when the rest of the world was switching to
> XML because of all the problems with binary config files, Xilinx decided
> to move to a binary format ".ise" from it's .npl files. Now, each SCM
> checkin required the whole binary file to be checked in each time rather
> than just diffs (like the ISE 6.x days).
>
> ISE 8.x came along and the conspiracy became clearer. Xilinx held on to
> its binary format but has apparently added a LOT more to the file. Now,
> it's almost 1 MB!!! This means that my SCM repository grows by 1 MB
> EACH TIME I do a checkin if I include the ISE file. That's ridiculous!
>
> PLEASE Xilinx, be learn about CVS, SVN, and others, and how to design
> file formats for SCM. Also, place all temporary files in a temp
> directory and stop spamming my project directory. Oh, and one more
> thing -- it would be nice to know which files from a CORE are necessary
> to the project. Each CORE generates almost a dozen files and I'd rather
> not add all of them to SCM.
I'm a subversion user, and I've been complain' about this for a couple
of years now. Not only about the binary formats that change between
major revs, but also the stupid default directory structure.
You would think that Xilinx would "eat their own dog food," but every
time you talk to an FAE they always say, "I'm a Real Man -- I never use
the GUI, only the command line." So it's not likely you'll get support
from the FAEs.
Yes, Xilinx: users WANT to keep the HDL sources in one directory (I
call this "src", the FPGA build instructions/"project" file/constraints
files in another directory ("fitter"), the testbench sources and
controls in a third directory ("testbench"), etc. Put build results in
a TEMP directory below the "fitter" directory, please. At least
there's usually an option to "reference source file from current
location" instead of the stupid tools copying the source to the same
directory as the project file.
You would think they could make command-line options consistent across
tools, but you'd be wrong. Why does ngdbuild want the part number
given as, say, xcr3256xl-tq144-10, but CPLDfit wants it as
xcr3256xl-10-tq144? (Why? Just to make your Makefile difficult.)
PS: Altera's no better. Nor Lattice.
-a
Article: 98616"Jake Janovetz" <jakeREMOVEjanovetz@REMOVEyahoo.com> schrieb im Newsbeitrag news:dv4h09$hp6$1@wildfire.prairienet.org... > I, too, prefer command line tools for many things. Unfortunately, when I > moved to Windows out of necessity (CAD software mainly), I realized that > the environment is just CL-hostile. > > Customers and clients like to get nicely packaged projects that are easy > to startup and rebuild. IDEs favor that. > > Also, I've taken a new appreciation to well-designed IDEs. They can save > a lot of time for those of us that spend our day shuffling among dozens of > tools. I just don't have the bandwidth any more to learn all the options > and remember them for so many tools and languages. A good IDE is nice. > Xilinx ISE tools are by far the worst tools I use at the moment. > > They should completely ditch their ISE line and build an Eclipse plugin > for their stuff. Eclipse is a fantastic environment. ROTFL - the want do that !! just for 8.1 they did major rework to have what they is better, so I am pretty sure they will stick with their new GUI for some while. Eclipse is nice, and yes that would real nice if all IDEs would be eclipse based, but hum I havent ever checked that, I was told that Eclipse is too slow on linux machines? maybe that guy who told me that (only a few week ago) needs a real computer and then eclipse will be ok with speed as well. AnttiArticle: 98617
"Antti Lukats" <antti@openchip.org> wrote in message news:dv20p0$5e1$1@online.de... > "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag > news:Iq_Qf.488$ng.39085@news20.bellglobal.com... > > if you read first locations - raw data !! out of xcf0xs that holds a valid > bitstream > then you must see > ff ff ff ff 99 66 aa 55 > or something alike the bit order may be reversed in the bytes > > I said .bit file, well a bit file can be programmed as is, eg included the > text header > as it want hurt, but you may strip anything before the ff ff ff ff < > > xapp544 tries to use the free platform flash area as read-write eeprom so > it > adds some special flags to rows to mark then free or dirty, > if you are looking for bitstream data then you need to check the plain raw > readback > data from platform flash, it really really does containt the bitstream > with no magic > applied, you can consider the platfrom flash as normal serial memory that > can > be read and written using custom jtag instructions > > antti > Interresting. So, my first try will be to program the .bit file content directly into the PROM. Further more, maybe I will try to remove unnecessary informations from the .bit file before programming it into the PROM. Thank you. Claude Sylvain Electro-Technica inc.Article: 98618
Paul van der Linden wrote: > Hi, > I'm very new to fpga, just came interrested in these things. > The only problem I think I will have is the soldering. > How to solder fpga's on the boards? I'm a student so I don't have money > for very expensive machines. > I want to be able to solder the whole range of packages of Xilinx > spartan 3e, will that be possible with not to expensive tools? > > Package types: > Table 121: Xilinx Package Mechanical Drawings > Package Web Link (URL) > VQ100 / VQG100: http://www.xilinx.com/bvdocs/packages/vq100.pdf > CP132 / CPG132: http://www.xilinx.com/bvdocs/packages/cp132.pdf > TQ144 / TQG144: http://www.xilinx.com/bvdocs/packages/tq144.pdf > PQ208 / PQG208: http://www.xilinx.com/bvdocs/packages/pq208.pdf > FT256 / FTG256: http://www.xilinx.com/bvdocs/packages/ft256.pdf > FG320 / FGG320: http://www.xilinx.com/bvdocs/packages/fg320.pdf > FG400 / FGG400: http://www.xilinx.com/bvdocs/packages/fg400.pdf > FG484 / FGG484: http://www.xilinx.com/bvdocs/packages/fg484.pdf The flat packs are solderable by hand. I do various chips, including FPGAs with up to 0.5 mm lead pitch. I use solder paste, and a soldering iron with a VERY fine point. I work under a stereo zoom microscope. You may be able to use one at your school, and bring the rest of the gear to it. I specifically have done the TQ144, which is 0.5 or 0.65 mm spacing, I forget. The BGAs can't be soldered by hand, because the balls are between the board and the package. You pretty much need an X-ray system to check the soldering, too. Also, note that some of these larger BGA parts are REALLY expensive. JonArticle: 98619
Antti Lukats wrote:
> Eclipse is nice, and yes that would real nice if all IDEs would be eclipse
> based, but hum I havent ever checked that, I was told that Eclipse is too
> slow on linux machines?
It is used here for java and C++ development.
Seems to work just fine.
Someday there will be verilog and vhdl plugins.
http://ivi.sourceforge.net/screenshots.html
-- Mike Treseler
Article: 98620Jake Janovetz wrote: > I, too, prefer command line tools for many things. Unfortunately, when > I moved to Windows out of necessity (CAD software mainly), I realized > that the environment is just CL-hostile. > > Customers and clients like to get nicely packaged projects that are easy > to startup and rebuild. IDEs favor that. > > Also, I've taken a new appreciation to well-designed IDEs. They can > save a lot of time for those of us that spend our day shuffling among > dozens of tools. I just don't have the bandwidth any more to learn all > the options and remember them for so many tools and languages. A good > IDE is nice. Xilinx ISE tools are by far the worst tools I use at the > moment. What about the (radical?) idea of the IDE setting the options, and then creating a full command line batch file as well. (they must do this already, in pieces ) In an ideal setup, it would be able to READ the batch files, and flip the options to match. That way, you get full two way movement between GUI and Commandline operation. If Xilinx WERE serious about version control, they would know the only way to ENSURE an identical build is to remove the GUI from the loop. They should provide better support for when a project goes into "don't break it" maintenance mode. -jgArticle: 98621
Thank you. I will try it the synthesizer and see the resource usage.Article: 98622
Jake Janovetz wrote: > I, too, prefer command line tools for many things. Unfortunately, when > I moved to Windows out of necessity (CAD software mainly), I realized > that the environment is just CL-hostile. > > Customers and clients like to get nicely packaged projects that are easy > to startup and rebuild. IDEs favor that. > > Also, I've taken a new appreciation to well-designed IDEs. They can > save a lot of time for those of us that spend our day shuffling among > dozens of tools. I just don't have the bandwidth any more to learn all > the options and remember them for so many tools and languages. A good > IDE is nice. Xilinx ISE tools are by far the worst tools I use at the > moment. > > They should completely ditch their ISE line and build an Eclipse plugin > for their stuff. Eclipse is a fantastic environment. > > Jake -snip- 1. Open DOS window 2. Switch to correct directory 3. type "make <enter>" 4. wait a while When doing burn & turn design, repeat steps 3 & 4 as necessary. To me, that's easer than an IDE. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/Article: 98623
I am too trying to get a DDR controller up and running on a Spartan 3 and have found MIG to be very frustrating. At the moment I am looking at the DDR controller on opencores and have got it simulating under modelsim. Not sure how easy it will be to get going on real hardware though. I have posted a few messages on here regarding DDR and havent really got any replies so either people are having trouble getting it working or are keeping quiet JonArticle: 98624
Tim Wescott wrote:
> 1. Open DOS window
> 2. Switch to correct directory
> 3. type "make <enter>"
> 4. wait a while
>
> When doing burn & turn design, repeat steps 3 & 4 as necessary.
>
> To me, that's easer than an IDE.
>
Yes -- I expected many responses like this. And I don't disagree with
them nor did I want to start a religious war between two preferred
styles of development. I just wanted to suggest that Xilinx make their
IDE style of development easier for folks to handle.
Afterall, when I ship product, I include project files for customers so
they can get up and running quickly and have a nice out-of-box
experience. With a couple dozen projects, the .ISE files now consume an
enormous amount of space on the CD or installer. About 65% ISE file,
30% precompiled bitfile, and 5% source.
Jake
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