チップエンジニアとしては、卒業初日から入社初日まで明らかな変革を遂げる必要があり、仕事の発展やプロジェクトの進行に伴い、個人の能力も微妙に向上していきます。振り返ってみると、個人の知識・スキルの成長曲線を見ると、当初の計画とは異なる出来事や変化がたくさんあるかもしれませんが、将来に目を向けると、将来必要とされるスキルやスキルが変わってくることがわかります。私たちの手の差はまだ非常に大きいようです。では、どのような学習曲線が合理的で科学的でしょうか? ここでは著者の簡単な意見のいくつかを共有/議論したいと思いますが、不適切な場合は修正してください。早速、ICer GO!
成長したいという欲求
身長・容姿だけでなく、スキルや知識、自己実現の連続ブレークスルーは誰もが成長意欲があり、もちろんそれがあなたの幸福の源（エンドルフィンの源の一つ）でもあります（from: Howより多くのエンドルフィンを得るには? )
学生時代に、難しい問題を解決し、試験の追加問題を完了し、クラスメートから成績、いいね、良いランキングを獲得したのと同じように、仕事でも同様のことを行う必要があります。チップ エンジニアとしての価値を示すには、独自のアルゴリズムを使用して畳み込み Verilog の記述を実現するか、UVM を使用して CPU クラスターの相互接続の検証を完了するか、または TCL スクリプトを使用してマニュアルを完成することが考えられます。 DFT チェーンの微調整など、全体的には外観を取り除いても、学生は依然として「問題を抱えている」状態です。
基本的な知識を学び、基本理論をマスターし、独自のコードを使用して、プロジェクトが正常に完了するまで既存のプロセス、スクリプト、ドキュメントを学習することで、基本的なプラットフォーム上で小さなタスクを次々と完了させます。フィルムが返却されると、チップテストであなたの仕事の成果が認められ、垂れ下がったハートが「Yes, I Can!」と落ちます。おめでとうございます。螺旋階段の次のレベルに到達しました。
同様に、感謝や給料の増加などの物質的な変化は、エンドルフィンの幸福だけでなく、家族やガールフレンドに良い知らせを伝えることができる硬い物理的な物体ももたらします。
これは単にプロジェクト全体の成長曲線であり、次の要素があります。
- プロジェクトベース
- コラボレーション
- 個人は自分のビジネス/仕事に集中する
- 全体的な成功は個人的な成功のみを反映しますが、
以下のことはさらに類似しており、常に永遠に上向きのスパイラルを続けます。
個人の価値も徐々に拡大し、自分自身への自己同一性も徐々に強化されます。技術を理解して、しっかり仕事をして、連鎖を失わずに、ゆっくりと血液の中に組み込んでいくと、この時に標準技術者が誕生します！
プラットフォームと個人
チップ設計は比較的長い業務を伴う複雑なエンジニアリング プロジェクトであり、基本的には締め切りがあるため、誰もが非常に忙しいです。しかし、ゼロからスタートするプロジェクトはほとんどありません。新しいプロジェクトであっても、多くの知財リソースと EDA プロセスが提供されます。もちろん、人材が企業の競争力の中核であるため、最終的には依然として人が切り離せません。ここでは、プロジェクトを成功させる要因、つまりハードウェアを好むプラットフォームとソフトを好む人材を区別する必要があります。
プラットフォームの価値
単純なことは創造性に依存し、複雑な作業はプロセスに依存します。チップ設計は明らかに後者のカテゴリーに分類されます。フロントエンド/ミドルエンド/バックエンド/DFT など、各ステージには一連の独立したプロセスがあります。プロセスとは:プロセスとは、個人的なエラーを回避し、製品を高速化するための仕様です。会社がオペラを歌うために舞台技師を設置したと言われれば、この過程を単純にこの舞台とみなすことができます。鉄壁の大隊は流れるような兵士でいっぱいですが、このチップの設計も大隊のこのプロセスの一部です。
企業が大きければ大きいほど、そのプロセスにはより多くの注意が払われており、基本的なプロセスはシリコンの黄金律でも証明されています。この点は海外メーカーやHiSiliconを見ればZTEにも感じられます。バックエンドを考慮すると、さまざまなファブ/ノードに従ってプロセスを区別することもできます。
チップ設計が複雑すぎて、プロセスをゼロから構築することができないため、現在では EDA ツールをベースに構築する方法が一般的です。
| 設計ステップ | プロセスポイント | 補助ツール |
|---|---|---|
| コード設計 | コード仕様のチェック | 糸くず/望遠鏡 |
| 機能検証 | シミュレーション環境 | VC/NC-SIM |
| DFT | テスト容易性の設計と実装 | テキスト/テキスト |
| ミドルエンドおよびバックエンドの実装 | 総合・広報等 | DC/ICC/PT/キャリバー |
上記はいずれもEDA企業が提供する標準ツールですが、ユーザーがこれらのツールを利用したい場合には、それぞれのツールでプロセスを構築する必要があります。
一つのステップを展開すると、おそらくこのような図になるでしょう
しかし、ここで疑問が生じます。どこの地域ですか?
OK、見つかりました。おめでとうございます。APR を実行しています! 全体像を見ると、エンジニアは実際には会社のために働いているのではなく、プロセスのために働いていることがわかります。
したがって、厳密に言えば、プロジェクトの技術的構成は次のようになります。エンジニアはプロセスを使用してプロジェクトのタスクを完了します。
ただし、すべてのプロジェクトがプロセスを通過する必要があるため、プロセスの力はより複雑かつ強力になり、自動化がより高度になり、収束がより強力になることに注意してください。以下のような簡単な式があるとします。
项目技术总需求 = 流程 + 本项目的工程师的代码量
そして、プロジェクトが完了するたびに、将来的により大規模で安定したプロジェクトを作るために、エンジニアのコード量がプロセススクリプトにパッケージ化（アーカイブ）されるため、エンジニアのn番目の開発量が増加することがわかります。プロジェクトは:
项目n技术总需求 = 项目n-1的流程 + 项目n的工程师的代码量
設計がますます複雑になるにつれて、このプロセスの重要性は自明のことですが、大手 EDA 企業は現在、この点に攻撃を加えています。さらに、最近では AI を導入しており、現在と今後の動向 エンジニアのコード量がプロセスに飲み込まれるのは避けられない（EDA会社のエンジニアと綱引き？） プロジェクト開発という観点から見ると、やる目的
はこれは非常に合理的です。プロジェクトの成功率が最優先事項です。
このモデルを会社の誠実さに従って比較すると、同じプロジェクトの規模はおおよそ次のようになります。
コードの総量は似ているように見えますが、なぜ新興企業が既存企業に厳しいのかというと、答えはノーです。このモデルは次のように改良できます。
项目n技术总需求 = 项目n-1的流程*准确率 + 项目n的工程师的代码量*准确率
手作業に比べて工程の品質・完成度がはるかに高いため、結局、同じエンジニアが新会社の工程で同じ品質のプロジェクトを作ることは難しく、これは人間の問題ではなく、プラットフォーム構築の問題。
複雑な作業環境のプロジェクトでは、プロセスの価値が人の価値よりもはるかに大きくなりますが、これは EDA 自動化の観点からのみですが、IP、PHY、コーディングなどの観点から見ると、この現象はさらに拡大するでしょう。
したがって、プラットフォームはほとんどのエンジニアに依存していないかもしれませんが、プラットフォームはありませんが、ほとんどのエンジニアはプラットフォームなしではやっていけません
個人の価値観
プロジェクトのコードは依然としてエンジニアがコーディングする必要があります。エンジニアがいないと、プラットフォームは何も生み出すことができません。プラットフォームが川なら、エンジニアは川の中のボートです。ボートがなければ何も運ぶことができません。ただし、船は動的であり、エンジニアの選択も自由であることに注意してください。
大工場の高いプラットフォーム、広いスペース、強力な資本のおかげで、通常、仕事に入るときがピークであり、山から小さなものまですべてを見渡すことができます。
「ダシは香りが良い」というのは今でも昔から言われています。プラットフォーム構築の違いにより、大企業と中小企業では人に求めるものが全く異なります。
| 会社 | プロセス | 自身の仕事 | ジョブフィル |
|---|---|---|---|
| 大司 | 専門的なメンテナンス | フォーカス フォーカス フォーカス | 大根1本と穴1つ、誰がその仕事をしても |
| 小司 | 行うことで発展する | 集中すべきことが多すぎる | 全部やらなきゃいけないのに何もうまくできない |
ダシは梯子を登る
Dasi のプラットフォームは非常に優れており、これまでエンジニアが必要としていたのは、セグメント化されたフィールドを掘り下げ続け、ノンストップで繰り返し繰り返すことだったかもしれません。ゼロから始めるのではなく、基礎に基づいていることに注意してください。以前の多くのバージョンでは、以前は木が植えられ、子孫は日陰を楽しんでいた。もちろん、大規模なプラットフォームも非常に忙しいです。たとえば、HiSilicon スタイルの企業は優れたプラットフォームを持っていますが、プロジェクトも巨大で、非常に高いです。はしごを登るのと似ています:
大規模なプロジェクトの場合、このはしごは非常に長く、非常に長いかもしれませんが、優れたプラットフォームのおかげで、心配する必要はありません、間違いなく登ることができます。これが大きな工場のプラットフォームの強度です。エンジニア向けに、いくつかの機能を紹介します。
- ポジションの基本的な知識が必要です。実際にやってみてください。
- 先人の仕事を参考・継承し、完成できないリスクがない可能性が高い
- 質問がある場合は、EDA や周囲の同僚に質問したり、あらゆるリソースに相談したりできます。
- はしごは比較的長いので、孤独と継続的な残業に耐えることができる必要があります
シャオシーは家を建てる
小規模な会社では、通常、チームはそれほど大きくなく、プロジェクトは比較的小規模ですが、プロセスが不完全であるため (通常、EDA 企業のサポートがまったくありません)、プロジェクトを実行することは家を建てることと同じですが、支払いは発生します。注意してください、リーダーはあなたに高層ビルを建てさせません、おそらくXiaosiは高層ビルのセメントコストさえ支えることができないからです。
最初のプロジェクトでは、まずバンガローを建てて、チームがどのように機能するかを見てみましょう。
エンジニア向けに、いくつかの特徴を示します。
- チームには理解者 (つまり、プロジェクトを完了した人) が必要です
- 家を建てるには、たくさんの雑用が必要です。すべてをやらなければなりません。すべてができなければなりません。できない場合は、少なくともそれを学ばなければなりません。
- プロセスは現場で構築され、実行中に変更されます
- 強いイニシアチブが必要で、待っていてはいけない
- 頼める人がほとんどいない、みんな忙しいか、あなたにやってもらいたいだけ
- プロジェクトは繰り返しがほとんどないので、家を建てるときに問題が発生するかどうかは誰にもわかりません。問題があった場合でも文句を言わないでください。忍耐強く思いやりを持ってください。
大企業のはしごは長く、中小企業の家は広い、面積と仕事量で見ればその差は基本的に同じであり、プラットフォームの違いにより、両者のリスクは異なります
。
このような違いは、人々の要求に明らかな違いをもたらします。新人や若手技術者は、はしごが落ちずにうまく登れるように、他の人が家を建てているのを見る前に大溪に滞在することを選択する必要があります。経験豊富な技術者であれば、どちらでも良い、家がしっかり建てられるなら、レベルの高い小さな会社を立ち上げても良い（ベンチャー企業の論理）、しかし、小さな会社が成功したいのであれば、カードの位置が大きい場合、そうでない場合は失敗する可能性が高くなります。
学習曲線
エンジニアが中小企業であっても大企業であっても、プロジェクト全体の大きな方向性やプロセスは基本的に似ており、おそらく中小企業のプロダクトは比較的シンプルで簡素化されていくのでしょう。個人の学習曲線に戻ると、被験者には次のような段階的な学習の提案がいくつかあります。
- スキルの概要
エンジニアにとって、そのポジションの技術的な概要を理解することは重要です。
チップのビジネス プロセスは比較的長く、どのノードでも比較的長いプロセスが必要です。エンジニアはこの業界に不慣れです。体系的なデータ、社内プロセス、ツール UG などを確認することで、このプロセスの価値と特性を理解する必要があります。 。これは、今後の作業のフロー制御にとって非常に重要であり、プロジェクトのサービスをより効率的に提供することもできます。
ここでは、たとえば、ポスト シミュレーションを説明するための簡単な例を示します。ポスト シミュレーションは、通常、APR の完了後に提供されるデータベースで発生します。目的は、静的タイミング解析とゲートシミュレーションの間のギャップを埋めることです。一般的に言えば、それはのみ実行できます。 APR が実際に収束した後、ゲート シミュレーションを開始し、エンジニアがゲート シミュレーションと APR ECO の焦点を正確に区別できれば、より高速な方法でゲート シミュレーション シミュレーション環境を提供することが完全に可能となり、ゲート シミュレーションの速度を向上させることができます。少なくとも1か月。
このポジションで自分のポジションの技術的な概要にさえアクセスできない場合、それは基本的に会社のプロセスが完璧ではないか、基幹人材が不足している状況と見なすことができます。このようにして作られたものは保証できない可能性が高いです。 - 技術的な専門知識
が個人的に注力される可能性が高い例: RTL 設計エンジニアは、PCIE の開発と呼び出しに重点を置いていますが、ここでは PCIE の本を何回も読むのに多大な労力を費やす必要があります。 。検証担当者であれば、PCIE の仕様を理解するだけでなく、検証環境/プロセスで影響を受ける箇所にも目を向ける必要があり、RTL コードのバグに加えて、次のような点にも注意する必要があります。プロセスの穴。この技術点は長年培われてきたものであり、将来この分野のエキスパートとなれるでしょう。結局のところ、PCIE6.0 が登場するのですが、それを理解するより良いことはあるでしょうか? - インボリューションの理解
英語には「volution」を語源とする単語がいくつかありますが、これは大まかに次のような「渦」を意味しますが、これを語源とする場合は以下のような単語が一般的です。
| 言葉 | 言い換える | 追記 |
|---|---|---|
| 進化 | 渦巻く | 根 |
| 畳み込み | 理解できないこと | – |
| 権限委譲 | 分散化 | – |
| 進化 | 進化 | – |
| 革命 | 革命 | – |
| インボリューション | 変性/退縮 | と evoluton は互いに対義語です |
現在よく言われる「内向化」には、実は退化的な意味が含まれていることが分かりますので、イノベーションとは競争（コンペティション）やチャレンジ（挑戦）ではなく、むしろ内部退化、あるいはチーム内部消費です。 。
進化の理解:あるもの (進化) が外に向かって進化することができず (電子進化)、それが既存のリソースに対してのみ同じ人々によって同様の方法で繰り返し反復される場合、最終的なもの (進化) は遅れをとってしまいます。インボリューション（インボリューション）。
インボリューションの中核的な問題は、現在の問題に焦点を当てすぎ、既存のプロセスや方法を使用して現在の問題を解決することに大きな期待を寄せていることです。この力が強ければ強いほど、巻き込みはより深刻になります。巻き込みから抜け出す 1 つの方法は、次元を増やすことです。つまり、現状の手法を学習した上で、既存の手法のプロセスを飛び出し、より高い次元から最適化を行うのです。これには、進化、さらには革命に対する強い意識が必要です。これは自分自身への挑戦であると同時に、チームへの挑戦でもあります。
インボリューションの渦に陥るな、インボリューションを誇るな、システム全体がインボリューションの状態にあるので、インボリューションで消費される資源は全て消費（コスト）収益となり収入にはならない。
4. フラットラーニング
はしごを登るときも、家を建てるときも、これは非常に重要です。前述したように、プラットフォームのプロセスは、日々の仕事において空気と水です。誰もがその価値をまったく感じていないため、多くの人が抜け出します。私のクラスメートのほとんど、特に大きな工場の出身者は非常に狭い業務を行っているため、特に長い経験を持つエンジニアにとって、新しい環境や小さな会社で働くことはより困難になるでしょう。彼らの生活は、引っ越しするのが難しいです。したがって、特に大工場の従業員に対しては、できるだけ早くフラットな学習経路を確立する必要があります。そうしないと、大工場を辞めた場合のプレッシャーが非常に高くなります。
コードは特定の問題を解決し、プロセスはプロジェクトの問題を解決します。次元を改善したい場合は、プロセス プラットフォームの観点から問題を見る必要があります。
したがって、自社の事業を中心にしながら、その事業を実現するプロセスにも注目する必要がありますし、間接的に他の事業部門のプロセスを参考にすることもできます。
プロセスを理解することはプロセスを最適化するための最初のステップであり、プロセスを最適化することはプロセスを作成するための最初のステップであり、プロセスを作成することは従来のプロセスを打破するための最初のステップです。
学習をフラット化し、思考の次元を向上させることによってのみ、現在の渦（進化）から飛び出し、巻き込み（巻き込み）を回避することができます。
大企業のはしごを登る場合でも、中小企業で家を建てる場合でも、フラットな学習を通じて、最終的な知識トポロジーは大きな長方形として実現されなければなりません。
個人的な経験という実際の状況を考慮すると、人々が事実について包括的かつ熟達することは不可能であり、実際の知識領域の総量は正規分布に似ています。
フラットな学習、知識の拡大、進化と革命の精神の活用、外部の世界からのリソースと強みの吸収を通じて、効果的な空間で相互の巻き込みを効果的に回避し、個人の向上とチームの価値を達成することができます。