2014-06-11

移植状況

ちょっと前にHDMI入出力をZynqに移植してるとか書いたけど、途中経過。
結論としては、未完成(´Д⊂ヽ

結局方針自体は間違っていなかったらしい。UCFの書き換えが必要。
ただし、MIG周りはそのボード用に再生成した方がいいよ・・・・と。
移植したデザインは、

入力をそのまま出力するモード
入力をフレームバッファに入れてからそれを出力するモード
カラーバー出力モード

の３つがあるのだけど、最初のスルーモードしか動作していない。
弱った・・・・

2014-05-31

Kintex ISEプロジェクトをZynq Vivadoへ・・・

最近Z706でHDMI入出力をやりたい・・・・
って感じのことをやっていて、
今週はHDMI入出力用の拡張ボード（？）買ったところからゲットした
Kintex用のISEプロジェクトをZ706用に移植しようとしていた。

とりあえず、買うときの説明的にはこれ使えばすぐできますよ！
という感じに聞こえたけど、やり方悪いせいかまだできてない・・・orz

結局やっていることは、UCFファイルをXDCファイルに変換！に尽きる気がする。
まぁ、それに合わせてVerilogも多少は弄っているけども・・・
クロック周りの制約書き換えて、マニュアル見ながら配置制約を書き換えて・・・・
で、大体できた気がするけど、MIG周りでまだ解決できない制約がいらっしゃる。

それでも週明け早々に終わるとは思っているけども
そもそもこのお仕事の正しい（？）やり方あるのかな？
思いつきでこの作業したけど、筋が悪いってオチが普通にありそう

2014-05-20

ZVIK camera

タイトル適当。
xapp794-1080p60-cameraをちょっと前に弄ったからそのときのメモを。
Zynq(z702) Video and Imaging Kitの付属カメラ使って、
カメラ入力をそのままHDMI出力するだけの簡単なもの。

ライセンス

まず、ライセンスが必要だから取得して下さいと書いてあるけど、
ドキュメントで指定されているのに加えて、
今から試すならDefective Pixel Correctionも追加で取得の必要がある。
更についでに言うとVivado 2014.1だとこのDefective Pixel Correctionと
Image Statistics(だっけ？)が廃止されていたりする・・・・
これ、同等のデザイン作りたかったらどうすればいいのでしょうね？

TCL

ドキュメントはVivado 2013.2が想定されているのだけど、
2013.3以降だと恐らくいくらかTCLスクリプトの修正が必要。

変数board に指定する文字列。TCLコンソールで"get_boards"を実行して、そこから選択する。
IPのインスタンス化でいくつかバージョン違いによってエラーが発生する。IP Catalogからバージョンを確認して、適宜修正をする。
2014.1 の場合はライセンスの項でも書いたようにいくつかのIPが廃止されている。当該IPを削除してつなぎ変えが必要*1。
2013.3 以降ではProcessing Systemのボード設定が自動化されないため、インスタンス直後にプリセットを適用する必要がある*2。
WindowsならCドライブ直下にしとかんとPATH長の制限で合成エラーになるかも

SDK

特に何も考えずに行けた

boot.bin

ドキュメントの生成箇所の指定ファイルがパッケージに同梱のもの・・・
これまでのフローで生成したものに差し替える。

以上で一応自力ビルドと動作確認ができた（はず）。何か忘れているかもしれん。。。

*1:本当は代替IPを入れるべきなんだろうけども・・・

*2:参考: http://japan.xilinx.com/support/answers/58425.html これやらんとSDKでエラー発生

2014-04-16

Zynq HP Port

Zynq で HPポートを使おうとしたときのメモ

http://forums.xilinx.com/t5/Embedded-Processor-System-Design/Accessing-DDR-from-PL-on-Zynq/m-p/324877#M8413 このリンクを偶然発見したのだけど、
HPポート使うなら

(AR/AW)CACHE=0x11
(AR/AW)PROT=0x00

にしろと・・・

VivadoさんにはAXIペリフェラルのテンプレート生成機能があるようで、
AXI Masterインタフェースを作ってみたところ、コメントには

//Update value to 4'b0011 if coherent accesses to be used via the Zynq ACP port. Not Allocated, Modifiable, not Bufferable. Not Bufferable since this example is meant to test memory, not intermediate cache. 
   assign M_AXI_AWCACHE    = 4'b0010

とか書いてある・・・・あれ？ACP用なの？？？
と思いつつ、結局0x11で正しく動いた

2014-04-15

CREATORS AMIGO

Creators Amigo vol.1 2014/4/13(sun)に参加してきた。
正直畑違い。。。しかも逗子とか鎌倉縁がない。。。
けど、友人主催だし、面白そうだしということで。
メモ取りたかったのだけど、テーブルがなかったのと、
イスもとれなかったので無理。。。。

エンジニアだし、デザインとかせんし（設計はするが）、
楽しめるの？って思ったけど、意外とかなり楽しかった。
レイヤーが上な人々は得だね。。。と修士時代のような感想をもつなど。

色々面白かった中で特に印象に残ったのは、
michiさんのプロジェクションマッピングの話。
デモもかなり面白かったのと

映像を作るのではなく空間を作る

という発言がとてもよかった。カッコいい。
他にもわかる〜ってことが結構あったり、なるほど〜だったり

2014-01-13

PetaLinuxをzshで

12月からZynqと戯れているのだけど、
PetaLinuxをCentOS5上にインストールしたあと、
source /settings.sh
が失敗してしまった・・・・
zshだから修正しましょうと。
Xilinxさんにはzshにも対応していただきたく。。。

修正したのは上記のsettings.shスクリプトを2点だけ。

==を＝に修正
$BASH_SOURCEを$0に修正

前者については、=にしてもbashは問題ない。
後者については、bashで困りそう。
ということで調べた。
http://qiita.com/yudoufu/items/48cb6fb71e5b498b2532
ここを参考にして
XIL_SCRIPT_LOC_TMP_UNI=${BASH_SOURCE:-$0}
に書き換え。解決した。

2013-12-17

必要悪なModular Interface

この記事はHDL Advent Calendar 2013の17日目の記事です。
HDLとか無関係なのに何やっているんだか・・・・

はじめに

SystemCで動作合成をやると出くわす(人も多いであろう)Modular Interfaceですが、
私はこれが割と嫌いです。厳密に言えばある条件を満たすと嫌いです。
嫌いだけどこれがないとどうしようもない・・・ってのもわかります。
だからもうSystemCも割と嫌かもｗｗｗ

Modular Interfaceとは？

厳密な定義があるのかも知らないけど、まずは次の超簡単なSC_MODULEの例を見てみましょう。

SC_MODULE(test) {
  sc_in<int> i1;
  sc_out<int> o1;
  sc_in_clk clk;
  sc_in<bool> rst;
  int v;

  void proc(void) {
    wait();
    while(1) {
      v = i1->read();
      o1->write(v);
      wait();
    }
  }

  SC_CTOR(test) {
    SC_CTHREAD(proc, clk.pos());
    reset_signal_is(rst, true);
  }
};

動作合成用の記述なんて久しぶりに書きました。
当然環境がないので、合成とかしてません。
~~面倒なので~~OSCIシミュレーションも試してませんm(__)m
ポートi1から入力をそのままポートo1に毎サイクル流し続けるだけの単純な構成です。

これをModular Interfaceを使うとどうなるかと言うと？次のコードを御覧ください。

class my_if
{
  sc_in<int> i1;
  sc_out<int> o1;

 public:
  int read() {
    return i1->read();
  }
  void write(int v) {
    o1->write(v);
  }
};

SC_MODULE(test) {
  my_if p1;
  sc_in_clk clk;
  sc_in<bool> rst;
  int v;

  void proc(void) {
    wait();
    while(1) {
      v = p1.read();
      p1.write(v);
      wait();
    }
  }
};

コンストラクタは省略しました。
要はModular Interfaceは入出力関連のポートと処理を隠蔽するためのものです。
実際にはmy_ifのポートはバスやらに応じて多種用意されますし、
そのバスを利用した外部との通信はここまで単純ではないでしょう。

何が嫌いなの？

はい、ここまで全然嫌いじゃないです。至って普通。
しかし、my_ifクラスが実はSC_MODULEでプロセスを持っていたらどうでしょう？
例えば、クラス内にFIFOバッファを持っていたりして、
read()はその最初の要素を取ってきてとか・・・
私が大嫌いなのはコレです。

SC_MODULEは外部と通信するときは自身の持つポートを介して通信しろ！
と声を大にして言いたい。
ポートを介して外部と通信している癖に、
関数を通じて内部変数にアクセスとか死ねばイイ・・・
という気持ち。心底汚いコードだと思うのです
その辺、ポートを排してしまったBSVとかイイよね！とか思う。

必要なの？

実はMaster側のポートをModular Interfaceに押し込めるだけなら、
例で見たとおりな構成で行けるので不要です。
問題はSlave側です。同じ構成でやろうとするとすぐに無理だと気付きます。
というかSlave側は何かテクニカル過ぎて頭痛くなる。
これをやろうと考えた某社と某社と某社はマジで凄いと思う。
~~面倒なので~~気が向いた人はどうすればいいか考えてみればいいと思います。

結論

Modular Interfaceは心底穢らわしいけど必要なのです。。。。orz

どうやって実現するか考えるとこうなるのはわかるけど、
本人たちは汚いとか思わなかったのかな・・・？というのもちょっと気になる。