Ver0.2/マニュアル

Ver0.2 マニュアル †

Ver0.2 マニュアル
語句説明
動作概念
準備段階
チェック
- NCチェック
内部構造
背景
- 想定されるビジネスフロー
動作確認経過
- サンプルプロジェクトの動作

↑

現在のバージョンで出来ること †

回路図じゃ分かりにくいデバイス間の接続がひと目で分かる。
複数基板構成の場合、基板をまたぐデバイス間の接続がひと目で分かる。
FPGAなどの各端子の接続先がひと目で分かるので、表をエクセルなどで加工すればHDL言語開発時のピン（端子）アサイン情報が簡単に作れる。
システム側でサポート出来てなくても、各ピン（端子）の接続先が分かるので、回路の妥当性検討には使える。
簡単な接続チェックを行ってくれる。

↑

エラー報告 †

現在、チェックをスタートするとシステムディレクトリの削除の失敗なのか、作成の失敗なのかエラーが出る場合があるようなので
その場合はシステムディレクトリを削除後、再度チェックをしてみてください。サンプルプロジェクト内に削除するバッチファイルを入れました。
NetやBOMのファイル名に日本語があるとエラーが出ることが判明。

↑

インストール †

公式サイトからダウンロードしてください。
```
http://download.scoutlabo.com/top/scoutchecker/
```

↑

サンプルプロジェクト †

サンプルプロジェクト

回路はほんと適当に書いたものです。もう少し余裕ができたら、もう少しマシな回路に変更します。
システム側でアサインされてない電源の出力を手動で補った部分も入っています。
追加情報ファイル(ETCファイル)の書き方など、これを参考にしてください。

↑

使い方 †

ここで使い方を示す。

↑

[準備段階] †

解析したい回路図のネットファイルと部品表ファイルを用意。

追加情報ファイルを作成。

プロジェクトディレクトリを作り、その下に子ディレクトリを作り、回路図ネットリストと部品表ファイル、追加情報ファイルを保存。

↑

[プロジェクトファイル作成段階] †

新規にプロジェクトファイル作成
1. ScoutChecker?を起動すると、以下のような画面が出る。
2. [File]->[Load project]をクリックすると、以下のような画面が出る。(前に動かしていたプロジェクトファイルで立ち上がる仕様)
3. [File]->[New project]で新しいプロジェクトファイルを作る。
NETファイルを登録する。
1. [FTYPE]をクリックして[NET]を選ぶ。
2. 以下のような表示に成る。
3. 「SET」ボタンを押して、NETファイルを選んで[開く]をクリック。
4. 以下のような表示に成る。
5. [SYMBOL]の欄をクリックしSYMBOLテキストを入れる。(基板１枚の場合も必須。)
6. [PATHTYPE]をクリックして相対を選ぶ。(これは必要な場合のみ行う。プロジェクトディレクトリごと移動するのに便利なので相対推奨)
7. 以下のような表示に成る。
8. [PATHTYPE]の変更を反映させるため空欄を選ぶ。そうすると[FILEPATH]の表示が切り替わる。
BOMファイルを登録する。
1. 同様の手順でBOMファイルも登録する。対応するNETファイルとBOMファイルのSYMBOLテキストは同じに揃えてください。
2. BOMファイルの場合、csvファイルの中の行/列の並びを[FORMAT]で指定する。数字/空欄は半角。行も列も0スタート(最初の列/行は0)。
  1文字目 2文字目 3文字目 4文字目 5文字目 6文字目
  スタート行空欄配置番号の列空欄 VALUEの列空欄 MODEL(型番)の列空欄メーカーの列空欄員数の列
ETCファイルを登録する。
1. ETCファイルもNETファイルと同様の手順で登録する。
プロジェクトファイルを保存する。
1. プロジェクトファイルを保存する。

↑

[チェック段階] †

プロジェクトファイルのダブルクリックで、ScoutChecker?を起動。すると以下のような画面が出る。

[All checked]を押し、全工程にチェックが入ったことを確認する。

メニューの[Check]を押すとチェックがスタートする。

全部の工程に緑のインジケータが着いたら。チェック終了。

デフォルト設定のブラウザが自動で立ち上がり結果が表示される。

↑

[結果確認段階] †

デフォルト設定のブラウザで以下のように表示される。これはTop画面。

全チェック結果
ここに各デバイスの電源端子チェック以外の結果が表示される。

項目名内容
R_CATEGORY チェックの分類カテゴリー
R_TITLE チェックタイトル
R_TARGET チェック対象
R_JUDGE 判定結果
R_JOTAI チェック状態
R_JOTAI_SHOSAI チェック結果の説明
R_KIKAKU チェックの規格

各オブジェクトの表の項目
各オブジェクトのページに飛ぶことが出る。

項目名内容
Symbol シンボルアイコン
KEY プロジェクト内で一意のコード
MODEL 型番(BOMから引用)
VALUE 値(BOMから引用)
MAKER メーカー名(BOMから引用、またはシステムから引用)
DB_Hit システム側で情報が用意されてた場合OK
Status 電源端子の総合判定結果
Linked 各オブジェクトページへのリンク

各オブジェクトのページを開くとこのように表示される。

【結果】

項目名内容
Status 電源端子の信号タイプと論理の総合判定結果
stPOWLOGIC 電源端子の論理の総合判定結果

【デバイス詳細】

項目名内容
KEY プロジェクト内で一意のコード
MODEL 型番(BOMから引用)
IMP 員数。0:未実装、1:実装
VALUE 値
MAKER メーカー名
PinCount? ネットリスト上にあるこのオブジェクトに属するピン（端子）数
MaxPinNum?

【各Pinステータス】

