IRC logs for #openrisc Thursday, 2013-08-08

--- Log opened Thu Aug 08 00:00:02 2013
stekernolofk: ok, but what does the tools do? i.e. how does it work09:53
stekernsay I have my rtl in there, what is it that orpsocv3 do? and how do I make it do that?09:54
stekernand is the 'generic' and 'generic-or1200' usable? and what's the difference between the two?09:55
stekernsay I want to run a simulation with the generic 'system', how do I do that?09:55
* ams ponders.10:46
olofkstekern: Both systems should be usable. Try orpsoc sim or1200-generic --or1k-elf-load=<path to elf file with test case>11:43
olofkgeneric is made to mimic the reference system from orpsocv2, and should be synthesisable11:45
olofkor1200-generic is a minimal system that is mainly for testing or1200 itself11:46
arokux1hi stekern11:47
arokux1stekern, are there any todos for orpsocv3?11:48
olofkarokux1: I'm the one who's doing orpsocv3, and yes, there are lots of todos :)11:48
arokux1olofk, is there a list of them?11:51
olofkarokux1: Yes, but it's a bit incomplete and not very up to date. You can find it in the orpsoc repo at git.opencores.org11:52
arokux1olofk, ok!11:53
olofkI'm currently working on verilator support and some helper functions to easier create wishbne interconnect blocks11:54
arokux1ok, i'd need to learn a lot of things before I can do smth, I was asking for an entrance point.11:55
olofkEntrance point for doing OpenRISC stuff in general?11:56
arokux1olofk, for doing hardware design, at the high level for the start i.e. assembling boards11:57
olofkI'm not very good at those things, unfortunately12:00
arokux1olofk, what are you doing then?12:01
olofkCreating a framework for connecting cores, running simulations and create FPGA images.12:04
olofkI haven't done any PCB design at all12:05
arokux1ah wait, soc is only a part of a board12:05
arokux1do you also do board assembly in the project?12:06
olofkNo, I only generate the contents of the FPGA. Maybe you should talk to the guys at dangerous prototypes. The do a lot more board designs12:07
olofkThey seem to have a very active community for it too12:08
arokux1thank you olofk12:08
arokux1btw, do you know about upverters?12:08
olofkI guess it's the opposite of a downverter :)12:09
arokux1olofk, no, has nothing to do with it :)12:09
olofkIs it something like the "Ham it up"?12:10
olofkI might be the wrong guy to ask here. Only wild guesses12:10
arokux1olofk, no, it's like github only for hardware projects12:12
olofkaha. That's cool. Should check it out for some ideas12:12
olofkWhat we are doing here falls a bit inbetween software and hardware, so we struggle a bit with our identity and don't feel welcome anywhere12:15
olofkIn fact, we are so linely that we had to create our own conference...only for us12:15
olofkBut at least we have our own cheerleader group. Go SoC Kittens!12:23
arokux1I see olofk12:24
arokux1olofk, the problem for you is that you cannot produce (real) prototypes and are force to do it in FPGA, that is why it is between software and hardware?12:55
stekernno, the problem is that rtl design is a gray zone between hardware and software design12:57
stekernat least in the open source world12:57
hnoarokux1, what is "real" prototypes?12:58
arokux1hno, chips in silicon, not fpga, anyway it was just a thought.12:59
hnoarokux1, making silicon is very late in the process. There is silocon versions of OpenRISC even (Allwinner A31 have one)13:01
arokux1hno, ok13:05
stekernand FPGA is not (necessary) equal to prototyping13:07
olofkGreat. Got a verilated model now. Time to raid orpsocv2 again for some test bench glue logic13:10
olofkI chose to go with pure c++ output from verilator to avoid a dependency on systemc. Any downsides to that?13:11
stekernno idea13:16
stekernthanks for the hand holding btw13:16
stekernI like the debug flow I have with verilator, right now I'm debugging a problem that only shows itself when I run gcc with hw tlb reload enabled13:17
stekernpretty hard to pin down in both simulations and hw13:18
stekernso what I do instead is to add a bit of $displays with possible corner cases, run things in verilator to get the $time when it happens13:19
stekernthen rerun with vcd generation on around that $time13:20
olofkstekern: It's good to know what kind of features that people are looking for. Both verilator support and delayed VCD generation is on my todo list14:00
olofkI also plan to add sqlite support to or1200-monitor (and mor1kx-monitor) so I can analyze large instruction traces more efficiently14:01
olofkMy linux boot experiment in icarus was a pain since I got several GB of clear text log files to look at14:02
stekerndelayed VCD generation, but what also would be nice would be triggered VCD and trace generation14:16
stekernand (if at all possible) vcd ring buffer is a feature I'd like14:17
stekerni.e. to have a fixed (say 500MB) size vcd backlog14:18
stekernI don't mind the clear text trace logs14:19
stekernI wouldn't care using compressed/sqlite trace logs14:19
stekernbetter to selectively generate the text logs then14:19
stekernI pretty often direct the output to a named pipe and then tail -f that14:22
stekernor grep it for something I'm interested in14:22
--- Log closed Fri Aug 09 00:00:03 2013

Generated by 2.15.2 by Marius Gedminas - find it at!