住宅ローンの仮審査に通った！ ～住宅ローンを組みたい会社経営者の方へ～

なひたふは齢40を超えてもまだ賃貸で、家が欲しいと思っていました。

2~3年前まで本郷の事務所を借りていたときには、家と会社を併せた毎月の家賃が50万円を超えているという超絶アホな状態でした。これ以上、賃貸に無駄なお金を使いたくないので、良さそうなマンションを決めて住宅ローンの仮審査を申し込んでいました。

今日、信金の担当者から「住宅ローンの仮審査に通った」という電話が来ました。この2週間、本当に生きた心地しませんでした。

せっかくなので、会社経営者が住宅ローンを組むために必要な知識について、ネット上の情報をまとめたものを紹介します。

住宅ローンには

• 都市銀行(三菱UFJとかみずほとか三井住友とか)
• 地方銀行(横浜銀行とか千葉銀行とか)
• 信用金庫
• フラット35

とあるようです。

金利は

都市銀行 < 地方銀行 = 信金 < フラット

なので、申し込めるなら都市銀行が一番いいようなのですが、審査の厳しさとしては

フラット < 信金 < 地方銀行 < 都市銀行

だそうです。

都市銀行は金利が安いのですが、公務員とか一部上場企業の正社員といった職業が安定した立場の人向けという記事を読みました。なひたふは会社の経営者なので、職業の安定性としては下位ランクになります。三菱UFJの住宅ローンにもネットで申し込んでみましたが3日ほどで容赦なく否決メールが来ました。否決履歴が残るので申し込まなかったほうがよかったでしょう。

審査内容は金融機関ごとにみんな違うということなのですが、実際には

• 収入
• 返済負担率
• 個人信用
• 借入時年齢・返済時年齢
• 他からの借入
• 頭金(10%程度)を用意しているか
• 会社の業務内容と安定性

を主に見ているようです。

返済負担率というのは、年収のうちの何%までを返済に回せるかということで、これが20~35%以下に収まるかというのが審査のポイントのようです。実際の住宅ローンは0.5％から1.5%くらいで貸し出されますが、審査のときには審査金利といって、仮に3~4%に金利が上がったとしても返済できるかどうかを見るようです。

つまり、借りたい金額を3%~4%の金利で貸したとして35%の負担率に収まるかどうかというのが、審査のポイントのようです。これがアウトだと否決されるか、もしくは減額を言い渡されるようです。

なひたふは会社経営者なので、信金の担当者は「審査は厳しめに行われます」とおっしゃっていました。審査金利を5%くらいに上げても返せるかどうか(負担率35%以内に収まるか)というのを見ているのだと思います。

個人信用の件は、CICから情報を取り寄せて「$」や「-」だけならOKでしょう。返済時の年齢は、現在の基準では80歳までに返し終わればよいみたいです。

他からの借入があるかどうかというのは影響します。以前、会社で必要になったお金を個人のクレジットカードで150万円ほど借りてそれを毎月ちびちび返していたのですが、まだ半分くらい残っている残高がCICの情報にバッチリ載っていました。夜も寝れないほど気になったので、住宅ローンの申し込んだ翌日に全額返済し、返済した証拠を付けてFAXで送りました。

信金と都市銀行の違いとしては、都市銀行は貸せるか貸せないかギリギリでわからない場合にはリスクを取らずに貸さないという判断をするのでしょう。信金はおそらく融資できるようにどこをどうすれば融資できるかをアドバイスしてくれたり信用保証会社と交渉してくれるのだと思います。都市銀行は面倒な人には貸さない。そういう意味では、会社経営者は信金のほうが融資は通りやすいと言えます。

会社の安定性については、直近3期の決算書を求められますが自主的に16期分出しました。16年間ちゃんと利益と役員報酬が毎年同じくらい出ていることを説明する資料を付けました。もちろん赤字の年や利益が少ない年もありますが、ちゃんと理由があればよさそうでした。直近に赤字があっても住宅ローンが否決されるわけではなく、ちゃんと役員報酬が出ていれば、会社と経営者は一体として扱われるようです。

コロナ禍にあっても売上は落ちていなく給付金はもらっていないこと。売上のいくらかの割合は大学や国立の研究機関なので、景気に左右されないことなどを資料を付けて説明しました。

あと、健康保険証の発行日と会社創業日にずれがある理由も聞かれましたが、最初の1年くらいずれていても「従業員を雇い始めたのをきっかけに社会保険に加入した」と説明できればOKでした。

