IRC logs for #openrisc Thursday, 2013-09-19

--- Log opened Thu Sep 19 00:00:02 2013
stekernolofk: is there a reason why wb_intercon_gen is missing the .py extension?03:02
stekerngetting the wires into a template was dead easy, already done with that03:24
stekernadding the instantiation wasn't much harder05:15
stekernmy first glance turned out to be wrong too, verilogwriter had all the pieces and bits ready05:16
stekernI only had to change three lines in that05:16
stekernto make it not emit the "module"05:17
olofkstekern: Dropping .py is the common practice when you make a python script a main executable05:52
olofkAnd that's awesome! Is it ready for a review?05:52
olofkyour additions I mean05:53
olofkI mean, it's awesome that you added the instantiation template, not that you can drop the .py and make python scripts executable05:54
stekernhaha, I got that!05:56
stekernI reckon it's not taking screenshots and trying to access /var/mail if I run it as ./wb_intercon_gen now then?05:57
stekernand yes, you can expect a pull request some time today05:57
stekernI'm testing the autogenerated header file righ now05:58
olofkYeah, I saw on the keylogger that you are preparing the pull request05:58
olofkI really really should have gotten a de0 nano board06:20
stekernshould have as in "I ordered one and it should have been here already", or "I should have ordered one"06:30
olofkI should have ordered one06:54
olofkWould feel better to actually have one before orconf06:54
olofkHmm.. might still be time actually06:54
stekernolofk: pull request ahoy!06:59
stekernseems like farnell even sell them nowadays:
olofkYeah, I know. And I see now that they ship the next day, so I probably place an order when I get home07:16
stekernI pretty much have a simple de0 nano board port ready btw07:25
olofkThat's great07:25
olofkRAM and UART?07:25
stekernSDRAM and UAR07:25
olofkWith wb_sdram_ctrl?07:25
olofkIs that a replacement for versatile_mem_ctrl btw?07:26
olofkThen I don't think we should add a core for versatile_mem_ctrl, and keep it in their system directories for legacy systems instead07:28
olofkThat will make it more obvious that wb_sdram_ctrl should be used for new systems07:29
stekernare there any systems in orpsocv3 that use it?07:33
stekernIIRC it was very cumbersome to generate the files for it (that might have changed), so that alone is an argument for keeping it in the system directories07:34
olofkI have a local ordb2a system that uses it. It's more or less a copy of the orpsocv2 version, so I might rewrite it from scratch instead07:37
olofkI'm ordering a nano now. Do I need anything else, like a UART adapter or something?07:38
stekerndo you still have an orsoc debug-adapter?07:39
olofkhmm.. I might have returned that when I quit ORSoC07:42
olofkBut I guess any cheap USB-UART adapter would be enough, right? Or do I want JTAG in the cable too?07:43
stekernany cheap USB-UART will do07:45
olofkAnd JTAG through the same cable as I do the programming?07:45
olofkThe Blaster thing-a-mob07:45
stekernthe only occasion where you want to use the seperate JTAG interface is when you want to debug or1k at the same time as you have a signaltap connection07:46
stekernotherwise you can use JTAG over blaster-thing-a-mob07:46
stekernand orpsocv3 have a open source alternative to signaltap anyway - DIILA! ;)07:47
stekernI'd love to get insertion of that more automated, and orpsoc is probably a great platform for that07:47
olofkYeah, I've been thinking about something like DIILA a lot, and figured out that it must exist already07:48
olofkBut as you say, this is the kind of thing where it's important to have good support programs07:49
stekernI agree, from an user point of view, DIILA isn't great (yet)07:52
olofkfuck users. They are just complaining all the time07:53
stekernbut it's built with automation in mind, so it should basically just be to write the tools to do it07:54
olofkThat's good07:54
olofkAgain, the dot notation would be a godsend here :)07:54
stekernyes, I reckon that'll be the most annoying part, pulling out the signals in all of the sources07:55
stekernbut, on the bright side, we can do that in the build directory, so we don't have to mess with the *actual* sources07:58
olofkI don't know how Altera does it, but Xilinx chipscope hooks up to the synthesized edif netlist.08:06
olofkBut it might be easier to insert it into the hdl code directly08:07
jeremybennettjuliusb_: Are you online?08:12
stekernolofk: I think altera does something similar. but, yes, inserting it into the hdl code sounds easier.. and probably less prone to break with quartus version updates08:43
stekern...and last but not least, it's device independent08:43
-!- ysionneau is now known as Yannou08:49
olofkYes, the DI part of DIILA is quite important10:15
olofkHmm.. turns out that the nano was a bit more expensive with VAT added10:15
olofkGetting them on ebay from Shenzhen seems to be the cheapest option so far10:17
stekernstupid VAT, stealing all our money10:31
olofkYeah, and I'm sure those VAT guys are linked to the government somehow, but I can't prove anything10:34
olofkI could probably walk to China and get a DE0-Nano, and it would still have it before my compilation of LibreOffice is finished10:51
olofkoh.. it's finished now10:52
olofkstekern: I'm not sure that verilog_write supports generating modules without ports with your latest changes13:08
olofk...or actually, I'm not sure what the updates to verilog_writer really do13:11
stekernhmm,, can you have modules without ports?13:13
olofkahh ok, I see. If there are no ports, you skip the module header. I'll pull your changes (as we don't generate portless modules atm), but we should fix that somehow13:13
stekernI was under the assumption you don't, but if you do, then that is indeed broken13:13
olofkportless modules can be useful, for example or1200_monitor or vlog_tb_utils in orpsocv313:13
stekernok, yeah, we should fix that then13:14
olofkYeah, but I just add a note to the pull request and let it be. It's better to have the fix as it is now in the tree13:14
stekernsounds good, I can take a look into what would be the "right" way to do module-less generation13:15
stekernprobably feed the verilog_writer a parameter wether you want a module or not13:16
olofkThanks for the patch, btw. This will simplify getting up new systems a whole lot13:17
stekernI sent out a pull request for the de0 nano port I had in my local tree btw13:17
stekernI've tested it briefly and it works13:17
stekern...but it lacks sim support and SPI13:18
olofk(verilog_writer) Something like that should work.13:19
olofkAwesome that we got a de0 nano port13:19
olofkI should still get a board for myself :)13:20
olofkHave you tested it with a debugger too?13:24
olofkCool. I haven't had time to try that in orpsocv3 except for with jtag_vpi13:26
olofkWhen you say that simulation doesn't work... what's the problem?13:32
stekernummm, I haven't put any effort into it..13:39
stekernit's basically based on an older version of francks de1 port, so the simulation stuff as he's stuff was then13:42
stekernso, hook-up to memory model is probably lacking13:43
stekernand the question is how "board-like" we want our sims to be13:43
stekerni.e. do we want to simulate plls etc13:43
olofkI like the traceability of the code in the orpsoc_top header :)13:45
olofkI would like to include the real pll if it's a potential issue with it, but that won't work straight away in Icarus13:46
stekernmmm, it probably goes even further... but that felt enough13:47
olofkWe got de0_nano in the tree now. Thanks13:52
olofkstekern: Do you have this problem? k.13:54
olofk13:19 < olofk> Awesome that we got a de0 nano port13:54
olofkfucking stupid paste13:54
olofkahh... now I know. Haven't cleaned my cache13:55
stekernhmm no13:55
stekernbut mine fails when it tries to compile the pll.v file13:55 I get the same issue that _franck_ was complaining about with the conflicting option string --transactions13:55
stekernand yes, I have problems with "fucking stupid paste" too ;)13:56
stekernI didn't know that Gothenburg was in a completely different timezone than the rest of sweden btw14:03
olofkHaven't figured out how to fix that14:05
olofkI guess it's because my raspberry pi is set to some left-side-driving kidney-pie-eating country's timezone14:05
amsstekern: it is because gothenburg belongs to denmark.14:09
olofk_franck_: I pushed a fix for the problem with conflicting plusargs14:15
olofkstekern: de0_nano simulation almost working in modelsim now14:30
olofkIt's being picky about some syntax issues14:30
_franck_olofk: good14:34
_franck_my de1 is working with modelsim14:34
stekernolofk: I can't see no de1 in de0_nano.system15:03
stekern_franck_: yeah, I should probably have brought in the new stuff from your de1 port18:33
olofkstekern: I can't see it either now. Wonder where I got that from19:09
stekernme neither *puts on my best poker face*19:12
stekernI did something forbidden, I noticed those right after I did the pull request so I force pushed that change...19:13
stekerndidn't think you'd be that quick noticing the request ;)19:14
olofkOh no! You could have slipped in a back door19:25
stekernI need to get my screenshots back!19:27
_franck_no one is using the mt48lc16m16a2 model in orpsoc-cores ?19:36
_franck_can I update it (the wb_sdram_ctrl testbench will need updates) ?19:37
_franck_parameters are now exported to the top:
olofk_franck_: Hmmm... aren't they already exported, but with the old parameter syntax?19:39
_franck_didn't we have defines for SDRAM parameters ?19:40
olofkYes, but that was some weird solution where a define selected which parameters to use19:41
olofkAre you using the upstream version or the one from orpsocv2 now?19:42
_franck_upstream + patches19:43
_franck_give me half an hour (for me to branch, checkout, pull, cherry-pick, whatever,...) so I can prepare my pull request for you to see the patch ;)19:45
olofkThat sounds like a plan :)19:46
_franck_olofk: done19:56
olofkThanks. I'll take a look19:57
stekernI'm trying to get my things around this yocto stuff...20:02
stekernI want a native arm toolchain20:02
stekernI want to compile an or1k toolchain on the arm20:03
olofkThat would probably be another great stress test for our toolchain20:04
_franck_wb_intercon_gen try with upstream version and stekern wb_intercon.conf :
olofk_franck_: You're missing an argument. It needs the output verilog file as the second argument20:16
olofkI got a bit lazy with the command line parsing :)20:16
_franck_arf ;)20:16
olofk_franck_: I've looked at your pull request now, and I think that patch 0001 is unnecessary. Could you remove that and resend? Looks good otherwise20:19
olofkThat line separator patch is really annyoing, but I guess it's better to have it20:20
_franck_is that patch 0001 really a problem ? because I would have to change 0002 also to be consistant20:25
stekerncounter question, is it really a problem to change 0002? =)20:29
_franck_well it is bacause I need git skills for that ;)20:30
stekerngit rebase -i is your friend20:30
stekernyou'll get a list with your patches, just remove 0001 in that list and set 0002 to edit20:31
stekern(0002 will fail with 0001 so you'd get the chance to edit that anyway though)20:32
_franck_yes I'm using this sometimes. But when my patch is already pushed and I want to change it with rebase -i it breaks everything20:32
stekern*with 0001 removed20:32
stekernheh, define "breaks everything"20:32
_franck_it doesn't want to push the new "merged" patch because fast foward or something like this20:33
stekernyou have to define the commit you want to 'git rebase -i' against20:33
stekernah, you just need to force push it20:33
stekerngit push -f20:34
_franck_ah ok, I'll try this. I need to generate my patch serie again (the one in mt...). Are you sure you want me to do that ? :)20:34
stekernwhat harm can it do me? =)20:35
_franck_I love those new upper case parameters :) If I were you I just leave it like this20:36
_franck_stekern: you already gave me some more work with wb_intercon.vh, I need to update my signals names20:38
stekernyou're welcome ;)20:38
_franck_should have pushed my de1 system before you did ;)20:38
_franck_the more I wait the more I have things to fix20:39
_franck_I think I'll go for a copy/paste back of orpsoc_tb from de0_nano to de120:41
stekernorpsoc_top you mean?20:41
stekernyeah, I merged most of the things from sockit into de0_nano20:42
stekernand then I just alt-shift-% the rest20:43
stekernthe kernel I just built with yocto boots at least...20:54
olofk_franck_: Yeah, I agree that the upper case parameters look nicer. Just wanted to avoid unncecessary patches.20:54
olofkAnd I too have noticed that some things move fast, so it's best to just push stuff as soon as possible to avoid extra work :)20:55
stekernif there would be a chance that they'd be upstreamed, they would probably be less "unnecessary"20:55
olofkYeah, but in this case I don't think we should hold our breath for it :)20:56
olofkstekern: Did someone just try to sneak in a .gitignore? Is that to hide your back doors?21:03
stekerndamn you're onto me, that's what the *.pyc is for...21:06
olofk_franck_: I can try to do the rebase stuff for the mt... in my tree and push it if you want21:17
_franck_olofk: it would be great21:18
olofkhmm.. I'm having some trouble applying the patches21:43
olofkI tried to just keep 0000, but it fails to apply that one too21:45
olofkNeed to sleep now. Will try again tomorrow21:46
poke53281Spend again 5 hours on this stability with X11.22:27
poke53281Reproducible in some way, but different problems for each client. No matter if22:27
poke53281I use xeyes, xclock, glxinfo or glxgears ... every program stops at a another position22:27
poke53281in the server. Eiter segmentation fault, assert, unknown opcode or unaligned access.22:27
poke53281I run even into problems while starting another program which has nothing in common with22:27
poke53281X11 except the use of the shared library uClibc.22:27
poke53281Mysterious is the best word describing it.22:27
poke53281So I don't think the bug is in X but in the kernel.22:27
poke53281Maybe some very rare mapping issue.22:27
--- Log closed Fri Sep 20 00:00:04 2013

Generated by 2.15.2 by Marius Gedminas - find it at!