シミュレーション言語SystemCを語る

回路設計はできないシミュレーション専用言語です

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

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

Hogehoge

前(関連)スレ？

SystemC、SpecCについてのスレ
http://science3.2ch.net/test/read.cgi/denki/1072282085/l50

関連スレ、続き

ＭＡＴＬＡＢ/simulinkでシミュレーション
http://science3.2ch.net/test/read.cgi/sim/1031226067/l50

Verilog,VHDL等のＨＷ記述言語のシミュレータ
http://science3.2ch.net/test/read.cgi/sim/981553632/l50

>>ALL
重複スレにつき、こちらへ移動おながいしまふ。

SystemC、SpecCについてのスレ 2
http://science3.2ch.net/test/read.cgi/denki/1104436852/l50

http://rock23.value-net.net/29/dsi/　最近、この子に萌え。


　　　　　まじヤバイ・・

　　　　　　　　　　　　　　　　リリカぁ、俺とも頼む・・・

http://science3.2ch.net/test/read.cgi/sim/981553632/2-4
4 ：えーしっ君 ：2001/02/11(日) 23:38
では、最後に、役に立つリンクをば。

まずは、

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

シミュレータに興味をもたれているなら、噂ぐらいは聞いたことがあると思います。

SystemCというのは、C++でHWをモデリングするためのフレーム・ワーク(クラス・ライブ
ラリ)です。上記サイトで名前を書けば、無償で入手できます。

上の書き込みで、シミュレータがどのようにHWモデルをCに変換するかを説明しました
が、SystemCフレーム・ワークをつかってHWのモデルを手でガリガリ書くことは、シミュ
レータがHWモデルをCに変換する過程を、自分の手でやることと同じことです。

ですから、HWのモデリングを理解するには、よい教材になると思います。

SystemCフレーム・ワークには、以下のものが用意されています。

- 4値の信号をモデリングするためのデータ・タイプ
- これらのデータ・タイプで演算するためのオーバーロードされた演算子
- ダイナミック・スケジューラを隠蔽したmainルーチン