普通は事前審査は4日から1週間かかると聞いていたので、ローンを申し込んで1週間経っても連絡がないときには非常にもやもやした気持ちで過ごしてきたのですが、逆に10日くらい過ぎてからは時間がかかっているということで安心するようになってきました。

なぜなら、もし個人信用の問題や返済負担率の問題でアウトならすぐに否決されるし、会社の状態の審査でも1週間はかからないだろうから「否決する理由が個人や会社の経営状態にはない」という気がしてきたからです。時間がかかっているのは、物件の担保価値とか、自分とは関係のないところの審査を行っていたためでしょう。

事前審査に通ったので次に物件の売買契約をして本審査に進むわけですが、銀行や信金のローンでは仮審査に通れば本審査はそほど怖くはないそうです。収入や返済負担率、会社経営状態などは事前審査で審査しているので、本審査では健康状態や物件の調査、反社との付き合いがないか、事前審査で記入した内容に嘘がないかなど、調べた感じではそういったことがメインになるそうです。数字的なことは事前審査の結果を確認する程度だそうですが、本審査までの間にキャッシングしてしまうとヤバくなります。

あと、会社経営者で必須のことは運をよくすること。家の片付けや大掃除をしたり、神棚の米や塩を新しくしたり、運の悪そうな物を捨てたり遠ざけたりすること。健康状態に問題がなければ献血に行くのもよいでしょう。

それから神社仏閣に行くこと。借りたい物件の地域にある神社と今住んでいる地域の神社にお参りするのは勿論のことです。今まで住んでいる地域の神様にこれまでありがとうございましたとお礼を言うのと、新しく住む地域の神様にご挨拶するのは必須です。崇敬する神社やお寺にも参拝すること。運がもらえます。

最後にいくつかの雑感を述べます。

• 私が申し込んだ信金には信用保証会社が2社あって、その2つの会社のどちらかがOKを出せば良いようでした。銀行自体は審査をせずに保証会社に任せているという記事もどこかで読んだのですが、本当にそういうものかもしれません。
• 仲介してくれた不動産業者が、9年間の賃貸を借りた個人不動産業者で、知り合いの信金担当者を紹介してくれたことも影響していると思います。仲介をお願いするなら一見の不動産チェーンより、長年の付き合いのある地域の不動産を選んだほうがよい。要するに地域密着ということです。信金の担当者も、なんとか通したいと頑張ってくれると思います。
• 私の会社は2年前に従業員をゼロにして、一人だけの会社に戻したということはプラスに働いたかもしれません。従業員がいなくても利益と役員報酬の総額が変わらないという証拠が数字で示せたので、伸びないけど潰れることはないと判断されたのかもしれません。「このローンが通ったら会社のほうにも融資したい」とまで言ってくれました。
• 赤字でもポジティブな理由があればよい（リストラしたとか）。役員報酬と会社利益を足したものがちゃんとが出ていればよい。

ところで、もし信金のローンで落ちたらフラット35に申し込もうと思っていました。仲介金融機関にもよりますがフラットは経営する会社が赤字でも年収が安定していればOKだそうだからです。フラットの事前審査は金融機関が行うのですが、その金融機関が実際に貸すわけではない(機構に仲介する手数料をもらうだけ)のでゆるくなる傾向があり、本審査は機構が行うので厳しくなるそうです。つまり、フラットは事前審査が通っても本審査で落とされる可能性が高く、全く喜べないそうです。

いろいろなことがプラスやマイナスに働くので蓋を開けてみるまでわからないのですが、とりあえず第一段階はクリアできてほっとしています。

返し終わるときには80歳になっているはずなのですが、FP爺Aさんになってまだ電子回路いじっているのかもしれません。

Vivadoで自作のIPをアップグレードした時の超効率的な操作

Vivadoで自作のIPをアップグレードした時の操作ってどのようにしていますか？

まず、普通のやり方を紹介します。

① 子IPのプロジェクトを開いて修正したら、Re-Package IPを実行します。

② メインのプロジェクトに戻ると、上のステータスバーに「Refresh IP Catalog」が出ているので、これをクリック。

③ 画面下にIP Statusという表示が出るので、更新されたコアに赤い鍵が付いているのを確認してUpdate Selectedを実行。

Upgrade IPが行われるのをぼーっと待つ。

終わった。

④ 自動的にGenerate Output Productsというダイアログが開くので、GenerateまたはSkipを押す。

Generateを押すと、すぐにIPのジェネレート(RTLソースをVivadoの内部フォルダにコピーしてラッパを作り、パラメタライズを適用して軽く論理合成すること)が行われる。

Skipを押すと、その作業は全体の論理合成の最中に行われる。

時間のかかる作業を先にやるか、後にやるかの違い。

