Replies: 4 comments 16 replies
|
Thank you for the information. My use case: I get the NEORV32 core as a Git submodule and integrate it into my project. I do not want to make any modifications inside the NEORV32 checkout. |
Why? I also add NEORV32 as a submodule to my projects (actually I add as a submodule inside a submodule because I add the neorv32-setups project 😬). Every Monday, when Stephan merges the dependabot PR into the neorv32-setups project, I update the submodule locally. If everything works fine, I push the change to origin. If something crashes, I adapt my own fonts to the new NEORV32 changes, then I commit and upload them. Tip To update the submodule: From your project's path, locate in the submodule by typing You can examine what I consider to be an example that I keep up to date: https://github.com/Unike267/afselerator Cheers! |
I also like to use patches for submodules, but I actually prefer to keep the code base clean. So I can definitely understand that.
The option was removed because we had two timeout counters (one for external bus accesses and one for internal ones). They had to be synchronized, and in the end, I found it just too complicated. Could you explain your use case in a bit more detail? Right now, we have a default timeout of 1024 cycles. So, every AXI interconnect, for example, should definitely respond to a request within this time frame. I don't think the option to disable the timeout completely is a good idea, as this can quickly lead to problems that are difficult to detect (the processor simply freezes). Perhaps we could add the Wishbone |
That would be great!! 🙏 |
|
I can no longer find any reference to So we would have to add a custom signal (perhaps "halt" to avoid confusion) that pauses the timeout countdown. Alternatively, we could a another configuration generic to set the timeout value. However, I would recommend not allowing a value of zero - precisely because it can quickly cause the system to freeze. What do you think would be the better option? And why? Maybe you have some specific use cases? |
That's because that web page hosts the Wishbone B3 spec (2002), and I think that the You can check the ReStructuredText (RST) sources that compose the webpage here: https://github.com/fossi-foundation/wishbone/tree/master/src I don't know if there is any way to emulate a stall using b3 version. Another option is to implement the more modern b4 version in NEORV32. BTW, I've read this @wallento's comment in the issue 24 of the repo which store the code of that web page and it caught my attention quite a bit.
Perhaps he can clarify something for us. Cheers! |
Ah ok, that makes sense. I'm not really sure what the differences between B3 and B4 are... Maybe the burst signaling?
Anyway, burst arbitration in NEORV32 is a little different anyway, so we're probably not 100% Wishbone-compatible anyway.
Actually, I don't like the idea that an external module can completely freeze the processor (via some |
|
Okay, you requested more details:
Wishbone spec B4: https://cdn.opencores.org/downloads/wbspec_b4.pdf
True, but we can handle this. |
The paper has just been published: |
|
This looks like a cool paper - I'll take a closer look at it once I have access to IEEE again. 😉 Thanks for sharing, anyway! 👍 |
|
FTR: I am sharing a video of myself speaking at CERN about the capture architecture from my thesis, as well as the postprint of the paper, which is stored in my university's database. Initially, the "Custom EtherBone Master Core" (CEBMC) described in the paper was intended to be attached just as shown in the video slides. However, I am refining/simplifying the design and unifying it into a single block that uses a version of the CEBMC state machine and a register block instead of a RAM. Nevertheless, the paper allowed us to verify that, when sending a RAW Ethernet frame (Figure 1) from our hardware to the White Rabbit PTP Core (WRPC) through the 16-bit data port of the fabric interface (a modification of a Wishbone interface used by CERN in its WRPC), the WRPC handles it transparently for the user and exchanges it correctly through the physical layer (PHY) over the network. Video: https://videos.cern.ch/record/3025804 |
|
BTW: @stnolting, I asked Maciej Lipinski if they had ever considered replacing their own implementation of the RISC-V softcore (urv), which they use in the WRPC, with an open source project such as NEORV32, and this was his response: https://videos.cern.ch/record/3025741 (min 35:30) Hahaha, honestly it was a pleasure to be with so many geniuses—Adam, Maciej, Tristan, etc. ❤️ |
|
Thanks for asking that questions (and for the advertising 😅). |
Uh oh!
There was an error while loading. Please reload this page.
Maybe I’m missing something, but why is it no longer possible to configure the XBUS timeout?
As far as I can see, it’s still somehow configurable via
constant bus_timeout_c : natural := 1024;, but the neorv32_top entity no longer exposes this as a generic parameter.I really need to be able to disable it (multi-master system).
All reactions