2017年1月21日土曜日

【電子工作】 AUO B101EAN01 でHDMI LCD displayを作ってみる (完)

中華通販LCDでHDMIディスプレイを作ってみるシリーズの、今回は最終回です.

↓ラズパイPCの出来上がりということになりました.Raspberry-pi3でyoutubeの麻雀番組を見ているところ.フリーズなどせずにフツーに観れます.
↓裏面はこんなかんじ.左の基板はHDMI→LCD変換回路、右上はラズパイ3、左上の小さいのは5V→17VのDDコンでバックライト用.中央部の紫色の基板はピッチ変換基板.
ラズパイを除く消費電力は5V 650mAぐらいです.
HDMIは周波数の高い信号ですけど、このようなクソ配線でも意外と動くものです.差動伝送の恩恵かと思います.

今までの出費
(LCD部分)
  LCD                            ¥2000   ←安い!
  ピッチ変換基板+FPC   ¥1000   ←クソ高い!
  HDMIケーブル                ¥200
  FPGAボード                 ¥2600   ←クソ高い!
  DDコン                          ¥100

(PC部分)
  ラズパイ3                    ¥3400
  SDカード                      ¥1000
  無線KBD+MOUSE         ¥2200


ソースファイル
XILINX ISE13.3のprojectフォルダをupしときました.他バージョンのため開けなかった場合には、top.vがトップモジュールですので、適宜add sourceしてください.
全てのソースを解説するのもかったるいので、以下ではポイントだけ解説します.


FPGAブロック図
FPGAボード上のSpartan6で、HDMI-LCDのデータ変換をします.HDMI信号をTDMSで受信して、LCDパネルへの信号をLVDSで出力します.ブルーの四角はXILINXのcoreです.クロックは750M, 150M, 75M, 525MHzの4種類を使います.

シンボル抽出回路
HDMIケーブルから来るビットストリームの正体は、10bitシンボルの連続体です.ゆえにビットストリームを適切な位置で10bitにブツ切りする必要があります.ビットストリームを20bit shift registerに流し込んでやりますと、連続したいずれか10bitが正しいシンボルであるはずです.正しいシンボルの位置が一度決まれば、10bit時間間隔で同じ場所を切り出せば常に最新の受信シンボルを得られます.というのが原理です.

↓ソースコードではここらへんです.
// parallel RGB data
reg [19:0] r20,g20,b20;
always @(posedge clk150) begin
 r20 <= {r5,r20[19:5]} ;    20bitシフトレジスタ
 g20 <= {g5,g20[19:5]} ;    20bitシフトレジスタ
 b20 <= {b5,b20[19:5]} ;    20bitシフトレジスタ
end

// extract RGB symbols
reg [4:0] symbol_boundary_position;
reg [9:0] symbol_r, symbol_g, symbol_b;
always @(posedge clk75) begin
 {symbol_r, symbol_g, symbol_b} <=     適切な位置でシンボルをブツ切りする
symbol_boundary_position==19 ? {r20[19:10],g20[19:10],b20[19:10]} :
symbol_boundary_position==18 ? {r20[18: 9],g20[18: 9],b20[18: 9]} :
symbol_boundary_position==17 ? {r20[17: 8],g20[17: 8],b20[17: 8]} :
symbol_boundary_position==16 ? {r20[16: 7],g20[16: 7],b20[16: 7]} :
symbol_boundary_position==15 ? {r20[15: 6],g20[15: 6],b20[15: 6]} :
symbol_boundary_position==14 ? {r20[14: 5],g20[14: 5],b20[14: 5]} :
symbol_boundary_position==13 ? {r20[13: 4],g20[13: 4],b20[13: 4]} :
symbol_boundary_position==12 ? {r20[12: 3],g20[12: 3],b20[12: 3]} :
symbol_boundary_position==11 ? {r20[11: 2],g20[11: 2],b20[11: 2]} :
symbol_boundary_position==10 ? {r20[10: 1],g20[10: 1],b20[10: 1]} :
                              {r20[ 9: 0],g20[ 9: 0],b20[ 9: 0]} ;
end

SYNC検出回路
正しいシンボルの位置を決めるための回路です.上のソースコードで参照されている symbol_boundary_position という変数を決める役割です.
ビットストリームから探索するSYNCパターンは、垂直・水平同期期間でのみ出現する、1101010100 です.1101010100 は、1水平期間毎に必ず到来するはずなので、100uSec待っても1101010100 が到来しなければそれは、symbol_boundary_position が不正値である証しですから、symbol_boundary_position を+1します.1101010100 を受信できるまで+1を繰り返します.というのが原理です. (これがHDMIの通常の作法なのかは知りません)

↓ソースコードではここらへんです.
// sync pattern definitions (=control period symbols)
wire [9:0] sync0 = 10'b1101010100; // zero
wire sync = symbol_b==sync0;

// check sync
// 100uSec timer to detect H-SYNC
reg [12:0] timecnt;
always @(posedge clk75 or negedge xrst)
if(!xrst)     timecnt<=2;
else if(sync) timecnt<=2; // if sync then timer is initialized
else          timecnt<=timecnt+1;

// if no sync then change symbol boundary
always @(posedge clk75 or negedge xrst)
if(!xrst) symbol_boundary_position<=19;
else if(timecnt==0) // when missing sync
begin // change symbol boundary
       if(symbol_boundary_position==19) symbol_boundary_position<=18;
  else if(symbol_boundary_position==18) symbol_boundary_position<=17;
  else if(symbol_boundary_position==17) symbol_boundary_position<=16;
  else if(symbol_boundary_position==16) symbol_boundary_position<=15;
  else if(symbol_boundary_position==15) symbol_boundary_position<=14;
  else if(symbol_boundary_position==14) symbol_boundary_position<=13;
  else if(symbol_boundary_position==13) symbol_boundary_position<=12;
  else if(symbol_boundary_position==12) symbol_boundary_position<=11;
  else if(symbol_boundary_position==11) symbol_boundary_position<=10;
  else if(symbol_boundary_position==10) symbol_boundary_position<=9;
  else                                  symbol_boundary_position<=19;
  led0<=~led0; // LED indicatoro
