Comparing ASAP7 and sky130hd with respect to ALU operations

[oharboe]

The mock-alu allows studying the speed and area of various typical ALU operations.

The mock-alu has two 64 bit inputs and one 64 bit output. The inputs and outputs are registered within the mock-alu. This is to have clear boundary conditions when studying the guts of the mock-alu.

The mock-alu implements a number of operations and variants of these operations to study the area and minimum clock period for these operations.

The operations fall into a couple of categories:

• add, subtract and compare: ADD, SUB, SETCC_EQ(equal), SETCC_NE (not equal), SETCC_LT (less than), SETT_LE (less than or equal), SETCC_ULT (unsigned less than), SETCC_ULE(unsigned less than or equal)
• barrel shifter: SHR(logical shift right), SRA(arithmetic shift right), SHL(shift left)
• bitwise logic: OR(bitwise or), AND(bitwise and), XOR(bitwise xor)
• multiplication: 64 bit multiply. There are various algorithms used, default Han Carlson. The implementation is PDK specific and comes from https://github.com/antonblanchard/vlsiffra/
• multiplexor: MUX1..8. This is not really an ALU operation. All that is happening here is that bits from the input as selected using a mux and put into the output. This allows studying the performance of the mux that sits before the output of an ALU, which is selecting between the various supported operations.

Next, the mock-alu allows implementing any combination of these operations. This allows implementing an ALU that only supports the shift operations, which can be labelled "SHR,SHL,SRA". This shift operation only mock-alu has a single shared barrelshifter. Similarly, a bitwise logic only mock-alu, can be labelled "OR,AND,XOR".

At this point, we can plot various mock-alu implementations for ASAP7 and sky130hd:

Here 8,16,32 and 64 wide ADD operations are plotted:

Various multiplication algorithms for 64 bit multiplication, 4 pipeline stages:

Plotting Han Carlson multiply algorithm with 8, 16, 32 and 64 bit bit width:

Thoughts?

[maliberty]

Its interesting that the various multiply algorithms have the same delay (excluding ripple).

I don't see a MULT for sky130

[maliberty]

The same as my comment "Its interesting that the various multiply algorithms have the same delay (excluding ripple)."

[QuantamHD]

If you're interested you might want to try a booth multiplier from https://github.com/antonblanchard/vlsiffra

[oharboe]

booth isn't mentioned in the docs on that link, nor can I see it in the command line parser.

I missed it when I first looked, but I am going to try out vlsi-adder.

[QuantamHD]

vlsiffra achieves this by using many well established techniques including Booth encoding, Dadda reduction and a choice of fast adders like Kogge-Stone.

[oharboe]

I see. As I understand booth is used within the algorithms that are listed in vlsi-multiplier algorithms and I have plotted those results above for these multiplication algorithms.

[oharboe]

Here are the vlsi-adder algorith, excluding ripple that was ca. 2000+ ps. It would have made the graph harder to read:

[oharboe]

With negative slack and TNS_END_PERCENT=100:

[maliberty]

A bit mixed. Some are improved and others are just bigger.

[oharboe]

Negative slack for multipliers, 64 bit, 4 pipeline stages.

This is a great example of how one should not be fooled by the scales on the axis....

There's essentially no difference between these implementations.

Leaving out MULT_RIPPLE as it is far, far off to the right and the bottom. As expected.

[maliberty]

Do all your runs end in negative slack at the end of the cts & the complete flow? Once we reach zero slack we stop optimizing.

[oharboe]

Ah, I see. No, they have positive slack.

[maliberty]

One thing worth noting is that asap7 doesn't have a full or half adder cells in the library (sky130 does).

[oharboe]

Can you explain a bit more what that means.

I saw full adders and half adders here...

https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/7db5d2c1fc7a2d99711ea3af19c9567dd45e371e/flow/platforms/asap7/yoSys/cells_adders_L.v#L28

[maliberty]

I take it back - it does seem to have them. The $fa is the full adder in yosys and this code maps it to the tech dependent cells (if you have a constant on a full adder then you can use a half adder instead).

[mithro]

BTW Have you seen Teo's spreadsheet @ https://docs.google.com/spreadsheets/d/1pTGzZo5XYU7iuUryxorfzJwNuE9rM3le5t44wmLohy4/edit#gid=126548956 ?

[oharboe]

Fascinating. So much to explore on simple addition :-)

[mithro]

