IRC logs for #openrisc Tuesday, 2016-10-18

--- Log opened Tue Oct 18 00:00:02 2016
SMDhomepromach: be aware that lattice fpga is rather small one and i.e. has no dram controller and there is no sdram on icoBoard either00:35
SMDhomeI would try to synth mor1kx core in first place and try PnR to see how much space is left00:39
promachis 8K of logic enough for openRISC plus DMA ? wait DMA is for DRAM ?00:40
promachSMDhome: how would I synth mor1kx ?00:40
promachSMDhome: I will be back for a while. Need to move to another place00:42
SMDhomepromach: 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
promachSMDhome: hi01: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
promachsorry, I was not logged on that time01:46
promachcould you repost kc5tja's sentence ?01:48
SMDhomepromach: (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
promachwhat kind of configuration for mor1kx_cpu.v before synthesis ?01:50
SMDhomechoose pipeline, features, etc01:50
promachcould briefly point out which line number inside the verilog file ?01:51
promachor let me search around the mor1kx documentation if any ?01:52
SMDhomemor1kx_cpu.v lines from 25 till 10701:52
SMDhomeI think you'd better get a bit familiar with mor1kx sources before trying to synthesize it01:52
promachI am reading the documentation html now01:54
promachI am not going to synthsise right away01:54
promachit is not my purpose after all to just get a working CPU core01:54
olofkDoh! I forgot that SignalTap steals the JTAG connection so I can't use openocd at the same time05: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:
olofkThat is a first step05:56
_franck__you just start signaltap trigger05:56
_franck__and then download your elf. That should work05:57
olofkWoohoo!! It works06:05
olofkor maybe not...06:57
karussellbremserthx guys for responding to my uclibc question07:12
karussellbremseri'll give newlib a try then07:12
karussellbremseri just followed the instructions here btw:
karussellbremsermaybe they should be updated?!07:12
ZipCPUkarusselbremser: The OpenRISC team has been struggling with those instructions.  The team has left OpenCores,07:13
ZipCPUand the instructions left behind are now quite out of date.07:13
karussellbremserthat's good to know07:13
ZipCPUI think I found more up to date instructions at openrisc.io07:13
karussellbremseryeah i had a look at that page already07:16
karussellbremserbut i thought opencores would be the more relevant one07:16
ZipCPUSadly, the OpenCores one is ... hopelessly out of date and no longer maintained.07:16
ZipCPUTo make matters worse, not all of the instructions from there have been updated and moved elsewhere.07:16
karussellbremserwhile 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 , but it's outdated because of orpsocv2, i guess07:17
ZipCPUIt's a problem the team is aware of, but the solution has yet to fully present itself.07:17
karussellbremseryes a resolution to this would be very good for the project i think07:17
ZipCPUYou'll have to hold off for that answer ... it's not one that I know.  ;)07:17
karussellbremsernp ;)07:18
olofkkarussellbremser: You can build a SoC for Atlys with FuseSoC (which has replaced ORPSoC since a few years ago)07:19
olofkI no longer have an Atlys board myself, but there are other people in here who have done that not too long ago07:20
karussellbremserisn't fusesoc a build tool? i think i used it when building orpsocv3 for the atlys07:20
karussellbremserso how can it replace orpsoc07:21
olofkkarussellbremser: Yes, you're absolutely right07:21
olofkorpsoc was more of an integrated environment07:21
olofkorpsoc was also capable of building bare-metal drivers for some targets07:22
olofkBut for just building the FPGA image, FuseSoC will do the job07:22
olofkThere is an Atlys system definition in the standard core library07:22
karussellbremseri 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 orpsoc07:26
karussellbremseri'm totally new to processor / soc stuff, so i may talk garbage, please forgive07:26
karussellbremserthx already btw, this seems to be a very helpful and friendly channel07:28
_franck__karussellbremser: if you have working bitstream for your Atlys board you're ready to run Linux07:30
_franck__and you don't need the newlib toolchain. The baremetal toolhchain is enough07:30
olofk_franck_: A typo? :)07:34
olofknewlib is the baremetal toolchain07:34
_franck__my brain read uclibc07:35
olofkI suspected that :)07:35
_franck__thanks olofk07: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 that07:39
olofkBut I did not get any data, so there is still something wrong07:40
olofkMaybe the download triggers a reset of some kind07: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 button07:41
olofkI can see on the uart that the program is running07:42
olofkkarussellbremser: Did you get what you needed, or are you still looking for help?08:15
karussellbremseri have just started installing the newlib toolchain ;)08:16
karussellbremseri will report if i get what i want08:17
ZipCPUolofk: 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
ZipCPUI've got a [fileset rtl] section, with a files= and a file_type=verilogSource.09:23
ZipCPUWhere I'm struggling is with the Verilator.09:24
ZipCPUFor Verilator, I have two types of files: C++ and more Verilog.09:24
ZipCPUThe core can be built as a stand-alone test bench, but it is also designed to be incorporated into other (larger) projects.09:24
ZipCPUHow shall I note the difference between the two sets of Verilog and C++ files?09:25
ZipCPUolofk: Here's the file I'm discussing:
karussellbremseri think i need some hints concerning the linux build (i still want to run linux on an atlys board with orpsocv3)10:29
karussellbremserfirst, is this: the correct and not outdated repository for this purpose?10:30
karussellbremseri'm skeptical because during make procedure it complains that or32-linux-gcc command is not found, which - to my understanding - refers to an old toolchain10:31
karussellbremseralso, why does this repository not contain targets for the atlys board, only for de0 nano? according to an older version of the linux repo had atlys support10:33
karussellbremserthe toolchain installation with newlib was successful, btw10:34
shorneany comments on this revision structure?11:02
-!- Netsplit *.net <-> *.split quits: kc5tja, eliask, _franck_13:33
-!- Netsplit over, joins: kc5tja13:33
-!- Netsplit over, joins: _franck_13:33
karussellbremserby 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, anyway14:55
olofkZipCPU: So linetest.v is only for the verilator testbench?16:19
ZipCPUThat's correct.16:19
olofkRemove it from src_fies (typo btw) and put it in a separate fileset where you also set "usage=verilator"16:20
olofkAlso 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 automatically16:21
olofkDo 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
olofkAh, you already have linetest.v in tb_files. Just add the usage flag to that section then16:23
ZipCPUWell ... 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
ZipCPUNeither would be appopriately used if the core were a component.16:23
ZipCPUOk, got the tb_files ... was going to ask that.16:23
olofkCould you elaborate a bit on the two makefiles. Not sure I understand yet16:24
ZipCPUSure, but first it looks like I have my count wrong: there are 5 makefiles.  (Ouch!)16:25
ZipCPUOne builds the documentation, that's in doc/.16:25
ZipCPUA second one is in the rtl/ directory.  This one calls verilator and makes a verilated library of the rtl code.16:25
ZipCPUA 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
ZipCPUThe 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
ZipCPUThe final one is in the main directory, and it tries to do ... everything.16:27
ZipCPUNeither of these would be needed as components, but they are needed to build the testbench that proves everything works.16:27
olofkThe verilator flow in FuseSoC builds the RTL and c++ to one binary16:27
olofkSo if we start with the stand-alone flow16:27
olofkHopefully you should be almost there16:28
olofkDepending on how much magic is going on in your makefile16:28
ZipCPUWell ... 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'm cloning the repo to see for myself too16:29
ZipCPUOk, but I just updated the core file with our discussion.16:30
olofkAre you checking it in? Otherwise I do similar changes here on my side16:30
ZipCPUYes, I checked it in--to be certain you could get it.16:31
olofkAnother detail. You don't want linetest.v to be visible when the core is used as part of a bigger project?16:31
olofkcool. I'll get it16:31
ZipCPUolofk: Yes, that's it.  linetest.v is only used for the testbench to proves the core works.16:33
olofkRight. Then you can set scope=private for the fileset it is in16:34
olofkok, got the verilator model building with a few more changes16:36
olofkBut the c++ tb fails. I think you're getting hit by a quite recent change in verilator16:36
olofkWhich version are you on?16:36
ZipCPUOk, scope=private.16:37
ZipCPUI'm using Verilator 3.85616:38
ZipCPUDoes the c++ tb make fine with the make files, just not fusesoc?16:39
olofkThe problem is that they changed the api a few versions ago16:39
olofkPreviously the toplevel was called v16:39
olofkSo you could reach things with v.toplevel.sublevel.. etc16:40
olofkBut there's a slight difference now16:40
ZipCPUOk, 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
ZipCPUWant to try that change and see if it helps?16:41
olofkSuccesfully read 31 characters :)16:41
olofkThis is a UART test string16:41
olofkok, so there are a few changes to be made to the core file, and it will work for standalone builds at least16:42
ZipCPUThe core file still needs changes?16:43
ZipCPUOh, yeah, the ones you mentioned.  I think I've got those made,16:43
ZipCPUjust not checked in yet.16:43
olofkThe src_files section can be removed. FuseSoC will pick up the files listed in [verilator] src_files16:43
ZipCPUAh, good, okay.16:43
olofkNeed full path to linetest.cpp (i.e. bench/cpp/linetest.cpp)16:44
olofkThat should be it16:44
ZipCPUDo I need a full path to linetest (the executable) as well?16:44
olofkHaven't got a good idea yet how to deal with the verilator API change yet unfortunately :/16:44
olofkYou mean top_module?16:44
ZipCPUFor this code, I do: comment out the lines depending upon it.16:44
ZipCPUYes, top_module.16:44
olofkNo, that's just to inform verilator of the name of the verilog toplevel module.16:45
ZipCPUOk, I updated the repository.  Should (now) be completely golden.16:46
olofkI'll test16:47
olofkWorks fine!16:47
olofkSo then the stand alone flow is complete16:48
ZipCPUThe next part is the integration into mor1kx.16:48
olofkWhich part do we need then?16:49
olofkThe rtl code. Any cpp files?16:49
ZipCPUOne file of each: RTL and CPP.16:49
olofkI honestly have forgotten a bit how this works16:51
olofkI know that stekern and _franck_ helped me out with the C++ stuff some years ago16:51
ZipCPUHere's the adjusted tb.cpp:
olofkThe rtl files is no problem. They will be picked up automatically16:52
ZipCPUNot quite, there were some changes that needed to be made to the mor1kx-generic top level RTL file.16:52
ZipCPUAs I recall, the UART wasn't brought to the top like it needed to be.16:52
olofkAh yes. I'm talking about your .core file16:53
olofkThe mor1kx-generic files need some love too, as you say16:54
ZipCPUSorry.  Looks like I got ahead of you.16:54
olofkMy mouse cursor is gone, so I'm trying to do stuff by keyboard only16:55
ZipCPULearn to love "vi" ;P16:55
olofkEmacs has a better web browser :)16:56
olofkActually, 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 too16:57
kc5tjaEgads, lots of scrollback.16:58
ZipCPUkc5tja: Someone was asking about your CPU on #riscv.  You might wish to start there first.16:58
kc5tjaI will in a bit.  Still at the office hacking and stuff.16:59
olofkZipCPU: I can't make the mor1kx-generic testbench find uartsim.h. Most likely a bug or feature that I forgot about17:09
ZipCPUIs there anything I can do to help, or is the ball in your court at this point?17:10
olofkZipCPU: I'm afraid it's deep down in the messy verilator internals in FuseSoC17:11
olofkWhich is a part that has been in need of some cleanup for a while, and that might contains some surprises17:12
olofkBut it's good that we got the stand alone flow working at least17:12
ZipCPUOk, I'll stand by until you tell me otherwise.17:13
olofkwhoops. For got to add a dependency on wbuart32 :)17:20
olofkYes! It's building now17:21
olofkWith another change17:21
olofkAnd haven't tested if it actually works either17:21
olofkBut still. A great success17:21
olofkbench/cpp/linetest.cpp must be removed from src_files17:22
olofkOtherwise it will be picked up by mor1kx-generic, which will fail since it can't find Vlinetest.h17:22
olofkRunning wbuart32 stand-alone will still work as it's listed in tb_toplevel17:23
olofkIt's a bit messy, but these things predate the fileset sections17:23
olofkTime to sleep now17:26
olofkkarussellbremser: We'll take care of you tomorrow :)17:27
--- Log closed Wed Oct 19 00:00:03 2016

Generated by 2.15.2 by Marius Gedminas - find it at!