2018年4月23日月曜日

雑記 MarkUp MarkDown

MarkUp

もともとのテキストデータ(プレーンテキスト)に印刷指示命令を組み込むことで、より美しくテキストを表現する
例として、HTML、LaTeXなど
HTMLでは印刷指示命令のことを”タグ”と呼び、印刷指示だけでなくリンクを埋め込んだり様々な目的で利用される。

ただ、マークアップされたテキストデータは、本来必要な情報以外にタグが追加されるため、編集時に非常に分かりづらい(可読性が悪い)

MarkDown

マークアップによる可読性の悪さを改善するために、タグを短くしたり、マークアップする文章の書き方にルールを加えたりしたものがマークダウン
.MDとかPythonとか

ソースファイルは見やすくなるが、自由度が犠牲になる場合がある。
たとえばMDではスタイルを記述できないので、見出しのフォントや大きさなどは固定値になる
また、普段使わない記号をタグとして使用するため、慣れるまで入力に時間がかかったりする。(バッククォーテーションの場所を迷ったり、強調させたい時どの記号だったか忘れたり、リスト表示のフォーマットを忘れたり)

Pythonの場合は特殊な文法なため、かえって動きが想像しにくかったりする。

MDをHTMLに変換した結果

Atomの場合、GITのスタイルシートを基準に変換されるため、出力したHTMLを直接編集することはほぼ不可能。






MDを使ってMMDモデルのREADMEをかっこよく配布!

こんにちは、PiTです。
もうすぐOMF8が開催されますが、MMDモデラーの皆様は如何お過ごしでしょうか。

今日はMMDモデルに添付するREADMEを楽しつつかっこよくするための方法をご紹介します。


まずはこれを見てくれ

左がREADME.txt右がREADME.pdfです。
す、すごく読みたくなりませんか?

ともかく、単純なテキストファイルより、綺麗に編集され、まとまった文書のほうが読みやすいし、意図も伝わりやすいと思います。私は最近まで挿絵のない本とか全く読めなかったので、単なるテキストのみの解説書より絵入りのマニュアルのほうが好きなのです。


ここでの目的は、
”ダウンロードしてくれた人々が、隅々まで楽しめるようなコンテンツを作成すること”
”楽にかっこいい見やすいREADMEを作ること”
なので、MMDREADME問題の是非についてはここでは解説しません。
なぜ.MD(MarkDown)を使うのか、なぜPDF配布なのかについては最後に説明します。

□ATOMをダウンロード、インストール

いきなりですが、.MDの編集に、ここではAtomを使います。
ATOM以外のMDエディタを使ってもかまいません。
ATOMのダウンロード https://atom.io/
注意:AtomはMD専用のエディタではないので、他にもいろんな機能が備わっています。それらについての解説はできませんのでご了承ください。

□パッケージをインストール

Atomを起動して
File> Setting
設定メニューが開いたらInstall を選択
以下の4つのパッケージをインストールしてください。
markdown-writer
tool-bar
tool-bar-markdown-writer
markdown-pdf

また、メニューの日本語化が必要な方は、次のパッケージを追加します
japanese-menu

これで.MDを編集する準備が整いました。

□テンプレートをダウンロード

.MDはHTMLに比べてタグの種類も少ないので全てのタグを覚えてからでもかまわないのですが、MMDモデルの取扱説明書という限られた条件での文章を作成することを考えると、それほどいろいろなタグを使いこなす必要はないです。
それに、実際に動くファイルを弄って変化を見ながら工夫していくほうが、覚えやすいと思います。
なので今回はテンプレートを用意して、それを自分なりにカスタマイズするという手順で説明します。

テンプレートのダウンロード  https://bowlroll.net/file/164588

やっぱりめんどくさいので説明しません。しかし大丈夫です!わずか1ページです!弄れば分かります!

□READMEを編集する

ダウンロードしたテンプレートを適当に編集してください。
.MDのタグの解説などは解説しませんが、おそらくモデル制作をしている皆様なら、すぐ理解できると思います

□PDFで出力する

Packages>Markdown to PDF>convart














