OpenCores
no use no use 1/1 no use no use
Mapping between GPIO and Memory Addresses?
by Fredrique on Jan 8, 2016
Fredrique
Posts: 2
Joined: Jun 21, 2013
Last seen: Feb 19, 2016
I have compiled ORPSoC for the Terasic DE0 Nano as described in:
http://opencores.org/or1k/ORCONF2013_Workshop_ORPSoC_On_DE0_Nano

In the timerled example, I see that the 8 LEDs of the board can be activated by setting the 8 bits at memory address 0x91000000:


char* gpio_base = (char*) 0x91000000;

// ...

// Activate certain LEDs.
*(gpio_base+0) = 0x55;


Now I am wondering where (in the ORPSoC source files?) this is defined. Why are the GPIO bits of the LEDs assigned to the 8 bits at 0x91000000? Where would I change that address?

And most importantly: Can I add my own new ports to the hardware design and access them from the C files via a certain address range?


As you realise, I am very new to the whole field of openRISC. A hint would be greatly appreciated!
Thanks!
RE: Mapping between GPIO and Memory Addresses?
by dgisselq on Jan 9, 2016
dgisselq
Posts: 247
Joined: Feb 20, 2015
Last seen: Oct 24, 2024
I may be even newer than you--I just peeked at the code for the first time this evening.

Take a peek at the wb_intercon.v file. It's automatically generated, but you can see there that the GPIO address is passed to the wb_mux as 0x91000000.

I think you can find the interconnect data file, which is used to set this address, in the sockit/data directory--it's a file named wb_intercon.conf.

Again, while I'm even newer to OpenRisc, having listened to the discussions around here for a while, I think the issue of the WB interconnect, readdressing items, reconfiguring the bus, etc. has been an issue for a while. I guess there are just too many users who want to reconfigure OpenRISC to have their own special functionality ... wherever on the bus. (And why not?) At any rate, that's why the configuration has been made automatic, and as a result gets a little bit obscured.

While I'm not completely sure of the details, I think fusesoc was created to help this interconnect problem. The documentation for fusesoc hasn't been clear enough for me to catch the details, but from what I gather the software in fusesoc looks through the various directories for '.core' files, which are then used to help generate the configuration for the wishbone interconnect.

Hopefully that helps,

Dan
RE: Mapping between GPIO and Memory Addresses?
by olof on Jan 9, 2016
olof
Posts: 218
Joined: Feb 10, 2010
Last seen: Dec 17, 2018
Hi,

All though the general instrcutions in this workshop apply some of the details are a bit outdated in. What was called ORPSoC in that document is now FuseSoC, and can be found here https://github.com/olofk/fusesoc

After you have installed fusesoc, you can run "fusesoc build de0_nano" to build your system

Anyway, back to your question.

The CPU accesses its peripheral devices through an interconnect component that routes the reads and write to the correct slave depending on the address. In most of the systems that uses FuseSoC, this interconnect component can be autogenerated (since it's an extremely boring component to write yourself). If you look here https://github.com/openrisc/orpsoc-cores/blob/master/systems/de0_nano/rtl/verilog/orpsoc_top.v#L156 you can see where we include the autogenerated intercon file in the de0 nano top-level. The file wb_intercon.v in the same directory is the interconnect component itself, and wb_intercon.vh is a helper file that takes care of the instantiation and wire declaration.

The configuration file that is the source of the generated verilog code can be found here https://github.com/openrisc/orpsoc-cores/blob/master/systems/de0_nano/data/wb_intercon.conf . It lists all the master and slave ports and how they are connected to each other.

To generate a new wb_intercon file, you can run the wb_intercon_gen script found in the wb_intercon core (~/.local/share/orpsoc-cores/cores/wb_intercon/sw/wb_intercon_gen if you have done a normal installation with fusesoc init).

So, from your de0 nano root, you can run ~/.local/share/orpsoc-cores/cores/wb_intercon/sw/wb_intercon_gen data/wb_intercon.conf rtl/verilog/wb_intercon.v to regenerate the de0 nano files. I'm working on some improvements to make this process a bit smoother, but this is the way to do it for now

Hope this helps,

Olof
RE: Mapping between GPIO and Memory Addresses?
by Fredrique on Jan 11, 2016
Fredrique
Posts: 2
Joined: Jun 21, 2013
Last seen: Feb 19, 2016
Dear Olof, dear Dan,

thanks for your quick replies.

We were able to find the file:
fusesoc/orpsoc-cores/systems/de0_nano/data/wb_intercon.conf


There, we tried a first modification by duplicating one of the already present gpios:

slaves =
sdram_dbus
uart0
gpio0
gpio1
gpio2 i2c0
...


[slave gpio2]
datawidth=8
offset=0x93000000
size=2


As suggested by Olof, we run apparently successfully:
~/.local/share/orpsoc-cores/cores/wb_intercon/sw/wb_intercon_gen data/wb_intercon.conf rtl/verilog/wb_intercon.v


But if we try "fusesoc build de0_nano" afterwards, we get several times:

Error (10149): Verilog HDL Declaration error at wb_intercon.vh(...):
"wb_s2m_dbus_...." is already declared in thepresent scope File.


Any hint what we did wrong?

Thanks in advance!
RE: Mapping between GPIO and Memory Addresses?
by olof on Jan 11, 2016
olof
Posts: 218
Joined: Feb 10, 2010
Last seen: Dec 17, 2018
Hi,

Good to hear that you got it working so far. You haven't done anything wrong, but I forgot that there is actually a bug here. You need to manually remove the wb_{m2s,s2m}_dbus_* nets manually from wb_intercon.vh

The reason for this is that de0 nano is a bit special, since it contains two wb_intercon blocks that are connected in series, and both wb_intercon.vh and wb_intercon_dbg.vh declares the same wires. I should fix this.

Anyway. Hope this gets you further along the path. Good luck and don't hesitate to ask for more help

//Olof
no use no use 1/1 no use no use
© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.