デザイン2周目 - .mjtの日記復帰計画

(mieru-PCと名称が紛らわしいので名前変えた)
やっぱり、先にサイクル正確なシミュレータを作るべきだった。。yuniDSPはFPGA(Spartan-3)上で設計しているので、デバッグ用回路の有無でかなり動作速度が変わってしまう*1。
FPGAは特電のSpartan-6ボードが比較的安価(4万円弱)なので乗り換えを検討中。

http://www.tokudenkairo.co.jp/sp6brd.html

バス

現在のバスは2〜8192ワードの任意長のデータを、DDR-DRAMとBRAM(モジュールローカルストア)の間でやりとりできる*2。
しかし、実際のアプリケーションでは1/2/4/8/16/32/64/...のような選択式でも問題ないケースが多く、このようにすることで制御線の本数を減らすことが出来る。
制御線の本数はFPGAでは大きな問題にならない(配線層がこのような配線に最適化されている)が、かっこ悪い。
やること :

バスオペレーションの実態調査。現在は本格的なサンプルコードを書いてないので、それを実機向けでなくシミュレータ向けに作る。
バスサイズの検討
- 現在は、2ワード(= 32bits)を同時に転送している。これをWishboneのように8bitにしたり、逆にもっと広くすることは魅力的かもしれない。
バスコントローラを生成可能にする
- いまのところ、手書きのバスコントローラは8つまでのモジュールを接続できる。これをスクリプトなりなんなりで生成して制限なしにする。
- VHDLのgenerateで対応できるけど地味に面倒なので。。
シグナリングの改善。今は3clk(REQ-ACK-CLR)掛かる。

ワード巾を狭めるとシグナルとして送れる値が少なくなるという罠が有るのか。。
重大な問題を忘れてた : 大きなブロックサイズを許可すると、CRTCやUSBのようにリアルタイムな転送が必要なケースで困る(転送を中断できないため)。今はUSB1しか実装していないので、問題は表面化していないが。。

ペリフェラルモジュール

CRTCは信頼できるけど、(相当にバス帯域を食うため)細かい検証が面倒になるのでしばらく無効にする。
やること :

USBの送信は何か間違っているのでリワーク
USBの受信(FS)は機能している
LSは完全に間違っているのでリワークが必要
CRCはnahitafuさんの所からパクっている( http://nahitafu.cocolog-nifty.com/nahitafu/2007/01/crc_91af.html )のでどうにかする
UARTは信頼できるけどボーレート変えられないのが不便

core

coreに関しては完全に作り直すのでなんとも言えない。知見としては、

レジスタが少ないとグラフィックスアプリケーションが書きづらい
BRAMをレジスタとして使う上手い方法があると良いかも知れない
- というか、BRAMへのアクセスがLDとSTしか出来ないおかげでコード密度が低いと思われる
- たぶんアドレスジェネレータを搭載する必要がある
パイプラインを先に正確に設計しないとデバッグで死ぬ

でも元のコンセプトが"レガシーなDSPに現代的なペリフェラルを付けると何が出来るのか"*3という遊びなので、アドレスジェネレータとかを付けてシステムを複雑にしてしまうのは抵抗がある。。
あと数表はROMで持つしかないかなぁ。。sin/cosテーブルの転送でも地味にバスの時間を食うので、ステージ間のプログラム入れ替えでデータを共有できるデザインにする必要があって面倒。もちろんコンパイラで面倒を見るのが一番賢いけど。