gm300の日記: timing
日記 by
gm300
は 0.9 倍モードpreCTS で setup 0 violation になる。原因は、
1. uniqfy する。
2. 外部非同期クロック間はすべて false にする。
3. FP を変えて使用率を平均化する。
始めの見積もり時には 3. が効果的。以前は 33 時間かかって密着死していた部分が 2 時間程度で終わる。見積もり時の timing は 1. の問題等があると時間がかかるので、マージンを大きくしてはとお上グループに図に乗って提案した。図に乗りすぎたらしく拒否された。たぶん。お上グループは一枚板ではなく内部構造が非常に複雑なので、外部からの提案を受け入れたのか拒否したのかどう判断したのか意思表示がはっきりしないからだ。
今の SDC で実現している clock cycle の scaling も受け入れは難しいだろう。というのはSDC の文法に沿っていない上にすべての tool が同じように global 変数を扱えるかどうか保証できないためだ。さらに乗算がいいのか、加算がいいのか、もっと複雑な式を選ぶか議論できないだろう。こここそがデザインの見通しと切り込み方の重要地点だが彼らには単なる技巧で汎用技術ではないと見なされるだろう。
実際、今日のデザインで何が一番問題かという定義は非常に難しい。問題点を改善すべき点と等価とした場合、改善した後のビジョン無しに改善すべき点は指摘できない。改善した後の様子などだれも見たことがないので、そのような共通のビジョンは持ちずらい。せいぜい、「勘、経験」である程度実現可能な変更点をリストしてその中からコスト対比が大きいものを選ぶのだろう。日本型IDMではサポートしなくてはいけないデザインは多岐にわたる可能性があり、しかも IDM 自身は将来どんなチップ・システムを作りたいかビジョンがないためにメリットの評価も難しい。 .. まあ、だから会社辞めてしまったわけだが。
OK, 私の今の考えを説明しよう。今の問題はデザインの本質ではない部分でデザインルールの項目が多すぎて、tool の設定が複雑過ぎる点だ。lib は諦めて C の plug in を直接差し込めるほうがスマートっぽい。
1. uniqfy する。
2. 外部非同期クロック間はすべて false にする。
3. FP を変えて使用率を平均化する。
始めの見積もり時には 3. が効果的。以前は 33 時間かかって密着死していた部分が 2 時間程度で終わる。見積もり時の timing は 1. の問題等があると時間がかかるので、マージンを大きくしてはとお上グループに図に乗って提案した。図に乗りすぎたらしく拒否された。たぶん。お上グループは一枚板ではなく内部構造が非常に複雑なので、外部からの提案を受け入れたのか拒否したのかどう判断したのか意思表示がはっきりしないからだ。
今の SDC で実現している clock cycle の scaling も受け入れは難しいだろう。というのはSDC の文法に沿っていない上にすべての tool が同じように global 変数を扱えるかどうか保証できないためだ。さらに乗算がいいのか、加算がいいのか、もっと複雑な式を選ぶか議論できないだろう。こここそがデザインの見通しと切り込み方の重要地点だが彼らには単なる技巧で汎用技術ではないと見なされるだろう。
実際、今日のデザインで何が一番問題かという定義は非常に難しい。問題点を改善すべき点と等価とした場合、改善した後のビジョン無しに改善すべき点は指摘できない。改善した後の様子などだれも見たことがないので、そのような共通のビジョンは持ちずらい。せいぜい、「勘、経験」である程度実現可能な変更点をリストしてその中からコスト対比が大きいものを選ぶのだろう。日本型IDMではサポートしなくてはいけないデザインは多岐にわたる可能性があり、しかも IDM 自身は将来どんなチップ・システムを作りたいかビジョンがないためにメリットの評価も難しい。 .. まあ、だから会社辞めてしまったわけだが。
OK, 私の今の考えを説明しよう。今の問題はデザインの本質ではない部分でデザインルールの項目が多すぎて、tool の設定が複雑過ぎる点だ。lib は諦めて C の plug in を直接差し込めるほうがスマートっぽい。
timing More ログイン