FYI, Here is a link dump of the various stuff around adders that I have seen (in case you haven't seen these before);

Teo's work

• https://docs.google.com/presentation/d/1A8KDiTH1qyAzy9gKalUJgxLuPrOgqfOg7t7j_XdqeGE/edit#slide=id.p1
• https://www.youtube.com/watch?v=ZvssTXMTRmk
• https://github.com/tdene/synth_opt_adders
• https://github.com/tdene/adder_networks
• Skywater Adder Performance Spreadsheet
• SKY130 Maximum clock frequency (performance / speed) for DFF

Matt Venn testing of adders

• https://github.com/mattvenn/instrumented_adder
• https://github.com/mattvenn/wrapped_instrumented_adder
• https://www.youtube.com/watch?v=O38i5Y98m44
• https://docs.google.com/presentation/d/12Errw5M7lFYbBfi9yHc9-JNaikUcMz3qiLRNhj5hiUc/edit#slide=id.p
• https://www.youtube.com/watch?v=Gg6mxvhiEUs <-- Matt Venn mentions having gotten silicon back

Other stuff

It looks like you have already seen Anton's work @ https://github.com/antonblanchard/vlsiffra

Also checkout Alan Mishchenko's (the author of ABC) recent pre-prints for yet another direction in this space.

I'm sure I'm missing a bunch of stuff too!

[mithro]

BTW I would love to get a similar spreadsheet to Teo's for GF180MCU and ASAP7 too.

Sadly, Teo got distracted by the mathematical theory and then was stolen by NVIDIA before he could get to that.

[tspyrou]

@oharboe did you try using set_clock_uncertainty to force the slack to be negative and make the tool work harder.
As @maliberty mentioned optimization will stop once timing passes.

[oharboe]

I simply reduced the clock period to have negative slack and set TNS_END_PERCENT to 100. It changed the results a bit for the better, but I didnt see any dramatic change in relationships between algorithms.

[mithro]

@oharboe - Any chance you could do a write up of what you discovered?

[oharboe]

It is in this post... Any particular questions that come to mind that I could clarify?

[mithro]

There is a lot bunch of back and forth and I'm unclear what the final results are (and exactly how you produced them).

Various questions include;

• How do I reproduce your results and graphs?
• What settings did you end up using and why did you end up using those settings? (Particularly around making the tool work harder?)
• How do the various implementations compare? Do you understand why the compare this way?
• How do SKY130 and ASAP7 compare in the end here?
• Do the relative "positions" between the implementations hold across SKY130 and ASAP7?
• What was the most interesting / unexpected thing you discovered?

Writing it up as a nice coherent blog post would be pretty awesome but totally understand if you do not have the time to do so.

[oharboe]

There is a lot bunch of back and forth and I'm unclear what the final results are (and exactly how you produced them).

Various questions include;

• How do I reproduce your results and graphs?

Run this script: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/designs/src/mock-alu/plot-area-min-clock-period.py

Some tinkering required.

• What settings did you end up using and why did you end up using those settings? (Particularly around making the tool work harder?)

I didn't study how to make a best possible ALU, I was only interested the relationship between the ALU operations.

• How do the various implementations compare? Do you understand why the compare this way?

The various implementation of additions and multiplications?

It is a mystery why there is essentially no difference between multiplication implementation clock periods...

• How do SKY130 and ASAP7 compare in the end here?

The lessons learned on the relative size and speed of ALU operations appear to be much the same with SKY130 and ASAP7. Which is surprising. Ca. 15 years separate them...

• Do the relative "positions" between the implementations hold across SKY130 and ASAP7?

Pretty much.

• What was the most interesting / unexpected thing you discovered?

That relative size and speed of simple ALU operations are essentially unchanged across process nodes.

Also, it would appear that if an ALU operation is 200ps on x86 7nm, yielding 5GHz, then one could choose to divide clock period of ASAP7+OpenROAD by 4 for simple ALU operations when one models and decide to take the lessons learned and apply them to architectural exploration. Further choose to treat the speed of ASAP7+OpenROAD as not terribly important in terms of making architctural choices as the choices will be the same if everything is optimized.

By this I mean that to drive your architctural exploration, as a first order approximation, write the RTL in an idiomatic way, run them through ASAP7+OpenROAD and if your design is 4x the desired clock period, your design isn't completely off.

Nobody who have information on commercial tools and PDKs can challenge me here. :-) Not because I'm right, but because PDKs and commercial tools are under strict NDAs... This also explains why there are a lot of unsaid things in this thread...

Writing it up as a nice coherent blog post would be pretty awesome but totally understand if you do nt have the time to do so.

Agreed. At least I summarize a bit here. I'm happy to hear that there are some that are interested in this.

Perhaps you would like to write a blog-post using the script above?