IRC logs for #openrisc Wednesday, 2015-05-06

--- Log opened Wed May 06 00:00:37 2015
olofkstekern: Nvidia? That sounds really cool05:02
bandvigolofk: What about Nvidia? (it looks like not all night post were logged)08:40
olofkbandvig: It turns out that all Nvidia GPUs are just OpenRISC CPUs08:41
bandvigolofk: :) Where did you read that?08:42
olofkWhen I grow up I'm going to stop lying :)08:44
-!- Netsplit *.net <-> *.split quits: arokux08:58
-!- Netsplit over, joins: arokux09:00
GeneralStupidokay, 39% of my FPGA is used by my core:)09:33
GeneralStupidIs there anything i can do to reduce the used area? For example, did he already uses the FPGAs built in DSP's?09:34
olofkGeneralStupid: The .map.rpt file (and maybe others) should give some clues about what resources have been used09:55
olofkYou can also fire up the quartus gui and take a look at the netlist09:55
GeneralStupidbut at the moment i have nothing, just 4 GPIO units and the "normal" mor1k09:56
GeneralStupidolofk: i would like to tune fusesoc a bit. I think it will be good of you can add "module" (and connect them to wb) Configurations in already working projects and tell fusesoc to regenerate the wishbone related files...10:05
olofkGeneralStupid: Can you elaborate a bit?10:05
GeneralStupidolofk: i think of this workflow: checkout with fusesoc, add a user defined core with extensions to the wb_intercon.conf, call fusesoc to create that wb files again.10:07
olofkGeneralStupid: The part of regenerating the wb_intercon files automatically is on my todo list. I have written up a proposal for a generic way of letting cores specify that they have files that needs to be regenerated10:11
GeneralStupidahh okay sounds nice :)10:12
olofkDo I understand you correctly that you also want to have the additions to wb_intercon.conf inside the slave cores themselves (such as in gpio, or uart)?10:12
olofkAlright! Looks like my u-boot image loader works now10:12
olofkBye bye bin2binsizeword!10:12
GeneralStupidolofk: i dont know how exactly i would concatenate it exactly but thats what i wanted to do10:13
GeneralStupidi will thx10:13
olofkI don't think you should put that information inside the slave cores. The top-level core should be the only one to decide on the register map10:14
GeneralStupidis there an easy way to switch between the mor1k implementations?10:44
olofkI think you just need to set the parameter OPTION_CPU0 to something else. Not sure how well maintained the other pipelines are though10:45
olofkIf you are looking to save resources I suggest you decrease the cache size and turn off MMUs if you don't plan to run Linux10:46
GeneralStupidbut i have to change the verlilog code for that?10:48
GeneralStupidok ok i see it looks well documentated into the sourcecode10:48
olofkJust your top-level file10:48
GeneralStupidfrome enabled to None10:50
olofkYep. That will bring down the resources a bit. You can disable DMMU too10:51
GeneralStupidICACHE - Instruction cache?10:51
GeneralStupidDCACHE data cache?10:51
GeneralStupidok now iam down from 35% (just 2 GPIO modules) to 31%10:55
olofkThe cache sizes are controlled by *_BLOCK_WIDTH, SET_WIDTH and WAYS10:57
GeneralStupidwhat is a good size?10:59
olofkNot sure11:00
GeneralStupid(i dont understand the WAYS)11:00
GeneralStupidthx, i think i try it this way first :) iam on 30%11:03
olofkNot sure why you need to optimize it further. You still got 70% to play with :)11:06
GeneralStupidiam also not 100% sure what i want to do with it right now. I had an idea but it looks like its too much work to realize it.11:08
olofkOh god, how I hate branch delay slots11:10
olofkI wonder if anyone has analyzed the cycles saved on branch delay slots vs the extra debugging time caused by them11:11
GeneralStupidi already changed my ram to 8mb in my template, but i cant fetch it because of or1200 svn and the jtag bug i had in de1 too14:40
stekernolofk: not as cool as openrisc ;)14:51
stekernbut yeah, it's pretty exciting14:52
GeneralStupidstekern: where can i change the RAM amount in orf1k ? in verilog :)15:25
stekernGeneralStupid: what RAM?15:43
GeneralStupidthe sdram15:50
GeneralStupidit was 32mb and i changed it but i did not change it into my build15:50
stekerniirc, it doesn't matter as long as you don't access it15:57
GeneralStupidcan i control this if i use malloc?15:57
stekernmost likely16:03
olofkGeneralStupid: What jtag bug?18:20
olofkand or1200 shouldn't be fetched from svn anymore18:21
olofkHave you update orpsoc-cores?18:21
olofk'fusesoc update' should take care of that for you18:21
GeneralStupidfusesoc update does nothing18:22
olofkGeneralStupid: Do you run it from your workspace directory?18:36
-!- Netsplit *.net <-> *.split quits: ed-jones, tfh, arokux, poke5328118:48
-!- Netsplit over, joins: ed-jones, poke53281, tfh18:49
-!- Netsplit over, joins: arokux18:49
-!- Netsplit *.net <-> *.split quits: ed-jones, tfh, poke5328119:18
-!- Netsplit over, joins: ed-jones, poke53281, tfh19:19
GeneralStupidolofk: yes19:55
olofkAnyone good with C preprocessing macros?20:44
GeneralStupidi could give it a try20:48
olofkI just want to byte-reverse a number20:49
olofkIt's something weird going on here20:51
olofkI think I found a way around it now20:52
olofkI probably needed some more parenthesis20:53
olofkyep. That was it21:00
olofkAlright. The uImage loader is pushed to the de0_nano system in orpsoc-cores21:13
olofkwb_ram still doesn't work with quartus though. Need to push the fix for that as well21:17
olofksome other day21:17
GeneralStupidits really hard to get this running and generic21:56
--- Log closed Thu May 07 00:00:39 2015

Generated by 2.15.2 by Marius Gedminas - find it at!