SystemC HLS Optimizes Power
by Bryon Moyer
June 18, 2013 at 12:00 PM
Forte occupies what you might call a middle level in logic synthesis. We’ve talked about the positioning before, but a concise way of looking at it might be as follows:
- ANSI C/C++ provides an unstructured, untimed description of the design.
- SystemC provides a structured, untimed description of the design.
- RTL provides a structured, timed description of the design.
The middle one isn’t quite that simple: the interfaces are timed, either at the transaction or pin level. But the timing of what goes on inside is a product of synthesis and is subject to tradeoffs.
In an update conversation at DAC, Forte noted that one of the big improvements to their latest high-level synthesis (HLS) release, Cynthesizer 5, is the ability to include power in the tradeoffs in addition to performance and area. This actually required a complete redo of the underlying infrastructure, so much of the code is brand new.
One of the outcomes of that rework was to change how scheduling and allocation are done. For a given microarchitecture, scheduling refers to the process of assigning an event to a particular clock edge. For example, if two streams of logic converge and one needs eight clock cycles to complete and the other only three, then you could have the short-chain logic start early and then wait (“eager”) or start just-in-time to arrive with the long logic chain (“lazy”). Allocation assigns resources.
Their tools used to do scheduling first and then allocation. Now they happen at the same time, which means they can be co-optimized.
They can also do more design space exploration, with Monte Carlo capabilities. An example of this would be in the selection of a multiplier. In the past, they had one multiplier architecture; now they have several, with different performance/power/area tradeoffs. After manually dialing in the number of choices to get close, you can use Monte Carlo analysis to figure out which is best. (The manual part is just to keep the design space from being too enormous.) A half hour or so typically allows the tool to sort through thousands of different configurations to find the optimal one(s).
Optimizing for power brings one new consideration into play: state machine encoding. You generally want to minimize the number of bits switching (and even gate clocks to hit only the register that’s going to change). But one-hot, which is the extreme example, requires too many flip-flops. So they have a statistical algorithm that determines, short of one-hot, what the lowest-power encoding scheme would be.
Finally, they’ve put an algorithm viewer into the tool to allow the guys doing the implementation, who likely received it from the guy who wrote the algorithm, to get a better feel for what’s going on in the algorithm itself.
You can find more about their latest update in their announcement.