end


HDMIデコーダーはとても簡単
最低限、RGBのデコーダーと、垂直・水平同期のデコーダーとを実装する必要があります.

まずRGBのデコーダーですけど、HDMI規格書の情報どおりのたったのこれだけです.10bitシンボルを入れると8bitバイトが出てくると、それだけです.
module hdmi_dec
(
input clk,
input [9:0] in,
output [7:0] out
);
wire [9:0] D = in;
wire [9:0] DD = D[9] ? {D[9:8],~D[7:0]} : D;
reg [7:0] Q;
always @(posedge clk)
if(DD[8]) begin
Q[0] <= DD[0];
Q[1] <= DD[1] ^ DD[0];
Q[2] <= DD[2] ^ DD[1];
Q[3] <= DD[3] ^ DD[2];
Q[4] <= DD[4] ^ DD[3];
Q[5] <= DD[5] ^ DD[4];
Q[6] <= DD[6] ^ DD[5];
Q[7] <= DD[7] ^ DD[6];
end
else begin
Q[0] <= DD[0];
Q[1] <= DD[1] ~^ DD[0];
Q[2] <= DD[2] ~^ DD[1];
Q[3] <= DD[3] ~^ DD[2];
Q[4] <= DD[4] ~^ DD[3];
Q[5] <= DD[5] ~^ DD[4];
Q[6] <= DD[6] ~^ DD[5];
Q[7] <= DD[7] ~^ DD[6];
end
assign out = Q;
endmodule

つぎに垂直・水平同期のデコーダーはこれです.4パターンとの一致チェックの結果、de,hd,vdを得るという仕組みです.deはRGB valid、hdは垂直同期、vdは水平同期、の意味です.
wire [9:0] sync0 = 10'b1101010100; // zero
wire [9:0] sync1 = 10'b0010101011; // hd
wire [9:0] sync2 = 10'b0101010100; // vd
wire [9:0] sync3 = 10'b1010101011; // vd,hd
reg hdmi_de,hdmi_hd,hdmi_vd;
always@(posedge clk75)
case(symbol_b)
   sync0 : {hdmi_de,hdmi_hd,hdmi_vd}<=3'b000;
   sync1 : {hdmi_de,hdmi_hd,hdmi_vd}<=3'b010; // hd
   sync2 : {hdmi_de,hdmi_hd,hdmi_vd}<=3'b001; // vd
   sync3 : {hdmi_de,hdmi_hd,hdmi_vd}<=3'b011; // vd,hd
   default:{hdmi_de,hdmi_hd,hdmi_vd}<=3'b100;
endcase


制約は大事です
まずは、TDMSの入力ピンのロケーションと論理レベルの設定のところ.
・下記のロケーションならビルドが通りますけど、近所のピンに変えると「配線リソースがありません」というエラーが出たりするので注意が必要と思われます.
・「=FALSE」の部分は、クロックバッファの自動挿入をするなと命じています.クロックバッファはPLL coreに挿入されるので衝突を防ぐためです.
・VCCAUXは、デフォルトでは2.5Vなのですが、TDMSならば3.3Vである必要があります.
NET "clkm" LOC = "P9" ; //| DIFF_TERM = TRUE ;
NET "clkp" LOC = "P10" ; //| DIFF_TERM = TRUE ;  # HDMI clock
NET "bm"   LOC = "P16" ; //| DIFF_TERM = TRUE ;
NET "bp"   LOC = "P17" ; //| DIFF_TERM = TRUE ;
NET "gm"   LOC = "P21" ; //| DIFF_TERM = TRUE ;
NET "gp"   LOC = "P22" ; //| DIFF_TERM = TRUE ;
NET "rm"   LOC = "P23" ; //| DIFF_TERM = TRUE ;
NET "rp"   LOC = "P24" ; //| DIFF_TERM = TRUE ;
NET "clk?" IOSTANDARD = "TMDS_33" ;
NET "r?"   IOSTANDARD = "TMDS_33" ;
NET "g?"   IOSTANDARD = "TMDS_33" ;
NET "b?"   IOSTANDARD = "TMDS_33" ;
NET "clkp" CLOCK_DEDICATED_ROUTE = FALSE ;
NET "clkm" CLOCK_DEDICATED_ROUTE = FALSE ;
CONFIG VCCAUX = "3.3";  # needed for TMDS_33

次にclock制約はtoolで自動生成させた結果です.
・clk50はオンボードXTALですが、最終的に使わなかった
・clkp/clkmは12ns=83MHzで制約しておきました
・グループHDMI_DATAは、1ns before clkp にしました.前回にも書きましたが、仕様が不明なのでこれで動いたからこれでいいや、という設定です.
・グループLCD_SIGNALSは、1ns after clkp にしました.前回にも書きましたが、仕様が不明なのでこれで動いたからこれでいいや、という設定です.
NET "clk50" TNM_NET = clk50;
TIMESPEC TS_clk50 = PERIOD "clk50" 20 ns HIGH 50%;
NET "clkp" TNM_NET = clkp;
TIMESPEC TS_clkp = PERIOD "clkp" 12 ns HIGH 50%;
NET "clkm" TNM_NET = clkm;
TIMESPEC TS_clkm = PERIOD "clkm" 12 ns LOW 50%;
INST "gm" TNM = HDMI_DATA;
INST "gp" TNM = HDMI_DATA;
INST "bm" TNM = HDMI_DATA;
INST "bp" TNM = HDMI_DATA;
INST "rm" TNM = HDMI_DATA;
INST "rp" TNM = HDMI_DATA;
TIMEGRP "HDMI_DATA" OFFSET = IN 1 ns BEFORE "clkp" RISING;
INST "lvo_0m" TNM = LCD_SIGNALS;
INST "lvo_0p" TNM = LCD_SIGNALS;
INST "lvo_1m" TNM = LCD_SIGNALS;
INST "lvo_1p" TNM = LCD_SIGNALS;
INST "lvo_2m" TNM = LCD_SIGNALS;
INST "lvo_2p" TNM = LCD_SIGNALS;
INST "lvo_3m" TNM = LCD_SIGNALS;
INST "lvo_3p" TNM = LCD_SIGNALS;
INST "lvo_clkm" TNM = LCD_SIGNALS;
INST "lvo_clkp" TNM = LCD_SIGNALS;
TIMEGRP "LCD_SIGNALS" OFFSET = OUT 20 ns AFTER "clkp";