項目名内容
KEY プロジェクト内で一意のコード
PIN ピン（端子）番号
NAME ピン（端子）名
DB_Hit システム側で情報が用意されてた場合OK
IO正解端子の方向性(In/Out/IO)
SIG結果正しい信号タイプ(POW/SIG/LVDS)
jSIG評価チェック結果の信号タイプ
POW正解信号タイプがPOWの場合のみ、信号タイプが一致したらOKの判定が出る。
LOGIC正解正しい論理(L/H)
jLOGIC評価チェック結果の論理
LOGIC結果論理の判定結果
jVOLT チェック結果の電圧
Linked 端子ページへのリンク
端子説明端子の説明
パス評価結果この端子に繋がるパスリスト(アイコン)。
終端詳細接続先情報(テキスト)

終端詳細
[]:この中はピン（端子）名
PU:プルアップ
PD:プルダウン
DirectL:GNDに直接繋がっている。
DirectH:電源パターンに直接繋がっている。
NM:システムが認識出来るパターンじゃない。

各オブジェクトの端子のページを開くとこのように表示される。

各オブジェクトの表の項目
各オブジェクトのページに飛ぶことが出る。

項目名内容

↑

きちんと結果を出すまで †

正直、上記結果はある程度、手を加えた状態です。

おそらく、最初はScoutChecker?側のデータベースが不十分だったりでなかなか思うように出てきません。

なので、次の手順に従って情報を付与してください。

まず、電源パスが全部通るようにする。
1. 欠けてる電源情報を追加
  - 電源ICでシステム側のアサインがされてない場合、アサインをETCファイルに書いて追加します。
  - 例:GigE.U6.2に3.7Vをアサイン
```
[>]KEY:GigE.U6.2,;IO:Out,SIG:POW,LOGIC:H,VOLT:3.7V,jIO:Out,jSIG:POW,jLOGIC:H,jVOLT:3.7V,;
```
2. 電源パスを遮る要素にスルー設定を入れる。
  - 電源パスを遮るダイオードなどにスルー設定をETCファイルに書いて追加します。
  - ダイオードは2pinのデバイスとは限らないためScoutChecker?側でスルーさせることが出来ません。
  - 例:IO.D1.CATHODEとIO.D1.ANODEを接続
```
[&]KeyA:IO.D1.CATHODE,KeyB:IO.D1.ANODE,;
```
とりあえず、電源パスが全て通れば、そこそこの結果が出るようになります。お手間だとは思いますが、最初だけですので何卒よろしくお願いします。

↑

語句説明 †

デバイス

部品のこと。回路上の部品全てがこれに当てはまります。Unitで言うとREF+PIN。

ネット(カタカナ表記)

回路図CADが吐き出す結線情報１個。ネットのこと。デバイスの端子間の接続のこと。

NETリスト

ネットリスト。回路図CADが吐き出す結線情報群。

オブジェクト

デバイス/NETをまとめてオブジェクトと呼ぶ。結果表示の時、この単位で扱うと便利なので名称を与えた。

追加情報

NETリストやBOM(部品表)以外の情報全て。外部からの電源入力や、基板間接続情報など。

追加情報ファイル

追加情報のファイル。テキストファイル。手動で編集ができる。

プロジェクト

ScoutChecker?でチェックを行いたい回路(複数基板間接続も見たいなら、その回路群)に対して１個定義する。

BOM及びBOMファイル

Bill of materialの略。部品構成表。回路図のシンボルに対して詳細情報を記載したもの。

ETCファイル

追加情報ファイル。ユーザーが設計に基いて、必要な情報を付与するためのファイル。

チェック

ScoutChecker?で回路の検査を行うこと。

パス

ここではデバイス間の接続をパスと呼ぶことにします。端子から終端条件のあるデバイスまたはNETまでの接続を１つのパスとします。パスはNETを共有出来ます。
(例：VCC端子には電源ICの出力端子、パスコンなどが繋がっていますが、VCC端子-電源出力端子/VCC端子-パスコンそれぞれが一つのパスになります。)

終端

パスを終わらせること。パスを終わらせるデバイス。

アサイン

端子やデバイス、NETなどに対して情報を付与すること。

スルー

3pin以上のデバイスでパスを通過させたい場合。スルー設定を入れます。

基板シンボル(=SYMBOLテキスト)

基板を特定するシンボル名。
プロジェクトファイルで定義します。
主に基板間の配置番号の被り対策に使います。

Key

このプロジェクト内でデバイス本体/ピン（端子）/NETを特定するために付ける名前。
配置番号のようなもの。
フォーマットは

基板シンボル.部品配置番号.ピン（端子）番号

例：CMOS.CN3.1

DEVKEY

端子が属するデバイス本体のKey。端子が自分の親デバイスを把握するために持つ。

システム対応

デバイスがScoutChecker?側で登録されている。ピン（端子）アサインなどがScoutChecker?側で出来ている。

NET

NETリストを最小単位Unitにバラした時の基板のパターン部分。

REF

NETリストを最小単位Unitにバラした時のデバイス（部品）本体の部分。回路上の部品全ての本体部分(端子除く)がこれに当てはまります。

PIN

NETリストを最小単位Unitにバラした時の端子の部分。デバイスの端子。デバイスは必ず端子でNETに接続されていることを前提にしています。

Unit

REF/NET/PINの単位、総称。NETリストをこの最小単位Unit(REF/NET/PIN)に分解した時の呼び名。デバイス本体／ネット／端子を個々に(REF/NET/PIN)というUnit単位で扱います。

UA

UnitArray?の略。プロジェクト内の全てのデバイス本体／ネット／端子情報が、この中に入っています。

Con

デバイス本体－端子／ネット－端子接続情報を個々にConという単位で扱います。(全て1:1接続です)

CA

ConArray?の略。プロジェクト内の全てのデバイス－ピン（端子）／ネット－ピン（端子）接続情報が、この中に入っています。

