アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
GAを用いた設計の評価って? (スコア:0)
Re:GAを用いた設計の評価って? (スコア:0)
なんか、クロックのタイミングをフリップフロップ（ＦＦ）ごとにずらしてタイミング調整するなんてすごく違和感があります。
まあ、ＦＦのクロ
Re:GAを用いた設計の評価って? (スコア:1, 興味深い)
> 部分的なセットアップ不足には効き目がありそうな気がしますが・・・。
まさにこれじゃないですか？
CTSでは遅延がでかいパスに全体がひきずられて、
高速化の足かせになってしまうような話は数年前からあります。
そのころにはCTSの途中にバッファ挿入したり配線調整したりして、
このような遅延調整したCTS(?)の生成を目指すベンチャーも出来てました。
＃ものになったという話は聞きませんが・・・
多分現在でも、高性能なチップの設計ではなんらかの調整を考えたり
実行したりしててるんじゃないですかね。
＃私はASIC屋なので、そんな調整
Re:GAを用いた設計の評価って? (スコア:2, 参考になる)
>CTSでは遅延がでかいパスに全体がひきずられて、
>高速化の足かせになってしまうような話は数年前からあります。
CTSと言うよりデータラインの問題では？
＃データライン側が遅れてタイミングが合わないのは、CTSのせいでしょうか？
＃・・・違いますよね？ ブロックの配置位置などの問題ではないですか？
あと、CTS側で高速対応が出来ない、ってのはCTSの構成の調整で
なんとかするしかない気がします。
＃論理合成側で遅いパスを高速部分から切り離すってのもアリ。
＃論理合成でなんとかなるんなら、製造後にいろいろいじる必要がなく
---- redbrick
Re:GAを用いた設計の評価って? (スコア:0)
>>高速化の足かせになってしまうような話は数年前からあります。
> CTSと言うよりデータラインの問題では？
> (以下略)
そうですよ。
データラインの遅れのせいで、Clockを高速化出来ない。
CTSでは、そのCTSにぶら下がっているFF/Latch全体に
同時にClock信号が到達することを前提にしています。
周波数をその遅れがあるパスにあわせることで、
そのCTSに繋がる部分全てに影響しますよね。
なので、遅れが生じるパスに部分的に遅延を挿入することで
それを制御しようという考えが出るのは自然だと思います。
ニュアンスはちょっと違う感じですけど、
>(以下略)
のところでredbrickさんが言ってるのは同じことと思います。
>>そのころにはCTSの途中にバッファ挿入したり配線調整したりして、
>>このような遅延調整したCTS(?)の生成を目指すベンチャーも出来てました。
>こっちは寡聞にして知らないのですが・・・、chipやテクノロジの
>アーキテクチャ依存の部分が大きいので、ベンチャーは難しいでしょうね。
アーキテクチャ依存なのか、そもそも手法に魅力がなかったのかは謎です。
うちに売り込みに来た時は、どっちの点でも問題視して採用を見送りました。
アーキテクチャの部分は頑張ってライブラリを作ってしまえばいいので、
世界中のどこのベンダも採用しなかったってことは、
やっぱり手法として魅力がなかったってことかもしれません。
>「配線性が悪化して製造期間増大」→「配線性が悪化して設計期間増大」ですよね？
そうです。
まぁ、ようはユーザーへの納入が遅れるってことで(^^;
>＃クロックだから周囲や自身へのクロストークも怖いし、
>＃余分なブロックのせいで 配線負荷も、
>＃制御信号のために配線数自体も増えるし、それに
>＃ブロック配置領域まで圧迫するわけですな(汗)。
>＃ちょっと、CADや設計側への負担が大きいなぁ・・・。
いやまったく。
やるなら、制御素子を埋め込んだFF/latchを作成して、
一つのブロックとして扱うのではないでしょうか。
ていうかそうしないと上記の問題に対処できんと思います。
それでもブロックが大きくなって配置に影響出そうですが。
制御信号用にはテスター専用配線が一系統増えるだけ(?)と考えれば。
結局は、実用化可能かどうか、そのコストはどうなのか、
ってのが大事なんですけどね。
そういう意味でもっと詳しいレポートを見たいですね。
多分、そのうちに業界ニュースで伝わってくるでしょう。
Re:GAを用いた設計の評価って? (スコア:1)
ですよね。
>CTSでは、そのCTSにぶら下がっているFF/Latch全体に
>同時にClock信号が到達することを前提にしています。
まぁ、多少のずれはありますが、それなりに高精度に、各F/Fや
Latchにクロックが伝播するようにCTSを作りますよね。
>周波数をその遅れがあるパスにあわせることで、
>そのCTSに繋がる部分全てに影響しますよね。
んー・・・わたしがそうする場合は、データラインに改良の余地がない
場合のみ、ですね。
クロックより修正しにくいデータラインって、あんまりないですし。
>なので、遅れが生じるパスに部分的に遅延を挿入することで
>それを制御しようという考えが出るのは自然だと思います。
いやぁ、それは同期回路とは違ってしまうので、非同期回路を完全に
検証漏れがないように検証できる方だけがやってください(苦笑)。
＃わたしには到底出来ないです(汗)。
>まぁ、ようはユーザーへの納入が遅れるってことで
それは、わたしも避けたいですね・・・(汗)。
＃今は、早くできないとASICも売れない時代だしなぁ・・・。
>やるなら、制御素子を埋め込んだFF/latchを作成して、
>一つのブロックとして扱うのではないでしょうか。
そういうのもありですねぇ。
>ていうかそうしないと上記の問題に対処できんと思います。
>それでもブロックが大きくなって配置に影響出そうですが。
確かに・・・。
>そういう意味でもっと詳しいレポートを見たいですね。
同感です。
コスト面などに関する続報などが出たら、興味深いですね。
＃ちょっとウオッチングしておこうっと。
---- redbrick