| --- Log opened Tue Sep 06 00:00:59 2016 | ||
| mor1kx | [mor1kx] wallento pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/736b625ad4750b2a0f6a9b2f7686ccf40a1a01c8 | 04:37 |
|---|---|---|
| mor1kx | mor1kx/master 736b625 Stefan Wallentowitz: Fix verilog mode template | 04:37 |
| mor1kx | [mor1kx] spacemonkeydelivers closed pull request #38: Introducing Performance Counter Unit (master...master) https://github.com/openrisc/mor1kx/pull/38 | 06:06 |
| wallento | anyone ever faced by the baremetal toolchain building GOT into object files? | 10:52 |
| vidya | Hello all, Is it possible to toggle a GPIO pin other than the LEDs using a C code in OR1K running on DE0 Nano board? | 11:04 |
| ZipCPU | Hold on ... let me take a peek ... | 11:08 |
| ZipCPU | Looks like it has 8 GPIO I/O's, and 4 GPIO inputs ... | 11:10 |
| ZipCPU | Controlled by two separate GPIO controllers ... | 11:11 |
| vidya | How did you figure it out? In the verilog files? | 11:12 |
| ZipCPU | Yes. | 11:12 |
| ZipCPU | You can find the pins those GPIO controllers control in the data/pinmap.tcl file within the system core. | 11:13 |
| vidya | Ok. What is the base address that I have to use in the C code to toggle the pin? | 11:13 |
| ZipCPU | If you have fusesoc installed, which I do, I find a copy of that core in .local/share/orpsoc-cores/systems/de0_nano/... | 11:13 |
| ZipCPU | Let's see ... that would be in the wb_intercon.v file ... | 11:14 |
| ZipCPU | or maybe not ... | 11:15 |
| vidya | I checked the LED or UART C code both of which specify a base address. I suppose I have to get separate base address to drive a GPIO pin on board? | 11:16 |
| _franck__ | vidya: https://github.com/openrisc/orpsoc-cores/blob/master/systems/de0_nano/data/wb_intercon.conf | 11:17 |
| ZipCPU | Yeah ... there it is. Thank's _franck__! The first GPIO is at 0x9100_0000, and the second at 0x9200_0000! | 11:18 |
| ZipCPU | So that gives you the base addresses of the two GPIO peripherals. | 11:18 |
| ZipCPU | Control the first, and you can control 8 I/O pins to be either inputs, or outputs, and you can set their values. | 11:19 |
| vidya | _frank_ thanks a lot. One more question to access general GPIO pin I will have to use 0x9200_0000 address right? | 11:19 |
| ZipCPU | There are two GPIO controllers. One controls 8 gpio0_io pins, which are both inputs and outputs, the other controls 4 input pins. | 11:19 |
| ZipCPU | You can find that piece of the configuration in the rtl/verilog/orpsoc_top.v file. | 11:20 |
| vidya | I want to get an output from the board so that should be gpio0? | 11:20 |
| ZipCPU | The 0x9100_0000 address gives you access to the gpio0_io pins. | 11:20 |
| ZipCPU | The 0x9200_0000 address gives you access to the gpio1_i (input only) pins. | 11:21 |
| ZipCPU | Yes. | 11:21 |
| vidya | so other than the LED pins the other pin descriptions are not there in qsf | 11:21 |
| vidya | So I have to add them manually? | 11:21 |
| vidya | I'm not too sure of the flow actually | 11:21 |
| ZipCPU | Help me out for a moment, do those 12 pins connect to anything you are interested in controlling? | 11:22 |
| ZipCPU | Bear with me, I don't have a de0_nano board ... but I can see that the board has 8 LED's and 4 dip-switches. | 11:23 |
| ZipCPU | It makes sense, then that the GPIO controller would drive these two. | 11:23 |
| ZipCPU | Since the GPIO controller can only control 8-bits, you may wish to ... connect another four bits to GPIO controller #1, | 11:24 |
| ZipCPU | or create a third GPIO controller. | 11:24 |
| vidya | I want to use the GPIO controller to use some other IO pins on board | 11:25 |
| vidya | other than what is default pins | 11:25 |
| ZipCPU | I guess it depends on how hard you want to work at it. | 11:26 |
| ZipCPU | One method would be to use the LED controller (GPIO0) to also control your pins, and then just adjust the LED's to output what's going on on the pin you are interested in. | 11:27 |
| ZipCPU | Another method might be to integrate a third GPIO controller. | 11:27 |
| vidya | I was thinking something similar to the first method you mentioned | 11:28 |
| vidya | instead of blinking the LED can I drive another pin on board? How to do this? | 11:28 |
| ZipCPU | 1) You'll need to "connect" the pin to the design, and create a new toplevel port within orpsoc_top.v | 11:29 |
| ZipCPU | 2) You'll need to create a pin assignment for your pin, in a fashion similar to line 850 that assigns to gpio0_in[i]. | 11:30 |
| ZipCPU | 3) You'll also want to "disconnect" the pin from the current port (line 850), and set the read input to your new port. | 11:31 |
| ZipCPU | So, let's call your port "user_io". You would then ... | 11:31 |
| vidya | Ok let's suppose I declared the port in the top ad output and the pin assignment also done. How the LED code will access this top port? | 11:32 |
| ZipCPU | assign user_io = gpio0_dir[PIN] ? gpio0_out[PIN] : 1'bz; | 11:32 |
| ZipCPU | and adjust the assign gpio0_in[PIN] so that | 11:32 |
| ZipCPU | gpio0_in[PIN] = gpio0_dir[PIN] ? gpio0_out[PIN] : user_io; | 11:32 |
| ZipCPU | (where PIN is the pin number, 0-7, as defined by the GPIO controller. You pick which one ...) | 11:33 |
| vidya | for output from the board , assign user_io = gpio0_out[PIN]; is this right? | 11:41 |
| vidya | Can add just this line? | 11:41 |
| ZipCPU | Sure, why not? | 11:41 |
| ZipCPU | You might want to adjust it so it handles the direction pin of the GPIO port as well, but sure! | 11:42 |
| vidya | Yeah, right! I think I have an idea now. I will try it on board and check if it works. Thanku very much <ZipCPU> | 11:43 |
| ZipCPU | My pleasure. | 11:43 |
| ZipCPU | vidya: Were you the individual that just wrote to the openrisc mailing list on librecores as well? Or does someone else still need their question answered? | 12:28 |
| vidya | Yeah one of my lab mate asked that question. | 12:33 |
| ZipCPU|Laptop | Okay, I think I've got all the logic in place for a pipelined wishbone master to axi slave bus converter. | 14:55 |
| ZipCPU|Laptop | I opened up a new project for it, and now I just need to figure out how to test it. | 14:56 |
| olofk | ZipCPU|Laptop: You could use my wb_bfm and a AXI memory for the slave | 15:08 |
| ZipCPU|Laptop | Can I verilate your wb_bfm? | 15:09 |
| olofk | ZipCPU|Laptop: No, it's behavioural verilog | 15:11 |
| ZipCPU|Laptop | Hmm ... I'm going to struggle verilating an AXI memory too, aren't I? | 15:11 |
| olofk | I've been thinking of doing a synthesizable one, that could be used for verilator | 15:11 |
| olofk | No, you can do the memory pretty easily | 15:12 |
| ZipCPU|Laptop | Really? | 15:12 |
| olofk | Looking around orpsoc-cores, I see that there is the axi_mem_if_DP component from the Pulpino guys. | 15:15 |
| olofk | There's a axi_mem_if_SP component in that repo too. That could probably be used right away | 15:15 |
| olofk | I guess | 15:15 |
| ZipCPU|Laptop | Okay, I see it in orpsoc, but it'll take me another step to look it up. | 15:16 |
| olofk | Unfortunately there isn't any stand-alone testbench for that core | 15:16 |
| * ZipCPU|Laptop laughs. | 15:16 | |
| ZipCPU|Laptop | How often is there? | 15:16 |
| olofk | Yeah, I know :/ | 15:17 |
| olofk | Ok, the axi_mem_if_SP is a bridge between AXI and a SRAM interface | 15:18 |
| olofk | I'll see if I can throw something together | 15:18 |
| olofk | I have a feeling that I already have something somewhere | 15:19 |
| ZipCPU|Laptop | The core includes the capability (should it work) to reorder out of order responses. | 15:19 |
| olofk | Probably not | 15:20 |
| ZipCPU|Laptop | That should handle any problems folks have had with pipelined translations in the past. | 15:20 |
| olofk | Never seen reordering being used in AXI actually | 15:20 |
| ZipCPU|Laptop | That's fine--its parameterizable, and can be turned off. | 15:20 |
| olofk | Or was that not a question? Did you mean that axi_mem_if_SP does reodering? | 15:22 |
| ZipCPU|Laptop | No, I mean that the pipelined wishbone master to AXI slave translater I just built will reorder things if necessary. | 15:22 |
| ZipCPU|Laptop | The logic to do it was simple enough, although it will cost an extra clock delay on the return path. | 15:23 |
| olofk | How on earth do you handle that on the wishbone side? There's no info on the wb bus to tell which transaction that a data is attached to | 15:23 |
| ZipCPU|Laptop | Easy! | 15:23 |
| ZipCPU|Laptop | Create a FIFO. Clear the fifo whenever the strobe is low. | 15:23 |
| olofk | ? | 15:24 |
| ZipCPU|Laptop | Use the FIFO head as the transaction ID for the AXI. | 15:24 |
| ZipCPU|Laptop | (fifo head pointer, that is) | 15:24 |
| ZipCPU|Laptop | It becomes a one-up counter in the AXI interface. | 15:24 |
| ZipCPU|Laptop | AXI responses come back with their transaction ID, so use that to fill in the return FIFO in an out of order fashion if necessary. | 15:24 |
| olofk | Ah ok. But then you can't handle bursts, right? Only single accesses | 15:24 |
| ZipCPU|Laptop | You mean, AXI bursts? | 15:25 |
| olofk | yes | 15:25 |
| ZipCPU|Laptop | I mapped everything to single accesses. | 15:25 |
| olofk | aha | 15:25 |
| ZipCPU|Laptop | As long as it'll let me do multiple single accesses in a row, I'm golden. | 15:25 |
| ZipCPU|Laptop | *Every* access is the last one in its burst. | 15:25 |
| olofk | That probably works | 15:26 |
| ZipCPU|Laptop | We'll see what happens when the core meets ... something real as a test case. | 15:27 |
| olofk | If you use an event-based sim instead of verilator, you will probably have a higher chance of getting something to play with | 15:28 |
| ZipCPU|Laptop | Hey, this is neat: I just requested an open cores project for this core, and it already came back approved! | 15:29 |
| ZipCPU|Laptop | That usually takes a day or so ... | 15:29 |
| olofk | Like in worst case using ISE or Vivado to generate a memory core with an AXI interface | 15:29 |
| ZipCPU|Laptop | But I can drive it so nicely from Verilator ... I can have my CPU run the interface even ... | 15:30 |
| olofk | Yeah. That would help a lot of course | 15:30 |
| olofk | If you can run axi_mem_if_SP in verilator, coupled with a simple SRAM component that would solve the slave side | 15:30 |
| olofk | Not sure if there are any usable WB master BFMs however | 15:31 |
| ZipCPU|Laptop | Running WB from a C++ test rig within Verilator isn't that hard. | 15:31 |
| ZipCPU|Laptop | It's actually pretty easy. | 15:31 |
| --- Log closed Wed Sep 07 00:00:00 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!