RTYPE

部品タイプ。REFの種類。部品配置番号の頭のアルファベット。このツールではこのアルファベットでデバイスの種類を把握しています。

RTYPE	定義
R	抵抗
C	コンデンサ
L	インダクタ
F	ヒューズ
Z
CN	コネクタ
X	発振器、発信子
D	ダイオード、LED
Q	トランジスタ
IC	半導体
U	自分ではあまり使わないですが、使う人が多いので半導体に近い何かとして定義

↑

動作概念 †

概略でもこのScoutChecker?の仕組みを理解してないと準備が出来ないと思うのでここで概念を説明します。
そこそこボリュームがあるので、まずは触りたい場合はサンプルプロジェクトを触ってください。
デバイスという呼び名は、IC/L/R/C/Qなど回路図上に存在する部品全てを指しています。
ScoutChecker?ではデバイスを端子/デバイス本体に分解し、ネットと合わせて３種のUnitという単位に分解して考えます。
内部ではそれぞれ、デバイス本体はREF、ネットはNET、端子はPINという名前で扱います。
接続は端子-デバイス本体/端子-NETの２種の1:1Unit間接続情報(Con)に分解して考えます。
（ユーザーの設定する基板間コネクタ接続やスルー接続の端子-端子を合わせると３種）
まず、ネットファイルからUnitリスト(UA:UnitArray?の略)とConリスト(CA:ConArray?の略)を生成します。
ユーザー情報側からは部品表ファイル、追加情報ファイル。システム側からはMODELで判断してピン（端子）名やIO情報などをUAやCAに追加します。
UAの電源アサインや出力端子を起点にCAを探索し終端するまでConを積み上げて行きます。これで一つのパスが生成されます。
このパスリストから得られる情報を基に回路の評価を行います。

↑

NETリストの詳細 †

NETリストは一般的に、あるパターンに属するピン（端子）名リスト。これの集合体で表現されています。
【telesisの場合】
- パターン名：GNDという名前のネットに属するピン（端子）のリスト。GPIO_2というネットに属するピン（端子）リスト。
```
GND;  CN3.6 CN3.4 CN3.5 IC1.11,
    R7.1 R3.1 CN1.1 CN1.5,
    CN1.20
GPIO_2;  IC3.4 IC3.1 CN1.10
```

↑

Unitの定義 †

このScoutChecker?ではNETリストを最小単位Unitというモノに分解してその集合体として回路を扱います。
Unit種類説明
REF デバイス本体
PIN デバイスに付いている端子
NET 基板上のパターン
【例】
- 以下のNETリストを分解すると、REF/NET/PINの３種類のUnitにバラすことができる。
- 厳密に言うとNETリスト上にはREFに当たるものが出てきませんがPINに載っている情報から作ります。
```
GND;    CN3.6 CN1.20
```
  ↓
```
GND/CN3/CN3.6/CN1/CN1.20
```

↑

KEYの定義 †

回路図内でそれぞれのUnitを１個に特定するためにKEYというモノを定義しています。これはプロジェクトファイル内で定義した回路図のSYMBOLとNETリスト上の呼び名で作るものです。この回路群の中の住所みたいなものです。

基本的に文字列の塊として認識するため、ピン（端子）番号にBGAやダイオードのCATHODE/Cなどの文字列が入っていても問題ありません。

	SYMBOL		NETリスト上の名前			説明
	KEY					説明
例1	MAIN	.	IC1	.	1	MAIN基板のIC1の1番ピン（端子）を指します。
例2	MAIN	.	IC1			MAIN基板のIC1を指します。
例3	MAIN	.	#0001			MAIN基板のネット#0001を指します。

↑

NETリストをUA/CAに変換する仕組み †

このScoutChecker?ではNETリストを最小単位Unitというモノに分解して、それをUA/CAという集合体で再定義して扱います。その仕組をここで説明します。
【例】
メイン基板のNETリスト(SYMBOL:MAIN)：
```
GND;    CN3.6  R3.1 CN1.20
#0001;  IC3.4 CN1.10
```
IO基板のNETリスト(SYMBOL:IO)：
```
GND;  CN1.1 CN1.2 CN3.1
GPIO_2;  IC3.4 IC3.1 CN1.10
```
回路群（プロジェクトで扱う回路全体）
┣ NETリスト（メイン基板）
┃.┣ GND
┃.┃...┣ CN3.6
┃.┃...┣ R3.1
┃.┃...┗ CN1.20
┃.┗ #0001
┃......┣ CN3.4
┃......┗ CN1.10
┗ NETリスト（IO基板）
...┣ GND
...┃...┣ CN1.1
...┃...┣ CN1.2
...┃...┗ CN3.1
...┗ GPIO_2
........┣ CN3.4
........┣ CN3.1
........┗ CN1.10

↓