-----
設計上のキモのところは以上です.

なお、前回も書きましたが、windows PCに接続しても動きませんでした.PC-LCDのネゴシエーションを実装してないからだと思っています.

読者の皆さんが色々なLCDパネルをいじり倒していただく参考になれば幸いです.なお、上記情報に誤りが在った結果貴方が蒙った如何なる損害もわたしは関知しませんので素直に死んで頂戴ませ.それと、HDMIって使用にあたってはライセンス料の支払いが必要だと思うので、商売で無断で使うのはどうかと思うよ、と優等生ぶってみたりしておこう.

前回へ

かしこ

2017年1月20日金曜日

やるなぁ、APA

ひら的には地方出張で毎度おなじみのAPAホテルですが、外国人観光客が増えたからかと思いますがAPAですら一泊¥15000などという狂ったようなホテル相場になっていて、「ホテル予約できなかった日本死ね」状態なこの頃death. ビジネスホテルには¥6000で泊まりたいよ.

そのAPAが、南京大虐殺という中国共産党のデマへの反論本を客室に配備しているというのが騒ぎになっています.わたしがAPAに宿泊したときに南京デマ本が在ったかどうかは記憶にないのですが、何らかの保守系書籍は在りました.だから何をいまさら騒いでるんだという気がするんですよね.
APAが右翼だってのは昔から有名じゃなかったのかなぁ? 元自衛隊の多母神さんが自衛隊をクビになった原因がAPAの保守系雑誌の懸賞論文で優勝しちゃって顰蹙を買ったためでしたし.

中国共産党だってAPAの保守系スタンスはご存知だったろうにと推察します.なのに何故いまごろになって騒いでるの?
きっと、従軍売春婦の件で日本政府が意外に健闘しているのと、USではトランブが台湾と仲良しで、なんでもいいから反撃材料は無いのか?と反日ネタ帳を探した誰かが「APAがいいんじゃね?」って見つけたんでしょう.
APAを標的にしたのは、ひとまず中共を褒めてあげたいです.だってさ、中国本土の日本企業を吊るし上げたら暴動が起きちゃって困るもんねwww    だから攻撃対象を日本のホテル業者にしたのはひとまず正解なんだよ.中国シンパの日本人という自律支援システムも起動されるしね.お上手deathね~
いま何者かが着火したがっているDHCへも燃料投下指令が下されるかもしれません.その指令に従う日本人死ね.おっとちがった潜入工作員死ね.

中共からAPAへの非難声明に対抗して、「南京デマ本の撤去はしません」とAPAが反論しました.APAは筋金入りの保守ですから、徹底抗戦するじゃないかな? 少なくともオリンピックまではホテル業は超景気いいでしょうから、中国人旅行客が来ようと来まいと痛くないだろうし.

APAがんばれよ!


----
もうひとつ、日韓の従軍売春婦の件で大使を帰国させた是非についての世論調査で76%が賛成なんですって???   日本人にそんな根性が在ったのかと驚いてしまいました.どーせ半分ぐらいはロクに事情も知らずに「サンセー」って答えたのだろうけどね.

ひら的には、韓国の実情が万人に伝わるように、半島が北朝鮮によって統一されちゃうのが明示的で良いかなと思う. (実際にそうなる可能性よりも、韓国で軍事クーデターが起きる可能性の方が高かろうが)
「サンセー」って答えた人々は、対馬のすぐ先にある赤い半島とか軍事クーデターとかに直面しても「サンセー」し続ける根性はあるのだろうか? あって欲しいものですがw

ちな、わたしは不惑のサンセーw

かしこ

2017年1月19日木曜日

【懐かしパーツ】 山水の小信号トランスはまだ健在だった!

昭和の40~50年代前半の頃、「初歩のラジオ」や「ラジオの製作」が回路好き少年向け雑誌として、ほぼ滅亡している今のパソコン雑誌よりも人気がありました.わたしは「ラ製」よりも「初ラ」の方が好きでした.

その頃の回路製作記事には、必ずと言っていいくらいトランスが使われていました.
よく使われていたトランスはST-32などという製品番号が記憶にあります.
←¥540

そういった回路図を見た中学生のヒラサカくんとしては、あぁトランス買うのかったるいなぁといつも思ったんです.トランスは当時からトランジスタ1つ買うよりも高価で、巻き線比が違うたびに新しく買わなくちゃいけなくて、作るならトランスレスの回路がいいなぁと思っていました.

当時の半導体事情ですとオペアンプをさくさく使えるほどICは普及しておらず、真空管がトランジスタに置き換わった程度の数のトランジスタしか使えなかったため、インピーダンス変換の必要があるならばトランスでやるのが通常の設計作法だったのでしょう.
今じゃインピーダンス変換はオペアンプでやってしまうし、その方がトランスを使うよりも価格が1/10ぐらいで済んでしまいます.

