アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
GAを用いた設計の評価って? (スコア:0)
Re:GAを用いた設計の評価って? (スコア:0)
なんか、クロックのタイミングをフリップフロップ（ＦＦ）ごとにずらしてタイミング調整するなんてすごく違和感があります。
まあ、ＦＦのクロ
Re:GAを用いた設計の評価って? (スコア:1)
>ということなんだろうか？
単純に、アプローチする観点が違うって事じゃないかと思います。
＃CTSで解決するかもしれないけど、こういう手法もあるよ、って事かと。
まぁ、ASIC屋の立場からすると、
>クロックのタイミングをフリップフロップ（ＦＦ）ごとにずらして
>タイミング調整するなんてすごく違和感があります。
ってところで、「はっきり言って使えないなぁ」と言うしかないですけどね。
＃理屈はそんなに筋が悪くないとは思うけど、なんか視点が数年くらい
＃古い気がするし。
＃セットアップエラーの対策でクロックラインを遅らせるって事は
＃クロックに対してのクロストークの影響とかが、部分的に狂うって事で、
＃同期設計の製品ではシステムレベルで製造後の調整で全く違う影響、
＃エラーが発見されかねず、はっきり言って危なくて使えない技術ですね。
>ＦＦのクロックに遅延挿入できれば部分的なセットアップ不足には
>効き目がありそうな気が
製造後は無理だけど、設計中はそんな程度のパッチワークみたいな
対症療法的な手法は全然可能ですけど、システムとしての動作に支障を
きたさないか、検証が大変なだけであんまり意味がないので、普通は
やらないですね。
＃遅らせてセットアップエラーを回避したクロックの次段で、遅らせてない
＃クロックでF/F叩いてデータ取りこんだら、マージン足りないよな気が。
＃それでなくても、クロックの位相がずれるから、同じクロックの根元から
＃分岐してるのに、異クロックとして扱わなければならない、なんて
＃事にもなりそうだし・・・。
＃あと、製造後、ってのがちょっとイヤだなぁ・・・。
＃条件の違う1chip毎に、ずらした状況で全F/Fのタイミングの再検証するの？
＃しないんなら使えないよ、これ・・・(汗)。
---- redbrick
Re:GAを用いた設計の評価って? (スコア:0)
>>効き目がありそうな気が
>
>製造後は無理だけど、設計中はそんな程度のパッチワークみたいな
>対症療法的な手法は全然可能ですけど、システムとしての動作に支障を
>きたさないか、検証が大変なだけであんまり意味がないので、普通は
>やらないですね。
普通はやらないけど、ＡＳＩＣ屋さんのお客の立場から言うと、スケジュール的に厳しいときにはやってしまい
Re:GAを用いた設計の評価って? (スコア:1)
>厳しいときにはやってしまいたくなる技のような
クロックを局所的にずらした状況で、製品の信頼性や機能の妥当な
検証作業が、すぐに終わるなら、誰も反対しやしないと思うのです
けど・・・。
>そんなパスは早く見つかるだろうから普通は優先パス（だっけ？）指定して
>とっとと再レイアウト
そうですね、それが普通の対処だと思います。
>＃ピンの同時変化制限対策には使えないかな
外部端子の出力ピンでなら可能性は皆無ではないと思いますが・・・
かなり難しそうな気が。
＃出力の波形を同時動作対策としてラインごとにずらしても、お客さんが
＃満足してくれるか？ってのもあるので、ASIC屋としては提案しにくいですし。
＃パッケージに出たら、パラメータが数桁変わるから、なかなか
＃chip内だけで閉じた検証のようにはいかないしなぁ・・・。
---- redbrick