回路群（プロジェクトで扱う回路全体）
┣ UA(UnitArray?)
┃...┣ MAIN.GND
┃...┣ MAIN.CN3.6
┃...┣ MAIN.CN3
┃...┣ MAIN.R3.1
┃...┣ MAIN.R3
┃...┣ MAIN.CN1.20
┃...┣ MAIN.CN1
┃...┣ MAIN.#0001
┃...┣ MAIN.CN3.4
┃...┣ MAIN.CN3
┃...┣ MAIN.CN1.10
┃...┣ MAIN.CN1
┃...┣ IO.GND
┃...┣ IO.CN1.1
┃...┣ IO.CN1
┃...┣ IO.CN1.2
┃...┣ IO.CN1
┃...┣ IO.CN3.1
┃...┣ IO.CN3
┃...┣ IO.GPIO_2
┃...┣ IO.CN3.4
┃...┣ IO.CN3
┃...┣ IO.CN3.1
┃...┣ IO.CN3
┃...┣ IO.CN1.10
┃...┗ IO.CN1
┃.
┗ CA(ConArray?)
.....┣ MAIN.GND ━ MAIN.CN3.6
.....┣ MAIN.CN3.6 ━ MAIN.CN3
.....┣ MAIN.GND ━ MAIN.R3.1
.....┣ MAIN.R3.1 ━ MAIN.R3
.....┣ MAIN.GND ━ MAIN.CN1.20
.....┣ MAIN.CN1.20 ━ MAIN.CN1
.....┣ MAIN.#0001 ━ MAIN.CN3.4
.....┣ MAIN.CN3.4 ━ MAIN.CN3
.....┣ MAIN.#0001 ━ MAIN.CN1.10
.....┣ MAIN.CN1.10 ━ MAIN.CN1
.....┣ IO.GND ━ IO.CN1.1
.....┣ IO.CN1.1 ━ IO.CN1
.....┣ IO.GND ━ IO.CN1.2
.....┣ IO.CN1.2 ━ IO.CN1
.....┣ IO.GND ━ IO.CN3.1
.....┣ IO.CN3.1 ━ IO.CN3
.....┣ IO.GPIO_2 ━ IO.CN3.4
.....┣ IO.CN3.4 ━ IO.CN3
.....┣ IO.GPIO_2 ━ IO.CN3.1
.....┣ IO.CN3.1 ━ IO.CN3
.....┣ IO.GPIO_2 ━ IO.CN1.10
.....┗ IO.CN1.10 ━ IO.CN1

↑

Path探索 †

CAを使ってパスを探索します。
外部からの電源入力などを起点にパスを探索し、起点の電源情報をパスの終端にアサインしていきます。
全端子についてパス探索を行ったらパス探索は終了です。
パス探索の終端条件はプロジェクトファイル内のプロジェクトパラメータで設定します。
終端条件説明

↑

準備段階 †

以下のファイルを作成する必要があります。各ファイルの作成について説明します。

↑

ファイルの種類 †

基本的に拡張子に制限は無く(PRJを除く)。ScoutChecker?上で各ファイルに対して以下の属性を定義します。

ファイルタイプ	拡張子	名称	詳細
NET	何でもOK	ネットファイル	回路図のネットファイル。各CADの操作手順に従ってネットリストを作成ください。telesisフォーマットです。テキストファイル。
BOM	何でもOK	部品表ファイル	部品構成表のCSVファイル。部品構成表をcsv形式(,区切り、１行１部品)にして作成してください。テキストファイル。
ETC	何でもOK	追加情報ファイル	NETとBOM以外の追加情報ファイル。外部からの電源入力や基板間接続情報。テキストファイル。
PRJ	.schkprj	プロジェクトファイル	ScoutChecker?で使用するプロジェクトファイル。ScoutChecker?を起動して作成します。テキストファイル。

↑

プロジェクトディレクトリ構造 †

プロジェクトごとにプロジェクトディレクトリを作り、その下に子ディレクトリを作り必要なファイルを入れて使用します。
プロジェクトファイルはプロジェクトディレクトリの直下に入れてください。

プロジェクトディレクトリ(ユーザー作成)
┃. 「プロジェクトファイル」
┃. プロジェクト全体を保管するディレクトリ。
┃. プロジェクトファイルをここの直下に置いてください。
┃. ディレクトリ名に制限はありません。
┣ InputData?(ユーザー作成)
┃.. 「ネットファイル」「部品表ファイル」「追加情報ファイル」
┃.. チェックに必要なファイルをユーザーが用意してここに置く。
┃.. ディレクトリ名は下記自動生成ディレクトリ名と被らなければ制限はありません。
┃.. 複数作成可。
┣ Result(自動生成)
┃.┃..・結果を出力するディレクトリ。
┃.┃..・以下全て相対パスなのでこのディレクトリごと移動しても表示に支障は出ません。
┃.┗ HTML(自動生成)
┃....┃.. 「Result.html」
┃....┃..・HTML形式の結果を保存するディレクトリ。
┃....┃..・ここの直下にResult.htmlというファイルが生成されるので、
┃....┃..・結果を見る場合はまずこれを開いてください。
┃....┗ DATA(自動生成)
┃...........・各詳細ページファイル及びCSSファイルなどを格納
┗ backup(自動生成)
.......・プロジェクトが途中結果を吐き出すディレクトリ。。

↑

追加情報ファイルのフォーマット †

追加情報ファイルの書式は以下に従ってテキストファイルで作成します。
行タイプによって、Unit数や何番目のUnitは何の意味など、個々に異なります。

	行タイプ			Unit1														・・・	UnitN
	行タイプ			Info1				Info2				・・・	InfoN				;	・・・	Info1				;
	[		]	ｶﾃｺﾞﾘ	:	値	,	ｶﾃｺﾞﾘ	:	値	,	・・・	ｶﾃｺﾞﾘ	:	値	,	;	・・・	ｶﾃｺﾞﾘ	:	値	,	;
例	[	&	]	TYPE	:	Pin	,	TYPE	:	Pin	,	・・・	TYPE	:	Pin	,	;	・・・	TYPE	:	Pin	,	;

ｶﾃｺﾞﾘ: ScoutChecker?上で一意の項目を指す。
値: ｶﾃｺﾞﾘに入れる値を指す。
Info: ｶﾃｺﾞﾘと値の１セットをInfoと定義する。便宜上左から順にinfo1,Info2,,,とUnitごとに番号を振って使う。
Unit: 複数Infoの集合体（Info１個でも可）をUnitと定義する。便宜上左から順にUnit1,Unit2,,,と番号を振って使う。
行タイプ: その行の扱い方タイプをここで定義。タイプを示す文字を[]で括る。
区切り文字: : ; , [ ] など項目や値の区切りとなる決められた文字。
[]: 行タイプを示す文字の区切り。
:: Infoのｶﾃｺﾞﾘと値を区切る。
,: Infoの終了を示す。
;: Unitの終了を示す。

