Re: See Peter's High-Wire Act next Tuesday

"Peter Alfke" <alfke@sbcglobal.net> schrieb im Newsbeitrag
news:1107733371.888845.5080@l41g2000cwc.googlegroups.com...
> Jim, I like your idea, but it is not all that straightforward.
> I mentioned in the seminar that there is a loadable synchronous counter
> inside every DSP Slice, and it runs at 500 MHz, no ifs, no buts.
> Now, I will build a 5 GHz counter using the MGT. Is that allowed?
> DDS obviously runs at 500 MHz in the DSP slice, but I will run a
> virtual 8 GHz DDS either by using 16 accumulators, or by doing some

Hi Peter

I have already done that! its reletivly simple to use MGT as DDS with
virtual 10GHz clock for every user clock 40 accu samples are calculated

and I also am using MGT as 3GS/S logic analyzer with ChipScope

I wish it would make sense for me to publish all that work

Antti

Paul Leventis (at home) wrote:
(non-constructive criticism snipped)

>>Altera changed the LUT structure significantly, and I can believe that
>>this makes certain applications faster, if they can tolerate shared
>>inputs. But  Altera made no systems-oriented functional changes, added
>>no new functions or structures.

> Shared inputs do not need to be "tolerated" -- they are an available but not 
> necessary feature.  Ignoring all other aspects of the ALM, a 6-input LUT can 
> do a lot more than a 4-LUT, reducing the depth of the critical path and 
> hence increasing its speed.  The reason where straight 6-LUTs lose out to 
> 4-LUTs is in area (or silicon cost) -- that's where all the other 
> innovations in the ALM come in, including shared inputs.  For example, the 
> ALM can split into two (fully indepedent) 4-LUTs.  Or you can share some 
> inputs and/or LUT mask bits and create two larger functions.  With the ALM, 
> you get the speed when you need it and good area when you do not.

I do wonder if the optimal LUT size has changed over the years.

Is there work showing the optimal LUT size as a function of 
silicon resources needed to implement such LUTs?

-- glen

Antti Lukats wrote:
> "Peter Alfke" <alfke@sbcglobal.net> schrieb im Newsbeitrag
> news:1107733371.888845.5080@l41g2000cwc.googlegroups.com...
> 
>>Jim, I like your idea, but it is not all that straightforward.
>>I mentioned in the seminar that there is a loadable synchronous counter
>>inside every DSP Slice, and it runs at 500 MHz, no ifs, no buts.
>>Now, I will build a 5 GHz counter using the MGT. Is that allowed?
>>DDS obviously runs at 500 MHz in the DSP slice, but I will run a
>>virtual 8 GHz DDS either by using 16 accumulators, or by doing some
> 
> 
> Hi Peter
> 
> I have already done that! its reletivly simple to use MGT as DDS with
> virtual 10GHz clock for every user clock 40 accu samples are calculated
> 
> and I also am using MGT as 3GS/S logic analyzer with ChipScope
> 
> I wish it would make sense for me to publish all that work
> 
> Antti

  Hi Antti
  -- just an idea -- how about Xilinx keep you supplied with
FPGA Eval Boards, & Tools, on 'long loan', and you supply Xilinx with 
source codes... ?  Peter?
-jg

Glen,

" > I do wonder if the optimal LUT size has changed over the years.
> 
> Is there work showing the optimal LUT size as a function of silicon 
> resources needed to implement such LUTs?"

Good point.  Paul has referred to their studies of replacing a 4 LUT 
with a 6 LUT, and then re-running synthesis to see just how much 
improvement one sees.

Assuming one can get enough >4 term, <=6 term logic synthesised, one 
saves logic levels, and improves speed (even if a 6 LUT is slower than a 
4 LUT).

Then comes the other nagging questions:
- are inputs shared?
- how badly does that mess up the results?
- is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra 
logic to almost give you a 6 LUT?  How badly does that work?
- given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, 
how badly does that increase the delay?

I would claim a properly engineered 6 LUT would improve the overall 
performance.  A compromise would provide some improvement.  A poor 
implementation woukd make no difference.

Should all LUTs be 6 LUTs?  Or a mixture of both?  In what ratio?

Can you use them as SRL?  LUT RAM?