⑤ 上のダイアログでの作業が完了したら、再びRerunを押す。

Update Selectedが出なくなったらOK。

Update Selectedが出たり、ReRunが出る限りこのクリックを何度も繰り返す。Generate Output Productsの作業を毎回やっていると時間のムダになるのでSkipしたほうがよい。

⑥ 次に、Generate Bitstreamを実行するが、自動的にValidate(パラメータの伝搬とデザインのルールチェック)が行われ、Warningなどが表示される場合があるのでOKをクリック。

⑦ 論理合成結果が古いから、Generate Bitstreamの前に論理合成と配置配線を行うというダイアログが出るのでYesを押す。

⑧ 何個のジョブを同時に走らせるかと聞かれるのでそのままOKを押す。

これで論理合成と配置配線が行われ、Bitstreamが作成されるのですが、毎回毎回このようなクリック作業をするのは疲れます。

いったい、何回クリックしたでしょう？

ただでさえ時間のかかる論理合成。論理合成中にご飯食べて帰ってきたら「ダイアログで確認待ちになっていた」なんて言うことになったら目も当てられません。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

でも、NahiVivaというVivado用のライブラリを使えば、上の手順をすべて自動で行ってくれます。

NahiVivaはgithubで公開していて、

https://github.com/tokuden/NahiViva/

にあります。

下記のURLからZIPでダウンロードできます。

https://github.com/tokuden/NahiViva/archive/master.zip

NahiVivaで自動化する際に使うのは、なんとVivadoのTclコンソールのみです。

まず、Vivadoのプロジェクトフォルダにnahiviva.tclをコピーしたら、

source ./nahiviva.tcl

と入力してNahiVivaのライブラリを読み込みます。

IPの子ウィンドウでのRe-Package IPが終わったら、メインのVivadoに戻って

NahiRun -update

と入力すれば、あとは自動的にBitStreamが作成されているというわけです。

確認のダイアログが出て止められることもありませんので、一気に最後まで行けます。

どんなことをやっているかはTclのソースを見てみてください。

これからは、Update IPから論理合成～配置配線の作業まで自動化して楽をしてしまいましょう！

Vivadoの操作を自動化するライブラリ「NahiViva」をアップデート

Vivadoを使っていて、次のような悩みはないですか？

「プロジェクトがVivado 2018.3用なんだけど、わざわざ古いVivadoをスタートメニューから開くのが面倒くさいな」

「Vivadoがたくさんあるんだけど、古いのを選んで開くのが面倒」

「Update IPの作業って、どうしてこんなに何度も何度もクリックしなきゃいけないの？」

「MCSファイルって、どうやって作るんだっけ？？」

「gitで管理したいけど、ブロックデザインもプロジェクトもバイナリだから相性が悪いな」

「テレワークしようと会社のファイルを家に持って帰ってきたけど、ディレクトリ関係が変わってやりにくい」

「そもそもBitStreamってどこにあるの？」

「お客さんに300Mバイトのプロジェクトをメールで送ったら怒られた」

このような悩みを解決するツール「NahiViva（なひビバ）」を作りました。

オープンソースのツールとしてgithubで公開しています。

https://github.com/tokuden/NahiViva

このツールを使うと、VivadoでIPを変更してから、Update IPをして、論理合成をして、ROMに書き込むためのMCSを作る操作が、

% NahiRun -update
% NahiGenMcs

と、簡単にでできてしまいます。

もう、生のVivadoには戻れなくなりますよ。

ぜひご利用ください！

Vivadoでクロックの名前を付けなおしてset_false_pathを設定する

インタフェースが絡んでくると複数のクロックを使う必要が出てきて、Vivadoはクロック間のタイミングでエラーを出してきます。

タイミングエラーはCritical Warningであるだけではなく、routingにかかる時間が激増するので、早めに解決しておきたいものです。

これを防ぐにはset_falth_pathといって「この信号はタイミング解析しない＝エラーがあっても構わない」という指示を出すのですが、set_falth_pathの指定には正式なクロック名を使って-from -toで設定しなければなりません。

しかしながら、タイミングレポートを見てもクロック信号名は論理合成中にいろいろとリネームされているので、どのクロックがどんな名前なのか一見してさっぱりわからなくなっています。

そこで、クロックの名前をリネームしてset_false_path設定するスマートなやり方を考えたので紹介します。

上の図のタイミングレポートを見てみてください。Timingがエラーを起こしてしまっていて、clk_out1_clk_wiz_0とclk_out1_design_1_clk_wiz_0_0という2つのクロック間でのタイミングが満たされていないようです。

