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
There are hard cores and soft cores. Hard cores are specialized silicon areas that implement a fnction very efficiently, but only the manufacturer ( Xilinx, Altera, etc ) can do that. Soft macros use the logic fabric ( CLBs etc ), and any user can instantiate them anywhere. Soft macros consume more silicon area per function, and are slower, but more flexible. (eg MicroBlaze and Nios) IMHO, both PowerPC and ARM are too complex to be implemented as soft macros. Xilinx picked PowerPC as the hard core in Virtex-II Pro, Altera picked ARM for Excalibur, and, surprisingly enough, no microprocessor at all for Stratix, their future flagship... Peter Alfke =================== Ron Huizen wrote: > Peter, > > Are you saying that putting an ARM core into a Virtex II is not doable, > or just not practical? Or are you only talking about the V2 Pro? > > --------- > Ron Huizen > BittWare > > Peter Alfke wrote: > > > > "Cyrille de Brébisson" wrote: > > > > > In our design we are using an ARM CPU. My question is: > > > Can we put an ARM in the virtex 2 pro? > > > Were can I find/buy an ARM cpu core source (or precompiled) file to program > > > in my FPGA? > > > > > > > Cyrille, > > the answer to both your questions is: No. > > The PowerPC in Virtex-II Pro is a "hard" implementation, packing the > > microprocessor with its caches and MMU into the smallest possible silicon > > area, <4 square millimeters. > > What you seem to be looking for is a "soft" implementation, using the > > programmable logic "fabric". > > That solution is impractical for something as complex as PowerPC or even ARM. > > It would take up an unreasonable portion of a large chip, and achieve mediocre > > performance at best. > > Xilinx offers a soft microprocessor, called MicroBlaze, especially tuned for > > efficient implementation in the Virtex architecture. It is not as fast and > > capable as PowerPC, but uses only ~900 slices. > > "Half the size and twice the speed of NIOS" is the Xilinx slogan. Please, no > > flames... > > > > Peter Alfke, Xilinx ApplicationsArticle: 41526
Performance LZW compression is a bear. The algorithm isn't friendly to single channels at top performance and under most circumstances requires an external SRAM (about 60 FPGA pins). It's achievable but not a project for the feint of heart. For items like text, you have to use a lossless algorithm so your choices are limited. For audio and video, lossless algorithms are a bit of overkill - there are many compression algorithms with almost no human-perceptible loss that would be much more effective than the lossless alternatives. I've seen a few people on the newsgroups talk about hardware MP3 implementations (audio) and know that JPEG cores are available for FPGAs, but lossless algorithms haven't found much play on the newsgroups or in the IP offerings I've seen. VP wrote: > Hi all, > > I am trying to find best general purpose data (text, audio, video and > other types) compression algorithm suitable for FPGA implementation. > On doing some research LZW compression and variations of LZ (LZ-77, > LZS etc) compression seems to be a good fit. Can someone point me to > other hardware based loss less data compression algorithms? Did anyone > implement data compressors in FPGAs? Any pointers/references would be > greatly appreciated. > > ThanksArticle: 41527
I didn't respond initially because of one underlying issue. Tristate multiplexers are a design element best left in the past. The efficiencies aren't high in current silicon with respect to performance and are only available (as far as I know) in one brand of devices. If it weren't for legacy issues, I'd almost expect the feature would've been dropped a generation or two ago. There are so many different approaches to multiplexing that - in my opinion - the tools should concentrate on generic logic implementation issues. Non-generic items that are used most frequently might benefit from optimization; tristate multiplexing is just used less and less these days. Aki Niimura wrote: > I still would like to have more responses from FPGA/ASIC designers. > With few more responses, I will wrap up this petition and present to Synplicity. > (However, developers in Synplicity are already following this petition.) > > The more I hear others' opinions, the more I feel that this is something > Verilog standard didn't do a good job. I can find both "for" and "against" > reasons in the standard.Article: 41528
In article <3CA88D75.1468E42C@mail.com>, johnhandwork@mail.com says... > Performance LZW compression is a bear. The algorithm isn't friendly to > single channels at top performance and under most circumstances requires > an external SRAM (about 60 FPGA pins). It's achievable but not a project > for the feint of heart. What about a CAM based LZ? Xilinx has datasheets describing how to make a CAM out of BlockRAMs. The CAM sizes seem reasonable for LZ (512 to 1024 entries give reasonable compression) in the moderate sized Virtex-2. Unless the chip has a lot more to do than LZ, the cost is going to be outrageous though. ---- KeithArticle: 41529
I've been playing with the Webpack floorplanner this weekend, and have created a few "planned" designs from modules within my verilog source. The question is how to use those nice layouts within the encompassing module: say for example I have module X that contains an instance of module Y. I've floorplanned Y, how do I get X to use the floorplanned design for Y when laying out X ? Any hints gratefully received. SimonArticle: 41530
Unfortunately, the floorplanner doesn't really export floorplans and it produces a flat (not hierarchical) floorplan. That makes it hard to export a pattern from one design into another. WHat you can do is embed the floorplanning information in the source by putting RLOCs on the instances. Of course, that means that you need to instantiate primitives in your source rather than working with an RTL description. You can also write a UCF file from the floorplanner. That produces LOC constraints for all the instances in the floorplan. You can then go in with a parser written in your favorite text processing language (Perl) to parse the floorplan file looking for matching primitive names, then add x,y offsets to the LOCs in the floorplan ucf file. This presents two challenges: one, the easier, is to find the LOCs and tranlate them to the new origin. The tougher part is matching up the symbol names to those in your second design, which will have additional hierarchy on top of it. If you can manage to keep the instance names from changing (ie, don't recompile your macro through the synhtesizer), you have a fighting chance of making tht work. Wish I had a better answer for you. Unfortunately, until Xilinx finally decides to do a hierarchical floorplanner and allow copying parts of floorplans across designs or across instances in the design, this is about the best you can do. We lean toward RLOCing the source, since it is less prone to headache later. A hint: most of the time you can get away with just RLOCing the flip-flops. The combinatorial logic, if it is restricted to one level, will get placed with the flip-flop. The second level of combinatorial logic is much more troublesome, as the autoplacement doesn't seem to like to put that second level near the first. Spaced Cowboy wrote: > I've been playing with the Webpack floorplanner this weekend, and have > created a few "planned" designs from modules within my verilog source. The > question is how to use those nice layouts within the encompassing module: > say for example I have module X that contains an instance of module Y. I've > floorplanned Y, how do I get X to use the floorplanned design for Y when > laying out X ? > > Any hints gratefully received. > > Simon -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 41531
Hi all, I am testing my designs using the Insight MicroBlaze development board with the Virtex II 1 million gate FPGA. When configuring the FPGA directly (ie. bypassing PROM) using the JTAG port, I first attempt to establish communication through reading the idcode. I received an error message from iMPACT that the device idcode doesn't match the idcode in the bsdl file. I'm guessing the problem is related to bypassing the ISP PROM, and I should perhaps associate the ISP PROM with either a dummy .mcs file or a .bsd file to bypass it. My question is: can I just use the generic bsdl file available on the Xilinx site as the dummy .bsd file? And if so, where should I save this file and how do I specify that it's targeted for the PROM? I'd appreciate any help on this matter, TerryArticle: 41532
"Alexander Miks" <monstrum@tiscali.se> skrev i meddelandet news:z7_o8.1055$m4.19213@news010.worldonline.se... > Where can I get the MAX7000S-series of chips in Sweden. Do you know of any > place shipping devices over here. I know a place here in Sweden, but they > only have the 7064S. > > Or try out the pin compatible Atmel ATF1500 series ... -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.Article: 41533
"Chris Wilkson" <cwilkson@mit.edu> skrev i meddelandet news:ee75da9.-1@WebX.sUN8CHnE... > I'm looking for an FPGA family that doesn't require a separate boot > PROM. (I can't afford the board space for the second chip.) > > Does anyone have any suggestions? > Please respond by email as I don't regularly read this forum. > > Thanks! > -Chris The AT94S Family (S for Secure) is available with the FPGA and Configurator in a single BGA package. The FPGA also contains the AVR micro, SRAM and AVR peripherals. -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.Article: 41534
VP wrote: > > Hi all, > > I am trying to find best general purpose data (text, audio, video and > other types) compression algorithm suitable for FPGA implementation. > On doing some research LZW compression and variations of LZ (LZ-77, > LZS etc) compression seems to be a good fit. Can someone point me to > other hardware based loss less data compression algorithms? Did anyone > implement data compressors in FPGAs? Any pointers/references would be > greatly appreciated. Not sure why you want a single algorithm for all these data types; I'd think multiple algorithms sharing common routines and having the smallest footprint would be the engineering choice. But http://dakx.com describes a lossless method suitable for low-complexity FPGAs. It's not great for text, maybe compression 80-90% of original without using a character remapping table, but competitive for audio or video.Article: 41535
"Keith R. Williams" wrote: > In article <a82m6n$lvj$1@web1.cup.hp.com>, cyrille_de-brebisson@hp.com > says... > > Hello, > > > > Actually, I have a related question. > > In our design we are using an ARM CPU. My question is: > > Can we put an ARM in the virtex 2 pro? > > Were can I find/buy an ARM cpu core source (or precompiled) file to program > > in my FPGA? > > In the interest of full disclosure... Xilinx doesn't do ARM, but Altera > has an ARM hard core in their Excalibur series. I don't know anything > more than what is on their web site though. > > Xilinx chose the right processor. ;-) > > Nah! It should have been one of the MIPS cores. - Speaking as someone for whom the bigger the MIPS world, the bigger my earnings.Article: 41536
William L Hunter Jr wrote: > Changchun > > Core version 0.0 is not valid means that you have not inserted a ILA core > using the ILA core inserter or by instaniating one in VHDL. > I've also had this error with a perfectly o.k. ILA and control core, I've even had it complaining about Core version 15.15 not being valid!. Basically it means that its not reading the JTAG stream correctly. My case is slightly different since I'm using the old-fashioned Parallel-III Centronics cable. This was based on advice I got that using MultiLinx with ChipScope was very flakey. So far I've found 3 sources of this, but there's at least one other I haven't got at yet. o If there's another heavy compute process running in the background e.g. a PAR for the next level of debug. o iMPACT JTAG programmer is running. This seems to sometimes cause problems even if I get iMPACT to disconnect before opening up the ChipScope analyser. o Doing a `print' through the parallel port with ChipScope analyser up & running but disconnected.Article: 41537
lucky_hero@yahoo.com (VP) writes: >I am trying to find best general purpose data (text, audio, video and >other types) compression algorithm suitable for FPGA implementation. >On doing some research LZW compression and variations of LZ (LZ-77, >LZS etc) compression seems to be a good fit. Can someone point me to >other hardware based loss less data compression algorithms? Did anyone >implement data compressors in FPGAs? Any pointers/references would be >greatly appreciated. IBM has a hardware compression chip with a patented algorithm. See: http://www.google.com/search?q=cache:NMXQVGVNNR0C:www.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525697500612122+aldc+ibm&hl=en The most appropriate algorithm depends on how you need to use it? It may be that compression can be slow and decompression fast, or the other way around. That and cost constraints should help determine the best algorithms. -- glenArticle: 41538
CAM based LZ would be spectacular. I haven't seen that the Xilinx CAM implementations allowed the width and breadth needed for a decent LZW implementation (20 bits tag, 12 bits data, 4k elements per channel). Oh, to have an embedded CAM with a worthwhile size! "Keith R. Williams" wrote: > In article <3CA88D75.1468E42C@mail.com>, johnhandwork@mail.com says... > > Performance LZW compression is a bear. The algorithm isn't friendly to > > single channels at top performance and under most circumstances requires > > an external SRAM (about 60 FPGA pins). It's achievable but not a project > > for the feint of heart. > > What about a CAM based LZ? Xilinx has datasheets describing how to > make a CAM out of BlockRAMs. The CAM sizes seem reasonable for LZ (512 > to 1024 entries give reasonable compression) in the moderate sized > Virtex-2. Unless the chip has a lot more to do than LZ, the cost is > going to be outrageous though. > > ---- > KeithArticle: 41539
Hello All, The TimingAnalyzer can be used to draw timing diagrams and check for timing problems in digital systems. The diagrams can be included in word processing documents, printed, or saved as image files. http://members.aol.com/d2fabrizio Regards, Dan Fabrizio d2fabrizio@aol.com -------------------------------------------------------------------------- ------------------- Beta Versrion 0.70 New Features and Improvements 1 A new help gui which shows all the topics in a tree on the left and the html help files on the right. The topics are stored in an xml file in the docs dir. The Aelfred XML parser has been added and is used to parse this file and coming soon, TDML. 2 Increment(+) and decrement (-) now works with multiple selected edge values. This makes it easy to increment or decrement all the values in counter output or burst output 3 You can now add multiple constraints per edge 4 You can optionally specify color, fonts, fontsize, and font styles for Delays, Constraints, Text objects, Delta Time Text objects, StateBars, and bus values. If they are not specified, the defaults values are used and they are not saved in the *.tim file. Any non-default values are saved in the *.tim file. See file format help for the object. 5 .taDefaults has been renamed to .ta_defaults This contains only InstallDirectory and Password values. .taOpenFileList has been renamed to .ta_open_files_list .taRecentFiles has been renamed to .ta_recent_files .td_defaults contains all the default values for timing diagrams. All of the above files are stored in a subdirectory off of the user home directory called .ta-0.XX when XX is the version number. In this case it is .ta-0.70. This should improve previously seen issues with upgrading. 6 Added more scripting API descriptions. 7 File reload menu. This is handy if you edit the *.tim with a text editor. 8 Zooming centers selected object in window. 9 changing global options settings in dialog now effect the timing diagram immediately. If you want use the settings for all timing diagrams, just hit save.Article: 41540
Ray Andraka wrote: > Unfortunately, the floorplanner doesn't really export floorplans and it > produces a flat (not hierarchical) floorplan. That makes it hard to > export a pattern from one design into another. WHat you can do is > embed the floorplanning information in the source by putting RLOCs > on the instances. Of course, that means that you need to instantiate > primitives in your source rather than working with an RTL description. Cheers Ray. Not the news I wanted :-) but at least it will stop me trying to figure out the impossible. I'd chosen a reasonably simple module because one look at the cpu module was enough to give me nightmares :-( I was hoping to break the problem down into manageable chunks. It's a shame the tools don't let you do that. I don't suppose you have a simple example of how to use an RLOC (in verilog), or a url showing how to do it. Actually, this *must* be a FAQ, I'll go search :-) > You can also write a UCF file from the floorplanner. That produces > LOC constraints for all the instances in the floorplan. You can then > go in with a parser written in your favorite text processing language > (Perl) <grin> is this a compulsory "favourite" then :-) Actually I'm pretty keen on Perl, but I prefer python. :-) > to parse the floorplan file looking for matching primitive names, then > add x,y offsets to the LOCs in the floorplan ucf file. This presents two > challenges: one, the easier, is to find the LOCs and tranlate them to the > new origin. The tougher part is matching up the symbol names to those > in your second design, which will have additional hierarchy on top of it. > If you can manage to keep the instance names from changing (ie, don't > recompile your macro through the synhtesizer), you have a fighting > chance of making tht work. Yeah, the chances of that are fairly slim though - I tend to work on a chunk at a time (divide & conquer). Unless the gui tool doesn't re-make already-synthesised parts (I don't know if it does or not) I'll almost certainly run afoul of that stipulation. Gaaah. I could do this *much* easier if I had 'make' and a shell... Perhaps I should invest some time in getting Webpack to work under Wine, and learning what actually happens when you click on the little circle thing. At least then I could be sure what was happening behind the scenes. Alternatively, XILINX - I WOULD LIKE WEBPACK UNDER LINUX. THANKYOU. Hell, it has to be worth a try! > Wish I had a better answer for you. Unfortunately, until Xilinx finally > decides to do a hierarchical floorplanner and allow copying parts of > floorplans across designs or across instances in the design, this is > about the best you can do. I take it I'm not the first person to hit this one then ? <grin> >We lean toward RLOCing the source, since it is less prone to headache > later. A hint: most of the time you can get away with just RLOCing the > flip-flops. The combinatorial logic, if it is restricted to one level, will get > placed with the flip-flop. The second level of combinatorial logic is much > more troublesome, as the autoplacement doesn't seem to like to put that > second level near the first. Thanks for the hint :-) So for larger designs (when you'll get bitten by >1 layer combinatorial) do you professional types get down and dirty and floorplan big modules directly ? I don't really see how you could keep track of the N entities, where N is a *large* number! Cheers, SimonArticle: 41541
> I don't suppose you have a simple example of how to use an RLOC > (in verilog), or a url showing how to do it. Actually, this *must* be a > FAQ, I'll go search :-) Ray will tell you to use VHDL which has generate. :-) Here's what I do in Verilog. I write Python programs that generate Verilog with RLOCs. For example, here's some Python to build an n-bit register floorplanned into a column of slices. (edited slightly) def fde(n): for s in range(3): print ''' module fde%d%s(clk, ce, d, q) /* synthesis syn_hier="hard" */; input clk, ce; input [%d:0] d; output [%d:0] q; ''' % (n,Sls[s],n-1,n-1) for i in range(n): print ' FDE r%d(.C(clk), .CE(ce), .D(d[%d]), .Q(q[%d]))' % (i,i,i) if s < 2: print ' /* synthesis RLOC="R%dC0.S%d" */;' % ((n-i-1+n%2)/2,s) else: print ' /* synthesis RLOC="X0Y%d" */;' % (i/2) print 'endmodule\n' Which emits .S0, .S1, and Virtex-2 versions of an n-bit register: (also edited slightly) module fde6v2(clk, ce, d, q) /* synthesis syn_hier="hard" */; input clk, ce; input [5:0] d; output [5:0] q; FDE r0(.C(clk), .CE(ce), .D(d[0]), .Q(q[0])) /* synthesis RLOC="X0Y0" */; FDE r1(.C(clk), .CE(ce), .D(d[1]), .Q(q[1])) /* synthesis RLOC="X0Y0" */; FDE r2(.C(clk), .CE(ce), .D(d[2]), .Q(q[2])) /* synthesis RLOC="X0Y1" */; FDE r3(.C(clk), .CE(ce), .D(d[3]), .Q(q[3])) /* synthesis RLOC="X0Y1" */; FDE r4(.C(clk), .CE(ce), .D(d[4]), .Q(q[4])) /* synthesis RLOC="X0Y2" */; FDE r5(.C(clk), .CE(ce), .D(d[5]), .Q(q[5])) /* synthesis RLOC="X0Y2" */ ; endmodule (No warranties, your mileage may vary, etc.) Jan Gray, Gray Research LLCArticle: 41542
Jan Gray wrote > Ray will tell you to use VHDL which has generate. :-) Generate is a good feature of VHDL, but the point is that VHDL is a more complete programming language and it allows you to compute the functions which otherwise need something like a Python script. On the main issue, a hierarchical floorplan system keyed to "hierarchical EDIF" is not too difficult, but productising such a piece of software is not so trivial. Keep pressing the X to do it.Article: 41543
Yep, That's what I'd say. We do extensive floorplanning in many of our designs. Stuff that is expected to be reused, either multiple times in a design or over more than one design gets floorplanned hierarchically in the code. One time stuff is generally done in the floorplanner since it is faster to do it there and the code is more readable. I've posted here several times in the past on putting RLOCs in VHDL using the generate, and I believe it is also on the comp.arch.fpga faq. I'm not holding my breath for a hierarchical floorplanner. We've (XEUC and XPERTs) have been asking for it for as long as I can remember, and it seems never to make it to the short list. Before that can be addressed, the new bugs in the 4.x floorplanner have to be addressed just to get us back to where we were with 3.3sp8 Tim wrote: > Jan Gray wrote > > > Ray will tell you to use VHDL which has generate. :-) > > Generate is a good feature of VHDL, but the point is that VHDL > is a more complete programming language and it allows you to > compute the functions which otherwise need something like a > Python script. > > On the main issue, a hierarchical floorplan system keyed to > "hierarchical EDIF" is not too difficult, but productising > such a piece of software is not so trivial. Keep pressing > the X to do it. -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 41544
Rick Filipkiewicz wrote: > "Keith R. Williams" wrote: > > > Xilinx chose the right processor. ;-) > > > > > > Nah! It should have been one of the MIPS cores. > I voted for an RCA1802 knock off ;-) -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 41545
Hi, Adrian: I know it's a pretty interesting topic on how to design a digital filter for a complex filter. Do you know any websites on this topic? Or else do you have any soft copy of your materials i can get from you? In fact you can opt trade for something from me. Thanks. -- Best Regards, ----------------------------------------------------------------- Xu Qijun Engineer OKI Techno Centre (S) Pte Ltd Tel: 770-7049 Fax: 779-1621 Email: qijun@okigrp.com.sg "Noddy" <g9731642@campus.ru.ac.za> wrote in message news:1017299896.720952@turtle.ru.ac.za... > Hi, > > This is more of a signal processing problem which I am implementing on FPGA > (Spartan II 200k). I have two 40 tap FIR filters for a complex signal. The > imaginary filter is a normal low pass filter which has been convolved with a > hilbert transform. The real filter is just a normal low pass filter. > > My question is this: I want to add a dc blocker into the real filter to > attempt to get my passbands in the imaginary and real filters the same. The > imaginary filter has one automatically due to the nature of the hilbert > transform, which makes the roll-off to DC very large. As the filters were > designed using a hamming window, my first attempt was to subtract a 40 unit > hamming window from the real coefficients such that the DC gain of the > coefficients was 0. This is effectively a DC block. However, due to the > nature of the infinite negative spike I have put in the pass band, the > roll-off to DC is not as large as the imaginary filter => pass bands do not > match. > > Does anyone have any other ideas on how to implement a DC block and still > have the same roll-off to DC as that in a hilbert transform. It seems this > won't be possible, since the "negative spike" in a hilbert transform is > finite, but the DC block is infinite. > > Thanks > Adrian > > >Article: 41546
Although I am not sure if it will help, but what I will suggest is to create two separate project files for X and Y. Synthesize Y by itself, likely without I/O pads being inserted. Then, create a blackbox for Y in X, and synthesize X without Y. XST's user manual talks about how to declare a blackbox for a module. Copy Y's netlist (If you are using XST, which I will assume, a .ngc file.) to X's project directory, and run NGDBUILD. NGDBUILD should automatically find Y's netlist, and will attach it to X. You can put X and Y in the same directory to save time. (That way, you won't have to copy Y's netlist each time you make modifications to Y.) Now that X and Y are separated, you should be able to floorplan X and Y, and even if you make modifications to Y, X's floorplan information won't change. (In theory.) Regarding the Floorplanner, I find UCF flow easier to deal with than the regular flow. Speaking of my wish list for ISE WebPACK, I will like to see FPGA Editor being added to the future versions of ISE WebPACK. I know most people won't use such a tool, and if that's the case, that's fine with me, but I will probably use it to see how LUTs are being routed in my design. Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.) Spaced Cowboy wrote: > > I've been playing with the Webpack floorplanner this weekend, and have > created a few "planned" designs from modules within my verilog source. The > question is how to use those nice layouts within the encompassing module: > say for example I have module X that contains an instance of module Y. I've > floorplanned Y, how do I get X to use the floorplanned design for Y when > laying out X ? > > Any hints gratefully received. > > SimonArticle: 41547
Microblase has an unofficial slogan too: "Half the size of Nios, and a quarter of the features". Xilinx certainly doesn't prefer this one, but it seems to be catching on with those who have used both processors. --------->Alan Peter Alfke <palfke@earthlink.net> wrote in message news:<3CA54B02.A18049F2@earthlink.net>... > "Cyrille de Brébisson" wrote: > > > In our design we are using an ARM CPU. My question is: > > Can we put an ARM in the virtex 2 pro? > > Were can I find/buy an ARM cpu core source (or precompiled) file to program > > in my FPGA? > > > > Cyrille, > the answer to both your questions is: No. > The PowerPC in Virtex-II Pro is a "hard" implementation, packing the > microprocessor with its caches and MMU into the smallest possible silicon > area, <4 square millimeters. > What you seem to be looking for is a "soft" implementation, using the > programmable logic "fabric". > That solution is impractical for something as complex as PowerPC or even ARM. > It would take up an unreasonable portion of a large chip, and achieve mediocre > performance at best. > Xilinx offers a soft microprocessor, called MicroBlaze, especially tuned for > efficient implementation in the Virtex architecture. It is not as fast and > capable as PowerPC, but uses only ~900 slices. > "Half the size and twice the speed of NIOS" is the Xilinx slogan. Please, no > flames... > > Peter Alfke, Xilinx ApplicationsArticle: 41548
Ray - What would set me apart is the "secret methodology sauce" of 10 years of inside Altera experience. Thus improvements are attained including: increased performance, increased device utilization, and decreased development schedule - all these results would be a few things that set my services apart from the average user. Thus, I was asking what kind of results people were seeing as the baseline. True, I could do my own pushbutton, but this would not provide me with apples to apples comparison because my process of obtaining these better results start at the beginning of the design process and can not truly be seperated out into pushbutton and non-pushbutton results as both benefit from earlier stages of my methodology. I hope you can understand this better with this explanation. Thanks for questioning my intent. Guy "Ray Andraka" <ray@andraka.com> wrote in message news:3C980C21.F136647D@andraka.com... > Why? Your clients can push the button just as well as you can. How does > that set you apart? > > Guy Schlacter wrote: > > > Now as an independent consultant, > > I need to sensitize myself to push-button expectations of users. > > > > Thanks, > > Guy Schlacter > > ex-Altera Field Specialist > > > > President > > Abosulte Consulting, Inc. > > > > -- > > Posted via Mailgate.ORG Server - http://www.Mailgate.ORG -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 41549
For those looking for improved CAM efficiencies for larger CAMs ask your Altera FAE person for the STratix Cam Emulation write-up. you will find "cheaper" costs of implementing larger CAMs rather than "burning" 16kbit block rams. CAM implementation is not just a function of array size, but also, data rate, latency acceptable, and frequency/periodicity of implementing a search/matching on data. Just a suggestion, Guy "John_H" <johnhandwork@mail.com> wrote in message news:3CA8D347.47F2ED0E@mail.com... > CAM based LZ would be spectacular. I haven't seen that the Xilinx CAM > implementations allowed the width and breadth needed for a decent LZW > implementation (20 bits tag, 12 bits data, 4k elements per channel). Oh, to > have an embedded CAM with a worthwhile size! > > > "Keith R. Williams" wrote: > > > In article <3CA88D75.1468E42C@mail.com>, johnhandwork@mail.com says... > > > Performance LZW compression is a bear. The algorithm isn't friendly to > > > single channels at top performance and under most circumstances requires > > > an external SRAM (about 60 FPGA pins). It's achievable but not a project > > > for the feint of heart. > > > > What about a CAM based LZ? Xilinx has datasheets describing how to > > make a CAM out of BlockRAMs. The CAM sizes seem reasonable for LZ (512 > > to 1024 entries give reasonable compression) in the moderate sized > > Virtex-2. Unless the chip has a lot more to do than LZ, the cost is > > going to be outrageous though. > > > > ---- > > Keith -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
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