次に製品ラインアップについてだが、まずCortex-M3を利用しなかった理由について「Synergy S3を例にとって見る。これは省電力向けの製品だが、社内では評価用にCortex-M3ベースのSoCも作ってみた。ところがシステム全体での消費電力をM3とM4で比較すると、Cortex-M4の方が優れていた。Synergy S3の場合は長時間待機状態にあり、なにかイベントがあったらすぐに復帰して処理を行い、また待機に入る。この処理の性能そのものも、追加命令がある分Cortex-M4の方が高く、かつ場合によっては浮動小数点演算性能が必要になるため、Cortex-M4の方が良いという判断になった。これは多くの顧客にヒアリングした結果だ。また40MHzあたりでの動作を考えた場合、Cortex-M4は良いバランスになっている」というものだった。一方、ハイエンドにCortex-M7を選ばなかった理由としては「2つ理由がある。1つはSynergyの開発時期にCortex-M7は6カ月ほど間に合わなかった。2つ目に、240MHzのCortex-M4は現時点では十分高速だし、また利用しているフラッシュメモリは120MHz駆動になっているため、丁度1:2の関係になって複雑なキャッシュやアクセラレータが要らなかったことが挙げられる。実際簡単なバッファとフラッシュのシンプルなインターリーブ構成だけで済んだ。240MHz駆動でCortex-M4とM7での性能をシミュレーションで比較してみたが、それほど性能差はなかった。加えて言えば、消費電力もずっと増えている。なので、S7のターゲットとなるHMIパネルなどの用途には消費電力の縛りとコストの制約がきつく、M7は適当ではないと判断した」との事だった。
ただ将来製品に関しては現在色々な評価(Study and investigation)を行っており、この中で「高性能なシングルコアと、そこそこの性能のマルチコアのどちらが好ましいか、色々検討しているとの事。ちなみにマルチコアのメインフォーカスは、アシンメトリック・マルチコアだそうだ。
Synergyで興味深いのはツールチェーンで、コンパイラはIARがサポートされるが、Debug Probeがseggerを選択した。これについて「我々はツールチェーンについてもゼロから見直した。その結果、我々はDebug ProbeとしてはSeggerの製品が最適だと判断し、一方コンパイラはIARが最適と判断した。なので両者を組み合わせてe2studioに組みあわせるのがゴールデンツールチェーンの構築には欠かせないと判断した。もちろん、例えばIAREWやIARのDebug Probe、あるいはSeggerのIDEなどを含むその他のパートナーの環境を排除するわけではないので、将来はIAREWでサポートされるかもしれない。この組み合わせを選んだ理由の1つは、IARはすでにコンパイラのマーケットで40%のシェアを持っており、Seggerも同じくDebug Probeで40%程度のマーケットシェアを持っていることが挙げられる。つまり多くの顧客はすでにコンパイラのライセンス、あるいはDebug Probeを所有しているから、これをそのまま利用できる。なので、導入コストは必ずしも高いとは言えないこともポイントだった。加えて言えばIARは評価用コンパイラを出しているし、Seggerに関して言えばすべての開発キットはオンチップデバッガを搭載している(から、開発のとりかかりだけで言えば必ずしもseggerのDebug probeは必要ない)。恐らく2016年に入ればIARやSegger、その他のベンダは新しい開発ツールのオプションを出してくると思う」との事であった。