AXIの勉強（その2.2） [AXI]
書き込みの依存関係です。
3チャンネルあるので長くなりますが、読み込みと同じように分けてみます。
Write transaction dependencies
1• the master must not wait for the slave to assert AWREADY or WREADY before asserting AWVALID or WVALID
2• the slave can wait for AWVALID or WVALID, or both before asserting AWREADY
3• the slave can assert AWREADY before AWVALID or WVALID, or both, are asserted
4• the slave can wait for AWVALID or WVALID, or both, before asserting WREADY
5• the slave can assert WREADY before AWVALID or WVALID, or both, are asserted
実はAWとWの2チャンネルの依存関係が絡んでるここが結構面倒です。
1 マスターのAWVALIDやWVALIDは、AWREADYとWREADYに依存してはならない。
2,3 スレーブのAWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
4,5 スレーブのWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
「１」の制約は
・AWシーケンサーはAW自身のREADYだけでなく、WのREADYも参照してはならない
・WシーケンサーはW自身のREADYだけでなく、AWのREADYも参照してはならない
という２つの制約になっています。
なぜか。
書き込みなのでマスターのAWとWはソースですが、AWとWの順番には特に決まりはなく、アドレスが先でそれからデータ、先にデータを出してからアドレスを送る、もしくは同時、でかまいません。
・ マスターはAWとW、どちらを先に出すか、自由に選べる
・ スレーブはAWとW、どちらを先に受け取るか、自由に選べる
という状況です。相手がどちらを先だと想定しているのかが不明です。
この状態で、
・ もしマスターのWVALIDがAWREADYに依存していて （これが違反）
・ マスターはAW→Wの順番で送る
・ スレーブはW→AWの順番で来ると思ってる
という場合、マスターがAWREADY待ち、スレーブがWVALID待ち、となりデッドロックします。
普通アドレスが先でデータが後でしょう、って事で
AWVALID <= '1';
if (AWREADY = '1') then
AWVALID <= '0'; next_state;
WVALID <= '1';
if (WREADY = '1') then
WVALID <= '0'; next_state;
こんなマスター回路が思いつきます。当たり前な回路に見えますが、 WVALIDがAWREADYに依存しているので、実はこれ違反です。ただ、世の中、アドレスが先だと想定してるスレーブがほとんどなので、大体問題なくつながっちゃいます。
データが来るまでアドレスは受け付けない、というひねくれた（けど仕様に反してはいない）スレーブが、この回路につながるとデッドロックします。例えばこんな回路。
if (WVALID = '1') then
WREADY <= '1';
AWREADY <= '1'; データが送られ始めてからアドレスを受け取る
AWVALIDかWVALIDを動作開始のトリガーと考えると、そんなにひねくれて見えませんよね。2,3,4,5の項目から、これは正しい動作です。
この制約は多分、アドレスとデータを同時に転送できるようにするために作られたんだと思います。データを先に転送するような回路は、もちろん作っても良いですけど、不自然ですよね。
2,3,4,5の制約は、今までと同じく、VALID側を制約して、READY側は自由にすし、デッドロックを回避する、という項目です。
6• the slave must wait for both WVALID and WREADY to be asserted before asserting BVALID the slave must also wait for WLAST to be asserted before asserting BVALID, because the write response, BRESP, must be signaled only after the last data transfer of a write transaction
ちょっと長めですが、要するに
・全てのデータ転送を終えてから、BVALIDをアサートすること。
という制約です。リードのAR→Rの制約と似ています。
注意点としてはWLASTも見ている所です。今まではペイロードの中身がタイミングに影響することはなかったのですが、「全ての」が関係してきます。AXIはバースト転送が基本なので、Wチャンネルの転送が何回あるかはペイロードの中身を見ないとわかりません（転送が1回でも1バーストです）。WREADY&WVALID&WLASTが揃ったのを確認してから、BVALIDをアサート、レスポンスのステートに入ります。
7• the slave must not wait for the master to assert BREADY before asserting BVALID
8• the master can wait for BVALID before asserting BREADY
9• the master can assert BREADY before BVALID is asserted.
これは単純。Bチャンネルのデッドロック防止です。
AXI4になると書き込みの依存関係の図に、矢印が2本増えます。
項目はほとんど同じですが、、「6」だけ異なります。
• the slave must wait for AWVALID, AWREADY, WVALID, and WREADY to be asserted before asserting BVALID
the slave must also wait for WLAST to be asserted before asserting BVALID because the write response, BRESP must be signaled only after the last data transfer of a write transaction
これは
・アドレス転送と、全てのデータ転送を終えてから、BVALIDをアサートすること。
という内容になります。アドレス転送が条件に入ってます。
実はAXI3だと、アドレス転送を完了させないままレスポンスを返せるようになってます。制約がありませんので。AWREADYをずっと返さずにデータ転送を終えて、レスポンスを返して、それからアドレス転送を完了する、という順番でも良かったわけです。
まぁ、普通に考えればおかしな動作ですが。制約されてない以上、あり得る動作です。
AXI4ではこれが制約され、マスターがアドレスとデータ全ての転送を完了するまで、スレーブはレスポンスを返せなくなってます。
スレーブ側の制約です。AXI3のスレーブをAXI4のマスターに接続するときに注意が必要で、ペイロードの内容を変換する以外に、この書き込みの依存関係を満足させる必要があります。
3チャンネルあるので長くなりますが、読み込みと同じように分けてみます。
Write transaction dependencies
1• the master must not wait for the slave to assert AWREADY or WREADY before asserting AWVALID or WVALID
2• the slave can wait for AWVALID or WVALID, or both before asserting AWREADY
3• the slave can assert AWREADY before AWVALID or WVALID, or both, are asserted
4• the slave can wait for AWVALID or WVALID, or both, before asserting WREADY
5• the slave can assert WREADY before AWVALID or WVALID, or both, are asserted
実はAWとWの2チャンネルの依存関係が絡んでるここが結構面倒です。
1 マスターのAWVALIDやWVALIDは、AWREADYとWREADYに依存してはならない。
2,3 スレーブのAWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
4,5 スレーブのWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
「１」の制約は
・AWシーケンサーはAW自身のREADYだけでなく、WのREADYも参照してはならない
・WシーケンサーはW自身のREADYだけでなく、AWのREADYも参照してはならない
という２つの制約になっています。
なぜか。
書き込みなのでマスターのAWとWはソースですが、AWとWの順番には特に決まりはなく、アドレスが先でそれからデータ、先にデータを出してからアドレスを送る、もしくは同時、でかまいません。
・ マスターはAWとW、どちらを先に出すか、自由に選べる
・ スレーブはAWとW、どちらを先に受け取るか、自由に選べる
という状況です。相手がどちらを先だと想定しているのかが不明です。
この状態で、
・ もしマスターのWVALIDがAWREADYに依存していて （これが違反）
・ マスターはAW→Wの順番で送る
・ スレーブはW→AWの順番で来ると思ってる
という場合、マスターがAWREADY待ち、スレーブがWVALID待ち、となりデッドロックします。
普通アドレスが先でデータが後でしょう、って事で
AWVALID <= '1';
if (AWREADY = '1') then
AWVALID <= '0'; next_state;
WVALID <= '1';
if (WREADY = '1') then
WVALID <= '0'; next_state;
こんなマスター回路が思いつきます。当たり前な回路に見えますが、 WVALIDがAWREADYに依存しているので、実はこれ違反です。ただ、世の中、アドレスが先だと想定してるスレーブがほとんどなので、大体問題なくつながっちゃいます。
データが来るまでアドレスは受け付けない、というひねくれた（けど仕様に反してはいない）スレーブが、この回路につながるとデッドロックします。例えばこんな回路。
if (WVALID = '1') then
WREADY <= '1';
AWREADY <= '1'; データが送られ始めてからアドレスを受け取る
AWVALIDかWVALIDを動作開始のトリガーと考えると、そんなにひねくれて見えませんよね。2,3,4,5の項目から、これは正しい動作です。
この制約は多分、アドレスとデータを同時に転送できるようにするために作られたんだと思います。データを先に転送するような回路は、もちろん作っても良いですけど、不自然ですよね。
2,3,4,5の制約は、今までと同じく、VALID側を制約して、READY側は自由にすし、デッドロックを回避する、という項目です。
6• the slave must wait for both WVALID and WREADY to be asserted before asserting BVALID the slave must also wait for WLAST to be asserted before asserting BVALID, because the write response, BRESP, must be signaled only after the last data transfer of a write transaction
ちょっと長めですが、要するに
・全てのデータ転送を終えてから、BVALIDをアサートすること。
という制約です。リードのAR→Rの制約と似ています。
注意点としてはWLASTも見ている所です。今まではペイロードの中身がタイミングに影響することはなかったのですが、「全ての」が関係してきます。AXIはバースト転送が基本なので、Wチャンネルの転送が何回あるかはペイロードの中身を見ないとわかりません（転送が1回でも1バーストです）。WREADY&WVALID&WLASTが揃ったのを確認してから、BVALIDをアサート、レスポンスのステートに入ります。
7• the slave must not wait for the master to assert BREADY before asserting BVALID
8• the master can wait for BVALID before asserting BREADY
9• the master can assert BREADY before BVALID is asserted.
これは単純。Bチャンネルのデッドロック防止です。
AXI4になると書き込みの依存関係の図に、矢印が2本増えます。
項目はほとんど同じですが、、「6」だけ異なります。
• the slave must wait for AWVALID, AWREADY, WVALID, and WREADY to be asserted before asserting BVALID
the slave must also wait for WLAST to be asserted before asserting BVALID because the write response, BRESP must be signaled only after the last data transfer of a write transaction
これは
・アドレス転送と、全てのデータ転送を終えてから、BVALIDをアサートすること。
という内容になります。アドレス転送が条件に入ってます。
実はAXI3だと、アドレス転送を完了させないままレスポンスを返せるようになってます。制約がありませんので。AWREADYをずっと返さずにデータ転送を終えて、レスポンスを返して、それからアドレス転送を完了する、という順番でも良かったわけです。
まぁ、普通に考えればおかしな動作ですが。制約されてない以上、あり得る動作です。
AXI4ではこれが制約され、マスターがアドレスとデータ全ての転送を完了するまで、スレーブはレスポンスを返せなくなってます。
スレーブ側の制約です。AXI3のスレーブをAXI4のマスターに接続するときに注意が必要で、ペイロードの内容を変換する以外に、この書き込みの依存関係を満足させる必要があります。
AXIの勉強（その2.1） [AXI]
続いてリードの依存関係。
Read transaction dependencies
1• the master must not wait for the slave to assert ARREADY before asserting ARVALID
2• the slave can wait for ARVALID to be asserted before it asserts ARREADY
3• the slave can assert ARREADY before ARVALID is asserted
4• the slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available
5• the slave must not wait for the master to assert RREADY before asserting RVALID
6• the master can wait for RVALID to be asserted before it asserts RREADY
7• the master can assert RREADY before RVALID is asserted.
なんかいっぱいありますが、分けてみるとわかりやすいかと思います。
まず上3つ。1,2,3。
・マスターのARVALIDは、ARREADYに依存してはならない
・スレーブはARVALIDを待ってからARREADYをアサートしても良い
・スレーブはARVALIDより前にARREADYをアサートしても良い
前の記事のソース・シンクの関係と同じです。ARチャンネルのデッドロックを防止する制約です。
下3つ。5,6,7。
・スレーブのRVALIDは、RREADYに依存してはならない
・マスターはRVALIDを待ってからRREADYをアサートしても良い
・マスターはRVALIDより前にRREADYをアサートしても良い
Rチャンネルのデッドロック防止です。
真ん中の一つ。4。
・スレーブはARREADYとARVALID両方がアサートされるのを待ってからRVALIDをアサートすること
ARREADYとARVALID両方がアサートされるということは、ARの転送が完了したということです。
ARVALIDはマスターがドライブしているので、スレーブ側のRのソースシーケンサーの制約になります。つまり、
・スレーブはARVALIDが来ないうちにRVALIDをアサートしてはならない
・スレーブはARREADYを先に返してからRVALIDをアサートすること
という制約です。
要は
・アドレス情報が与えられてもいないのに余計な情報を勝手に送るな
・アドレス情報を受け取ったことを、まずマスターに知らせてから、データを返せ
という制約です。1つ目はまあ良いですよね。
2つ目、例えばスレーブがARREADYを返さずに、ARの情報をゆっくり解析する回路にしたとします。これ自体は正しい動作です。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：
・・・・
nクロック目：ARREADY <= '1';
この途中でデータを返すのを違反としています。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：RVALID <= '1'; 違反
4クロック目：if (RREADY) then ここでデッドロック
・・・・
nクロック目：ARREADY <= '1';
なぜか。
例えばこれにつながるマスターがこんな風に順番に処理する回路の場合です。あり得る回路です。
アドレス処理ステート
ARVALID <= '1';
↑クロック
if (ARREADY = '1') then ここでデッドロック
ARVALID <= '0';
データ処理ステート
if (ARVALID = '1') then
RREADY <= '1'
・マスターのARシーケンサーがARREADYを確認してからデータの受信処理を行う
・スレーブのRシーケンサーがARREADYをアサートする前にRREADYの評価を行う
この2つがつながるとデッドロックします。
実際の犯人はRREADYを評価していることで、RVALIDをアサートしたこと自体ではないですが。RVALIDを操作したということは、スレーブがデータ処理ステートに入ったことを意味します。けどマスターがアドレス処理のステートのままだと、RREADYが返ってこないかも知れません。
この、スレーブがデータ処理ステートに入ったのに、マスターがアドレス処理ステートのところで止まったまま、となるのを防ぐための制約で、マスター・スレーブともアドレス処理ステートを完了させてからデータ処理ステートに移行しましょう、そのために、スレーブはARREADYを先に返してからRVALIDをアサートすること、という決まり事です。
下のような違反の回路、AXIに慣れてないうちだと、意外と作りがちな回路です。
ARVALIDをアドレスストローブ信号、ARREADYをウェイト制御信号、と認識してるとこんな回路になります。パケット式じゃない、普通のタイミング方式のバスに慣れてる人がはまりやすいパターンです。
AXIはただのインターフェースの仕様で、どんなコーディングしてるのかわからない相手が接続されます。デッドロックのパターンを決めておかないとエラいことになります。なので、こんな制約が存在します。
Read transaction dependencies
1• the master must not wait for the slave to assert ARREADY before asserting ARVALID
2• the slave can wait for ARVALID to be asserted before it asserts ARREADY
3• the slave can assert ARREADY before ARVALID is asserted
4• the slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available
5• the slave must not wait for the master to assert RREADY before asserting RVALID
6• the master can wait for RVALID to be asserted before it asserts RREADY
7• the master can assert RREADY before RVALID is asserted.
なんかいっぱいありますが、分けてみるとわかりやすいかと思います。
まず上3つ。1,2,3。
・マスターのARVALIDは、ARREADYに依存してはならない
・スレーブはARVALIDを待ってからARREADYをアサートしても良い
・スレーブはARVALIDより前にARREADYをアサートしても良い
前の記事のソース・シンクの関係と同じです。ARチャンネルのデッドロックを防止する制約です。
下3つ。5,6,7。
・スレーブのRVALIDは、RREADYに依存してはならない
・マスターはRVALIDを待ってからRREADYをアサートしても良い
・マスターはRVALIDより前にRREADYをアサートしても良い
Rチャンネルのデッドロック防止です。
真ん中の一つ。4。
・スレーブはARREADYとARVALID両方がアサートされるのを待ってからRVALIDをアサートすること
ARREADYとARVALID両方がアサートされるということは、ARの転送が完了したということです。
ARVALIDはマスターがドライブしているので、スレーブ側のRのソースシーケンサーの制約になります。つまり、
・スレーブはARVALIDが来ないうちにRVALIDをアサートしてはならない
・スレーブはARREADYを先に返してからRVALIDをアサートすること
という制約です。
要は
・アドレス情報が与えられてもいないのに余計な情報を勝手に送るな
・アドレス情報を受け取ったことを、まずマスターに知らせてから、データを返せ
という制約です。1つ目はまあ良いですよね。
2つ目、例えばスレーブがARREADYを返さずに、ARの情報をゆっくり解析する回路にしたとします。これ自体は正しい動作です。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：
・・・・
nクロック目：ARREADY <= '1';
この途中でデータを返すのを違反としています。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：RVALID <= '1'; 違反
4クロック目：if (RREADY) then ここでデッドロック
・・・・
nクロック目：ARREADY <= '1';
なぜか。
例えばこれにつながるマスターがこんな風に順番に処理する回路の場合です。あり得る回路です。
アドレス処理ステート
ARVALID <= '1';
↑クロック
if (ARREADY = '1') then ここでデッドロック
ARVALID <= '0';
データ処理ステート
if (ARVALID = '1') then
RREADY <= '1'
・マスターのARシーケンサーがARREADYを確認してからデータの受信処理を行う
・スレーブのRシーケンサーがARREADYをアサートする前にRREADYの評価を行う
この2つがつながるとデッドロックします。
実際の犯人はRREADYを評価していることで、RVALIDをアサートしたこと自体ではないですが。RVALIDを操作したということは、スレーブがデータ処理ステートに入ったことを意味します。けどマスターがアドレス処理のステートのままだと、RREADYが返ってこないかも知れません。
この、スレーブがデータ処理ステートに入ったのに、マスターがアドレス処理ステートのところで止まったまま、となるのを防ぐための制約で、マスター・スレーブともアドレス処理ステートを完了させてからデータ処理ステートに移行しましょう、そのために、スレーブはARREADYを先に返してからRVALIDをアサートすること、という決まり事です。
下のような違反の回路、AXIに慣れてないうちだと、意外と作りがちな回路です。
ARVALIDをアドレスストローブ信号、ARREADYをウェイト制御信号、と認識してるとこんな回路になります。パケット式じゃない、普通のタイミング方式のバスに慣れてる人がはまりやすいパターンです。
AXIはただのインターフェースの仕様で、どんなコーディングしてるのかわからない相手が接続されます。デッドロックのパターンを決めておかないとエラいことになります。なので、こんな制約が存在します。
AXIの勉強（その2） [AXI]
何年ぶりでしょう（笑）
簡単にタイミングの依存関係について書いてみます。
元になる資料はARMからダウンロードできる「IHI0022E_amba_axi_and_ace_protocol_spec.pdf」です。Issue Eが多分最新版。
AXIは、
という5チャンネルでパケットのやりとりをしている感じなのですが、それぞれのチャネルがREADYとVALIDを持っていて個別にハンドシェイクを行う、という仕組みになっています。
けど、ハンドシェイクは個別ですけど、ちょっとは相手のことも考えないとダメよ、勝手に動くとデッドロックしますよという項目です。これが依存関係で、資料に書いてあります。A.3.3のRelationships between the channelsから始まる内容です。
A3.3.1 Dependencies between channel handshake signals
一番基本になる依存関係です。5系統それぞれにある、READYとVALIDの関係です。AXI Streamにも同じ制約がかかります。こんなことが書かれてます。
• the VALID signal of the AXI interface sending information must not be dependent on the READY signal of the AXI interface receiving that information
• an AXI interface that is receiving information can wait until it detects a VALID signal before it asserts its corresponding READY signal.
掻い摘まむと
・VALIDはREADYに依存してはならない（ソース側の制約）
・READYはVALIDに依存しても良い（シンク側の制約）
と言う事になります。
（マスター・スレーブと呼ぶとと5チャンネルを束ねたインターフェースを指します。だから英語の方ではちょっと持って回った言い方になってます。間際らしいので、ここでは個々のチャンネルのインターフェースをソース・シンクと呼んでます。ソースからシンクへデータが流れます。マスターは3つのソースと2つのシンク、スレーブは3つのシンクと2つのソースを持ちます。）
要するに、ソース側のシーケンサーを作るとき、
if (READY = '1') then
VALID <= '1';
みたいな回路は作っちゃダメですよ、という制約になります。
シンク側は
if (VALID = '1') then
READY <= '1';
という回路を作っても大丈夫です。
ソース側の制約な訳ですが、ダメな回路例と大丈夫な回路例をつないでみれば一目瞭然かと。ソースがREADY待ちで、シンクがVALID待ちとなり、デッドロックします。どちらかに制約をかける必要があり、AXIではVALID側を制約しています。
ちなみにシンク側ですが、この回路にしなければなりません、という’訳ではありません。VALIDに依存しない、
if (Im_free) then
READY <= '1';
という回路にしても良いです。
VALIDに関係なく、自分の都合でREADYをアサートしてもかまいません。READY側の方が自由になっています。
こんなのがAXIの依存関係です。他のチャンネルとの依存関係も読んでいきましょう。
簡単にタイミングの依存関係について書いてみます。
元になる資料はARMからダウンロードできる「IHI0022E_amba_axi_and_ace_protocol_spec.pdf」です。Issue Eが多分最新版。
AXIは、
という5チャンネルでパケットのやりとりをしている感じなのですが、それぞれのチャネルがREADYとVALIDを持っていて個別にハンドシェイクを行う、という仕組みになっています。
けど、ハンドシェイクは個別ですけど、ちょっとは相手のことも考えないとダメよ、勝手に動くとデッドロックしますよという項目です。これが依存関係で、資料に書いてあります。A.3.3のRelationships between the channelsから始まる内容です。
A3.3.1 Dependencies between channel handshake signals
一番基本になる依存関係です。5系統それぞれにある、READYとVALIDの関係です。AXI Streamにも同じ制約がかかります。こんなことが書かれてます。
• the VALID signal of the AXI interface sending information must not be dependent on the READY signal of the AXI interface receiving that information
• an AXI interface that is receiving information can wait until it detects a VALID signal before it asserts its corresponding READY signal.
掻い摘まむと
・VALIDはREADYに依存してはならない（ソース側の制約）
・READYはVALIDに依存しても良い（シンク側の制約）
と言う事になります。
（マスター・スレーブと呼ぶとと5チャンネルを束ねたインターフェースを指します。だから英語の方ではちょっと持って回った言い方になってます。間際らしいので、ここでは個々のチャンネルのインターフェースをソース・シンクと呼んでます。ソースからシンクへデータが流れます。マスターは3つのソースと2つのシンク、スレーブは3つのシンクと2つのソースを持ちます。）
要するに、ソース側のシーケンサーを作るとき、
if (READY = '1') then
VALID <= '1';
みたいな回路は作っちゃダメですよ、という制約になります。
シンク側は
if (VALID = '1') then
READY <= '1';
という回路を作っても大丈夫です。
ソース側の制約な訳ですが、ダメな回路例と大丈夫な回路例をつないでみれば一目瞭然かと。ソースがREADY待ちで、シンクがVALID待ちとなり、デッドロックします。どちらかに制約をかける必要があり、AXIではVALID側を制約しています。
ちなみにシンク側ですが、この回路にしなければなりません、という’訳ではありません。VALIDに依存しない、
if (Im_free) then
READY <= '1';
という回路にしても良いです。
VALIDに関係なく、自分の都合でREADYをアサートしてもかまいません。READY側の方が自由になっています。
こんなのがAXIの依存関係です。他のチャンネルとの依存関係も読んでいきましょう。
Dartが来た [PC]
Kickstarterでやってた、小型ACアダプタのFinsix、Dartが到着しました。
・・・来ると思ってませんでした（笑）。すっかり忘れてました。
履歴を見るとKSキャンペーンが2014年の5月ぐらいですかね。約2年前です。
遅れた理由の一つにLenovoへのライセンシングがあるんだと思います。人的リソースに限りがあるスタートアップで大企業へのサポートに手を出せばそっちでいっぱいいっぱいになるでしょう。一方ライセンス収入でキャッシュフローが潤沢になり、資金切れを起こすことなく製品化に持ち込めたわけで、結果的には良かったんだとは思います。
ということで、箱。
見開き状態に開く。ちなみに小口部分に磁石が入っていて、小気味よくパコンと閉まる。それほど品質の良い箱でもないのに無駄な（笑）
内容物。本体、ケーブル、各種チップ、チップのリスト、袋、取説
チップは9種類
コネクタは2ピン。チップ側も同じ形で、切り欠きの付いた円形。特にセンスピンなどはなく、テスタで当たってもツーツー。ACが入ると単純に20Vが出力される仕様。途中で5Vに落とすDCDCなどが入っていて、USBに供給してるようだ。ちなみにUSBにはLEDのインジケーターが付いてて、負荷がかかると明るくなる。
つないだところ。ケーブルの両端は同じ形なので、USBを本体側にしてもチップ側にしてもOKのようだ。
先にFinsixのライセンスを元に製造されたらしい、Lenovoの65W トラベルACアダプターと比較。半分ぐらい。量産する数が全然違うのはずなので、部品や組み立てのコストが大きさより優先されたのだろうと想像される。Lenovoは筐体もプラスチックだし、プラグが交換可能だし。Finsixは金属筐体。
オレンジと青を入手。
ここしばらくもって歩いてますが、普通のACアダプタとして使えてます。やっぱり小さくて便利。PCの負荷をかけると結構熱くなります。非接触温度センサーで50度ぐらい。ちょっとした小型カイロ。
Lenovoは元々20Vだから問題ないけど、他のPCはどうなんでしょ？18~21Vらしいんで、大体合ってればOKってことかな？
・・・来ると思ってませんでした（笑）。すっかり忘れてました。
履歴を見るとKSキャンペーンが2014年の5月ぐらいですかね。約2年前です。
遅れた理由の一つにLenovoへのライセンシングがあるんだと思います。人的リソースに限りがあるスタートアップで大企業へのサポートに手を出せばそっちでいっぱいいっぱいになるでしょう。一方ライセンス収入でキャッシュフローが潤沢になり、資金切れを起こすことなく製品化に持ち込めたわけで、結果的には良かったんだとは思います。
ということで、箱。
見開き状態に開く。ちなみに小口部分に磁石が入っていて、小気味よくパコンと閉まる。それほど品質の良い箱でもないのに無駄な（笑）
内容物。本体、ケーブル、各種チップ、チップのリスト、袋、取説
チップは9種類
コネクタは2ピン。チップ側も同じ形で、切り欠きの付いた円形。特にセンスピンなどはなく、テスタで当たってもツーツー。ACが入ると単純に20Vが出力される仕様。途中で5Vに落とすDCDCなどが入っていて、USBに供給してるようだ。ちなみにUSBにはLEDのインジケーターが付いてて、負荷がかかると明るくなる。
つないだところ。ケーブルの両端は同じ形なので、USBを本体側にしてもチップ側にしてもOKのようだ。
先にFinsixのライセンスを元に製造されたらしい、Lenovoの65W トラベルACアダプターと比較。半分ぐらい。量産する数が全然違うのはずなので、部品や組み立てのコストが大きさより優先されたのだろうと想像される。Lenovoは筐体もプラスチックだし、プラグが交換可能だし。Finsixは金属筐体。
オレンジと青を入手。
ここしばらくもって歩いてますが、普通のACアダプタとして使えてます。やっぱり小さくて便利。PCの負荷をかけると結構熱くなります。非接触温度センサーで50度ぐらい。ちょっとした小型カイロ。
Lenovoは元々20Vだから問題ないけど、他のPCはどうなんでしょ？18~21Vらしいんで、大体合ってればOKってことかな？