注意事項
- 情報は１行で完結する。複数行にまたがらない。
- 行が入れ替わっても意味は変わらない。（影響しても表示順だけ）
- 区切り文字は全て半角英数字
- 区切り文字,:;[]はユーザー記載部分では使用禁止。
- １行内に１個以上複数のUnit記載可。
- １Unit内に１個以上複数のInfo記載可。

↑

追加情報ファイルの作成方法 †

↑

接続の追加 †

Unit間接続の追加。CAに追加されます。

この接続に方向性はありません。両方から素通りが可能になります。

行ﾀｲﾌﾟ	説明
[&]	Info1とInfo2が繋がっていることを定義する。方向性無し。

使用ｶﾃｺﾞﾘ	値	説明
KeyA/KeyB	Keyを入れる	KeyAとKeyBは等価に扱われます。

	行タイプ			Unit1					Unit2					説明
	行タイプ			Info1				;	Info1				;
	[		]	ｶﾃｺﾞﾘ	:	値	,	;	ｶﾃｺﾞﾘ	:	値	,	;
例1	[	&	]	KeyA	:	MAIN.IC1	,	;	KeyB	:	MAIN.IC1.1	,	;	普通の接続。REF(MAIN.IC1)とPIN(MAIN.IC1.1)の接続例。
例2	[	&	]	KeyA	:	MAIN.IC1.1	,	;	KeyB	:	MAIN.#0001	,	;	普通の接続。PIN(MAIN.IC1.1)とNET(MAIN.#0001)の接続例。
例3	[	&	]	KeyA	:	MAIN.CN1.1	,	;	KeyB	:	IO.CN2.1	,	;	基板間接続。PIN(MAIN.CN1.1)とPIN(IO.CN2.1)の接続例。基板間接続時に使用する。
例4	[	&	]	KeyA	:	MAIN.D1.CATHODE	,	;	KeyB	:	MAIN.D1.ANODE	,	;	スルー接続。PIN(MAIN.D1.CATHODE)とPIN(MAIN.D1.ANODE)の接続例。電源ラインにダイオードがシリアルに入っている場合、電源アサインをその先に到達させるために使用する。

[&]KeyA:Val1,KeyB:Val2,;
KeyA:Val1をInfo1、KeyB:Val2をInfo2とする。

【基板間接続コネクタアサイン】
- 基板同士のコネクタ接続をPIN同士を繋ぐアサインで実現しています。本来であればREFのコネクタ同士が間に挟まるのですが。扱いにくいのでPIN同士。
- Result表示では、間にコネクタのシンボルが自動で入ります。
  - 例:CMOS.CN3.1とMAIN.CN2.1を接続
```
[&]KeyA:CMOS.CN3.1,KeyB:MAIN.CN1.1,;
```
【スルーアサイン】
- ダイオードやEMIフィルタは3pin以上のモノもあるためパスをスルーさせるためここでピン（端子）間にスルー設定をアサインします。
- ダイオードの端子名はネットリスト内の名前で書いてください。
  - 例1:CMOS.D3.AとMAIN.D3.Cを接続
```
[&]KeyA:CMOS.D3.A,KeyB:CMOS.D3.C,;
```
  - 例2:IO.D1.CATHODEとIO.D1.ANODEを接続
```
[&]KeyA:IO.D1.CATHODE,KeyB:IO.D1.ANODE,;
```

↑

パラメータ追加 †

Unitに対してパラメータ追加。UAの子供のUnitに情報が付与されます。

行ﾀｲﾌﾟ	説明
[>]	Unit1の情報と合致するUnitをUAから検索しUnit2を付与

使用ｶﾃｺﾞﾘ	値	説明
KEY	基板シンボル.配置番号.ピン（端子）番号	回路全体の中でUnitを特定するための名前
IO	I/O/IO	この端子の正解IOタイプを入れる。
SIG	POW/SIG	この端子の正解SIGタイプを入れる。
LOGIC	L/H	この端子の正解ロジックを入れる。
VOLT	数字V	この端子の正解電圧を入れる。
jIO	I/O/IO	実際の所のIOタイプを入れる。
jSIG	POW/SIG	実際の所のSIGタイプを入れる。
jLOGIC	L/H	実際の所のロジックを入れる。
jVOLT	数字V	実際の所の電圧を入れる。

	行タイプ			Unit1					Unit2
				Info1				;	Info1				Info2				・・・	InfoN				;
	[		]	ｶﾃｺﾞﾘ	:	値	,	;	ｶﾃｺﾞﾘ	:	値	,	ｶﾃｺﾞﾘ	:	値	,	・・・	ｶﾃｺﾞﾘ	:	値	,	;
例1	[	>	]	KEY	:	GigE.U6.2	,	;	IO	:	Out	,	SIG	:	POW	,	・・・	jVOLT	:	3.7V	,	;
例2	[	>	]	KEY	:	IO.CN2.5	,	;	IO	:	Out	,	SIG	:	POW	,	・・・	jVOLT	:	GND	,	;
例3	[	>	]	KEY	:	IO.CN2.10	,	;	IO	:	Out	,	SIG	:	POW	,	・・・	jVOLT	:	12V	,	;

【内部電源アサイン】
- ScoutChecker?が回路内の電源ICを認識出来なかった場合(未対応の場合)、手動でそのデバイスの出力端子に電源アサインを付与して電源パスを実現します。
- (電源パスは回路内全て実現しないとチェックは有効な結果を吐きません)
  - 例:GigE.U6.2に3.7Vをアサイン