ちょっとわけあって、昔のような小信号用トランスを入手したくなりました.今でも売ってるのかな? 中華メーカーの正体不祥なトランスが見つかるかどうか、、、というのが期待値でした.

ところが! ネット通販を探したら、なんのことはない、秋月でST-32などがまだ売られているんです.

えぇ~っ、ST-32って山水だったの!? 山水のアンプ、トランスというと、80年代のオーディオ全盛期の有名メーカーでした.ST-32はその山水だったのですね.

だけど、山水という会社はもう存在しないはずです.いったいどこの誰が山水のST-32を生産しているのでしょうか? 江戸川コナンくんも冷や汗が吹き出てしまうほどのミステリーです.

wikiを調べてみたら、真空管オーディオショーでも見かける、橋本電気株式会社に山水トランスの製造販売権が譲渡され、いまでも秋月で売られているST-32がそれであるようです.

赤井は消滅し、パイオニアも消えそう、ナショセミはTIに吸収され、フェアチャイルドはオンセミに吸収され、あのLTですらADに吸収されて、いろんな老舗が無くなってしまう中で山水ブランドが意外な形で残っていたとは、昭和時代からの回路ヲタクとしては深く感銘を受けざるを得ませんでした.

しかし¥540は決して安くは無いですね.

かしこ

2017年1月18日水曜日

2017年1月期アニメ インプレッション (豊作)

2017年1月期のアニメが始まりました.毎週お楽しみな作品がいろいろあって豊作かもしれんかなぁと思っているところであります.以下のように、お楽しみ作品目白押しなのは久しぶりですよ.

クズの本懐
まだ第一話しかみてないけど、ノイタミア枠はまた挑戦的な作品を世に出しましたな.BPOへの配慮もありエロは第一話だけだろうと想像するのですがね.これは今期の第一級本命作品と位置づけられマス.
←いきなり濡れ場

小林さんちのメイドラゴン
主人公は女流SE. ドラゴンのメイドがそこへ転がり込んでくるという藤子不二雄設定.女子vs女子で異種族ハーレムとはずいぶんニッチな趣向である.いや~おもしろいじゃないかと第1話を観ながらEDテロップでなんとあの京アニであるコトを知ってびっくり.いつもの京アニのテイストじゃないんだもん.京アニの別働隊が制作しているんだろうか?
←女流SEってみんなこんななの?

ガブリールドロップアウト
琴浦→さばげぶ→うまる、と良作をリリースしつづける太田雅彦の作品ということで期待度高し.題名は堕天使ガブリエルそのもの.1,2話を観たところでは、まだクソビッチさが不足している気がするのでもっと墜ちるところまで墜ちてもらいましょう.
←バトーさんが飼ってる犬もガブでした

政宗くんのリベンジ
子供の頃にバカにされた恨みを晴らすべく、高校生になった政宗くんがその女をコマす様が描かれます.どーせしまいにゃ両思いになるんだろう.ラブコメで良くあるネタでありますが、最後まで楽しめそうです.
←キャラ設定は月並み

ハンドシェイカー
なんだあの第1話は、、、色が濃すぎて狂っている.パースが狂っている.回り込みのしすぎで狂っている.NPCが狂ったように動画になっている.鎖を出す女子が狂っている.... でもねぇ、なぜか憎めない作品.狂人には狂人なりのフェティシズムが在るように思う.あと、安っぽいBGMが好きなんだわ.
←闘うかイクかどっちかにしてください

セイレン
労せずハーレムを形成するという男子憧れのアマガミ系列作品.だが既にアマガミには劣る.脚本がゲームっぽいんだよなぁ.どうして合宿先で女子が窓から侵入してくるのだろう... 自分のジャージを女子に貸すとして、わたしなら一つ条件を課すだろう、「貸してもいいけど洗わずに返すこと」
←振り回される悦楽

風夏
「涼風」の原作者によるマガジン系列アニメ.第2話にしてすでに作画品質が劣化しているが、涼風って好きだったので、あのテイストが蘇るだけで反射的に嬉しくなってしまう.てっきり陸上競技ベースなのかと思っていたのだがそうではなく、バンドの物語らしい.
←こっちの女子が良い

幼女戦記
ヨーロッパ戦線での魔力戦隊の活躍というと、先日まで放映していた「終末のイゼッタ」を思い出します.「イゼッタ」は最後の魔女と弱小国という設定から鬱展開が予想されその通りでした.「幼女戦記」は鬱展開にならずにもっとドライに最悪な結末になりそうで楽しそうな気がしてます.
←微妙なキャラ設定
チェインクロニクル
バトルファンタジー作品は元来苦手なわたしです.しかし本作では戦闘の動きが軽快なのと、やたら複雑な髪型をした女子の作画がやけに手が込んでいます.制作スタジオはどこかなぁと思ったらテレコムでした.テレコムは宮崎駿と少し関係が在ったスタジオです.テレコムのアニメを観られる幸福を感じつつ見続けようよ.

リトルウィッチアカデミア
一目でわかるTRIGGER制作のアニメ.TRIGGERのアニメを観られる幸福を感じつつ見続けようよ.

AKIBA'S TRIP
よく知っている街の風景がアニメの背景として登場する幸福を感じつつ見続けようよ.OPで叫んでいるのはザブングルの歌手の人ですかね?
←サンボの前

亜人ちゃんは語りたい
亜人と書いて「デミ」と読むのだそうです.わたしはデミとは呼ばずにアジンを貫き通そうと決意するのですが、登場する亜人たちは亜人ではなくて吸血鬼などの既存の妖怪です.なんか残念.
←コスプレで淫魔は隠せなかろう

かしこ

【電子工作】 AUO B101EAN01 でHDMI LCD displayを作ってみる (5)

中華通販LCDパネルで作った1280x800のHDMIディスプレイに表示できました.

今回は、HDMI→LCDブリッジロジック回路設計にあたって困ったコトを書こうと思います.

