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
Uncle Noah wrote: > Hi there > > it seems now that there is another download as "xapp730.zip" at the > Xilinx website. Has anyone checked this out? (i'm on pstn so will check > it tomorrow from office). > > so it was a leak :( It looks like the only .vhd files have nothing to do with a pcore :-) We've talked about airing "dirty laundry" being something people are reluctant to share, but this sounds along the same lines of being caught with the skirt tucked into the pantyhose! Nice.Article: 110176
the pcores flder is empty now :( can anyone email me the origianl zip file which has pdf and zip file in it? i guess Antti can do so. Antti can you please? Uncle Noah wrote: > Hi there > > it seems now that there is another download as "xapp730.zip" at the > Xilinx website. Has anyone checked this out? (i'm on pstn so will check > it tomorrow from office). > > so it was a leak :(Article: 110177
Hi all, I'm new in this field. Please guide me how can I proceed to implement the cyclone altpll megafunction in my own design. I compiled individually PLL and my own design but could not able to link-up both. Please help me.Article: 110178
KKay wrote: > Hi all, I'm new in this field. Please guide me how can I proceed to > implement the cyclone altpll megafunction in my own design. I compiled > individually PLL and my own design but could not able to link-up both. > Please help me. Use the wizard to generate a wrapper, then either include the wrapper in your project, or if you prefer cut-and-paste the code into your own file as required. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 110179
Hi Antti i am unable to get any download from lattice website and get the following message: "The file you have attempted to retrieve is not available at this time. We apologize for the inconvenience. If you continue to experience this difficulty, please contact the Webmaster" i have an account with lattice website as well. i am unable to download any zip or exe file but pdf files open correctly. anyone else facing this problem? any solution to it? Antti wrote: > Thomas Entner schrieb: > > > Hi Antti, > > > > have you any idea why it is that slow? Branch penalty? Or is the write that > > slow? Does the performance improve with caches on? (I have not looked > > closely at Mico32 yet, maybe it is intended to only be used with caches?) > > > > Regarding the GPL: I think it is sufficient if they clearly say that the > > softare is GPL-licensed and if they provide you the source-code on request. > > So they would be only violating the license if you ask them to provide you > > the source-code and they say "No". Once you have the source-code, you are > > free to publish it yourself on a web side (I am sure, you will ;-) > > > > Thomas > > > > www.entner-electronics.com > > > http://www.latticesemi.com/dynamic/index.cfm?fuseaction=view_documents&sloc=01-01-08-11-48 > > LatticeMico32 GPL sources no need to ask, just get it. > > AnttiArticle: 110180
rickman wrote: > > I think you missed Scott's point. He is saying that for a production > of any volume, you can let the manufacturer program the devices. They > are better equipped and at that point it adds little to the price. > Let's face it, the cost of testing any large FPGA is not trivial and > the cost of factory programming antifuse parts is lost in the noise. > In fact, once you let the factory program the parts, you can likely > save on test costs since you only need to test the logic you are using, > just like EasyPath, if I have the right name. So factory programming > will likely reduce the price of the antifuse parts over buying them > yourself even without considering the cost of programming them in > house. And let me expand on that. The dirty secret of our industry is that reprogrammable FPGAs are being used to cover for lacks in testing and vector creation. I came from a full custom background, and its shocking what passes for simulation and test now. The point is, when you reach production with these devices, the game changes. Our little lab rats are not sitting there plugging in the devices, so they are being programmed by the distributor, or in system. In other words, what was once formalized testing is now ad-hoc. Is this an advance? > > If the programming were done with something other than electricity, the > programming circuitry could be eliminated. I seem to recall a company > that used to provide fast ASIC-like prototypes with laser cutting of > traces. I have not heard much about them lately. What was the down > side of this approach? > I was very interested in the technology myself, until I ran into a veteran of the laser configurable chips. In a word, their contamination issues were paramount. Apparently blasting away at metal, or the need to have openings in the passivation, or both, was contaminating the chips. In any case, this method started in the days of two level metals. I doubt its equally attractive against eight or more metals, when you can only gain access to perhaps the top two. Scott MooreArticle: 110181
radarman wrote: > The structured ASIC's do cost more than a true ASIC, so you have higher > recurring costs, but the initial investment is lower (by an order of > magnitude - $100k vs $1M), and you lose less of your NRE, since you > aren't reworking the design to operate in an standard ASIC flow. There > is also the lock-in problem as well. If the firm ever quit making the > parts, you are SOL, as they own most of the ASIC IP. You have to hope > that you pick the right structed ASIC firm, or do a lifetime buy at > some point. The only saving grace is that you still have the original > design files, and can begin migrating to another process while you sell > off your current inventory. > > I haven't had a chance to use the process myself, since my employer can > afford to use FPGA's, or when the time arises, pony up for a true ASIC, > but it makes sense for middle tier players. You get most of the > advantages of an ASIC without the ridiculously expensive upfront costs. > I've looked at it, and all I can say is "grow a pair", and invest in COTS to get portable between fabs. Scott Moore PS. We are FPGA to proof full custom designs, so there is my bias right there.Article: 110182
scott moore wrote: > radarman wrote: > >> The structured ASIC's do cost more than a true ASIC, so you have higher >> recurring costs, but the initial investment is lower (by an order of >> magnitude - $100k vs $1M), and you lose less of your NRE, since you >> aren't reworking the design to operate in an standard ASIC flow. There >> is also the lock-in problem as well. If the firm ever quit making the >> parts, you are SOL, as they own most of the ASIC IP. You have to hope >> that you pick the right structed ASIC firm, or do a lifetime buy at >> some point. The only saving grace is that you still have the original >> design files, and can begin migrating to another process while you sell >> off your current inventory. >> >> I haven't had a chance to use the process myself, since my employer can >> afford to use FPGA's, or when the time arises, pony up for a true ASIC, >> but it makes sense for middle tier players. You get most of the >> advantages of an ASIC without the ridiculously expensive upfront costs. >> > > I've looked at it, and all I can say is "grow a pair", and invest in > COTS to get portable between fabs. Apologies, that would be Customer Owned Tooling, not that other acronym. > > Scott Moore > > PS. We are FPGA to proof full custom designs, so there is my bias right > there.Article: 110183
Mark McDougall wrote: > As for open-source, I'd love to see it myself, but it would be a > vendor's nightmare! "My design simulates fine but doesn't work in > silicon... I'm using the red-hat disto of Quartus II v7.4.5 patch level > 12 with the turbo annealing enhancements v2.1b4. Oh, and I found a bug > so I patched the timing analyzer myself too..." It's not any different for high end server companies like IBM, HP, SGI, .... etc where stability, crash free, operation are CRITCAL operational points for million dollar hardware sales. There is a reason each of these companies have legions of developers supporting the open source products on salary. On the other hand, if the vendors had absolutely crash free reliable products that were feature rich and fast that met everyones needs, there probably wouldn't be a discussion. So, the reliability arguement I believe is a red herring. IBM, SGI, HP, RedHat all ship stable open source products, which some argue are significantly more stable and secure than proprietary alternatives in the same high reliability server market, like Microsoft. It's probably baseless to believe that any vendor would allow their inhouse programming team supporting the open source EDA tools to have any less of a quality initiative than the tools they might augment or replace. With a much wider user base, and multiple vendor support, one would expect that the broader testing and broader developer base to actually produce better tools, better tested, and stable in comparison to cash strapped proprietary efforts. The common parts of the product should reach much better maturity and stability. As for vendor specific parts, that's no different than today, since the vendors in house team will be pretty much solely responsible for their chip support. Just as we see IBM, SGI, HP, etc ... all solely responsibly for their systems architecture and device driver code.Article: 110184
Michael Sch=F6berl wrote: > this question pops up every few months ... > - Most important is the CPU cache (so Intel Core 2 Duo with 4M should > give some speedup) It doesn't appear to be quite that simple. Frequency does matter. Case in point, my 2.2 GHz 0.5 MiB L2$ Athlon beats my 2.0 GHz 1 MiB by more than 10% on Synthesis and P&R, though the former also have dual channel memory. That said, I'm getting a Core 2 Duo tomorrow for the 4 MiB L2$ and other improvements. The extra core is completely irrelevent here, but doesn't hurt. I'll be sure to post a comparison between the three architectures. I disagree about the value of ECC. If you have memory issues, they are exceedingly unlikely to be silent errors (more likely a crash). Besides, if you're truly anal, compile twice for production and compare both. The same error won't happy twice. TommyArticle: 110185
shidan schrieb: > Are there any functional languages that can be compiled to hardware at > the same or greater level of abstraction than languages like Mitrion-C > and Handel-C. Is it all research or is there anything that is practical? > Hi shidan, You can use Matlab. but it is mostly limited to DSP Design and only available for XILINX FPGAs. Follow this link for more Information: http://www.xilinx.com/ise/optional_prod/system_generator.htm Also there are HDCaml and Confluence. And it seems they are open source. http://www.confluent.org/ have a nice synthesis EilertArticle: 110186
jajo schrieb: > Hi, > > Do you think that it is a good idea to control several blocks of the > design (for example with a 802.11 transceiver) with a finite state > machine? or maybe with a microcontroller? . The idea consists on > implementing everything into a FPGA. > > Thanks > Hi Jajo, can you offer any better idea? If you are just not sure what to prefer (FSM or microcontroller) find out the original(!) meaning of "KCPSM". :-) have a nice synthesis EilertArticle: 110187
May I use rocketIO (Virtex2PRO) in custom mode for serialize/deserialize STM-1 (155.52 Mb) ?Article: 110188
shidan wrote: > Are there any functional languages that can be compiled to hardware at > the same or greater level of abstraction than languages like Mitrion-C > and Handel-C. Is it all research or is there anything that is practical? Altera announced an HLL-C for their product line last spring, with HDL coupling. Mitrion-C, Celoxica and Impluse-C are all real production, hardly research.Article: 110189
Jim Granville schrieb: > Austin Lesea wrote: > > > Colin, > > > > Where are the scan cells? What does that have to do with anything > > whatsoever? > > > > The scan cells are where they are convenient. The scan chain is wired > > to the JTAG controller, and the JTAG controller is wired to the JTAG pins. > > > > Since I seem to be completely unable to help you, I apologize, as I > > think I am answering your questions, only to have you be frustrated, and > > ask me a seemingly completely unrelated new question. > > > > Perhaps I should quit, right now, and trouble you no further, > > I think the OP is questioning how the device programming affects JTAG ? > He mentions before programming, and after programming. > > If you are going to JTAG-scan a post-pgmd full system, I'd say it > helps to know which are IPs (to prevent accidental drive) > - I'm guessing that's what BSDLANNO does ? > > My understanding of bondary scan is that once you are in that mode, > the config fuses actually don't care, and the system does not know if > the device is new/blank/pgmd, so scan is the same in all cases. > > I think Colin is trying to confirm that, but with modern devices with > many IO options, it is not a silly question - and one could argue that > ideally, post pgm scan _should_ use the Pin-option information. > (but I don't think it does, on anyones CPLDs - correct me if I am wrong ? ) > > -jg Jim, the boundary scan with Xilinx silicon is *NOT* the same before programming/configuration and after. the effects how the IO programming affects the boundary scan behaviour is(or can be) different per cpld-fpga family, so I assume some missing description of this behavior is what causes issues to the OP. AnttiArticle: 110190
Who can will share the ready deserializer module? Would be very grateful... :) my male : axalay@gmail.comArticle: 110191
Use xtclsh. Whatever commands related to creating a project, adding files and setting partitions you might do through the GUI's tcl console, you can do in this shell. You can script it and avoid the GUI, as you see fit. Other tcl shells might also work. ymmvArticle: 110192
Hi everbody, I wanna implement VGA core at 1024x768x75Hz (15" LCD Monitor) on Spartan3E starter kit. I have got a few question. I have tried to find some detialed documents for VGA timing But I can't. There are 640x480 and 800x600 but there is no document for more resolution and refresh rate. - Front porch time, back porch time, and sync pulse times are same at every resolution (I think it's standard because VGA cards can change resulation and refresh rate for every value and every monitor??? But There are different values for 640x480 and 800x600 on the documents???) - What is hsync and vsync polarisation? What must I do if it's negative or positive? (invert the sync signal???) Why it is different for different resolution? - Any body can give me timing values or recommend any source? ( I can't a right document on the Vesa web page) ThanksArticle: 110193
On Wed, 11 Oct 2006, John_H wrote: > "Frank Leischnig" <leischni@vialux.de> wrote in message > news:Pine.WNT.4.64.0610111610270.3048@wxpvl06.iwu.fhg.de... > <snip> >> Does anyone know how I can adjust the clock polarity (without using the >> DCM CLK180 output)? >> >> Thanks >> >> Frank > > Do you explicitly have a problem if you invert the clock in your source > code? Do you mean something like: clk_n <= not clk; inst_ramb : RAMB16 port map ( clkb => clk_n, ... ); Will this be implemented into the "optional inverter" or into slice? I would not like it if the implement tools complain about "gated clocks", but as far as it works reliable I have no problem with this solution. I'll try it. Thanks FrankArticle: 110194
"shidan" <shidan@gmail.com> writes: > Are there any functional languages that can be compiled to hardware at > the same or greater level of abstraction than languages like Mitrion-C > and Handel-C. Is it all research or is there anything that is practical? You could take a look at Lava (http://www.cs.chalmers.se/~koen/Lava/), which is a hardware description language based on Haskell. TorbenArticle: 110195
Austin I have just pulled up my copy of IEEE1149.1 to check my terminology The proper name for a scan cell is "boundary scan register cell" and this is almost allways shortened to scan cell. Your CPLDs have them at every IO pin (and also some which drive programming). They are what is shifted out on TDO if your TAP controller (which is what can be placed wherever is convenient) has been placed into the correct state. If the input to the scan cell is before the VREF comparator then clearly I can only do CMOS levels, if it is after the VREF comparator then hopefully I can boundary scan with sstl. I think you will find that I have been asking the same questions, just each time assuming you know a little less. Colin Austin Lesea wrote: > Colin, > > Where are the scan cells? What does that have to do with anything > whatsoever? > > The scan cells are where they are convenient. The scan chain is wired > to the JTAG controller, and the JTAG controller is wired to the JTAG pins. > > Since I seem to be completely unable to help you, I apologize, as I > think I am answering your questions, only to have you be frustrated, and > ask me a seemingly completely unrelated new question. > > Perhaps I should quit, right now, and trouble you no further, > > AustinArticle: 110196
On 2006-10-12, wolfco2006@yahoo.com <wolfco2006@yahoo.com> wrote: > Use xtclsh. Thank you! I must have overlooked any reference to xtclsh in the documentation. /AndreasArticle: 110197
On 2006-10-12, icegray@gmail.com <icegray@gmail.com> wrote: > - Any body can give me timing values or recommend any source? ( I can't > a right document on the Vesa web page) If you google for mode line generator you should find some pages that allow you to specify a resolution and refresh rate and get timing information in return. These pages are generally intended to create modelines for XFree86 so you will have to interpret the results yourself though. /AndreasArticle: 110198
On 12 Oct 2006 00:46:41 -0700, icegray@gmail.com wrote: >Hi everbody, >I wanna implement VGA core at 1024x768x75Hz (15" LCD Monitor) If it is always going to be LCD you can probably use 60Hz to reduce bandwidth.Article: 110199
icegray@gmail.com wrote: > Hi everbody, > I wanna implement VGA core at 1024x768x75Hz (15" LCD Monitor) on >... > - Any body can give me timing values or recommend any source? ( I can't > a right document on the Vesa web page) You can try: http://www.tkk.fi/Misc/Electronics/faq/vga2rgb/calc.html Sandro
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