IRC logs for #openrisc Saturday, 2016-09-03

--- Log opened Sat Sep 03 00:00:54 2016
SMDhome1olofk: clear_ram was introduced due to problems w/ uninitialized ram in dhrystone, so it's required. At least for icarus02:16
wallentoThere is a bug in vivado so that it crashes only on haswell processors (at least in ubuntu): https://github.com/MyrtleSoftware/glibc-no-lock-elision03:59
olofkSMDhome1: Yeah, you're right. It's probably safest to use clear_ram, but for most programs it shouldn't be needed07:32
olofkCan you sign up for as many accounts as you like on github?08:11
wallentoolofk: you want more likes for fusesoc? ;)08:14
olofkFuseSoC is a stronger brand name than I am :)08:17
olofkWith the changes to versioning, I'm considering freezing orpsoc-cores now and move the cores I want to keep to a new repo08:17
olofkAnd that could also be a good time to first of all rename it to fusesoc-cores or something like that08:18
olofkAnd also to create a new account that contains just FuseSoC-related things. I fear I'm getting close to the 50-repo limit08:18
olofkwallento: I took a look at your forked FuseSoC repo btw. Would it be much work to rebase that on latest fusesoc master?08:21
olofkAnd great blog post. Good work by you, Philipp and the others08:21
wallentoI will do this today I think08:24
wallentoI started my personal fusesoc_cores repo too08:24
wallentowith subfolders: boards, systems, cores08:24
wallentoand I started using some more hierarchy in cores08:24
wallentowith the new vlnv scheme08:24
wallentoI will put something in the Wiki of my repo about the new system=board+core abstraction I use08:25
olofkI liked the idea to separate boards and systems08:26
wallentomy current plan is (mor1kx,pulpino,lowrisc)->(arty,nexys4,kc705)08:27
olofkok, I did a diff of our repos. These are the functional differences that I found08:28
wallentoyou still need the toplevel glue logic in a "system", but it shouldn't be too much of a problem for now08:28
olofkVivado, DPI, verilator use sim instead of synth, xsim project mode, skip empty core directories, lists-paths, FUSESOC_CORES env var08:28
olofkYes. I don't want to spend too much effort trying to make FuseSoC to clever things with top-level glue logic08:29
olofkBetter to handle that manually or with IPXACT08:29
wallentoyes, agree08:29
wallentoolofk, any of those you don't want in FuseSoC at all?08:30
olofkMight be08:30
olofkThe verilator sim vs. synth thing might already be too late08:30
wallentoyes, I can double check that08:31
olofksince it will break backwards compatibility to change it now.08:31
wallentoit is no pain to have synth and sim for what I would consider sim-only, right08:31
olofkAnd you know I'm not a big fan of env vars, but I might give in to pressure on that one :)08:32
wallentoIt makes it way easier for us08:32
wallentootherwise we would wrap the fusesoc call08:32
wallentoalso possible08:32
olofkOr just create a fusesoc.conf08:32
wallentoactually we don't want to bother users to much with such things08:33
wallentoespecially if the file is always the same08:33
wallentoor he has to change something in his home config or so08:33
wallentoit is way easier to just put it into our env.sh08:33
wallentobecause that is something we always need08:34
wallentoah, I saw your issue reply, by the way: opencores mailing lists are dead now08:34
olofkoh08:34
olofkWhich reply do you mean08:35
olofk?08:35
wallentoyou directed someone to the new mailing list08:35
wallentoI tried to cross post to the old08:36
wallentojust came to my mind now08:36
olofkCan't you put this in your env.sh? :) echo -e "[main]\ncores_root=something" > fusesoc.conf08:37
wallentonaaa08:37
wallentothat would do something in the current folder08:38
wallentoit should just be known to the environment :)08:38
olofkI give up08:38
wallentothats good08:38
wallento;)08:38
olofkYou can have your damn env var :)08:38
wallentootherwise I would fork it :-D08:38
olofkYou already did!!08:40
olofkMaybe we should pick up the env var in config.py instead, where all the other path trickery is08:41
wallentoyes, I can check it later. my computer is currently un-nice as I am building android in "background"08:42
olofkoh dear08:42
wallentoits unbelievable this sh*t actually works on a gazillion of phones..08:43
olofk:)08:43
olofkSo from my perspective it would be easiest to first add the path stuff, then switch over xsim to project mode (if you can justify that change), add the Vivado backend and finally we can talk about how to best implement DPI08:44
ZipCPU|Laptopwallento: Have you made any progress with the Arty memory, or am I the only one trying to get that to work with wishbone?08:49
olofkZipCPU|Laptop: I think he's using a wb to axi bridge08:55
olofkI know that andrzejr tried to make a wishbone wrapper to the Xilinx UI interface instead08:56
olofkAnd I think that the full open source controller that _florent_ et al has been working on has a wb interface as well08:56
ZipCPU|Laptop_florent_ has been working on ... a DDR3 open source controller?08:57
olofkZipCPU|Laptop: Yes. I'm sure I've mentioned this before. Not sure if _florent_, mithro or someone else should get the credit for that one though08:57
ZipCPU|LaptopFascinating.08:58
olofkIt's based on migen08:58
ZipCPU|Laptopmigen ... do you have a link for that?08:58
olofkhttps://github.com/m-labs/migen08:59
olofkIt's a python framework to do RTL designs08:59
ZipCPU|LaptopGot it.08:59
olofkIt can output verilog08:59
ZipCPU|LaptopWhat I'm now struggling with is the interface between logic and I/O.08:59
olofkThe main usage is to build complete SoCs in that language, but it can also be used to generate stand-alone cores08:59
ZipCPU|LaptopXilinx built some very nice hardware helpers ... but then declined to document any of them.08:59
olofkOh yes. It's horrible09:00
ZipCPU|LaptopAt least they made their code available ... it seems like the entire MIG generated code gets delivered in any MIG project.09:00
olofkyep09:00
ZipCPU|LaptopThe differences being only the configuration.  They're not even excluding parts that aren't in use--just give you everything.09:01
olofkBut they're using some undocumented primitives, at least in the virtex-6 backend09:02
olofkAnd also, the interface towards the user differs between the FPGA families09:02
ZipCPU|LaptopThey're doing there's on a Virtex-6?09:02
olofkI mean MIG09:03
ZipCPU|LaptopThe 7-series phy is significantly different from the 6-series, or so Xilinx says ...09:03
ZipCPU|LaptopOh ... got it09:03
olofkSure, the phy is of course different, but they also change the user interface between EDA versions and FPGA families09:03
wallentoZipCPU, yes, mig and wb2axi09:03
wallentoworks okay for now09:03
wallentoI had my months with the mig user interface in virtex5 and spartan6 already...09:04
olofkSo a straight-forward upgrade from a MIG targeting V5 to one targeting V6 turned out to be a complete mess09:04
ZipCPU|Laptop"a complete mess" --- thank you for your pleasant, but accurate, description.  ;)09:05
ZipCPU|Laptopwallento: Ever thought about pipelining the wb2axi controller?  To see if you couldn't achieve a throughput of one access per clock?09:10
wallentoyeah, of course09:21
wallentoits just a start to ramp up09:21
wallentonext is bursts and timing decoupling09:22
wallentoAlways looking for help of course :)09:24
wallentobursts are better in the other direction actually, but I think we can easily support the default fixed-size bursts09:24
wallentoburst reads of undetermined length are the hardest, it means doing speculative reads09:25
ZipCPU|LaptopIf you are interested in help, then I'd love to try my hand at it.  I would need, however, a good reference document describing the ARM AMBA interface.  Any suggestions?09:50
ZipCPU|LaptopMy goal would be to support WB4 pipeline mode--which is what I'm using with all my work.09:51
ZipCPUHere it is: http://www.gstitt.ece.ufl.edu/cvourses/fall15/eel4720_5721/labs/refs/AXI4_specification.pdf10:32
ZipCPUs/cvources/courses/10:35
olofkUnknown burst lengths in wb is a pain10:43
olofkThe quickest solution would probably be to just add a burst length signal10:44
olofkBut I've been thinking quite a lot about this10:44
ZipCPUI can handle unknown burst lengths ...11:29
ZipCPUThe first version I built of the DDR3 controller (of the many attempts I've made) handled grabbing 32-bits of a 128-bit access without much hassle.  It even handled pipelining across all 128-bits.  (If you requested all four, you got all four, if you requested fewer you got fewer).  My point: it's quite doable.11:31
ZipCPUThe issue is knowing the natural data rate of the interface.11:31
wallentoyeah, but for mapping to axi it is an issue12:11
wallentobut as you say, it is still possible to do it12:11
wallentoolofk, isn't bte or how its called meant for that12:12
wallentoI remember there was something like 8 beat wrap bursts12:12
wallentothe cache should do those12:12
wallentoand the core can have a parameter like DEFAULT_BURST_LEN12:12
wallentoWhat I am undecided about is a real good test strategy12:24
wallentoolofk: does the wb bfm handle such wrap bursts?12:41
wallentoalready found it, it does12:47
andrzejrolofk, ZipCPU, wallento, I indeed tried making the WB->UI bridge but the version that works "reliably" has burst capabilities disabled.13:03
andrzejrI've solved some errors with bursts but afair there was still something wrong with the bridge.13:04
andrzejrOn top of that, the DDR2 controller had some issues on its own (seeing only half of the memory etc).13:05
ZipCPUandrzejr: Can I see how far you got?  I'm studying AXI now for this purpose ...13:37
andrzejrZipCPU, https://github.com/andrzej-r/orpsoc-cores/tree/nexys4ddr/systems/nexys4ddr/nexys4ddr_ddr2_wb/rtl15:12
andrzejr"wire classic       = wb_cyc_i &  wb_stb_i & wb_cti_i == WB_CLASSIC;" in *wb_to_ui.v enables bursts15:14
andrzejrBut if you want efficiency, you should avoid using wb bus between cpu's cache and memory in the first place. Both axi and ui busses are much better for that purpose.15:16
ZipCPUandrzejr: "HTTP request sent, awaiting response... 404 Not Found"15:22
ZipCPUIs that the right address?15:22
andrzejryes, strange, works just fine here.15:24
andrzejrtry to dig down to it starting from https://github.com/andrzej-r15:24
ZipCPUUnder tree, I get an error.  Under systems, I don't see nexys4ddr.15:27
ZipCPUOkay ... I might've found it ...15:28
ZipCPUOkay, I've got it now.  Funny, cloning andrzej-r didn't get it ....15:29
andrzejrBTW, the controller files are in https://github.com/andrzej-r/orpsoc-cores/tree/nexys4ddr/systems/nexys4ddr/nexys4ddr_ddr215:32
andrzejrnot sure if that works with the current version of fusesoc (they rely on ISE code generator/provider for producing the code)15:33
ZipCPU|LaptopWell ... I have somewhat of a DDR3 simulation, THAT WORKS, in Verilator in the wbddr3 project.15:35
andrzejrIt's probably best to use Vivado for that these days. Potentially the reason for problems with the DDR controller I was seeing in the past.15:35
ZipCPU|LaptopThe problem is it doesn't match the Xilinx interface--and wouldn't know what to do with it.15:35
ZipCPU|Laptopandrzejr: Did you do anything to handle out of order responses?15:50
andrzejrNo. UI spec (supposedly) guarantees there are no out of order responses.15:51
ZipCPU|LaptopWB UI, or AXI UI?  WB certainly makes that guarantee, does AXI?  I thought MIG did not ...15:51
andrzejrMy code does not use AXI. It's a direct bridge from WB to UI.15:52
kc5tjaWhat does UI stand for in this context?16:45
andrzejrkc5tja, a custom bus Xilinx uses for their DDR controllers16:50
--- Log closed Sun Sep 04 00:00:56 2016

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