【windows PCには接続できなかった】
windowsの表示解像度を1280x800に設定してからこのモニタを繋ぎます.しかし映りませんでした.
たぶん原因は、PC-モニタ間で行われるネゴシエーション対応を実装してないからだと思います.HDMI規格書には、ネゴに関する様々な情報が書かれていますが、それらのうちどれを実装すればwindowsにご満足いただけるのかが不明なので実装する気が起きません.

運よく表示できたのは、Raspberry-pi3のHDMI出力でした.Raspbianはモニタとのネゴシエーションをやってないみたいです.というわけで残念ですが、Raspbian専用モニタになってしまいました.

ちなみにRaspbianの表示解像度変更は /boot/config.txt のこの辺をいじりました.
# uncomment to force a console size. By default it will be display's size minus
# overscan.
framebuffer_width=1280
framebuffer_height=800

# uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=2
hdmi_mode=27


【HDMI信号のtiming仕様が不明】
HDMIケーブルの信号は、下図のようになっています.要点は、
 1) 周波数は1280x800解像度でのおおよその値
 2) 1ピクセルのデータを送信するのに各色ごとに10bitを要する  (8/10変換のため)
 3) クロック周波数はデータレートの1/10である  (=ピクセルレート)
 4) HDMIモニタは、75→750MHzの周波数逓倍回路を要する

ふ~ん、と思ったところで、さらに欲しい情報が2つあります.

 5) 上図ではclockがD1D2境界とD5D6境界で遷移しています.しかし、この絵が正しいのかどうかはHDMI規格書Rev1.3のどこにも書かれていないのです.これが不明だと、シンボルをどこで区切ったら良いのかが不明になって困ってしまいます. (=シンボル同期問題)

 6) 下図のような、bit遷移とclock遷移のtimingがHDMI規格書Rev1.3のどこにも書かれていません.これじゃFPGAを設計できないよ. (=bit同期問題)

シンボル同期問題を次の方法で回避しました.

光DISKやHDDでは、データには存在しない特定のシンボルパターンを検出することで同期します.

同じことをHDMIでもやれば良いので、特定のシンボルパターンをどれにするかを勝手に決めました.水平・垂直同期期間を示すシンボルパターン4種のうち、RGBのBに属するsync0を同期シンボルパターンとして実装したら上手く動きました. (これが正解なのかどうかは知りません)
 wire [9:0] sync0 = 10'b1101010100; // zero
 wire [9:0] sync1 = 10'b0010101011; // hd
 wire [9:0] sync2 = 10'b0101010100; // vd
 wire [9:0] sync3 = 10'b1010101011; // vd,hd

bit同期を次の方法で回避しました.

コンパイル制約で、めくら打ちでいいとこ探ししました. (げろげろ)


【LCD-IFのtiming仕様が不明】
上記6と同じことがLCD仕様にもいえまして、製品仕様書にこういう図は掲載されているのですが、timing情報の記載はありません.コンパイル制約で、めくら打ちでいいとこ探ししました. (げろげろ)


【PCは水平・垂直同期を出力しているのか?】
HDMI規格書によると、水平垂直同期期間では、HSYNC,VSYNC,DE,CTL[3:0]を伝送できるようになっています.
 HSYNC    水平同期     (Bに乗る)
 VSYNC    垂直同期     (Bに乗る)
 DE           画像データか同期信号か     (RGBに乗る ※)
 CTL[1:0]   いろいろ      (Gに乗る)
 CTL[3:2]   いろいろ      (Rに乗る)
ここまでは、HDMI規格書1.3に明記されています.

それでいつものように規格書の悩ましいところですが、上記の信号伝送能力を有すると規格書は述べていますけれど、実際の製品がこの機能を利用しているかどうかは規格書の知ったこっちゃありません.

Rapsberry-pi3のRaspbian OSで実際に試してみて判ったところでは、VSYNCもHSYNCも送信されていませんでした.CTL[3:2]は謎の信号が送信されていました.CTL[1:0]は常時ゼロでした.DEは送信されています.

そんなんでどうしてLCDが表示できるの?と思われるでしょう.
LCDパネルのIFは、VSYNCもHSYNCも不要なのです.
LCDパネルに必要なのは、DEだけなのです.LCDパネルには、RGB+DEを与えます.

※ DEが送信されるとは、この4パターンのいずれかが検出されたらDEが非アサートとなる、という意味です.DE bitがRGBに埋め込まれているわけじゃないんです.
 wire [9:0] sync0 = 10'b1101010100; // zero
 wire [9:0] sync1 = 10'b0010101011; // hd
 wire [9:0] sync2 = 10'b0101010100; // vd
 wire [9:0] sync3 = 10'b1010101011; // vd,hd


-----
なんだか他にもunknownがあったような気がするんだけど忘れちゃった.

もっとも、HDMI規格書を書いた人に恨みつらみを言う気はありません.

そもそも、技術規格というのはお金を払った人だけに開示されるものですから、表情報はここまでだよ、裏情報はお金次第だからね、という新興宗教みたいな性質が多かれ少なかれありますから.
また、規格書に書かれた膨大な情報のうち、どれが必須で、どれが盲腸なのかを規格書が明示する義理もないんです.どれが盲腸なのかはお金を支払った仲間同士で情報交換してくれたまえという新興宗教信者同士みたいな性質が多かれ少なかれありますから.

規格書モノで遊ぶには、規格策定者達のゲスな気持ちを察して快感を感ずる神経があるといいかもしれません.仕事でそれをやらされるとかな~り地獄なんですがねwww

前回へ     次回へ

なお、いつものように上記の情報で貴方が受けた損害についてわたしは知りませんのでハマったら素直に死んでください.

かしこ

2017年1月17日火曜日

【電子工作】 AUO B101EAN01 でHDMI LCD displayを作ってみる (4)

