Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

how to run a nax_core with a AXI4 interface #81

Open
duanjiulon opened this issue Feb 23, 2024 · 24 comments
Open

how to run a nax_core with a AXI4 interface #81

duanjiulon opened this issue Feb 23, 2024 · 24 comments

Comments

@duanjiulon
Copy link

1.Hello, prior to this, I successfully ran a nax_soc using lite according to your tutorial, but its nax_core core interface is AXI4_lite. I want to use AXI, but I entered axi in the -- bus stand parameter, but it still doesn't work. The generated core interface is still axi4_lite. How can I generate a core for the axi4 interface to connect to the SOC where Briey is located, and replace the vex with nax?
2.

jlduan@dev-optiplex3060:~/work1/pythondata-cpu-naxriscv/pythondata_cpu_naxriscv/verilog/ext/NaxRiscv$ sbt "runMain naxriscv.platform.LitexGen --with-jtag-tap --with-debug --scala-args=rvc=true --scala-file=/home/jlduan/work1/pythondata-cpu-naxriscv/pythondata_cpu_naxriscv/verilog/configs/gen.scala --scala-args=rvc=true"
[info] welcome to sbt 1.6.0 (Debian Java 17.0.9)
[info] loading settings for project naxriscv-build from plugins.sbt ...
[info] loading project definition from /home/jlduan/work1/pythondata-cpu-naxriscv/pythondata_cpu_naxriscv/verilog/ext/NaxRiscv/project
[info] loading settings for project root from build.sbt ...
[info] loading settings for project spinalhdl-build from plugin.sbt ...
[info] loading project definition from /home/jlduan/work1/pythondata-cpu-naxriscv/pythondata_cpu_naxriscv/verilog/ext/NaxRiscv/ext/SpinalHDL/project
[info] loading settings for project all from build.sbt ...
[info] set current project to NaxRiscv (in build file:/home/jlduan/work1/pythondata-cpu-naxriscv/pythondata_cpu_naxriscv/verilog/ext/NaxRiscv/)
[info] running (fork) naxriscv.platform.LitexGen --with-jtag-tap --with-debug --scala-args=rvc=true --scala-file=/home/jlduan/work1/pythondata-cpu-naxriscv/pythondata_cpu_naxriscv/verilog/configs/gen.scala --scala-args=rvc=true
[info] [Runtime] SpinalHDL dev git head : 700e223f5dc8c2258117fae140ab8d6eb8446d97
[info] [Runtime] JVM max memory : 3956.0MiB
[info] [Runtime] Current date : 2024.02.23 14:49:17
[info] [Progress] at 0.000 : Elaborate components
[info] memoryRegions: Seq[naxriscv.platform.LitexMemoryRegion] = ArrayBuffer()
[info] import scala.collection.mutable.ArrayBuffer
[info] import naxriscv.utilities.Plugin
[info] import naxriscv.platform.LitexMemoryRegion
[info] import spinal.lib.bus.misc.SizeMapping
[info] plugins: scala.collection.mutable.ArrayBuffer[naxriscv.utilities.Plugin] = ArrayBuffer(DocPlugin, MmuPlugin, FetchPlugin, PcPlugin, FetchCachePlugin, AlignerPlugin, FrontendPlugin, DecompressorPlugin, DecoderPlugin, integer_RfTranslationPlugin, RfDependencyPlugin, integer_RfAllocationPlugin, DispatchPlugin, BranchContextPlugin, HistoryPlugin, DecoderPredictionPlugin, BtbPlugin, GSharePlugin, Lsu2Plugin, DataCachePlugin, RobPlugin, CommitPlugin, integer_RegFilePlugin, CommitDebugFilterPlugin, CsrRamPlugin, PrivilegedPlugin, PerformanceCounterPlugin, ALU0_ExecutionUnitBase, ALU0_IntFormatPlugin, ALU0_SrcPlugin, ALU0_IntAluPlugin, AL...The main thread is stuck at :
[info] [email protected]/jdk.internal.misc.Unsafe.park(Native Method)
[info] [email protected]/java.util.concurrent.locks.LockSupport.park(LockSupport.java:341)
[info] [email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(AbstractQueuedSynchronizer.java:506)
[info] [email protected]/java.util.concurrent.ForkJoinPool.unmanagedBlock(ForkJoinPool.java:3465)
[info] [email protected]/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3436)
[info] [email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1623)
[info] [email protected]/java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:236)
[info] [email protected]/java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:364)
[info] app//spinal.sim.JvmThread.park(SimManager.scala:30)
[info] app//naxriscv.platform.NaxRiscvLitex$$anon$1.(Litex.scala:48)
[info] app//naxriscv.platform.NaxRiscvLitex.(Litex.scala:47)
[info] app//naxriscv.platform.LitexGen$$anonfun$14.apply(Litex.scala:184)
[info] app//naxriscv.platform.LitexGen$$anonfun$14.apply(Litex.scala:157)
[info] app//spinal.sim.JvmThread.run(SimManager.scala:51)
[info] **********************************************************************************************
[info] [Warning] Elaboration failed (0 error).
[info] Spinal will restart with scala trace to help you to find the problem.
[info] **********************************************************************************************
[info] [Progress] at 4.306 : Elaborate components
[info] memoryRegions: Seq[naxriscv.platform.LitexMemoryRegion] = ArrayBuffer()
[info] import scala.collection.mutable.ArrayBuffer
[info] import naxriscv.utilities.Plugin
[info] import naxriscv.platform.LitexMemoryRegion
[info] import spinal.lib.bus.misc.SizeMapping
[info] plugins: scala.collection.mutable.ArrayBuffer[naxriscv.utilities.Plugin] = ArrayBuffer(DocPlugin, MmuPlugin, FetchPlugin, PcPlugin, FetchCachePlugin, AlignerPlugin, FrontendPlugin, DecompressorPlugin, DecoderPlugin, integer_RfTranslationPlugin, RfDependencyPlugin, integer_RfAllocationPlugin, DispatchPlugin, BranchContextPlugin, HistoryPlugin, DecoderPredictionPlugin, BtbPlugin, GSharePlugin, Lsu2Plugin, DataCachePlugin, RobPlugin, CommitPlugin, integer_RegFilePlugin, CommitDebugFilterPlugin, CsrRamPlugin, PrivilegedPlugin, PerformanceCounterPlugin, ALU0_ExecutionUnitBase, ALU0_IntFormatPlugin, ALU0_SrcPlugin, ALU0_IntAluPlugin, AL...The main thread is stuck at :
[info] [email protected]/jdk.internal.misc.Unsafe.park(Native Method)
[info] [email protected]/java.util.concurrent.locks.LockSupport.park(LockSupport.java:341)
[info] [email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(AbstractQueuedSynchronizer.java:506)
[info] [email protected]/java.util.concurrent.ForkJoinPool.unmanagedBlock(ForkJoinPool.java:3465)
[info] [email protected]/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3436)
[info] [email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1623)
[info] [email protected]/java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:236)
[info] [email protected]/java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:364)
[info] app//spinal.sim.JvmThread.park(SimManager.scala:30)
[info] app//naxriscv.platform.NaxRiscvLitex$$anon$1.(Litex.scala:48)
[info] app//naxriscv.platform.NaxRiscvLitex.(Litex.scala:47)
[info] app//naxriscv.platform.LitexGen$$anonfun$14.apply(Litex.scala:184)
[info] app//naxriscv.platform.LitexGen$$anonfun$14.apply(Litex.scala:157)
[info] app//spinal.sim.JvmThread.run(SimManager.scala:51)
[error] Exception in thread "main" java.lang.AssertionError: assertion failed
[error] at scala.Predef$.assert(Predef.scala:156)
[error] at spinal.core.package$.assert(core.scala:497)
[error] at naxriscv.lsu.DataMemBus$$anon$13.(DataCache.scala:408)
[error] at naxriscv.lsu.DataMemBus.toAxi4(DataCache.scala:407)
[error] at naxriscv.lsu.DataCacheAxi4$$anonfun$1$$anon$1.(DataCacheAxi4.scala:16)
[error] at naxriscv.lsu.DataCacheAxi4$$anonfun$1.apply(DataCacheAxi4.scala:13)
[error] at naxriscv.lsu.DataCacheAxi4$$anonfun$1.apply(DataCacheAxi4.scala:13)
[error] at naxriscv.utilities.Plugin$$anon$1$$anonfun$late$1$$anonfun$5.apply(Framework.scala:58)
[error] at spinal.core.Area$class.rework(Area.scala:59)
[error] at naxriscv.utilities.Framework.rework(Framework.scala:81)
[error] at naxriscv.utilities.Plugin$$anon$1$$anonfun$late$1.apply(Framework.scala:56)
[error] at spinal.core.fiber.package$$anonfun$1.apply$mcV$sp(package.scala:16)
[error] at spinal.core.fiber.AsyncThread$$anonfun$1.apply$mcV$sp(AsyncThread.scala:59)
[error] at spinal.core.fiber.EngineContext$$anonfun$newJvmThread$1.apply$mcV$sp(AsyncCtrl.scala:39)
[error] at spinal.sim.JvmThread.run(SimManager.scala:51)
[error] Nonzero exit code returned from runner: 1
[error] (Compile / runMain) Nonzero exit code returned from runner: 1
[error] Total time: 9 s, completed 2024Äê2ÔÂ23ÈÕ ÏÂÎç2:49:22