set_falth_pathの書式は、

set_false_path -from [get_pins 生成元クロック] -to [get_ports 宛先クロック]

ですから、エラーを出しているクロック名を調べて、互いに

set_false_path -from [get_clocks clk_out1_clk_wiz_0] -to [get_clocks clk_out1_design_1_clk_wiz_0_0]
set_false_path -from [get_clocks clk_out1_design_1_clk_wiz_0_0] -to [get_clocks clk_out1_clk_wiz_0]

とすれば解決です。

おしまい！志低くしていくならこれで十分です。

ただ、これだと何のことかわからないし、本当に無視していいクロックの関係なのかも怪しくなってきます。

ユーザがHDLで書いたクロック名から変わってしまっているので、名前を見ただけではどういうクロックなのかわかりません。まずはリネームすることを考えましょう。

クロックをリネームするには、tclのcreate_generated_clock コマンドを使うのですが、書式を見ると

create_generated_clock -name new_name [-source source_pin] [-master_clock master_clk] source_object

となっていて、source_pinやmaster_clkに何を指定してよいのか一層わからなくなります。おまけに、アンサーだかフォーラムによればMMCMで作ったクロックはタイミング解析が伝搬するからcreate_generated_clockを使う必要はないよ、とまで書かれています。いや、そうじゃない。MMCMのクロックをリネームしたいんだよ。

やりたいことは、論理合成中にぐちゃぐちゃな名前になったクロックを、ユーザがわかりやすいクロック名に変更してset_falth_pathを設定することです。

それでは順番に解決していきましょう。

まずは、tclコンソールに get_clocks と入力します。

get_clocks
usb_clkout_ip clkfbout_clk_wiz_0 clk_out1_clk_wiz_0 xtalclk_ip clkfbout_design_1_clk_wiz_0_0 clk_out1_design_1_clk_wiz_0_0

このデザインで使われているクロックのリストが出てきました。

ここで、list_property [get_clocks クロック名] とするとクロックの持っているプロパティの一覧が得られるので、やってみましょう。

list_property [get_clocks clk_out1_clk_wiz_0]
CLASS DIVIDE_BY DUTY_CYCLE EDGES EDGE_SHIFT FILE_NAME INPUT_JITTER IS_GENERATED IS_INVERTED IS_PROPAGATED IS_RENAMED IS_USER_GENERATED IS_VIRTUAL LINE_NUMBER MASTER_CLOCK MULTIPLY_BY NAME PERIOD SOURCE SOURCE_PINS SYSTEM_JITTER WAVEFORM

いろいろなプロパティがあるのがわかります。NahiVivaに含まれている便利マクロ _NahiShowAllProperty を使って調べてみると、

_NahiShowAllProperty [get_clocks clk_out1_clk_wiz_0]
CLASS <= clock
DIVIDE_BY <= 
DUTY_CYCLE <= 
EDGES <= 
EDGE_SHIFT <= 
FILE_NAME <= 
INPUT_JITTER <= 0.000
IS_GENERATED <= 1
IS_INVERTED <= 0
IS_PROPAGATED <= 1
IS_RENAMED <= 0
IS_USER_GENERATED <= 0
IS_VIRTUAL <= 0
LINE_NUMBER <= 
MASTER_CLOCK <= usb_clkout_ip
MULTIPLY_BY <= 1
NAME <= clk_out1_clk_wiz_0
PERIOD <= 16.670
SOURCE <= design_1_i/axi_ftsyncfifo_0/U0/INST_CLK_WIZ/inst/plle2_adv_inst/CLKIN1
SOURCE_PINS <= design_1_i/axi_ftsyncfifo_0/U0/INST_CLK_WIZ/inst/plle2_adv_inst/CLKOUT0
SYSTEM_JITTER <= 0.050
WAVEFORM <= 0.000 8.335

いろいろな情報が出てきました。このクロックを生成しているプリミティブのソースがSOURCEで、出力がSOURCE_PINSであることが想像できます。だから、クロックのピンを得るtclコマンドは

[get_pin [get_property SOURCE_PINS [get_clocks clk_out1_clk_wiz_0]]]

でよいことがわかります。

clk_out1_clk_wiz_0をusbclkに、clk_out1_design_1_clk_wiz_0_0をadcclkにそれぞれリネームしてあげましょう。

create_generated_clock -name usbclk [get_pins [get_property SOURCE_PINS [get_clocks clk_out1_clk_wiz_0]]]
create_generated_clock -name adcclk [get_pins [get_property SOURCE_PINS [get_clocks clk_out1_design_1_clk_wiz_0_0]]]

