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
"SG" <gupt@hotmail.com.NOSPAM> wrote in message news:m34qiw7az2.fsf@agni.ics.uci.edu... > > The key things here is that ST Micro is going after the embedded FPGA > market. This is not an established market and Xilinx & Altera will > have advantages only in terms of tool familiarity. > > About ST's architecture, if the Logic synthesis and P&R tools are open > source, it should be very easy to figure out what the architecture > is. Also, I don't think its a very big innovation, otherwise, ST > would go after the standalone FPGA market, instead of a non-existant > embedded FPGA market. > > My 2 cents. > Sumit hm Xilinx and IBM are (or did try to be?) on the "embedded FPGA market? http://www.xilinx.com/company/press/kits/xil_ibm/xil_ibm_faq.pdf so its at least not first attempt of "embedded FPGA" ,also leopard logic is offering something similar: low cost kinda-asic where part of the die is FPGA like anttiArticle: 76676
Hi Dan, > I need an information about some prices for some fpga. > > Acex1k speed -1, 208 pins. > Cyclone speed -6, 240pins. > > Thanks, Check http://www.arrow.com. Do realize that you haven't specified the actual size of the device, just the pin count, family and speed grade. No mention of gate/LE count. Best regards, BenArticle: 76677
"Marcio A. A. Fialho" wrote: > > I'm looking for a rad-tolerant, non-volatile (preferably programmable > at once) FPGA or CPLD, for a new project (a satellite instrument). I just found this in my in box... http://www.reed-electronics.com/ecnmag/article/CA486284?nid=2023&rid=1102926705 Aeroflex is a company that seems to take other company's products and building them for military and aerospace applications. They are making an industrial version of the Hynix ARM chip along with this FPGA which is apparently a hardened Quicklogic device. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76678
Kees van Reeuwijk wrote: > rickman <spamgoeshere4@yahoo.com> wrote: > > > >>No open source tool will be much better in those areas as has been >>discussed here many times. Unlike software tools, FPGA tools have to >>evolve much more quickly to adapt to the changes in FPGAs and FPGA >>markets. This results in lots of updates and lots of bugs. > > > Perhaps, but the point remains that quite a lot of people would be happy > with not-so-bleeding-edge FPGAs and a more accessible toolset than brand > X or A offer. So, if you already have not-so-bleeding-edge FPGAs, open > sourcing your toolset is one way of meeting that demand. And potentially > a very effective way: if you play it right, you can get a lot of help > from the open-source community. Ideally, yes. But open source means different things, to different people : you need to watch the fine print. This from TI: > NEW CODE COMPOSER ESSENTIALS OFFERS OPEN SOURCE IDE FOR TI'S ULTRA-LOW POWER MSP430 MICROCONTROLLERS > The CCEssentials IDE was designed specifically to offer users an intuitive interface > combined with the industry's highest C code density... sounds good so far... ..then the fine print kick in further down... > > CCEssentials IDE for MSP430 microcontrollers will be available for free and includes an > 8K byte C complier and unlimited assembler. > CCEssentials Pro IDE features unlimited C and assembly code space for $499. So, if they can offer a crippled C compiler, then clearly the source is not all that open ?! -jgArticle: 76679
Kees van Reeuwijk wrote: > > rickman <spamgoeshere4@yahoo.com> wrote: > > > > No open source tool will be much better in those areas as has been > > discussed here many times. Unlike software tools, FPGA tools have to > > evolve much more quickly to adapt to the changes in FPGAs and FPGA > > markets. This results in lots of updates and lots of bugs. > > Perhaps, but the point remains that quite a lot of people would be happy > with not-so-bleeding-edge FPGAs and a more accessible toolset than brand > X or A offer. That remains to be seen. From what I can tell, there is actually little demand for less capable chips with less capable but open-source tools. The issue is not the number of people who want this, the question is how many chips can they sell? The money is in volume and not many chip users can sacrifice the advantages of the most current technologies. It will make their products more expensive and not competitive. In reality the current tools work and actually work pretty well. So well that college students are designing chips in junior level classes. If it ain't broke, don't fix it! > So, if you already have not-so-bleeding-edge FPGAs, open > sourcing your toolset is one way of meeting that demand. And potentially > a very effective way: if you play it right, you can get a lot of help > from the open-source community. Neither of us really have any stats about the level of demand. I guess we'll find out when products roll out the door. :) > > (BTW > > Mentor, are you *ever* going to fix the bug where Modelsim crashes > > randomly for no special reason???) I dont' see open source tools fixing > > any of this. The current open source front end tools are still far > > inferior to vendor supplied tools. > > I had to laugh when I saw that combination of sentences. The whole open > source movement was started by people that got frustrated with software > vendors that ignored bug reports. And it does help. Yeah, I know. But that is a community of software people who are using software tools. I worked in construction in my youth and I saw carpenters make a lot of tools out of wood, and metal workers make tools from metal, but not much the other way around. This has been discussed many, many times here and I still don't see any open source tools that are worth using. > > Not before I retire.... but hey, "build it and they will come". > > Personally, I believe this is possible, but the problem is always that > the stuff on offer has to be right. A vendor with a weak FPGA and a > rotten toolset will get nowhere. A vendor with a good FPGA and a good > toolchain may well have a smash hit. But I think the key phrase in this > business plan is KEEP IT SIMPLE. What is possible? That I will retire? :) I agree that the whole package has to be right. But a good FPGA will always outweigh a good toolset because the FPGA is a recurring cost. If you have to spend a few more bucks on tools or using tools, that will have less impact on your bottom line. If your project is a lower volume run where the development cost is relevant, then it is not big enough to matter to the FPGA maker. And the discussion goes on, and on, and on... -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76680
The logic transitions in the routing and subsequent differential delays through
the LUT can make for many more transitions than a simple buffer implemented in a
LUT. Unless all the LUT inputs are precisely timed so that the edges change
together, you wind up with a walk through several of the LUT addresses in the
process of settling to the next clock. A paper presented at FPGA a few years
ago went as far as to say that as much as 30-40% of the power in a typical fpga
design is due to propagating glitches in the logic between flip-flops, and they
showed that by heavily pipelining the design, the power consumption improved
dramatically.
Symon wrote:
> Hi Paul,
> Comments/Questions below!
>
> "Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message
> news:686dnTKPrvwyGyvcRVn-pQ@rogers.com...
> > (2) LUT Configuration. A LUT configured as an AND gate does not burn
> > nearly
> > as much power as one configured as an XOR. This difference is due to the
> > number of internal nodes in the circuit that toggle states upon the toggle
> > of in input signal. On top of this, (blah, blah, XORs transition more)
>
> Could you explain that a little more? I thought that the LUT was just a 16x1
> RAM. Is the extra power consumed only when two inputs change? e.g. 00 => 11
> into the XOR would still have 0 as its output but it might transistion
> through the 1 output state? I understand that XOR gates are more likely to
> transition, but you seem to be saying there's some additional internal
> reason why they consume power.
>
> >
> > Paul Leventis
> > Altera Corp.
> >
> Cheers, Syms.
--
--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, 1759
Article: 76681John_H wrote: > > Noise shaping is the right way to go for a superb quality synthesizer, but > the correction phase error - the output from the noise shaper - needs to be > applied based on the synchronous edge position relative to the "ideal" edge > position - the input to the noise shaper. (Pseudo)Random doesn't do it. > > All this assumes, of course, that there's an analog PLL driven by the single > bit, noise-shaped NCO output. Without the PLL to filter out the high > frequency phase noise of a Sigma-Delta style NCO, the jitter is still around > 1 reference clock period peak-to-peak, maybe worse. That answers a question I have had for a long time. It occured to me a long time ago to use an analog PLL to smooth out the ragged edges in an NCO clock. But no one I spoke to about it could say if it would work. I always figured that the low pass filter would do the smoothing for me. I should never have doubted myself. ;) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76682
Antti Lukats wrote: > > "SG" <gupt@hotmail.com.NOSPAM> wrote in message > news:m34qiw7az2.fsf@agni.ics.uci.edu... > > > > The key things here is that ST Micro is going after the embedded FPGA > > market. This is not an established market and Xilinx & Altera will > > have advantages only in terms of tool familiarity. > > > > About ST's architecture, if the Logic synthesis and P&R tools are open > > source, it should be very easy to figure out what the architecture > > is. Also, I don't think its a very big innovation, otherwise, ST > > would go after the standalone FPGA market, instead of a non-existant > > embedded FPGA market. > > > > My 2 cents. > > Sumit > > hm Xilinx and IBM are (or did try to be?) on the "embedded FPGA market? > http://www.xilinx.com/company/press/kits/xil_ibm/xil_ibm_faq.pdf > > so its at least not first attempt of "embedded FPGA" ,also leopard logic is > offering something similar: low cost kinda-asic where part of the die is > FPGA like No they are not the first. The key here is that this is a niche market with a small total size, although growing. I doubt that an FPGA vendor can survive just supplying this one market. I expect they either see this as a way to bring in more ASIC customers or they will branch out to full FPGA chips. BTW, wasn't that Lucent's marketing strategy to acquire ASIC customers by getting them to prototype with primitive compatible Orca FPGAs? I believe they sold off the Orca line to Lattice... guess that didn't work out too well for them. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76683
SG wrote: > > The key things here is that ST Micro is going after the embedded FPGA > market. This is not an established market and Xilinx & Altera will > have advantages only in terms of tool familiarity. Yes, but it is a very small market still. They must have something else in mind with this as a foothold. > About ST's architecture, if the Logic synthesis and P&R tools are open > source, it should be very easy to figure out what the architecture > is. Also, I don't think its a very big innovation, otherwise, ST > would go after the standalone FPGA market, instead of a non-existant > embedded FPGA market. You may be right. Certainly you don't need the *best* FPGA to market it as a partially reprogrammable ASIC. But some FPGA vendors are saying that ASICs are loosing market share to FPGAs in a big way. Perhaps that opens up a middle ground or maybe it is the *worst* of both worlds, a long lead time ASIC that you have to configure at boot time... :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76684
Jim Granville wrote: > > This from TI: > > NEW CODE COMPOSER ESSENTIALS OFFERS OPEN SOURCE IDE FOR TI'S ULTRA-LOW POWER MSP430 MICROCONTROLLERS > > The CCEssentials IDE was designed specifically to offer users an intuitive interface > > combined with the industry's highest C code density... > > sounds good so far... > > ..then the fine print kick in further down... > > > > CCEssentials IDE for MSP430 microcontrollers will be available for free and includes an > > 8K byte C complier and unlimited assembler. > > CCEssentials Pro IDE features unlimited C and assembly code space for $499. > > So, if they can offer a crippled C compiler, then clearly the source is > not all that open ?! > -jg They said the IDE is open source, not the compiler. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76685
Thanks for the reply. I read the data sheet and it clarified all the queries I had. I am just quoting the same here. For synchornous clocks. 1. If both ports read simultaneously from the same memory cell: Both Data_out ports will have the same data. 2.If both ports write simultaneously into the same memory cell: The data stored in that cell becomes invalid (unless both ports write identical data). 3. If one port writes and the other port reads from the same memory cell: The write operation succeeds, and the data to be read out from the read port will be determined by the read output modeArticle: 76686
rickman wrote:
> I still don't see any open source tools that are worth using.
On the back end that may be true.
However, emacs vhdl-mode and "make"
are useful to me at the front.
-- Mike Treseler
Article: 76687
Hi Symon,
> > (2) LUT Configuration. A LUT configured as an AND gate does not burn
> > nearly
> > as much power as one configured as an XOR. This difference is due to
the
> > number of internal nodes in the circuit that toggle states upon the
toggle
> > of in input signal. On top of this, (blah, blah, XORs transition more)
>
> Could you explain that a little more? I thought that the LUT was just a
16x1
> RAM. Is the extra power consumed only when two inputs change? e.g. 00 =>
11
> into the XOR would still have 0 as its output but it might transistion
> through the 1 output state? I understand that XOR gates are more likely to
> transition, but you seem to be saying there's some additional internal
> reason why they consume power.
While logically a LUT is just 16x1 ROM, physically it is not built the same
way as a RAM.
A traditional RAM is built with a 2D-array of bits, where a row is selected
by decoding the address, and a pair of differential bit lines per cell is
precharged and then the cell pulls one side down which is amplified by a
sense-amplifier to speed things up (gross simplification). In that
structure, regardless of what you are reading, you burn the same power since
the reads are differential, and you burn power on each read, regardless of
the previously read value, since all that precharge, pull-down and sensing
happens every read.
A LUT however is traditionally built as a multiplexor tree. You have 16
SRAM cells feeding a tree of 2:1 muxes. The 4 inputs of the LUT each
control one level of the tree. There is a diagram below for a 2-LUT.
Let's take a 2-LUT implementing an XOR as an example (see diagram). We have
x = A?1:0 and y = A?0:1, and f = B?y:x. Let's say A switches from 0-->1
(and B = 0). Node x toggles from a 0 to 1. Node y toggles from a 1 to a 0.
And node f toggles from a 0 to a 1 (with x). So you have not only the
output of the LUT toggling, but also the internal stages. If you extend the
example to an N-LUT, you'll see that a toggle on input A results in 2^(N-1)
first stage nodes toggling, 2^(N-2) second stage, etc. or 2^N - 1 nodes
toggling *internal* to the LUT. If you look at an AND instead, you'll see
that only one first stage node toggles state with a change in A.
A B
+-+ | |
|0|-|\ x |
+++ | |__ |
+-+ | | |\
|1|-|/ | |
+++ | | |__ f
+-+ | | |
|1|-|\ y| |
+++ | |__|/
+-+ | |
|0|-|/
+++
So in conclusion, an XOR not only results in a higher output switching
probability (which should be modeled by your simulation vectors or assumed
toggle rate), but also results in higher *internal* switching activity.
Hence power of a LUT is not constant in LUT mask. In fact, it also changes
as a function of what the "static probabilities" of each input are, or % of
the time those inputs are 1 or 0, since assymetric LUT masks result in
assymetric internal states as a function of input values.
Regards,
Paul Leventis
Altera Corp.
Article: 76688Hi Ray et al: Good point on glitching. On a related note, this glitching also makes power analysis difficult. Even with good-quality simulation vectors for a design, the resulting gate-level simulation results will contain glitches. Are the glitches real? If so, then they should count towards power. But sufficiently short glitches will never propagate through the routing, or even through the gate. This is why we recommend that our users employ glitch filtering on simulation results. This can be done with the Quartus II 4.2 simulator or with 3rd party simulators (via the control file emitted by Quartus II). We find that very glitchy designs do not correlate well unless this glitch filtering is used. In addition, the resulting VCD files produced by 3rd party sims need to be further filtered by Quartus in order to improve accuracy further. For further information on power analysis, the Quartus II PowerPlay Power Analyzer and glitch filtering specifically, please see http://www.altera.com/literature/hb/qts/qts_qii53013.pdf. And yes, pipelining is an excellent way to reduce glitching and thus dynamic power. At some point, the pipeline registers and additional clock routing will add more power than the glitches removed, but for glitch-heavy designs (anything with XORs, such as adders, multipliers, and parity trees, and "randomizing" circuits such as encryption) pipeling will help a lot. Regards, Paul Leventis Altera Corp.Article: 76689
I would like to offer some clarification of points raised in this
whitepaper, first in summary and then in some detail. I will occasionally
refer to our web-based performance seminar
(http://seminar2.techonline.com/s/altera_dec0704) for further details.
* Constraints. The clock constraint methodology we employ matches
that outlined in the whitepaper. It is good to see that both
companies can agree on something!
* High-Effort Compiles. We run the ISE software in the mode that
yields the highest results across our benchmark set. We also run a
seed sweep ("multi-pass") for ISE at the end of the process.
* Retiming. ISE does not offer physical synthesis during place and
route. Quartus II does. We do not use XST (and hence XST
retiming) since we find this results in a far greater disadvantage
for Xilinx than when we use a common synthesis tool (Synplicity in
this case).
* Block Performance. Maximum block toggle rates are pretty worthless
if the fabric that stitches the blocks together can't keep up. Our
design set includes a variety of types of resources including RAMs
and DSPs, yet yields +39% performance advantage. Why? Our blocks
have comparable propagation delays which it turns out matters more,
and our logic & routing are substantially faster. Also, our Fmax
limits have increased in Quartus II 4.2 and will continue to
increase as we complete our detailed characterization process.
* Design entry. Good advice that applies to any modern FPGA
(Stratix II and Virtex-4).
* Speed Grades. We compare to what's available in the software. If
users know how much faster a -12 device will be (we do not), they
can derate our 39% average performance advantage accordingly.
Clock Constraints
^^^^^^^^^^^^^^^^^
We appear to agree on how to constrain clocks.
For synthesis, we employ the flow suggested by Synplify to optimize
multiple clock designs. This results in optimization of all clock domains.
Are there other ways to do it? Probably -- but since Synplicity Pro 7.7 is
a common-denominator in our comparisons, it is hard to see how changing this
would affect the 39% average performance advantage that we see for Stratix
II.
For ISE, as outlined in the web-seminar (slide #9) and other locations,
we constrain each clock independently and iterate to find the best such
(tight) constraints. As you suggest, we do not look at paths that cross
clock domains (difficult to do in an apples-to-apples way). We do not over
constrain ISE as we have found this degrades Xilinx performance. Slide #10
shows the results of the iterative constraint process for one design (with
two clocks); I think it highlights the rigour and correctness of this
process.
I should point out that for Quartus II, we don't need to jump through
hoops since applying a global 1 Ghz constraint on the clocks will result in
each clock being optimized as best as possible.
Synthesis/P&R Effort
^^^^^^^^^^^^^^^^^^^^
On the P&R front, we use the ISE settings that yield the best
performance results across our benchmark set. We also run a seed-sweep (or
"multi-pass" compile) using ISE at the end of our iterative process.
For synthesis, we have no reason to believe that enabling a high-effort
mode in Synplicity would change the conclusions of our comparison, since we
are using the same synthesis tool for both Stratix II and Virtex-4.
Register Retiming/Physical Synthesis
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quartus II can perform physical synthesis optimizations during
place-and-route. These algorithms have access to detailed placement and
timing information, enabling further optimization that synthesis just can't
know about. ISE does not provide any such optimizations. Note: We always
include Tco and Tsu constraints, so our re-timer will not violate I/O timing
to improve core speed.
We did not use Synplicity's retiming options during these comparisons,
and are in the process of evaluating how the comparison changes when we use
these options. While one might guess that these optimizations would reduce
Quartus' physical synthesis upside, register retiming is only one of the
many algorithms employed in Quartus physical synthesis and is responsible
for a very small part of +39% performance we see.
I'm told that ISE also offers some sort of retiming option during
synthesis with XST. We find that using XST yields much worse Xilinx results
(which make us look much better), so do not use XST, and hence do not use
that retiming option.
Block Performance
^^^^^^^^^^^^^^^^^
Our benchmarking results address overall performance across real
designs. These designs contain RAMs, DSP/MAC/Multipliers, adders, counters,
and other such building blocks in a large variety of sizes and varying
quantities. We do not claim that Stratix II is 39% faster on all building
blocks, but rather that when you put it all together Stratix II is 39%
faster.
Why is this? Fundamentally, the logic and routing of Stratix II is
significantly faster -- and you need logic & routing to stitch together the
blocks. Also, critical paths often start or end on a RAM/DSP, and are very
rarely just a RAM/DSP toggling in isolation. The timing microparameters of
the RAM/DSP are quite comparable between the two families. According to the
Virtex 4 data sheet, the DSP microparameters are faster in the -12 device
and we will certainly rerun the analysis when Xilinx releases software that
enables this fastest speed grade.
Our Fmax limit is not simply just 1/Tco. The block toggle rate limits
imposed by Quartus II are selected based on characterization to guarantee
operation of our devices in all environments, under all noise and switching
conditions. When you clock a block very quickly, you start getting
interesting effects that can affect operation. As we complete the
characterization of hard IP blocks, we will raise these limits. The Quartus
II 4.2 software introduces higher Fmax limits than stated in this table, and
further increases are likely in future software releases.
Speed Grades
^^^^^^^^^^^^
I believe we have addressed this in numerous forums. We use the
available speed grades in the software. We can't compare to something we
can't get our hands on. Users can derate our +39% average performance
result by the difference between our fastest and medium speed grade to get a
flavour for how things will compare if & when a fast Virtex-4 speed grade is
made available.
Regards,
Paul Leventis
Altera Corp.
Article: 76690
[In my attempt to text-format my first posting, I somehow double spaced
it... weird. If I fail this time, my descent into management is complete.]
I would like to offer some clarification of points raised in this
whitepaper, first in summary and then in some detail. I will occasionally
refer to our web-based performance seminar
http://seminar2.techonline.com/s/altera_dec0704) for further details.
* Constraints. The clock constraint methodology we employ matches
that outlined in the whitepaper. It is good to see that both
companies can agree on something!
* High-Effort Compiles. We run the ISE software in the mode that
yields the highest results across our benchmark set. We also run a
seed sweep ("multi-pass") for ISE at the end of the process.
* Retiming. ISE does not offer physical synthesis during place and
route. Quartus II does. We do not use XST and hence XST retiming)
since we find this results in a far greater disadvantage for Xilinx
than when we use a common synthesis tool (Synplicity in this case).
* Block Performance. Maximum block toggle rates are pretty worthless
if the fabric that stitches the blocks together can't keep up. Our
design set includes a variety of types of resources including RAMs
and DSPs, yet yields +39% performance advantage. Why? Our blocks
have comparable propagation delays which it turns out matters more,
and our logic & routing are substantially faster. Also, our Fmax
limits have increased in Quartus II 4.2 and will continue to increase
as we complete our detailed characterization process.
* Design entry. Good advice that applies to any modern FPGA (Stratix
II and Virtex-4).
* Speed Grades. We compare to what's available in the software. If
users know how much faster a -12 device will be (we do not), they
can derate our 39% average performance advantage accordingly.
Clock Constraints
^^^^^^^^^^^^^^^^^
We appear to agree on how to constrain clocks.
For synthesis, we employ the flow suggested by Synplify to optimize
multiple clock designs. This results in optimization of all clock domains.
Are there other ways to do it? Probably -- but since Synplicity Pro 7.7 is
a common-denominator in our comparisons, it is hard to see how changing this
would affect the 39% average performance advantage that we see for Stratix
II.
For ISE, as outlined in the web-seminar (slide #9) and other locations,
we constrain each clock independently and iterate to find the best such
(tight) constraints. As you suggest, we do not look at paths that cross
clock domains (difficult to do in an apples-to-apples way). We do not over
constrain ISE as we have found this degrades Xilinx performance. Slide #10
shows the results of the iterative constraint process for one design (with
two clocks); I think it highlights the rigour and correctness of this
process.
I should point out that for Quartus II, we don't need to jump through
hoops since applying a global 1 Ghz constraint on the clocks will result in
each clock being optimized as best as possible.
Synthesis/P&R Effort
^^^^^^^^^^^^^^^^^^^^
On the P&R front, we use the ISE settings that yield the best
performance results across our benchmark set. We also run a seed-sweep (or
"multi-pass" compile) using ISE at the end of our iterative process.
For synthesis, we have no reason to believe that enabling a high-effort
mode in Synplicity would change the conclusions of our comparison, since we
are using the same synthesis tool for both Stratix II and Virtex-4.
Register Retiming/Physical Synthesis
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quartus II can perform physical synthesis optimizations during
place-and-route. These algorithms have access to detailed placement and
timing information, enabling further optimization that synthesis just can't
know about. ISE does not provide any such optimizations. Note: We always
include Tco and Tsu constraints, so our re-timer will not violate I/O timing
to improve core speed.
We did not use Synplicity's retiming options during these comparisons,
and are in the process of evaluating how the comparison changes when we use
these options. While one might guess that these optimizations would reduce
Quartus' physical synthesis upside, register retiming is only one of the
many algorithms employed in Quartus physical synthesis and is responsible
for a very small part of +39% performance we see.
I'm told that ISE also offers some sort of retiming option during
synthesis with XST. We find that using XST yields much worse Xilinx results
(which make us look much better), so do not use XST, and hence do not use
that retiming option.
Block Performance
^^^^^^^^^^^^^^^^^
Our benchmarking results address overall performance across real
designs. These designs contain RAMs, DSP/MAC/Multipliers, adders, counters,
and other such building blocks in a large variety of sizes and varying
quantities. We do not claim that Stratix II is 39% faster on all building
blocks, but rather that when you put it all together Stratix II is 39%
faster.
Why is this? Fundamentally, the logic and routing of Stratix II is
significantly faster -- and you need logic & routing to stitch together the
blocks. Also, critical paths often start or end on a RAM/DSP, and are very
rarely just a RAM/DSP toggling in isolation. The timing microparameters of
the RAM/DSP are quite comparable between the two families. According to the
Virtex 4 data sheet, the DSP microparameters are faster in the -12 device
and we will certainly rerun the analysis when Xilinx releases software that
enables this fastest speed grade.
Our Fmax limit is not simply just 1/Tco. The block toggle rate limits
imposed by Quartus II are selected based on characterization to guarantee
operation of our devices in all environments, under all noise and switching
conditions. When you clock a block very quickly, you start getting
interesting effects that can affect operation. As we complete the
characterization of hard IP blocks, we will raise these limits. The Quartus
II 4.2 software introduces higher Fmax limits than stated in this table, and
further increases are likely in future software releases.
Speed Grades
^^^^^^^^^^^^
I believe we have addressed this in numerous forums. We use the
available speed grades in the software. We can't compare to something we
can't get our hands on. Users can derate our +39% average performance
result by the difference between our fastest and medium speed grade to get a
flavour for how things will compare if & when a fast Virtex-4 speed grade is
made available.
Regards,
Paul Leventis
Altera Corp.
Article: 76691Mike Treseler wrote: > > rickman wrote: > > > I still don't see any open source tools that are worth using. > > On the back end that may be true. > However, emacs vhdl-mode and "make" > are useful to me at the front. Are you talking about an editor??? I guess you can consider that a tool for FPGA design, but I think you know I am talking about synthesis, simulation and P&R. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76692
Hernán Sánchez wrote: > Hi Kubik. > > You can also find boards in http://www.xess.com/ Good prices. > > Cheers, Ooh, yummy! I was hoping to find a Spartan 200k board with more than 1MB RAM than the Digilent board has. -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply.Article: 76693
On Wed, 08 Dec 2004 18:04:31 -0500, rickman <spamgoeshere4@yahoo.com> wrote: >John_H wrote: >> >> Noise shaping is the right way to go for a superb quality synthesizer, but >> the correction phase error - the output from the noise shaper - needs to be >> applied based on the synchronous edge position relative to the "ideal" edge >> position - the input to the noise shaper. (Pseudo)Random doesn't do it. >> >> All this assumes, of course, that there's an analog PLL driven by the single >> bit, noise-shaped NCO output. Without the PLL to filter out the high >> frequency phase noise of a Sigma-Delta style NCO, the jitter is still around >> 1 reference clock period peak-to-peak, maybe worse. > >That answers a question I have had for a long time. It occured to me a >long time ago to use an analog PLL to smooth out the ragged edges in an >NCO clock. But no one I spoke to about it could say if it would work. I must be a 'no one'. Rick, we have discussed this before, e.g. in this thread: http://groups-beta.google.com/group/comp.arch.embedded/browse_frm/thread/7e0ec68b5c53e4 This is something I've done in real designs. I've also developed tools for estimating the output jitter of the NCO, taking the loop bandwidth (and order) of the PLL into account. It is possible to achieve very low levels of jitter at the PLL output, if the frequencies are carefully chosen such that the higher level spurious signals at the output of the NCO are well outside the PLL loop bandwidth. >I always figured that the low pass filter would do the smoothing for >me. Exactly. Although this does require the phase detector to be linear (otherwise the jitter signals will be demodulated). Common phase detector types (e.g. most digital phase detectors driving charge pumps) aren't particularly linear due to inexact balance between the pull-up and pull-down current sources. A figure of 10% is sometimes quoted. Regards, AllanArticle: 76694
"SG" <gupt@hotmail.com.NOSPAM> wrote in message news:m3wtvsk5mo.fsf@agni.ics.uci.edu... > > Looks like ST Micro has been trying to unsuccessfully develop a new > FPGA for many years with 100s of engineers. The good thing to come > out of this project is that they are open-sourcing the EDA tools they > developed for their FPGA. These tools (Synthesis, P&R etc) are > available at: > http://www.gospl.org > > Specifically, see: > http://www.gospl.org/fpl/static/aboutgospl.jsp > > This is good for researchers to play around with tools. And at first > glance, looks like a true open-source license (publish any changes to > source code that you make). However, ST benefits the most, since they > get free tool enhancement, while they sell their FPGA fabric as an > embedded FPGA fabric. > > Sumit It seems that the GOSPL project is not just focused on development of the tools, but also of the target architectures. From their website: "It provides a platform to innovate, improve and define next generation FPGA architectures and to design optimized silicon using state-of-the-art circuit designing techniques." The website implies that users are encouraged to also develop new FPGA architectures. There may be an opening here for alot of interesting FPGA-on-FPGA projects (synthesise your own FPGA architecture into a Xilinx, Altera, Lattice, ... device). Something like the old "Meta Programmable Gate Array" project http://ce.et.tudelft.nl/~reinoud/mpga/README.html Tony Burch BurchED, Making FPGA Prototyping Easy, http://www.BurchED.biz BurchED FPGA boards... * Largest number of accessible I/O pins. * Widest selection of plug-on modules. * Ideal for prototyping real-world designs. * Economical for engineering and advanced student projects.Article: 76695
Has anyone seen Atari 10-in-1 Joystick? www.walmart.com/catalog/product.gsp?product_id=2233972 It looks really cool! This is the first time that I have seen a commercially available Atari Resurrection implemented in hardware. Others are usually emulated in software. I wonder what kind of chip inside that joystick? Is it an FPGA? And how many gates would it take to make those games? HendraArticle: 76696
"Hendra" <u1000393@email.sjsu.edu> wrote in message news:1102573360.598385.97830@c13g2000cwb.googlegroups.com... > Has anyone seen Atari 10-in-1 Joystick? > www.walmart.com/catalog/product.gsp?product_id=2233972 > It looks really cool! This is the first time that I have seen a > commercially available Atari Resurrection implemented in hardware. > Others are usually emulated in software. > I wonder what kind of chip inside that joystick? Is it an FPGA? And how > many gates would it take to make those games? > > Hendra there is also commodore-in-joystick as those products are deep low priced they do have an ASIC inside not FPGA. made in china. at 18.77USD end user price it is not possible to have FPGA based product. not yet, the FPGA prices are not so down! BTW in Germany the same thing costs 34EURO !! I think the atari in joystick is made by that guy who had a webpage about the 2600 in FPGA, he never released any design files and went commercial. The commodore-in-joystick is designed by and girl named Jeri who also designed C1 reconfigurable computer, but then obviously decided there is more money in joystick business. anttiArticle: 76697
Hmm, that's very interesting. I wonder if the FPGA vendors have got their SLICEs back to front? I.e. the FFs should feed directly into the LUTs within the SLICEs, instead of the other way round that exists now. If it saved even 20% of the power, it'd be worth it. Instead of using all the FFs for pipelining, you use them to replicate signals within the SLICEs to prevent the glitchy power thing. Hmm, interesting indeed! Thanks Ray. Cheers, Syms. "Ray Andraka" <ray@andraka.com> wrote in message news:41B787FB.B377EF49@andraka.com... > The logic transitions in the routing and subsequent differential delays > through > the LUT can make for many more transitions than a simple buffer > implemented in a > LUT. Unless all the LUT inputs are precisely timed so that the edges > change > together, you wind up with a walk through several of the LUT addresses in > the > process of settling to the next clock. A paper presented at FPGA a few > years > ago went as far as to say that as much as 30-40% of the power in a typical > fpga > design is due to propagating glitches in the logic between flip-flops, and > they > showed that by heavily pipelining the design, the power consumption > improved > dramatically. >Article: 76698
Hello all, i have a hard time to route my Microblaze sucessfully at 100 MHz (virtex2 xc2v3000 -5). it seems the limiting point is linked to the OPB, because i have 2 masters (dopb + iopb) and many peripherals. here is my question : is it possible to clock Microblaze with a 100 MHz clock while having the OPB and its peripherals runnning with a 50 MHz clock ? has this configuration ever been tested by someone here ? thank you, Julien.Article: 76699
BurchED, Making FPGA Prototyping Easy, http://www.burched.biz In this newsletter: (1) Sale ending on Saturday. (2) Free Stuff. (3) User Login Area. (4) User website spotlight for December. (5) How are your latest projects going? (1) Sale ending on Saturday. Our sale, offering 10% to 25% off all items, is ending on this Saturday, 11 December 2004. If you can't purchase this week, please request a quotation online - quotations at the sale prices are valid for 30 days. (2) Free Stuff. We want to remind everyone about our free stuff, including mailed sets of printed product brochures. And also the absolute best guarantee in the industry - if you break your FPGA, we will fix it for free! For details please see http://www.burched.biz/FreeStuff.html (3) User Login Area. The Sydney-X1 user login area now also has the schematic for the B5-Audio-Out module. Over the coming week, we will be consolidating the user login areas into a single user login area, so that all users will have access to all of the applications, including the Pacman demo. For example, Super-Value-Pack users will be able to run the Pacman demo (with sound if you add a B5-Audio-Out to your system http://www.burched.biz/b5audioout.html ) (4) User website spotlight for December. Altium DXP / Nexar design software http://www.altium.com/dxpcentral/thirdpartyboards/search/ BurchED boards can be used with the Altium DXP / Nexar design software, by connecting Altium's Universal JTAG Interface. Have a look at DXP / Nexar - it is a serioulsy powerful design environment for FPGA design (just turn a blind-eye to those other develolpment boards while you are there:):) ). (5) How are your latest FPGA projects going? As always, we are interested to hear about your latest FPGA projects and applications. Please drop me a line, any time, at tony@burched.com.au
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