```
[>]KEY:GigE.U6.2,;IO:Out,SIG:POW,LOGIC:H,VOLT:3.7V,jIO:Out,jSIG:POW,jLOGIC:H,jVOLT:3.7V,;
```
【外部電源アサイン（必須）】
- この回路群に外部から供給する電源をアサインします。
  - 例:IO.CN2.5にGNDをアサイン
```
[>]KEY:IO.CN2.5,;IO:Out,SIG:POW,LOGIC:L,VOLT:GND,jIO:Out,jSIG:POW,jLOGIC:L,jVOLT:GND,;
```
  - 例:IO.CN2.10に電源１２Vをアサイン
```
[>]KEY:IO.CN2.10,;IO:Out,SIG:POW,LOGIC:H,VOLT:12V,jIO:Out,jSIG:POW,jLOGIC:H,jVOLT:12V,;
```

↑

チェック †

チェックの詳細を説明していきます。おおまかに分けると２種類。各デバイス固有のチェックと汎用のチェックがあります。
各デバイスチェック
- 各デバイス固有の端子ごとに、必要な接続があるか？必要な論理切り替えが可能か？をチェックします。
- 各デバイスの設定端子などからデバイスがどういう状態になっているか？をチェックします。
汎用チェック
- NC(Non connect)チェック、GNDネットが複数あるかチェックなど。

↑

NCチェック †

ネットリストにNCは出てきません。なので、システム側で対応出来ているデバイスについてのみ、NC端子のチェックを行います。

↑

内部構造 †

ScoutChecker?の内部構造。

↑

概要 †

このScoutChecker?はモジュールの集合体で。各モジュールはBackUp?ディレクトリ内のファイルを元に動作を行い、またBackUp?ディレクトリに出力して終わる。
各モジュールが独立に完結している。これにより、各モジュールのデバッグ、単体テスト、各個バージョンアップなどを容易にしている。
モジュール入出力説明
PrjF2FL <= BackUp?ファイル群 BackUp?ファイル群をロード。
モジュール動作を行う。
=> BackUp?ファイル群 BackUp?ファイル群をセーブ。

↑

BackUp?ファイル群 †

ScoutChecker?がチェック時backupディレクトリ内で展開しているファイルについて説明。

【ファイル名ルール】

フロー順番		モジュール名		パラメータ名		拡張子
0	_	PrepBackUp?	_	AllResultList?	.	txt

パラメータ名	説明
AllResultList?	全体結果をここに格納している。ResultのTopのテーブル。
ConList?	Conリスト。Unit(REF/NET/PIN)間の接続情報リスト。
FileList?	Fileリスト。プロジェクトに属する全ファイルのリスト。
PathList?	Pathリスト。パス探索結果の全Pathのリスト。ここでは接続情報のみを格納。パス探索で得られた情報付与はUnitList?に付与。
PrjParam?	プロジェクトパラメータリスト。プロジェクトに関する情報を全てここに格納。プロジェクトに属するファイルパスや関連パス、デフォルト値、チェックのトータル結果なども格納。
RuleList?	適用ルールリスト。チェックを行った時のルールを入れる予定。今は未使用？
UnitList?	Unitリスト。個々のUnitに付与された情報全てをここに格納。

↑

オブジェクト(Object)の概念 †

回路評価でいろいろ検討した結果オブジェクトの括りでデータをまとめた方が便利。
オブジェクトとは回路図上の部品（デバイス）。
オブジェクトという器を作って、それに属するピン（端子）リスト。そのピン（端子）リストから発生したパスリスト。などを放り込み、オブジェクト全体で必要な信号が入っているかを評価する。
まだ、試しに入れた概念なので、これが本当に便利で、定着するかはこの後の運用で決める。
BackUp?ファイル群では敢えて、導入せず、毎モジュール動作時、内部でUA/CA/PathList?でObjectを作っている。(ほとんどのデータが重複するので)

↑

各モジュールの影響範囲マトリックス †

主に自分のためにソフトの仕様をここに纏める。
ObjectList?は実際の格納庫はUA(UnitList?)。

一部は順番を入れ替えても問題無いですが。順番に制限があるものもあります。

BackUp?ファイル (パラメータ名)→	FileList?	PrjParam?	UnitList?	ConList?	PathList?	RuleList?	なし	なし	AllResultList?	なし	関数	説明
クラス→	cUnitList?	cUnit	cUnitList?	cConList?	cULList	cULList	cObjectList?	cUnitList?	cUnitList?	cObRuleList?
モジュール名	FL	PrjParam?	UA	CA	PathList?	RuleList?	ObjectList?	ARL	allresult	ObRuleList?
PrepBackUp?		PP_AppPath_Path PP_AppPath_Drive PP_AppPath_Dir PP_AppPath_Filename PP_AppPath_Ext PP_PrjPath_Path PP_PrjPath_Drive PP_PrjPath_Dir PP_PrjPath_Filename PP_PrjPath_Ext										BackUp?ファイルの準備。
PrjF2FL	PrjParam?からFileList?作成 (PrjFile?も)	参照： FTYPE FILEPATH									cPrjF2FL::Conv	プロジェクトファイルからファイルリスト(FL)を生成。
PrjF2PPDTBDTM		参照										プロジェクトファイルからプロジェクトパラメータを展開。_DefaultTerm?/_DefaultTable?を作っているが保存してないことが判明。何もしてない
NetF2UACA	参照： NetFile?	参照： PrjPath?	Unit(REF/PIN/NET)に分解	Conに変換								NETリストファイルの中身を分解してUA/CAを生成する。
EtcF2UACA	参照： EtcFile?	参照： PrjPath?	Unitに情報付与	Con追加		ルール？追加					cEtcF2UACA::Conv(LoadOtherFile?)	・ETCファイル（追加情報ファイル）から得た情報をUA/CAに追加する。・cToken::con（Con行）・cToken::lib（Lib行）・cToken::rule（ルール行）・cToken::include（Include行）。
BomF2UA	参照： BomFile?	参照： PrjPath?	BomFile?からUnitに情報付与								LoadPartFile?	・BOMファイルから得た情報をUnit(REF)に追加する。
		参照	付与								Add_Lib2Unit	・Lib情報をUnitList?に追加。（受け側の想定と引数の中身が違う？　多分機能してない）
			単体加工								_Ref2Pin	・UAの中でDEVKEYが合致するUnit全部にMODEL/MAKER/VALUE/IMPを追加する。(PINにもBom情報を展開)
