Chiselでのハードウェア記述入門編「Hello Chisel3.3 !」
はじめに
Chisel3.3が出てたので、自分の簡単なコードを。IDEとかの環境構築はまたの機会に。 詳しいことは公式かdiningyoさんのブログで確認した方が良いです。 www.tech-diningyo.info
scala.sbtの設定
まずはscala.sbtを記述。とりあえず自分はこんな感じにしてます。意味はそんなに分かってないです。
scala.sbt
name := "Chisel_project" //自分のプロジェクト名
version := "0.1"
scalaVersion := "2.12.11"
scalacOptions ++= Seq("-deprecation", "-feature", "-unchecked", "-language:reflectiveCalls", "-Xsource:2.11")
resolvers ++= Seq(
Resolver.sonatypeRepo("snapshots"),
Resolver.sonatypeRepo("releases")
)
libraryDependencies += "edu.berkeley.cs" %% "chisel3" % "latest.release"
libraryDependencies += "edu.berkeley.cs" %% "chiseltest" % "latest.release"
実行方法
src\main\scalaフォルダ直下に次のMain.scalaとHello.scalaを作成する
Main.scala
object Main extends App{ val verilogString = (new chisel3.stage.ChiselStage).emitVerilog(new Hello) // verilogコードを吐く println(verilogString) // verilog のprint ただの確認用 }
Hello.scala
import chisel3._ class Hello extends Module{ val io = IO(new Bundle() { // ここで入出力の宣言 ここでは宣言してないので暗黙のinput reset のみ }) }
Main.scalaを実行すると下のようにVerilogファイルHello.vが出力される。
Hello.v
module Hello( input clock, input reset ); initial begin end endmodule
Steal/No-Steal と Force/No-Force
Steal / No-Steal とは
コミットされていない更新をディスク上のDBに反映するか否か
Steal
- データを段階的にディスクに書き込むのを許す
- Undo Loggingが必要
- 大きいバッファ空間必要
No-Steal
- コミット前は更新をDBに書き込まずに全データを一度に書き込む
Force / No - Forceとは
コミット前に全ての更新をDBに反映するか否か
Force
- コミットする前に全てのDBをすぐに更新
No-Force
- DBを更新しなくても良い
- Redo Logging が必要
- ディスク書き込み頻度高い（オーバーヘッドが大きいということ）
memo
世の中のDBはSteal and No-Forceがほとんど。 データを保存するディスクと、ログを保持するディスクがある。 メモリのB+ treeはキャッシュであり、WriteBackする。
*コミットとは
トランザクション（=メモリからディスク（DB）への書き込み）の完了
参考資料
http://www.tkl.iis.u-tokyo.ac.jp/top/modules/lecnote4/materials/2006/data_engineering_11_2.ppt
悲観的ロックと楽観的ロック
まずは背景
例えば、あなたの仕事のパートナー(彼)が1人いて、彼と一緒にオンライン上の発表資料(パワポ)を編集しろとの指示を受けたとする。 ここで問題が起こる可能性がある。
問題ないとき
- 別々のスライドを編集しているとき
問題があるとき
- 同じスライドを編集しているとき
あるときに、彼の編集しているマスと自分の編集しているマスが同じだったとき、どのようなことがおこってしまうのだろうか？
それは、これから説明する悲観的ロックか楽観的ロックかのそれぞれの場合かによって異なる。
悲観的ロック
同じ処理を異なる誰かが同時に行うことがよくあるという悲観的な考えで、
そのアイテム処理を誰かが行った瞬間に、他の人が処理を同時に行えないようにアイテムをロックすること。
処理を行っている人の処理が終わったらロックは解除される。
上の例だと、彼の処理が一通り終わるまではそのスライドの編集が出来なくなる。
悲観的ロックはどういう時に使う？
- 競合が発生する可能性が高い
- 更新頻度が多い
- トランザクションにかかる時間が長い
デメリット
同時に処理が行えないことはもちろんデメリット。また、上の例では彼の仕事がかけた時間に比例して良いスライドが作れる優秀な人間なら良いのだが、もし彼がポンコツのときは死ぬ。
楽観的ロック
同じ処理を異なる誰かが同時に行うことがあまりないという楽観的な考えで、 上の例だと、彼と自分は同時に作業できるけど、先に編集を終わらせた方の人のものだけが反映される。後の人の編集は無効になる。
楽観的ロックはどういう時に使う？
- 競合が発生する可能性が低い
- 更新頻度が少ない
- トランザクションにかかる時間が短い
デメリット
上の例だと、彼のポンコツぶりをカバーしようと頑張ってスライド作っていたのに、もしその時彼が同時に編集して彼が先に編集を終わらしていたら自分の編集が反映されない。
参考資料
こっち読んだ方がいい。
排他制御（楽観ロック・悲観ロック）の基礎 - NagaokaKenichiさん