これで名前が付きました。

あとは、お互いにset_false_pathを設定すればOKです。

set_false_path -from [get_clocks usbclk] -to [get_clocks adcclk]
set_false_path -from [get_clocks adcclk] -to [get_clocks usbclk]

まとめると、

① まずは、デザインを開く（Open Implemented DesignまたはOpen Synthesized Designを行う）

② get_clocksでどのようなクロックがあるか調べる

③ 調べたクロックを
create_generated_clock -name 新しい名前 [get_pins [get_property SOURCE_PINS [get_clocks クロック名]]]
でリネームする(xdcに記述)

④ set_falth_path -from [get_clocks ソース] -to [get_clocks 宛先]
でタイミング解析から除外する(xdcに記述)

です。

これでクロックに名前が付くのでわかりやすくなり、タイミング解析されなくなるのでCritical Warningを消すことができます。

XILINXのIP Catalogの割り算器を使ってみた

ADCを使ったデザインで、トリガの設定のために割り算をしなければならなくなりました。ユーザがmV単位で指定してくるトリガレベルをADCのLSB単位に変換するというためです。

除算回路というとサイズが大きく、速度も遅いという印象があるのですが、現在ではどうでしょうか？試してみました。

IPカタログから「div」で検索して除算器を見つけます。Divider Generatorというそうです。どうやらAXI Stream専用になっているようですね。

いろいろな設定項目があり、どう使えばよいのか少し悩みます。

最初のタブではArgorithm TypeはRadix2のほかにHighRadixやLutMultが選べますが、デフォルトのRadix2でいいでしょう。

Operand SignはUnsignedとSignedが選べます。

Dividend WidthとDivisor Widthは、割られる数と割る数です。12÷5＝2あまり3といった場合の、12がDividentで、5がDivisorです。

出力のビット幅はDivident.width+Divisor.widthになります。

DividentもDivisorも1ビット単位で指定できますが、出力のビット幅を見ていると内部では8bit単位で回路を構成しているようなので8の倍数で指定したほうがよさそうです。

出力フォーマットは、「商 & 剰余」という形式になっています。

商のwidthはdividentのwidthであり、剰余のwidthはdivisorのwidthと等しくなります。

つまり、32bit÷16bitの割り算器を作る場合、

signal divident : std_logic_vector(31 downto 0);
signal divident_rdy : std_logic;
signal divident_vld : std_logic;
signal divisor : std_logic_vector(15 downto 0);
signal divisor_rdy : std_logic;
signal divisor_vld : std_logic;
signal divout : std_logic_vector(47 downto 0);
signal divout_vld : std_logic;

で信号を作って、

inst_divider : div_gen_0 port map (
aclk => clk,
s_axis_divisor_tvalid => divisor_vld,
s_axis_divisor_tready => divisor_rdy,
s_axis_divisor_tdata => divisor,
s_axis_dividend_tvalid => divident_vld,
s_axis_dividend_tready => divident_rdy,
s_axis_dividend_tdata => divident,
m_axis_dout_tvalid => divout_vld,
m_axis_dout_tdata => divout
);

で実装すると、divout(47 downto 16)が商、divout(15 downto 0)が剰余となります。

Output ChannelはRemainderとFractionalが選べますが、Fractionalにすると剰余の代わりに小数が出てくるようです。

2ページ目の設定項目は主にタイミングに関するものです。

Clocks per Divisionは、１回の除算を何クロックで行うかを指定するもので、1,2,4,8が選べます。当然遅くしたほうが回路は小さくなるので、時間に厳しい回路でなければ遅くしたほうがいいでしょう。レイテンシのオプションも、回路規模を小さくしたいのであれば最大にしておくのがよいでしょう。

こうして出来上がった回路をMITOUJTAGのBRAMロジアナで解析してみます。

DivisorもDividentもAXI Streamで、treadyに8クロックに1回のパルスが来ているのがわかります。除算コアはtvalidが来るまで待っていてくれるわけではないので、割り算したい信号はこのタイミングで入れなければなりません。

結果が出たタイミングでdivout_validが有効になっているのがわかりますので、計算結果が出てくるのは38クロック後になります。結果がいつ出てくるかは回路規模によって変わるので、除算コアを取り扱うために簡単なステートマシンを作ったほうがよいでしょう。

使用したロジック数はDesign Runsのステータスに出てきます。

32bit÷16bitの除算器を作った場合のリソース消費量は、LUTが259個、FFが626で、Artix-7 100Tの1%にも満たない量でした。BRAMやDSPも使っていませんでした。

これなら気兼ねなく使うことができそうですね。