おめでとうございます。README.pdfが出力されました。
あとは配布したいモデルと一緒にZipして、配布サイトにアップすればOKですが、モデルのほうは完成してますか?( ゚д゚ )

□なぜ.MDを使うのか

覚えるべき項目が少ないので、比較的簡単に導入できる(と思う)
マニュアルはフォーマットが統一されていたほうが読みやすい
楽して綺麗なデザインにしたい

□なぜPDFなのか

最初に提示したとおりテキストファイルよりHTMLやPDFのほうがより見やすい
HTMLで配布してもいいけど、本来配布すべきコンテンツに.htmlが混じってると(略

□おわりに

MDの良さとかは私が語るまでもないので、特に書くことはありません。
HTMLが得意な人ならHTMLでも良いかと思います。
また、WordやOpenOffice、Googleドキュメントなどを使うのも良いですが、READMEを書くのにわざわざ…
というわけで、私にとって.MDでPDFを出力するというのは非常に良かったわけで、おそらく何人かの方は賛同して頂けるのではないでしょうか?

ともあれ、俺得モデルフェス、楽しみです!



2018年4月17日火曜日

I2C接続メモ

I2Cの接続についてメモ

1.プルアップ電圧
低いものに合わせる。
ArduinoUNO                      5V
ArduinoMICRO(Leonardo) 5V
LaspberryPI  (1,2,3)          3.3V
GY-521 (6軸ジャイロ)        3.3V
AE-BME280(気象センサ) 3.3V (マニュアルでは Typ1.8V~Max3.6V)
なので基本的にI2Cバスは3.3Vを使用する。

2.プルアップ抵抗
Laspberry PIにはプルアップ抵抗1.8kが入っているが
Arduinoには入っていない。
6軸ジャイロには2.2kが入っている
AE-BME280は4.8kがJ2,J3がデフォルトで切断されている

〇問題なく接続できる組み合わせ
LaspberryPI  ---  AE-BME280(J2, J3はオープン)

〇プルアップとかで迷う組み合わせ
Arduino  ----  GY-521  
ジャイロのVcc は3.3V推奨 (たぶん5VでもOK。)プルアップはGY-521側に入っているので、ArduinoのIOはオープンコレクタに設定。
LaspberryPI  --- GY-521
マスタースレーブ両側にプルアップが入るが、おそらく問題ないと思う。
この場合のプルアップ抵抗はおよそ1k

Arduino  ----  AE-BME280
センサの電源は3.3Vに接続。J2、J3に半田を盛るとOKだが、あとでLaspPIにも使いたい場合、外部にプルアップ抵抗4.7kを接続。3.3Vにプルアップ。

3.レベルシフタは必要?
上記の組み合わせでは不要。必要な状況が今のところ思いつかない。

5V-3V3混載で気を付けるべきは、プルアップ先が3.3Vになっていれば、問題ないと思われる。(今のところ問題はおきていない)
ただし、5V側のIOの設定には注意する。(必ずオープンコレクタ出力にしておく)

2017年7月18日火曜日

Vivado CASE文の不具合 調査中

どうやら 
”メモリを推定する記述の場合に不具合が出る”
ようです。

■サンプル1 2bitGCC
reg [1:0] gcc
    always @ (posedge CLK or posedge RST) begin
        if (RST) gcc <= 0;
        else
          case (gcc)
            0 : gcc <= 1;
            1 : gcc <= 3;
            3 : gcc <= 2;
            2 : gcc <= 0;
            default : gcc <= 0;
          endcase

2bitのカウンタ(GrayCode)をcase文で記述。結果RTL記述より2個多い、4bit分のレジスタが合成された
これに対しては、前回に書いたように、
Gray2Bin→+1→Bin2Gray→Reg
の回路を記述すれば最小構成で合成される。

■サンプル2 4input RoundRobinArbiter

    reg [3:0] timeout_counter;
    reg [2:0] sequence;
    wire timeout;

always @ (posedge CLK or posedge RST) begin
      if (RST) sequence <= 0;
      else begin
        case (sequence)
          0 : if (REQUEST1) sequence <= 1;
              else if(REQUEST2) sequence <= 2;
              else if(REQUEST3) sequence <= 3;
              else if(REQUEST4) sequence <= 4;
          1 : if (!REQUEST1 || timeout) begin
                if(REQUEST2) sequence <= 2;
                else if(REQUEST3) sequence <= 3;
                else if(REQUEST4) sequence <= 4;
                else if (REQUEST1) sequence <= 1;
                else sequence <= 0;
              end
          2 : if (!REQUEST2 || timeout) begin
                  if(REQUEST3) sequence <= 3;
                  else if(REQUEST4) sequence <= 4;
                  else if(REQUEST1) sequence <= 1;
                  else if (REQUEST2) sequence <= 2;
                  else sequence <= 0;
                end
          3 : if (!REQUEST3 || timeout) begin
                  中略
                end
          4 : if (!REQUEST4 || timeout) begin
                  中略
                end                    
          default : sequence <= 0;
        endcase
      end
    end
 
    assign GRANT1 = (sequence == 1);
中略
 
    //timeout counter
    always @ (posedge CLK or posedge RST) begin
      if (RST) timeout_counter <= 0;
      else begin
        if (sequence == 0) timeout_counter <= 0;
        else timeout_counter <= timeout_counter+1'b1;
      end
    end
    assign timeout = (timeout_counter == 4'hf);

4bitのタイムアウトカウンタと3bitシーケンス制御用レジを記述。結果はRTL記述と同じ7個のレジスタが合成された。
シーケンサの記述に関しては問題なさそうです。

■おまけ ラウンドロビンの配置結果
レジスタ7個に対しLUTが22個なので、このようにスカスカ。記述を工夫すれば詰められそうですが・・ 

2017年7月16日日曜日

vivado におけるグレイコードカウンタの書き方

Vivadoにおけるというか、XilinxのFPGA向けというか、
6LUTを持つFPGA向きの記述というか、なんかそんな感じです。

前回、case文でグレイコードカウンタを記述すると意図しないレジスタを生成することが分かったので、他の記述をした場合にどのような回路を合成するか調べてみた。

1:加法標準形による記述
always @ (posedge CLK or posedge RST) begin
        if (RST) gcc <= 0;
        else begin
            gcc[5] <= (gcc[5:0]==6'b010000)||(gcc[5:0]==6'b110000)|| ...中略
    ・・・中略
       end
end

前回と同じ加法標準形による記述では、正しく意図した回路を生成する。

2:いちどバイナリになおして加算してグレイにして(略
Gray2Binaryとインクリメント演算で2度のリップルキャリーが出るため、避けるべきと思っていた記述だが(少なくともsynopsysでは避けていた)、vivadoではリップルキャリーの出る部分は全て6入力LUTに吸収され、加法標準形による記述と同様の回路が生成された

module GRAYCODECOUNT(
    input CLK, RST,
    output [5:0] GOUT
);

reg [5:0] gcc;
wire [5:0] gray2bin;
wire [5:0] inc;
wire [5:0] bin2gray;
    
assign gray2bin[5:0] = gcc[5:0] ^ {1'b0, gray2bin[5:1]};
assign inc  = gray2bin[5:0] + 1'b1;
assign bin2gray = inc[5:0] ^ {1'b0, inc[5:1]};
always @ (posedge CLK or posedge RST) begin
  if (RST) gcc <= 0;
  else gcc <= bin2gray;
end
    
assign GOUT = gcc;
endmodule

結論 Vivadoの合成では、いらんこと考えずにビヘイビアレベルで記述したほうが良かったりしますよ

vivado case文の不具合?

vivado2017.1でcase文を使ったら、意図しない回路を生成してくれやがったのでメモ。

module graycounter_3bit(
  input CLK, RST,
  output [2:0] GOUT
);
reg [2:0] gc3;
always @ (posedge CLK or posedge RST) begin
  if (RST) gc3 <= 0;
  else
    case (gc3)
      3'b000 : gc3[2:0] <= 3'b001;
      3'b001 : gc3[2:0] <= 3'b011;
      3'b010 : gc3[2:0] <= 3'b110;
      3'b011 : gc3[2:0] <= 3'b010;
      3'b100 : gc3[2:0] <= 3'b000;
      3'b101 : gc3[2:0] <= 3'b100;
      3'b110 : gc3[2:0] <= 3'b111;
      3'b111 : gc3[2:0] <= 3'b101;
      default : gc3[2:0] <= 3'bxxx;
    endcase
  end
  assign GOUT[2:0] = gc3[2:0];
endmocule

上のような3ビットのグレイコードカウンタを記述したところ、
下のような8bitのレジスタ+LUTの回路を生成しやがりました。

出力はちゃんとグレイコードしてますが、せっかくグレイコードカウンタを記述してるのに回路面積を増やしてくれやがるのはダメですね。ちゃんとレジ止めしてるのに出力段にLUTを生成してくれやがるので、ゲートシムするとヒゲが出ます。一番ダメなのは、3bitのレジを作ったつもりが8bitになってるあたり。

というわけでマニュアルオプティマイズをした3bitグレイコードカウンタを作成し、コンパイルしてみました。

module graycounter_3bit(
  input CLK, RST,
  output [2:0] GOUT
);
reg [2:0] gc3;
always @ (posedge CLK or posedge RST) begin
  if (RST) gc3 <= 0;
  else begin
            gc3[0] <= (!gc3[2] && !gc3[1]) || (gc3[2] && gc3[1]);
            gc3[1] <= (!gc3[2] && gc3[0]) || (gc3[1] && !gc3[0]);
            gc3[2] <= (gc3[1] && !gc3[0]) || (gc3[2] && gc3[0]);
    end
  end
endmodule


こちらで合成すれば、ちゃんと意図した回路を生成してくれます。

case文を使った箇所を一度見直す必要がありそうです orz

追記 4bitグレイコードカウンタ
加法標準形を書き出しただけですが、オプティマイズされた回路が出力されるようです。
ZYNQのLUTが6bitなので、6bitまでなら、このやり方で最適な回路が生成されるかと思われます。

 reg [3:0] gc4;
 always @ (posedge CLK or posedge nRST) begin
    if (nRST) gc4 <= 0;
    else begin
      gc4[0] <= (gc4 == 4'b0000) || (gc4 == 4'b0001) || (gc4 == 4'b0110) || (gc4 == 4'b0111) || (gc4 == 4'b1100) || (gc4 == 4'b1101) || (gc4 == 4'b1010) || (gc4 == 4'b1011);
      gc4[1] <= (gc4 == 4'b0001) || (gc4 == 4'b0011) || (gc4 == 4'b0010) || (gc4 == 4'b0110) || (gc4 == 4'b1101) || (gc4 == 4'b1111) || (gc4 == 4'b1110) || (gc4 == 4'b1010);
      gc4[2] <= (gc4 == 4'b0010) || (gc4 == 4'b0110) || (gc4 == 4'b0111) || (gc4 == 4'b0101) || (gc4 == 4'b0100) || (gc4 == 4'b1100) || (gc4 == 4'b1101) || (gc4 == 4'b1111);
      gc4[3] <= (gc4 == 4'b0100) || (gc4 == 4'b1100) || (gc4 == 4'b1101) || (gc4 == 4'b1111) || (gc4 == 4'b1110) || (gc4 == 4'b1010) || (gc4 == 4'b1011) || (gc4 == 4'b1001);
   end
  end
assign GOUT = gc4;

2017年6月29日木曜日

VivadoでIPを作るのが…

1:一度、素プロジェクトでRTL作って
2:ビヘイビアSIMが通ったら、IPパッケージャー起動してRTLをコピー、AXI仕様にして
3:ブロックデザインで組み込んでタイミング検証して
4:SlackがMetしなければ1へ戻り
を繰り返してる。 すげー面倒。 
もっと楽にやる方法はないものか。

XilinxのチュートリアルにIPを作るのがあるけど、
もともと完成してるRTLをそのままAXI仕様にするだけの簡単なお仕事なので、
タイミングがシビアな回路の組み立てチュートリアルみたいなのが欲しい。

などとぼやいてみたり。