ライセンスチェックを入れて、Downloadボタンで入手。これで3.10.0.111.2_Diamond_x64.zipがダウンロードされた。解凍すると\3.10.0.111.2_Diamond_x64\3.10.0.111.2_Diamond_x64.exeが生成されるので実行。あとはウィザードに従ってインストールを進める。Micosystemインストールhttp://www.latticesemi.com/ja-JP/Products/DesignSoftwareAndIP/EmbeddedDesignSoftware/LatticeMicoSystemここのページから以下をクリック。WindowsLMS_1.0_for_Diamond3.10.exe.zipをダウンロードし、解凍後、インストールする。Cygwinインストールコマンドラインでいろいろ操作したいのでCygwinをインストールする。環境変数として以下を設定。/bin/bashまた、.bashrcの設定としてとりあえず以下。Starterが遅すぎるので、Veritakを使う。veritakwin384D.exeをインストール。エディタ(Gvim)インストールウィンドウ分割で複数ファイルを開いて、次回同じ構成で開く時、:mks!とやれば、Session.vimが生成される。Session.vimとやれば、複数ファイル開いた状態のまま復元出来る。directoryhttps://cygwin.com/ml/cygwin/2014-09/msg00164.htmlここ見るとこんな投稿があった。Deloyment実行しても、Warningは出なくなったが、.memのサイズが0KB・・・なぜだ。C:\lscc\diamond\3.4_x64\micosystem\utilities\bin_to_verilogConsoleタブのバーにこんなMSGが出た。v3.4.0.80)構造体、共用体を使って、SPIコアのレジスタへBYTEでもBITでも両方アクセス可能にしたい。ようにbitアクセスすると、目的のbitのみの操作が出来ない。上の波形で、一番上のled_out_regの値を逐一変えて、順番にレジスタアクセス動作を見ている。0;したのが、led_out_reg=19のところ。この波形の通り、bit操作するためには、まずは対象のアドレス(SPIコアControllレジスタ)の値を読みだして、その値を基準にして、操作対象のbitのみを変更している(と理解)。波形図では見えないが、SPI_DAT_Oはreg_controlのリード値=0x140が出ていた。Mico32は32bitデータバスなので、SEL[3:0]を使って、アクセス対象のBYTEを指定する。IEビットはbit8なので、SEL_I[1]のみがHになる。そのため、上の波形におけるSPI_SEL_Iは、fから2([1]のみHになった)へ値が変わっている。期待の動作は、reg_control[8]のみH->Lへ変化するはずが、[6]も変化してしまっている。MicoSystemが生成したwb_spi.vを見たら、SPI_SEL_Iは未接続。SEL_I制御が効いてないから、無関係のbitまで変更してしまった。見ると、MicoSystemで生成したSPIコアは、WISHBONEのSEL_I信号に未対応だって。Portsにしっかり書いてあるが。MicoSystemで生成されるRTLはWISHBONE完全準拠かと勝手に思ってた。wb_spi.vをSEL信号対応に修正しよう。Mico32を動かそうとしてる。メモリをXilinxからAlteraへ変えるだけで、確かこの前LEDチカチカ出来てたんだが、また動かなくなった。ソースの取り違いの可能性大だが、こんな場合に、どんな確認すれば良いのか考えてみる。外部リセットを入れてから、どこからSRAMが読まれ、どんな値が出たらOKなのか?を確認したい。objdumpでelfを解析してみる。(sp+36),r9:まずリセット直後に読まれるアドレスは0x00番地(のはず)。Webでぐぐっても0番地と書いてあるが、保有してるRTLの設定が本当にそうなってるのか?が確認出来てないから「はず」を付けた。<__startup>0番地から始まり、そこではbi命令で、_startupラベルの番地へ飛ぶ。__startupラベルは100番地を指していて、__startupの記述を見ると次のようになってた。60cmvhiって何だ?と思ったら以下を見る。ここにアセンブラの仕様がのってる。http://www.latticesemi.com/~/media/Documents/UserManuals/JL/LatticeMico32ProcessorReferenceManual34.pdf?document_id=50900少なくとも0番地からスタートする事は正しそうだし、hexファイルを見ても、0番地に下の命令がある。?命令メモリ単体でシミュレーションしても同じでwren=0、rden=1、addr=0、be=0xfにしても0番地が読まれない。目的と違って出力がレジスタ付になってる。詳細な論理は不明だが、単にレジスタ1段入ってたって、ずっと出力が変わらないって事は無いだろう、とは思いつつも、ここを出力レジスタ無にした。すると、リードデータが出力されるようになった。ソースでいうと、以下の設定。UNREGISTEREDなので出力レジスタ無って事らしい。RAMからその後段の論理が遠くなり、セットアップ違反になるケースを回避するための役目程度にしか考えてなかった。hexはちゃんとかどうか不明だが、見る限り先頭の100アドレスくらいは初期値として読まれている。SRAMからデータも出力されるようになった。SRAM単体のシミュレーションからMico32のシミュレーションに戻ってみると、命令アドレスは、0x000、0x004、0x008、0x100、0x104、0x108・・・と進んで行く。リセット解除後に、0x000に進むのは納得。ここがスタートアップルーチンの開始ポイントだから。<__interrupt>...次の0x004、0x008に行くのはなぜ?と思ったが、よくよく考えると以下が理由だよね。CPUなので、データは4バイト毎読まれる。・今シミュレーションで見ているのはSRAMへのアドレス入力。パイプライン内の命令フェッチステージの動作。branch)があるため、無条件分岐するのだが、パイプライン上の命令フェッチステージでは次から次への先取りしてアドレスを進める。・0x000のbi命令が、IF、DECODE、EXEとパイプラインを進むうちに分岐命令が実行され、0x008の次にbi命令で指定した0x100へジャンプした。どこかおかしいらしい。思ったら、.hexのパスが間違ってた。DWM200710付属のmemcvt.exeで.hex生成してから、hex内のアドレスをRubyで修正していて、修正版の.hexを使ってなかった事が原因でした。■.hexのアドレス数間違ってる?Veritakでこんなエラーが。module:tb_mico32_neek.uut.mico32.data_ram32_core.data_ram.altsyncram_component.m_non_arria10.altsyncram_inst;C:\user\onedrive\vm_share\de0_nano\mico32\rtlsim\rtl\altera_mf.v(48133)::Mico32命令メモリとして使ってるアルテラメモリIPの初期値ファイルを試しにQuartusで作ってみる。OKを押して値がセットされた。保存するとmifファイルが生成される。.hexしか使えないと思ってたが、.mifが使えるなら、その方が記述簡単そうだ。.mifを使う方向で再度、おさらい。・DWM200710付属memcvt.exeでelfから.mifを生成。・そこで生成された.mifは以下のフォーマットだった。IPは2048にしてた。IPをWord=1024に変更して、生成した.mifがそのまま読み込めるようにした。・Veritakで確認してみても、シミュレーション開始時エラー無く.mifが読めてる。address=800・・・)の原因は初期値ファイルのアドレスサイズと実際のRAM定義が違っていた模様。.elf結果では、以下だった。mainのかっこは全角<>にしてます。半角だとHTML記述?に関係して表示されなかったため。0x60c(main)と進む。・mainが配置されるべき0x60c=dec1548なので、生成したRAMのword=1024をこえてる。・.mifの中身を追うと、以下を発見出来る。00000183:379cffec;00000184:5b9b0008;00000185:5b9d0004;00000186:341b0014;00000187:b77cd800;00000188:78012000;00000189:38210000;0000018a:28210000;0000018b:5b61fffc;0000018c:78012000;0000018d:38210004;0000018e:34020000;これはobjdumpして確認出来るmain関数の最初と命令コードが全て一致。r2,0・.mifにおけるmain開始位置は0x183=dec387と分かった。387*4=1548であり、0x60c=dec1548と一致。・そういえばDWM200710付属のRTLは命令メモリアドレスは下位2bitを抜かしてRAMへ接続していた。下位2bitを抜かす事で、実際の命令アドレス信号の1/4サイズのRAMで対応させてると。■これでLEDチカチカが動いた!以上の事を踏まえ、system_top.v(Mico32のトップmodule)の以下を修正し、LEDチカチカ出来た。0Pagetop[LM32]gpio.vのPIO_DATAはどこから来る?mico32でLEDチカチカのRTLシミュレーションは動く。mico32でLEDチカチカのGATEシミュレーションや実機は動かない。FPGAトップ/LEDPIO_OUTとデータが出てくる。GPIO_DAT_I_switch[ipd_idx];のみ。それ以外は0入力なので、値はGPIO_DAT_I_switchから来るはず。RTLシミュレーションではGPIO_DAT_I_switch=0のまま。PIO_DATAはソフトで書いた即値に変化してる。