[LM32]トラブルシューティング
[MSB] Couldn't compute FAST_CWD pointer.
micosystemのソフト（C/C++画面）のビルド時にこれが出たら、LMS画面の方に切り替えて、
何かしら変更して保存する。（例えば変更箇所なければ、一度変えて保存、戻して保存、という方法）
Generate AddressからRun Generatorまで実行し直す。それからビルドし直すとエラー無くビルド出来るようになった。
（Windows 10の場合）
しかし、Windows 8.1でも同様の方法で解決していたが、ある時から解決しなくなった。
8.1ではCygwinの問題だという指摘を掲示板で見つけた。
make all
0 [main] make 28276 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to
the public mailing list cygwin@cygwin.com
make[1]: Entering directory `/cygdrive/c/user/work/quartus/DE2-115/micosystem/sw/ether/ether/Debug'
make[1]: Leaving directory `/cygdrive/c/user/work/quartus/DE2-115/micosystem/sw/ether/ether/Debug'
[Cygwin] objdumpが効かない
Windows 10上のCygwin64から以下いずれも実行しても何も返って来ないで終わる。
/cygdrive/c/lscc/diamond/3.10_x64/micosystem/gtools/lm32/bin/lm32-elf-objdump.exe -d ether.elf
/cygdrive/c/lscc/diamond/3.10_x64/micosystem/gtools/lm32/lm32-elf/bin/objdump.exe -d ether.elf
コマンドプロンプトから実行すると、以下を言われる。
cygwin1.dllが見つからないため、コードの実行を続行できません。プログラムを再インストール
すると、この問題が解決する可能性があります。
あ、でもこれは当たり前か。Cygwin用のプログラムobjdumpをコマンドプロンプトで実行しようとするのがダメか。
さらに試してみたら、
C:\cygwin64\Cygwin.bat
を使ってたために、この症状が起こったが、
C:\cygwin\Cygwin.bat
を使えば、正常に実行出来た。
Lattice DiamondインストールDIRのGNUツールは、Cygwin 32bit用実行ファイルという事だった。
[Cygwin] gcc: error trying to exec 'cc1': execvp: No such file or directory
memcvt.exeが効かなかったので、以前cygwin64bitのgccで生成したものだからと考え、
再度ビルドしてみたらこのエラー。
ごめんなさい、単にgccのパスを以下に間違えてただけでした。
/cygdrive/c/lscc/diamond/3.10_x64/micosystem/gtools/lm32/lm32-elf/bin/gcc
正しくは/bin/gccでした。これでエラー消えた。
[Cygwin] /tmp/ccmUUqJZ.s:2: Fatal error: unrecognized .section attribute: want a,w,x,M,S,G,T
/bin/gcc memcvt_171125.c -o memcvt_171125.exe
上に続き、/bin/gccでビルドしようとしたらこのエラー。
/tmp/ccmUUqJZ.s: Assembler messages:
/tmp/ccmUUqJZ.s:2: Fatal error: unrecognized .section attribute: want a,w,x,M,S,G,T
原因は$PATHの前に、
/cygdrive/c/lscc/diamond/3.10_x64/micosystem/gtools/lm32/lm32-elf/bin
を追加した事が原因だった。
export PATH=/cygdrive/c/lscc/diamond/3.10_x64/micosystem/gtools/lm32/lm32-elf/bin:$PATH:/cygdrive/c/user/onedrive/user/app/vim74-kaoriya-win64:/cygdrive/c/user/tool/lattice/memcvt:/cygdrive/c/lscc/diamond/3.10_x64/micosystem/gtools/lm32/bin
memcvt_171125.cをビルドする時は以下に戻す事で成功した。
export PATH=$PATH:/cygdrive/c/user/onedrive/user/app/vim74-kaoriya-win64:/cygdrive/c/user/tool/lattice/memcvt:/cygdrive/c/lscc/diamond/3.10_x64/micosystem/gtools/lm32/bin
inst_ram_data.ver Access Error accessing address=1000 min_address=fff max_address=0
In module:tb_DE2_115.uut.ether1.LM32.cpu.instruction_unit.ram.ram.m_default.altsyncram_inst;
[Cygwin] C:/lscc/diamond/3.10_x64/micosystem/gtools/lm32/libexec/gcc/lm32-elf/4.3.0/cc1.exe: error while loading shared libraries: cyggmp-3.dll: cannot open shared object file: No such file or directory
Cygwin32bit環境で以下を実行した際に出たエラー。
lm32-elf-gcc -c $src_name.c
[Quartus] object "GSR_INST" is not declared.
Error (10161): Verilog HDL error at DP16KD.v(157): object "GSR_INST" is not declared. Verify the object name is correct. If the name is correct, declare the object.
Error (10161): Verilog HDL error at DP16KD.v(158): object "PUR_INST" is not declared. Verify the object name is correct. If the name is correct, declare the object.
PUR PUR_INST (.PUR(1'b1)); ＞ 追加
GSR GSR_INST (.GSR(1'b1)); ＞ 追加
tri1 GSR_sig = GSR_INST.GSRNET;
tri1 PUR_sig = PUR_INST.PURNET;
[Quartus] Error (10200): Verilog HDL Conditional Statement error at wb_spi.v(338): cannot match operand(s) ...
Error (10200): Verilog HDL Conditional Statement error at wb_spi.v(338): cannot match operand(s) in the condition to the corresponding edges in the enclosing event control of the always construct
always @(posedge CLK_I or posedge RST_I)
if (RST_I || (c_status == ST_IDLE)) ＞ ここがエラー箇所
clock_cnt <= 0;
else if (clock_cnt == CLOCK_SEL)
clock_cnt <= 0;
else
clock_cnt <= clock_cnt + 1;
always @(posedge CLK_I or posedge RST_I)
if (RST_I)
clock_cnt <= 0;
else if (c_status == ST_IDLE) ＞ RST_Iとは別にif文追加した。
clock_cnt <= 0;
else if (clock_cnt == CLOCK_SEL)
clock_cnt <= 0;
else
clock_cnt <= clock_cnt + 1;
[Veritak] ether_top.vo::Error: CLOCK2_50~input.bus_holdパラメータが見つかりません
Quartus生成ネットリストをVeritakでコンパイルするとこのエラー。
C:\user\work\quartus\DE2-115\ether\soc\simulation\custom\ether_top.vo(113291)::Error: CLOCK2_50~input.bus_holdパラメータが見つかりません
C/intelFPGA_lite/17.0/quartus/eda/sim_lib/altera_primitives.v
C/intelFPGA_lite/17.0/quartus/eda/sim_lib/altera_mf.v
C/intelFPGA_lite/17.0/quartus/eda/sim_lib/cycloneiv_atoms.v ＞ 後述するが、ivではなく、iveが正解だった。
220_model.vじゃなく、altera_primitives.vを追加したらエラーが消えて、今度は以下が出た。
../../../../../../intelFPGA_lite/17.1/quartus/eda/sim_lib/altera_primitives.v(34):: Error: Macro name=begin_keywords is not defined.
../../../../../../intelFPGA_lite/17.1/quartus/eda/sim_lib/altera_primitives.v(44):: Error: Macro name=end_keywords is not defined.
../../../../../../intelFPGA_lite/17.1/quartus/eda/sim_lib/altera_primitives.v(84):: Error: Macro name=begin_keywords is not defined.
../../../../../../intelFPGA_lite/17.1/quartus/eda/sim_lib/altera_primitives.v(93):: Error: Macro name=end_keywords is not defined.
エラーの箇所は以下。
//if simulator dees not support begin_keywords/end_keywords pragmas then define macro SKIP_KEYWORDS_PRAGMA to skip them.
//pragmas are required to prevent "global" from being treated as a systemverilog 1800-2009 keyword
`ifndef SKIP_KEYWORDS_PRAGMA
`begin_keywords "1364-1995"
`endif
altera_primitives.vのコメント通り、以下を宣言してみる。
tb_ether_top.v内に追加
// 2017.12.29 to prevent error of altera_primitives.v for veritak
`define SKIP_KEYWORDS_PRAGMA
しかし、テストベンチに追記しても、下位モジュールに適用されないのでエラーは出た。
なので、Veritakで以下設定を行う。
Veritak ＞ Verilogプロジェクト ＞ プロジェクト設定 ＞ Define Propagationの設定を変える。
＞ 現状＝Per File → 変更後＝Throughout Project
すると、SKIP_KEYWORDS_PRAGMA関連エラーが消えた代わりに、元のエラーが出た。
つまり、altera_primitives.vが対策ではなかったようだ。
Loading vpi
スコープを生成中です。
C:\user\work\quartus\DE2-115\ether\soc\simulation\custom\ether_top.vo(113291)::Error: CLOCK2_50~input.bus_holdパラメータが見つかりません
C:\user\work\quartus\DE2-115\ether\soc\simulation\custom\ether_top.vo(113292)::Error: CLOCK2_50~input.simulate_z_asパラメータが見つかりません
：
ネットリストでエラー箇所を見てみる。
// Location: LCCOMB_X112_Y36_N24
cycloneive_lcell_comb \led_cnt[9]~41 ( ＞ cycloneivじゃなくて、cycloneiveだった。
：
// synopsys translate_off
defparam \led_cnt[9]~41 .lut_mask = 16'hC30C; ＞ このdefparamはcycloneive_lcell_comb宣言があればエラーにならない。
defparam \led_cnt[9]~41 .sum_lutc_input = "cin";
// synopsys translate_on
結論
以下条件でネットリストでゲート（GATE）シミュレーションが出来た。
＜読み込むファイル＞
GSR.v
PUR.v
tb_ether_top.v
simulation/custom/ether_top.vo ＞ simulation/custom/ether_top.sdo
C/intelFPGA_lite/17.0/quartus/eda/sim_lib/altera_primitives.v
C/intelFPGA_lite/17.0/quartus/eda/sim_lib/altera_mf.v
C/intelFPGA_lite/17.0/quartus/eda/sim_lib/cycloneive_atoms.v
＜設定＞
Veritak ＞ Verilogプロジェクト ＞ プロジェクト設定 ＞ Compile Mode = Altera SDF
＜準備＞
simulation/custom/*.sdo をVeritakのプロジェクトファイル（＝実行場所）に保存する。
＜結果＞
SDFを実行場所に保存する前はこれ。
ERROR: can not open $sdf_annotate
ちゃんとSDF保存したらエラーが消えて、以下が出た。
------------- シミュレーションを開始します。--------------------
SDF: timing check[0] HOLD[Spec.186ps] FAILS at simtime 87ps <- 87ps: posedge tb_ether_top.uut.ether1|LM32|cpu|load_store_unit|irom_select_m.clk ==> tb_ether_top.uut.ether1|LM32|cpu|load_store_unit|irom_select_m.d
SDF: timing check[0] HOLD[Spec.186ps] FAILS at simtime 87ps <- 87ps: posedge tb_ether_top.uut.ether1|LM32|cpu|load_store_unit|d_we_o.clk ==> tb_ether_top.uut.ether1|LM32|cpu|load_store_unit|d_we_o.d
SDF: timing check[0] HOLD[Spec.186ps] FAILS at simtime 87ps <- 87ps: posedge tb_ether_top.uut.ether1|spi|wait_one_tick_done.clk ==> tb_ether_top.uut.ether1|spi|wait_one_tick_done.d
[Quartus] Mico32のゲート（GATE）シミュレーションが動かない
動く、の定義は、ソフトでLEDがチカチカすること。HWで組んだカウンタではチカチカしてる。
実験１
以前2014/11に動かなかったブログの後に、以下を自分でやってた。
[Quartus]グローバルクロック設定と確認方法
http://bobgosso.blog13.fc2.com/blog-entry-370.html
でも今回はこれだけでは動かず。
[Quartus] Mico32のデータ用SRAMがマッピングされない？
Quartus ＞ Analysis & Synthesis ＞ View Report ＞ LPM Parameter Settings ＞ RAMs
＞ asyncram Parameter Settings by Entity instance
＞ これで見ると、以下２つのRAMが表示されている。
ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_instruction_unit:instruction_unit|pmi_ram_dp_true_altera:ram|altsyncram:ram
ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|pmi_ram_dp_true_altera:ram|altsyncram:ram
＞ load_store_unit内のデータ用RAMも認識されている。
Quartus ＞ Fitter ＞ View Report ＞ Resource Section ＞ RAM Summary
ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_instruction_unit:instruction_unit|pmi_ram_dp_true_altera:ram|altsyncram:ram|altsyncram_bni1:auto_generated|ALTSYNCRAM
＞ ここでは、instruction_unit内の命令用RAMしか認識されてない。
Fitterレポート（*.fit.rpt）には以下のようにinstruction_unitのみRAMになってる。
; Fitter RAM Summary
; Name ; Type ; Mode ; Clock Mode ; Port A Depth ; Port A Width ; Port B Depth ; Port B Width ; Port A Input Registers ; Port A Output Registers ; Port B Input Registers ; Port B Output Registers ; Size ; Implementation Port A Depth ; Implementation Port A Width ; Implementation Port B Depth ; Implementation Port B Width ; Implementation Bits ; M9Ks ; MIF ; Location ; Mixed Width RDW Mode ; Port A RDW Mode ; Port B RDW Mode ; ECC Mode ; ECC Pipeline Registers ; Fits in MLABs ;
; ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_instruction_unit:instruction_unit|pmi_ram_dp_true_altera:ram|altsyncram:ram|altsyncram_hni1:auto_generated|ALTSYNCRAM ; AUTO ; True Dual Port ; Single Clock ; 2048 ; 32 ; 2048 ; 32 ; yes ; no ; yes ; no ; 65536 ; 2048 ; 32 ; 2048 ; 32 ; 65536 ; 8 ; inst_ram_data.mif ; M9K_X51_Y35_N0, M9K_X64_Y35_N0, M9K_X64_Y32_N0, M9K_X51_Y36_N0, M9K_X64_Y33_N0, M9K_X51_Y33_N0, M9K_X51_Y37_N0, M9K_X51_Y34_N0 ; Don't care ; New data with NBE Read ; New data with NBE Read ; Off ; No ; No - Unknown ;
Note: Fitter may spread logical memories into multiple blocks to improve timing. The actual required RAM blocks can be found in the Fitter Resource Usage section.
Mapレポート（*.map.rpt）を見ると、lm32_load_store_unitのRAMの扱われ方がinstruction_unitのRAMとは違うようだ。
Warning (14284): Synthesized away the following node(s):
Warning (14285): Synthesized away the following RAM node(s):
Warning (14320): Synthesized away node "ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|pmi_ram_dp_true_altera:ram|altsyncram:ram|altsyncram_dmi1:auto_generated|q_a[0]" File: C:/user/work/quartus/DE2-115/ether/soc/db/altsyncram_dmi1.tdf Line: 43
Warning (14320): Synthesized away node "ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|pmi_ram_dp_true_altera:ram|altsyncram:ram|altsyncram_dmi1:auto_generated|q_a[1]" File: C:/user/work/quartus/DE2-115/ether/soc/db/altsyncram_dmi1.tdf Line: 79
：
Warning (14320): Synthesized away node "ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|pmi_ram_dp_true_altera:ram|altsyncram:ram|altsyncram_dmi1:auto_generated|q_a[31]" File: C:/user/work/quartus/DE2-115/ether/soc/db/altsyncram_dmi1.tdf Line: 1159
実機でLM32が動かない原因（これが動かない原因か不明だが、データ用RAMがマッピングされない事）は、
`define SIMULATION を宣言してるのが問題か？
以前どんな判断したか忘れたが、SIMULATIONをdefineしてた。
FPGAにインプリするためには、これdefineしてはダメなのでは？
[Quartus] Warning (xx): Synthesized away the following RAM node(s)
上に書いた流れでデバッグしてみた。
QuartusのAdvanced Settings(Synthesis)やAdvanced Settings(Fitter)のオプションを見直したが、これでは直らず。
以下のコメントをヒントに、load_store_unitのRAM出力をFPGAトップまで引き上げて信号出してみた。
結果、Synthesized awayのWarningは消えた！
https://www.alteraforum.com/forum/showthread.php?t=21882
A signal is synthesized away, if it's not used in the design, more exactly, if no FPGA output signal depends on it.
pmi_ram_dp_true_altera ＞ Lattice用RAMからAltera用RAMへ個人的に変えてる
#(
// ----- Parameters -------
.pmi_family (`LATTICE_FAMILY),
.pmi_addr_depth_a (`CFG_DRAM_LIMIT/4-`CFG_DRAM_BASE_ADDRESS/4+1),
.pmi_addr_width_a (clogb2_v1(`CFG_DRAM_LIMIT/4-`CFG_DRAM_BASE_ADDRESS/4+1)),
.pmi_data_width_a (`LM32_WORD_WIDTH),
.pmi_addr_depth_b (`CFG_DRAM_LIMIT/4-`CFG_DRAM_BASE_ADDRESS/4+1),
.pmi_addr_width_b (clogb2_v1(`CFG_DRAM_LIMIT/4-`CFG_DRAM_BASE_ADDRESS/4+1)),
.pmi_data_width_b (`LM32_WORD_WIDTH),
.pmi_regmode_a ("noreg"),
.pmi_regmode_b ("noreg"),
.pmi_gsr ("enable"),
.pmi_resetmode ("sync"),
.pmi_init_file (`CFG_DRAM_INIT_FILE),
.pmi_init_file_format (`CFG_DRAM_INIT_FILE_FORMAT),
.module_type ("pmi_ram_dp_true")
)
ram (
.ClockA (clk_i),
：
.QA (dram_data_out),
.QB (load_store_unit_ram_out) ＞ 元は接続無しだったが、この信号に接続して上の階層へ引き出す。
);
lm32_load_store_unit.v ＞ 上の階層へ引き出す
lm32_cpu.v ＞ 上の階層へ引き出す
ether.v ＞ 上の階層へ引き出す（これがMico System Builderで生成するRTLトップ）
ether_top.v ＞ ここがFPGAトップ。以下のように、てきとーに信号をLEDR[1]（FPGA出力）へ出してる。
assign LEDR[1] = !load_store_unit_ram_out ;
[MSB] 割り込みハンドラに飛ばない
しょーもない話だけど、MSBで構成変更したりして、
A ＝ Generate Base Address
I ＝ Generate IRQ
D ＝ Run DRC
G ＝ Run Generator
とやった時、Generatorでファイルが生成されない時は、
コンソールにばらばらと表示されずに、1行とかで終わる時がある。
これはたぶんファイルを生成しようと思ったら上書き出来ずに失敗した時とかだと思う。
対策として、既存のcomponentを改名して、一からcomponentフォルダを作らせるとちゃんとGeneratorが走る。
これをさぼってて、RTLが更新されなかった事が原因で、割り込みハンドラにジャンプしない原因になったらしい。
[Quartus] lpm_mltもSynthesized away nodeになった
Warning (14284): Synthesized away the following node(s):
Warning (14285): Synthesized away the following DSP element node(s):
Warning (14320): Synthesized away node "ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_multiplier:multiplier|lpm_mult:Mult0|mult_7dt:auto_generated|mac_mult7" File: C:/user/work/quartus/DE2-115/ether/soc/db/mult_7dt.tdf Line: 66
Warning (14320): Synthesized away node "ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_multiplier:multiplier|lpm_mult:Mult0|mult_7dt:auto_generated|mac_out8" File: C:/user/work/quartus/DE2-115/ether/soc/db/mult_7dt.tdf Line: 90
[Quartus] sysresetが内部FF駆動でGlobal Signalになってない？
＜ether.vの中身＞
reg [2:0] counter;
wire sys_reset = !counter[2];
Mico System Builderで生成されたRTLトップ見ると、リセット信号は内部カウンタから生成されてる。
これがあると、Global Signalとして扱われるのか？
Quartus ＞ Fitter ＞ View Report ＞ Resource Section ＞ Global & Other Fast Signals
ここでGlobal Signalを調べられる。
CLOCK_50 Location=PIN_Y2 Fan-Out＝2107
KEY[0] Location=PIN_M23 Fan-Out＝2092
Fan-Outが2000以上あるから、counterというFF（FlipFlop）を超えてGlobal Signalが適用されてるみたい。
[Quartus] LM32動かない箇所シミュレーション
instruntion_unit/ramはRTLと同じ動きしてるように見えるが、load_store_unit/ramは同じでない。
しかもPOATB/WEは信号が消えてる。
ネットリストでの信号名
◆ether1|LM32|cpu|load_store_unit{ramの信号
// Location: M9K_X51_Y25_N0
cycloneive_ram_block \ether1|LM32|cpu|load_store_unit|ram|ram|auto_generated|ram_block1a28 (
.portawe(gnd),
.portare(vcc),
.portaaddrstall(gnd),
.portbwe(gnd), ＞ PORTBのWEはなぜGNDになってる？
.portbre(vcc),
.portbaddrstall(gnd),
.clk0(\CLOCK_50~inputclkctrl_outclk ),
.clk1(\CLOCK_50~inputclkctrl_outclk ),
.ena0(\ether1|LM32|cpu|stall_x~3_combout ),
.ena1(\ether1|LM32|cpu|stall_m~combout ),
.ena2(vcc),
.ena3(vcc),
.clr0(gnd),
.clr1(gnd),
.portadatain({\~GND~combout ,\~GND~combout ,\~GND~combout ,\~GND~combout }),
.portaaddr({\~GND~combout ,\~GND~combout ,\~GND~combout ,\~GND~combout ,\~GND~combout ,\~GND~combout ,\~GND~combout ,\~GND~combout ,\~GND~combout ,\~GND~combout ,\~GND~combout }),
.portabyteenamasks(1'b1),
.portbdatain({ \ether1|LM32|cpu|load_store_unit|dram_store_data_m[31]~63_combout , \ether1|LM32|cpu|load_store_unit|dram_store_data_m[30]~61_combout , \ether1|LM32|cpu|load_store_unit|dram_store_data_m[29]~59_combout , \ether1|LM32|cpu|load_store_unit|dram_store_data_m[28]~57_combout }),
.portbaddr({\ether1|LM32|cpu|operand_m [12],\ether1|LM32|cpu|operand_m [11],\ether1|LM32|cpu|operand_m [10],\ether1|LM32|cpu|operand_m [9],\ether1|LM32|cpu|operand_m [8],\ether1|LM32|cpu|operand_m [7],\ether1|LM32|cpu|operand_m [6],\ether1|LM32|cpu|operand_m [5],\ether1|LM32|cpu|operand_m [4],
\ether1|LM32|cpu|operand_m [3],\ether1|LM32|cpu|operand_m [2]}),
.portbbyteenamasks(1'b1),
.devclrn(devclrn),
.devpor(devpor),
.portadataout(\ether1|LM32|cpu|load_store_unit|ram|ram|auto_generated|ram_block1a28_PORTADATAOUT_bus ),
.portbdataout(\ether1|LM32|cpu|load_store_unit|ram|ram|auto_generated|ram_block1a28_PORTBDATAOUT_bus ));
portbweがGND固定になってる。RTLでは信号入れてるのに。動いてない、と判断されたのか？
.WrA (`FALSE),
.WrB (store_q_m & dram_select_m),
; Registers Removed During Synthesis
; Register name ; Reason for Removal
; ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|d_stb_o ; Merged with ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|d_cyc_o ;
; ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|dram_select_m ; Stuck at GND due to stuck port data_in ;
; ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|wb_select_m ; Stuck at GND due to stuck port data_in ;
; ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|wb_load_complete ; Lost fanout ;
; ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|byte_enable_m[1] ; Merged with ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|byte_enable_m[0] ;
; ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|size_m[1] ; Merged with ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|byte_enable_m[2] ;
; Removed Registers Triggering Further Register Optimizations
; Register name ; Reason for Removal ; Registers Removed due to This Register ;
; ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|dram_select_m ; Stuck at GND ; ether:ether1|lm32_top:LM32|lm32_cpu:cpu|lm32_load_store_unit:load_store_unit|wb_load_complete ;
; due to stuck port data_in ;
load_store_unitのRAM/portbweがGNDにスタックされているので、論理が動いてないからかと思い、
FPGA出力まで引き出して見たが変わらず。
load_store_unit|dram_select_m ; Stuck at GND due to stuck port data_in
よくよく見ると、RAM/WｒBに入力されているstore_q_m & dram_select_mの方ではなくて、
「due to stuck port data_in」って、WrBがDisable？
load_store_unit.ramのパラメータを調べると、
が抜けてた。これが原因か？defparam ram.width_byteena_a= 1;
defparam ram.width_byteenb_a= 1;
bit幅はてきとーに1bitにした。
：
試すが、これでもLM32ソフトによるLEDチカチカは動作せず。
シミュレーションだと意図した動きになってるのに、なぜかQuartusでDE2-115にインプリすると、Mico32のプログラムが動作しない。
[LM32] system_conf.v LATTICE_FAMILYは"EC"でなく"SC"を使え。
ソース追ってないので理由は不明だが、system_conf.vで
`define LATTICE_FAMILY "EC"
から
`define LATTICE_FAMILY "SC"
にしたら、Mico32のプログラムによるLEDチカチカした！
ちなみにsystem.confの最初の数行は以下設定。
//`define LATTICE_FAMILY "EC"
// 2018.1.4
`define LATTICE_FAMILY "SC"
`define LATTICE_FAMILY_EC
`define LATTICE_DEVICE "All"
`ifndef SYSTEM_CONF
`define SYSTEM_CONF
：
変更した箇所として、厳密にはLATTICE_FAMILYをSCにしたら、
components/uart_core/rtl/verilog/rxcver_fifo.v
components/uart_core/rtl/verilog/txcver_fifo.v
で使ってるpmi_fifo_dcが無いと言われ、同等回路をQuartusのIP CatalogでFIFO作った（中身はdcfifo）。
1.85us付近からLM32のINST RAMアドレス0x1a4から0xb4のループになる
問題？が起こる前にやった事
ソースの置き場所をgitへまとめた後、DE2-115でMico32の動作を確認しようとしたら、
IROM=BASE 0x0, Size 0x2000、 DRAM=BASE 0x2000, Size 0x2000
ではelfがオーバーした。なので、
IROM=BASE 0x0, Size 0x4000、 DRAM=BASE 0x4000, Size 0x4000
に変えた。
症状
ループとなるアドレスは、
tb_ether_top.uut.ether1.LM32.cpu.instruction_unit.ram.ram.address_a
の信号でいうと、0x69から0x6dの間。
1アドレス32bit（4バイト）のため、4倍すると、0x1a4から0xb4になる。
elfからobjdumpした中身で見ると、このアドレスの期間は以下になる。
1a0: 38 63 44 7c ori r3,r3,0x447c
000001a4 <.ClearBSS>:
1a4: 44 23 00 04 be r1,r3,1b4 <.CallConstructor>
1a8: 58 20 00 00 sw (r1+0),r0
1ac: 34 21 00 04 addi r1,r1,4
1b0: e3 ff ff fd bi 1a4 <.ClearBSS>
000001b4 <.CallConstructor>:
1b4: 78 04 00 00 mvhi r4,0x0
何やらmain関数に行く前にループしてるような感じ。
解決するまでにやった事
・system_conf.vを古い方を読んでいた。不要なsystem_conf.vを削除して１つだけにした。さらに以下。
＞ LATTICE_FAMILYは"SC"になってるので問題なし。
＞ `define CFG_IROM_LIMIT 32'h1fff から 32'h3fff へ変更した。
＞ `define CFG_DRAM_BASE_ADDRESS 32'h2000 から 32'h4000 へ変更した。
＞ `define CFG_DRAM_LIMIT 32'h3fff から 32'h7fff へ変更した。
・IROMとDRAMのアドレスを12ビット（4096バイト）にしたので、Verilogソースもアドレス12ビットになっているか確認した。
・memory.def を修正。
＞ .rdata 0x00002000: { のアドレスを 0x00004000 に変更した。
＞ スタックポインタの . = 0x00004000 + (1024*8) - 4; の加える値を (2048*8) に変更した。
・シミュレーションを175usまで進めたら、main関数の先頭コードまで進んだ。
IROM/DRAMサイズを変えた事で、上記の変更は必要になったが、加えて、シミュレーション時間を175usまで
待たずに、途中の動きを見て、勝手に問題視したようだ。
main関数まで進めた設定で、1.85us付近を見ると、やはり.address_a信号は、
1.8us付近から、0x69から0x6dの間のループが始まり、17.17us付近まで続いていた。
なのでこの動きは全く問題無いみたい。
2022.6.7 命令メモリ（lm32_instruction_unit.v内）からデータが出て来ない
system_conf.v内で以下ファイルは存在するか？
`define CFG_IROM_INIT_FILE_FORMAT "hex"
`define CFG_IROM_INIT_FILE "inst_ram_data.hex"
`define CFG_DRAM_INIT_FILE_FORMAT "hex"
`define CFG_DRAM_INIT_FILE "data_ram_data.hex"
ベースアドレスは、ビルドした際のstartup.sやmemory.def、さらにはmemcvtプログラム設定と一致してるか？
`define CFG_IROM_BASE_ADDRESS 32'h0
`define CFG_DRAM_BASE_ADDRESS 32'h2000
micosystem.exeで生成されるcomponent/lm32_top/rtl/verilog/lm32_include_all.v内でpmi_def.vが読まれてないか？
`ifndef SIMULATION
`include "pmi_def.v" → SIMULATION宣言が無いとpmi_def.vが読まれるが、これは中身の論理が無い箱なのでveritakコンパイル通ってしまうが、中身の動作が無く、信号がzになったりする問題発生。
`endif
instruction_unitとload_store_unitの中で、pmi_ram_dp_trueを使ってないか？
これを使うとなぜかveritakシミュレーションがスタートしない（止まるというより最初から進まない）。
過去対策したようで、代わりに自作したpmi_ram_dp_true_altera.vを使うとシミュレーションが進むようになった。
テストベンチ内のtimescale設定が無くて、例えば生成したクロックがps単位の高速なパルスになってないか？
そうするとおそらくPLLとか一部の回路は動作しないはず。
2022.6.13 UART入力割込でinterrupt_handlerに飛ばない
RTLシミュレーションでLattice Mico32のinterrupt_nはアサートされている事は確認してる。
一度Cソースビルド前にclean projectしてみたら、生成されたsw.elfの各セクション容量に違いが出たので、これはこれで原因の１つと思う。
→ clean project（クリーンプロジェクト）する前は、.dataセクションなどデータメモリの値がALLゼロだった。これは明らかにおかしい。
それでもまだ割込入ると、crt0からmainへ飛んでしまう。なぜ？
