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 have a DDR design from Xilinx MIG and the lock signal never moves from '0'. So I have just created my own design with just a DCM and the lock signal still is '0'. I cant see that I am doing anything particularly wrong? Cheers JonArticle: 98676
<langwadt@ieee.org> wrote in message news:1142296809.622734.161470@i40g2000cwc.googlegroups.com... > >> 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 ) >> > > You used to? be able to kinda do that , you just had to read though the > log files to find the commands needed to pick the right files and put > that in to a .bat file. > Still works this way. The ISE IDE calls the inidividual command line tools and the command line issued is at the top of the report file from each tool (.bld file from ngdbuild, .mrp file from map, etc.). I agree with the complaint about the binary project files (stupid!!) and the funky directory structure, and it would be nice if the IDE spit out a .bat or makefile (it might - I'll check when I have a little more time). But all in all the ISE tools generate pretty damn good results for the money. I used to use Synplify, but I find XST does a more than adequate job for free. Keep up the good work, Xilinx, but listen to these unanimous IDE complaints! RobArticle: 98677
>> 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. I can do this repeatedly well with a normal thickish tip, the secret is to flood the area with flux before you start and do it before the flux dries. Nial.Article: 98678
Hi, As you know Xilinx does not specify clock to output MINIMUM time of their devices. They only specify clock to output MAX time. The Tco MIN is used in calculating hold margin when there are devices on the bus with positive hold time requirement. What is your experiance, how to deal with this situation, how to simulate best case? Regards WojtekArticle: 98679
Thank you very much for your detailed explanation. I really appreciated it.Article: 98680
Hi Paul Leventis, My Altera FPGA boards is UP2 development kit-programmable logic for education, with MAX EPM7128S &FLEX 10K EPF10K70 devices. Thanks!! Laura Paul Leventis =E5=AF=AB=E9=81=93=EF=BC=9A > Hi Laura, > > Could you please post the product id or name and manufacturer of the > board you are using? There are a lot of Altera FPGA boards floating > around. >=20 > Regards, >=20 > Paul Leventis > Altera Corp.Article: 98681
Brian Drummond wrote: > A good starting point is Peter Ashenden's "VHDL Cookbook". I disagree. It is a real nice book for advanced VHDL designers, but not for beginners. It shows a lot of not synthesizable code, a lot of features of the VHDL language (which may be confusing for a beginner), uses the data type bit / bit_vector which is not recommended and so on ... For me Douglas J. Smith "HDL Chip Design" has of great help learning both VHDL and Verilog. RalfArticle: 98682
Maybe not quite what your are looking for but we have a new add-on module that can be used as simply as a XC9572XL CPLD holder. It is actually an IDE interface but can be made to do a number of things by programming your design into the CPLD. Pinned out on 0.1 inch pitch is relatively easy to use on a stripboard. Picture on our Raggedstone1 webpage if you are interested. John Adair Enterpoint Ltd. - Home of Raggedstone1. The low Cost Spartan-3 Development Board. http://www.enterpoint.co.uk "Paul van der Linden" <msn@paultjuh.org> wrote in message news:44159b38$0$2337$2e0edba0@news.tweakdsl.nl... > 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.pdfArticle: 98683
Hi Jean-Baptiste, you can download a presentation about my work in: http://www.ii.uam.es/~igonzale/recursos/Self_Reconfigurable_Coprocessors.pdf I think it will be useful to understand how to develop slice-based bus macros :) Regards Ivan jean-baptiste wrote: > Hello Ivan, > > I would like to do a slice-based bus macro. > > But i don't know how to do. Could you help me or show me the direction? > > Jean-BaptisteArticle: 98684
Xess has an appnote with a sample makefile. It depends on (included) perl scripts to get and set variables from Xilinx files but shouldn't be hard to simplify if needed. http://xess.com/appnotes/makefile.html Regarding comments that eclipse is too slow, a native version is available for both Ubuntu and Fedora. http://packages.ubuntulinux.org/dapper/devel/eclipse-platform-gcj http://sourceware.org/eclipse/ And here's another eclipse hdl editor. http://veditor.sourceforge.net/ Gary A. Gorgen wrote: > Bob Perlman wrote: > > < snip > > > > > A question for the many folks who use the IDE: what does it really buy > > you that the command tools don't? > > > > Memory leaks. > Trashed project files. > Seg faults all over the place. > About 100 major bugs, and about the same amount of bad design. > Then there is the schematic capture, pathetic! > > Anyhow: > To stay on subject. > I use ClearCase and cvs/rcs. > > Would anyone care to post a Makefile rules template for "ise". > Of the form: > > .c.o: > $(CC) $(CFLAGS) -c -o $@ $< > > > I've been giong to write one but haven't had the chance to sit down > and figure it out yet. > > Or just a simple Makefile for some project, would be helpful. > > Thanks for any help that can be provided. > > > -- > Gary A. Gorgen | "From ideas to PRODUCTS" > tunxis@comcast.net | Tunxis Design Inc. > | Cupertino, Ca. 95014Article: 98685
deunhido@gmail.com wrote: > Xess has an appnote with a sample makefile. It depends on (included) > perl scripts to get and set variables from Xilinx files but shouldn't > be hard to simplify if needed. > > http://xess.com/appnotes/makefile.html > Thanks, that's just what I need. < snip > -- Gary A. Gorgen | "From ideas to PRODUCTS" tunxis@comcast.net | Tunxis Design Inc. | Cupertino, Ca. 95014Article: 98686
Wojtek2U wrote: > Hi, > > As you know Xilinx does not specify clock to output MINIMUM time of their > devices. They only specify clock to output MAX time. The Tco MIN is used in > calculating hold margin when there are devices on the bus with positive hold > time requirement. > What is your experiance, how to deal with this situation, how to simulate > best case? IIRC there was an earlier thread on this, and I think the consensus was to use one quarter of the MAX time. [.. but the IC vendors really _should_ include this in the data sheets...] -jgArticle: 98687
Markus Zingg wrote: >>The BGA parts will probably not be within your capabilities. I have >>baked my own chips on before, but be prepared to ruin a few chips. > > > May I ask wether you ruin a few chips "per run" or up until one get > used to the process? What kind of oven are you using? > > Markus > Toaster Oven, and just until I get used to the process. Its alot easier to have an assembly house with the correct tools to do it!Article: 98688
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? > >> 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. > Paul I actually use a very fat soldering tip and regular solder. As long as things are aligned, it will go smoothly. Also, If you have solder bridges, dont worry, just wick off the extra solder. It's next to impossible to get all of the solder from under neath a pin, so its easy to clean up the solder bridges. Just run a toothpick across the pins to make sure they are soldered down. This isn't probably the best process for a production run, but you can get prototypes working with little hassle. -EliArticle: 98689
Uzytkownik <ghelbig@lycos.com> napisal w wiadomosci news:1141894341.833606.298410@i40g2000cwc.googlegroups.com... > The problem is that the 16R4 isn't HDL-friendly; use a 16V8 instead. > (Do they even sell 16R4's anymore?) Thank You so much! It works. I do not understand what is the difference between 16R4 and 16V8 and more others, but it works and i am gratefull :-) WojtekArticle: 98690
I have a program running on my board using the xilmfs. When the program completes, I want some of the files in the filesystem. As of now I am just printing the file and capturing text off my terminal because I can't find a way to just upload the whole filesystem from the board to my host. XMD works fine for getting the .elf and .mfs down to the board, anyone know how to get data back from it? Hopefully it's something easy that I have overlooked. Any advice appreciated. The filesystem is living in an external SDRAM if that matters at all... Thanks, JoeyArticle: 98691
All, And if it costs me X to see if the die is 100% good, and I only spend 1/4 X to see if it works for you, then my gross margin is higher, or I can charge less and keep the same gross margin if I test for you, and no one else. The Easypath flow is patented as a business method. The NRE is to develop the special test program to test just for your requirement, and to handle all the overhead of a new marking, new part number, etc. If they didn't even charge enough for the overhead in the structured ASIC business, no wonder they are all going broke while they ship their 150M$ a year (basically they wrap money around each part shipped). Many people think that if we find a part is bad, we know what is bad: that is not true. It costs a small fortune to identify any failure, on any part. That is called failure analysis, and requires a whole team of engineers working by hand. We do that on occasion, but try to avoid it at all costs. Failure analysis is done for yield issues, and design issues: not for a bad memory cell on one part! Another way of saying this is if I run test program "A" and I fill bucket for customers, and then I go to test program "B" and fill buckets for cutomers, and then go to test program "C" and take all parts that failed "A" and "B" (as well as new completely untested parts) and fill buckets. Did I care why anything failed "A" or "B"? No, I do not. All I care is that it passes "C". How does this affect reliability? Not at all. We have done reliability and qualification studies on Easypath (no different that what you do for any ASIC, ASSP) that prove that Easypath has perfectly acceptable reliability and life. These die had to meet the same defect density requirements as regular product, and they had to meet all other process requirements, so they are no different that any other. I direct you to read about LCD display "bad pixels." It turns out that all those beutiful displays we buy have some bad pixels. How many? Sometimes as many as 12 bad pixels are allowed, and they ship the display. Do you care? 12 out of 1760 X 1024 X 3? As long as they are not in a row, or in a cluster (read: as long as the application doesn't care) the display is perfectly "good." Easypath is one better. We prove that there are no faults that are visible. Austin Note: all figures above are merely examples of how Easypath works, and not actual numbers (which turn out to be much more atttractive). Also the test flow is not what we actually use, but an example of one flow that would work. John_H wrote: > Evan Lavelle wrote: > <snip> > >> No, it doesn't. If the silicon cost you *nothing*, then the biggest >> discount you could offer would be 35% before eating into your gross >> margins. And I can't believe that you do that, or that the silicon >> costs you nothing. Oh, and the unit cost advantage of ASICs has >> nothing to do with reduced testing. > > > Gross margins 101: > > If the part costs you nothing then your gross margins can stay at 65% > and be - NOTHING!Article: 98692
Thank you very much John. I want to implement a system run at 100Mhz(clk) at Xilinx virtexII -5 chip xc2v6000 and time-multiplexing should be able to satisfy my requirement. I used the DCM to get a 300Mhz(clkx3) signal from pin CLKFX and used it as the clock to the dual port RAM, which will render me 6 ports(dual x3) and it is enough for my application. By the way, DCM in this chip can provide up to 320Mhz signal and BRAM can run at about 387Mhz. (I am not sure about the BRAM frequency because I calculate it by myself) Now here is the new problem: after synthesis, while the clkx3 can achieve 287.9Mhz , which I will try to improve it to a higher number above 300Mhz later, the clk can only achieve 72Mhz. Shouldn't they have the relationship clkx3/clk=3, in which case I can get a 287.8/3=96Mhz? Anything wrong here? Besides generating the clkx3 signal, my clk only used to synchronize the output data from BRAM. Actually, if the only usage of clk is to generate clkx3, XST and synplify will still give me same timing result. Thank you very much for your kind suggestion.Article: 98693
Doh! I moved the coregen project file to C:\Projects\Cores to avoid the spaces, but I didn't realize it stored the path in the project file. I edited the path in the .cgp, and everything is working. The error should have been a hint... Oh well, I'm still learning ISE. I've used Altera MaxPlusII or Quartus my entire career - this is my first Xilinx based design. Thanks!Article: 98694
Jan Panteltje wrote: <snip> > I was reading about new Intel research and they mentioned 200mV > processor cores...... > It means a lower noise margin, but maybe the low impedances will > prevent spikes... or at least external influences. > Think this was about indium-antimonide. > So, when we get 200mV (100GHz) FPGA then yes, [always drivers] > but then perhaps we will have to go optical from the chip. Note in today's news: Researchers in Korea claim a 3nm FinFET and talk of 100GHz operations... -jgArticle: 98695
Hello, John. Because my target is to implement a 100Mhz(clk) system on vertexII xc2v6000-5 chip. I think the time-multiplexing way can satisfy my requirement because for this chip, DCM can provide up to 320Mhz and BRAM can run at about 387Mhz. (I am not sure about the BRAM value becasue I calculate it by myself .) I used DCM to get a 300MHz(clkx3) clock from hte CLKFx fpin and used it to get an 6 ports RAM. (dualportx3), which is enough for my application. But another problem arise, my clkx3 can achieve 287.9Mhz, which I will try to improve it a higher value above 300Mhz later , my clk can only achieve 72Mhz. These numbers are got after synthesis.I suppose that clk should be able to achieve 287.9/3=96Mhz. Anything wrong here? Thank you very much for your help again.Article: 98696
backhus schrieb: > In synthesis only one architecture per entity is allowed. I believe immediately that this is the case for ISE and many other VHDL compilers, but it is stupid. Why should a configuration not work for synthesis? I could tell the synthesis tool that I want a wallace tree for multiplier U1 and an array for multiplier U2. This is useful and it also is extremely easy to implement compared to all the other steps that are done in the systhesis process. I am working in EDA research for many years now and stil can not comprehend why on the algorithm and backend side EDA tools are always pretty close to the cutting edge of technology. But the parser and compiler frontend side lacks at least a decade (more like two decades) behind software compilers. I am baffled when a 80k$ asic targeted vhdl synthesis tool tells me that generics must be of type integer and that I can not have arrays of records and similar bugs. Kolja SulimmaArticle: 98697
First, let me try to address the reason why the ISE file is binary. A binary file allows us to manage concurrent reads/writes which is critical in making all the GUI applications work together. Binary files are faster and more efficient. Right now, there is a bug that is making the ISE file much larger than it needs to be. Also, a binary file can be more robust and requires less error checking. Access to the data in the ISE file is often important, so providing the capability to import and export is key. Check answer record 21067 for info on how to do this. Other than the GUI, the standard way to add info into the ISE file is Tcl, however, 8.2i will be required for this capability. Regarding keeping intermediate files in a separate directory, that is a great idea. We are planning on allowing you to specify the directory structure in the future. Regarding creating a batch file from the GUI, you can just cut and paste the commands from the command_log file. We do not hate version control and have plans to allow for integration with your source control systems. We are listening and taking your input seriously. Regards, Steve 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. > > JakeArticle: 98698
Hi Steve, Good to hear from someone in Xilinx Steve Lass wrote: > First, let me try to address the reason why the ISE file is binary. A > binary file > allows us to manage concurrent reads/writes which is critical in making all > the GUI applications work together. Binary files are faster and more > efficient. > Right now, there is a bug that is making the ISE file much larger than > it needs to be. So how can _that_ be faster and more efficent ? Did no one notice this ? Such an error would have been spotted very quickly with ASCII files.... Also, a binary file can be more robust and requires less error > checking. Yeeessss, only until said file gets corrupted, and then it becomes a brick wall. Moving across tool versions also a risk area, and likely to be a minefield.... > > Access to the data in the ISE file is often important, so providing the > capability > to import and export is key. Check answer record 21067 for info on how to > do this. Other than the GUI, the standard way to add info into the ISE > file is > Tcl, however, 8.2i will be required for this capability. and recovery from a corrupted file is done the same way ? Seems to me if you must use binary for your convenience, that you should also provide an easy ASCII import/export as well. That way, users CAN archive a 100% ASCII project ( and some (most?) WILL prefer to do this ), but they can also reap the benefits(?) of binary files during re-iterations. > > Regarding keeping intermediate files in a separate directory, that is a > great > idea. We are planning on allowing you to specify the directory > structure in > the future. that will be well received. > > Regarding creating a batch file from the GUI, you can just cut and paste > the > commands from the command_log file. Why should the (skilled) user have to trawl these log files ? It would be nice to configure via GUI, and then be able to run a created batch file, and get an indentical build. > > We do not hate version control and have plans to allow for integration with > your source control systems. > > We are listening and taking your input seriously. Many will be pleased to hear this. When is 8,2i due for release ? -jgArticle: 98699
Hi all, I have some program receiving data on a virtex-ii pro board. I'm trying to obtain information from the board, so I can process the data in a PC. The amount of data I try to retrieve is about at least 2MB. Can anyone suggest an efficient method to do so? Thanks.
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