中華通販LCDパネルで作った1280x800のHDMIディスプレイに表示できました.

↓ラズパイのRaspbian OSのデスクトップ画面を表示している状態です.

↓いろいろあって裏側はジャングル配線になっています.右上にあるのはラズパイ3です.HDMIケーブルは直接ハンダ付け.

それにしても問題山積です.

HDMI規格書を読んだだけだと判らないことがいろいろとありましてね.どうしても根拠レス実装になってしまいました.その結果、仮定で実装して動いた部分もあれば、闇雲にパラメータをいじって良好なポイントを探した部分もあります.

山積した問題を回避した結果、汎用LCDモニターにはならずに、小型のラズパイマシンになっちゃった.予定と少しちがうけど、まぁよしとするか...

設計情報と問題点の解説はまた後日.



#明日は川崎の海に近い辺りに居ます.天気は良いが寒そうです.

かしこ

2017年1月14日土曜日

宇宙戦艦ヤマト2202 PV第3弾

宇宙戦艦ヤマト2202のPV第3弾が公開されました.

それでは各シーンをチェック!

↓大帝様のご尊顔を初めて拝見します.さらばヤマトの大帝様よりも貫禄がありそう.
↓ドメラーズの前面展開したシールドは火焔直撃砲には無力だったようです.おまけにドメラーズ側からの攻撃ができませんから専守防衛にもほどがあるだろと思っちゃった.
↓きりしまと同型艦がやられてます.地球ガミラス連合艦隊にきりしま型も動員されたってこと?
↓でたあぁっっ、アンドロメダの拡散波動砲! 拡散場面は未公開ですが.
↓勇者の岡でしたっけ? 沖田さんの銅像が建つ場所のようです.
↓この3カットは、連続したカットかもしれません.真田さんの「呼ばれているのか」というセリフがあり、月面で敵に追撃され、月面のドックを主砲で破ってヤマトが発進するという流れかなと.それで空間騎兵隊の斉藤が加勢してとかなんとか.
↓そして、、、PVのラストショットはこの邪悪極まりない雰囲気のアンドロメダの正面画像です.アンドロメダを正面アングルで描いた絵って過去に在りましたかねぇ? 福井さんの脚本におけるアンドロメダはこの絵のような意味づけなのでしょうか??? う~んあまりにも邪悪だ.

ヤマト関連の情報収集を担当しているエージェントの分析によると、このPVが全7章のうちの第1章だとするとハナシの進み方が早すぎるのではないかという点が問題になりました.例えばアンドロメダの拡散波動砲の発射は白色彗星と対峙する後半の場面のはずですから.
エージェントが消息筋から得た情報を基に分析した結果、ストーリー構成等について次のように考えられるとのことです.

第1章は、1,2話でテレサのメッセージとガトランティスの脅威と波動砲問題が描かれ、3話でヤマト発進.

新キャラのガミラス人は、波動砲封印にこだわる古代を説得する役目.

アンドロメダの拡散波動砲は、テスト航海中の1場面.

第1章でガミラス&地球連合軍がガトランティスと戦うのはストーリー構成上無理がある.また、方舟で火焔直撃砲対策もある程度やられている.ゆえに、唐草模様のドメラーズと盾は、戦術シミュレーションの一場面ではないだろうか?

第2章以降の展開については、ヤマト2では22話で地球艦隊VS白色彗星で土方&アンドロメダがやられたはず.さらにヤマト2はデスラー戦が挿入されたが2202ではそれはないはずなので、10,11話ぐらいにテレサに会う展開か?


宇宙に新たなる危機が迫っているのです.

かしこ

2017年1月11日水曜日

複雑な思いもある、キネマ旬報ベストテン、「君の名は」ランク外

2016年キネマ旬報ベストテンが発表されました.

「この世界の片隅に」が一位で、「君の名は」がランク外という事態には複雑な重いが去来します.

■キネ旬 日本映画ベスト・テン2016
 1位 この世界の片隅に
 2位 シン・ゴジラ
 3位 淵に立つ
 4位 ディストラクション・ベイビーズ
 5位 永い言い訳
 6位 リップヴァンウィンクルの花嫁
 7位 湯を沸かすほどの熱い愛
 8位 クリーピー 偽りの隣人
 9位 オーバー・フェンス
 10位 怒り

「この世界の片隅に」が一位になったのは誠に目出度い.評判はすごく良いけれど、興行収入はたったの10億円でしかないのでこれで弾みがついてもっと上に行けるとよいと思います.

ただし、これで片渕須直監督はもう「BLACK LAGOON」みたいな不良作品を作らなくなっちゃうんだろうなぁという複雑な思いもある.当ブログでBLACK LAGOONについては以前書きました.大好きです、BLACK LAGOON.ひら的には片淵監督には「BLACK LAGOON」みたいなバイオレンス作品をどんどん作って欲しいんだよね.ご本人の作品歴からすると、文芸作品を作りたい人のようですが...

「この世界の片隅に」の片淵監督というネームバリューが確立して、ますます文芸路線へ行ってしまうんでしょうなぁ.惜しい、、、

-----
もう一点、「君の名は」がランク外というのも随分と映画インテリから嫌われたもんだなと、複雑な思いです.

「君の名は」をランク外に追放したキネ旬の選者達は、あんなのラッセンの絵画だろとバカにしているのだろうと思います.わたしも「君の名は」=ラッセンだと思いますけど、そのラッセンが今じゃ日本映画歴代2位の興行収入ですからね.まだまだ伸びつつある興行収入がどこまで行っちゃうんだろ?と興味津々です.

キネ旬の映画インテリの行動様式は、宮崎駿作品に「文明批判」「環境擁護」テーマを見出すから上位入賞させる、「この世界の片隅に」には反戦テーマが在るから一位にする、「シン・ゴジラ」には311テーマを見出すんでしょう.だけどさぁ、テーマがそんなに大切なんですかね?
(ちなみに.キネ旬の映画インテリが人間を描くことへのこだわりが薄いのはシン・ゴジラが2位にいることで推測がつく)