The synthesis tools all have to be retuned, and debugged to take 
advantage, so this is not without risk.

As for area, a 6 LUT is not all that big as technology shrinks, so some 
combinations of variable LUT size, alternate architectures, is in my 
opinion, inevitable.

As for speed, the smaller the technology, the less improvement in speed 
(ITRS roadmap, and anyone who says differently can be confidently 
ignored).  For speed, one now has to use triple oxide to get both speed 
and static power reduction (eg compare us to S2 at 25C and there is no 
difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the 
static power!).

The wonderful thing about standard CMOS, is just that.  No one has a 
remarkably different or unique process.  But one can use standard CMOS 
with all of the available tricks, and see a 1/2 to 1/3 reduction in 
static power, an improvement in speed, and an improvement in SEU 
resilience.  Like V4.

Also, there is room for improvement with the P&R tools, so software is 
always looking for that QOR improvement that gives us another speed 
grade advantage without any process change.  So far they do that every 
generation (they get credit for part of the improvement in speed with 
each generation, too, including the most recent ones).

Austin

austin wrote:
> Glen,
> 
> " > I do wonder if the optimal LUT size has changed over the years.
> 
>>
>> Is there work showing the optimal LUT size as a function of silicon 
>> resources needed to implement such LUTs?"
> 
> 
> Good point.  Paul has referred to their studies of replacing a 4 LUT 
> with a 6 LUT, and then re-running synthesis to see just how much 
> improvement one sees.
> 
> Assuming one can get enough >4 term, <=6 term logic synthesised, one 
> saves logic levels, and improves speed (even if a 6 LUT is slower than a 
> 4 LUT).
> 
> Then comes the other nagging questions:
> - are inputs shared?
> - how badly does that mess up the results?
> - is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra 
> logic to almost give you a 6 LUT?  How badly does that work?
> - given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, 
> how badly does that increase the delay?
> 
> I would claim a properly engineered 6 LUT would improve the overall 
> performance.  A compromise would provide some improvement.  A poor 
> implementation woukd make no difference.
> 
> Should all LUTs be 6 LUTs?  Or a mixture of both?  In what ratio?
> 
> Can you use them as SRL?  LUT RAM?
> 
> The synthesis tools all have to be retuned, and debugged to take 
> advantage, so this is not without risk.
> 
> As for area, a 6 LUT is not all that big as technology shrinks, so some 
> combinations of variable LUT size, alternate architectures, is in my 
> opinion, inevitable.
> 
> As for speed, the smaller the technology, the less improvement in speed 
> (ITRS roadmap, and anyone who says differently can be confidently 
> ignored).  For speed, one now has to use triple oxide to get both speed 
> and static power reduction (eg compare us to S2 at 25C and there is no 
> difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the 
> static power!).
> 
> The wonderful thing about standard CMOS, is just that.  No one has a 
> remarkably different or unique process.  But one can use standard CMOS 
> with all of the available tricks, and see a 1/2 to 1/3 reduction in 
> static power, an improvement in speed, and an improvement in SEU 
> resilience.  Like V4.

and Intel also varies the Vth over 21 steps, to have CLK, Vdd, Vth
to tune for speed/power trade offs.

http://www.eet.com/semi/news/showArticle.jhtml;jsessionid=TWZH2G3BR2K2OQSNDBCSKHSCJUMEKJVN?articleId=59301578

> 
> Also, there is room for improvement with the P&R tools, so software is 
> always looking for that QOR improvement that gives us another speed 
> grade advantage without any process change.  So far they do that every 
> generation (they get credit for part of the improvement in speed with 
> each generation, too, including the most recent ones).

  A significant difference at the LUT spec level that I DID see ( and I 
presume still applies ? ) is that Altera have differing LUT path delays
( all LUT legs are not created equal ), whilst Xilinx treated them
all equal.
  That means the Altera SW/HW can presumably choose the faster legs, 
where that matters, and so shave 100's of ps off the critical path ?
  => Faster P&R on otherwise similar silicon ?

-jg

Hi Glen,

> I do wonder if the optimal LUT size has changed over the years.
> Is there work showing the optimal LUT size as a function of silicon 
> resources needed to implement such LUTs?

