IRC logs for #openrisc Monday, 2015-11-16

--- Log opened Mon Nov 16 00:00:11 2015
-!- trevorman_ is now known as trevorman07:15
-!- mithro_ is now known as mithro07:17
-!- Empyrium_ is now known as Empyrium07:32
-!- simoncoo1 is now known as simoncook09:29
-!- mafm1 is now known as mafm10:58
olofkhesham: I made some fixes to mor1kx-generic and would like to do the same fixes to vscale-generic13:00
olofkI added a simulation mode to uart16550 and dropped the uart16550_model13:01
olofk_franck__: Would be great if you could try to bump wb_intercon to wb_intercon-1.0 for neek and de113:04
olofkstekern_: Same thing with sockit13:04
_franck__olofk: why wb_intercon is in orpsoc-cores and wb_intercon-1.0 on your github ?13:07
olofk_franck__: Because I've been trying to move RTL code out from orpsoc-cores13:20
olofkSo it's only old ones that are still in orpsoc-cores13:20
_franck__ah ok. However, if you move everything out of orpsoc-cores you may loose the ability to maintain some cores where the owner is not available anymore13:30
olofk_franck__: Yes, I guess that's the same thing for all Linux distributions as well :)13:39
olofkBut we can always clone the repos13:39
olofkAnd I have also started to use specific revisions for most cores, so that we don't get affected if the git HEAD changes13:40
olofkFor example, I have already cloned the uart16550 repo and applied patches there, so we're no longer using the one from opencores13:40
heshamolofk: done13:47
heshamIt's also slower than the previous uart model module13:49
olofkhmm...13:59
olofkDid you set the SIM parameter?13:59
olofkI thought I had hacked it to be as fast as it could be, but I probably missed something14:00
heshamolofk: Setting it on has no notable effect14:03
olofkhmm..14:03
heshamI wouldn't worry about how quick/slow it's as long as it's working correctly though.14:05
olofkNo, it's not that important, but I thought I had made it as quick as the model, so I was a bit suprised14:06
heshamDon't you have the same behaviour?14:09
olofkActually, I realized that I haven't really been using the uart model. Most of my tests were using elf files that used the l.nop 0x3 feature to write to stdout14:11
olofkIs it much slower?14:11
olofkLooking at the code, I would suspect it's about four times slower14:11
heshamIt's printing out characters with some notable delay14:12
heshamFew milliseconds or so, but can be noticed.14:12
heshamThat wasn't the case with the UART model module.14:13
olofkI'll try to fix that, but if it's ok I'm pulling your patch now, because I want to retire some old code in orpsoc_cores14:21
heshamThat's fine14:25
olofkhesham: Fixed the UART issue now. Pushing some updates14:48
heshamolofk: Great, let me know when you push the updates to give it a test.14:49
olofkpushed14:50
heshamolofk: I'm afraid it's still slow.14:59
olofkDid you set SIM?14:59
olofkIt was much faster for me14:59
heshamYes15:00
olofkhmm..15:00
heshamUART_SIM15:00
olofkyep15:00
heshamNot sure what's wrong15:00
olofkMe neither15:00
olofkhmm.. you're right15:03
olofkIt's no big difference here15:03
olofkFor mor1kx-generic it was a huge difference15:04
heshamSo you tested the vscale one?15:06
heshamMaybe it's the way the code is written?15:06
heshamI don't think so, it's just one line ...15:07
hesham*((volatile char *)0x90000000) = c;15:07
heshamIt doesn't even poll on LSR15:07
olofkYes. That's probably why it isn't faster on vscale with the latest fix15:11
olofkThe elf I was using for mor1kx-generic polled lsr, so it was really slow15:11
olofkok, so we're still a bit slower than the model, but I don't think I'll spend more effort on that now. It shouldn't be too much difference15:11
heshamBut the RISC-V elf is not polling on LSR.15:12
heshamI agree, it's not a big issue.15:12
olofkIt might also be that I'm flushing now after each character so it might be that it just appears slower15:13
olofkBecause every byte is written out one by one15:13
hesham** With Hello World at least15:14
heshamWas it buffered with the uart model?15:14
olofkLooks like that15:16
olofkYou could try to comment out the $fflush in uart_transmitter.v and see if it helps15:16
olofkYou'll find it in ~/.cache/fusesoc/uart16550-1.5.2/rtl/verilog (if you used the default directories)15:17
heshamolofk: Yes it doesn't introduce delays between characters, but it does between lines15:18
heshamAnd it doesn't output anything if there's "Hello World" without \n15:20
heshamSo I think it buffers it until it find "\n"15:20
olofkah ok. Maybe I should remove the fflush then15:21
olofkBut I think the speed should be almost as fast as the model now15:21
heshamIt's now the same as before when commenting fflush15:21
heshambefore == uart model15:22
heshamBut still the delay exists between lines.15:22
olofkWas there a delay between the lines with the model?15:23
heshamI can't give an answer for that as I didn't use multi-line output program with the uart model15:26
heshamLet me reset and see15:26
heshamYes it's there!15:27
heshamI think that's expected, giving that it's cycle accurate.15:29
-!- clopez_ is now known as clopez17:58
-!- mboehnert1 is now known as mboehnert19:58
olofkAlright. I'm about to release a new FuseSoC version now.21:18
olofkAnyone good with autotools?21:35
olofkhttps://github.com/olofk/fusesoc/releases/download/1.3/fusesoc-1.3.tar.gz22:16
olofkHello github releases. Goodbye opencores FTP22:17
--- Log closed Mon Nov 16 23:00:39 2015
--- Log opened Mon Nov 16 23:00:56 2015
-!- Irssi: #openrisc: Total of 50 nicks [0 ops, 0 halfops, 0 voices, 50 normal]23:00
-!- Irssi: Join to #openrisc was synced in 9 secs23:00
-!- Netsplit *.net <-> *.split quits: sb0, juliusb23:06
-!- Netsplit over, joins: sb023:12
--- Log closed Tue Nov 17 00:00:13 2015

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!