about the gen.scala and ifetch

[duanjiulon]

Hi, recently I have been using your nax gen.scala file to generate a core with three axi interfaces, ibus，dbus，pbus， After connecting another axicrossbar to an axi system, the anchipram was set to 0 and the DDR address was 0x40000000. The following problem occurred during axi debugging:

1. By loading the address of 0x0 through openocd+gdb, single step debugging can be successfully performed
2. When loading the DDR address containing 0x40000000 through openocd+gdb, the following error message will appear

Loading section .init, size 0x6e lma 0x40000000
Loading section .text, size 0x16fc lma 0x40000070
Loading section .data, size 0x858 lma 0x4000176c
Start address 0x40000000, load size 8130
Transfer rate: 63 KB/sec, 2710 bytes/write.
(gdb) si
unable to resume hart 0
  dmstatus =0x00430c82
  was stepping, halting
unable to halt hart 0
  dmcontrol=0x00000001
  dmstatus =0x00430c82
Hart was not halted after single step!
unable to step rtos hart

By capturing the waveform signal, it can be preliminarily determined that IFetc failed at address 0x40000000

you can look at this picture
in the gen.scala, I set

def plugins = {
    val l = Config1.plugins(
      withRdTime = true,
      aluCount    = 2,
      decodeCount = 2,
      debugTriggers = 4,
      withDedicatedLoadAgu = true,
      withRvc = true,
      withLoadStore = true,
      withMmu = true,
      withDebug = true,
      withEmbeddedJtagTap = false,
      jtagTunneled = false,
      withFloat = false,
      withDouble = false,
      withLsu2 = true,
      lqSize = 16,
      sqSize = 16,
            withCoherency = true,
      ioRange = a => a(31 downto 28) === 0xf// || !a(12)//(a(5, 6 bits) ^ a(12, 6 bits)) === 51
    )

May I ask which parameter caused the issue with this fetch，thanks

[duanjiulon]

[Dolu1990]

Hi,

There is also the fetchRange which can matter, but by default it is :
fetchRange : UInt => Bool = _(31 downto 28) =/= 0x1,

Which should be fine.

Did you tried first the openocd telnet ?
trying to use it to load binaries into memory and reading them back.

Also, one important step, is to run everything in simulation (including jtag / openocd), that way we aren't facing a blackbox to debug.
What are you using to run simulation in general ?

[duanjiulon]

I don't know how to use simulation, after all, this one loads its own IP core related things when it's loaded onto the board, and I haven't seen the mode of simulating while debugging with jtag anywhere except on Verilator. This SOC development is detached from the Litex environment. This has also caused me great difficulties。 段玖龙 ***@***.***  

…

------------------ 原始邮件 ------------------ 发件人: "SpinalHDL/NaxRiscv" ***@***.***>; 发送时间: 2024年7月17日(星期三) 晚上8:38 ***@***.***>; ***@***.******@***.***>; 主题: Re: [SpinalHDL/NaxRiscv] about the gen.scala and ifetch (Issue #119) Hi, There is also the fetchRange which can matter, but by default it is : fetchRange : UInt => Bool = _(31 downto 28) =/= 0x1, Which should be fine. Did you tried first the openocd telnet ? trying to use it to load binaries into memory and reading them back. Also, one important step, is to run everything in simulation (including jtag / openocd), that way we aren't facing a blackbox to debug. What are you using to run simulation in general ? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Dolu1990]

To reduce bug possibilities, maybe try with :
aluCount = 1,
decodeCount = 1,
debugTriggers = 0,
withDedicatedLoadAgu = true,
withRvc = false,

This will reduce the CPU complexity and maybe workaround a potential bug in the debug module ?

[duanjiulon]

Did you tried first the openocd telnet ?
trying to use it to load binaries into memory and reading them back.

1. I have tried your method, and after loading through GDB, the openocd terminal can read the corresponding hexadecimal data through the mdw command. Loading is done through dbus, but as soon as I start running or step through debugging, the core will freeze directly. However, running the program on the address of onchipram does not have this problem, but running the program on the address of DDR will cause this problem, so I suspect it is an issue with ifetch.
   I also directly used the default settings for fetch range without making any modifications.
2. The cores generated through the Litex command line all have the 'coherent' option enabled by default. Can we disable it before generating Litex_soc

[duanjiulon]

To reduce bug possibilities, maybe try with : aluCount = 1, decodeCount = 1, debugTriggers = 0, withDedicatedLoadAgu = true, withRvc = false,

This will reduce the CPU complexity and maybe workaround a potential bug in the debug module ?

Hi， Recently, I have successfully embedded Nax_come into SOC systems without memory consistency, and there are no issues with debugging peripherals. However, I have encountered a problem recently where a timer is required to run drystone programs on this SOC system. I have looked at some NAX_CORE systems that have a timer input, which is:

input  wire [63:0]    PrivilegedPlugin_io_rdtime

assign _zz_EU0_CsrAccessPlugin_logic_fsm_readLogic_csrValue_17[31 : 0] = PrivilegedPlugin_io_rdtime[31 : 0];
assign _zz_EU0_CsrAccessPlugin_logic_fsm_readLogic_csrValue_18[31 : 0] = PrivilegedPlugin_io_rdtime[63 : 32];

May I ask what command I need to use to successfully read this timer?

[duanjiulon]

Hi,

There is also the fetchRange which can matter, but by default it is : fetchRange : UInt => Bool = _(31 downto 28) =/= 0x1,

Which should be fine.

Did you tried first the openocd telnet ? trying to use it to load binaries into memory and reading them back.

Also, one important step, is to run everything in simulation (including jtag / openocd), that way we aren't facing a blackbox to debug. What are you using to run simulation in general ?

Regarding the issue of abnormal program loading earlier, I found through an online logic analyzer that after GDB loads the program, there will be an authorization failure when reading, and the reason for the failure is that Dcached has an abnormal writable backup. After loading DDR, the program cannot be pulled down normally, so I directly set this signal to a low level and the program loading (dbus) and finger retrieval (ibus) will be fine. Is there anything else to pay attention to here?

[Dolu1990]

rdtime

to access it you can use the CSR defined in gcc as "time"
https://github.com/SpinalHDL/NaxSoftware/blob/c63c0ce9311160a7965637fb7de5899c3a5110b8/baremetal/driver/riscv.h#L96
=>
x = csr_read(time);
shouls be ok.

Else you can use the cycle counter :
x = csr_read(cycle);

there will be an authorization failure when reading

What kind of authorization failure ?

abnormal writable backup
pulled down normally

What do you mean ?

[duanjiulon]

What do you mean ?

you can see this one：
After I loaded the program into the DDR where 0x40000000 is located through jtag, the signal DataCachePluginloggic_cache_iw_ritebackBusy remained in a high state. By using commands such as mdw to check the data in the memory at that address, it was successfully loaded.
Correspondingly, if the program is loaded into ROM through jtag, it is the result of the second image.

[Dolu1990]

Ahhh i forgot you were in litex.

writeback_slot_1_valid being stuck high is realy weird, as it is quite decoupled from all the rest of the CPU, it is rely at the border toward the memory system.

One thing, did you let the litex bios calibrate the dram after the reset and after starting openocd ?

[duanjiulon]

Ahhh i forgot you were in litex.

writeback_slot_1_valid being stuck high is realy weird, as it is quite decoupled from all the rest of the CPU, it is rely at the border toward the memory system.

One thing, did you let the litex bios calibrate the dram after the reset and after starting openocd ?

No, no, no, this is my own SOC, which has already separated from Litex and lacks memory consistency. It's just a Dcache to axi4 interface connected to axifabric, and then connected to a DDR peripheral, so there's no BIOS

[Dolu1990]

Ahhh then the issue is likely the source / id handeling in the memory interconnect.
Can you probe the various cache/io_mem valid+ready+id ?
There is a good chance that the memory interconnect give back the wrong ID as a response.

[duanjiulon]

Ahhh then the issue is likely the source / id handeling in the memory interconnect. Can you probe the various cache/io_mem valid+ready+id ? There is a good chance that the memory interconnect give back the wrong ID as a response.

This is a result after GDB loads the binary file:

[Dolu1990]

Hi,

You also need the rsp_id for read and writes.

[duanjiulon]

sp_id

while load on the on chip ram(0x0 start)