Need of Axi4 Memory Zeroer in mc

66 views
Skip to first unread message

Raghavendra Srinivas

unread,
May 20, 2020, 8:52:53 PM5/20/20
to OpenPiton Discussion
Hi Jon,
Can you please give some inputs on why we have axi4 memory zeroer code in mc_top.v?
Based on compile defines, I needed to disable that with "zeroer_off" switch with protosyn flow to pick driving signals from noc_axi4_bridge onto mig controller (AXI4 based).
Thanks,
Raghav

Jonathan Balkind

unread,
May 20, 2020, 9:05:32 PM5/20/20
to OpenPiton Discussion

For the OpenSPARC T1 core, its boot code assumes that memory has been pre-zeroed otherwise it spends a long time zeroing at the start of boot when a dedicated zeroer state machine takes significantly less time. For Ariane, the zero-stage bootloader has to have a barrier in the beginning and so the location for that barrier in RAM needs to be guaranteed to be zero.

 

If you're using Ariane and you only want to run a single core or you want to come up with another mechanism for smp_resume() then you can remove the zeroer.

 

smp.h: https://github.com/pulp-platform/ariane/blob/master/openpiton/bootrom/linux/src/smp.h

 

Thanks,

Jon

--
You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/effcfb8d-2e07-4797-ad6f-678bb8e95c78%40googlegroups.com.

Message has been deleted

Raghavendra Srinivas

unread,
May 20, 2020, 9:15:59 PM5/20/20
to OpenPiton Discussion
Thanks.! got you.
Now I need only single Ariane core. So, disabling zeroer code in compilation/synthesis is fine I believe as per your explanation (that is below SMP code should not get triggered!)
I found that , enabling Zeroer results in multi-driving issue in exiting RTL of mc_top.sv, though I did not look much into it. Not sure, how does it smoothly transition from Zeroer operation to noc_birdge within hardware logic with multi-driver issue. May be genesys2 flow was not tried with noc_axi4_bridge present, seems this flow has exposed this issue.

rag...@vt.edu

unread,
Aug 2, 2020, 5:24:19 PM8/2/20
to OpenPiton Discussion
Hi Jon,

Where is the "zero stage bootloader" file located in ariane-sdk or linux repo. I searched for macro usage "smp_pause" or smp_resume". I could not find ! I am not using memory zeroer and I work with only single ariane core, So I want to remove usage of these macros as you mentioned above which has dependency of memory zeroing.
I could not find even find same smp.h file in araine-sdk that you pointed in this email chain.

FYI : Current axi4_mem_zeroer has dependency of both "awready" and "wrreay"  before it starts  , but that is not the case with AXI4 memory controller I used from Xilinx on genesys2, so it was hung (wready is not asserted on reset). However I updated the code, and proceeded with memory zeroing, but something is still problematic as I see hang during SD card image blocks copy process. But it will be my design issue now.

However, I am planning not to use memory zerorer itself, So I want to disable the "smp_resume/pause" macros usages in zero stage bootloader. Can you please help on this?

Thank you!,
Raghav

rag...@vt.edu

unread,
Aug 2, 2020, 7:55:13 PM8/2/20
to OpenPiton Discussion
Hi Jon,

I fixed the bug in axi4_memory_zeroer .
NOw axi4_memory_zeroer is more stabel design as It considers AW* W* channels as independent and does not wait for AW /Wready handshakes before asserting Aw/Wvalids. This avoids deadlock situation.
It should work with any AXI based controller now. Openpiton can take this design change to main repo, if helps other users. I will provide the file.

Thanks,
Raghav

jbalkind

unread,
Aug 3, 2020, 12:33:53 AM8/3/20
to OpenPiton Discussion
Hi Raghav,

The zsbl is located under piton/design/chip/tile/ariane/openpiton/bootrom/linux/ and is built into a bootrom automatically before each FPGA implementation run. If you look in that location you'll find the smp_pause and smp_resume I mentioned. Keep in mind you'll only be able to run single core if you remove those. I wonder if you could have your compression engine come up with all of memory in a zero state if you want to do multicore. That could be useful.

As for the AXI zeroer, that's great! I think maybe the difference here is the addition of the resizer module. Please feel free to open a PR on the openpiton repo (to the openpiton-dev branch) of your commit(s) which fix it. We can give it a review and then merge :)

Thanks,
Jon

rag...@vt.edu

unread,
Aug 8, 2020, 12:18:38 AM8/8/20
to OpenPiton Discussion
Hi Jon,
Thanks.
Zeroer is working fine in hardware and OS also boots fine without any changes in ZSBL.
but I have some defect in my other custom block which fails if memory are zeroed out.I know the problem and  I want to debug and fix later due to time constraints.

So for now, I want to move with single core only (so without Zeorer in hardware). So I removed highlighted lines from "startUp.s" then ran FPGA implementation. But OS do not boot. CAn you please let me know is there any other dependency on memory zeroing other than ZSBL.

  .section .text.init
  .option norvc
  .globl _prog_start
_prog_start:
  #Removed  smp_pause(s1, s2)
  li sp, 0x84000000
  call main
  #Removed smp_resume(s1, s2)
  csrr a0, mhartid
  la a1, _dtb
  li s1, DRAM_BASE
  jr s1

Thank you!,
Raghav

Jonathan Balkind

unread,
Aug 18, 2020, 5:12:25 PM8/18/20
to OpenPiton Discussion

Hi Raghav,

 

Did you get this one resolved? I'm not really clear on why removing those lines would stop the OS from booting.

 

Thanks,

Jon

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpiton/ZAO_X0AZ_wY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpiton+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/67a43b37-af3a-4139-8d6f-81db7add1d72n%40googlegroups.com.

Reply all
Reply to author
Forward
0 new messages