IRC logs for #openrisc Monday, 2013-09-09

--- Log opened Mon Sep 09 00:00:48 2013
mor1kx[mor1kx] skristiansson pushed 2 new commits to master:
mor1kxmor1kx/master 49eb6f1 Franck Jullien: cappuccino/fetch: initialize imem_err during reset...03:33
mor1kxmor1kx/master 46a23ff Stefan Kristiansson: icache: reorganize OPTION_ICACHE_WAYS == 2 guard...03:33
mor1kx[mor1kx] skristiansson pushed 1 new commit to master:
mor1kxmor1kx/master 3324116 Stefan Kristiansson: update version number to v2.0...05:18
stekernwhois juliusb_05:18
stekernjuliusb_: ^ that's in line with our discussion, right?05:19
mor1kx[mor1kx] skristiansson pushed 1 new commit to mor1kx_v1:
mor1kxmor1kx/mor1kx_v1 1eb23f2 Stefan Kristiansson: mor1kx v1.105:38
stekernjuliusb_: ^ and that makes our release branch complient with the options we have discussed for that05:40
stekern_franck_: how do I set npc in the latest openocd?06:07
stekernset $pc = 0x10006:13
stekernbut how can I get "raw" spr access?06:13
stekernI want to access sr too06:14
stekernsingle stepping doesn't work, at least not with mor1kx06:15
stekernbut this whole soc is a bit unknown, so could be unrelated to changing openocd version06:15
stekernthe old version doesn't work at all with sockit, so can't compare neither06:22
_franck_stekern do you have the last gdb ?07:02
_franck_maint print reggroups07:06
_franck_shows you all registers groups07:06
_franck_you can do "info registers timer" for example07:06
_franck_then set $sr=0x... if you want to set sr07:07
_franck_info register sr to see its content07:07
_franck_or info register system07:07
stekern_franck_: thanks07:50
olofkSlow day today. I'm just merging pull requests and stuff... you know, the usual08:10
stekernyou really need to be following #openrisc pretty closely to get the fun in that sentence ;)08:26
stekernyou nailed it btw08:28
-!- knz_ is now known as knz09:14
hansfbaierstekern: Did you have something like this in mind:
hansfbaierfor the enc28j60 interrupt09:58
stekernhansfbaier: yes, that looks like what I had in mind09:59
hansfbaierstekern: thanks09:59
olofkNow this is annyoing12:02
olofkgithub is trying to be clever with the archives12:03
stekernclever in what way?12:04
olofkYou can download an archive of the tree at a certain commit from<user>/<repo>/archive/<version>.tar.gz12:06
olofkversion can be sha, branch head or a tag12:06
olofkYou get a tar.gz where the files are stored under the directory <repo>-<version>12:07
olofkBut for the tags, the name of the archive is mor1kx-v1.0.tar.gz, but it's extracted under mor1kx-1.012:08
olofkSo github throws away the 'v' in the pathname12:08
olofkUgly workaround for now is to look at the first path element of some random file to determine where it will end up12:09
stekernhmm, actually, the filename is mor1kx-1.1.tar.gz too, if you download from the web interface12:10
olofkAny file in the archive, to be clearer12:10
olofkhmm.. interesting12:10
olofkAre the tags named v1.x, or just 1.x?12:11
stekernstill.. wouldn't it be better to just use the git tree?12:11
stekernthan downloading tar.gz12:11
stekerntags are named v1.x12:11
olofkMight be, but by doing it like this, I won't have a hard dependency on git12:12
stekernno, but you will have a hard dependency on tar and gzip12:12
olofkI see your point, but those are in python's core libs :)12:12
stekernyou're going to have a git dependency anyway, you can't expect everything to be in github12:14
stekernalso, from a caching point of view, it makes more sense to have the git repo in cache12:15
olofkOnly if you have a clever cache mechanism12:15
olofkIn order to decrease the amount of work on those parts, I decided to drop automatic updating for now12:16
stekern"automatic updating"?12:17
olofkAutomatic as in detecting when the cached copy is outdated and needs to be updated12:17
stekernah, ok12:18
stekernwell, you don't have that now, but it's probably an aim for the future to have that12:18
olofkI have some ideas for how to improve the cache handling, but I think it's good enough for now12:19
olofkI can at least use tagged versions from github in the core files now12:20
stekernbut I mean, with a git repo you could just do: if !coreincache: git clone; git checkout <tag/branch/sha>12:21
stekernmaybe you want to throw in a fetch there too, but you get the point12:22
stekernthis makes me realise that git submodules would be a royal pain to have in orpsoc-cores12:26
stekernyou'd have to setup seperate git submodules in every system/<system-port-dir>/12:27
stekern...but actually, what I'm thinking about isn't even possible as it is now...12:28
stekernyou can't have different versions of a core for different systems12:28
stekernthat's not good12:28
stekernmaybe it's not so much of a problem when I think about it a bit more, if you want some very special version of a core for a system, you can just do a seperate .core description for it in cores/12:38
_franck_or you can put the core files in your board directory12:39
stekernyes, but that falls in the "not good" category12:40
olofkMultiple versions of cores is planned too12:40
stekernok, that sounds good12:40
olofkI'll probably go the gentoo way and have multiple <name>-<version>.core files, and let the core files themselves tell which patches they should use12:41
olofkAnd add more intelligence to the depend string. Like being able to set dependencies on >=mor1kx-1.112:42
olofkThe best thing would be if I could actually steal some of the logic from portage. I think that is written i Python too12:42
stekernthat sounds good too12:42
olofkI should probably write down all this stuff, especially if someone wants to help out12:44
_franck_stekern: about the dpram in wb_sdram_ctrl, removing intended_device_family in the instantiation makes modelsim to choose the Stratix family and it now complains about clock_enable_output_a not being supported by Stratix family :(12:45
_franck_stekern: what would you prefer ?12:45
_franck_1) remove clock_enable_output_a from dpram_altera.v12:46
_franck_2) add a parameter FAMILY to wb_sdram_ctrl12:46
_franck_3) add a new dpram_altera_cii.v file12:46
stekernhmm, we don't use the clock_enable_output_a, so removing that sounds like the logical step forward12:47
stekernI have to admit that I didn't really use a lot of time on consider the options and settings in that dpram_altera.v file12:49
stekernI'm not sure why I even created it, the generic should work too12:51
stekernmaybe just to make it easy for people to see where they should insert their technology dependent RAM if necessary12:52
stekernbut if we can make that generic over altera devices, fine12:52
_franck_GENERIC throws an error then Quartus tries to fit it (I didn't try to find out why...)12:55
stekernhmm, ok14:12
stekernon the bright side...14:12
stekernleds are blinking!14:12
stekernbut accessing the vjtag messes up the arm processor14:24
olofkstekern, _franck_: My two favorite early adopters. I'm about to update the interface of wb_mux and wb_arbiter soon in orpsocv317:22
olofkstekern: Revenge! Feel the wrath in the pull request I just sent you!18:29
stekernolofk: I've got a busy day, but I managed to squeeze in the pull anyway19:24
stekerntwo general constructive comments, a more descriptive commit message on the testbench would have been nice and keeping the coding style across the project19:26
stekernapart from that nitpicking...19:26
* stekern bows and say thanks!19:26
stekernon to some ranting about qsys...19:27
stekernwhy on earth is it so slow on my (k)ubuntu machine?19:27
stekernhas to be something with my java setup, it takes ~20 sec to change a value in one of the setting boxes19:28
stekernolofk: can I somehow reference my own files in the build/src/ directory?19:50
stekernand if not, can you point me to where I should start hacking to make it do that?19:51
stekernto explain a bit more what I'm doing, I will have qsys generate a set of .v files, I don't want them to end up in my orpsoc-cores directory, but in the build directory (and under src seems appropriate)19:53
stekernwell, it's enough to add the .qip file19:55
olofkstekern: Regarding coding style, what did I miss? I'm using emacs with verilog-mode, but I might have forgotten to beautify20:00
olofkstekern: You want the qip file to end up in the build directory?20:01
stekernI used tabs only indentation (i.e. not verilog-mode default)20:02
stekernbut it's no big deal, the testbench is standalone, I'd be more upset if it was a module in rtl/verilog/ ;)20:03
olofkI need to understand a bit more about the qsys stuff.20:03
olofkIs the qip something similar to coregen, ie. you use the qip as an input file to generate the .v files?20:04
stekernI want all the qsys generated files ending up in the build directory, the .qip file should be added to the project file (.qpf)20:04
olofkYou want the .v files generated on the fly then I guess?20:04
stekernno, the .qip (AFAIU) is just a description of what files qsys generated20:04
stekernso if you change the qsys system, you don't need to add a lot of files to the project20:05
stekernbut I guess will be my friend here, right?20:05
stekernI need to add qsys support too20:06
stekernfortunately, you can drive the qsys generation from commandline20:06
olofkI'm not familiar with the Altera stuff on that level, but I recognized that I need to add explicit support for coregen, and I guess the same goes for qsys then20:06
olofkCan you describe the workflow with qsys? I assumes you have some description file (qpf?) that is used as input to some generator that spits out .v files. Is that correct?20:07
stekernyou use the qsys gui (that I just cursed about being slow as hell) to describe you system, that will be saved into a .qsys file (that I will store in systems/sockit/data/)20:09
stekernyou then run the generator on that (in the gui, you press the "generate" button)20:09
stekernwere you sleeping on the workshop? or did you spend all time rekompiling your kernel? ;)20:10
olofkWell, actually. That isn't too far from the truth20:10
olofkI also spent some time cursing that I had node locked the ARM stuff license to the tethered internet connection on my phone20:11
olofkWhich occupied one of my two only USB ports, which prevented me from using the blaster and terminal at the same time20:12
olofkIt was a bit messy20:13
olofkAnyway. The generate part generates the verilog files then, right?20:13
stekernwell, we only had boards for half the people, so we had to share20:13
stekernluckily the guy I was sharing with wasn't as messy as you, but others were, so we had time to finish of all assignments anyway ;)20:14
stekernyes, the generate part generates the verilog files, and a top module that I will instantiate in orpsoc_top20:14
stekernbasically all I'm going to have in the qsys system is the hps20:15
stekern+ an avalon bridge to the hps ddr320:15
olofkok, so the qsys stuff will be a sub-component in orpsoc_top. That helps too20:15
stekernyes, I considered doing it the other way around, but I decided it'll be cleaner to have it as a sub-component20:16
olofkStep one *could* be to store the generated .v files in your sockit core20:17
stekernnonono, wroooong ;)20:17
stekernand ugly20:17
olofkYes, definitely ugly, but an option20:17
stekernactually, if I just get the .qip file in the project file, it's not so much of a problem during development20:18
stekernI just have to run the qsys generation as a seperate step20:18
olofkWhat we _do_ want is to have a section in the .core file that tells which qsys file to use, and parses the qip file to see which additional files that should be referenced when you do the build/simulation20:19
stekernhmm, where do you need that information?20:19
stekernfor simulation, perhaps, yes20:20
olofkYes. For building you could reference the qip directly, right?20:20
stekernqsys can generate testbenches too, but I'm not sure how deeply you will be able to simulate this system20:22
olofkIs it feasible to run simulations on that system?20:22
olofkOtherwise I would say that we start out with the easy way and concentrate on getting it right for the bitstream generation20:22
stekernthe ddr3 is connected to a hardcore memory controller in the hps, I'm not sure if you can simulate that20:23
stekern(and even if you can, you'll need the hps to set it up)20:23
olofkIs HPS the TLA for the ARM SoC?20:24
stekernyes ;)20:24
olofkStupid Textile Labour Association!20:24
stekernHard Processor System20:24
olofkI would have guess High Performace or something Paralell20:25
stekernthis will be quite different from the other orpsocs we have20:25
olofkYes, so it would be nice to support it without adding too much specialized logic in orpsoc20:26
olofkBut qsys can be used for other things too, right?20:26
stekernsince the fpga isn't really connected to anything interesting (apart from the vga port and ac97) on the board, there will be connections into the hps instead20:26
stekernyes, you can build complete socs with qsys, point and clicky style20:27
olofkThis is basically the opposite from your idea of a qsys mor1kx wrapper, right?20:27
stekernso, essentially orpsocv3 could be considered a start to a qsys (or a backend if you will)20:28
olofkhmm... explain20:29
stekernor, what I'm trying to say, there are similarities20:29
stekernmy "qsys mor1kx wrapper" was a qsys core description file for mor1kx20:30
olofkI thought so20:31
stekernpretty much the same as the .core file in orpsocv320:31
olofkBeing able to generate qsys core descriptions directly from orpsoc is another thing that I plan to support somewhere in the distant future20:32
stekernin qsys you pick the cores in the gui (as you do in the .system file)20:32
olofkOr at least export them, so the build/src directory can be picked up in qsys or Xilinx XPS20:32
stekernthen you point and click how the cores are connected (including bus interfaces)20:33
olofkI guess it's quite equivalent to XPS20:33
stekernand then when you click "generate" it copies all the verilog files from the core description files into a single directory20:34
olofkRegarding yes, that's where the logic should go, _but_, that file is a mess and should be converted to a sub package in orpsoc20:34
stekernand it autogenerates the bus connections and a top file20:34
stekernso, isn't that quite similar to what orpsocv3 does?20:35
stekernexcept the top file autogeneration20:35
olofkYep, but without top-level generation and a fancy GUI :)20:35
olofkAnd it probably works too :(20:36
stekernwell, I rather use emacs than the fancy gui that takes 20 sec for each input box to update...20:36
olofkSo, there are two qsys-related things that could be supported in orpsoc.20:36
stekernthere are like 40 parameters in the DDR3 settings...20:37
olofk1. Run the generate command on a qsys file to generate the verilog files in the build directory20:37
stekernyup, that should be easy20:37
olofk2. Create qsys files from .core files (and probably some more info) to make it possible to use the orpsoc-cores in a qsys workflow20:38
olofkNumber 2 will have to wait20:38
stekernyes, and that's kind of out of the scope of the project20:38
stekernbut a cool feature, I admit20:39
stekernbecause the qsys component I made for mor1kx have already bitrotted..20:39
olofkCan you pastie it? Would be interesting to see what it looks like20:39
olofkDo you ever reference more than 1 qsys file?20:40
olofkDoesn't matter really20:40
olofkI say that we add a [qsys] section to the .core file and an option that tells where to find the .qsys file. Would that be enough?20:41
olofkThose changes should go in orpsoc/core.py20:43
stekernhmm, are the files in data hardcoded somewhere?20:43
stekernnm, no they are in the .system file20:44
stekernwouldn't it make more sense to have a qsys_file(s) in the .system file?20:45
olofkNot if we want to generate them for simulations as well20:45
stekernhmmm... but it's a very quartus specific thing20:46
stekernqsys can appearently generate testbenches as well20:47
stekernI'd say the most logical place from a user point of view would be under [quartus] as a qsys_file(s) option20:49
olofkWell, as you represent 50% of the user base, I say we go for that :)20:50
stekern33.3333%, aren't you dogfooding?20:50
olofkNo, I only use qsys20:51
olofkCan't stand all this command line crap20:51
stekernsince I raised the issue of coding style earlier, is there a preference in systems, or is that the decision of the system creator?20:58
olofkIt would be great to unify that, but it seems that there aren't any prevalent coding styles in the verilog world20:58
olofkI prefer spaces, but in practice just go with whatever verilog-mode gives me21:00
stekernI copied _franck_'s de1 board, he disliked verilog-mode so much so he changed everything to tabs21:01
olofkI don't like it either. Everything looks like shit when I'm doing diffs21:01
olofkI get the feeling that it isn't very consistent between versions either21:02
stekernyeah, I noticed that too, it lines up multi-line statements different now than it did before21:02
stekernsomeone needs to do a modified config for it and distribute ;)21:03
olofkI gave up instead :)21:03
stekernyeah, me too...21:03
stekernmaybe I just let verilog-mode have it's way with the sockit port too...21:06
_franck_no ! please !21:06
stekern_franck_: it's up to you to make the configuration to save the world then!21:07
_franck_I don't use emacs :)21:07
stekernit's a noble quest21:07
_franck_insted I would create a like for verilog/vhdl21:08
_franck_so we can check every file, and if you have a coding style issue, you can't commit :) (like gerrit with openocd)21:09
stekernhmm, yes, but then the project maintainer have to dictate the coding style rules that should go into checkpatch.pl21:10
_franck_we are in a democracy (most of us) so discussion is welcome when it's about coding style21:11
olofk_franck_: Aha! You have been exposed! I see that you are using quartus instead of orpsoc!21:13
stekernI'd like a v-set-style command, so I can swap between the evil verilog-mode and a sane configured verilog-mode21:13
stekernbut my emacs-fu is restricted to copy paste what google gives me into the .emacs file21:14
olofkI haven't written a single line of lisp-like code in 12 years21:14
_franck_olofk: I was about to say: quartus tells me he wont infer the ram but does not tell me why...21:16
_franck_but yes, I have to admit I use quartus sometime :)21:16
stekernok, _franck_ let me rephrase that, I let verilog-mode have it's way with the code I add *now* to sockit21:17
stekernthat will leave it in such an ugly state when it's mixed with your tabs that I will have to do something about it before it's done ;)21:17
stekernbtw: // *************** BUG OLOFK ************** <- what's that?21:18
_franck_some thing I had to push21:19
stekernstop pushing buggy olofks around!21:19
_franck_AFAIR address names on the line above this nice comment are not correct in the code I copied from (or1200-generic)21:20
stekernI can probably remove it from my sockit then ;)21:22
_franck_or you can lease it so "olof will have his name" in sokit :)21:24
stekernI got interrupted in my description of the setup of the sockit orpsocv3 port21:31
stekernso, I was saying that there are no interesting stuff connected to the fpga on the board, so ethernet and uart for instance will have to go through the arm system21:32
stekernI think it'd be cool to have the debug port hooked up straight to the arm system as well21:33
olofkGot to sleep now21:42
olofkUpdate your orpsocv3 and orpsoc-cores if you haven't already21:42
_franck_ok, thanks, good night21:43
juliusb_stekern: yep, I'm on board - .0 is dev branch, .(>0) is release22:16
juliusb_looks great22:16
juliusb_thanks a lot for organising this!22:16
juliusb_i'm currently road tripping through the US - I bought a SIM card with data here but the reception is patchy so I may take time to respond to thing, sorry22:17
juliusb_but i'm keeping an eye on the logs ;)22:18
juliusb_you guys give us lurkers plenty to read of late22:18
juliusb_and why am I my underscored version of myself?22:18
-!- You're now known as juliusb22:18
--- Log closed Tue Sep 10 00:00:49 2013

Generated by 2.15.2 by Marius Gedminas - find it at!