Elias Ahmed & Jonathan Rose from the Unversity of Toronto published "The 
Effect of LUT and Cluster Size on Deep-Submicron FPGA Performance and 
Density".  See http://www.eecg.toronto.edu/~jayar/pubs/ahmed/fpga00.pdf. 
Elias's M.A.Sc. thesis was on clustering and optimal lut sizes.  This paper 
contains many references to previous work in the area and is probably a good 
starting point.  The paper's conclusion is that a LUT size between 4 and 6 
is and cluster sizes of between 3 and 10 LEs are best from a balanced 
area-delay perspective.  If you want higher speed, larger LUTs are better. 
One suggested area of future research is finding a way to reduce logic 
levels without the area cost of large LUTs -- and this is what we have done 
in Stratix II with the ALM.  Figure 12 is particularly interesting.

I think Guy Lemieux had some work in this area from his PhD -- not sure if 
its published anywhere yet.

At the FPGA 2005 conference in two weeks, the Stratix II logic architecture 
and some experimental results will be presented in a paper by David Lewis et 
al.

Regards,

Paul Leventis
Altera Corp.

Hi Austin,

No offence, but I don't think you're going to get far with an attack on the 
logic architecture.  I think you should read the paper at FPGA 2005 when you 
get a chance.  It is very informative.

> Then comes the other nagging questions:
> - are inputs shared?
> - how badly does that mess up the results?

Irrelevant to the speed question.  A simple 6-LUT in Stratix II does not 
share inputs.  LUT input sharing is an area optimization that we employ 
intelligently to avoid any penalty on performance while reducing number of 
ALMs required.

I should also point out that all our experiments during architecture 
experimentation are full synthesis + place & route runs on 100+ designs. 
One thing anyone who works on FPGA logic & routing architecture knows is 
that intuition isn't worth too much -- you can argue about "will shared 
inputs hurt things?" until you are blue in the face, but in the end only an 
experiment will tell the truth.

Funny side story:  One time during architecture experimentation someone put 
up a graph of some parameter (I forget what).  We sat their and rationalized 
why the answer would come out that way, and were all content.  Then we 
realized the graph was backwards and the trend was actually the other way 
around.  We could rationalize that answer too...

Bottom line:  Logic & routing architecture development must involve large 
amount of experimentation with real cad tools, otherwise you just don't 
arrive at the right answer.

> - given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, 
> how badly does that increase the delay?

Wrong again.  The ALM breaks into two independent 4-input LUTs with no delay 
penalty (ok, maybe a couple ps for a gate load or two) relative to a 
Stratix-like 4-LUT.

> I would claim a properly engineered 6 LUT would improve the overall 
> performance.  A compromise would provide some improvement.  A poor 
> implementation woukd make no difference.

Your first claim is correct.  And the ALM gives the speed of a 6-LUT, but 
the extra circuitry added to support fractured modes (2 4-LUTs, shared LUTs, 
etc.) is minimal and adds a tiny amount of delay to the guts of the LUT.

> Should all LUTs be 6 LUTs?  Or a mixture of both?  In what ratio?

Good questions.  The reality is that a real design mapped into 6-LUTs 
doesn't yield all 6-input functions -- it decomposes into a set of functions 
ranging from 1- to 6-inputs.  That is why making a pure 6-LUT architecture 
is not so great for area -- for those functions that don't use 6-inputs, you 
are wasting a lot of routing & logic area.  That is why we added the 
fracturing capabilities of the ALM.  This makes the ALM more expensive than 
a straight 6-LUT for implementing 6-input functions, but overall once the 
distribution of functions is taken into account, the ALM comes out on top.

One alternative could be to make an architecture with a hybrid set of LUT 
sizes.  But then you have to wonder whether you've picked the right mix of 
the two, you have the pain of hetrogeneous floorplanning in layout, you have 
potential issues with placement, more complicated CAD tools, etc.

> Can you use them as SRL?  LUT RAM?

No, the ALM can't do that.  We've argued about that many times in this 
newsgroup -- SRLs and LUT RAM add cost to the Logic Element.  M512 memories 
are more efficient for many circuits, while SRLs/LUT RAM are more efficient 
for others.  Are SRL/LUT RAM a bad idea?  No.  Are they a slam dunk?  No.

> The synthesis tools all have to be retuned, and debugged to take 
> advantage, so this is not without risk.

