--- Log opened Mon May 30 00:00:29 2016 | ||
jeremybennett | shorne: I haven't been following the whole conversation. Is it that you want to upstream GDB with the Or1ksim integration. | 05:29 |
---|---|---|
jeremybennett | I have no problem with my or1ksim work going to the FSF (I have the necessary FSF paperwork in place). However most of Or1ksim predates me, so you'd need those authors' permission as well. | 05:30 |
LoneTech | I'm tempted to try getting libgomp openmp 4 or Cray Chapel offloading to run on the Epiphany | 05:52 |
olof | jeremybennett: It's the other way around. We want to push gdb with the regular sim backend | 06:24 |
olof | To avoid the or1ksim dependency for the upstream code | 06:24 |
jeremybennett | olof: Much better idea. In which case you don't need to worry about or1ksim. | 06:38 |
olof | jeremybennett: I think that shorne mainly wanted your blessing for removing the or1ksim stuff when we push it upstream | 06:46 |
jeremybennett | olof: shorne: That's fine by me | 06:50 |
olof | thanks jeremybennett | 06:51 |
shorne | jeremybennett: its that we now have 2 simulators in gdb 1. the cgen based simulator completely housed in gdb, 2. the or1ksim which depends on the externel libsim provided by or1ksim. | 07:52 |
shorne | We were thinking that to upstream gdb we would go with the internal cgen version, that way gdb doesnt have gnu external dependencies | 07:53 |
shorne | olof: thanks for already explaining | 07:54 |
shorne | jeremybennett: thanks I missed your reply at first | 07:54 |
stolar | wallento: shorne: or anyone know how to switch off multiplier ( ~ Unit responsible for multiplication) in or1ksim or openrisc? I think it is related with Arithmetic Logic Unit. | 11:36 |
tariq786 | can anyone tell me what is the bare minimum openrisc i need to run linux on top of it? | 12:37 |
-!- tariq786 is now known as kaaliakahn | 12:38 | |
GeneralStupid | kaaliakahn: one ? | 12:41 |
olofk | kaaliakahn: As I said yesterday, you need a CPU, memory controller and UART | 12:43 |
kaaliakahn | Olofk: where can i get these 3 things or should i make my own | 12:44 |
olofk | If you have an Atlys board, we have a preconfigured system you can build with FuseSoC | 12:44 |
kaaliakahn | olofk: I want to do bottom up approach | 12:44 |
kaaliakahn | I don't have an idea about RISC architecture. I want to learn it as well. | 12:45 |
kaaliakahn | so please suggest a custom approach such that after following it, I can contribute like you guys are doing | 12:45 |
olofk | kaaliakahn: Then I would recommend that you start with some simpler system that won't necessarily run Linux | 12:45 |
kaaliakahn | but first i need to learn this giant system | 12:45 |
kaaliakahn | yes sure | 12:45 |
kaaliakahn | running linux can be the next step | 12:46 |
kaaliakahn | where do i get started then | 12:46 |
olofk | If you just want to study the CPU, you can run simulations with small compiled programs | 12:46 |
olofk | You can do that either on simulated RTL code, or in the C simulator | 12:47 |
kaaliakahn | so lets break it down bottom up and make sure it is doable | 12:47 |
kaaliakahn | so here is what i am thinking. | 12:47 |
kaaliakahn | study cpu, simulate cpu, cpu + mem controller, cpu + mem controller simulation, cpu + mem controller + uart, simulation of the former | 12:48 |
olofk | You will need some kind of memory connected to the CPU so that the CPU can load and run a program | 12:49 |
olofk | So the minimum configuration would be cpu + mem controller | 12:49 |
olofk | This is basically the mor1kx-generic SoC that you can find in the FuseSoC library | 12:50 |
kaaliakahn | olofk: sure. I am thinking to make a tutorial along the way so beginners like me can follow that | 12:50 |
olofk | It is meant to be a bare minimum simulation environment | 12:50 |
kaaliakahn | or is there a tutorial like this from baby steps to giant steps | 12:50 |
olofk | kaaliakahn: Absolutely agree. We are aware of the lack of tutorials to get started :/ | 12:51 |
olofk | But we are trying to rectify this now https://github.com/openrisc/tutorials/ | 12:51 |
olofk | It's not that much yet though | 12:51 |
kaaliakahn | I am happy to do that. But please help me get the momentum | 12:51 |
kaaliakahn | so where do i find the cpu + mem controller? | 12:51 |
olofk | If you just need a memory controller for simulation, you can use this one https://github.com/openrisc/orpsoc-cores/tree/master/cores/wb_ram | 12:52 |
olofk | And for the CPU we use mor1kx https://github.com/openrisc/mor1kx/ | 12:52 |
olofk | And if you want to see a top-level that binds it all together, I recommend that you take a look at the mor1kx-generic system here https://github.com/openrisc/orpsoc-cores/tree/master/systems/mor1kx-generic | 12:53 |
olofk | You will need to download and install the toolchain to be able to compile your own programs too. Have you done that? | 12:54 |
kaaliakahn | olofk: As you recall, I remained in the RTL only world | 12:54 |
kaaliakahn | olofk: so please clarify a few things for me as they confuse a hell lot of me | 12:55 |
kaaliakahn | ;) | 12:55 |
olofk | ah yes, right. There is a whole lot of software to this as well :) | 12:55 |
olofk | sure | 12:55 |
kaaliakahn | ok lets go one by one. You earlier wrote a few minutes ago | 12:55 |
kaaliakahn | "If you just want to study the CPU, you can run simulations with small compiled programs. You can either do that on simulated RTL code or C simulator" | 12:56 |
kaaliakahn | What i know and have done is RTL verilog with RTL test bench and thats it. For example CPU dut in verilog and its testbench in verilog as well | 12:57 |
olofk | Yep. We have that option | 12:57 |
kaaliakahn | what does compiled program means in the context of cpu and what is C simulation? | 12:57 |
kaaliakahn | how do you explain this to a RTL guy who lived in RTL cave :) | 12:58 |
olofk | Let me try :) | 12:58 |
olofk | When you compile your code with the OpenRISC compiler, you get an executable file. | 12:59 |
olofk | This file can be run on a real OpenRISC system running in an FPGA or an ASIC | 13:00 |
olofk | Or we can run it in an emulator | 13:00 |
olofk | The C simulator that I mentioned before is called or1ksim. It's an emulator (written in C) that can load an OpenRISC executable on your PC just as if it would be running on a real OpenRISC | 13:01 |
olofk | But we can forget about that for now, since what you're likely is interested in is running verilog simualations | 13:01 |
olofk | Questions so far? :) | 13:02 |
kaaliakahn | ok. It means there are two separate things. One is developing OpenRISC in RTL and one is developing applications that run on openRISC. Right? The former is purely RTL. The latter is C programming cross compiled with openrisc compiler. Correct? | 13:02 |
olofk | Correct | 13:03 |
kaaliakahn | did i use the term cross compiler correctly? :) | 13:03 |
olofk | Yes, you did :) | 13:03 |
kaaliakahn | hmm | 13:03 |
kaaliakahn | olofk: I am interested in both and that is the goal. First understand OpenRISC RTL then the compiler and then run the two together | 13:04 |
olofk | So now we want to run our cross-compiled program on the RTL code in a simulator such as modelsim or icarus | 13:04 |
kaaliakahn | so lets now plan a tutorial that goes bottom up approach | 13:04 |
olofk | Sure. Understanding the compiler isn't something I would recommend though :) | 13:04 |
kaaliakahn | hang on. I have a question | 13:05 |
kaaliakahn | so you are recommending running cross compiled programs on RTL code in Model Sim? How is it different from running a verilog testbench. I am wondering what would this simulation show? | 13:06 |
kaaliakahn | and how do you interface cross compiled programs with RTL? assuming cross compiled program acts as Testbench for RTL? | 13:07 |
kaaliakahn | I am not worried about compiler. It does what it is supposed to do GIGO (garbage in, garabage out) :) | 13:08 |
olofk | What we do in the testbench is that we preload a memory with an OpenRISC executable, and when we release the reset, the simulated CPU will start fetching instructions from that memory | 13:09 |
kaaliakahn | ok. So its like readmem kind of thing? | 13:10 |
olofk | Yes, more or less | 13:10 |
kaaliakahn | ok. I am good so far. Is this what you recommend as the first step? | 13:10 |
olofk | But with FuseSoC we can load an executable file directly into the testbench with some VPI magic | 13:10 |
olofk | Yes, I think that's a good first step | 13:11 |
olofk | And the mor1kx-generic SoC that I pointed out before has all the facilities to do that for you | 13:11 |
olofk | I somewhat expect that there will be several things that could need some more explaining before you're up to speed | 13:12 |
kaaliakahn | just to confirm, it is this one https://github.com/openrisc/mor1kx/ ?? | 13:12 |
olofk | That's the CPU | 13:12 |
kaaliakahn | ok | 13:13 |
kaaliakahn | but dont you think, one needs to understand CPU and then the mem controller before going to generic SoC? | 13:14 |
kaaliakahn | I am trying to come up with table of contents for the tutorial. | 13:14 |
kaaliakahn | like part 1, part 2, part 3, ... | 13:14 |
kaaliakahn | going from baby steps to giant steps | 13:15 |
SMDwrk | kaaliakahn: ask wallento about tutorial | 13:15 |
olofk | The mor1kx-generic SoC is a basic SoC just for this kind of purpose | 13:15 |
olofk | It's not possible to run the mor1kx-generic SoC on real HW. Only in simulations | 13:15 |
kaaliakahn | why? | 13:15 |
kaaliakahn | olofk: Where is the documenation for mor1kx-generic | 13:17 |
olofk | Because it uses a very basic memory controller that wouldn't be possible to implement in an FPGA | 13:17 |
olofk | Well, here's the fun part. There isn't really any documentation | 13:17 |
kaaliakahn | SMDwrk: tutorial on what specific topic that wallento might be able to help? | 13:18 |
olofk | Which sucks of course | 13:18 |
kaaliakahn | olofk: wow | 13:18 |
SMDwrk | ask him, I don't know for sure | 13:18 |
SMDwrk | I decided to read mor1kx code and let others do their soc magic | 13:19 |
kaaliakahn | olofk: No worries. I will try to document it | 13:19 |
kaaliakahn | guys you are doing amazing job in development but some what slacking in documentation | 13:19 |
SMDwrk | as always | 13:20 |
kaaliakahn | ;) | 13:20 |
SMDwrk | kaaliakahn: speaking of documentation, what are you going to do? I mean which part of it | 13:20 |
kaaliakahn | may be i can chip in my 2 cens here | 13:20 |
olofk | Yeah, we're not proud of the situation :/ | 13:20 |
olofk | gtg | 13:20 |
kaaliakahn | SMDwrk: I am going to understand how SoC works and document it for beginners | 13:20 |
kaaliakahn | in a step by step manner | 13:21 |
kaaliakahn | and that is what i was talking to olofk | 13:21 |
kaaliakahn | about | 13:21 |
SMDwrk | I'm going to deal with mor1kx rtl sources, make pipeline scheme and so on | 13:21 |
SMDwrk | kaaliakahn: in that case you really should talk to wallento, IIRC he had same plans as you | 13:21 |
kaaliakahn | SMDwrk: It seems you know the RTL source code | 13:22 |
kaaliakahn | what does IIRC mean :) | 13:22 |
SMDwrk | if i remember correctly | 13:22 |
kaaliakahn | I am going to message him. But as you said you are going to make drawings of the pipeline. | 13:22 |
SMDwrk | kaaliakahn: I'm struggling to know it) | 13:22 |
kaaliakahn | hmm | 13:23 |
SMDwrk | yep, that's my plan. But it relates only to cpu-core, not soc all in all | 13:23 |
kaaliakahn | so we are in the same boat in a stormy weather ;) | 13:23 |
kaaliakahn | are you talking about the mor1kx-generic-soc ? | 13:24 |
SMDwrk | I use it to run my binaries, yes | 13:24 |
kaaliakahn | what exactly are those binaries? I mean what programs? | 13:24 |
SMDwrk | Let's say dhrystone. I use baremetal toolchain, dhrystone sources, compile it to elf and then run it on simulator | 13:26 |
kaaliakahn | ok. so benchmarks | 13:26 |
kaaliakahn | ok. I know my work to do | 13:27 |
kaaliakahn | can you explain what is baremetal toolchain? | 13:27 |
SMDwrk | I'm interested it perfomance mostly, so I'll try to improve mor1kx one | 13:28 |
SMDwrk | Correct me plz, but baremetal toolchain differs from linux one in c library, which is used. | 13:29 |
kaaliakahn | i think it differs in the compiler itself | 13:36 |
kaaliakahn | it wont use gcc, it would use arm-gcc instead | 13:36 |
kaaliakahn | as an example | 13:36 |
kaaliakahn | http://stackoverflow.com/questions/28963427/preparing-gnu-toolchain-for-bare-metal-arm-on-linux | 13:37 |
kaaliakahn | the answer is quite good | 13:37 |
SMDwrk | Firstly we use cross-compilation: with given toolchain you compile binary file on x86 machine for orisk arch. | 13:38 |
SMDwrk | Then with cross-compiler you can compile binary in elf format either for linux, or for baremetal usage. | 13:39 |
kaaliakahn | ok | 13:40 |
SMDwrk | Let's say you use printf() in your c prog. In case of baremetal toolchain it will call printf implementation which will send data to the uart port, while using linux toolchain it will somehow use existing linux stdio | 13:40 |
SMDwrk | So the difference is, as I see it, in standart c library | 13:41 |
kaaliakahn | yeah that is correct | 13:42 |
kaaliakahn | but remember compiler is also different as i said and its compiler's job | 13:42 |
SMDhome | kaaliakahn: what's different? or1k-elf- and or1k-linnux-gnueabi-? | 14:49 |
stolar | in this file: https://github.com/openrisc/or1ksim/blob/or1k-master/cpu/or32/insnset.c should be l_cust5 instruction, but there is no instruction like that. wtf? | 15:41 |
SMDhome | stolar: try to add it | 16:39 |
SMDhome | Do we have up to 7 l.cust? | 16:39 |
stolar | SMDhome: I add it and everything is fine | 16:41 |
SMDhome | then, I think, someone just forgot to add it. And since it's custom instruction noone really cared about it | 16:41 |
SMDhome | stolar: what's your task? I wonder if you do this to study sim internals or this is real isa extention | 16:50 |
stolar | It's a part of project on my university ( wroclaw university of technology - POLAND) from computere architecture course. I am studying computer science. | 17:08 |
stolar | SMDhome: It isn't commercial, probably I will not publish result of my project | 17:10 |
stolar | SMDhome: Currently I study or1ksim how it works etc. to pass subject + it is a real extension, probably nobody do this in the world. Topic: modulo instruction and residue number system | 17:15 |
stolar | SMDhome: You can read sth aboout my project in IRC logs from e.g http://juliusbaxter.net/openrisc-irc/index.html First question i ask on IRC 16th may 2016, nickname: stolar | 17:18 |
--- Log closed Tue May 31 00:00:31 2016 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!