| --- Log opened Tue Oct 18 00:00:02 2016 | ||
| SMDhome | promach: be aware that lattice fpga is rather small one and i.e. has no dram controller and there is no sdram on icoBoard either | 00:35 |
|---|---|---|
| SMDhome | I would try to synth mor1kx core in first place and try PnR to see how much space is left | 00:39 |
| promach | is 8K of logic enough for openRISC plus DMA ? wait DMA is for DRAM ? | 00:40 |
| promach | SMDhome: how would I synth mor1kx ? | 00:40 |
| promach | SMDhome: I will be back for a while. Need to move to another place | 00:42 |
| SMDhome | promach: Firstly configure mor1kx_cpu.v file, and then as kc5tja told: | 00:43 |
| SMDhome | >For those wondering, you can synthesize a design with multiple Verilog components by simply listing all the components on the command-line. Throwing them all in a directory D and doing something like "yosys -p '...' D/*.v" is sufficient. | 00:43 |
| promach | SMDhome: hi | 01:42 |
| SMDhome | (07:43:58 AM) SMDhome: promach: Firstly configure mor1kx_cpu.v file, and then as kc5tja told: | 01:44 |
| SMDhome | (07:43:58 AM) SMDhome: >For those wondering, you can synthesize a design with multiple Verilog components by simply listing all the components on the command-line. Throwing them all in a directory D and doing something like "yosys -p '...' D/*.v" is sufficient. | 01:44 |
| promach | sorry, I was not logged on that time | 01:46 |
| promach | could you repost kc5tja's sentence ? | 01:48 |
| SMDhome | promach: (08:08:51 PM) kc5tja: For those wondering, you can synthesize a design with multiple Verilog components by simply listing all the components on the command-line. Throwing them all in a directory D and doing something like "yosys -p '...' D/*.v" is sufficient. | 01:49 |
| promach | what kind of configuration for mor1kx_cpu.v before synthesis ? | 01:50 |
| SMDhome | choose pipeline, features, etc | 01:50 |
| promach | could briefly point out which line number inside the verilog file ? | 01:51 |
| promach | or let me search around the mor1kx documentation if any ? | 01:52 |
| SMDhome | mor1kx_cpu.v lines from 25 till 107 | 01:52 |
| SMDhome | I think you'd better get a bit familiar with mor1kx sources before trying to synthesize it | 01:52 |
| promach | I am reading the documentation html now | 01:54 |
| promach | I am not going to synthsise right away | 01:54 |
| promach | it is not my purpose after all to just get a working CPU core | 01:54 |
| olofk | Doh! I forgot that SignalTap steals the JTAG connection so I can't use openocd at the same time | 05:53 |
| olofk | _franck_: Your or1k-tcltools worked for this, right? Can you remind me how to use them? | 05:54 |
| _franck__ | olofk: it does work but I'm not sure I remember more than you :) | 05:56 |
| _franck__ | see the readme here: https://github.com/openrisc/or1k-tcltools | 05:56 |
| olofk | Thanks | 05:56 |
| olofk | That is a first step | 05:56 |
| _franck__ | you just start signaltap trigger | 05:56 |
| _franck__ | and then download your elf. That should work | 05:57 |
| olofk | Woohoo!! It works | 06:05 |
| olofk | or maybe not... | 06:57 |
| karussellbremser | thx guys for responding to my uclibc question | 07:12 |
| karussellbremser | i'll give newlib a try then | 07:12 |
| karussellbremser | i just followed the instructions here btw: http://opencores.org/or1k/OpenRISC_GNU_tool_chain | 07:12 |
| karussellbremser | maybe they should be updated?! | 07:12 |
| ZipCPU | karusselbremser: The OpenRISC team has been struggling with those instructions. The team has left OpenCores, | 07:13 |
| ZipCPU | and the instructions left behind are now quite out of date. | 07:13 |
| karussellbremser | that's good to know | 07:13 |
| ZipCPU | I think I found more up to date instructions at openrisc.io | 07:13 |
| karussellbremser | yeah i had a look at that page already | 07:16 |
| karussellbremser | but i thought opencores would be the more relevant one | 07:16 |
| ZipCPU | Sadly, the OpenCores one is ... hopelessly out of date and no longer maintained. | 07:16 |
| ZipCPU | To make matters worse, not all of the instructions from there have been updated and moved elsewhere. | 07:16 |
| karussellbremser | while we're on it, i'm actually trying to run linux on orpsoc (preferably v3) on an atlys board...are there any instructions on building the linux and getting it on the board out there? there's http://openrisclinux.blogspot.de/ , but it's outdated because of orpsocv2, i guess | 07:17 |
| ZipCPU | It's a problem the team is aware of, but the solution has yet to fully present itself. | 07:17 |
| karussellbremser | yes a resolution to this would be very good for the project i think | 07:17 |
| ZipCPU | You'll have to hold off for that answer ... it's not one that I know. ;) | 07:17 |
| karussellbremser | np ;) | 07:18 |
| olofk | karussellbremser: You can build a SoC for Atlys with FuseSoC (which has replaced ORPSoC since a few years ago) | 07:19 |
| olofk | I no longer have an Atlys board myself, but there are other people in here who have done that not too long ago | 07:20 |
| karussellbremser | isn't fusesoc a build tool? i think i used it when building orpsocv3 for the atlys | 07:20 |
| karussellbremser | so how can it replace orpsoc | 07:21 |
| olofk | karussellbremser: Yes, you're absolutely right | 07:21 |
| olofk | orpsoc was more of an integrated environment | 07:21 |
| olofk | orpsoc was also capable of building bare-metal drivers for some targets | 07:22 |
| olofk | But for just building the FPGA image, FuseSoC will do the job | 07:22 |
| olofk | There is an Atlys system definition in the standard core library | 07:22 |
| karussellbremser | i have already built the orpsocv3 for the atlys board successfully, wouldn't you recommend to use that? my problem is only to build linux and run it on the board running orpsoc | 07:26 |
| karussellbremser | i'm totally new to processor / soc stuff, so i may talk garbage, please forgive | 07:26 |
| karussellbremser | thx already btw, this seems to be a very helpful and friendly channel | 07:28 |
| _franck__ | karussellbremser: if you have working bitstream for your Atlys board you're ready to run Linux | 07:30 |
| _franck__ | and you don't need the newlib toolchain. The baremetal toolhchain is enough | 07:30 |
| olofk | _franck_: A typo? :) | 07:34 |
| olofk | newlib is the baremetal toolchain | 07:34 |
| _franck__ | my brain read uclibc | 07:35 |
| olofk | I suspected that :) | 07:35 |
| _franck__ | thanks olofk | 07:35 |
| _franck__ | olofk: so, did or1k-tcltools downloaded your elf file ? | 07:36 |
| olofk | _franck__: Yes, it worked, and signaltap was triggered when I did that | 07:39 |
| olofk | But I did not get any data, so there is still something wrong | 07:40 |
| olofk | Maybe the download triggers a reset of some kind | 07:40 |
| _franck__ | I think what I did was to push the reset button of my board (putting the core halted), download the elf using or1k-tcltools then start signaltap trigger then release the reset button | 07:41 |
| olofk | I can see on the uart that the program is running | 07:42 |
| olofk | karussellbremser: Did you get what you needed, or are you still looking for help? | 08:15 |
| karussellbremser | i have just started installing the newlib toolchain ;) | 08:16 |
| karussellbremser | i will report if i get what i want | 08:17 |
| olofk | Great | 08:17 |
| ZipCPU | olofk: Got a moment to help me out with a fusesoc core? I'm trying to build the core for wbuart32--the TCP/IP enabled uart simulating core. | 09:23 |
| ZipCPU | I've got a [fileset rtl] section, with a files= and a file_type=verilogSource. | 09:23 |
| ZipCPU | Where I'm struggling is with the Verilator. | 09:24 |
| ZipCPU | For Verilator, I have two types of files: C++ and more Verilog. | 09:24 |
| ZipCPU | The core can be built as a stand-alone test bench, but it is also designed to be incorporated into other (larger) projects. | 09:24 |
| ZipCPU | How shall I note the difference between the two sets of Verilog and C++ files? | 09:25 |
| ZipCPU | olofk: Here's the file I'm discussing: https://github.com/ZipCPU/wbuart32/blob/master/wbuart32.core | 09:32 |
| karussellbremser | i think i need some hints concerning the linux build (i still want to run linux on an atlys board with orpsocv3) | 10:29 |
| karussellbremser | first, is this: https://github.com/openrisc/linux the correct and not outdated repository for this purpose? | 10:30 |
| karussellbremser | i'm skeptical because during make procedure it complains that or32-linux-gcc command is not found, which - to my understanding - refers to an old toolchain | 10:31 |
| karussellbremser | also, why does this repository not contain targets for the atlys board, only for de0 nano? according to http://openrisclinux.blogspot.de/ an older version of the linux repo had atlys support | 10:33 |
| karussellbremser | the toolchain installation with newlib was successful, btw | 10:34 |
| shorne | https://stffrdhrn.github.io/openrisc.github.io/architecture | 11:02 |
| shorne | any comments on this revision structure? | 11:02 |
| -!- Netsplit *.net <-> *.split quits: kc5tja, eliask, _franck_ | 13:33 | |
| -!- Netsplit over, joins: kc5tja | 13:33 | |
| -!- Netsplit over, joins: _franck_ | 13:33 | |
| karussellbremser | by now, i have built the linux, but i still miss some non-outdated tutorial for getting it onto an atlys board (or xilinx in general) with orpsocv3, preferably not using linux as the bootloader. everything i've read so far in this direction was outdated. maybe i'm missing something? either way, some help would be great. i guess it's only a few commands, anyway | 14:55 |
| olofk | ZipCPU: So linetest.v is only for the verilator testbench? | 16:19 |
| ZipCPU | That's correct. | 16:19 |
| olofk | Remove it from src_fies (typo btw) and put it in a separate fileset where you also set "usage=verilator" | 16:20 |
| olofk | Also move the header files from src_files to include_files in the verilator fileset. That will have the side effect that their directories are added to the include path automatically | 16:21 |
| ZipCPU | Ok. | 16:22 |
| olofk | Do you need Makefile to be exported to the build directory? FuseSoC won't use it for anything automatically, but maybe you want to run it later? | 16:22 |
| olofk | Ah, you already have linetest.v in tb_files. Just add the usage flag to that section then | 16:23 |
| ZipCPU | Well ... that's a question. There are two makefiles within the project. One builds the Verilator code into Verilator libraries, another uses that code to build the test bench. | 16:23 |
| ZipCPU | Neither would be appopriately used if the core were a component. | 16:23 |
| olofk | hmm | 16:23 |
| ZipCPU | Ok, got the tb_files ... was going to ask that. | 16:23 |
| olofk | Could you elaborate a bit on the two makefiles. Not sure I understand yet | 16:24 |
| ZipCPU | Sure, but first it looks like I have my count wrong: there are 5 makefiles. (Ouch!) | 16:25 |
| ZipCPU | One builds the documentation, that's in doc/. | 16:25 |
| olofk | haha | 16:25 |
| ZipCPU | A second one is in the rtl/ directory. This one calls verilator and makes a verilated library of the rtl code. | 16:25 |
| ZipCPU | A third one is in bench/verilog and does the same as the rtl/ one, save that it includes the linetest.v source as the main file. | 16:26 |
| ZipCPU | The fourth one is in bench/cpp. This references the library built by the bench/verilog Makefile, to build a C++ testbench with verilator. | 16:26 |
| ZipCPU | The final one is in the main directory, and it tries to do ... everything. | 16:27 |
| ZipCPU | Neither of these would be needed as components, but they are needed to build the testbench that proves everything works. | 16:27 |
| olofk | The verilator flow in FuseSoC builds the RTL and c++ to one binary | 16:27 |
| olofk | So if we start with the stand-alone flow | 16:27 |
| olofk | Hopefully you should be almost there | 16:28 |
| olofk | Depending on how much magic is going on in your makefile | 16:28 |
| ZipCPU | Well ... hold on, I may have confused things. The Makefile's are needed to build my own testbench. They are probably not needed to build any test benches, were the code to be included as a component. | 16:28 |
| ZipCPU | (There's not much magic in the makefiles.) | 16:28 |
| olofk | I | 16:29 |
| olofk | 'm cloning the repo to see for myself too | 16:29 |
| ZipCPU | Ok, but I just updated the core file with our discussion. | 16:30 |
| olofk | Are you checking it in? Otherwise I do similar changes here on my side | 16:30 |
| ZipCPU | Yes, I checked it in--to be certain you could get it. | 16:31 |
| olofk | Another detail. You don't want linetest.v to be visible when the core is used as part of a bigger project? | 16:31 |
| olofk | cool. I'll get it | 16:31 |
| ZipCPU | olofk: Yes, that's it. linetest.v is only used for the testbench to proves the core works. | 16:33 |
| olofk | Right. Then you can set scope=private for the fileset it is in | 16:34 |
| olofk | ok, got the verilator model building with a few more changes | 16:36 |
| olofk | But the c++ tb fails. I think you're getting hit by a quite recent change in verilator | 16:36 |
| olofk | Which version are you on? | 16:36 |
| ZipCPU | Ok, scope=private. | 16:37 |
| ZipCPU | I'm using Verilator 3.856 | 16:38 |
| ZipCPU | Does the c++ tb make fine with the make files, just not fusesoc? | 16:39 |
| olofk | The problem is that they changed the api a few versions ago | 16:39 |
| olofk | Previously the toplevel was called v | 16:39 |
| olofk | So you could reach things with v.toplevel.sublevel.. etc | 16:40 |
| olofk | But there's a slight difference now | 16:40 |
| ZipCPU | Ok, let me just comment out linse 210-223 of linetest.cpp, and then it should build. | 16:40 |
| ZipCPU | (They're only needed for debugging anyway ...) | 16:40 |
| ZipCPU | Want to try that change and see if it helps? | 16:41 |
| olofk | Succesfully read 31 characters :) | 16:41 |
| olofk | This is a UART test string | 16:41 |
| ZipCPU | SCORE!!!! | 16:41 |
| olofk | ok, so there are a few changes to be made to the core file, and it will work for standalone builds at least | 16:42 |
| ZipCPU | The core file still needs changes? | 16:43 |
| ZipCPU | Oh, yeah, the ones you mentioned. I think I've got those made, | 16:43 |
| ZipCPU | just not checked in yet. | 16:43 |
| olofk | The src_files section can be removed. FuseSoC will pick up the files listed in [verilator] src_files | 16:43 |
| ZipCPU | Ah, good, okay. | 16:43 |
| olofk | Need full path to linetest.cpp (i.e. bench/cpp/linetest.cpp) | 16:44 |
| olofk | That should be it | 16:44 |
| ZipCPU | Do I need a full path to linetest (the executable) as well? | 16:44 |
| olofk | Haven't got a good idea yet how to deal with the verilator API change yet unfortunately :/ | 16:44 |
| olofk | You mean top_module? | 16:44 |
| ZipCPU | For this code, I do: comment out the lines depending upon it. | 16:44 |
| ZipCPU | Yes, top_module. | 16:44 |
| olofk | No, that's just to inform verilator of the name of the verilog toplevel module. | 16:45 |
| ZipCPU | Ok, I updated the repository. Should (now) be completely golden. | 16:46 |
| olofk | I'll test | 16:47 |
| olofk | Works fine! | 16:47 |
| olofk | So then the stand alone flow is complete | 16:48 |
| ZipCPU | The next part is the integration into mor1kx. | 16:48 |
| olofk | Which part do we need then? | 16:49 |
| olofk | The rtl code. Any cpp files? | 16:49 |
| ZipCPU | One file of each: RTL and CPP. | 16:49 |
| olofk | I honestly have forgotten a bit how this works | 16:51 |
| olofk | I know that stekern and _franck_ helped me out with the C++ stuff some years ago | 16:51 |
| ZipCPU | Here's the adjusted tb.cpp: https://dpaste.de/AZCG#L5 | 16:51 |
| olofk | The rtl files is no problem. They will be picked up automatically | 16:52 |
| ZipCPU | Not quite, there were some changes that needed to be made to the mor1kx-generic top level RTL file. | 16:52 |
| ZipCPU | As I recall, the UART wasn't brought to the top like it needed to be. | 16:52 |
| olofk | Ah yes. I'm talking about your .core file | 16:53 |
| olofk | The mor1kx-generic files need some love too, as you say | 16:54 |
| ZipCPU | Sorry. Looks like I got ahead of you. | 16:54 |
| olofk | My mouse cursor is gone, so I'm trying to do stuff by keyboard only | 16:55 |
| ZipCPU | Learn to love "vi" ;P | 16:55 |
| olofk | Emacs has a better web browser :) | 16:56 |
| olofk | Actually, looking at some similar structures, like how elf-loader is used in mor1kx-generic, I think that the src_files in the verilator section are picked up automatically too | 16:57 |
| kc5tja | Egads, lots of scrollback. | 16:58 |
| ZipCPU | kc5tja: Someone was asking about your CPU on #riscv. You might wish to start there first. | 16:58 |
| kc5tja | I will in a bit. Still at the office hacking and stuff. | 16:59 |
| olofk | ZipCPU: I can't make the mor1kx-generic testbench find uartsim.h. Most likely a bug or feature that I forgot about | 17:09 |
| ZipCPU | Is there anything I can do to help, or is the ball in your court at this point? | 17:10 |
| olofk | ZipCPU: I'm afraid it's deep down in the messy verilator internals in FuseSoC | 17:11 |
| olofk | Which is a part that has been in need of some cleanup for a while, and that might contains some surprises | 17:12 |
| olofk | But it's good that we got the stand alone flow working at least | 17:12 |
| ZipCPU | Ok, I'll stand by until you tell me otherwise. | 17:13 |
| olofk | whoops. For got to add a dependency on wbuart32 :) | 17:20 |
| olofk | Yes! It's building now | 17:21 |
| olofk | With another change | 17:21 |
| olofk | And haven't tested if it actually works either | 17:21 |
| olofk | But still. A great success | 17:21 |
| olofk | bench/cpp/linetest.cpp must be removed from src_files | 17:22 |
| olofk | Otherwise it will be picked up by mor1kx-generic, which will fail since it can't find Vlinetest.h | 17:22 |
| olofk | Running wbuart32 stand-alone will still work as it's listed in tb_toplevel | 17:23 |
| olofk | It's a bit messy, but these things predate the fileset sections | 17:23 |
| olofk | Time to sleep now | 17:26 |
| olofk | karussellbremser: We'll take care of you tomorrow :) | 17:27 |
| --- Log closed Wed Oct 19 00:00:03 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!