5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

SystemC、SpecCについてのスレ

1 :名無しさん@お腹いっぱい。:03/12/25 01:08 ID:wBgaN8Yz
今、話題になってるようですが、どうなんでしょうか?
企業ではもう使ってる?

2 :名無しさん@お腹いっぱい。:03/12/25 01:32 ID:HcnmKJl0
よし、キターーーー(゚∀゚)ーーーー!
だが、お隣の板で、C記述段階と合成後のシュミレーションのギャップでは苦労しそうだという見解だったが・・。

3 :名無しさん@お腹いっぱい。:03/12/25 21:28 ID:0WhUi6G4
Open SystemC Initiative
http://www.systemc.org/

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

4 :名無しさん@お腹いっぱい。:03/12/25 21:33 ID:0WhUi6G4
C/C++によるVLSI設計―SystemCによるJPEGコーデック設計
http://www.amazon.co.jp/exec/obidos/ASIN/4320120817/ref=lm_lb_2/250-6918473-1229059

5 :名無しさん@お腹いっぱい。:03/12/26 12:41 ID:wTzjnqQ7
Cを使ってみてる。すげーっ!!!としか言いようがない。
久しぶりに感動した。

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


6 :名無しさん@お腹いっぱい。:03/12/26 20:57 ID:Z5dYxya7
 企業で実際にSystemCを使ってLSI設計している方います?
私は、大学でやってますが。

7 :名無しさん@お腹いっぱい。:03/12/26 21:10 ID:bwD/CgBi
学部生乙

8 :名無しさん@お腹いっぱい。:03/12/26 21:36 ID:hd73r4AI
>>6
苦学生かもしれんが親のスネかじってるんなら必死で勉強しておけよ。
会社に入ったら勉強してる時間もなく即実戦投入なんて当たり前だからな。

9 :名無しさん@お腹いっぱい。:03/12/27 11:15 ID:IT/DGOSU
セロックシカのHandel-Cも仲間に入れてくれる?
http://www.celoxica.co.jp



10 :名無しさん@お腹いっぱい。:04/01/01 17:42 ID:oJAp2x+k
freeでCからHDLレベルまで落とせるヤツを探してちょっとだけいじってみた。

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

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

11 :名無しさん@お腹いっぱい。:04/01/02 21:32 ID:SluL5UR6
Streams-Cを眺めてみましたが、ターゲット決めうちはちと辛いっすね。
ソースがあるし、簡単にリターゲットできるから・・なんて書いてあった
けどほんとかな?
やはりHandel-Cみたいなごく素直なC環境が一番いい気がします。
フリーで出回ってくれば大きな転換点になることは間違いないと
思うのだけども。


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

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

13 :名無しさん@お腹いっぱい。:04/01/03 11:53 ID:8cTDGtIM
こんなのもあったけど・・・ちと古いっすね。
http://www.eecg.toronto.edu/RESEARCH/tmcc/tmcc/

14 :名無しさん@お腹いっぱい。:04/01/03 12:08 ID:PnIvEyVG
あ、URLを書くのを忘れていましたね。

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

15 :名無しさん@お腹いっぱい。:04/01/03 13:35 ID:8cTDGtIM
おっとぉ・・・Handel-Cの太古バージョン、Win2000のDOS窓で
動きましたぜ。
HCC.EXE

CAMLRUNM.EXE
の両方を落として、
hcc t1.hcc
とやっただけ。中身はマニュアル眺めながらちょっと
書いてみたけど、こんな感じ(インデントがおかしくなると思うけど・・)
const spec t1 = {
fpga_type = "Xilinx3000",
fpga_chip = "3195APQ160-3",
clock_pad = "P160",
not_error_pad = "P55",
finish_pad = "P44",
clock_divider = "1",
carry_weight = "50",
critical_weight = "100"
};

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

16 :名無しさん@お腹いっぱい。:04/01/03 13:37 ID:8cTDGtIM
コンパイルするとそのまんまシミュレーターが動いてしまうの
だけども、ちゃんとXNFファイルができとりました。


17 :名無しさん@お腹いっぱい:04/01/03 14:20 ID:8cTDGtIM
hcc -ns t1.hcc
とやれば、シミュレータは動かず、
コンパイルしてXNFファイルを作って終了するようですね。


18 :名無しさん@お腹いっぱい。:04/01/03 17:04 ID:PnIvEyVG
あれま。Win2000だと動くのですか。
単にうちの環境が腐っているだけなのかな。うーん

19 :名無しさん@お腹いっぱい:04/01/03 17:30 ID:8cTDGtIM
D/Lしたときにデータ化けしてしまったとか?


20 :名無しさん@お腹いっぱい。:04/01/03 17:58 ID:PnIvEyVG
こんなんがでるのです。

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

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

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

21 :名無しさん@お腹いっぱい。:04/01/03 19:38 ID:8cTDGtIM
XPでやってみたら、同じようにコケますね。
Win98は大丈夫。Win2000も大丈夫・・ふむ。
そういうことみたいですね。

#で、それは一応そのままノーコメントってことで(w


22 :名無しさん@お腹いっぱい。:04/01/03 20:03 ID:PnIvEyVG
あー。XPではダメなんですね・・・。とほほ。
(たぶん)前掲のリンクのHandel-Cは、研究途上の物だと思われるので、
これの利用は商用を考えなければいいのですよね? ですよね?

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

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

23 :無しさん@お腹いっぱい。:04/01/03 20:44 ID:8cTDGtIM
別に良いんでしょうね。商用には絶対使いようがないでしょうし。
デバイスは・・うーん・・と、吐いたXNFを見るとかなりプリミティブな
ものの結合でしかやってないので、XNFを読ませてからターゲットを
決めることが・・・できるのかな?


24 :名無しさん@お腹いっぱい。:04/01/03 21:04 ID:PnIvEyVG
なんといいますか。

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

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

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