PrepAnalysis?			単体を加工								cAdd_PinCountMax2Unit	分析の準備。これがないとDB_HITしてないデバイスは何ピン（何番端子）か分からない。なのでPathSearch?の3pin以上ストップが効かない。
			単体を加工								cAdd_ColFilter?	分析の準備。出力HTMLのテーブルのデフォルトcolfilterを全Unitに追加。
			評価結果を追加	評価結果を追加							cJudgeCheckNC::SearchNet2OnePin2Net	分析の準備。Netを全部見て、Netに対して接続が１個だけの場合、そのNetにNCをアサインする。Unitにも追加。
DB2UA_User	参照		FLでDB指定のあったFileのデータを付与								Add_DB2RefUnit?:FL/UA	ユーザーが用意したDBからUAに情報を追加する。要動作確認。
PinAssign?			追加(ObjectList?経由)				UA→OL				cHyokaTorex?::PinAssignOL cHyokaACycIII::PinAssignOL cHyokaXSprtnVI::PinAssignOL cHyokaMEM::PinAssignSPIFlashOL cHyokaMEM::PinAssignParaFlashOL cHyokaCL::PinAssignOL cHyokaCLCN::PinAssignOL	UnitのPINにアサインを追加する。
AnalysisPow?		解析の結果フィードバックがある場合のみ付与	解析の結果フィードバックがある場合のみ付与				このデータの作り込がメイン	解析の結果を追加			cHyokaTorex?::AnalysisOL	電源ICのデバイス分析。今はTorexのみ
PathSearchPow?				CA使用	GND/POWラインのパスリストを作成		編集				cPathSearch?(GND)	SIGタイプがPow信号についてパス探索を行う。オブジェクト単位でパス探索する。結果をオブジェクトにフィードバックする。変化有なら再度パス探索を行う。デバイスに必要な信号が入ってるか？チェックをしてOKなら。電源を出力するサイクルを繰り返す。
PathSearchPow?				CA使用	GND/POWラインのパスリストを作成		編集				cPathSearch?(POW)
Analysis											cHyokaACycIII::AnalysisOL cHyokaXSprtnVI::AnalysisOL cHyokaMEM::AnalysisOL cHyokaCL::AnalysisOL cHyokaCLCN::AnalysisOL	分析。DBからPINアサインをUAに追加。DBヒットデバイスについてはNC端子もここで追加される。
PathSearchSig?				CA使用	Sigラインのパスリストを作成							SIGタイプがSig信号についてパス探索を行う。ALLモード[*:[#w7ac5e15]]でパス探索を行う。
PrepJudge?			参照		PinPin?接続部にDevKey?のUnitを挿入する。						cUA2UAE::PinPin2PinDevPin4PathList?	判定準備。PinPin?接続部にDevKey?のUnitを挿入する。
					同じパスを除外。						cUA2UAE::Compress	判定準備。同じパスを除外。
			PageリンクをUnitに追加								cMakeLinkResult?::Make_LinkOfObject?	判定準備。PageリンクをUnitに追加。
			シンボルリンクをUnitに追加								cMakeLinkResult?::Make_LinkOfSymbol?	判定準備。シンボルリンクをUnitに追加。
JudgeObList?					参照		固有デバイス判定		結果出力		cHyokaTorex?::JudgeOL cHyokaMEM::JudgeSPIFlashOL cHyokaACycIII::JudgeOL cHyokaXSprtnVI::JudgeOL cHyokaCL::JudgeOL cHyokaCLCN::JudgeOL cHyokaNotHit?::JudgeOL	Object単位で判定。
HyokaObPow?							単体評価				cHyokaObPow?::_Analisys_ObPow?	Object単位で電源の判定。
PrepResult?		PP→UA	PP→UA								cPrepResult?::MakeStr_ResultFileName?	結果出力の準備。PrjParam?からPath情報抽出
		単体編集									cPrepResult?::Make_ResultDir?	結果出力の準備。Pathを作っているのでJudgeの前。Judgeでファイル出力している。
		参照									cPrepResult?::Copy_SymbolImageFile?	結果出力の準備。イメージファイルをコピー。
Judge		参照	付与						編集		cJudgeGNDMult cJudgeCheckNC cJudgeCheckPowShort? cJudgeIOCheckResult? cJudgeNonConnectInput? ::Judge/Output	判定。
OutputResult?		参照									cOutputCSS::CSS_Main	結果HTMLファイルの出力。CSS出力。
		参照	参照						参照		cOutputObjectList?::OutTXT_AllResultListHTML	結果HTMLファイルの出力。全体結果出力。
		参照	参照	参照	参照				参照		cOutputObjectList?::OutTXT_ObjectList?	結果HTMLファイルの出力。ObjectList?結果出力。
		参照	参照						参照		cOutputObjectList?::OutTXT_ObjectListTop?	結果HTMLファイルの出力。ObjectListTop?結果出力。

↑

パス探索のモード †

GND/VCCパス探索でSIGTYPE：POWを各所にアサインして廻り、そのPOWを終端条件にしてSigパス探索を行う。
この辺はPrjParams?でいじれるようになっているが、触らないのが良い。
モード終端条件
RTYPE SIGTYPE VALUE IOTYPE
GND X Q IC CN Z D U C U1K(1KΩ以上は終端の意味)
Pow X Q IC CN Z D U C POW U1K(1KΩ以上は終端の意味)
All X Q IC CN Z D U POW

↑

パス探索の仕組み †

スタート端子(PIN)決める。空のPathList?を用意。
そのPINが属するREFとそのPINのConをCAから探してPathList?に追加。
そのPathList?で終端判定。
PathList?の端のUnitのKeyでCAからCon検索。
ヒットしたらPathList?にそのConを追加。
再帰探索。（3に戻る）

パスの例

TOP.CN1-6pin =(GNDネット)= 94pin-TOP.IC5

段階
```
PLKEY:TOP.CN1,PLKEY:TOP.CN1.6,;
```

段階

PLKEY:TOP.CN1,PLKEY:TOP.CN1.6,PLKEY:TOP.GND,;

段階

PLKEY:TOP.CN1,PLKEY:TOP.CN1.6,PLKEY:TOP.GND,PLKEY:TOP.IC5.94,;

段階

PLKEY:TOP.CN1,PLKEY:TOP.CN1.6,PLKEY:TOP.GND,PLKEY:TOP.IC5.94,PLKEY:TOP.IC5,;

↑

DEVKEYの概念 †

DeviceKey?の略。Unit(REF/PIN)が持っているparams(属性)の一つ。
REF/PINについては、それぞれが部品（デバイス）の一部なのでBomから得られる部品全体情報を持つ。
Unit(REF)のKEYをUnit(PIN)にDEVKEYの名前で付与して実現。
使いみちはObject作成時に同じDEVKEYでくくるなど。

↑

各モジュール †

最初のウィンドウ表示で、モジュールごとにボタンが並んでいる。個々のモジュールをここで説明する。

↑

PrepBackUp? †

BackUp?ファイルの準備。

↑

PrjF2FL †

プロジェクトファイルからファイルリスト(FL)を生成。

↑

PrjF2PPDTBDTM †

プロジェクトファイルからプロジェクトパラメータを展開。

↑

NetF2UACA †

NETリストファイルの中身を分解してUA/CAを生成する。

↑

EtcF2UACA †

ETCファイル（追加情報ファイル）から得た情報をUA/CAに追加する。

↑

BomF2UA †

BOMファイルから得た情報をUAに追加する。

↑

PrepAnalysis? †

分析の準備。

↑

DB2UA_User †

ユーザーが用意したDBからUAに情報を追加する。

↑

PinAssign? †

UnitのPINにアサインを追加する。

↑

AnalysisPow? †

電源信号関連の分析。

↑

PathSearchPow? †

SIGタイプがPow信号についてパス探索を行う。

↑

Analysis †

分析

↑

PathSearchSig? †

SIGタイプがSig信号についてパス探索を行う。

↑

PrepJudge? †

判定準備。

↑

JudgeObList? †

Object単位で判定。

↑

HyokaObPow? †

Object単位で電源の判定。

↑

PrepResult? †

結果出力の準備。

↑

Judge †

判定。

↑

OutputResult? †

結果ファイルの出力。

↑

エラー報告(対策済み) †

FPGAなどの型番を末尾まで入れないと複数の型番が合致して、オブジェクトのピン（端子）リストで同じピン（端子）番号の行が複数出る不具合が発覚。(Ver0.2.0.4で対策)

↑

背景 †

このソフトの存在に関する周辺状況。

↑

想定されるビジネスフロー †

回路設計者を取り巻く環境は、会社の規模、業種、業態、それぞれによって異なります。回路を設計して基板が出来上がるまでの工程で、どこを外注に頼んでいるかなどはまさに会社によってまちまちだとは思います。なので、ここではこちらが想定している業務フローを書いておきますので。参考にしていただき、自分の工程で活かせる部分を活かして頂ければと思います。

回路検討（採用部品（デバイス）の使い方や、周辺回路の妥当性の調査）
回路設計（回路図CADで回路図面を書く）→ ここでScoutChecker?に入れて結線の確認や、異常検出を行う。
アートワーク設計（ここは外注にお願いしています）→ 外注さんと連絡とりあうとき、どの部品（デバイス）の話かを突き止めるのに回路図面よりはScoutChecker?の結果表示の方が見やすい。
基板作成（ここも外注にお願いしています） → 空いた時間でFPGAなどの準備。そこでもScoutChecker?の結果表示からFPGAアサイン作成が楽にできる。
基板実装（基板に部品（デバイス）を乗せる（実装する））
実装基板上がり → 火入れをして、異常を見つけたら、速やかにScoutChecker?の結果を確認。

↑

動作確認経過 †

↑

サンプルプロジェクトの動作 †

↑

H30.12.24 ダウンロード後起動してもエラーで止まる。Win10 †

エラー箇所がわかって対策を打ったつもりだったけど、なんだかまた似たエラー出る。そもそもVer0.2.1.2でWin7で動いてたプロジェクトをVer0.2.1.2＋Win10で動かすと動かない。Win10でカレントディレクトリの挙動が変わったからか？

↑

H30.12.24 やはりカレントディレクトリの部分が何かおかしい。 †

↑

H30.12.26 VS2013のDVDを発見した。 †

MSのテクサポに聞いたら、DVD版を買ったならDVDを見つけるしか無いとのこと。使う権利を買ったんじゃないかとゴネたけどダメだったｗ
引き出しをひっくり返してなんとか、以前買ったVS2013のDVDを探し出した。VS2017とはもうオサラバだ。