IRC logs for #openrisc Saturday, 2015-08-22

--- Log opened Sat Aug 22 00:00:10 2015
olofkAhh... I didn't know about this git feature. That's awesome
stekernmm, especially the --swagger-twist-submodule option is useful09:09
olofkstekern: Yeah, I have been looking for something like that. I just don't understand if that can be used together with --page-serve-ref. Maybe you need to do a git-photograph-tree or import with git-blow-history first09:46
andrzejrguys, has anyone managed to generate a Xilinx API from command line using coregen? I am trying this now and it coregen/MIG is ignoring parameters specified in input files.10:31
andrzejre.g. memory interface type (uses DDR3 instead of DDR2) and occasionally FPGA device type (6-series instead of 7-series)10:33
andrzejrThe latter problem was caused by an incorrect version number (-u parameter). But coregen still keeps generating DDR3 i/f.10:54
andrzejrIt works, I copied the following files (for MIG): .cgp, .cgc, .xco, .prj. Command: coregen -r -b xco_file -p cgp_file. I have modified .xco and .cgc files to point at a valid .prj file.11:51
andrzejrcoregen in batch mode does not generate the memory model (gui would present a license) but it can be downloaded separately.11:53
andrzejrI've pushed a "coregen" provider/generator to
olofkI never thought of adding coregen support via a provider12:17
olofkBut it's definitely a cool approach12:18
andrzejrWe could do the same for wb_interconn12:19
olofkThe main drawback I see is that we would need a separate core for every new configuration12:19
andrzejrYes, we could have cores like atlys_interconn, atlys_ddr2 etc.12:20
olofkBut I say we go for it. Better to have something working now, than something "better" that is not implemented yet12:20
olofkI've been talking about that damn generator API for like three years now without getting anywhere with the implementation :)12:22
andrzejrI think the extra core is a small price to pay for flexibility. If we wanted to merge it with other cores then we would have to combine e.g. github provider with some generator mechanism and specify the order of operations.12:22
olofkYeah, and you're allowed to put all the stuff in the same directory, so we can still logically group all board-specific stuff12:23
andrzejrAm I? I didn't know about it.12:23
olofkAnd an extra benefit of having a separate core is that we can cram some instance-specific stuff there as well, like IP-Xact models12:24
olofkYes. file:///home/olof/code/or1k/fusesoc/doc/capi.html12:24
olofkohh.. that link won't work :)12:24
olofk...I hope at least :)12:24
olofkBut here
olofkOr generate the html docs by running make in fusesoc/doc12:25
andrzejrI see, that's neat. I thought cores were assumed to be in ./cores directory12:26
olofkIt was like that initially, and the separation of systems and cores are also a remain from the initial implementation, but there's no real need for that anymore12:28
andrzejrhow to organize the orpsoc-cores/systems/<system>/ directory? It already contains its own .core file12:28
olofkThat's a valid point12:29
andrzejrPut all system-related cores in ./system/<system>-cores/?12:29
olofkJust put all the existing stuff in a subdir perhaps. That would also allow to put variants of Atlys-builds side by side12:30
andrzejrsorry, not sure if I get it12:31
olofkI'm ok with either. We should come up with best practices, but we can always move stuff later12:31
andrzejrwhich subdir?12:31
andrzejrorpsoc-cores/systems/atlys/system|cores ?12:31
olofkI was thinking about moving systems/atlys/* to systems/atlys/atlys_top (or similar)12:32
andrzejrOK, that sounds reasonable. thanks.12:33
olofkoh, but wait. You can just put the new coregen .core file in systems/atlys directly12:35
olofkNow I got to go :)12:36
andrzejryes, that's how I understood your proposal: orpsoc-cores/systems/atlys/atlys_top|atlys_ddr2|atlys_interconn etc.12:38
andrzejrjust to clarify - I am not planning to change anything in atlys (this was just an example, besides I don't have this board)12:39
andrzejrAlso, I assume all core names still have to be unique, hence atlys_ddr2, not just ddr212:40
andrzejrolofk, a bug report (fusesoc crash when fetching vga_lcd with an empty cache): fusesoc --verbose sim --simulator=icarus atlys14:07
andrzejrit is triggered by --verbose option (and the feature I added a couple of weeks ago) and can be fixed by specifying cwd parameter in Launcher constructor14:09
andrzejr(like it is done in the coregen provider)14:10
-!- pecastro_ is now known as pecastro14:11
andrzejrI would like to propose a configuration change to orpsoc-cores:14:12
andrzejrPut fusesoc.conf in the orpsoc-cores directory with the following contents:14:13
andrzejrcores_root   = cores14:13
andrzejrsystems_root = systems14:13
andrzejrbuild_root   = build14:13
andrzejrcache_root   = cache14:13
andrzejrand add build/ and cache/ to .gitignore14:14
andrzejrI find the recommended fusesoc setup with a separate build directory and ~/.cache cumbersome. If someone wants that it is still possible, but IMHO the default should be just "go to the oprsoc-cores and run fusesoc"14:15
andrzejrolofk, pushed a bug fix to my fusesoc repo14:41
andrzejrolofk, there are some issues with exception handling in fusesoc. In several places you are trying to catch urllib.URLError|HTTPError, which does not exist in python2 (in fact, in python3 it is called urllib.error.URLError...)15:11
andrzejrI could "fix" it by replacing all except clauses with except IOError and except OSError. I am not pushing this change because you may want to handle it differently.15:13
andrzejrThe problem occurs when e.g. subprocess fails during fetch (git, opencores, coregen) and it triggers exception handling in e.g. bin/fusesoc or fusesoc/simulator/simulator.py15:15
olofkSo many things to answer :)18:58
olofkBut that's good18:58
olofkCore names must be unique, yes18:58
olofkI don't agree with building stuff in orpsoc-cores. It's the main repo, yes, but there are other projects using FuseSoC that don't use orpsoc-cores at all19:00
olofkAnd most people shouldn't have to edit stuff in orpsoc-cores at all, except for fixing bugs in the existing cores there19:00
olofkI got a separate tree for all the cores I'm working with, so my fusesoc.conf contains 'cores_root = /path/to/my/staging/tree /path/to/orpsoc-cores'19:01
olofkOh, and another small thing. systems_root is not really used anymore.19:02
olofkAnd you're right about the exception handling. I got some reports from other python2 users about the urllib stuff. I think all URLError are handled now, but HTTPError must be fixed as well to be python2-friendly19:04
olofkThinking again, I guess that I could add a default fusesoc.conf to orpsoc-cores. That won't affect the current setup, but makes it trivial to also use your method19:07
olofkBut ideally, I don't really want any code in orpsoc-cores at all.19:08
andrzejrolofk, yes, I meant adding a config file to orpsoc-cores, not changing fusesoc.20:09
andrzejra question, how to force re-fetch of some cores? (other than deleting them from cache manually)20:13
andrzejrah, I just noticed you have fixed that urllib issue after I've cloned the fusesoc repo20:23
doomlordwould openrisc compile on a Zynq 701021:28
doomlord(an openrisc core  , of some sort)21:28
andrzejrdoomlord, I'm currently working on another 7-series device. Yes, it does work, but since there are no other designs available for this family of devices you would be on your own.21:35
doomlordi'm toying with the idea of getting a paarallella , it has a zynq, the more of interest the zynq can do the better21:36
doomlordi've not dabled with HDL's yet at all21:36
andrzejrby far the most difficult part is to get the ddr2 i/f working. Xilinx have redesign this par so the i/f from atlys board doesn't work.21:37
doomlordi've heard HDL's are flaky to use, a lot of bugs that aren't determined at compile time (more so than, say, C source), is that true?21:37
doomlordi mean its' very easy to write a C program that copmiles, but crashes21:38
doomlordsupposedly its even easier to write broken HDL21:38
andrzejrWriting HDL is not hard but if you have never done it before you should start from something simpler. Trying to make a new board working is not a good project for start.21:41
andrzejrwhat so special about zynq?21:43
doomlordjust the fact its on the Parallela board, which interests me for its' epiphany accelarator21:44
doomlord^ epiphany manycore chip21:45
doomlordit uses the Zynq to interface the eiphany manycore chip to memory. the epiphany chip just exposes its' NoC eLinks to the outside world. They implement DMA channels for it.21:47
doomlordsimple projects would be to devise various more elaborate DMA channels (gather indirect data, that sort of thing)21:47
doomlordthe idea of an actual opensource CPU is rather interesting21:48
andrzejrwhat are the cores in that epiphany chip?21:48
doomlordcustom , a pretty generic RISC. 64 registers, unified float/int registers21:49
doomlordit has no caches, just local-store, adressable on a grid21:49
doomlordits defining feature is the grid network-on-a-chip layout21:49
doomlordone of the barriers to getting decent software on it is the lack of even an i-cache21:50
doomlordif i could design my own processor on a whim, it would have that grid & scratchpads, but i-caches at least.21:51
andrzejrI guess you would run the os on Zynq's ARM core and just offload some computation to epiphany, just like with a GPU. If you like to play with software that seems like a fun project, but I don't seem much connection to openrisc here.21:52
doomlordright there is no connection.21:52
doomlordjust the fact there's an FPGA , whch could be used to dable with OpenRISC aswell21:52
olofkdoomlord: Yeah, I've been meaning to implement an OpenRISC-system on my Parallella as well, but haven't started working on it21:57
andrzejrIMHO openrisc on Zynq doesn't make sense - you've already got a powerful CPU in there, for which you paid 4x the price of a similar FPGA without that CPU. That embedded FPGA is just for glue logic + some hardcoded DSP.21:57
olofkThere was a guy a while ago who implemented support for building the Parallella with FuseSoC21:58
andrzejrlooks like not everyone agrees with me :-)21:58
doomlordyou're right it makes no sense for performance, it woudl just make sense 'to dable with an opensource processsor'21:58
doomlord^ if you just happen to have a Zynq around, and no other fpga21:58
olofkAgree. It doesn't make sense when you have two beefy ARMs, but it could still be fun, and it could be useful if there comes another board with an Epiphany with a ARM-less FPGA21:59
olofkI was offered a FMC board with an Epiphany for example22:00
doomlordwhats that22:00
andrzejrActually the board itself is fairly cheap ($99), the smallest Zynq is $57 on digikey and they add this extra chip. Not bad.22:00
olofkFMC is a standardized connector that is used to connect peripherals with many I/O22:00
andrzejr(I mean parallella board)22:01
doomlordok i see22:01
olofkYeah. I bought the Parallella partly to play with the Zynq since that was quite new when the kickstarter project was run22:01
olofkAnd this was a cheap way to get that and the Epiphany22:01
olofkOh well. Got to sleep now. Good night22:02
stekerneven with that beefy arm cpu, openrisc on the fpga for other tasks still make sense22:27
andrzejrstekern, do you have any specific examples? IMHO it would make sense if it was e.g. power efficient.22:36
andrzejrof course if it was a hard macro that is a completely different story - I'd love to see an open CPU with an open FPGA on the same chip.22:37
doomlordif you cared about performance, surely the FPGA would be best directly implmenting functions, rather than running a softcore22:42
--- Log closed Sun Aug 23 00:00:12 2015

Generated by 2.15.2 by Marius Gedminas - find it at!