確かに「君の名は」には、反戦テーマがあるわけでもないし、人間を描いたわけでもないです.だけど、映画の本質ってテーマでも人間でもないでしょう? 「綺麗な絵が動いてる~」っていう「君の名は」のプリミティブな感銘の方が映画にとってより本質的なんじゃないの? しかもその「綺麗な絵が動いてる~」っていうのが世界中の消費豚にウケまくっているわけでしょう.

だからキネ旬の映画インテリ達に「君の名」を2位や3位にしろとまでは言わないが、7位か8位ぐらいには入れても良かったんじゃないかと言いたいわけですよ.

世界中の消費豚にウケまくっている実情をガン無視して「君の名は」をランク外に据え置いたキネ旬の映画インテリ達の視野の狭いセカイ観は、 日本映画ビジネス発展の妨げになると思います.だいたい日本の映画業界なんてそんなに景気のよい業界じゃないでしょう.セカイに売れる作品が出現したら、たとえそれがラッセンであったとしても一定の評価を与える大人の配慮を見せてこそ、キネ旬ランキングの重みが増したのではないでしょうか? だがしかし、冒頭のランキングからはマイナー映画ヲタクの戯言の匂いがします.

シャキッとしろ、マーケットを見ろ、マスかいてんじゃねえょ  >  キネ旬

追記:  キネ旬の選考システムは、映画インテリ達による合議制ではなく、映画インテリ達による投票制なのだそうです.

-----
「君の名は」の年末年始をはさんだ2週間の興行収入が発表されました.
http://www.kogyotsushin.com/archives/alltime/
君の名はの興行収入の推移はこうなっています.
 11/7    180億円   +5
 11/14  185億円   +5
 11/21  190億円   +5
 11/28  195億円   +5
 12/5    200億円   +5
 12/11  205億円   +5
 12/19  209億円   +4
 12/26  213億円   +4
 01/10  229億円   2週間で+16    ←盛り返してる
 01/16  232億円   +3
ずーっと毎週おおよそ5億円ペースで増加していましたが、年末年始では毎週8億円にブーストアップしてますぞ.

↓この勢いだとアナ雪もタイタニックも越えるだろうなぁ、、、、恐ろしい...
かしこ

2017年1月9日月曜日

【電子工作】 AUO B101EAN01 でHDMI LCD displayを作ってみる (3)

中華通販LCDでこんな感じのHDMIモニタを作ってみようとしています.
だがしかし、XILINX Spartan6 でHDMI信号を処理するため750Mbpsシリアル信号を10bitパラレル 75Msymbol/Sに変換するのが意外にめんどくさい件についてレポートします.まぁなんとか上手く行かせたんだけどね.


【簡単な状況表現】
Spartan6の動作速度の限界を突破するための方策に関して、、、

1) Spartan6でユーザーロジックを好き勝手に実装できるのはせいぜい300MHzぐらいまで

2) 750MHzなどという速度のユーザーロジックは動作速度がまずMETしない (簡単なシリパラ変換回路ですらMETしないくらいダメ)

3) ユーザーロジックによるシリパラ変換すらMETしないことからの逃げとして、ISERDES2のようなシリパラ変換coreを活用してシリパラ変換する必要がある

4) 円満な実装状態では750MHz clockはシリパラ変換coreにのみ供給される形になる


【背景】
HDMI→LCDへのブリッジ回路を設計中です.
HDMIのケーブルを流れるRGB信号のデータレートは、画面の解像度にもよりますが、1280x800だとするとおよそ750Mbpsぐらいになります.

ゆえにぶっちゃけ、FPGAには750MHz clockで動く性能が必要となります.だがしかし、Spartan3EやCycloneのような廉価なFPGAだとPLLが300MHzぐらいまでしか発振してくれないので、採用不可となります.

Spartan6なら750MHzを発振できるだけのPLL性能があるのでSpartan6を採用しました.

次に、パラシリ変換の仕様について考えます.

HDMIケーブルを流れる信号は8/10変換されていますから、750Mbpsのビットストリームを10bitパラレル変換するのが通常的な処理になります.10bitパラレルデータを1シンボルと呼びます.シンボルレートは、75Msymbol/Secになります.

↓以上より、FPGAの入力直後で10bitシリパラ変換して75MHzのゆっくりしたclockでユーザーロジックを実装すればよいわけです.こんなイメージです.

↓ところがですぅ、HDMIケーブルを流れるクロック信号はシンボルレートの75MHzなんです.なのでFPGAで750MHzを再生しなくちゃいけません.こんなイメージになります.

↓だんだんと状況が地雷めいてきます.青いブロックがSpartan6のcoreなんですが、シリパラcoreが最大8パラまでしかできません.なので、10パラを実現するには5パラと2パラを直列接続しないといけません.こんなイメージです.
ここで、XILINXのFPGAについてさらに詳しく知っていれば、2パラもcoreを採用して、core-coreカスケード接続で10パラを実現することも可能らしいのですが、coreの使いこなしってめんどくさいのでやめました. (coreのカスタマイズは専らcore generatorを使っています)

以下では、PLL coreとシリパラcoreの生成について、ノウハウを書きます.


