SystemC、SpecCについてのスレ

今、話題になってるようですが、どうなんでしょうか？
企業ではもう使ってる？

よし、キターーーー(ﾟ∀ﾟ)ーーーー！
だが、お隣の板で、C記述段階と合成後のシュミレーションのギャップでは苦労しそうだという見解だったが・・。

Open SystemC Initiative
http://www.systemc.org/

SpecC Technology Open Consortium
http://www.specc.gr.jp/index.htm

C/C++によるVLSI設計―SystemCによるJPEGコーデック設計
http://www.amazon.co.jp/exec/obidos/ASIN/4320120817/ref=lm_lb_2/250-6918473-1229059

Cを使ってみてる。すげーっ！！！としか言いようがない。
久しぶりに感動した。

>>4の先の
＞SystemCによる回路記述
っていうのは考え方が間違ってるよ！と言いたくなる。

　企業で実際にSystemCを使ってLSI設計している方います？
私は、大学でやってますが。

学部生乙

>>6
苦学生かもしれんが親のスネかじってるんなら必死で勉強しておけよ。
会社に入ったら勉強してる時間もなく即実戦投入なんて当たり前だからな。

セロックシカのHandel-Cも仲間に入れてくれる？
http://www.celoxica.co.jp

freeでCからHDLレベルまで落とせるヤツを探してちょっとだけいじってみた。

Streams-C : ターゲットが決めうちなのがちょっとつらい。ソース付きなので
　 　 　 　どうにかなるようなならんような。使い勝手は、オラクルとProCみたいな感じか。
SPARK : 必要なソースファイルだけ論理合成用に指定してVHDLに落とす。
　 　 高級？なアプリケーションをターゲットにしているのか、生成された
　 　 VHDLは、あまり直感的ではないような。
　 　 入出力の定義をどうやるのか、またクロック同期をする方法がまだよくわからない。

# どちらもHandel-Cみたいに、素直なC環境とは大分違うです。

Streams-Cを眺めてみましたが、ターゲット決めうちはちと辛いっすね。
ソースがあるし、簡単にリターゲットできるから・・なんて書いてあった
けどほんとかな？
やはりHandel-Cみたいなごく素直なＣ環境が一番いい気がします。
フリーで出回ってくれば大きな転換点になることは間違いないと
思うのだけども。

