公開日：2021/10/16

18th Season

#18-4　Moscoviumと日本語フォント

　今回は、FPGAボード(Sipeed Lichee Tang Primer)のMoscoviumマイコンに、日本語(漢字)フォントROMを搭載しようというテーマです。

日本語(漢字)フォント考察

　昔(「#12-3　DUE＋TFTで日本語表示」)、Arduino DUE＋TFTシールドで考察したことがあるので、重複は避け、以下にまとめます。

空き領域が少なく漢字がぎっしり詰まっている、区点コード：94区×94点＝8,836文字を使った。

区点コード表はこちら。
DUEの時は区点コード1区～94区のコード領域をカバーしていた。
1区～47区：　第一水準
48区～84区：　第二水準
89区～92区：　その後に追加された漢字、環境依存
13区もJIS規格には無くて、環境依存だとか(余談)。

16×16[ドット]のフォントデータだと、32バイト/文字。
合計：8,836文字×32バイト/文字≒277KバイトのROMが必要。

「Flashメモリが512KバイトもあるDUEならでは」の、アプリケーションだった。

　まさに、Flashメモリが512KバイトもあるDUEだから実現できた応用だったのですが、これをMoscoviumマイコン(FPGAボード)で実行できるか？と言うと、できません。
　メモリ(RAMマクロ)が全く足りないのです。FPGAボードの全RAMマクロを投入しても、128Kバイトにしかなりません。

※1トランジスタ/ビットのFlashメモリに比べて、FPGAボードのRAMはデュアルポートなので8トランジスタ/ビット程になるため、太刀打ちできません。

　これをMoscoviumマイコン(FPGAボード)で実現するには、メモリ使用量の削減が必要です。以下に、その削減案を示します。

１）文字領域を絞る。

94区×94点の全区点コードをカバーしていたDUEから、例えば、以下の様に削減することが可能。
1区～47区まで、4,418文字を収録して、第一水準漢字だけに対応する。
1区～84区まで、7,896文字を収録して、第二水準漢字まで対応する。

２）フォントサイズを小さくする。

16×16[ドット]だと、フォントデータは32バイト/文字。
これを8×8[ドット]に縮小すると、フォントデータは8バイト/文字となる。

　案１）及び２）を組み合わせて、結果、64Kバイト以下まで圧縮できたら、何とかFPGAボードのRAMマクロで賄うことが可能です。２）案でデータサイズは1/4、１）案でも1～1/2程度まで圧縮可能なので、合わせ技で何とかなりそうな感触です。

コード体系

　これについても、「#12-3　DUE＋TFTで日本語表示」で議論済みなので詳しくはそちらをご覧ください。

　コード体系はシフトJIS(S-JIS)が便利なので、これを採用します。

　S-JISから区点コードへの変換が必要となります。変換プログラムは、「#12-3　DUE＋TFTで日本語表示」より、tft_kprint.inoの中で使ったtft_sjis2kuten()関数がそうなので、そちらを参照してください。
　このプログラム(tft_kprint.ino)でもそうですが、区点コードは二次元(区と点)のマトリクスで扱い難い為、0番からのシリアル番号に変換して取り扱います(下式)。

　　区点シリアルコード＝(<区>－1)×94＋<点>－1
　　　……　1≦<区、点>≦94、0≦区点シリアルコード＜8,836＝94²

半角フォント

　半角フォントには対応しません。全角フォント8×8[ドット]に対して半角フォント4×8[ドット]では、あまりに視認性が悪すぎるためです。
　ただし、半角のASCIIコードを指定された時に、漢字などと同じ8×8[ドット](全角)のフォントを表示可能な様に工夫しておきます。

　具体的には、区点シリアルコードの0x0300～0x03ff番にASCIIコード(0x00～0xff)のフォントを入れておきます(下図)。

　上図赤枠で囲んだ所が、区点シリアルコードで0x0300～0x03ff番に該当する部分です。区点コードの9区～11区辺りに相当します(上図一番上に見えている行が1区)。
　元々、区点シリアルコードの0x0300番台は空き領域になっていて、有効な文字が存在しないため他の文字とは干渉しません。

　ASCIIコード範囲のフォントデータを取り出したい時には、<ASCIIコード>＋0x0300を区点シリアルコードとするフォントを取ってくれば良いことになります。

日本語フォントユニット(FONTJP)

　DUEのプログラム(tft_kprint.ino)では、プログラムメモリ上にフォントデータを配置しました。
　Moscoviumの場合16ビットマイコン故、メモリ空間が64Kバイト分しかなく、現在のバスステートコントローラBUSC2040Dでは、RAM領域が最大40Kバイト、ROM領域が最大20Kバイトに制限されていて、メモリ空間にフォントROM 64Kバイトを配置するのは困難です。

　そこでMoscoviumマイコンでは、I/Oユニットの1つとして「日本語フォントユニット」を作り、メインメモリとは別空間にフォントROMを持たせます。I/OレジスタにS-JISコードを書き込むと、別なレジスタからフォントデータを読み出せるような仕組みにしようと思います。

目標仕様

　以下、日本語フォントFONTJPユニットの目標仕様をまとめます。

漢字コードレジスタにS-JISコードを書き込むと、別なレジスタから対応するフォントデータを読み出せるような仕組みとする。

フォントデータは8ビット(1バイト)毎に処理する可能性が高いので、読み出しレジスタはバイトアクセスが可能な様に設計する。

S-JISコードから区点シリアルコードへの変換は、ハードウェアで作り込む。

複雑な計算が必要なので、ハードウェア化すると論理規模が大きくなってしまうが、その計算を毎回ソフトウェアで実行する時間的ロスを考えると、ハードウェア化しておくのが正しいと信じる。

読み出したフォントの回転や反転、×2倍拡大などの簡単なアフィン変換は、ソフトウェアよりハードウェアの方が得意なので、その機能も盛り込む。

ブロック図

　ブロック図は以下の様になります。

　薄黄色の箱は、CPUからアクセス可能なI/Oレジスタです。レジスタの中に、その機能と関連する論理も含まれています。例えば、fnjpcodブロックにはS-JISコードから区点コードへの変換回路、fnjpdatブロックにはアフィン変換回路(後述)が含まれます。

I/Oレジスタ仕様

　以下表にI/Oレジスタ一覧を示し、その後に各レジスタの仕様を説明します。

Addr

Name

R/W

Bit：15～0

Memo

0xf0b0

fnjpctl

－

SJ
S1

SJ
S2

KT
C

IN
V

FL
PH

FL
PV

ROT
[1:0]

font rom control

0xf0b2

fnjpcod

FCOD[15:0]

S-JIS(W) or KU-TEN(R) code

0xf0b4

fnjpdbl

－

FNTD[7:0]

convert double

DOBL[15:0]

0xf0b6

－

reserved

0xf0b8

fnjpdata

FDAT7[7:0]

FDAT6[7:0]

font rom data a

0xf0ba

fnjpdatb

FDAT5[7:0]

FDAT4[7:0]

font rom data b

0xf0bc

fnjpdatc

FDAT3[7:0]

FDAT2[7:0]

font rom data c

0xf0be

fnjpdatd

FDAT1[7:0]

FDAT0[7:0]

font rom data d

　BUSC出力のセレクト信号はbcs_fnjp_nです。上表の範囲でアサートされるので、FONTJPユニット内では、アドレスbadr[3:0]を復号してレジスタを特定しています。このI/Oユニットでは、fnjpdata，fnjpdatb，fnjpdatc，fnjpdatdに対してはバイト／ワードアクセスが可能です。それ以外のレジスタは、必ずワードアクセスしてください。

制御レジスタfnjpctl

初期値：　0x0000　(フラグ値は除く)
FONTJPユニットの制御レジスタです。以下、各ビットについて説明します。
SJS1：　S-JIS第一バイトフラグ

fnjpcodレジスタに書き込んだコード値の上位バイトFCOD[15:8]がS-JIS第一バイトコード範囲にある場合、SJS1＝1となります。
読み出し専用、書き込みは無効です。

SJS2：　S-JIS第二バイトフラグ

fnjpcodレジスタ書き込んだコード値の下位バイトFCOD[7:0]がS-JIS第二バイトコード範囲にある場合、SJS2＝1となります。
読み出し専用、書き込みは無効です。

KTC：　区点シリアルコードビット

KTC＝1とすると、fnjpcodレジスタへ書き込んだコード値を区点シリアルコードと見なします。
KTC＝0では、fnjpcodレジスタへ書き込んだコード値はS-JISまたはASCIIコードと見なします。

INV：　0／1反転ビット

INV＝1とすると、読み出すフォントデータの0／1を反転します。

FLPH／FLPV：　横／縦反転ビット

アフィン変換設定ビットです。
1を設定すると、読み出すフォントデータの左右(FLPH)・上下(FLPV)を反転します。

ROT[1:0]：　回転フィールド

アフィン変換設定ビットです。
読み出すフォントデータを時計回りにROT[1:0]×90°だけ回転します。

文字コードレジスタfnjpcod

本レジスタに書き込んだコードに対応するフォントデータを、フォントデータレジスタfnjpdatXから読み出すことが可能です。

fnjpctl[KTC]ビット＝0の場合、本レジスタに書き込んだ値はS-JISコード(16ビット)またはASCIIコードと見なします。

上位バイトFCOD[15:8]＝0x00の場合：　下位バイトFCOD[7:0]をASCIIコードと見なします。
下位バイトFCOD[7:0]＝0x00の場合：　上位バイトFCOD[15:8]をASCIIコードと見なします。
それ以外の場合、fnjpcodレジスタ値をS-JISコードと見なします。

KTC＝1の場合、本レジスタに書き込んだ値は区点シリアルコード(13ビット)と見なします。
本レジスタを読み出すと、書き込んだコードに対応する区点シリアルコード番号が読み出されます。
本レジスタに書き込んだコードが有効なコード範囲から逸脱していた場合、読み出し値は0x8000となり、フォントデータレジスタfnjpdatXから読み出されるフォントは、区点シリアルコード0x0000の全角空白となります。
書き込んだコードがASCIIコードの場合、区点シリアルコードの0x0300～0x03ffに変換されて読み出されることに留意してください(この範囲にASCII文字フォントを写像してあるためです)。

倍角変換レジスタfnjpdbl

初期値：　0x0000

下位8ビットFNTD[7:0]に書き込んだデータに対して、以下の様に変換したデータが読み出し可能です。
DOBL[15:0]＝｛
　　FNTD[7]，FNTD[7]，　FNTD[6]，FNTD[6]，
　　FNTD[5]，FNTD[5]，　FNTD[4]，FNTD[4]，
　　FNTD[3]，FNTD[3]，　FNTD[2]，FNTD[2]，
　　FNTD[1]，FNTD[1]，　FNTD[0]，FNTD[0]｝
フォントデータに対して上変換を実施すると、横方向に×2倍拡大したのと同じ効果となります。

フォントデータレジスタfnjpdata～fnjpdatd

fnjpcodレジスタに書き込んだコードに対応するフォントデータを読み出し可能なレジスタです。
本レジスタだけは、バイト／ワードアクセスの両方が許可されています。
8×8[ドット]フォントの上から1行目がFDAT7[7:0]、2行目がFDAT6[7:0]、……8行目がFDAT0[7:0]に対応します。
各バイトデータ内のビットは、MSB側(第7ビット)が左端、LSB側(第0ビット)が右端のドットに対応します。

アフィン変換回路

　前節レジスタ仕様に示した様に、90°毎の回転変換と、左右・上下反転(アフィン変換)をハードウェアで実行できるようにしておこうと思います。

　例えば、時計回り90°回転は、以下表の様になります。

レジスタ		original font								→	rotate 90°
レジスタ		7	6	5	4	3	2	1	0	→	7	6	5	4	3	2	1	0
fnjpdata	[15:8]	63	62	61	60	59	58	57	56	→	7	15	23	31	39	47	55	63
fnjpdata	[7:0]	55	54	53	52	51	50	49	48		6	14	22	30	38	46	54	62
fnjpdatb	[15:8]	47	46	45	44	43	42	41	40		5	13	21	29	37	45	53	61
fnjpdatb	[7:0]	39	38	37	36	35	34	33	32		4	12	20	28	36	44	52	60
fnjpdatc	[15:8]	31	30	29	28	27	26	25	24		3	11	19	27	35	43	51	59
fnjpdatc	[7:0]	23	22	21	20	19	18	17	16		2	10	18	26	34	42	50	58
fnjpdatd	[15:8]	15	14	13	12	11	10	9	8		1	9	17	25	33	41	49	57
fnjpdatd	[7:0]	7	6	5	4	3	2	1	0		0	8	16	24	32	40	48	56

　表は8×8[ドット]のマトリクスとなっていて、レジスタ欄に、フォントデータを読み出し可能なfnjpdata～fnjpdatdレジスタと、その上位・下位バイトが縦に並んでいます。
　マトリクス内に記載した数字は、読み出したフォントデータのビット番号63～0です。青く着色したセルから、ビット値"1"が読めると思ってください。上表の例では、平仮名「あ」のフォントデータを読み出している状態です。

　左半分(original font)に示したフォントデータを時計回りに90°回転すると、右半分(rotate 90°)となるべきです。つまり、対応するビット番号(63～0)が対応するレジスタから読める様、単にビット順番を組み替えれば良いことが解ります。
　他の左右・上下反転も同じです。

　すると、アフィン変換回路は以下図となります。

　ビットの組み替え回路(○に×の⨂回路)は論理セルを消費しませんが、セレクタMUXは、64ビット2 to 1セレクタとなるので、そこそこ大きい回路にはなります。しかし、この変換をソフトウェアで実現しようとしたら、大変です。一体、何百サイクル掛かるんだ？ってことです。ハードウェアで持たせておいた方が絶対良いはず！

　なお、複数のアフィン変換を組み合わせた場合の変換順番は、上図の通りとなっております。

　時計回り90°回転回路(図中ROT90)を1つ作っておくと、それを3個カスケードに接続するだけで、0°、90°、180°、270°の回転に対応することが出来ます。

RAMマクロ

　TD IDEのROMマクロは、RAMマクロをリードオンリで使っています。
　RAMマクロには、9KビットRAMマクロ(最大64個使用可能)と、32KビットRAMマクロ(最大16個使用可能)の2種類があります。

　Moscoviumマイコンに於いては、32KビットRAMマクロはCPUのメインメモリ(ROMおよびRAM)用として、最大でROM 20Kバイト＋RAM 40Kバイトを使う場合があります。最大構成の場合に必要な32KビットRAMマクロ数は15個です。
　残り1個では4Kバイト分にしかならず、フォントROMに使うにはサイズ不足です。

　従って、フォントROM用としては9KビットRAMマクロを使うことになります。
　9KビットRAMマクロも、UART8N1の受信FIFOバッファや、LOGA8CHの取り込みFIFOなどで使うため、全て使い切ってしまう様では、他のI/Oユニットとの同時使用が出来なくなります。

フォントは8×8[ドット]なので、8バイト/1文字のデータ量である。
TD IDEのROMマクロは、柔軟にビット幅とワード数を指定できるので、1文字分のフォントデータ(8バイト)を1サイクルで読み出し可能な様に、64ビット(8バイト)幅のROMマクロとする。
つまり、1文字当たり1ワード(＝64ビット)となるので、区点コード表から収録したい文字数を決め、その分のワード数でROMマクロを作成する。 → 文字数＝ワード数
第二水準まで収録すると、1区～84区まで84区×94点＝7,896文字なので、このコード範囲をカバーできる様なワード数は8Kワード(8,192ワード)となる。

　TD IDEのIP Generatorを起動して、以下図の様にROMマクロを作成しておいてください。

　この場合の9KビットRAMマクロ数は、上図にある通り57個(推定値)です。最大64個まで、7個ほど余裕がありますので、UART8N1等いくつかのI/Oユニットとは共存できると思います。

漢字フォントはどうする？

　第二水準までの文字で、ざっと7,000文字以上の漢字フォントを起こすのは大変……。気が遠くなりかけた時、福音がありました！フリーの8×8[ドット]フォントを提供してくれているHPを見つけたのです(↓)。

　　Little Limit(別ウインドウが開きます)

　ありがたや。上HPから、「美咲フォント」を使わせていただこうと思います。

　以下、「美咲フォント」のMIFファイルを生成する手順です。

１）「美咲フォント」をダウンロードする。

上のリンクから、「font ⇒ 一覧 ⇒ 美咲フォント」と進んで、「PNG 形式 (ビットマップ画像)」のファイルをダウンロードしてください。
解凍すると、区点コード順で整列されたフォントデータが入っているPNGファイルが見つかります。

２）PNGファイルをMicrosoftのペイントソフトウェアなどを使って開き、BMP形式でセーブする。

Olive+のスクリプトで処理するので、Olive+で読み込めるよう、BMP形式でセーブしてください。
PNGファイルはゴシック体2パタンと明朝体の3種類があるので、お好きなフォントを使ってください。

３）Olive+のスクリプト(fontjp_gen_mif.olv)を使って、美咲フォントのBMPファイルからMIFファイルに変換する。

スクリプト(.olv)の実行には、Windowsに拙作Olive+のインストールが必要です。
入力ファイル名：

スクリプト先頭付近の文字列マクロfnam_inで指定してあります。
macro　fnam_in="misaki_gothic_2nd";
適切なファイル名に変更してください。

出力ファイル名：

fontjp_gen_mif_out.txtで出力します。
出力後、所望のファイル名(fnjp_rom_8kw.mif等)にリネームしてください。

謝辞：しっかり第二水準までカバーした極小フォントを提供してくださっている「Little Limit」の作者(門真なむ)様に感謝いたします。

完成したデザイン

　前節で完成させたFONTJPユニットを含む、MCOC115JP0408のデザインデータを以下リンクよりダウンロード可能です。FPGAボードへの書き込み手順はこちらを参照してください。

　以下に、コンパイル(論理合成・配置配線)結果をまとめておきます。

MCOC_JP.al (MCOC115JP0408)
コンパイル時間：　約4.5分

LUT数：　7,024個　(最大19,600個)

F/F数：　2,135個　(最大19,600個)
9KビットRAMマクロ数：　58個　(最大64個)

1Kバイト分のUART8N1ユニット受信バッファ用FIFOマクロで1個使用。
64Kバイト分のFONTJPユニットフォントROM用ROMマクロで57個使用。

32KビットRAMマクロ数：　3個　(最大16個)

4Kバイト分の命令ROM用RAMマクロで1個使用。
8Kバイト分のデータRAM用RAMマクロで2個使用。

DSPマクロ数：　1個　(最大29個)

MULC16の乗算器で1個使用。

タイミング解析(STA)結果：

Max Freq：　30.207MHz

Setup Slack：　6.895ns　(MET)
Hold Slack：　0.347ns　(MET)

確認時のクリティカルパスは、CPUステートコードレジスタから、汎用レジスタ、Aバス出力、乗算コプロセッサ、Cバスと抜けて、バンク3の汎用レジスタr1へ到達するパス(真パス)。
タイミングはメットしており、問題なし。

　FONTJPユニット単体でコンパイルしてみたところ、約1,000LUTと、かなり大きいことに驚きました。

オリジナル16ビットCPUコアMoscoviumが2,000LUT程(リンク先のデータから命令の追加等があるため、最終的には2,000LUT程)なので、CPUの半分強くらい。

半精度浮動小数演算ユニットH-FPU(約1,100LUT)と同じくらい。
と、いずれにしても大きい！

ブロック毎に分解してコンパイルしながら、論理規模を調べた(ブロック図を参照)。

FONTJPユニットのロジック部分合計＝619LUT

fnjpcod＝227LUT　……　S-JIS → 区点コード変換回路
fnjpdat＝389LUT　……　アフィン変換回路
fnjpcodブロックとfnjpdatブロックの大きさは、検討段階で既に許容済み。

fnjp_rom＝378LUT　……　犯人はこの子

ROMマクロfnjp_romが想定以上に大きいことが判った。

fnjp_romブロックは、TD IDEのIP Generatorで自動生成されたモジュールで、一切論理を追加していない。
どうやら、57個もの9KビットRAMマクロを、1個の64ビット×8KワードROMに見せかけるための周辺論理が大きい模様。

　FONTJPユニット単体で1,000LUTは、ちょっと大きいけど、上の様に避けられない理由であることが判ったので、これを許容します。

RAMマクロの消費数量

　RAMマクロの消費数量について追加検討しておきます。

　一応、最大仕様として漢字コード第二水準までカバーできる様に、64ビット×8KワードのフォントROMとしましたが、不要な文字コード領域は省いて、なるべく小さいROMに収める様な努力はすべきです(RAMマクロ数は有限なので)。

　TD IDEのIP Generatorは賢くて、ROMデータとして喰わせるMIFファイルの中身に0x0000等(※)の固定データが連続した場合、その領域にはRAMマクロを配置せず、ちゃんとしたデータが詰まった部分にだけ、RAMマクロを配置します。

※0x0000以外の固定データの扱いについては、当方では確認しておりません。

　この為、スクリプト(fontjp_gen_mif.olv)実行時、スクリプト先頭付近の変数max_datに所望のワード数を設定しておくと、最小限のRAMマクロだけを消費して回路を構成することが出来ます。

　有意義な選択肢は以下2通りです。

　　var　max_dat＝5*1024;　　// 5Kワード＝1区～54区(第一水準＋α)までカバー

　または、

　　var　max_dat＝8*1024;　　// 8Kワード＝1区～87区(第二水準)までカバー

　上の設定でMIFファイルを作ってコンパイル(論理合成・配置配線)した結果、使用した9KビットRAMマクロ数は、5Kワードで36個、8Kワードなら57個でした。MIFファイルを作り直すだけで、論理回路にも、ROMマクロにも、手を触れずにRAMマクロ数を削減することが出来るのがGoodです。
　RAMマクロは全部で64個まで使えるので、第二水準までカバーする8Kワードを選択しても、UART8N1等のI/Oユニットで使う分くらいは確保できます。もっと沢山のRAMマクロをFONTJPユニット以外のI/Oユニットで使いたい場合には、第一水準だけで諦める等の妥協をすると、占有使用するRAMマクロ数を減らすことが可能です。

小手調べの実験

　サンプルアプリケーションは、「#18-2　SPI通信する」で作成したプログラムのFONTJPユニット対応版です。FONTJPユニットからフォントデータを読み出して表示するように、ちょこっと改造するだけです。以下にソースファイルをリンクしておきます。

　　FONTJPユニット対応版プログラム：flash_mesg.asm

　デフォルトでは従来通り、7ビットASCII(英数)フォントを使うようになっていて、以下の修正をしてアセンブルすると、FONTJPユニットを使って日本語(漢字)フォントを表示できるようになります。

　　def　f,""　　// fontjp unit: not use="" / use="#"

　　　　↓下の様に変更すると、日本語フォントが表示できる。

　　def　f,"#"　　// fontjp unit: not use="" / use="#"

　デザインがMCOC115JP0408に変わるだけで、FPGAボードと8×8 LEDなどとの接続に変更有りませんので、こちらを参考に、実験を進めてください。
　あと、日本語(漢字)の文字列を送信する時、文字コードがS-JISである必要があるので、UTF-8になってしまうArduino IDEのシリアルモニタは使えません。Tera Termなど、S-JIS送信対応の通信ソフトウェアを使ってください。

　以下、実験中の様子です。

　8×8 LEDに「あ」と「花」を表示したところを撮影しました。上写真の方向で文字が読めるように、FONTJPユニットのアフィン変換機能を使って、時計回りに90°回転してあります(下コード)。

　　// fontjp setting
　　ldbiu　r0,fnjp_rot_1　　// 時計回りに90°回転
　　ldwi　r7,fnjpctl
　　stw　[r7],r0

　実は、本命の実験はSPI-TFTへ日本語表示する「次回」なので、今回の実験はあっさりと以上で終了します。

　次回、FPGAボード(Moscoviumマイコン)にSPI-TFTを接続して、日本語表示してみたいと思います。お楽しみに。