【core generatorによるPLL生成】
1ページ目
・Minimize output jitterを選択したけどこれで論理合成が楽になったのかどうかは不明
・入力周波数=75MHzにする
・HDMIケーブルの信号は差動なのでDifferential clock capable pinにします.ここをsingle-endにしておいて手書きでIBUFGDSを手書きで配置することも可能ですが、IBUFGが2ヶシリーズになってしまうのでエラーでビルドが止まってしまいますのでやめた方がいいでしょう.
2ページ目
・出力周波数を、75/750/375/150MHzに設定
・750MHzの位相は、simulationや実機デバッグでシリパラcoreのデータ化けが生じたら疑って下さい.0か180度を試すとどっちかで上手くいくかもです.わたしの場合はsimulationでシリパラcoreのデータ化けが生じ、750MHzの位相を180度にしたら治りました.シリパラcoreの取り扱いにはクロックレーシングの回避は設計者マターのようです. (FPGAロジックにおいてはPLLで生成させたクロックの乗せ変えはビルドツールが自動的にやってくれるのかなーと思ってるんですがね、わたしの誤解なのかもしれない)
・750MHzではBUFGじゃ役不足なのだそうで、強制的にNo bufferになる
・BUFGではなくBUFPLLを使えと指示される
↓3ページ目
とくになにもせず
↓4ページ目
とくになにもせず
↓5ページ目
クロックのポート名をお好みに名付けます.
↓6ページ目
とくになにもせず、Generateを押す.

【core generatorによるシリパラ生成】
↓1ページ目
・Customを選択
・入力なのでConfigure inputs from deviceを選択
・HDMI信号は差動なのでDifferentialを選択
・HDMI信号はTMDSという電圧規格です.ゆえにTMDS33を選択します.
↓TMDSの受信端では、3.3Vへ50Ωでプルアップするよう定められています.
↓Spatran6がTMDSを受信するには、VCCAUXを3.3Vにしなくちゃいけませんが、あいにくプリント基板は2.5Vに接続されています.なお、VCCAUXはFPGA内部で同一ノードですから、全部同時に3.3Vに接続変えする必要があります.
↓プリント基板の回路図を見ると、電源部分の2.5Vを3.3Vに繋ぎ替えれば良さそうです.まだ試してませんが.  → 追記: これでやってみてOKでした

↓2ページ目
・Use serializationを選択
・5パラにするので、Serialization factor=5
・外部から入力される信号はRGBの3本ですので、External data width=3
・以上の設定により、入力[2:0]、出力[14:0] になります
・Retimedを選択します.これを怠ると、750MHz clockでラッチされた信号が出力に出てきてしまってMETしません.Retimedにすれば、出力が150MHzでラッチされた信号になります.
↓3ページ目
・Delay TypeはNoneでよいと思う
↓4ページ目
・Clock仕様は、Single-endedです.なぜなら、ここに入力されるclockはPLLで生成された750/150MHzだからです.すなわち内部信号であって外部信号ではありません.
・内部信号がLVCMOS18であるべきなのかはよく判りませんがLVCMOS18を選んでおきました.論理合成で無視されることを期待します.
・PLLの設定の2ページ目でBUFPLLを使いなさいと指摘されていました.それに従ってBUFPLLを選択します.BUFPLLはこのcoreに自動的に実装されますので、自分で記述する必要はありません.
・Risingを選択します.これをBothにしてしまうとDDRになってしまいます.
↓5ページ目
とくになにもせず、Generateを押す.


【verologソース】
PLLとシリパラに関連する箇所だけです.

module top(
    input xrst,   // LOW=RESET
    input  clkp,  // HDMI clock  75MHz
    input  clkm,
    input  rp, // HDMI R   750Mbps
    input  rm,
    input  gp, // HDMI G
    input  gm,
    input  bp, // HDMI B
    input  bm
);

pll_tdms pll_tdms        // PLLのcore
(
    .clk75in_P(clkp),    // IN 差動pinを直接配線
    .clk75in_N(clkm),    // IN
    .clk75(clk75),       // OUT
    .clk750(clk750),     // OUT
    .clk375(clk375),     // OUT
    .clk150(clk150),     // OUT
    .RESET(~xrst),       // IN
    .LOCKED(tdms_LOCKED) // OUT
);

wire [14:0] rgb;
ser2para2 ser2para2      // 5シリパラ変換のcore
(
    .DATA_IN_FROM_PINS_P( {rp,gp,bp} ), 差動pinを直接配線
    .DATA_IN_FROM_PINS_N( {rm,gm,bm} ), 差動pinを直接配線
    .DATA_IN_TO_DEVICE( rgb ),          出力は150MHzレート
    .CLK_IN(clk750),
    .CLK_DIV_IN(clk150),
    .LOCKED_IN(tdms_LOCKED),
    .LOCKED_OUT(),
    .CLK_RESET(~xrst),
    .IO_RESET(~xrst)
);

後段のユーザーロジックはrgbとclk150でお好きにどうぞ、となります.


【制約ファイル】
HDMI信号の部分だけです.

NET "clkp" LOC = "P134" ;  # HDMI clock 75MHz = 13.3ns
NET "clkm" LOC = "P133" ;
NET "rm"   LOC = "P137" ;
NET "rp"   LOC = "P138" ;
NET "gm"   LOC = "P139" ;
NET "gp"   LOC = "P140" ;
NET "bm"   LOC = "P141" ;
NET "bp"   LOC = "P142" ;

NET "clk?" IOSTANDARD = "TMDS_33" ;
NET "r?"   IOSTANDARD = "TMDS_33" ;
NET "g?"   IOSTANDARD = "TMDS_33" ;
NET "b?"   IOSTANDARD = "TMDS_33" ;
NET "clk?" PERIOD = 13.33 ns | CLOCK_DEDICATED_ROUTE = FALSE ;

最後にあるFALSEの意味は、差動IOバッファであるところのIBUFGDSがpll coreに自動的に実装される都合上、clkpとclkmにIOバッファが自動挿入されるのを抑制するためです.これがないとビルドがエラーで止まるはずですのでご注意ください.


↓こうなるまでに4~5日悩んだよ.

なお~いつものように、この情報に間違いがあってもわたしは知りませんので、はまったら素直に死んでね.

前回へ      次回へ

かしこ