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
Hi Scott, scotto wrote: > Hello, Does anybody out there actually know how to set up HWICAP in EDK? > Has > anyone ever got this to work? It works - I've even wrapped a Linux driver around it to make a self-reconfiguring MicroBlaze system. That was version 1.00.a - it's up to 1.00.b now but don't think much has changed. > If you've ever looked into this, you know there's very little > documentation on how to setup and use HWICAP. Would someone please post a > C file instantiating, initializing, and perhaps even reading/writing a > frame through ICAP? That would be extremely helpful. The trick with this core is to realise that it's buffered - you send your reconfig frames to a BRAM buffer (memory mapped on the OPB bus), then trigger the core to do the actual reconfig. Readback is the reverse - trigger the frame read, then get the data from the buffer. In /path/to/edk/sw/XilinxProcessorIPLib/hwicap_v1_00_a is the source of the level 0 drivers, and some example code as well. Also, in the core directory itself /path/to/edk/hw/XilinxProcessorIPLib/pcores/opb_hwicap_v1_00_b. /doc has a nice data sheet, and the /hdl subdirectory is the full source in nicely commented VHDL. Use the source, Luke! JohnArticle: 99076
Ray Andraka wrote: > Roger Bourne wrote: > > Hello, > > > > I never actually implemented FIR filters in FPGAs. But, if I am able to > > assume, I would say that FIR filters take up a SIGNIFICANT amount of > > space in an FPGA. > > E.g. 20th-order FIR filter, 16 bit, would require at the very least 320 > > FFs. Then there is all the combinationnal logic that will be employed > > to multiply the output of each 16bit-delay element by its respective > > tap (at least the taps can be hardcoded). And finally there is the 16 > > bit accumulator register at the output. > > I am sure that I am oversimplifying the realization of the FIR filter; > > there must be some major details that I am overlooking. And there is > > also optimization techniques that the FPGA device probably offers that > > I have not mentionned. > > > > Still, I feel that the above description does give a good description > > on the realization of FIR filters. Would that be accurate? I mean that > > FIR filters (or IIR filers) do take up a considerable chunck of FPGA > > space ? > > > > Thx in advance > > -Roger > > > > 20 Tap FIR filters don't occupy all that much room in FPGAs, especially > the modern parts which have quite a bit more logic resources than > earlier chips. First, most times we can run the clock at a multiple of > the sample rate, which allows us to time share the hardware either by > using the same multiplier for several tap coefficients, or by using > several clock cycles to accomplish the multiplies (distributed > arithmetic takes that a step further to postpone the shift-adds). A > brute force full parallel implementation will be the largest, but for 20 > taps, even that is not all that large, especially if you take advantage > of the embedded multipliers present in most of the current families. > Look at the multipliers and distributed arithmetic pages on my website > for a bit of a tutorial: http//:www.andraka.com Hi Ray and Peter, I am sorry for hijacking your thread Roger , but I think my question is relevant. I was thinking of using about 8 FIR (bandpass) filters in parallel to create a graphic equalizer. Now I know there are some phase problems with this method but it seems to me like a very logical way to go about this problem. I was wondering if you guys know of any better methods? I also was thinking of using 16 taps each. 320 FF's is not a lot actually. My XC3S200 (which is probably dirt cheap) has almost 4000 FF's. Enough for your filter network and much more. -IsaacArticle: 99077
>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. What's wrong with RS-232? You'll need some software on a PC to catch the data, but you'll need something like that anyway. 115Kbits/sec works fine on most PCs. You can kludge things if the cables are short. We use TTL levels rather than real RS-232 all the time. 2M bytes is 174 seconds. Extra credit if you add a checksum. If you want something faster, I'd try ethernet. You'll have to wrap things into a UDP packet. That's just putting a constant on the front end and a CRC on the back. If you want to get fancy you could include a sequence number and/or start/end flags. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 99078
Isaac Bosompem wrote: > Hi Ray and Peter, > > I am sorry for hijacking your thread Roger , but I think my question is > relevant. > > I was thinking of using about 8 FIR (bandpass) filters in parallel to > create a graphic equalizer. Now I know there are some phase problems > with this method but it seems to me like a very logical way to go about > this problem. I was wondering if you guys know of any better methods? > > I also was thinking of using 16 taps each. > > 320 FF's is not a lot actually. My XC3S200 (which is probably dirt > cheap) has almost 4000 FF's. Enough for your filter network and much > more. > > -Isaac Another great advantage to FPGA FIRs: most of the time the FIRs are symmetric which allows half the taps (half the multipliers) to implement the full FIR by adding t-δ to t+δ before multiplying by the common coefficient, the implementation is more elegant.Article: 99079
The cultural and class bigotry in this tread is appalling. If some of the OLD TIMERS in this group wish to be mentors, they first need to learn to be a bit more flexible, and not riddicule and insult others at the drop of a hat. This is not a native US born and educated form. It has many posters struggling to communicate in a non-native foriegn language based on language skills learned in chat rooms, IRC's, and a number of other forums. This list also includes posters like myself that are dyslexic, and find it extremely difficult to proof our own writings because misspellings, transpositions, missing/wrong characters and words are all "corrected" incorrectly by our brains as we reread our own work. Spelling and grammar flame wars like this thread are nothing short of bigotry.Article: 99080
Ivan wrote: > Hi Jean-Baptiste, > > you can download a presentation about my work in: > http://www.ii.uam.es/~igonzale/recursos/Self_Reconfigurable_Coprocessors.pdf Hi Ivan, could you please comment, on your slide 63, how you compute the values for the options PartialMask0,1,2 ? Thanks > > > 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: 99081
Can you explore "not working as intended"? The C code looks a little strange. You write on FSL channel 0 but read on FSL channel 1. Is that how you have connected the FSL accelerator to MicroBlaze? Göran BilskiArticle: 99082
burn.sir@gmail.com wrote: > Hello everyone > > > In the last couple of months, I have become very interested in CPU > design. Specially the ones that you can actually build and fire up > right on your kitchen table (i.e. the ones you can get into a decent > FPGA). I have read the classic texts on the subject (Enoch Hwangs book, > Jan Grays articles and scanned all code I could find on OpenCores, to > name a few). What I am still missing is some real-world design > examples. You know, things like L1 and L2 caches, TLB and all that > stuff. Things that differs PicoBlaze from ARM9 :) > > While ago, I saw a recommendation here in the group about few books > that taught state-of-the-art techniques. It contained references to > things like the newest ARM, Intel and AMD CPUs. Unfortunately, I cannot > find the post anymore. > > Any idea which book or books it was? > > (any general recommendation is also very welcome) > > > regards > - Burns > My bible on CPU design is "Computer Architecture, A Quantitative Approach". I never stop reading it. Göran BilskiArticle: 99083
fpga_toys@yahoo.com wrote:
> Jim Granville wrote:
>
> > > Stupid isn't the right word. Complacent with their margins is probably
> > > a better descripton. It's why they are only a $1.3B company instead of
> > > $10-40B dollar company like Sun Microsystems or Microsoft which are
> > > similar ages.
> >
> > But in quite different fields, so impossible to compare.
>
> Nothing could be farther from the truth.
So your first thought was "right", laced with sarcasm. Let's examine
this a bit. Xilinx produces about as many board level products as Apple
Computer did in 1984, including an outstanding entry into the system
level market with the ATX form factor ML310 motherboard. It's "only"
problem is it's cost of ownership coupled with marginal software
support to actually use it as a reconfigurable computer -- IE nearly a
complete lack of software support for the applications developer
community, focusing instead on embedded markets. Considering the Xilinx
ROI for those boards, and Apples ROI for it's board development, there
are questions to consider.
Consider that Apple produced 1 million systems with the MacIntosh 128,
512, and Plus design, with a price tag of over $2K each over three
years from introduction. That nearly doubled the companies sales in
just over a year, to just under $2B for 1985 and 1986 while redefining
the personal computer industry. Apple did this with one of the most
agressive cost of ownership designs in the computer industry at the
time, and aggressively creating a developer network that produced some
800 application programs that "sold" the MacIntosh for Apple.
http://apple.computerhistory.org/stories/storyReader$24
Everything on the ML310 board, except the VP30, can be found on a
commodity $50 retail ATX motherboard. The value that Xilinx failed to
capitalize on was taking reconfigurable computing mainstream by
agressively pricing this product, and creating a large reconfigurable
computing developer network to produce applications for the platform.
Having Xilinx FPGA literate developers, and lots of them, would easily
push Xilinx's chip sales and market share for an explosive growth.
Missing at Xilinx was system product level architects and a management
team visionary enough to build and capitalize on a systems level growth
market. To do so, would require Xilinx doing an about face on it's
software product licensing and embracing open software in a very
different way.
I believe that Xilinx leading the reconfigurable computing market could
easily take 5-10% of the global computing market share, just as Apple
has for the last two decades. Apple for fiscal 2005, generated revenue
of $13.93 billion, ten times Xilinx concentrating on chip sales.
With it's patent protection for the cash cows expiring, and a very
likely boom in off shore competition in the comodity FPGA market, I
believe that Xilinx needs to seriously pick up some vision about it's
future. While it has some major volume design in's for the US auto
industry, it has also created a huge introductory market for off shore
fabs to produce FPGA's for foriegn auto producers that will follow the
US lead.
So, while the Xilinx staff here are critical of offering "advise"
because they are so successful, that "success" does have other
measures. There is another view that Xilinx doesn't need advice, it
needs a completely different "vision" in it's management team to create
new and larger markets as FPGAs go comodity and off shore competitors
chip away at the cash cows. The $155M structured ASIC market is
peanuts compared to the possiblities as a systems level company.
Xilinx with an agressive cost of ownership strategy, could produce
ML310 like motherboards into the market at pretty substantial volumes,
along with fully packaged retail systems later. Deep seeding of the
educational and open source developers communities would result in a
rapid expansion of RC literate programmers, and applications, creating
an RC market that has a very likely chance of securing 5-10% of the
computer market inside a few years. RC established on Xilinx product,
would set a defacto binary standard (and resulting market share) that
would be hard to erase for a long time - the Intel effect. Or, one of
the A-Team companies, or new off shore entrants, can establish that
standard first.
Article: 99084> None of these would work? > * http://www.siliconimage.com/products/productfamily.aspx?id=3 they only list various PCI to SATA chips or SATA to PATA-(device) ... All those chips that could be used in the mass-market for desktop PCs :-( looks like there is no way other than using PCI-whatever? SI once had a SATA phy on their homepage but it was far from beeing available ... their local representation did not even know about it ... BTW: some time ago there was an announcement from TI to build a DSP with some Rapid-IO interface (C6455) ... It would be really cool to connect *that* to PCI-e and SATA directly ... I asked them - they did not even think about that opportunity :-( bye, MichaelArticle: 99085
Eric Smith wrote: > fpga_toys@yahoo.com writes: > > My family is from the show me state .... and I'd like to see the > > numbers behind the spin that testing is responsible for a 25-80% > > savings over a 50K FPGA order converting to easypath. > > I work for a fabless semiconductor company (though I'm not speaking for > them), and I can confirm that testing is expensive. Sometimes after a > product has already been in production for a while, we're able to come up > with a new set of test vectors that provides the same coverage in less > time, and this *significantly* reduces our costs. The flip side of that is tester time is so expensive that a die can only spend a short time on it, so intermitant failures don't get caught. I've been on the system end of the problem most of my life, doing operating systems, drivers, and diagnostics combined with hardware design. There was a reason we did burn-in with tests specifically targeting intermittants, and heavy qualification in an environmental chamber. As a systems guy, we provided burn-in support that directly augmented board level ATE testing. With a systems guy view, I can only wonder why die level and package level ATE is required. Design for test has to be one of the most critical requirements in the process - from die to system. It would seem that the the ATE function should probably be redundant on the wafer at fab, tightly integrated to the application die's IO pads -- AND critical internal logic not visible from pads. The wafer in this environment would have surface metalization on one edge for power and a network interface. The ATE function on the wafer would include power control for each die, an on wafer jtag chain, plus an on wafer gigabit network, each bused to a set of pads on one keyed edge of the wafer. The wafers would be racked into a test/burnin fixture that would provide power and network connectivity to the wafer (thousands of wafers) with an external test controller and logger. Each wafer's on silicon ATE system would then test each die (possibly hundreds in parallel) and leave a rest report for the external logger. This can be done by the fab, as they build up a multi-project wafer, or by the fabs customers for single customer wafers. Xilinx is such a large company, it would seem that designing a standard on wafer ATE function to free themselves of expensive die probing ATE would be a huge priority. IT would also allow for entire batchs of wafers to be tested with a full range of environmentals over a significant period of time to better issolate intermittants coupled to particular environmental ranges. Similarly, a subset of that on each die would facilitate package level testing both after packaging, and after customer board mounting. There is nothing special about the ATE's test interfaces, that can not be implemented on wafer with some good test for design strategies. > > Every second a part spends on a tester costs real money, and a big FPGA > probably spends a LOT of time on a tester. I'd be surprised if Xilinx > didn't employ a fair number of engineers whose entire job is optimizing > test vectors for high coverage in short test time. One of the biggest problems in any industry .... "we have always done it that way".Article: 99086
marvell has PATA<->SATA bridge that is available for low volume ordering - it easier to connect than PCI-SATA AnttiArticle: 99087
Ray Andraka wrote: > It appears to me that perhaps you are assuming the yeild is high, more > than 50% anyway. What happens to your assumption if the yield is more > like, say, 10-20%. It seems to me that the lower the yield, the more > attractive easypath becomes, especially if, as Austin indicated, most > yield fallout is only one defect. Actually the concept of managed defects becomes even stronger economically with lower yeilds, as the ratio to valuable recovered defect product to discards gets higher. Instead of discarding 80-90% of the product, you then add that yield to your revenue. Only untestable dies (those with power rail shorts, failed jtag interfaces, failed configuration paths, etc) are discarded. And even some of those can be recovered with additional design for failure strategies. > Maybe if you have enough spare cycles in your RC system, you can do that > in the background and hope you don't hit a defect in operational builds > before the defect map for the system is completed. Every system I've worked with has spare cycles ... doing testing/scrubbing in the idle loop is always a possibility. > The current tools make this even harder since the user has little > control over the what routing resources are used (there's directed > route, but it is tedious to use and is a largely manual effort), and > even less control over what routing resources can't be used. Granted, > this is a tools issue more than anything else, but the fact remains that > with the current state of the tools, I don't see this as feasible > right now. Yeah, I know, this supports your contention that the tools > should be open. Yep. > > Look at it from Xilinx's point of view though. What is in it for them? As I've posted elsewhere in this thread, increasing their revenue by 10-20x in a few years, and their long term market share substantially. Or, just staying in business. > More software that would need development and testing, more user > support, devices with defects out on the market that could wind up in > the hands of people thinking they have zero defect devices, or, as the disk drive market ... just assume every device has defects and design for it. > not to > mention their increased testing and administration cost to even > partially map the defects, or even determine to what degree the part > fails. Designing for defect detection and management changes the entire view of their process and ATE .... as I posted just a few minutes ago, why isn't this integrated on wafer, instead of continuing to do it with ATE as has been done for several decades? > I can see where the cost of doing it could exceed the potential > benefit. If it were profitable for them to do it, I'm sure they would > be pursuing it. In any event, it is a business decision on their part; > one they have every right to make. I can see where the cost of ATE could make the difference between being in business, or not. Designing for test, in a very different wafer oriented way I see as critical. > > Anyway, it still seems to me that the amount of extra work to manage > parts with defects would cost more than the cost savings in the part > prices not just for XIlinx, but also for the end user. For some applications sure .... for system level RC applications it's completely trival (and necessary) in the grand scheme of things. A very very minor amount of software. Consider that a new system could be brought up using triple redundancy and run live in that reduced capacity configuration for it's first few hundred/thousand hours, then back off to single redundancy for checking, and after the part is well qualified run only with background idle loop testing and scrubbing. Using the racked wafer strategy this is very viable to hold wafers in test for 72 hours or more before they are cut and packaged. Then the same strategy is extended to the package after it's brought up in a system. Designing for test, good test, coupled with defect management should only increase yields, lower costs, and benifit both the mfg and customer long term.Article: 99088
Hi,
Can anybody please tell me what is wrong with the following code? In
post-translate simulation there are a few unexpected short pulses.
Thanks,
Alastair
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity divcontrol is
port (
q : in std_logic_vector (7 downto 0);
pulse, shift, rstout,ledinc,ledread: out std_logic
);
end divcontrol;
architecture BEHAVIORAL of divcontrol is
begin
with q select
pulse <= '1' when x"00",
'1' when x"14",
'1' when x"28",
'1' when x"3C",
'0' when others;
with q select
rstout <= '1' when x"4D",
'1' when x"4E",
'1' when x"4F",
'0' when others;
with q select
shift <= '1' when x"03",
'1' when x"04",
'1' when x"17",
'1' when x"18",
'1' when x"2B",
'1' when x"2C",
'1' when x"3F",
'1' when x"40",
'0' when others;
with q select
ledinc <= '1' when x"49",
'1' when x"4A",
'1' when x"4B",
'1' when x"4C",
'0' when others;
with q select
ledread <= '1' when x"41",
'1' when x"42",
'1' when x"43",
'1' when x"44",
'0' when others;
end BEHAVIORAL;
Article: 99089Ray Andraka wrote: > A few points: > 1) The routing structure is many times larger than the LUT structures. > A defect in the FPGA is far more likely to show up in the routing > structure, and it may not be a hard failure. Very true. Having been responsible for both factory level burnin testing and field testing, intermittants are by far the toughest nut to crack as they seldom show up at the ATE station. > 2) The testing only identifies bad devices. It does not isolate or map > the exact fault, to do so would add considerably to the tester time for > a part that can't be sold at full price anyway. Good software based diagnostics generally attempt issolation to a component set. Which in the FPGA sense, would include searching for the specific resource set that fails. I generally see design for testing to use ATE for screening of dangerous hard failures (power faults) and completely dead devices. > 3) Defect map dependent PAR is necessarily unique to each device with a > defect, so you wind up not being able to use the same bitstream for each > copy of a product. Fine for onesy-twosy, but a nightmare for anything > that is going into production. The administration cost would far exceed > the savings even if you get the parts for free. Production in an RC world ... not problem. Production for an embedded design that is not defect aware a complete nightmare. Designing for test, desiging for defect management, I believe is not an option ... even for embedded. > 4) Each part would need to come with a defect map stored electronically > somewhere. Since the current parts have no non-volatile storage, that > means a separate electronic record has to be kept for each part. This > is expensive to administer for everyone involved from the manufacturer, > the distributors, and the end user. Again, the administration costs > would overshadow any savings for parts with a reasonable yield. Seems that it can be completely transparent with very very modest effort. The parts all have non-volatile storage for configuration. If the defect list is stored with the bitstream, then the installation process to that storage just needs to read the defect list out before erasing it, merge the defect list into the new bit stream, as the part is linked (place and routed) for that system. With a system level design based on design for test, and design for defect management, the costs are ALWAYS in favor of defect management as it increases yeilds at the mfg, and extends the life in the field by making the system tollarent of intermittants that escape ATE and life induced failures like migration effects. > 5) Timing closure has to be considered when re-spinning an FPGA > bitstream to avoid defects. In dense high performance designs, it may > be difficult to meet timing in a good part, much less one that has to > allow for any route to be moved to a less direct routing. In RC that is not a problem ... it's handled by design. For embedded designs, that is a different problem.Article: 99090
austin wrote: > That is a very strange thought. > > Both Peter and I are "retire-adverse." But is your employeer?Article: 99091
Peter Alfke wrote: > Are we continuing this thread until John (aka Mr Toy) has made a > complete fool of himself ? > His ranting is neither coherent nor entertaining or amusing anymore. > Peter Alfke Your turn.Article: 99092
That is complete nonsense. The OP comes from a country in which English is widely used claiming more good speakers than the country that gave it to them. Nobody is offended by the minor grammatical and typos error some of us make more often than others. People don't hear accents here. I also get confused between UK and US English, and often use google for spell checking. What this thread is about is very simple, "deliberate" unnecessary destruction of a language that can only confuse people who trully are having problems learning the language. If all they see is the terse cell phone encodings, that is hardly going to help them with their own English, they might even come to think that i,u,ur are acceptable. If I were to visit any non English speaking country and talk or write in jibberesh as if I should be understood when I could as easily speak or write better, I wouldn't expect a great reception. I am also quite used to having my own written English corrected by non native speakers. But we are just repeating ourselves. John JaksonArticle: 99093
JJ wrote: > That is complete nonsense. It's a VERY common form of TECH SPEAK used on every BBS, Chat, and IRC system. It doesn't matter where the poster was from, the nature and intent of the post would make any non-english poster firmly feel unwelcome. Maybe we need to be politically correct in this global formun, at take the top 52 languages and use one a week, or month, or year. JohnArticle: 99094
I am using the MXE 5.7 with free license, but sometimes it seems unable to handle too large designs. What are the main upgrades of MXE 6.0? TIAArticle: 99095
Hi, I'm looking for a V4FX devel. board, with both optical (e.g. SFP)MGTs and ddr2 memory (especially one with DIMM modules, if two ddr2 busses are available even better). Can someone suggest something, I haven't found one incorporating both features. Thanks, GeorgeArticle: 99096
fpga_toys@yahoo.com wrote: > The cultural and class bigotry in this tread is appalling. If some of > the OLD TIMERS in this group wish to be mentors, they first need to > learn to be a bit more flexible, and not riddicule and insult others at > the drop of a hat. Flexibility is in the eye of the beholder. It's insulting to see language - any language - needlessly butchered. As many others on this forum, I have sincere respect for those who don't know the nuances of English but try to communicate in this second (or third or forth) langauge. There is no need for mentors to put up with disrespect. Disrespect is what it is, plain and simple. Bcoz u cant tolr8 r annoyance with eye cancer doesn't mean we need to be tolerant of purposful butchering. If the post is MADE from a cell phone, I'd personally be willing to give some leeway. Given the strong support from so many who don't regularly contribute to threads of a more personal nature, the shorthand just isn't welcome. I've seen now 2 posts in mild support of gibberish, the majority against. > This is not a native US born and educated form. It has many posters > struggling to communicate in a non-native foriegn language based on > language skills learned in chat rooms, IRC's, and a number of other > forums. If we had a hint that the poster wasn't an english speaker, the tolerance would be greater; the posts read as if the individual was a native english speaker. If English is not their first language and chat is the second language, I applaud the original poster for being able to otherwise communicate rather well; I seriously doubt this is the case. > This list also includes posters like myself that are dyslexic, and find > it extremely difficult to proof our own writings because misspellings, > transpositions, missing/wrong characters and words are all "corrected" > incorrectly by our brains as we reread our own work. Misspellings and transpositions are easy to deal with especially for anyone who has dealt with a tremendous amount of chat and email over the development of the internet. The issue is a lack of desire to put any respect into the communication. > Spelling and grammar flame wars like this thread are nothing short of > bigotry. The issue isn't spelling (there were no unintentional spelling mistakes). The issue isn't grammar (the "cool" chat appreviations were in well constructed sentences). The issue is about communication and any level of respect for the communication medium - the English langauge. Dyslexics and foreign language posters still have respect for language. SO, are you trying to agitate again this late in the thread? Are you trying to be the devils' advocate to help out the mentors on this board or are you becoming an ass again? I do love to start my morning being pissed; if that's your goal, you succeed rather well.Article: 99097
hello, I have to do a program in VHDL which sends email via the SMTP protocol on the Pegasus board. I have to use the XILINX ISE and the EDK. I haven't worked with the EDK before, so any help would be welcomed. thank youArticle: 99098
I would like to implement a DDS on a Spartan device. Here are is my spec. Clocked at 200MHz. Max Output of 80MHz. 1uHz increments. Is this possible on a Spatan? Cheers JonArticle: 99099
Novice wrote:
> I am using the MXE 5.7 with free license, but sometimes it seems unable to
> handle
> too large designs. What are the main upgrades of MXE 6.0?
None of the free versions are usable with large designs.
Some low cost simulators are usable:
http://groups.google.com/groups/search?q=modelsim+altera+crippled+simili
Call Mentor to evaluate other versions.
-- Mike Treseler
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