Based on your previous answers to classmates' questions, I have added a specific gen.scala file, but this error still occurs. How can I resolve this error?
@duanjiulon
Copy link
Author

for example,CMD
runMain naxriscv.platform.LitexGen --netlist-name MyNaxRiscvLitex --netlist-directory=/home/jlduan/work1/pythondata-cpu-naxriscv/pythondata_cpu_naxriscv/verilog --reset-vector=0 --xlen=32 --memory-region=0,65536,rw,p --with-jtag-tap --with-debug --scala-file=/home/jlduan/work1/pythondata-cpu-naxriscv/pythondata_cpu_naxriscv/verilog/configs/gen.scala
is also the problem,
please help me ,thanks

@Dolu1990
Copy link
Member

Hi,

but its nax_core core interface is AXI4_lite

You mean its pbus is AXI4_lite right ? mbus is ok right ?

How can I generate a core for the axi4 interface to connect to the SOC where Briey is located, and replace the vex with nax?

That was never done before. so, for single core without memory coherency right ? just AXI4 ?

I would say, the best there would to not use the litex related port, but instead going with raw NaxRiscv and implementing the bridge from the native NaxRiscv interfaces.

@duanjiulon
Copy link
Author

duanjiulon commented Feb 29, 2024 •
edited
Loading