Yes, that was a risk.  We took that risk because we believed the ALM was a 
large enough win on the performance front to be worth the investment in 
synthesis and the risk to product success.  If the ALM had given us 5% 
performance, there's no way we would have gone for it.  But sometimes you 
need to take a big jump in architecture to get out of a local minimum in the 
space of architecture possibilities.

We worked with our 3rd party synthesis vendors well in advance of the 
release of Stratix II, and our own integrated synthesis was used during 
architecture development and thus was already ready to go.

> As for area, a 6 LUT is not all that big as technology shrinks, so some 
> combinations of variable LUT size, alternate architectures, is in my 
> opinion, inevitable.

Actually, the area of everything (LUTs, routing, RAMs, etc) shrinks as 
technology does, so I don't think the 4-LUT vs. 6-LUT question changes too 
much with process.  The only effect here is that perhaps as the amount of 
delay in routing vs. logic moves around with process, the precise answer as 
to what LUT and Cluster sizes are optimal will shift slightly, but this is 
probably a small effect.  A bigger effect could be evolution in the quality 
of synthesis and CAD tools, the changing nature of user designs, and 
advances in routing architecture.

> As for speed, the smaller the technology, the less improvement in speed 
> (ITRS roadmap, and anyone who says differently can be confidently 
> ignored).  For speed, one now has to use triple oxide to get both speed 
> and static power reduction (eg compare us to S2 at 25C and there is no 
> difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the 
> static power!).

I haven't seen any worst-case power numbers from you guys Austin.  Typical 
is a marketing number -- how do you define your "typical" silicon?  Let's 
hold off the power conclusions until both companies release final specs.

Besides, total power is what matters and you guys have curiously been shying 
away from dynamic power.  Your own web page claims equivalent dynamic power 
for a Virtex-4 LUT + routing vs. an Stratix II LUT + routing -- but our LUTs 
implement 25% more logic, and hence there are fewer of them in a given 
design.  Our pin capacitance is 1/2 that of V-4 -- you know what this does 
for I/O power?  Imagine 200 I/Os toggling at 200 Mhz with 6 pF instead of 12 
pF loads @ 2.5V (just as an example) -- if I've done my math right that's 
1.5W right there.  Now there's a strong chance I've done my math wrong (give 
me a break, its late) but you get the point!

> The wonderful thing about standard CMOS, is just that.  No one has a 
> remarkably different or unique process.  But one can use standard CMOS 
> with all of the available tricks, and see a 1/2 to 1/3 reduction in static 
> power, an improvement in speed, and an improvement in SEU resilience. 
> Like V4.

Yes, there are tricks to employ.  But they can cost speed.  They can cost 
area.  They can increase wafer costs.  All involve trade-offs.  In the end, 
we each picked the tricks we wanted to use.  Gate oxide is only one variable 
to play with, and not the most effective one on the speed vs. leakage 
trade-off front.

> Also, there is room for improvement with the P&R tools

True.  Both companies have teams beating on this software for lots of 
performance.  But if you're now saying that perhaps future software and a 
future speed grade will help you catch up on performance, I'm feeling pretty 
happy with our position.

Regards,

Paul Leventis
Altera Corp.

Hi Jim,

>  A significant difference at the LUT spec level that I DID see ( and I 
> presume still applies ? ) is that Altera have differing LUT path delays
> ( all LUT legs are not created equal ), whilst Xilinx treated them
> all equal.

Our LUTs have (significantly) different delays on different inputs.

>  That means the Altera SW/HW can presumably choose the faster legs, where 
> that matters, and so shave 100's of ps off the critical path ?
>  => Faster P&R on otherwise similar silicon ?

Yes, the software does take advantage of the variance in LUT delay to 
optimize the critical path.  This is why using 6-LUTs to implement 4-input 
functions is no worse for speed than using a 4-LUT -- the four fastest 
inputs of a 6-LUT are basically the same speed as the four inputs of a 
4-LUT.

Regards,

Paul Leventis
Altera Corp.

Oops, I missed one point (thanks Carolyn!).

> - is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra 
> logic to almost give you a 6 LUT?  How badly does that work?

Yes, the ALM is a universal 6-LUT.  It can do some functions of 7-inputs, 
and all functions of 6-inputs.

