IRC logs for #openrisc Thursday, 2014-06-05

--- Log opened Thu Jun 05 00:00:20 2014
olofk_blueCmd: Did I apply all your fusesoc patches or did I miss any of them? I'm a little behind in my patch applying07:00
olofk_Got the de0 nano test bench running in Icarus with the Micron SDRAM model and Altera's primitives07:46
olofk_sb0: Perfect. I was just looking for you :)07:54
_franck__great, do that for my de1 board now :)07:54
olofk_Unfortunately I forgot what I was going to ask07:54
olofk__franck__: I based my work on your de1 :)07:54
sb0hi olofk_07:56
olofk_sb0: Ah yes... now I remember. Is the migen-generated sdram controller verilatable (probably not a real word). I guess not the phy part, but the core logic07:57
sb0I think so07:57
sb0I never tried, but I imagine it would work without much hassle07:57
olofk_Hungry baby IRQ. brb07:58
sb0there are existing test benches that use iverilog with the migen interface08:02
sb0they're slow of course, but maybe fast enough08:03
olofk_sb0: I guess what I'm looking for is a way to run verilator simulations with as much of the RTL as possible08:20
olofk_And when you talked about separate controller/phy layers, I thought it would make sense to run the controller in the simulation but switch out the phy and memory to a verilatable model08:22
sb0yes, the migen testbenches already do that08:22
olofk_Do you run simulations on the python code or on the generated verilog?08:23
sb0why do you need verilator? it's painful to set up, so you'd only use it when you really need speed08:23
olofk_And which simulators do you support? I've seen som VPI module to connect migen and verilog, but never really looked up how it works08:24
olofk_Sounds pretty cool though :)08:24
sb0generated verilog - so it's possible to simulate legacy verilog code instantiated from migen easily08:24
sb0iverilog, but VPI is semi-standard08:25
olofk_sb0: Running Linux or anything related to say graphics would probably need verilator to be somewhat fast08:25
sb0now that I'm getting familiar with LLVM, I might give a try at compiling the migen representation for fast simulations08:25
olofk_Have you tried it with modelsim? (I know that Xilinx toy simulator Isim refuses to support VPI)08:26
sb0I haven't run modelsim for ages08:26
olofk_Is LLVM feasible for that? It sounds like a good idea, but I've heard people write it off since it's too byte/word-oriented to be useful for RTL. Don't know anything about it myself though08:27
olofk_You mean compile migen to LLVM IR and run that, right?08:28
sb0it's less byte-oriented than C++ which is the base of Verilator08:28
sb0the main problem is you'd still need to run Python code at every cycle08:28
olofk_So what would be your plan? Compile the DUT to LLVM IR and generate/evaluate stimuli with the python code?08:34
olofk_ahh... is this where llvmpy comes in?08:36
sb0best would be to combine that with a way to avoid running python at every cycle08:39
sb0yeah, llvmpy would be the library to use08:39
sb0but my main use of it isn't that - it's for building a compiler for a DSL that runs complex physics experiments with tight real-time constraints08:40
olofk_Are you building an open-source death ray?08:48
blueCmdolofk_: I think you did apply all except the generator, but I want to change some things in the generator so that's probably just good09:03
olofk_sb0: Ah ok... not a death-ray :(09:16
olofk_But cool stuff. Were you already working for NIST or recruited to do this work?09:23
sb0I have a contract through m-labs ltd09:25
olofk_I have some changes for de0 nano that I would like to apply, but I have no board to test it with. Anyone up for some quick testing?10:41
olofk_Perhaps I should just prepare a pull request10:47
olofk_hmmm... I think it would be a good idea to have two wb_intercon's in de0_nano11:34
olofk_It's probably the same thing for other systems as well11:34
olofk_One that just contains an arbiter between the debug connection and the or1k data bus11:35
olofk_That would probably save a lot of logic11:35
olofk_And most likely, we won't use them at the same time anyway11:36
olofk_the data bus and the debug data bus that is11:36
olofk_--trace_to_screen in mor1kx_monitor is pretty handy.11:48
stekernwallento: any idea about this?,OpenRISC,0,548916:38
stekernI'm just wild guessing, but I would assume that newlib would be the first suspect to look into16:38
blueCmdolofk_: seen this?
blueCmdapparently uses "cpu cards"19:37
olofk_Yes, it's the same idea basically as SODIMM cards, right?19:38
blueCmdI guess19:39
olofk_But eoma68 has specified pinouts which is a bit nier19:39
olofk_I made some changes in a local branch of openrisc/orpsoc-cores. Can I just push my branch to github and make a pull request against master, or do I need to fork the repo first (to olofk/orpsoc-cores), then create a branch, add my patches and create a pull request from that one?20:36
_franck_you can push your new branch (git push -u origin my_new_branch) and then do a pull request20:41
olofk_Watch out github! I'm unstoppable now20:45
olofk_Time to give up now20:46
blueCmdolofk_: nice work! I'm really excited about that!21:03
--- Log closed Fri Jun 06 00:00:21 2014

Generated by 2.15.2 by Marius Gedminas - find it at!