ASIC開発用サーバの妥当なスペックを理解するには

質問

社内SEとしてInfraを担当しています。ひとつ表題の件で困窮しており、
この場をお借りしました。

先月より、ASIC設計の会社が吸収され、勤務先の傘下にはいりました。
事業はハイスペックなサーバを多数所有しており、しかも来年度入替を控えている
というので、予算の判断に頭を悩まされています
　メモリ400GB
　REDHAT Linux6.**　Enterprise版
　サーバ機器　2013年導入が20台
　設計Toolとして EDA　である NCVerilogを常用　設計＞コンパイルの作業が日常的
このコンパイルのプロセスで大容量メモリが必要らしいです。

やっかいなことに、開発部署の人間が退職率がきわめて高く、
サーバ導入時の担当者もおらず、構成情報が皆無に等しいです。

そこで社内SEが状況把握に努めねばなりませんが、
私がlinuxの経験がなく、足踏みしています
自己学習である程度フォローせねばなりませんが、
納期の関係もあり、そうは言っておれません。

そこで経験ある方にお尋ねしたいことがあります
　1.ASIC設計の開発者が要求するハードウェアスペックの定番（？）水準をどうやって調べるか
　2.1を調べるに当たり、当事者（開発者）に、どういうヒアリングを展開すべきか
　　・ファイルサイズ、プロジェクト規模、開発プロセス、プロジェクトの中の立ち位置など
　　→　ここが一番時間がかかりそうです。テーマを絞らねば、、です
　3.ASIC設計のアウトラインを予備学習するにはどういうメディア、テキストが効果的か

理想的には、現場に何度か出向いて、キーパーソンとの面識をつくる、というアプローチがよいでしょうが、末端の社員なので（つまり偉くないので）、地道に調査を進める方略を探している次第です。

おつきあいいただくと幸いです。
以上、長文失礼しました。

回答No.3

superside0

ゲート数というのは、ロジック回路の最小構成要素で
2入力NANDで１ゲートとか、4bitカウンターで30ゲートとか、そういう感じです。
今どきのASICだと１００万ゲートぐらいはあるはずです。
（それ以下ならFPGAでも作れるので）

退職率の件ですが、職場環境うんぬんとかより、
ASICの事業そのものの変化による人材の選別化が行われての結果だと思います。
大手でもかなり再編されていますし。

お礼

ありがとうございます。
100万なんて天文学的ですね。
ASICの今後の展望も視野に入れて経営者の意見を促します。

回答No.2

superside0

まずは　設計対象となる　ゲート規模（最大ゲート数）を　調査されてはどうでしょう。

また、コアロジックの論理設計を行うだけなら、それこと普通のパソコンでも可能ですが、
論理合成や配置配線後の情報をバックアノテートして
チップのPin to Pin の正確な実遅延シミュレーションとか、
消費電力シミュレーションとか、故障診断シミュレーションまで、
行うのであれば、　ゲート数（回路規模）に合わせたそれなりのプラットフォームが必要になります。

それが決まっていれば、　メーカー（Cadence）か日本代理店が
マシンのCPUコア数やメモリーのサイズやI/Oスループットを　推奨してくれると思いますよ。

ちなにみ、ASICの事業自体は、小規模なチップ開発は、FPGAにとってかわられているので
生産数の少ないものをどんどん開発していたような昔とは違って
回路自体は大規模化しつつも、プロジェクトの数はかなり減っているので、
設備が余剰化しないように　注意したほうが　よいかもしれませんね。
もちろん今後の事業計画次第ですが。

お礼

superside0様
アドバイスありがとうございます。面白い世界に思います。
新しい用語、概念の吸収にはまりこんでしまわないようにして探究を進めます
>ゲート規模（最大ゲート数）を　調査されてはどうでしょう。
規模の大きさを「ゲート」と呼称していると解釈してますが（いったん）
業務内容に直結するので、しっかりした裏付けが必要のようです。
ただ、一歩近づけたような気がしてうれしいです。

回答No.1

hue2011

ASICというのはなんだかんだ言ってもハードウェア開発です。

これを1枚失敗すると、億単位の損害が発生しますので、品質監査が最も大事です。
繰り返しレビューを行う必要がありますが、担当者がそんなに退職が激しいのでは、くびくくりに近い状態だと見えます。
これは悪意がなくて言っていることです。

人材を固定的に確保する必要がありますが、居つきが悪いのは給与と環境が問題だと思います。
そもそもひくてあまたの技術者ですから、好条件での引き抜きは仕方がない。
だけどそれを引き留めるだけの体力を会社が持っているべきだというのは当然です。
そこは人事・経理との交渉です。

M&Aで買い取った会社なのであれば、経営が不調であるはずはありません。健康なはずです。

むしろ会社が買収されることで現場が不安感を持ち、退職者が増えたものと思われます。
これはきわめて致命的なことです。
現開発状況を知るものがいないのであれば、ASIC開発事業はたたんだほうがいいという考えもあります。
残っているメンバーが得意なことを全面に出したほうがよろしい。
しかし、もちろんすでに納入済みのものがあり、それを洗いなおしたりする要望が客先からあるかもしれない。
そのときは、実際の開発をここから外注に出すという策があります。

書類を書いてよく討論してみてください。

実際のハードウェアスペックですが、基本的にはかなり貧しい機器でも問題はありません。
メモリが多く、仮想記憶も豊富であるほうが良いのは当然ですが。

現場はよりハイスペックなものを求めるのは生理的に当然です。
だからここは、現場が「親会社が変わってよかった」と思わせるような予算を投入すべきだというのが一番妥当です。
一種の労使交渉です。

学習は、電気回路知識が最低限必要です。
電気工事士受験みたいなレベルはいりませんが、トランジスタICなどが入り込んだ回路図を読み取るまでは必要です。

そうしないと、進捗報告などで問題点が上がってきたときに現場からの提案が妥当かどうかの判断がつきません。

次に、この文化は、ハードウェアの世界の話をソフト的に処理するために開発されたようなものなので、FPGAの最低限の知識を身に着けることです。
HDL系の書物を読むのもありだと思います。

また、当然現場も使っているはずですが、SPICEで仮想的に回路をシミュレートする訓練もしたほうがいいでしょう。

verilogなんかは、文法的にはCとほとんど同じと思っていい。
ただし、オブジェクト指向ではあっても、クラスとインスタンスという概念はありません。
フレームワークの概念はあります。

いずれ、あなたがプログラムするわけではないはずなので、自分が活躍できるほどにまで習おうなどと思わないほうがいい。
しかし、第三者レビューができる程度にソースは読めたほうがいい。

あまりのめりこんで勉強しようと考えないほうがいいです。

この世界は、ずっとソフトウェアをやってきた人間にとってはかなりの壁が立ちはだかっています。

お礼

Fue2011様
ご回答ありがとうございます。
>この世界は、ずっとソフトウェアをやってきた人間にとってはかなりの壁>が立ちはだかっています。
ごもっともです。
そもそも用語が初めてのものだらけで、言葉に慣れるまでの忍耐が必要です。
しかし、嫌いな世界ではないので、好奇心をもって入ってゆけそうです。
ただ、仕事は激務のようですので、エンジニアの方の言い分にNOというのが簡単にはできそうもないです。
まずは共通の概念を少しでも確保してから心理的な距離を縮めていこうと思います。
課題：　FPGA、HDL、電気回路などの概念理解

また、人事的な面は切実です。
人材が確保できないと事業自体がもたなくなる危険も予想されます
加えて、サーバの入替が遅延したら、私にも責任がかかってくるので、
関係がこじれていないよう気を付けます。