I would say, the best there would to not use the litex related port, but instead going with raw NaxRiscv and implementing the bridge from the native NaxRiscv interfaces.

Hello, according to your prompt, I have recently successfully replaced all keywords related to Axi4lite in the NaxSoc.scala file with Axi4., And using the command in your example, I generated a Nax_core for the Axi4 interface of pBus, which I plan to use for DDR3 read and write of AXI4

  1. Is there anything I need to pay attention to? Is this core capable of performing this function? Is the pBus-AXI4 interface of the core now connected to dBus?
  2. Automatically generated commands through Litex:
    CD/home/jlduan/work1/pythandata CPU naxriscv/pythondata_cpu naxriscv/verilog/ext/NaxRiscv&&sbt "RunMain naxriscv. platform. site. NaxGen -- netlist name=NaxRiscv_cpu -- netlist directory=/home/jlduan/work1/pythontata cpu naxriscv/pythonadata_cpu_ naxriscv/verilog -- reset vector=0-- xlen=32-- CPU count=1-- litedram width=32-- memory region=21474836482147483648, io, p -- memory region=032708, rxc, p --" memory region=26843545632708, rwxc, p -- memory region=402653184065536, rw, p -- with jtag tap -- with de Bug -- scala file=/home/jlduan/work1/pythandata cpu naxriscv/pythondata_cpu naxriscv/verilog/configurations/gen. scala -- scala args=rvc=true“
    I successfully generated the V file, but I don't quite understand the roles played by the four memory regions. In other words, I don't know what their purpose is.
    thanks for your reply！best wishes！

@Dolu1990
Copy link
Member

Dolu1990 commented Mar 4, 2024

So, the pBus is only used by the core for IO accesses (slow, in-order, word based accesses)
While the mBus is used for all the main memory accesses (fast, always 64 bytes, out of order)
So you only need to connect the DDR to the mBus.

