| --- 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 applying | 07:00 |
|---|---|---|
| olofk_ | Finally! | 07:45 |
| olofk_ | Got the de0 nano test bench running in Icarus with the Micron SDRAM model and Altera's primitives | 07: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 ask | 07:54 |
| olofk_ | _franck__: I based my work on your de1 :) | 07:54 |
| sb0 | hi 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 logic | 07:57 |
| sb0 | I think so | 07:57 |
| sb0 | I never tried, but I imagine it would work without much hassle | 07:57 |
| olofk_ | Hungry baby IRQ. brb | 07:58 |
| sb0 | there are existing test benches that use iverilog with the migen interface | 08:02 |
| sb0 | they're slow of course, but maybe fast enough | 08:03 |
| olofk_ | sb0: I guess what I'm looking for is a way to run verilator simulations with as much of the RTL as possible | 08: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 model | 08:22 |
| sb0 | yes, the migen testbenches already do that | 08:22 |
| olofk_ | cool | 08:22 |
| olofk_ | Do you run simulations on the python code or on the generated verilog? | 08:23 |
| sb0 | why do you need verilator? it's painful to set up, so you'd only use it when you really need speed | 08: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 works | 08:24 |
| olofk_ | Sounds pretty cool though :) | 08:24 |
| sb0 | generated verilog - so it's possible to simulate legacy verilog code instantiated from migen easily | 08:24 |
| sb0 | iverilog, but VPI is semi-standard | 08:25 |
| olofk_ | sb0: Running Linux or anything related to say graphics would probably need verilator to be somewhat fast | 08:25 |
| sb0 | now that I'm getting familiar with LLVM, I might give a try at compiling the migen representation for fast simulations | 08:25 |
| olofk_ | Have you tried it with modelsim? (I know that Xilinx toy simulator Isim refuses to support VPI) | 08:26 |
| sb0 | I haven't run modelsim for ages | 08: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 though | 08:27 |
| olofk_ | You mean compile migen to LLVM IR and run that, right? | 08:28 |
| sb0 | it's less byte-oriented than C++ which is the base of Verilator | 08:28 |
| sb0 | yes | 08:28 |
| sb0 | the main problem is you'd still need to run Python code at every cycle | 08: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 |
| sb0 | best would be to combine that with a way to avoid running python at every cycle | 08:39 |
| sb0 | yeah, llvmpy would be the library to use | 08:39 |
| sb0 | but 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 constraints | 08:40 |
| olofk_ | Are you building an open-source death ray? | 08:48 |
| sb0 | http://www.nist.gov/pml/div688/ions-080812.cfm | 08:59 |
| blueCmd | olofk_: I think you did apply all except the generator, but I want to change some things in the generator so that's probably just good | 09: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 |
| sb0 | I have a contract through m-labs ltd | 09: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 request | 10:47 |
| olofk_ | hmmm... I think it would be a good idea to have two wb_intercon's in de0_nano | 11:34 |
| olofk_ | It's probably the same thing for other systems as well | 11:34 |
| olofk_ | One that just contains an arbiter between the debug connection and the or1k data bus | 11:35 |
| olofk_ | That would probably save a lot of logic | 11:35 |
| olofk_ | And most likely, we won't use them at the same time anyway | 11:36 |
| olofk_ | the data bus and the debug data bus that is | 11:36 |
| olofk_ | --trace_to_screen in mor1kx_monitor is pretty handy. | 11:48 |
| stekern | wallento: any idea about this? http://opencores.org/forum,OpenRISC,0,5489 | 16:38 |
| stekern | I'm just wild guessing, but I would assume that newlib would be the first suspect to look into | 16:38 |
| blueCmd | olofk_: seen this? http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 | 19:36 |
| blueCmd | apparently uses "cpu cards" | 19:37 |
| olofk_ | Yes, it's the same idea basically as SODIMM cards, right? | 19:38 |
| blueCmd | I guess | 19:39 |
| olofk_ | But eoma68 has specified pinouts which is a bit nier | 19:39 |
| olofk_ | nicer | 19: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 request | 20:41 |
| olofk_ | great | 20:42 |
| olofk_ | Watch out github! I'm unstoppable now | 20:45 |
| olofk_ | https://github.com/openrisc/orpsoc-cores/pull/68 | 20:45 |
| olofk_ | Time to give up now | 20:46 |
| blueCmd | olofk_: nice work! I'm really excited about that! | 21:03 |
| --- Log closed Fri Jun 06 00:00:21 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!