Handel-Cって、元々はオクスフォード大学で開発されたわりには、
ペーパーはいくつか見つかったけど、ソースその他は見当たらず・・・。
研究者自体がスピンオフして会社にしてしまった(現セロックシカ)から、
しかたないのかなぁ・・・。なんか変な気がするけど。
とりあえずDOS版の超古い('96物)実行ファイルは発見けど、XPのDOS窓や
wine,dosboxでは動かなかったです。

SystemCやSpecCは、俺みたいな在野の親父にとっては、うなぎの良い匂いを嗅がせてくれるだけだしなぁ(w
Streams-Cでもつついて遊ぶしかないか(まあ、これもコ・デザインのスウィートになった3桁万円の製品版があったり
するみたいだけど)。

こんなのもあったけど・・・ちと古いっすね。
http://www.eecg.toronto.edu/RESEARCH/tmcc/tmcc/

あ、URLを書くのを忘れていましたね。

Streams-C : http://rcc.lanl.gov/Tools/Streams-C/index.php
SPARK : http://www.cecs.uci.edu/~spark/index.shtml
Handel-Cの太古版 : http://www.inf.pucrs.br/~moraes/topicos/hdls/HANDEL-C/

おっとぉ・・・Handel-Cの太古バージョン、Win2000のDOS窓で
動きましたぜ。
HCC.EXE
と
CAMLRUNM.EXE
の両方を落として、
hcc t1.hcc
とやっただけ。中身はマニュアル眺めながらちょっと
書いてみたけど、こんな感じ（インデントがおかしくなると思うけど・・）
const spec t1 = {
fpga_type = "Xilinx3000",
fpga_chip = "3195APQ160-3",
clock_pad = "P160",
not_error_pad = "P55",
finish_pad = "P44",
clock_divider = "1",
carry_weight = "50",
critical_weight = "100"
};

main(target = t1,chan (out) dataout : 8)
{
int x:8;
x=0;
do {
x = x+1;
dataout!x;
} while (x < 125);
while(1) ;
}

コンパイルするとそのまんまシミュレーターが動いてしまうの
だけども、ちゃんとＸＮＦファイルができとりました。

hcc　-ns　t1.hcc
とやれば、シミュレータは動かず、
コンパイルしてXNFファイルを作って終了するようですね。

あれま。Win2000だと動くのですか。
単にうちの環境が腐っているだけなのかな。うーん

Ｄ／Ｌしたときにデータ化けしてしまったとか？

こんなんがでるのです。

｜Exception 12 (0x0c) at eip=2183
｜eax=00000301 ebx=000062d2 ecx=00000000 edx=0000ffff esi=000030d6 edi=000030e8
｜ebp=0000ffc4 esp=00062bc0 cs=19f ds=17f es=17f fs=0 gs=0 ss=1b7 cr2=00002fd8
｜Call frame traceback EIPs:
｜ 0x00002183
｜ 0xffd80001

で、DEBUGで見ると該当アドレスには、未定義コードが・・・。
もしかしたらEMSとかメモリ関係で引っ掛けてるところが家の環境はうまく動いていないのかな。
あとで太古マッスィーンのAMiTY CNを引っ張り出してチャレンジしてみようと思います。

# SH派さんですよね？　相手してくれてるのって(W

ＸＰでやってみたら、同じようにコケますね。
Win98は大丈夫。Win2000も大丈夫・・ふむ。
そういうことみたいですね。

＃で、それは一応そのままノーコメントってことで（ｗ

あー。XPではダメなんですね・・・。とほほ。
(たぶん)前掲のリンクのHandel-Cは、研究途上の物だと思われるので、
これの利用は商用を考えなければいいのですよね？　ですよね？

とは言え、どのデバイスまでサポートしているのでしょうね。英語は良くわからないので（ｗ

# ノーコメントって、元は英語ですけど日本語で解釈すると含みがありますよね（ｗ

別に良いんでしょうね。商用には絶対使いようがないでしょうし。
デバイスは・・うーん・・と、吐いたＸＮＦを見るとかなりプリミティブな
ものの結合でしかやってないので、ＸＮＦを読ませてからターゲットを
決めることが・・・できるのかな？

なんといいますか。

学者様や起業家の方の技術やスキルはすごいことだと思うのですが、漏
れら底辺エンジニアが遊べる環境は、どうしても3桁万円・・・。

学生さんはアカデミックプログラムがあったりして最新技術に触れられるけど、
漏れらは雑誌の付録のサンプル(無論、実用性はなし)をさわって「へー」とかいう位しかない。

どうにかならないかなぁ。
あ。どうにかなっても、現場で実際に運用するには、習得するよりも多くの労力が
必要だったり(苦笑

ですね。Ｈａｎｄｅｌ−Ｃに至っては４桁万円（爆

制約があっても、とにかくそれなりのものを実際に動かす
ところまで作れるという環境さえ出来上がればいいのです
けど。QUARTUSやＩＳＥ WebPackにＣインターフェース
がオマケにつくことは・・・ないんでしょうね、やっぱり。

ＩＳＥをインストールしてみたのですが、ＸＮＦが読めないんですね。
http://support.xilinx.co.jp/xlnx/xil_ans_printfriendly.jsp?getPagePath=12980
を見たら、ＩＳＥの4.2iがＸＮＦが使える最後のツールだそうで。
http://support.xilinx.co.jp/webpack/classics/wpclassic/index.htm
こっちから4.2以下のを落とさないとだめか・・

げ。DK1って4桁万円もするのですか。
UKではDK2が発売されているみたい？ですが、
こっちもすごい値段になりそうですね。

ISEですが意外と最新のやつよりも4.2iあたりが親しまれている
感じがありますね。ついつい最新版を入れたくなっちゃいますが（ｗ
仕事では枯れた環境を好んで使うくせに、家の環境はわけわかめだったり。

正月の酒に任せて思うことを書いてみます。

正直、SystemCやSpecC、そしてHandel-Cなど、
自分の仕事の上ではきっと役に立つツールだと思います。
便利そうだし、自分の身の丈にあったアプリケーションが比較的楽に
構築できそうですし。

でも、仕事の現場にあっては、そのコードは誰が書くのか？
自分は趣味で電子工作をしているので、まぁ全部が自分の担当です。
で、仕事となるとどうかなぁ、と。

自分の職業は、ファーム屋なんですが、これらの技術が普及すると
自分の身の置き場(というか、何で飯を食って行けばいいのか)が、
非常に不明確になってしまうような気がしてなりません。

電気屋さんの設計したハードウェアの持つ仕様にしたがって客先の望む
アプリケーションを実装するのが自分等の仕事なわけですが、これら
Cベースのコ・デザインツールが普及した際は、自分は何をすればよいのか、
何ができるのか、などと考えてしまいます。

アナログ回路や、デジタルにしても微妙な味付けなどが存在します。
漏れら一介のファーム屋がわかるわけもなく、電気屋もCでバリバリコードを
かけるわけでもなく・・・。
今後組み込み業界で生きてゆくには、どうしたらいいのかなぁ、
なんて酔った頭で考えてみたのですが、結論はでなかったです。
ファーム屋が電気屋さん兼業になるか、電気屋さんがファーム屋さん兼業になるか。

電気屋さんがファームを書いたほうが、当然いい仕事ができますよね・・・。
正直、ハードのデバッグには付き合えるけど、自分でアナログ回路とかは組めないですから・・・。

>>28
APIを組み合わせてプログラムを作るという、
ロジカルな作業ができればだいじょうぶです。

私も、ほろ酔い気分ですが・・

Ｃで書かれたソースコードをコンパイルするのが合成ツール、
「実行」するのがFPGAなりGAだと考えるのが良いんではないかと
感じてますが。どう見たって「プログラミング言語」ですし、
ファーム屋みたいに泥臭いところをかいくぐってきた人が一番
活躍できるんではないかな？

LEDの点滅、ターミナルへの１文字出力レベルからネチネチと書
いてきて、マルチタスクやらリアルタイムの考えも叩き込まれて
いるファーム屋さんにとってはこれほど美味なものはないと感じ
るんではないかなぁ。なにせ、同一クロックのマイコンと比べたら
嬉し涙が出るほど速いですし、マイコンじゃ絶対無理な完全な
平行処理が平気でできちゃうのも魅力でしょう。

今までの延長というだけでは考えもしなかったようなものとか、
できそうな気はするけど、あまりにも手間がかかりそうであきらめ
ていたようなものが在野の中小企業から生まれるきっかけになる
んじゃないかとさえ思っとります。

アルゴリズムだけ書けてI/Fは宜しくなんて仕事の仕方をする
ソフト屋がハードも設計できると勘違いしてハード屋不要論を
振りかざすなんて、10年前に見た光景を繰り返すんだろうな。（ｗ

「そんな中途半端な分け方しないで全部やれ！」ってことになるかもね。

ところで1990年頃にハード屋不要論なんてあったっけか？

>>32
ハード屋不要論
HDLがだんだん使えるようになってきた頃解ってない奴が
盛んにそんなことを言っていた。

日経エレクトロニクスも10年位前に、今のCと同じような扱いで
HDLの記事を盛んに書いていた。ハード屋不要論もこれに感化
されたっぽいね。

あぁ、了解。
結局不要どころか、「ハード屋もっとやることあるぞ」になって
しまった気がするね（ｗ

日経はセンセーショナルな書き方が好きだからなぁ。
100%嘘ではないんだけど、ごく一部だけスポットあてるから、
妙な解釈されてしまうのかも。

うう。webpack4.2iには、.xnfを読むためのDesign managerが入っていないですね・・・。
xnf2ngdとか使ってどうにかするしかないのかな＜Handel-C太古版

こっちも探してみました。
なんと・・・ＩＳＥには入ってるとあるけど、確かにWebPackには
入ってない・・（怒
4.1も落としてみましたけど、やっぱり無い
xnf2ngdっていう手ですかね、こりゃ。

うまくいくのかな？
これがうまく開通すれば面白いことになりそうですけどね。

>>36
私も落としてみました。3.3も。
3.3には同名のバッチファイルが入っていて、実行すると
「コレ、先は長くないよ」といったテキストを表示するだけでした。

闇雲に件のディレクトリにあるarq1.cをhccにかけ、
出来たxnfを3.3のxnf2ngdに。
"パッケージが変だぜ"といわれましたが、
かまわずに出来たngoファイルをngdbuildにかけると、やっぱりパッケージの指定が
どうちゃらとかいわれて手詰まり。
xlinxのサイトでみた-pオプションの項目のやつを指定してみましたが、うまく行かなかったです。
あとで、4.2iのexeで再挑戦してみます。
ngdファイルが作れれば、あとはどうにかなりそうな気がするのですが、はてさて。

3.3版で試してみたことの追記です。

xnf2ngdとngdbuildは別々に呼び出す必要はなく、
ngdbuild -nt off -p パッケージ名 ファイル名
だけでよさそうです(-nt offは不要かも)。

ngdbuildは、指定したファイル名.ngoがなければ、
xnf2ngdを自分で呼び出してくれます(逆に、ngoファイルが
あると、xnfは読みに行きません)。

前の書き込みで-pオプションについて書きましたが、自分は
CPLD環境しかインスコしていなかったためかもしれません。
xc9500とかを指定すると、かなり頑張る意欲を見せてくれましたので。

SystemCが組込まれたVerilogCを使っている。
もう、ハードとファームは同時に設計するのが当たり前。

Handel-Cその後。

・fpga_typeに"VHDL"を指定すると、VHDLを吐いてくれる。しかし・・。
・デザインマネージャは、ISE　クラシックにあるspartan/4kに入っている。

>>39
詳細きぼんぬ。

オープンHandel-C（って言うのも変だな・・（笑））
テスト用に小さいファイルで"VHDL"でやってみますた。
んんん・・・・電源らしきところはコメントアウトするにしても、
LIB_OR2とか、これが全滅か。こういうプリミティブなゲートを
全部定義しないといけないのかな？

>>42
なんかそんな感じです。とほほ。
今のところ出てくるライブラリは、本当に原始的な奴しか出てこないので、
ぼちぼちとこしらえて行くしかないのかな、なんて思っています(すぐに飽きそうですが)。

んで、HARPのサイトからオクスフォード時代の
Ian Pageさんのページにリンクがあって、(web archiveで)みると
マクロやらHandel-Cのファイルにリンクがあるのですが、ことごとく
NGでした・・・。


Handel-C太古版の話をこのスレでするのも、ちょと気が引けてきたり・・・。
スレを立てるか、あっち(w)へ行くか・・・。んー

# HARPってトランスピュータだったんですね。どうりで謎の
# ハンドシェイクみたいなコードがくっ付くわけだ・・・。

ＨＡＲＰはＳ抜きシャープ（嘘
あぁ、そういえば、なんとなくそういう名前の製品もあったような・・

なぞのハンドシェークってTXRDYとかRXRDYですよね？
HARPじゃなくて、上に示したような単純なソースでも生成されます。
関数の処理がシーケンシャルに行われるので、Go-Done信号が
必須だからそれかな？と

あぁ、そうそう、outの信号をリードしようとしてしまうので、
一回signalで受けなおす必要もありました。
ゲート自体はかなりプリミティブなものしか出てこないようなので、
地道に（っても、たいしたものじゃないけども）作成していけば
ひょっとしたら使えるのかも。

＞Handel-C太古版の話をこのスレでするのも、ちょと気が引けてきたり・・・。

確かに・・・Handel-Cな部屋でもこしらえたほうがいいのかな？

>>44
>なぞのハンドシェークってTXRDYとかRXRDYですよね？

それですそれです。必要ならCの記述に含めるのが筋かと思ったので、
デフォルトでくっつくのはもしかしてHARPのお約束なのかな、などど感じた次第です。

# 別スレ起こしても、二・三人しか書き込んでいないみたいですね・・・（ｗ
# 面白いネタだと思うのですが。

>>45
× # 別スレ起こしても、二・三人しか書き込んでいないみたいですね・・・（ｗ
○ # 別スレ起こしたとしても、現状では二・三人しか書き込んでいないみたいなので、どうでしょうかね(w

# 昼酒は効くなぁ(仕事サボり)

手作業が結構入ったけど、できました。
フリーHandel-CからALTERAのFPGAにフィッティング。
まだ簡単なことしかやってないけど面白く遊べるかもしれない。

>なぞのハンドシェークってTXRDYとかRXRDY
この２つはシリアルドライバチップレベル(PCではチップセット)で行っていて、バス内には信号でない。
非同期シリアルで送るときTxRDYに１立てる(データ入れると勝手にチップがやる)と、相手のRxRDYに１が立つ。
この２つのbitはPCのI/Oアドレス上に見える。アドレス03FE(COM1)のMSRレジスタ(シリアルドライバチップ内)にbitがある。
このビットを見れば、データが着てるかどうかが分かる。
これは、非同期シリアルのプログラムで使う場合と使わない場合がある。
送るときはレジスタに流せばいいんだけど、上述のように受けるときは頻繁に確認がシツヨウで、その確認にTxRDY、RxRDYを使う。
他のレジスタを見て判断することもできる。→IIRレジスタ(I/Oアドレス03FA)
ここでは、受信ラインステータス、受信データ有効、THRエンプティの状態データが見れる。
他に、使わない場合はINT21(DOSシステムコール)でAHを見に行くのでそこにシリアルがセットされてれば、DOSがデータをひっぱってくる。
AHを06h,07h,08hのコンソール入出力、コンソール入力にセット。INT21掛けた時点で、割り込みルーチンで、シリアルドライバチップのレジスタからデータを引っ張ってきてどこぞやに保存してくれているはず。
その場所を定期的に見ればよい。

>>48
あのー。勘違いしてませんでしょうか？
HANDEL-C(太古版)の吐くVHDLの話なんですが。

>>47
すばらしい！

やっと開通しましたよ。
ＡＮＤやＯＲやＦＦなんかのプリミティブなゲート類を
定義してライブラリ化（といっても、VHDLの入門書の
最初の方のページにあるようなつまらんものばかりですけど）
するのと、エラーが出てしまう行を見ると使ってないようなので
コメントで殺して、あとは出力ポートをいきなり読み出そうとす
るようなコードを吐くことがあったので、ポートの方を名前変えて
ポート名と同じsignalを定義して、
旧ポート名signalと新ポートを＜＝を使って結合した
程度ですが。

ためしにインクリメントデータを出力するものを
作ってQUARTUSにかかって、FPGAにダウンロードして
みたらちゃんと波形がでてきましたんで、これでひとまず
ｵｯｹｰでしょう。

>>51
をを。自分の考えていた方向性が間違っていなかったのを確認できて一安心です。
私は手を動かしてませんでしたが(苦笑
買ったまま未組み立てて放置してあるEZ-FPGA(スパ２)があるので、いまさらながら
がんばってみようと思います。

ノウハウ公開、ありがとうございます > 51さん

システムCを使いたいけど、コストの面でどうにもならないな。
こういうツールを使うことが出来るのは、そのコストをあまり
気にしないセットメーカーさんだな・・・

１個数万円のFPGAを使っているんだったら、コストなんて
あんまり関係ないじゃない。LSI屋はどこも似たり寄ったり
なんで、１個５００円以下で売らないといかん。だからとても
じゃないが、冗長性が大きくなる可能性があるモノを使え
ないなぁ・・・ブレッドボードのFPGAは１個、７５万円だもん
な・・・

個人的には面白そうだと思うんだけど　<HANDEL-Cの昔のやつ
なかなか盛り上がらないね。

誰かがインベーダーゲームとかわかりやすいアプリを出してこないと
食いつかないのかな。

# 俺にはできないんだけど。

良くも悪くも大人になっちゃった人が多いんでしょう。

来月号のデザイン・ウェーブ・マガジンはＣベース設計の特集ですね。
さて、どうなることやら。

>>55
こんどこそ、鰻のよい匂いを嗅がすだけの特集でないことを祈っています（ｗ

どっちの料理ショー

じゃないですが、せめて鰻の皮が食べられれば・・・（笑
そろそろ本格的にＣな時代になってほしいですよねぇ。
エポックだと思うんですけどね。

このスレ的には、Handel-Cの古いヤツが鰻の皮かな？（ｗ

なんか色々あって、未だに試せていないのですが・・・。

D.W.誌、買って来ました。
太古版がコラムで紹介されていたので、ちょっと嬉しかったり。

XPだとダメだという話は、
今月のデザインウェーブに載ってるね
それにしても、いよいよCの時代かな

>>60
このスレがネタ元っぽいね。

>>61
やっぱりこのスレがネタ元なのかな？

もしもここがネタ元だとしたら、うれしいです。

ぐぐるってみると、太古版を使い始めている人もちらほら。
イカすアプリケーションが出てくるといいなぁ。

VHDLで書いた回路が引き継げなくて、困ってるのよ
Cで書き直すのはわけないから、あとはただとか安い値段で手に入るCベース設計ツールがあればいいんだけど
太古版Handel-Cが安定してくれてればいいのに

>>64
安定、と言うよりも、基本的なライブラリの拡充が必要ですね・・・。
今のところ、どんなゲートが要求されるかわからないので、
「オマイ、NANDすら知らないのかっ！」みたいな感じですから。

やっぱりまだ時期尚早なのかな

規模増大を，抽象度を上げる方向でなく，IP（買い物）で済ますという方向になってる気がするんだが…

昔だったらＩＰを使わないとやってられなかったようなのが、
パタパタッと書いてできちゃう領域が広がるというのは
メリットだろうね。
まだＩＰとして提供されていないようなものもサラッと
実現できるだろうし。

ズブの素人なんですが
HDLとこれ、どっちからはじめるのがお勧めですか

SynopsysはSystemCを見限ったの？
最近のSynopsys主催のセミナーは
System Verilogばかりのような気がする。

シノちゃんはSystem Verilog派でしょ？

折れ的には、保険のつもりで二股かけてるのかと思った。
軸足はSystem Verilogかな。

Synopsys SystemC Compiler はあぼーん予定
http://www.eedesign.com/showArticle.jhtml?articleID=18201864

どうせやめるならフリーにして欲しいな

マイナーな上にベンダ固定なんだけど、NECのBDLっつー
Cモドキ設計言語使ったことある人っている？

ForteのCynthesizerはいよいよ正式発表でつか。
http://www.forteds.com/news/pr051004fortekkjapanese.pdf

日本法人社員の桜井至氏ってHDL関係の本書いている人か。

>>75
社員ハケーン・・・ってCyberの事だね。BDLは動作記述言語の事
あれはコデザインじゃないから
今のところ敵視してないです。
それに展示会見る限り他社に供与する気も無いでしょ。
お金の話したら歯切れ悪かったよ

BDLみたいな動作記述言語からファームウエアなどのソフトを生成することはできないのかね。
そういうアプローチのコデザインもあっていいとおもうのだが。

>>78
とりあえずファームにしておいて、間に合わなかったらハードに持っていく
ってーのが最近の流行(?)

>77
この業界狭いんだからやめとけ
すぐだれだかわかっちまう
俺もなー
最近Visialspecつかってますた。
マイナーだ
つーかだれかまともな掲示板立ち上げれ！

荒らしｷﾀ━(ﾟ∀ﾟ)━( ﾟ∀)━( 　ﾟ)━(　　)━(　　)━(・ 　)━(∀・ )━(・∀・)━ｶｴﾚ!!!!!

age

このｽﾚの廃れようじゃ、Cベース設計も終わったか

ソフト・ファーム屋さんは結構手を出しているんじゃないの。

LSI設計者から見ると、DesignCompilerのように動作合成ツールの
デファクトスタンダードができるまで手を出しづらい。
逆に言うとそのような状況になれば設計フローも確立するし、
一気に普及しそうな気がする。

いまのところHDL渡しなので、
C合成出力のHDLが読みにくいのがネック。　だけど、
ツールによっては、慣れると読める(変態?)のもある。
＃読んでも、C合成のBug報告以外に何をするってこともないんだけど…

HDLとの等価性が無いのが厳しいんだよね。
いくら機能検証がHDLと比べて劇的に速いといっても等価性が無い以上
ハード化にはHDLでの検証も必要になってくるわけで、
単にフェイズが増えるといった結果にもなりかねない。

フルスクラッチでFPGAぐらいの規模ならよいとしても、
SoCとなると最初は結構ハードルが高いのかも。

今はとにかく早く動くものを作った方が勝ちって感じだから、
HDLでの検証なんてすっ飛ばしてタイミングレポートだけ見て
オッケーで突っ走るんじゃね？

「速く」じゃないからな・・・念のため

>>86
これの等価性検証ってど〜よ？
http://www.necel.com/ja/channel/pdf/2003/an0716_s2.pdf
UnTimeとCycleAccurateまたいでるので難しそう

日経エレクトロニクスのサイトを見たら、各社からSystemC入力ツールが結構発表されているのね。

枯れ木も山の賑わい・・・てことはないよな。

C++ってC#の言語仕様を知ってしまうとやっぱり古いもんなぁと思ってしまう。
出来上がったバイナリの話じゃないよ。特にOOの文法が・・・
そのC++をベースにしてHDL作ってもどうよ？って感じがする。
出来上がる合成結果も今一で、ソフトの世界でもC++だと生産性が向上
しないことは明らかになったとなるとシノプも見切るわな。

>>91
抽象度生産性云々ではないと思う。
シノプが見切ったのは、儲からないから

そんな名前の恋人も……

>>93
デブオタ的外見云々では無いと思う。
忍が見切ったのは、稼ぎがないから

・・・・＿|￣|○

ageて迄書くことかよ。
つまらん。

そんなシノブに誰がした〜

ConvergenSC

>>97 << SystemC+C++

>>98
ConvergenSCはSystemC入力じゃなかったっけ？

>>99　入力と〜解析昨日

忍もケイデンスも検証ツールはそろえてきてるんだし、
HDLユーザーがSystemCを始めるならモデリングから入るのがベストではないか、と思う。

>>92
生産性が高くないからユーザが選択しない->シノプが儲からないんだよ。

乱立で何が生き残るかわからんし現在移行するメリットなしと見たのだろう。
HDLが出来てきたときほどのインパクトはない、パラダイムシフトも起こっていないし
起こす必要も無いとなると消極的にもなるわ。

SystemC は C++ 上に実装されているというより C++ の STL 上に実装されて
いると言うべきです。

現在、広く使われている言語のうちで、C++/STL の記述能力がダントツに優れ
ています。Template による抽象データ構造を使えるからです。C++ 自体の糞
仕様を STL は十二分に補っています。(Java や C# でも template を導入す
るとの話がありますが、実用段階にはありません。)

記述能力に優る SystemC および STL の問題点は、その抽象性にあります。ユ
ーザーに平均以上の抽象的思考能力を要求します。C++/STL を使いこなしてい
るユーザーは C++ ユーザーの一割にも満たないでしょう。STL を使って実装
されている SystemC の普及が阻害されるとしたら、その抽象性ゆえの難しさ
だと思います。数学でいえば、N 次元空間での直行・回転などをイメージして
ベクトルや行列を使いこなせる程度の抽象的思考能力が必要だと思います。

さて LSI の設計者は、一般の設計者より抽象的思考の面で優れていると思い
ます。設計ミスが発生したときのロスが大きいので、意識的に頭の良い連中を
投入しているはずです。

以上のことを前提にすると LSI 設計分野で SystemC が主流からはずれつつあ
るとしたら、LSI 設計者の能力が低いことが原因だとも言えます。STL を使い
こなせるユーザーにとって、現在のところ SystemC が最も記述力のある回路・
モデル・仕様記述言語だからです。

本当に LSI の設計者の知的レベルは低いのでしょうか？行列・ベクタも適切
に理解できていないような設計者が多数派なのでしょうか？ そうは思いたく
ないのですが。

日本語から学び直すことをお勧めします。

>>104
んで、けっきょく何を言いたい？

>>106
LSI設計者の能力が低い

>>106
納得。104はシノプの営業さんだったんだね。

忍はSystemCを捨てたから、彫る手の営業さんでしょ。

>>104
今のところ知的レベル云々よりも、
Cから石にする言語環境的腕力が必要かと。。。

Cから石にできるという幻想さえ捨ててしまえば、SystemCは
結構便利だと思うけどね。
テストベンチ書くのは楽でいい。

>>104
SystemCがSTL上に実装って、STLが何の略か解っているのでしょうか。
どうせならboost上に実装してくれればいいのに。

確かにSystemCとかTestBuilderとか、あたかも言語仕様を拡張できるような
C++ templateの自由度には関心するけど。
最終的に実行形式に落ちれば良いだけの、"プログラミング言語 C++"とは違い、
合成やら形式検証やら色んなツールに喰われるHDLとしての役割を考えると、
その自由度は凶器になると思う。
STLをフル活用したSystemC記述を、シミュレータ以外のEDAはまともに扱えるのだろうか。

>>111
たしかに素のVerilog使うよりはよさげだけど
石の部分と同じ言語を使えないんなら、他のHVLに対するメリットは薄そう。

ところでプライムゲートが大々的に紹介していた自社Cコンパイラはどうなったか
知っている人いないかい？

うちの部署に売り込み来ていたネーチャンは年食っていたがそれなりにキレイだ
ったが．

似たようなふゅちゃーでざいん
って会社あったが、あれどうなったんだ？？
最近みないんだが。

フューチャーデザインオートメーションはつぶれますた。
今は「礎デザインオートメーション」という会社が資産を引き継いでいます。
ttp://www.ishizue-da.co.jp/info/news_011504.htm

中の人おんなじ

ひげの社長ね

>>104
手順書くしか能のない、ソフト屋ごときが何ほざいてやがる。

>LSI の設計者の知的レベルは低いのでしょうか？行列・ベクタも適切
>に理解できていないような設計者が多数派なのでしょうか？
線形代数どころか、数値演算全般について理解できてないのは、
サービスソフトしか組んだことのないソフト屋なんだよ。 -> それはお前 >>104

馬鹿を無視出来ない奴も同レベルだよ。

これからは手順書くだけでハードができるようになるんだもんね

ハードが生成されるかもしれないが品質は推して知るべしだわな。
論理合成ツール万能論で記述がダサダサでもまともな回路ができると
言い張るなら別だがね。

>>121
ソフト屋ってそういうアフォが多いよ。アセンブラをイメージせずに抽象的なコード書いてる奴
CPUの場合はシビアな速度要求がなければそれで動いてしまうんだが
その感覚でHDL書いて使い物にならん回路こさえるんだよ。

>>122
ポイントはそこだぁね。
アセンブリ→C言語、ゲート→HDL
の10年〜15年遅れで
HDL→C言語
が来る。扱うべき複雑度という観点では、ソフトはハードより10年進んでいる。
ちゃんと動いて、システム全体でみた性能がOKなら、ダサダサでもなんでもOK

HDLは使っても、できあがる回路を意識した書き方をしていないと
デバッグが大変だからね。

> ちゃんと動いて、システム全体でみた性能がOKなら、ダサダサでもなんでもOK

仰る通り。
無駄に労力をかける必要はな部分では手を抜いて解りやすさのみを追求しても良い。

手間と回路品質は二律背反の関係だからどっちを取るかは状況次第。

普段からダサダサコード書いてる奴がポイントポイントで高品質コードを
書けるわけがないと思う。
こういう使い分けができるのは相当技術力のある奴

>>124
>HDLは使っても、できあがる回路を意識した書き方
そうそう、
C動作合成も、出来上がる回路を意識した書きかたが重要なんですが、
コツをつかむのに半年〜かかった。それもツールごとにコツが違うのがシンドイっす

今のところセミナーで現実逃避という利点はかなり実感しているぞ

sharpのbach-cはどうですかね?
使ったことある人います?

>>128
回答でなくてすまんが、国内電気メーカーのツールって社内か特定顧客以外に実績あるの？

三洋がCynthesizerを入れるそうで。
ウチの会社でもCynthesizerを入れようかなんて話がある。
でも、Forteがコケるリスクがまだありそうだなあ。
大手ならともかくウチのような規模の会社があの値段で購入して失敗したら
屋台骨が揺らぎかねん…

>>129
大手がBUGが取ってくれるまで待て

http://www.sony.co.jp/SonyInfo/News/Press/200310/03-041/
がＢＵＧ取ってくれるまでまてない

この記事一年前だな。もうフォルテもバグ取れたかぁ？　代理店がやってた時はらちあかない状態だったけど、本格的に動き出してるね。関心！
BUGなんて規模がでかい会社は気にしないよ。永久に続くから中小は永久にまってても無理かも

>>129
ないです。
ＳｙｓｔｅｍＣ関連の事を調べてると京都大学の研究室の方が出してる
論文の中で Bach-cを使った研究があったので、ここで聞いてみると
意外と使ったことある人いるかも？というすごい曖昧な発想でカキコしました。
すいません。。。

Ｂａｃｈ−Ｃは既に、メンターがシャープと共同で商用化しています。
研究室レベルではオリジナルを使えるけど、企業向けには有料の高いツールとして売っています。
基本的にはANSI-Cだから、ＳystemCリファレンスシミュレータとはつながらないから、只のSystemCではなく有料のＳｙｓｔｅｍＣ（メンター製）で使えるだけ。基本的にＣＡＤメーカはオープンソースを利用したがらないということで盛り上がらないのかもしれない。
シミュレータは只、検証環境も只でビジネス考えると儲からないから、独自なＳystemCをCAD屋さんは考えます。
やはり最終的に合成で儲ける仕組みだったんですね？


http://www.mainichi.co.jp/universalon/clipping/200211/068.html

ばっかもーーん　盛り上がってる　SystemCでググルしてみんさい。
只だから普及するんじゃ！！！
Microsoft Visual C++は飼わないとだめだけど、最小予算でハード作るには今これしかない。
ソースも公開してるから研究室レベルでも拡張できるんじゃ。
初心者にはここ
http://www.geocities.com/systemc_win/

回路になるの？
Simが出来るだけなんて無意味も良いところ。

シミュレーションならCadenceとかのツールで対応できるし、
結局のところ動作合成ツールが普及せんことにはハード展開は難しいよね。
CynthesizerはUntimedレベルのSystemCに対応してくれるのかしらん。

>>136
そんなことないよ。
CPUやバス周りの性能予測、ソフト/ハードウェアの処理切り分けなど、複数の組み合わせの中から最適な物を選ぶのに、シミュレーション速度の速さが役立つ。

ぶっちゃけ、検討さえ終わってしまえば今まで通りRTLで設計しても問題ない。最近のSoCは最初の方式検討が最も重要だよ。

＞検討さえ終わってしまえば今まで通りRTLで設計しても問題ない

RTLで設計するんじゃやっぱり面白くないな。Cでアルゴリズム的に書いた
物がそのまんま落ちてくれるから美味しいんでは？
そうでなくては、まるでC++をCに手動でトランスレートしているような感じだもん。

FPGA等に書いて動かしてみないと面白くも何ともない。

FPGAならやっぱりHandel-Cが一番実績あるだろうな。
一回使ったことがあるけど、感動した。

>>139
もちろん、最終的にはCから直接ゲートレベルまで落とせるようになれば、それに越した事はない。
ただ、現状ではこういった用途しか使いようがないのでは? SimだけでもCの恩恵を受けられる。

特に勉強目的のSimのみと言うのを否定するわけではないけど、
実際に動作させないとなかなか続かないってのが現実だと思うな。
HDLが出てきたとき、も行数制限があるシミュレータで遊べたけど
やっぱり波形を見るだけではすぐ飽きてしまったし。

>142
ずっと上の方にもあるけど、Handel-Cの太古バージョンで
ゲートまで落とせるんだよ・・・・・

C＞HDLってトランスレーションだから悪くはない。

ところでどなたか、デザインウェーブマガジン（今月号）の付録ＣＤのSystemCツール入れた？
入れようと思ったけど、Linux対応版だからだめだった。せっかく自腹で本屋で買ったのに。。

>>146
それ、論理合成できますか？
できるのなら、ちょっと買ってきてためそうかな。
シミュだけだったら要らないけど。

まだ入れてないけど、なんたって只だからな。
Win環境ならSygwin使えばいいんじゃない。これも只
http://www.cygwin.com/ml/cygwin/2001-06/msg00186.html

>>147
http://www.cqpub.co.jp/dwm/Contents/dwm0083.jpg

コーウェアのConvergenSC System Verifierだから検証ツールと思われ。

>>144
LSI設計にはまだ使えないという認識です。

Handel-CというかDKつーるづ持ってまつ。
サクサクうまうま。シミュレータでのデバッグはマルチスレッドな以外、ふつうのCな開発環境みたいな。
一度動いた回路なら10分でマルチクロックドメインにできるのに驚き。
ただ、付属のテキストエディタは欝になるレスポンス。

>>151
金持ち！！

＞146
それ確か普通にサイトからダウンできますよ

>151
確かにＤＫ（Ｈａｎｄｅｌ−Ｃ）はウマウマ。現状ＦＰＧＡ化するならあれが一番
じゃないかな？とにかく漫然と書いてもそれなりに動いてくれるし、
後からスレッド分割してみたりも簡単。
本当にカリカリにチューンしなくてはいけないような用途でもなければ、
サラサラとCで書いてDK通しちゃえばいいやって感じ。

付属のエディタはほとんど使ったことがないな。つか、あの手のって
最低限用意しないと顰蹙だからとオマケで付いてるようなものだしね。

>>153
サイト見たけど、結局ライセンスが必要で期間限定だった。　しかもシミュレータだけ。
デザインウェーーブもなに考えてこんなの付録にするんだろう。まったくセンスないし、わかってないね。
SystemCのツールならOpenSystemCのサイトでいくらでもダウンロードできますよーー。
今欲しいのは、Model-simとかシノのツールでHDL混在シミュレーション環境だよ。
単体のシミュレータで何するの？
まったく！！　ぷんぷん

そいえばケイデンスのツールインザイシブーＳｙｓｔｅｍＣも混在できるよ。
お試し版はないけど、、、金持ちしか利用できないけどね。。
おいらNCのユーザだから、今アップグレード待ち。

ModelSimにしてもIncisiveにしても
SystemCやアサーションはオプションライセンスなのが痛い…

VCSはライセンス追加はなさそうだが（SystemCは追加があるのか？）、
ウチの会社はVHDLが主流だからな（ｗ

ウチの会社はSILOS使ってる。汁箱に食べられちゃったからSystemCの可能性はなくなった。
永久ライセンスで買ってるから、いまさらSystemCにはいけないし。ＯＳＣＩに繋がるらしいけど、
聞くところによるとOSCISystemCも拡張はしないって決まったようだし。
Incisiveは見積もり見たけど、SILOSと桁が二個も違うのでみんなでひっくり返った。
これは、半導体メーカ用ってはっきり言われたよー。もう、Ｔｏｏｌは事Ｘ器屋には手が出ない金額になってきてるね現実は。
SystemCはオープンだから注目だったけど、半導体業界の陰謀？？結局手の出ないＴｏｏｌになってしまった。

マジレス希望
すれ違い？かもしれないけど、ここの人たちSystemC詳しいようなので相談です。
今わたしソニー株式会社のセミコンダクタソリューションズネットワークカンパニー
にものすごく興味がありなんですけど 職種がＳｙｓｔｅｍＣ／Ｃ++によるシステムレベル設計手法開発 の職種
ttp://next.rikunabi.com/rnc/docs/cp_s01800.jsp?rqmt_id=0000850138&__m=1
みんなは、ある人物の一本釣りの広告だから真剣に考えても馬鹿みるっていうけど、どなたかSONYのLSI開発の詳しい事情通いませんか？
CellとかPSXの記事はいくらでも見つかるけど、開発環境はわからなくて面接不安です。
知り合いもこの会社の実態は知らないし。
ちなみに今まで、SpecCでLSI二個作りました。SystemCは勉強中です。

同じIDで何やってるんでしょうか？

ソフト作る場合はC++の実行速度が魅力だけど
HDLのベース言語としていまさらC++？という気がする。
C#見てると言語仕様が古い。
SystemC は普及せずにあぽーんして正解だ罠

コストがあまり関係ないとこで使うんだろうなぁ・・・あるいはFPGA/PLDか。
コストや再利用性を考えるとダサダサってわけにはいかんのよ。

俺には関係ないとこの話かな？

>>104

ソフトとLSI設計の決定的な違いはコスト意識なんだよ。
量産性を考えたときに、６ｍｍ角の大きさに再利用性
も含めて性能の高いものをなるべく入れるわけ。
ま、RTLとかを使っていれば、どこも同じレベルにしか
ならんから、価格競争になっちゃうんで、論理合成だけ
に頼るのは問題だと思うけどね。

>>161
じゃ、C#のコンパイラ作ってくれ。ARMかMIPS用な。作ってくれたら５Myen/Lis・yearで使ってやる。

系伝巣のは、金持ちとか、ソーユー次元じゃアルメ。
更に、カスタムにチップ内レイアウトできて、シミュレーションもできる。
PLD･FPGAは内部は一様のセルをマトリックス上に形成させたセルアレーでできていて、電圧掛けりゃ、回路ができるが、アナログIC・ハイブリッドIC・カスタムIC・カスタムCPUじゃそうは行かない。
PLD･FPGA･ｼｽﾃﾑLSI屋はジョーリュー気取ってる部分があるが、
実は、カスタムの場合、カリューと呼ばれるその後のレイアウト・シュミレーション、マスク層分割作成の方が、遥かにレベルが高かったりする。
シミュレーションで出た遅延を考慮したレイアウトの上に更に、サブストレート層ノイズ･C-MOSスイッチングノイズ･ラッチアップ・ミラー効果防止軽減の為に、ポテンシャルバリヤ層やバックバイアスを設けたり、
パンチスルー改善に、フィールドストップ層を設けたり、アナログのTrならアバランシェ破壊対策にガードリングのMr.ドーナッツが要る。
形状・大きさ、幅、深さ、knowhowの塊だ。

そういう手間暇かける必要のある製品って漏れの扱うような範囲じゃほとんどない。
第一それだけのコストを掛けて作ってもペイできない。

まぁ、アナログでも最近はDSPとかあるし、こーいうのはCでも書けるし、
プログラムアレイのデバイスでもいいと思うけど、
後々の為に、カスタムも、蓄積として、実験的に作ってデータ溜めと居た方がいいんでない甲斐。
アナログだと、ドナーのドーピング量やセルの厚さでかなり半導体としての性質が変わってくるし。
もちろん、C-MOSでも、対集積度、ウェハーによって、各所厚さ・幅・形状やドナー量が決まってくるし、この辺は、半導体メーカとの調整だろうけど。

SystemCのスレですよねここは、カリューの話は難しいのーーーーっ

>168
ママゴト・箱庭・おもちゃチップやっとれ、オニアイだ。

暗いよ
下流＞＞演歌系
上流＞＞ラテン系
大変だけどがんばってくれないと、韓国系に負ける。
ドッチも仲良くね

>>164
>HDLのベース言語として
の意味わかるか？

C#って何ですか？ ＭＳの推奨してる言語のようだけど、初めて聞く。前の議論単にＣ＋の誤変換だと思っていた、俺はアフォ？
Ｃ言語の派生のようだけど。ここの議論とどうかかわるのか？
SpecCとかSyetemCに関係ないと思うんだけどー

>>165
DFMが重要なのは知っているけど、
このスレ的には「だから何？」としか言いようが無い。

http://www.ilink.co.jp/products/impulse/CoDeve.htm

高価なツール買わずに、頭使って仕事しろ！
はうちの事業本部長のお言葉です。
やっと↑を買ってもらいまそた。
23万円のツールさえ高価と思う様な会社です、
いまどきどこでもそうだろうけどね。
連休なのに今日は出だし。
昼飯に戻ってばっくれてる俺はやる気なし。＜＜半導体部門持ってる一応大会社です。
部門はレイアウトツール（国産）のばか高ツール買って、
セット部門は23万円＜こんなもんです。現実は
impulseはほとんどザイリンクス専用です。でも使えますね。

でＳｙｓｔｅｍＣなんだけど。
講習会受けたけど、結論＝SystemCはやはり半導体部門のツールです。
理由＝まともに使えるようにするには高い！EDAビジネスです。
ＦＰＧＡのパスは一応あるようだけど、マーケ的にあるだけ。
うちの会社もそうだけど、ＡＳＳＰ待てないんで仕方なく、最近コスト安いＣＰＬＤやＦＰＧＡを使うんであって、
物理検証の厄介さの言い訳はしないで欲しい。
ASICはなるほど最近は300万ゲート以上ARMコア入れられると、
SystemC使ってるから早く検証に入れるって、当社の競合3rdティア国内半導体が説明にきたけど、
月産何万台売れるもの作ってると思ってんのか？よく調べて売り込むべし。
SoCとかワンチップとかの議論になると必ずSystemCの話が飛び出すから、
アメリカかぶれ上流のマネージャは勘違いするから困る。っていってもFPGA,CPLDは米国産だけどね。
それの製造を当社のＦＡＢ使ってやってるから笑い。
もうSystemCあぼーん。
俺の部門、全員がケイデンス使える環境になったのはいいけど、Verilogはなし。
Orcadだけ。このNetListからＳｙｓｔｅｍＣ出せないか馬鹿がいってるけど、どーしよ

ハード屋は、ブロック図、ステート図、タイミングチャートを見て、論理合成の結果を見て、実装に近い形で動きを判断できる。
ソフト屋は、ソースプログラムで判断する。
といったとこか・・・違いは。
論理合成の結果の莫大な数のゲートであっても、ブロック単位ではもちろん、どこがどういう機能をもっているか、すぐに察しは付くけど、ハード屋は。
レジスタのラッチの数の方がコントロールより段違いに多いし、レジスタ・順序回路(カウンタ)・レジスタ・ラッチ・エンコーダ・デコーダ・セレクタ・演算回路・・・どれも単位回路はハード屋は頭に入っている。

＞SoCとかワンチップとかの議論になると必ずSystemCの話が飛び出すから、
＞アメリカかぶれ上流のマネージャは勘違いするから困る。

DAC等の成果発表を見る限り、
米国は日本ほどあまりSystemCが流行っているとは思えないが。

>177
だろうなぁ、実際にプログラムして求めたものと、合成されて吐かれたものに意図しない食い違い(バグ)があった・・・、なーんてことはありそうだ。
印照、亞位美絵夢、元路螺、なんかは何使ってやってるんだろね。

MIPSはVerilogで書かれていた。

ご免、正確には某社のMIPSアーキテクチャのCPUは・・ね

>>179
この発言ってMIPSからライセンス剥奪されないか？

あの手のものだとまずＶＨＤＬでは書かないだろ。

HDL自体、米の軍用規格MILの一種であり、もっと言うと、HDLで設計されたものでないと軍に採用されない。
当然、軍に主要チップメーカのチップが採用されているなら、HDLで書かれたということになる。
まぁ、MENTERのツールなぞを使って、CPUをワイヤード設計していたなら恐れ入谷の・・・だが。
まぁ、8086の頃のキャッシュ無し、複雑なアーキテクチャ無しなら、内部パイプライン・メモリパイプラインバス採用であってもゲートレベルでの設計でも不可能ではないと感じられるが・・・。

>>１８３

VHDLは国防総省のVHSICが始まりだね。そもそも仕様を記述する言語で、
検証や論理合成などは関係がない。Verilogはgatewayがはじめた言語
で検証目的で、これまた論理合成が関係がない。

モトローラでは６８０４０までは回路図設計だし、インテルの４８６も
そうだろう。とは言いつつも、高位MPUは単純な論理合成を使うわけ
じゃなく、システム検証は高位言語だが、LSIはトランジスタから
書いた特殊セルを多用しますよ。

>>183
それを言うなら

"VHDLは"

だろが！

>>176
分類でいうとハードなんだがソースで判断してるなぁ。。
ブロック図なんてしっかり仕様書出す必要があるときだけ後付けで書く。。
頭の中はデータパスとステートマシンでイメージされてるかな。(HDLの場合）

SystemCの時はもちろんクラスで。そのほうが判りやすい。

>>177
IntelがNoC（Netowork On Chip)で使い始めたね。MPP typeの並列処理を
アーキテクチャレベルで解析、オプティマイズしようということらしい。
もともとSystemCは抽象度上げないと効果発揮しないから、単体IPの抽象度
をあげて、アーキテクチャを含めたシステムレベルの解析しようという
意図からは妥当な着想ですね。立ち上がりは日本のシステム・ベンダーが
早かったけど、ここ2，3年で米国が追い越すと見ている。
相変わらずコンサーバティブな日本の半導体ベンダーがシステム・ベンダーの
動き読めてないのが、元凶。モトローラ、TIもシルバーなSystemCのライブラリ
を構築中。その動きに応じて、日本以外のアジアのベンダーも着実に・・・
相変わらず、日本だけがファブ重視で、システムレベルでのプラットフォーム
作り、IP準備に手付かずの状態。
くだらん延命合併とかしてないで、半分ぐらいつぶれちまえ。

>>187

アプリがないんじゃないの？コストに見合うシステムがさ。
民生なんてじゃ、合わないと思うよ。

>187
言い意味での「ヲタ」がいなくなったからだろうね
つか、そろそろ半導体だの電気・電子産業全般から足を洗う準備をしても
いいんじゃねぇかとも思うけどな。

>>188
そのプロジェクトは64chipでのArchの最適化らしい。で、アプリは
4-64ぐらいなんだろね。最終的にSoCにするということなので、指摘
通り量産しなきゃ採算合わないし、コンシューマにそんなもの必要と
するアプリあんのかって話になるが・・・それは俺もよく分からないよ。
ただcore chipがそうとうsimpleなものなのは確かだろうね。bus arch
固定でcore chipをASIP likeにアプリに対応させる。
まあ、今のコンシューマ向けアプリの課題である「性能と柔軟性」を
HWとSWでどう最適化するか、のひとつの解を求めているんじゃない
かと、まあ個人的な推測です。
dynamic reconfigureble あたりはまだ当分先のようだしなぁ・・・

誰かSystemCをBorlandC++Builder6で使ってるひといませんか
無料バージョンのVer5.51ではコンパイルできたけど5.6はエラーが出てコンパイルできないんです．
ここにソースがあったので試してみたんですが．
http://www.geocities.com/systemc_win/

論理シミュレータだけあっても合成ツールなきゃ使い物にならんやんけ！
あとgccでそのままコンパイルできるんだからそれ使え。

合成ツールが無いと使い物にならないという発想では、所詮システム
レベルのソリューションは使いこなせないな。それより、抽象度の方が
問題だ。PAレベルでsystemC使って何がうれしいかと。

でも、合成まで行ってくれないと、ワクワク感が無いよね。
なんか美味しそうな餌を見せられながらおあずけされてるみたいだ。

ここには、誰もＥＳＬをわかっている人間はいないようです。
さよなら。　二度とここにはこない。合成の話をしてるようじゃ話にならないし、まじめな話を期待して全部読んだけど、
レベル低すぎ。２ｃｈ以外のところに新しいスレッド作るから今度はまともな議論しましょ　わかる人にはわかる場所です。

>>195
書き込まなくて良い。
黙って消えられないのはお前が厨だから。

オマケ
半角を巧く使えない奴に、まともな論客が居たためしがない。

>>197
そのうちわかるよ、君にも　さいなら　おやすみ
スレッド終了

>>198
笑わせるな。

誰か
>>191
よろ

せめてエラーメッセージを載せることとか考えないのだろうか・・・

ありがとうございました！

おかげで解決しました．

広告の裏にでも書いてろ

解決したし、すごい事がわかった。
教えてあげない。

これからはSpecC

SpecC

SPECC

SpecCで何なるんだ?　ｗ

システィナC











は違うか

どっかにも書いてあったけど、
これ絶対「小雪さん、小雪さん、SystemCのことおしえて下さい」
って聞こえるって！

http://www.daiichipharm.co.jp/health/cf/cystina.html

カーセックスを盗撮された女に興味なし

SystemC＆SystemVerilogデザイン・ワークショップ

http://it.cqpub.co.jp/tse/DW200410/

>>212
ケーデンスのSystemCは実はどこかのOEMらしい。イノテックの営業から聞いた。
じゃ会場であいましょう

>>213
#?

CadenceのSystemCのカーネルはCoWareのものだと思ったが・・・
CoWareの環境で作ったモデルは、結果を含め完全互換という意味らしい。

>>215
Modelsimとメンターの関係と同じだと思っていたけど、
先月Modelsiimはsingle-kernelでトライリンガルのシミュレータを独自で開発し終わった。
Cadenceは外部調達する理由は？
ModelsimとCowareは互換性はないみたいだし。　CoWareはトライリンガルどころか、
SystemCとN2Cのシミュレータだから、結局のところSystemVerilogとは共存しない？
VerilogとVHDL資産を持っている限り、
MentorっていうかModelsimかCadenceを最終的に揃える事になるのかな？
各社の方針見たくて申し込んだけど、今年はCoWare出ないみたいだしね。
SystemC＆SystemVerilogってテーマだと両方やってないとだめだからなんだろう.......

ごめん
Coware協賛していないだけで、展示はしてるようだ

個人的な見解だが、SysteｍVerilogのように過去のレガシーに留まって
いる限り、上位設計の発展は当分来ないような気がするな。SoCなんかは
これからHWよりSWの開発の方が重要になってくるだろうから、SW開発の
Platformをいかに早く開発するかが、死活問題のような気がする。
その戦略をどのEDAベンダーが採用して、提案できるだろうかだろうな。

>>216
>SW開発のPlatformをいかに早く開発するかが、死活問題のような気がする。
>その戦略をどのEDAベンダーが採用して、提案できるだろうかだろうな。

大手セットメーカーだとEDAベンダーに頼らずプラットフォームを立ち上げているよね。
最近だと松下だったかな。
CadenceやSynopsysはここ最近DFM関連にご執心なのでしばらく先になりそう。

SystemCをdesign compiler Version2001.08でverilogに落としているのですが、
SystemCでinout宣言したポートが出力されたverilogファイルではoutputになっていしまいます。
解決策がわかる方がいらっしゃいましたら教えてください。
よろしくおねがいします。

>>220
単に output としてしか使ってないんから最適化されたんじゃないの？

>>221
ありがとうございます。
.readでそのポートを読んではいるんですけど、これではinputとして使っていないということでしょうか？
すみません、よくわかっていないので変な質問かもしれません。

SystemC は Verilogへのトランスレータをフリーで用意すれば裾野がぐーんと広がるんだけど・・・

しかし相変わらず抽象度を上げずにSystemCを利用している連中が
いるんだねぇ・・・やっぱり日本はアメリカに追い越されちゃうのね。

>>224
お前のような糞ソフト屋はツールに頼らずにまともな回路の設計なんてできないだろうしな！

そんな設計はアフォでもできるんだよ。

>>225
どうしたの？図星？ｗ

既に上の方で結論が出てる問題を蒸し返して煽りを入れるのは何故か？

>>227
すいません。純粋に日本の現状を憂いてしまい、つい・・・

>223
フリーで用意した奴には何の見返りもないじゃん
利用する側がありがたや、ありがたや・・ってただ乗りして
金儲けるだけ

抽象度を上げればゲート数が増えるからFPGA屋はもうかるじゃん。

製品規格を満たしていて、そこそこの性能がでて、それで終わりが許されるのなら
抽象度を上げまくればいい。

チューニングと無縁で居られる管理クラスは楽で良いってことさ。

>>224
抽象度を上げるのは結構だが切り分けたHW部分はどうやって落とし込むの？
人手でやるとしたらあまりスマートじゃないよね。

>230
SystemC屋ってFPGA屋じゃねぇだろ？

FPGA屋としては現状Verilog／VHDLだけでも市場ニーズ
には十分応えているんだし、あえてSystemCに手を出す
理由がない

抽象度を上げてなにをするかがやっぱり分かってないんだね。
おもちゃの高位合成に群がるアホな日本人が多いわけだ。
もう、日本ダメポ。

＞抽象度を上げてなにをするかがやっぱり分かってないんだね。

じゃ、何するか教えてくれ

システム全体をSWで動作できる実行モジュールあったら
何ができるか、考えてみろよ。それくらい頭使え。

>>234
違う

頭の悪いお前一人がもう駄目

だいたい前処理＋CPUコアで事足りてしまったりするしな。
結局「おもしれぇ！」で飛びつけるだけのカネと時間とフットワーク
の良さを兼ね備えている所はそうそうない。
何事もそうだけど右見て左見てみんな使っていて、しかも
無料ないし無料同然で手に入らないと使わない／使えない

そんなもんさ

SystemC自体もう終わってるのに何を盛り上がってるの？

何かマイナス意見ばっかだね。。。学生だとただで使えたりするので
多分居ると思うんだけど動作合成ツールつかってる人います?
Synopsys社のCSSとか。どれくらいの規模の回路で使ってるとか
FPGAで動作できたとかの詳細まで教えてくれたら嬉しいです。
ここは見てないかなー?

>>237
何の知識もないのが、バレバレ・・・ちゃんと反論するならすれば？

>>234
システムも半導体もそろそろどっか倒産したり、本格的な統合する時期
だと思うよ。大体おんなじことやってるような会社が多すぎるからね。
切羽詰ってからじゃないとやらないような状況だから、仕方ないんだよ。
半導体で2社、システム系で4社ぐらいになってから、日本は勝負だぞ。
まだまだあきらめるには早い。

ここプロの人ばっかなの?俺学校で勉強してるんだけど
正直こんな業界で定年まで食える自身もないしプロはすげーなー
とか思ったりしてます。でも若いうちは冒険してみたかったりもする今日この頃

>>243
この分野もしかしたら一番動きが早い業界かもしれないね。ここで議論されてる
言語も設計手法もインプリやら、いろんな要素でやらなきゃならないこと変わるから
ねぇ。ある意味楽しいといえるかもしれないけど・・・

>>243
ここにはプロは来ないと思う。
お金とっている人＝プロだから。
只で情報は出さない。
いえることはSystemCが扱う領域は半導体設計のせいぜい2％以下って事。
大半の普通のハード設計者には関係のない技術だから、知識として知っていればそれでいいんじゃない。
ハード設計目指すなら、HDLが頂点だからね。
SystemCはその上のシステムLSIの領域でほとんどのハード設計と言われる人が関係のないエリアです。

>>243
今学生ならHDL主体の仕事だけには就職しないようにね。

>>243
規模という意味でソフトは10年先行ってるので、ソフト開発が
直面している問題を参考に設計を勉強するのも良いんでねーか？
だが、食えるかどうかは別の才能。冒険は死なない程度で。

>>246
それは言えてるな。
自分の専門分野の開発でASIC起こすのにどうしてもHDLと付き合う羽目(テストデータ用意したりね)になったっていうならいいけど。
分野に関係なくASIC起こすことがメインの仕事っていうのはたんなる下請けにすぎんからな。

>>245
>ここにはプロは来ないと思う。
そんなことはない。

>>245以外はみんなプロという罠だったりして。
自分はCeloxicaのDKをつかっています。
実装結果を見ながらアルゴリズムレベルの検討をするには非常に強力なツールと思います。

>CeloxicaのDKをつかっています
どんなツールか説明してよ。
実装結果を見ながらアルゴリズムをいじりだすと収束しないように思うからね。

vhdlとかって別にロジック分からない人も組めますよね
systemcも同じく
そしたら簡単に記述できそうなsystemcが効率よさそうに思うんですがそんなことないんですかね？

>250
DKはCベース（C++ベースじゃない）で、VHDLかVerilog
のコードを吐く。
Cの１行が１クロックで処理されるように生成する。
複数行を同時実行させるにはpar{}でくくる。
par{}でくくられた中で一番遅いものが終了してから
par{}ブロックの次の行に行く。
関数コールとかは、基本的にGo-Done式で生成される。

だから・・例えば、重い式はユーザ側で複数行に分けて
処理するように書いて、par{}してやるとパイプライン化し
たみたいになる。

Cを使っている人にはとっつきやすいみたいだね。
DesignWaveでブロック崩しとかワイヤーフレーム３D
グラフィックなんかやらせていたよ。１，２日くらいで書
けたってさ。

生成されたHDLは随分酷い物になってることが容易に想像出来るなぁ

バージョンUPとともにきれいな方向には向かってはいるようです。
（昔HDLから生成されたゲートも醜かった。。。）
も一つメリットとしては、醜くてもHDL製造という観点での品質がそろうという点かいな。
もちろん職人さんのHDLも必要ではあるが、生産が追いつかない。

一つの大きな問題は、CのソースをリコンパイルするとHDLが大幅に変わってしまうから
結局HDLを触ることが出来ないと言うジレンマ。

うちではDKで生成したHDLをSimplifyにかけているけど、出てくるNetlistはけっこうまともだよ。
分野によっては、アルゴリズムを変えずにHDLを手直しして改善する分よりも、アルゴリズムの改良による
効率改善のほうが勝っていることもあるかもね。

>>256
それはsimplifyが優秀なのだとおもわれ

Cベースの記述でまともなNetlistが出てくるのならなんでもいいかと。
DK+Simplify+Amplifyはけっこう気に入っている組み合わせです。

最終回路の種類、回路の規模等々、制約はあるにしてもインプリフローが確立
されているということは、評価されてもいいのではないかな。
これがHW-SW分割し、SoCのような大規模なシステムに適用できるような方向に
拡張できるのか、がメジャーになれるかどうかの境目だろうね。
ところで、どの程度のアルゴリズムに適用可能なのか、興味あるなぁ。

>>252
わざわざ教えてくれてありがと。
DWの記事は俺も読んで興味持ってたんだけどすっかり名前を忘れてたmOm
実際抽象度上げるだけならC++ベースである必要は全くなくてCベースでいいように思う。
アルゴリズムとして第3者に伝えるのはC++よりCの方がずっとわかりやすいみたいだしね。
それと
FPGA/LSIに乗せる規模はCで書ける規模でいいんじゃないかと思うよ。多分銀行のオンラインシステムを
HDLで全て書くことなんてないように思う。
ところでいくらで買えるの？

今調べてみてわかったHandel-Cなのね。
名称変更したの？

Cを拡張してハード向きにした言語の名前がHandel−Cで、
統合環境のソフトウェア一式がDKって感じかな？

>>255
その点でC合成の方がプレッシャーは高いっすね（アルミ変更とか超能力が必要）
>>259
非同期物は難しいですね
マルチクロックは最近なんとかなりつつある？

HDLにしても、一度回路が確定した後から見つかったバグで良い幅に回路が
かわって大変なことがある・・・。

マルチクロックは最近なんとかなりつつある？

DKはクロックの違うドメイン間の接続はチャンネルを使えという
仕様だったと思うけど、ごく普通にできたんじゃないかな？

ユーザの方DKのどのバージョン使ってるの？

そのためのデュアルポートRAMなのでは？
それ以外の解決策って・・・

ふつうにハンドシェイク。
DKはそういう回路も生成します。

DK2.0って使える？3.0出てるみたいだけど

漏れはDK2しか使ったことないから3.0はわからん。

ここの住人にくらべたら低レベルなので今まで書き込みしなかったけど
レスが付かないので書き込みしてみるテスト。

大学でSystemCについて勉強してるんだけど、このまえ
「SystemCは抽象的な表現がC++を使っているぶん設計、特にビヘイビアモデル
については、他のCベースの言語と比べて便利なのではないか?またビヘイビア
を特にアンタイムドで記述した場合、それから動作合成可能なモデルまでの
コーディングにビヘイビアで使った記述も使えるわけだし効率も良いのではな
いか?」
みたいな事を教授に聴いてみたら、「それはそうだけど、みんながC++の
機能をうまく使えてるわけではないし、実際の開発に携わってる人、会社で
思想(設計方法などの)が変わってくるから、それについて議論するのは意味が
無い」みたいな返事が返って来た。それはそうかもしれんけど意味が無い
議論かなぁ。
底辺大学生の低レベルな書き込みすまんですが、御意見承りたいです。

訂正。他多々変なところはあるけど見逃してくだちい
>SystemCはC++をつかっていて、抽象的な表現もできるし、特にビヘイビアモデル
>については、他のCベースの言語と比べて便利なのではないか?

>>271
HDL の、そもそもの存在意義に議論の価値があるかどうか

>>271
その教授に
"お前はC++の機能をうまく使えて、かつ、実際の開発に携わった経験があるのか？"
と聞きたいのだが。。。

最後までビヘイビアで済ませてた部分が開発のネックになるんじゃね?

つまるところ合成ツールのでき次第でセンセイ方の能書きは木の葉のように揺れ・・・

>>271
なんだかその教授まずいね。未来は若い君の肩にかかっているよ。どんどん議論してくれ。
それはさておき、SystemCの良いところは、無料で、C++の機能やスレッドを使いこなさなくても、
時間とbit概念を表現できるようにしたことで、ハード関係のC言語人口を増やしたこと。
良くない（？）ところは、無料なので、EDAベンダとしてはシミュレーション単体では儲からない
ので根性がはいらない。合成ツールも同時使用数が少ないので、たくさん売れない。
そのためだからか、議論がHDLのときに比べてなんだか歪んでいる感じがするところか？

>それから動作合成可能なモデルまでのコーディングにビヘイビアで使った記述も使えるわけだし

>それから動作合成可能なモデルまでのコーディングにビヘイビアで使った記述も使えるわけだし
ここはなかなかむずかしい

http://standards.ieee.org/announcements/pr_1666.html
ついにIEEE1666というお墨付きが付きましたね
これで、EDA企業も積極的になるんじゃないかな。
合成ツールが出てくると昔のDCの様に一気に普及となるんだけど
でも、一般化には4年はかかると思う　何も書籍が特に日本語が出てなかったからね。
これで、教授の皆様も教科書書きやすくなるから。変な議論はなくなるね
高抽象化は理解するのに、教授先生も脳みそをリセットしないと駄目だから

抽象度を上げたときに何が難しいかって、モジュールの動作記述
ではなくて、APIでのモジュール間のコミュニケーション記述だって、
知ってる人はどれくらいいるのだろうか・・・

IEEEがスペック作るのは勝手
それがビジネスとして成功するか否かは全く別の問題
いまさらソフトウェア言語としてさえ生産性の低いC++をHDLに
積極的に取り入れる意味も無ければ、時期も逸した。
今後はポストC++をベースにしたHDLに期待だな。

もひとつ付け加えると、
ソフトウェア言語ではCという普及した言語が既にあって、
それをベースに生産性の向上を目指してC++なんていうつぎはぎ言語を無理して使ってきたし、
それなりの意味もあったわけだが、
もともとC言語設計の下地のないHDLにC++ベースのSystemCを導入するメリットは希薄この上ない。

>280
確かにまだインターコネクトの重要さに気が付くレベルの人、それほど多くないから281 282のような煽りがでてくるんじゃないかな。
だから標準化が必要なのです。標準化によって各々のモジュールの切り口がOCPなりAXIなりに基準化すれば、コミュニケーション記述も特に難しくなくなることを期待します。
ビジネスとして成功するには、スペックをパブリックにする必要がある事はいまさら議論しないほうが頭悪い事がばれませんよ。
ひとつ付け加えると、MSTの例を出すまでもなく、世の中技術的に優れたものが普及するわけではないの知ってるでしょ。
設計言語も同じで、今後普及する言語が何かをよく見極めないと又痛い目にあう。
漏れは完全にあきらめて、皆が使うものを文句言わずに積極的に使いこなす。
OSCIからIEEEに標準化が移ったって事だから、ビジネスの流れになってきたんだと思う。
アメリカの標準化団体はビジネス”しか”考えてないよ。ただしアメリカが儲かるビジネスだけどね

>設計言語も同じで、今後普及する言語が何かをよく見極めないと又痛い目にあう。
>漏れは完全にあきらめて、皆が使うものを文句言わずに積極的に使いこなす。

ここには同意。EDA関係は大多数が使っているものが結局残るからね。
これが大前提で、標準化云々はそのための一つの手段に過ぎないから
あまりそこに拘らない方がいいと思う。

SystemCに関してはもう少し細かい設計フローに関する情報が欲しいな。
その点で、今月のDesignWave誌のUMLと絡めた話は結構参考になった。

280
>>283
まあ、全面的に賛成だな。281,282は実はたいした問題じゃないと思うよ。
特にOCPに関してはきちっと標準化して欲しいね。おそらく、バス・コミュニケーション
だろうからなぁ、ネックは。ここが標準化させれば、抽象度高くても共通
IPが普及する可能性あるしな・・・ここでビジネスが起これば、おそらく
主流になるだろうね。

>>284
SystemCの設計フローが確立しない理由は、ひとつにはユーザが過剰に
SystemCに期待してきた背景があるよね。まあ、最近はそれでも現実的な
フローに理解を示す状況ができてきたかな、という気はしないでもないが・・・

>ここが標準化させれば、抽象度高くても共通　（誤

標準化はされてんだな。すまそ。283の基準化が正確か・・
ということで、細かいが訂正。

>ここが基準化させれば、抽象度高くても共通　（正

IEEEといっても、P966のような運命を辿ったものもあったわけで・・・
P1666とP1800の戦いか。DCがSystemVerilogになってしまった
のがちょいとひっかかる気がするけども

漏れはいまのところHandel-Cしか使ってないけど、
（そういう意味では>282の言う下地がある状態か）
ゴソゴソ書いているとカプセル化にしても多態性にしても、
インスタンスにしても、継承／多重継承にしても
ソフト屋より、ハード屋さん向きな概念という感じ。
（多重継承なんて要するにマルチチップモジュールだべ？とか・・・違うか？）
使い始めれば便利そうな気はする。

>>273
たぶん解らなくなるから漏れが訂正。
HDLの議論としてSystemCを眺めると色々文句でるのは解ります。
ハードウエア記述言語はHDLって言いますが、Verilog-HDLやVHDLさらにSystemVerilogの事をいいます。

SystemC あるいはIEEE1666は,HDLではなくSDLであると明確に定義してます。
この三文字は飽きたからどうでもいいんだけど、、、

なんだっけ？　
そうそう、SystemCはシステム記述の言語として成り立っていますからハード記述の言語ではありませんね。

勿論HW(SystemLSI)を設計するための言語だけど、HDLを理解する視点と完全に頭を切り替えないと、
絶対にsystemLSIの設計の難しさの本質は理解できないな。
実際の設計現場では、
SystemC以外の解決策は見つからなかったから標準化を急いで、
環境（ビジネスとしてのEDA)が整うのを期待している。
抽象度の議論はOSCIでは既に終わっていて、
HDLでも抽象度はいくらでも上げられる事も理解のうえでSDLを考えましょう。

わかんないなぁ・。。どうなるか。systemc自体は消えていくような予感が
するけどさ。ソフト寄りで使用するC（C++)とハードよりのC（C++）とsystemVerilog
の収斂するような気がする、しばらくはだけど。俺自体はどれが良いとかじゃ
なくて、業界の向きとか仕事として考えるとだけどさ。

FPGAを使って産業向けなら良いけど、LSIだと余程の市場か製品じゃないと
最新プロセスではペイはしないから、業界そのものがどうなのか考えちゃうな。

なんたって、0.09um以下だとマスク代だけで1億円を越えるからね・・・

間違いなくSystemCは消えるな。いいだしっぺが投げ出して言語を一体誰が推進するのさ。

>SystemC以外の解決策は見つからなかったから標準化を急いで、
>環境（ビジネスとしてのEDA)が整うのを期待している。
整う前に既存のHDLベースなり、非C++ベースのシステム記述言語のEDAツールが
普及してるだろね。今何が何でもSystemC使わなきゃならん奴は極めて限られる。

>勿論HW(SystemLSI)を設計するための言語だけど、HDLを理解する視点と完全に頭を切り替えないと、
俯瞰してないで、どう切り替えるか説明してくれよ。
君は理解してて、それを明確に説明できるだろうからさ。
説明できないのは結局わかってないことの証明

俯瞰なんて難しい単語使っていらいらしないでください。
OSCIのホームページとそして古いけど、
SystemC考えた本人の以下の説明を読んでください。
でも視点と頭切り替えてないと、脳みそが迷子になります。
ポイントはHDLはハードウエアの動作記述の言語であるに対し、
SDLはシステムのすべてを記述できるということです。

さらに、重要なのは今の一連の標準化作業です。IP,Bus,CPU,SWなどベンダーは間違いなく環境を用意します。
標準に合わせないと、ベンダーは何でもかんでも用意しないといけないので、経済的に限界が来てしまいます。
DCのライブラリをどんなに苦労してベンダが作ったかはそれが標準だからです。
これが分からないと
>整う前に既存のHDLベースなり、非C++ベースのシステム記述言語のEDAツールが
普及してるだろね。今何が何でもSystemC使わなきゃならん奴は極めて限られる。
という事を言い出したりします。
ちなみにHDLは普及しまくってます。
非C++ベースのシステム記述言語のEDAツールの会社はほぼ全社なくなりました。

今の設計にはHDLで勿論十分だと思う。
でも、きわめて限られた設計者は,
来年再来年の設計を今始めています
明日の設計には、昨日までの古い手法は使えないのが最先端LSI開発者考えです。

これで答えにはなってないと思いますが、とりあえず説明はしました。
あなたが理解したかどうかは分かりませんが、
理解している人も30人はいるんじゃないかな。

ttp://www.synopsys.co.jp/products/systemc/

うーん、なるほどねぇ・・でも「最先端LSI」とは何を指すのか、最近はわかんないよ。
ぶっちゃけ、ARMやDSPなどの既存コアにMPEGだなんだカンダと詰め込んで
半年作業でLSIを上げれば、最先端LSIではあるけど、傍目にはLSIというより、
ボードに乗ってるLSIをワンチップ化しましたということじゃない？

それって、仕事だろうとは思うけど、技術としては残んないって感じ
がするなぁ・・・

標準化なんていうより、先に広がったほうが勝ちじゃないかな？遅れた
ほうが標準化を言っているんじゃないかな？systemcも（XXONも？）・・

>>292
>ARMやDSPなどの既存コアにMPEGだなんだカンダと詰め込んで
>半年作業でLSIを上げれば、最先端LSIではあるけど、傍目にはLSIというより、
>ボードに乗ってるLSIをワンチップ化しましたということじゃない？
その通りです。
デープサブミクロンになってから、何をぶち込めばいいかって話で暫くはメモリーがんがん入れてたけど、
これじゃいけねぇって　その辺にあるもの全部詰め込んだら、なるほど入るねーー
ってことになって、まだまだ余裕があるからCPUも何個か入れてDSPも突っ込んで、
インターコネクトにAXI使おうかって発想です。
そうすると、その詰め込むものが一定の基準やら規格に沿ったのでないと、
繋がるかどうかさえ分からないという問題にぶち当たったてわけです。

どうでもいいけど、いちいち上げてるけどなんで？
そんなに発言を第三者に誇示したいの？それとも下げ方知らない？

君が自分で認識してるように
HDL設計からどういう風に頭を切り替えるか全く不明瞭だな。
何の説明もできてない。これを説明とは言わない。

あと、システム記述を主張したいようだけど、VHDLだってシステム記述言語だぜ。
RTL記述はVHDLのサブセットにしか過ぎん。
要は抽象度とソフトウェア言語であった生産性の話だろ?

>http://www.synopsys.co.jp/products/systemc/
最後に手を引いたシノプシスを挙げてたんじゃ何の説得力もないわな。

つーか君、実際設計にタッチしてる？
>非C++ベースのシステム記述言語のEDAツールの会社はほぼ全社なくなりました。
はぁ？

>>294
消えろ、おまえ見苦しい
充分 age るに値する内容あるぜ
もっともそうでなくても age る理由をあんたに説明する必要などない

シノプシスに手を引かれてなければもう少し説得力あるんだがな

というわけでsage

上げてまでやる見苦しい喧嘩をこれ以上続けることがないように。

>>296
それは必ずしも研究者の本意ではなかったんじゃないか？　上客・・・いや何でもない

そんな妄想していても仕方ないよ。
結果的にシノプシスは手を引いてSystemVerilogに
回った。IEEE

>>295,298 ID:n78KSPzh
アホかお前。それが上げるに値する内容か？
上げるとお前のようなカスが集まってくるから上げるなつってんだよ。

ありゃ・・途中で書き込んでしまった。
ところで、IEEE P1800はなの？

>>300
消えろといったはず
情報を提供するでなし、人の話とかみ合うでなし、空疎なスクロールは迷惑だ

>>302

>情報を提供するでなし、人の話とかみ合うでなし、空疎なスクロールは迷惑だ
自己紹介か？
下らん情報でいちいち上げたおかげお前のような糞が出てきたわけだ。

いつまでやるんですか？

続けるんなら厨房板辺りにスレッドを立ててそこでやって下さい。

>>304
それはいきなり喧嘩しかけてきたID:n78KSPzhに言ってくださいな。

喧嘩両成敗

＞A5K9qIYJ
まあ落ちけつ。

>>294
> HDL設計からどういう風に頭を切り替えるか全く不明瞭だな。

この辺、今月のDesignWave誌を読むことをすすめるよ。
（別にCQ出版の回し者じゃないからねｗ）

HDL設計は典型的なウォーターフォールモデルだけど、
オブジェクト指向なSystemCだと、ソフト開発でよく見られるような
モデリング中心のスパイラルモデルに設計フローが変わってくる。

俺はあまり頭がよくないんでオブジェクト指向を学ぼうとしなかったから
内容の理解はほとんどサッパリで具体的に伝えられないのが申し訳ないが
HDL設計とは全く違うなあとは感じた。

全く新規設計でSoCを起こすならこういった手法は有効なのだろうと思う。
ただ、設計資産と市販IPの組み合わせが中心でSoCを作るなら
これをやるよりも最新のHDL検証手法を学んでバグ無しでかつTATを縮める努力したほうがいい。
SystemCのBCAレベルの抽象度でちょこちょこ設計するだけじゃ短期的には時間の無駄とも思える。

大手だと来年再来年の設計を検討する人と、nmレベルのASICのタイミング収束をやる人が
別々にいるから良いけど、俺の会社みたない中小規模はは同じ人が考えなくてはならない。
今みたいに設計手法の変換に差し掛かっている時期はホント、泣けてくるよ。

ちなみに「ボードに乗ってるLSIをワンチップ化しました」的なASIC開発を
軽んずるつもりは毛頭ない。市場の要求に応じて設計･開発することは
大事な仕事と思うから。

>>308　ASIC的な開発手法がメインになっているじゃない？それに開発費が1億円
以上もかかる中でペイするもの・・・　携帯電話、グラフィック、その他向けの
LSIを設計するのがシステムメーカーになっているから、システムLSIとしては
何々向けとはなるけど、今のところ、新規なLSIシステムは見えないなぁ・・・
携帯電話のLSIだって、結局はマイクロコントローラー路線に乗っているだけ
だし・・・しばらくたてば変わるかもしれないけどね。

記述言語はシステム記述とHW記述に分けないと使えない・・っというのは
暗黙の了解としてコストや性能を見合わせるには　という条件が入っている
んだと思うよ。コストも性能も関係なし、システム記述だけでのLSIが出来れば
良いという人もいるけど（研究畑の人たちね）、そういうのは廃れちゃうので
は・・・おもったりします。

進化型プロトタイピングと廃棄型プロトタイピングから説明しないと、
バリバリのHDL屋さんにはESLやSLDは理解しにくい概念だと思うから、
説明はこれ以上はしないほうが無難。

抽象概念によるシステム設計手法がなぜ必要かも説明しても、
HDL屋さんには理解できないし、、
煽るつもりはないんだけど、明日の為の勉強してないよね。
先ずは、シノプシスの記事を読んでみたら！と言いたい。
シノプシスを例に挙げるのは、説得力ないとも思わないし、たぶんあの説明以上の分かりやすい説明はない筈だしね。
ビジネスとして今日はHDLの延長線上にあるSystemVerilogがすぐ金になるからやってるだけで、
明日の技術を捨てたわけじゃないと思うよ。
システム記述からスタートするという設計概念は、痛い目にあって始めて分かるのかもしれない。

＞明日の技術を捨てたわけじゃないと思うよ。

藻前の脳内ではね。そんな「思うよ」なんていう妄想に周囲は
つきあってはいられないって。
現実としてSystemVerilogでシステム記述分野でビジネス的に
金になるということは、すなわち成功し、普及してしまうということ。
むろん、藻前がシノプシスを買収して方針変更をさせるというなら
別だけどね。

それこそ>283にあったような
＞世の中技術的に優れたものが普及するわけではないの知ってるでしょ。
これに該当するんではないかな。

充分つきあってられる話だね

>抽象概念によるシステム設計手法がなぜ必要かも説明しても、
>HDL屋さんには理解できないし、、
こんなもんは誰でも理解してる。
ゲート規模に応じた設計手法が求められてる。
ただしだ、ソフトウェアの設計手法をみてるからC++をベースにしても
極めて近い将来、変更が必要になることを言ってる。
オブジェクト指向を否定する気はさらさらない。
ただし、C++をベースにすること自体大いに問題あると言ってるわけ。
君、C#でプログラミングしたことある？C++に戻ることが嫌になるはずだ。
明日の技術をいうなら今更C++でわざわざ苦労する必要も無いってこった。
べからず集のEffective C++もない時代に散々苦労したから言ってるんだよ。
今後、普及したHDLがベースになるか、C#,Dあたりがベースになるかわからんが
システム記述言語は必要だよ

>システム記述からスタートするという設計概念は、痛い目にあって始めて分かるのかもしれない。
C++で痛い目にあってない奴にはわからんだろうがね。

ID変えてもにじみ出るものは同じだね・・・

お前、邪魔だから死ねよ。
それとだIDは0:00になれば勝手に変わることも知らんのかアホがよ。
糞レス上げるのは止めろ。
精　神　的　カ　タ　ワ　学　生　よ！
食　い　扶　持　稼　げ　る　よ　う　に　な　っ　て　か　ら　ほ　ざ　け　！

>>311
>現実としてSystemVerilogでシステム記述分野でビジネス的に
>金になるということは、すなわち成功し、普及してしまうということ。
そうだ、その通り。普及するでしょう。それとSystemCは関係ない話。
SystemVerilogはVHDLと同じ土俵での議論なんだけどね。
SystemCはSpecCと同じ土俵。
システム設計という言葉の定義が脳内で異なっている事がいまわかった。

ダメージ確認
気が済んだ

>>317
気が済んだよ。
いつも設計現場でこのような人たち相手にしてるから、逆切れする理由も分からなくもないけどね。
自分の理解の範囲超えるとパニックになるのは良くあることでしょ
説明しろというから、丁寧に説明しても分からないと、
意味のない説明だと逆切れして、自分の得意分野で関係ない話始める。

ID:9YFbYvvh & ID:NMW42G1f
お前ら二人いや一人か。
いつも仲良く上げてるなぁ

>いつも設計現場でこのような人たち相手にしてるから、逆切れする理由も分からなくもないけどね。
逆切れの意味わかってるか？
君が社内の問題児だということもよくわかった。

いくら思想的に優れていても、研究レベルでどうであろうと、
現場に理解されないもの、、実用にならないものは広く使われる
ことはないし、商売にもならない。
商売にならないものは廃れていくだけ。
それだけ。

>君、C#でプログラミングしたことある？C++に戻ることが嫌になるはずだ。
今まで聞いたことなかった。
このスレッドで、C#ってワード検索したら、結構出てくるけどみんな同一人物のような..

やっぱりそこでSmallTalkですよ

いやいやEiffelだろ？

いっそのことLISPとか、PROLOGベースも面白いかもしれんな。

ひまわり
織田信長
ってのもあるでよ

ＰＲＯＬＯＧ・・って自動的にバックトラックするシステムか
ガベージコレクションとか言われて使わなくなった回路が
燃やされたりして

漏れPascalが絶対いい大学で習ってたけど、社会にでて出会った事がない
ALGOLもハードには向きそう
Algol-HDLなんてありそうだなー　

>>313
C#は確かにプログラミングが楽と思うよ。でもSystemCで書いてあれば、
ベースをC++から、C#に変えても、ヘッダレベルでかなり吸収できると
思うんで、そういう言語レベルのことは、あまり気にしてない。

やはり、大きく変更を伴う可能性がある、高抽象度のコミュニケーション
（特にバスとの）でしょう。ここが、固まればレガシーが無駄になる可能性が
可能性が少なくなるんで、しきいが下がる可能性は大きい。

>>294
VHDLのことあまり良く知らないんだけど、SW-HW混在できるの？
SW-HW混在記述できて、ある程度自由な切り分けできるんだったら、
VHDLでもいいかもしれないが。もちろん、今のsystemCでSW-HW混在を
うまく処理できるといったら嘘になるが、そちらの方向へ向かうことは
確実で、それができない限り正確な意味でシステム記述言語ではないよね。

シノプシスにすら見放されてしまったSystemCにこだわっても現場は
困るだけだから、次世代に期待〜♪

開発元がなにがなんでも普及させるという強い意欲のない規格が世に支持されるはずもなし〜♪

シノプシスのメッセージをちゃんと読んだほうがいいのではないかな。

シノプシスもケイデンスもSystemVerilogに軸足を移した

そりゃ、一気に変わるより今使ってる環境や思想を流用出来た方が理にかなってる。

御託並べるのはHDL設計でまともな設計をできるようになってからにしようねボクちゃん〜♪

忍も軽電もいい機会だったと思うね。身動き取れなくなる前に抜けた。
PCBエディタ各社がオートルータ機能を声高に主張しなくなったのと同じだね。
規格の布教活動の先陣切ってたわけだから失敗したらはるかに痛手は大きいしね。

C/C++という書き方をしていて、単にC++と言い切れてないってところもﾐｿだよね。
現実にソフト側の記述でもCが圧倒的ということを認めざるを得なかったのだろう

>>336
C にない ++ な書き方は推奨度が低く
C な書き方でほとんど事足りるって言いたいのかな
私はそうは思ってないけど・・・

は？

>>338

×>339

煽りあいかおとしめるかぐらいのレスしかつかねー状態かよ。
頼むから普通にコミュニケーションしてくれ。なんで喧嘩腰なんだ

無意味にageたがるｵｹﾞﾚﾂなのがいるからだろうね

>>342
それ言うとまたキチガイが噛み付いてくるぞ↓

774ワット発電中さん ：04/11/21 18:57:46 ID:n78KSPzh
>>294
消えろ、おまえ見苦しい
充分 age るに値する内容あるぜ
もっともそうでなくても age る理由をあんたに説明する必要などない

ああ、ここもやっぱり2chなんだなぁ

うほっ間違えた。ユルシテ

うほっ間違えた。ユルシテ

正直議論になっていないと思う。SystemCで設計したことない人間が
多すぎる。聞きかじりで話してる人間が多すぎるし、根本的にずれた
こと言ってるやつもいるし、レベル低すぎ。って、ここ２CHか　ｗ

2chだから

みんな、わざとずれてる
本当は専門家だよ

漏れなんか、10年も前からSystemCで配置配線やってるんだぜ

Synopsys社のAart de Geus会長がSystemCとSystemverilogについて含蓄の
あること言っている。何故、SynopsysがSystemCを後回しにしたかが、よく
分る。実際、どういう人間がSystemCを使って、どういう目的で使っているか
ちゃんと、分ってればここ一両日のちゃらんぽらんな議論は起こらないはずだ。

>>350
馬路れすはやめたほうがいいよ
シノプシスとケイデンスはバックエンドで戦ってるから、上流どころじゃないって、
みんな分かってる。
SystemVerilogはもはや検証言語で上流でもないしさ。
上に上がるのには、大変な労力と啓蒙が必要なのはシノプシスが一番知ってる。
今、スタートアップが一杯出てるから、盛り上がったら、有力会社を買収するのがいいと結論
馬路レスしてしまった。

GNUなSystemC to Verilog／VHDLトランスレータ
でもできれば普及するんでは？

後回しね。日進月歩のこの世界、後に回してどうする。
"後に回す"すなわち辞めたんだよ。もうちょっと表現を代えれば仕切りなおし。
次にはじめるときは全く別物になってるはずだ。
撤退といわないところは大本営発と全く同じ。企業は自社のイメージを損ねる表現はしない。

350
>>351
まあ、そうだがな。ビジネス云々勘違いしてる連中が多すぎるからさ　ｗ

>>353
もうちょっとシノプシスのお家事情勉強した方がよろしいね。

要するに終わったってことですな

>>354
シノプシスが活動停止してる間、お前は指くわえて霞でも食って生きていくんかい？
ホンダもF1参戦してから40周年らしいな。休んでた時間の方がはるかに長いわけだが、
その間F1サーカス見てるだけのファンは楽しみに待ってりゃいいが、実際にそれを生業
にしてる側にとっては指咥ええてみてるわけにいかないんだよ。
いいなぁただの傍観者は。待ってるだけでいいからな。
もうちょっと社会常識身に着けて現実的になった方がよろしそうだね。

>>355
completely! 規格はね。
但し、普及しないまま　完了。そして　終了

では、SystemCの失敗に鑑みて、次の時代の設計のありようを
楽しく語ることにしませう

シノプシスがなんだってんだろう？結構笑えるよな、冷静に見てると。
社員なのか？

>>356
あなたシステム設計者じゃないよね？下請けHDL設計屋さんでしょ？
勘違いしてるよ、根本的に・・・で直してこいや

356を支持する気は毛頭ないが
相手の素性なんか叩いて何になる

>>320 の言う通りですね。大学の研究じゃないからさ。実用ONLYだよ。

まぁ、HDLやシステム記述にしろ、使い方は様々なんですわ。ぶっちゃけ、コストや
パフォーマンスを考えなければ、HWなどは全てSWで置き換えられるのが可能なわけ
ですよ。シングルチップマイコンなんてそのものだし、最近じゃMPEG2デコードも
DSPで出来るようになってきた。そうすると、システム記述云々でHWなんて要らない話で、
HWはごく一部のコアLSIを設計できる連中とユーザーとしてのFPGAに収斂していくんじゃ
ないかと、思うこの頃ですわ。

スレ違いすまぬ。

>>363
今、現にそうじゃないですか？

漏れは逆にHandel-Cのデザインウェーブのサンプルや、ET2004
でのデモ見て「ソフト丸ごとFPGAになっちまうんだなぁ」と感慨深かった。
まるっきりシングルチップマイコン感覚でザクザク書いてる感じで
FPGAになってブロック崩しだの、３DグラフィックスがCPUレスで
グイグイ動いてるし

あぁいう具合になるとマイコンでどこまでやらせるのか、どこまで
ハードに押しつけるのかっていうのはその都度要求仕様やらコスト
を睨んで決めればいいんだろうなぁとか思ってしまった。
ソフトハードの相互乗り入れならやっぱりC++よりCかな？

パフォーマンスはHWで複雑な動きはSW＋マイコンとなる・・っていうか、
もうなっているのか？でも本職のLSI設計屋としては悩む話なんだよなぁ。

>HWなどは全てSWで置き換えられるのが可能なわけ
いやそれをいうならコストさえ考えなければソフトウェアは全て
ハードウェアに置き換え可能でしょ。

MPEG2は開発のはじめからSparcベースのCPU+αだったよ。ああいう順序回路べったりのものはこれからもそうだし、
CPUがマルチコアを進めていけばますますパフォーマンスの点でもFPGAの出番はなくなってくると思う。Xilinxも
Alteraも戦々恐々だろうな。
ただ、シビアな省電力条件が課せられている場合、どうしてもASICを起こさにゃならんわけで、その
事前試作としてFPGAはなくなってもらっちゃ困るな。財も寺もがんばってもらわんとな。
アプリ屋の俺から見れば、テストベンチ作るうえでも高抽象度設計はWelcome
だがSystemCは終わったな。使うエンジニアにがそういう印象あたえちゃもう終わり。

>あぁいう具合になるとマイコンでどこまでやらせるのか、どこまで
>ハードに押しつけるのかっていうのはその都度要求仕様やらコスト
>を睨んで決めればいいんだろうなぁとか思ってしまった。

どの機能をどこで(CPU/DSP/GA あるいは ASIC、あとアナログ処理も在)やらせるか考えるのがシステム設計の重要な仕事。
SystemCじゃなくて製品というか"セット"の意味のシステムだけどね。

>>367
> MPEG2は......中略.......ああいう順序回路べったり

オイオイ（w

SpecC誰か使っている人最近いますかー
SystemCはお亡くなりになったようですのでいよいよ出番です

確かセットの設計にも向くようなので、
一時どこかで話題になったけどsageられた様で
どこに行けばいいのか分かりません。
ここは、SpecCも語るページですね

>>370
放置プレー

このスレを見るにつけトレードオフって言葉の大切さを思い知る。

＞CPUがマルチコアを進めていけば

ただ、今のCPUででかいからね。FPGA的な方法での分散処理とCPUでの分散のトレードオフ
FPGAなんかのダイナミックリコンフィギュレーション使って専用CPUそのものを動的に
生成したりして（デバッグしたくねぇ〜）

>>371
SystemC Vs SpecCが正しいんだけど。
VHDL Verilod C++ Sytemverilogの話をしてるのは違いが分からないからだね。
タイレッドカレーの話をしてるのにいきなりラーメンの方がマイウーって言うくらいずれてる事に気がつかないで、
違うだろハヤシライスが主流だよって議論をふっかけた。
一番大事なのは米なのにね。
って茶々入れると
馬鹿やろう、水が一番重要だってなって、結局SpecC Vs systemCの話より、水が大事か土が大事かになって、
堆肥をどう作ればいいかの話ね。
面白いけど　むなしい。

age

　SystemCはC++で、ハードウェアを主体としたシステムのモデリングのための
DesignPatternの研究の成果でして、それで留まってくれていれば良かったの
ですが、当時合成では非常の信頼の厚かったSynopsysがぶち上げたものです
から、皆さん勘違いをなさって大変なことになっているんですね。

　SystemCの最初の論文では、

　　　Simulation高速化のために、記述能力は犠牲にする

とはっきり謳っていますから、Simulation速度を最優先に考えてそれなりに苦労
して記述する事が当たり前の言語なんですね。

　ただね、SystemC1.0では

　　−サイクル精度レベル
　　−レジスタ転送レベル（RTL）

しかサポートしてなくて、これだと合成可能な範囲だったんですよ。但し、RTLだと
HDLの記述の倍以上の記述量になるし、勿論HDLだとCompilerがメチャクチャ
最適化するから、所詮はg++でしかないSystemCだと、Simulation速度は圧倒的
に遅いんですね。

　で、SystemC2.0登場！ しかしです、

　　　Simualtion高速化のためにモデリングで苦労するのは当たり前やんけえ

という思想だけはしっかり受け継いだ(元々の言語の定義からして受け継がざる
を得なかった)ので、お池にはまってさあ大変！ となりました。

　SystemCのSimulation環境、

　　　クロックの乗り換えとか、Bus周りはRTLで無理矢理書く、

というのが常識となりました(だって、それしかほぼ無理なんだもん)。なので、

　　　HDLで直接RTL書くほうが楽なんじゃ？

という疑問が普通に出てきます。どうしましょ。

age

　こんなんもあるよ。

　Metropolis Project
　http://www.gigascale.org/metropolis/

　Meta Modelなんで、何でも書ける！ というツワモノ。記述と制約の
両方でシステムのモデル化を行う感じ。抽象仕様から実装へのパスに
関しては様々なケーススタディが行われていたりする。SONYとかSTが
参画してるみたいっす。

　http://www.gigascale.org/metropolis/metropolis_icm0403.pdf
　http://www.gigascale.org/pubs/558/tutorial.pdf
　
　確か、これの前進であるPolis ProjectではSimulatorとして
ptolemyを使ってたよ。

　ルネサスと米YXIが共同開発した拡張C言語「HY-C」，WWWサイトで公開
　http://ne.nikkeibp.co.jp/members/NMDNEWS/20041113/106427/

　実時間モデルに即時通信ですか……。確かに、Metropolisでは記述
できないかも。

>>377
それでは、こうしましょう
http://tmp4.2ch.net/test/read.cgi/company/1093497747/121
http://tmp4.2ch.net/test/read.cgi/company/1093497747/124

SystemCがそんなにすごいものなら、とりあえずブロック崩し専用機
でいいから、ハード／ソフト一体のシステムと見なして書いて、遊べる
ところまで持って行ってみてくれってところか。

>　　　Simulation高速化のために、記述能力は犠牲にする

いちいちRTLで記述する必要性はないって言いたいだけじゃないんですか?
ビヘイビアでUTFでってそーゆーことでしょ

しかも Ver.1 ではとりあえずって謙虚な姿勢だと思います

>> 383

　ビヘイビアでUTF？ 機能検証とかには良いのかも知れないけど、
性能解析にはほぼ役立たずでしょ、それ。

　SoCで低消費電力化が課題なのは言うまでもなく、この対策として
複数クロックのアーキとなるのは必然。で、非同期ハンドシェイク
なんて効率の悪いものは、本当に必要な所を除いて通常使いません。

　低消費電力SoCの性能解析のためには、複数クロックがあって、且つ
モードで各モジュールのクロックが切り替えられるようなモデルを
記述する必要が必然的に出ます。

　こういうのをRTLを用いずにSystemCで綺麗に書く方法を教えて、
誰かエロイ人！

　というか、無理って白状して下さい、エロイ人！！ これが、
SystemCの限界であり、実用性に耐えない部分なんだと。つまり、
ハードウェア・システムを記述するのに丁度よい、計算モデル
というのはSystemCには実際には全く備わっておらず、それ故、
結局SystemCはC++のTemplateを使ったお遊びしでしかなかった
のだと。

　白状して下さい、エロイ人！

ばれたらシャーない。
SystemCから撤退します

>>386
　もう殆ど撤退してますがな。米国でSystemC関係の人員、大量にレイオフ
してたじゃない。

>>287
大量レイオフは恒例行事でしょ
今年もあとのこり5日だな
何人かな恒例レイオフ
SystemC関係はレイオフされてないでしょ本当は

>>388
　もとい、SystemCの動作合成関係は確実にレイオフされてたね。動作合成
の開発人員がもういない、と米国から説明を受けた事があったよ。

　CoCentricのSimulatorが売り上げを立てているとはとても思えず、残って
いたとしても極少数で、そろそろレイオフの時期でしょ、どうみても。

　というか、そもそもその会社、Simulation技術すらないでしょ。HDL
Simulatorでさえ遅すぎて、もうだめぽ。等価性検証に関しても、かなり
レイオフしたしね。

　2000年のEDS Fairで、日本の営業から、

　　　「うちはバックエンドのEDAベンダです。」

と堂々と言われた事もあったなあ。

　このスレのタイトルには反するけど、結局SystemVerilogなのかしら。
SystemCをぶちあげた会社が、そうだというんだし。結局、論理合成は
ここのが何だかんだ言って、最終的にはいい結果出してくるしね。

　でもなあ、SystemVerilogじゃなあ……。

DCでさえ真剣じゃないもんね
結局バックエンドだよ　大手三社は4社か溶岩いれて
そういう意味だと合成含めて撤退でSystemVerilogも検証目的でやってるだけ
そもそも、論理設計さえどうでも良くてフィジカル以外はみんな撤退でしょ

もうどこのEDA会社も論理設計になんか力を入れていないのは事実
論理検証以降がビジネスになるからね。
SystemVerilogもVHDLも大量に必要とするのはレグレッション用途だからに
SystemCもSpecCも大手も含めどこもやらないよ
大体半導体の設計の大部分はバックエンドです
上流はMatlabで十分

そこでHandel-Cですよ。C合成で８年も実績あるし
・・ってFPGAだけっすけどね

やっぱりSystemCをどういう目的で使うのか分かってない人が
世の中多いんだなぁ・・・結構びっくりだ

>>392
そうまでして頭の悪さを宣伝してなんになる？

>>394

　じゃあ、>>385 のような設計を行う場合は、SystemCをどうやって
使うべきなのか答えて頂けませんかね？ まさか、

　　　ハンドシェイクでビヘイビアUTFを記述して、ツールで
　　　ハンドシェイク通信チャネルの構造を最適化してから、
　　　TLMに移行

とか ﾌﾟｹﾞﾗ な回答を言わないですよね？

　だって、TLMの記述能力はクロック同期の世界では、ハンドシェイクを
用いたビヘイビアUTFより遥かに高いですよ。まあ、まともなアーキテクト
が居ないなら、そんなド素人手法もアリですけどね。

　>>393
　という事で、Handel-CもCSPベースでハンドシェイク君だから駄目っす。
お話しになりません。悪しからず。

　正確にはTLMではなく、RTLだった……、ｽﾏｿ。

　ただ、同一サイクルでデータ転送が可能な記述能力があるなら、上記
主張：

　　TLMの記述能力はクロック同期の世界では、ハンドシェイクを
　　用いたビヘイビアUTFより遥かに高い

は論理的に真です(ｷｯﾊﾟﾘ)。

　でも、SystemCでは、同一サイクルでのプロセス間のデータ通信は
RTLでないと、ほぼ記述不能。そりゃ、C++だから、OSのシステムコール
やPOSIX Thread Libraryも利用可能なわけだし、記述できないとは
言いませんが。

　でだ、>>380 で言っている「即時通信」とは、この同一サイクル
でのデータ転送の事なんでしょうか？ 取り合えず、勉強してみる
価値はありそうですね。

　ダウンロードサイト ↓↓↓
　http://www.yxi.com/download.htm

　うーん、もしそうだとして、どうやってシミュレーションするん
でしょうね。

>>396=385さん？

383だけど、俺べつにRTL廃止しろとか言ってるわけじゃないよ
ただ本当にわざわざRTLで検証しないと見つからない不具合ばかりではなく
UTFでつぶせるバグをつぶしまくるのは意味あるだろって言いたかっただけ

ど素人が生意気いうようで恐縮だけど
これをせずしてSystemCって理由は確かにないと思う
RTLだけでの勝負じゃ勝ち目がないのはあなたの言うとおり

>>399

　396です。

　ハードは並列に動作します。しかも、各プロセスは実行途中で
入力を受け付けますし、出力動作も行います。問題なのは、この
動作を上手く抽象化してUTFで本当にモデル化可能か？ という事
です。モデル化できなければ、検証出来ませんからね。

　確かに、すべて非同期プロセスとして記述し、ハンドシェイク通信
のみを用いて記述すれば、任意の並列・平行システムは記述可能だと
いう事が知られています。多くの場合は、恐ろしく非効率的な記述に
なるでしょうけどね。確かに、記述してしまえば、機能の検証は可能
です。でも、このモデルで性能解析を行うのは困難だと思います。

　また、タイミングと機能がからんだ部分の検証が最もデバッグ
が困難な部分ですから、やはり全てを非同期プロセスで、という
のには無理があるように感じています。

　やはり >>385 にあるように、SystemCにはハードを簡潔に丁度
良い抽象度でモデル化するに為の妥当な計算モデルがない、という
のが真実なのではないでしょうか？

　追記ですが、ここで言っている非同期プロセスは、完全非同期プロセス
であり、クロックを持たないプロセスです。また、ハンドシェイクも
クロックを用いないで記述されているものとしています。つまり、純粋な
ランデブーという意味です。

　>>396 では、各プロセスやハンドシェイクはwait()メソッド(バリア同期)
を用いて実現されていると仮定しています。

　一見、>>396 と矛盾しているように見えますが、そうではありません。

>>396
なんで385のようなものにSystemCを用いようとするのか、全く理解できん。
SoC設計ということで脳内反射してるとしか、思えんよな・・・ほんとお先
真っ暗だな、日本は。

>>402
　出来るだけ高速なSim環境を立ち上げて、性能解析をきちっと
行った上で、アーキの探索を行いたいから。性能と低消費電力が
それなりに求めらる設計では、385は一般的なアーキですよ。
ARMでも複数の標準バスがあり、それぞれ周波数が異なります。
コデザインを行う上で、高速な性能解析環境の構築は非常に
重要です。

　では、SystemCは何に用いるべきだというのでしょうか？

　というか、385のような設計が日本の情報家電の真髄だという事
を貴方は理解していないのですか？

>>395
高卒哀れだよ高卒。

>>403

>では、SystemCは何に用いるべきだというのでしょうか？
アナログ設計だろ　末期的
http://csdl.computer.org/comp/proceedings/delta/2004/2081/00/20810097abs.htm

SystemC-AMSついに登場か

>>395
意味が分からん
>そうまでして頭の悪さを宣伝してなんになる？
設計の現実の話をしてるだけでしょ
どこが頭悪いのかせつめいしてよ

395は高卒なのでスルーしてくれ。

検証はまず論理設計ありきであり検証だけが単体で存在するわけではないからね。

設計を生業としていたら検証作業の重要性を認識するのは当たり前としてもそれらは
一貫したLSI（今はFPGAである場合が多いが）の中のフローである事に変わりはない。
アルゴリズムとその検証だけをやっていられる職場は非常に幸せな職場だろう。
羨ましい限りだ。

>>405
　SystemC-AMSですか……。著者の方々、余程、論文が書きたかったので
しょう。元々、SystemCの計算モデル、苦し紛れでPtolemyからパクッて
いますからね。PtolemyではContinuous Time Modelなど、この論文がいう
所のものは既にサポートされていますからね。それと、ある程度固まった
ら、何でもハイブリッド・システム(各状態で微分方程式が記述できて、
時間制約も遷移条件に記述可能なステートマシンみなたいなやつ)へ拡張
する、という論文が割と沢山あるんですよ。

　その意味では、この論文、恐らく別に何ら新しい事をしてないんです
よね。まあ、Abstractしか読んでないので、本当はこういう事を言う
べきではないのかもませんが。


　お遊びと、本気の実用化、どっちなんでしょう？ これを誤魔化しを
もって混同されると、それが暴かれるまで信じて相当努力しちゃいます
からね、ユーザとしては非常に辛いんですよね。

>>403
まず、クロックの概念から離れなさい・・・話はそれからだ

>>411
　既に離れた内容も記載しています。CCSとかCSPを知らないのですか？

　私が言いたいのは、CCSやCSPのレベル(完全非同期プロセスとランデブー
のみ使用)でハードをモデル化するのは無理がある、という事です。

　ソフトウェア向けに考えられた抽象度の高い世界というをハードに
そもまま持ってきて、どうだ！ とかいうのは

　　は　っ　き　り　言　っ　て、　ド　ア　ホ

です。

　貴方、SystemCかぶれ(Ptolemyくらいは知ってるかな？)の単なる
素人でしょ。

>>400
逐次制御で書いてたのをパイプライン化って、そんなに乖離してましたっけ？
俺的にはルーチンワークって気がしてますけど・・・

あ、申し遅れました 399 です

>>413

　396です。

　単一プロセスだけをモデル化するなら、そうでしょうね。ストール
やフォワーディングがあっても、それはちょっとしたテクニックで
記述できますね。入力データもプロセス記述中にデータ入力メソッド
を埋め込めば良いですし、出力はファイルに吐き出せば確認できます。

　単一プロセス(で表現可能な範囲)だと、物事は非常に簡単です。

　ただ、複数プロセスだと、どうでしょう？ 実は、途端に難しく
なります。何故でしょう？ それは、単一プロセスで簡単に実現
できた、必要な個所でのデータの入力、出力が、プロセス間の
通信になり、これをRTLより抽象度の高い記述で表現しようとする
と、SystemCではうまく表現できないからです。

　本質的に複数プロセスのモデルを、単一プロセスに置き換えて
検証する、という事も考えられますが、あまり自然な方法では
ないと考えています。

>>414
俺、パイプラインはマルチプロセスかサブモジュールで書いてますけど・・・
逆にシングルプロセスと言われて面食らってます

>>415
　だって、そんな事したら、Simulationが遅くなっちゃうじゃない
ですか。別に合成を目的としているわけではないのですから、
不自然じゃない範囲でプロセス数を最小化して、システムは記述
しないと、でしょ？

>>416
だから、それまでに潰せるバグは潰しておくわけでしょ
突き詰めるならパイプライン化のしくじりだけに集中できるように

s/わけでしょ/んじゃないんですかね/

>>416
そんな極端に遅くなります？システム全体の検証としてみて、RTLより
はるかに速いという印象なんだけど。いや、実測してません。もう、あたり
まえに使っているので・・・
合成を目的としているわけではない、ということからインプリメンテーションと
ある程度独立しているmind setを持っているということで、まともな議論の
できる方とお見受けしての質問です。

>>412
Ptolemyが出てきてる時点でどうなのかな？
MatLabやSystemCをシステム設計と勘違いしてるんじゃないかと
勘違いされちゃうよね。２，３年前と違って今の現状を見ないとね。
ここ２、３ヶ月のNE Onlineの記事を読むことをお勧めします。

>>420
>MatLabやSystemCをシステム設計
↑　誤

>MatLabやSPWをシステム設計
↑　正

スマソ

うーむ、やはりSystemCは研究職向けの言語なのかなぁ・・・
専門用語の羅列で満足しているような。まぁ、でもそれが
ユーザー数が少ないということを表しているとも言える
けどさ。

こういった言語は設計に使用されて始めてビジネスとなるん
だからさ。まぁ、上位記述言語が欲しい設計屋としては、
そのときの主流を使うだけだけど。

いや、専門用語出してるのは、研究所の人間だと思う。それは、みな内々
感じている。SystemC自体の問題ではないと思うよ。
知ってる人は知ってるが、日本では一部システムベンダーでは
非常にうまく運用に乗っている。ある時点で、一切表に事例を出さなく
なった。自分達が敷居が高いところを乗り越え、うまくフローに乗った
ところを追従されたくないからだと思う。ここの議論の傾向は、そういう
ベンダーにとっては願ったりかなったりというわけだ。
ただ、それらシステムベンダーの動向に気づいた半導体ベンダーの動向が
ここ２，３ヶ月の顕著な動き。

研究職というのはあくまでもシステム記述言語を研究してる人間のことだろ？
俺はこんな言語で自分のシステムを記述するつもりはない。

>ただ、それらシステムベンダーの動向に気づいた半導体ベンダーの動向が
>ここ２，３ヶ月の顕著な動き。
引くときはとっとと引くのが泥沼にはまらない鉄則

>>421
　MatlabとかSPWは、DSPの設計用ですよね？ 特にSPWは携帯等特定の
アプリのライブラリが充実している、という印象ですね。使った事は
ないですが。昔は、待ち行列シミュレータのBones(綴り、間違って
たらスマソ)が携帯電話の基地局設計向けとか称してありましたね。

　で、システム設計というより、プラットフォームベース設計
として、
　　Polis −＞ VCC −＞ Metropolis
に進化していったと。Ptolemyは最近ベンダから発売されている
みたいですが、Polisのシミュレータでもありましらね。言語で
いうと、
　　Polis　　　：Esterelベース
　　VCC　　　　：根性でC/C++対応
　　Metropolis ：Javaベース（プロパティ言語(LTL、LOC)含む）
ですね。

　ちなみに、Polisで採用されたGALSの思想に基づいて、Intelの
Xscaleが設計されていたりします。というかIntel、結構これが
好きみたいで、奇妙奇天烈なFIFOを使った設計をしているそうな。

>>419
　すいません、私も実測したことはないです。ただ、記述量が複数プロセス
で記述するより少ないような気がしています。気のせいかも知れませんが。

　リファレンス・シミュレータしか使ってないので、何とも言えませんが、
複数プロセスで記述しても、SAMP構成のマルチCPUを上手に使って
シミュレーションを実行してくれるわけではないですから、複数プロセス
だと確実にオーバーヘッドが出るのは事実ですよね。

　プロセッサのISSとかだと、この記述方法が圧倒的に早いと聞いた事が
あります。

>>423
　SystemCを使いこなしているメーカでさえ、記述能力の低さを嘆いて
いたりするのが現状なんですが。

　また、合成のことを言うと、「わかってないなあ、この高卒君」となり
そうですが、これは実は避けて通れないんでよ。だって、効率向上の
要求はキリがなく、幹部から

　　　もっと、効率化せんか、ゴルｧｧｱ

　　　既に、動作合成を運用しているメーカ、あるだろ、
　　　何故やらんのだゴルｧｧｱ

と責められるのは当たり前ですからね。

>>416
　単一プロセスでパイプライン記述を行うって事は、SystemCの恩恵を
殆ど必要としない、という事に気付いていないのですか？ この記述
方法だと、Cで直接記述した方が記述量も少なくてすみますし、シミュ
レーション速度も圧倒的に早いです。

　まあ確かに、VCDのダンプが出来る、というのはありますが。

>また、合成のことを言うと、「わかってないなあ、この高卒君」となり
合成前提じゃないとか上でも言ってる奴いるが、それは単なるバカ。
高抽象度設計だけでいいならそれこそピュアC++でもMatlabでも使ってりゃいい。
システム記述言語だろうがHDLだろうが回路に落とせてなんぼ。

HDLが何のためにあるのかを全否定してるわけだが。＞また、合成のことを言うと、「わかってないなあ、この高卒君」

>>429
MatlabやピュアC++で、例えばARM9 + AMBAで携帯系のアプリ用の
システム、embedded SW込みのシステム記述してくれや。ちなみに
画処理が多くて、busがcriticalなんで最適なバス構成も探索したいんで、
どうやってMatlabやピュアC++で効率よく、最適化できるかもよろしく。

＞431
まず藻前がSystemCで書いて、実際のモノまで
落とし込んでみてくれ。言い出しっぺの法則だ。さぁどうぞ。

詳細きぼんぬ
「SystemCの勉強を始めて5カ月でJPEGデコーダを設計完了」，ロームが発表
ttp://ne.nikkeibp.co.jp/members/NMDNEWS/20041127/106592/
関係者いたら

>>420
なにか知っているようだけど。
先ず登録したら、すごい記事が出てきた
信じられないが世の中結構すすんでるようだな

>>432
　だから、>>385 の指摘とおり、SystemCじゃそう簡単には書けないん
だって。

>>429
　でも、現実的な(つまり製品にして商品価値があるような)ハード
をSystemCで記述して合成、というのは、現状では諦めて下さいね。
将来も暗いかもね。明るいとか思っている人はきっと「幸せ回路」
が脳内で発動しているのでしょう。ご愁傷様です。

　ただ、これ↓
　　http://ne.nikkeibp.co.jp/members/NMDNEWS/20041113/106427/
　　http://www.yxi.com/download.htm
の計算モデルを採用すれば、複雑なシステムも記述できて、合成も
可能になると、言えなくはないかもね。実際、合成はサポートされて
いるらしく、等価性検証も可能とか書いてある。ちょっとチェックし
て見たが、確かに理論的には可能そうな感じかも、……でもちょっと
自信ないっす。

>>433
100KSTEP/秒てSystemCの中で使われる新しい単位？

>>431
Verilogでハード記述して、それができれば合成して、
実機上でアルゴリズムの完成したソフトウェアを動作させる。
全部SystemCで記述して画像処理？？？
お前の画処理というのは一枚表示して終わりか？笑わせんな！アホ！

DMAコントローラごときを記述するのに一ヶ月もかかるようではなぁ・・

>>438
　それが、SystemCの欠点だよ。やはり、ハードを適切に記述するための
計算モデルというのがSystemCには備わっていない、という事なのでしょう。

>>429
　これが、SystemCを利用する際に、
　
　　「合成は捨てる、期待しない」

というのが、ある意味常識化している事の裏にある真実なのでしょう。

>　「合成は捨てる、期待しない」

恐ろしく現場と現実の仕事を無視したご意見だ。
本当に設計したことあるのかよ。

>>439
>　「合成は捨てる、期待しない」

そうすっと、HWに落とし込むときは人間コンパイラの出番ですか？

だめだ、こりゃ・・・びっくりするぐらいレベルが低い

>>440 >>441 >>442
　バリバリ設計者ですが、何か？ こちらは、RTL設計をカリカリに
チューニングして行っているんでね。それに勝て、とまでは言わんが
それにしても、SystemC合成ツールは酷すぎるのだよ、結果も、記述
制約も。で、記述可能な範囲の拡張を要求しても、出来ないの一点
張り。マジで、無理だって。

　つうか、使った事あんのか？

>>440 >>441 >>442
　おまいら、ちっとは、こういうのも勉強してみろよ。

　http://www.cecs.uci.edu/eve_lec_and_sem_details/lec_arvind_slides.pdf

ただ、SystemVerilogの拡張といても、文法が関数型言語Haskelをベース
としてるから使いたいとは思わんが。でも、これが提唱している設計手法
というのは、RTL設計での方式チューニング時にやっている事を、全てと
いうわけではないが、上手く抽象化して最適化としてサポートしている
んだよ。

　確かに、Cベースの方が記述も楽たし、合成できるの越したこたあ
ないんだが、SystemCやSpecCでは無理だという事が、もう常識なんだよ
チミタチ。

　ちゃんと、勉強しようね。

SystemCは、SWを生かすための言語なのでは、これでHW設計するのは
お門違いなような気がする。

>>442
2CHに何を期待してる？土台、落ちこぼれの設計者だよ、こんなスレ読んでるのは。
RTLやっと覚えたのに、また新しい言語だぁ・・・将来のことなんか、考えてね〜よ。
これ以上、仕事増えるのは嫌嫌〜。合成？できりゃ、できたで落ちこぼれRTL設計者
はリストラさ。
このスレのRTL設計者でSystemCが普及して欲しいと思ってるやつはいない、それが本音。

>>443
それはサポート範囲外です。
マニュアルを読んでから質問してください。

バグではなく機能ですので、制約を守っていただかないと困ります。
って言われた？

>>445
　その通りです。でも、ハード・ソフト一体のシステムを記述するとき
やはり、ハードのモデル化も必要となる。で、このモデル化のハードル
が異常に高い、というのは事実だよね。だから、CoWareなんかが、
単なるモデル化支援ツールや、バスアクセスAPI作成受注で、金儲け出来
たりすんだよね。

　実際、CoWareの対抗馬だったEDAベンダはARMに買収されたしね。

　英ARM，マルチCPUコア対応の協調検証ツールのEDAベンダーを買収
　http://ne.nikkeibp.co.jp/members/NMDNEWS/20040816/104961/

もともと、Arexsysという動作合成サポートもしていたコデザイン
ベンダがCoWareと同時期に出来たんだが、節操なく半島系企業と
提携するような売国メーカがCoWareに肩入れしたから、話が変に
なったんだよね。この事が、Synopsys撤退に始まるSystemC崩壊
への引き金ともなったんだよね。

>>446
　SystemC普及？ ある程度はしてるんじゃない、「合成の事は度外視、
無視」 という前提で。NEONLINEの記事によれば、性能解析くらいには
何とか使えてるみたいだし。

　でも、確かに、FPGAとかを使って実機検証をとっとと立ち上げた方が
良い部分もあんだよね。

>>2LEs8LOY
よく調べた　偉い
NE ONLINE全部読んだようだな。
ついでに、www.ertl.jp
も読むこと推奨
半島系企業と提携するような売国メーカは4様効果もあって売り上げどうなった？

>>450
　ああ、ここね。動作合成専門とかいいながら、ﾌﾟｹﾞﾗ な

　　お　前、　完　璧　に　素　人　だ　ろ！

って論文を北九州で学生に発表させてた事あったね。個人的には、
物凄く善意に解釈して「学生の発表練習」だったんだと信じるよう
にはしているが。

>>450
　もしかして、
　　http://www.ertl.jp/~honda/codesign/
を見ろって事？ それともeXCiteの事を指しているの？

　ANSI-C記述からのFPGAへのプロトタイピングでは、eXCiteを
使ったりもしてるよ。確かに、使うの簡単でいいね、これ。
結構きたないループ記述のパイプライン化も自動で行って
くれるし。

TOPPERSプロジェクトにたどりついた

これって低質な自作自演なのか？
もしかして本人だけ気付いてない？

>>450
　TOPPERSを指し示したかったのか？ 確か、ここって、コデザインの研究も
行ってたよね、SpecCを使って。それを宣伝したかったの？ 一体どれ？

　　ケンちゃんと反目関係　−＞ TOPPERS
　　コデザインまっしぐら　−＞　惰性で諦め悪くSpecC
　　動作合成まっしぐら　　−＞　本当に使えるの？ System Bulder

口だけ達者で行動が伴わない　＝＞SystemC

この同じIDの痛い人をどう扱えばいいのか？

>>457
　つまり、総合すると、SystemCもSpecCもダメダメってこった。それに
納得すりゃ、イイんじゃねぇーの。痛い目見る前に、下手な投資をしな
くて済んで良かったじゃん。

分からないな
ここの話
SoCにCPU入れるからそんなことになるわけで、入れなきゃいいじゃん
何で全部ハードで設計しないのかな
分かってきたのは無理やりARMを使うことを考えている人たちがいるって事
ハードで全部できるからSystemVerilogがいい
ARMのコアを広める為の仕組みでしょ。
反論してください。
どうしてもSWでやらないと気がすまない人たち

>>459
　その昔、携帯電話のチップセットをDSPもCPUも用いずに、全て
専用ハードで設計し、それを販売しようとした会社がありました。
確かに、性能や低消費電力という意味では、当時抜群でした。でも、
殆ど受注案件が無かったのも事実です。

　さて、何故でしょう？

　こういうのは、チップ供給メーカだけではなく、システムメーカ
でも将来の事を考えてやっちゃならない事なんだよね。解るかな？

痛すぎる馬鹿が張り付いてるある意味凄いスレだね。（ｗ

>>459
なかなか斬新な意見というか、２ｃｈ特有の陰謀説とかが好きなタイプなのかなｖｖ。


ROMから単体のMPUを動作させる程度のアプリだけやったら製品の検証は、
ISSでSWの下調べして後はICE付Boardの検証だけで十分だす。

でも単純なマイコンだけでは仕事にならないから皆困ってるわけで、
ARMやMIPS系システムに肝のCoproを幾つも入れざるを得ないから、
実務経験があればそこんとこの検証が工数でボトルネックになる位わかりまっしゃろ。

そんなどんどん肥大化するSoCを従来のRTLで
だらだら検証してもいつまで経っても終わらんわな。
e使ったり、OVLやらAssertionベースの検証言語が発達して楽にはなってるけど、
それでもRTLのシュミレーションが実際にどれ位の動作周波数に
相当するか、概算した事ありまっか？

続き、

一方SystemCが合成を無視した糞言語なのは周知の事実として、
でも実際の動作速度の速さ”だけ”は超魅力的。

ここの板でも散々出てるけど、こいつを統一言語と考えるから議論が破綻するだけ。
でもこいつの供給する上流検証用のソケットやOpenLibを無視すると、
将来的に検証が破綻するだけの話や。

まあ、そこまで短期間で大規模な設計した事なかったら感覚的に掴めんやろけどな。

＞分かってきたのは無理やりARMを使うことを考えている人たちがいるって事

これはHWの設計そのものには昔ほど価値がないって事の表れ。
例えばおまいさんはトイレットペーパーの銘柄を選ぶかね？

おケツふければなんでもOK=コンパイラまで揃ってたらなんでもOK

設計屋より検証屋の方が市場価値のある時代が近いのかもしれんのう。

僕が考えているのは、
何でハードで設計すればいいものをわざわざSWでインプリするのかが分からないだけ。
オンチップにするからバスやインターコネクトの難しい問題を考えないといけない。
システムオンチップの定義も理解できるけど、CPU+メモリーのオフチップでいいんじゃないかな。
確かに実装面積を小さくする事と消費電力の観点からはワンチップがいいに決まってるけど、
そこまでして売れるチップなり製品があると思えない。
間違ってるんだろうけど、どうしてもCPUでしかできない処理ってわからない。
うちもSystemCやSpecCの狂信者がいるけど、製品化は考えていないような気がする。
やはり無理してARMをチップ内に入れたがっている。話が逆のような気がする。
つまりシンプルできれいなチップを作るのが仕事なのに、
わざと難しくして>>音を上げると>>それならSystemCを使うべき
と技術を使わせるために面倒を持ち込んでくる。
忙しいのだ勘弁してください。

一方SystemCが合成を無視した糞言語なのは周知の事実として、
でも実際の動作速度の速さ”だけ”は超魅力的。

いくらシミュレーションで動いてもそこから手作業で落とし込んで
行かざるを得ないんじゃ、そこでRTLレベルでまたシミュレーション
していかなくちゃいけないじゃん。

>>464
要するに、製品サイクルが短く、かつ細かい修正が必要なアプリが多いんです。
したがって、柔軟性をどこかに保持しておかなくてはならない。速度が相当
要求される部分は別にして、できればソフト部分を多くしたいというのが本音。
アプリマーケ含めた、システムレベルの企画から検証まで担当してないと
SystemC、SpecCのありがたみは分らないのではとこのスレ見て、思うね〜

製品サイクルが短いならなおのことDMAコントローラ
ごとき作るのに一ヶ月もかかるようでは問題では？
現実のデバイスはもっと複雑怪奇でしょ？
結局のところ、モデリングして検討するだけのものにしては
複雑すぎるし、実際に実チップへの落とし込みまでやるもの
としてはあまりに貧弱すぎる

ってあたりに落ち着いてるんじゃねぇの？このスレ的には

>>467
　そうなんだが、米国の言うプラットフォームベース設計とやらを
前提とすると、DMACやらBusアクセスAPIやらは一旦作りこんじまえば
再利用できるって寸法。

　でも、こんなんで、商品価値のあるSoCが出来るかは甚だ疑問。だって、
皆さん、AMBA等の標準バスに、ブリッジぶらさげて自分たちが実現したい
システム向きのバスを構成するでしょ。これが、日本の情報家電の強み
でもあるわけだが。

　誰かが、指摘していた通り、高いハードルを飛び越えて、そうした
データ転送系のSystemC記述のある意味ライブラリ的な部分を即効で変更
流用とか新規開発できるようにならんとSystemCは使いこなせないんじゃ
ない。CoWareに外注しつづけて金をばら撒きながら環境を立ち上げる
という情けない方法も考えられるけどね。

前提とすると、DMACやらBusアクセスAPIやらは一旦作りこんじまえば
再利用できるって寸法。

それはCベースでもHDLベースでも同じことでしょ？
既にある設計資産を流用しない手はないしね。
”たかだかDMAごとき”で一ヶ月もかかるようでは、他にもっと
ややこしい物を作ろうとしたときに莫大な工数がかかってしま
いそうだよね？たかがＤＭＡごときで一ヶ月もかかるようで、
果たして今後の改良のときに本当にＳｙｓｔｅｍＣレベルで改良
しようという気になれるの？
というのが素朴な疑問として上がってくるわけだ。

「合成は二の次」と来てしまったのではそこで苦心惨憺
したDMAすら結局ＨＤＬで書かざるをえなくなるわけでしょ？

高いハードルを越えた先には崖があったなんてことに
なりかねないんでは？

>>469
　鋭いですね。

　RTLでしか記述できない部分は、SystemCであっても、結局RTLで記述
しなきゃならないのは事実です。ただ、そういう場所を限定して、他を
工夫して高速化すれば、デバドラの検証やコデザインの実施に足るだけ
の、性能解析環境というのは作成可能です。

　勿論、これには、ハード設計とは異なるスキルが必要となりますし、
シミュレーションの高速化を念頭に記述を行うわけですから、仮に
合成出来たとしても、先ず使い物にならないRTLしか生成できないの
も事実です。

　設計すべきシステムが複雑になったから、SystemCなりで全体の
性能解析を行うフェーズが一つ余分に増えた、というのが正直な
所ではないでしょうか。

　ただ、POSIX ThreadやOSのシステムコールを直に用いてそうした
検証環境を構築するよりは学習が少なくて済みますし、HDLでは性能
解析を行う事は困難ですから、全体での設計期間の短縮化も達成
出来なくはないと思います。まあ、担当される方のスキルに大きく
依存するのは事実ですが、それは仕方ないですね。

　一方、FPGAでプロトを作成する方法に比べてのメリットは、
SystemCを用いて環境を構築すると、バスサイクル単位などの細かい
レベルでのデバックが可能となるので、例えばデバドラのデバックが
エミュレータなしで出来る、という点とかですかね。

　ハードを簡単にそうモデル化する事もできないし、合成できるわけ
でもない。でも、今の所代替案もないし、SystemCで我慢するしかない
のかな、といった感じです。

　そういえば、OSCI(Open SystemC Initiative)の偉いさんが、システム
レベルの設計に関しては、

　　　消去法でSystemCしかないんだ！

と分けのわからん説得を試みていた事がありましたよ。

　まとめ：
　　１．SystemCを用いると設計フェーズが１つ増えます。

　　２．ハードをモデル化する事を念頭に開発したといいながら、
　　　　実はそうではないので、HDLで簡単に書ける事が、そう簡単
　　　　には書けない、という事が頻繁に起こります。

　　３．SystemCでRTLを記述すると、HDLに比してコード量が爆発的に
　　　　増加します。

　　４．入手可能な市販合成ツールは、記述制約、合成結果、ともに
　　　　最悪なのが現状です。

　　５．でも、性能解析には役立つらしく、結構使われているようです。
　　　　(By NEONLINE)

　さあ、皆さん頑張ってSystemCを使いましょう！

>>468
>でも、こんなんで、商品価値のあるSoCが出来るかは甚だ疑問。だって、
>皆さん、AMBA等の標準バスに、ブリッジぶらさげて自分たちが実現したい
>システム向きのバスを構成するでしょ。これが、日本の情報家電の強み
>でもあるわけだが。

このProprietyなlocal busをアプリによってパアメトリックに自在に再構成
できるの技術が既に存在するんだね。しかもこの部分に関しては、RTL生成
が可能。ユーザロジックが合成できないので、その部分に関しては
HW設計という観点からは2度デマになるのは皆さん、ご指摘のとおり。
SW設計プラットフォームという観点からは、今後期待が持てそうかな・・・

>>472
> このProprietyなlocal busをアプリによってパアメトリックに自在に
> 再構成できるの技術が既に存在するんだね。しかもこの部分に関しては、
> RTL生成が可能。

　ソース、きぼんぬ。

>>473
Openにされてないのです。Local busをapplication毎に作成するのが
大変なので、どうにかしてくれと、主要ベンダーにそれぞれコンタクト
すれば、そのうち情報にあたるでしょう。

>>474
　マジですか。凄いっすね。U.C.BerkeleyがMetropolisプロジェクトの
中で、階層調停方式を用いたバスシステムのシミュレーション環境構築
技術を研究してたのまでは知ってましたが、もうそこまで進んでいるん
ですね。とは言ってもC社とは限りませんよね。M社やS社の可能性もあり
ますからね。

　ちなみに、スプリット・トランザクションとか、クロスバ的な構成、
これ位までならパラメトリックに指定Okayでしょうか？ で、恐らく
問題となるのが、バスブリッジを含む階層多重バス的な構成の
パラメトリックな指定ですが、これはどうでしょうか？

結論づけたりまとめたりするのは良いんだけど、みんなほぼ同意見(?)みたいな

　　４．入手可能な市販合成ツールは、記述制約、合成結果、ともに
　　　　最悪なのが現状です。

この部分は実際にツールを使ってそれで言ってるのか、それとも
どうも使えないらしいというまた聞きみたいな情報からそうではないかと
言ってるのか知りたいんですけど。＞All
それとDK出してるceloxicaからSystemCの動作合成ツールがでたのは皆しって
るんでしょーか。あんまり話題にでてませんが。
まあ価格が価格なので全部使ってみるというのも無理な話でしょうが、
使った事があるツールやその感想とかもよければ書き込んで欲しいです。

ConvergenSCについて語って欲しい。宜しく
http://www.coware.co.jp/products/convergensc.pdf

漏れはForteのCynthesizer使っている人に感想を聞きたいっす。

それとDK出してるceloxicaからSystemCの動作合成ツールがでたのは皆しって
るんでしょーか。

あれは、DKの上にC++ to Cトランスレータを乗せたようなものじゃないっけ？
？

>それとDK出してるceloxicaからSystemCの動作合成ツールがでたのは皆しって
>るんでしょーか。使った事があるツールやその感想とかもよければ書き込んで欲しいです。
使ったことがあるならお前がインプレッションを書けよ。
それとも指くわえて高見の見物決め込んでる糞学生か？

>>475
>ちなみに、スプリット・トランザクションとか、クロスバ的な構成、
>これ位までならパラメトリックに指定Okayでしょうか？

OKじゃないかな。
さらにバス・アーキ自体をある程度Genericに構成することも可能に
なるでしょうね。バス・ネットワーク構成をある程度、IP化して用意
するような・・・

>>187　のNoCでの使用例はそのいい例なんじゃないかな。

>>478
　>>447 がその回答です。

ちなみに、C社のBerkeley研究所でも、Cycle True Synthesisとか
いうのをやってますよ。SystemCかどうかは知りませんが。

　http://www.cadence.com/company/cadence_labs/systems.aspx

あっ、Transactor Generationってのもやってますね。て事は、>>481 は
C社って事ですね、きっと。

　≪SystemCの動作合成関連の研究？≫
　Behavioral Synthesis of Concurrent Processes
　https://buffy.eecs.berkeley.edu/PHP/resabs/resabs.php?f_year=2004&f_submit=one&f_absid=100418

　Optimization of Inter-Process Communication in Concurrent Systems Using Behavioral Synthesis
　https://buffy.eecs.berkeley.edu/PHP/resabs/resabs.php?f_year=2005&f_submit=one&f_absid=100892

　≪バスアーキの探索支援の研究？≫
　Design Space Exploration of Inter-Process Communication in the Metropolis Environment
　https://buffy.eecs.berkeley.edu/PHP/resabs/resabs.php?f_year=2004&f_submit=one&f_absid=100277

　≪SystemCとの関連を示唆する研究≫
　Metropolis SystemC-based Simulator
　http://www.eecs.berkeley.edu/IPRO/Summary/03abstracts/guyang.1.html

まあ、そういう事のようですね。

　でも、SystemCから合成するのは大変だと思いますよ。シミュレーションの
高速化を第一に作成された記述というが、資産の大半となっているでしょう
からね。

　SystemCの合成を行っているところは例外なく、

　　「どういったハードを想定して、このような記述をされたのですか？ 」

という質問をしてくるから、大丈夫なんかい？ といつも思ってしまいます。
だってそれじゃ、国内半導体メーカの内製動作合成ツールの後追いにしか
なりませんからね。

SystemCじゃないけどMentorGraphicsのC合成ツールはど〜なんでしょうね。

>>483
　以前は相当酷かったのですが、結構頑張ってるみたいで、それなりですね。
ただ、パイプライン最適化が弱いかな、という印象です。C合成ツールとして
はYXIのeXCite Basic/Pro の方が優れているようですね。

　http://www.yxi.com/Japanese/indexJ.html

>>477
ここにくわしく
http://ne.nikkeibp.co.jp/members/NEWS/20041130/106618/

これも結局、SystemCで、コンパイルできるようVerilog記述を置き換えに
よって変換しているみたいです
http://www.cadence.co.jp/news/h16-6-8.html

http://www.oki.com/jp/Home/JIS/New/OKI-News/2004/11/z04106.html

ロームや沖といった2nd Tierの半導体ベンダーがSystemCのプラットフォームで
先行してるんですね。過去のHDLの資産やビジネスのしがらみが無いだけ、
柔軟に対応できるのと、1st Teirベンダーとの差別かでSystem Levelのsolutionを
打ち出し、売りにしてるということなんでしょうね。
記事だけ見てると、HDLのパスが無くてもそれなりの効果あるように見えるけど、
実際はどうなんでしょうね。ここでの議論とあまりにGAPがありますね。流れを
見てると、このスレの住人はちょっと時代に乗り遅れてるかな、という印象を
持ってしまいますが・・・やっぱり、SystemC勉強しなくちゃいけないかな・・・

>>488
　正しくは、実力のない2nd Tierが、売国企業が投資したCoWareの成果物で
あるARMを主体としたSystemCのライブラリを、大枚はたいてCoWareから導入
した。単にそれだけの事でしょ。

　心配しなくても、1st Teirは自力でSystemCの環境を既に構築済みだし、
現在運用中ですよ。それを踏まえて、SystemCの問題点をさらけ出している
のが、ここのスレ。

>>488
　>>470、>>471 をちゃんと読め！

>>489
>心配しなくても、1st Teirは自力でSystemCの環境を既に構築済みだし、

なるほど、やっぱりSystemCは使われる方向なんですね・・・色々問題が出るのは
ある意味、いい傾向なんでしょうね。ということで安心してSystemCの勉強します。

>>480
使ったことない。っつーか使ったことないから聞いてるんだけど。
DKって聞いてなんの事かわかってなかったりしてるのでほとんど
C入力のツールを実際には使ったことない人が多数なんだろーけど。

>>491
　但し、合成がまともにサポートされる事はないと、それだけは肝に
銘じておいて下さいね。

　WSやPCのようにメモリが沢山利用可能な環境で、ポインタやmallocを
用いて高速化だけを念頭にアプリを研究者が開発しました。で、それを
技術者が組み込みマイコンに移植する事になりました。

　研究者は言いました。

　　「リターゲッタブルコンパイラがあるから楽勝でしょ。」

　技術者

　　「はあ？ ……(沈黙) 」

　そんなリターゲッタブルコンパイラはあるわけないのである。SystemCの
現在での存在意義は、HDLに比べて最高１万倍というシミュレーション速度。
それ故、シミュレーション速度を最優先課題として記述し、環境構築を行う
事になります。合成可能な記述もありますが、それらは得てして
シミュレーション速度が遅いです。以下(ry

>>491
だからー。わからんかなー。3年前ならともかく
今更SystemCベンチョーしても文化的な意味しかない。
つまり奥様がカルチャーセンターに通うのと同等の意味合いしかない。
実務において役立つ確率はきわめて小さい。

ということで安心してSystemCの勉強します。

現状オブジェクト指向風味言語としてC++が一番普及
はしてるから勉強しておいて損はないだろうけども、
C++で書いたソースをコンパイルしたらどういう風に
落ちるのかということを見ておくといろいろな意味で
いいと思うよ。
DK云々ってことも言ってるのがいるけど、DKでも実際
にどういう具合に落ちるかをある程度頭で意識しながら
ハードよりのコード（合成向きのコード）を書かないと
痛い目にあうからね〜

勉強しておいた方がいいのは
SystemCじゃなくてC++な、念のため

>>494
下請けHDLコーディング屋さんになるよりはマシ？　かな　ｗ

>>496
C++よりは、Javaでしょ。最近ではGCJなるGNUフリーコンパイラもあるし。

それに、C++はダメダメ言語で有名でしょ。で、C++上に構築されたのが
SystemC。つまり、でっどこぴー、ってヤツですね。

C++やるんじゃなくてtemplateだろ？
プログラミング言語C++読破して、その後で、Modern C++ designやらC++ Templates
やらを読みこなすと。C++ TemplatesはともかくModernの読破をハード屋に求めるのは
かなりお門違いのような気がするがな。

>>498
プログラム言語としてはC++は存在意義がある。速度を求めたいときはCライクにも書けるし。
あと、templateはC#2.0でもDでも実装されるだろうけども基本的な考え方はC++と大差ない。
ループのアンロールにしろexpression templateにしろC++そのままになるんじゃないかな？
ただ、仮想ハードウェアをソフト記述するのにC++が適当だとは思わんけども。

>>497
言っといてやろう。アプリ屋はSystemCなんかに手を出したりしない。

>>499
>>497
>言っといてやろう。アプリ屋はSystemCなんかに手を出したりしない。

できれば、アプリを企画する側になりたいものだな　ｗ

>>499
　だから、C++だとPOSIXとかシステムコール使わないと、スレッドプログラ
ミングできないじゃん。その点、Javaだと条件同期が言語としてサポート
されてるからOkay！

　Templateが凄いのは当然なんだけど、C++はスレッドプログラミングに
対してはどうなの？ って疑問がある。ただ、そのModernなんちゃら、
というのは読んだ事がないので、お門違いの事を言ってたらスマソ。

>>488 - >>490
1st tier 2nd tier?? 何ゆえ、この二人は同じスペルミスを1st Teirの時だけするの？
しかも、この失礼な言い方は◎立特有のエリートが使い始め....
自分たちが1stだから普段侮辱している2nd tierだけ書きなれている。
ということを前提で。

その昔パワー半導体や個別半導体で儲けていた元大手半導体ベンダーには、
SyetemCでシステムLSI設計ができる"エンジニア"はいません。
その代わり論文屋さんもしくは研究職は一杯います。
ARMを実際に使いこなしている、SystemCを立ち上げられるのは
あなた方の言う2nd Tireだけなのかもしれません。

本業の整流器やバイポーラトランジスタに真剣に戻ったほうがいいかも。
単価は高いし。
なぜロームや沖がやってて、我社3rd tire <<Typo>>がやらないのかってさっき喧嘩してきた。
あ、俺？　グーグルでここにきた　SystemC 勉強済み実戦経験なしのベテラン
もうこないけど　バイ

言い忘れたけどCoWareの外人営業とマーケが3年くらい前に我社3rdtierにも来たけど。
その時のマーケ迫力あったけどSystemC思い切り否定してた
みんなくびになったのかな？
展示会でも見かけないし

>>502
　◎立のシステムLSI部門って、合弁会社になったんですよね。しかも、
そこのホムペに、「研究部門はありません。」 と堂々とUPしていた
ような気がしますが。そう言えば、

　　ルネサス，SoC向けシステム・レベル性能評価・検証プラットフォームを構築
　　http://ne.nikkeibp.co.jp/members/NMDNEWS/20040922/105484/

なんて発表がありましたね。つう事は、マジで立ち上がっているって事？

　関係者の方、本当の所を教えてくらさい！

LogicBenchでまだやってるって実際は。

それにまだ立ち上がってるとこみたことない
ついでにいうと　◎立の頃はやってたらしいけど
その時はCoWareCとかN2CとかいうCは付くけどまったく別物
正直3年で、このCoWareって会社はSystemCに宗派替えしたみたいだ。
まだまだSystemC早いといってたのは3年前　当時は斬新だったけどねN2C
だけどすげ！　社長もマーケも入れ替わってる。
しかも大手EDAのCの子会社みたいだな。俺にはわかるベテランだからな
SystemCのツールを金だして買う必要あるの？
このベテランエンジニアに関係者の方、本当の所教えてくれさい！
だって元　◎立が当社自慢のDA部長
わかるかな？　関係者の皆様

ちなみに俺は　つぎはぎだらけけの「継ぎ目なし」ってツール買わされた

>>505
　日本語がヘンです。裏社会版◎立スレ特有のメルヘンってヤツですか？

>>506
違います。すこそ頭がヘンなだけです。
普段Verilogしか書かないベテランだから日本語ちょっとにげてです
元◎立で今合併会社で働いている人たちが、かなりの割合でここにいるみたいで、
面白いから煽ってみました
2ndとか3rdって言う言い方大嫌いでカチンときてしまいました。
正直技術はどこが高いかはお客様が良く知ってるからあわてないけど
わたくしはSystemCでどうしてもやりたいのです。
SystemCを始めたいっていう言い方
俺パソコン始めました！　みたいで結構気に入ってる。

Verilogをg++でコンパイルできるよう変化するツールだけど、こんなのどう
http://verilog2cpp.sourceforge.net/

>>508
抽象度上げないと早くならないから、速度的なメリットは無いような気がするけど
実行時ツールいらなくなるメリットはあるのかな・・・？

>508
cpp2verilogが欲しいね（笑

>>508
だからさ。Verilogなら、ファンクションシミュレーションならフリーツールだけでもできる。
タイミングシミュレーションに関してはハードウェアベンダのサポートが要るが、メーカのフリーツールでもできるし、
論理合成にしたって、そこそこ問題ないレベルでできるんだよ。
わけわざわざg++でコンパイルして何になるんだよ。
わけのわかってない学生が絡んできて迷惑千番だな。

わざわざg++でコンパイルして何になるんだよ。

sourceforgeだぞ。ムキになるなよ。
「おぉ、面白い遊びしてるじゃん！」でいいんだよ。

"わざわざg++でコンパイルして何になるんだよ。"って思ってるから
"cpp2verilogが欲しいね（笑"だろ？
monitorをいちいち書かなきゃ値を確認できないようなシミュレータをg++で
作ったところでめんどくさいだけだもんな。

>>513
こだわるね
やめよ
もう

だっからぁ、実用にするようなものじゃないって
面白そうだからcpp2verilogも欲しいんだって

・・って・・そんなにﾏｼﾞになってたのか？
所詮sourcefogeだぞ。

君たち間違ってるよ。
日立はそんなこといわない
Tier one, tier ryanが正しい

>>507
　技術には自信がおありなんですね？ そんな貴方がSystemCを始められると。
>>499 を参考に頑張って下さいね。

すてきだなと思ってC++を盗作しちゃいました。

で、2.0への移行時に、SystemCの創始者である RAJESH GUPTA教授に見捨て
られたと。

　　http://www-cse.ucsd.edu/~gupta/

　　An Efficient Implementation of Reactivity for Modeling Hardware in the Scenic Design Environment (1997)
　　http://citeseer.ist.psu.edu/2621.html

　その2.0を提案したのが、CoWare！！

1.0では駄目だと言い張り、SpecCを参考に拡張しなければならない！ と
主張し、且つCoWareに割と大規模な投資を行ったのが、某売国メーカ。

某売国メーカってどこなんですか・・・なんか粘着してるようで見てて
とってもかっこ悪いです。

ぴぃー（えー）すぅ！

>>521
　ATGの方が、嘆いていた。

　　「本当はもっとゆっくりと、合成も高速Simulationも両方考えながら、
　　　SystemCを育てたかった。でもね、顧客に腕力を振るわれると、
　　　どうしようもない。こちらで対応する方針がないとわかると、
　　　コントロール可能な新興ベンダを支配下に、以下(ry 」

まあ、撤退という賢明な選択を余儀なくされたそうな。つまり、荷担した
当時新興ベンダ以外は、合成の事を全く考えていない糞言語SystemC2.0に
対して、責任はほぼ皆無なのである。

test

最近、速聴により頭の回転が速くなるという話を聞きますが、
多分というより、確実に、心を読み取る装置のほうが効果が挙がると思われます。

メールよりも、チャットのほうが返答回数が多くなります。
チャットよりも、電話で話したほうが、返答回数が多くなります。
電話で話すよりも、直接会ってはなしたほうが、返答回数が多くなります。
直接会うぐらいなら、心の声で話をしたほうが、効率的に話せます。
心の声で話をするぐらいなら、潜在意識を通わせたほうが、圧倒的に情報量が多くなります。

この効果は恐らく、泉ピン子と２４時間会話をしたときの比ではないかと…。
しかも、速聴と違い、自分の欲しいと思っている情報が次々と入ってきます。

みなさんも、どうぞお試しあれ。

↓↓↓↓心を読み取る装置の注文は、こちらでどうぞ↓↓↓↓
http://that3.2ch.net/test/read.cgi/bouhan/1101371479/l50
（ときどき、心を読み取る装置の風評を流している工作員がいるので注意）

>>522
ずっと考えてたけど意味不明

>>522
SpecCで放置プレーの人だ

>>521
　ATGの方が、嘆いていた。

これもわかんね
壊れたかな

#include "systemc.h"
#include "mpi.h"
int
sc_main(int argc, char *argv[])
{
MPI::Init(argc, argv);
sc_initialize();
int rank = MPI::COMM_WORLD.Get_rank();
int size = MPI::COMM_WORLD.Get_size();
cout << "Hello World! I am " << rank << " of " << size << endl;
MPI::Finalize();
sc_start(10);
return 0;
}

今日届いた日経マイクロデバイスによると、
リコーはForteのCynthesizerを「想定している」んだそうな。
2003年度に導入、実用化のメドがほぼ立ったそうで、
2004年度中には新規開発ブロックへ適用予定だそうで。

>>529

想定してるけど本当にメドたった？
本当ならすごいことだ。

まぁ、systemcは主流になれば使うだけだな。systemcは
ソフト屋がなんとかハードウェアを設計したい願望の
現れとも言う人も居る。それはともかく、

標準化を目論んでも多数派になったモノが標準になるのよ、
この世界は。通信方式みたいに制約のあるものじゃないしさ。

良くある話だけど、標準化を言う連中は主流のなり損ない
とも。。

でも為になるスレッドだなぁ・・・

systemcを使っても、使わなくても、稼いでなんぼ、画期的なLSIでナンボだかんね。
金銭あるいは技術的な貢献がなくて、「systemcでシステム設計をした！」と
言っても、そりゃ、「道具としてsystemcを使ったんだね・・・ご苦労さん」としか、
思われないよ。それで良いなら仕方がないけどな。

>>472

>このProprietyなlocal busをアプリによってパアメトリックに自在に再構成
>できるの技術が既に存在するんだね。しかもこの部分に関しては、RTL生成
>が可能。ユーザロジックが合成できないので、その部分に関しては
>HW設計という観点からは2度デマになるのは皆さん、ご指摘のとおり。
>SW設計プラットフォームという観点からは、今後期待が持てそうかな・・・

専門用語に酔っているような・・・専門用語を数えましょう！

>>527
きっと、これではないかと。

http://bookweb.kinokuniya.co.jp/htm/4621071440.html

米国Ｍａｓｓａｃｈｕｓｅｔｔｓ工科大学にて電子工学と情報工学の
博士号を取得。１９９６年にＳｙｎｏｐｓｙｓ社に入社し、現在は
Ａｄｖａｎｃｅｄ　Ｔｅｃｈｎｏｌｏｇｙ　Ｇｒｏｕｐの
~~　　　　　　　　~~　　　　　　　　　　~~
プリンシパルエンジニアとして勤務

>>534

　ずれたあ……　orz

　ATG ：＝ Advanced Technology Group


>>533

　Proprietyなlocal bus ：＝ 独自ローカルバス

　×パアメトリック
　〇パラメトリック

　意味は、英和辞典なりで、parametric を引いて調べて下さい。


　ユーザロジック ：＝ バスにぶら下がるモジュールの事（だと思ふ）

　SW設計プラットフォーム　：＝ 独自ローカルバスに対応したSystemC
　　　　　　　　　　　　　　　のシミュレーション用記述を効率良く
　　　　　　　　　　　　　　　構築できるプラットフォームというか
　　　　　　　　　　　　　　　環境（だと思ふ）

systemcを使っても、使わなくても、稼いでなんぼ、画期的なLSIでナンボだかんね。

だよね。結局導入しました！っていうアドバルーン効果に
期待しているんじゃなくて、それでなんぼ稼げたかという
のが大事だし。
果たして投資を大幅に上回るだけの利益が得られるかどうか。

>>532
記事読むと設計期間短くなってるからね・・・ご苦労さん以上のものがあるよ。
特に、発注側のシステムベンダーとしては。

>>535
あれだな。ATGはともかく、proprietary(proprietyじゃないぞ〜>472）や
パラメトリックぐらいの言葉、自由に使わせてほしいよな。酔ってるとか
言われたんじゃ・・・・orz

>>537
自分の理解できない言葉を大量に使われると、

　　使　え　な　い　研　究　者　、発　見　！

とか思っているのかね？　よーわかりませんが。そんな風に思うより、
勉強が足りないと思って前進する方がずっと良いだけどね。

そういえば、OSCI(Open SystemC Initiative)で日本人がリーダになって
推し進めていた、合成サブセットの定義、というのはどうなったんだ？

２年前、某社のSystemC合成担当の方が、

　　「折角合成サブセットを定義したのに、マーケが顧客の意向を
　　　反映したと言って、勝手に合成サブセットを拡張しやがった。
　　　こんなの６割も合成出来やしない！ 」

と愚痴っていたなあ。ああ、懐かしい。

合成が期待薄だっていうのは、>>493 を読むと凄く納得出来ちゃうね☆。

合成は期待薄でもない断言できます
DC（シノプシスのデザインコンパイラ）や
シリコンコンパイラ構想の頃もそのような意見が大半でした
技術は常に進歩していますから、新興ベンダーが現れる度に技術革命は起きます
徐々にですがフォルテも使い物になるとの意見が出てきてますし、
実験的にですが高位合成を使用した成功例も出てるように聞いています。
日本のメーカでも4人位がこの分野で挑戦していますので、日本発の技術が現れないとも限りません。
夢を見ない、園児にあ、にはわかりにくいかもしれませんが、
研究職の間では高位合成の方法論も、それを利用したフィジビリティスタディも実行しています。
合成方法の議論はまだまだ続いています。
期待してください

そういうのはブツが出来てから言わないと全く説得力
がないって。夢を議論して飯が食えるのどかな研究者
連中には現場なんてどうでもいいだろうけどね。
そのDCのシノプシスに見捨てられてはなぁ・・もう一回
土下座してでも引き込むべきじゃないの？

C++プログラマを一週間ばかり教育する程度で、
サラサラッと書いたRTLレベルでカリカリチューンした
やつの20%増し（30%でも許す？）くらいのサイズ／速度
のものが合成できる程度のものを、GPLに基づいて配布
してくれれば世の中変わると思うよ。

>>542さん
領域噛み合わないComunicationになると思いますが、一応レス付けます
現段階では配布できるものではありません、有料でEDAベンダから買ってください。
Proprietaryの物で良ければ半導体ベンダにお尋ね願います。
土下座しなくて無配布してくれるでしょう。
普及段階として多くの高位合成は既に出来上がっています。
只SystemCの言語制約逸脱しなく開発をしているのを理解いただきたい
議論はWGの中で提案として正しく伝えてください
誰かいいこと言ってましたが。
今役に立たない物を否定するの良くないと思います。
明日の設計の為の道具ですからね。
わかりますか？　
だから攻撃的にならずに期待していてくれればそれでいいです

SystemCは今設計に使用できる言語ではありません。
明日の設計の為の物ですので、残念ですが今役に立てません。
認めます。　見捨てられた技術と言いたいのですね。
これは完全に誤った認識ですが、ここで説明しても仕方ないので、
自分で何がEDA業界でhappenしてるか調べると面白いとです。
今の現場のannoyedは理解してます。

ついでに言うと、気に障ったら悪いんですけれども
私は十二分にこの夢だけで飯がたくさん食える人です
苛々するなら合成,SystemCというワードにフィルタをかけて、
今後一切関連の技術情報読まないほうが精神的に楽

>>543
計算不能なものはどうしようもないです。EDAベンダの方にせよ、メーカの
方にせよ、結局はコンピュータシステム上で実現可能なものしか出来ない
のです。

SystemCの問題点は、現在広く行われているであろう性能解析シミュレー
ションのための記述を変更する事なく合成し、且つ玄人RTL設計者が、
これなら納得！ という結果を得ようとすると、

　　計　算　機　科　学　で　ノ　ー　ベ　ル　賞　モ　ノ

の宇宙人から教わる位しか方法のない、現こんぴーたーさいえんすを
覆す理論に基づくような得体の知れない技術でもないと、ほぼムリ
だという事が断言出来てしまう、という事です。

　ちなみに、ノーベル賞が計算機科学を対象としていない事はご存知
ですよね？

　確かに、ある種のコーディングルールに従って書き換えたり、それを
前提として合成ライブラリを拡充すれば、確かに使い物になるツールも
作成可能だとは思いますけどね。問題なのは、そのコーディングルール
を記述が満たしているかどうかの判定でさえ、相当の記述制約を課さ
ないと、決定不能問題となる恐れがある事です。

　それを解った上で否定しています。

　計算不能　＝　どんなに頑張っても、こんぴーたで解く事が出来ない、
　　　　　　　　つまりその問題をとくためのアルゴリズムが存在しない
　　　　　　　　という事

補足

　　決定不能　＝　計算不能


>>OSC1さん
　まあ、そうは言っても頑張って下さい。

>GPLに基づいて配布
CPUの場合アセンブラは公開されてるからフリーで作っても何とかなるかもしれんが、
FPGAの場合、先ずメーカは内部情報を公開せんな。
GPLに基づくフリーでできるのはファンクションシミュレータまでだと思われ。

蛇足

　　　論理合成は学問だが、動作合成は学問じゃない！

これ、U.C.BerkeleyのEDA関連の超有名教授のお言葉。

論理合成は、ブール代数という無矛盾な数学ワールドで展開されている
非常に綺麗な学問なのです。方や動作合成は、プログラムを表現する
あるデータ構造(通常はコントロールデータフローグラフなど)をグラフ
と見立ててのスケジューリング問題、として定式化されているだけで、
ブール代数のような無矛盾な数学的バックボーンがはっきりとあるわけ
じゃないんですね。

で、例えばブール式の場合、標準形が存在するんですが、プログラムの
標準形というのは恐らく存在しないんですね。だってあったら、２つの
プログラムが等価かどうか判定できる事になるでしょ。これは一般には
決定不能です。勿論、厳しい条件をつければ解けますけどね。

つまり、論理合成の場合、初めから標準形がある世界でのお話しだったん
ですよ。方や動作合成は、どの範囲だと標準形があるのかえ解ってない
世界なんですよ。これが解れば、劇的に進歩するかも知れませんが、RTL
に毛が生えた世界というのが解である可能性もあるんですよ。

>>OSC1さん
　頑張って下さい。

>>543

お前の文章にイライラするんだよッ

やってる本人が「使えるものじゃない」だの「明日の為の・・」
（丹下段平みたいだな）なんてシロモノだって言うんだし、
”当分間実用に耐えるようなものにはなりませんが前向きに努力はしています”
だろ？それでもGPLに基づいて配布するとかいうなら玩具のようなレベル
でも全然ｵｯｹｰだけどね。

ﾁﾐは夢で飯が食えるんだから、それでいいけど、他人に食わせ
ようとするなら、きちんと他人に食わせるに足る料理にしてから
持ってきなさいということさね。今の状態はメニューの写真は
立派だけど、実体はがらんどうの食品サンプルみたいなもの。
「いずれ凄く美味しいものになるはずです」と言ってるようなもので
しかないよってこと。

漏れはSystemCについては他のイロモノと同レベルのものとして
生ぬるく見てるさね。
そういや、XのForgeなんていうのも生ぬるくいじったことがあったな。

＞FPGAの場合、先ずメーカは内部情報を公開せんな。
＞GPLに基づくフリーでできるのはファンクションシミュレータまでだと思われ。

とりあえずVerilogやVHDLを吐いてくれればいいんじゃね？

蛇足２

私が知る限りでは、数学的バックボーンを伴う、合成がそれなりにサポート
された言語というのが、

　　Esterel　　：　Esterel計算(SOS：Structured Operational Sematics)

　　Bluespec　 ：　項書き換え系(TRS：Term Rewriting System)

　　HY-C　　　 ：　時間拡張を伴うプロセス代数(Process Algebra)

ですかね。この中でCベースのは、HY-Cだけですね。

>>547
工学を見下すタイプの理学屋は歴史的功績を残せない

verilogも論理合成がなければ、RTL記述は使われなかったということになるな。

今日は（今日も）暇だからレス付けますが
Googleでここに来てしまった真剣な人たちが誤解するといけないので言ってもいいかな？

トランジスタ>IC>LSI>VLSI>ULSI>SoCという流れ（かなり大雑把）に
レイアウトツール>回路図入力>HDL(他さまざま）>DC(RTL)>ときてる
今はサインオフはGateLevel VelirogXLここまできてるね。
これぜんぜんOK
トランジスタ(CMOS)レイアウトも配線も配置もフロアープランニングも大事

SystemCはこの歴史の延長線上にあるわけで、RTL技術者を否定してなんかいませんよ。
むしろ、尊敬しております。
トランジスタ>IC>LSI>VLSI>ULSI>SoC
明日の話という意味は最後のSoCの事を言ってるのです。
この領域の難しさは、HDLの玄人の直面している難しさと別次元の難しさなのです。
ここが分からないと否定するしか立場がなくなるのです。
HDLの玄人がトランジスタレベルの苦労を知らないのと同じです。
SoCの玄人が時代の要請で出てきてしまったんです。
みんな大事ですが、後進に席を譲るのではなく新しい世界によって自分の仕事がなくなるわけではないので頑張ってください。
勿論電子物性から上流の研究者に成り下がった人もいますが、いい給料と研究費もらってますよ。

>>554
パーフェクトに同意

>>554
手彫りレイアウト屋さんと、打ち合わせながらRTL＋図面入力設計してた頃
が懐かしいっすね。

> 勿論電子物性から上流の研究者に成り下がった人

厳しい意見ですね(笑)。

>>554
でも、SystemCの合成は、相当な記述制約が付かざるを得ない事をちゃんと
白状して下さいね。誤魔化しちゃ駄目よ 凸▼▼ﾒ)。

SytemCはトランザクションレベルで記述して美しく、ソフト(あるいはファーム)
も同時に検証できるツールなんですよ。一昔前はこの辺はHDL記述を論理合成して
ハードエミュレータを実現し、ソフト(あるいはファーム)を載せて検証していた
のです。今でもこれしているところ多いけどねぇ

>>558
> SytemCはトランザクションレベルで記述して美しく、ソフト(あるいはファーム)
> も同時に検証できるツール

美しく？ えっ？？？ お、おかすぃー、そりは変だっぴ。高速化を考えて
出来るだけRTLを使わないように真面目にモデル化しようとすればする程
変態コーディングになっていくんでしゅが……。

　　？　？　？　？　？　？　？　？　？　？　？

ここで、質問するのはお門違いと突っ込まれそうなのですが、詳しい方が
沢山いらっしゃるみたいなので、敢えて質問させて頂きます。

　　[記述したい動作内容]
　　　eventが２つ以上あり、その中のどれかのeventを受けると
　　プロセスを起動するが、受けたeventでプロセスの動作を
　　切り替える。


　　wait(e1 | e2 | ... | en);

で、「eventが２つ以上あり、その中のどれかのeventを受けるとプロセス
を起動する」は簡単に記述できるのですが、

　　if(e1)

と記述できるとも思えず、「受けたeventでプロセスの動作を切り替える」
というのをどうやって実現したらよいのか、サッパリわかりません。

どなたかエロイ方、ご教授お願い致します ｍ（＿ ＿）ｍ。

ＩＤがＤＱＮっぽくなってる……　ｏｒｚ

＞SytemCはトランザクションレベルで記述して美しく、ソフト(あるいはファーム)
＞も同時に検証できるツールなんですよ。

研究者には趣味的な美しさも大事かもしれないけど
実務では別段美しくなくてもいいんだよ。
水商売のねぇちゃんじゃないんだから。

「今までより綺麗です」なんていうのは駄目。検証できる
といっても、検証するために莫大な手間が掛かるのでは
本末転倒。「今までよりも格段に楽になります」でなくては
価値がない。
要するにサラサラッっと記述してパパッと実験して
それでオッケーとなったら、ササッと実際のソフトウェア
とハードウェアになって製品化できなくてはね。

>>560
event毎にsensitive割り当てるとか、じゃダメなんかな？

>>563
staticではなく、dynamicで実現したいのです。eventはデータを運搬
できませんが、これが出来るとある程度、eventによるデータの運搬
が一部可能になるので。

ご教授、宜しくおながい致します。

>>564
動的の場合、イベントの発生順番が決まってないと、難しいような気がするなぁ。
どうだろう、エロイ人？

？

SystemC勉強中さん、
きっと0SC1メンバ さんが教えてくれますよ。

がんばろうねー　やっぱしシステムシーだよ

>>560
これ書けると便利だあね。でも、書き方、解らないッス、スマソ。
でも、これが書ければ、ぐぅば がリアリアになりがちな投機実行制御での
キャンセル信号とかが、あんたいむど、とか、ばすさいくるせいど、とか
で簡単に書けちゃうね。つうか、他にも色々使えそうっすね。

て、もし書けましぇーん！ って回答だったら、

　　や　っ　ぱ　使　え　な　い　ぢ　ゃ　ん、　ＳｙｓｔｅｍＣ

って事？

そんな回答じゃないよね、エロイ人？

システムの動作を記述しようっていうのなら
普通に必要になる機能なんじゃないの？

>>560
68kのIPLとFCみたいなこと?

>>570
staticで普通に書けるでしょ。

>>572
サイクル精度でSC_THREADを用いて記述するとすると、あるサイクルでは
>>560 みたいな事をしたいけど、別のサイクルではしたくない、って感じ
の記述って、staticで出来たっけ？

アホな質問だったら、スマソ。

あのう、もしかして、質問内容がSystemCの こうあるべきだ！ という
使用方法というか記述方法に、大きく反するものだったのでしょうか？

うーん、でも出来れば、dynamicで実現する方法をご教授頂きたいです。
エロイ方、何卒宜しくお願い致します ｍ（＿ ＿）ｍ。

同じIDで大量投稿しているCの達人さんへ

講釈より何か設計事例を書いて欲しい。
そうでないと言っていることに何の説得力もない。

だから事例がないんだよ。
遠い将来の言語だから

違う
言えないこと書けないことが多すぎるんだよ

なんでーーー　聞きたいよーーーーー

うーん、確かに、wait(10); とかをクロックだと思って記述すれば、static
でも良いのですが、それだと、クロック遷移ごとにトリガにしたいeventを
変更したり出来ないから辛いです。

やっぱり、どなたかがご指摘されていたように、ちょっと複雑な事をしよう
とするとRTLで記述しなければならない、という事でしょうか？

そんな悲しい結論じゃない、って回答付きで主張して下さい、エロイ人！
何卒、お願い致します。

sc_eventだとnotifyっぽいのしかないので、たぶん（？）できなかったと思う。
event数が決まってるんだったら、sensitive << e1 << e2 << e3 <<..で張っといて
wait()で抜けたあとに分岐ということになりそうな気がするなあ。

>>580
有難うございます。

ただ、それだと、eventが全く来ないクロック遷移では、デッドロック
しちゃう気がするのですが、それは気のせいでしょうか？

eventがこないと、waitは抜けないけど。クロックイベントも必要なの？
（しつもん理解してないかも

>>582
はい。取り合えず、wait(10);とかでクロックにしようかと思っては
いたんですが。

もし、クロックイベントを追加した場合、デッドロックはなくなりますが、
wait()を抜けたときの分岐で困るような気がするのですが、気のせいで
しょうか？ wait()を抜けた条件が、クロックイベントによるものかなか、
それとも、その他のstaticなイベントによるものなのかの識別は、可能
なのでしょうか？

#include "systemc.h"
#define EVENTSU 3
SC_MODULE(he){
void loopp();
sc_buffer< bool > hohe[EVENTSU];
SC_CTOR(he) { SC_THREAD(loopp){
for(int i=0;i<EVENTSU;i++) {
sensitive << hohe[i];
}}}};
void he::loopp(){
while(1) {
wait();
for(int i=0;i<EVENTSU;i++) {
if(hohe[i]) {cout << "hohe" << i << endl;hohe[i]=0;}
}}}

int main() {
he *he_inst = new he("hoho");
sc_start(10); he_inst->hohe[2] = 1;
sc_start(10); he_inst->hohe[1] = 1;
sc_start(10); he_inst->hohe[2] = 1;
sc_start(10); he_inst->hohe[0] = 1;
sc_start(10);
return(0);
}
見にくくてスマソ

SystemCはCだから、いざとなれば、なんでもありだよ。そろそろ寝ます。さようなら〜

>>585
有難うございます。sc_startでクロックの代わりという事ですね。ただ、
申し訳ないですが、汎用性が低いような……。

よく考えれば、wait() methodには timeoutもありますから、クロック周期
を10nsとかに設定するのであれば、event数が決まっているものとして、
sensitive << e1 << e2 << e3 <<..で張っといて、timeout付きのwait()
で抜けたあとに、クロック遷移内にeventが発生したかを否かをsc_time
なりで確認した後に分岐すれば良い(eventを受けた場合は、行うべき処理
を行った後必ずwait(10);を実行するように記述する)、という方法も考え
られますね。


ただ、この方法の問題点として考えられるのは、

　１．sc_clockを使えないので、VCDダンプでちょっとはまりそう

　２．レーシング対策を主導でデルタ遅延等を挿入して行う必要がある
　　　(ゼロサイクルの安定ループの扱いは相当困難かも知れませんね)

　３．RTL記述を混載してはならない(同一周期内に同じeventが複数回
　　　発火して漸く値が安定する事がありますが、その場合、最初の
　　　event発火で確定した誤った値を用いて受けた側のSC_THREADが
　　　動作する事になりますね）

ですね、きっと。勿論、sc_clockを使っていない段階で、恐らくHDLとの
Co-Simulationはきっとムリですね。うーん、でも、これはちょっと……
ですね。

間違えました、timeout付きwaitはsc_eventに対してのみサポートされて
ますね。本当に、すんまそん。

どうやら、私が記述したい内容はSystemCでは、やはりRTLを用いるしか
方法が、最も自然なようですね。

勿論、クラスライブラリを直接いじれば何か出来るのかも知れませんが。
sc_event classにパブリック変数を導入して、wait(e1|e2|...|en)で
受理したイベントの変数を更新するよるwaitをオーバーライドするなり
して作成し、必ず、waitを抜けた後で、その変数をユーザがクリアする
とでもすれば良いんですかね？

もう、ここまでくると何か病的な気がするのですが、気のせいでしょうか？

というか、SystemCはC++なんだから、これ(クラスライブラリの派生クラス
なりの作成)は、どちらかというと当たり前で、これ位は出来ないと使い
こなせないという事なのでしょうか？

もし、そうだとすると、私には、かなり荷が重いです……。　ｏｒｚ

#include "systemc.h"
#define EVENTSU 3
SC_MODULE(he){
sc_in<bool> sck;
void prd();
void loopp();
sc_buffer< bool > hohe[EVENTSU];
SC_CTOR(he) {
SC_THREAD(prd){sensitive<<sck;}
SC_THREAD(loopp){
sensitive << sck;
for(int i=0;i<EVENTSU;i++) {
sensitive << hohe[i];
}}}};
void he::prd(){while(1){wait();hohe[rand()%EVENTSU] = 1;}}
void he::loopp(){
while(1) {
wait();
for(int i=0;i<EVENTSU;i++) {
if(hohe[i]) {cout << "hohe" << i << endl;hohe[i]=0;}
}}}

int main() {
sc_clock sck("ck",10);
he *he_inst = new he("hoho");
he_inst->sck(sck);
sc_start(1000);
return(0);
}
とりあえず動いたので、うPします。（こんなんで良かったっけか？）
酔った勢いスマソ。

実例を挙げよと言われてとたんに来なくなった奴が一匹居るわけだが。

>>
申し訳ないですが、全く違います。すいません。

clock以外のイベントでwait()を抜けても、クロック遷移をしてもらわないと
困るのです。

この問題は、きっとご提供頂いたコードでは解決不能だと思うのですが、
どうでしょう？

間違っていたら、すいません。

>>588
本当にご教授頂き有難うございます。結局、wait()を抜けたのが、
clock eventなのか、clock以外のeventなのかを識別する必要が
でます。逆に、これさえ可能なら、多分大丈夫のような気がします。

その実現方法として、sc_time変数を用いて、10ns経っていなかったら、
抜けてきたwait()の前にJumpするとかいう風に記述することになって
しまうような気がとってもするのですが、これって、RTLですよね？

やはり、>>589 の方が責めてらっしゃるであろう方の意見「複雑なことを
記述しようとするとSystemCではRTLでしか記述不能」が正しかったという
事なのでしょうか？

それは悔しいです。何とか、RTLっぽくない方法で解決する方法はない
ものでしょうか？ エロイ方、何卒宜しくお願い致します。

ある意味当然だと思う。
結局はやりたいことを事細かに書かないと高速化も実回路もあったもんじゃないってのは
HDLでもおなじだわ。

実回路を意識せずアルゴリズムのみの検証をした後結局RTLで書き直しなんて事になるので
あれば、Verilog、VHDLで開発しているのと余り変わらない気もする。
取り敢えず動作する回路をでっち上げるには、問題が無いレベルまでは来てるのかね？Cも。

今のところ仕事で使う予定がないからDWMを読んで「ふーん」程度で終わってるが。

三年後には現場に降りてきてるだろうか？

#include "systemc.h"
#define EVENTSU 3
SC_MODULE(he){
sc_in<bool> sck;
void prd(),loopp();
bool prev_sck;
sc_buffer< bool > hohe[EVENTSU];
SC_CTOR(he){
SC_THREAD(prd){sensitive<<sck;}
SC_THREAD(loopp){
sensitive << sck;
for(int i=0;i<EVENTSU;i++) { sensitive << hohe[i]; }
}}};
void he::prd(){while(1){wait();wait();wait();hohe[rand()%EVENTSU] = 1;}}
void he::loopp(){ prev_sck=sck;
while(1) {
wait();
for(int i=0;i<EVENTSU;i++) {if(hohe[i]){cout<<"hohe"<<i<<endl;hohe[i]=0;}
if(prev_sck != sck){prev_sck=sck; cout <<"ck!"<<endl;}
}}}
うーん。いい加減なところあり。。
こうなると抽象度（？）をあげたほうが良いかも。クロック同期で
クロック間の別いべんとはキューイングしちゃだめなのか？
（イベントキューと言えば、SysC2.1はどうなったんだ？おしえてエロイ人）

>>592
『一匹』とおっしゃっているのは、C++＆Templateﾏﾝｾｰ な方の事なので
しょうか？

確かに、その方ならどうやってSystemCやC++で実現されるのか、とっても
伺ってみたいですね。

　[記述したい内容]
　　１．SC_THREADを用いたサイクル精度記述
　　２．clockを含む複数のeventを受けて動作
　　３．waitが受けた(起こされた)eventを識別して動作を切り替え
　　　　(event、または／及びサイクルごとに動作が異なる)
　　４．clock以外のeventが来ないクロックサイクルあり

見ていらっしゃったら、何卒宜しくお願い致します。

>>593
本当に、有難うございます。以下に、ご質問を記載致しますので、
ご回答お願い致します。


#include "systemc.h"
#define EVENTSU 3
SC_MODULE(he){
sc_in<bool> sck;
void prd(),loopp();
bool prev_sck;
sc_buffer< bool > hohe[EVENTSU];
SC_CTOR(he){
SC_THREAD(prd){sensitive<<sck;}
SC_THREAD(loopp){
sensitive << sck;
for(int i=0;i<EVENTSU;i++) { sensitive << hohe[i]; }
}}};
void he::prd(){while(1){wait();wait();wait();hohe[rand()%EVENTSU] = 1;}}
void he::loopp(){ prev_sck=sck;
while(1) {
wait();
for(int i=0;i<EVENTSU;i++) {if(hohe[i]){cout<<"hohe"<<i<<endl;hohe[i]=0;}
if(prev_sck != sck){prev_sck=sck; cout <<"ck!"<<endl;}
}
wait(); // <- これ入れても本当に大丈夫ですか？ たまに、sck以外で
　　　　//　　動いてしまうような気がとってもします。
}}


ちなもに、仕様は >>594 の[記述したい内容]です。looppがそこで言う
SC_THRAEDに対応します。で、これ以外の縛りはないものと考えて頂いて
問題ないです。

あっ、サイクル精度記述と言う意味は、wait()をクロック境界と考えている
記述だという事です。が、明確に、クロック境界を記述可能なら、この規則
に縛られる必要はないです。

>>595　SCK以外で動きますよ

>>596
＿|￣|○　いままでの記述例全部忘れてくれ

ですよね。私はもう解らないのですが、やっぱりsc_timeでclock eventか
否か判断して、clock eventでない場合は、抜けてきたwait()の前へJump、
という方法しか、サイクル精度記述を保持する方法が思いつかないです。

別にクロック同期である必要はないとは思いますし、wait()からwait()
が実際の実装のサイクルと合って無くても良いとか思うのですが、やっぱり
ある期間ごとに処理を記述する、というのが解り易いのではないかと
思うのです。

相手のThreadがこういう動作をしているとき、このwait()は、このeventで、
この動作のときはクロック境界で、なんて記述も可能ですが、ちょっと頭が
付いていきそうにないというか、バグのないように管理するのが私には
辛い気がしてならないです。

>>597 さんは、そのような記述を意図なさっていらっしゃるのでしょうか？

乗りかかった船さん、
>>599 の「ですよね」は>>597に向けての言葉であって、決して>>598に
対しての言葉ではございませんので、くれぐれもご立腹なさらないで
下さい。すいません。

レーシングは本当に難しいですね。

今までの記述であっても、>>599で述べさせて頂きましたように、「相手の
Threadがこういう動作をしているとき、このwait()は、このeventで、この
動作のときはクロック境界で」という記述が可能なら、十分参考になると
思います。ただ、私は使いこなす自信がないですが。すいません。

#include "systemc.h"
struct hohe_if:virtual sc_interface{ public: virtual void fuhe(bool a)=0; };
SC_MODULE(he),public hohe_if{
sc_in<bool> sck;
void loopp(), fuhe(bool);
SC_CTOR(he){SC_THREAD(loopp){sensitive<<sck.neg();}}
};
void he::fuhe(bool a){cout <<"キター(ﾟ∀ﾟ)！"<<endl;
/*メッセージをキューに積む*/
};
void he::loopp(){
while(1) { wait(); /*ここでキューをチェック*/ }
}
//---
SC_MODULE(prd){
sc_in<bool> sck;
sc_port<hohe_if,1> port_out;
void loopp();
SC_CTOR(prd){SC_THREAD(loopp){sensitive<<sck.pos();}}
};
void prd::loopp(){ while(1){wait(); port_out->fuhe((bool)1);}
}
int main() {
sc_clock sck("ck",10);
he *he_inst = new he("hoho");
he_inst->sck(sck);
prd *prd_inst = new prd("foo");
prd_inst->sck(sck);
prd_inst->port_out(*he_inst);
sc_start(1000);
return(0);
}
//SystemCのexampleのSimpleBusを参考

>>SystemC勉強中
下らんこと書いていちいち上げるな。
ブラウザの使い方から勉強せぇ。アホが！

>>601
本当に有難うございます。

SC_THREAD間の同一サイクルでのデータ転送を可能とするために、キュー
を準備し、キュー内のメッセージのチェックを立下りエッジ同期で行う、
という事ですね？ これなら、サイクル精度記述も保持されていて大丈夫
ですね。素晴らしいです。本当に有難うございます。

ただ、SC_THREADが３つ居て、１−＞２−＞３と同一サイクルでevent
(メッセージ)がスルーで加工されながら抜けていく感じとか、２個でも
１−＞２、リターンで２−＞１的感じには拡張できないような、そんな
気がしますが、そんな記述をRTLを用いずにSC_TREADで書こうという態度
そのものが間違っているんですよね、きっと。ここまで複雑だと、やっぱ
り、諦めてRTLを使うしかないんでしょうかね。どうなんでしょう？

>>602
？？

このスレ、結構勉強になって良いと個人的には思うのですが。私が
間違っているのでしょうか。何だか、ご立腹のようですね。すいません。

>>603 そのへんになると。。
また別の方法が（1->2->3の場合は4相にするとか。。（速度はおちる））。
自力で考えてみてくれ
>>604 E-mailのところに「sage」って書いてちょーだい

>>605
本当に有難うございます。1->2, 2->1も３相とかで対応できそうですね。

ただ、何れにしても、３個以上とか、双方向でのデータのやり取りがある
場合は、データ通信の順番が予めある程度静的に決まっていないと辛そう
ですね。

実行順が完全に決まっているなら、共有変数にデータを書き込んでから、
event.notify()して、wait(event)で抜けてから、共有変数を読む、という
のが一番簡単ですね。適応場所を限定すれば、これも使えるような気が
します。

抽象度の高い世界では、バスシステムなんかもそうですが、シナリオみたい
なものがあるので、完全ではないにせよ、通信の実行順というがある程度
決まっているでしょうから、恐らくはご教授頂いた方法で何とかなるのかも
知れませんね。

ただ、システムの全体像が見えない状態でボトムアップ的に記述しようとする
とかなりハマりそうですね。システムの全体像を見て記述する、というのが
SystemCの運用で一番大切な事なのかも知れないですね。

>>604
どこの世界にもくだらんことに言いがかりつけて
威張り散らすチンピラはいるものさ
はいはいといなすのは賢い知恵だが
あんまり気にしなさんな

>>606
>完全ではないにせよ、通信の実行順というがある程度
>決まっているでしょうから、恐らくはご教授頂いた方法で何とかなるのかも
>知れませんね。
>
>ただ、システムの全体像が見えない状態でボトムアップ的に記述しようとする
>とかなりハマりそうですね。システムの全体像を見て記述する、というのが
>SystemCの運用で一番大切な事なのかも知れないですね。

この一連のやり取りでそこまで理解できた点でご立派です。もうお気づきかと
思いますが、何故SystemCでできないか、ではなく、何故SystemCでは
やりずらいか、を理解できれば十分です。

SystemCで抽象度をあげると、こうなるので具体性が要求されると
どうすりゃいいんだと言うことでしょう

> 何故SystemCでできないか、ではなく、何故SystemCでは
> やりずらいか、を理解できれば十分です。

どうやら、システムの全体構成を把握しているという前提があって且つ
苦労すればSystemCで何でも記述できる、という事が明らかになった
みたいやね。

でも、この一連のやりとり見てて思うけど、何を意図してそう記述した
のかを自動で判別できんと、合成なん無理やん。いうか、２相とか４相
とかのクロックって、ブロック図での信号線を無理矢理表現するための
もんやろ？ これを、実は信号線なんですわ、って言われてもなあ。

やっぱり、SystemCは、ごく一部の人のためだけに存在するもんなんやね。

やっぱ、晒し上げ、やね。

どう表現したらいいのだろうね？
具体的記述の話をしろと言われたらとたんに消え、結論が出た頃に
的外れなことを言いに来るとはな。

皿仕上げってのは自殺のことか？

おもしれぇな、ここ。よく分ってるやつは口をつぐみ、てんで分ってない奴らが
騒いでやがる・・・まあ、技術先行してるから、表に出したくない気持ちはよく
分るが、少しぐらい情報出せや。

>>613
合成を意識していない記述を合成しようと考える >>611 はバカって事？
それはそうかも知れんが、現場とか上の要求ってそんなもんだよ。

　「折角SystemCの資産があるんだから、何とかしろ！ 」

　「まさか書き直せなんて言わないよね？ 百万歩譲って書き直す
　　として等価性検証くらいはサポートしろよな！ 」

とか、もうねアホか、バカかと。出来ないものは出来ないのよ、どう
あがいてもね。

>>614
所詮はC++だという事実と、合成を意識しない記述はどうする事も出来ない
という事実しか初めからないが、何か？

所詮はＣ＋＋だから合成されることを前提としてシステム
の挙動を考えてはならない
とな。

取り敢えずは、「同じID」で具体的にどう使うのか、どうFPGA等に
実装するのかを語れ無いのであれば、実際HDLも使ったことのない
たんなる口だけ厨って事で終わりにしたいよ。

>>617
自意識過剰バカ、ﾊｹｰﾝ（ｗ

>>617
実際に設計で役立つSystemC記述は合成できないのが前提だし当たり前。
どっかのプリンタメーカが想定してるとか言ってたけど、業界じゃ、
内部で「誰が使うんだあ、ﾊｱ? 状態」だってのは実はバレバレなんよ。
なので、SystemCを記述しようが結局は、シコシコRTLを記述する事に
なるんだよ、現状では。というか遠い将来に渡ってね。で、RTL以降
の説明も欲しいの？

なんか変なのが釣れたが何これ？

>>620
釣りだったのかあ……　ｏｒｚ

まあ、嘘は言っとらんので参考にしてくれ。

多分よく読んでないと思われ。
Cマンセーの馬鹿に出てこいと言ってるのに何故か頓珍漢なレスを返してる。
もしかしたらC厨の自演かもな。

なんと言っても連続で同じIDで書き込みしてるし。
と、突っ込みを入れると今度は二度と同じIDが出てこなくなるであろう。

>>622
そ　う　だ　っ　た　の　か　あ。

鬱出汁脳……。

>>662
ちなみにあんたは何がしたいんだ、このスレで。

662なんてありまへんがな。自爆　ｏｒｚ

>>622　の間違いね。スマソ

誰がどう見てもよく読んでない馬鹿＝ID:XH+BjicC

面白いから、ＩＤ変えるのやーめた。実力のない人たちって面白い！
誹謗中傷するのが大好きなんだね、やっぱオタクって。素晴らしい！！
否定するのも大好きらしい。生産性なくていいね☆

>>626
どうでも良いからHDL又はCの事を書いたら誰もが君を認めるだろう。
それ以外で実力を示すことなど出来ないわな。

>>627
じゃあどうして君は書かないの？

　　パイプライン乗算器のＣ記述
　　int　A,B;
　　int　MULT;
　　int　cnt;

　　main() {
　　　int　t1,t2;
　　　cnt = 0;
　　　MULT = 0;　//　しょきち
　　　A=B=0;　　//　しょきち
　　　while(1) {
　　　　MULT = t2;
　　　　printf("MULT = %d\n", MULT);
　　　　t2 = t1;
　　　　t1 = A*B;
　　　　printf("A = %d, B = %d", A, B);
　　　　printf("clock boudadary (%d)\n", ++cnt);
　　　　input();
　　　}
　　}
　　void input() {
　　　A = rand()/(RAND_MAX /100);
　　　B = rand()/(RAND_MAX /100);
　　}

ちなみに、私はSystemCﾏﾝｾｰ じゃないよ。

>>628
これって、YXIのeXCIteのマニュアルからパクッたの？

というか、文書整形とかでAWK使うけど、確かにこんな感じに記述するよね。
このテク使うと、ファイルを一回なめるだけで済むから、AWKのクセに処理
も結構早いし。DCとかPTのレポートファイルの加工に結構イイ感じで
役立つよね、このテク。

>>617
なんか粘着してるみたいだが言ってる意味わからんよ。あと、一方に
合成含め、実装は別に考えろってのも全く的外れじゃないんだろ、この
スレ的には・・・で、何をやっきになって要求してるのかと。

>>630
だよね。

一般に、コンパイラが作成可能な言語は動作合成可能なんよね。だって、
プロセッサのROMに焼けば、ほらハードの出来上がり！

つまり、効率を求めないのであれば合成って何でもアリなんだよ。でも、
求めるでしょ、効率。となると、それに向けて記述を最適化しないとね。
組み込みミドルウェアとかって、アルゴリズムの独自性とかもあるのかも
知れないけど、対象としてるアーキに特化して最適化してるから、で、
それがそんな簡単に作れないから、商品価値を持つわけでしょ。

> 合成含め、実装は別に考えろってのも全く的外れじゃないんだろ
というかコレが、正に真だあよ。

言いたいことは判らないでもないけど、かなり的はずれだと思うけどね。

いやいや、これが動作合成の開発を実際にやってる人間の心情だよ。

つまり
×動作合成の開発
○動作合成ゴッコ
ってことか

>>634
まあ、そんなようなもんだね。プログラムの標準形みたいなものが恐らく
存在しないだろうから、こればっかりはどうしようもないんだよね。

それでも中間表現とかを頑張って、標準形っぽくしようと努力したり、
超コンパイラの技術を参考に発展させたり、と努力は惜しみなくして
いるらしいんだけどね。

確かに、この発言、米国の動作合成で有名な背の高い教授にして、
エラクどやされた事があった、とか言ってたね。まあ、人間、本当の
事を言われるとムカつくから、仕方ないんだけどね。

痛い自演の応酬か。
なんか可哀相な奴。

私、ID変えないよ。変えると面白くないもん、だって(笑)。

>>636
　>>626 をもう一度読んでね☆

前のもそうだけど、いくらなんでもこんな下手な自演ないだろう・・・
IDのベースがドメインベースとかそんなんじゃないの？スレごとに
そういうの指定できるかどうか、分らんけどさ。
つか、すぐ自演とか条件反射するの頭悪すぎるよね。HWコーディング屋
って、頭堅そうな奴多いけど、イメージ固定されてきたよな、このスレで。

Panel on standards talks of ESL progress
http://www.eedesign.com/news/showArticle.jhtml;jsessionid=EOGH3SWCDXWBCQSNDBESKHA?articleId=55300526

Another member of the audience asked whether some sort of consensus
was building around transaction level modeling as a level of
abstraction above RTL and whether this would allow automated
methods to develop to take designs from SystemC to VHDL or Verilog.

Synopsys' Kunkel answered by saying that while top-to-bottom
synthesis had been largely discredited, the use of "channel"
synthesis to define interconnectivity between blocks and where
necessary develop RTL patches was being used and the way forward,
a point of view endorsed by fellow panelists James Colgan,
director of strategic alliances at Sonics Inc.

For ST's Clouard the important thing to stress was that even
without automated movement between the transaction level and
the RTL, the use of TLM more than pays for itself in terms of
speeding up chip design, selecting appropriate blocks and
allowing early software development.

【要約】
　会場からの質問：
　　SystemCのTLM記述からHDLのRTLへの合成ってどうなの？

　支那腐死巣
　　トップダウンに合成するのは諦めて下さい。HDLのRTL記述を用意して
　パッチ的にチャネル記述部に割り当てるような操作を明示的にユーザが
　行うという前提に立てば、出来る可能性はあります。
　
　餌巣手舞黒
　　合成なくても、Simulationが高速化できるから設計期間の短縮が可能
　です。SystemCﾏﾝｾｰ です。


　【結論】このスレの議論と同じ結論。為になるね、このスレ☆

まあ、餌巣手舞黒はU.C.Berkeleyに研究所を持っていて、そこでSystemC
によるTLMを用いた設計手法とかツールの研究を、結構根気良く続けてた
からね。

支那腐死巣の回答は、>>611 を読むと非常に納得です。はい。

Nikkei Electronics の2004.12.6号に特集があります。
NEシーやめのつけどころが鋭い会社が既に実用化してるようですね
EDAでは緬汰がやはり製品だしてるようだけど。
それでもやっぱり無理なのかな？
特集記事の表紙には、うちの会社も2005年から本格適用って書いてある。
本当かよ！！
マンセーの会社じゃないけどね

あの特集ってCとC++、SystemCをごちゃまぜにして語っている
のがどうにも許せんなぁ。

＞うちの会社も2005年から本格適用って書いてある。
頑張って、大本営発表でない実情をここで暴露してくれたまへ
それが多くの人民の命を救うことになるのだ

いいすよ
部外者だし。
うちの部門は●投げで設計はほとんどなし、
漏れは仕様書書くのと検証で精一杯。

出向でハード屋さんが来てるけど、
彼らにはSystemCの教育かね出してもらって受けさせてる。
社員の名刺持ってるからここの人間が受けてると思ってる、
のは誰でも知っている有名な新横浜の会社だけ
SystemCコース受講すれば明日からバリバリ設計者になれると思っているアホ下請け。
特定されるからこのくらいにしとこ。
でも、社内セミナーでこれからは社内で何でもできるような事、
systemC検討の部門はほざいてた。
HDLの設計者もいないのにどうするんだよ。いきなりSW専門の派遣受け入れやがって.

>>643
お前もなんか暴露しろ！

あ　もひとつ暴露
たぶんうちだけじゃないと思うけど。
無料のソフトは設計では使ってはいけないことになってる
資産計上できないから無理無理無理
だからOSCIさんの一所懸命作ったRefシミュレータは、
結局個人でダウンロードさせて貰いました。
実際は使ってないけどね。
間違えて6回ダウンロードしてるから、
去年1万5千回の数はユーザ数として当てにならないよん
たぶん1/6だと思う実際のユーザ数は
SW屋さんにHW作らせようという魂胆は間違ってるよ
分かるわけ無いからね。レースって何？だって帰れお前！

あげ

日経エレだれも読んでいないのかな？
明日読んでね。

記者

うそだぴょーん

>>641
いわゆる、いんたーふぇーす合成ってヤツね。しかも、いんたーふぇーす
ライブラリベースの。この技術なら、もう十年くらい前に研究段階を終えて
製品化されてるよね。

かなり早い時期からサポートしてるのは、

　　CoWare　：HW/SW 間のI/F合成

　　Arexsys ：HW/SW 間のI/F合成、動作合成

　　YXI　　 ：動作合成

だね。最近では、経営がとっても不安定な日本のEDAベンダとMentor
がサポートしてるね。そういやSTRACでもVCDSとかいう、お取り潰しになった
プロジェクトで、研究というか単なる猿真似というかをやってたね。

でも、この技術の問題点は、いんたーふぇーすライブラリの構築が非常に
困難だという事なんよね。なので、ベンダが用意して提供(販売)するという
形でしか普及してないんだな。実際、CoWareとかMentor見てそうでしょ。
AMBAに関数コールで繋がります、ってのが売りだもんね。

という意味では、>>472 は神発言かも！　取り合えず、再掲。

> このProprietyなlocal busをアプリによってパアメトリックに自在に再構成
> できるの技術が既に存在するんだね。しかもこの部分に関しては、RTL生成
> が可能。ユーザロジックが合成できないので、その部分に関しては
> HW設計という観点からは2度デマになるのは皆さん、ご指摘のとおり。
> SW設計プラットフォームという観点からは、今後期待が持てそうかな・・・

そう言えば、2003年のDACでCoWareが独自バスのモデル化ツールを作った
とか言ってたよ。確か、汎用的かどうかをCore Connectバスかなんかを
実際にモデル化する事で確認してるとか言ってたね。で、CoWareはCadence
と組んでいて、Cadenceでは >>482 のように頑張っていると。

ただ、ハードのいんたーふぇーす合成は、YXIが一番先行していたハズなん
だけどね。こんなのもあるし。

日立，SHベースのシステムLSI開発ツールとして，米Y Exploration社の動作合成ツールを採用
http://ne.nikkeibp.co.jp/members/01db/200106/1009606/

どうなったの？ 関係者の方、情報きんぼんぬ！

これからはSystemCを使って動作合成でしょう
http://www.hdlab.co.jp/service/hdt/mokuji_pdf/SystemC_syn.pdf

悪名高き動作合成ツール君って話しになんねぇー ｏｒｚ

ちなみに、そこらにあったＣ記述から合成可能なSystemC記述作るのに
相当苦労して、且つバグだらけで合成結果が１月経っても２月経っても
返って来ないという、非常に香ばしい感じ。まあ、妄想だったのかも
知れないが。

是非、評価を積極的に行って、我々が費やした以上の時間と金を無駄に
消費して欲しいものです。

>>651
このスレでの評判は、↓↓↓
　>>443　>>447　>>619

ふむふむ、なるほど。ちょー納得かも。

制約守ればできるということかもしれないが
あんなにゲート数がおおきくなるんじゃ、チップ面積大で
使えないのと同じ

>>652
>我々が費やした以上の時間と金を無駄に
>消費して欲しいものです。
詳しく教えてくれませんか？
いつ頃の話ですか？少しは改善を期待してると、後追い決めてたけど
来年度評価開始考えてるけど無駄になるのやだな。
大手が採用決めたからって営業の人言ってたけど、
結局>>652の会社は買ってしまったその大手？
>>651
これ受講してみようかと思ったけどやめたほうがよさそ
本当の情報が欲しいけど、誰も教えてくれない。

採用決めたor決めそうなのは、西と東のS社って言ってましたが、>>652は西??

>>652 >>654が同じ人とは思えないので、西のSと東のSがここに揃ったって事
このスレッド役に立つね

早く教えてくれ
その後なんでやっぱり決定したのかを

RTLでの論理合成を育てた日本の会社ってどこなんだろう？誰か教えて。
そのときの苦労をここで共有したいよね。
それこそ役に立つ話がきけそうです。　お金いくらかかったのかなぁ？
動作合成バブルは何処が受け取れるのでしょうか？
来年、支那腐死巣は屍か、抜け殻らしいですね。
大変そう。外資EDA社員さんにエールを贈ろう。

http://www.forteds.com/news/pr082504sanyojapanese.pdf
西のsの記事
実名ででてるけどとりあえず
教えて

>>685
技術力が理解できない権限だけがある幹部クラスに、ビジネスミーティング
だと突然最初に宣言し、あまつさえ技術説明を避け、技術的質問をしよう
ものなら、「ビジネスのお話しですから」と語気を強めて回答し、こちらに
非があるかような振る舞いを平然と行う「トップセールス」なる詐欺まがい
販売活動をその生業とするような売国奴に同情の余地は無い。逝って良し！

>>658 だった
それでも、技術的質問をしようものなら、「担当の方はやる気がおあり
ですね、早速パートナーシップ契約に話しを進めましょうか。」と来る。
質問が詳細だと、「パートナーシップ契約をご締結頂かないと……。」
と来る。実に計算されている。素晴らしい。巷にある詐欺まがい商法
そっくり、イヤそのものだ。理系人間はそういうのに弱い。引っかかっても
仕方がないのかも知れない。

「理系から金を毟り取る文系」という縮図を垣間見た気がする。

外資系ＥＤＡベンダ、逝って良し！

>>660
よほど外資EDAに恨みがあるみたいですねー
同じような人がここにもいますよ
同一人物？　図kenさん？
http://tmp4.2ch.net/test/read.cgi/company/1093497747/452

Verilogの導入時、DCの導入時も同じようなもの・・・

「言語で回路を記述するだと、アホか」
「機械(w)が作った回路が動作するわけないだろ、第一サイズが
でかするぎるよ」
「回路はテンプレートで紙に書くものと昔から決まってんだよ」
「・・・・」

時代を先行するということは、今の技術の範疇では判断不可能な
部分もある。それなりのリスクが必要ということ。ビジネス提案に
対し、その程度の認識なら、言われたことやってば良し。

所詮、頭の固い時代遅れの技術者は、邪魔なだけ。逝って良し！

そう？漏れの所では「いいんじゃない？細かい所はゲートレベル
まで書けるし、テキストエディタでいいし」だったよ。
だいたい、あれはちゃんと合成して最終段階まで持って行けた
じゃん。だから、多少生成されたものの効率は悪くても、それに
見合うだけのメリットを見いだしてやることができた。
C合成だって、ちゃんと合成して石にするところまでいける。

でもSystemCは・・・事実上シミュレーションだけ？
もし、システム記述＆シミュレーションだけというなら、
Schematic Vs Verilogと比較しようなんていうのは思い上がりも
甚だしい。

>>664
後からならなんとでも言える。
リスクテイクせずに、恩恵だけ受けたやつが偉そうなこと言うな、バカタレが

恩恵を受けるのがいるからこそ普及するのだ。
それが判らん奴は共産主義国にでも逝ってろ。

>>666
リスクテイクして、恩恵を実証してるやつがいるから、初めて恩恵を
受けることができる。別に後追いのやつらなどが恩恵受けなくても、
普及するからOK。もともと日本は半導体もシステムもメーカが多すぎ。
きちんとリスクテイクしてくれている企業が設けてくれればそれで十分。

>それが判らん奴は共産主義国にでも逝ってろ。
競争原理の理解できないお前のような奴こそ、逝ってくれ。

>>663
ちゃんと、>>639 嫁！ >>664 の主張は非常に的を得ていると思うが。

SystemCはHDLの合成可能なRTLと混載、または対応付け、という技術が
ちゃんと商用化されてからでしょ、合成は。先行メーカはSimulation
環境立ち上げ一辺倒ってのが正直な所。中には、本気で合成は無理
だと割り切っている先行大手もある位なんだから。その意味での普及
であって、HDLの普及とは性質が大きく異なる。

HDLとSystemCでは抽象度の向上のステップに大きなギャップがあり、それは
未だに埋められていないし、今後埋められる事がないかも知れない(多分、
無理、だってSimulation速度重視のための抽象度と、合成重視の抽象度は
余りに大きく異なるし、合成重視の抽象度でのSimualtion高速化は非常に
困難だから)。なので、>>639 のようなハイブリッドアプローチというのは、
「Simulationは高速に、一方で合成結果は最適に」、という我侭な要求に
答えるための妥協策として必然。

>>668
それが解ってたらあんな間抜けなレスはしないであろう。

えーっと、これってもしかして……。

>>652 >>653 >>660 >>661 はIDが同じです。という事は……。

15年前（ぐらい？）、合成なんて使い物になると思ってる奴なんか
一人もいなかったように記憶してるがな・・・できるできないという議論
よりmindsetの話をしてるじゃないの？やっぱり、技術の枠組みから
一歩も踏み出すことのできない頭の固いHW設計者の実態が浮き彫りに
なってるな　藁

技術の話にもどると

>Simulation速度重視のための抽象度と、合成重視の抽象度は 余りに大きく異なるし

これは的を得た指摘だ。しかし、間を結ぶ技術はできつつある。要するに片方の
抽象度で全てをやろうと思わないことだ。また、ふたつのモデルを作るのか、
などと的外れな質問しないように・・・それでも来そうだが・・・ヤレヤレ

>>671
> 間を結ぶ技術はできつつある。要するに片方の
> 抽象度で全てをやろうと思わないことだ。また、ふたつのモデルを作るのか、
> などと的外れな質問しないように・・・それでも来そうだが・・・ヤレヤレ

このスレで >>671 は何がしたいのだろう？

> また、ふたつのモデルを作るのか、などと的外れな質問しないように

これは、詐欺師と同じ手口の文言だね。

というか、>>671 は先ず、>>649-650 を嫁！で、「仮にパラメトリックな
ライブラリが構築可能と言っても、そのサポートシステムを考え出した人間
が想定していないような事が起こるとどうしようもなくなるんだよね。でも、
それが出来てこそ、商売が出来るんだよな。」というのを踏まえて、回答を
ここに晒してもうらおうじゃないか。

まさか、

　「インターフェースライブラリの開発は受注案件です。」

とか寄生虫商売考えてんじゃないよね？

まあ、他社の作ったツールのトレーニングで金儲けようと思っている時点で
十分寄生虫だよね　＞　>>651

>>671
向学の為に、>>547 も嫁！

>>671
俺はあんたを支持する

笑えるくらい同じID

>>675
そう、面白いでしょ(笑)。ID変えない方が。

>>674
じゃあ、頑張って投資してネ♪ そうすりゃ、>>652 の思惑通りになるなあ。
何か悔しいかも。

ID変えるの変えないのと、くだらんことを・・・
燕雀いずくんぞ鴻鵠の志を知らんや

>>677
大きく出たねぇ〜。じゃあ、頑張って巨額の投資を行って、皆が使える様に
する事で、その大志を貫き通して下さいな(笑)。

動作合成ツールを利用するのにRTLライブラリを構築しないとイケナイなんて
何か矛盾してるよね。その点、支那腐死巣の論理合成ツール君はしっかり
してたよね。演算器コンポーネントのライブラリを提供してたもんね。

そう、もうお気づきだろう。動作合成では、持つべきライブラリの複雑度が
増していて、初めから想定して全てを構築するのが非常に困難なんだよね。
世の中の動作合成ツールがイマイチなのは、AMBAインターフェースを除いて
論理合成と同程度のライブラリしかサポートしてないって事なんだよね。

でも、ライブラリのあるべき姿さえはっきりしないのが現状。さあて、
大志を抱いていらっしゃる >>677 さん、納得がいくように解決策を
ここに晒してもらいましょか！

>>678
>納得がいくように解決策を
>ここに晒してもらいましょか！

その手にのるか
アフォにすな

>>679
つまり、アイデアがない、或いは、あるのかも知れないが、大したアイデア
ではない、って事ね。まあ、そんなもんだろうね。

そういや、RTLリユースがうたい文句の動作合成ツールってあったよね？
あれって、どうなったんだっけ？

べー

＞15年前（ぐらい？）、合成なんて使い物になると思ってる奴なんか
＞一人もいなかったように記憶してるがな・

記述から落とすということなら、ＰＡＬの時代からＰＡＬＡＳＭ
だのって使わなかったか？ヒューズマップ一本やりでやってたのか？
もうちょっとややこしい物だって書いて落とせるようになるよな・・と
普通の感覚してる香具師なら思ってたよ。

ごきげんよう暇人ども

"RTLリユース" 動作合成　でググったら、何も出て来んかった……　ｏｒｚ

でも、"IPリユース" 動作合成　でググったら、トップに

　[PDF] Y Explorations 社 C 言語高位合成ツール「eXCite」 ...
　http://lsi.soliton.co.jp/others/040930_excite1_nr_j.pdf

が出来てきた。どうやら、ANSI-Cベースだが、RTLのリユースも出来る
らしい。

>>684
元◎立君
こんな所で釣りはやめたまえ
◎立 systemc でっググったら　トップになんと

◎はお日さまのことか？　なるほど

>>685
◎立 systemc でググると
　　日立IT ニュースリリース 新世代設計規範 ...
　　http://www.hitachi-it.co.jp/news/030101.htm

日立 systemcでググると
　　日立ＩＴ｜製品情報｜論理記述言語 ...
　　http://www.hitachi-it.co.jp/dvedu/sysc/

？？？

いけね　釣り手伝ってしまった

>>671　
禿同（余談だが的を得たではなくて的を射ただ）

>>689
> ふたつのモデルを作るのか、などと的外れな質問しないように・・・
> それでも来そうだが・・・ヤレヤレ

この部分にも賛同するの？

だから二つのモデルは必要ないんでしょ・・・
それだけで、どういう流れになるかすぐ分るよ。で、俺的にはなるほどな、と。
合理的かつ現実的な解だなと、思うわけだな。

>>682
いわゆるSilicon Compile社が最初提唱きてきた合成のことをいうのであって、
PALはその中に含まれないんじゃないの？PALは期待通りのものができるよ。
つか、ありゃ変換だべ　ｗ

>>690
あ。しません（悩みどころなんだが）

あげちゃった。すまん

ハードウェアアルゴリズムは、
並列性、コスト、遅延時間の制約などソフトウェアアルゴリズムと異なる点が多い。
そのため様々なハードウェアアルゴリズムを使い分ける必要がある上に、
演算のスケジューリングとリソースの共有化を考慮する必要がある。
簡単な例として、入力を複数の定数で乗算した結果を出力する複数の
定数乗算回路(MCM)を考える。
定数の乗算は部分積のシフト加算に置き換えられるが、
乗算器を個別に合成するより、加算の順序を入れ替え、
演算器を共有した方がはるかに小さい回路となる。しかし、
問題は同一の機能を満たす回路は多数存在するということである。
特に機能が複雑になるとその組合せは膨大な数になり、
すべてを調べることは非現実的となる。
このような膨大な組合せの中から
最適なものを発見する問題を組合せ最適化問題と呼び、
最近、人工知能の分野で発展してきたシミュレーテッドアニーリング(SA)、
遺伝的アルゴリズム(GA)、
タブーサーチ(TS)などの知的最適化アルゴリズムが様々な分野で応用されている。

このような最適化アルゴリズムを利用すれば、
回路モデルとその評価式を与えるだけで、
ハードウェアとして最適化された回路仕様を自動的に合成することが可能となる。

>>691
釣り？ てか、マジありえねぇー。高速Sim用のSystemCモデル、書いた事
ないっしょ？

>>695
だから、腐汚流手はDSPアルゴリズムしか対象としていない、と断言する
わけだ。そうしたデータ演算系の設計なんて、実際の設計のごく一部なの
が現実。メモリアーキとかはどうするわけ？ 現状、これを自動で最適化
する技術は残念ながら無いよ。あったら凄いね、フォン・ノイマン・
ボトルネックとかプロセッサ・アーキテクチャの進化を自動で実現出来る
わけないからね。プロセッサ・アーキは芸術の世界だからね。

さて、支那腐死巣のSystemCのSimulationのメインエンジンを開発した張本人
が書いたこんな論文もあるが、それにはSystemCﾏﾝｾｰ の方はどう反論して
下さるのだろうか？ ちょと、見ものだね。

The Challenges of Hardware Synthesis from C-like Languages
http://www1.cs.columbia.edu/~sedwards/papers/edwards2004challenges.pdf
http://www1.cs.columbia.edu/~sedwards/presentations/iwls2004.pdf

この論文では、SystemC ＝ Verilog in C++、となってるね。

In summary, I believe the next great hardware specification language
will not closely resemble C or any other familiar software language.
Software languages work well only for software, and a hardware language
that does not produce efficient hardware is of little use.

まあ、これはちょっと言い過ぎのような気もしなくはないが。でも、気持ちは
物凄くわかるかも。

>>696
おまえ、GAなめてるだろ？
評価関数に全体処理速度を入れとくだけで
ネックになる箇所に勝手にキャッシュを入れるよ。

システム”設計用”の言語だとというから角が立つ
システム”検討用”の言語だと言っておけば良い

Genetic Algorithm
HALの世界観に近いけど分かるかな？
わかんないよね

>>696
>>691
>釣り？ てか、マジありえねぇー。高速Sim用のSystemCモデル、書いた事
>ないっしょ？

なんだよ、高速Sim用のSystemCモデルって？UTのことか？レベル低すぎて
なんのこと言ってるかわかんねえぞ。お前のようにお試しでモデル書いてる
ような奴と議論してる暇はないんだよ。
つか、情報足りなさ過ぎだ、お前。偉そうな口きくまえに、各社のProduct
Roadmapぐらい情報仕入れておけ、ボケが。

>>ALL
ここの話題の登場人物は世の中に利用されているLSIを設計
しているのですよね。お金稼いで、飯食ってるわけだ。ふう〜ん。
各社のロードマップか。ふ〜ん。
鬼畜なブッシュに先導される国に日本の技術者がジタバタとしている図。

オイオイ、このスレはEDA社員に盗聴されているらしいぞ。気をつけろ。
ふう〜ん。（自嘲）

HW設計って、オブジェクト指向型の設計なんですかねぇ。「そうなんだろうな」
と思うけど。だってさぁ。入りがチョット違うと、それなりに違った物が
出てくるわけじゃない。それってOODってやつなんでしょう。SystemCはC++の
バッタもんなわけだから、オブジェクト指向言語なわけじゃない。
まともにHW設計できないのは、C++が綺麗じゃないからかもね。
もともと、SW設計用の言語だからかね。
↑と同じIDです。先に逝っておかない（言っておかない）と怖いのでちゅぅ。

つーかHDLを導入して未だ十年も経ってないのに又大変革かよ勘弁してくれ
ってのが正直な所。
で、オブジェクトなんとかとかトップダウン云々言ってても仕様が流動的で
結局設計はボトムアップなんて事は普通だから、回路図がHDLに変わって
Simできるとかってメリット以外は力業の連続なわけで多分道具がCになろうが
この辺りは変わらないんだろうなと思う。
なもんで、使えるツールてか寺のツールが対応したら嫌でも導入って事になるだろう。
あまり感慨がないなぁー。
ぶー。

>>703
納得。最終形を見るな。その過程ってことね。じゃあ、何でも良いならSystemC
でも言い訳で。毛嫌いされるのはかわいそうな話である。ふむふむ。
昔は、DCもないし、Simもないし。その頃は、「ぶー」って言う場所もなし。
なるほど。
誰があの「マトリックス」の様な世界に連れて行ってくれるのだろう。
「ユビキタス」懐かしい響きだ。　「指切った」に聞こえる。
叙情。

言い訳で。→　良いわけで

c++もどきなんかじゃなくて、LSIがLabviewのような
もので設計できたらすごいよな。
極めて抽象度の高いGUIでデータフローを書くだけ。

一度Labview使えばわかるが、計測・制御目的にc++書くのなんて
馬鹿馬鹿しくてやってられなくなる。

究極的には何でも良いって点はまーそうだ罠。
生き残った奴が偉い。そう言うこと。
仕事の都合でVHDLとVerilog両方使えるのが割と当たり前なのがこの業界だし。
しかし、論理合成の癖を加味した記述とかRTLにかみ砕いた記述なんてのは今でも
当たり前だし道具が変わろうがこの点は暫くかわらんだろうさ。

Matlab+simulink→DSP
ってのが既にあるじゃん。

Labview→PSOCみたいなののもっとすごいの

っての誰か作ってくれよ。

>>708
納得。生き残りさえすればOK。死ぬなよ、諸君。
諸君、ツールに合わせてたばっかりに、自分のやりたいことを出来ない。
そんな思いは捨てて。
ツールの奴隷となれ！　さもなければ逝くしかない。

A氏：そこらへんのSystemCを信用するな。　************こと。　間違いない。
B女史：あんた、どこ見てんのよぉ。　（目を剥き、逆ギレ）<=逝ったEDA屋
C侍：って、　Youじゃない。　でも、SystemC君は*********ですから、残念。
***********斬り。拙者もLSI屋に厄介になってます。　切腹。
>>ALL
誰か**********を埋めてくれ。　私は逝く。
ドドーン。楽しかった。

つまらん

>>697
おまえ、キャッシュなめてるだろ？ 待ち行列理論で綺麗に最適化できない
のがネックなの知らないのか？ 汎用的になればなるほど、データの局在性
を分布で表すにはムリがあるからな。

それに、メモリアーキはキャッシュだけじゃないぞ。つうか、設計した事
あんのか？

SystemCの参考書、どんなの使ってます？

>>700
UT？ ﾊｧ？ >>280 は見たか？ それと >>385 への回答は結局 >>606 とか
>>608 。で合成への期待感が出てきたのは、>>639 。更に、それが現実的か
をきちっと議論しないとイケナイんだが、それにまともに答えようとして
いるのが、>>649-650 。

一方、>>671 は精神論しか言ってなくて何の信憑性もない。で、>>691 >>700
はそれを盲信しているだけ。流石に、根拠無くSystemCの合成が何でも可能
という風に話しを持っていこうとしいるとしか考えられないな、この３つ
のレスは。

(続き)

現実的なのは、>>708 とかかな。NEｼｰ のがそうだっていうのは
　http://tmp4.2ch.net/test/read.cgi/company/1093497747/302
で暴露されていて、それでも
　http://tmp4.2ch.net/test/read.cgi/company/1093497747/305
なんて問題点があるらしい。まあ、この辺りは、どのSystemC合成ベンダも
「どういったハードを想定して、このような記述をされたのですか？ 」
という風に聞いてくるからね。

>>696 の論文はかなり過激だけど、的を射ているとは思うよ。でも、Cベース
が俺個人としても、有り難いんだけどね。

>>714
先ず、

　ハードウェアエンジニアのためのC++講座
　http://www.testbuilder-jp.com/inno/tu/cpp/p1.html

で、C++ のおさらいをしたあと、

　SystemCの薦め
　http://www.testbuilder-jp.com/inno/tu/sysc/index.html

を一通り読んで実行してみてから、OSCIが出しているUser Guideを読むのが
良いと思われます。で、記述して実際に動かすのが重要なんですが、LRMも
参考にされながら、例えば値変化によるイベントの発生ってどう扱っている
んだあ？とか興味を持ってソースを読んで見るのも良いと思います。

頑張って下さい。

(また、ID同じで一杯書いてしまった……　ｏｒｚ)

>>697
もしかして、これ↓↓↓ の事？

　GAスケジューリングによるリアルタイムマルチプロセッサ自動合成システム
　http://www.mil.se.ritsumei.ac.jp/pdf/j85-c_12_1216.pdf

この大学ね。教授も大変だよね。学生が……だから。つうか、もし君が学生
なら狼狽心ながら言っておくが、就職の面接のときに、

　「組み合わせ最適化アルゴリズムは沢山あるが、何故GAを選択したのか？」

くらいの質問には軽く答えられるようにしとけよ。研究を行うときに、学生
がその背景や同行とかをきちっと押さえていない傾向が強いんだよね、君ん
とこみたいな中途半端な大学は。

で、何故にGA？

>>715
御託はいいけど、>>700に対する答えは？
高速sim？口だけなのがバレバレ？ちゃんと説明して、あなたの「高速sim」って
なんの事なの？

>>719
お前、>>280 読んでも解らんか？ だとしたら、レベル低杉。というか、後発
組みの落ちこぼれ君かあ。じゃあ、CoWareに大枚はたいて導入すれば。でも
APIの記述テクニックは教えてくれんだろうけどね(笑)。まあ、頑張れ。この
スレで、そこまでお人良しに教えるバカは居ないよ。

>>714
参考書じゃないけど
http://www.testbuilder-jp.com/index.html
がすごく役に立ったyo
ここでの議論がばかげていることも分かる

結局答えられないんじゃん・・・

>>720
719は分ってて、715をからかってるんだよ。議論の流れを読もうぜ。

>>722
答えるのがばかばかしいんじゃない？
分かってる？
SystemCの薦め
　http://www.testbuilder-jp.com/inno/tu/sysc/index.html
読んでからまた書き込みたら？
8章　9章まで読み終わって理解しないと
>>720には勝てない

って、715=720かよ　ｗ
なんとお粗末な・・・

IDの仕組みを解ってないのかもな。
てか、漏れのレスを引用しないで欲しいな。

>>724
逃げは良くないね。ちゃんと答えて欲しいよ。
検証用モデルから合成用モデルの合わせこみに関して、ベンダーから
いろいろ情報が流れてる状況で、ばかばかしい内容でもレベルでも
ないことは、本人がよく分かってるはずだけどね。

答えるのがバカバカしいとかやめてほしい
議論してるんだから・・・

「引用読んでもわからないのか？」
とかで返すのは
「だからチョンはダメなんだ」
って言ってるようなヤツと同じじゃん

携帯板やニュー速じゃないんだから冷静に行こうぜ

これ嫁

!!! "It's not a BUG,
/o o\ / it's a FEATURE!"
( > )
\ - /
_] [_

ttp://www.deepchip.com/items/dac03-04.html

それとこれもふるいけど参考になる
ttp://www.deepchip.com/items/dvcon04-03.html

>>725
だから、ID変えないって言ってるだろうが。

しかし、APIというヒント出しても解らんヤツが、良く >>691 みたいな事を
言えるな。質問があるなら、SystemC勉強中が見せたくらいの礼節をわきまえ
ろよな。まあ、それでも当然教えないけどね。

SystemCの醍醐味はTLMで、プロセス間通信のAPIを如何に作り込むかがポイント。
この部分は、例えばCoWareがAMBAのアクセスAPIをBinaryで提供(販売)している
ように、商売ネタだから誰も教えてくれんと思う。勿論、私も答えない。いくら
何でも守秘義務ってのもあるしね。

>>731
桜＃さんでツカ？
ヒント出しすぎ

ところで
>>729 >>730
読めないよ
消えてる

>>733
ちゃんと読めるが。SystemC何て使い物になるか、ぼけぇー、的な内容では
あるが、状況は米国と日本じゃ異なるし、先行している ST Micro の意見を
参考にするのが日本の現状に会っていると思うよ。

>>734
読めました。
だけど言語がSystemCでなく英語なのでやっぱり読めません（笑）
それより桜＃さんn+MGMwpxのID固定はどうすればできるのですか？（仮に桜＃さんとしときます）

>>714
これも読め
ttp://www.starc.or.jp/kaihatu/hldgr/documents/subject_investigation.pdf

ID固定わかりました
はは

このスレに来てる人って、エンジニアとか理系学生でしょ？ 英語読めないの？
それって、マズくない？

>>718
おれそんなレベル低い大学行ってないから。
GAなんて俺にとっては一般教養レベルなんだよ。

でさぁ、何だって効率の悪いc++なんかお手本にしてるわけ？
この分野こそGUIプログラミングが最適だろう。SimulinkとかLabviewのような。

>>718
なぜにGAかだと？
そんなもん解空間が離散的すぎてSAやタブーサーチではお話にならないからだろ。

>>739
一般教養なのは常識として、問題なのは、何故にGAをメモリアーキ最適化に
用いようとしたかの動機なんよ。良かったら、他の組み合わせ最適化との比較
を交えて、何故GAとして定式化して解くのが良いのかを教えてくれない？
宜しくです。

メモリアーキの最適化に関しては、がーびぃ の著作である
　Memory Architecture Exploration for Programmable Embedded Systems
　http://www.amazon.com/exec/obidos/tg/detail/-/1402073240/qid=1042775764/sr=8-1/ref=sr_8_1/103-4254399-6973414?v=glance&s=books&n=507846
が結構有名だよね。

>>740
HDLで、GUI系ツールが駄目だったからね。あと、テキストで編集できる
お手軽さは結構重要だよ。確かに、C++ をお手本しにしている時点で
SystemCはDead Copyだと言えるよね。SystemC2.0の開発動機は、システム
アーキ検討のための高速なSim Model作成の容易化だから、その意味では
C++ という選択肢も悪くはないと思うんだけどね。うーん、ちょっと難しい
です。

>>741
有難う。て事は、突然変異のさせ方が非常に重要になるって事だよね？ 論文
とかは執筆してないの？ 執筆していたのなら、タイトル等を教えて下さいな。

>>741
> 回路モデルとその評価式

これは具体的には何？ 例えば、SDRAMをメモリとして用いる場合、リフレッシュ
モードをどれにするかとか、バンク有り無しをどうするかとか、様々なパラメータ
が存在し、且つ、SDRAMの前段にFIFOを置いて初期レイテンシを隠蔽するなん
てのも結構ありありで設計したりするんだけれど、その辺り全部の組み合わせ
とか言い出すと、設計パラメータすら数え切れなくなるんだけど、それに
メモリの種類はもっと沢山あるし、どうなの？ で、評価式、これは具体的には
何？

>>742-743
別にそんなん専門でもないし論文も書いてないが、
GAの一般論からして、有効に働く回路ブロックの単位と
有効な遺伝子型の対応がつきやすいからだろ。
つまり一度できた有効な回路ブロックはほんの少し変化させてもドラスティックに性能指標が
変化しうる。
突然変異以外では有力な遺伝子型を基本的に保存する方向に働くというGAの性質は
この既に有効な回路を破壊しないという性質とうまく合致するだろう。

重要なのは変異の方法ではなく、回路要素をどう遺伝子型にインプリメントするかだと思われる。
これをうまくやったときは既に有効な回路を破壊しないという性質がうまく出てくるがそうでない場合は
現れない。

まぁもし俺がその分野を研究するなら、回路要素の遺伝子型へのインプリメント法自体を
メタ問題としてGAで最適化するね。

>>NClMqcqP
やっぱり桜＃さんだったのですね。
全部本持ってます　私のバイブルです
何で、Verilog/VHDLから転向したか教えてくださいよー

あっ間違えたな
n+MGMwpxが桜＃さん
まいっか　
二人とも桜＃さんで

変なの釣り上げて面白い？

>>745
一般的に回路アーキは、特に、データ転送などメモリアーキを主体に考えた
場合、オープンな待ち行列ネットワークになる。確かに、少しの変化が系内
待ち時間などネットワークのトラフィック性能にドラスティックな変化を
与える。

が、問題なのは、分布を一概に与える事ができないため、そのネットワーク
のトラフィックに関する性能指標というのを定式化できないという事である。
確かに、データが一方向にしか流れないような単純なものであれば、可能
かも知れないが。

GAとして定式化する場合、その性能指標を与えなければならないが、それが
対象とする待ち行列ネットワーク毎に異なり、かつその決定が困難だという
問題がある。

その意味でGAが有効かどうかは疑問が残る。


>>746
初期設定はファジイ推論でもよくね？ でも、計算時間凄くなりそうだね。

遅レス ｽﾏｿ。>>691 >>700 の根拠ってもしかして、これ？

　　http://www.yxi.com/Japanese/indexJ.html

　　http://www.yxi.com/news-2004-11-11.htm

　　http://www.yxi.com/Library/excite%20expert%20datasheet%206_2_04.pdf

何だか色々釣れてて否定的な意見も多いみたいだけど、個人的には２つ
用意しないで良い方向に技術が発展して欲しいっす。素人の願望、ｽﾏｿ。

>>731
だからさ、逃げないでちゃんと答えてくれないかな？

>しかし、APIというヒント出しても解らんヤツが、良く >>691 みたいな事を
>言えるな。質問があるなら、SystemC勉強中が見せたくらいの礼節をわきまえ
>ろよな。まあ、それでも当然教えないけどね。
こんなことは、俺にとって常識なんだよ。何をいまさら、つまらんこと出して
ごまかすんじゃないよ。

某高位合成のためのPxxxxxxレベルへ某設計ツール用のBxxxxxxレベルの
変換はそのうちできるのかな？で、どっちが作るのかな？

まあ、ともかくさ、"高速sim"について説明してもらおうか？
ちなみに >>280　は俺だよ。

>抽象度を上げたときに何が難しいかって、モジュールの動作記述
>ではなくて、APIでのモジュール間のコミュニケーション記述

賛同しまつ