Please refer to http://www.altera.com/literature/hb/stx2/stx2_sii51002.pdf. 
Page 2-8 is the diagram you want to stare at closely.

Paul Leventis
Altera Corp.

Jim,

Yes, I see everyone taking advantage that LUT delays are variable, based 
on input.  The last stage selection is always faster, so there is one 
input that is always faster than the others.  Makes the software slower 
to P&R, but there is an advantage, and if taken, can provide that little 
extra ps of improvement.

As for Vt's, there is low Vt, and Hight Vt.  As for body biasing, it has 
practically no benefit (slope of body vs power is terrible, easier to 
just raise or lower Vdd).  So Intel has 100 adjustments, most of which 
are useless.

And, yes, we use low, and high Vt's, on core, mid-ox, and thick ox in 
the triple oxide process.  Only way to go.

Austin

Jim Granville wrote:
> austin wrote:
> 
>> Glen,
>>
>> " > I do wonder if the optimal LUT size has changed over the years.
>>
>>>
>>> Is there work showing the optimal LUT size as a function of silicon 
>>> resources needed to implement such LUTs?"
>>
>>
>>
>> Good point.  Paul has referred to their studies of replacing a 4 LUT 
>> with a 6 LUT, and then re-running synthesis to see just how much 
>> improvement one sees.
>>
>> Assuming one can get enough >4 term, <=6 term logic synthesised, one 
>> saves logic levels, and improves speed (even if a 6 LUT is slower than 
>> a 4 LUT).
>>
>> Then comes the other nagging questions:
>> - are inputs shared?
>> - how badly does that mess up the results?
>> - is it a universal 6 LUT, or 2 5 LUTs with some sharing and some 
>> extra logic to almost give you a 6 LUT?  How badly does that work?
>> - given the smallest LUT is not a 4 LUT, for smaller than 5 logic 
>> terms, how badly does that increase the delay?
>>
>> I would claim a properly engineered 6 LUT would improve the overall 
>> performance.  A compromise would provide some improvement.  A poor 
>> implementation woukd make no difference.
>>
>> Should all LUTs be 6 LUTs?  Or a mixture of both?  In what ratio?
>>
>> Can you use them as SRL?  LUT RAM?
>>
>> The synthesis tools all have to be retuned, and debugged to take 
>> advantage, so this is not without risk.
>>
>> As for area, a 6 LUT is not all that big as technology shrinks, so 
>> some combinations of variable LUT size, alternate architectures, is in 
>> my opinion, inevitable.
>>
>> As for speed, the smaller the technology, the less improvement in 
>> speed (ITRS roadmap, and anyone who says differently can be 
>> confidently ignored).  For speed, one now has to use triple oxide to 
>> get both speed and static power reduction (eg compare us to S2 at 25C 
>> and there is no difference for leakage, but compare us at 85C, and we 
>> are 1/2 to 1/3 the static power!).
>>
>> The wonderful thing about standard CMOS, is just that.  No one has a 
>> remarkably different or unique process.  But one can use standard CMOS 
>> with all of the available tricks, and see a 1/2 to 1/3 reduction in 
>> static power, an improvement in speed, and an improvement in SEU 
>> resilience.  Like V4.
> 
> 
> and Intel also varies the Vth over 21 steps, to have CLK, Vdd, Vth
> to tune for speed/power trade offs.
> 
> http://www.eet.com/semi/news/showArticle.jhtml;jsessionid=TWZH2G3BR2K2OQSNDBCSKHSCJUMEKJVN?articleId=59301578 
> 
> 
>>
>> Also, there is room for improvement with the P&R tools, so software is 
>> always looking for that QOR improvement that gives us another speed 
>> grade advantage without any process change.  So far they do that every 
>> generation (they get credit for part of the improvement in speed with 
>> each generation, too, including the most recent ones).
> 
> 
>  A significant difference at the LUT spec level that I DID see ( and I 
> presume still applies ? ) is that Altera have differing LUT path delays
> ( all LUT legs are not created equal ), whilst Xilinx treated them
> all equal.
>  That means the Altera SW/HW can presumably choose the faster legs, 
> where that matters, and so shave 100's of ps off the critical path ?
>  => Faster P&R on otherwise similar silicon ?
> 
> -jg
>