How to add a custom module, based on GPIO #147
Replies: 4 comments 15 replies
-
More likely it will provide you knowledge, fun, and excitement! I wouldn't bet on it making you (almost anyone) rich 🤣 Jokes aside, can you please provide a reference to a branch/fork with your modified sources? That will make it easier for other users/contributors to better understand what you are trying to achieve. My very first feeling is that you are making it more complicated than it should. You should not replace/duplicate the GPIO component yet. You can plug your logic outside instead. That will allow you to reuse the existing software drivers, memory map, etc. Once you succeed on that, you can evaluate other tighter integration approaches. |
Beta Was this translation helpful? Give feedback.
-
I'll take that as well. I created a fork/branch here: https://github.com/motius/neorv32/tree/add-custom-module
That is the opposite of what I was trying to do 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I tried both using the same address space ("ffffffc0") and a different one ("fffffff0") - same address space gives me 0, the different one gives me 4294967296, regardless of input. |
Beta Was this translation helpful? Give feedback.
-
|
You can use the same address space as the GPIO - just disable the GPIO component in your testbench so there is no read-data collision: IO_GPIO_EN => false, -- implement general purpose input/output port unit (GPIO)?You cannot use the address (space) neorv32/rtl/core/neorv32_package.vhd Lines 282 to 284 in e07f1f3 |
Beta Was this translation helpful? Give feedback.
-
|
Knowing about the CFS now, I stole the last two registers from there: That still results in all 0 in the results. I'll try disabling the GPIO module and stealing these registers and got the same results: 0 whichever input I get. So I changed my VHDL, to write Which still leaves me unsure about whether the mistake is the VHDL or in the C code, but I think at least the addresses I now use are good. /edit: |
Beta Was this translation helpful? Give feedback.
-
This cannot work because the base address of a module is evaluated inside that module before evaluating the actual register address.
Good idea. You could simplify your PLAM registers at first: rw_access: process(clk_i)
begin
if rising_edge(clk_i) then
-- bus handshake --
ack_o <= acc_en and (rden_i or wren_i);
-- write access --
if ((acc_en and wren_i) = '1') then
inp_data <= data_i;
end if;
-- read access --
data_o <= (others => '0');
if ((acc_en and rden_i) = '1') then
data_o <= inp_data;
end if;
end if;
end process rw_access;By this, any access to the PLAM address space access the same single register. Make sure that GPIO_BASE= 0x1234abcd; // write to PLAM register
neorv32_uart_printf("%x", GPIO_BASE); // read back
👍 |
Beta Was this translation helpful? Give feedback.
-
|
This snippet also resulted in all 0 🤷 BUT -> The CFS is working as expected, so I will stay within that for now to develop some kind of functionality and then will revisit the spinning it out into a separate module once I got a bit more accustomed to VHDL and the neorv32 code. I think my first try was already close, but since I was just blindly copy-pasting without too much understanding, there is probably mistakes and crucial parts missing. |
Beta Was this translation helpful? Give feedback.
-
|
Hey there! As @umarcor already said: you can add custom blocks via the external bus interface. However, if you want to add new functionality to the processor internally, then the Custom Functions Subsystem (CFS) is the right place to start. I think it would be easier to use the CFS first before you start modifying existing components or adding completely new modules. The CFS is something like a an "empty template module" that is explicitly intended to add custom functionality. All the interface stuff is already there: address assignment, C-language support, internal bus protocol handling, etc.
The CFS provides 32x 32-bit memory-mapped registers for the interface: neorv32/sw/lib/include/neorv32.h Lines 538 to 611 in e07f1f3 Some time ago, I used the CFS to implement a WS2812 interface (this is now an individual module -> If your are interested in implementing CRC: I also did that for a different project: Regarding your modifications of the GPIO controller: At first sight, your VHDL code looks good. Maybe there is a problem with the definitions of Another minor thing: I think this is not VHDL-compliant (at least not with GHDL and pre-VHDL2008), but is accepted by most toolchains: case addr is
when plam_in_addr_c => data_o <= inp_data; |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, I overlooked the CFS module when I was scanning the docs for hints. I'll keep experimenting and will probably come up with more questions here. |
Beta Was this translation helpful? Give feedback.
-
Sure, feel free to ask if you have any questions or if you encounter any problems. |
Beta Was this translation helpful? Give feedback.
-
This is copied from the GPIO module: https://github.com/stnolting/neorv32/blob/master/rtl/core/neorv32_gpio.vhd#L107 |
Beta Was this translation helpful? Give feedback.
-
|
You got me 😅 constant gpio_in_addr_c : std_ulogic_vector(15 downto 0) := std_ulogic_vector(unsigned(gpio_base_c) + x"0002"); |
Beta Was this translation helpful? Give feedback.
-
|
Hey guys! First, it's been really cool playing around with the neorv32 😎! Thank you for this project! To contribute to the discussion I wrote this simple guide: How to add a custom module - Cyclic Redundancy Check (CRC32) - Nexys A7 Board I tried to be as organised and clear as possible 😅. I know there is still so much complexity to take into account. What do you think about it? Does it make sense to use it as a Tutorial (or at least starting point)? Looking forward to your comments! |
Beta Was this translation helpful? Give feedback.
-
|
He is my colleague by the way 😄 |
Beta Was this translation helpful? Give feedback.
-
|
We discussed about adding that type of content to this same repository, or maybe creating a sibling repo for that purpose. The risk of adding it here is that "optional" IP features might end up "eating" the CPU codebase, making it more difficult to approach for less experienced users. Nontheless, I do want to see such content very tightly coupled to the main repo (see What nobody tells you about documentation). That is, I can help setup CI for creating HTML and PDF versions of that tutorial, using a similar style as the one in the Datasheet and the User Guide. That might be the foundation/template for "a series of NEORV32 Tutorials" that contibutors/users as you can write in the future. At some point, we might want to have a landing page in stnolting.github.io/neorv32 which points to 2-4 documents. Overall, I am really happy to see you both being colleagues and collaborating into making good use of NEORV32. I do know of two other people in another company also expecting to extend/use NEORV32 (not guaranteed to be made open source yet). It's good to see NEORV32 be used further than just testing the provided examples. EDIT Naturally, CI for that tutorial would not only create the HTML/PDF doc, but it could also generate a bitstream if extended to the "osflow" (we cannot run Vivado in CI). |
Beta Was this translation helpful? Give feedback.
-
|
Hey @ikstvn and @turbinenreiter! I would love to have your CFU "tutorial" somehow connected to this project. But as @umarcor already said, putting it into this repo would require a lot of maintaining... Anyway, you could create a PR and add your setup as link to the
I totally agree! 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I made a PR (#157) to add your tutorial (as a first step) to the setup's README. |
Beta Was this translation helpful? Give feedback.
-
Hi!
I have been trying to add a custom module to neorv32, based on the GPIO module. For context, I am an absolute novice at FPGA programming and don't really know VHDL. The module itself is trivial (for now, it just writes the input register to the output register - once I get it working I might try something slightly useful, like crc32), but the module itself isn't the point - the point is to figure out how to add modules (and hopefully document it for the next person). The reason I'm doing this as an absolute novice if because I like RISC-V and want to convince my colleagues that RISC-V + FPGAs + custom modules will make us rich 😄 .
To achieve this, I basically copied the GPIO module and changed the word GPIO to a different one and replaced the logic with, what I think, just a copy from the input to the output register. I did the same thing with the GPIO .h/.c files. Then I hunted down all the other places in the code where the GPIO module is mentioned and added my module in those places as well.
I got all of this somewhat working, except that the results don't make too much sense, which is why I'm here, asking questions 😄 .
Let's start with the list of files I added:
All these are copied over from the GPIO module and simplified somewhat.
And here is the list of other files I touched, to add this module to the core that I run in the simulator (I use the ghdl scripts in the sim folder to test for now):
The C code I run to test this is:
And the VHDL (again, this is a naive copy of the GPIO module):
Now to the issues that I have:
Which brings me to the questions:
out_data <= inp_data;copy the data from my input reg to the output reg?)So far, I really enjoyed working with neorv32, I was able to program both an ice40 with the Open Source toolchain and a nexys a7 with Vivado and flash custom programs on it, without any kind of prior FPGA knowledge. I hope I can sort out my issues with this custom module and make it available somehow as a Tutorial.
Beta Was this translation helpful? Give feedback.
All reactions