--- Log opened Mon Mar 17 00:00:24 2014 | ||
olofk_ | blueCmd: It's from CERN, right? | 06:47 |
---|---|---|
olofk_ | Just realized that this web connection has been up for almost a week now. That's impressive | 06:53 |
_franck_web_ | olofk: ok, I'll check for error codes 127 and 2 when shell=True | 07:42 |
olofk_ | hmm... wait a minute | 08:22 |
olofk_ | It might work to set 'perl' as the command, and set the verilator binary as the first argument | 08:22 |
-!- xlro` is now known as xlro | 08:23 | |
olofk_ | Yep, that seems to work | 08:42 |
_franck_web_ | great | 08:45 |
olofk_ | _franck_web_: Is shell=True only used for verilator? In that case, I think we should change to something like this http://pastie.org/8937316 | 08:46 |
olofk_ | (Haven't tested it) | 08:46 |
_franck_web_ | olofk_: don't know, didn't grep for that yet | 08:47 |
olofk_ | _franck_web_: Looks like the only other place where we use shell=True is when we launch the scripts | 08:49 |
olofk_ | And in those cases we want a shell | 08:49 |
_franck_web_ | ok so we're good :) | 08:54 |
blueCmd | olofk_: yes i think so | 10:39 |
olofk_ | blueCmd: I have looked at it, but not used it | 10:49 |
blueCmd | olofk_: fair enough | 10:53 |
_franck__ | olofk: if VERILATOR_ROOT is not set, we are going to launch "perl verilator --cc ...." and it's not going to work | 11:56 |
olofk_ | _franck__: We are already running which verilator, so we could use the output from that | 13:03 |
olofk_ | So it basically becomes "perl `which verilator` --cc..." | 13:04 |
_franck_web_ | the idea was to remove which | 13:08 |
olofk_ | Yes, I want to get rid of that too | 13:12 |
olofk_ | Hmm.. | 13:12 |
_franck_web_ | olofk: like you suggested here: https://github.com/olofk/fusesoc/pull/2 | 13:37 |
jungma | hey, i verilated the OR and wrote a wishbone transactor for tlm2 AT, i'm using it in synopsys platform architect, and it seems to work. However, now i want to test it with software, what is the right toolchain/library to generate code? I fount at github: or1k-gcc, or1k-src? | 15:15 |
jungma | found | 15:16 |
blueCmd | jungma: those are the latest yes | 15:20 |
olofk_ | jungma: Nice! I'm very interested in that model. Are you planning to share it? | 15:22 |
olofk_ | _franck__: | 15:24 |
jungma | olofk_: if it is working yes ;) | 15:24 |
olofk_ | _franck__: Have to think about that some more. It would be nice to remove shell=True. I think that is slightly worse than using which to find the path | 15:25 |
olofk_ | jungma: Cool. Is it available somewhere now? If not, just give me a ping when it's ready for the masses | 15:26 |
jungma | olofk_: I want to use it for my research, since i developed a lot of TLM models for memory controllers and Wide-I/O DRAM i need a cycle accurate processor model with TLM interface | 15:26 |
jungma | olofk_: yes, i will stay here in the channel for while, and then i'll give you a ping when i tested everything | 15:27 |
olofk_ | Sounds great, and don't hesitate to ask for help if you need any | 15:28 |
jungma | olofk_: okay thanks, first I want to run a simple hello world, to get printf working with a TLM UART component ;) | 15:32 |
stekern | _franck__: what triggers the cpu0_rst signal from adv_debugsys to go high? | 19:38 |
stekern | 'reset' command in openocd? | 19:38 |
_franck__ | stekern: I guess so | 20:04 |
stekern | ok.. I better make sure | 20:04 |
stekern | right now my setup works if I load the SDRAM with openocd and then hit the reset button | 20:05 |
stekern | and I have connected that cpu0_rst to the cpu reset | 20:05 |
stekern | but the 'reset' command in openocd doesn't work | 20:06 |
stekern | there's of course other differences in hitting the reset button and that, the reset button is connected to wb_rst | 20:06 |
_franck__ | you can try "reset run" | 20:07 |
stekern | no luck | 20:08 |
_franck__ | this is the "not much tested" part of openocd | 20:09 |
stekern | it's a bit hard to debug since I can't do signaltap at the same time | 20:10 |
blueCmd | verilog people. output 'reg' or not? | 20:11 |
blueCmd | I want to say 'not', but I'm rusty | 20:11 |
stekern | if it's a reg, then why not? | 20:11 |
_franck__ | stekern: that's an anoying issue, some times ago I was about to interface openocd with ALtera jtag server TCL interface | 20:12 |
blueCmd | it doesn't do anything weird like actually use some extra memory for it? | 20:12 |
stekern | blueCmd: it becomes a 'reg', an annoying notion in verilog ;) | 20:12 |
stekern | if it actually becomes a register, depends on how you assign it | 20:13 |
_franck__ | stekern: soft_reset_halt ? | 20:15 |
_franck__ | then "run" | 20:16 |
stekern | what does "run" do? | 20:16 |
stekern | in terms of hw signals? | 20:16 |
stekern | nothing I assume, since openocd tells me this: invalid command name "run" | 20:17 |
_franck__ | I meant "resume" | 20:18 |
stekern | ok, so what does that do in terms of hw signals? | 20:18 |
stekern | it didn't work in either case | 20:19 |
* _franck__ is looking at the code | 20:19 | |
stekern | bah, crap... typo in the signal assignment | 20:20 |
stekern | another fantastic feature of verilog | 20:21 |
_franck__ | I would say it unstall the cpu (cpu0_stall_o) | 20:21 |
stekern | ok, that is of course not connected to anything in my case | 20:21 |
_franck__ | you should connect cpu0_rst_o to a led and try soft_reset_halt | 20:22 |
stekern | but let's start over from the top, with the signal actually connected to anything... | 20:22 |
stekern | yes, or to a register that I can read over the wb_bus | 20:22 |
_franck__ | yes, even better | 20:23 |
stekern | ok, still not working when properly connected, I'll dig deeper | 20:55 |
wkoszek | Did somebody ask why OpenRISC weren't accepted for this years' GSOC? | 21:09 |
_franck__ | olofk_: would you mind if I add colors and carriage return to fusesoc output messages ? It is sometimes hard to read. | 22:33 |
--- Log closed Tue Mar 18 00:00:25 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!