アカウント名:
パスワード:
「オープン」なプロジェクトというのは、ソースがオープンなのは当然として、仕様書、バクトラッカ、ヴァージョン管理（CVS）など開発過程そのものがある程度開かれていて、複数の人間が関わっているというのが特徴ではないでしょうか。
オープンにしたから、それだけで Linux とか Apache のように成功すると考えるのは甘いわけで、定期的なメーリングリストでのコミュニケーションに始まり、コードを書く上での規定（coding standard）、チームそのも
僕の言葉足らずと日本語のコンピュータ用語の訳語のまずさのせいもありますが、設計と実装に理解の食い違いがあると思います。 回路図や「回路にあわせて配線長や太さ、部品の電気的物理的干渉などを考え」る過程は設計ではなく、ソフトウェアにおけるソースコード、つまり実装(implimentation)にあたると思います。 詳しくは、Re:オープンアーキテクチャー [srad.jp]に書き散らしましたが、 ハードウェアの設計にあたる部分はより抽象的な設計、アーキテクチャ、になると思います。
実際ソフトウェアでも、ソースは製品(product)ではなく、それを製造(build)する必要があります。ただ、zeissmania氏 [srad.jp]や AC氏 [srad.jp]らが述べてる通り、ソフトウェアの製造はコンパイラで自動化されていて透明化されていますが、ハードの製造は比べ物にならないコストがかかることになります。
プログラマの立場から見ると、実際の製品の安定性やコストなど含めた設計図の実装に複数の人間が関わることに意義があると思うので、製造は誰がやろうとあまり関係が無いことです。ただ、この製造過程がどうにかならない限り、アマチュアが実装を平行作業させるのは難しいことは想像がつきます。
＃それが分かっていないが故の日本の現状なんですけどね。
僕が言いたかったのは、AC氏 [srad.jp]の 設計 ＝ 回路図 実装 ＝ 現物
に対して、 設計 ＝ アーキテクチャ(1 byte = 8 bit) [srad.jp] 実装 ＝ 回路図 / ソースコード 製造 ＝ 現物 ということです。
安定した現物や実装を無視した設計というのはありえないし、アーキテクトは実装レベルにも深く関わることでしょう。しかし、「ことハードウェアに関しては、コンセプトと実装とが切り離せるなんて妄想のレベルです。」というのはどうかと思います。IBM Symtem/360 や IBM PCは妄想でしょうか？
「それが分かっていないが故の日本の現状」のそれっていうのは、「コンセプトと実装とが切り離せるなんて妄想のレベル」であり、「ブロックレイアウトが見えてなければアーキテクチャの設計なんて出来」ないというのが分かってないが故の日本の現状ということでしょうか？で、日本の現状というのはどのような状態なのでしょうか？多分悪い現状なのでしょうが、ハードウェア業界に詳しくないので、まったく分かりません。
LSI設計におけるアーキテクチャ設計とは、要求仕様はもちろん、例えばメモリの速度、場合によっては配線遅延などデバイスの特性に大きく左右されながら行うものです。わかりやすい言葉を使えば(ただし正確ではない)、リアルタイム性を意識することがとても多いです。
例えば、メモリに1000個入っている値を全て加算する、という要件があります。大雑把ですが、j3259さんの言っているアーキテクチャでは、どのような命令セットを定義するかを考え、結論は個々のマシンで共通した命令セットを作ればよいという答えに達すると思います。
LSIの設計ではどうかといいますと、結果はいつまでに出せばよいか、メモリの応答速度はどのくらいか、スループットはどれくらいか、などを考慮し、間に合うんだったら数個の加算器をループさせて使うし、時間的に厳しいなら加算器を999個並べようとします。でもそれではメモリ帯域が、、、云々。これがLSIでいうアーキテクチャ設計です。
設計と実装は階層的な言葉です。Cのソースコードが設計でコンパイラがマシン語に変換することを実装といいますが、そのマシン語を実行するためには命令セットの"設計"というものがどこかであるわけです。その命令セットを実行するためにCPUという"実装"があるわけですが、それもまたどこかで"設計"という作業があるわけです。つまり、両者ともおのれが言っているアーキテクチャや設計という言葉がどのレベルを指しているか気をつけないといけないということです。
長ったらしいけど最後に、日本の経済状態が悪いのはほぼ無関係でしょう。
設計とか実装とか言ってるうちに、オープンハードウェアからずいぶん話が逸れてしまった（反省
結局、アマチュアのレベルで設計図を共同作業で作成するってのはどれぐらい可能なんでしょうか？VHDLとかPSpiceとか言葉しか聞いたことがないんですが、シミュレータ上で色々試したりとかできるんでしょうか？
オープンソースというのは、金銭的な見返りをメインに求めず、何か作りたいという自己の欲求を満たすようなものですから、この「欲求」をどれだけ満たせられるか、そしてコストとのバランスが問題だと考えています。
LSI設計レベルでのオープンハードウェアに的を絞って書きます。
gEDA [seul.org]を見ていると、フリーのverilogのシミュレータはあったりします。つまり、LSIの設計はできるわけですが、そのシミュレーションスピードはハードウェアより遥かに遅いわけです。それで「欲求」を満たすことができるかというと、とてもできるものじゃないと考えています。
32BitCPUを設計している会社にいたのですが、高速なLSIシミュレータをオーダーメイドで作っていました。市販のシミュレータと比較して2ケタから3ケタ高速でしたが、それでも組み込みOSを起動して仮想端末に"Hello World"を出すのに2時間程度のシミュレーション時間が必要でした。
このような経験から、VHDLやVerilogで何かLSIを設計しても、シミュレーションのみじゃつまらなくて、オープンソースソフトウェアのようなムーブメントはまず起こらないだろうというのがQsの考えです。
また、opencores [opencores.org]のように、IPコアを公開しているケースもありますが、コードを見てみると、合成ツールを持っている人が結構います。つまり、公開している人間はLSI設計環境をもっている人間が多い。でも設計ツールというのはべらぼうに高価なので、そうそういる訳ではありません。つまり、コード設計人口がとても少ないと考えられます。
とても悲観的ですが、現状ではオープンハードウェアは幻想でしかなく、LSIを設計したいと考えている共同開発者を探すことすら難しいと思います。ただ、企業と連携できれば話は違ってくると思いますが、どうやって連携に持っていくことができるか、検討も付きません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
過程がオープンじゃなきゃダメ (スコア:3, すばらしい洞察)
「オープン」なプロジェクトというのは、ソースがオープンなのは当然として、仕様書、バクトラッカ、ヴァージョン管理（CVS）など開発過程そのものがある程度開かれていて、複数の人間が関わっているというのが特徴ではないでしょうか。
オープンにしたから、それだけで Linux とか Apache のように成功すると考えるのは甘いわけで、定期的なメーリングリストでのコミュニケーションに始まり、コードを書く上での規定（coding standard）、チームそのも
Re:過程がオープンじゃなきゃダメ (スコア:1, 参考になる)
回路図が設計で、現物が実装です。当然担当を別の人にすることができます。
ですが小規模なハードウェアならともかく、通常は複数人がさまざまな段階を担当し、互いに密接に連絡を取らなければまともな物は作れません。
仕様を決定する際にも、使いやすさや大きさ、消費電力や使用条件、そして一番大事な値段を考えなければなりません。
これらは回路設計以降の全てに影響します。
回路設計は、それらの仕様を満たすために、回路規模や部品の入手のしやすさ、実装のしやすさなどを考えます。
その際、ファームウェア
設計、実装、そして製造 (スコア:1)
> 回路図が設計で、現物が実装です。当然担当を別の人にすることができます。
僕の言葉足らずと日本語のコンピュータ用語の訳語のまずさのせいもありますが、設計と実装に理解の食い違いがあると思います。
回路図や「回路にあわせて配線長や太さ、部品の電気的物理的干渉などを考え」る過程は設計ではなく、ソフトウェアにおけるソースコード、つまり実装(implimentation)にあたると思います。
詳しくは、Re:オープンアーキテクチャー [srad.jp]に書き散らしましたが、 ハードウェアの設計にあたる部分はより抽象的な設計、アーキテクチャ、になると思います。
実際ソフトウェアでも、ソースは製品(product)ではなく、それを製造(build)する必要があります。ただ、zeissmania氏 [srad.jp]や AC氏 [srad.jp]らが述べてる通り、ソフトウェアの製造はコンパイラで自動化されていて透明化されていますが、ハードの製造は比べ物にならないコストがかかることになります。
プログラマの立場から見ると、実際の製品の安定性やコストなど含めた設計図の実装に複数の人間が関わることに意義があると思うので、製造は誰がやろうとあまり関係が無いことです。ただ、この製造過程がどうにかならない限り、アマチュアが実装を平行作業させるのは難しいことは想像がつきます。
Re:設計、実装、そして製造 (スコア:1)
＃それが分かっていないが故の日本の現状なんですけどね。
違います？ (スコア:1)
> 違います。
が不明です。何がどう違うのでしょうか？
僕が言いたかったのは、AC氏 [srad.jp]の
設計 ＝ 回路図
実装 ＝ 現物
に対して、
設計 ＝ アーキテクチャ(1 byte = 8 bit) [srad.jp]
実装 ＝ 回路図 / ソースコード
製造 ＝ 現物
ということです。
安定した現物や実装を無視した設計というのはありえないし、アーキテクトは実装レベルにも深く関わることでしょう。しかし、「ことハードウェアに関しては、コンセプトと実装とが切り離せるなんて妄想のレベルです。」というのはどうかと思います。IBM Symtem/360 や IBM PCは妄想でしょうか？
「それが分かっていないが故の日本の現状」のそれっていうのは、「コンセプトと実装とが切り離せるなんて妄想のレベル」であり、「ブロックレイアウトが見えてなければアーキテクチャの設計なんて出来」ないというのが分かってないが故の日本の現状ということでしょうか？で、日本の現状というのはどのような状態なのでしょうか？多分悪い現状なのでしょうが、ハードウェア業界に詳しくないので、まったく分かりません。
Re:違います？ (スコア:1)
部品レベルの知識が全くなく、トラ技に掲載されているサンプル回路図をコピーすればちゃんと動くと思いこんでいるような上司に、何度泣かされたことか (-_-;;;;;
Re:違います？ (スコア:1, すばらしい洞察)
ハタでみていると、j3259さんとalpさんの言っている「アーキテクチャ」が大きくレベルが違っています。j3259さんが言っているアーキテクチャは、instruction set architectureのような、より上流を指しています。対してalpさんの言っているアーキテクチャはLSIのRTL設計のようなレベルを指しています。
LSI設計におけるアーキテクチャ設計とは、要求仕様はもちろん、例えばメモリの速度、場合によっては配線遅延などデバイスの特性に大きく左右されながら行うものです。わかりやすい言葉を使えば(ただし正確ではない)、リアルタイム性を意識することがとても多いです。
例えば、メモリに1000個入っている値を全て加算する、という要件があります。大雑把ですが、j3259さんの言っているアーキテクチャでは、どのような命令セットを定義するかを考え、結論は個々のマシンで共通した命令セットを作ればよいという答えに達すると思います。
LSIの設計ではどうかといいますと、結果はいつまでに出せばよいか、メモリの応答速度はどのくらいか、スループットはどれくらいか、などを考慮し、間に合うんだったら数個の加算器をループさせて使うし、時間的に厳しいなら加算器を999個並べようとします。でもそれではメモリ帯域が、、、云々。これがLSIでいうアーキテクチャ設計です。
設計と実装は階層的な言葉です。Cのソースコードが設計でコンパイラがマシン語に変換することを実装といいますが、そのマシン語を実行するためには命令セットの"設計"というものがどこかであるわけです。その命令セットを実行するためにCPUという"実装"があるわけですが、それもまたどこかで"設計"という作業があるわけです。つまり、両者ともおのれが言っているアーキテクチャや設計という言葉がどのレベルを指しているか気をつけないといけないということです。
長ったらしいけど最後に、日本の経済状態が悪いのはほぼ無関係でしょう。
Re:違います？ (スコア:1)
いえいえ、ナイスなまとめどうもです。
設計とか実装とか言ってるうちに、オープンハードウェアからずいぶん話が逸れてしまった（反省
結局、アマチュアのレベルで設計図を共同作業で作成するってのはどれぐらい可能なんでしょうか？VHDLとかPSpiceとか言葉しか聞いたことがないんですが、シミュレータ上で色々試したりとかできるんでしょうか？
Re:違います？ (スコア:1)
オープンソースというのは、金銭的な見返りをメインに求めず、何か作りたいという自己の欲求を満たすようなものですから、この「欲求」をどれだけ満たせられるか、そしてコストとのバランスが問題だと考えています。
LSI設計レベルでのオープンハードウェアに的を絞って書きます。
gEDA [seul.org]を見ていると、フリーのverilogのシミュレータはあったりします。つまり、LSIの設計はできるわけですが、そのシミュレーションスピードはハードウェアより遥かに遅いわけです。それで「欲求」を満たすことができるかというと、とてもできるものじゃないと考えています。
32BitCPUを設計している会社にいたのですが、高速なLSIシミュレータをオーダーメイドで作っていました。市販のシミュレータと比較して2ケタから3ケタ高速でしたが、それでも組み込みOSを起動して仮想端末に"Hello World"を出すのに2時間程度のシミュレーション時間が必要でした。
このような経験から、VHDLやVerilogで何かLSIを設計しても、シミュレーションのみじゃつまらなくて、オープンソースソフトウェアのようなムーブメントはまず起こらないだろうというのがQsの考えです。
また、opencores [opencores.org]のように、IPコアを公開しているケースもありますが、コードを見てみると、合成ツールを持っている人が結構います。つまり、公開している人間はLSI設計環境をもっている人間が多い。でも設計ツールというのはべらぼうに高価なので、そうそういる訳ではありません。つまり、コード設計人口がとても少ないと考えられます。
とても悲観的ですが、現状ではオープンハードウェアは幻想でしかなく、LSIを設計したいと考えている共同開発者を探すことすら難しいと思います。ただ、企業と連携できれば話は違ってくると思いますが、どうやって連携に持っていくことができるか、検討も付きません。
Re:違います？ (スコア:0)
> どうやって連携に持っていくことができるか、検討も付きません。
STARCは？
まぁ、オープンとはちょっと違うか。
それに実作業者でないおっさん達が
各社の思惑をぶつけ合ってるだけっぽいし。
Re:違います？ (スコア:1, 参考になる)
横レスですみませんが、結局ハードウェア関連のシミュレーションはシミュレーションでしかないので、そこから先をどうするかだと思います。
チップレベル・基板レベルのシミュレーションは処理時間などの関係から正確にはできないので、なんらかのデフォルメをしてシミュレーションすることになります。例えば、機能レベルのＲＴＬシミュレーションでは通常はゲート遅延や配線遅延は考慮しません。逆に遅延まで考えるゲートレベルシミュレーション（めちゃくちゃ時間がかかります）の場合は、普通は全機能のシミュレーションはしません。Spiceだったら、全回路だと重いので、関係のない回路は削除します。
ですから、最終的には必ず実機を作って確認することになります。
また、昔なら（デジタル回路なら）回路図通りに作れば動いたものですが、現在のクロック数十ＭＨｚ以上（基板なら20～40MHz、LSIなら100MHzよりやや下あたりか？）で動くものでは回路図があっても、安定して動かすのは容易ではありません。つまり、回路図やネットリストがあってそれにしたがって作っても、動作は一様にはならないということです。
動作を確認していくにも、通常はデジタルオシロスコープやロジックアナライザなどの高価な機器に頼らなければいけません。（あまり頼らずにデバッグできる神様みたいな人もまれにいますが・・・）
オープンソースソフトウェアの場合には、低コストのＰＣ／ＡＴ（もちろん他のハードウェアもありますが）という開発者・利用者間で共通に同じ動作をすることが保証されているプラットフォーム、ＧＣＣなどの共通の開発ツールがあるからこそ成り立つのです。
現在、ハードウェアの分野でこのような環境を実現してくれるものはＦＰＧＡだと思います。ＦＰＧＡで作っても、結局基板レベルでは難易度は変わらないのですが、ＦＰＧＡの外は共通のハードウェア（中は金をそれほどかけずに独自のものが作れる）にすることでオープンソースハードウェアの可能性が見えてきます。
モルフィーは共通のハードウェア＋ＦＰＧＡ（ＣＰＬＤ）で少しでもこれに近づけようとしていたのでしょうが、実現性も危ういままに先に大規模に金を集めてしまった、というのが最大の失敗でしょうね。