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
Marty Ryba wrote: > "John McCaskill" <junkmail@fastertechnology.com> wrote in message > news:1174756909.000771.39330@e1g2000hsg.googlegroups.com... >> The SLR16s have two outputs that can be used for serial to parallel >> shifters, the Q15 for cascading, and the selectable output. I finally >> found the article that describes how to use an SRL plus a FF to build >> a 6 bit per slice serial to parallel shifter. It is by Kris Chaplin, >> not Ken Chapman like I had been thinking. > > Slightly in another direction...is there a trick to setting up the cascades > on the SRL16s to maintain a consistent delay? We strung 8 in a row to get an > adjustable 1-bit delay line. It works, but there's a bunch of extra muxes, > etc. to get the delay consistent (3 clocks plus whatever tap I pull as > output). I'm actually the systems guy and not the VHDL coder (and > communication of requirements is always tricky when you're doing something > new), but I'm always interested in the mechanics to see if it can be done > better (smaller) while still meeting requirements. Especially since I'd > really like a 1024 tap delay but I ran out of space (I need tens of these, > plus other DSP goodies). Suggestions on other mechanisms to use are also > welcome. > > Dr. Marty Ryba > martin (dot) ryba (at) verizon (dot) net (man, I hate sp*m) Shift registers are clocked. Clocked elements don't have routing consistency issues, they have routing maximum issues. I'd suggest using some Xilinx routing for combinatorial delays in an *extremely* well controlled situation, inverting consecutive stages of a multi-tap delay to reduce pulse width distortion. But a 1024 element delay line?! It sounds like you need a nice, clocked delay. SRLs in series shouldn't have delay issues. Is it that you're taking the output from a very long clocked shift register? If so, just clock the muxed outputs to get all the SRLs to show up at the output pin at a predictable time. Often the conceptual problem with unclocked delay lines is figuring out how to get a consistent input path or a consistent output path; the trouble is, both are needed. What is your desired range and resolution? Acceptable jitter?Article: 117176
Unclocked delay lines are really not stable over temperature and voltage, although there are "servo' tricks to stabilize them (as done in the IDELAY and ODELAY Virtex I/O functions) For a very long clocked delay line, it might make sense to use a dual- ported BlockRAM. "Waste is often only in the eyes of the beholder..." Peter Alfke, Xilinx On Mar 25, 8:35 pm, John_H <newsgr...@johnhandwork.com> wrote: > Marty Ryba wrote: > > "John McCaskill" <junkm...@fastertechnology.com> wrote in message > >news:1174756909.000771.39330@e1g2000hsg.googlegroups.com... > >> The SLR16s have two outputs that can be used for serial to parallel > >> shifters, the Q15 for cascading, and the selectable output. I finally > >> found the article that describes how to use an SRL plus a FF to build > >> a 6 bit per slice serial to parallel shifter. It is by Kris Chaplin, > >> not Ken Chapman like I had been thinking. > > > Slightly in another direction...is there a trick to setting up the cascades > > on the SRL16s to maintain a consistent delay? We strung 8 in a row to get an > > adjustable 1-bit delay line. It works, but there's a bunch of extra muxes, > > etc. to get the delay consistent (3 clocks plus whatever tap I pull as > > output). I'm actually the systems guy and not the VHDL coder (and > > communication of requirements is always tricky when you're doing something > > new), but I'm always interested in the mechanics to see if it can be done > > better (smaller) while still meeting requirements. Especially since I'd > > really like a 1024 tap delay but I ran out of space (I need tens of these, > > plus other DSP goodies). Suggestions on other mechanisms to use are also > > welcome. > > > Dr. Marty Ryba > > martin (dot) ryba (at) verizon (dot) net (man, I hate sp*m) > > Shift registers are clocked. Clocked elements don't have routing > consistency issues, they have routing maximum issues. I'd suggest using > some Xilinx routing for combinatorial delays in an *extremely* well > controlled situation, inverting consecutive stages of a multi-tap delay > to reduce pulse width distortion. But a 1024 element delay line?! It > sounds like you need a nice, clocked delay. SRLs in series shouldn't > have delay issues. > > Is it that you're taking the output from a very long clocked shift > register? If so, just clock the muxed outputs to get all the SRLs to > show up at the output pin at a predictable time. > > Often the conceptual problem with unclocked delay lines is figuring out > how to get a consistent input path or a consistent output path; the > trouble is, both are needed. > > What is your desired range and resolution? Acceptable jitter?Article: 117177
> Plus, the vendors give free tools, so there is not the > price, or sponsored, incentive other open-source targets have. Yes... free tools... with large minimum quantity provisioning contract for anything besides economy/entry-level parts - Quartus Web/ISE Webpack only support Cyclone/Spartan FPGAs and small Stratix/Virtex devices. For small customers, the full Quartus/ISE usually costs a few grands. While it would certainly be nice to have open-source tools to support FPGA development (more options is almost always good for those days where ISE&all keep on crashing and burning), the rather small world-wide pool of FPGA people with both the programming knowledge and motivation to build and maintain this sort of project as volunteers is, unfortunately, almost certainly far too small. There are incentives to having independent tools such as avoiding XST/PAR/MAP bugs by replacing the whole tool chain... but the magnitude and complexity of such a project goes beyond what I believe can be expected from volunteer work. Whether or not the gains would offset the effort is a subjective matter but odds are mostly against it for the foreseeable future as you said. Who knows, maybe some FPGA vendor will open-source their tools some day and get the ball rolling.Article: 117178
Daniel S. wrote: >> Plus, the vendors give free tools, so there is not the >> price, or sponsored, incentive other open-source targets have. > > > Yes... free tools... with large minimum quantity provisioning contract > for anything besides economy/entry-level parts - Quartus Web/ISE Webpack > only support Cyclone/Spartan FPGAs and small Stratix/Virtex devices. For > small customers, the full Quartus/ISE usually costs a few grands. True, but I did notice Altera is has decided to make the Entire Cyclone III for free : PR: "Quartus II software version 7.0 provides industry-leading performance and productivity features to support the new Cyclone III family, including the EP3C120 device with 120,000 LEs, 4 Mbits of memory and 288 multipliers—the highest-device density available in any FPGA vendor’s free software package." Q: So how many NIOS cores could fit in this device ? -jgArticle: 117179
On 25 mar, 22:17, carlos.as...@gmail.com wrote: > > Thank you very much Luzerne for taking the time of explaining it step > by step really clearly and slowly. I really really appreciate it. > > What I was doing wrong was doing "export LD_PRELOAD=/path/Travail/usb- > driver/libusb-driver.so" in another terminal session since I thought > this was a kind of global setting. > > Again thanks a lot for everything you have done. > > Carlos You're welcome. My post was in fact more a contribution given back to Michael GERNOTH's work than to you :) but I'm happy to know it helps someone, and to discover this someone is so grateful :) But I think your greets are misplaced, as Michael GERNOTH deserves all of them. Luzerne GANHIRArticle: 117180
Dear Rob Thank You for your reply below. I am still a student learning more into FPGA so please excuse me style of questioning Quartus defaults to the most stringent hold requirement, 0ns. A hold violation is typically due to clock skew, gated clocks, or the sourse and destination register clocked by two different clocks. Your state machine probably transistions from one state to another by CLK_H; and certain states within your state machine are probably creating strobes that are clocking registers. My guess is that the source and destination register are being clocked by two different signals thus giving you this error. If you really don't need a 0ns hold requirment on this path, you can utilize the Multicycle Hold assignment to get you by this timing warning. Search on "hold relationship" and "Multicycle Hold timing assignment" in the help section of Quartus. These two section should help you. I got few things i need to ask. When you say " your state machine are probably creating strobes that are clocking registers", would that mean that once i get to into a state i am asserting signal, for example the input vector to the RAM gets asserted to ceratain binary value. My design uses only one clock, so how can "My guess is that the source and destination register are being clocked by two different signals thus giving you this error" i check i am not having this problem. Thank You very much for your help Regards Dharmesh JoshiArticle: 117181
<psihodelia@googlemail.com> wrote in message
news:1174871961.121540.72100@d57g2000hsg.googlegroups.com...
> Today I see no alternative to use Xilinx or Alteras Web Packs. Both
> are in a very sad state. As Linux or PowerPC user you cannot develop
> your FPGA design with this tools. On x86 or on Windows they are very
> buggy, slow, and unproductive as well.
Strange... last time I looked, Xilinx provided full support for Linux as a
host environment, even with the free WebPack software. True, it's only on
x86. But if there was a great demand for e.g. Mac software for FPGA
development, I'm sure FPGA vendors would at least think about providing it.
Personally I can't see FPGA vendors going completely open-source with their
tool development - they have too much "secret sauce" tied up in their
back-end algorithms. Still, it's not hard to imagine a more open approach
than what we have at the moment...
-Ben-
Article: 117182Dear Rob I also have some states that has not commands in them. The purpose of these were to cause few clock cycle delays. Could this be a problem. Regards Dharmesh JoshiArticle: 117183
psihodelia@googlemail.com wrote: > Many engineers today have Linux on Desktop as main-OS. Many engineers > today use Open Source products because of their quality, stability, > and configurability. > > Today I see no alternative to use Xilinx or Alteras Web Packs. Both > are in a very sad state. As Linux or PowerPC user you cannot develop > your FPGA design with this tools. On x86 or on Windows they are very > buggy, slow, and unproductive as well. > > So, any idea, how can we change this situation? Will we meet the time > of Open Source development tools for programmable logic devices? > This is a mix of two different things - running tools in an open source environment, and open-source tools. For a number of reasons, it is unlikely that we will see open source toolsets that cover the whole range of FPGA design. In particular, placing, routing and timing are so tied in with the hardware, and so specialised, that there are few people in the world who are capable of writing such software that are not already working for an FPGA company. Open source is not an appropriate development model for such software. Other parts of the toolset are a different matter. There are a number of open source HDLs, such as MyHDL or confluence, which are at a level above Verilog or VHDL. There are open source synthesisers, compilers, interpreters and simulators (such as Icarus and GHDL). There are also, of course, open source hardware designs (look at www.opencores.org for examples). When it comes to running closed source fpga software in open source environments, however, it's a different matter. Both X and A toolkits rely very heavily on open source software. As far as I can see (and I'm sure I'll be corrected if I've got it wrong), Quartus is build around a few closed source binaries, a gui, a large collection of open source glue such as cygwin, perl, and tcl/tk, and scripts written in these languages. For the binaries doing the hard work, it should make little difference which OS they run on. The infrastructure, written in perl and tcl (and perhaps other languages too), Linux or another *nix would be a far more natural OS than windows. About the only part that is actually tied to windows is the gui. What is needed for a more open-source friendly Quartus (and presumably the same applies to ISE), is two things. First, drop the proprietary closed-source kit used to run the win32 gui on linux (this is, I believe, the main reason why there is no free version of Q on Linux). Either re-write the gui using one of the many cross-platform toolkits available (such as Qt, GTK, or wxWidgets), or make the gui run with wine or winelib on Linux (that would avoid major re-writing). Secondly, drop the requirement for particular distributions, and replace it with a simple requirements for minimum versions of the infrastructure like perl and tcl. In these days of virtual machines, it should be a simple matter to set up automated testing on a dozen different distributions, and if your code works on Red Hat, Suse, Debian, and Ubuntu, then it will work on almost anything. Personally, I don't think there would be any benefit in the critical tools themselves being open source, and have no problem with the idea of a free version supporting the low-end families and paying for support for the high-end families. I don't do much fpga work at the moment - I do mostly embedded software development. As with most professionals in the field, I am happy to pay for quality tools - but I would prefer greater choice in how I run these tools.Article: 117184
On a sunny day (Mon, 26 Mar 2007 10:48:36 +0200) it happened David Brown <david@westcontrol.removethisbit.com> wrote in <4607844a$0$31544$8404b019@news.wineasy.se>: >What is needed for a more open-source friendly Quartus (and presumably >the same applies to ISE), is two things. First, drop the proprietary >closed-source kit used to run the win32 gui on linux (this is, I >believe, the main reason why there is no free version of Q on Linux). >Either re-write the gui using one of the many cross-platform toolkits >available (such as Qt, GTK, or wxWidgets), or make the gui run with wine >or winelib on Linux (that would avoid major re-writing). What are you talking about? Quatus II 5.1 GUI running in wine-0.9.9 in Linux right now! And the Linux version of webpack works too.Article: 117185
<psihodelia@googlemail.com> wrote in message news:1174871961.121540.72100@d57g2000hsg.googlegroups.com... > Many engineers today have Linux on Desktop as main-OS. Many engineers > today use Open Source products because of their quality, stability, > and configurability. > > Today I see no alternative to use Xilinx or Alteras Web Packs. Both > are in a very sad state. As Linux or PowerPC user you cannot develop > your FPGA design with this tools. On x86 or on Windows they are very > buggy, slow, and unproductive as well. > > So, any idea, how can we change this situation? Will we meet the time > of Open Source development tools for programmable logic devices? > I guess if more people donate more of their own time and effort to the FOSS effort for FPGAs, the situation might change. I'm curious as to how much effort you have contributed. ;-) Cheers, Syms.Article: 117186
On Mar 26, 3:48 am, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > psihode...@googlemail.com wrote: > > Many engineers today have Linux on Desktop as main-OS. Many engineers > > today use Open Source products because of their quality, stability, > > and configurability. > > Hmm, yes, but your many is still a tiny %. > Other are more pragmatic: as long as windows does not get in the > way, they tolerate it. I had a different impression. In the ASIC EDA world until a few years ago the Windows market share was about 0%. It is a little higher now but most of the tools still do not support windows. Of course there are a lot more FPGA designs done than ASIC designs and the number of licenses sold/given away for FPGA tools outnumbers the ASIC licenses by orders of magnitude, but a lot of the algorithms used in FPGA tools are developed with ASIC EDA money. As an example Magma Design Automation paid something like 150 developers having less than a hundred customers. (Very inaccurate and old numbers, but you get the point.) I soubt that the EDA user community is large enough to spin off a enough developers to get anything useful done. See for example how hard it is to get a working open source IP community together and that should be a lot easier. Other successfull Open Source projects are either a lot easier than EDA or have a marge larger user base to draw developers from. However what can be done, is the development of additional vendor independant tools that complement the major tools as well as replacing parts of the tool chain. One example on the fringe of EDA is Octave as a replacement for Matlab. Antoher one is a recent paper on a GI workshop that show how easy it is to extend the synthesizable subset of VHDL. They presented a VHDL to VHDL preprocessor that allowed you to use more constructs in your synthesizable code than Synopsys supports. Yet another example are timing diagram editors for documentation. Smaller projects like these are much more likely to yield high quality results than aiming for a complete toolchain. Also, they remain useful once they are not developed actively anymore. A backend tool would become useless as soon as development can not match the pace of the introduction of new architectures. Kolja Sulimma (I did EDA research for years)Article: 117187
Jan Panteltje wrote: > On a sunny day (Mon, 26 Mar 2007 10:48:36 +0200) it happened David Brown > <david@westcontrol.removethisbit.com> wrote in > <4607844a$0$31544$8404b019@news.wineasy.se>: > >> What is needed for a more open-source friendly Quartus (and presumably >> the same applies to ISE), is two things. First, drop the proprietary >> closed-source kit used to run the win32 gui on linux (this is, I >> believe, the main reason why there is no free version of Q on Linux). >> Either re-write the gui using one of the many cross-platform toolkits >> available (such as Qt, GTK, or wxWidgets), or make the gui run with wine >> or winelib on Linux (that would avoid major re-writing). > > What are you talking about? > Quatus II 5.1 GUI running in wine-0.9.9 in Linux right now! I am sure it works (I have not tried it - as I say, I haven't done much fpga work for a while), but the only "official" Altera way to run Quartus on Linux is the paid version, running on a few specific choices of distribution. Since your experience proves that Quartus runs fine under wine, what is needed is for Altera to say so, and to provide instructions and relevant install scripts for their web edition. > And the Linux version of webpack works too. > I have heard that the Xilinx Linux webpack uses the same commercial win32 wrapper, and that Xilinx in fact have to pay a royalty fee for each Linux webpack that is downloaded. I don't know whether this is fact or rumour - again, I hope someone will correct me if I'm wrong.Article: 117188
Hi I am about to start on a design that will need a number of smallish memories. i.e. 8 deep x 16 wide shift registers, small FIFOs etc. I am looking at the Spartan 3E and Cyclone II/III. The distributed memories in the Spartan 3E seem like the clincher. Why would I use a Cyclone and either waste a block RAM or quite a few Logic Elements when I can use distributed RAM in the S3E? The Cyclone III just makes it worse with their 9K memory blocks as against the 4K blocks in the CII. Any thoughts from the Altera folks on the newsgroup? Thanks MikeFArticle: 117189
Why don't you FPGA guys put delta sigma A/D's in future devices ? The good thing about a delta sigma A/D is the resolution/bandwidth tradeoff selected by the digital post-filter. And if you already have a >3GBit serdes, you maybe could do a continuous time delta sigma modulator with similar area, er even combine it with a serdes. National has a continuous time delta sigma A/D with 14 Bit at 40MSPS. Again, the good thing about it would be, that the tradeoff between resolution / bandwidth can easily be selected by post-filtering the bitstream. Resolutions from 6-16Bit's and 200MSPS - 1MSPS seem possible.Article: 117190
Sanjay,
I totally hear ya on different versions of the tools. We try to
stick with one version on a project start to finish... for some of our
older projects that have been around a few years, we've got people
running ISE 6-something around here for that very reason. As for
inference templates changes from version to version - I've only used
the vendor's synthesis tool on smaller hobby projects. For the larger
stuff here, Synplify seems to be pretty stable in that regard. I'm
just saying, when starting on a new project, clean slate... I don't
understand the drive to go one way or the other, because it really
depends upon the application.
On Mar 25, 4:21 am, "fpgabuilder" <fpgabuilder-gro...@yahoo.com>
wrote:
> Paul,
>
> For the same reasons as you spelled out we wanted to migrate from QII
> 6.0 to QII 6.1 unfortunately, the signed multiplier did not get
> inferred correctly in QII 6.1. I can still remember checking with the
> QII documentation to see if we incorrectly described the logic. But
> everything was according to the docs on Altera's website.
>
> The point is that it is this kind of unpredictable behavior between
> releases of the tools that give us cold feet when it comes to moving
> an existing project to a new release of the software.
>
> -sanjay
>
>
>
>
>
> > So if you don't care about Stratix III or Cyclone III devices, don't
> > want faster & better compilation results, don't need to interface with
> > a PCB, and aren't hitting any bugs that affect your design, there's no
> > reason for you to move to QII v7.0. However, the migration experience
> > is fairly painless, and you may find yourself liking some of the new
> > features you can by migrating.- Hide quoted text -
>
> - Show quoted text -
Article: 117191
MikeF wrote:
> I am about to start on a design that will need a number of smallish
> memories. i.e. 8 deep x 16 wide shift registers, small FIFOs etc. I am
> looking at the Spartan 3E and Cyclone II/III.
>
> The distributed memories in the Spartan 3E seem like the clincher. Why
> would I use a Cyclone and either waste a block RAM or quite a few
> Logic Elements when I can use distributed RAM in the S3E?
I would focus on writing and simulating an HDL design first.
The only way I can know for sure if my design fits
a particular device is to prototype the design and try it.
The Spartan 3e has more block RAM than distributed RAM.
If I don't use the block RAM I lose it.
LUTs can be used for anything.
> The Cyclone
> III just makes it worse with their 9K memory blocks as against the 4K
> blocks in the CII.
There is no way to know which is worse until
the design is finished.
-- Mike Treseler
Article: 117192> The point is that it is this kind of unpredictable behavior between > releases of the tools that give us cold feet when it comes to moving > an existing project to a new release of the software. Hi Sanjay, Yes, there are always risks moving between versions of software. We spend literally months between when we're finished programming a Quartus II version and when we actually release it. That time is spent running tons of tests -- every single old test we have lying around, plus a bunch of new ones we write to cover new cases. However, we cannot cover every possible form of input to the tool. Did you file a bug report on your issue? Bug reports turn into new tests that get run with each release, filling holes in our code coverage. In your case, was it a relatively small piece of code whose synthesis changed? Or was it a complex piece of code? I don't know if in this case it was a bug (somebody broke inferencing?) or just a subtle change in the myriad of choices/trade-offs the synthesis tool must make. One approach to reduce the amount of change between releases is to lock down the version of your synthesis tool -- be it Quartus or a 3rd party tool. But you can continue to update your Quartus back-end to get the latest & greatest P&R, timing, features, etc. I like to think the *stability* and overall quality of Quartus does not degrade from release to release -- in fact, as measured by number of IEs (internal errors) per compile as reported by users, it has been steadily improving. As suggested by yourself and another poster, sometimes the best approach is to lock down to one version of the software for your entire design cycle. We certainly have customers who do this. When the family you are designing to is reasonably mature (for example, has Final timing models), this may be the best solution. Or you could take the Microsoft user approach -- wait until the first Service Pack release when any of the little problems have been shaken out! Regards, Paul Leventis Altera Corp.Article: 117193
In news:1174904051.342594.320050@e65g2000hsc.googlegroups.com timestamped 26 Mar 2007 03:14:11 -0700, Kolja Sulimma <ksulimma@googlemail.com> posted: "[..] [..] Antoher one is a recent paper on a GI workshop that show how easy it is to extend the synthesizable subset of VHDL. They presented a VHDL to VHDL preprocessor that allowed you to use more constructs in your synthesizable code than Synopsys supports. [..] [..] Kolja Sulimma (I did EDA research for years)" Hello, Could you provide more details on this please? How does it compare to the behavioral VHDL synthesizer advertised in Petru Eles & Krzysztof Kuchcinski & Zebo Peng, "System Synthesis with VHDL", Kluwer Academic Publishers, 1998? Regards, Colin Paul GlosterArticle: 117194
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2275800f3158eabf/fced326c44af23e3?tvc=1&q=adc+analog+group%3Acomp.arch.fpga&hl=en#fced326c44af23e3 <ray@desinformation.de> wrote in message news:1174911826.663025.272910@n76g2000hsh.googlegroups.com... > Why don't you FPGA guys put delta sigma A/D's in future devices ? > > The good thing about a delta sigma A/D is the resolution/bandwidth > tradeoff selected by the digital post-filter. > And if you already have a >3GBit serdes, you maybe could do a > continuous time delta sigma modulator with similar area, er even > combine it with a serdes. > National has a continuous time delta sigma A/D with 14 Bit at 40MSPS. > > Again, the good thing about it would be, that the tradeoff between > resolution / bandwidth can easily be selected by post-filtering the > bitstream. > Resolutions from 6-16Bit's and 200MSPS - 1MSPS seem possible. >Article: 117195
Hi Mike, This of course depends on how many of these shift registers you have as compared to other logic in your chip, and whether you're going to be using all the block rams for another purpose. "Wasted" blocks are irrelevant when your design is using 70% of the logic and 30% of the RAMs in the chip. You can implement shift registers by using the alt_shift_taps megafunction in Quartus II. Assuming these are single-tap shift registers, you can fit 36 of them per Cyclone II/III M4K/M9K block RAM. Or you can choose to implement them in LEs if you'd prefer (by changing a flag in the megafunction), which may be the correct choice if your design has spare FFs lying around. Quartus will automatically use the LUTs for other functions in your design, so you are not "wasting" the rest of the LAB unless your design is FF limited. If you use Spartan-3E, it will take you 36 LCs. From a silicon area perspective, a M4K/M9K RAM takes a similar amount of area, so *archtiecturally* distributed RAM doesn't help in this case -- which doesn't mean much to you since you can't change the number of RAMs we choose to put in a chip. In case this factors into your decision, remember that with Cyclone III, you can buy a lot more logic / RAMs per $ than you can with an older 90-nm family. And you get lower power to boot. Also, if performance is a factor at all, Cyclone II/III of significantly higher performance. Distributed RAM isn't useless. There are certain applications where it makes sense. But these applications where many small, narrow independent memories are (a) needed and (b) dominate the logic/ram utilization are rare. And in exchange, each logic cell is costing more silicon area to build -- would you prefer 10% or 20% more logic cells in your chip or would you prefer distributed RAM? Different customers will say different things. Regards, Paul Leventis Altera Corp.Article: 117196
Paul Leventis wrote: excerpt: > In case this factors into your decision, remember that with Cyclone > III, you can buy a lot more logic / RAMs per $ than you can with an > older 90-nm family. I thought the Lattice ECP2M series - "an older 90-nm family" - beat out the Cyclone III family in "logic / RAMs per $" and had a better memory-to-logic ratio and had embedded SERDES and included distributed memory. Will the Cyclone-III price positioning outperform the Lattice offering?Article: 117197
Paul, I agree, (this is getting pretty unusual, isn't it? Fruit basket must have been spiked with something...) Locking down a release for a project is just smart engineering management. When I ran development groups, each project manager submitted the tools they were to use, and the tools were all placed under ECO control. AT various times I would have QA audit the project, to be sure we had control of our software. If something horrible happened, and the tool had to change, at least it was a structured process, and there was a paper trail to show what, where, and why. Additionally, an archive of everything would be made at the transition point, just in case. AustinArticle: 117198
On Mar 26, 5:09 am, "Paul" <pauljbenn...@gmail.com> wrote: > Sanjay, > > I totally hear ya on different versions of the tools. We try to > stick with one version on a project start to finish... for some of our > older projects that have been around a few years, we've got people > running ISE 6-something around here for that very reason. As for > inference templates changes from version to version - I've only used > the vendor's synthesis tool on smaller hobby projects. For the larger > stuff here, Synplify seems to be pretty stable in that regard. I'm > just saying, when starting on a new project, clean slate... I don't > understand the drive to go one way or the other, because it really > depends upon the application. > > On Mar 25, 4:21 am, "fpgabuilder" <fpgabuilder-gro...@yahoo.com> > wrote: > > > Paul, > > > For the same reasons as you spelled out we wanted to migrate from QII > > 6.0 to QII 6.1 unfortunately, the signed multiplier did not get > > inferred correctly in QII 6.1. I can still remember checking with the > > QII documentation to see if we incorrectly described the logic. But > > everything was according to the docs on Altera's website. > > > The point is that it is this kind of unpredictable behavior between > > releases of the tools that give us cold feet when it comes to moving > > an existing project to a new release of the software. > > > -sanjay > > > > So if you don't care about Stratix III or Cyclone III devices, don't > > > want faster & better compilation results, don't need to interface with > > > a PCB, and aren't hitting any bugs that affect your design, there's no > > > reason for you to move to QII v7.0. However, the migration experience > > > is fairly painless, and you may find yourself liking some of the new > > > features you can by migrating.- Hide quoted text - > > > - Show quoted text - Paul, I fall in the same camp as you do... i.e. look at the best architecture for a project. But lately with a processor inside the FPGA, we find that the decision to move to a different vendor at the start of any project gets a bit complicated as the software developers would also like a say in the decision. It would be interesting to see how others approach this problem. Maybe a different thread. Best, SanjayArticle: 117199
msg wrote: > Herbert Kleebauer wrote: > > 2. Was somebody able to run Viewlogic (DOS version) in a virtual > > PC emulation. The problem is, the virtual PC must provide > > the proper graphics mode, mouse type and support a physical > > dongle on the virtual parallel port. > Also, it would be an interesting experiment to try running > the software on a VMWare MSDOS VM (a no-cost experiment); please > report the results! Downloaded Microsoft Virtual PC 2007 and installed it on a 3.4 GHz P4 with Windows XP. Workview runs on a DOS 6.22 installation on the virtual PC (the parallel port dongle works) but needs an extra mouse on the serial port (the Windows USB mouse is not recognized by Workview). But it's not usable because it is extremely slow (slower than on a 486), especially the mouse movements.
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