25 :名無しさん@お腹いっぱい。:04/01/03 21:40 ID:8cTDGtIM
ですね。Handel−Cに至っては4桁万円(爆

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



26 :名無しさん@お腹いっぱい。:04/01/03 22:43 ID:8cTDGtIM
ISEをインストールしてみたのですが、XNFが読めないんですね。
http://support.xilinx.co.jp/xlnx/xil_ans_printfriendly.jsp?getPagePath=12980
を見たら、ISEの4.2iがXNFが使える最後のツールだそうで。
http://support.xilinx.co.jp/webpack/classics/wpclassic/index.htm
こっちから4.2以下のを落とさないとだめか・・


27 :名無しさん@お腹いっぱい。:04/01/04 10:40 ID:Z5yOsB41
げ。DK1って4桁万円もするのですか。
UKではDK2が発売されているみたい?ですが、
こっちもすごい値段になりそうですね。

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

28 :名無しさん@お腹いっぱい。:04/01/04 12:41 ID:Z5yOsB41
正月の酒に任せて思うことを書いてみます。

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

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

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

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

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

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

29 :S川T秋:04/01/04 13:18 ID:ZTHlj6a9
>>28
APIを組み合わせてプログラムを作るという、
ロジカルな作業ができればだいじょうぶです。

30 :名無しさん@お腹いっぱい。:04/01/04 13:51 ID:j0iLib1Y
私も、ほろ酔い気分ですが・・

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

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

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


31 :名無しさん@お腹いっぱい。:04/01/04 14:03 ID:mkzAF1/L
アルゴリズムだけ書けてI/Fは宜しくなんて仕事の仕方をする
ソフト屋がハードも設計できると勘違いしてハード屋不要論を
振りかざすなんて、10年前に見た光景を繰り返すんだろうな。(w

32 :名無しさん@お腹いっぱい。:04/01/04 15:16 ID:j0iLib1Y
「そんな中途半端な分け方しないで全部やれ!」ってことになるかもね。

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


33 :名無しさん@お腹いっぱい。:04/01/04 16:13 ID:mkzAF1/L
>>32
ハード屋不要論
HDLがだんだん使えるようになってきた頃解ってない奴が
盛んにそんなことを言っていた。

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

34 :名無しさん@お腹いっぱい。:04/01/04 17:52 ID:j0iLib1Y
あぁ、了解。
結局不要どころか、「ハード屋もっとやることあるぞ」になって
しまった気がするね(w

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


35 :名無しさん@お腹いっぱい。:04/01/05 21:39 ID:+T85cApK
うう。webpack4.2iには、.xnfを読むためのDesign managerが入っていないですね・・・。
xnf2ngdとか使ってどうにかするしかないのかな<Handel-C太古版

36 :名無しさん@お腹いっぱい。:04/01/06 19:37 ID:UUSuOCWK
こっちも探してみました。
なんと・・・ISEには入ってるとあるけど、確かにWebPackには
入ってない・・(怒
4.1も落としてみましたけど、やっぱり無い
xnf2ngdっていう手ですかね、こりゃ。

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


37 :名無しさん@お腹いっぱい。:04/01/07 08:44 ID:j/+ATAMw
>>36
私も落としてみました。3.3も。
3.3には同名のバッチファイルが入っていて、実行すると
「コレ、先は長くないよ」といったテキストを表示するだけでした。

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

38 :名無しさん@お腹いっぱい。:04/01/07 09:19 ID:j/+ATAMw
3.3版で試してみたことの追記です。

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

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

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

39 :名無さん@お腹いっぱい:04/01/07 15:36 ID:1hW0KQuy
SystemCが組込まれたVerilogCを使っている。
もう、ハードとファームは同時に設計するのが当たり前。

40 :名無しさん@お腹いっぱい。:04/01/08 07:59 ID:gyYktsi4
Handel-Cその後。

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

41 :名無しさん@お腹いっぱい。:04/01/08 09:38 ID:fymclxvq
>>39
詳細きぼんぬ。


42 :名無しさん@お腹いっぱい。:04/01/08 15:37 ID:ihd3pYUB
オープンHandel-C(って言うのも変だな・・(笑))
テスト用に小さいファイルで"VHDL"でやってみますた。
んんん・・・・電源らしきところはコメントアウトするにしても、
LIB_OR2とか、これが全滅か。こういうプリミティブなゲートを
全部定義しないといけないのかな?



43 :名無しさん@お腹いっぱい。:04/01/08 23:00 ID:gyYktsi4
>>42
なんかそんな感じです。とほほ。
今のところ出てくるライブラリは、本当に原始的な奴しか出てこないので、
ぼちぼちとこしらえて行くしかないのかな、なんて思っています(すぐに飽きそうですが)。

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


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

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

44 :名無しさん@お腹いっぱい。:04/01/09 09:05 ID:07eBXsqw
HARPはS抜きシャープ(嘘
あぁ、そういえば、なんとなくそういう名前の製品もあったような・・

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

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

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

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


45 :名無しさん@お腹いっぱい。:04/01/14 12:07 ID:s7ELe5Gg
>>44
>なぞのハンドシェークってTXRDYとかRXRDYですよね?

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

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

46 :名無しさん@お腹いっぱい。:04/01/14 12:10 ID:s7ELe5Gg
>>45
× # 別スレ起こしても、二・三人しか書き込んでいないみたいですね・・・(w
○ # 別スレ起こしたとしても、現状では二・三人しか書き込んでいないみたいなので、どうでしょうかね(w

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

47 :名無しさん@お腹いっぱい。:04/01/31 11:02 ID:baoXXSXM
手作業が結構入ったけど、できました。
フリーHandel-CからALTERAのFPGAにフィッティング。
まだ簡単なことしかやってないけど面白く遊べるかもしれない。


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


49 :774ワット発電中さん:04/01/31 13:51 ID:/kLjdDdX
>>48
あのー。勘違いしてませんでしょうか?
HANDEL-C(太古版)の吐くVHDLの話なんですが。

50 :774ワット発電中さん:04/01/31 13:51 ID:/kLjdDdX
>>47
すばらしい!

51 :774ワット発電中さん:04/01/31 14:38 ID:baoXXSXM
やっと開通しましたよ。
ANDやORやFFなんかのプリミティブなゲート類を
定義してライブラリ化(といっても、VHDLの入門書の
最初の方のページにあるようなつまらんものばかりですけど)
するのと、エラーが出てしまう行を見ると使ってないようなので
コメントで殺して、あとは出力ポートをいきなり読み出そうとす
るようなコードを吐くことがあったので、ポートの方を名前変えて
ポート名と同じsignalを定義して、
旧ポート名signalと新ポートを<=を使って結合した
程度ですが。

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



52 :774ワット発電中さん:04/01/31 18:35 ID:/kLjdDdX
>>51
をを。自分の考えていた方向性が間違っていなかったのを確認できて一安心です。
私は手を動かしてませんでしたが(苦笑
買ったまま未組み立てて放置してあるEZ-FPGA(スパ2)があるので、いまさらながら
がんばってみようと思います。

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

53 :774ワット発電中さん:04/02/07 20:04 ID:ZRB3qdQx
システムCを使いたいけど、コストの面でどうにもならないな。
こういうツールを使うことが出来るのは、そのコストをあまり
気にしないセットメーカーさんだな・・・

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



54 :774ワット発電中さん:04/02/23 20:54 ID:FgsP7tnK
個人的には面白そうだと思うんだけど <HANDEL-Cの昔のやつ
なかなか盛り上がらないね。

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

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

55 :774ワット発電中さん:04/02/23 23:29 ID:YqOMtdjy
良くも悪くも大人になっちゃった人が多いんでしょう。

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


56 :774ワット発電中さん:04/02/28 19:44 ID:WD1MtbMc
>>55
こんどこそ、鰻のよい匂いを嗅がすだけの特集でないことを祈っています(w

57 :774ワット発電中さん:04/02/28 21:26 ID:qYAk0gch
どっちの料理ショー

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


58 :774ワット発電中さん:04/02/28 22:44 ID:WD1MtbMc
このスレ的には、Handel-Cの古いヤツが鰻の皮かな?(w

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

59 :774ワット発電中さん:04/03/10 10:42 ID:vZdSe25w
D.W.誌、買って来ました。
太古版がコラムで紹介されていたので、ちょっと嬉しかったり。

60 :774ワット発電中さん:04/03/18 18:35 ID:A/qHndsv
XPだとダメだという話は、
今月のデザインウェーブに載ってるね
それにしても、いよいよCの時代かな

61 :774ワット発電中さん:04/03/18 18:45 ID:vxvuR75V
>>60
このスレがネタ元っぽいね。

62 :774ワット発電中さん:04/03/19 16:28 ID:qfhUEwPw
>>61
やっぱりこのスレがネタ元なのかな?

63 :14,40:04/03/20 08:52 ID:Ex1f3GMl
もしもここがネタ元だとしたら、うれしいです。

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

64 :774ワット発電中さん:04/03/24 12:23 ID:2j4YU/fV
VHDLで書いた回路が引き継げなくて、困ってるのよ
Cで書き直すのはわけないから、あとはただとか安い値段で手に入るCベース設計ツールがあればいいんだけど
太古版Handel-Cが安定してくれてればいいのに

65 :774ワット発電中さん:04/03/24 13:02 ID:P5+sF8l5
>>64
安定、と言うよりも、基本的なライブラリの拡充が必要ですね・・・。
今のところ、どんなゲートが要求されるかわからないので、
「オマイ、NANDすら知らないのかっ!」みたいな感じですから。

66 :774ワット発電中さん:04/03/24 20:34 ID:2j4YU/fV
やっぱりまだ時期尚早なのかな

67 :774ワット発電中さん:04/03/27 02:57 ID:wNKAfPPJ
規模増大を,抽象度を上げる方向でなく,IP(買い物)で済ますという方向になってる気がするんだが…

68 :774ワット発電中さん:04/03/27 07:33 ID:EfFo1Vob
昔だったらIPを使わないとやってられなかったようなのが、
パタパタッと書いてできちゃう領域が広がるというのは
メリットだろうね。
まだIPとして提供されていないようなものもサラッと
実現できるだろうし。

69 :774ワット発電中さん:04/03/29 18:17 ID:EinKCVVE
ズブの素人なんですが
HDLとこれ、どっちからはじめるのがお勧めですか

70 :774ワット発電中さん:04/03/29 22:56 ID:QezwgINt
SynopsysはSystemCを見限ったの?
最近のSynopsys主催のセミナーは
System Verilogばかりのような気がする。

71 :774ワット発電中さん:04/03/30 00:24 ID:GVa9dVL6
シノちゃんはSystem Verilog派でしょ?


72 :774ワット発電中さん:04/03/30 16:45 ID:/TUWDNnO
折れ的には、保険のつもりで二股かけてるのかと思った。
軸足はSystem Verilogかな。

73 :774ワット発電中さん:04/03/30 22:19 ID:mT1zjk3y
Synopsys SystemC Compiler はあぼーん予定
http://www.eedesign.com/showArticle.jhtml?articleID=18201864


74 :774ワット発電中さん:04/04/14 17:38 ID:t6Vuj43k
どうせやめるならフリーにして欲しいな


75 :774ワット発電中さん:04/04/14 17:43 ID:7+5TCQlL
マイナーな上にベンダ固定なんだけど、NECのBDLっつー
Cモドキ設計言語使ったことある人っている?


76 :774ワット発電中さん:04/05/18 17:00 ID:unuKhMp8
ForteのCynthesizerはいよいよ正式発表でつか。
http://www.forteds.com/news/pr051004fortekkjapanese.pdf

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

77 :774ワット発電中さん:04/06/18 02:00 ID:3KdNuoj/
>>75
社員ハケーン・・・ってCyberの事だね。BDLは動作記述言語の事
あれはコデザインじゃないから
今のところ敵視してないです。
それに展示会見る限り他社に供与する気も無いでしょ。
お金の話したら歯切れ悪かったよ

78 :774ワット発電中さん:04/06/19 22:17 ID:GcnextNa
BDLみたいな動作記述言語からファームウエアなどのソフトを生成することはできないのかね。
そういうアプローチのコデザインもあっていいとおもうのだが。

79 :774ワット発電中さん:04/06/22 04:07 ID:/NWWRRG1
>>78
とりあえずファームにしておいて、間に合わなかったらハードに持っていく
ってーのが最近の流行(?)


80 :774ワット発電中さん:04/06/25 03:50 ID:0zbbbtSc
>77
この業界狭いんだからやめとけ
すぐだれだかわかっちまう
俺もなー
最近Visialspecつかってますた。
マイナーだ
つーかだれかまともな掲示板立ち上げれ!

81 :774ワット発電中さん:04/06/29 01:58 ID:F2tjVIVH
荒らしキタ━(゚∀゚)━( ゚∀)━(  ゚)━(  )━(  )━(・  )━(∀・ )━(・∀・)━カエレ!!!!!


82 :774ワット発電中さん:04/06/30 03:53 ID:647wrS6u
age

83 :774ワット発電中さん:04/07/01 00:08 ID:bLnyLCJ9
このスレの廃れようじゃ、Cベース設計も終わったか

84 :774ワット発電中さん:04/07/01 20:15 ID:90yMV1+v
ソフト・ファーム屋さんは結構手を出しているんじゃないの。

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

85 :774ワット発電中さん:04/07/02 02:42 ID:toQ5rXKk
いまのところHDL渡しなので、
C合成出力のHDLが読みにくいのがネック。 だけど、
ツールによっては、慣れると読める(変態?)のもある。
#読んでも、C合成のBug報告以外に何をするってこともないんだけど…



86 :774ワット発電中さん:04/07/02 08:13 ID:E7tiU86f
HDLとの等価性が無いのが厳しいんだよね。
いくら機能検証がHDLと比べて劇的に速いといっても等価性が無い以上
ハード化にはHDLでの検証も必要になってくるわけで、
単にフェイズが増えるといった結果にもなりかねない。

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

87 :774ワット発電中さん:04/07/02 15:09 ID:4w2zVRAg
今はとにかく早く動くものを作った方が勝ちって感じだから、
HDLでの検証なんてすっ飛ばしてタイミングレポートだけ見て
オッケーで突っ走るんじゃね?

88 :774ワット発電中さん:04/07/02 15:09 ID:4w2zVRAg
「速く」じゃないからな・・・念のため


89 :774ワット発電中さん:04/07/04 16:04 ID:wVkPNQpU
>>86
これの等価性検証ってど〜よ?
http://www.necel.com/ja/channel/pdf/2003/an0716_s2.pdf
UnTimeとCycleAccurateまたいでるので難しそう

90 :774ワット発電中さん:04/07/14 22:31 ID:tlbNV7Wt
日経エレクトロニクスのサイトを見たら、各社からSystemC入力ツールが結構発表されているのね。

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

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

92 :774ワット発電中さん:04/07/16 23:43 ID:N2mA28sR
>>91
抽象度生産性云々ではないと思う。
シノプが見切ったのは、儲からないから



93 :774ワット発電中さん:04/07/17 00:14 ID:cjBGvUVC
そんな名前の恋人も……

94 :774ワット発電中さん:04/07/17 00:50 ID:KxS/ZoFB
>>93
デブオタ的外見云々では無いと思う。
忍が見切ったのは、稼ぎがないから

・・・・_| ̄|○

95 :774ワット発電中さん:04/07/17 01:09 ID:wjKj571o
ageて迄書くことかよ。
つまらん。

96 :774ワット発電中さん:04/07/17 03:40 ID:F/uNI29i
そんなシノブに誰がした〜

97 :774ワット発電中さん:04/07/17 10:14 ID:HcIlXJoE
ConvergenSC

98 :774ワット発電中さん:04/07/17 17:56 ID:rACh1O9e
>>97 << SystemC+C++

99 :774ワット発電中さん:04/07/17 19:19 ID:uoWDUesL
>>98
ConvergenSCはSystemC入力じゃなかったっけ?

100 :774ワット発電中さん:04/07/18 00:06 ID:OEwsDAt9
>>99 入力と〜解析昨日


101 :774ワット発電中さん:04/07/18 22:37 ID:cAd7IOKa
忍もケイデンスも検証ツールはそろえてきてるんだし、
HDLユーザーがSystemCを始めるならモデリングから入るのがベストではないか、と思う。

102 :774ワット発電中さん:04/07/19 00:18 ID:gChJ8CYL
>>92
生産性が高くないからユーザが選択しない->シノプが儲からないんだよ。

103 :774ワット発電中さん:04/07/20 01:10 ID:r1ztiHKA
乱立で何が生き残るかわからんし現在移行するメリットなしと見たのだろう。
HDLが出来てきたときほどのインパクトはない、パラダイムシフトも起こっていないし
起こす必要も無いとなると消極的にもなるわ。

104 :774ワット発電中さん:04/07/20 17:51 ID:OpCdZM52
SystemC は C++ 上に実装されているというより C++ の STL 上に実装されて
いると言うべきです。

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

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

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

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

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


105 :774ワット発電中さん:04/07/21 02:15 ID:0ZdSLfgw
日本語から学び直すことをお勧めします。

106 :774ワット発電中さん:04/07/21 02:47 ID:XbMwVrbv
>>104
んで、けっきょく何を言いたい?

107 :774ワット発電中さん:04/07/21 06:11 ID:JShK/li2
>>106
LSI設計者の能力が低い

108 :774ワット発電中さん:04/07/25 16:18 ID:JN7nZCwp
>>106
納得。104はシノプの営業さんだったんだね。

109 :774ワット発電中さん:04/07/26 22:50 ID:iuGYuGue
忍はSystemCを捨てたから、彫る手の営業さんでしょ。

110 :774ワット発電中さん:04/07/27 01:21 ID:aEFhnPUh
>>104
今のところ知的レベル云々よりも、
Cから石にする言語環境的腕力が必要かと。。。



111 :774ワット発電中さん:04/07/27 05:53 ID:J6akz9AY
Cから石にできるという幻想さえ捨ててしまえば、SystemCは
結構便利だと思うけどね。
テストベンチ書くのは楽でいい。


112 :774ワット発電中さん:04/07/29 01:27 ID:uIxDz4PF
>>104
SystemCがSTL上に実装って、STLが何の略か解っているのでしょうか。
どうせならboost上に実装してくれればいいのに。

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

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


113 :774ワット発電中さん:04/08/03 01:25 ID:sNX4uTcp
ところでプライムゲートが大々的に紹介していた自社Cコンパイラはどうなったか
知っている人いないかい?

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

114 :774ワット発電中さん:04/08/08 23:53 ID:3GCsLQL4
似たようなふゅちゃーでざいん
って会社あったが、あれどうなったんだ??
最近みないんだが。

115 :774ワット発電中さん:04/08/10 10:20 ID:BbFqmC0Q
フューチャーデザインオートメーションはつぶれますた。
今は「礎デザインオートメーション」という会社が資産を引き継いでいます。
ttp://www.ishizue-da.co.jp/info/news_011504.htm

116 :774ワット発電中さん:04/08/10 11:10 ID:2d/yUj36
中の人おんなじ

117 :774ワット発電中さん:04/08/12 14:39 ID:UP+AaFfN
ひげの社長ね

118 :774ワット発電中さん:04/08/12 20:44 ID:ejSmdAqw
>>104
手順書くしか能のない、ソフト屋ごときが何ほざいてやがる。

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

119 :774ワット発電中さん:04/08/13 10:40 ID:iA7pQPmt
馬鹿を無視出来ない奴も同レベルだよ。

120 :774ワット発電中さん:04/08/13 12:21 ID:JZ83PsED
これからは手順書くだけでハードができるようになるんだもんね


121 :774ワット発電中さん:04/08/13 13:55 ID:6fFS22wW
ハードが生成されるかもしれないが品質は推して知るべしだわな。
論理合成ツール万能論で記述がダサダサでもまともな回路ができると
言い張るなら別だがね。

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

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


124 :774ワット発電中さん:04/08/13 22:18 ID:AcaRXowP
HDLは使っても、できあがる回路を意識した書き方をしていないと
デバッグが大変だからね。

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

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

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

125 :774ワット発電中さん:04/08/14 00:05 ID:ra/w9jQn
普段からダサダサコード書いてる奴がポイントポイントで高品質コードを
書けるわけがないと思う。
こういう使い分けができるのは相当技術力のある奴

126 :774ワット発電中さん:04/08/14 11:48 ID:6sy7h58e
>>124
>HDLは使っても、できあがる回路を意識した書き方
そうそう、
C動作合成も、出来上がる回路を意識した書きかたが重要なんですが、
コツをつかむのに半年〜かかった。それもツールごとにコツが違うのがシンドイっす


127 :774ワット発電中さん:04/08/18 02:35 ID:vAxgqPfQ
今のところセミナーで現実逃避という利点はかなり実感しているぞ


128 :774ワット発電中さん:04/08/21 16:54 ID:jgLVMlBt
sharpのbach-cはどうですかね?
使ったことある人います?

129 :774ワット発電中さん:04/08/29 22:07 ID:4RxWXG3a
>>128
回答でなくてすまんが、国内電気メーカーのツールって社内か特定顧客以外に実績あるの?

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

130 :774ワット発電中さん:04/08/31 12:37 ID:MqkPL34f
>>129
大手がBUGが取ってくれるまで待て

131 :774ワット発電中さん:04/09/10 23:36:38 ID:zxADNeYP
http://www.sony.co.jp/SonyInfo/News/Press/200310/03-041/
がBUG取ってくれるまでまてない

132 :元Sちゃん休職中:04/09/12 00:37:22 ID:SKPqkwUQ
この記事一年前だな。もうフォルテもバグ取れたかぁ? 代理店がやってた時はらちあかない状態だったけど、本格的に動き出してるね。関心!
BUGなんて規模がでかい会社は気にしないよ。永久に続くから中小は永久にまってても無理かも

133 :774ワット発電中さん:04/09/12 01:07:08 ID:tThF472X
>>129
ないです。
SystemC関連の事を調べてると京都大学の研究室の方が出してる
論文の中で Bach-cを使った研究があったので、ここで聞いてみると
意外と使ったことある人いるかも?というすごい曖昧な発想でカキコしました。
すいません。。。

134 :名無しのVHDLマン:04/09/12 11:42:24 ID:VToDEHJG
Bach−Cは既に、メンターがシャープと共同で商用化しています。
研究室レベルではオリジナルを使えるけど、企業向けには有料の高いツールとして売っています。
基本的にはANSI-Cだから、SystemCリファレンスシミュレータとはつながらないから、只のSystemCではなく有料のSystemC(メンター製)で使えるだけ。基本的にCADメーカはオープンソースを利用したがらないということで盛り上がらないのかもしれない。
シミュレータは只、検証環境も只でビジネス考えると儲からないから、独自なSystemCをCAD屋さんは考えます。
やはり最終的に合成で儲ける仕組みだったんですね?


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

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


136 :774ワット発電中さん:04/09/12 15:25:05 ID:Ef5Ts9Y/
回路になるの?
Simが出来るだけなんて無意味も良いところ。

137 :774ワット発電中さん:04/09/12 16:47:19 ID:UOYLWsoF
シミュレーションならCadenceとかのツールで対応できるし、
結局のところ動作合成ツールが普及せんことにはハード展開は難しいよね。
CynthesizerはUntimedレベルのSystemCに対応してくれるのかしらん。

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

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


139 :774ワット発電中さん:04/09/12 21:52:52 ID:dm+D5aJk
>検討さえ終わってしまえば今まで通りRTLで設計しても問題ない

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


140 :774ワット発電中さん:04/09/12 22:58:35 ID:Ef5Ts9Y/
FPGA等に書いて動かしてみないと面白くも何ともない。

141 :774ワット発電中さん:04/09/12 23:15:50 ID:dm+D5aJk
FPGAならやっぱりHandel-Cが一番実績あるだろうな。
一回使ったことがあるけど、感動した。


142 :774ワット発電中さん:04/09/12 23:38:49 ID:6xYPREfp
>>139
もちろん、最終的にはCから直接ゲートレベルまで落とせるようになれば、それに越した事はない。
ただ、現状ではこういった用途しか使いようがないのでは? SimだけでもCの恩恵を受けられる。


143 :774ワット発電中さん:04/09/13 01:04:02 ID:gF8YxSxP
特に勉強目的のSimのみと言うのを否定するわけではないけど、
実際に動作させないとなかなか続かないってのが現実だと思うな。
HDLが出てきたとき、も行数制限があるシミュレータで遊べたけど
やっぱり波形を見るだけではすぐ飽きてしまったし。

144 :774ワット発電中さん:04/09/13 08:32:26 ID:kNjtt+Xb
>142
ずっと上の方にもあるけど、Handel-Cの太古バージョンで
ゲートまで落とせるんだよ・・・・・


145 :774ワット発電中さん:04/09/13 12:45:49 ID:M78u+rDr
C>HDLってトランスレーションだから悪くはない。

146 :774ワット発電中さん:04/09/13 13:15:09 ID:JDQZbsuv
ところでどなたか、デザインウェーブマガジン(今月号)の付録CDのSystemCツール入れた?
入れようと思ったけど、Linux対応版だからだめだった。せっかく自腹で本屋で買ったのに。。

147 :774ワット発電中さん:04/09/13 13:31:34 ID:Ii8QoZ86
>>146
それ、論理合成できますか?
できるのなら、ちょっと買ってきてためそうかな。
シミュだけだったら要らないけど。

148 :774ワット発電中さん:04/09/13 14:06:59 ID:+8yTYF21
まだ入れてないけど、なんたって只だからな。
Win環境ならSygwin使えばいいんじゃない。これも只
http://www.cygwin.com/ml/cygwin/2001-06/msg00186.html

149 :774ワット発電中さん:04/09/13 16:40:09 ID:kVbkQ7z+
>>147
http://www.cqpub.co.jp/dwm/Contents/dwm0083.jpg

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

150 :774ワット発電中さん:04/09/13 21:42:54 ID:nZDK2aRe
>>144
LSI設計にはまだ使えないという認識です。


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

152 :774ワット発電中さん:04/09/14 00:47:15 ID:UaCHz3pz
>>151
金持ち!!

153 :774ワット発電中さん:04/09/14 12:47:06 ID:tBFgZvye
>146
それ確か普通にサイトからダウンできますよ

154 :774ワット発電中さん:04/09/14 12:56:30 ID:U0nfRjRE
>151
確かにDK(Handel−C)はウマウマ。現状FPGA化するならあれが一番
じゃないかな?とにかく漫然と書いてもそれなりに動いてくれるし、
後からスレッド分割してみたりも簡単。
本当にカリカリにチューンしなくてはいけないような用途でもなければ、
サラサラとCで書いてDK通しちゃえばいいやって感じ。

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


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

156 :774ワット発電中さん:04/09/17 13:14:48 ID:d1rKMnic
そいえばケイデンスのツールインザイシブーSystemCも混在できるよ。
お試し版はないけど、、、金持ちしか利用できないけどね。。
おいらNCのユーザだから、今アップグレード待ち。

157 :774ワット発電中さん:04/09/17 23:10:35 ID:hdhMvki1
ModelSimにしてもIncisiveにしても
SystemCやアサーションはオプションライセンスなのが痛い…

VCSはライセンス追加はなさそうだが(SystemCは追加があるのか?)、
ウチの会社はVHDLが主流だからな(w

158 :774ワット発電中さん:04/09/18 13:47:38 ID:YPK9G0MY
ウチの会社はSILOS使ってる。汁箱に食べられちゃったからSystemCの可能性はなくなった。
永久ライセンスで買ってるから、いまさらSystemCにはいけないし。OSCIに繋がるらしいけど、
聞くところによるとOSCISystemCも拡張はしないって決まったようだし。
Incisiveは見積もり見たけど、SILOSと桁が二個も違うのでみんなでひっくり返った。
これは、半導体メーカ用ってはっきり言われたよー。もう、Toolは事X器屋には手が出ない金額になってきてるね現実は。
SystemCはオープンだから注目だったけど、半導体業界の陰謀??結局手の出ないToolになってしまった。

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

160 :774ワット発電中さん:04/09/18 16:56:30 ID:mnpnzSnh
同じIDで何やってるんでしょうか?

161 :774ワット発電中さん:04/09/18 17:12:01 ID:8R1E0s10
ソフト作る場合はC++の実行速度が魅力だけど
HDLのベース言語としていまさらC++?という気がする。
C#見てると言語仕様が古い。
SystemC は普及せずにあぽーんして正解だ罠

162 :774ワット発電中さん:04/09/18 17:27:29 ID:OwCjPLiN
コストがあまり関係ないとこで使うんだろうなぁ・・・あるいはFPGA/PLDか。
コストや再利用性を考えるとダサダサってわけにはいかんのよ。

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

163 :774ワット発電中さん:04/09/18 17:32:25 ID:OwCjPLiN
>>104

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

164 :774ワット発電中さん:04/09/18 17:56:44 ID:4t6mpc4X
>>161
じゃ、C#のコンパイラ作ってくれ。ARMかMIPS用な。作ってくれたら5Myen/Lis・yearで使ってやる。

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

166 :774ワット発電中さん:04/09/18 20:32:42 ID:+X0LHa0A
そういう手間暇かける必要のある製品って漏れの扱うような範囲じゃほとんどない。
第一それだけのコストを掛けて作ってもペイできない。


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

168 :774ワット発電中さん:04/09/18 23:34:13 ID:YPK9G0MY
SystemCのスレですよねここは、カリューの話は難しいのーーーーっ



169 :774ワット発電中さん:04/09/18 23:50:33 ID:vz2d5FZq
>168
ママゴト・箱庭・おもちゃチップやっとれ、オニアイだ。

170 :774ワット発電中さん:04/09/19 01:05:56 ID:YRTVer0d
暗いよ
下流>>演歌系
上流>>ラテン系
大変だけどがんばってくれないと、韓国系に負ける。
ドッチも仲良くね

171 :774ワット発電中さん:04/09/19 19:59:38 ID:lC7klqYF
>>164
>HDLのベース言語として
の意味わかるか?

172 :774ワット発電中さん:04/09/19 22:46:44 ID:kYz8c225
C#って何ですか? MSの推奨してる言語のようだけど、初めて聞く。前の議論単にC+の誤変換だと思っていた、俺はアフォ?
C言語の派生のようだけど。ここの議論とどうかかわるのか?
SpecCとかSyetemCに関係ないと思うんだけどー


173 :774ワット発電中さん:04/09/19 23:31:02 ID:bjwV+P4v
>>165
DFMが重要なのは知っているけど、
このスレ的には「だから何?」としか言いようが無い。

174 :774ワット発電中さん:04/09/20 13:07:14 ID:P0YUEQAP
http://www.ilink.co.jp/products/impulse/CoDeve.htm

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

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


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


177 :774ワット発電中さん:04/09/20 15:11:59 ID:xp0t+OuJ
>SoCとかワンチップとかの議論になると必ずSystemCの話が飛び出すから、
>アメリカかぶれ上流のマネージャは勘違いするから困る。

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

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

179 :774ワット発電中さん:04/09/20 18:29:44 ID:vhnQ01FM
MIPSはVerilogで書かれていた。



180 :774ワット発電中さん:04/09/20 18:30:14 ID:vhnQ01FM
ご免、正確には某社のMIPSアーキテクチャのCPUは・・ね


181 :774ワット発電中さん:04/09/20 21:27:38 ID:/tX0yVmm
>>179
この発言ってMIPSからライセンス剥奪されないか?

182 :774ワット発電中さん:04/09/20 21:42:52 ID:s6d23qj0
あの手のものだとまずVHDLでは書かないだろ。


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


184 :774ワット発電中さん:04/09/20 23:58:52 ID:x40Dm6Mf
>>183

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

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

185 :774ワット発電中さん:04/09/21 12:00:03 ID:qXm66vd+
>>183
それを言うなら

"VHDLは"

だろが!


186 :774ワット発電中さん:04/09/23 01:44:04 ID:ocp/ZJ+V
>>176
分類でいうとハードなんだがソースで判断してるなぁ。。
ブロック図なんてしっかり仕様書出す必要があるときだけ後付けで書く。。
頭の中はデータパスとステートマシンでイメージされてるかな。(HDLの場合)

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



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


188 :774ワット発電中さん:04/09/23 21:05:18 ID:j+bwLrz9
>>187

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

189 :774ワット発電中さん:04/09/23 21:06:24 ID:78KEvZFG
>187
言い意味での「ヲタ」がいなくなったからだろうね
つか、そろそろ半導体だの電気・電子産業全般から足を洗う準備をしても
いいんじゃねぇかとも思うけどな。


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


191 :774ワット発電中さん:04/09/25 21:34:12 ID:Jhhj+16A
誰かSystemCをBorlandC++Builder6で使ってるひといませんか
無料バージョンのVer5.51ではコンパイルできたけど5.6はエラーが出てコンパイルできないんです.
ここにソースがあったので試してみたんですが.
http://www.geocities.com/systemc_win/

192 :774ワット発電中さん:04/09/30 20:55:26 ID:Hf4umZ1v
論理シミュレータだけあっても合成ツールなきゃ使い物にならんやんけ!
あとgccでそのままコンパイルできるんだからそれ使え。

193 :774ワット発電中さん:04/09/30 21:16:10 ID:LwkL1Om/
合成ツールが無いと使い物にならないという発想では、所詮システム
レベルのソリューションは使いこなせないな。それより、抽象度の方が
問題だ。PAレベルでsystemC使って何がうれしいかと。

194 :774ワット発電中さん:04/09/30 22:46:00 ID:/FH1qBh0
でも、合成まで行ってくれないと、ワクワク感が無いよね。
なんか美味しそうな餌を見せられながらおあずけされてるみたいだ。


195 :774ワット発電中さん:04/09/30 22:56:02 ID:QdJPzg5b
ここには、誰もESLをわかっている人間はいないようです。
さよなら。 二度とここにはこない。合成の話をしてるようじゃ話にならないし、まじめな話を期待して全部読んだけど、
レベル低すぎ。2ch以外のところに新しいスレッド作るから今度はまともな議論しましょ わかる人にはわかる場所です。


196 :774ワット発電中さん:04/09/30 23:05:04 ID:ewAfnzTs
>>195
書き込まなくて良い。
黙って消えられないのはお前が厨だから。

197 :774ワット発電中さん:04/09/30 23:06:09 ID:ewAfnzTs
オマケ
半角を巧く使えない奴に、まともな論客が居たためしがない。

198 :774ワット発電中さん:04/09/30 23:38:30 ID:DwpnCQ9Y
>>197
そのうちわかるよ、君にも さいなら おやすみ
スレッド終了

199 :774ワット発電中さん:04/09/30 23:43:41 ID:ewAfnzTs
>>198
笑わせるな。

200 :774ワット発電中さん:04/10/01 00:01:00 ID:WdKXcOSR
誰か
>>191
よろ

201 :774ワット発電中さん:04/10/01 10:33:51 ID:NlbV8DE0
せめてエラーメッセージを載せることとか考えないのだろうか・・・

202 :191:04/10/02 21:01:17 ID:O1Arr+ya
ありがとうございました!

おかげで解決しました.

203 :774ワット発電中さん:04/10/02 21:45:13 ID:PiltKYCL
広告の裏にでも書いてろ

204 :774ワット発電中さん:04/10/05 21:35:15 ID:88blgXK3
解決したし、すごい事がわかった。
教えてあげない。

205 :774ワット発電中さん:04/10/05 21:48:57 ID:l0ciWgEE
これからはSpecC

206 :774ワット発電中さん:04/10/05 21:50:13 ID:l0ciWgEE
SpecC

207 :774ワット発電中さん:04/10/05 21:51:02 ID:l0ciWgEE
SPECC

208 :774ワット発電中さん:04/10/05 23:16:26 ID:EmtE7tiL
SpecCで何なるんだ? w

209 :774ワット発電中さん:04/10/05 23:55:30 ID:JF/t9vyR
システィナC











は違うか

210 :774ワット発電中さん:04/10/06 00:12:43 ID:0u9gJgpQ
どっかにも書いてあったけど、
これ絶対「小雪さん、小雪さん、SystemCのことおしえて下さい」
って聞こえるって!

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

211 :774ワット発電中さん:04/10/06 02:27:43 ID:/Gm2IO1h
カーセックスを盗撮された女に興味なし

212 :774ワット発電中さん:04/10/14 13:02:47 ID:IArkPici
SystemC&SystemVerilogデザイン・ワークショップ

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

213 :774ワット発電中さん:04/10/15 00:06:44 ID:fViToCo7
>>212
ケーデンスのSystemCは実はどこかのOEMらしい。イノテックの営業から聞いた。
じゃ会場であいましょう


214 :774ワット発電中さん:04/10/15 02:37:11 ID:+3FVr1dw
>>213
#?

215 :774ワット発電中さん:04/10/15 11:47:21 ID:buJFzFHu
CadenceのSystemCのカーネルはCoWareのものだと思ったが・・・
CoWareの環境で作ったモデルは、結果を含め完全互換という意味らしい。

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





217 :774ワット発電中さん:04/10/16 12:18:29 ID:n7KyBwjV
ごめん
Coware協賛していないだけで、展示はしてるようだ


218 :774ワット発電中さん:04/10/16 20:06:03 ID:U9+YQhph
個人的な見解だが、SystemVerilogのように過去のレガシーに留まって
いる限り、上位設計の発展は当分来ないような気がするな。SoCなんかは
これからHWよりSWの開発の方が重要になってくるだろうから、SW開発の
Platformをいかに早く開発するかが、死活問題のような気がする。
その戦略をどのEDAベンダーが採用して、提案できるだろうかだろうな。

219 :774ワット発電中さん:04/10/16 20:49:44 ID:vBrTNCuY
>>216
>SW開発のPlatformをいかに早く開発するかが、死活問題のような気がする。
>その戦略をどのEDAベンダーが採用して、提案できるだろうかだろうな。

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

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


221 :774ワット発電中さん:04/10/26 05:46:54 ID:Un1X/tb+
>>220
単に output としてしか使ってないんから最適化されたんじゃないの?

222 :初心者:04/10/26 17:36:21 ID:/oKFF0XV
>>221
ありがとうございます。
.readでそのポートを読んではいるんですけど、これではinputとして使っていないということでしょうか?
すみません、よくわかっていないので変な質問かもしれません。

223 :774ワット発電中さん:04/10/27 03:40:45 ID:MUvDFuNU
SystemC は Verilogへのトランスレータをフリーで用意すれば裾野がぐーんと広がるんだけど・・・

224 :774ワット発電中さん:04/10/27 12:40:50 ID:TI7xmuI5
しかし相変わらず抽象度を上げずにSystemCを利用している連中が
いるんだねぇ・・・やっぱり日本はアメリカに追い越されちゃうのね。

225 :774ワット発電中さん:04/10/27 16:04:02 ID:SqYhHjy/
>>224
お前のような糞ソフト屋はツールに頼らずにまともな回路の設計なんてできないだろうしな!

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

226 :774ワット発電中さん:04/10/27 21:57:46 ID:8DGzE8Qn
>>225
どうしたの?図星?w

227 :774ワット発電中さん:04/10/27 22:14:03 ID:ydxwNVb+
既に上の方で結論が出てる問題を蒸し返して煽りを入れるのは何故か?

228 :774ワット発電中さん:04/10/28 01:03:38 ID:zh7l+R25
>>227
すいません。純粋に日本の現状を憂いてしまい、つい・・・

229 :774ワット発電中さん:04/10/28 11:41:09 ID:2YS53A6w
>223
フリーで用意した奴には何の見返りもないじゃん
利用する側がありがたや、ありがたや・・ってただ乗りして
金儲けるだけ


230 :774ワット発電中さん:04/10/28 23:38:01 ID:bKHci/Am
抽象度を上げればゲート数が増えるからFPGA屋はもうかるじゃん。

231 :774ワット発電中さん:04/10/28 23:54:57 ID:Q3wCWLIP
製品規格を満たしていて、そこそこの性能がでて、それで終わりが許されるのなら
抽象度を上げまくればいい。

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

232 :774ワット発電中さん:04/10/29 00:13:02 ID:H3j+dcMx
>>224
抽象度を上げるのは結構だが切り分けたHW部分はどうやって落とし込むの?
人手でやるとしたらあまりスマートじゃないよね。

233 :774ワット発電中さん:04/10/29 09:30:42 ID:rPCOuo0N
>230
SystemC屋ってFPGA屋じゃねぇだろ?

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


234 :774ワット発電中さん:04/10/29 10:34:39 ID:Vi21VUCl
抽象度を上げてなにをするかがやっぱり分かってないんだね。
おもちゃの高位合成に群がるアホな日本人が多いわけだ。
もう、日本ダメポ。

235 :774ワット発電中さん:04/10/29 13:57:03 ID:oF+FwAlY
>抽象度を上げてなにをするかがやっぱり分かってないんだね。

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

236 :774ワット発電中さん:04/10/29 15:28:37 ID:Vi21VUCl
システム全体をSWで動作できる実行モジュールあったら
何ができるか、考えてみろよ。それくらい頭使え。

237 :774ワット発電中さん:04/10/29 19:17:51 ID:h9k+TQUV
>>234
違う

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

238 :774ワット発電中さん:04/10/29 19:21:09 ID:6yUv+seQ
だいたい前処理+CPUコアで事足りてしまったりするしな。
結局「おもしれぇ!」で飛びつけるだけのカネと時間とフットワーク
の良さを兼ね備えている所はそうそうない。
何事もそうだけど右見て左見てみんな使っていて、しかも
無料ないし無料同然で手に入らないと使わない/使えない

そんなもんさ


239 :774ワット発電中さん:04/10/29 21:26:49 ID:3jAZ0yBr
SystemC自体もう終わってるのに何を盛り上がってるの?

240 :774ワット発電中さん:04/10/29 21:59:13 ID:IrtX7rLR
何かマイナス意見ばっかだね。。。学生だとただで使えたりするので
多分居ると思うんだけど動作合成ツールつかってる人います?
Synopsys社のCSSとか。どれくらいの規模の回路で使ってるとか
FPGAで動作できたとかの詳細まで教えてくれたら嬉しいです。
ここは見てないかなー?

241 :774ワット発電中さん:04/10/29 23:00:05 ID:3eod0UAt
>>237
何の知識もないのが、バレバレ・・・ちゃんと反論するならすれば?

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

243 :774ワット発電中さん:04/10/30 00:29:29 ID:LybqSLSP
ここプロの人ばっかなの?俺学校で勉強してるんだけど
正直こんな業界で定年まで食える自身もないしプロはすげーなー
とか思ったりしてます。でも若いうちは冒険してみたかったりもする今日この頃

244 :774ワット発電中さん:04/10/30 01:46:36 ID:Xl2p5ofF
>>243
この分野もしかしたら一番動きが早い業界かもしれないね。ここで議論されてる
言語も設計手法もインプリやら、いろんな要素でやらなきゃならないこと変わるから
ねぇ。ある意味楽しいといえるかもしれないけど・・・

245 :774ワット発電中さん:04/10/31 07:53:44 ID:7Kf3Lc8V
>>243
ここにはプロは来ないと思う。
お金とっている人=プロだから。
只で情報は出さない。
いえることはSystemCが扱う領域は半導体設計のせいぜい2%以下って事。
大半の普通のハード設計者には関係のない技術だから、知識として知っていればそれでいいんじゃない。
ハード設計目指すなら、HDLが頂点だからね。
SystemCはその上のシステムLSIの領域でほとんどのハード設計と言われる人が関係のないエリアです。





246 :774ワット発電中さん:04/11/01 22:37:40 ID:Z3/MniIh
>>243
今学生ならHDL主体の仕事だけには就職しないようにね。

247 :774ワット発電中さん:04/11/03 13:18:56 ID:zDRJLb5Y
>>243
規模という意味でソフトは10年先行ってるので、ソフト開発が
直面している問題を参考に設計を勉強するのも良いんでねーか?
だが、食えるかどうかは別の才能。冒険は死なない程度で。

248 :774ワット発電中さん:04/11/03 16:15:02 ID:AR3bLCIe
>>246
それは言えてるな。
自分の専門分野の開発でASIC起こすのにどうしてもHDLと付き合う羽目(テストデータ用意したりね)になったっていうならいいけど。
分野に関係なくASIC起こすことがメインの仕事っていうのはたんなる下請けにすぎんからな。

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

249 :774ワット発電中さん:04/11/03 17:02:22 ID:eVFEBgTy
>>245以外はみんなプロという罠だったりして。
自分はCeloxicaのDKをつかっています。
実装結果を見ながらアルゴリズムレベルの検討をするには非常に強力なツールと思います。

250 :774ワット発電中さん:04/11/04 01:48:15 ID:SAvmLsRr
>CeloxicaのDKをつかっています
どんなツールか説明してよ。
実装結果を見ながらアルゴリズムをいじりだすと収束しないように思うからね。

251 :774ワット発電中さん:04/11/04 02:07:15 ID:fGokSC8S
vhdlとかって別にロジック分からない人も組めますよね
systemcも同じく
そしたら簡単に記述できそうなsystemcが効率よさそうに思うんですがそんなことないんですかね?

252 :774ワット発電中さん:04/11/04 10:39:15 ID:22YR4yEp
>250
DKはCベース(C++ベースじゃない)で、VHDLかVerilog
のコードを吐く。
Cの1行が1クロックで処理されるように生成する。
複数行を同時実行させるにはpar{}でくくる。
par{}でくくられた中で一番遅いものが終了してから
par{}ブロックの次の行に行く。
関数コールとかは、基本的にGo-Done式で生成される。

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

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


253 :774ワット発電中さん:04/11/04 20:27:53 ID:Rqq+9JOh
生成されたHDLは随分酷い物になってることが容易に想像出来るなぁ

254 :774ワット発電中さん:04/11/04 21:54:14 ID:D6YH+8GT
バージョンUPとともにきれいな方向には向かってはいるようです。
(昔HDLから生成されたゲートも醜かった。。。)
も一つメリットとしては、醜くてもHDL製造という観点での品質がそろうという点かいな。
もちろん職人さんのHDLも必要ではあるが、生産が追いつかない。

255 :774ワット発電中さん:04/11/04 22:08:57 ID:a774LwRE
一つの大きな問題は、CのソースをリコンパイルするとHDLが大幅に変わってしまうから
結局HDLを触ることが出来ないと言うジレンマ。

256 :774ワット発電中さん:04/11/05 01:39:24 ID:Qo4LpIw1
うちではDKで生成したHDLをSimplifyにかけているけど、出てくるNetlistはけっこうまともだよ。
分野によっては、アルゴリズムを変えずにHDLを手直しして改善する分よりも、アルゴリズムの改良による
効率改善のほうが勝っていることもあるかもね。

257 :774ワット発電中さん:04/11/05 02:03:00 ID:X004nxxf
>>256
それはsimplifyが優秀なのだとおもわれ

258 :774ワット発電中さん:04/11/05 02:08:22 ID:Qo4LpIw1
Cベースの記述でまともなNetlistが出てくるのならなんでもいいかと。
DK+Simplify+Amplifyはけっこう気に入っている組み合わせです。

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

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

261 :774ワット発電中さん:04/11/05 15:25:23 ID:YM5nVMjE
今調べてみてわかったHandel-Cなのね。
名称変更したの?

262 :774ワット発電中さん:04/11/05 16:53:59 ID:6+kZlNNc
Cを拡張してハード向きにした言語の名前がHandel−Cで、
統合環境のソフトウェア一式がDKって感じかな?



263 :774ワット発電中さん:04/11/06 14:02:34 ID:bKZHMgS8
>>255
その点でC合成の方がプレッシャーは高いっすね(アルミ変更とか超能力が必要)
>>259
非同期物は難しいですね
マルチクロックは最近なんとかなりつつある?


264 :774ワット発電中さん:04/11/06 14:11:07 ID:Qx83pKXP
HDLにしても、一度回路が確定した後から見つかったバグで良い幅に回路が
かわって大変なことがある・・・。

265 :774ワット発電中さん:04/11/06 17:37:32 ID:QYsU+jzW
マルチクロックは最近なんとかなりつつある?

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


266 :774ワット発電中さん:04/11/07 23:22:48 ID:nckuUAMg
ユーザの方DKのどのバージョン使ってるの?

267 :774ワット発電中さん:04/11/09 23:05:34 ID:CaasmtpO
そのためのデュアルポートRAMなのでは?
それ以外の解決策って・・・

268 :774ワット発電中さん:04/11/10 00:32:59 ID:Ua7ewUzW
ふつうにハンドシェイク。
DKはそういう回路も生成します。

269 :774ワット発電中さん:04/11/11 03:10:23 ID:7fRSB0GW
DK2.0って使える?3.0出てるみたいだけど

270 :774ワット発電中さん:04/11/11 20:50:33 ID:n+TMFxd/
漏れはDK2しか使ったことないから3.0はわからん。


271 :774ワット発電中さん:04/11/19 16:02:35 ID:5FD8nvz5
ここの住人にくらべたら低レベルなので今まで書き込みしなかったけど
レスが付かないので書き込みしてみるテスト。

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

272 :774ワット発電中さん:04/11/19 16:08:23 ID:5FD8nvz5
訂正。他多々変なところはあるけど見逃してくだちい
>SystemCはC++をつかっていて、抽象的な表現もできるし、特にビヘイビアモデル
>については、他のCベースの言語と比べて便利なのではないか?

273 :774ワット発電中さん:04/11/19 17:19:47 ID:cuh3QHjB
>>271
HDL の、そもそもの存在意義に議論の価値があるかどうか


274 :774ワット発電中さん:04/11/19 18:56:02 ID:Wzh0ygMv
>>271
その教授に
"お前はC++の機能をうまく使えて、かつ、実際の開発に携わった経験があるのか?"
と聞きたいのだが。。。

275 :774ワット発電中さん:04/11/19 21:11:00 ID:qoJW92cN
最後までビヘイビアで済ませてた部分が開発のネックになるんじゃね?

276 :774ワット発電中さん:04/11/19 21:21:47 ID:cuh3QHjB
つまるところ合成ツールのでき次第でセンセイ方の能書きは木の葉のように揺れ・・・

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

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



278 :277:04/11/19 23:59:11 ID:ckL+skoN
>それから動作合成可能なモデルまでのコーディングにビヘイビアで使った記述も使えるわけだし
ここはなかなかむずかしい

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

280 :774ワット発電中さん:04/11/21 01:44:07 ID:+xo3SFHB
抽象度を上げたときに何が難しいかって、モジュールの動作記述
ではなくて、APIでのモジュール間のコミュニケーション記述だって、
知ってる人はどれくらいいるのだろうか・・・

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

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

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



284 :774ワット発電中さん:04/11/21 10:24:43 ID:JfNgRyrG
>設計言語も同じで、今後普及する言語が何かをよく見極めないと又痛い目にあう。
>漏れは完全にあきらめて、皆が使うものを文句言わずに積極的に使いこなす。

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

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

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

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

286 :774ワット発電中さん:04/11/21 10:44:25 ID:+xo3SFHB
>ここが標準化させれば、抽象度高くても共通 (誤

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

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


287 :774ワット発電中さん:04/11/21 11:10:45 ID:k70hS0sG
IEEEといっても、P966のような運命を辿ったものもあったわけで・・・
P1666とP1800の戦いか。DCがSystemVerilogになってしまった
のがちょいとひっかかる気がするけども

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

288 :774ワット発電中さん:04/11/21 11:13:27 ID:HbZhRAE7
>>273
たぶん解らなくなるから漏れが訂正。
HDLの議論としてSystemCを眺めると色々文句でるのは解ります。
ハードウエア記述言語はHDLって言いますが、Verilog-HDLやVHDLさらにSystemVerilogの事をいいます。

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

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

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


289 :774ワット発電中さん:04/11/21 12:12:32 ID:tcVz8UMZ
わかんないなぁ・。。どうなるか。systemc自体は消えていくような予感が
するけどさ。ソフト寄りで使用するC(C++)とハードよりのC(C++)とsystemVerilog
の収斂するような気がする、しばらくはだけど。俺自体はどれが良いとかじゃ
なくて、業界の向きとか仕事として考えるとだけどさ。

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

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


290 :774ワット発電中さん:04/11/21 17:12:26 ID:A5K9qIYJ
間違いなくSystemCは消えるな。いいだしっぺが投げ出して言語を一体誰が推進するのさ。

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

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

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

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

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

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

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

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

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

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

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

294 :774ワット発電中さん:04/11/21 18:29:59 ID:A5K9qIYJ
どうでもいいけど、いちいち上げてるけどなんで?
そんなに発言を第三者に誇示したいの?それとも下げ方知らない?

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

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

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

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

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

296 :774ワット発電中さん:04/11/21 18:59:17 ID:ArV8pPLc
シノプシスに手を引かれてなければもう少し説得力あるんだがな

というわけでsage


297 :774ワット発電中さん:04/11/21 18:59:48 ID:aoZZp4Xo
上げてまでやる見苦しい喧嘩をこれ以上続けることがないように。

298 :774ワット発電中さん:04/11/21 19:08:13 ID:n78KSPzh
>>296
それは必ずしも研究者の本意ではなかったんじゃないか? 上客・・・いや何でもない

299 :774ワット発電中さん:04/11/21 19:10:37 ID:ArV8pPLc
そんな妄想していても仕方ないよ。
結果的にシノプシスは手を引いてSystemVerilogに
回った。IEEE

300 :774ワット発電中さん:04/11/21 19:12:06 ID:A5K9qIYJ
>>295,298 ID:n78KSPzh
アホかお前。それが上げるに値する内容か?
上げるとお前のようなカスが集まってくるから上げるなつってんだよ。


301 :299:04/11/21 19:12:12 ID:ArV8pPLc
ありゃ・・途中で書き込んでしまった。
ところで、IEEE P1800はなの?


302 :774ワット発電中さん:04/11/21 19:16:14 ID:n78KSPzh
>>300
消えろといったはず
情報を提供するでなし、人の話とかみ合うでなし、空疎なスクロールは迷惑だ

303 :774ワット発電中さん:04/11/21 19:20:45 ID:A5K9qIYJ
>>302

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

304 :774ワット発電中さん:04/11/21 19:27:10 ID:aoZZp4Xo
いつまでやるんですか?

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

305 :774ワット発電中さん:04/11/21 19:30:11 ID:A5K9qIYJ
>>304
それはいきなり喧嘩しかけてきたID:n78KSPzhに言ってくださいな。

306 :774ワット発電中さん:04/11/21 19:31:55 ID:aoZZp4Xo
喧嘩両成敗

307 :774ワット発電中さん:04/11/21 19:36:54 ID:JfNgRyrG
>A5K9qIYJ
まあ落ちけつ。

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

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

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

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

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

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

308 :774ワット発電中さん:04/11/21 19:40:49 ID:JfNgRyrG
ちなみに「ボードに乗ってるLSIをワンチップ化しました」的なASIC開発を
軽んずるつもりは毛頭ない。市場の要求に応じて設計・開発することは
大事な仕事と思うから。

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

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

310 :774ワット発電中さん:04/11/21 23:39:00 ID:iKxbLH5A
進化型プロトタイピングと廃棄型プロトタイピングから説明しないと、
バリバリのHDL屋さんにはESLやSLDは理解しにくい概念だと思うから、
説明はこれ以上はしないほうが無難。

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


311 :774ワット発電中さん:04/11/22 00:05:09 ID:/WAUJ1SH
>明日の技術を捨てたわけじゃないと思うよ。

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

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


312 :774ワット発電中さん:04/11/22 00:11:12 ID:9YFbYvvh
充分つきあってられる話だね

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

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


314 :774ワット発電中さん:04/11/22 00:15:10 ID:9YFbYvvh
ID変えてもにじみ出るものは同じだね・・・

315 :774ワット発電中さん:04/11/22 00:21:39 ID:gnOg+2py
お前、邪魔だから死ねよ。
それとだIDは0:00になれば勝手に変わることも知らんのかアホがよ。
糞レス上げるのは止めろ。
精 神 的 カ タ ワ 学 生 よ!
食 い 扶 持 稼 げ る よ う に な っ て か ら ほ ざ け !

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


317 :774ワット発電中さん:04/11/22 00:23:43 ID:9YFbYvvh
ダメージ確認
気が済んだ

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



319 :774ワット発電中さん:04/11/22 00:39:26 ID:gnOg+2py
ID:9YFbYvvh & ID:NMW42G1f
お前ら二人いや一人か。
いつも仲良く上げてるなぁ

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

320 :774ワット発電中さん:04/11/22 00:40:06 ID:/WAUJ1SH
いくら思想的に優れていても、研究レベルでどうであろうと、
現場に理解されないもの、、実用にならないものは広く使われる
ことはないし、商売にもならない。
商売にならないものは廃れていくだけ。
それだけ。

321 :774ワット発電中さん:04/11/22 00:41:03 ID:NMW42G1f
>君、C#でプログラミングしたことある?C++に戻ることが嫌になるはずだ。
今まで聞いたことなかった。
このスレッドで、C#ってワード検索したら、結構出てくるけどみんな同一人物のような..

322 :774ワット発電中さん:04/11/22 00:41:55 ID:/WAUJ1SH
やっぱりそこでSmallTalkですよ

323 :774ワット発電中さん:04/11/22 00:48:26 ID:gnOg+2py
いやいやEiffelだろ?

324 :774ワット発電中さん:04/11/22 00:52:15 ID:/WAUJ1SH
いっそのことLISPとか、PROLOGベースも面白いかもしれんな。


325 :774ワット発電中さん:04/11/22 01:02:54 ID:gnOg+2py
ひまわり
織田信長
ってのもあるでよ

326 :774ワット発電中さん:04/11/22 12:53:30 ID:6fQX/u+s
PROLOG・・って自動的にバックトラックするシステムか
ガベージコレクションとか言われて使わなくなった回路が
燃やされたりして


327 :774ワット発電中さん:04/11/22 16:24:02 ID:Fw9o0lSH
漏れPascalが絶対いい大学で習ってたけど、社会にでて出会った事がない
ALGOLもハードには向きそう
Algol-HDLなんてありそうだなー 

328 :774ワット発電中さん:04/11/22 17:01:48 ID:dWIx89k7
>>313
C#は確かにプログラミングが楽と思うよ。でもSystemCで書いてあれば、
ベースをC++から、C#に変えても、ヘッダレベルでかなり吸収できると
思うんで、そういう言語レベルのことは、あまり気にしてない。

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

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

329 :774ワット発電中さん:04/11/22 18:28:01 ID:6fQX/u+s
シノプシスにすら見放されてしまったSystemCにこだわっても現場は
困るだけだから、次世代に期待〜♪

330 :774ワット発電中さん:04/11/22 18:36:20 ID:oAnSWxCB
開発元がなにがなんでも普及させるという強い意欲のない規格が世に支持されるはずもなし〜♪

331 :774ワット発電中さん:04/11/22 19:32:06 ID:dWIx89k7
シノプシスのメッセージをちゃんと読んだほうがいいのではないかな。

332 :774ワット発電中さん:04/11/22 19:39:55 ID:6fQX/u+s
シノプシスもケイデンスもSystemVerilogに軸足を移した

333 :774ワット発電中さん:04/11/22 19:47:13 ID:CEebaxxZ
そりゃ、一気に変わるより今使ってる環境や思想を流用出来た方が理にかなってる。

334 :774ワット発電中さん:04/11/22 19:52:53 ID:oAnSWxCB
御託並べるのはHDL設計でまともな設計をできるようになってからにしようねボクちゃん〜♪

335 :774ワット発電中さん:04/11/22 19:59:07 ID:oAnSWxCB
忍も軽電もいい機会だったと思うね。身動き取れなくなる前に抜けた。
PCBエディタ各社がオートルータ機能を声高に主張しなくなったのと同じだね。
規格の布教活動の先陣切ってたわけだから失敗したらはるかに痛手は大きいしね。

336 :774ワット発電中さん:04/11/22 20:15:58 ID:6fQX/u+s
C/C++という書き方をしていて、単にC++と言い切れてないってところもミソだよね。
現実にソフト側の記述でもCが圧倒的ということを認めざるを得なかったのだろう

337 :774ワット発電中さん:04/11/22 20:42:05 ID:9YFbYvvh
>>336
C にない ++ な書き方は推奨度が低く
C な書き方でほとんど事足りるって言いたいのかな
私はそうは思ってないけど・・・

338 :774ワット発電中さん:04/11/22 21:04:57 ID:6fQX/u+s
は?

339 :774ワット発電中さん:04/11/22 21:17:36 ID:9YFbYvvh
>>338


340 :774ワット発電中さん:04/11/22 21:34:50 ID:DjpZwQxS
×>339

341 :774ワット発電中さん:04/11/22 21:45:17 ID:uJnDIG+1
煽りあいかおとしめるかぐらいのレスしかつかねー状態かよ。
頼むから普通にコミュニケーションしてくれ。なんで喧嘩腰なんだ

342 :774ワット発電中さん:04/11/22 21:57:41 ID:DjpZwQxS
無意味にageたがるオゲレツなのがいるからだろうね

343 :774ワット発電中さん:04/11/22 22:08:56 ID:1Y3KqlHZ
>>342
それ言うとまたキチガイが噛み付いてくるぞ↓

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

344 :sage:04/11/22 22:54:39 ID:uJnDIG+1
ああ、ここもやっぱり2chなんだなぁ

345 :774ワット発電中さん:04/11/22 22:55:05 ID:uJnDIG+1
うほっ間違えた。ユルシテ

346 :774ワット発電中さん:04/11/22 22:56:08 ID:uJnDIG+1
うほっ間違えた。ユルシテ

347 :774ワット発電中さん:04/11/22 22:58:11 ID:qqs2uRKm
正直議論になっていないと思う。SystemCで設計したことない人間が
多すぎる。聞きかじりで話してる人間が多すぎるし、根本的にずれた
こと言ってるやつもいるし、レベル低すぎ。って、ここ2CHか w

348 : :04/11/22 23:43:21 ID:QPmUFXmG
2chだから

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

349 : :04/11/22 23:46:44 ID:QPmUFXmG
漏れなんか、10年も前からSystemCで配置配線やってるんだぜ

350 :774ワット発電中さん:04/11/23 00:12:19 ID:NbZKVg9M
Synopsys社のAart de Geus会長がSystemCとSystemverilogについて含蓄の
あること言っている。何故、SynopsysがSystemCを後回しにしたかが、よく
分る。実際、どういう人間がSystemCを使って、どういう目的で使っているか
ちゃんと、分ってればここ一両日のちゃらんぽらんな議論は起こらないはずだ。

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




352 :774ワット発電中さん:04/11/23 01:09:20 ID:kTJNrvAD
GNUなSystemC to Verilog/VHDLトランスレータ
でもできれば普及するんでは?


353 :774ワット発電中さん:04/11/23 02:15:58 ID:+8rPSg/0
後回しね。日進月歩のこの世界、後に回してどうする。
"後に回す"すなわち辞めたんだよ。もうちょっと表現を代えれば仕切りなおし。
次にはじめるときは全く別物になってるはずだ。
撤退といわないところは大本営発と全く同じ。企業は自社のイメージを損ねる表現はしない。

354 :774ワット発電中さん:04/11/23 09:28:18 ID:NbZKVg9M
350
>>351
まあ、そうだがな。ビジネス云々勘違いしてる連中が多すぎるからさ w

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

355 :774ワット発電中さん:04/11/23 09:30:50 ID:ONxgZolb
要するに終わったってことですな

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

357 :774ワット発電中さん:04/11/23 09:56:13 ID:mgmLr5lo
>>355
completely! 規格はね。
但し、普及しないまま 完了。そして 終了

358 :774ワット発電中さん:04/11/23 10:55:35 ID:ONxgZolb
では、SystemCの失敗に鑑みて、次の時代の設計のありようを
楽しく語ることにしませう

359 :774ワット発電中さん:04/11/23 11:04:13 ID:NbZKVg9M
シノプシスがなんだってんだろう?結構笑えるよな、冷静に見てると。
社員なのか?

360 :774ワット発電中さん:04/11/23 11:16:24 ID:ODZkJJWE
>>356
あなたシステム設計者じゃないよね?下請けHDL設計屋さんでしょ?
勘違いしてるよ、根本的に・・・で直してこいや

361 :774ワット発電中さん:04/11/23 11:42:17 ID:8kjqTnA9
356を支持する気は毛頭ないが
相手の素性なんか叩いて何になる

362 :774ワット発電中さん:04/11/23 12:02:10 ID:w81x19A6
>>320 の言う通りですね。大学の研究じゃないからさ。実用ONLYだよ。

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

スレ違いすまぬ。


364 :774ワット発電中さん:04/11/23 13:08:06 ID:8kjqTnA9
>>363
今、現にそうじゃないですか?

365 :774ワット発電中さん:04/11/23 15:26:21 ID:mfiZu4bM
漏れは逆にHandel-Cのデザインウェーブのサンプルや、ET2004
でのデモ見て「ソフト丸ごとFPGAになっちまうんだなぁ」と感慨深かった。
まるっきりシングルチップマイコン感覚でザクザク書いてる感じで
FPGAになってブロック崩しだの、3DグラフィックスがCPUレスで
グイグイ動いてるし

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

366 :289:04/11/23 15:39:19 ID:WiaTahQr
パフォーマンスはHWで複雑な動きはSW+マイコンとなる・・っていうか、
もうなっているのか?でも本職のLSI設計屋としては悩む話なんだよなぁ。

367 :774ワット発電中さん:04/11/23 16:10:03 ID:K2BJwezk
>HWなどは全てSWで置き換えられるのが可能なわけ
いやそれをいうならコストさえ考えなければソフトウェアは全て
ハードウェアに置き換え可能でしょ。

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

368 :774ワット発電中さん:04/11/23 16:19:44 ID:K2BJwezk
>あぁいう具合になるとマイコンでどこまでやらせるのか、どこまで
>ハードに押しつけるのかっていうのはその都度要求仕様やらコスト
>を睨んで決めればいいんだろうなぁとか思ってしまった。

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

369 :774ワット発電中さん:04/11/23 18:33:19 ID:4ROw4nlK
>>367
> MPEG2は......中略.......ああいう順序回路べったり

オイオイ(w

370 :774ワット発電中さん:04/11/23 18:53:50 ID:J/zdXAf3
SpecC誰か使っている人最近いますかー
SystemCはお亡くなりになったようですのでいよいよ出番です

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


371 :774ワット発電中さん:04/11/23 19:40:42 ID:xjv5+Dz6
>>370
放置プレー

372 :774ワット発電中さん:04/11/23 20:11:24 ID:SppjzzqQ
このスレを見るにつけトレードオフって言葉の大切さを思い知る。

373 :774ワット発電中さん :04/11/23 21:44:14 ID:mfiZu4bM
>CPUがマルチコアを進めていけば

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

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



375 :774ワット発電中さん:04/11/23 23:27:29 ID:OP+kBQLU


376 :774ワット発電中さん:04/11/23 23:28:11 ID:OP+kBQLU
age

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

 SystemCの最初の論文では、

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

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

 ただね、SystemC1.0では

  −サイクル精度レベル
  −レジスタ転送レベル(RTL)

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

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

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

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

 SystemCのSimulation環境、

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

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

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

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

378 :774ワット発電中さん:04/11/24 05:10:46 ID:atsT51CR
age

379 :こぴぺ、スマソ:04/11/24 08:45:26 ID:atsT51CR
 こんなんもあるよ。

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

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

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

380 :こぴぺ、スマソ:04/11/24 08:46:01 ID:atsT51CR
 ルネサスと米YXIが共同開発した拡張C言語「HY-C」,WWWサイトで公開
 http://ne.nikkeibp.co.jp/members/NMDNEWS/20041113/106427/

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

381 :774ワット発電中さん:04/11/24 11:16:40 ID:6I8yFpa/
>>377
それでは、こうしましょう
http://tmp4.2ch.net/test/read.cgi/company/1093497747/121
http://tmp4.2ch.net/test/read.cgi/company/1093497747/124

382 :774ワット発電中さん:04/11/24 13:25:21 ID:KOKhz2JL
SystemCがそんなにすごいものなら、とりあえずブロック崩し専用機
でいいから、ハード/ソフト一体のシステムと見なして書いて、遊べる
ところまで持って行ってみてくれってところか。

383 :774ワット発電中さん:04/11/24 20:46:46 ID:YSvbKVnj
>   Simulation高速化のために、記述能力は犠牲にする

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

384 :774ワット発電中さん:04/11/24 20:49:09 ID:YSvbKVnj
しかも Ver.1 ではとりあえずって謙虚な姿勢だと思います

385 :774ワット発電中さん:04/11/25 05:13:59 ID:C9V2FFy2
>> 383

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

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

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

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

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

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

386 :忍死す:04/11/25 06:46:22 ID:Z/Dgz+iT
ばれたらシャーない。
SystemCから撤退します

387 :774ワット発電中さん:04/11/25 07:39:26 ID:C9V2FFy2
>>386
 もう殆ど撤退してますがな。米国でSystemC関係の人員、大量にレイオフ
してたじゃない。

388 :計伝巣:04/11/25 08:28:06 ID:dCoaL5M+
>>287
大量レイオフは恒例行事でしょ
今年もあとのこり5日だな
何人かな恒例レイオフ
SystemC関係はレイオフされてないでしょ本当は

389 :774ワット発電中さん:04/11/25 08:43:00 ID:C9V2FFy2
>>388
 もとい、SystemCの動作合成関係は確実にレイオフされてたね。動作合成
の開発人員がもういない、と米国から説明を受けた事があったよ。

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

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

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

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

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

390 :774ワット発電中さん:04/11/25 08:51:49 ID:C9V2FFy2
 このスレのタイトルには反するけど、結局SystemVerilogなのかしら。
SystemCをぶちあげた会社が、そうだというんだし。結局、論理合成は
ここのが何だかんだ言って、最終的にはいい結果出してくるしね。

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

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




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

393 :774ワット発電中さん:04/11/25 12:37:40 ID:smVLSlta
そこでHandel-Cですよ。C合成で8年も実績あるし
・・ってFPGAだけっすけどね

394 :774ワット発電中さん:04/11/25 12:44:22 ID:NRIH/+sf
やっぱりSystemCをどういう目的で使うのか分かってない人が
世の中多いんだなぁ・・・結構びっくりだ

395 :774ワット発電中さん:04/11/25 13:04:49 ID:Y27wg02+
>>392
そうまでして頭の悪さを宣伝してなんになる?

396 :774ワット発電中さん:04/11/25 15:39:33 ID:5UVLzEHw
>>394

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

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

とか プゲラ な回答を言わないですよね?

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

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

397 :774ワット発電中さん:04/11/25 15:53:24 ID:5UVLzEHw
 正確にはTLMではなく、RTLだった……、スマソ。

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

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

は論理的に真です(キッパリ)。


398 :774ワット発電中さん:04/11/25 18:05:15 ID:5UVLzEHw
 でも、SystemCでは、同一サイクルでのプロセス間のデータ通信は
RTLでないと、ほぼ記述不能。そりゃ、C++だから、OSのシステムコール
やPOSIX Thread Libraryも利用可能なわけだし、記述できないとは
言いませんが。

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

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

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

399 :774ワット発電中さん:04/11/25 20:49:44 ID:yR6rR9G4
>>396=385さん?

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

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

400 :774ワット発電中さん:04/11/25 21:41:02 ID:5UVLzEHw
>>399

 396です。

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

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

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

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

401 :774ワット発電中さん:04/11/25 21:49:44 ID:5UVLzEHw
 追記ですが、ここで言っている非同期プロセスは、完全非同期プロセス
であり、クロックを持たないプロセスです。また、ハンドシェイクも
クロックを用いないで記述されているものとしています。つまり、純粋な
ランデブーという意味です。

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

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

402 :774ワット発電中さん:04/11/25 23:00:03 ID:bqr2biP4
>>396
なんで385のようなものにSystemCを用いようとするのか、全く理解できん。
SoC設計ということで脳内反射してるとしか、思えんよな・・・ほんとお先
真っ暗だな、日本は。

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

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

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

404 :774ワット発電中さん:04/11/26 00:10:00 ID:jFG1eH0+
>>395
高卒哀れだよ高卒。

405 :774ワット発電中さん:04/11/26 00:12:32 ID:V9xSsX+m
>>403

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

406 :774ワット発電中さん:04/11/26 00:14:22 ID:V9xSsX+m
SystemC-AMSついに登場か

407 :774ワット発電中さん:04/11/26 01:19:45 ID:UZfLQbYH
>>395
意味が分からん
>そうまでして頭の悪さを宣伝してなんになる?
設計の現実の話をしてるだけでしょ
どこが頭悪いのかせつめいしてよ






408 :774ワット発電中さん:04/11/26 01:28:24 ID:jFG1eH0+
395は高卒なのでスルーしてくれ。

409 :774ワット発電中さん:04/11/26 01:48:45 ID:GzvH9dcV
検証はまず論理設計ありきであり検証だけが単体で存在するわけではないからね。

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

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

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


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

411 :774ワット発電中さん:04/11/26 11:28:45 ID:jtufxuvb
>>403
まず、クロックの概念から離れなさい・・・話はそれからだ

412 :774ワット発電中さん:04/11/26 13:09:04 ID:ZK5MvGI6
>>411
 既に離れた内容も記載しています。CCSとかCSPを知らないのですか?

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

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

  は っ き り 言 っ て、 ド ア ホ

です。

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

413 :774ワット発電中さん:04/11/26 19:35:30 ID:udSKr1KG
>>400
逐次制御で書いてたのをパイプライン化って、そんなに乖離してましたっけ?
俺的にはルーチンワークって気がしてますけど・・・

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

414 :774ワット発電中さん:04/11/26 20:00:12 ID:ZK5MvGI6
>>413

 396です。

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

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

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

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

415 :774ワット発電中さん:04/11/26 20:21:40 ID:udSKr1KG
>>414
俺、パイプラインはマルチプロセスかサブモジュールで書いてますけど・・・
逆にシングルプロセスと言われて面食らってます

416 :774ワット発電中さん:04/11/26 20:38:38 ID:ZK5MvGI6
>>415
 だって、そんな事したら、Simulationが遅くなっちゃうじゃない
ですか。別に合成を目的としているわけではないのですから、
不自然じゃない範囲でプロセス数を最小化して、システムは記述
しないと、でしょ?

417 :774ワット発電中さん:04/11/26 21:10:49 ID:udSKr1KG
>>416
だから、それまでに潰せるバグは潰しておくわけでしょ
突き詰めるならパイプライン化のしくじりだけに集中できるように

418 :774ワット発電中さん:04/11/26 21:12:50 ID:udSKr1KG
s/わけでしょ/んじゃないんですかね/

419 :774ワット発電中さん:04/11/26 23:41:16 ID:c8dQr8/d
>>416
そんな極端に遅くなります?システム全体の検証としてみて、RTLより
はるかに速いという印象なんだけど。いや、実測してません。もう、あたり
まえに使っているので・・・
合成を目的としているわけではない、ということからインプリメンテーションと
ある程度独立しているmind setを持っているということで、まともな議論の
できる方とお見受けしての質問です。

420 :774ワット発電中さん:04/11/26 23:45:39 ID:873CdzPQ
>>412
Ptolemyが出てきてる時点でどうなのかな?
MatLabやSystemCをシステム設計と勘違いしてるんじゃないかと
勘違いされちゃうよね。2,3年前と違って今の現状を見ないとね。
ここ2、3ヶ月のNE Onlineの記事を読むことをお勧めします。

421 :774ワット発電中さん:04/11/26 23:47:03 ID:873CdzPQ
>>420
>MatLabやSystemCをシステム設計
↑ 誤

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

スマソ

422 :774ワット発電中さん:04/11/27 00:09:37 ID:lPZ2BuSw
うーむ、やはりSystemCは研究職向けの言語なのかなぁ・・・
専門用語の羅列で満足しているような。まぁ、でもそれが
ユーザー数が少ないということを表しているとも言える
けどさ。

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



423 :774ワット発電中さん:04/11/27 00:25:30 ID:Xjzjc/5b
いや、専門用語出してるのは、研究所の人間だと思う。それは、みな内々
感じている。SystemC自体の問題ではないと思うよ。
知ってる人は知ってるが、日本では一部システムベンダーでは
非常にうまく運用に乗っている。ある時点で、一切表に事例を出さなく
なった。自分達が敷居が高いところを乗り越え、うまくフローに乗った
ところを追従されたくないからだと思う。ここの議論の傾向は、そういう
ベンダーにとっては願ったりかなったりというわけだ。
ただ、それらシステムベンダーの動向に気づいた半導体ベンダーの動向が
ここ2,3ヶ月の顕著な動き。

424 :774ワット発電中さん:04/11/27 01:22:38 ID:GzPY7Hr6
研究職というのはあくまでもシステム記述言語を研究してる人間のことだろ?
俺はこんな言語で自分のシステムを記述するつもりはない。

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

425 :774ワット発電中さん:04/11/27 04:25:08 ID:VXYjE4ZN
>>421
 MatlabとかSPWは、DSPの設計用ですよね? 特にSPWは携帯等特定の
アプリのライブラリが充実している、という印象ですね。使った事は
ないですが。昔は、待ち行列シミュレータのBones(綴り、間違って
たらスマソ)が携帯電話の基地局設計向けとか称してありましたね。

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

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

426 :774ワット発電中さん:04/11/27 04:33:40 ID:VXYjE4ZN
>>419
 すいません、私も実測したことはないです。ただ、記述量が複数プロセス
で記述するより少ないような気がしています。気のせいかも知れませんが。

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

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

427 :774ワット発電中さん:04/11/27 04:51:43 ID:VXYjE4ZN
>>423
 SystemCを使いこなしているメーカでさえ、記述能力の低さを嘆いて
いたりするのが現状なんですが。

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

   もっと、効率化せんか、ゴルァァア

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

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

428 :774ワット発電中さん:04/11/27 04:57:06 ID:VXYjE4ZN
>>416
 単一プロセスでパイプライン記述を行うって事は、SystemCの恩恵を
殆ど必要としない、という事に気付いていないのですか? この記述
方法だと、Cで直接記述した方が記述量も少なくてすみますし、シミュ
レーション速度も圧倒的に早いです。

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

429 :774ワット発電中さん:04/11/27 06:10:12 ID:LbhldsN2
>また、合成のことを言うと、「わかってないなあ、この高卒君」となり
合成前提じゃないとか上でも言ってる奴いるが、それは単なるバカ。
高抽象度設計だけでいいならそれこそピュアC++でもMatlabでも使ってりゃいい。
システム記述言語だろうがHDLだろうが回路に落とせてなんぼ。


430 :774ワット発電中さん:04/11/27 06:14:08 ID:o0D8AZae
HDLが何のためにあるのかを全否定してるわけだが。>また、合成のことを言うと、「わかってないなあ、この高卒君」

431 :774ワット発電中さん:04/11/27 09:32:43 ID:4uGS0/M0
>>429
MatlabやピュアC++で、例えばARM9 + AMBAで携帯系のアプリ用の
システム、embedded SW込みのシステム記述してくれや。ちなみに
画処理が多くて、busがcriticalなんで最適なバス構成も探索したいんで、
どうやってMatlabやピュアC++で効率よく、最適化できるかもよろしく。


432 :774ワット発電中さん:04/11/27 10:09:40 ID:JP9TQMn1
>431
まず藻前がSystemCで書いて、実際のモノまで
落とし込んでみてくれ。言い出しっぺの法則だ。さぁどうぞ。

433 :774ワット発電中さん:04/11/27 11:17:34 ID:OZTp9BGP
詳細きぼんぬ
「SystemCの勉強を始めて5カ月でJPEGデコーダを設計完了」,ロームが発表
ttp://ne.nikkeibp.co.jp/members/NMDNEWS/20041127/106592/
関係者いたら

434 :774ワット発電中さん:04/11/27 11:30:28 ID:iMUE1O/D
>>420
なにか知っているようだけど。
先ず登録したら、すごい記事が出てきた
信じられないが世の中結構すすんでるようだな


435 :774ワット発電中さん:04/11/27 13:02:55 ID:VXYjE4ZN
>>432
 だから、>>385 の指摘とおり、SystemCじゃそう簡単には書けないん
だって。

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

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

436 :774ワット発電中さん:04/11/27 14:56:32 ID:pNNZqEMN
>>433
100KSTEP/秒てSystemCの中で使われる新しい単位?

437 :774ワット発電中さん:04/11/27 17:05:30 ID:BZIvrWI7
>>431
Verilogでハード記述して、それができれば合成して、
実機上でアルゴリズムの完成したソフトウェアを動作させる。
全部SystemCで記述して画像処理???
お前の画処理というのは一枚表示して終わりか?笑わせんな!アホ!

438 :774ワット発電中さん:04/11/27 22:56:43 ID:JP9TQMn1
DMAコントローラごときを記述するのに一ヶ月もかかるようではなぁ・・


439 :774ワット発電中さん:04/11/28 06:22:47 ID:2LEs8LOY
>>438
 それが、SystemCの欠点だよ。やはり、ハードを適切に記述するための
計算モデルというのがSystemCには備わっていない、という事なのでしょう。

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

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

440 :774ワット発電中さん:04/11/28 08:09:37 ID:H+gSzsXb
> 「合成は捨てる、期待しない」

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

441 :774ワット発電中さん:04/11/28 09:14:20 ID:+ibWWL7E
>>439
> 「合成は捨てる、期待しない」

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

442 :774ワット発電中さん:04/11/28 09:32:31 ID:aNFxEFgw
だめだ、こりゃ・・・びっくりするぐらいレベルが低い

443 :774ワット発電中さん:04/11/28 09:45:33 ID:2LEs8LOY
>>440 >>441 >>442
 バリバリ設計者ですが、何か? こちらは、RTL設計をカリカリに
チューニングして行っているんでね。それに勝て、とまでは言わんが
それにしても、SystemC合成ツールは酷すぎるのだよ、結果も、記述
制約も。で、記述可能な範囲の拡張を要求しても、出来ないの一点
張り。マジで、無理だって。

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

444 :774ワット発電中さん:04/11/28 09:53:28 ID:2LEs8LOY
>>440 >>441 >>442
 おまいら、ちっとは、こういうのも勉強してみろよ。

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

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

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

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

445 :774ワット発電中さん:04/11/28 09:53:46 ID:SXLxIdWv
SystemCは、SWを生かすための言語なのでは、これでHW設計するのは
お門違いなような気がする。

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

447 :774ワット発電中さん:04/11/28 09:58:42 ID:qbqj3AaM
>>443
それはサポート範囲外です。
マニュアルを読んでから質問してください。

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


448 :774ワット発電中さん:04/11/28 10:07:45 ID:2LEs8LOY
>>445
 その通りです。でも、ハード・ソフト一体のシステムを記述するとき
やはり、ハードのモデル化も必要となる。で、このモデル化のハードル
が異常に高い、というのは事実だよね。だから、CoWareなんかが、
単なるモデル化支援ツールや、バスアクセスAPI作成受注で、金儲け出来
たりすんだよね。

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

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

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

449 :774ワット発電中さん:04/11/28 10:15:25 ID:2LEs8LOY
>>446
 SystemC普及? ある程度はしてるんじゃない、「合成の事は度外視、
無視」 という前提で。NEONLINEの記事によれば、性能解析くらいには
何とか使えてるみたいだし。

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

450 :774ワット発電中さん:04/11/28 10:29:54 ID:dgMROn0Y
>>2LEs8LOY
よく調べた 偉い
NE ONLINE全部読んだようだな。
ついでに、www.ertl.jp
も読むこと推奨
半島系企業と提携するような売国メーカは4様効果もあって売り上げどうなった?



451 :774ワット発電中さん:04/11/28 13:00:41 ID:2LEs8LOY
>>450
 ああ、ここね。動作合成専門とかいいながら、プゲラ な

  お 前、 完 璧 に 素 人 だ ろ!

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

452 :774ワット発電中さん:04/11/28 13:10:12 ID:2LEs8LOY
>>450
 もしかして、
  http://www.ertl.jp/~honda/codesign/
を見ろって事? それともeXCiteの事を指しているの?

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

453 :774ワット発電中さん:04/11/28 14:09:05 ID:E5/B68+O
TOPPERSプロジェクトにたどりついた

454 :774ワット発電中さん:04/11/28 15:34:33 ID:H+gSzsXb
これって低質な自作自演なのか?
もしかして本人だけ気付いてない?

455 :774ワット発電中さん:04/11/28 15:44:42 ID:2LEs8LOY
>>450
 TOPPERSを指し示したかったのか? 確か、ここって、コデザインの研究も
行ってたよね、SpecCを使って。それを宣伝したかったの? 一体どれ?

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

456 :774ワット発電中さん:04/11/28 15:51:09 ID:TYwLDJNv
口だけ達者で行動が伴わない =>SystemC

457 :774ワット発電中さん:04/11/28 15:58:11 ID:H+gSzsXb
この同じIDの痛い人をどう扱えばいいのか?

458 :774ワット発電中さん:04/11/28 17:06:45 ID:2LEs8LOY
>>457
 つまり、総合すると、SystemCもSpecCもダメダメってこった。それに
納得すりゃ、イイんじゃねぇーの。痛い目見る前に、下手な投資をしな
くて済んで良かったじゃん。

459 :774ワット発電中さん:04/11/28 23:47:45 ID:E5/B68+O
分からないな
ここの話
SoCにCPU入れるからそんなことになるわけで、入れなきゃいいじゃん
何で全部ハードで設計しないのかな
分かってきたのは無理やりARMを使うことを考えている人たちがいるって事
ハードで全部できるからSystemVerilogがいい
ARMのコアを広める為の仕組みでしょ。
反論してください。
どうしてもSWでやらないと気がすまない人たち

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

 さて、何故でしょう?

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

461 :774ワット発電中さん:04/11/29 07:24:32 ID:6S7EIoIp
痛すぎる馬鹿が張り付いてるある意味凄いスレだね。(w

462 :774ワット発電中さん:04/11/29 07:36:57 ID:383QmPFm
>>459
なかなか斬新な意見というか、2ch特有の陰謀説とかが好きなタイプなのかなvv。


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

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

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


463 :462:04/11/29 07:39:57 ID:383QmPFm
続き、

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

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

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

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

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

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

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


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


465 :774ワット発電中さん:04/11/29 08:56:50 ID:YHRaEfYa
一方SystemCが合成を無視した糞言語なのは周知の事実として、
でも実際の動作速度の速さ”だけ”は超魅力的。

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


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

467 :774ワット発電中さん:04/11/29 10:18:26 ID:YHRaEfYa
製品サイクルが短いならなおのことDMAコントローラ
ごとき作るのに一ヶ月もかかるようでは問題では?
現実のデバイスはもっと複雑怪奇でしょ?
結局のところ、モデリングして検討するだけのものにしては
複雑すぎるし、実際に実チップへの落とし込みまでやるもの
としてはあまりに貧弱すぎる

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

468 :774ワット発電中さん:04/11/29 12:29:18 ID:Iu7Vqo4f
>>467
 そうなんだが、米国の言うプラットフォームベース設計とやらを
前提とすると、DMACやらBusアクセスAPIやらは一旦作りこんじまえば
再利用できるって寸法。

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

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

469 :774ワット発電中さん:04/11/29 13:13:05 ID:YHRaEfYa
前提とすると、DMACやらBusアクセスAPIやらは一旦作りこんじまえば
再利用できるって寸法。

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

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

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


470 :774ワット発電中さん:04/11/29 13:49:56 ID:Iu7Vqo4f
>>469
 鋭いですね。

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

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

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

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

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

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

471 :774ワット発電中さん:04/11/29 13:59:32 ID:Iu7Vqo4f
 そういえば、OSCI(Open SystemC Initiative)の偉いさんが、システム
レベルの設計に関しては、

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

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

 まとめ:
  1.SystemCを用いると設計フェーズが1つ増えます。

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

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

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

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

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

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

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

473 :774ワット発電中さん:04/11/29 18:10:22 ID:Iu7Vqo4f
>>472
> このProprietyなlocal busをアプリによってパアメトリックに自在に
> 再構成できるの技術が既に存在するんだね。しかもこの部分に関しては、
> RTL生成が可能。

 ソース、きぼんぬ。

474 :774ワット発電中さん:04/11/29 18:52:42 ID:Qdx1/ixC
>>473
Openにされてないのです。Local busをapplication毎に作成するのが
大変なので、どうにかしてくれと、主要ベンダーにそれぞれコンタクト
すれば、そのうち情報にあたるでしょう。


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

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

476 :774ワット発電中さん:04/11/29 21:23:13 ID:O7xvdggC
結論づけたりまとめたりするのは良いんだけど、みんなほぼ同意見(?)みたいな

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

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

477 :774ワット発電中さん:04/11/29 22:17:25 ID:JaAse83f
ConvergenSCについて語って欲しい。宜しく
http://www.coware.co.jp/products/convergensc.pdf

478 :774ワット発電中さん:04/11/29 23:42:43 ID:0kwx4DUf
漏れはForteのCynthesizer使っている人に感想を聞きたいっす。


479 :774ワット発電中さん:04/11/29 23:56:13 ID:YHRaEfYa
それとDK出してるceloxicaからSystemCの動作合成ツールがでたのは皆しって
るんでしょーか。

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



480 :774ワット発電中さん:04/11/30 00:44:27 ID:RtEzWfvH
>それとDK出してるceloxicaからSystemCの動作合成ツールがでたのは皆しって
>るんでしょーか。使った事があるツールやその感想とかもよければ書き込んで欲しいです。
使ったことがあるならお前がインプレッションを書けよ。
それとも指くわえて高見の見物決め込んでる糞学生か?

481 :774ワット発電中さん:04/11/30 02:02:33 ID:6ozBJLEq
>>475
>ちなみに、スプリット・トランザクションとか、クロスバ的な構成、
>これ位までならパラメトリックに指定Okayでしょうか?

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

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

482 :774ワット発電中さん:04/11/30 05:26:38 ID:iW+D6jto
>>478
 >>447 がその回答です。

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

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

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

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

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

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

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

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

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

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

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

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

483 :774ワット発電中さん:04/11/30 06:12:37 ID:ayTBsGBn
SystemCじゃないけどMentorGraphicsのC合成ツールはど〜なんでしょうね。

484 :774ワット発電中さん:04/11/30 06:25:34 ID:iW+D6jto
>>483
 以前は相当酷かったのですが、結構頑張ってるみたいで、それなりですね。
ただ、パイプライン最適化が弱いかな、という印象です。C合成ツールとして
はYXIのeXCite Basic/Pro の方が優れているようですね。

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

485 :774ワット発電中さん:04/11/30 07:46:16 ID:cq2DM3w+
>>477
ここにくわしく
http://ne.nikkeibp.co.jp/members/NEWS/20041130/106618/


486 :774ワット発電中さん:04/11/30 08:51:59 ID:USg+CEjI
これも結局、SystemCで、コンパイルできるようVerilog記述を置き換えに
よって変換しているみたいです
http://www.cadence.co.jp/news/h16-6-8.html

487 :774ワット発電中さん:04/11/30 10:18:10 ID:WN7Yuy7Q
http://www.oki.com/jp/Home/JIS/New/OKI-News/2004/11/z04106.html

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

489 :774ワット発電中さん:04/11/30 15:02:47 ID:FZa1pDNT
>>488
 正しくは、実力のない2nd Tierが、売国企業が投資したCoWareの成果物で
あるARMを主体としたSystemCのライブラリを、大枚はたいてCoWareから導入
した。単にそれだけの事でしょ。

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

490 :774ワット発電中さん:04/11/30 15:05:41 ID:FZa1pDNT
>>488
 >>470>>471 をちゃんと読め!

491 :774ワット発電中さん:04/11/30 15:15:25 ID:Mc/icbJW
>>489
>心配しなくても、1st Teirは自力でSystemCの環境を既に構築済みだし、

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


492 :774ワット発電中さん:04/11/30 15:26:39 ID:rxE5YQjA
>>480
使ったことない。っつーか使ったことないから聞いてるんだけど。
DKって聞いてなんの事かわかってなかったりしてるのでほとんど
C入力のツールを実際には使ったことない人が多数なんだろーけど。

493 :774ワット発電中さん:04/11/30 15:58:03 ID:VgjN5sc2
>>491
 但し、合成がまともにサポートされる事はないと、それだけは肝に
銘じておいて下さいね。

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

 研究者は言いました。

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

 技術者

  「はあ? ……(沈黙) 」

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

494 :774ワット発電中さん:04/11/30 16:39:58 ID:9wn6BFAa
>>491
だからー。わからんかなー。3年前ならともかく
今更SystemCベンチョーしても文化的な意味しかない。
つまり奥様がカルチャーセンターに通うのと同等の意味合いしかない。
実務において役立つ確率はきわめて小さい。

495 :774ワット発電中さん:04/11/30 16:46:06 ID:mtSohh9F
ということで安心してSystemCの勉強します。

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

496 :774ワット発電中さん:04/11/30 16:48:27 ID:mtSohh9F
勉強しておいた方がいいのは
SystemCじゃなくてC++な、念のため



497 :774ワット発電中さん:04/11/30 16:51:15 ID:DGqhM3aC
>>494
下請けHDLコーディング屋さんになるよりはマシ? かな w

498 :774ワット発電中さん:04/11/30 17:01:02 ID:VgjN5sc2
>>496
C++よりは、Javaでしょ。最近ではGCJなるGNUフリーコンパイラもあるし。

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

499 :774ワット発電中さん:04/11/30 17:23:18 ID:9wn6BFAa
C++やるんじゃなくてtemplateだろ?
プログラミング言語C++読破して、その後で、Modern C++ designやらC++ Templates
やらを読みこなすと。C++ TemplatesはともかくModernの読破をハード屋に求めるのは
かなりお門違いのような気がするがな。

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

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


500 :774ワット発電中さん:04/11/30 17:27:40 ID:DGqhM3aC
>>499
>>497
>言っといてやろう。アプリ屋はSystemCなんかに手を出したりしない。

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


501 :774ワット発電中さん:04/11/30 17:41:08 ID:VgjN5sc2
>>499
 だから、C++だとPOSIXとかシステムコール使わないと、スレッドプログラ
ミングできないじゃん。その点、Javaだと条件同期が言語としてサポート
されてるからOkay!

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

502 :774ワット発電中さん:04/11/30 18:01:00 ID:Rt5IFbC1
>>488 - >>490
1st tier 2nd tier?? 何ゆえ、この二人は同じスペルミスを1st Teirの時だけするの?
しかも、この失礼な言い方は◎立特有のエリートが使い始め....
自分たちが1stだから普段侮辱している2nd tierだけ書きなれている。
ということを前提で。

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

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

503 :774ワット発電中さん:04/11/30 18:04:48 ID:Rt5IFbC1
言い忘れたけどCoWareの外人営業とマーケが3年くらい前に我社3rdtierにも来たけど。
その時のマーケ迫力あったけどSystemC思い切り否定してた
みんなくびになったのかな?
展示会でも見かけないし


504 :774ワット発電中さん:04/11/30 18:14:14 ID:VgjN5sc2
>>502
 ◎立のシステムLSI部門って、合弁会社になったんですよね。しかも、
そこのホムペに、「研究部門はありません。」 と堂々とUPしていた
ような気がしますが。そう言えば、

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

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

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

505 :774ワット発電中さん:04/11/30 18:39:02 ID:9ck/sZ1P
LogicBenchでまだやってるって実際は。

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

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



506 :774ワット発電中さん:04/11/30 18:44:17 ID:VgjN5sc2
>>505
 日本語がヘンです。裏社会版◎立スレ特有のメルヘンってヤツですか?

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


508 :774ワット発電中さん:04/11/30 19:16:05 ID:BISxb0qH
Verilogをg++でコンパイルできるよう変化するツールだけど、こんなのどう
http://verilog2cpp.sourceforge.net/

509 :774ワット発電中さん:04/11/30 19:30:17 ID:6ozBJLEq
>>508
抽象度上げないと早くならないから、速度的なメリットは無いような気がするけど
実行時ツールいらなくなるメリットはあるのかな・・・?

510 :774ワット発電中さん:04/11/30 20:47:31 ID:mtSohh9F
>508
cpp2verilogが欲しいね(笑

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

512 :774ワット発電中さん:04/11/30 21:28:33 ID:mtSohh9F
わざわざg++でコンパイルして何になるんだよ。

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

513 :774ワット発電中さん:04/11/30 22:58:59 ID:L5ahK8hY
"わざわざg++でコンパイルして何になるんだよ。"って思ってるから
"cpp2verilogが欲しいね(笑"だろ?
monitorをいちいち書かなきゃ値を確認できないようなシミュレータをg++で
作ったところでめんどくさいだけだもんな。

514 :774ワット発電中さん:04/11/30 23:41:36 ID:IRFepDnc
>>513
こだわるね
やめよ
もう

515 :774ワット発電中さん:04/12/01 00:23:13 ID:owgeIZqj
だっからぁ、実用にするようなものじゃないって
面白そうだからcpp2verilogも欲しいんだって

・・って・・そんなにマジになってたのか?
所詮sourcefogeだぞ。

516 :774ワット発電中さん:04/12/01 00:41:46 ID:2UzFjxHt
君たち間違ってるよ。
日立はそんなこといわない
Tier one, tier ryanが正しい


517 :774ワット発電中さん:04/12/01 04:47:47 ID:TwDjKFeX
>>507
 技術には自信がおありなんですね? そんな貴方がSystemCを始められると。
>>499 を参考に頑張って下さいね。

518 :支那腐死酢:04/12/01 09:42:54 ID:r3Aj2q2S
すてきだなと思ってC++を盗作しちゃいました。

519 :774ワット発電中さん:04/12/01 11:39:06 ID:TwDjKFeX
で、2.0への移行時に、SystemCの創始者である RAJESH GUPTA教授に見捨て
られたと。

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

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

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

520 :774ワット発電中さん:04/12/01 13:29:46 ID:xkbsnZBs
1.0では駄目だと言い張り、SpecCを参考に拡張しなければならない! と
主張し、且つCoWareに割と大規模な投資を行ったのが、某売国メーカ。

521 :774ワット発電中さん:04/12/01 14:36:14 ID:dUMdFcqy
某売国メーカってどこなんですか・・・なんか粘着してるようで見てて
とってもかっこ悪いです。

522 :774ワット発電中さん:04/12/01 15:09:24 ID:xkbsnZBs
ぴぃー(えー)すぅ!

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

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

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

523 :774ワット発電中さん:04/12/01 15:14:09 ID:JI/+DFYl
test

524 :スレの研究員 ◆3qjiX6plj2 :04/12/01 19:41:48 ID:NMeCUDWR
最近、速聴により頭の回転が速くなるという話を聞きますが、
多分というより、確実に、心を読み取る装置のほうが効果が挙がると思われます。

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

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

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

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

525 :774ワット発電中さん:04/12/01 21:25:53 ID:sbCC+bP4
>>522
ずっと考えてたけど意味不明

526 :774ワット発電中さん:04/12/01 21:27:47 ID:sbCC+bP4
>>522
SpecCで放置プレーの人だ

527 :774ワット発電中さん:04/12/01 21:29:16 ID:sbCC+bP4
>>521
 ATGの方が、嘆いていた。

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

528 :774ワット発電中さん:04/12/01 21:57:40 ID:KyfMrPa5
#include "systemc.h"
#include "mpi.h"
int
sc_main(int argc, char *argv[])
{
MPI::Init(argc, argv);
sc_initialize();
int rank = MPI::COMM_WORLD.Get_rank();
int size = MPI::COMM_WORLD.Get_size();
cout << "Hello World! I am " << rank << " of " << size << endl;
MPI::Finalize();
sc_start(10);
return 0;
}


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

530 :774ワット発電中さん:04/12/01 23:08:53 ID:hy+6T8I9
>>529

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


531 :774ワット発電中さん:04/12/01 23:41:04 ID:n27q4T7B
まぁ、systemcは主流になれば使うだけだな。systemcは
ソフト屋がなんとかハードウェアを設計したい願望の
現れとも言う人も居る。それはともかく、

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

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

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

532 :774ワット発電中さん:04/12/01 23:46:06 ID:n27q4T7B
systemcを使っても、使わなくても、稼いでなんぼ、画期的なLSIでナンボだかんね。
金銭あるいは技術的な貢献がなくて、「systemcでシステム設計をした!」と
言っても、そりゃ、「道具としてsystemcを使ったんだね・・・ご苦労さん」としか、
思われないよ。それで良いなら仕方がないけどな。

533 :774ワット発電中さん:04/12/01 23:49:34 ID:n27q4T7B
>>472

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

専門用語に酔っているような・・・専門用語を数えましょう!


534 :774ワット発電中さん:04/12/02 05:13:32 ID:XQeKTgEr
>>527
きっと、これではないかと。

http://bookweb.kinokuniya.co.jp/htm/4621071440.html

米国Massachusetts工科大学にて電子工学と情報工学の
博士号を取得。1996年にSynopsys社に入社し、現在は
Advanced Technology Groupの
~~        ~~          ~~
プリンシパルエンジニアとして勤務

535 :774ワット発電中さん:04/12/02 05:19:38 ID:XQeKTgEr
>>534

 ずれたあ…… orz

 ATG := Advanced Technology Group


>>533

 Proprietyなlocal bus := 独自ローカルバス

 ×パアメトリック
 〇パラメトリック

 意味は、英和辞典なりで、parametric を引いて調べて下さい。


 ユーザロジック := バスにぶら下がるモジュールの事(だと思ふ)

 SW設計プラットフォーム := 独自ローカルバスに対応したSystemC
               のシミュレーション用記述を効率良く
               構築できるプラットフォームというか
               環境(だと思ふ)

536 :774ワット発電中さん:04/12/02 09:55:22 ID:cN5Mab9j
systemcを使っても、使わなくても、稼いでなんぼ、画期的なLSIでナンボだかんね。

だよね。結局導入しました!っていうアドバルーン効果に
期待しているんじゃなくて、それでなんぼ稼げたかという
のが大事だし。
果たして投資を大幅に上回るだけの利益が得られるかどうか。

537 :774ワット発電中さん:04/12/02 09:57:46 ID:lNf5HJH+
>>532
記事読むと設計期間短くなってるからね・・・ご苦労さん以上のものがあるよ。
特に、発注側のシステムベンダーとしては。

>>535
あれだな。ATGはともかく、proprietary(proprietyじゃないぞ〜>472)や
パラメトリックぐらいの言葉、自由に使わせてほしいよな。酔ってるとか
言われたんじゃ・・・・orz


538 :774ワット発電中さん:04/12/02 15:16:25 ID:vAtqnPiA
>>537
自分の理解できない言葉を大量に使われると、

  使 え な い 研 究 者 、発 見 !

とか思っているのかね? よーわかりませんが。そんな風に思うより、
勉強が足りないと思って前進する方がずっと良いだけどね。

539 :774ワット発電中さん:04/12/02 16:18:19 ID:vAtqnPiA
そういえば、OSCI(Open SystemC Initiative)で日本人がリーダになって
推し進めていた、合成サブセットの定義、というのはどうなったんだ?

2年前、某社のSystemC合成担当の方が、

  「折角合成サブセットを定義したのに、マーケが顧客の意向を
   反映したと言って、勝手に合成サブセットを拡張しやがった。
   こんなの6割も合成出来やしない! 」

と愚痴っていたなあ。ああ、懐かしい。

540 :774ワット発電中さん:04/12/02 16:19:43 ID:vAtqnPiA
合成が期待薄だっていうのは、>>493 を読むと凄く納得出来ちゃうね☆。

541 :0SC1メンバ:04/12/02 16:51:22 ID:W2hCeAPD
合成は期待薄でもない断言できます
DC(シノプシスのデザインコンパイラ)や
シリコンコンパイラ構想の頃もそのような意見が大半でした
技術は常に進歩していますから、新興ベンダーが現れる度に技術革命は起きます
徐々にですがフォルテも使い物になるとの意見が出てきてますし、
実験的にですが高位合成を使用した成功例も出てるように聞いています。
日本のメーカでも4人位がこの分野で挑戦していますので、日本発の技術が現れないとも限りません。
夢を見ない、園児にあ、にはわかりにくいかもしれませんが、
研究職の間では高位合成の方法論も、それを利用したフィジビリティスタディも実行しています。
合成方法の議論はまだまだ続いています。
期待してください





542 :774ワット発電中さん:04/12/02 17:20:48 ID:cN5Mab9j
そういうのはブツが出来てから言わないと全く説得力
がないって。夢を議論して飯が食えるのどかな研究者
連中には現場なんてどうでもいいだろうけどね。
そのDCのシノプシスに見捨てられてはなぁ・・もう一回
土下座してでも引き込むべきじゃないの?

C++プログラマを一週間ばかり教育する程度で、
サラサラッと書いたRTLレベルでカリカリチューンした
やつの20%増し(30%でも許す?)くらいのサイズ/速度
のものが合成できる程度のものを、GPLに基づいて配布
してくれれば世の中変わると思うよ。

543 :0SC1メンバ:04/12/02 18:59:30 ID:aPgM3nLt
>>542さん
領域噛み合わないComunicationになると思いますが、一応レス付けます
現段階では配布できるものではありません、有料でEDAベンダから買ってください。
Proprietaryの物で良ければ半導体ベンダにお尋ね願います。
土下座しなくて無配布してくれるでしょう。
普及段階として多くの高位合成は既に出来上がっています。
只SystemCの言語制約逸脱しなく開発をしているのを理解いただきたい
議論はWGの中で提案として正しく伝えてください
誰かいいこと言ってましたが。
今役に立たない物を否定するの良くないと思います。
明日の設計の為の道具ですからね。
わかりますか? 
だから攻撃的にならずに期待していてくれればそれでいいです

SystemCは今設計に使用できる言語ではありません。
明日の設計の為の物ですので、残念ですが今役に立てません。
認めます。 見捨てられた技術と言いたいのですね。
これは完全に誤った認識ですが、ここで説明しても仕方ないので、
自分で何がEDA業界でhappenしてるか調べると面白いとです。
今の現場のannoyedは理解してます。

ついでに言うと、気に障ったら悪いんですけれども
私は十二分にこの夢だけで飯がたくさん食える人です
苛々するなら合成,SystemCというワードにフィルタをかけて、
今後一切関連の技術情報読まないほうが精神的に楽

544 :774ワット発電中さん:04/12/02 19:42:35 ID:vAtqnPiA
>>543
計算不能なものはどうしようもないです。EDAベンダの方にせよ、メーカの
方にせよ、結局はコンピュータシステム上で実現可能なものしか出来ない
のです。

SystemCの問題点は、現在広く行われているであろう性能解析シミュレー
ションのための記述を変更する事なく合成し、且つ玄人RTL設計者が、
これなら納得! という結果を得ようとすると、

  計 算 機 科 学 で ノ ー ベ ル 賞 モ ノ

の宇宙人から教わる位しか方法のない、現こんぴーたーさいえんすを
覆す理論に基づくような得体の知れない技術でもないと、ほぼムリ
だという事が断言出来てしまう、という事です。

 ちなみに、ノーベル賞が計算機科学を対象としていない事はご存知
ですよね?

 確かに、ある種のコーディングルールに従って書き換えたり、それを
前提として合成ライブラリを拡充すれば、確かに使い物になるツールも
作成可能だとは思いますけどね。問題なのは、そのコーディングルール
を記述が満たしているかどうかの判定でさえ、相当の記述制約を課さ
ないと、決定不能問題となる恐れがある事です。

 それを解った上で否定しています。

 計算不能 = どんなに頑張っても、こんぴーたで解く事が出来ない、
        つまりその問題をとくためのアルゴリズムが存在しない
        という事

545 :774ワット発電中さん:04/12/02 19:48:46 ID:vAtqnPiA
補足

  決定不能 = 計算不能


>>OSC1さん
 まあ、そうは言っても頑張って下さい。

546 :774ワット発電中さん:04/12/02 19:54:28 ID:PlPflBco
>GPLに基づいて配布
CPUの場合アセンブラは公開されてるからフリーで作っても何とかなるかもしれんが、
FPGAの場合、先ずメーカは内部情報を公開せんな。
GPLに基づくフリーでできるのはファンクションシミュレータまでだと思われ。


547 :774ワット発電中さん:04/12/02 19:57:30 ID:vAtqnPiA
蛇足

   論理合成は学問だが、動作合成は学問じゃない!

これ、U.C.BerkeleyのEDA関連の超有名教授のお言葉。

論理合成は、ブール代数という無矛盾な数学ワールドで展開されている
非常に綺麗な学問なのです。方や動作合成は、プログラムを表現する
あるデータ構造(通常はコントロールデータフローグラフなど)をグラフ
と見立ててのスケジューリング問題、として定式化されているだけで、
ブール代数のような無矛盾な数学的バックボーンがはっきりとあるわけ
じゃないんですね。

で、例えばブール式の場合、標準形が存在するんですが、プログラムの
標準形というのは恐らく存在しないんですね。だってあったら、2つの
プログラムが等価かどうか判定できる事になるでしょ。これは一般には
決定不能です。勿論、厳しい条件をつければ解けますけどね。

つまり、論理合成の場合、初めから標準形がある世界でのお話しだったん
ですよ。方や動作合成は、どの範囲だと標準形があるのかえ解ってない
世界なんですよ。これが解れば、劇的に進歩するかも知れませんが、RTL
に毛が生えた世界というのが解である可能性もあるんですよ。

>>OSC1さん
 頑張って下さい。

548 :774ワット発電中さん:04/12/02 19:58:34 ID:PlPflBco
>>543

お前の文章にイライラするんだよッ

549 :774ワット発電中さん:04/12/02 20:03:25 ID:cN5Mab9j
やってる本人が「使えるものじゃない」だの「明日の為の・・」
(丹下段平みたいだな)なんてシロモノだって言うんだし、
”当分間実用に耐えるようなものにはなりませんが前向きに努力はしています”
だろ?それでもGPLに基づいて配布するとかいうなら玩具のようなレベル
でも全然オッケーだけどね。

チミは夢で飯が食えるんだから、それでいいけど、他人に食わせ
ようとするなら、きちんと他人に食わせるに足る料理にしてから
持ってきなさいということさね。今の状態はメニューの写真は
立派だけど、実体はがらんどうの食品サンプルみたいなもの。
「いずれ凄く美味しいものになるはずです」と言ってるようなもので
しかないよってこと。

漏れはSystemCについては他のイロモノと同レベルのものとして
生ぬるく見てるさね。
そういや、XのForgeなんていうのも生ぬるくいじったことがあったな。

550 :774ワット発電中さん:04/12/02 20:14:46 ID:cN5Mab9j
>FPGAの場合、先ずメーカは内部情報を公開せんな。
>GPLに基づくフリーでできるのはファンクションシミュレータまでだと思われ。

とりあえずVerilogやVHDLを吐いてくれればいいんじゃね?

551 :774ワット発電中さん:04/12/02 20:15:07 ID:vAtqnPiA
蛇足2

私が知る限りでは、数学的バックボーンを伴う、合成がそれなりにサポート
された言語というのが、

  Esterel  : Esterel計算(SOS:Structured Operational Sematics)

  Bluespec  : 項書き換え系(TRS:Term Rewriting System)

  HY-C    : 時間拡張を伴うプロセス代数(Process Algebra)

ですかね。この中でCベースのは、HY-Cだけですね。

552 :774ワット発電中さん:04/12/02 20:15:46 ID:aRurnsxg
>>547
工学を見下すタイプの理学屋は歴史的功績を残せない

553 :774ワット発電中さん:04/12/02 20:53:24 ID:o6lj5DIQ
verilogも論理合成がなければ、RTL記述は使われなかったということになるな。

554 :0SC1メンバ:04/12/02 21:01:35 ID:2CgZk/Hd
今日は(今日も)暇だからレス付けますが
Googleでここに来てしまった真剣な人たちが誤解するといけないので言ってもいいかな?

トランジスタ>IC>LSI>VLSI>ULSI>SoCという流れ(かなり大雑把)に
レイアウトツール>回路図入力>HDL(他さまざま)>DC(RTL)>ときてる
今はサインオフはGateLevel VelirogXLここまできてるね。
これぜんぜんOK
トランジスタ(CMOS)レイアウトも配線も配置もフロアープランニングも大事

SystemCはこの歴史の延長線上にあるわけで、RTL技術者を否定してなんかいませんよ。
むしろ、尊敬しております。
トランジスタ>IC>LSI>VLSI>ULSI>SoC
明日の話という意味は最後のSoCの事を言ってるのです。
この領域の難しさは、HDLの玄人の直面している難しさと別次元の難しさなのです。
ここが分からないと否定するしか立場がなくなるのです。
HDLの玄人がトランジスタレベルの苦労を知らないのと同じです。
SoCの玄人が時代の要請で出てきてしまったんです。
みんな大事ですが、後進に席を譲るのではなく新しい世界によって自分の仕事がなくなるわけではないので頑張ってください。
勿論電子物性から上流の研究者に成り下がった人もいますが、いい給料と研究費もらってますよ。




555 :774ワット発電中さん:04/12/02 21:11:19 ID:aRurnsxg
>>554
パーフェクトに同意

556 :774ワット発電中さん:04/12/03 06:20:27 ID:V4w5rnRU
>>554
手彫りレイアウト屋さんと、打ち合わせながらRTL+図面入力設計してた頃
が懐かしいっすね。

> 勿論電子物性から上流の研究者に成り下がった人

厳しい意見ですね(笑)。

557 :774ワット発電中さん:04/12/03 06:23:20 ID:V4w5rnRU
>>554
でも、SystemCの合成は、相当な記述制約が付かざるを得ない事をちゃんと
白状して下さいね。誤魔化しちゃ駄目よ 凸▼▼メ)。

558 :名無しさん@3周年:04/12/03 10:10:28 ID:TEjMkKRP
SytemCはトランザクションレベルで記述して美しく、ソフト(あるいはファーム)
も同時に検証できるツールなんですよ。一昔前はこの辺はHDL記述を論理合成して
ハードエミュレータを実現し、ソフト(あるいはファーム)を載せて検証していた
のです。今でもこれしているところ多いけどねぇ

559 :774ワット発電中さん:04/12/03 11:15:08 ID:V4w5rnRU
>>558
> SytemCはトランザクションレベルで記述して美しく、ソフト(あるいはファーム)
> も同時に検証できるツール

美しく? えっ??? お、おかすぃー、そりは変だっぴ。高速化を考えて
出来るだけRTLを使わないように真面目にモデル化しようとすればする程
変態コーディングになっていくんでしゅが……。

  ? ? ? ? ? ? ? ? ? ? ?

560 :SystemC勉強中:04/12/03 13:47:22 ID:NQ/DQB+N
ここで、質問するのはお門違いと突っ込まれそうなのですが、詳しい方が
沢山いらっしゃるみたいなので、敢えて質問させて頂きます。

  [記述したい動作内容]
   eventが2つ以上あり、その中のどれかのeventを受けると
  プロセスを起動するが、受けたeventでプロセスの動作を
  切り替える。


  wait(e1 | e2 | ... | en);

で、「eventが2つ以上あり、その中のどれかのeventを受けるとプロセス
を起動する」は簡単に記述できるのですが、

  if(e1)

と記述できるとも思えず、「受けたeventでプロセスの動作を切り替える」
というのをどうやって実現したらよいのか、サッパリわかりません。

どなたかエロイ方、ご教授お願い致します m(_ _)m。

561 :SystemC勉強中:04/12/03 13:49:09 ID:NQ/DQB+N
IDがDQNっぽくなってる…… orz

562 :774ワット発電中さん:04/12/03 14:40:25 ID:kUBBcAZA
>SytemCはトランザクションレベルで記述して美しく、ソフト(あるいはファーム)
>も同時に検証できるツールなんですよ。

研究者には趣味的な美しさも大事かもしれないけど
実務では別段美しくなくてもいいんだよ。
水商売のねぇちゃんじゃないんだから。

「今までより綺麗です」なんていうのは駄目。検証できる
といっても、検証するために莫大な手間が掛かるのでは
本末転倒。「今までよりも格段に楽になります」でなくては
価値がない。
要するにサラサラッっと記述してパパッと実験して
それでオッケーとなったら、ササッと実際のソフトウェア
とハードウェアになって製品化できなくてはね。

563 :774ワット発電中さん:04/12/03 14:42:58 ID:E4aAdYRd
>>560
event毎にsensitive割り当てるとか、じゃダメなんかな?

564 :SystemC勉強中:04/12/03 15:06:21 ID:NQ/DQB+N
>>563
staticではなく、dynamicで実現したいのです。eventはデータを運搬
できませんが、これが出来るとある程度、eventによるデータの運搬
が一部可能になるので。

ご教授、宜しくおながい致します。

565 :774ワット発電中さん:04/12/03 15:32:15 ID:E4aAdYRd
>>564
動的の場合、イベントの発生順番が決まってないと、難しいような気がするなぁ。
どうだろう、エロイ人?

566 :774ワット発電中さん:04/12/03 18:00:36 ID:E4aAdYRd


567 :774ワット発電中さん:04/12/03 18:10:16 ID:E4aAdYRd
SystemC勉強中さん、
きっと0SC1メンバ さんが教えてくれますよ。

568 :774ワット発電中さん:04/12/03 18:39:55 ID:E4aAdYRd
がんばろうねー やっぱしシステムシーだよ

569 :774ワット発電中さん:04/12/04 05:18:47 ID:SR4Y3DPR
>>560
これ書けると便利だあね。でも、書き方、解らないッス、スマソ。
でも、これが書ければ、ぐぅば がリアリアになりがちな投機実行制御での
キャンセル信号とかが、あんたいむど、とか、ばすさいくるせいど、とか
で簡単に書けちゃうね。つうか、他にも色々使えそうっすね。

て、もし書けましぇーん! って回答だったら、

  や っ ぱ 使 え な い ぢ ゃ ん、 SystemC

って事?

そんな回答じゃないよね、エロイ人?

570 :774ワット発電中さん:04/12/04 09:18:02 ID:3XpYb70Y
システムの動作を記述しようっていうのなら
普通に必要になる機能なんじゃないの?

571 :774ワット発電中さん:04/12/04 10:15:33 ID:Sh8jMJde
>>560
68kのIPLとFCみたいなこと?

572 :774ワット発電中さん:04/12/04 10:21:24 ID:xK7rZycP
>>570
staticで普通に書けるでしょ。

573 :774ワット発電中さん:04/12/04 10:27:23 ID:SR4Y3DPR
>>572
サイクル精度でSC_THREADを用いて記述するとすると、あるサイクルでは
>>560 みたいな事をしたいけど、別のサイクルではしたくない、って感じ
の記述って、staticで出来たっけ?

アホな質問だったら、スマソ。

574 :SystemC勉強中:04/12/04 19:53:52 ID:URQn4v05
あのう、もしかして、質問内容がSystemCの こうあるべきだ! という
使用方法というか記述方法に、大きく反するものだったのでしょうか?

うーん、でも出来れば、dynamicで実現する方法をご教授頂きたいです。
エロイ方、何卒宜しくお願い致します m(_ _)m。

575 :774ワット発電中さん:04/12/04 20:43:47 ID:2pFMCrlu
同じIDで大量投稿しているCの達人さんへ

講釈より何か設計事例を書いて欲しい。
そうでないと言っていることに何の説得力もない。

576 :774ワット発電中さん:04/12/05 00:08:30 ID:cHFUPmEC
だから事例がないんだよ。
遠い将来の言語だから

577 :774ワット発電中さん:04/12/05 00:20:37 ID:h8xJeDoZ
違う
言えないこと書けないことが多すぎるんだよ

578 :774ワット発電中さん:04/12/05 00:57:40 ID:YqKE8M42
なんでーーー 聞きたいよーーーーー

579 :SystemC勉強中:04/12/05 04:46:11 ID:tLZwUcV+
うーん、確かに、wait(10); とかをクロックだと思って記述すれば、static
でも良いのですが、それだと、クロック遷移ごとにトリガにしたいeventを
変更したり出来ないから辛いです。

やっぱり、どなたかがご指摘されていたように、ちょっと複雑な事をしよう
とするとRTLで記述しなければならない、という事でしょうか?

そんな悲しい結論じゃない、って回答付きで主張して下さい、エロイ人!
何卒、お願い致します。

580 :酔っ払い:04/12/05 04:56:37 ID:6HfPJ8Mr
sc_eventだとnotifyっぽいのしかないので、たぶん(?)できなかったと思う。
event数が決まってるんだったら、sensitive << e1 << e2 << e3 <<..で張っといて
wait()で抜けたあとに分岐ということになりそうな気がするなあ。

581 :SystemC勉強中:04/12/05 05:03:22 ID:tLZwUcV+
>>580
有難うございます。

ただ、それだと、eventが全く来ないクロック遷移では、デッドロック
しちゃう気がするのですが、それは気のせいでしょうか?

582 :酔っ払い:04/12/05 05:08:56 ID:6HfPJ8Mr
eventがこないと、waitは抜けないけど。クロックイベントも必要なの?
(しつもん理解してないかも

583 :SystemC勉強中:04/12/05 05:14:38 ID:tLZwUcV+
>>582
はい。取り合えず、wait(10);とかでクロックにしようかと思っては
いたんですが。

もし、クロックイベントを追加した場合、デッドロックはなくなりますが、
wait()を抜けたときの分岐で困るような気がするのですが、気のせいで
しょうか? wait()を抜けた条件が、クロックイベントによるものかなか、
それとも、その他のstaticなイベントによるものなのかの識別は、可能
なのでしょうか?

584 :酔っ払い:04/12/05 05:22:59 ID:6HfPJ8Mr
#include "systemc.h"
#define EVENTSU 3
SC_MODULE(he){
void loopp();
sc_buffer< bool > hohe[EVENTSU];
SC_CTOR(he) { SC_THREAD(loopp){
for(int i=0;i<EVENTSU;i++) {
sensitive << hohe[i];
}}}};
void he::loopp(){
while(1) {
wait();
for(int i=0;i<EVENTSU;i++) {
if(hohe[i]) {cout << "hohe" << i << endl;hohe[i]=0;}
}}}

int main() {
he *he_inst = new he("hoho");
sc_start(10); he_inst->hohe[2] = 1;
sc_start(10); he_inst->hohe[1] = 1;
sc_start(10); he_inst->hohe[2] = 1;
sc_start(10); he_inst->hohe[0] = 1;
sc_start(10);
return(0);
}
見にくくてスマソ


585 :酔っ払い:04/12/05 05:27:30 ID:6HfPJ8Mr
SystemCはCだから、いざとなれば、なんでもありだよ。そろそろ寝ます。さようなら〜


586 :SystemC勉強中:04/12/05 07:12:49 ID:tLZwUcV+
>>585
有難うございます。sc_startでクロックの代わりという事ですね。ただ、
申し訳ないですが、汎用性が低いような……。

よく考えれば、wait() methodには timeoutもありますから、クロック周期
を10nsとかに設定するのであれば、event数が決まっているものとして、
sensitive << e1 << e2 << e3 <<..で張っといて、timeout付きのwait()
で抜けたあとに、クロック遷移内にeventが発生したかを否かをsc_time
なりで確認した後に分岐すれば良い(eventを受けた場合は、行うべき処理
を行った後必ずwait(10);を実行するように記述する)、という方法も考え
られますね。


ただ、この方法の問題点として考えられるのは、

 1.sc_clockを使えないので、VCDダンプでちょっとはまりそう

 2.レーシング対策を主導でデルタ遅延等を挿入して行う必要がある
   (ゼロサイクルの安定ループの扱いは相当困難かも知れませんね)

 3.RTL記述を混載してはならない(同一周期内に同じeventが複数回
   発火して漸く値が安定する事がありますが、その場合、最初の
   event発火で確定した誤った値を用いて受けた側のSC_THREADが
   動作する事になりますね)

ですね、きっと。勿論、sc_clockを使っていない段階で、恐らくHDLとの
Co-Simulationはきっとムリですね。うーん、でも、これはちょっと……
ですね。

587 :SystemC勉強中:04/12/05 07:35:44 ID:tLZwUcV+
間違えました、timeout付きwaitはsc_eventに対してのみサポートされて
ますね。本当に、すんまそん。

どうやら、私が記述したい内容はSystemCでは、やはりRTLを用いるしか
方法が、最も自然なようですね。

勿論、クラスライブラリを直接いじれば何か出来るのかも知れませんが。
sc_event classにパブリック変数を導入して、wait(e1|e2|...|en)で
受理したイベントの変数を更新するよるwaitをオーバーライドするなり
して作成し、必ず、waitを抜けた後で、その変数をユーザがクリアする
とでもすれば良いんですかね?

もう、ここまでくると何か病的な気がするのですが、気のせいでしょうか?

というか、SystemCはC++なんだから、これ(クラスライブラリの派生クラス
なりの作成)は、どちらかというと当たり前で、これ位は出来ないと使い
こなせないという事なのでしょうか?

もし、そうだとすると、私には、かなり荷が重いです……。 orz

588 :二日酔:04/12/05 11:46:35 ID:6HfPJ8Mr
#include "systemc.h"
#define EVENTSU 3
SC_MODULE(he){
sc_in<bool> sck;
void prd();
void loopp();
sc_buffer< bool > hohe[EVENTSU];
SC_CTOR(he) {
SC_THREAD(prd){sensitive<<sck;}
SC_THREAD(loopp){
sensitive << sck;
for(int i=0;i<EVENTSU;i++) {
sensitive << hohe[i];
}}}};
void he::prd(){while(1){wait();hohe[rand()%EVENTSU] = 1;}}
void he::loopp(){
while(1) {
wait();
for(int i=0;i<EVENTSU;i++) {
if(hohe[i]) {cout << "hohe" << i << endl;hohe[i]=0;}
}}}

int main() {
sc_clock sck("ck",10);
he *he_inst = new he("hoho");
he_inst->sck(sck);
sc_start(1000);
return(0);
}
とりあえず動いたので、うPします。(こんなんで良かったっけか?)
酔った勢いスマソ。


589 :774ワット発電中さん:04/12/05 13:13:24 ID:iQbno0lO
実例を挙げよと言われてとたんに来なくなった奴が一匹居るわけだが。

590 :SystemC勉強中:04/12/05 13:14:05 ID:tLZwUcV+
>>
申し訳ないですが、全く違います。すいません。

clock以外のイベントでwait()を抜けても、クロック遷移をしてもらわないと
困るのです。

この問題は、きっとご提供頂いたコードでは解決不能だと思うのですが、
どうでしょう?

間違っていたら、すいません。

591 :SystemC勉強中:04/12/05 13:24:38 ID:tLZwUcV+
>>588
本当にご教授頂き有難うございます。結局、wait()を抜けたのが、
clock eventなのか、clock以外のeventなのかを識別する必要が
でます。逆に、これさえ可能なら、多分大丈夫のような気がします。

その実現方法として、sc_time変数を用いて、10ns経っていなかったら、
抜けてきたwait()の前にJumpするとかいう風に記述することになって
しまうような気がとってもするのですが、これって、RTLですよね?

やはり、>>589 の方が責めてらっしゃるであろう方の意見「複雑なことを
記述しようとするとSystemCではRTLでしか記述不能」が正しかったという
事なのでしょうか?

それは悔しいです。何とか、RTLっぽくない方法で解決する方法はない
ものでしょうか? エロイ方、何卒宜しくお願い致します。

592 :774ワット発電中さん:04/12/05 14:23:46 ID:iQbno0lO
ある意味当然だと思う。
結局はやりたいことを事細かに書かないと高速化も実回路もあったもんじゃないってのは
HDLでもおなじだわ。

実回路を意識せずアルゴリズムのみの検証をした後結局RTLで書き直しなんて事になるので
あれば、Verilog、VHDLで開発しているのと余り変わらない気もする。
取り敢えず動作する回路をでっち上げるには、問題が無いレベルまでは来てるのかね?Cも。

今のところ仕事で使う予定がないからDWMを読んで「ふーん」程度で終わってるが。

三年後には現場に降りてきてるだろうか?

593 :乗りかかった船:04/12/05 14:33:49 ID:6HfPJ8Mr
#include "systemc.h"
#define EVENTSU 3
SC_MODULE(he){
sc_in<bool> sck;
void prd(),loopp();
bool prev_sck;
sc_buffer< bool > hohe[EVENTSU];
SC_CTOR(he){
SC_THREAD(prd){sensitive<<sck;}
SC_THREAD(loopp){
sensitive << sck;
for(int i=0;i<EVENTSU;i++) { sensitive << hohe[i]; }
}}};
void he::prd(){while(1){wait();wait();wait();hohe[rand()%EVENTSU] = 1;}}
void he::loopp(){ prev_sck=sck;
while(1) {
wait();
for(int i=0;i<EVENTSU;i++) {if(hohe[i]){cout<<"hohe"<<i<<endl;hohe[i]=0;}
if(prev_sck != sck){prev_sck=sck; cout <<"ck!"<<endl;}
}}}
うーん。いい加減なところあり。。
こうなると抽象度(?)をあげたほうが良いかも。クロック同期で
クロック間の別いべんとはキューイングしちゃだめなのか?
(イベントキューと言えば、SysC2.1はどうなったんだ?おしえてエロイ人)


594 :SystemC勉強中:04/12/05 14:37:37 ID:tLZwUcV+
>>592
『一匹』とおっしゃっているのは、C++&Templateマンセー な方の事なので
しょうか?

確かに、その方ならどうやってSystemCやC++で実現されるのか、とっても
伺ってみたいですね。

 [記述したい内容]
  1.SC_THREADを用いたサイクル精度記述
  2.clockを含む複数のeventを受けて動作
  3.waitが受けた(起こされた)eventを識別して動作を切り替え
    (event、または/及びサイクルごとに動作が異なる)
  4.clock以外のeventが来ないクロックサイクルあり

見ていらっしゃったら、何卒宜しくお願い致します。

595 :SystemC勉強中:04/12/05 14:49:40 ID:tLZwUcV+
>>593
本当に、有難うございます。以下に、ご質問を記載致しますので、
ご回答お願い致します。


#include "systemc.h"
#define EVENTSU 3
SC_MODULE(he){
sc_in<bool> sck;
void prd(),loopp();
bool prev_sck;
sc_buffer< bool > hohe[EVENTSU];
SC_CTOR(he){
SC_THREAD(prd){sensitive<<sck;}
SC_THREAD(loopp){
sensitive << sck;
for(int i=0;i<EVENTSU;i++) { sensitive << hohe[i]; }
}}};
void he::prd(){while(1){wait();wait();wait();hohe[rand()%EVENTSU] = 1;}}
void he::loopp(){ prev_sck=sck;
while(1) {
wait();
for(int i=0;i<EVENTSU;i++) {if(hohe[i]){cout<<"hohe"<<i<<endl;hohe[i]=0;}
if(prev_sck != sck){prev_sck=sck; cout <<"ck!"<<endl;}
}
wait(); // <- これ入れても本当に大丈夫ですか? たまに、sck以外で
    //  動いてしまうような気がとってもします。
}}


ちなもに、仕様は >>594 の[記述したい内容]です。looppがそこで言う
SC_THRAEDに対応します。で、これ以外の縛りはないものと考えて頂いて
問題ないです。

596 :SystemC勉強中:04/12/05 14:52:24 ID:tLZwUcV+
あっ、サイクル精度記述と言う意味は、wait()をクロック境界と考えている
記述だという事です。が、明確に、クロック境界を記述可能なら、この規則
に縛られる必要はないです。

597 :乗りかかった船:04/12/05 14:54:12 ID:6HfPJ8Mr
>>595 SCK以外で動きますよ

598 :乗りかかった船:04/12/05 14:58:14 ID:6HfPJ8Mr
>>596
_| ̄|○ いままでの記述例全部忘れてくれ


599 :SystemC勉強中:04/12/05 15:01:26 ID:tLZwUcV+
ですよね。私はもう解らないのですが、やっぱりsc_timeでclock eventか
否か判断して、clock eventでない場合は、抜けてきたwait()の前へJump、
という方法しか、サイクル精度記述を保持する方法が思いつかないです。

別にクロック同期である必要はないとは思いますし、wait()からwait()
が実際の実装のサイクルと合って無くても良いとか思うのですが、やっぱり
ある期間ごとに処理を記述する、というのが解り易いのではないかと
思うのです。

相手のThreadがこういう動作をしているとき、このwait()は、このeventで、
この動作のときはクロック境界で、なんて記述も可能ですが、ちょっと頭が
付いていきそうにないというか、バグのないように管理するのが私には
辛い気がしてならないです。

>>597 さんは、そのような記述を意図なさっていらっしゃるのでしょうか?

600 :SystemC勉強中:04/12/05 15:05:58 ID:tLZwUcV+
乗りかかった船さん、
>>599 の「ですよね」は>>597に向けての言葉であって、決して>>598
対しての言葉ではございませんので、くれぐれもご立腹なさらないで
下さい。すいません。

レーシングは本当に難しいですね。

今までの記述であっても、>>599で述べさせて頂きましたように、「相手の
Threadがこういう動作をしているとき、このwait()は、このeventで、この
動作のときはクロック境界で」という記述が可能なら、十分参考になると
思います。ただ、私は使いこなす自信がないですが。すいません。

601 :乗りかかった船:04/12/05 15:27:37 ID:6HfPJ8Mr
#include "systemc.h"
struct hohe_if:virtual sc_interface{ public: virtual void fuhe(bool a)=0; };
SC_MODULE(he),public hohe_if{
sc_in<bool> sck;
void loopp(), fuhe(bool);
SC_CTOR(he){SC_THREAD(loopp){sensitive<<sck.neg();}}
};
void he::fuhe(bool a){cout <<"キター(゚∀゚)!"<<endl;
/*メッセージをキューに積む*/
};
void he::loopp(){
while(1) { wait(); /*ここでキューをチェック*/ }
}
//---
SC_MODULE(prd){
sc_in<bool> sck;
sc_port<hohe_if,1> port_out;
void loopp();
SC_CTOR(prd){SC_THREAD(loopp){sensitive<<sck.pos();}}
};
void prd::loopp(){ while(1){wait(); port_out->fuhe((bool)1);}
}
int main() {
sc_clock sck("ck",10);
he *he_inst = new he("hoho");
he_inst->sck(sck);
prd *prd_inst = new prd("foo");
prd_inst->sck(sck);
prd_inst->port_out(*he_inst);
sc_start(1000);
return(0);
}
//SystemCのexampleのSimpleBusを参考

602 :774ワット発電中さん:04/12/05 15:48:54 ID:BpWxwkLr
>>SystemC勉強中
下らんこと書いていちいち上げるな。
ブラウザの使い方から勉強せぇ。アホが!

603 :SystemC勉強中:04/12/05 15:51:43 ID:tLZwUcV+
>>601
本当に有難うございます。

SC_THREAD間の同一サイクルでのデータ転送を可能とするために、キュー
を準備し、キュー内のメッセージのチェックを立下りエッジ同期で行う、
という事ですね? これなら、サイクル精度記述も保持されていて大丈夫
ですね。素晴らしいです。本当に有難うございます。

ただ、SC_THREADが3つ居て、1−>2−>3と同一サイクルでevent
(メッセージ)がスルーで加工されながら抜けていく感じとか、2個でも
1−>2、リターンで2−>1的感じには拡張できないような、そんな
気がしますが、そんな記述をRTLを用いずにSC_TREADで書こうという態度
そのものが間違っているんですよね、きっと。ここまで複雑だと、やっぱ
り、諦めてRTLを使うしかないんでしょうかね。どうなんでしょう?

604 :SystemC勉強中:04/12/05 15:56:45 ID:tLZwUcV+
>>602
??

このスレ、結構勉強になって良いと個人的には思うのですが。私が
間違っているのでしょうか。何だか、ご立腹のようですね。すいません。

605 :乗りかかった船:04/12/05 16:11:59 ID:6HfPJ8Mr
>>603 そのへんになると。。
また別の方法が(1->2->3の場合は4相にするとか。。(速度はおちる))。
自力で考えてみてくれ
>>604 E-mailのところに「sage」って書いてちょーだい

606 :SystemC勉強中:04/12/05 16:55:45 ID:tLZwUcV+
>>605
本当に有難うございます。1->2, 2->1も3相とかで対応できそうですね。

ただ、何れにしても、3個以上とか、双方向でのデータのやり取りがある
場合は、データ通信の順番が予めある程度静的に決まっていないと辛そう
ですね。

実行順が完全に決まっているなら、共有変数にデータを書き込んでから、
event.notify()して、wait(event)で抜けてから、共有変数を読む、という
のが一番簡単ですね。適応場所を限定すれば、これも使えるような気が
します。

抽象度の高い世界では、バスシステムなんかもそうですが、シナリオみたい
なものがあるので、完全ではないにせよ、通信の実行順というがある程度
決まっているでしょうから、恐らくはご教授頂いた方法で何とかなるのかも
知れませんね。

ただ、システムの全体像が見えない状態でボトムアップ的に記述しようとする
とかなりハマりそうですね。システムの全体像を見て記述する、というのが
SystemCの運用で一番大切な事なのかも知れないですね。

607 :774ワット発電中さん:04/12/05 18:09:16 ID:h8xJeDoZ
>>604
どこの世界にもくだらんことに言いがかりつけて
威張り散らすチンピラはいるものさ
はいはいといなすのは賢い知恵だが
あんまり気にしなさんな

608 :774ワット発電中さん:04/12/05 19:48:46 ID:uXfPnWw5
>>606
>完全ではないにせよ、通信の実行順というがある程度
>決まっているでしょうから、恐らくはご教授頂いた方法で何とかなるのかも
>知れませんね。
>
>ただ、システムの全体像が見えない状態でボトムアップ的に記述しようとする
>とかなりハマりそうですね。システムの全体像を見て記述する、というのが
>SystemCの運用で一番大切な事なのかも知れないですね。

この一連のやり取りでそこまで理解できた点でご立派です。もうお気づきかと
思いますが、何故SystemCでできないか、ではなく、何故SystemCでは
やりずらいか、を理解できれば十分です。

609 :774ワット発電中さん:04/12/05 20:21:40 ID:M2+AwfiY
SystemCで抽象度をあげると、こうなるので具体性が要求されると
どうすりゃいいんだと言うことでしょう


610 :774ワット発電中さん:04/12/06 05:52:41 ID:8cVOKflv
> 何故SystemCでできないか、ではなく、何故SystemCでは
> やりずらいか、を理解できれば十分です。

611 :774ワット発電中さん:04/12/07 06:21:09 ID:wtcaSlxR
どうやら、システムの全体構成を把握しているという前提があって且つ
苦労すればSystemCで何でも記述できる、という事が明らかになった
みたいやね。

でも、この一連のやりとり見てて思うけど、何を意図してそう記述した
のかを自動で判別できんと、合成なん無理やん。いうか、2相とか4相
とかのクロックって、ブロック図での信号線を無理矢理表現するための
もんやろ? これを、実は信号線なんですわ、って言われてもなあ。

やっぱり、SystemCは、ごく一部の人のためだけに存在するもんなんやね。

612 :774ワット発電中さん:04/12/07 06:53:35 ID:wtcaSlxR
やっぱ、晒し上げ、やね。

613 :774ワット発電中さん:04/12/07 12:08:22 ID:EyDkuiXf
どう表現したらいいのだろうね?
具体的記述の話をしろと言われたらとたんに消え、結論が出た頃に
的外れなことを言いに来るとはな。

皿仕上げってのは自殺のことか?

614 :774ワット発電中さん:04/12/07 14:41:20 ID:wOPtT2gt
おもしれぇな、ここ。よく分ってるやつは口をつぐみ、てんで分ってない奴らが
騒いでやがる・・・まあ、技術先行してるから、表に出したくない気持ちはよく
分るが、少しぐらい情報出せや。

615 :774ワット発電中さん:04/12/07 15:31:28 ID:XH+BjicC
>>613
合成を意識していない記述を合成しようと考える >>611 はバカって事?
それはそうかも知れんが、現場とか上の要求ってそんなもんだよ。

 「折角SystemCの資産があるんだから、何とかしろ! 」

 「まさか書き直せなんて言わないよね? 百万歩譲って書き直す
  として等価性検証くらいはサポートしろよな! 」

とか、もうねアホか、バカかと。出来ないものは出来ないのよ、どう
あがいてもね。

>>614
所詮はC++だという事実と、合成を意識しない記述はどうする事も出来ない
という事実しか初めからないが、何か?

616 :774ワット発電中さん:04/12/07 16:52:03 ID:1mbEOzN3
所詮はC++だから合成されることを前提としてシステム
の挙動を考えてはならない
とな。

617 :774ワット発電中さん:04/12/07 19:28:24 ID:EyDkuiXf
取り敢えずは、「同じID」で具体的にどう使うのか、どうFPGA等に
実装するのかを語れ無いのであれば、実際HDLも使ったことのない
たんなる口だけ厨って事で終わりにしたいよ。

618 :774ワット発電中さん:04/12/07 20:42:12 ID:XH+BjicC
>>617
自意識過剰バカ、ハケーン(w

619 :774ワット発電中さん:04/12/07 20:50:47 ID:XH+BjicC
>>617
実際に設計で役立つSystemC記述は合成できないのが前提だし当たり前。
どっかのプリンタメーカが想定してるとか言ってたけど、業界じゃ、
内部で「誰が使うんだあ、ハア? 状態」だってのは実はバレバレなんよ。
なので、SystemCを記述しようが結局は、シコシコRTLを記述する事に
なるんだよ、現状では。というか遠い将来に渡ってね。で、RTL以降
の説明も欲しいの?

620 :774ワット発電中さん:04/12/07 20:56:33 ID:EyDkuiXf
なんか変なのが釣れたが何これ?

621 :774ワット発電中さん:04/12/07 21:01:34 ID:XH+BjicC
>>620
釣りだったのかあ…… orz

まあ、嘘は言っとらんので参考にしてくれ。

622 :774ワット発電中さん:04/12/07 21:03:04 ID:pKeL8Ty7
多分よく読んでないと思われ。
Cマンセーの馬鹿に出てこいと言ってるのに何故か頓珍漢なレスを返してる。
もしかしたらC厨の自演かもな。

なんと言っても連続で同じIDで書き込みしてるし。
と、突っ込みを入れると今度は二度と同じIDが出てこなくなるであろう。

623 :774ワット発電中さん:04/12/07 21:07:17 ID:XH+BjicC
>>622
そ う だ っ た の か あ。

鬱出汁脳……。

>>662
ちなみにあんたは何がしたいんだ、このスレで。

624 :774ワット発電中さん:04/12/07 21:08:40 ID:XH+BjicC
662なんてありまへんがな。自爆 orz

>>622 の間違いね。スマソ

625 :774ワット発電中さん:04/12/07 21:09:36 ID:qF5MSs6a
誰がどう見てもよく読んでない馬鹿=ID:XH+BjicC

626 :774ワット発電中さん:04/12/07 21:16:06 ID:XH+BjicC
面白いから、ID変えるのやーめた。実力のない人たちって面白い!
誹謗中傷するのが大好きなんだね、やっぱオタクって。素晴らしい!!
否定するのも大好きらしい。生産性なくていいね☆

627 :774ワット発電中さん:04/12/07 21:18:50 ID:qF5MSs6a
>>626
どうでも良いからHDL又はCの事を書いたら誰もが君を認めるだろう。
それ以外で実力を示すことなど出来ないわな。

628 :774ワット発電中さん:04/12/07 21:31:02 ID:XH+BjicC
>>627
じゃあどうして君は書かないの?

  パイプライン乗算器のC記述
  int A,B;
  int MULT;
  int cnt;

  main() {
   int t1,t2;
   cnt = 0;
   MULT = 0; // しょきち
   A=B=0;  // しょきち
   while(1) {
    MULT = t2;
    printf("MULT = %d\n", MULT);
    t2 = t1;
    t1 = A*B;
    printf("A = %d, B = %d", A, B);
    printf("clock boudadary (%d)\n", ++cnt);
    input();
   }
  }
  void input() {
   A = rand()/(RAND_MAX /100);
   B = rand()/(RAND_MAX /100);
  }

ちなみに、私はSystemCマンセー じゃないよ。

629 :774ワット発電中さん:04/12/08 05:27:28 ID:BKZISR/e
>>628
これって、YXIのeXCIteのマニュアルからパクッたの?

というか、文書整形とかでAWK使うけど、確かにこんな感じに記述するよね。
このテク使うと、ファイルを一回なめるだけで済むから、AWKのクセに処理
も結構早いし。DCとかPTのレポートファイルの加工に結構イイ感じで
役立つよね、このテク。

630 :774ワット発電中さん:04/12/08 12:50:25 ID:bB4kR+Zf
>>617
なんか粘着してるみたいだが言ってる意味わからんよ。あと、一方に
合成含め、実装は別に考えろってのも全く的外れじゃないんだろ、この
スレ的には・・・で、何をやっきになって要求してるのかと。

631 :774ワット発電中さん:04/12/08 13:26:24 ID:RAM4tS2v
>>630
だよね。

一般に、コンパイラが作成可能な言語は動作合成可能なんよね。だって、
プロセッサのROMに焼けば、ほらハードの出来上がり!

つまり、効率を求めないのであれば合成って何でもアリなんだよ。でも、
求めるでしょ、効率。となると、それに向けて記述を最適化しないとね。
組み込みミドルウェアとかって、アルゴリズムの独自性とかもあるのかも
知れないけど、対象としてるアーキに特化して最適化してるから、で、
それがそんな簡単に作れないから、商品価値を持つわけでしょ。

> 合成含め、実装は別に考えろってのも全く的外れじゃないんだろ
というかコレが、正に真だあよ。

632 :774ワット発電中さん:04/12/08 14:21:12 ID:5JqP6N7s
言いたいことは判らないでもないけど、かなり的はずれだと思うけどね。


633 :774ワット発電中さん:04/12/08 14:22:24 ID:RAM4tS2v
いやいや、これが動作合成の開発を実際にやってる人間の心情だよ。

634 :774ワット発電中さん:04/12/08 14:28:04 ID:5JqP6N7s
つまり
×動作合成の開発
○動作合成ゴッコ
ってことか

635 :774ワット発電中さん:04/12/08 14:34:19 ID:RAM4tS2v
>>634
まあ、そんなようなもんだね。プログラムの標準形みたいなものが恐らく
存在しないだろうから、こればっかりはどうしようもないんだよね。

それでも中間表現とかを頑張って、標準形っぽくしようと努力したり、
超コンパイラの技術を参考に発展させたり、と努力は惜しみなくして
いるらしいんだけどね。

確かに、この発言、米国の動作合成で有名な背の高い教授にして、
エラクどやされた事があった、とか言ってたね。まあ、人間、本当の
事を言われるとムカつくから、仕方ないんだけどね。

636 :774ワット発電中さん:04/12/08 15:03:40 ID:8nJw1uRr
痛い自演の応酬か。
なんか可哀相な奴。

637 :774ワット発電中さん:04/12/08 15:26:54 ID:RAM4tS2v
私、ID変えないよ。変えると面白くないもん、だって(笑)。

>>636
 >>626 をもう一度読んでね☆

638 :774ワット発電中さん:04/12/08 15:40:33 ID:R+TLKNRJ
前のもそうだけど、いくらなんでもこんな下手な自演ないだろう・・・
IDのベースがドメインベースとかそんなんじゃないの?スレごとに
そういうの指定できるかどうか、分らんけどさ。
つか、すぐ自演とか条件反射するの頭悪すぎるよね。HWコーディング屋
って、頭堅そうな奴多いけど、イメージ固定されてきたよな、このスレで。

639 :774ワット発電中さん:04/12/09 16:06:03 ID:ZTa9lNvO
Panel on standards talks of ESL progress
http://www.eedesign.com/news/showArticle.jhtml;jsessionid=EOGH3SWCDXWBCQSNDBESKHA?articleId=55300526

Another member of the audience asked whether some sort of consensus
was building around transaction level modeling as a level of
abstraction above RTL and whether this would allow automated
methods to develop to take designs from SystemC to VHDL or Verilog.

Synopsys' Kunkel answered by saying that while top-to-bottom
synthesis had been largely discredited, the use of "channel"
synthesis to define interconnectivity between blocks and where
necessary develop RTL patches was being used and the way forward,
a point of view endorsed by fellow panelists James Colgan,
director of strategic alliances at Sonics Inc.

For ST's Clouard the important thing to stress was that even
without automated movement between the transaction level and
the RTL, the use of TLM more than pays for itself in terms of
speeding up chip design, selecting appropriate blocks and
allowing early software development.

【要約】
 会場からの質問:
  SystemCのTLM記述からHDLのRTLへの合成ってどうなの?

 支那腐死巣
  トップダウンに合成するのは諦めて下さい。HDLのRTL記述を用意して
 パッチ的にチャネル記述部に割り当てるような操作を明示的にユーザが
 行うという前提に立てば、出来る可能性はあります。
 
 餌巣手舞黒
  合成なくても、Simulationが高速化できるから設計期間の短縮が可能
 です。SystemCマンセー です。


 【結論】このスレの議論と同じ結論。為になるね、このスレ☆

640 :774ワット発電中さん:04/12/09 16:11:12 ID:ZTa9lNvO
まあ、餌巣手舞黒はU.C.Berkeleyに研究所を持っていて、そこでSystemC
によるTLMを用いた設計手法とかツールの研究を、結構根気良く続けてた
からね。

641 :774ワット発電中さん:04/12/09 16:14:15 ID:ZTa9lNvO
支那腐死巣の回答は、>>611 を読むと非常に納得です。はい。

642 :774ワット発電中さん:04/12/09 20:13:58 ID:I/KkDfpm
Nikkei Electronics の2004.12.6号に特集があります。
NEシーやめのつけどころが鋭い会社が既に実用化してるようですね
EDAでは緬汰がやはり製品だしてるようだけど。
それでもやっぱり無理なのかな?
特集記事の表紙には、うちの会社も2005年から本格適用って書いてある。
本当かよ!!
マンセーの会社じゃないけどね

643 :774ワット発電中さん:04/12/09 20:40:29 ID:Kr5JHULq
あの特集ってCとC++、SystemCをごちゃまぜにして語っている
のがどうにも許せんなぁ。

>うちの会社も2005年から本格適用って書いてある。
頑張って、大本営発表でない実情をここで暴露してくれたまへ
それが多くの人民の命を救うことになるのだ

644 :774ワット発電中さん:04/12/09 20:56:11 ID:UtcXVSF4
いいすよ
部外者だし。
うちの部門は●投げで設計はほとんどなし、
漏れは仕様書書くのと検証で精一杯。

出向でハード屋さんが来てるけど、
彼らにはSystemCの教育かね出してもらって受けさせてる。
社員の名刺持ってるからここの人間が受けてると思ってる、
のは誰でも知っている有名な新横浜の会社だけ
SystemCコース受講すれば明日からバリバリ設計者になれると思っているアホ下請け。
特定されるからこのくらいにしとこ。
でも、社内セミナーでこれからは社内で何でもできるような事、
systemC検討の部門はほざいてた。
HDLの設計者もいないのにどうするんだよ。いきなりSW専門の派遣受け入れやがって.

>>643
お前もなんか暴露しろ!



645 :774ワット発電中さん:04/12/09 21:10:23 ID:0YXCIZIQ
あ もひとつ暴露
たぶんうちだけじゃないと思うけど。
無料のソフトは設計では使ってはいけないことになってる
資産計上できないから無理無理無理
だからOSCIさんの一所懸命作ったRefシミュレータは、
結局個人でダウンロードさせて貰いました。
実際は使ってないけどね。
間違えて6回ダウンロードしてるから、
去年1万5千回の数はユーザ数として当てにならないよん
たぶん1/6だと思う実際のユーザ数は
SW屋さんにHW作らせようという魂胆は間違ってるよ
分かるわけ無いからね。レースって何?だって帰れお前!

646 :774ワット発電中さん:04/12/09 23:12:24 ID:FNu9ixLi
あげ

647 :774ワット発電中さん:04/12/09 23:28:09 ID:peIIn1lb
日経エレだれも読んでいないのかな?
明日読んでね。

記者

648 :774ワット発電中さん:04/12/09 23:30:06 ID:peIIn1lb
うそだぴょーん


649 :774ワット発電中さん:04/12/10 05:43:59 ID:LzC1d81n
>>641
いわゆる、いんたーふぇーす合成ってヤツね。しかも、いんたーふぇーす
ライブラリベースの。この技術なら、もう十年くらい前に研究段階を終えて
製品化されてるよね。

かなり早い時期からサポートしてるのは、

  CoWare :HW/SW 間のI/F合成

  Arexsys :HW/SW 間のI/F合成、動作合成

  YXI   :動作合成

だね。最近では、経営がとっても不安定な日本のEDAベンダとMentor
がサポートしてるね。そういやSTRACでもVCDSとかいう、お取り潰しになった
プロジェクトで、研究というか単なる猿真似というかをやってたね。

でも、この技術の問題点は、いんたーふぇーすライブラリの構築が非常に
困難だという事なんよね。なので、ベンダが用意して提供(販売)するという
形でしか普及してないんだな。実際、CoWareとかMentor見てそうでしょ。
AMBAに関数コールで繋がります、ってのが売りだもんね。

650 :774ワット発電中さん:04/12/10 06:44:59 ID:LzC1d81n
という意味では、>>472 は神発言かも! 取り合えず、再掲。

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

そう言えば、2003年のDACでCoWareが独自バスのモデル化ツールを作った
とか言ってたよ。確か、汎用的かどうかをCore Connectバスかなんかを
実際にモデル化する事で確認してるとか言ってたね。で、CoWareはCadence
と組んでいて、Cadenceでは >>482 のように頑張っていると。

ただ、ハードのいんたーふぇーす合成は、YXIが一番先行していたハズなん
だけどね。こんなのもあるし。

日立,SHベースのシステムLSI開発ツールとして,米Y Exploration社の動作合成ツールを採用
http://ne.nikkeibp.co.jp/members/01db/200106/1009606/

どうなったの? 関係者の方、情報きんぼんぬ!

651 :774ワット発電中さん:04/12/10 12:04:56 ID:xN4KHRC3
これからはSystemCを使って動作合成でしょう
http://www.hdlab.co.jp/service/hdt/mokuji_pdf/SystemC_syn.pdf

652 :774ワット発電中さん:04/12/10 14:38:02 ID:wiIsJaUi
悪名高き動作合成ツール君って話しになんねぇー orz

ちなみに、そこらにあったC記述から合成可能なSystemC記述作るのに
相当苦労して、且つバグだらけで合成結果が1月経っても2月経っても
返って来ないという、非常に香ばしい感じ。まあ、妄想だったのかも
知れないが。

是非、評価を積極的に行って、我々が費やした以上の時間と金を無駄に
消費して欲しいものです。

653 :774ワット発電中さん:04/12/10 14:40:09 ID:wiIsJaUi
>>651
このスレでの評判は、↓↓↓
 >>443 >>447 >>619

ふむふむ、なるほど。ちょー納得かも。

654 :774ワット発電中さん:04/12/10 15:19:42 ID:JWmKKJKq
制約守ればできるということかもしれないが
あんなにゲート数がおおきくなるんじゃ、チップ面積大で
使えないのと同じ

655 :774ワット発電中さん:04/12/10 18:16:18 ID:26n59jBT
>>652
>我々が費やした以上の時間と金を無駄に
>消費して欲しいものです。
詳しく教えてくれませんか?
いつ頃の話ですか?少しは改善を期待してると、後追い決めてたけど
来年度評価開始考えてるけど無駄になるのやだな。
大手が採用決めたからって営業の人言ってたけど、
結局>>652の会社は買ってしまったその大手?
>>651
これ受講してみようかと思ったけどやめたほうがよさそ
本当の情報が欲しいけど、誰も教えてくれない。

656 :774ワット発電中さん:04/12/10 18:26:37 ID:26n59jBT
採用決めたor決めそうなのは、西と東のS社って言ってましたが、>>652は西??

657 :774ワット発電中さん:04/12/10 18:33:12 ID:26n59jBT
>>652 >>654が同じ人とは思えないので、西のSと東のSがここに揃ったって事
このスレッド役に立つね

早く教えてくれ
その後なんでやっぱり決定したのかを

658 :774ワット発電中さん:04/12/10 19:00:46 ID:DCtt82Ek
RTLでの論理合成を育てた日本の会社ってどこなんだろう?誰か教えて。
そのときの苦労をここで共有したいよね。
それこそ役に立つ話がきけそうです。 お金いくらかかったのかなぁ?
動作合成バブルは何処が受け取れるのでしょうか?
来年、支那腐死巣は屍か、抜け殻らしいですね。
大変そう。外資EDA社員さんにエールを贈ろう。


659 :774ワット発電中さん:04/12/10 19:05:30 ID:D/7aC7if
http://www.forteds.com/news/pr082504sanyojapanese.pdf
西のsの記事
実名ででてるけどとりあえず
教えて

660 :774ワット発電中さん:04/12/10 19:37:47 ID:wiIsJaUi
>>685
技術力が理解できない権限だけがある幹部クラスに、ビジネスミーティング
だと突然最初に宣言し、あまつさえ技術説明を避け、技術的質問をしよう
ものなら、「ビジネスのお話しですから」と語気を強めて回答し、こちらに
非があるかような振る舞いを平然と行う「トップセールス」なる詐欺まがい
販売活動をその生業とするような売国奴に同情の余地は無い。逝って良し!

661 :774ワット発電中さん:04/12/10 19:46:38 ID:wiIsJaUi
>>658 だった
それでも、技術的質問をしようものなら、「担当の方はやる気がおあり
ですね、早速パートナーシップ契約に話しを進めましょうか。」と来る。
質問が詳細だと、「パートナーシップ契約をご締結頂かないと……。」
と来る。実に計算されている。素晴らしい。巷にある詐欺まがい商法
そっくり、イヤそのものだ。理系人間はそういうのに弱い。引っかかっても
仕方がないのかも知れない。

「理系から金を毟り取る文系」という縮図を垣間見た気がする。

外資系EDAベンダ、逝って良し!

662 :774ワット発電中さん:04/12/10 20:35:43 ID:ADX6asx7
>>660
よほど外資EDAに恨みがあるみたいですねー
同じような人がここにもいますよ
同一人物? 図kenさん?
http://tmp4.2ch.net/test/read.cgi/company/1093497747/452

663 :774ワット発電中さん:04/12/10 20:43:04 ID:QpKkeIb0
Verilogの導入時、DCの導入時も同じようなもの・・・

「言語で回路を記述するだと、アホか」
「機械(w)が作った回路が動作するわけないだろ、第一サイズが
でかするぎるよ」
「回路はテンプレートで紙に書くものと昔から決まってんだよ」
「・・・・」

時代を先行するということは、今の技術の範疇では判断不可能な
部分もある。それなりのリスクが必要ということ。ビジネス提案に
対し、その程度の認識なら、言われたことやってば良し。

所詮、頭の固い時代遅れの技術者は、邪魔なだけ。逝って良し!

664 :774ワット発電中さん:04/12/10 22:41:20 ID:eQORYT+5
そう?漏れの所では「いいんじゃない?細かい所はゲートレベル
まで書けるし、テキストエディタでいいし」だったよ。
だいたい、あれはちゃんと合成して最終段階まで持って行けた
じゃん。だから、多少生成されたものの効率は悪くても、それに
見合うだけのメリットを見いだしてやることができた。
C合成だって、ちゃんと合成して石にするところまでいける。

でもSystemCは・・・事実上シミュレーションだけ?
もし、システム記述&シミュレーションだけというなら、
Schematic Vs Verilogと比較しようなんていうのは思い上がりも
甚だしい。

665 :774ワット発電中さん:04/12/10 23:50:35 ID:bO1vdVF+
>>664
後からならなんとでも言える。
リスクテイクせずに、恩恵だけ受けたやつが偉そうなこと言うな、バカタレが

666 :774ワット発電中さん:04/12/11 00:06:44 ID:7TaypKk8
恩恵を受けるのがいるからこそ普及するのだ。
それが判らん奴は共産主義国にでも逝ってろ。

667 :774ワット発電中さん:04/12/11 00:19:09 ID:q1FmNnEJ
>>666
リスクテイクして、恩恵を実証してるやつがいるから、初めて恩恵を
受けることができる。別に後追いのやつらなどが恩恵受けなくても、
普及するからOK。もともと日本は半導体もシステムもメーカが多すぎ。
きちんとリスクテイクしてくれている企業が設けてくれればそれで十分。

>それが判らん奴は共産主義国にでも逝ってろ。
競争原理の理解できないお前のような奴こそ、逝ってくれ。

668 :774ワット発電中さん:04/12/11 05:19:26 ID:mfF7ZIxS
>>663
ちゃんと、>>639 嫁! >>664 の主張は非常に的を得ていると思うが。

SystemCはHDLの合成可能なRTLと混載、または対応付け、という技術が
ちゃんと商用化されてからでしょ、合成は。先行メーカはSimulation
環境立ち上げ一辺倒ってのが正直な所。中には、本気で合成は無理
だと割り切っている先行大手もある位なんだから。その意味での普及
であって、HDLの普及とは性質が大きく異なる。

HDLとSystemCでは抽象度の向上のステップに大きなギャップがあり、それは
未だに埋められていないし、今後埋められる事がないかも知れない(多分、
無理、だってSimulation速度重視のための抽象度と、合成重視の抽象度は
余りに大きく異なるし、合成重視の抽象度でのSimualtion高速化は非常に
困難だから)。なので、>>639 のようなハイブリッドアプローチというのは、
「Simulationは高速に、一方で合成結果は最適に」、という我侭な要求に
答えるための妥協策として必然。

669 :774ワット発電中さん:04/12/11 05:20:51 ID:Rh47BBFy
>>668
それが解ってたらあんな間抜けなレスはしないであろう。

670 :774ワット発電中さん:04/12/11 05:26:01 ID:mfF7ZIxS
えーっと、これってもしかして……。

>>652 >>653 >>660 >>661 はIDが同じです。という事は……。

671 :774ワット発電中さん:04/12/11 09:20:34 ID:ilcQAhiS
15年前(ぐらい?)、合成なんて使い物になると思ってる奴なんか
一人もいなかったように記憶してるがな・・・できるできないという議論
よりmindsetの話をしてるじゃないの?やっぱり、技術の枠組みから
一歩も踏み出すことのできない頭の固いHW設計者の実態が浮き彫りに
なってるな 藁

技術の話にもどると

>Simulation速度重視のための抽象度と、合成重視の抽象度は 余りに大きく異なるし

これは的を得た指摘だ。しかし、間を結ぶ技術はできつつある。要するに片方の
抽象度で全てをやろうと思わないことだ。また、ふたつのモデルを作るのか、
などと的外れな質問しないように・・・それでも来そうだが・・・ヤレヤレ

672 :774ワット発電中さん:04/12/11 10:35:24 ID:mfF7ZIxS
>>671
> 間を結ぶ技術はできつつある。要するに片方の
> 抽象度で全てをやろうと思わないことだ。また、ふたつのモデルを作るのか、
> などと的外れな質問しないように・・・それでも来そうだが・・・ヤレヤレ

このスレで >>671 は何がしたいのだろう?

> また、ふたつのモデルを作るのか、などと的外れな質問しないように

これは、詐欺師と同じ手口の文言だね。

というか、>>671 は先ず、>>649-650 を嫁!で、「仮にパラメトリックな
ライブラリが構築可能と言っても、そのサポートシステムを考え出した人間
が想定していないような事が起こるとどうしようもなくなるんだよね。でも、
それが出来てこそ、商売が出来るんだよな。」というのを踏まえて、回答を
ここに晒してもうらおうじゃないか。

まさか、

 「インターフェースライブラリの開発は受注案件です。」

とか寄生虫商売考えてんじゃないよね?

まあ、他社の作ったツールのトレーニングで金儲けようと思っている時点で
十分寄生虫だよね > >>651

673 :774ワット発電中さん:04/12/11 10:39:01 ID:mfF7ZIxS
>>671
向学の為に、>>547 も嫁!

674 :774ワット発電中さん:04/12/11 10:43:31 ID:zWd5us/7
>>671
俺はあんたを支持する

675 :774ワット発電中さん:04/12/11 10:44:08 ID:Rh47BBFy
笑えるくらい同じID

676 :774ワット発電中さん:04/12/11 10:59:44 ID:mfF7ZIxS
>>675
そう、面白いでしょ(笑)。ID変えない方が。

>>674
じゃあ、頑張って投資してネ♪ そうすりゃ、>>652 の思惑通りになるなあ。
何か悔しいかも。

677 :774ワット発電中さん:04/12/11 11:12:38 ID:zWd5us/7
ID変えるの変えないのと、くだらんことを・・・
燕雀いずくんぞ鴻鵠の志を知らんや

678 :774ワット発電中さん:04/12/11 11:20:34 ID:mfF7ZIxS
>>677
大きく出たねぇ〜。じゃあ、頑張って巨額の投資を行って、皆が使える様に
する事で、その大志を貫き通して下さいな(笑)。

動作合成ツールを利用するのにRTLライブラリを構築しないとイケナイなんて
何か矛盾してるよね。その点、支那腐死巣の論理合成ツール君はしっかり
してたよね。演算器コンポーネントのライブラリを提供してたもんね。

そう、もうお気づきだろう。動作合成では、持つべきライブラリの複雑度が
増していて、初めから想定して全てを構築するのが非常に困難なんだよね。
世の中の動作合成ツールがイマイチなのは、AMBAインターフェースを除いて
論理合成と同程度のライブラリしかサポートしてないって事なんだよね。

でも、ライブラリのあるべき姿さえはっきりしないのが現状。さあて、
大志を抱いていらっしゃる >>677 さん、納得がいくように解決策を
ここに晒してもらいましょか!

679 :774ワット発電中さん:04/12/11 11:25:13 ID:zWd5us/7
>>678
>納得がいくように解決策を
>ここに晒してもらいましょか!

その手にのるか
アフォにすな


680 :774ワット発電中さん:04/12/11 11:32:14 ID:mfF7ZIxS
>>679
つまり、アイデアがない、或いは、あるのかも知れないが、大したアイデア
ではない、って事ね。まあ、そんなもんだろうね。

そういや、RTLリユースがうたい文句の動作合成ツールってあったよね?
あれって、どうなったんだっけ?

681 :774ワット発電中さん:04/12/11 11:34:44 ID:zWd5us/7
べー

682 :774ワット発電中さん:04/12/11 11:35:49 ID:XBQ7u2k8
>15年前(ぐらい?)、合成なんて使い物になると思ってる奴なんか
>一人もいなかったように記憶してるがな・

記述から落とすということなら、PALの時代からPALASM
だのって使わなかったか?ヒューズマップ一本やりでやってたのか?
もうちょっとややこしい物だって書いて落とせるようになるよな・・と
普通の感覚してる香具師なら思ってたよ。

683 :774ワット発電中さん:04/12/11 11:37:37 ID:XPBmE5sw
ごきげんよう暇人ども

684 :774ワット発電中さん:04/12/11 11:43:47 ID:mfF7ZIxS
"RTLリユース" 動作合成 でググったら、何も出て来んかった…… orz

でも、"IPリユース" 動作合成 でググったら、トップに

 [PDF] Y Explorations 社 C 言語高位合成ツール「eXCite」 ...
 http://lsi.soliton.co.jp/others/040930_excite1_nr_j.pdf

が出来てきた。どうやら、ANSI-Cベースだが、RTLのリユースも出来る
らしい。

685 :774ワット発電中さん:04/12/11 11:57:19 ID:o+2Zcw2E
>>684
元◎立君
こんな所で釣りはやめたまえ
◎立 systemc でっググったら トップになんと


686 :774ワット発電中さん:04/12/11 12:04:00 ID:HoQLAUdK
◎はお日さまのことか? なるほど

687 :774ワット発電中さん:04/12/11 12:08:26 ID:mfF7ZIxS
>>685
◎立 systemc でググると
  日立IT ニュースリリース 新世代設計規範 ...
  http://www.hitachi-it.co.jp/news/030101.htm

日立 systemcでググると
  日立IT|製品情報|論理記述言語 ...
  http://www.hitachi-it.co.jp/dvedu/sysc/

???

688 :774ワット発電中さん:04/12/11 12:27:14 ID:8G2BbHe+
いけね 釣り手伝ってしまった

689 :774ワット発電中さん:04/12/11 12:58:28 ID:ITyuGMOi
>>671 
禿同(余談だが的を得たではなくて的を射ただ)

690 :774ワット発電中さん:04/12/11 13:20:47 ID:KAjSZB+y
>>689
> ふたつのモデルを作るのか、などと的外れな質問しないように・・・
> それでも来そうだが・・・ヤレヤレ

この部分にも賛同するの?

691 :774ワット発電中さん:04/12/11 16:25:19 ID:ZAAp1ztO
だから二つのモデルは必要ないんでしょ・・・
それだけで、どういう流れになるかすぐ分るよ。で、俺的にはなるほどな、と。
合理的かつ現実的な解だなと、思うわけだな。

692 :774ワット発電中さん:04/12/11 16:28:32 ID:ZAAp1ztO
>>682
いわゆるSilicon Compile社が最初提唱きてきた合成のことをいうのであって、
PALはその中に含まれないんじゃないの?PALは期待通りのものができるよ。
つか、ありゃ変換だべ w

693 :774ワット発電中さん:04/12/11 17:00:29 ID:ITyuGMOi
>>690
あ。しません(悩みどころなんだが)


694 :774ワット発電中さん:04/12/11 17:00:56 ID:ITyuGMOi
あげちゃった。すまん

695 :774ワット発電中さん:04/12/11 17:13:13 ID:Ablr5ipR
ハードウェアアルゴリズムは、
並列性、コスト、遅延時間の制約などソフトウェアアルゴリズムと異なる点が多い。
そのため様々なハードウェアアルゴリズムを使い分ける必要がある上に、
演算のスケジューリングとリソースの共有化を考慮する必要がある。
簡単な例として、入力を複数の定数で乗算した結果を出力する複数の
定数乗算回路(MCM)を考える。
定数の乗算は部分積のシフト加算に置き換えられるが、
乗算器を個別に合成するより、加算の順序を入れ替え、
演算器を共有した方がはるかに小さい回路となる。しかし、
問題は同一の機能を満たす回路は多数存在するということである。
特に機能が複雑になるとその組合せは膨大な数になり、
すべてを調べることは非現実的となる。
このような膨大な組合せの中から
最適なものを発見する問題を組合せ最適化問題と呼び、
最近、人工知能の分野で発展してきたシミュレーテッドアニーリング(SA)、
遺伝的アルゴリズム(GA)、
タブーサーチ(TS)などの知的最適化アルゴリズムが様々な分野で応用されている。

このような最適化アルゴリズムを利用すれば、
回路モデルとその評価式を与えるだけで、
ハードウェアとして最適化された回路仕様を自動的に合成することが可能となる。




696 :774ワット発電中さん:04/12/11 17:50:37 ID:KAjSZB+y
>>691
釣り? てか、マジありえねぇー。高速Sim用のSystemCモデル、書いた事
ないっしょ?

>>695
だから、腐汚流手はDSPアルゴリズムしか対象としていない、と断言する
わけだ。そうしたデータ演算系の設計なんて、実際の設計のごく一部なの
が現実。メモリアーキとかはどうするわけ? 現状、これを自動で最適化
する技術は残念ながら無いよ。あったら凄いね、フォン・ノイマン・
ボトルネックとかプロセッサ・アーキテクチャの進化を自動で実現出来る
わけないからね。プロセッサ・アーキは芸術の世界だからね。

さて、支那腐死巣のSystemCのSimulationのメインエンジンを開発した張本人
が書いたこんな論文もあるが、それにはSystemCマンセー の方はどう反論して
下さるのだろうか? ちょと、見ものだね。

The Challenges of Hardware Synthesis from C-like Languages
http://www1.cs.columbia.edu/~sedwards/papers/edwards2004challenges.pdf
http://www1.cs.columbia.edu/~sedwards/presentations/iwls2004.pdf

この論文では、SystemC = Verilog in C++、となってるね。

In summary, I believe the next great hardware specification language
will not closely resemble C or any other familiar software language.
Software languages work well only for software, and a hardware language
that does not produce efficient hardware is of little use.

まあ、これはちょっと言い過ぎのような気もしなくはないが。でも、気持ちは
物凄くわかるかも。

697 :774ワット発電中さん:04/12/11 22:11:50 ID:M3VuMh3A
>>696
おまえ、GAなめてるだろ?
評価関数に全体処理速度を入れとくだけで
ネックになる箇所に勝手にキャッシュを入れるよ。

698 :774ワット発電中さん:04/12/11 22:35:24 ID:XBQ7u2k8
システム”設計用”の言語だとというから角が立つ
システム”検討用”の言語だと言っておけば良い

699 :774ワット発電中さん:04/12/11 23:39:00 ID:L1a72X4h
Genetic Algorithm
HALの世界観に近いけど分かるかな?
わかんないよね

700 :774ワット発電中さん:04/12/12 01:13:00 ID:C1kWyKV1
>>696
>>691
>釣り? てか、マジありえねぇー。高速Sim用のSystemCモデル、書いた事
>ないっしょ?

なんだよ、高速Sim用のSystemCモデルって?UTのことか?レベル低すぎて
なんのこと言ってるかわかんねえぞ。お前のようにお試しでモデル書いてる
ような奴と議論してる暇はないんだよ。
つか、情報足りなさ過ぎだ、お前。偉そうな口きくまえに、各社のProduct
Roadmapぐらい情報仕入れておけ、ボケが。


701 :774ワット発電中さん:04/12/12 03:24:56 ID:rHTzeNw9
>>ALL
ここの話題の登場人物は世の中に利用されているLSIを設計
しているのですよね。お金稼いで、飯食ってるわけだ。ふう〜ん。
各社のロードマップか。ふ〜ん。
鬼畜なブッシュに先導される国に日本の技術者がジタバタとしている図。

オイオイ、このスレはEDA社員に盗聴されているらしいぞ。気をつけろ。
ふう〜ん。(自嘲)

702 :774ワット発電中さん:04/12/12 03:38:08 ID:rHTzeNw9
HW設計って、オブジェクト指向型の設計なんですかねぇ。「そうなんだろうな」
と思うけど。だってさぁ。入りがチョット違うと、それなりに違った物が
出てくるわけじゃない。それってOODってやつなんでしょう。SystemCはC++の
バッタもんなわけだから、オブジェクト指向言語なわけじゃない。
まともにHW設計できないのは、C++が綺麗じゃないからかもね。
もともと、SW設計用の言語だからかね。
↑と同じIDです。先に逝っておかない(言っておかない)と怖いのでちゅぅ。


703 :774ワット発電中さん:04/12/12 03:43:13 ID:bdc8fApl
つーかHDLを導入して未だ十年も経ってないのに又大変革かよ勘弁してくれ
ってのが正直な所。
で、オブジェクトなんとかとかトップダウン云々言ってても仕様が流動的で
結局設計はボトムアップなんて事は普通だから、回路図がHDLに変わって
Simできるとかってメリット以外は力業の連続なわけで多分道具がCになろうが
この辺りは変わらないんだろうなと思う。
なもんで、使えるツールてか寺のツールが対応したら嫌でも導入って事になるだろう。
あまり感慨がないなぁー。
ぶー。

704 :774ワット発電中さん:04/12/12 03:56:26 ID:rHTzeNw9
>>703
納得。最終形を見るな。その過程ってことね。じゃあ、何でも良いならSystemC
でも言い訳で。毛嫌いされるのはかわいそうな話である。ふむふむ。
昔は、DCもないし、Simもないし。その頃は、「ぶー」って言う場所もなし。
なるほど。
誰があの「マトリックス」の様な世界に連れて行ってくれるのだろう。
「ユビキタス」懐かしい響きだ。 「指切った」に聞こえる。
叙情。

705 :774ワット発電中さん:04/12/12 03:58:41 ID:rHTzeNw9
言い訳で。→ 良いわけで

706 :774ワット発電中さん:04/12/12 04:06:57 ID:NClMqcqP
c++もどきなんかじゃなくて、LSIがLabviewのような
もので設計できたらすごいよな。
極めて抽象度の高いGUIでデータフローを書くだけ。

707 :774ワット発電中さん:04/12/12 04:07:53 ID:NClMqcqP
一度Labview使えばわかるが、計測・制御目的にc++書くのなんて
馬鹿馬鹿しくてやってられなくなる。

708 :774ワット発電中さん:04/12/12 04:10:06 ID:bdc8fApl
究極的には何でも良いって点はまーそうだ罠。
生き残った奴が偉い。そう言うこと。
仕事の都合でVHDLとVerilog両方使えるのが割と当たり前なのがこの業界だし。
しかし、論理合成の癖を加味した記述とかRTLにかみ砕いた記述なんてのは今でも
当たり前だし道具が変わろうがこの点は暫くかわらんだろうさ。

709 :774ワット発電中さん:04/12/12 04:12:35 ID:NClMqcqP
Matlab+simulink→DSP
ってのが既にあるじゃん。

Labview→PSOCみたいなののもっとすごいの

っての誰か作ってくれよ。

710 :774ワット発電中さん:04/12/12 05:04:35 ID:rHTzeNw9
>>708
納得。生き残りさえすればOK。死ぬなよ、諸君。
諸君、ツールに合わせてたばっかりに、自分のやりたいことを出来ない。
そんな思いは捨てて。
ツールの奴隷となれ! さもなければ逝くしかない。

711 :774ワット発電中さん:04/12/12 05:19:13 ID:rHTzeNw9
A氏:そこらへんのSystemCを信用するな。 ************こと。 間違いない。
B女史:あんた、どこ見てんのよぉ。 (目を剥き、逆ギレ)<=逝ったEDA屋
C侍:って、 Youじゃない。 でも、SystemC君は*********ですから、残念。
***********斬り。拙者もLSI屋に厄介になってます。 切腹。
>>ALL
誰か**********を埋めてくれ。 私は逝く。
ドドーン。楽しかった。

712 :774ワット発電中さん:04/12/12 05:30:34 ID:bdc8fApl
つまらん

713 :774ワット発電中さん:04/12/12 05:31:08 ID:n+MGMwpx
>>697
おまえ、キャッシュなめてるだろ? 待ち行列理論で綺麗に最適化できない
のがネックなの知らないのか? 汎用的になればなるほど、データの局在性
を分布で表すにはムリがあるからな。

それに、メモリアーキはキャッシュだけじゃないぞ。つうか、設計した事
あんのか?

714 :774ワット発電中さん:04/12/12 05:51:19 ID:1HTg2VCE
SystemCの参考書、どんなの使ってます?

715 :774ワット発電中さん:04/12/12 05:54:41 ID:n+MGMwpx
>>700
UT? ハァ? >>280 は見たか? それと >>385 への回答は結局 >>606 とか
>>608 。で合成への期待感が出てきたのは、>>639 。更に、それが現実的か
をきちっと議論しないとイケナイんだが、それにまともに答えようとして
いるのが、>>649-650

一方、>>671 は精神論しか言ってなくて何の信憑性もない。で、>>691 >>700
はそれを盲信しているだけ。流石に、根拠無くSystemCの合成が何でも可能
という風に話しを持っていこうとしいるとしか考えられないな、この3つ
のレスは。

716 :774ワット発電中さん:04/12/12 05:56:37 ID:n+MGMwpx
(続き)

現実的なのは、>>708 とかかな。NEシー のがそうだっていうのは
 http://tmp4.2ch.net/test/read.cgi/company/1093497747/302
で暴露されていて、それでも
 http://tmp4.2ch.net/test/read.cgi/company/1093497747/305
なんて問題点があるらしい。まあ、この辺りは、どのSystemC合成ベンダも
「どういったハードを想定して、このような記述をされたのですか? 」
という風に聞いてくるからね。

>>696 の論文はかなり過激だけど、的を射ているとは思うよ。でも、Cベース
が俺個人としても、有り難いんだけどね。

717 :774ワット発電中さん:04/12/12 06:04:01 ID:n+MGMwpx
>>714
先ず、

 ハードウェアエンジニアのためのC++講座
 http://www.testbuilder-jp.com/inno/tu/cpp/p1.html

で、C++ のおさらいをしたあと、

 SystemCの薦め
 http://www.testbuilder-jp.com/inno/tu/sysc/index.html

を一通り読んで実行してみてから、OSCIが出しているUser Guideを読むのが
良いと思われます。で、記述して実際に動かすのが重要なんですが、LRMも
参考にされながら、例えば値変化によるイベントの発生ってどう扱っている
んだあ?とか興味を持ってソースを読んで見るのも良いと思います。

頑張って下さい。

(また、ID同じで一杯書いてしまった…… orz)

718 :774ワット発電中さん:04/12/12 06:30:16 ID:n+MGMwpx
>>697
もしかして、これ↓↓↓ の事?

 GAスケジューリングによるリアルタイムマルチプロセッサ自動合成システム
 http://www.mil.se.ritsumei.ac.jp/pdf/j85-c_12_1216.pdf

この大学ね。教授も大変だよね。学生が……だから。つうか、もし君が学生
なら狼狽心ながら言っておくが、就職の面接のときに、

 「組み合わせ最適化アルゴリズムは沢山あるが、何故GAを選択したのか?」

くらいの質問には軽く答えられるようにしとけよ。研究を行うときに、学生
がその背景や同行とかをきちっと押さえていない傾向が強いんだよね、君ん
とこみたいな中途半端な大学は。

で、何故にGA?

719 :774ワット発電中さん:04/12/12 09:31:26 ID:Zpgfc76x
>>715
御託はいいけど、>>700に対する答えは?
高速sim?口だけなのがバレバレ?ちゃんと説明して、あなたの「高速sim」って
なんの事なの?

720 :774ワット発電中さん:04/12/12 10:56:44 ID:n+MGMwpx
>>719
お前、>>280 読んでも解らんか? だとしたら、レベル低杉。というか、後発
組みの落ちこぼれ君かあ。じゃあ、CoWareに大枚はたいて導入すれば。でも
APIの記述テクニックは教えてくれんだろうけどね(笑)。まあ、頑張れ。この
スレで、そこまでお人良しに教えるバカは居ないよ。

721 :774ワット発電中さん:04/12/12 11:23:37 ID:dKOfOtHW
>>714
参考書じゃないけど
http://www.testbuilder-jp.com/index.html
がすごく役に立ったyo
ここでの議論がばかげていることも分かる

722 :774ワット発電中さん:04/12/12 11:26:52 ID:gYatB/TJ
結局答えられないんじゃん・・・

723 :774ワット発電中さん:04/12/12 11:38:43 ID:C1kWyKV1
>>720
719は分ってて、715をからかってるんだよ。議論の流れを読もうぜ。

724 :774ワット発電中さん:04/12/12 11:38:44 ID:dKOfOtHW
>>722
答えるのがばかばかしいんじゃない?
分かってる?
SystemCの薦め
 http://www.testbuilder-jp.com/inno/tu/sysc/index.html
読んでからまた書き込みたら?
8章 9章まで読み終わって理解しないと
>>720には勝てない




725 :774ワット発電中さん:04/12/12 11:40:17 ID:C1kWyKV1
って、715=720かよ w
なんとお粗末な・・・

726 :774ワット発電中さん:04/12/12 11:41:46 ID:bdc8fApl
IDの仕組みを解ってないのかもな。
てか、漏れのレスを引用しないで欲しいな。

727 :774ワット発電中さん:04/12/12 11:45:18 ID:UD5Nry2c
>>724
逃げは良くないね。ちゃんと答えて欲しいよ。
検証用モデルから合成用モデルの合わせこみに関して、ベンダーから
いろいろ情報が流れてる状況で、ばかばかしい内容でもレベルでも
ないことは、本人がよく分かってるはずだけどね。

728 :774ワット発電中さん:04/12/12 11:53:11 ID:gYatB/TJ
答えるのがバカバカしいとかやめてほしい
議論してるんだから・・・

「引用読んでもわからないのか?」
とかで返すのは
「だからチョンはダメなんだ」
って言ってるようなヤツと同じじゃん

携帯板やニュー速じゃないんだから冷静に行こうぜ

729 :774ワット発電中さん:04/12/12 12:31:47 ID:b2xhpVjl
これ嫁

!!! "It's not a BUG,
/o o\ / it's a FEATURE!"
( > )
\ - /
_] [_

ttp://www.deepchip.com/items/dac03-04.html

730 :774ワット発電中さん:04/12/12 12:46:38 ID:ps/V3gzO
それとこれもふるいけど参考になる
ttp://www.deepchip.com/items/dvcon04-03.html

731 :774ワット発電中さん:04/12/12 12:54:14 ID:n+MGMwpx
>>725
だから、ID変えないって言ってるだろうが。

しかし、APIというヒント出しても解らんヤツが、良く >>691 みたいな事を
言えるな。質問があるなら、SystemC勉強中が見せたくらいの礼節をわきまえ
ろよな。まあ、それでも当然教えないけどね。

SystemCの醍醐味はTLMで、プロセス間通信のAPIを如何に作り込むかがポイント。
この部分は、例えばCoWareがAMBAのアクセスAPIをBinaryで提供(販売)している
ように、商売ネタだから誰も教えてくれんと思う。勿論、私も答えない。いくら
何でも守秘義務ってのもあるしね。

732 :774ワット発電中さん:04/12/12 13:13:26 ID:5gkY21wA
>>731
桜#さんでツカ?
ヒント出しすぎ

733 :774ワット発電中さん:04/12/12 13:26:50 ID:5gkY21wA
ところで
>>729 >>730
読めないよ
消えてる

734 :774ワット発電中さん:04/12/12 13:38:02 ID:n+MGMwpx
>>733
ちゃんと読めるが。SystemC何て使い物になるか、ぼけぇー、的な内容では
あるが、状況は米国と日本じゃ異なるし、先行している ST Micro の意見を
参考にするのが日本の現状に会っていると思うよ。

735 :774ワット発電中さん:04/12/12 13:53:20 ID:5gkY21wA
>>734
読めました。
だけど言語がSystemCでなく英語なのでやっぱり読めません(笑)
それより桜#さんn+MGMwpxのID固定はどうすればできるのですか?(仮に桜#さんとしときます)


736 :774ワット発電中さん:04/12/12 17:21:06 ID:5gkY21wA
>>714
これも読め
ttp://www.starc.or.jp/kaihatu/hldgr/documents/subject_investigation.pdf

737 :774ワット発電中さん:04/12/12 17:22:20 ID:5gkY21wA
ID固定わかりました
はは

738 :774ワット発電中さん:04/12/12 19:35:43 ID:l0JImPDy
このスレに来てる人って、エンジニアとか理系学生でしょ? 英語読めないの?
それって、マズくない?

739 :774ワット発電中さん:04/12/12 20:12:55 ID:NClMqcqP
>>718
おれそんなレベル低い大学行ってないから。
GAなんて俺にとっては一般教養レベルなんだよ。

740 :774ワット発電中さん:04/12/12 20:14:51 ID:NClMqcqP
でさぁ、何だって効率の悪いc++なんかお手本にしてるわけ?
この分野こそGUIプログラミングが最適だろう。SimulinkとかLabviewのような。

741 :774ワット発電中さん:04/12/12 20:20:06 ID:NClMqcqP
>>718
なぜにGAかだと?
そんなもん解空間が離散的すぎてSAやタブーサーチではお話にならないからだろ。

742 :774ワット発電中さん:04/12/12 20:33:57 ID:n+MGMwpx
>>739
一般教養なのは常識として、問題なのは、何故にGAをメモリアーキ最適化に
用いようとしたかの動機なんよ。良かったら、他の組み合わせ最適化との比較
を交えて、何故GAとして定式化して解くのが良いのかを教えてくれない?
宜しくです。

メモリアーキの最適化に関しては、がーびぃ の著作である
 Memory Architecture Exploration for Programmable Embedded Systems
 http://www.amazon.com/exec/obidos/tg/detail/-/1402073240/qid=1042775764/sr=8-1/ref=sr_8_1/103-4254399-6973414?v=glance&s=books&n=507846
が結構有名だよね。

>>740
HDLで、GUI系ツールが駄目だったからね。あと、テキストで編集できる
お手軽さは結構重要だよ。確かに、C++ をお手本しにしている時点で
SystemCはDead Copyだと言えるよね。SystemC2.0の開発動機は、システム
アーキ検討のための高速なSim Model作成の容易化だから、その意味では
C++ という選択肢も悪くはないと思うんだけどね。うーん、ちょっと難しい
です。

743 :774ワット発電中さん:04/12/12 20:44:06 ID:n+MGMwpx
>>741
有難う。て事は、突然変異のさせ方が非常に重要になるって事だよね? 論文
とかは執筆してないの? 執筆していたのなら、タイトル等を教えて下さいな。

744 :774ワット発電中さん:04/12/12 21:11:44 ID:n+MGMwpx
>>741
> 回路モデルとその評価式

これは具体的には何? 例えば、SDRAMをメモリとして用いる場合、リフレッシュ
モードをどれにするかとか、バンク有り無しをどうするかとか、様々なパラメータ
が存在し、且つ、SDRAMの前段にFIFOを置いて初期レイテンシを隠蔽するなん
てのも結構ありありで設計したりするんだけれど、その辺り全部の組み合わせ
とか言い出すと、設計パラメータすら数え切れなくなるんだけど、それに
メモリの種類はもっと沢山あるし、どうなの? で、評価式、これは具体的には
何?

745 :774ワット発電中さん:04/12/12 21:20:51 ID:NClMqcqP
>>742-743
別にそんなん専門でもないし論文も書いてないが、
GAの一般論からして、有効に働く回路ブロックの単位と
有効な遺伝子型の対応がつきやすいからだろ。
つまり一度できた有効な回路ブロックはほんの少し変化させてもドラスティックに性能指標が
変化しうる。
突然変異以外では有力な遺伝子型を基本的に保存する方向に働くというGAの性質は
この既に有効な回路を破壊しないという性質とうまく合致するだろう。

重要なのは変異の方法ではなく、回路要素をどう遺伝子型にインプリメントするかだと思われる。
これをうまくやったときは既に有効な回路を破壊しないという性質がうまく出てくるがそうでない場合は
現れない。


746 :774ワット発電中さん:04/12/12 21:21:46 ID:NClMqcqP
まぁもし俺がその分野を研究するなら、回路要素の遺伝子型へのインプリメント法自体を
メタ問題としてGAで最適化するね。

747 :774ワット発電中さん:04/12/12 23:02:42 ID:UeNEF0Lq
>>NClMqcqP
やっぱり桜#さんだったのですね。
全部本持ってます 私のバイブルです
何で、Verilog/VHDLから転向したか教えてくださいよー

748 :774ワット発電中さん:04/12/12 23:07:13 ID:oRRWv2zH
あっ間違えたな
n+MGMwpxが桜#さん
まいっか 
二人とも桜#さんで

749 :774ワット発電中さん:04/12/12 23:16:13 ID:f7kiDebL
変なの釣り上げて面白い?

750 :774ワット発電中さん:04/12/13 05:31:15 ID:9m+Mo/2I
>>745
一般的に回路アーキは、特に、データ転送などメモリアーキを主体に考えた
場合、オープンな待ち行列ネットワークになる。確かに、少しの変化が系内
待ち時間などネットワークのトラフィック性能にドラスティックな変化を
与える。

が、問題なのは、分布を一概に与える事ができないため、そのネットワーク
のトラフィックに関する性能指標というのを定式化できないという事である。
確かに、データが一方向にしか流れないような単純なものであれば、可能
かも知れないが。

GAとして定式化する場合、その性能指標を与えなければならないが、それが
対象とする待ち行列ネットワーク毎に異なり、かつその決定が困難だという
問題がある。

その意味でGAが有効かどうかは疑問が残る。


>>746
初期設定はファジイ推論でもよくね? でも、計算時間凄くなりそうだね。

751 :774ワット発電中さん:04/12/13 09:32:19 ID:lzKmj7jc
遅レス スマソ。>>691 >>700 の根拠ってもしかして、これ?

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

  http://www.yxi.com/news-2004-11-11.htm

  http://www.yxi.com/Library/excite%20expert%20datasheet%206_2_04.pdf

何だか色々釣れてて否定的な意見も多いみたいだけど、個人的には2つ
用意しないで良い方向に技術が発展して欲しいっす。素人の願望、スマソ。

752 :774ワット発電中さん:04/12/13 12:07:35 ID:YKqVGp/i
>>731
だからさ、逃げないでちゃんと答えてくれないかな?

>しかし、APIというヒント出しても解らんヤツが、良く >>691 みたいな事を
>言えるな。質問があるなら、SystemC勉強中が見せたくらいの礼節をわきまえ
>ろよな。まあ、それでも当然教えないけどね。
こんなことは、俺にとって常識なんだよ。何をいまさら、つまらんこと出して
ごまかすんじゃないよ。

某高位合成のためのPxxxxxxレベルへ某設計ツール用のBxxxxxxレベルの
変換はそのうちできるのかな?で、どっちが作るのかな?

まあ、ともかくさ、"高速sim"について説明してもらおうか?
ちなみに >>280 は俺だよ。



753 :774ワット発電中さん:04/12/13 12:16:40 ID:YY5ogNp1
>抽象度を上げたときに何が難しいかって、モジュールの動作記述
>ではなくて、APIでのモジュール間のコミュニケーション記述

賛同しまつ

754 :774ワット発電中さん:04/12/13 12:29:47 ID:7biU3tdt
>>752
しつこい厨でつね。見ていて情けなくなって来まつ。ある意味、哀れでしゅよ
高卒君。


> 某高位合成のためのPxxxxxxレベルへ某設計ツール用のBxxxxxxレベルの
> 変換はそのうちできるのかな?で、どっちが作るのかな

これはどうみてもライブラリベースじゃないとムリでつね。プラットフォーム
ベースの固定バスのみを用いて設計する分には十分でつね。それじゃ、半導体
屋さんは商売にはならないだろうから、辛いでつね(笑)。

755 :774ワット発電中さん:04/12/13 12:46:18 ID:raOCnBHA
>>752
もう苛めるのはやめたら? そいつは口だけ厨房って事でいいんじゃない?
でも、もし知っているんだったら、ここに暴露して欲しいっす。分っていて
黙ってるのだとしたら、それはある意味その厨房より酷いっすよ。

ちなみに、変換じゃなくて、バスモデル化手法を定めてそこから両方同時に
生成するというのはどうだろう? この方が現実的だと思うが。

756 :774ワット発電中さん:04/12/13 14:03:50 ID:l2f0aIzS
>>750
もちろん一般的なデータフローの分布に対してすべて効率よいような
回路など存在しないのだから、実用で使われる分布を
モデルとして与えて性能指標の評価関数を作ると思われる。
というよりそもそもどういう使い方をするかという事前の情報がなければ、
人間だって設計できないw

757 :774ワット発電中さん:04/12/13 14:08:14 ID:dZrpB+sB
>>754
口だけ厨が答えれば、いいたけじゃないの?
情報欲しいから、もっと頑張って欲しいな >>752 には
それともあんた口だけ厨本人かな? 


758 :774ワット発電中さん:04/12/13 15:46:35 ID:ekrPulmA
まさか、>>752 = >>757 じゃないよね?

口だけ厨でも >>752 でもどっちでも良いから、情報きぼんぬ! 実は両方とも
厨だっていうオチかも…… orz


759 :774ワット発電中さん:04/12/13 15:52:44 ID:/VJfCegc
>>756
て事は結局、わりと具体的なメモリアーキの構成は人手で指定で、サイズ
などの細かなパラメータのチューニングにGAを用いるって事ね。それなら
納得。アナログの自動設計に似たアプローチって事だね。

まあ、となるとモデル化というか記述作成が必然的に必要になると。ここは、
>>752 さんがどうすべきか答えてくれるって事だね☆。>>752 期待してるぜ!

760 :774ワット発電中さん:04/12/13 15:58:03 ID:l2f0aIzS
>>759
GAにパラダイムシフト的な新アーキテクチャの創造を期待するには
それこそ歴史的な計算時間が必要になると思われる。

761 :774ワット発電中さん:04/12/13 16:01:32 ID:/VJfCegc
その前に、メモリアウトでしょw

762 :774ワット発電中さん:04/12/13 17:39:38 ID:q2OB8EkK
              ☆ チン     マチクタビレタ〜
                         マチクタビレタ〜
        ☆ チン  〃 ∧_∧    / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・) <  >>752 口だけ厨、情報まだ〜?
             \_/⊂ ⊂_ )   \_____________
           / ̄ ̄ ̄ ̄ ̄ ̄ /|
        | ̄ ̄ ̄ ̄ ̄ ̄ ̄|  |
        | .佐賀みかん.  |/

763 :774ワット発電中さん:04/12/13 17:53:08 ID:iuhtYLGW
>>ALL
あの〜、>>731

> SystemCの醍醐味はTLMで、プロセス間通信のAPIを如何に作り込むかがポイント。
> この部分は、例えばCoWareがAMBAのアクセスAPIをBinaryで提供(販売)している
> ように、商売ネタだから誰も教えてくれんと思う。勿論、私も答えない。いくら
> 何でも守秘義務ってのもあるしね。

とか言ってるから、どう考えても答えてはくれないんじゃない? ここは、
>>752>>753 くらいしか居ないんじゃない、答えてくれそうなの。
頼むぜ! >>752 >>753

764 :774ワット発電中さん:04/12/13 19:12:45 ID:l7ZpSCoQ
>>763
恐らく、>>752 >>753 は単なるCoWareユーザではないかと思われ。従って、
ただの クレクレ 厨。APIの記述テクなど知るわけも無い、単なる真性厨房と
思われ。

  知恵のないヤツァ、金を出せ (CoWareに大枚はたく)

  金のないヤツァ、汗をかけ (HDLでシコシコ頑張る)

それだけのことだと潔く割り切って諦めろ。

765 :774ワット発電中さん:04/12/13 19:27:46 ID:R08AHgIR
手段を選ばない情報の引き出し方を試みる >>752>>757 (同一人物?)
はまさしく、チュンやチョンと一緒だな。こいつ(ら)が、日本人でない
事を願うのみだよ。さっさと半島に帰れ、寄生虫!

766 :774ワット発電中さん:04/12/13 21:40:01 ID:Q4W8grT3
>>714
最初、これ読むといいかも
http://www.kumikomi.net/article/review/2003/05SystemC/05.html

767 :774ワット発電中さん:04/12/13 23:31:11 ID:cRsR0Enx
>>764
http://ne.nikkeibp.co.jp/members/NEWS/20041213/106823/
確実に先行している会社はリスクを取ってでも導入を決定してる現実がここにある

>知恵のないヤツァ、金を出せ (CoWareに大枚はたく)
たかが知れてんだろ 馬鹿じゃないの!
お前の会社もしかして1000万超えるツールは買えないんで自社開発に励んでる?
それで、C言語設計にのべ15億もつかっちまった会社知ってるけどねーーー

我社上流のツールなんてDA予算のコンマ数パーセント
(引用した会社じゃない事は一応ことわっておく)
Magmaツールの消費税にも満たないよ。

ちなみにここはバリバリCoWareユーザだよ
公表してないけどーーーさらに、フォルテも検討中
ヘンデルは去年から一部使ってる

SystemCツールはシノプシスもケイデンスも、
メンターもSeamlessCVEも勿論ある。セラロも3年前に買った。

大枚はたくって! あなた昔CoWareに馬鹿にされたんじゃないの、
貧乏会社だから


聞いたことあるけど、数十万数百万円じゃ
今時まともなEDAツールなんか手に入らないよ。
FPGAやゲートアレーのツールと勘違いしてないか
はぁ
CAD予算500万円超えると稟議に2年ってあなたの会社でしょ。
せいぜいMATLABがいいツールだすのにでも期待しておけ!

なお、うちのDAは大枚はたいた知恵の無いやつでしたが成功しそうです


768 :774ワット発電中さん:04/12/13 23:53:43 ID:J+dWVWSb
>>767
哀れだな

769 :774ワット発電中さん:04/12/14 00:03:57 ID:X0mjJa39
>>767
導入・評価できる環境がうらやますぃ

770 :774ワット発電中さん:04/12/14 00:05:02 ID:LUAM8h6o
>>768
目潰電機

771 :774ワット発電中さん:04/12/14 00:06:26 ID:LUAM8h6o
>>767
スマソ
目潰電機


772 :774ワット発電中さん:04/12/14 00:08:48 ID:LUAM8h6o
Matlabは会社名ではなくて商品名
ザ・マスワークスが会社名

773 :774ワット発電中さん:04/12/14 00:09:03 ID:yY1pDJh3
確実に先行している会社はリスクを取ってでも導入を決定してる現実がここにある

日経の記事なんて引用しなくてはならないほどに
無様な状況に焦っているということか・・・・(哀

774 :774ワット発電中さん:04/12/14 00:10:35 ID:LUAM8h6o
ここの人たち商品名と会社名よく間違えるねー
だからばれちゃった
あとセラロ
おかねもっち

775 :714:04/12/14 01:08:07 ID:qnZhMctC
>>717 >>721 >>736 >>766
レスどうもです。ありがとう。
とりあえず>>766で紹介された「SystemCによるシステム設計」をアマゾンで注文。
あとはネット上の情報も参考にしつつ勉強しようと思います。

776 :774ワット発電中さん:04/12/14 04:19:48 ID:CHhx+5u9
SystemCによるシステム設計は糞本だからやめたほうがいい。

777 :774ワット発電中さん:04/12/14 09:27:37 ID:z8b56XlV
どうクソ本なのか言わないと、単に国語の成績が悪くて
本が読めなかった奴と思われて終わりだぞ。

778 :774ワット発電中さん:04/12/14 11:20:47 ID:rPUV7HH6
>>775
いい本ですよ 心配しないでOK
実用書としては
SystemCによるJPEGコーデック設計も参考になりました
ISBN:4320120817
http://bookweb.kinokuniya.co.jp/guest/cgi-bin/wshosea.cgi?W-NIPS=9977587132

779 :774ワット発電中さん:04/12/14 11:30:44 ID:2cN9T4qC
>>777
たぶん>>776は読んでいないというか、
どう読めばいいかわからないで、初めの40ページで躓いた
そして読み飛ばすこと最終章
でしょ? TL何のことか、何のためかわからないよね
わからなければ糞本 勿体無い


780 :774ワット発電中さん:04/12/14 14:18:19 ID:B18yZjQZ
>>751
確かに、HY-CとかいうCの拡張言語を定義していて、

  HY-C −−> SystemC
  HY-C −−> HDL RTL

へと合成してくれるらしい。2つ書く必要ないのかも……。うーん、謎。

781 :774ワット発電中さん:04/12/14 14:48:50 ID:aL96MfRF
>>776
 ハードウェアエンジニアのためのC++講座
 http://www.testbuilder-jp.com/inno/tu/cpp/p1.html

をきちっと理解してから、「SystemCによるシステム設計」を再度読まれる事
をお勧め致します。ちょっと、敷居が高いのは事実です。でも、勉強して
決して損にはなりませんから。頑張って下さいね。

782 :774ワット発電中さん:04/12/14 14:54:50 ID:aL96MfRF
>>767
しかし、15億は凄いな。ちなみにそれって、もしかしてS ?

P はCoWareの対抗馬でARMに買収されちゃったEDAベンダのを採用してた
みたいだけど、どうなったんかいね?

783 :774ワット発電中さん:04/12/14 15:55:04 ID:IgympgVb
>>782
767ではありませんが、知っていますよ。何処だか
でも恐くて言えない

でも15億円はそんなにおかしな予算ではないのではないかと思います。
実際自前で構築しようとすると、組織も含め相当な体制を作らないといけないから。
実際に国家プロジェクトの時も、各会社が手弁当で参加したけど、
それでも20億円の大切な税金が3年間投入されたしね。
でもこの国は2500万円も先端技術に費やしているから20億程度はどうって事無いけど。
でも、大金をSpecCにつぎ込んだんだからこの成果も日本の技術者は積極的に使わないとね。
http://www.nedo.go.jp/iinkai/hyouka/bunkakai/14h/13/1/6-1.pdf


784 :774ワット発電中さん:04/12/14 16:05:57 ID:IgympgVb
修正
でもこの国は2500万円> 勿論億円
書いたことない数字で間違えた

785 :774ワット発電中さん:04/12/14 16:34:19 ID:aL96MfRF
>>783
情報、ありがとうございます。結局、自前開発より保守などを考えるとベンダ
任せにした方が安上がりって事なんでしょうね。

ただ、うちでは独自開発しなきゃならない状態だったから、そうしたらしい
のですが(私のような一般ピープルにはバイナリしかくれません! ) グル的
プログラマーが一人で頑張って構築したらしく、お金なんて殆どかかって
ないみたいですよ。というか、上流だけで15億円なんて、うちでは考え
られないですよ。

……、これってあの悪名高きVC××じゃないですか! 成果の中身がないのは
業界ではもう常識じゃなかったでしたっけ? 確か、第五世代に比べても遥か
に悲惨だと聞いたような。それに、SpecCは背の高い教授が、自ら敗北宣言
していたような……。

786 :774ワット発電中さん:04/12/14 16:46:31 ID:ZNKn3E4A
>>783
もしかして、◎立?

787 :774ワット発電中さん:04/12/14 17:35:27 ID:BXYz8ZYx
産総研のNEDOの事業計画/予算申請書だと思うが、明確な目的が極めて不鮮明だろ?
日本発のスペック作りますと言うわけでもなく、論理合成の新理論が生まれるわけでもなし。
首突っ込みますというだけの事業計画。不要な新幹線や高速道路作る以上に全く
必要ない税金のバラマキ事業そのものだ。
そもそも産総研なんていう公設の無駄遣い研究機関構えてるとそこに籍置く限り何か予算申請せにゃならんのだ。
なくしてしまえよ公設研究機関なんてのは。

>この成果も日本の技術者は積極的に使わないとね。
そんな技術を積極的に使ったら会社潰れます。そもそも成果なんて無い。

788 :774ワット発電中さん:04/12/14 17:52:08 ID:WJvPUIrG
>>787
V××S が成果なしの虚構だった事は事実として、公的研究機関全てを廃止に
するのはどうかと思うよ。まあ、最初5年で契約して、成果が出たもののみ
更新、で5年リセット方式で成果を出しつづけたもののみが生き残れる、と
いう仕組みに大幅変更する必要はあるだろうけど。勿論、そうした変革に
着手する際は、以降期間なしで過去5年に成果がない者は即時レイオフ、
というのも必要だが。

789 :774ワット発電中さん:04/12/14 18:13:32 ID:BXYz8ZYx
だから、成果があったかどうかをどう判断するんだよ。判断のしようがないから、
予算が受理されたこと==成果
と見なすだけ。その結果、意味のない事業計画書が乱発され、無駄遣い予算がばら撒かれる。
それとだ、NEDOにSoCの事業申請されること自体税金の不正流用だよ。NEDOの目的とは全く違うじゃないか。
大体SoCの研究するのに場当たり的に予算投入して何が生まれる?
こういう研究は大学がやればいい。
レイオフって?公務員をレイオフするのか?研究員だけレイオフするわけにはいかないんだよ。
国中公務員上がりの失業者があふれるぞ。

790 :774ワット発電中さん:04/12/14 18:21:04 ID:WJvPUIrG
研究者なら学会や論文で戦って欲しい。確かに、これは大学の仕事だね。
そうした研究機関を取り壊して、科研費を米国並にするなら賛成。

> 公務員をレイオフするのか?
郵政民営化は、公務員への労働三権供与とそれに伴うリストラへの地獄の
入り口です。まあ、レイオフまではしないかもだが、ボーナス一律無支給、
給与3割カットくらいはIMFの通告通り執り行われても何の不思議もない
でしょ。

でも、NEDOは貧乏。経産省より文科省の方が予算がずーっと多い。

791 :774ワット発電中さん:04/12/14 18:34:48 ID:BXYz8ZYx
>郵政民営化
だからさ、民間なら法律にのっとったレイオフはできるよ。
産総研は民間じゃないからレイオフはできない。
独立法人なんかになっても看板架け替えただけで、税金投入され続けることは変わらない。
郵便局と違って自前で稼げといわれて彼らに食い扶持稼げると思うか?
まぁ、つぶさないなら産総研という研究機関じゃなくて
大量に配置転換させるなどして、少数人数でコーディネイト機関として存続させることだな。
どこそこの大学と企業をジョイントさせるとか旗振りするような機関。

792 :774ワット発電中さん:04/12/14 18:40:30 ID:BXYz8ZYx
あと、産総研だけじゃなく、工業試験場っていう糞の役にもたたん
名ばかりの研究機関が47都道府県すべてにあるぞ。
これが税金の無駄遣いじないと言えるか?

793 :774ワット発電中さん:04/12/14 18:40:31 ID:xb3H0/BJ
そろそろ空気読んで元の話題に戻ったらどうだ?

794 :774ワット発電中さん:04/12/14 18:43:02 ID:WJvPUIrG
> どこそこの大学と企業をジョイントさせるとか旗振りするような機関

だめぽ人間でそんなの作って本当に役立つの? 確かにアメリカにはこういう
のを生業としている企業人もいるようだけど。

公務員の処遇に関するIMFの勧告は、全公務員数の三割削減、ボーナス一律
カット、給与の一律三割以上削減、です。郵政事業だけじゃないです。
全公務員対象です。でも、法改正などの理由で、実現が相当困難だから、
取り合えず郵政民営化から着手しているのが現状。ただ、憲法改正も同時
進行中だという事にも注目すべき。

795 :774ワット発電中さん:04/12/14 18:45:32 ID:aL96MfRF
おまいら、空気嫁!

796 :774ワット発電中さん:04/12/14 19:39:35 ID:rjFly+p/
aL96MfRFが少し抽象度上げると、たちまち>793のような発言が。。
システム設計者は常々色々なこと考えていて様々なドメインでの話に噛める
>>793今の空気を読んで少しお待ちください。

>>795の発言は793に対してですね?
少し同じIDでの間にインタラプト入りraceが起きたようで混乱

そ、税金使ってSoC基盤整備は立派だと思います。
これが日本の半導体を強くするのだったらね

797 :774ワット発電中さん:04/12/14 19:40:50 ID:rjFly+p/
ごめんageた

下げ進行なのこのすれ

798 :774ワット発電中さん:04/12/14 19:48:05 ID:xb3H0/BJ
何ででも書いてやるよ。
Cの話をしてくれ。

空気を読めないお馬鹿さん。(ゲラ

799 :774ワット発電中さん:04/12/14 20:32:36 ID:D1MMYcOX

遺伝的アルゴリズム位まで話戻ると、
http://www.nedo.go.jp/iinkai/hyouka/bunkakai/14h/13/1/6-1.pdf
の中に書いてあって、プロジェクトの成果物に既になっているわけ。
税金を有効活用するには、この成果は使わせてもらいましょう

それとこの国家プロジェクトは最後まで完璧な落ちが用意されています。
たった20億でこれだけ笑えるんだからお得です
2ch以上のつるし上げが公開情報としてここにあります。
http://www.nedo.go.jp/iinkai/hyouka/bunkakai/14h/13/1/gijiroku.pdf




800 :774ワット発電中さん:04/12/14 22:53:19 ID:rokUnPOD
Cの話は

801 :774ワット発電中さん:04/12/14 22:58:42 ID:xb3H0/BJ
具体的設計の話とかと同じで何故か聞かれると急に静かになってしまう
話題があるようです。
不思議ですが事実です。

802 :774ワット発電中さん:04/12/14 23:52:54 ID:ppfEb02f
釣りねた、思い浮かばないから寝ます
ウン10億使った○XC社の話でも明日は仕入れておきましょう


803 :774ワット発電中さん:04/12/15 10:11:08 ID:RlwrjCcr
>>799 >>802
ちくり裏事情かビジネス板へ逝くべし
ここは学問板だ
釣りねた禁止

804 :774ワット発電中さん:04/12/15 16:51:55 ID:1J7dpYzJ
>>798
おまいが先ずしろ! それとも出来ない、ただの厨か?

805 :774ワット発電中さん:04/12/15 19:09:36 ID:KWvITDT/
>>487
沖の場合、設計資産を沢山持っている大手半導体メーカに対抗して
導入したんじゃないの?
http://www.oki.com/jp/Home/JIS/Books/KENKAI/n196/pdf/196_R31.pdf

806 :774ワット発電中さん:04/12/16 10:25:34 ID:xgQ7I5G/
SystemC-AMSは、Verilog-Aのアナログモジュールを組み込んで通信している
だけに思えるが?
http://www.nascug.org/Presentations/NASCUG_2004.8-Younis.pdf

807 :774ワット発電中さん:04/12/16 14:32:40 ID:HKQ3cJod
>>806
SystemC-AMSが目指すところはどこにあるですか?現場ではVerilog−Aから
Tr設計(スケマティック)までブレイクダウンするのは未だに人手でやってる
のでしょうか?もしそうならば、SystemC-AMSが担う記述はVerilog-AがC++表現
されたものでしかなく、その意義はどこにあるのでしょうか? 教えてください。


808 :774ワット発電中さん:04/12/16 14:51:53 ID:pUfFlgPP
SystemCが目指すところはどこにあるですか?現場ではVerilogから
Tr設計(スケマティック)までブレイクダウンするのは未だに人手でやってる
のでしょうか?もしそうならば、SystemC-が担う記述はVerilogがC++表現
されたものでしかなく、その意義はどこにあるのでしょうか? 教えてください。

809 :774ワット発電中さん:04/12/16 15:50:27 ID:Yb3BpLB1
>>808
ざぶとん へ( -_-)_

810 :774ワット発電中さん:04/12/17 17:42:29 ID:zpiSG370
SystemVerilogは、Objectが使えるのですか?

811 :774ワット発電中さん:04/12/17 17:47:19 ID:TjPxDigX
>>803
面白くないから、誰か要望通り
ちくり裏事情?
ビジネス板?
にスレ立てないかな

812 :774ワット発電中さん:04/12/17 17:50:01 ID:0KibUOLC
それとも、>>803の言うようにスレがあるの?
探したけどみっかんないから誰か教えて

スミマセンネー 
学問版汚して

813 :774ワット発電中さん:04/12/17 18:39:15 ID:RMdj8Ssc
>>811 >> 812
お前らがスレ立てろ! 簡単なことだろ!

814 :774ワット発電中さん:04/12/18 11:12:50 ID:tjx1zOGI
>>807
 HW(A、D)、SWのモジュール組込めるので、コアなDSPをHWのモジュールとして
作成しておけば、動作合成して検証できるではないか

815 :774ワット発電中さん:04/12/18 18:31:01 ID:ZAT/VBb2
>>817
ローパスフィルタとかもDSPでやんの? ……無駄杉!

816 :774ワット発電中さん:04/12/19 11:06:58 ID:ZuGSW7Wj
全部ざぶとん取って

817 :774ワット発電中さん:04/12/19 11:35:16 ID:/ALZaUu4
SystemCはIEEEで標準化されてからじゃない、本格的に普及するかどうかが
決まるのは。ただ、フリーのシミュレータが出回っている以上、ベンダとして
は本格的にサポートするのが難しいんじゃないかな? どうなのその辺り?

818 :774ワット発電中さん:04/12/19 17:05:23 ID:Q5f2Yvvg
>>817
Modelsim使ったことないだろ?

819 :774ワット発電中さん:04/12/19 17:18:10 ID:/ALZaUu4
>>818
アホでつか? そういうのは前提での話なんだが……。「本格的」の意味を
ようく考えようね、単純作業者厨。

820 :774ワット発電中さん:04/12/19 17:23:02 ID:Q5f2Yvvg
modelsim 使ったことあれば現状のシミュレータだけで十分かどうかはわかるはず。
カスに言っても仕方ないけどな。

821 :774ワット発電中さん:04/12/19 17:24:34 ID:Q5f2Yvvg
それとだ。
シミュレータの話じゃない。
それも普通の思考回路があればわかるはず。
カスに言っても仕方ないけどな。

822 :774ワット発電中さん:04/12/19 17:27:55 ID:jmltUDS7
>>821
実務経験者が何もわかってない学生いじめても空しいだけでしょ

823 :774ワット発電中さん:04/12/19 19:22:23 ID:UHCggsWD
>>806
Verilog-Aは、中途半端なんだよな。これじゃ使いたくね


824 :774ワット発電中さん:04/12/19 19:32:32 ID:RFuWnUtC
>>823
H-Spiceでいいじゃん
ネットリストで十分
ワザワザAMS使う意味わかんない
そんなにC言語と無理やり協調させて意味ある?
誰が必要なのかマジに知りたい。

825 :774ワット発電中さん:04/12/19 19:54:28 ID:tlf63Y5y
>>824
H-SPICEにDSPを組めないと思うが?

826 :774ワット発電中さん:04/12/19 20:21:16 ID:/ZIiyjlP
>>824
人口を増やすって点では、かつての COBOL に似てるのかな

827 :774ワット発電中さん:04/12/19 21:37:09 ID:ITYjO9zI
誰が必要なのかマジに知りたい。

Cでやったぞ!という成果発表をしなくてはならない立場の人だろ

828 :774ワット発電中さん:04/12/20 12:36:01 ID:N7Jc4leN
>>827
HDL書けない & ハードウェアのかけらもわかってないバカソフト屋


829 :774ワット発電中さん:04/12/20 19:59:21 ID:G2AAH+9w
富士通研、ソニー、リコーが使っているというフォルテのCynthesizerについて
意見聞かせてくろ
http://www.forteds.com/news/pr051004cynthjapanese.pdf


830 :774ワット発電中さん:04/12/20 22:43:44 ID:HuE9YauX
>>829
ここは学問版なので、この辺で意見聞いたら?
漏れも怒られちゃいました
http://science3.2ch.net/test/read.cgi/kikai/1027071698/

831 :774ワット発電中さん:04/12/21 12:10:32 ID:Guuhse12
H-SpiceじゃなくてPSpiceじゃだめなん?
みんなSpiceは何使ってる?
俺はOrcad か Protelのもの使う。パラメータの設定とかはProtelの方がいい。
波形ビュアーとか観測点の指定はCadenceの方がいいかな?

832 :774ワット発電中さん:04/12/21 17:56:31 ID:PuogHy70
漏れは貧乏人なんで、
http://www.linear-tech.co.jp/software/index.html
の、LTspice/SwitcherCAD
なんぞというものを使ったりしていた
でも、最近はすっかりズボラになって、使ってないなぁ


833 :774ワット発電中さん:04/12/22 07:12:36 ID:M1hrVAnx
うちは内製のヤツ。

で、「SystmC死亡」 ってのが当たり前なんじゃなかったっけ? まだ頑張っ
てる(頑張らなきゃならない)人、居るんだね。本当にお気の毒な話だよ。

834 :774ワット発電中さん:04/12/22 15:55:30 ID:xMwoqN32
今日、某超大手ASICメーカーが来て
System-Cベースの開発環境があって、トップダウン設計にむいてまっせ。
とプレゼンテーションしていった。

シボーンしてるんじゃないのか?

835 :774ワット発電中さん:04/12/22 19:02:29 ID:qg9eCbA0
>833
まぁまぁ・・それで飯を食ってる人もいるのだから、
そういう刺激的な表現は避けた方が良い。

>834
トップダウン設計というなら、やはり下まで「ダウン」できないと
いけないと思うのだよなぁ。シミュレーションまでしか実用に
なってないというのじゃトップダウン設計じゃなくて、
「トップ'だけ’設計」だし。

836 :774ワット発電中さん:04/12/22 20:13:06 ID:qODYLEs2
なんか、設計と実装の区別がつかない人が暴れてますね

837 :774ワット発電中さん:04/12/22 20:33:53 ID:TXdaCOJQ
>設計と実装の区別がつかない人が暴れてますね
君わかってるか?
設計というのは実装のことも当然加味してなされるべき。

838 :774ワット発電中さん:04/12/22 20:51:20 ID:qODYLEs2
>>837
ええ、わかっていますとも
自然言語でチップ作れない RTL 組めない検証できない、
だから人工言語で仕様書くれって実装側の泣き言に
歩み寄る試みが SystemC の本質でしょうが

839 :774ワット発電中さん:04/12/22 21:01:58 ID:TXdaCOJQ
お前は何もわかってない。
お前は製品設計を実際にやったことがない鼻たれの糞ガキということがすぐわかる。



840 :774ワット発電中さん:04/12/22 21:05:15 ID:qODYLEs2
>>839
>鼻たれの糞ガキ

はいはい、結構ですよw

841 :774ワット発電中さん:04/12/22 21:13:24 ID:qg9eCbA0
実装無き設計なんてモックアップみたいなものだしな
「写真はイメージです」
「画像はハメコミ合成です」

実装を無視したら、SystemCでこりゃええわい!となった
実際にやってみたらとても現実的なコスト/サイズでは
収まらないようなものになってしまった。
そんなの設計じゃない罠

842 :774ワット発電中さん:04/12/22 21:18:35 ID:nNCMY4Fv
互いの認識のズレを確かめようともせず
ただの煽りあいをするのは頼むから止めてくれ。
端から見てて見苦しい。

「設計と実装の区別がつかない」と指摘するなら
まず自分の認識している「設計」「実装」を説明すべきなんじゃないか。

843 :774ワット発電中さん:04/12/22 21:47:22 ID:TXdaCOJQ
設計とは仕様を具現化することだ。
つまり頭の中で描いたことを実装することが設計。
それすらわかってないID:qODYLEs2は糞だといってるわけだ。

844 :774ワット発電中さん:04/12/22 22:08:22 ID:qODYLEs2
何を使ってどうしたいのかを決めるのが設計
実際にブツを使って結果を出すのが実装
実装側の能力が低いほど設計側で細かくお膳立てしてやる必要がある
これは言い過ぎにしてもお互いに誤解のないように気をつける方法論に例えば SystemC があるわけだ
要は実装側に設計側の意図が正しく伝わればいいわけでそのプロトコル自体で実装できるかどうかは本質的な問題じゃない
変換に伴うヒューマンエラーを回避したければ機械化すればいいわけだが入力と出力のフォーマットが同じであることは絶対条件ではない
「トップだけ設計」という煽りに対しては「ボトムだけ実装」という反論があるだけの全く不毛な構図に対しての
アンチテーゼをやっている最中に根本を否定するアイディアキラーを冷ややかに見てはいるが別にどうもしない

845 :774ワット発電中さん:04/12/22 22:24:04 ID:TXdaCOJQ
>何を使ってどうしたいのかを決めるのが設計
>実際にブツを使って結果を出すのが実装

だからお前は製品設計を全くやったことないアホだといってるんだよ。
実装状態を考えない設計なんかあると思ってるのか。
糞戯言書きながらいちいち上げるな。
休みに入ったと思ったらこれかよ。
まともな就職先でもとっとと探せアホ学生がよ。

846 :774ワット発電中さん:04/12/22 22:27:33 ID:qODYLEs2
>だからお前は製品設計を全くやったことないアホだといってるんだよ。

はいはい、結構ですよw

847 :774ワット発電中さん:04/12/22 22:32:21 ID:vf9xdS+r
なにこのクソスレ

848 :774ワット発電中さん:04/12/22 22:32:26 ID:TXdaCOJQ
SystemCようやく覚えたのにどっこも生かす先がなくて残念だったなぁ。
えぇおい。アホの一つ覚えの学生ちゃん!はぁと

849 :774ワット発電中さん:04/12/22 22:41:35 ID:qODYLEs2
製品設計ってアンタ・・・

850 :774ワット発電中さん:04/12/22 23:10:57 ID:WWVj6r5d
>>844 さん、
>これは言い過ぎにしてもお互いに誤解のないように気をつける方法論に
>例えば SystemC があるわけだ
844 さんの”設計と実装”に関する見解は、設計・実装( CAD/EDA 絡み )
の実際に即したものだと、私は感じております。私も同じように考えています。
それほど間違った考え方(と言うよりは、捉え方)では無いと思うのですが。


851 :774ワット発電中さん:04/12/23 07:52:05 ID:TREzBj1D
那珂工場の人たちも使うのかな?
すれ違い?


852 :774ワット発電中さん:04/12/23 08:04:04 ID:5QViod4L
>>834
某超大手ASICの只の宣伝にだまされるな!
SystemCを使うから設計が簡単になるわけでもないし、
面積小さくなるわけでもないからな。
ゲート数で稼ぐのか?その某超大手ASIC
設計期間は確実に増える
検証も大変
そんなことやってないで検証フローをしっかり立ち上げろ
アサーションツールでばっちりってのも聞いたばかり

どっちもASICには向かない技術ですよ。まして宣伝に使うな。

うちにもくるけど、判ってない半導体営業が多すぎる。
この業界の営業はみんなレイアウト上がりの馬鹿ばかりだから注意


853 :774ワット発電中さん:04/12/23 08:05:33 ID:4rQI3EEu
FPGA屋が対応したら漏れも使うだろう。
それまではイラネ。

854 :774ワット発電中さん:04/12/23 10:36:43 ID:QC9Ne6AM
>要は実装側に設計側の意図が正しく伝わればいいわけでそのプロトコル自体で
>実装できるかどうかは本質的な問題じゃない

実装できなかったら製品も何にもならんじゃん。それこそ単なる
絵に描いた餅。画家なら絵だけでいいだろうけどさ。
そういう区分けなら「設計」じゃなくて「研究開発」だろ?
それに、仮に「研究開発レベルだ」にしても、最終的に目指すものが
製品である以上、ボトムを無視してトップだけなんていうのはナンセンス
だよ。
たとえばある物質が汚れを落とすのに効果があることがわかりました。
でもそれが1mgで10万円します。一回の掃除で使う分量は1g位必要
だけど、効果はあるんだから、あとの製品化はよろしくね・・・なんていう
ようなもんでさ。

>「トップだけ設計」という煽りに対しては「ボトムだけ実装」
>という反論があるだけの全く不毛な構図に対しての
でも、そのボトムだけ実装というので実際に物ができるところまで
ちゃんとつながっているじゃん。それとも今まで設計せずに物を作っ
ていたとでも言う?ただの言葉遊びのレベルであって、反論に
なってないよね?

855 :774ワット発電中さん:04/12/23 10:49:04 ID:Xe7RnBf2
>>854
>>836

856 :774ワット発電中さん:04/12/23 11:19:26 ID:RdgY1/xl
今はFPGAの時代
ASICは時代遅れだから漏れも使わない

牧本ウエーブ信者
ttp://www.sony.co.jp/Products/SC-HP/cx_pal/vol57/pdf/sideview.pdf

857 :774ワット発電中さん:04/12/23 12:35:17 ID:J99mtn5I
どうも、設計の定義づけがずれているだけのような気がする。
844の言う設計はつまり仕様作成のことじゃないの?
ソフトウェア開発をやってたのかな?
実装を無視した仕様は困りもの。

858 :774ワット発電中さん:04/12/23 14:11:45 ID:QC9Ne6AM
まったくだ。
>836はおおかた仕様検討/作成=設計と思いこんでいるのだろう。
(>855もか?)
でも、実際に製品化するときのボリュームが見積もれないのでは
仕様作成用としても使える範囲なんて限られてくる罠。

859 :774ワット発電中さん:04/12/23 17:22:50 ID:MtljD0OP
modelsimはVHDLを止めたがってて代わりにSystemCには対応してるね。
Verilog使いの俺にはどうでもいい話だけど。
SynplifyとPrecisionがSystemCに対応したら俺も使いたいね。
その予定あるのかないのか知らないけど。
シミュレータだけの絵に描いた餅じゃ意味ないからな。

860 :774ワット発電中さん:04/12/23 20:15:00 ID:QC9Ne6AM
でも、SystemC屋に言わせると、合成なんて考えなくては
ならないような領域の人間が使う物ではないんだとさ。
あくまでもシミュレーションでこういうシステムがよさそうだね〜
で、おしまい。あとは実装屋さん、がんばって!なんだとさ。

絵に描いた餅は餅屋

861 :774ワット発電中さん:04/12/23 22:25:02 ID:72doeMJj
> modelsimはVHDLを止めたがってて

止めたがってるのかなあ。
機能の実装は相変わらずVerilog HDLよりVHDL優先の気がするけど。

それにSystemCも力が入っているとはとても思えず…

862 :774ワット発電中さん:04/12/24 00:07:29 ID:brvQHNvL
PEはVHDL削除されてるよ

863 :774ワット発電中さん:04/12/24 04:26:48 ID:dghj+Kf+
RTL設計でも結局用いるセルライブラリの遅延・面積を考慮して論理段数を
意識しながら設計してますた。なので、気持ち的には、
  RTL設計 = Gate Level設計(実装)
ですた。確かに、最適化してくれるだけマシですが。SystemC、どうなんで
しょう? より抽象度があがるわけですから、実装を意識した設計というの
は可能なのでしょうか?

グル的プログラマはこう言います。
  「Cは好きだけど、C++はイヤ! だって、コンパイル後のアセンブラが
   イメージできないから。」

SystemC、どうなんでしょう? やっぱ、仕様検討用のSimulation用言語っすよね?
個人的にはそう割り切るのが、一番納得なんですが……。

864 :774ワット発電中さん:04/12/24 07:09:57 ID:0iqGqet9
言語の仕様的部分はVHDLが好きで今でもメインで使ってるが別に不便はない。
てか、どんな言語が出てこようが普通に対応出来て当たり前だろ?
言語のヨロ好みなんてエンジニアとして恥ずかしすぎる。

865 :774ワット発電中さん:04/12/24 07:24:04 ID:dghj+Kf+
>>864
> 言語のヨロ好みなんてエンジニアとして恥ずかしすぎる

この発言凄いでつね。議論を一般化する事で、全てを誤魔化そうとして
いまつね。言語には向き不向きがあって当然なのでつ。だって、そのよう
に言語を設計するわけでつから。その向き不向きをここで議論しているの
でつ。

というか、貴方は、詐欺師ですか?

866 :774ワット発電中さん:04/12/24 07:40:55 ID:0iqGqet9
何度でも書きますよ。

言語の選り好みなど技術者としての恥であると断言します。

867 :774ワット発電中さん:04/12/24 08:28:34 ID:FIflhbNy
好みがないのはそこまで使いこなせてない証拠
それこそ技術者としての恥


868 :774ワット発電中さん:04/12/24 08:37:09 ID:4d/GQay/
SystemCにとって不利な発言(例えば、>>863)が出てくると決まって、>>866
のような厨が湧き出てくるな。どっかのベンダの回し者って事だね。

諦めて転職でもしる! > >>866

869 :774ワット発電中さん:04/12/24 12:14:49 ID:EuYi0o2a
>>866
横レスだが
人それぞれなんだから、もっと心を広く持とうね
技術者の恥ってのは、知らないのに知っているような振りをして最終的には自爆するのが最強だと思うな


870 :774ワット発電中さん:04/12/24 12:42:12 ID:E44Ulhw2
俺はVHDLは大嫌いだ。とにかく記述量が多すぎる。あとdefineやif〜defとかの
プリプロセッサが無いのも勘弁してくれって感じ。
マジで下請けでえり好みできない立場じゃなくてよかったよ。
ある程度ソフトウェア言語に慣れた奴でVHDLのゲゲボ仕様が好きになるとは思えないんだが?
なんでVerilogより後発でこんな言語仕様にしたんだか?
そりゃ好みとしてはSystemCがいいよ。
でも現状使えないからVerilogだな。2001で相当よくなった。

871 :774ワット発電中さん:04/12/24 12:50:08 ID:QHnFTkMy
>>869
佐川豊秋さんとか?(w

872 :774ワット発電中さん:04/12/24 18:04:31 ID:fttx5oB4
>>870
学生さんですか? 記述量が多いのは全部ゼロから作るからでしょ。
そんなことしなくてもVHDLも普通の量だよ。なにが普通なのかは疑問だが?


873 :774ワット発電中さん:04/12/24 18:48:10 ID:fttx5oB4
いいね若いうちは量が掻けて
年取ったら一回の中身の濃さで勝負

874 :774ワット発電中さん:04/12/24 20:30:16 ID:8E6HhbWx
>技術者の恥ってのは、知らないのに知っているような振りをして最終的には自爆するのが最強だと思うな

ワラタ

875 :774ワット発電中さん:04/12/24 21:09:08 ID:zw/s17rB
http://www.geocities.jp/endlessskyline009/megaryuushi.htm
上記のURLの一番上のスペースに下記URLをコピペ
http://www.innolife.net/bbs3/list.php?bbs=baeyongjun

更新間隔は、500(0.5秒に1回)頻度高いと結果更新がされない
8時50分(20:50)一斉攻撃開始
応援求む 作戦本部スレは下

http://ex7.2ch.net/test/read.cgi/news4vip/1103879941/

876 :774ワット発電中さん:04/12/24 21:17:45 ID:7iyHey1e
>>874
あなたの身の回りにもいるでしょう、そんな人が
例えば 上司の○○さんとか (w

877 :774ワット発電中さん:04/12/24 23:31:15 ID:HPX6vJsw
>>870
あれは古くから存在する2つの言語形式の現れだと思う。
プログラマはどっちの形式も知っておくべきらしいが、Cに慣れている人はVerilogが好きだろう。
もっとも俺の場合はその”慣れ”が邪魔してVerilogの概念をつかむのに苦労したんだけどね。
回路図を自分で書いて初めて納得出来たのを覚えている。

878 :774ワット発電中さん:04/12/24 23:56:08 ID:CVldDHGS
>>876
佐川さん?

879 :774ワット発電中さん:04/12/25 00:47:27 ID:G8Ty/szl
Verilogの方がシミュレーションが速いとか言うんだよなぁ〜
どっちも囓っていたけど、Verilogに重み置こうかな

880 :774ワット発電中さん:04/12/25 02:18:07 ID:wXN6T03B
Verilog-HDLはSimulation用の言語として開発された経緯があって、VHDLは
ADAをベースに米軍がお金を出して開発した経緯がある、と聞いた事があり
ます。で、Verilog-HDLの方がSimulationが一般に早いそうなのですが、
問題は、Simulator間での互換性に難がある事です。特に、Racingなどが
あると、Simulatorを変更した際に動作が再現できなくなる恐れがあります。
でも、私は、Verilog-HDLユーザですけどね。

RTLを記述しなきゃならないくらいなら、SystemCを記述するメリットは
ほぼ皆無だと個人的には考えていたりもします。RTLを全く記述しなくて
良いんだったら、話しは別なんですけどね。

881 :774ワット発電中さん:04/12/25 02:25:50 ID:a6TpKrKG
>>880
自分で記述するのか? ツールの出力を点検するのではなく・・・。

882 :774ワット発電中さん:04/12/25 03:14:30 ID:uShCseof
上司・先輩がVerilogしか分からないとおっしゃるので
VHDLは使えない

個人的にはVHDL、Verilogのどっちでもいいんですけど

883 :774ワット発電中さん:04/12/25 04:08:21 ID:VWXrrZhA
VHDLとVerilogで出来上がりのファイルだけをみてるとそう記述量も大差ないように一見思えるのだが、
HDL上で実験するとかなったら、条件コンパイルが不自由なVHDLはAWKかperlあたりを駆使して擬似条件
コンパイルできるように細工せんと使い物にならんわな。生産性良くないよ。マジで、

884 :774ワット発電中さん:04/12/25 07:43:20 ID:twiUQuKR
つーか初期からHDLを弄ってるエンジニアならどっちも使えて当然。
どっちが良いなんて議論は技術以前。
論外。

885 :774ワット発電中さん:04/12/25 10:07:57 ID:ESM1//7F
どっちも使えればこそ、好みが出るんでない?
何となく自分のフィーリングに合うとか

886 :774ワット発電中さん:04/12/25 10:41:54 ID:m4RVO6AO
ここはSystemCとSpecCのスレだと思ったのだが、いつからVerilogとVHDLのスレになったのだろうか?

#VerilogとVHDLはベータとVHSみたいな関係になっていくんだろうなあ。
#どっちかはライブラリ(レンタル)も環境(自己録再)も豊富だけど、もう片方は環境だけになる。
#個人的にはVHDLでもdefineとif defもしくはconditional-compileが出来れば文句はないんだが

>>884

AHDLもやってみるかえ?



887 :774ワット発電中さん:04/12/25 10:57:59 ID:TeruedxB
最近、セミナーとかの対象言語がverilog一辺倒に
なりつつある気がするのは俺だけ?

888 :774ワット発電中さん:04/12/25 11:01:00 ID:ESM1//7F
AHDLもやってみるかえ?

ついでにABELとかPALASMとかPARTHENONとか

889 :774ワット発電中さん:04/12/25 11:01:20 ID:a6TpKrKG
>>886
C コンパイラは、プリプロセッサだけを独立したツールとして使えるのはご存知?
つまり、別に C ソースに限らずどこででも #define と #ifdef は使えるんです

890 :774ワット発電中さん:04/12/25 11:09:37 ID:ESM1//7F
そういえば、コメントの先頭が#で始まるものに使って痛い目に
あったことがあったような・・・


891 :774ワット発電中さん:04/12/25 11:23:05 ID:PdosDJVi
>>886
やっぱり抽象度上げるのは現実には無理だからEDIFとSPICEのスレにしよう。
GDS2でもいいよ

892 :774ワット発電中さん:04/12/25 11:41:33 ID:a6TpKrKG
井桁が気に入らなければ別に C プリプロセッサでなくても構いませんが
条件により少しずつ異なるテキストを出力するマクロ言語なんてそこいら中にいくらでもあるでしょう
そのマクロ言語に依存したくないとか言い出すのは合成ツールや特定の HDL に依存したくないというのと同じだと思いますが

893 :774ワット発電中さん:04/12/25 12:45:39 ID:Pzx1hcyO
>>891
ワロタ

やはり、SystemVerilogくらいが落し所なんかいのう。PSLを既に使っている
者としては、別段嬉しくない解だなあ、しかし。CだろうがJavaだろうが
Temporal拡張さえ行えば、PSLを組み込むのは簡単なのにね。そういう単純
な発想のが一番使い勝手が良いような気がするんだけどね。

ただ、Handel-Cは却下ね。だってVerilogでRTL書くのと変わらんもん、それ
だったら。別段合成時に最適化してくれるわけでもないし。

894 :774ワット発電中さん:04/12/25 12:49:37 ID:kMKpehP+
>どっちが良いなんて議論は技術以前。
バカだなお前は。
どっちがよいかを議論するのが技術論
言い換えれば技術論というのは方法の選択の議論だ。
宗教論になっては意味がないが、
言語仕様としてXXができないから効率悪いというのは正当な技術論だ。

895 :774ワット発電中さん:04/12/25 13:04:09 ID:L0Q8edMW
>>893
SystemVerilogだとデザインレベルでの抽象度は変わらんわけで、
落とし所と言えるのかどうか。

まだ正式リリースじゃないけどSystemCにPSLを入れ込むらしいですね。

896 :774ワット発電中さん:04/12/25 13:11:51 ID:Pzx1hcyO
>>895
そうだよね。SystemVerilogじゃなあ〜。やっとPSLに追いついて来たって
とこだもんね、アサーションの記述能力。

でも、SystemC+PSLも解とは言い辛い気がするなあ。大体からして、Test
Builderってどうすんだあ?

某社のトレーニング紹介資料を見て愕然としたよ。

  CPUインターフェースはRTL設計

ってオイ! それじゃあ、ちっとも抽象度が上がっとらんじゃないか!
DSPアルゴの部分だけ、超制約付きで職人芸には程遠いレベルで最適化
します、じゃ話しにならんだろ!!

つうか、結局バス周りとか、そういうコントロール系の部分をいじくり
まわす事の方が多いと思うんだけど、どうよ、皆さん? そこんとこを
楽にしてくれないとね。PSLはその意味では嬉しかったんだけどね。

897 :774ワット発電中さん :04/12/25 15:52:17 ID:bLvQw9Mo
age

898 :774ワット発電中さん:04/12/25 16:03:44 ID:ESM1//7F
SystemCはそういう実装屋のようなゴチャゴチャしたところは
バッサリと切り捨ててもっと上流の、お上品な部分だけを綺麗に
シミュレーションしてシステムの構成だけを考えるためのものです。
考えた結果が実現可能か、採算ベースに乗るような製品になるのか
どうかは実装屋が考えることでSystemC屋には関係ありません。

とな

899 :774ワット発電中さん:04/12/25 16:10:16 ID:kMKpehP+
そんなシミュレーションならMatlabでいいだろな。

900 :774ワット発電中さん:04/12/26 01:21:49 ID:BFbARYYL
>ってオイ! それじゃあ、ちっとも抽象度が上がっとらんじゃないか!
>DSPアルゴの部分だけ、超制約付きで職人芸には程遠いレベルで最適化
>します、じゃ話しにならんだろ!!

…そうなんだけどね。
今の段階ではその程度の適用にとどめるのがどうも現実的なんだよな。


901 :774ワット発電中さん:04/12/26 05:17:21 ID:R4p3jp3u
SystemCでなくて良いなら、

http://tmp4.2ch.net/test/read.cgi/company/1098504831/133
http://www.yxi.com/Japanese/exciteJ.html#

なんて解もあるみたい。これなら、抽象度がちゃんと上がっているようです。
考えてる人は考えてるんですね。

902 :774ワット発電中さん:04/12/26 14:37:08 ID:sKDWHEtz
HY-Cは抽象を好むシステム屋より、LSI屋が抽象からHWに落とすときに
便利なようですな。システム屋ならSystemCがよいと言うに決まって
いるから、SystemCからHY-Cに変換するツールが欲しくなるが、
如何なものか

903 :774ワット発電中さん:04/12/26 14:44:23 ID:sKDWHEtz
NECのCyberもいいと思うが、SystemCからの変換ツールが欲しい
http://ne.nikkeibp.co.jp/NEWS/dac2003/030317_1.html

904 :774ワット発電中さん:04/12/27 03:33:19 ID:4W2YSMOP
>>902
HY-CからSystemCへの変換ツールがあるみたいよ。それで、既存SystemCの
環境との融合が出来るのではないかと期待しているのですが、如何なもの
でしょう?

て、個人的にSystemCは性能解析専門のSimulation言語と割り切ってます。
だって、割り当て可能なサイクル数見積もりのためのSystemCモデルを作成
する時って、機能を適当にはしょって書いてたりしますからね。そんなの、
合成出来ないのは当然だし。つうか、システム屋として、SystemCのこの
使い方は妥当だと思ってるんですけどね。

905 :774ワット発電中さん:04/12/27 08:52:07 ID:S0Fxf7W9
そのために投下する費用や教育の為の費用なんかと節約できる
コストのバランスだろな。
Simulationが開発工程の中ですごく大きなウェイトを占めていて、
そこが劇的に改善されるということがあって、しかもそれが何度も
いろいろな物で繰り返されるというのならば良いけれども、従来手法
でも大差ない程度のものでしかないとか、一回こっきりや、たまに
思い出したように使う程度とか、トータルでは同じような成果しか
あげられないなら、営利を目的とした企業としてはあえて導入する
積極的な理由付けに乏しいと言わざるを得ないからな。
趣味的に使ってみたいとか研究目的でというなら良いんだろうけど。

906 :774ワット発電中さん:04/12/27 10:40:08 ID:b49AXNR2
> Simulationが開発工程の中ですごく大きなウェイトを占めていて、
> そこが劇的に改善されるということがあって、しかもそれが何度も
> いろいろな物で繰り返される

 そうじゃないSystemCの性能解析環境作る方がよっぽど あふぉ だと
思うわけだが。まあ、合成は最初から諦めてるし、捨ててるけどね。
それでも、十分意味があるから良いのよ。

907 :774ワット発電中さん:04/12/27 12:35:47 ID:M+IRxyCp
>それでも、十分意味があるから良いのよ
差し支えないレベルでそこを紹介しなきゃ何も説得力ないよ。
俺はシミュレーションはC++でやってるけどSystemCを使うメリットなんて感じてない。

908 :774ワット発電中さん:04/12/27 13:40:32 ID:VFEvt5Et
>>907
見苦しいよ、クレクレ君。また、自爆する気か? 大体、ここは便所の落書き
なんだから、書き込んだヤツも説得する気なんて初めからないんじゃん?

  信 じ る も、 信 じ な い も あ ん た の 勝 手 !

だぁーね。でないと、君がC++で十分だと主張している事の説明が先ず最初に
必要となるわけだが。その説明なんて、どうせ出来ないんでしょ? だって
クレクレ厨だもんね。何だか、可愛そうというか大概哀れなヤツようのう。

909 :774ワット発電中さん:04/12/27 15:13:31 ID:r5wlWSjh
>>908
おまえ書き込むのやめろ。
下らん内容書き込んでいちいちあげるなバカタレが

910 :774ワット発電中さん:04/12/27 15:19:15 ID:vIJahzFK
世の中の多くは上位レイヤのファンクションシミュレーションはC++やら
Matlabやら使ってる。SystemCを使ってシミュレーションしなければならない事例
があれば具体例ぐらい書ける。その具体的な必要性を明確に示せない。もしくは
その痛いところを突かれれば切れるしかないよね?
人格破綻者の>>906 ID:VFEvt5Et君

911 :774ワット発電中さん:04/12/27 15:21:18 ID:vIJahzFK
あ、間違ったキチガイ人格破綻者は>>908 ID:VFEvt5Etだった。

912 :774ワット発電中さん:04/12/27 15:26:25 ID:S0Fxf7W9
>そうじゃないSystemCの性能解析環境作る方がよっぽど あふぉ
>だと思うわけだが

だろ?結局そういう極狭い範囲で役に立つかもしれない、
役に立てばラッキーって程度。それじゃあ導入する気になれんよ。
SystemC屋を食わせるために仕事しているわけじゃないんだから。

913 :774ワット発電中さん:04/12/27 15:28:20 ID:j5xhvPKC
現実のデバイスにインプリ出来なければ利用価値がない現場も世の中には
存在する。
よってCは現状使い物にならないと考える者が多い。

914 :774ワット発電中さん:04/12/27 16:13:29 ID:/ZuMhzGK
>>913
高卒の現場で使えないから価値がない?

オイオイオイオイ、高卒の現場そのものが価値がない、の間違いだろwwwwwww

915 :774ワット発電中さん:04/12/27 17:52:11 ID:X42sGp6s
↑無価値なやつが、何か負け犬の遠吠えをしているようだな。

916 :774ワット発電中さん:04/12/27 17:54:26 ID:/ZuMhzGK
すまん、より正確に言うべきだったな。
高卒の現場そのものが価値がない、はもちろん正しいが、
より正確に言えば
高 卒 そ の も の に 価 値 が な い
だ。


917 :774ワット発電中さん:04/12/27 18:10:37 ID:X42sGp6s
>>916
一番価値が無い奴がなんかほざいてますな。(藁


918 :774ワット発電中さん:04/12/27 18:14:33 ID:/ZuMhzGK
リアル高卒ニートハケーン

919 :774ワット発電中さん:04/12/27 19:54:00 ID:S0Fxf7W9
>918
藻前が見ているそれって鏡だぞ


920 :774ワット発電中さん:04/12/27 20:58:24 ID:laCbSqYG
滅び行く日本・・・ ハード屋こんなのばっかり?

921 :774ワット発電中さん:04/12/27 20:59:51 ID:j5xhvPKC
一部の痛い奴が全部じゃない。

922 :774ワット発電中さん:04/12/27 22:16:20 ID:kb7wM4jX
年末進行でみんなストレスたまってるんです

923 :774ワット発電中さん:04/12/27 22:46:41 ID:uJBQpAyK
Qとかいうのってハード屋ですのん?
なんか一流らしいが、見てる限りは

一流を、超えた
超一流の阿呆

924 :774ワット発電中さん:04/12/27 23:17:55 ID:Bd9zYiGp
>>923
口先だけですから。ざんねんっ!

なんか物理屋らしいけど超一流のクズらしいですよ

925 :774ワット発電中さん:04/12/28 04:46:56 ID:nNC+t5CX
実装へのパスがあるということで、個人的には、HY-CかCyberに期待
といった所です。やっぱ、RTLよりは記述量を減らして仕事したい
ですし。実際、記述が長いとバグる確率が跳ね上がって行きますしね。
どっちでもいいから、PSLとかサポートして欲しいっす。

でも、そうとは思っていたけど、やっぱりSystemCは駄目なんだあ orz

926 :774ワット発電中さん:04/12/28 10:49:03 ID:CwpkXiMF
SystemCは、バスをチャネルで処理するから、気に入らないと言う人が
いるんだろうなぁ


927 :774ワット発電中さん:04/12/28 13:01:27 ID:dhBd1vbh
皆様、お久し振りです。
>>910
> 世の中の多くは上位レイヤのファンクションシミュレーションはC++やら
> Matlabやら使ってる

でも、どうしてCではなく、C++なんでしょうか?
 http://www.cybernet.co.jp/matlab/applications/dsp/
によると、SimulinkからはANSI-Cが生成されるとありますよ。

928 :774ワット発電中さん:04/12/28 13:52:58 ID:aXN1CriD
>>927
はぁ?
C++の全機能を使わなくてもC++の方が便利だからだ。極くわずかの点を除いてC++の言語仕様はCを
包含しているからだ。
SimulinkがCソースコードを出力するなら上で書いたわずかの相違点が問題になる事柄以外は
それをC++で利用することは可能だからだ。
逆にピュアCを選択した時点でC++の機能を利用したくてもできなくなってしまうからだ。

929 :名無しさん@3周年:04/12/28 14:08:09 ID:dhBd1vbh
納得。やはりそうですか。確かにソフト開発でも、g++でコンパイルする事に
して、C+αのコーディングルールを採用すると開発効率が良いのは事実です
よね。ご回答、有難うございました。

930 :774ワット発電中さん:04/12/28 14:37:28 ID:O7LvgWgU
SimlinkからHWに落とすとき、ハードウエアのことを知らないと
できないですよ。 CからHWに落とすときも同じです。

931 :774ワット発電中さん:04/12/28 14:57:16 ID:aXN1CriD
上位レイヤのシミュレーションするのにC++やMatlabを使うという話であって、
誰もハードウェアに落とし込む下位レイヤのシミュレーションの話などしてないのだが。


932 :774ワット発電中さん:04/12/28 17:44:15 ID:X1LfI0vW
Matlab使ったことないので、よく分らないのですが、並列動作とかも恐らく
記述できるんですよね? だとして、C++で互いに通信し合う並列動作する
プロセスの記述とかはどう記述するのですか?

Matlabとはかなり違いますが、制御系主体のEsterel(Esterel Studio)だと、
Esterel記述からSequentialなANSI-Cを合成してくれますね。ちなみに、HY-C
はSystemCに、BDL(Cyber)はC++(CheckMate)に変換で、同一サイクルでの
(双方向)データ転送はEsterelとHY-Cのみで記述可能、BDLは未サポートです
よね。

933 :774ワット発電中さん:04/12/28 18:37:35 ID:Tx/8DQsG
MatlabだろうがCだろうがJavaだろうがハードウェアにあるような並列動作の動的な
シミュレーションなどはできない。擬似的にできた気分になったとしても正確には無理。
そりゃそうだろ元がCPUなんだから。マルチコアが進む今後は知らんが?
C/C++でやるときはプロセス間通信を使えばそういう気分に浸ることはできるかもね。
だいたいMatlabをどう考えてるか知らんがあれは単なる行列エクセルだぜ。
とりあえずただのOctaveかScilabでも使ってみれば。

934 :774ワット発電中さん:04/12/28 18:52:44 ID:AhgAgUc9
うわ、simulink使った事無い高卒が一匹紛れ込んでるなwwww

935 :774ワット発電中さん:04/12/28 18:58:27 ID:ns1bI6ux
Matlabを使うならは、こう言う使い方でしょう
http://ne.nikkeibp.co.jp/members/NMDNEWS/20040929/105593/

936 :774ワット発電中さん:04/12/28 19:01:48 ID:Tx/8DQsG
大体>>932が考えてるシミュレーションは何のためにしたいわけ?
上位のシミュレーションでは、実装予定のすべてをシミュレーションしたりしない。
そんなの時間の無駄だし、やること自体意味ないからな。
じゃ。なんのためにするかといえば、パラメータやアルゴリズム決めるためにもっぱら使う。
下手に制御段数を複数にすると発振してしまうのでそれを防ぐためにはどういう
フィードバックループ、フィルタゲインを考えるかとかだ。
仕様が決まってて作ったものがそれを満たすかどうかを確認する目的じゃなくてむしろ
仕様を決める手段として使う。

>うわ、simulink使った事無い高卒が一匹紛れ込んでるなwwww
アホが参上したようだな。本質が全くわかってないだろお前は。

937 :774ワット発電中さん:04/12/28 19:02:25 ID:ns1bI6ux
すまん、ちょっと言葉足らずだった、これも参照してくれ
http://ne.nikkeibp.co.jp/members/01db/200204/1010022/

938 :774ワット発電中さん:04/12/28 19:05:43 ID:Tx/8DQsG
>>835
確かにそういう使い方もできるだろうけど。
あんまり意味ないんだよね。

939 :774ワット発電中さん:04/12/28 19:09:51 ID:X1LfI0vW
SimulinkはSDF(Synchronous Data Flow)をベースにしてると聞いた事があった
ので、その意味での並列処理は記述可能なハズなんだろうと思って質問した
んですけどね。結局生成されるC記述というのは、EsterelのようにSequential
な記述なのか、それともスレッドとかプロセスを用いた記述となっているので
しょうか?

Simulinkでシステム的なパイプライン(粗粒度並列パイプライン)アーキを如何
に決定するかが腕の見せ所、とも聞き及んでおりますが、その通りなんで
しょうか?

エロイ方、ご教授お願い致します。

>>933
シングルCPUで、並列動作を模倣する事が前提の議論です、念のため。HDL
はその最たるものでしょ。

940 :774ワット発電中さん:04/12/28 19:22:55 ID:AhgAgUc9
>>938
初めて見てカルチャーショックか?
本質的に並列処理・マルチスレッドで記述可能なデータフローモデル
に基づいたsimukinkやLabviewからDSPのコード生成するなんて話は昔からあって、
そのC生成版では並列をどう扱ってるのかという質問だろうが。

941 :774ワット発電中さん:04/12/28 19:29:26 ID:X1LfI0vW
研究自体は、さかのぼる事1980年代ですね。U.C.BerkeleyのEdward Lee教授
がSDFの提唱者ですしね。

ハード設計に関してそれほど需要はないと思って今まで無視していたのが
正直な所ですね。

で、差し支えない範囲で、C生成版では並列をどう扱ってるのかお答え頂け
ないでしょうか? 宜しくお願い致します。

942 :774ワット発電中さん:04/12/28 19:35:40 ID:04/nGq3o
>>940 で?答えは?煽るだけか?

943 :774ワット発電中さん:04/12/28 19:50:56 ID:xc2S39Yq
>>942
>>940が必死に調べてるからちょっと待ってやれよ。

944 :774ワット発電中さん:04/12/28 19:52:23 ID:eRvkXBIr
一行煽りは何故か二度と同じIDで現れない。

945 :774ワット発電中さん:04/12/28 20:13:37 ID:xc2S39Yq
>>940
>C生成版では並列をどう扱ってるのかという質問だろうが。

知ってるんなら答えてあげれば?


946 :774ワット発電中さん:04/12/28 20:30:18 ID:ns1bI6ux
>>934 = >>940  ID:AhgAgUc9

947 :774ワット発電中さん:04/12/28 20:30:52 ID:DZQ7BIM8
>>945
答えられるわけないよな。一万歩譲って研究室で持ってるだけで、使いこなすどころか使い方すらよくわかっていない
にちがいない。

948 :774ワット発電中さん:04/12/28 20:38:56 ID:ns1bI6ux
カタログ研究室のこと? 

この研究室ではカタログを研究するだけだそうです。

949 :774ワット発電中さん:04/12/28 20:42:44 ID:/sUGKjWx
Matlab/SimulinkにLabview使いこなしてもあんまり自慢にならんわな。苦笑
ANSI-CしかもMatlabがいろんなOSで動くとすると、生成されるCコードは
シーケンシャルなもの以外だと困るように思うけど?
OS固有のスレッドの書き方されても・・・
つーかシミュレーションの実現方法なんてどうでもいいやん。
実用に耐えるHDL生成してくれるなら言うことないけどさ。
そうなったらSystemCなんてさらさら必要なくなるが。

950 :774ワット発電中さん:04/12/28 21:00:15 ID:sy8cGgDV
>>940
>並列処理・マルチスレッドで記述可能なデータフローモデル
>に基づいたsimukinkやLabviewからDSPのコード生成するなんて話
生成はできるだろうな。
製品に搭載できるレベルにあるかどうかが問題だと思うDSP屋の俺
SystemCの合成も同じ話じゃないの?
そういやPCB CADのオートルータどうなったっけ?

951 :774ワット発電中さん:04/12/28 21:10:08 ID:JUIUhDNE
オートルータはought to route ・・・「配線できた筈」で終わりマスタ


952 :774ワット発電中さん:04/12/28 21:35:06 ID:P+eyxGyh
PCB CADのオートルータは、とっくの昔に出来てバンバン使われている。

953 :774ワット発電中さん:04/12/28 21:49:54 ID:hKEjag+m
>>934 = >>940 = >>950

話しそらしたね。ここは、Routerを語るスレじゃないきに。

954 :774ワット発電中さん:04/12/28 21:58:40 ID:sy8cGgDV
>>953
俺は>>940じゃない。 >>940間違われたじゃないか出てきてなんか言え!!
電気屋の癖にMatlabに長けてる奴なんて(ry

・オートルータ
・自然言語の自動翻訳
・SystemCの合成
なんか同じ匂いがするんだが

955 :774ワット発電中さん:04/12/28 22:23:08 ID:7QwLXuTl
第五世代コンピュータ
とか


956 :774ワット発電中さん:04/12/28 22:36:15 ID:hKEjag+m
また話しがそれとろうが。意図的としか思えんきに……。

957 :774ワット発電中さん:04/12/28 22:40:13 ID:sy8cGgDV
だから俺は>>940じゃないってば!
それどころか
>>940 == >>953 == >>956
じゃないのか?人に擦り付けるとは見事なやり口だな。

958 :774ワット発電中さん:04/12/28 22:45:26 ID:hKEjag+m
> 人に擦り付けるとは見事なやり口だな。
その言葉そのまま返してやるき。大体からして、おまんが話題変えたんは
事実じゃろがあ! おまんが、一番怪しいき。



959 :774ワット発電中さん:04/12/29 00:20:30 ID:vhMfmOBq
設計ゴッコツールとしては優秀なんじゃない?SystemCって。


960 :774ワット発電中さん:04/12/29 05:02:58 ID:WuBITndV
だからと言って、SystemVerilogも「抽象度を上げた設計効率化」 の解には
成り得ないんだよね。だから、辛いんよね。現状、実装へのパスがあって
Cベースなのは、BDL(Cyber)とHY−C(eXCite eXpert)
だけだけど、未だ海のものとも山のものとも判んないだよね。ここいらの
情報きぼんぬ!

961 :774ワット発電中さん:04/12/29 10:50:50 ID:gESDmB48
systemC community(http://www.systemc.org)
が文字化けしまくりなので英語表示したいのですが、
どうすれば英語表示できますか?




962 :774ワット発電中さん:04/12/29 11:09:43 ID:yx6ofRoh
SiftJISでみられる筈
PCを英語環境にすれば、自動で英語版読めます。

963 :774ワット発電中さん:04/12/29 11:44:03 ID:oZsKlgyl
>>960
もう知ってるかと思われるが、Cyberはある意味完璧
ここに詳しくある 登録は必要だけど読め
ttp://ne.nikkeibp.co.jp/members/01db/200301/1010509/

964 :774ワット発電中さん:04/12/29 12:52:37 ID:qHNMN3rU
http://tmp4.2ch.net/test/read.cgi/company/1100361078/194-200
[奢れる]NECエレクトロニクス[カンパニー]

194 : :04/12/27 12:26:46 ID:n65FUxJP
Cyberより、こちのほうがいいんじゃねぇのか?
http://www.coware.co.jp/news/2004/2004.11.16.html

198 : :04/12/28 04:58:21 ID:xQgpghdQ
>>194
心配するな、それだけは有り得ないから。


199 : :04/12/28 05:04:02 ID:88zfsf3I
Cyberは鶏冠タンが大好きだし。
鶏冠タンがいるかぎりやめないだろ。


200 :  :04/12/28 09:10:00 ID:5OrobazQ
好きなのはいいが誰もつかってないだろ。
株価下落の責任とれ!

965 :774ワット発電中さん:04/12/29 13:10:49 ID:CgndsGOJ
続き
http://ne.nikkeibp.co.jp/NEWS/dac2003/030317_1.html
http://ne.nikkeibp.co.jp/members/01db/200301/1010509/

966 :774ワット発電中さん:04/12/29 13:23:11 ID:CgndsGOJ
>>941
正しい解になっていないが、
>SimulinkはSDF(Synchronous Data Flow)をベースにしてる

だから、これができる
  http://ne.nikkeibp.co.jp/members/01db/200204/1010022/

因みに、>>934 = >>940  ID:AhgAgUc9 ではないのであしからず

967 :774ワット発電中さん:04/12/29 13:24:11 ID:qHNMN3rU
続き
http://tmp4.2ch.net/test/read.cgi/company/1093497747/305
でも、設計者のノウハウをそのままインプリして、

  こういう回路が欲しけりゃ、こう記述しな
  でないと、実用的な回路は出ないのね

とか

  最適化のコストを指定しても、結果はそれに従わないから
  取り合えず何通りも合成して、好きなの選んで

とかいうのは、ねえ……。結局、RTL設計できないと使えないじゃん

http://tmp4.2ch.net/test/read.cgi/company/1093497747/305
NECのC言語合成ってCyberのことかな。
ありゃダメダメ。
回路のことを知らないヤツらが使ってるから、
論理的には合ってても回路的にはメチャクチャなものを作りやがる。
それをさらにCyberでコンパイルすると、
理解不可能なnetlistが出来上がる。
Verilog RTLの方がはるかにマシ。

968 :774ワット発電中さん:04/12/29 13:46:27 ID:L1fO0wyv
この際比較対象はシミュレーション以外に能の無い
ナンチャラCだろうから、回路の事を知らない香具師ら
が作ったソースから、(中身はともかくとして)動く物ができるなら
遙かに良いという結論でいいんじゃないかい?


969 :774ワット発電中さん:04/12/29 15:08:26 ID:dvBbiuwj
そういう意味だと、HY−CかBDLのどっちかになるね。片方はベンダだけ
ど、片方はNだよね。一般に入手可能なのは、前者の方のみって事なのかな?

970 :774ワット発電中さん:04/12/29 18:53:02 ID:c9LwaSlz
>>969 結局かね使える会社の勝ちってことで>>767の解答は分かった。
すごい金使ったことだけのことはある、
駄目っていってる967は嫉妬しているだけ。

現実に気がつかないし、目の前の成功事例を否定するだけのノータリン
LSIメーカが使えたって言ってるんだから敗北認めろそろそろ。
馬鹿には使えない道具だけどのー 
お馬鹿が使うと>回路的にはメチャクチャなものを作りやがる。
Verilogと比較して「まし」などというのがお馬鹿の証拠



971 :774ワット発電中さん:04/12/29 19:04:03 ID:L1fO0wyv
金使える会社が金をドブに捨てているだけだったりして

972 :774ワット発電中さん:04/12/29 19:06:22 ID:S6D+SLr6
メーカー系は一旦はじめてしまうと簡単には辞められないから糞でも
万歳して延々続けてユーザーがある程度減った時点で終息させる事が
多い。
散々メーカーに振り回された経験は無いんだろうか?
現実社会を知らない?

973 :774ワット発電中さん:04/12/29 19:34:32 ID:5aZNctzg
>>767 の回答は(実は朝鮮系である)創始者の未亡人が未だに人事権を掌握する
しかも粉を飾ざっている国内大手の(情報)家電メーカじゃないの?

コンサル事業は失敗、銀行は累積赤字、ってね。

さて、そんな端金で完成度の高い合成を含めた上流設計ツールは常識的に
考えて構築出来ないよ。80年代前半から取り組んで来たそうだしね。でも、
エL では使われていないって事だから、まあ、>>972 の言う通りなのかも
知れないし、RTLのプロ以外はきちっと恩恵を受けているのかも知れないし、
それは判らんけどね。

974 :774ワット発電中さん:04/12/29 20:50:48 ID:RtBrWnkX
>>973
決め付けないほうが恥じかかないよ。
どうせ、2chの発言程度と思っていても、
つい上司とかに訳知り顔で話したりせぬように。
子会社、関連会社にもいきわたり始めてるという話もあるし。
教育も相当の数のエンジニアが受けてるから品質悪いエンジニアも中にはいるようだけど、
ま、基本常識としてロジックを知っていればそこそこ使える <という話だ
確認はしてないし出来ないけどね。
EL関係者の発言は無いかね??
技術丸ごと米国系EDAに売ればいいのになー そんなの独り占めしてないで



975 :774ワット発電中さん:04/12/29 21:19:35 ID:0zA8JvUn
>>972
高卒工員の現実はその他の人の現実とは違うよ。
勝手におまえの悲惨な現状を周囲に敷衍するな。

976 :774ワット発電中さん:04/12/29 21:23:23 ID:IMWrnuae
ID:0zA8JvUnは荒らし。
無視の徹底をお願いします。

2chブラウザで透明あぼーんに設定すると消し去れるので精神衛生上よろしい。

977 :774ワット発電中さん:04/12/29 21:25:01 ID:0zA8JvUn
反論できなくなるとあぼーんして精神の安定を図る高卒って哀れだね。
まぁそんなんで精神の安定を図れるくらいでなければ
悲惨な現実に耐えられずに自殺しちゃうのかもねww

978 :774ワット発電中さん:04/12/29 21:27:28 ID:L1fO0wyv
>977
自虐趣味なんだね。

979 :774ワット発電中さん:04/12/29 21:30:45 ID:/ZctxjTz
クソスレに急落したな、ここ。
200台までの味はどこえやら・・・

980 :774ワット発電中さん:04/12/29 22:02:33 ID:5aZNctzg
>>974
上にある >>964 が関係者の発言と取れなくはないかも。取り合えず、社長が
オキニのようで、関係する会社しか使用する事が出来無そうな感じだね。
つう事は、恐らくASICのお得意とかでもない限り、競合メーカでは利用でき
ないのかも知れんね。となると、ベンダがやってるHY−Cになるのかな。もう
売ってるんだっけ? 評価した人とか居ないの?

981 :774ワット発電中さん:04/12/29 22:51:53 ID:kBypYkE5
>>980
ソリトンの関係者ですね。
◎立はSystemCに逝っちゃたし、◎立ITは教育まで始めたし
○ネサスだけが頼りだけどSHはSuperHの関係でSystemCに軸足移したしね。
あせるね
HY-Cすでにアボーン
たとえばだけどね、BDLは普通にもう使ってるんだって...ちょっろっと検索してみろ

ttp://www.adte.co.jp/job/job_lsi.html
別に、EL向け設計やってる会社ならどこでも使えるよ

昔、うちの会社にもいたけど自動車教習所で仮免もまだなのに、
ポルシェは立ちあがり悪いしBMWはエンジン音がいまいち好きになれない、
やっぱり、アルファかな?でも雨漏りするから日本では使い物にならないなー
なんていうやつ
お前だよ!

先ずは自分で運転できるようになってから意見いいたまえ!!
頼めば貸してくれるけど、馬鹿には貸さないから気をつけろ

982 :774ワット発電中さん:04/12/29 22:55:45 ID:/ZctxjTz
俺は知っている
お前は知らない
だから黙れ

・・・はいはい黙りますよ

983 :774ワット発電中さん:04/12/29 22:55:54 ID:L1fO0wyv
SystemCは実在しない車だもんな・・・流星号か?
あんなもの誰も運転できないって。

984 :774ワット発電中さん:04/12/29 22:58:08 ID:icRnP+wn
>>973
実は朝鮮系だったらどうだというのだろうか…底が見えたな。

985 :774ワット発電中さん:04/12/29 22:58:52 ID:L1fO0wyv
SystemCはプラモデルである


986 :774ワット発電中さん:04/12/29 23:52:19 ID:KPpVBIlR
>>982
黙ってみてろ
ちゃりんこヤローに車の運転とやかく言われたくない
知らない世界に来るんじゃない!
実在しないんだよ。当分ね。
SystemLSIを設計する為のものだからね。
想像つかない世界にくびつっこむんじゃね!!


987 :774ワット発電中さん:04/12/30 00:07:28 ID:M/1ljra4
SystemLSIを設計するものじゃなくて、仕様検討する道具だろ?
あくまでもシミュレーションしかできないんだからなぁ。

988 :774ワット発電中さん:04/12/30 00:10:31 ID:M/1ljra4
>986はATしか運転できないのであった。

989 :774ワット発電中さん:04/12/30 01:14:24 ID:SCEP2o2m
>>988
うまいこと言うね(笑
よく分かった。そのとおり楽だからねAT
マニュアルで俺に勝てるならいいけど?
技術あっても、6リッターAT車にいくらマニュアルでも軽自動車じゃ
勝てないっしょ
趣味の世界ではいいかもね。 細かなテクニック議論するのも
考えただけで穴が痛くなってきたー
目的地に快適に着けばいいんだよ 仕事だからねー

990 :774ワット発電中さん:04/12/30 02:40:02 ID:PWYr7ixV
>>987
その仕様検討こそが大事なんだけどね、最近は。
世界中から追い上げられている中で、どの会社も簡単には失敗できないからなぁ。
設計まで出来れば理想だけど、そうでなくてもやる意味はあると思うよ。
Verilogなんかに比べると理不尽に見える所が多くて大変だったけどね(笑)。

991 :774ワット発電中さん:04/12/30 04:48:29 ID:XejpbR0U
>>981
〇ルネ〇スがSystemCに軸足? ありえねぇ〜。つうか、SystemCの合成捨て
てる筆頭じゃなかったっけ?

バグだらけのツール、早く修正して下さいね。って、お前に言っても無駄か wwww

992 :774ワット発電中さん:04/12/30 05:19:53 ID:JTaKj8aH
>>981 = >>986 = >>989
Cyberの関係者ですね。開発部隊か特約店かは知らんが。

ちなみに、これギャグか?

http://www.adte.co.jp/job/job_rd.html
1.業務紹介
 今までに蓄積してきた技術を活かし、高度な LSI 開発を行なっています。
現在はオーディオ系のチップを手始めとして、各種マルチメディア・コーデック
の基礎技術を開発中です。

4.開発ツール
   開発環境        LINUX WINDOWS
   HDL シミュレータ    NC-Verilog Cadence社製
               Model-SIM Mentor社製
   オープンソース開発環境 GNU Compiler Collection (gcc)

( ゚Д゚)ハァ? 何で、BDLベースでClassMateを使わないんだあ?

>別に、EL向け設計やってる会社ならどこでも使えるよ
無理矢理、押し付けてるって事ね。つか、競合他社への納入実績が無いなら
話にならんだろうが。第一、公開する気があるんかマジで? 仮に公開した
としてもツールがバグったときに、競合だったら設計データ出せないのは
常識だろ。一体、どうしたいのチミは?

993 :774ワット発電中さん:04/12/30 07:57:09 ID:yM8qltmp
>>991
ttp://ne.nikkeibp.co.jp/members/NEWS/20040716/104536/
「ケータイ向けチップはすべてSystemCで検証」
この講演の記事読む限りHY-Cの一言も言ってないんだが

全部SystemCだって

994 :774ワット発電中さん:04/12/30 11:01:52 ID:kQcTkF17
検証だけ・・な


995 :774ワット発電中さん:04/12/30 11:03:13 ID:kQcTkF17
>989は遊園地のゴーカート

996 :774ワット発電中さん:04/12/30 11:56:27 ID:S+IB5z4g
>技術あっても、6リッターAT車にいくらマニュアルでも軽自動車じゃ
>勝てないっしょ
満足に車を走らせたことが無いというのが見え見えだね。
それに、シミュレーションだけだから、ゲームの
画面上で走らせてるだけみたいなものだしな。
そんな絵に描いた車より、実際にちゃんと
公道走れる軽自動車の方がずっといいよ


997 :774ワット発電中さん:04/12/30 12:33:42 ID:N8hGQHW2
ちなみに、次スレはあるのかしら?

998 :774ワット発電中さん:04/12/30 13:16:29 ID:S+IB5z4g
シミュレート板にでも逝った方がいいんじゃね?


999 :774ワット発電中さん:04/12/30 14:24:08 ID:a3+QSrII
話の方向が定まったようですなぁ

1000 :774ワット発電中さん:04/12/30 14:24:44 ID:a3+QSrII
終了じゃ

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

348 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)