ﾜﾛﾀ (w

>>ALL

こちらが本スレです。
電気・電子版のSystemCスレは重複スレです。

では、続きをどうぞ！

>>ALL
やはり慣れた電気電子版の方が盛り上がると思われますので、このスレは
終了と致します。以後、こちらへどうぞ。

　SystemC、SpecCについてのスレ 2
　http://science3.2ch.net/test/read.cgi/denki/1104436852/l50

>>ALL

こちらが本スレです。
電気・電子版のSystemCスレは重複スレです。

では、続きをどうぞ！

>>ALL
やはり慣れた電気電子版の方が盛り上がると思われますので、このスレは
終了と致します。以後、こちらへどうぞ。

　SystemC、SpecCについてのスレ 2
　http://science3.2ch.net/test/read.cgi/denki/1104436852/l50

>>ALL

こちらが本スレです。
電気・電子版のSystemCスレは重複スレです。

では、続きをどうぞ！

SystemCはハードを主体とした抽象度の高いC++モデル記述を行って、従来から
あるHDLよりも高速なSimulationを可能とする事を目的として開発された言語
です。ただ、SystemC1.0ではきちっと合成も出来、実用に耐え得る回路も合成
可能でした。

また、システムLSIの大規模化による設計危機を克服するためにSystemCや
SpecCなどC/C++ベースの言語が提案されており、議論においてはそうした
背景を尊重すべきです。

従って、前スレ同様、システム設計手法、合成、モデル化のテクニック、
はたまた、他のBDLやHY-C、Handel-C、SystemVerilogなどの言語との比較
やそうした亜種の状況を活発に議論するのが良いと考えます。

では、前スレ同様、活発な議論をどうぞ！

SystemC信者のそのペテン師みたいな言い方が嫌われるんだよな。

＞従来から あるHDLよりも高速なSimulationを可能とする事を
＞目的として開発された言語
まず、今のHDLは（生い立ちはともかくとして）単なるシミュレーション用
の道具じゃない。Simulationを可能にするという言い方には、従来同様
に合成まできちんといけるかのような誤解を与えかねないからやめた
ほうがいいだろな。

Simulation専用言語として・・と正直に言うべき。


＞SystemC1.0ではきちっと合成も出来、実用に耐え得る回路も合成
可能でした。
過去形で語るしかないんだよな？結果として合成は捨てたんだろう？
合成を捨てた以上、合成までのパスを確立して、実設計ツールと
して利用できるHY-CやらHandel-Cなどと比べることは間違ってるし、
それらと同様に合成までできるかのような誤解を与える。


＞従って、前スレ同様、システム設計手法、合成、モデル化のテクニック、
こうやってさりげなく合成を含ませたり、システム設計という言い方
がまたRTLレベルまで落とし込めるかのような誤解を与える。
前スレと同じようなことにしないためには、”システム設計”ではなく、
より誤解の少ない「システム仕様検討」とでも言うべきだろな。

では、前スレ同様、活発な議論をどうぞ！

>>14
Verilog-HDLもVHDLも双方ともに、Simulation専用言語として定義されたん
だが。で、ブール代数やオートマトンの理論に基づいて、合成可能サブ
セットのRTLを定義したんだが。任意のVerilog-HDL記述やVHDL記述が合成
出来ない事にも留意すべきである。

SystemC1.0の場合、EsterelのSimualtionが高速なC++版であるから、
Simulationと合成を念頭に定義がなされている。ただ、2.0はSpecCを
取り込んだのでこれが失敗。

どちらかと言えば、

　　HDL：Simulation専用言語として定義され、後に合成可能なサブセット
　　　　RTLが定義された

　　SystemC：Simualtionと合成を同時に考慮して1.0を定義し、後に記述
　　　　　　能力を高めたSimulation用途の言語拡張を行った

というのが正しい理解。

確かに、Handel-CやHY-Cは合成可能である事を前提に最初から言語定義が
なされているね。BDLというのはどうなんだろう？

……、結局実装を考えると、この三者の優劣比較とかの議論の方が重要
なのかなあ。書いてて自信がなくなって来た ｏｒｚ

　　システム仕様検討 ： SystemC関連で議論
　　合成込みの実装　 ： Handel-C、HY-C、BDLを中心に比較を交えつつ議論

というのがこのスレでの話題として適切なんだろうね。

>>15
> システム仕様検討 ： SystemC関連で議論
　→　本スレが適切かと

> 合成込みの実装　 ： Handel-C、HY-C、BDLを中心に比較を交えつつ議論
　→　SystemC、SpecCについてのスレ 2
　　　http://science3.2ch.net/test/read.cgi/denki/1104436852/l50
　　が結局適切かと。

まあ、棲み分けが出来るので、こうなると、重複スレとも言い切れなくなる
というか、既に重複スレとは言い難いような。

じゃ、皆さまそーゆー事で、いづれかの適切なスレで活発な議論をどぞ！
ないしね

>>ALL

こちらが本スレです。
電気・電子版のSystemCスレは重複スレです。

では、続きをどうぞ！

>>17
どうしてそんなにこだわるの？ もっと心を大きく持った方がよくてよ。

>>ALL

こちらが本スレです。
電気・電子版のSystemCスレは重複スレです。

では、続きをどうぞ！

　これを読んでから、議論しよう
http://ns.cqpub.co.jp/dwm/column/hasegawa2/dwm0037hase1.htm
http://ns.cqpub.co.jp/dwm/column/kawarabayashi/dwm0038kawa1.htm
http://ns.cqpub.co.jp/dwm/column/makino/dwm0040maki1.htm
http://ns.cqpub.co.jp/dwm/column/makino/dwm0041maki2.htm
http://ns.cqpub.co.jp/dwm/column/sugiura/dwm0043sugi1.htm
http://ns.cqpub.co.jp/dwm/column/mryc/dwm0044mryc1.htm
http://ns.cqpub.co.jp/dwm/column/kurokawa/dwm0045kuro1.htm
http://ns.cqpub.co.jp/dwm/column/kakimoto/dwm0046kaki1.htm

　番外編
http://www.kumikomi.net/article/column/0012cbac/001.html

　誰か Bach C を知っている人いる?
http://ne.nikkeibp.co.jp/members/01db/200211/1010353/

>>20
所詮は素人が御託を並べている記事に過ぎないが、何処をどう参考にしろと。
有名人なのと実力とは、この世界余り関係ないって事しらん厨か、お前？

まあ、導入には良いかも知れんがね。

SystemC2.0 LRM
http://www.systemc.org/projects/systemc/document/SystemC_v201_LRM/

SpecC2.0 LRM
http://www.specc.gr.jp/news/SpecC_manual_Jap.pdf

SystemVerilog LRM
www.eda.org/sv/SystemVerilog_3.1a.pdf

Handel-C LRM
http://www.am.ics.keio.ac.jp/members/fukuda/image/handel_c/handel-c-ref.pdf

HY-C LRM
http://www.yxi.com/download.htm

Bach-C (シャープ技法)
http://www.sharp.co.jp/corporate/rd/journal-78/pdf/78-07.pdf

BDL (DATA'99)
http://csdl.computer.org/comp/proceedings/date/1999/0078/00/00780390abs.htm

Bach-CとBDLのLRMにリンク先、教えてエロイ人！

↓ これって自作自演か？

http://ns.cqpub.co.jp/dwm/column/kurokawa/dwm0045kuro1.htm

ClassMateの開発者がCyber使って設計？ 不自然過ぎるだろが！

>>24
Thanks! 純粋にLRMを読んで比較するのが正しい気がとてもする。でも、
BDLとBach-CのLRMは確かに見当たらんね。関係者の方、情報きぼんぬ！

>>25
ClassMate、Cyberが何なのか知っていれば、全然、不自然じゃないけど。

SystemCを使ってRTL記述するよりHY-Cの方が楽ですが、BDL、Cyberの方が
最、楽になるように思いますが、如何でしょう。

>>24 抜け発見　SystemCでRTL作成
http://www.synopsys.co.jp/marketing_pdf/rtl_systemc-J.pdf

BDL & Cyber これじゃ、楽だと思うけど、適応できないところもありそう？
http://ne.nikkeibp.co.jp/edaonline/eachnews/00jun/20000605necinterview-cyber.html

BDLは、記述が全て構造化されてないとCyberで動作合成しても
理解できないものが出力されると思われ。

>>31
ごてごて回路には使えないと言うことですな！

使える対象者は、すっきり回路を設計できる人に限る？　ウ〜ン

>>32
HY-Cだと、スネークパスだろうが何だろうが設計可能みたいですね。BDLは
言語仕様が不明なのでコメントできないです。まあ、両方ともSystemCや
HDLでRTLを記述するよりは数段楽なんでしょうけどね。LRMをざっと見る限り
HY-Cだと、単一クロックという限定はあるみたいですが、RTLで記述可能な
ものは何でも書けそうですね。

それと、難しすぎて理解不能なので、本当かどうか知らないですが、LRMでは
形式モデルとしては複数クロック拡張まで対応していると謳っているので、
きっと文法拡張は直ぐに発表されるかも知れませんね。

ちなみに、BDLってRTLで記述可能なものは何でも記述可能なのでしょうか？
またHDL並みの複数クロックのサポートも行っているのでしょうか？ というか
これが将来的にでも良いから出来ないと、使い物にならないですよね。その
意味で、SystemCはシステム検討言語としても記述し易さの観点では失格
ですよね。

BDLは、使ったことがないんですよ。申し訳ないです。
聞いた話だと、ここにも（>>25）書いてあるけど、ビヘイビアモデルで
クロック記述が不要、>>30にあるように組込マイコンのプログラムの
ように作成すればなんでもCyberでRTLを出力すると言うことなので
Cyber自身にみそがありそうですよね。これも推測ですがVerilogに
ビヘイビアモデルが扱えるSystemVelilogが登場しますが、この記述に
近いのではないかと想像しています。ご質問ですが、複数のクロックが
扱えるか、おそらくCyber自身の機能にこれが出来るよう実装すればいいだけ
の話ではないかと思いますが、これを開発しているNECは、マルチ
プロセッサのLSIを製品化していますから、対応していると考えても
よいのではないかと思いますが、間違っているかもしれません。
自社のみ使用可能な非公開のツールは分かりませんよね。

>>24
BDLのpaperは、ここにあり
http://www.ensta.fr/~hammami/DEA/SETI/mustpapers/1507waka.pdf

>>35
ワンモア　
http://www.sigda.org/Archives/ProceedingArchives/Date/papers/1999/date99/pdffiles/06a_4.pdf

>>35、>>36
　これ凄い動作合成ツールだと思います。初期にリリースされたものは、バグ
がかなりあり、人柱から使えないと言われたでしょうが、バグフィックスされる
と、脅威的なツールになりますね。　これじゃ非公開なのは当り前でしょう。

>>35-36
いづれも設計環境の話であって、BDLの言語仕様がどうこうというものでは
ないですね。記述できない事には合成も何もありませんから。所望の回路動作
を書き表す事が出来ないと、合成はおろかSimulationも無理ですから。

http://www1.cs.columbia.edu/~sedwards/papers/edwards2005challenges.pdf
によると、

　Cyber：Restricted C with extensions

だそうで、

　NEC's Cyber system accepts a C variant dubbed BDL that contains
hardware extensions but prohibits recursive functions and pointers.
Timing can be implicit or explicit.

だそうです。他の言語や合成システムの記述と比較して推察すると、

　１．サイクル精度記述と、Untimedな記述の両方が可能
　　　(混合記述はプラグマで対応？)

　２．明示的な並列構文はサポートせず
　　　(ファイル毎に合成して、ClassMateで結合検証？)

といった感じでしょうか。また、サイクル精度記述での同一サイクルでの
データ転送をサポートしているのは、この論文とLRMをベースに議論すると、
恐らくHY-CだけでありBDLではサポートされていないとも推察されます。
これがあれば、例えばMealy FSMは２プロセスで記述する必要はなく、
１プロセスで記述可能となるので、RTLよりも抽象度が上がると言えますね。

>>37
未公開ツールや言語の評価を行うのは非常に困難です。もしかすると、恥ず
かしくて公開できないとか、バグだからけで運用が困難なため公開できない
とか、逆にそういう理由も考えられますからね。どなたか、利用経験のある
方が情報を公開してくれれば良いのですが……。

>>27
ClassMateはCyberが出力するサイクル制度のC++記述を食って動くSimulator。
という事は、ClassMate自体のデバッグでCyberを利用するというのは理解。
ついでに、設計までやってしまった、という事かいね？ にわかには信じ難い
ですな。

で、ELでのCyberの評判だけど、↓ これを参考にすべきなんだろうね。
http://tmp4.2ch.net/test/read.cgi/company/1100361078/234-246

設計言語としては、どうやらVerilog-HDLが主体のようですな。

多分、コアがフィックスして周辺回路だけ、これで作っているとは考えられないかな？
例えば、プロセッサは、ARMを使うことが決まっており、ARMのコマンドでＣ++の
プログラムを作り、そのプログラム記述の中でどこを周辺回路としてハードウエア化
すればよいか検討し、そこだけを切り出しBDLに焼きなおしてCyberで動作合成するなんて
いいんじゃないのかな？　ただし作ったＣ++プログラムが即、BDLで使えればの話だが。
また、ARMコマンド関係は、BDLでライブラリー化しておく準備が必要だが？

>>40
　Cyberの手間がLSI、VLSI規模のチップならVerilogと余り変わらないからじゃないの？
ULSI規模でやっと発揮できるのでしょう。ULSI規模の開発てほとんどないんだよ、日本
の半導体メーカでは、����通信のコントローラとか、MPEGぐらいでしょう。

周辺回路の特にインターフェースの部分を記述する目的なら、BDLは単体での
記述特にUntimedな部分の記述を主体としているみたいだから、HY-Cの方が
向いてるっぽいね。

BDLはクロック記述不要ということは、Cyberのほうでその関係の別ファイルを
要求していると思われ、そじゃないとRTLを吐き出さないぜ。

つまりBDLは、システム屋が作成し、クロック関係はハード屋がBDLの内容を
解読して別ファイルを作成し、それらを束ねてCyberで動作合成しているん
じゃないかと思うのだが、�����。

というか、DBLの記述例でいいから何か情報ないかいね。もし、>>44 が真なら
誰も使わんだろ、そんな使い勝手の悪い言語とツール。まあ、ANSI-Cからの
合成ツールを使ってるけど、別にサイクル制約を行わなくてもRTLを生成
してくれるよ。つうか、動作合成ツールって学術も商用も普通一般に、そう
じゃね？

HY-CだとLRMを見る限り @; がClock Boundaryとあるから、恐らくこれがSystemC
の wait(); に対応しているので、サイクル精度記述はOkayだし、chan wire型
とかいうのがあるみたいなので、同一サイクルでのデータ転送もOkayだね。
これだと、例えスネークパスがあるようなインターフェースであってもサイクル
精度で記述出来てしまうね。そんな仕様を認めて良いのか悪いのか、は別として。
BDLではどうなんだろう？ 誰かLRM公開汁！

だから、>>42　の言う通り使わねぇ
LRMは、関係者以外マル秘

>>47
じゃあ、関係者以外はＨＹ−Ｃに期待するしかないって事？ それとも、
ＢＤＬで無理だったから他も多分無理って事？ つうか、公開予定とか
無いの？ それとも、恥ずかしすぎる内容だから公開できないって事？

自社が生き残る為の他社との差別化じゃんないの。そんなの当りまえじゃん

それじゃあんたとこも自社開発すればいいではないの、ただ互換性はなくなる
けどね。ユーザがつかない問題も出てくる。だから社内のキーデバイスにしか
使うユーザがいない。自業自得、それでも開発する意義あるからでしょう。
（他社との差別化の為だけ）そこは置いといてあんた学生さんなら、就職して
仕事で製品開発すれば、ここで書いたことが理解できるようになると思う。

Bach-Cも同じでしょう。

ビヘイビアモデルが扱えるSystemVerilogにするよ。
SystemCはダメだ。

>>1 シミュレーション言語SystemCを語る

>回路設計はできないシミュレーション専用言語です

市場で手に入る機能拡張Ｃ言語は、HY-Cしかない。
HY−Cから、SystemCあるいはVerilog-HDLに変換するツールも市場で手に入る。

しかし、ルネサスは使っているようだけど、他ではないのかな？

どうも、アーキテクトに長けたシステム屋がハード設計まで携りたくないやつが
SystemCを使い。逆にハード設計できるシステム屋は、Verilogを使いこなしてPDLを
使ってLSIを作ってしまう。結局、技術バランスが悪いのよね。

　　　　↑
PDL →　PLD 誤記修正

>>52 >結局、技術バランスが悪いのよね。

だから、>>45 じゃないのかな？

この議論、伝送屋には、人種が２人いて、伝達関数で話する人と
トランジスタ回路で話する人がいるのよ。お互い共通言語がないので
意思の疎通が図れない。そこで共通語として出てきたのがＳパラメータだった。
これと良く似ている。

Cyberは、非同期なので、クロック情報はいらないのよ。
http://www.ipa.go.jp/SYMPO/SYMPO99/pdf/63_3.pdf

非同期回路のVerlog-RTLを、同期回路に手作業で修正しているだけです。
ここをautomaticに出来れば皆使うでしょう。

やぱりそうか　Cyber 誇大広告
http://tmp4.2ch.net/test/read.cgi/company/1100361078/208

HY-CがＳパラメータのようになるとも思えないが？

システム屋がSystemCが、言いといっているんだよ。
回路設計出来ないけどね。

SystemCは、何たって無料だもん。　無料で出さないと勝てない。

>>58
システム屋がSystemCで環境を整備して、設計部隊がHY-Cで実装を意識して
設計、で、HY-CからSystemCに変換して整備した環境に繋げて性能検証、とい
う筋書きではないのだろうか？

↓ これを参考にすると、そう推察してしまうのは私だけ？

http://science3.2ch.net/test/read.cgi/denki/1104436852/20-22
20 ：774ワット発電中さん ：05/01/01 16:39:00 ID:qEoy5Wr4
>>15　結局、どこもこの方法を採用するようだ。

http://www.renesas.com/jpn/news/2004/0921/index.html

22 ：774ワット発電中さん ：05/01/01 17:12:04 ID:PEpoedHS
>>20
LogicBenchって確か、eXCiteじゃなかったけ？、アーリープロトのツール。
記事を読む限り、SystemCは純粋なシミュレーションのみが目的のようだけど。
というか、SimulationはCモデルをSystemCモデルへ書き換えて実施し、合成
はCモデルから直接行う、という風にも読めるのだがこの記事。どうなんだ
ろう？ 関係者の方、情報お待ちしておりやす。

>>50
本質的にSystemCと何も変わらんぞ。まあ、RTLのコード量がHDLのままだから
SystemCに比べれば短くなるけどね。アサーションもサポートされているが、
SystemCでもTestBuliderがあったからな。まあ、個人的にはPSLの方が好みだ
けどな。で、でだ、支那腐死巣の言いなりになるのが、一番嫌なわけだし。
そこんとこは、どーなのよ？

開発のスケジュール管理がやりやすい。

HDL記述が完成していないブロックは、仕方ないのでビヘイビアで繋いで
検証するしかないでしょう。

あんた一人で設計しているのか？　納期守れるのか

>>62
ほぼお目にかかったことの無い、ビヘイビアのHDLが書けるRTL設計者が
そちらには沢山いると。あーそーですか。羨ましい限りですなあ ｏｒｚ

>>62
追記。アサーションが流行る前から、ＨＤＬでアサーションを書いてた
けど、これって、ビヘイビアのＨＤＬの記述能力が問われるよね。
という事は、ずっと以前から、さぞかしアサーションを使いまくって、
これまでバグのない短期設計をされておられたんでしょうな。アサーション
用に構文が追加されたけど、別にＨＤＬでそのまま書けばいいじゃん、でも
楽だから使うかあ、位の勢いなんでしょうなあ。

つうか、ありえねぇー。まあ、そういう方もいらっしゃいますけどね。
そんなに沢山は居るもんじゃないっしょ。

ALDECってVerilogもVHDLもSystemCもおまけにmatlabも協調シミュレーションしてしまうみたい。
TLMとVerilogのタイミングどう取るのだろ。
UTかUMLかなんて議論もあったけど、matlabもありか。
シミュレーションと割り切ればこういうのもいいね。
ttp://lsi.soliton.co.jp/products/aldec/riviera/riviera.html
ソリトンはeXCiteもやってるからそのうち合成へ繋がる事　期　待

今後はこの辺の準大手がSystemCを引っ張っていくとおもわれ
http://www.aldec.com/Press/Releases/?ID=276&year=2004
超期待

>>66
ここ、ＳｙｓｔｅｍＣのＮａｔｉｖｅ Ｃｏｍｐｉｌｅｒ持ってないよ。
多分良くて、ＯＳＣＩのＲｅｆｅｒｅｎｃｅ Ｓｉｍｕｌａｔｏｒ（Ｃｌａｓｓ Ｌｉｂｒａｒｙ）
をいじってるだけなんじゃん。で、期待ですか。あーそーですか ｗｗｗｗ

SystemC2.0はSimualtion専用言語であって、それ以上でもそれ以下でもない。
この事は前スレの議論で確定したよね。実際、実装を意識した記述を行う場合、
RTLを用いるしか、ほぼやりようがないんだよね。ディスコンした、支那腐死巣
のCoCentricも、実装を意識するんだったらRTLでよろぴこ、と謳っていたぞ。
で、今更何を期待するの？ というか何を期待できるというの？

このスレ、システム屋にSystemCを諦めさせる掲示板？　大いに賛成

しかし、システム屋全員が、RTLでHDL記述できるようになると
半導体の設計やってる連中皆失業でっせ。

いやシステム屋が細部にわたってHDL書かなくても、
テストベンチ書いたり、外注先のRTL眺めたり、シミュレーションするだけでも
進捗具合が的確に把握できるし。なんら問題ないと思うけど？
システム屋一人で全部書けるわけじゃないし。

>>60
SystemCはシステム設計検討言語なので、実装まで考えた他のCベース設計
記述言語である、BDL、HY-Cなどについて語るスレです。勿論、SystemCを
用いたシミュレーション主体のシステム設計検討に関する議論も大歓迎の
スレです。

って、違ったらスマソ。

60ではなく、>>69 だった ｏｒｚ

HY-Cなどについて語る必要ないのでは？
SystemC対応してないし。
従って、Cyb○rとF○lte以外の合成はSystemC未対応の製品議論外ですね。
ということはソリALDECトンの香具師はHY-CやSpecCをここで語れない　残念！！
粗利豚君電子版へ戻れー！
http://science3.2ch.net/test/read.cgi/denki/1104436852/32
SpecC君もそこで待ってるぞ！

CyberはBDL（LRM未公開）で、ForteはSystemC対応です。

SystemCの動作合成は、ForteのCynthesizerとCoWareのConvergenSC だけだったです。

http://www.forteds.com/japan/cynthesizer_datasheet_japanese.pdf
http://www.coware.co.jp/products/convergensc.pdf

Cowareのニュースです。
http://www.coware.co.jp/news/2004/2004.11.16.html

ちょっとふるいけどCadenceのニュースです。
http://www.cadence.co.jp/news/h16-6-8.html

ちなみに、SystemC対応の動作合成ツールは、Celoxica、Forte、礎デザイン
オートメーションの三社です。CoWareは無関係です。が、

　ＳｙｓｔｅｍＣ の 合 成 の 議 論 は こ の ス レ の 対 象 外

です。もはや、SystemCはSimulation専用言語である、というのが本スレ
での大前提です。これを覆したい場合は、具体的な事例と納得できる
結果を提示する必要があります。出来ないなら、諦めて下さい。

但し、SystemCによるモデリングや性能解析手法の話題は本スレの対象
ですので、ノウハウ等の公開は活発に行って下さって大歓迎です。
CoWareの方、議論に参加されるなら、ぜひAMBA APIのSystemCソース
コードを無償公開して下さいね。

>>73-75
SystemC2.0 ＝ 回路設計はできないSimulation言語

実際、>>76 はSimualtion言語としてのSystemCの話題。流石、大手C社
わきまえている。>>68 にあるように合成最大手のS社も撤退してるから
な。CoWareにForte、必死だな。そう言えば、NovasとBluespecという
組み合わせもあったな。誰か、ご存知？

これ読んでね
http://www.ednjapan.com/content/issue/2004/05/cover/cover.html

続き
http://www.eetimes.com/showArticle.jhtml?articleID=49901438

誰か、名古屋大学のSystemBuilder使ったことある人いる？
http://www.ertl.jp/~honda/codesign/

>>79
そら会社は自社のやってることをくさしたりしないよ。それこそ破滅だからな。
駄目だとわかってても破滅寸前まで可能性をPRするさ。
客観的評価じゃないと紹介する意味ないと思うけど?
それと、合成そのもの光明が見えるならここでやることはいいんじゃないの？
つーかこのスレ俺が立ち上げたんだけどさ。
C++文法のもとで回路まできちんと合成できればこんなありがたいことは無いよ。
できないのにできるかのような広告は信じたものがバカを見るから問題
信じたものは救われなきゃね。

動作合成に完璧を求めると、貴殿(>>1)の言う通りだが、回路を知らない
システム屋がいる限り、サイクル詳細記述を要求しても能力なしだから
書けやしない。そこを諦めて、SystemCでもいいから、抽象モデルで
機能記述をくれと言うしかない。そうすると、もらた記述を手でRTLのHDL
記述に直す作業は、止めてくれとどなりたくなる。それじゃ、完璧では
ないが、今ある動作合成ツールでRTLを出力できれば、それを土台にして
手直しする方がよっぽどマシと言うことになってしまう現実がそこには
あるんだよ。

結局、BDL、Cyberあたりがシステム屋に喜ばれるのが理解できると言うも
のだ。後は回路屋の仕事やでとなってしまうと、社内のシステム屋
とは付き合いたくないよな。　この気持ちが分かってくれるシステム屋だっ
たら付き合ってもいいよとなちゃうところが、浪花節なんだよ。あ〜ぁ

>>83
だから、Cyberではシステム設計できないって。MPEGとか大規模なDSPアルゴリズム
の合成に使ってるだけで、それならForteとかとかわらんて。ただ、SystemC
よりは文法が簡単だという利点があるにはあるんだろうけどね。

HY-Cだとシステム記述も合成も両方出来るみたいだよ。しかも、LRMを見る
限り、サイクルをパラメトリックに記述可能だから、パラメトリックなIPの
設計なんかも出来るよね。システム設計では、サイクル割り当ての検討とか
を先延ばしにして行うのが普通だけど、どこをそうしたのかをドキュメント
化してないのが現状なので、この文法はそういった情報を管理するという
意味で、結構イケテルような気がする。

>>84
粗利豚君必死
HY-Cは◎立、目潰し電機専用だから駄目
それとSystemCではないしね。
SystemCという条件外せば合成なんか色々方法あるってば　残念！
Cyberは懸命にSystemC対応を目指しているからOK
Cyberはシステムの一部のアルゴリズムの合成専用と割り切った使い方で十分メリットあります。
Forteと大きく異なるのは、インプリ先がNECライブラリとプロセス専用って事くらい。
普通のシステム設計者は問題なく使えます。
ただし、システム全部を検証したい合成したいなどとほざく馬鹿以外はね

>>85
得濡異死 必死

HY-Cは一般公開ですから
それと、BDLは未公開だし、CyberこそNEC関連専用だから駄目
SystemCに対応したところで、BDLを撤廃できないから、残念！
SystemCやBDLでは、商用化に耐えるインターフェース設計できないから、残念！
インターフェース部は、SystemCでもBDLでもHDL使わなきゃなんないから、勉強する事増えるだけだし、更に残念！
HY-CはSystemCに変換できるからOK
HY-Cはアルゴリズム記述からインターフェース記述まで実装を意識して記述可能なので十分メリットあります。
高速なSimulationを実現したい場合は、SystemCに変換して既存のSystemCのSimulation環境に接続すれば良いので、
SystemCが大好きなシステム設計者でも問題なく使えます。

Cyber、いくら期待しても開発元がNECなので、バグったときに設計データの提供できないから、競合は結局使えませんから。
しかも、Cyberで合成した設計データはCyberの開発元の知的所有権、って契約書にさりげなく入ってそうで怖いですから。

ほんま、フザケンのもええかげんにせーよ　＞　得濡異死

>>86
Cyberは、BDLだけでなくVHDLのビヘイビア記述も動作合成できるて、
どこかで読んだような？　むしろ、BDLはVHDLをまねた物ですか？

>>87
しーばりあんと。くろっくが、ぅん だらー でよ。最近のドル安にはホント困りますなあ。

　　特開２００１−８４２８４

を特許庁でしらべなよ。

　　永久接続文部　：　インターへース合成のための記述

　　順序動作文部　：　サイクル精度記述
　　
この著者の他の特許も検索するとイイ事あるかもよ。

ホントにいいことなん？
それとも笑えるような特許？
そこだけ教えて。
前記、前記・・・・読むの疲れるから

>>89
従来技術、発明が解決しようとする課題、図面、これだけ最初に見て判断
すれば？ で、読む気になったら、実施例を読めばいいんでないの？
特許請求項なんて、最後に読むもんでしょ。

つうか図面に、BDLらしき記述があるような感じ、というだけなんだが。

特許は、ここで調べて下さい
http://www.ipdl.ncipi.go.jp/Tokujitu/tokujitu.htm

>>88

　ドル　＝　$　


　　・・・・・・
　　れーたか、くのー
　　$
　　えーん、ざぁああん
　らんべる ：
　　しおり１
　　$
　　もしもあしたが腫れならば、
　　　しおり２
　　もしもあしたが飴ならば、
　　　しおり３
　　もしもあしたが逝きならば、
　　　らん、べるへ逝くぅうう
　　$
　　・・・・・

>>92
何かの呪文か？ ここはそういうとこじゃないよ、坊や。

>>86
HY-Cの話題終了　ここはSystemCのシミュレーションのスレです
++++++++++++++++++++++++++++++++++++++
http://techon.nikkeibp.co.jp/members/01db/200301/1010509/
既に一昔前にBDL＞SystemC宣言をしております。
今はれっきとしたSystemCツール

急に態度変わったけど、どうしたの

童貞捨てたのか？

>>94
ソース古杉。SystemCだと無理だから未だにBDLが残ってるんだよ。
ちゃんと、情報はチェックしようね。まあ、CeloxicaがHandel-C
とSystemCの二本立てにしてるしね。これは、SystemCでは実装を
意識した記述というのが、多くの場合RTLに成らざるを得ないから
なんだけどね。

なので、

　　システム仕様検討　−＞　SystemCでシミュレーション
　　個別実装　−＞　BDL、Bach-C、HY-C、Handel-C、SystemVerilog、
　　　　　　　　　　Verilog、VHDL

と今現在住み分けが行われているわけなんよ。これら言語の多くが、
>>24 のリンクからLRMがダウンロードできるわけだし、これらは関連
し合っているわけだから、比較検討の議論をこのスレで行うのは自然
だと思うぞ。

つうか、>>94 はCyber関係者で、>>86 の内容に反論できないって事なの？
それだと情けないよね。

>>94 は、今年4月にNECエレに入社予定の学生でSEになるそうです。
>>86 は、おそらくNEC関係者でしょう。

失礼しました私は、たけ（松下）です。今後ともよろしく。

>>98
松下で干されているらしいですね。ご愁傷様。では、SystemC関連の使用
経験をここに吊るして下さい。もしかしたら、転職に有利に働くかも
知れませんよ。あっ、でも南山とかいう低脳私立のしかも文型でしたね。

　も　う　来　な　く　い　い　よ、　負　け　犬　君

たけは、ここで吠えていた方がいいよねぇ
http://tmp4.2ch.net/test/read.cgi/company/1103546099/l50

>>97
>>86 は、おそらくNEC関係者でしょう。
違います
関係者ならCyberにはもう触れませんN関係者は
今はプラットフォーム設計フローを推奨でMicroSSPマンセーです。
勿論SystemCベースです
http://www.necel.com/cbic/ja/microssp/microssp.html#flow

ARMが、SystemCをサポートしたからですね。
ソフト、ハードの協調設計になるとSystemCしかないもん。

>>101
そこで、こんなのも見つけたよ。　お客さんがそれ読むといい印象持つかな
公開しないほうがいいのでは？
http://www.necel.com/ja/news/archive/0501/0401.html

>>103
Cyberだと言ったり、SystemCベースのMicroSSPだと言ったり、一貫性がない
よね。お客さん、混乱するでしょ、これ。でも、やっぱり動作合成って
駄目なのね、相当適用先を限定しないと。それでも、役立つんだと信じたい
けどね。いつになったら、ちまちましたRTLコーディングとか図面修正から
解放されるのやら……。

BDLは、ソフトが入ると無理でしょう？
VHDLもどきだもん

HY-Cはどうなのかなあ？ だれか教えてエロイ人！

>>106
うちは使ってないしこれからもその気はない
プラットフォームだよ。これからは
SystemC未対応は相手にしない

エンジニアの処遇改善の為にも、↓ このムーブメントに乗って下さい！

　日本国民はエンジニアを尊敬しる！
　http://science3.2ch.net/test/read.cgi/kikai/1104172261/20-36

このスレでは、結構な方が首相官邸や政党、各省庁へエンジニア優遇政策
の提言を行っております。皆様も是非ご協力下さい。

>>107
おまいは、>>60 を先ず嫁。話はそりからだ。

>>109
何をどう読むのかね？
ルネサスもプラットフォーム中心の設計に変えた事
SystemCがアーリープロトタイプの為の物なんてとっくに知っていたが
それとも
>HY-CからSystemCに変換して整備した環境に繋げて性能検証、とい
>う筋書きではないのだろうか？
これか？
ありえね。そのようなフローはだれるだけ
大体いちいち変換する馬鹿はいない

>>110
SystemCから手作業でRTL作成、それとも合成、どっちなんすか？
もしかして、合成結果を人手で修正？ それも辛いような・・・。
市販ツールが対応している合成可能なSystemC記述って物凄く制約
がキツイから辛いんですけど、その辺りはどうなんすか？

>>111
あんた学生？
プラットフォームベース設計手法ってRTL作成は基本的にしない
RTLと機能等価なSystemCモデルを使って設計するやり方
いちいちRTLなんか考えなくていいんだよ。　バス以外はね
ルネサスも合成を一時やってた様だけど、今はIPベースまたはプラットフォームに以降済み。
Nは少し遅れてるけど、考え方はみんな同じ
って　ここではSystemCの本質を語るといけないのかな？
だれもそこだけ触れないように気をつけてるみたいやけど

>>112
確かに、バス周りが物凄く重要なんすよね。ここを楽にする方法はないもん
かいなと。HY-Cってこれを楽にする目的で言語設計されているようにも思える
んすけど、それはオイラの勘違いかも知れないっすね。

名スレ
http://tmp4.2ch.net/test/read.cgi/kitchen/1105001950/

N板から今たどり着いたけど
なにここ。
あっちの板でみんな話せばいいのに

HY-Cって化石みたいな話題だな　>>113
BUSモデルどうするかって？　DWに決まってるよ
ところでHY-C使い物になるの？　ルネサス版日立板かなこの話題は

ここで待ってる
http://tmp4.2ch.net/test/read.cgi/company/1100361078/

HY-C ? 設計資産があるから使ってない。

>>115
大変だねー　みんな
ここでまったりする？

うちN資本3％以下に去年なったから、
ルネSH関係でもSystemCの仕事結構回ってきてる。
本体より使ってると思う。
ここ読んで驚いたけどハード設計にSystemCを使う発想って普通じゃないよ
現場では、とっくにシステム設計とHW設計は分けて考えてるよね
合成も夢の話としてはいいけど現実そんな夢を言わなくなって久しい
俺はファーム屋だけどSystemCなしでは今の仕事は面倒でできないよ
RTL屋さんは嫌いなんだろうねーー　俺も少しは分かるけど。。。
では戻りましょうか　いつものスレへ

>>ALL
最後にみんなに教えてあげる
SystemCはハード屋の使うものではありません。
ソフトをインプリ前に乗せる仕組みです。
こればらしちゃいけなかったかも知れないけど、
今度来るまでに少し健全なスレになってなー

どうでもいいけど、お前らWEBで調べて納得してんじゃね。
ASICベンダーを呼んで話聞いたら少しは

>>117
>うちN資本3％以下に去年なったから、ルネSH関係でもSystemCの仕事結構回ってきてる。
　>本体より使ってると思う。

　この本体てＮのこと？　そうだよな　
http://tmp4.2ch.net/test/read.cgi/company/1100361078/

　おまえ資本が減ってもＮ意識じゃねえか？

>>118
　そんなこと誰でも知っている。 何言っているんだ。

ルンルンルネサス頑張ってべーーー
HY-C本当に使ってるの？

おばかじゃない？

http://www.edsfair.com/systemdesign/index.html
宣伝してるよ

>>115
DW(DesignWare)？ こりゃまた独自バスに対応するの大変だな。マジで言って
いるのか、それ？

独自バス関連の設計が楽になるんだったらアリじゃない、そのHY-Cってのも。

BDLでも良いけど、なんかBDLって棄てられてるイメージだし、実際に設計できる
かさえ不明だもんな。で、SystemCは無理だし、SystemVerilogだとRTL書いてる
のと変わらない。Handle-Cなんてハンドシェイクだからそもそも記述すら無理
だしなあ。

つまり、このスレでの独自バス関係の設計への回答というのは、

　　　RTLで従来通りシコシコ設計し続ける

　　　DWを無理矢理根性で構築する

というので皆さん宜しいでしょうか？

聞くだけタダなので、

　http://www.edsfair.com/seminar/index.php?code%5B%5D=77

に行く事にしたよ。NDAとか要求されたらパスだけどね。まあ、馬脚を現すかもな ｗｗｗｗ

>>121
ルンルンは、ルネサスじゃないけど、性格良くないので
告げ口しておいた。

>>117
　ここIDが残らないから、いいのよ。戻らない！

>>125
おまい、ルンルンはルネ板にいるじゃないか。
ルネ板にウンコなすりつけるぞ！

N板だれもこねーぞ
NEL板は、日経の業績発表94％営業益ダウンで静まりかえってる。
>>123
お前もルネ確定　すーぱハイウェーってL1がんがん積んでも慢性渋滞
独自バスの合成？　あきらめなベー　
篠にDW作ってもらうくらいならAHBを使いな。そしたらSH考える。おっとMRもあったっけ。
大変だねー
そいえば、>>123 独自BUSの合成なんかToolで出来るわけないだろ！
お前のところAIで何とかするのかな？
独自バス関連って　はぁ？？　ペリフェラルどうやってくっつけるんだよ
面白いねーー　みんなの発言

>>127
お前、素人だな。独自バスを設計しないでどうやって情報家電向けの
ASIC設計すんじゃ、ボケ！ AMBにいきなりバスブリッジ繋げて独自
バス構築、これ常識だろが！！ こうしたサブシステムの設計が本当に
楽になるんならHY-C上等じゃねーかよ。相当、眉唾だけどな。まあ、
裏切られないように期待しないってのは、ここいら関係ではもう基本中
の基本の心構えだからな。

>>128
興奮してるみたいだけど、AMBってAHBの事？

>>127
しかし、AIってバスプロトコルの自動合成って意味？ プロトコル合成って
何らかの記述言語で記述したプロトコルを衝突などの不具合がないか検証
して実装言語へ変換するとかいう研究なんじゃね？、普通。独自バス云々
ってのは、そーゆー事がやりたいんでねぇーの？

>>128
RTL設計者はこれだから困る。
俺も元Verilog屋だけど..

OCP Sonics AHB/APB それにAXIってデファクト候補がこれだけあるのに、
IBM-Interconect も公開してるしね。
俺を素人扱いするなら、お前が化石であることを認めたことになる。
いまSystemCで情報家電向けSoC設計をするということの意味が、
お前まるで分かっていないようだな。
独自バス構築が常識の会社？　どこだ　間違いなく失敗する。
独自バスを使う必要があるのは、経済的理由と複雑なネゴシエーションや、
アービトレーションが不要な単純な「配線」用途だろ。
僕ちゃん　配線はバスって言わないんだよ。
ともかく、バスは規格であって、標準プロトコルに従うというルールを我慢して、
HW設計者は苦労をするんじゃないか。
独自バスっていうやつは、他人の書いたルールが理解できない、
お前みたいな馬鹿だけ。

15年前にTCP/IPを否定して独自プロトコル考えた俺たちもばかだったけど、
業界動向無視した、集団馬鹿は困るね。

>>130
でも、結局より優れた独自バスを実力あるメーカは作り出すのさ。国際
ビジネス機械で馬力PCの電脳建築屋だった方々は、北米太平洋沿岸の
南方の新境地でコア接続バスを更に発展させていたりするなんて、知りも
しないんだろうな。

それと、バスは用途に合わせて複雑度が変わるのは当たり前。製品にあった
複雑度の選択が重要なのよ。で、丁度良いのが見当たらない場合もある。
その場合にシステム屋自らが起こす事になるんだな、これが。まあ、確かに
それってタダの結線だろ、みたいなのもあるけどね。そんなのばかりじゃ
ないのも事実。

ブラックボックス化とか、ストック型モデルとか、そーゆーキーワードと
標準化って相反するんだよね。牧本ウェーブなのさ、結局。標準化と独自化
の繰り返し。で、今から暫くまた独自化の波が来るって事った。分ったか
房や。

>>127 >N板だれもこねーぞ NECエレ？
>>131 >牧本ウェーブ ルネサス？

両者の対決如何に

>>132
牧本さんって今、糞ニーじゃなかったっけ？ で、ブラックボックス化は
派那だよね。そういや、糞ニー、バ韓国企業と独自路線だな 藁

>>127

　売上高　　　６％減
　営業利益　　９４％減
　税引前利益　９９％減
　純利益　　　９９％減

　http://tmp4.2ch.net/test/read.cgi/company/1100361078/268

　ﾌﾟｹﾞﾗｯﾁｮ (w

この板、論理設計できない奴等が現状の動作合成を貶しているようにしか
見えないけど。　おまえら、体力ないモヤシ？

>>135
RTL設計は、遅延がターゲットデバイスでどれ位になるか考慮しながら
行う分野に最適。こういう職人芸的な設計ならRTLというか殆どゲート
レベルのRTL設計が一番。こういうエンジニアが沢山居て、しかも収益力
があるなら問題なし。

でも、現実ってそうじゃなくて厳しいでしょ。一人でDSPアルゴブロック
バス・ローカルメモリ周り、中<-->中、外<-->中転送のインテリジェント
な高機能DMAC、三ヶ月位で仕様おこしからデバッグ、遅延チューニング
込みでやる体力って常人にはないと思うぞ。まあ、世の中にはそうい
香具師もいるようだけど。せめて、DSPアルゴブロックを、って思わんか？

>>136
それ、積和演算の多い家電製品の話だよな。

ワンコアで実現するとなると大変だけど、マルチコアにして必要ビット数を
最小限にし、汎用CPUの支援プロッセサとして動作させれば、消費電力も
クロック２乃至３倍より増えない。またそれ専用で考えればいいのだから
設計も複雑にならない。そのプロセッサに実装されるOSのカーネルも
知っていればバスの制御だって自ずから決まるというものだ。但し
チップサイズが大きくなる欠点はあるが、間違っているかな。また
仕様の決まらないで設計を始めないといけない環境は抜きですよ。

おまえ初心者かと言われそうだけど、　
間違っていれば、ごめんと言うことで����

>>137
メモリアクセスが頻繁だから、インテリジェントな高機能なDMACなんて言葉が
>>136 にあると思われ。マルチコアというより、プロセッサ＋コプロ＋フォン
ノイマンボトルネック解消の為の特殊なDMAC利用、ってのが >>136 の想定して
いるアーキだと思われ。コプロが直接メモリ管理するような設計だとかなり
高性能なコプロが必要になると思われ。下手すると、DMACでデータ転送しなが
らCRCチェックくらい行っているなんて実装もありのような。そうなると、
もはや単純なマルチコアではないよね？

間違ってたら、スマソ

画像処理専用なら、専用メモリ実装したDRAM混載でOKではないの。

回答間違っているかしら？

Makimoto wave
http://pc.watch.impress.co.jp/docs/2004/0524/epf13.jpg

実現出来そうもない仕様を貰ったのか？

その場合は、仕様変更案を沢山作って、逆にこのようにしたら出来ると
仕様変更検討依頼だなぁ。

三ヶ月位で仕様おこしからデバッグ、遅延チューニング
込みでやる体力って常人にはないと思うぞ。

やった挙げ句に「これって実装できませんよ」と言われて
全部ご破算

>全部ご破算

仕方ないね　
ご愁傷様　出来ない理由は報告書にまとめておいたほうがいいぞう。後々��

皆さんこんばんはーーー

元気でやってるかい　ルンルン君もここにいるのかな？
3連休仕事忘れて、転職先でも探そうね。
http://rikunabi-next.yahoo.co.jp
キーワードは勿論SystemC
あれあれ、韓国系二社がヒット

Nのキーワード入れてもだめだねー　何でかな？
ルネ　おおおっーー

Ele営業利益もっちょとで-100%惜しい！　頑張ったのになー
本体はままあ、そこそこ、想像通りにはいいんだけどね。　
本体ってELeじゃないよ念のため

>>135
RTL屋さんはSystemC使わなくっていいんじゃない。
RTOS乗せてドライバや通信アルゴリズム（ソフト）検証するのは、
あなたと別の次元だけど、動作合成に期待してるのはなぜかハード屋だね。
そりゃ俺たちと付き合うのは大変だろうけど、バグ取りはファーム屋任せにすんなよ
とんでもないメモリー空間しかよこさないで。
バスプロトコルなんか分かった振りしてるだけなのみえみえでやになる。
プロトコルをハード化するって無理だよ。
動作合成　C−−＞RTLってそんなに簡単じゃないだろ!
SWをハードにする発想をどうにかしないと、
SystemCはHW屋には使えないって話だな　
アーリープロトタイプとか仮想ハードってSW屋さんにはよく理解できる話だけど、
ここの板は間違った方向に進んでるね。
SystemCは検証環境で設計環境だと今は理解してるけど、
っていうか使い始めて衝撃うけてるけど、HW屋の認識は違うね。
誰が「使うか」そして最終製品を作るかヨーク考えてね。

age

NECELEででこい

動作合成　C−−＞RTLってそんなに簡単じゃないだろ!

でも、某C系動作合成ツールでUSBコントローラを書いたら
一週間でできて動いてしまった。
システム設計屋のレベルからしたらくだらんことなのだろうけど、
漏れは非常に嬉しかった。
一番問題なのは、これに味をしめた上層部が無茶苦茶な
工程表を作り始めるのではないかということだな。

__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

動作合成より10シリカ

>>145
それは言うのまずいよ
N板に帰れ

ずーっと上げっぱなしにするな。

性能検証や機能検証のためのC記述と、実装を意識したC記述は全然別物。
で、SystemCは前者向きで、後者はRTLでないと表現出来ない事が多く
その場合HDLより記述量が数倍に膨れ上がる、というだけの事。なので、
RTL屋がSystemCを使って実装を意識した記述を作成するというのには
無理がある、という結論となるわけ。

で、この後者を簡潔に表現できて、且つ合成結果がそこそこの言語と
動作合成ツールがあれば、それはそれでRTL設計者にも実は受け入れら
れる、というのもまた事実。ここでの候補が今の所、BDLとかHY-Cくらい
しかない、というのが悲しいかな現状。しかし、BDLは未公開だし、
HY-Cは言語のみ公開でツールは今年の第一四半期出荷とあるだけで、
ルネの息がかかってるだろうから、まともに売り出されるかさえ不明、
という状態。あーあ、って感じ。

>>153
RTL屋はSystemVerilogでいいと思う
動作合成もこのあたりからいいのが出てくるとおもわれ

>>154
やっぱ、そうなんかいのう。でも、既に構築してあるSystemCの性能解析
環境とのつなぎとかが大変そうなんよね、それだと。あちらを立てれば
こちらが立たず、って感じだね。

でも、SystemVerilogはVHDLを包含しつつ簡潔な文法になるよう言語設計が
なされているらしいけど、VHDL自体が実は相当でかい言語だからね。合成
可能なサブセットが小さ過ぎると、記述能力って意味でSystemVerilogを
定義した意図が意味不明になるだろうし、大き過ぎたら今度は使いこなせる
か不安だし、SystemVerilog自体、あちらを立てればこちらが立たず、って
要素を含んだ言語なんだよね。

きっと、BDLとかHY-C、Bach-Cって物凄く単純なんだと思う。こいつらは、
CベースだからC++への変換もある程度可能だし、Simulation速度をHDLに
比べて犠牲にする事なくSystemC環境へ接続する事もできるのだと期待
してるんだけどね。結局、お客のデバドラとかファーム、最悪の場合
アプリが仕様みたいなとこあるから、Simulation速度って重要なんよね。
確かに、FPGAボードって手もあるけど、規模がでかいとそう簡単じゃない
からね。それに、FPGAプロトの場合、デバッグとなると結構大変だし。

追記：

仕様というか機能サインオフの条件が「お客のアプリが正常動作する事」
っていう場合、確かにFPGAプロトでないとやりようがないんだけど、
バグ出しはボードの工夫とかである程度可能かもしれないが、バグ修正
を SystemC + SystemVerilog の強調Simulation環境でやるのは、ちょっと
痛い気がしてならないんだよね。

この強調Simが、シングルカーネルのネイティブコンパイル方式とかで
TLMのSystemC記述をOSCIのReference Simulatorで実行するより、概ね
早いとかいうんだったら、勿論Okayなんだけどね。でも、そんなの実現
可能なんかいね？ 教えて、エロイ人！

　×　強調
　〇　協調

鬱出氏膿　ｏｒｚ

>>154
今のSystemVerilogはRTL部分はもろにVerilog HDLだよね。
そこから動作合成とは？？？

>>158
SystemCでそうだったように、元々ある支那腐死巣BCの言語パーサ部を
SystemVerilog対応にして売り出すとかが考えられるけど、どうだろうね。

SystemCでの失敗は、C++プログラマがEDAベンダが考える以上の凄まじい
使いこなしをしてしまった事なんじゃないかな。なので、SystemVerilog
へ移行して、動作合成ツールのコーディングガイドが固まるまでの間は
「RTL＋アサーションです」 で通しているようにも思うんだが。で、
また例によって例の如く、ある日突然、BC for SystemVerilogなんてのが
発売されたりしてね。これだと、RTL設計者がDC使ってRTLというかVerilog
やVHDLを覚えたように、BC使ってSystemVerilogの動作合成サブセットを
覚えるような事が起こるかも知れんね。

まあ、勝手な憶測なので、ソースとか言われてもないが。

内容：
>>158-9
マイナーだけど、アサーションからのRTL合成という意味で、Bluespec
なんてのがあるよ。

　Bluespec, Inc
　http://www.bluespec.com/

　Lecture Slide by Prof. Arvind (M.I.T)　
　http://www.cecs.uci.edu/eve_lec_and_sem_details/lec_arvind_slides.pdf

　Bluespec LRM
　http://csg.csail.mit.edu/IAPBlue/doc/language-manual/lang.pdf

まあ、ゲテモノ系だけどね。

追記：

　A Mini Course on Bluespec (M.I.T)
　http://csg.csail.mit.edu/IAPBlue/schedule/

SystemCはシミュレーション専用でいいじやん

>>162
もうそれは常識。問題なのは、実装とのつなぎ。つまり、必然的に実装は別の
言語で行う事になるので、SystemCで構築した高速Sim環境との融合が問題だ
という事。扱う設計規模が大きくなり過ぎだからね。

>>163
実装を別言語でやるようになら非効率的すぎる。
SystemCより上位レベルの数値計算的なシミュレーションも絶対必要なわけだし。
シミュレーションのためだけに人員配置するのか？逆にアサインされた人間にとっても悲劇じゃないの？
後々の人生考えると。

>>164
そういうのにしか使えない奴をアサインする

良く使うコマンドをハードウエア化できる拡張可能プロセッサ
http://www.tensilica.co.jp/html/products.html

>>166
ARMで既にConfigurable対応やってるので、出る幕ないですから 藁


そういや、SynforaのPICOなんてツールもあったなあ。

　　Synfora, Inc
　　http://www.synfora.com/

FORTRANライクなC記述をConfigurableなArray Architectureで実現して、
複雑な制御系はVLIEWタイプのプロセッサを生成するってシロモノ。
HPの研究所が出身母体で、もともとはItanium対応の最適化コンパイラを
開発していたチームがスピンアウトして立ち上げた会社らしい。

ただ、問題なのは、このツールで合成したRTLはSynforaのIPという扱い
で、出荷するチップ毎にロイヤリティの支払い義務が発生する事。

例え技術が優れていても、これじゃなあ。誰も使わんて。

>>164
> 実装を別言語でやるようになら非効率的すぎる。

　それなら、おまいが合成の事を何も考えていない糞言語SystemCを
何とか言語拡張して、使えるようにせんかい！





　　　　　　　　　　　　　　　　　　　　　　　　　　　　Simulation速度を犠牲にしない限りは、１００％無理だけどね。

>>166
これが実装の解だと漏れもおもう。
CからRTLにするには違いないからね。　只ロイアリティが高そう

ハードはあと十年はRTLがゴールデンだろ。
SystemVerilogやVHDLで実装は書くべきだね。
配置配線とか重たい仕事も永遠にあるからな。
今は、やはりRTLゴールデンのプラットフォーム型の設計の検証に、
SystemCを使うのが正解だと思う。
つまりさ、SystemCから設計を始めようとするから無理があるんじゃないかな。
うちの会社もRTLでハードは実装するからね。
Cから実装は無理ですね。アルゴリズムという意味なら>>166が正解のひとつ

>>169-170
シンシリカの営業の方ですか？ 無茶を言っちゃいけませんよ。

Configurableコアをコプロに使えるアプリって限定されてるでしょうが。
メモリアクセスが頻繁に発生する用途だと、先ずそのままでは使えない
でしょ。コプロにメモリ管理やらせるなんて贅沢な事できないでしょ。

それに、性能そこそこのローエンドモデル開発ではメモリをケチるんだが、
その場合、Unified Memoryアーキとかを採るんだよね。そうすると、低
レベルではあるけれど、ローカルなアプリ向き独自バスの設計が必要に
なるんだよね。そうしたバスとの接続とか大変でしょ。

動作合成の良さは、一般にロイヤリティが不要だという事。で、RTLだと
アプリ特化のDMACやら、バスコントローラやらの設計が即座に行えず、
アーキを幾つも試すって事ができないから、BDLとかHY-Cを使って、お気軽
にその辺りを仕様検討の書き言葉として記述して設計するんじゃないか。

HDLだと、仕様検討の書き言葉ってわけにはいかんからね。

そこんとこ忘れちゃ駄目よ、房や達。

×　シンシリカ
〇　テンシリカ

この版で、こんな突っ込むヤツいないと思うが、>>171 自ら訂正ということで。

>Simulation速度を犠牲にしない限りは、１００％無理だけどね。
それだけ？
合成にこそ問題あるんじゃないの？

>>173
RTLでもそうだが、アホな記述からはアホな回路しか合成されないし、合成
出来ないのよ。

人間は、記述を見て、内容を理解した上で様様な最適化というかコードの
書き換えを行う事ができるが、機械にこのような知的な作業をさせる事は
実は不可能なんよ。

現状の高速Sim用SystemC記述の合成における問題点は、意味解釈に基づく
最適化を行う必要がどうして現れてしまう、という部分。

記述内容の意味解釈が出来てそれに基づく最適化が出来れば凄いけど、
そんな事が可能だったら、例えば、CPUアーキテクチャとかコンパイラの
ベンチマークなんてやる意味なくなるだろ。だって、ベンチマークか
どうか意味解釈して判断して、カリカリにチューニングしたアセンブラ
呼び出せばよい事になるからな。

まあ、実は計算機で解決可能な問題なんて、実はほんのわずかなんよね。
数学的に定式化できても計算機で解けない問題なんて山ほどあるよ。
詳しくは、「決定不能問題」をキーワードにググってくれ。

>>171
テンシリカの営業ではないけど、テンシリカの今の方針はRTLなんかやめて、
専用プロセッサをHWブロックの代わりに使え！だよ。
マルチプロセッサをHW代わりに使ってHWペリフェラルZeroのSoCも実現できるっていうプレゼンを去年、
社長がセミナーしてました。
その時は、馬鹿馬鹿しいと思ったけど結構パフォーマンスも消費電力も満足できるから、
ロイアリティは別にして画像処理関係のアルゴリズム処理の専用「HW」として使えると検討している会社もあるくらいだからね。
ニュースもあった筈　TMCだったかな？

>>175
そういや随分前になるけど、どっかの学会だかシンポジウムで

　「規模がバカみたいに膨れ上がったら、どうせ搭載すべき機能の方が
　　ネタ切れになるから、オンチップ・マルチプロセッサを実現すれば
　　良い。そうすりゃいくらでもトランジスタを消費出来る。独自性を
　　出したければ、アプリケーションに合わせて結合網を変更すれば
　　良い。」

と公演していたスパコンの専門家が居たな。当時は酔っ払っているのかと
思ったけどね。そんな時代がもうそこまで来てるって事なのか？

でもね、必要となるプログラマビりティをしっかり考慮して、専用ハード
とプロセッサ／コプロセッサの切り分けをきちっと行わないと、少なくとも
汎用品としての競争力を出すのは困難だと思うよ。それに、並列プログラ
ミングを開発環境でサポートするのは困難だからね。決まりきった処理しか
しないなら、専用ハードの方が格段に低面積・低消費電力化出来るからね。
まあ、セット部品ごとに個別対応で採算が採れるなら、そーゆー解もあり
かもだけど、低消費電力・低コストが勝負所の情報家電じゃ辛そうな気が
とってもするのは気のせいではないと思うなあ。

これ読むと本気みたい
http://www.tensilica.com/html/accelerate_rtl.html

高性能なASICの開発には多大な開発費が必要となるので、かなり共通部品
として使い回しが効く様に仕様のみならず、プログラムの開発環境も整備
しないといけないんだよね。その意味で、>>176 の言ってる

　＞ 必要となるプログラマビりティをしっかり考慮して、専用ハード
　＞ とプロセッサ／コプロセッサの切り分けをきちっと行わないと、
　＞ 少なくとも汎用品としての競争力を出すのは困難

というのは可也重要なポイントなんだよね。

全部、プロセッサベースでプログラマビリティを持たせるすると、プログラム
の開発環境の整備をどうするのか、という問題が出てくる。一方、自動車用
マイコンのように専用部品を汎用マイコン＋ROMで実現するイメージで、
各プロセッサベースのコプロを実現するのだとすると、プログラムの開発
環境の整備という問題はかなり低減されるが、可也無駄な設計になっている
というのも事実。余程信頼性が要求されない限り、専用部品を汎用マイコン
＋ROMで実現する、なんてのは解には成り得ない。

まあ、テンシリカは元々が高性能かつ高付加価値な市場向けだからね。お金
が有り余っていて、１チップ５０マソとかで良いなら、良いのかも知れない
けれど。

なんだか、既にＳｙｓｔｅｍＣの話題ではなくなっているやうな・・・・・。
でも、まっ、いっか。

＞ １チップ５０マソ

超高速の研究レベルの試作ネットワークルータとか、原発、軍事用途なら
アリでない。しかし、そーゆー仕事には無縁だのう。

久しぶり

話題がそれたついでに、
http://www.kumikomi.net/article/report/2003/04edsfre/01.html
Target とかLisatekってのもあるよね。

ハード化が面倒ならソフトに最適化された専用インストラクションプロセッサ？
シングルインストラクションMPUっていうのもありなんだね。
合成の議論の発端は、ソフト又はアルゴリズムをマイコンで動かすと性能や電力の問題にぶち当たるから、
ハードにして欲しいって依頼を出すでしょ。
じゃ、手っ取り早い専用のプロセッサを作るってのがいいみたいでMP3なんかもハードとしてプロセッサモデルが存在する。
でも、テクノロジはプロセッサだから使いまわしが出来るので、継続使用を考えれば高くないのかもしれない。
50万のFPGAは考え物だけど、数出ればSoCでやっていけるのでは？

過疎板でこのスレだけ浮いてるな

本スレ以外の住人SystemCに感謝するかな？

>>180
ドイツのAachen University of Technologyで開発されたLISA

　www.sigda.org/Archives/ProceedingArchives/ Dac/Dac99/papers/1999/dac99/pdffiles/51_2.pdf

を入力記述言語としたASIP(Application Specific Instraction set Processor)
生成ツールとして、LisateckとAXYS Design Automation

　http://www.coware.com/portal/page?_pageid=167,106822&_dad=cust_portal&_schema=STAGE
　http://www.axysdesign.com/

があったけど、LisateckはCoWareに、AXYSはARMに買収されちゃったね。

この系統の研究だと日本では、阪大の今井先生が有名だよね。

　http://www.eda-meister.org/asip-meister/

このあたりの技術になると一般エンジニアが使うレベルではなくなるね。
研究室で研究している技術が民間に渡るのは5年かかるからね。
ここの研究室の研究で起業の予定があれば早いかも。
出資者がいればだけどね。
横浜方面の合成研究している研究室もスポンサー探してたけど見つからないみたいだし。

周りに聞いたら結構知ってる開発者がいて驚いた。
でも使った事あるひとはいない。
使用経験者、情報求む。
組み込みソフト屋がHW？？？作る時代がきたのかな。
NからSystemCの紹介が初めにあったときは、
これからはC言語経験者がHWを作るってモチベートされたのは3年前。
ちなみに、そんなことは無かったけどね。

ttp://www.tensilica.co.jp/html/rtl_performance.html

e-言語のベリシティ買収
ttp://www.eedesign.com/showArticle.jhtml?articleID=57700906

ISSを使わない高速協調検証技術，SystemCベースでSTARCが開発
こんなニュースも
ttp://techon.nikkeibp.co.jp/article/NEWS/20050111/100388/

プロセッサアーキテクトのイヤな所は、LISAとかそういったプロセッサ
記述言語を見せた途端に、やれ、SIMD命令は記述できるのか、とか
ハイパースレッディングが記述出来ないようじゃ駄目だとか、自分の
領域を自動化されるのがイヤらしく、叩き潰しに来る事だよね。だいたい
ハイパースレッディングなんて組み込みで必要なのか？ まあ、そう言っ
たら、スーパスカラで記述不能な動作をすぐさま答えたけどね。頭良い
んだろうけど、融通をちょっと位は持って欲しいとおもたよ。

確かに、支那腐死巣の動作合成ツール君もプロセッサコアはRTLで設計
してね、って言い切ってたしね。その方が良いのかもね。

ASIPの辛さは、OSやその周辺ドライバの移植性なんだよね。確かにコプロ
のみって割りければ何とかなるかもだけど。そこんとこ、どうしてるんかい
なと。経験者の方、解説よろぴくです。

プロセッサ記述言語ってなんだか強そうだけど、
SystemCに関係は？
ASIPって　エーシップッ　と発音するのですか？
なんか台湾製のような響き

ここの板は書き込み3人だけ？
マターーリしてる
　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

>>189
発音だいたいあってますよ。えーしっぷ です。プロセッサ記述言語とSystemC
が関係するかというと、言語としては殆ど関係しないと思います。ただ、LISA
の場合、Cライクな文法を用いてマイクロアーキの動作記述を行う形式ですので
Cベースという意味での共通項があると思えばありますが。まあ、かなり
こじつけですね。

ただ、LISAで記述したプロセッサモデルから、論理合成可能RTL、開発環境
としてのコンパイラとアセンブラ、リンカ、それとシミュレーションモデル
としてのSystemC記述が生成されたハズです。これは、確かAXYSもLisateck
もそうだったように記憶しています。カタログベースの情報なので、
定かではありませんが。

ARCやXtensaは、基本命令セットを持っていて、それにユーザ命令を追加する
形式。方や、Lisateck、AXYS、TargetCompilerはユーザが全ての命令セット
を決定する方式。ちょっと違う。ARCはローエンド向けの軽い感じのRISC
プロセッサで、XtensaはDual MACとかばりばりハイエンド向けの思い感じ
のどちらかと言えばMediaプロセッサ系で、パター損教授の申し子。
こんな感じじゃない。

スレ違いのレス、ソマソ。

で、結局BDLの情報は？ 誰か特許番号を吊るしてたよな。それと、HY-Cって
対応合成ツールはいつからリリースなんだ？ 情報きぼんぬ！

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

＞ ALL
変なのが発生し始めたので、sage進行でお願いします。

　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　／￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ ﾟ ∀ ﾟ ）＜　さいたまさいたま！
　　　　　　　　　　　　　　　　　＼＿／　　＼＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧∩ ／￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼ ∩∧ ∧∩＼（ ﾟ∀ﾟ）＜　さいたまさいたまさいたま！
さいたま〜〜〜〜！ ＞（ ﾟ∀ﾟ ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／ ｜　　　 〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」
　　　　　　　　　　　　　 ￣　　　　 / ／
　　　　　　　　　　　　　　　　　　　￣

>>193
　http://www.edsfair.com/seminar/index.php?code%5B%5D=77
にでも行って、情報入手してここに吊るしてくらさい。つうか、EDA部門
じゃないので行けないっす。

HY-Cはもう終わってるツールだと思う
来年は無いね

最近はSyetemC対応のビヘイビア合成が各社から出てるから、
どうあがいても◎立一社では支えきれない。
結局標準ではないものはいつの間にか淘汰されるんだよね。
大手EDAに売るしかないね

>>199
SystemC対応の動作合成ツールは、Forte、礎デザインオートメーションと
研究所でそれらしい事をしている大手C社の三社。で、SystemC対応の
論理合成ツール(動作合成ツールとは呼べない)はCeloxica。確かに、
結構居るね。でも、Handel-Cは標準じゃないけど、しぶとく生き残って
るね。HY-Cもその可能性は否めない。というか、LRMが主張する所の
Semi-Formalってのが、本当だったら面白い展開になるかも知れないね。
案外、どっかの国の軍隊とかが採用したりしてね。

そういや、支那腐死巣もSystemC対応の動作合成ツールを提供していたが、
余りにも酷かったので、ディスコンになったのは当然だと当時思ったよ。

SC_THREAD対応の動作合成ツールが市場に出てきたら、考えてもいいかも
ね、SystemC。でも、記述能力にやっぱ問題があるんだよね、SystemC。
ちょっと抵抗感はあるんだけど、>>145 の言ってる事がかなり的を射て
いる気がしてならないんだよね。

　　　　　　　　　　_,,.．-一=''ー-､.　　　　　　　　　　　　　　　　　
　　　　　　　 __,,.;-''´;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;｀‐-､._
　　　　　　 r´;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;'ヽ、
　 　　　　（;;;;;;;;;;;;;;;;;;:::::''''''''''''''''::::;;;;;;;;;;;;;;;;;;;;;;;;;;i、
　　　　　　`i;;;;;;;;;::'''　　　　　　.....::.;;;;;;;;;;;;;;;;;;;;;;;;i
　　　　　　　''''''/　　　　　　　　.......::::::::;;;;;;;;;;;;;;;l、
　　　　　　　　/　 ,＿_ 、＿＿＿::::::::::;:::;;;;;;;;;;;;;;i
　　　　　　　⊥ _ f ‐._´`i￣￣￣ ::::::: r´ ｀i,;;;;;;,l
　　　　　 r´. l_,.,i t, "~’j　　　　　::　　ヽ,　.ｌ;;;;;;i
　　　　 　'i､　|'~ﾉ ,ヾ-‐´　　　　　　 l ィ´, ﾉ;;;;ｌ、
　　　　　　`-+イ､,・ .)、　　　　　　　`;- ´ ;;;;;;;ｊ　 ＜殺すぞボケ！！
.　　　　　　　`::ﾉ ,=--､ヽ　　　　　　　　　／';、　＿＿＿＿＿＿＿＿＿＿
　　　　　　　　`i ､==‐ﾌ　　　　　　　　,／ 　　ヽ--―--、　　　　　　　　 .／|
　　　　　　　 ／`i、"´　　 ノ　　　　.ィ´　　　　_.ィ´　　　,,＞ー-､_..　 .／　　|
　　　　　　／　　ヽ__, ,ィ"´　　 ,.ィ´　　　　,.ィ´ //　　／　　　''　　.／ 　　　.|
　　　　 ／　　 〃´　 >- 、 　／　　　　　／　 //　 /´　　 〃　／ 　 　　　 .|
　　　／　　　 /　 　,ﾉ　,=､ヽ/＼　　　 ,:'´　　 /／ /　　 　　／　　　.　　　　|
　　　|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|　　.　 　 　. .　　|
　　　|　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 | 　 　 　 　 　　　|
　　　| 　 　 　 　 　 　 　 　 　 　 　 　 　　 　 　 　 　 　 　 | 　 　 　 　 　　　|
　　　| 　 　 　 　 　 　 　 　 　 　 　 　 　 　　 　 　 　 　 　 | 　 　 　 　 　　　|
　　　| 　 　 　 　 　 　 　キ 　 　ム 　 　 　 　　 　 　 　 　 |　 　 　 　 　　／
　　　| 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　　 　 　 　 　 |　 　 　　　／
　　　| 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　　 　 　 　 　 | 　 　　／
　　　| 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　　 　 　 　　　|　　／

　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　／￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ ﾟ ∀ ﾟ ）＜　さいたまさいたま！
　　　　　　　　　　　　　　　　　＼＿／　　＼＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧∩ ／￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼ ∩∧ ∧∩＼（ ﾟ∀ﾟ）＜　さいたまさいたまさいたま！
さいたま〜〜〜〜！ ＞（ ﾟ∀ﾟ ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／ ｜　　　 〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」
　　　　　　　　　　　　　 ￣　　　　 / ／
　　　　　　　　　　　　　　　　　　　￣

HDラボのSystemC e-ラーニングシステム

http://www.hdlab.co.jp/service/e-Learning/top.html

ライセンス有効期間は3ヶ月で59,800円はちょっと高いか？

>>203
腐汚流手にツール評価のためのトレーニングを依頼すると、その寄生虫会社
を紹介されて、しかも有料。完璧にナメ腐ってますな。まあ、これでなら
許すが、 つ�I

合成可能な範囲でのSystemCを勉強したければ、
　http://www.inf.pucrs.br/~calazans/research/BrazilIP_project/SystemC_synth_prot_course/
がオススメ。但し、英語だけどね。後、概要という意味では、
　http://www.testbuilder-jp.com/inno/tu/tumain.html
がいいんじゃない。それと
　http://www.forteds.com/systemc/training/index.asp
なんてのもあるよ。但し、登録が必要で且つ英語だけどもね。


Webで入手できる情報での話しだから、あれなんだが、合成可能記述に
対する制約が非常に厳しいようなので、実際には使い物にならんよね。

　「こういう回路が設計したいのです。」

と質問すると、

　「お客様には既にRTLイメージがおありのようなので、SystemCでRTLを
　　記述いただくか、HDLでRTLを記述頂くかになります。無理に全てを
　　SystemCで記述され必要はないですからね。」

となる悪寒。ｗｗｗｗ

まあ、SystemCはSimulation専用言語という事で。

>>205
この記事を読んでも1000％同意します。
今　いかに高速にシミュレーションするかが多くの企業の懸案なんだと証明されてるね。
合成の問題より、高速検証の研究の依頼がニッポンでは多いんじゃないかな。
Starcの研究テーマは一歩先に行っていない現実の問題を反映しているからね。
ここみれば企業の今の問題がはっきりするね。
3年前は確かに合成にスポットライトが当たっていたようだけど、今はスピードが常識になったって事で、
合成はアボーン！！！
http://techon.nikkeibp.co.jp/article/NEWS/20050111/100388/
。「市場にあるEDAツールに比べて100〜1000倍の性能を出せるようにする」
（設計技術開発部上位設計開発室上級研究員の新舎隆夫氏）という。


研究成果をどう事業家するかがここの研究室の問題だけどね

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

　 　 醴醴醴醴醴ｹ..　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 .ﾞ'..: 『醴醴醴歡
　 　 層醴醴醴歡　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 . .(濁醴醴歡
　 　 醴醴醴醴]['.　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 : ｀:ﾞ{[醴醴¶
　 　 層醴醴蠶[l' 　 　 　 　 .､,,..__＿＿＿_、　 　 　 　 　 　 ＿＿＿＿_. ';ﾞ(}醴醴†
　 　 濁醴醴鏖《' 　 　 　 　 'f『ﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟ閂昃'!! 　 　 　 . -忌『『『『門愬ﾀ!i'ﾞ(ｉ層躑
　 　 ..f[醴醴醴』' 　 　 　 _．　 　 　 　 　 ...`:ﾟ'.:　 　 　(Jl}~ﾟ 　 　 　 .'.^'ﾟ(ｌi､.'僧歉
　 　 . ‘體醴醴廴,｡r､':'｀‘｢.... _,ｇg豐齟籬ｇｊlｊl;ilド 　 .:ﾞl:','｡;i,g豐醯踰ｇz.(.(.( i.ｊ|]｢
　 　 . ;ｔqi_ﾟﾟ¶醴†｀　 　 　 } ｉi填閇ﾟﾟﾞﾟﾟﾟﾟﾟ『『摂'''^' . 　 .::､'ﾇ}們ﾟﾞﾟﾟ門門轡埣lﾞ(|遁
　 　 . ﾞ}}' ﾞﾏl'. ¶$. 　 　 　 ｀ .　 . !!!!!!!!!!!''''＾ .. . 　 　 . ｉｌ｡ﾞ(｀ﾞﾞ'ﾟ''''''?ﾍ'''''`｀ ''､ii濬
　 　 ､ !)　.:..ｊg_ﾟ[Ｉｉ;. . 　 　 　 　 　 　 　 　 　_， 　 　 . ｀?)ｊ、 　 　 　 　 . ._,(,(:ｱ
　 　 　 ′､(|『゜.'ﾟli' . 　 　 　 丶､.,,__.,.,__＿ｖ!ﾟ｀ .　 　 　 '''?ﾃliuｖ- ..､...､r!iﾟ(.(0i
　 　 　 　 .,ﾟ''' -. ' 　 　 　 　 　 　 　 .､.;,(ｊＩｊ.....__,._._..,xs,iiu_,..,,Ｉ詬i;｡.､....､... .(iﾞ(Ｉ
　 　 　 　 ｀｀　 　 　 　 　 　 　 　_._,(ii.lＩ}lﾟ(ﾞ'ｦ増嚇ｊg]獅嬲叛lﾟ(}}ＩＩＩD,;';ﾞ;iiＩi;iiﾞ(|
　 　 　 　 　 　 、 　 　 　 　 　 ::.ﾐ浴?ﾟ(. . 　 　 ｀｀'ﾟﾀ'ﾟ''''ﾟ''''.!''.(ｌＩ泪||Ｉ}i.[(ｌ}}Ｉlﾞ(}
　 　 　 　 　 一' . 　 　 　 　 　 :ﾞ(}l}ｼ.､;;､....､,,__.,uu,｡,,,,,gｇggｊ_ｊ,(Ｉ}'ﾟ(勿l.[(','i}ｿＩ.
　 　 　 　 　 　 　 　 　 　 . . 　 ' .(.(.(.()l瘟尸ﾟﾞﾟﾞﾞﾞﾟﾞﾞﾞﾟﾟﾞﾟﾟﾟﾟﾟﾟﾟ層鬱浴)).'';ﾐi.(,(l;ﾐ.
　 　 　 　 　 　 　 . . 　 　 . . ::､.､..:.(,(:､''ﾞﾟ『咐':'･!･ 　 　f負鄂､.:'.(.(>.(,(3iﾞ(}|Ｉ'
　 　 　 　 　 　 　 '､..　 .､:.､'.:､'.'.'.､.(｀' . 　 　 　 : : : : ｰ;;,(,(ｉ','i.(.(.(.(.(ｌＩＩＩＩＩｉＩＩＩlﾟ
　 　 　 　 　 　 　 　 ､...､'.:.'.､.'.､.'.､::､.　 　 　 . ｀'ﾞ(!!i'ill}ﾇミ(iﾞ'''.､::.(.(ｉＩ|}}Ｉ||肝

>>206
国内EDAベンダと組んで事業化　−＞　鳴かず飛ばず　−＞　あぼ〜ん

まあ、STARCなんてそんなもんでしょ。金食い虫の業界のお荷物。

-─＝==─ヽ/へ
iiii彡≡≡≡|≡ヾ ヽ　　　 ＿＿＿＿＿＿　　　　　　　　　　　　　　　　　　　　　　＿＿＿　,-───
彡≡≡≡≡|≡ミミヾ　／　　　　　　　　　＼　　　　　　　　　＿-=─=-　　　／　　　　 ｀
￣￣￣￣￣￣＼ミiiiiiヽ　　　　　　　　　　　 ＼　　　　_-=≡///::　;;　''ヽ丶/ヾ　ヾ .,! !,,!＿´,,//_／／
　　　　　　　　　　 ＼iiiiiiiゞ　　　　　　　　　─　 |　 ／ 　　　''　　~　　　　ヾ/=/`''~~　　　　　　　/彡-
　　　　　　　　　　　　 ＼iiヽ　　　　　　　 ──　| /　 　　　　　　　　　　　　|=.|　　 　　二　　　　　| 三
━━━'/　　ヽ━━━ ヽミヽ _,-＝-　　_,-=　ヽ| | 　　 　　　　　　　　　　　 ヽ|　　　──　　　　　＼三
　 ⊂⊃,.::　　::　⊂⊃　　ヽiiiii　⊂⊃ノ_⊂⊃ ヽ│|≡　　 　　　,　、　　　　　　||　ヽ　,, 　　、ｰ￣　　　＼
　　　　　　　　　:::　　　 　 |iiiii 　　　　　　　ヽ　 │|≡_≡=-、_＿＿, - -=≡=│　⊂⊃　　　　⊂⊃　　　|=
　　　　　　　　　　　　 　 　|iii|　　　　 ( о　)　　 | | ,⊂⊃　|　 　　 |　⊂⊃　|┤　　　　/　　　　　　　　　|/
　　　 （　●　●　）　 　 　 .|iiii| ／_,,,,;;iiiiiiii;;;,,_ヽ　 |ヽ二＿,(　　 　）＼＿二/　|　　　 ( ｡つ＼
　　　》━━━━《 　 　 　 |iiiii|///;;;;───､ヾ. |　　　/(　　　 　　)ヽ　　　　| 　　　/　　　　　丶ー
　　》　／￣￣＼　《 　 　 |iiiiiiii|:::///＼＿_/ヾヽ| 　　/　　⌒｀´⌒　　　　　　| 　 　/＿＿＿＿」
　《《　 ＼￣￣／　》》 　 |iiiiiiiiiii|::// ;;　　; ;; 》::::::|　 　　　　　　　　　　　 ／　 | 　 　　　|/ 　　 /
　 》》　　 ￣￣　　《《　》》》》》iiiii|::《　;;　;; ;》　;;》:（　 　　|＿／ヽ_'＼＿／　　　|　|　　 　|＿＿/　 　　//
《《《《《《《《《》》》》》》》》》》》》》》iii|/ 》　 ;;》　》　;;ミ ヽ 　　､＼_￣　￣／ヽ　　　 ヽ　　　 -─　　 　　 /
巛巛巛巛》》》》》》》》》》》》》》IIII　　ヽヽ《　;;; 》(　　＼ 　 | 　 ￣￣　　　 　＿／/ ヽ＿＿＿＿_/_ノ
巛巛巛巛》》》》》》》》》》》》iiiiiii　　　　　 ``《人/　　　＼__ ヽ＿＿＿＿／　　／

>>209
国内大手EDA候補
　上流
1位　図研
2位　インターデザイン
3位　礎DA
4位　ジーダッド
5位　マイクロアーク
その他
エスアイアイ・イーディーエー・テクノロジ
日立超LSIシステムズ
富士通LSI
ソフィアシステムズ
こんなところかな

個人的には、Cyber公開かHY-Cに期待している。変ですか？

>>200
ま、まさか米軍とかでしか？ いくら◎立が政治力に長けてるって言っても
そりはないでしょう。でも、確かに米国での話だし……。もしそうなら、
そのHY-C(何て発音するのか不明)は超だーくほーすっちゅー事かいね？

>>211
図研はないでしょ
CATSあたりかもね　
でも本当にどことやるのだろ

>>212
あるスジの話だと、アメリカ大手EDAにCyb○rの売却話があったらしいけど、
金額的に折り合わないのだそうだ。
だから、開発はまだまだ続くそうだ。やめ時失ったから続けるって矛盾してるけどうなずいた。

>>211
ジーダットって上流なの？
どっちかというとDFM関係のような気がしたのだが。

>>215
やっぱ、そうなんだ。ていうか、Ｗ林さんどっかの学会で

　　８０年代の前半からやってるから、ＥＤＡベンダより優れていて
　　直ぐには追いつかれない状況にある、でも、数年したら、市場
　　にも使えるツールが現われ始めるかも知れない

とか言ってたからね。しかし、そんな昔からやってたら、コードの保守
とか大丈夫なんかいね。もう誰も触れないコードとかがあったりして。
その大手、可也賢いかも。

>>217
行く川の流れは絶えずして、しかも元の水にあらず

>>218
よくわかった
これも贈る

祇園精舎の鐘の声
諸行無常の響きあり
沙羅双樹の花の色
盛者必衰の理をあらわす
おごれる人も久しからず
ただ春の世の夢のごとし
たけき者も遂には滅びぬ
偏に風の前の塵に同じ

そして、誰も来なくなった。
これじゃ、学問は発展しないよね。相手への口撃の中に、
キラリと光る好撃を見出さないと。
”シミュレーション”の枕詞外せば、皆寄ってくるかもよ。
意外とみんな偶に覗いて、変化を望んでるだろう。
>>ALL
誰か吼えてくれ。

先ずは受講するか
ttps://www.necuniv.com/jgk/soc/mosi_form.htm

うぇ　これも高い

SystemCユーザフォーラム2005
司会：長谷川 隆 氏（富士通）
1. 河原林 政道 氏（NEC Electronics America）：IEEE標準化状況およびSystemC最新状況とロードマップ、US/EUでの利用状況
2. 高嶺 美夫 氏（ルネサステクノロジ）：短TAT性能評価プラットフォームとその応用
3. 塚本 泰隆 氏（リコー）：動作合成ツールを使ったJPEG（DCT）回路の設計事例
4. 柿本 勝氏（ソニー）：動作合成の設計適用事例とその効果
1月28日（金）
9：30〜17：00 場 所 ：
パシフィコ横浜 アネックスホール F204
聴 講 料 ：
5,250円（消費税込み）/セッション
定 員 ：
100名／セッション

1番と3番の人有名だよね

２番以外はどれも有名人だが。

面白いから、これ読め！
ttp://www.deepchip.com/items/0438-01.html

2番がかわいそう。元俺の上司だったなぁ。

いよいよ等価検証
http://www.calypto.com/events/japanseminar/

>>227
期待したいですな。でも、どうせSC_METHODとSC_CTHREADのみサポートなんだろう
なあ。それだとなあ……。無理もないんだけど。でもなあ……。

>>255
英語じゃねーか
なんて書いてあるか、お前がきちんと要約解説しろ
それとも、お前が読めないから釣ってるのか？

SystemCに関係あることか？？？

hTTPのｈが抜けてるみたい

>>230
仕方がない釣られてあげよう。

Assertionを記述する言語として、貴方はどれにマンセーですか？ という
内容。で、「現状はPSL、でも将来はSystemVerilogだよね！」 というのが
大半の意見だそうな。

また、e や VERA のような独自言語は瀕死の状況だし、ユーザでさえPSLや
SystemVerilogへの移行を行いつつある、という現状も報告されている。

つまり、DBL、HY-C、Handel-C、Bach-Cなどなども、いつかは同じ運命を
辿る可能性がある、とも解釈できる、という事。逆を言うと、標準化
されれば、HDL論争で当時明らかに後発だったVHDLがそうであったように、
生き残るとも言える。やはり、米軍の力は強大だと。

でも、SystemCのIEEE標準化での番号は、悪魔の数字である６６６を
そのまま含んでいたりして、結構皮肉な運命だね。

e言語はなくなるのかな？

俺も釣られそうになったけど、面白かった。
教えてあげない

>>233
Cadenceがどう扱うかねえ。自身はPSL推進だけど。
テストベンチ言語の一部としてニッチに生き残るかも試練。

SystemCのTestbuliderは死滅する方向だという事だけは、はっきりして
いそうだね。SystemC + PSL で SystemVerilog に対抗するのかどうか、
はたまた e を持ち出してくるのかどうか、まあ、じっくり観察するしか
ないね。

SystemC使えといわれている。

5万9千円という金は会社持ちだからいいんだが、
こんなんで基礎学ばせていいのか疑問
http://www.hdlab.co.jp/online/online.html

SystemC e-Learning System使ったやつ体験をここに晒せ

SystemC synthesis under $2,000 debuts
http://www.eedesign.com/news/showArticle.jhtml?articleId=57701852&kc=4217

Celoxica同様、Scheduling/Resource Sharingなどの動作合成技術は一切
未サポート。SystemCからの超破格論理合成ツール。

そこまでしてSystemCを使いたいものなのだろうか？

>>237
先ず、オマイが体験を鶴氏やがれ！ まあ、どうせ寄生虫会社の社員なんだ
ろうけどね。

明日からＥＤＳフェア。Ｃベース設計は盛り上がるのだろうか？

結局、お手軽さが重要だろうから、ＳｙｓｔｅｍＣは敬遠され、ＡＮＳＩ−Ｃ入力ツール
のみが今回は生き残るような気がするな。本家本元のＹＸＩなのか、後追いのＭｅｎｔｏｒ
なのか、どっちなんだろう？

まあ、両方頑張って、実設計での成果が出始めたら、考えようっと。初期に
投資するほど馬鹿らしい事はないもんね。

>>239
どこぞのEDA屋か、逝け。誰も釣れねぇぞ。

SpecC本家本元のメンターと元祖YXIの香具師が釣れた
http://www.yxi.com/news-03-23-00.htm

>>240
SystemC陣営、必死だな　ｗｗｗｗ
確かに、もう腐汚流手に商機はないよな、実際。

>>241
SpecCなんてもう死滅してるんじゃないの？

ARMの開発（買収）したC言語設計が新しい流れになるかも。
専用ツールと考えてもほぼ独占でいけるからね
SystemCとISSとソフト開発環境を統一して持っているのはここだけ。
結局ARMにはEDAメーカは勝てない

>>243
プロセッサはARM9でBUSはAMBAかAXIでSW開発環境にRealviewを使う場合、
ARMの開発環境しか選択枝ないって事だよな。
EDAベンダはARM以外のバスとプロセッサで勝負って事で、SHの◎立系YXIの勝ち

>>240
合成はHeuristically programmed ALgorithmic computerが出るまでまて

準備中のESDF会場から書き込んでみるテスト

俺も

>>245
映画「2001年宇宙の旅」の HAL9000 でつか？ チューリングマシーンの能力
を越えたコンピータね。

確かに、計算のComplexityというのは(計算の定義が正しいと仮定すると)
数学的にきちっと定式化されているけど、通信のComplexityというのの
数学的な定義は実は未だだから、実際のところは並列コンピータって良く
わかっていないのかも知れない。なので、完璧にその可能性を否定する
事は出来ない。だがしかし、我々が生きている間に実現出来るかは甚だ
疑問。

並列・並行システムって難しいね。この辺りをきちっと理論的に扱った
のってこの分野だと、OCCAMベースのHandel-C、(恐らく)Bach-Cと、Timed
Process AlgebraベースのHY-Cくらいだね。BDLもSystemCもSpecCもその辺り
は殆ど脳味噌無し無し状態で議論がなされているのは事実だね。理論的な
背景の無さで言えば、この３つは存在価値さえないんだけど、ツールが
その内２つは揃っているから話がややこしいのかも。

>>249
BluespecもTRSをベースとしてるから、ちゃんと考えてるよ。でも、ゲテモノ
なのは事実だけどね。

シャープがC言語設計で開発期間1/4にしたそうな
http://www.sharp.co.jp/corporate/news/050124-a.html

>>250
シャープ以外の誰も嬉しくないな、それ。例えば、シャープでASICなんて
作るかあ？

そういや、Mentorに売っぱらったんぢゃなかったっけ？ 関係者の方、
情報ヨロ！

>>251
>シャープ以外の誰も嬉しくないな、それ。例えば、シャープでASICなんて
>作るかあ？
お前バカ？
今時、社内各所からのASIC開発を請け負うASIC/LSI設計センターなんてこれぐらいの規模の会社になれば
どこでも設置してるよ。多くはそこから害虫先に振り分けられるけど。
それと情報家電作ってる会社でASIC起こさない会社なんてない。
DVコーデックあたりは外販してたし、カノプのDVStormはシャープ製使ってる。

>>252
> 社内各所からのASIC開発を請け負うASIC/LSI設計センターなんてこれぐらいの規模の会社になれば
> どこでも設置してるよ。

これって、シャープ社内の話しじゃん ｗｗｗｗ

プロセスが世代遅れだから話にならん、と言ってるだけ。 ｗｗｗｗｗ

EDSF SystemVerilogユーザーセミナー、席がらがら。
SystemCユーザーセミナー、席250に500人殺到。立ち見も満杯。
事前予約者5分遅れで、会場入れず・・・

趨勢は決した感あり・・・要約システムレベルの解析、SWプラット
フォームの重要さに気づいたらしい。1,2年遅い感もあるがな　藁

まぁ、すぐにSystemCはがらがらになってSystemVerilogがいっぱいになる罠
そいつらにとってはSystemCが終わってることに気づくのも1,2年先になるだろ。

>>254　>>255
ぜんぜんわかっていないね、おまいら

もう、こういう奴らはいなくなったと思ったけどまだこんなとこにいるんだね。
早く駆除しないと、日本の半導体下請けの設計能力どんどん低くなる。
「SystemCとSystemVerilogを並べて書く奴」はど素人って常識しってっか？
>>255
解説してやるのも馬鹿らしいから、自分で勉強して考えな
SystemVerilogなんて名前付けた香具師が一番悪いが

>>254-255
SystemCとSystemVerilogは競合する言語じゃないんだよね〜
だから趨勢とか勝ちとか負けとかは関係ない。
EDSFのそのセミナー聞かなかったけど、講演者もその辺のこと言ってなかった？

それはそうとEDSFは、Verisityのブースがあのスペースの割りに寒かった気がする。

設計やってる人たちはわかってるからあつくなる必要も無いけど。
>>256　SystemCベンダーさんでしょ
大丈夫　フォルテは頑張ってるのはみんな認めてるよ
ただちょっと強引だからいじめられるんだよね
ど素人に腹立てても仕方ないから無視してまったり行こうね
うちももうすすこしで、内製やめるからもう少し現場の人間にも会いに来てね。
近くまで来てるよ。君たちは競合だと思いすぎ。。。
XYKさんを殺せばフォルテ導入しますよん

SystemCはSimulation専用言語って割り切った方が良いと思うが。実際、
設計しようとしても実現したいハードがHDLよりコンパクトに記述でき
ないし。というか、合成を考えるとRTLを使わざるを得ない部分が多々
あるから記述がどうしても長くなってしまう。そんだったら、SystemVerilog
の方がいいに決まってる。

　　SystemC　→　Simulation専用

　　SystemVerilog　→　実装専用

という住み分けだから、永遠にRTLへの人手変換はなくならないって事
だよね。実際、腐汚流手って、メモリとかバスへのインターフェース
周りは「ＲＴＬ設計です！」って断言してるからね。これじゃあなあ。

それを解決してくれるなら、Ｃベースの独自言語の動作合成ツールでも
アリだと思う。

競合しないってのは。便利な言葉だよなぁ。さも違うベクトルがあるように見せて
単に時間つぶしツールを価値あるように宣伝できるもんな。フォルテさんよ。

>>256
中卒ってば！
必死の営業活動ご苦労さん。ﾌﾟｹﾞﾗ

いっその事、フォルテなんて強い名前やめて、メゾピアノとかに変えれば。
その方がお似合いだよ。ｗ ﾌﾟｹﾞﾗｯﾁｮ

>>259
EDSFでの公演内容に嘘偽りがないなら、YXIがその解を与えてくれそう。
かなり凄いかも。

そうなんだあ。

EDSFの社内レポートみたけど、そうみたいだね。で、実際はどうなの？ 教えてエロイ人！

実際は。。。。。。。。。。。。。

SystemCサポートできないからアボーーーンになったらしい
かわいそう

>>266
フォルテさん、乙！

SystemCのSimualtionモデルの生成を行うようだから、特に問題は感じない。
だって、SystemCはSimulation専用言語であり実装のための言語ではないと
割り切るのが妥当だから。

それにC++よりはCをかけるエンジニアの方が圧倒的に多いのも事実だし、
オブジェクト指向を理解している半導体設計者なんてそんなに居ない。
こうした背景から、SystemCは運用に物凄く問題が多い。もともとC記述
なんだから、そのまま扱える方が有り難い。実際のところは、SystemC
へのCから記述変更しなきゃならんわけだし。Cにちょっとした変更を
行うだけで、RTLのHDL記述とSystemCのSimulationモデルがゲットできる
なら、そんな嬉しい話はない。まあ、これが本当なら、という前提が
付くけどね。それは仕方ないし、いつもの事だから、生暖かく現状は遠目
で静観する事にしている。

腐汚流手に萌え！

>>267
半導体設計者はオブジェクト指向を理解している。ソフト屋より。
LSI内の機能ブロックはOODである。
OODを知らないのは誰？

>>269
Moduleの再利用とかいう意味ならそうかも知れないが、演算のオーバーローディング
やポリモーフィズムなどとなると、大抵の半導体設計者はついてこれないのが
実情。SystemCはSTL上に構築されているわけだし。

それに、文法を制限したとしても、CとC++では考え方が大きく異なるし、既存の
Cの資産を結局書き換える事になる。Cならサッと書いて動作確認も出来るが、
いざC++やSystemCとなると、とたんに手が止まる。最初から設計するなら、何でも
ありだが、現実にはそうはいかない。

>>270
その通り。だけどOODを理解していないわけじゃないし、SystemCという
設計言語を知らないだけ。だろ？

>>270
OBJを置き、そのOBJにコマンドを送る。そして結果が出てくる。まさしくOOD
である。　Moduleの再利用？　もう少し了見を広く考えてみよう。

　　SystemC　→　Simulation専用

　　SystemVerilog　→　実装専用

SystemC と SystemVerilogの間はどうすんの？

SystemCはSimulation専用言語で議論は終わり
>>271
は間違い
>SystemCという”設計”言語を知らないだけ　とか言ってるし
馬鹿丸出し

>>274
RTLで書けば、SystemCからSystemVerilogへは変換できるようになるんじゃない？
より長い記述から、コンパクトな記述を合成でゲットするのって、最悪だね。

つまり、RTLでしか記述出来ない部分が相当多いのが問題。だって、実際の設計
って、シコシコとGlue Logicをいじる事の方が多いでしょ？ で、腐汚流手君は
「そーゆー部分は、もちRTL設計！」って断言している。

これが解決できないと、実装はで視野に入れた設計の抽象度の向上なんて無理
なんだよ。

結局、SystemCはSimulation専用言語という形で、抽象度の向上を果たした、
と言っても過言ではないんだよね。

だから、これを解決してくれる設計ツールがあるなら、そしてＣの設計資産
の流用が割とスムーズに行える程度であれば、独自言語でも良しと思えてしまう
んだよね。でも、独自だとなあ。いっそ、デファクトになって標準化してくれれ
ば、乗りやすいんんだけどね。

VHDLもVerilogもシミュレーション言語だった

VerilogXLはサインオフゲートシミュレータ
ターボはRTL用だった

設計言語？
論理検証言語って定義でいいんじゃないでつか
SystemCはシステムLSI用の検証言語って事ですっきり

>>277
VHDLって実は物凄く記述能力が高いって知ってる？ 両方とも確かにSimulation
言語だったけど、結局物凄く小さなサブセットのRTLしか合成出来ないでしょ。

SystemCも結局RTLプラスαしか合成出来ないんよね。というか、RTLでしかGlue
Logicを記述できない時点で実装を視野に入れた設計抽象度の向上なんて無理
でしょ。

>>278
賛成です。

>>279
確かに
あらためてこの記事読んだけど、だれもSystemCやC言語を設計には使っていない事がわかるね
やはり検証に期待して導入したり、シミュレーション速度だねあとの期待は。
ここのスレ的にはさらに先の話なんだろうけど、現場では設計言語などとは言ってない。

http://neasia.nikkeibp.com/neasia/000253

関係者の皆様

http://www.calypto.com/corporate/management.html
いよいよスタートします。
Eikiさん　完全復活

わざわざ検証言語でシミュレーションだけやるより、
確実に合成できる言語ベースでシミュレーションまで持ち込む方がずっと効率的なんじゃないの？
アプリケーション屋はこんなの使わんよ。LSI屋がRTLにあわせてSystemC使った検証もわざわざやるのか？

>>282
280のリンクをよく読め。
確実に合成できる言語ベースでシミュレーションまで出来ないから、
C言語をつかうんだろ。
まだ、SystemCはエミュレータやアクセラレータの代わりでいいんだよ

>>281
Eikiさんは凄いな。誰か金曜の発表会行った？
報告晒せ

>>282

　×　まだ、SystemCはエミュレータやアクセラレータの代わりでいいんだよ

　〇　確実に合成できる言語ベースを用いたFPGAプロトでのデバッグが
　　　Simualtion並に使い勝手がよくなるまで、SystemCはエミュレータや
　　　アクセラレータの代わりでいいんだよ

SystemCは、どんなに頑張っても「確実に合成できる言語」にはなれない
ですから、残念！

>>283
>確実に合成できる言語ベースでシミュレーションまで出来ないから、
>C言語をつかうんだろ。

違う。アルゴリズムを作ったり、最上位のシステム設計に、合成できる言語なんかでシミュレーションやろうものなら
話が前に進まないからC/C++/Matlabを使う、過去の資産にしがみついてて未だにFORTRAN使ってる誰もが知ってる
大手企業だってあるよ。

>267、269
半導体設計者でRTLやTr.レベルやレイアウト等の下位レベルまで設計してる人はＯＯＰを理解してる。
同じ回路の使いまわしでリプレイスメントを頻繁にやるから。ＥＤＡのＤ．Ｂ．構造も理解してる。
ところが、仕様レベルや論理レベルなど上位レベルだけしか設計した経験がない半導体設計者は
ＯＯＰをなかなか理解できない。

昔、SystemCは半導体１個の中身の設計限定ならＯＫだけど、
HW/SW協調のシステム設計やボードレベルのシステムは困難な印象でした。
名前から受ける印象と違うので紛らわしいね。システム寄りはSpecCでしょう。

猫の手も借りたいほど忙しい半導体設計屋が、C/C++プログラマに手伝わせる為に
C/C++ライクな言語を作ったってのが、真相でないかな？
アーキテクチャをフィックスするまでに、試作設計の検証をしてもらう。つまりリハーサル。

半導体設計屋の数が足りてるところでは最初から確実に合成できる言語ベースで。

>285
FORTRANはコーディングした順番で演算順序が厳密に保証される高級言語だから使われてる。
また、今時のFORTRANはOOPが付いたのもあり進化してます。
C/C++はコンパイラによって動作が違う部分が、FORTRANはどのコンパイラでも動作が同じ。
FORTRAN以外にS言語などがあり、C/C++で代用できない分野がいろいろあるので。

>FORTRANはコーディングした順番で演算順序が厳密に保証される高級言語だから使われてる。
全然違う。
過去の資産がいっぱいあるから使われてる。

>また、今時のFORTRANはOOPが付いたのもあり進化してます。
んなもんはどーでもいい。
77時代のライブラリだけで、数値演算はほぼ全て網羅されてるから使われてる。

>C/C++はコンパイラによって動作が違う部分が、FORTRANはどのコンパイラでも動作が同じ。
なんやこれ？

下らんこと書いていちいち上げるな

>>286
システム寄りはここへ池ww
http://science3.2ch.net/test/read.cgi/denki/1104436852/

システムよりだからこそここでやるんだ。

結局、

　　http://www.deepchip.com/posts/dac04.html

を見る限り、データパス主体のデザインしか無理みたいね。まあ、SystemC
が良いのか、Cのまま扱えるのが良いのか、という趣味嗜好はあるとしても。

結局、共有メモリだとか、モジュール間の接続関係のGlueとかは、対象外
だから、使う場所は物凄く限定されちゃうみたいだね。せめて、任意の
Compiled SRAMを共有して記述できて合成できないと、辛いような気がする
けど、まだまだ時間がかかるという事なのかな。

純粋なCでは当然共有メモリ持つ複数モジュールなんて上手く書けないだろ
うし、SystemCでもSC_CTHREADでUntimed Modelとなると辛いだろうね。
それに、Timed Modelで記述するとしても、対象とする共有メモリがパイプ
ラインアクセスを許す場合は、記述の作成自体がシンドイ気がしてならない。
大体からして、Untimed Modeから共有メモリのメモリコンシステンシーを
保障して合成するなんて事ができるのだろうか？ がちがちに書けば良いん
だろうけど、そうするとGlue君が必要になるわけで、結局RTL設計になっ
ちゃう。

結局、どの合成ツールも本質的には、単一モジュールしか扱えないんだよね。

スキルの低いRTL設計者にとってのみ、「データパス設計が少し楽になりま
した」という程度という事でしかないんだね。

見る限りってどれの事
Forte Cynthesizerのレポートでつか

これは、去年のDACの話でしょ？　ずいぶん前の話だからなー
もう少し良くなってると期待。半導体業界の半年前は3年前に匹敵じゃない？
スキルはともかく、早くやっつけでもいいから終わらせないといけない設計が山の様にあるからね。
期待は高まるよ。
半年前のこれを見る限りでも、
その辺にいるスキルの低いRTL設計者よりいい仕事してる気がする。

今現在、共有メモリをまともにサポートする動作合成ツールはないし、今後
もほぼサポートされる事はないと思うよ。なんなら、ベンダに確認してみれ
ば。「共有メモリ周りはユーザ責任」、ってハッキリ言われるから。まあ、
コンシステンシの問題だけじゃなく、パイプライン・メモリ・アクセスって
いう問題もあるからね。

ユーザ責任って事は、ブロック分割して、メモリアクセス調停とか接続のため
のGlueをせこせことRTLで設計する事になるって事だね。ただ、こうしてしま
うと、全体的なメモリアクセスの最適化とかは人間が一生懸命考える事になっ
て、結局抽象度はサイクル精度以下になるような気ガス。特に、パイプライン
アクセス可能な共有メモリの場合、殆どRTL設計になちゃうね。

共有じゃなくて、１プロセス専用のメモリだったらパイプラインだろうが
何だろうがCompiled SRAM程度のものならサポートできないと話しにならん
けどね。これくらいは、どこのも出来るんじゃない。つうか、出来ない動作
合成ツールなんてあるの？ あっ、ちなみにCeloxicaのは動作合成ツール
じゃないからね。

>>291
>半導体業界の半年前は3年前に匹敵じゃない？
それはあくまでもデバイス自体の話だ。
SystemCの話は基本的には論理合成アルゴリズムそのものの話だ。
アルゴリズムは基本的に20年前と大差ない。

Synopsys社って、いろんなデバイスシミュレーション開発会社買収してるね。

MatlabからRTLを叩き出すそうです。
http://www.celoxica.co.jp/methodology/matlab.asp

これもMランゲージからRTLが出てくるらしい。
MatLab−−＞RTL　Cはいらない
http://it.cqpub.co.jp/tse/IFDW200405/guide/E011.htm

これも
RTLをC言語から自動生成
http://www.tensilica.co.jp/html/news.html

困っています。教えて下さい。初心者です。systemc.orgよりsystemc-2.1を
取ってきて/usr/local/systemC-2.1にインストールし、examplesをmakeして
エラーがでなく処理が終わります。*.cppファイルがコンパイルされて*.o
ファイルが作成されるのですが、run.xファイルが出来ません。その為実行でき
ません。Makefileは、そのままで使っていますがどうしてでしょうか？
（examplesの全てがこうなります。）

リンク失敗してるんでね？/usr/local/systemC-2.1で
configure
make
make install
たとえばsimplebusに行って
make check
でだめ？

>>292
バスマスタになるのではだめなの？

>>299 の通りでインストールしています。原因が分かりません。
　今まで、gccでC++記述の抽象モデルをシミュレーションしていたの
ですが、SystemCだとディジタル回路らしくシミュレーションできるので
使ってみようとインストールしましたが、うちの環境ではダメぽいので、
諦めます。

g++のバージョンいくつ？
どっかでエラーがでてると思うけど、エラーでてない？
でも、諦めるっつーのも美しいかも。。

3.4.3です。　SysytemCだと、デジタルの抽象モデルをは優れていると
思いますが、あまり使わないので辞めます。　お騒がせしました。

http://hidebbs.net/bbs/yukeyukego?sw=4&m=10
画像UP中!!!

>>298
環境は何？ もしかしてCygwin？ もし、そうだったら、

　　TARGET_ARCH = cygwin

ってしなきゃ駄目だよ。

>>304
　出来ました。ありがとうございました。

ForteのCEOが ↓の質問にどう答えるかみものだね☆

　http://www.deepchip.com/items/0439-04.html

１．SynopsysがSystemCとその合成を諦めたのに、何でForteだと上手くいくってのはどういう了見？

２．C合成の等価性検証ってどうよ？ 無理って思うんだけど。

３．C合成のプランに関する大物の苦悩って何？

４．どうしてSystemCって遅いの？ つうか、性能改善すんかいね？

５．２年以内に倒産するか買収されるような会社と何で仕事せにゃならんの？

６．特別な数学アルゴリズムを除いて、並列分散コンピューティングに関わる
　　一般的なコンピューティング・コミュニティでは誰もが皆順序プログラム
　　の自動並列化に失敗し、そうしたアプローチを諦めているのが現状だよね。
　　で、なんでForteは成功するなんて言えるの？ (もし、そういうアプローチ
　　じゃなくて設計者が並列化の面倒を見る事が前提というなら、ForteはRTL
　　を越える何を実際に提供しようとしているの？)

>>305 304
よかった。
（2.1(beta)でconfigure成功してたら、
　ツリーの各Makefileの中　TARGET_ARCH = cygwinにならない？）

>>306
全てが質問されたわけではないらしい。

http://www.eedesign.com/news/showArticle.jhtml;jsessionid=1FNMOQD5IG3GGQSNDBCSKH0CJUMEKJVN?articleId=60401205

Cooley asked Jacobsson why Synopsys abandoned SystemC synthesis.
Jacobsson responded that Synopsys' Behavioral Compiler didn't work
because it came out too early and lacked customer input. Forte's
SystemC-based Cynthesizer, he said, had considerable user input,
and has made verification an important part of behavioral design.

Domic noted that Synopsys supports SystemC for simulation and
high-level verification. "To add one more language for RTL synthesis,
we did not think that was of much value," he said.

Robert Hum, general manager of Mentor Graphics' verification and test
group, noted that Mentor's ModelSim simulator supports SystemC.
Mentor's Catapult synthesis tool is based on ANSI C, he said, because
that works well for the "flow-based, pipelined" designs the tool
targets, and because "dataflow does not need all of SystemC."

続き

個人的には、Synopsysが言っている事がとっても正しい気がしてならない。
それと、使い勝手とターゲット限定のANSI-Cからのパイプライン合成という
Mentorが示した解というのは、ASSPの設計をターゲットとしないセット
メーカに対してはアリだとは思う。でも、余り数は出ないだろうから儲けは
薄そうな希ガス。実際、Mentorの販売活動見ててもそんな希ガス。なんで
やっぱりSynopsysの言っている事が正しい希ガス。

確かに、実装重視のRTLを越える新たなパラダイムが提供されるなら、それが
一番嬉しいけど、慣れ親しんだRTLから簡単には脱却できないので、HDLが
ゲートレベルとRTLとを密な融合で最初から上手くサポートしていたように、
既存のRTLの枠組みと新たなパラダイムの密な融合が初めから成されていない
と、たとえ新たなパラダイムがどんなに素晴らしくても、RTL設計者には浸透
しない希ガス。

この辺を狙っているっぽいのが、BluespecとHY-Cなんだろうけど、両方とも
市場プレゼンスが余りに無さ過ぎなので、期待していいものか不安。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　 　∧＿∧　 ∧＿∧　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕 　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

SystemCでvhdlの同時処理文みたいなのってかけないんでしょーか?

...これからも僕を応援して下さいね（＾＾）。　　　
　　
━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―
　　　　　　　　　
　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。　　　　　　　　　　　　　　　　　　　　　　　　　
　　＝〔~∪￣￣〕　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　__∧＿∧_　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　|（　　＾＾ ）|　＜寝るぽ（＾＾）　　　　　　
　|＼⌒⌒⌒＼　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉　　　　　　　　　　　　　
　　 ~￣￣￣￣　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　 ∧＿∧　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　（　　＾＾ ）＜ ぬるぽ（＾＾）　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　 (⌒V⌒)　　　　　　　　　　　　　　　　　　　　
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。　　　
　　⊂|　　　　|つ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕　　　　　　　　　　　　　　　　　　　　　　　　　　
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

誰か釣ってくれ
http://techon.nikkeibp.co.jp/article/NEWS/20050217/101822/
パチンコで稼いで、どうにかなるなぁ。
>>腐汚流手さん
どうする！？

誰か釣ってくれ
http://techon.nikkeibp.co.jp/article/NEWS/20050217/101822/
パチンコで稼いで、どうにかなるなぁ。
>>腐汚流手さん
どうする！？

>>314
詳しくは、↓ こっち。

　http://www.eedesign.com/news/showArticle.jhtml?articleId=57701852&kc=4217

　SystemCrafter
　http://www.systemcrafter.com/

というか、Celoxicaからのスピンナウトしたエンジニアが起こした会社。
これで、CeloxicaのSystemC入力の合成ツールは死亡かも。

でも、動作合成というよりは、SystemC入力の論理合成ツールだよね、これ。
そこまでしてSystemC使いたいか？


で、腐汚流手さんだけど、

　Got system-level synthesis?
　http://www.eedesign.com/columns/showArticle.jhtml;jsessionid=2QSOYKKSYXWQOQSNDBESKHA?articleID=60402139

でかなり褒められているね。

ただ、>>309さんが主張されているように、SystemCはHDLと違って、既存のRTL
とのギャップが大きすぎて、昔HDLでやってたみたいなコンサバティブな論理合成
導入みたいな感じに行かないから、ちょっと厳しい。それに、ギャップ自体は
本当に大きく開いたままだし。というか、そのギャップを埋めることなく開けた
ままに構築されたのが、SystemC。論理合成のときのようには、いかないね。

議論がとまったのは
>>315が本質を言及ったから？Celoxicaいい線行ってるそうです

>>316
詳しく

今日初めてこの板に来ましたが、
もう議論は終わってしまったのですかね？

CeloxicaのSystemCのことか？
それともオリジナル路線のCベースのことか？
オリジナル路線はいくらよくてもデファクトにでもならないと怖くて使えない。
この規模の会社ならいつなくなってもおかしくないし
もっともシナプシスのSystemCみたいに途中でやーめたってのはもっと悪質なんだが。

>>319
言ってる意味がわからないのですが。

>>320
Celoxicaには
　１．独自言語Handel-Cを入力とするRTLへの変換ツール
　２．SystemCを入力とするRTLへの変換ツール
がある。>>316が

> Celoxicaいい線行ってるそうです

などという妄言を吐いたので、

> オリジナル路線(Handel-C)はいくらよくてもデファクトにでもならないと怖くて使えない。

という発言をしたまで。百歩譲って技術力があるとしても(Celoxicaにそんな
ものあると思えないが)、会社が小さいといつ潰れてもおかしくないので、
そのようなベンダとは付き合えないのは、まあ当然と言えば当然。

で、支那腐死巣の場合は、「これからはSystemCです！」と声高らかに布教活動
を始めたくせに、「SystemVerilogマンセーです。」に無責任にも態度を豹変
してしまったので、こんな道理の通らない事をする外資とは付き合えるかボケ！
となるのも至極当然というだけの事。

もともと自由度の高い言語では、合成は無理なのでは？
SystemC との棲み分けをもっと考えた方がいいと思います。

Verilogだってもともとは自由度はそう低くないんじゃねえの？
論理合成するとなると、
あれはだめ、
これはだめ
で自由度が低くなる。
VerilogにしろVHDLにしろ考えてみたらすごくシンプルな言語なんだよな。
それでも論理合成のために自由度奪われるとすごく記述が難しくなる。
C++ベースで同じような制限をユーザに求めざるを得ないとしたら破綻しそうな気がするな。

>>323
大当たりぃ〜☆

だから、論理合成には、VHDL か Verilog でいいじゃん。
どうせ今後は、RTL に関してはchip 単体よりもIPコアの開発がメインでしょ。
SystemC は、TLMでシステム設計、ソフト開発とかに適応すればいいんです。

>>302
gccでSystemCを使う場合のgccのバージョンは、3.2 か 3.3　だったと
思ったが、内とこでは、確か 3.4ではコンパイルできなかった。

SystemCrafterってXilinxに落とせて$995なんだ。
プライベートで買えないこともないな。

そんなもん使わなくてもVerilogかVHDLが使えたほうがより自分の考えてるのに近い回路ができあがる。
Xilinxに落とせるつったってCoregenでサポートされてる分についてはどうしてくれるんだ？

漏れはヘタレだからＣでゴソゴソ書いて落とせるなら嬉しい。

＞Coregenでサポートされてる分についてはどうしてくれるんだ？
おおかた、SC側では外部関数のようにしてVHDLを生成
（分割コンパイルと同じようなもん）しておいて、くっつけるんじゃない？
間に一枚皮を被せる位の細工は必要かもしれないけど、
所詮出てくるのはVHDLだし。

coregenってISEのバージョンとかチップによっても設定がいろいろ違うの知ってる？
DCM一つとってもcoregen使わんわけにいかんだろ？
今でも結構じゃまくさいのに、ISEがサポートしてない言語でcoregenを使おうとするとめちゃくちゃ面倒だろうよ。
つーか、現状FPGAでCベースを持ち込むのは逆に手間が増えるだけで生産性の向上につながるとは思えないな。

他のC合成だけど、ALTERAのMegaWizardで作るやつは簡単に
取り込めたけどね。

＞ISEがサポートしてない言語

え？VHDLサポートしてないの？

これ使えそう
ttp://www.cqpub.co.jp/dwm/Contents/0089/dwm008900700.pdf

>>331
何をあげあしとってんだよ。
HDL使ってユーザが作ることのできるライブラリならともかく、
Megacoreやcoregen使わないと設定しようのないチップ固有の機能の場合、
非常にやりづらいといってるんだよ。
機種間の互換の問題もある。
ISEなりQuartusがネイティブでサポートしてないような言語になんらかのツールをつかって変更するのは
面倒極まりないつってんの。
デバイスフィッタであるこれらのツールは、
お決まりのことを手早くこなすために作られてるんだからそれからちょっと外れるだけで非常に面倒だといってるわけ。

リコーは一貫してTLMについて話してたから、信用できる。
EDAの会社は合成ばかり言ってるけど、
シミュレーション言語とはっきり言っているこの記事は面白い

僕の取引先の、ケイデンスの子会社のSystemCの会社もTLMはシミュレーションの目的って言ってたな。
Modelsimとメンターの関係みたいな構図を考えてるのがみえみえでうざいから、嫌いだけどね。
でもやってる事はリコーとケイデンスの子会社が一番正しいような気がしてきた。マイナーだけどね

>333
SystemCからの合成っていったって、所詮ただの
VHDLジェネレータじゃねぇの？
手書きVHDLで一枚皮かぶせてやりゃいいだけじゃね？

ＮＥＣのＢＤＬ／Ｃｙｂｅｒは社内でかなり使われているようだ。
http://www.kumikomi.net/article/explanation/2002/08cbase/01.html

ＳｐｅｃＣの活動が停止している。　終わったのか？
http://www.specc.gr.jp/index.htm

いや！完成したんだよ。

>>337
そう、破綻して終了です ｗ

しかし、SystemCはしぶといね。Simulation専用言語って早く公に宣言して欲しいもんだ。

Systemcは、ゲームを開発するソフトでしょう
http://www5a.biglobe.ne.jp/~hamabe/main_j.html

>>339
宣言してるよとっくに。
他に使い道ないよ　この議論はとっくに終わってるから、もういいよ
それ以外使い道ないし、セラロやエクストリームの代わりに我社も使い始めてる

プアマンズセラロ

>>342
Celaroは買えないね貧乏設計会社では
うちはCelaroPRO最近入れたみたいだけどASIC検証には使わせてもらえない。
欲しいよー
SystemCで我慢汁 Alteraでエミュボード作るより早いか検討中

VStationならsystemCも動くらしい

VStationって誰か使ってるの？

345>>IKOSマンセーが使ってる
めんたと一緒になる前からSystemCのフロー持ってたからね

IKOS懐かしい
みんなどこにいったんだろ

最近のForteってどうよ？ まだ生きてるの？ それと、某大手C社の
Cycle True Synthesis ってどうなったの？ エロイ方、ご教授お願いしまふ。

http://www.opencores.org/projects.cgi/web/sc2v/overview
SystemCからVerilogへのトランスレータだけど使い物になるのか詳細キボン

>>348
Forteの桜井ちゅー奴が粘着連載つづけてるな。
他が言うならまだしも己の飯のために記事書き続けられてもねぇ

DW誌の話ね

>>349
↓ ここにもマッチポンプが ｗ

http://www.edn.com/article/CA503367.html

Respondent Hiroyasu Hasegawa of HD Lab, Inc., gives Forte Design
Systems' Cynthesizer a rave review, saying the tool met his
company's criteria for "support of pipelined design, ease in
defining/creating interfaces to surrounding blocks, processing speed,
and throughput and quality of design."

≪概略≫
HD Labの長谷川氏曰く「Cynthesizerマンセーです」。


確か、この長谷川とその桜井ってHDL普及うんたらで一緒に仕事して
なかったけ？ HDLでの儲けが忘れられず、SystemCに踏み込んじゃったん
だね(嘲笑)。

始めてきました。
アメリカでもSsytemCは普通に使いはじめてるよ
長谷川さんは有名です

>>352
それは、研究所に飛ばされて予算がつかなくなったFの長谷川じゃないの。


＞アメリカでもSsytemCは普通に使いはじめてるよ

だよ。但し、Simulation専用言語としてね。

何故シンセシスに制約の多いSystemCをわざわざ使うわけ？
SystemVerilogなりVHDLでいいでしょ。
SystemCは、Simulation専用言語として使い物になるでしょ。

>>354
SystemCの合成可能なサブセットというのは、SystemVerilogより広い、
これが「合成もSystemCで！」なんていうのを合言葉としたマッチポンプ
が登場してしまう大きな原因。

でも、SystemCの合成可能なサブセット程度の話なら、Cからの合成で
十分だという現実もそこにはある。

で、そのシミュレーション専用言語としてSystemCはベストチョイスなわけ？現状はおいといて、
C++の次世代、より生産性をあげるためのCSのような言語開発の動きはないわけ？
C++でもっと上位のシミュレーションやってるけど、C++がベースっていうのは気持ちが悪いなぁ。
つぎはぎのC++に更に継ぎ足すのかよ・・・っていうね。最近CS使ってみてC++に戻りたくなくなりつつある。
C++いじるときは、ハァ！またクラシックカー運転するのか鬱って感じ。

SystemCが合成できないなら手作業でHDLに翻訳せにゃならんが、
C++から翻訳するよりC的な手順ベース言語の方が作業しやすくないか？
アルゴリズム説明を回路設計屋にC++ベースでするのってどうよ？

>>357
それは趣味の問題。でも、Ｃ＋＋よりはＣを読み書きできる人口は圧倒的に
多いのも事実。まあ、動作切り替えを関数へのポインタをバリバリ使って実現
する位だったら、Ｃ＋＋を素直に使うのもありかと。でも、まあＣで普通は
事足りるよね。

純粋なアルゴリズム開発では、関数型言語を使う方が正当性の証明が楽なの
で良いんだが、そこまでやる必要は普通ないので、Ｉｍｐｅｒａｔｉｖｅな言語（Ｓｃｒｉｐｔ言語含む）
を用いてプロト開発ってのが普通だよね。

でも、Ｃ＃はちょと……。速度が気になるならＪａｖａでＧＣＪ使えばいいじゃん。

多重継承を多用したものを回路屋にぽいっと手渡してそれでHDLに落とせる？Cなら自分でもHDLに落とせるよ。
部分的には自分でもVerilog書くから。
でも、
SystemCは使ったことないけど、Expression Templateなんか使われてた日にゃこれをどうやって手でHDL
に翻訳したらいいのか想像つかんな。

そういや、Handel-Cって何て読んでる？
たまにヘンデルかハンデルか分からなくなる・・・

セロックシカの中の人は”ヘンデルシー”と発音していたよ。

じゃあ、ＨＹ−Ｃは何て読むの？ やっぱ、ハイシーなの。びーめいと を
後ろにくっつけたら薬局で売ってる薬みたいだな。

ハイシーそのものもなかったっけか？（ハイシーエー♪とかも）

ビタミンC入りとかいう、あの丸くて酸っぱいタブレット

シャープさんが、こんなこと発表
http://www.sharp.co.jp/corporate/news/050412-a.html

そんなもん提供されてもな。

>>364
麺多亜に売っぱらったけど、方針があわず細々と開発を続けていたとは聞いて
いたが。これで、学生が使わなかったら諦めるんだろうな。要するに、最後の
賭けね。

つうか、誰も期待してないんだけどなあ。あっ、シャープ社内の開発部隊とか
その近辺からの期待とかそーゆーの除外ね。

っていうか、こんなローカル&マイナーシステムを使って教育された日には学生が迷惑千万
しかもシャープにしてもこのシステムの標準化とかに積極的に取り組んでるわけじゃないんだろ？
つまり賭けなんてことはシャープだてｔこれっぱかりも思ってないだろ。
DW誌についてた旧スパ3のおまけと同じ。
要らなくなったけど、そのまま捨てちゃうよりも無料広報のために提供した。

要するにソフト先行でＣでできたものをそのままＬＳＩに落とし込みたいという用途だろ？
ネチネチと性能を狙うのでもなければ、ＣからVerilog/VHDLに手作業でトランスレートする必要はないわな。

>>368
そう、お遊びにしか使えないシロモノ！（嘲笑

>>368
そのまま一発でコンパイルできたらもうけもん。
文法制限にひっかかるところを直していたら、
一からHDL書いたほうが早かった、とか。

スレ違いかもしれんけど、ImpulseC ってどうなんだろう。
使えるんかな。

>>370
そのあたりはS社社内人柱のKnow-Howが生きるんだろうな。

SpecCで有名なUCIのGajski教授が、DATE05でまた新たな言語RTL++を発表。
　http://www.cecs.uci.edu/~cecs/conference_proceedings/date_2005/zhao_rtlSemantics.PDF

RTL++の特徴は、Wire変数による即時通信とpregister型変数の導入による
Pipeline動作記述のサポート。

……、2003年のDACでは既にYXIのデモブースやらデモスイートやらで発表
されていたHY-Cに物凄く酷似している。

Gajski教授も余程ネタがなかったんだろうなあ。なんだか、哀れだね。

結局さぁ、現実的に見てVerilog/VHDL以外ならC以外に選択肢は無いよな、やっぱし。

おまいら　これ読め
ttp://www.oki.com/jp/Home/JIS/New/OKI-News/2005/04/z05005.html#no2

>>374
また、捏造ですか。そーですか。

既存RTLデータがあるブロックに適用して設計期間が短縮したって言われてもなあ。
BehaviorとRTLの切り分けが、ある程度明らかな状況じゃ、そりゃ動作合成
使って当りつけて設計するのって楽に決まってるじゃん。

そいいや、惨陽と支那腐死巣が1997年当りに

　Behavioral Compilerを用いてデジカメASICを設計、テープアウト

とか捏造発表してたっけ（嘲笑

Ｃ合成でビデオコントローラとブロック崩しが数日で書けて動いた
というあたりからみて、Ｃ的なアプリケーションで使えば便利。

で、>>375には同意。既に先の見えてるものだしな。
でもこの位の会社になると、社内で使うツールの普及やら効率化を
目的とした部署もあるのだろうし、そいつらも成果物をださなくてはならない
のだからこういう大本営発表的やりかたもやむなしとは思うが。

>>374
きちんと使ってる会社もあるんですね

>>377
腐汚流手、乙！（わらわら

ホンマ！アフォルテだよな

　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　

　
　

アフォルテ クン、工作はいかんよ （嘲笑

あれれ？？？
工作を見破られてアフォルテ撃沈か？

合成考えてSystemC使うと、合成結果改善のためにどんどんソースコードを
RTLに書き換えなきゃいけなくて、確かにDSPアルゴリズムとかは決まった
記述の範囲にはまればそれなりなんだけど、でもねって感じ。

つうか、最初からHDLでも良いような。うーん、何か間違ってる。

＞確かにDSPアルゴリズムとかは決まった
＞記述の範囲にはまればそれなりなんだけど、

それでえぇんでないの？で、HDLが便利な領域にはHDLを使えば。
SystemC=>HDL=>論理合成
C=>アセンブラ＝＞オブジェクトコード
みたいなもので。今もCとアセンブラは共存しているのだし。

377ですけど漏れは工作員ではありません。只羨ましがっているエヌ系の検証系の奴隷です
うちは、色々と大変で評価もできないので。。　そんな状況です
展示会で色々と話しを聞くうちにフォルテのファンになりましたが、残念。永久に当社では買わないでしょう。
工作したいっす　出来るなら
完璧を皆さんは期待してるようですが、今よりましな環境であれば万歳です。
知らない人間は吼えないほうがいいですよ。
いい仕事してます。Oエレさんがんがれ
N->O増殖中　俺も誘って

377ですが
なお当社では、XXと比較してフォルテ君を汎用C合成ツールって言ってます
カタパルト君も触ってみたい。
あの、GUIが良いですよ。これは展示会でみただけだけどね　
>>383　は確信ついている。　ワザワザRTLで書けるのはCで書く必要ない。
当社の専用システムでもRTLと協調検証をやってます。
只、MIPSとかのISSが加わるともう駄目ー
RTLとISSは無意味に繋がるだけでサイクル粒度の結果が出るだけ。
命令だから苦労して某M社のEDAに食わせるけどクロックの意味ほとんど無し。
ま、なんていうか。　そういう議論じゃないところでいらいらしてるんだけど。
わからないだろうな　おまいらには
ま、システム検証やってから吼えな
汎用ソフト買えない会社の人間は死にたくなるから

>只、MIPSとかのISSが加わるともう駄目ー
>RTLとISSは無意味に繋がるだけでサイクル粒度の結果が出るだけ。
サイクル粒度が出て、デバドラとの動作がざっくりみれれば良いんでねーか？

> 汎用ソフト買えない会社の人間は死にたくなるから

じゃあ、死ねば？ （アホ

工作するわけないじゃろ
こんなとこで

>工作するわけないじゃろ
と工作員がほざいております

アフォルテには、きっと日本語が理解できる人員がないんだよ （嘲笑

SystemCの解説本が、また出たがどうよ
http://www.picfun.com/picbookB.html

>>392
やはり、Simualtion専用言語としての普及のみが現実的みたいだね。
こういう解説本でSystemCを学ぶと、Simualtion目的のシステム記述
が出来るようになる分、市販合成ツールの制約が受け入れ難くなる
だろうね。

つうか、乖離があり杉！ (まあ、もとも合成の事を後回しで適当に
こさえたような言語というかC++へのTemplate貼り付けだから仕方
ないんだけどね。)

シミュレーション専用言語っていうけど、
そんなもんの存在価値あるか？
最上位の検証にはFORTRAN/C/C++/MATLAB
があるわけでな。この最上位設計のためのプログラム/シミュレーション言語とHDLの間の
中間にもひとつSystemCがあっても意味無いじゃん。作業量増えるだけで。
SystemC->HDLとかSystemC->論理合成が仕事に使えるレベルで自動でやってくれるなら意味あると思うけど。

>>394
だから今度のDACで、MATLABだけで１セッションあるんじゃん。まあIEEEの
標準化番号も下三桁が６６６っていう悪魔の数字なわけだし、そのうち
「あの言語は今」ってなってんだろうね。

つうか、UDLとかって誰も覚えてないっしょ？

>>392
「抽象度低すぎ」と思ったけど、話の流れとしてはしかたない。これだけ書ききったのは偉い。という感じ

さすがの後関哲也も
SystemCをつかったPIC云々
とはできなかったみたいだな。

抽象度がどうこうより、これ論理合成は何を前提にしてる？

論理の話しじゃないいんだけど、、
もっと抽象度上げてね

400ゲッっと
ーーー終了ーーーー

>>400

また、工作ですか、あーそーですか。

アフォルテ、乙！　（嘲笑

リビエラってどうなん？
高速シミュレーションツールてふれこみだけど

本とならすごいね。VHDL,Verilog,SyStemC,M-Matlab全部つきにしかもアサーションすべて対応。
うそくせ

AldecはPolandが本体だけど、米国にもあってなんと場所がNevada州
Las Vegas。ここは、米軍基地が沢山あるところだったりする。

VHDL Simulatorとしては今は業界最速。で、VHDLは米国国防総省が
作成した言語。

軍事ってお金持ちなんだよね、そーいえば。

今年のDACで、Simulatorバトルはどうなる事やら。

支那腐死巣は既に脱落しているから、三社のバトルだね。どっかが隠し玉
とか持ってたりしないのかな？

MATLAB以外はModelsimでも遠の昔から使えてる。
FPGAメーカがタイミングシミュレーション用のライブラリを用意してないようなシミュレータは使う気にならんな。

>>404
DACではチキンスーツが見られるかも　ピンクのバレリーナのカッコも面白そうだけど。
http://www.deepchip.com/items/0441-12.html

>>392
やっぱり動作合成にはいっさい触れてないの?

いや、目次見ると論理合成には触れてるんだが、合成ツールはPrecosion??
PrecisionってSystemCなんかサポートしてるか？

　第７章　論理シミュレータおよび論理合成ツール
　　　７−１　シミュレーションおよび論理合成の手順
　　　７−２　Visual Eliteの使い方
　　　７−３　ISE WebPACKの使い方
　　　７−４　Precision Synthesisによる論理合成

SystemCは、サポートしていません。VHDLとVerilog-HDLだけです。

立ち読みしたら、やはりそう書かれていました。
結局、SystemCでは、論理合成できませんということではないかと？

いよいよやっとEDA最大手がSystemC対応版の合成発表した
DAC向けの発表じゃなさそうだし。流れが変わるな
http://www.mentor.com/products/c-based_design/news/catpultc_productextension.cfm

なんどもなんども
お前ホンマにアホやな

ま　いいじゃないか
>>411
FPGAくせ

>>410
SystemCの合成じゃなくて、単なるSimualtionモデルの生成でしょ。

These extensions enable the Catapult C Synthesis tool to
automatically create SystemC transaction-level models and wrappers

C++って言ってるけど、実際はCにSystemCのデータタイプを継ぎ足した
だけだし。

"The new enhancements to Catapult C promise to automate the
time-consuming process of SystemC model creation. Automatic
SystemC model generation has great potential to accelerate
block- and system-level verification, which would enable
designers to produce better hardware much faster than before."

てコメントだから、SystemCがSimulation専用言語というのは大前提なん
だけど、それでも覚えてられないし、記述するのが面倒だからSystemC
をCから生成してくれると楽だって話しじゃん。

>>413
対応したのは間違いないんだから、いいのでは？
ワザワザ合成をSystemCからやる必要なし。
技術的な事より、誰もそんなこと望んでないということでしょう。
大手のメンタの市場調査力は正しいと仮定するとね。
記事よく読むと、SystemCは高速解析の為にとはっきり言及してます。
と、言うことでDACでは大手のSystemCの合成はなし！

>>414
気になるのが、出力されたSystemCが既存のSystemC記述へ簡単に接続できる
か、という点。ここいらはど〜なんだろうね？

QurtusやISEがSystemCをサポートしないと市民権は得られないんじゃないの？
ASIC起こすにしてもその前にFPGAレベルで試験したものをできるだけ有効利用したいからな。

SynplifyかPrecisionでもいいけどさ。

サムソンの携帯開発あたりはSystemCの技術屋募集してたな。
日本のメーカはみたことない。

OSCIのSimulatorバグってんだけど、やっぱベンダから買わなきゃ駄目？
もしかして、それが狙い？ それじゃ、

　　りふぁれんす ＝ シミュレータの実装が仕様通りかを確認する試金石

じゃねぇーじゃん！

modelsim使え

NC-SCでしょ

ワザワザ合成をSystemCからやる必要なし。

でも、それだと二度手間なんだよな〜
適当に合成させて「できますた。ﾎｲﾎｲ」と言って明るいうちに帰りたい

と思う気持ちはやっぱり残るのであった。

>>422
まあ、仕事がなくなるよりはイイんでない？

SystemCで合成できたからといって仕事はなくならないよ。
多分いろいろ生えてくるって

>>424
合成は諦めな。まあ、SystemCを拡張すれば、何とか使い物になるかも
とは思うけど。それもなあ、って感じだしね。仮にそうしても、Simulation
とSynthesis向けの記述の差異は、チューリング賞受賞者とかその候補でも
埋める事は不可能だよ。

だいたいC++というかOO使って抽象度の高すぎる記述するから問題なんだろ？
もう少し抽象度を低くすれば落としどころあるんとちゃうかな？HDL++っていうかな。うまく合成できるつぼがあるように思うんだが？
何もSystemCでなきゃならない理由は全くない。でも今よりもうちょっと楽したい。

ひとつのレジスタに一alwaysブロックでしか代入できないとか、unknown flipflopエラーがないだけでも随分違うと思うんだけどな。

>>426
そういうのがSystemVeriogなんでは？ あと、Handel-CとかHY-Cとか言うのも
あるよ。>>24 に色んなリンクが貼ってあるので参考にすれば。

>>1
シミュレーション言語SystemCを語る
のスレタイ通りに、シミュレーションを語ってくれるエロイ人まだ？
早く語ってくれ！

合成に期待はシツツ、無理なものは無理なんだから

SystemCrafter（SystemCからXilinxのFPGAへの合成）がどこまで
使えるのか、ちょっと試してみたい希ガス

>>410

後関共著のSystemC本立ち読みしてきた。
合成はおまけのVisual EliteでSystemC->HDL変換するんだと。
おまけのVisual Eliteは期限付きライセンスでつかえるそうな。

>>397、>>430
SystemCでRTL記述につぃて解説されているが、抽象度の高い場合の解説が
ない。残念です

というより"RTLレベルで書かれてる場合はHDLに変換できて云々"って書いてたようにオモタ。
つまり、高抽象度の場合ははなから眼中なしなのでは？

>>428
OSCIのWeb
　　www.systemc.org
でIDゲットして、ディスカッションフォーラムの特に米国版に行けば。
相当コアな話が書かれてるよ。例えば、構造体をポートに用いる方法
とか、バリバリポインタを使った超C++な記述のSystemCへの記述変更
における問題とその対策とか。

ただ、C++とテンプレートが使いこなせるレベルじゃないと、読むの辛い
と思うけどね。まあ、英語は根性で克服してくれ。電子辞書も最近には
出来がいいし。

追記：
ただ、問題なのはOSCIのReference Simulatorはクラスライブラリ貼り付けて
g++でコンパイルしているだけだから、他に隠しThreadとかProcessが居ない
ので割とメチャが効くんだけど、市販SystemC Simulatorとなると隠し君が
見えないところで色々やってくれるようで、ちょっと凝った事するとそういう
のの影響がないようにしないといかん。でも、そうなるとOSCIには相談でけん
し、ベンダにもソース出すのがヤだから自力で解決するしかない。

まあ、お互い頑張ろうや。

>>434
市販SystemC Simulatorの事もう少し詳しく教えろ
どこのがサポートいいのですか
大手ベンダーはみんな出してるけど、本当に使ってるいるのか疑問　
CATSを使ってる部署もあるけど、なんだかナー

> 市販SystemC Simulatorの事もう少し詳しく教えろ

横柄な香具師だなあ。一回死んでから質問しなおせ。なら答えてやる（嘲笑

「少ない人数でも大きな回路を設計できた」，三洋電機がSystemCと動作合成の適用結果を発表
http://techon.nikkeibp.co.jp/article/NEWS/20050516/104703/?ST=edaonline

まあ、当たり前の事が書いてあるね。しかし、動作合成が出力する程度の
μアーキで満足できる会社は羨ましいよ。

＞インタフェース設計の手間は以前と変化していない

これを解決する目的で、SystemVerilog、Bluespec、HY-C、Handle-Cっての
があるんだよな？ SystemCと上手く融合できんもんなんかね。


あと、

＞またモジュール間の同期を「クロックよりも大雑把に定義できる手段」
＞が欲しいとした。

とかほざいてるね。こういうコンカレントシステムの基礎理論を全く知らない
白痴クンの発言って正直凄いなあと。言ってて恥ずかしいとさ感じてないん
だろうな。自分がアホだって解らん程アホってのも困りもんだのう。

>>437
学生が知ったかぶりしているようですが、何のことだか意味不明。
文章読めないのかな？
だれかエロイ人解説しろ
漏れには記事も437の書き込みの意味もわからん
一度死ぬ

>>438
オマイ、レベル低杉。エンジニア辞めてフリータにでもなれ。

既にフリータでRTLのコンサルやってます

間違っていたらすまん。今年大学卒業して４月から某大手の
半導体メーカーにSEとして就くんでは？　もう辞めたの

間違ってます　某大手の系列半導体設計15年です

>>442
チミは、期間工の方が向いてるよ。まあせいぜい精進したまえ（嘲笑

言っていることがバラバラじゃ
　>>440 フリー
　>>442 半導体設計15年

どっちが正しい？

メンドーな奴じゃ
大手（正確には最後は系列）で15年働いてたけどリストラにあって、
コンサルの名刺を持ちあるくプータロじゃ
文句あっか！　いくらでもいるだろそんな奴　

俺もそう。　
今、英会話の勉強しTOEIC 700点目指しております。
EDAのベンダーに再就職狙っている。

>>446
TOEIC 700点も取れんのか？ 帰国子女なら最低900は取るから、そいつら
が競争相手だよ。

まあ、設計経験がどれ位あるのか、って部分で自分を売り込むしかない
かもね。でも、700とれないのはマズイよ。

頑張れ、リストラされた元リーマン達！ 応援してるぜぃ！！

ちょっと待て。EDAベンダに就職って日本でEDA開発やってるようなとこあるか？
まさか、外資の日本法人への就職か？そんなのほとんど営業だ。米本社と日本ユーザとのつなぎ。
そんなので満足なのか？別にEDAには限らんが。

大学受験時、試験に出る英単語は嫌々全部覚えた。共通一次は150点で5教科の中で最低だった。
仕事でスペック、論文も特許も英語で読むことは問題ないんだが、会話はからっきし駄目。日常会話がまったくできん。
特に米語が聞き取れない。sharpとshopが聞き取れなかった。英語らしい表現を知らない。あまりにひどいんで
NHKの英会話入門と、中級、レッツスピークでお勉強中なんだが700点目指す君。
上達のツボを是非アドバイスして。

板違いではないの。　ここで議論中
http://academy3.2ch.net/test/read.cgi/english/1112626224/l50

板違いじゃないだろ。類似の職業の中で必要な英語能力の話がなんで板違いなんだ。

ここの住人はSystemCを勉強しようとして、英語の壁にぶち当たった？
Verilogにしておけば
SystemCは使える日本語の資料がほとんどないから、
情報はすべて海外から入手しないといけない。
最先端の仕事はどんなものでも、英語使わないと前に進まないから、
英語読み書き会話出来ないと大変だよ。
700点は最低レベルでしょ。少なくても半導体関連の仕事をするにはね
と、無理やり関連付け

何なんだここの板

>>437
言語云々ではなくて、人手でラッパーとドライバ書いてたら手間は変わんないざまス
＞クロックよりも大雑把に定義できる手段
開始と終了信号で良いんでね

>>454
> 人手でラッパーとドライバ書いてたら手間は変わんないざまス

I/FはRTL設計ってのが前提って事？


> 開始と終了信号で良いんでね

そんなんでいいのか？ えらく程度の低いアーキなんだなあ。

ハード設計しているのでなく、機能設計しているんだろ。

ハード設計なら手間が多過ぎてやってられない。

エンジニア未満外資系営業マンの寝言でした〜

>>452
最先端技術に対応できる人間がいなくていちいち米本社のエンジニアに問い合わせなきゃいけないから
TOEICも700点ぐらいないと意思疎通に支障来たすよなぁ。くっだらん仕事しかない会社だ。

>>458
たった700点で意思疎通できるのか？ 例えばESL nowとかから来るメール、
700程度じゃ辞書なしで読めないんじゃないの？ 米国人でも高校中退レベル
じゃ読めないと思うんだが。つうか、普通にEE Timesとか読めなくて大丈夫
なんかいね。EDA使ってて、結局本社の知り合いにメールしちゃうから、
日本の代理店要らないって最近物凄く思う。

つか、そもそも質問なんてほとんど無いし。

技術論文は読んで正確に把握するのは日本語であってもそれなりに時間がかかるよな普通。
言葉だけじゃ正確に説明できないから数式を併記して説明するわけだし。そういう流し見程度で仕事になるような楽な仕事したいな。
高校中退レベルで読めないというのは英語そのものじゃなくて内容がわかってないからだ。高校中退の奴に量子力学の本読ませてみ。絶対に読めんから。
日本の受験英語をやってきた奴なら技術英語ごときが読めないことはありえない。ただし、日常会話には支障があると思うけどな。

あと、辞書使うのは別になーんも問題ないだろ。英語屋じゃないんだからな。

>>461
＞高校中退レベルで読めないというのは

語彙レベルと言う意味だよ。


＞技術論文は読んで正確に把握するのは日本語であってもそれなりに時間がかかるよな普通。

こんなの当たり前。つうか、専門知識なしでどうする？ 言語障壁にやられて
理解が遅れるようじゃ話にならんと言いたんだが。EE Timesの解説記事とかは
程度はしれているがそれでもある程度の専門知識は必要。だけど、所詮は記事。
なので、そんなのに時間かけてたら話しにならんと言いたいだけ。


＞辞書使うのは別になーんも問題ないだろ。

日本のみで頑張るならそれでも良いが、海外との共同開発などをするなら
やはり語学力が高い方がよい。


スイス人は４ヶ国語使いこなせるのにね。情けないな、日本人。

>>456
m9(ﾟДﾟ)ﾌﾟｷﾞｬｰ

>>463
スイス土着で、4ヶ国の中に日本語、もっと範囲を広げてウラル-アルタイ語が含まれてたら尊敬してやるよ。

>>465
哀れだよ、高卒君　ｗ

おまえ高卒に負けている学卒だな？　俺。学卒だけど

高卒のいいのは、難しいことを知らないで作り上げてしまうこと。
なぜか理由が分からないが、こうしたら出来ちゃったと言う。

学卒が延々と考えても出来ないことを簡単に高卒がやってしまのを
見ると、あっらこんな簡単な方法でやってやがる悔しいだけ。

学卒は頭が硬いので、こんな術思いつかなかったという事なのかな。
学卒には、理論馬鹿が多いということでしょう。論理設計に量子力学
いらないもんね。　理論やりたければ研究所で働けばどうよ。

自己紹介おつかれ。カスの学士さん。
>学卒には、理論馬鹿が多いということでしょう。
学卒で理論？アホが！最低マスタぐらい修了してから言え。現実見てみい。スペック策定やってるのは博士、修士だ。
学卒程度がそのスペックに合わせる製品をしこしここさえるんだ。高卒云々と区別してるのは悲しいかな学卒のオツムの中だけ。
お前らはニアリーイコール高卒だ。

>>467
哀れだよ、学卒君　ｗ

>理論やりたければ研究所で働けばどうよ。

この回答まだだけど、キボンヌ

>>468
お前　中卒並みに権威に弱いんだな　かわいそ

院時代、研究室で教授から権威だけ教わったんじゃないのかな？

まともな研究してないよ。

>哀れだよ、高卒君　ｗ
>哀れだよ、学卒君　ｗ

　このような言動をして高卒、学卒から真新しい技術を聞き出そうと
している釣師で自分の研究ネタを探している香具師です。
この方、この筋では、２ちゃんねるで有名人になってます。

肝心のSystemCネタがもう尽きたって事？ まあ、一過性のブームだったと


＝＝＝＝＝＝＝＝＝＝　終了　＝＝＝＝＝＝＝＝＝＝

>>474
話題尽きるわけない。
みな、中卒の権威主義は別にして言わないだけで釣ってるの、わかんないかな。
権威と戦えるのは、SystemCとか学者があまりいない所だってのは知ってるかな？
ものを作るのが大事という人たちはSystemCでSpecCとかGAとかやってる人は権威側にいるね。
そろそろ、ネタでも振ろうかな

>>475
でも、SystemCのEuropa Communityでは、Rosenstiel教授(だっけ？)なんて
いう権威もいるし、U.C.BerkeleyでもSan Giovanni教授(だっけ？)のところの
学生がProcessor ModelingとかをGSRCの研究テーマとしてやってなかったっけ？

こう考えると、SystemCもバリバリ権威側なんですけど。

でも、合成の実用化はAlgorithm Synthesisより前へは全然進めそうにないね。
MITのArivind教授(だっけ？)に「無理っすよ」と結構強くICCADやDACの発表
で否定されまくりだったよね。まあ、彼はBluespecの生みの親だけどね。

SpecCはGajski教授(だっけ？)が事実上の敗北宣言してなかったっけ？

>>476
基本的にSystemCはOSCIや学会は離れてビジネスでやっていくことになる。
IEEEに載せたのも、（ビジネス）の標準化の為。
そりゃ、色々学者様は意見があるだろうが標準に向けて進まないと誰も利益を得ること出来なくなるからね。
今は、大学より企業にその標準化の為の意見が通りやすくなってる、企業の次がEDA企業。
実は日本の会社が頑張ってるのはみな知らないだろうけど、ここで日本にとって一番都合がいいのはどんな言語だと、
NのKさんが盛んに啓蒙してる。
Vote権は学者じゃなくみんなだから、ここで頑張らないといけないね。
マジ釣り！！　
厨房　日本のために俺は働いてる。お前も引きこもらないで前に出て来い。

Gajskiは寝返ったのは有名だよ。

ここにEDAの人はいないのですか？

>>477
Scenic(SystemCの元祖) ＝ (Esterel - Instantaneous Communication) in C++
SystemC1.0 ＝ Verilog-HDL in C++
SystemC2.0 ＝ SpecC in C++

こんな感じではないかと。2.0でSpecCを産業界が無理矢理取り込んで、
言語が破綻したので、Gupta教授とSynopsysのATGが逃亡したんだよね。

学術的には既に破綻した言語です。でも、産業としてはSimualtion専用
言語としてそれなりに成功しています。

但し、Simulation用記述とSynthesis用記述は未来永劫融合される事なく
溝が大きく開いたままだという事も事実として受け止めようね。

Robin Milnerを超える天才が現れれば、進展があるかも知れないけれど。

NのKは、ただのその辺にいるオヤジが勘違いして頑張ってるようで見ていて
痛いんだが。それは、FのHも同じだよね。まあ、頑張る分にはいいんだが、
業界への悪影響の方が大きいのではないかという気がしてならない。

　　SystemC　＝　Simulation専用言語

と彼らが割り切って今後活動してくれる事を切に願う。

>>478
Gajski教授といえば、>>372 に何かかかれているが、これって本当なの？

>>481
ガセではないと思うけど、表現が悪いねこの人
先生は、寝返ったわけではなく初めからSpecC派などというものはなかったんだ。
contributeした先がSpecCでSystemCでも何でもいいわけで、
研究続けるには色々アメリカでもあるからね。
特別行政法人として守られている日本の国立大学と違いビジネスに直結しないとだめな国だから。
厳しいね

>>482
> 初めからSpecC派などというものはなかったんだ。

うんなわけない。一時期は、「SystemCは死んだ！」と豪語していたぞ、
Gajski教授。この人は、恐らく人格に問題があるんでないの？ かなり
多方面から嫌われてるみたいだし。

（・ω・）ﾉｼﾛ

ﾉｼﾛ語(２１世紀の人口国際言語)
http://academy3.2ch.net/test/read.cgi/gogaku/1109756541/l50

SystemC（Simulation専用言語）のネタはやはり尽きたようですな。
一過性のブームとはそのようなものです。という事で、

＝＝＝＝＝＝＝＝＝＝＝＝＝＝　終了　＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

終了というなら、削除依頼でもするか？

↓ これって何？

Cycle-True Synthesis
http://www.cadence.com/company/cadence_labs/systems.aspx

ワクワク、かなあ？

下げ進行で、放置でいいんでない？

やっぱSystemCはシミュレーション言語ってことか。
３年前くらいにちょっとだけSpecCやったけど
いつの間にかあぼーんしたらしいな。
で、そのあいだ１０年前の非同期回路がこんがらがってる
寄せ集めの他人の作ったDQN回路ばっかやってる。今回は強引になんとか
なったのかもしれん。
が、今後DQN回路をＣベースの回路と組み合わせるには
どうしたらいんだ？フォルテだかなんだかしらんが
変な高位合成ツールがが吐き出した回路(RTL)もDQNなんだが。
どっちの回路もよーわからん。

> 今後DQN回路をＣベースの回路と組み合わせるにはどうしたらいんだ？

それ、誰も分からないの事ネ。抗日運動でもして気を晴らすしかないアルよ。

もういちど日中戦争だ。おまえらジェノサイド覚悟しておけ。
首洗って待ってろ。チンコロ

>>491
日本人はその民族性から言ってジェノサイドなんて無理。日本人の品位を
落とすような工作書き込み、乙！ ＞ ﾁｮｳｾﾝﾋﾄﾓﾄﾞｷ

the 4th annual ESL Technical Symposium and North American SystemC Users Group Meeting (NASCUG) at DAC:

ISNT IT TIME YOU MOVED UP TO SYSTEMC?

TECHNOLOGY SYMPOSIUM
Monday, June 13, 2005
12:00 - 2:00pm (complimentary lunch provided)
Room 304 A-B. Anaheim Convention Center

Registration and Information:
http://www.thinkbold.com/events/dac05/osci/

--------------------------------------------
NORTH AMERICAN SYSTEMC USERS GROUP MEETING

Monday, June 13,
2005 3:00 - 5:45 pm
(beer reception starts at 5:15 pm)
Room 304 A-B, Anaheim Convention Center

Registration and Information:
http://www.thinkbold.com/events/dac05/osci/

↑ これに出るエロイ方、報告よろ、です！

はーい

>>492
んなこといってるから、シナ人ごときになめられるんだよ。
在日の糞シナ野郎に仕事なんかさせるな。罪チョンといっしょにたたき出せ。

>>496
じゃあ、自衛隊の幹部にでもなってクーデター起こして時限軍事政権を樹立後
それを実行してくれ。それが可能なら、おまいを物凄く支持するぞ。

つうか、先ずはチミの周囲の人間に、現在我が国が半島及び支那と交戦状態
にあるという事実を知らしめる事と、先の大戦がある意味においては聖戦で
あり日本なかりせば世界は多くの貧困層と極限られた一部の裕福層からなって
おり文明の発展もそれほど望めなかったという事実を知らしめるという啓蒙
活動を地道に行いなさい。

なんで荒れるんだ？orz
逝ってきます。

>>497
>自衛隊の幹部にでもなって
今日、空自に入隊手続き済ましてきた。見とけよシナ人。空撃で北京、上海皆殺しだ。
と思ったら爆撃機なかったか？

>>499
下っ端ではなあ。何故、防衛大学に入学しない？ もう歳か？

>500
ああ、もう歳だしな。
今更防衛大に逝ってもな。
もう民間の変な電気回路もｲﾔﾎﾟだしな。
ひと華咲かせて靖国で待ってるよ。

>>501
偽者引っ込め！

>>500
俺は18だ。
頭悪いんで防大なんか受かるはずないだろ？考えてみろ。
下っ端からやってたたき上げて、自信ができたら仏語勉強してフランスの外人部隊に入隊するんだ。
そこでできるだけ長く働いて、そのあとハートセキュリティー社に入社するんだ。
ちゃんと人生設計もできてる。もちろん日シナ or 日チョン有事の際には
己が殺されること覚悟の上で、体張ってシナ、チョン公を皆殺しにするするまで戦い抜く覚悟はできてる。
死んだら靖国に祭ってくれ。

えーっと、SystemCで第三次世界大戦Simulatorでもモデル化するの？

三洋電機，Mentorの動作合成ツール「Catapult C Synthesis」を導入
http://techon.nikkeibp.co.jp/article/NEWS/20050526/105097/?ST=edaonline

あれ？ Cynthesizer じゃなかったの？ 両方とも大本営発表でつか？ （わら

傾いた会社がどんな設計ツールを導入しようが知ったこっちゃないわけだが

>502
藻前こそ引っ込め。
このスレの住人は防大受かる以上のレベルの人しかいませんがなにか？

ていうかシミュ版だと勘違いして変なの沸いてくるから
現段階では合成が難しいとしても
この話題は電気・電子板のほうがいんじゃないか？

>>482
そーゆーのを『老害』というのでは？ しかし >>372 が盗作を意味するなら
権威を傘に着た横暴だね。まあ、SpecC自体もGajskiではなく、Toronto大の
Zhuのアイデアだという事はその筋では有名な事実だしね。「老兵は去る
のみ！」 って事でFA？

そういう俺は防大どころか工業高校にも落ちてニートでつ。

>>506
お前は電電板行け。
ここには二度と立ち入るな。
合成できないSystemCはシム板でやるんだよ。

まあ、Forteだ、Mentorだ、と騒いでCベース設計頑張ってますって大本営
発表やってる会社ってのは、プロのRTL設計者がいないって事だろ。RTL
設計者のレベルが低いから、ツールに求める性能のレベルも低いって事だ
ろ。

>509
わーい
偽者がいぱーい

まあ、Ｃベース言語もこの程度ってことで


(・ー・)ｵﾜｯﾀﾅ･･･

>>511
まだ市場にそれ程出回ってないダークホースがありそうな雰囲気。
ダークホースは、NEC/Cyber(市販まだ)、Cadence/Cycle True Synthesis
(Berkeley Labで研究中)、YXI/eXCite eXpert(市販まだ)、Bluespec/
Bluespec Compiler(日本代理店がない)。

ただ恐らく、Cadence以外はSystemCではないと予想される。

↓ これ出るエロイ方も、報告よろ！

ESL DELIVERS: LESS RISK, GREATER PRODUCTIVITY AND OPTIMIZED DESIGN

Tuesday, June 14, 2005
12:00 - 2:00pm
Room #304 AB, Anaheim Convention Center

To register now:
http://www.thinkbold.com/events/dac05/summit/registration.php

For further details:
http://thinkaway.com/sd/esldelivers.htm

Calypto Design Systems
www.calypto.com

ChipVision Design Systems
www.chipvision.com

CriticalBlue
www.criticalblue.com

Forte Design Systems
www.fortedesignsystems.com

Summit Design
www.summit-design.com

教えてやろうと思ったが
俺は偉いがエロくないのでやめとく

>>514
じゃあ、「俺は偉い」というのは脳内妄想だという事で。（嘲笑

> NのKは、ただのその辺にいるオヤジが勘違いして頑張ってるようで見ていて
> 痛いんだが。それは、FのHも同じだよね。まあ、頑張る分にはいいんだが、
> 業界への悪影響の方が大きいのではないかという気がしてならない。

ﾜﾛﾀ w

>>516
分かるように説明せい！

Kのｋはうざい

>512
>YXI/eXCite eXpert(市販まだ)
まだじゃなくて、とっくにアボーンしてないのか？
日立で一応使ってたらしいけど。
代理店ではバグ取り先を探してるから
喜んで貸してくれると思われ。

>>517
最初から合成を無視してSystemCを2.0に拡張しておいたくせに、今更合成
サブセットがどうたらこうたらと活動してるから滑稽、というだけでないの？
HDLの黎明期ならそれも許されたけど、同じ事の繰り返しでは意味ないっしょ。

>>519
へー、そうなんだあ。今年のDACにも出展するらしいから、どなたか報告よろ
しく。

しってるけど
　お　前　の　態　度　が　気　に　入　ら　な　い
から教えない

>>521
「しったか」って超ダサだよね （嘲笑

>>519
日立でなく、三菱じゃなかたっけ？

>>523
三菱はeXCite Proじゃないの？ つうか、eXCite eXpertって何？

http://www.excite.co.jp
がどうしたって？

>524
これだろ
ttp://lsi.soliton.co.jp/products/yxi/excite/excite.html

>523
日立のストレージ関係でつかったらしい。
三菱は初耳だ。

>>527
↓ これが三菱なんでねーの？

ANSI C言語入力動作合成の「eXCite」, テストベンチや制約条件の自動生成が可能
http://techon.nikkeibp.co.jp/members/NMDNEWS/20041006/105757/

ニュース・リリースには三菱電機の△〇×□氏（△〇×□研究所 主席研究員）
がコメントを寄せている。


でもって、↓ これが日立のストレージ関係でね？

日立，RAIDシステム用LSIの開発に向け，シーケンス図入力のEDA環境を構築中
http://techon.nikkeibp.co.jp/members/01db/200301/1010491/


ついでに、↓ これがルネサスって事だよね。

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


つうか、日立と三菱って中良いんだね。

NECのC言語入力の動作合成，世界進出を図る
http://techon.nikkeibp.co.jp/article/NEWS/20050605/105459/

ある意味、無敵？

なんで？　すごいのこれ

Behavioral Synthesis、Co-simulator、Equivalence Checking、
Model Checking、FPGA Emulator、Dynamic Reconfigurable Processor
向けCompiler、と全部揃ってるって事が凄いって事なんじゃん？

ここまで揃えたのって、これ以外にないのは事実だよね。

なるほど。　そりゃすごそうだ
だけど、だれが使えるの？

NECのASICを設計する部門とその関連会社、及びNECELのASIC顧客のみ、
ではないかと。

うーん、外販してもバグ発生時の対応が困難だ罠。競合にデータ出すわけ
にいかん罠。

使いたい人はＡＳＩＣはＮＥＣに決めなければいけないんだ。
なるほど。新しいビジネスモデルだ。
汎用ＥＤＡの展示会ＤＡＣでぼこぼこにされないかな？

これでASICの設計そのものがコケタラ大変だから、そこそこの自信作ではありますね。
お客さんもツールを提供してくれて、それで責任も半導体メーカとして取るのであれば、
すごいことかもしれない。
一蓮托生でNECELに技術者生命かけようか。
他のASICベンダ（L露地やEPやＦ）はどうするのだろ？
まだ汎用EDAで設計続けるわけに行かないね。CもMもSもこれまでか。

ついにPPCもSystemC対応だ。
プロセッサのモデルもSystemCモデル対応になった。
PowerPCは結構ハイエンドで使われるから、この発表はすごいと思う。
シミュレーション専用ですが
ttp://synopsys.com/news/announce/press2005/ibm_powerpc_pr.html

DAC会場からテスト

ちぇっ　ESL Tシャツ貰えんかった
初日終了

ウェプソン
ttp://www.forteds.com/news/pr061305.asp
いつのまにか、、、、、、
大丈夫？

みなさん、ご協力お願いいたします。
http://bbs.enjoykorea.naver.co.jp/jaction/read.php?id=enjoyjapan_16&nid=1440591&work=list&st=&sw=&cp=1

>>536
　PPCはゲーム機専用になりつつある。

DAC W林さん頑張ってたな
ESLシャツでかくて着れない

佐倉広夢　広夢くん　広夢君　広夢たん　広夢きゅん　広夢ちゃん
綿貫琉宇　琉宇くん　琉宇君　琉宇たん　琉宇きゅん　琉宇ちゃん
イカル　イカルくん　イカル君　イカルたん　イカルきゅん　イカルちゃん
藤守直　直くん　直君　直たん　直きゅん　直ちゃん
市川学　学くん　学君　学たん　学きゅん　学ちゃん
クリス　クリスくん　クリス君　クリスたん　クリスきゅん　クリスちゃん
マオ　マオくん　マオ君　マオたん　マオきゅん　マオちゃん
七海かい　七海くん　七海君　七海たん　七海きゅん　七海ちゃん
柊真央　真央くん　真央君　真央たん　真央きゅん　真央ちゃん
東衣緒　衣緒くん　衣緒君　衣緒たん　衣緒きゅん　衣緒ちゃん
緋雨閑丸　閑丸くん　閑丸君　閑丸たん　閑丸きゅん　閑丸ちゃん

Synforaすげーや。でも、Bluespecは意味不明。

何のこと？
過疎だね、ここ。ひさしぶり見たけど、やはりＳｙｓｔｅｍＣは終わったの？
一応Age

終わったんじゃん。DACでもSystemCとかに対する同じような要求を何度も
耳にしたけど、実現性０だと皆わかっるみたいで、ひいてた感じだったし。

終わってたまるかよ。
ﾊﾞｶｼﾞｬﾈｰﾉ？

ｷﾀ━━━(゜∀゜)━━━ !!!!!

あらゆるところで、SystemC狩りが始まったぁ〜！

最近の日本CoWareってどんな感じ？ SystemC普及のバロメータ的存在なん
だし、元気なんかいね？

>>549
確か、氏にかけ寸前のような……。あーあ。

ケイデンスにSystemCのカーネル売却してかろうじて生きてるみたいだけど、
ttp://www.testbuilder-jp.com/inno/tu/sysc/udhistory.html
これを見る限り去年の9月にはお亡くなりになったような（嘲笑

>>550
SystemC以外の分野で頑張っているような気がします。
Lisa言語に注目

>>549
日本CoWareは探してもない。
正しくは、コーウエア株式会社　全部大文字
SPWだよ。この会社の主力商品は。
もうSystemCはやってないよー

CoWareってDACでForteとのつなぎを披露して、SystemCはSimulation専用言語
でしかないのに無理矢理「合成可能！」って言ってたような。でも、SystemC
とかCベース設計の市場って一番大きいのが日本で、日本支社がもうSystemC
やってないって事だから、言わずもがな、って事だね。

つまり、SがCoWare(SystemC)を見放したって事になりそうなんだけど、そう
いう理解で良い？ ＞ エロイ方

>>553
http://www.coware.co.jp/company/employment.html
600点で入れる

TOEICのスコア550点以上あれば尚可　← これじゃ話せないって（嘲笑

「SystemCからの動作合成を追悼する飲み会」を企画したら来たい人います？
とりあえず、来月の頭の土日に山手線近辺の飲み屋を考えています。

「TOEICスコア800点以上の飲み会」を企画したら来たい人います？
とりあえず、来月の頭の土日に山手線近辺の飲み屋を考えています。

「腐汚流手に騙されて人生棒に振った人のソープはしご会」を企画したら来たい人います？
とりあえず、来月の頭の土日に吉原近辺のソープを考えています。

＞腐汚流手に騙されて人生棒に振った人

これ一杯いそうだなあ （わら
しかも、これからも増えそうな感じ （わらわら

吉原は飽きたんで金津園でお願いしまつ mOm

もう話題尽きた？

新幹線で金津円行ってきた。
話題より
金とスペルマが尽きた。
最後に赤い玉が出た。
もう打ち止め。

汚須奇異
インテル入ってる

腐汚流手にだまされたDA部門よりも、それで設計する事を余儀なくされた設計者
の方が可愛そうだね。

ここ最近Celoxica関連のニュースがTechONで見かけるけど、これって線香花火
の最後の輝きってやつ？

>>566

ちがう。
分からないかな？　君たちが遅れているという事
意味が分からないやつは、引退しな！

>>567

ちがう。
分からないかな？　おまえがアホだという事
意味が分からないなら、

　　死　　ね　！

>>568
PICでもいじってろ
Ｆ　Ｐ　Ｇ　Ａ　は　ま　だ　お　ま　い　に　は　１００ねんはやい
Ｃ言語はもっとはやい。　大人になってからにしろ

>>569
センズリでもこいてろ
女　と　つ　き　あ　う　の　は　ま　だ　真　性　包　茎　糞　ガ　キ　の　テ　メ　エ　に　は　１０００ねんはやい
オメコはもっとはやい。　チンポの皮がむけてからにしろ

なんでも慣れの問題だから、Handel-Cでも我慢できるって奇特な設計者が
たまたま居たって事でしょ。まあ、性能をカリカリにチューニングするよう
な設計でもなさそうだしね。

まあ、ニッチで頑張ってるって事でしょ。メジャーになるのは無理でしょ。

腐汚流手のC++合成よさげ？

ここか見苦しいネガティブキャンペーンやってるの
無理だよ。　
使い始めているエンジニアは、もう戻れない。
ニッチにしたい？　無理だね　ここまで来たら。
　自分だけいい思いしようったって。。　見え透いてる
そういうのやめようよ　
知らない人間は、これ読まないしね。
追い詰められたらSystemCしかないって漏れは宣言する。
無理だよもう。ここまで来たら

腐汚流手社員宣伝乙
残念だったな。もう誰も騙されない。

最近の腐汚流手ってどうなの？ まだトップセールスで騙眩かそうとしてるの？
それとも実力勝負が出来るようになって来たの？ 設計が本当に楽になるなら
もう何でもいいよ。

それとHY-Cとか騒いでいたの厨っぽいのが居たけど、最近影も形もないね。
完璧に死滅したの？

電車に飛び込まれて死んだらしい。
某社のすぐ近くだったしな。

>>574
HY-Cでっか？
あのね　だめ　来月は驚くよ

あげるな！！！！

>>571
こら餓鬼！　ニッチの意味知ってるのか？　Verilogもニッチか？

Handel-CとかHY-Cってニッチ以外の何者でもないでしょ。でも、SystemCもなあ……。
俺もう、Verilog-2001で満足する事にしました。もう騙されるのヤです。

最近のHDL Simulatorって早いよね。しかもVerilog-2001とかだと結構抽象度
高いとこで記述できちゃったりするからね。下手なSystemC記述を作っちゃう
とOSCIのSimulatorだと、HDL Simulatorにボロ負けすんだよね。SystemCって
SimulatorがFreeってのが売りの部分ってあったのに、これじゃ意味ないよね。

つう事で、System Simulation込みで設計言語はVerilog-2001でFA？

DW誌は今月号でSystemC連載終了
代わってSystemVerilog特集

みんな、中核派（革命的共産主義者同盟全国委員会）のサイトみた？
あそこが今力入れてやってるのは、

中国の反日デモ応援
新しい教科書採択妨害
郵政民営化反対　　　←←←注目

ttp://www.zenshin.org/

>>583
腐汚流手 ｶﾜｲｿｽ ｗｗｗｗｗ

RTLをSystemCにするいい方法知ってたら教えてください。
無理矢理ARM720をSystemCの中で使わないといけなくなって、勉強中です。

CosimはC社のNCで試したけど遅くてだめです。

RTLはVHDLです。
よろしくお願いします。　こまってます

そんなことよりケツの穴にフリスク！！！１

なんか気分爽快したいんだけど、オススメある？

とりあえずシステムCを語るにはフリスクが欠かせないな

ﾌﾘｽｸ買ってきたｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ﾌﾘｽｸ

ペヤング板からきますた

＞587
そんなことより、肛門にﾌﾘｽｸ入れてみろｗｗｗｗｗｗｗｗ
ｷﾀｺﾚ!!

フリスクCを語ろうぜｗｗｗｗｗｗｗ

フリスクを尻に入れた場合の快感のシミュレーション

ﾌﾘｽｸ入れるシミュレーションからしてみた

なんだよまたラウンコのカスどもの仕業かよ
VIPの仕業に見せかけてるんだろうけど、俺の目はごまかせないぞ


ラウンコはカエレ！！！！！

フリスク民営化

フリスク擁護法案

やべｗｗフリスクC使ったら最強のプログラム出来たｗｗｗｗｗ

アメリカ国防総省に殺ｗｗｗｗｗさｗｗｗｗれｗｗｗｗｗｗｗるｗｗｗｗｗｗｗｗｗｗｗｗ

住人ｲﾅｻｽｗｗｗｗｗｗｗｗｗｗ

ラウンジにも来てね
　　 　　　　　　　　　　　　　　　　　∧　 ∧
　　　　　　　人 　　　　　　　　　　（　￣ 　）：;　←VIPPER
.　　　　 　 （＿_） 　　　　　　 　 ／〉　　　 つ；
.　　　　 　（＿＿）　　　 　 　 ／ ⊂　　　ﾉ
　　　　　 （,（●））　　　 　 ／／　　てし'
.　 　 　 /⌒　　 ｀ヽ 　　／／
　　　　/　/　　　 ﾉ 　／／
　　　 (　/ヽ　　　| ／／
　　　　＼ /　　 ／／
　　　 　 （　　 ( 人）
　　　　　 | 　 /　/
　　　 　　|　 /　/
　　　　 　(　 )　) 　　　　　　　　　　それがラウンコクオリティ
　　　　　 |　|　/ 　　　　　　　　　　 http://etc3.2ch.net/entrance/
　　　　　 |　|　|
　　　　　/　|＼ ＼
　　 　 ∠／　　￣

　ラウンジ新イメージキャラクター
　　　　　　ラウンコス

フリスク買ってきた
今ケツにINしてみた

フォーーーーーーーーーーーーーー

フリスク

1時までに1000いったらフリスクうｐしちゃおうかな(*＾o＾*)

ラウンコ市ねよ

>>606
kwsk

>>586
なにげにスルーされてるけど、すげえ高度な釣りですね

>>586
VTOCとか市販ツールじゃ駄目なの？

ランタイムライセンスで年間１００万位か。

つうか、前スレみたいな盛り上がりがないね。

女の子にかなりモテたし、今でもそれなりにモテている。

ちなみに、俺は、大学時代は体育会系のクラブに入ってて、そこで知り合った他校の女の子６人と付き合ったよ。
もちろん、ヤったよ。
それ以外にも、複数の女と付き合い、ヤったよ。
大学時代は、部活、アルバイト、ゼミ、恋愛、遊びといろいろと楽しかったよ。
当時は、インターネットや携帯電話なんか無かったし、茶髪、眉剃りのケバイ女も殆どいなかったし、すごく良かったよ。
インターネットや携帯電話なんて、無い方がいい、そう思ってる。
あーーーーー！！ 生れるのが君達より早くて、本当に良かった！！！

あと、大学時代に、普通自動車免許取った後、自動二輪の免許とって、バイク（ＮＳＲ２５０Ｒ）で峠攻めてた。
で、卒業旅行は、アメリカへ行きました。
楽しい大学時代でした。

今は、無借金経営の中小企業の社長です。

hoshu

ttp://www.electronicsweekly.com/Articles/2005/09/19/36345/CeloxicatofloatonLondon'sAIM.htm ???

ce

ttp://www.forteds.com/japan/pdf/program.pdf　誰が聞きに行くの？

2.1のベータが消え、v1になっている。

SystemCで電波に関する研究がしたいんですがテーマがよく見つかりません。なんかいいテーマはありませんか？

ちなみに現在大学生です

>>619
それって教授の指示なのか？ だったら院受験でロンダすることを強く
勧めるよ。

x86をSystemCを使って制御しろっていわれたんですけどどうやってできるのかが
分からないんですが誰かわかる人いますか？

シミュレータの上で制御することはできるだろうね。
x86もSystemCで作って。

SystemCはまだ始めたばかりなのであまりわかりませんが
x86をSystemCで作るのは難しいんですか？

ちなみにさきほどの>622のものです

簡単だよ。すぐできる。
作ったものはワンタッチで論理合成できて実体が出来上がるんだからいい時代になったもんだ

ありがとうございます。がんばってみます。

>>626
コレコレ！

研究で、教授に通常はソースはHDL変換になるがこのソースをCに変換するようにして
x86を作ってくれと言われたんですが
そんなことはできるんでしょうか？

簡単にできる

C++ど素人なら
ストラウストラップのプログラミング言語C++、1000ページ読んで、
べからず集のEffectiveあたりも読んで、
そこからSystemCに突入して、
x86の命令セットぜーんぶ調べて、ステートマシン組んで・・・
仕事なら、その前にx86のSystemCかRTLがネットに転がってないか調べるが、
それで卒論書くのは詐欺だな。俺なら単位出さないか。
つーか、x86をSsytemCで組んでいったいどんな卒論書くんだろ？
事情をまったくわかってないアホ指導教官でないことを祈るばかりだな。

まぁ、先は長いが頑張れや。

>>631
SystemC書くのにEffectiveが役に立つとは思えないクマー

そんなことはない。EffectiveはC++でやっちゃいけないことのべからず集だ。C++の問題点はやっちゃいけない書き方ができてしまうこと。
プログラミング言語はやっちゃいけないことを予め想定して、文法に沿った記述をしてれば、それを自然と排除する方向でコーディングできなきゃいけないのに、
高級アセンブラとしてのCの名残を残したままいろいろ機能を詰め込んだC++は文法的に問題なくても、思いもよらない落とし穴に入り込む可能性がある。
処理系がC++であるかぎり、Effectiveに目を通すのは当然だろ。

SystemCを理解するのにいいホームページとかありませんか？

http://www.systemc.org

http://www.eda-express.com/systemc/bbs.cgi

https://it.cqpub.co.jp/tse/DW200511/

赤西仁と亀井絵里のＳＥＸ動画→bbs.04/gio　

３ヵ所に貼ってから↑のアドが見れます

rtrtr

で、２年前にSpecCを見限った俺って勝ち組？

一人でできる仕事あるよ
http://blog.livedoor.jp/hide5972/archives/cat_50022506.html

>>640
出始めに見限らなきゃ駄目！ つうか、２年前までやってたの？ 余程
暇だったのね。

>>642
SystemCを
今から始めた人は？

>>643
ガンガレ！ きっとSystemVerilogの方が習得が楽で、Simulationも
普通にRTL設計者の発想で記述すると格段に早いと思うけど。
デバッグで気が狂いそうになるとも思うけど。sc_channelとか
使ってTransaction Leveにレベルを上げてSpeedでなくて苦しむと
思うけど。

ガンガレ！！

つうか、SystemCってC++にTemplate Libを追加しただけだから、
重いんだよね。自分が記述したハードモデルをSimulationする上で
実際に必要となるもの以外が山のようにくっついて無駄だらけだから
遅いの当たり前なんだよね。しかし、SCIも上手くやったなあ、と。
普及すればするほど、高速Simulatorに価値が出て商機ありだもんね。

SystemCってC++と同じく多重継承とか許すのけ？
式テンプレートとかも普通に通すのかな？
それで合成できたらすごいな。どんな回路になるんだろ。そういう合成は初めから無視なのかな
放る手

>>645
SystemCはSimulation専用言語だよ。合成って？ 無駄な期待は身体に毒だよ。

相変わらず、全然盛り上がってないね？

「SystemC v.s. SystemVerilog どちが主流？」で議論してみるというのはどうだろう？

え？ 答えが明らかって？ うーん、そーかも……。

学部で研究しています。
交通工学分野で、料金所混雑について調べています。
料金所利用車を、ＥＴＣ利用車と人による料金支払いをする車に分けて、後者の車による渋滞にＥＴＣ利用車が
巻き込まれる事象をシミュレートしたいと思っています。
到着率やＥＴＣ普及率を変化させ、車の平均滞在時間がどのように変化してゆくのかを調べるために、プログラム
を書こうとしているのですが、Ｃが適切なのでしょうか？
助言をしてください。

>>648
待ち行列モデル？

>交通工学
ﾌﾟｷﾞｬﾊｱ

クマー……。

SystemC2.0をDLして、「C/C++によるVLSI設計」に掲載されている
Jpegコーデックを設計しようとしたのですが、エラーがでて動きません。
もし試された方がいればご教授お願いします。

プログラミング環境はCygwinを使用しています。

Make fileのTarget Architecture指定をCygwinにしてCompileした？

レスありがとうございます。
Target ArchitectureはCygwinにしてるのですが・・・。

どうにも関数の定義がほとんどされていないようなのですが
ネットで調べて見つけたのはいいのですが
勉強がたりなくてそれらのつかいかたがわからな状態です・・・。

私が行ったときもすぐにはコンパイルエラーになりました。
多重定義とインクルードファイルの定義ミス（タイプミス？）
の修正で通ったと思います。

やはり動かないみたいです…。
もし支障がなければMakefileの中身を
教えていただけないでしょうか？
よろしくお願いします。

SystemCは通常のCのように配列は扱えないんですか？

>>657
データ型と配列の大きさによる。普通のCのデータ型を用いる分には大抵
大丈夫だけど、sc_intとかを用いる場合は、newを使ってくらさい。

で、channelに用いる場合は、www.systemc.org のIDとPasswordをゲット
してForumのQ&Aコーナーに行って該当する質疑を探し出してください。

あの…。家のパソコンでＣ言語をやろうとしたらエラーがでました。
#include <stdio.h>

省略…。

とやると
#include <stdio.h>見付かりません…。
***.objまでしか出ない…。
***.exeがさっぱりでない↓
どうしてですか？教えてください。
Windows meです(笑)

も前らちゃんとUML使って設計してるかえ？

>>660
不死痛の亡霊みたいな発言だね。Single Processor上のマルチタスク処理を
記述するために開発されたのがUML。確かにReal Time Extensionもなされて
いるが微妙な感じ。OMGでもヘテロ構造に拡張出来てないのに、そんなもの
をどうしろと？

SystemCとLinkして普及を狙ってるんだろうけど、迷惑なだけだから死滅して
くれ。

はぁ？オブジェクト指向のモデリングをするのがUML
シングルプロセッサ云々は全く関係ない。わかってないだろ。
オブジェクト指向モデルを記述するのに現状UML以外選択肢がない。
ヘテロ構造だと？笑わせんな。
それならSystemCで記述できてUMLだと不具合を生じることが何か言ってみな。

>確かにReal Time Extensionもなされて いるが微妙な感じ。
2.0の仕様だけ読んでわかった風にレスつけんなアホ。

> オブジェクト指向モデルを記述するのに現状UML以外選択肢がない。

レベル低杉 (ﾌｹﾞﾗ

> それならSystemCで記述できてUMLだと不具合を生じることが何か言ってみな。

完全な釣りだね (ﾊﾗｲﾃｰ。

↑　一　致　半　解　の　池　沼　の　戯　言　で　し　た　〜

不治痛って痛杉な香具師が多いのか？

しかし、SystemCのIEEE標準化で一番受けたのが、1666って数字。
666って悪魔の数字だからね。委員も相当苦笑していたらしいし。

UMLかあ、直ぐに役に立つのけ？ だったら有難いんだけど、現場は
新しい事やるのイヤがるからなあ。Verilog覚えて、SystemCのために
C++覚えて、更にAssertion言語も覚えて、で、UMLも？ 大変な世の中
になったもんだ。

UMLには状態遷移図もシーケンス図もあるわけだが。

少なくともソフトウェアの海外発注しようとすればUMLは必須
プログラムの粒度が小さくなったり、HDL記述だとオブジェクト指向が役に立つとは思わんが、
SystemCが目指してるところはHDLのような合成じゃなくてモデリングなんだから、
むしろSystemCなんかどうでもよくてUMLの方が大事じゃないか？

>>666 (悪魔の数字だのぅ)
うーん、対象システムは何？ きっとMPSoCなんだよね？ で、UMLかぁ。
そういうの向きのデザインパターンってもう纏まってるの？

>>667
「業界in裸の王様パターン」
どうみてもダメな技術or手法の宣伝が流行していて、
誰もそれを否定しない状況。

>>668
> どうみてもダメな技術or手法の宣伝

詳しく！

つうか、馬巣根派苛は確かに糞だよね。

つうか、UMLﾏﾝｾｰ バカは何処に雲隠れしたんだ？

馬巣根派苛ってなに？

>>671
きっと「ば す こん ぱ いら」と読むのではないかと。

SystemCで、プロセス内にfor文を用いると直列処理になるんですか？

シーケンシャル処理になる。並列実行はSC_CTHREADかSC_TREADで書いて。
Handel-Cとは違うよ。

>>674
ありがとうございます。勉強になりました。

★大家２ｃｈ出動！！★
＿＿＿＿＿＿_＿＿＿＿　　　　　　　　＿＿＿＿＿＿＿＿
| ／大　家　　 　 ＼:＼::　|　　　　　　　　|゜池田犬作　著　゜|
| .|　財務しろ!　　　 ﾐ:::|::　|　　　　　　　　|　『洗脳革命！』　|
|ﾐ|_≡=､´ ｀, ≡=_、　|;/.:　|　　　　　　　　|　＿.＿.日本壊滅..|
| ||..(ﾟ )|￣|. (。)　|─/ヽ:.　|　　　　　　　　|/:::::::::::::ヽ 挑戦人..|　　　　.|
| |ヽ二/　　＼二/　　∂:/.|　ｸｿｯ　　＼　/::::::::l　__.._l..家学会|　　　　:|
| /.　 ハ - −ハ　　　|_/　|　死ねｱﾝﾁ　|(6::/ーロロ￣￣￣　　　　　|
| |　 ヽ／＿＿＼_ノ　　/　|　氏ねﾔ／,/　　　　　_ゝ　　　　　　　　　:::|
|　＼､ ヽ|　.::::/.|／ヽ../　...|　　　　　／　　　ｌ￣ヽ-'　　　　ｶﾀ　　　　:::|
|　　　＼ilヽ::::ﾉ丿＿　　　..|　　　　／::|　　　|　ヽ　　ｶﾀ　　　　／|　　..|
|　　 　‐しｗ/ﾉ＿_　　　　..|　　／　　::|　　/＼　＼＿＿ilil!!　///　　　|
￣￣￣￣￣￣￣￣￣￣　／　　　　|　　`ー――l|l|l|l!!!；；///...ｶﾀ　.|　　　＿
　　　　　　　　　　　　　　　/　　　　　　ヽ,ー‐‐‐∈≡≡≡∋//|.　　　|..　　■|
＿＿＿＿＿＿＿＿＿＿.l　　　　＿∠♂__..　;―――――‐:ｌ:::|＿＿|　　/L｜
　　　　　　　　　　　　　　　|　　　　:　:　:　:　:ヽ|::::::::::⊂⊃::::::::::|:::|　　　＼/
　　　　　　　　　　　　　　　ヽ､　:　:　:　:　:　:　||::本場姦国産::|:::|..　　　/＼
　　　　　　　　　　　　　　__／ヽ`―――‐:　:..ｌ|::::::::キムチ:::::::|:::|――'　　..＼
　　　　　　　　　　　　　　~ー――――――'..|:::::::::::::::::::::::::::::::|/
　　　　　　　　　　　　　　　　　　　　　　　　　　￣￣￣￣￣￣　　

閑散スレになってるなあ。SystemCに皆飽きたのかな？ JOVEってどうよ？

で、藻前らは先々月のEDSフェアでなにみてきたの？
なんか３年ぶりに逝ってきたわけだが。
３年前と比べて、馬犬 目な匂いを感じた。
なんか、そばかす？ちがうご飯粒？
すうどん？あ〜それそれｗ
ま〜あれだ、金のある半導体部門もっている大手は
もうやっっててあたりまえな感じの事例発表だったが、
ほんとかな〜ってかんじ。・・・・なんだけど。
藻前らはRTLでこのままやっていくの？

>>678
論理合成ツールに勝る人手Trベースの設計まっしぐらです。RTLと実装は
機能一致しかしません。

>>679
Domino Logicっすか？ そりゃあ、大変ですね。

大規模化著しいFPGA，米XilinxがESLツールの利用促進の活動を開始
http://techon.nikkeibp.co.jp/article/NEWS/20060316/115019/?ST=edaonline

↑ メインは動作合成らしいんだが、BluespecにHandel-C、ImpulseC、
SystemC(但し、SystemCはほぼRTL記述しか無理)と「出来るなら何でも良い」
ってノリみたい。

http://gazo03.chbox.jp/home/gazo03/data/gazo/wara/src/1141725257305.jpg

STOCって未だ活動してるの？ つうか、↓ これって？？

　http://www.interdesigntech.co.jp/modules/news/article.php?storyid=50

結局、SystemCの合成ってどうなったの？ 使えるの？ OSCI準拠じゃない
へんちくりんなライブラリ使わないといけないような感じだったけど、
デバッグとか大丈夫なんでそか？

>683
洩れみたいな納期短縮民生品ばっかりやってると
こーいうのとても魅力的だな。
洩れのとこにもここの会社からメール入ってたけど、
逝ってきた神いる？

 

自分で書き起こす部分を全く無くして、
全てライブラリ使うと結局回路図入力するのと同じなんだよな

>>685
ライブラリをSpecCで作らにゃならんし、全部プロセッサみたいなModule
しかないChip設計ってどう思うよ？

そーいや、BachCとかHY-Cってどうなったん？ 完全に死滅した？ ｗｗｗｗ

盛り上がらんね。それだけ、SystemCが普及したって事？

>>690
いや、SystemVerilogなんでないの？ 実際に普及してるのは。

>>24
抜けあったよ。つうか、このスレ長いが結構勉強になったよ。
↓ BluespecのLRM
http://www.bluespec.com/support/documents/bsc-3.8.61-reference-guide.pdf

>>689
今年、YXIはDAC展示会場に居ないみたいだね。

http://www2.dac.com/data2/43rd/43exhibitorArea.nsf/%28exhibitshtml%29/$first?OpenDocument

死んだのかしら？

最近ベンダから良く聞く言葉は、

　　「SystemC使ってないから高速です！」

という力強い言葉なんだけど。おまいら、未だSystemCなんて、C++の
Dead Copy使ってるの？ だとしたら、アホだねｗｗｗｗ

>>693
新製品がでてますね

割り込み出すハードとソフトを

a. 通常のスレッド
b. 割り込みスレッド
c. ハードのスレッド

というふうにモデル化したいんすけど、
a<bとスレッドに優先順位をつける＆排他実行させるには
どうやればいいですか？

>>693
生き残ってるみたい。Cooleyのサイト

　http://www.deepchip.com/items/else06-08.html

で、ユーザサイドからのコメントがあったみたい。

　○ C2RTLはちゃんと機能してるけど、使うのチト難しい。サポート
　　重要なんだけど、米国じゃ手薄。

　○ タイミング情報を付加して記述可能なHyCも、もう使える。

おまいら、Ｃｙｂｅｒが売りに出るみたいでつよ、と。

NECの動作合成，ようやく市場へ出る
http://techon.nikkeibp.co.jp/article/NEWS/20060628/118677/

同業他社へどうやって拡販するかは意味不明だけど、全部揃ってるのは
これだけだね。大手ＥＤＡベンダの動向が楽しみだね。

SystemCの合成サブセットがOSCIから出たお。まぁ、納得はできるし妥当とは
思えるが、この程度の結果を出すのに時間かかり杉。既存技術で合成可能な
部分の寄せ集めであって、なんらブレークスルーを含むものじゃないので、
マジ時間かけ杉。

で、この言語サブセットでISSCCに投稿採択されるレベルの演算主体のDSP
アルゴリズムのアーキ構成を動作合成で効率良く実装しようとすると、RTLで
書く事になっちゃうので、やっぱプロには無用だね。アマチュアにはいいの
かも知れないけど。

「徐々に進歩していけば良いんだ！」と将来に先送りする事で擁護する白雉
が湧いて出てきそうだが、その進歩がないの事が大前提ってのがSystemC
だからね。この理由さえ、白雉には分からんのだろうけどね。

やっぱ、産官学関係なくEDAに集まってくる人間って、学術能力のレベルが
低いのかしら？ そーとしか思えない。

SystemCは、時期が早すぎたか・・・。

HDLとSystemCの差をアセンブラとコンパイラに例える人もいるけど、
アセンブラに相当するのはゲートレベル設計だろう。CとC++の差に例える
のが適切かな・・。

でも、ソフトウェア開発とハードウェア開発が完全に融合したときには、
ソフトウェア言語でシームレスにハードウェアを設計できるようになってほしい。

>>699
今のところ、HDLのユーザーは職業設計者が多いだろ。

現在のソフトウェア言語のユーザーのようにアマチュアが
非常に多くなったらどうだろうか。遅くても効率が悪くても、
とりあえず簡単に作れるなら良い、と考えれば。
とはいえ、ソフトウェアより遅かったら意味無いけど。

>>701
Pentiumの性能向上が凄すぎて、その頃にはPentiumに勝てる専用ハードを
作る事自体が難しくなっているかもね。

汎用ハードと専用ハードが交互にドミナントになるんだが、この先どうなる
んだろうね。ダイナミックリ・コンフィギャラブルなんてのもあるけど、
現状じゃ高性能汎用DSPに勝てなくて苦戦してるみたいだしね。

まぁ、ハード設計が商売である限りは、TAT重視の動作合成使いになるか、
チューニング命のRTL書きになるか、のどっちかなんだろうね。

>>702
Pentiumなどのプロセッサは頭打ちになりそうな気がする。プロセス
の微細化は遅くなっているし、クロック周波数もあがりにくくなっている。

妄想だけど、プロセッサとダイナミックリ・リコンフィギャラブルが同一の
チップに乗っているシステムがあったとして（例えば、ダイナミック・リコ
ンフィギャラブルプロセッサ付きPentium)、C/C++のような普通のソフト
ウェア言語が簡易の回路設計言語になれば良いな、と思ったりする。

各C/C++関数に対して回路化オプションを指定すると、回路化の候補に
してくれる、とか。で、回路化に失敗すると警告が出力される。

1ポートをHi/Loできる速度というかクロックは頭打ちでも、
プロセッサに求められる四則演算に関しては、しばらくは並列化で速くなるだろ。
除算もニュートン法使うわけだし。
でも、2倍/2年とかはもう無理だけどな。
並列化を進める毎に低クロック化して、どこでギブアップするかは確かに感心あるけど。

SystemC用のISSはどこが用意しているのですか？
販売している会社とか探しても見つからないです。
NECのマイコンをSystemCに繋げたいのです。
それにソフトウェアを載せて協調検証みたいなことが出来たらと思います。
誰か教えて。。
NECのSyber買わないとだめなのかな？

IEEE1666になってからというもの、SystemCの活動ってどうなんでそか？
GreenBUSとか出てきたけど、使えそうなんかいね。ライセンス形態とか
どうなんでそか？

結局、TLMとか騒いでたけど、アプリ開発には糞遅くて使い物にならんという
のが白日の下に晒しだされたので、Simulationでも使えないって事になって
しまったけどね。

>>705
大口ユーザだったら、ISSを提供してくれるんでないの？

大阪狭山市在住・自称19歳のスロット板のコテハン
おっぱい☆ミシェル◆HmqLf3qSgkこと藤井隆史をよろしく頼むおﾉｼ

　近畿大阪○行狭○支店　支○番号35*
　□座○号065*320　フジイ○カシ

( ^ω^)1000円以上で振込み頼むお

【機械割】乞食？詐欺師？藤井隆史【0％】
http://news18.2ch.net/test/read.cgi/slotk/1157603558/l50

ここも閑散としてるな。ここで議論してた連中は、MIXIにでも移った
んだろな。まぁ、OSCI含め素人集団が何を頑張ろうが、ゴミの開発・
流布を更に進めるだけの可能性が高いから、もうどうにでも、って
感じではあるが。

頑張れば良いってもんでも、尊敬されるわけでもないからね。本気で
頑張ってるって主張したいなら、HDLと共存ではなくて、HDLの完全な
代替手段として普及させるという実績を作るこったね。

「SystemCとHDLは補完関係にある」とかいう敗北宣言にはマジ笑ったよ（嘲笑

最新版のCygwinで、SystemCをInstallしようとしたんですが、上手く行かないです。
どうすればInstallできるのか、どなたか教えて頂けないでしょうか？

>>709
どのへんで詰まっているの？
Cygwinは開発ツールも一緒にインストールしなきゃだめ
だけどそれはOK?

wait使わずに時間管理で同期させる方法、どなたか知らないですか？
SystemCのスケジューラを殆ど動かさずに並列動作を実現する方法が
あれば嬉しいです。

age

誰だよ、SystemCなんてゴミ屑を流布させたの？ 正直迷惑なんだけど。

shu

保守age

開発

このスレとともに、SystemCもこの世から消えてはくれないものだろうか？

OSCI様、SystemCシミュレータ販売開発会社様、SystemCモデル販売開発会社様へ

　長時間シミュレーションできないクラスライブラリやモデル、本当に有難うございます。

SystemCをダウンロードしたいのですが、手持ちの本と
ホームページの構成が変わっており、どこからアカウントを取り、
ダウンロードするのかわかりません。誰か教えてください。

shu

ho

「ソフトの皆様，お待たせしました」

http://techon.nikkeibp.co.jp/article/NEWS/20080314/148965/?ST=edaonline

今回のバージョン・アップによって，当初から目標としてきた「C言語を使う
ソフトウェア設計者がLSIを開発できる環境を提供する」ことが実現したという。

ピントがずれすぎ
| 「C言語を使うソフトウェア設計者がLSIを開発できる環境を提供する」ことが
実現 |「処理の詳細な調整を可能にしてきたが，ソフトウェア設計者にはそれが...
(2008/03/14 22:13:50)

オオカミ少年
いつも大風呂敷を広げれば皆寄ってくると信じているのがＣＡＤ屋さん。ソフト
ウェア設計者がＬＳＩを設計って、ＨＤＬのときにも聞いたな。
(2008/03/14 13:18:16)

停滞気味のＥＤＡの法螺吹きでしょ？
ここに限ったことじゃないですがまるで実体が伴わないいつもの
話題づくりとしか。。。値段が１０万円、よいハードが普通の
Ｃ＋＋を変えずにワンタッチで出る、が完全...
(2008/03/14 09:37:51)

>>722
ちょｗ おまｗｗｗ

> 値段が１０万円、よいハードが普通のＣ＋＋を変えずにワンタッチで出る、が完全...

世界最先端の超並列コンピューティング環境向けコンパイラを、１０万円で提供しろって
言ってるに等しいぞｗ

つか、そんなの出来たらハード屋即死だしｗｗｗ

ＥＤＡのニュースソースとして全く見てないから放置汁

>>724
心配すんな、後数年すれば、ﾊｧ!? ってツールが登場する悪寒がしてるから。
つか、RTL職人さんの大量失業時代が直ぐそこまで来てるって感じ☆

SystemCなんて、所詮はシステムのモデリング言語。

主なターゲット・ユーザーはセットメーカのシステム・アーキテクトだろう。
すでに部品の切り分けが完了した下請けのLSI屋さんには余り重要でない。
また、システム・アーキテクトにしてもシコシコとシステム(セット)全体をモデリングする変態はいないと思う。
結局は、経験と知識と前例から殆ど適当(センスの問題もあるが)に機能の切り分けを行うんでしょ？
部分的なモデリングは、CでもMatlabでもはたまたエクセルでもできるしね。
さらに、SW屋さんのコミットメントも取ってないし、運用に少し無理がある。

ただ、LSI内部のSWとHWの協調検証にC/C++を使用するのは賛成。
この場合、シミュレータとデバッガが重要な位置をしめる。
HWをC/C++に変換するツール類もあるし後は、どうやって簡単に高速実行可能な環境を構築できるかだと思う。

ということで、SystemCは逝って良し
ただ、いつでも飛び乗れるように少しばかりは勉強はしとくがね。

>>726

補足

オーバーヘッド(変な継承やオーバーロード)の少ない
純粋なC/C++等で設計および検証できるなら是非使いたい。

謹賀新年！ 記念パピコ！！

SystemC詐欺はいつまで続く事やらｗｗｗ

（・∀・）　今年初の書き込み　（・∀・）