The memory region mainly specify

  • which address space can be accessed speculatively
  • which memory space is only for IO peripherals
  • which space the fetch l1 is allowed to access (the branch predictor may generate "random" address, so it need to prevent it from accessing the IO pBus space where there is side effects, but a rom/ram there is ok)

Here is some example :

--memory-region=2147483648,131072,io,p => Allowed to access address [2147483648,2147483648+131072] on pBus for io access only (meaning slow, in order, load+store, can't fetch instruction from there)
--memory-region=0,131072,rxc,p => address [0, 0 + 131072] are accessible via load(r) and fetch(x),no store, on pBus(p) and is cacheable(c)
--memory-region=2147483648,8192,rw,p => can do load store, not cacheable, on pBus
--memory-region=1073741824,536870912,rwxc,m => can do load store fetch, cacheable, on mBus

There seems like the rw flag aren't looked by NaxRiscv generator, what matthers are
"io", "x", "p,"m","c".

See

case class LitexMemoryRegion(mapping : SizeMapping, mode : String, bus : String){
  def isIo = mode.contains("i") || mode.contains("o")
  def isExecutable = mode.contains("x")
  def isCachable = mode.contains("c")
  def onPeripheral = bus match {
    case "m" => false
    case "p" => true
  }
  def onMemory = !onPeripheral
}

@duanjiulon
Copy link
Author

duanjiulon commented Mar 6, 2024 •
edited
Loading

--memory-region=2147483648,131072,io,p => Allowed to access address [2147483648,2147483648+131072] on pBus for io access only (meaning slow, in order, load+store, can't fetch instruction from there) --memory-region=0,131072,rxc,p => address [0, 0 + 131072] are accessible via load(r) and fetch(x),no store, on pBus(p) and is cacheable(c) --memory-region=2147483648,8192,rw,p => can do load store, not cacheable, on pBus --memory-region=1073741824,536870912,rwxc,m => can do load store fetch, cacheable, on mBus

Hi, I have generated a new core according to the example you mentioned, but when I embedded this core in my own SOC demo (replacing vex_core with nax_core), the other bus interfaces remained unchanged. At this point, a situation occurred. When debugging with jtag and GDB, I found that:

Loading section_ Vector, size 0x118 lma 0x40000000

Loading section. memory, size 0x1702 lma 0x40000118

Loading section. text. startup, size 0x50c lma 0x4000181a

Loading section. rhodata, size 0x4b4 lma 0x40001d28

Loading section. data, size 0xc lma 0x400021dc

Start address 0x40000000, load size 8678

Transfer rate: 39 KB/sec, 1735 bytes/write

Write data starting from 0x40000000 through the terminal, for example:

Mww 0x40000000 0x12345678 24

I was able to successfully write the memory data, but when I analyzed the address through online logic and found that the captured address was actually 0x0000000,

May I ask if this is due to address offset within the core?
Why is DDR reading and writing successful, but the data captured is inconsistent?
thank you for your reply!

@Dolu1990
Copy link
Member

Dolu1990 commented Mar 6, 2024 •
edited
Loading

Hi,

I was able to successfully write the memory data, but when I analyzed the address through online logic and found that the captured address was actually 0x0000000,

I think that is by design, the mBus only support having a single memory region, and remove that offset from the address

May I ask if this is due to address offset within the core?

Inside the Nax SoC

Why is DDR reading and writing successful, but the data captured is inconsistent?

Which data ?

@duanjiulon
Copy link
Author

duanjiulon commented Mar 6, 2024 via email

@Dolu1990
Copy link
Member

Dolu1990 commented Mar 8, 2024 •
edited
Loading

Hi,

0x0000000, So I conclude whether there is a memory offset phenomenon here?

Yes, that is by design.

@duanjiulon
Copy link
Author

Yes, that is by design.

Hi,
I have successfully read and written DDR with your help, but I would like to run a dryone through DDR and print it out through the serial port. If I want to connect an APB bridge on the AXI interface and then connect an APB uart to the bridge's slave port, what would I like to ask you
Should I use the pbus AXI or mbus AXI interface
2. What are the good suggestions for the configuration parameters and memory allocation of the generated core based on this? I hope you can provide guidance.
Looking forward to your reply!! Thank you very much!

@Dolu1990
Copy link
Member

Hi,

pbus => for peripherals (apb)
mbus => main memory => axi only

configuration parameters

The important things are --scala-args='rvc=true,rvf=true,rvd=true,alu-count=2,decode-count=2'

memory allocation

What is that ?

@duanjiulon
Copy link
Author

the important things are --scala-args='rvc=true,rvf=true,rvd=true,alu-count=2,decode-count=2'

Ahhhh, thank for your reply
Why do ALU units need two?
What I mean is, do the four parameters of the memory unit need to be changed?

@Dolu1990
Copy link
Member

Why do ALU units need two?

To get more performances, default being 1 ALU execution unit, 2 => more performance ^^

What I mean is, do the four parameters of the memory unit need to be changed?

One io,p for peripherals via pbus
One rwxc,m for high performance memory access and execution via mbus
that's the minimum required i think

@duanjiulon
Copy link
Author

One io,p for peripherals via pbus One rwxc,m for high performance memory access and execution via mbus that's the minimum required i think

hi,dear Dolu,I'm planning to use litex+nax to run dhrystone recently, can you use the dhrystone you provide in NAXRISCV directly, or what should I pay attention to in the compiled elf file?

@duanjiulon
Copy link
Author

hi,dear Dolu,I'm planning to use litex+nax to run dhrystone recently, can you use the dhrystone you provide in NAXRISCV directly, or what should I pay attention to in the compiled elf file

dear dulo，Recently, I have been analyzing the pipeline structure of the CPU, but the logic of the allocation unit structure before the issue queue has not been clearly explained in the data. Could you please draw a diagram？thanks

@Dolu1990
Copy link
Member

As far as i remember :

  • Allocating the register file (done via a multi port fifo)
  • Allocation of the LQ/SQ ID (just a few counters)
  • Allocation of the branch ID (just a few counters)

Nothing too tricky there :)

@duanjiulon
Copy link
Author

duanjiulon commented Dec 25, 2024 via email

@duanjiulon
Copy link
Author

duanjiulon commented Dec 27, 2024 via email

@Dolu1990
Copy link
Member

diapatch unit is mostly a dependency bit matrix :

Also, note there is this additional doc :

Can the issue queue be 2×2（2row 2col）structure？

2 col meaning 2 instruction waiting to be issued ?

@duanjiulon
Copy link
Author

duanjiulon commented Dec 27, 2024 via email

@Dolu1990
Copy link
Member

You could change

NaxRiscv/src/main/scala/naxriscv/Gen.scala

Line 72 in 1c50e84

dispatchSlots : Int = 32,
to 2, but i would say, it isn't reasonable. way too small

@duanjiulon
Copy link
Author

duanjiulon commented Dec 27, 2024 via email

@Dolu1990
Copy link
Member

Yes, the wake storage will change accordingly.

@duanjiulon
Copy link
Author

Yes, the wake storage will change accordingly.

ok,fine,thank you.
Recently, I have been researching the simulation of core, which is a simulation of the lw command in riscv_test. If I want to understand:

  1. Regarding the operational mechanism of branch prediction, what signals do I need to add to view the waveform
  2. Regarding the operation mechanism of the LSU2 transmission queue, which key signal waveforms do I need to check
  3. Regarding which key signal waveforms do I need to view during the write back submission phase
    thanks so much
    rv32ui-p-lw.zip

@Dolu1990
Copy link
Member

For branches : branch.gtkw.zip
For the LSU2, hmm that is a big complex one, i would say start with the state :

  • A few pointers to keep track of the LQ/SQ circular buffer : Lsu2Plugin_logic_.*ptr
  • load queue Lsu2Plugin_logic_lq_mem Lsu2Plugin_logic_lq_regs
  • store queue Lsu2Plugin_logic_sq_mem Lsu2Plugin_logic_sq_regs
  • The shared pipeline to the cache/mmu : Lsu2Plugin_logic_.*stages_
  • for the writeback related things, it mostly live in the cache itself, but is driven from Lsu2Plugin_logic_writeback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Dolu1990 @duanjiulon