| --- Log opened Fri May 20 00:00:14 2016 | ||
| zump | hey | 07:52 |
|---|---|---|
| SMDwrk | hi | 07:53 |
| zump | does anyone know about hw/sw co simulation | 08:00 |
| SMDwrk | in terms of openrisc? | 08:01 |
| zump | in general | 08:04 |
| SMDwrk | I have something like that at work, but I don't know if this could be helpful | 08:05 |
| zump | lets say you have some RTL of some core i.e a uart. is it possible to convert that to C, and then use it in firmware as some static lib such that "fake" register writes in firmware could produce the same functionality (tho much slower of course) | 08:07 |
| SMDwrk | Is verilator what you need? | 08:12 |
| SMDwrk | it converts verilog to c and then you can use C model of your core | 08:12 |
| zump | is it a simulator.. or just a compiler? cause a cycle accurate simulator would be slow :( | 08:15 |
| SMDwrk | it's a compiler | 08:32 |
| SMDwrk | but I don't know for sure (= | 08:33 |
| SMDwrk | at least it's faster than iverilog | 08:33 |
| olofk | zump: It's surprisingly fast. Orders of magnitude faster than event-based sims | 08:40 |
| zump | whats the difference btween verilator and carbon? | 08:42 |
| SMDwrk | olofk: http://pastebin.com/QaY3zKNY I can't run verilator with fusesoc btw, have you seen that problem? | 08:42 |
| olofk | SMDwrk: Haven't seen that one. Which version of verilator are you using? | 08:43 |
| olofk | ahh.. wait.. it's regarding $fflush. Hmm... I remember there was some problem with that now | 08:45 |
| SMDwrk | apt-cache policy verilator | 08:45 |
| SMDwrk | verilator: | 08:45 |
| SMDwrk | Installed: 3.856-1 | 08:45 |
| SMDwrk | Candidate: 3.856-1 | 08:45 |
| SMDwrk | Version table: | 08:45 |
| SMDwrk | *** 3.856-1 0 | 08:45 |
| SMDwrk | 500 http://ru.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages | 08:45 |
| SMDwrk | 100 /var/lib/dpkg/status | 08:45 |
| SMDwrk | sorry | 08:45 |
| olofk | If you can, I would recommend you to update to a newer version of verilator | 08:47 |
| SMDwrk | Ok, I'll check that at home on arch instead of ubuntu | 08:47 |
| SMDwrk | thanks | 08:47 |
| olofk | SMDwrk: Otherwise, I think you can do a quick hack and remove the argument to $fflush in on line 275 in uart_transmitter.v | 08:51 |
| SMDwrk | zump: http://www.embecosm.com/appnotes/ean6/embecosm-or1k-verilator-tutorial-ean6-issue-1.html 2.5 | 09:04 |
| wallento | zump: carbon and verilator are similar | 09:20 |
| zump | wallento: so the RTL model can't run in real time? :( | 09:21 |
| wallento | I heard someone saying verilator was significantly faster | 09:21 |
| wallento | only if it is sufficiently small | 09:21 |
| wallento | if its a small controller and its target frequency is like 50 MHz, it can also run in real time | 09:21 |
| wallento | but once you start talking about adding a processor its much much slower | 09:22 |
| zump | wallento: well what i want to do is write a UART.. and then compile it and deploy it to some microcontroller. and then write the microcontroller firmware as if actually exists in silicon. do you think thats possible? | 09:25 |
| SMDwrk | you want to run verilated model on mcu? | 09:26 |
| zump | yes.. | 09:26 |
| SMDwrk | What kind of controller are we talking about?) | 09:26 |
| wallento | That won't run in real time | 09:30 |
| wallento | why do you need it to be in real time? | 09:30 |
| zump | wallento because i want to write the real FW before the chip is taped out | 09:35 |
| olofk | zump: That doesn't mean you have to run it in realtime | 09:36 |
| SMDwrk | zump: why not using fpga? | 09:36 |
| zump | our design is too big for an FPGA :) | 09:37 |
| ZipCPU | zdump: Your UART design is too big for an FPGA? | 09:37 |
| SMDwrk | Use bigger fpga ;) | 09:38 |
| ZipCPU | Come on guys, this is ridiculous. If you can stick a micro-controller and a UART controller in a Spartan LX4, the problem isn't the size of your FPGA. | 09:39 |
| zump | The UART is just an idea for a proof of concept.. Im not a HW guy so it seems risky for this design to be coded up without firmware beeing proofed for it. Im just wondering what the current solutions in EDA are for it. | 09:39 |
| zump | basically, i cant use an fpga. | 09:40 |
| ZipCPU | zdump: It doesn't take much of a budget to learn ... | 09:40 |
| SMDwrk | then run rtl through verilator and test your firmware there: actual emulatuon speed could be in kHz but what's the problem? | 09:41 |
| zump | SMDwrk: so i can "hook in" firmware into whatever is produced by verilator? | 09:42 |
| ZipCPU | zdump: It may depend upon what you consider firmware. Are we talking ROM code, microcode, or something else? | 09:44 |
| SMDwrk | sure, but things could not be as easy as it sounds: you also have to write some wrappers and etc to get things working | 09:44 |
| SMDwrk | fusesoc can run openrisc simulations with verilated sources: I think they use jtag to upload code, but I'm not sure | 09:44 |
| zump | ZipCPU: writing registers, handling interrupts, etc.. | 09:45 |
| ZipCPU | zdump: Okay, very low level software then. Do you have Verilog available for the CPU you wish to deploy this firmware for? | 09:46 |
| _franck__ | zump: you can run any firmware you want if you verilate your cpu's RTL | 09:46 |
| zump | I don't want to do the entire CPU.. i want to verilate a specific core which would be on the same SoC as the CPU, and then read/write the verilated core using code on the CPU (though underneath, it will just be instructions, not silicon) | 09:47 |
| _franck__ | where would you run the CPU ? | 09:49 |
| ZipCPU | zdump: If you don't wish to verilate the entire CPU, then ... are you hoping to write, run, test the firmware on a different verilated CPU? | 09:49 |
| _franck__ | I mean your firmware is executed by the CPU so if you don't simulate the CPU ... ? | 09:49 |
| zump | in the actual SoC. that exists. but doesnt contain the new core as yet. | 09:49 |
| zump | *CPU in the SoC that is.. | 09:51 |
| _franck__ | so you need some sort of bridging between your hardware and some simulated software | 09:51 |
| ZipCPU | zdump: Let's see if I can summarize the details to this point: You are working to develop the firmware for an existing CPU. You'd like to create a new/better peripheral for this CPU, and want to make certain that the firmware works before the CPU with this peripheral is taped out ... right? | 09:52 |
| _franck__ | ibut without any core to communicte how would you do that ? | 09:52 |
| zump | ZipCPU: yeah sounds about right.. | 09:52 |
| zump | except its really a core on a SoC, rather than a peripheral for a CPU | 09:53 |
| ZipCPU | zdump: By core, you mean that it is going to be internal to the SoC, rather than an external peripheral, right? | 09:54 |
| zump | yep | 09:54 |
| _franck__ | zump: but if your CPU is not tapped out, not simulated and not in a FPGA...where it is ? | 09:54 |
| zump | in an existing ASIC | 09:55 |
| zump | its just a rev that doesnt have the new RTL in silicon | 09:55 |
| ZipCPU | Okay, this is starting to make sense. Do you have any form of simulator that can simulate your ASIC? | 09:55 |
| zump | no.. but we are looking at getting Carbon. | 09:57 |
| zump | but ive seen a demo of that. and it seems slow. I would like something that operates in near real time | 09:57 |
| ZipCPU | zump: Okay, but you've got the previous version of the ASIC, right? | 09:57 |
| zump | ZipCPU: yes | 09:58 |
| ZipCPU | So, if I understand correctly, what you'd like is an external peripheral to the real/current ASIC that you can develop against, right? | 09:58 |
| zump | yea | 10:01 |
| ZipCPU | If yes, then you still have some options. One classic one would be to connect a piece of reconfigurable hardware to your ASIC. You could then develop on that hardware and get your core and firmware working. The difficult part here would be that the external interface between the ASIC and the core would be ... other than true. | 10:01 |
| ZipCPU | Did I capture that right? | 10:01 |
| zump | that's true | 10:03 |
| zump | i dont think the hw guys would like that though | 10:03 |
| zump | haha | 10:03 |
| ZipCPU | zdump: Ok, if you don't want to develop on real hardware connected to a real processor, and you don't have a simulator for your real processor to enable you to develop on simulated hardware, then where do you wish to place the boundary between real hardware and your development environment? | 10:06 |
| zump | In theory, my verilator idea should work. Compile to static lib, link with firmware. Hack around with a thread that polls for a variable in the model and go into an interrupt handler if asserted | 10:06 |
| zump | on the chip itself? :P | 10:07 |
| zump | something like that isnt *too* far fetched is it? I should try it | 10:07 |
| zump | Is there some 'hello world' RTL out there? | 10:07 |
| zump | https://www.testandverification.com/DVClub/14_Jan_2013/DagBraend.pdf | 10:10 |
| zump | hah.. im not the first with this idea | 10:10 |
| ZipCPU | zdump: So ... you want to develop real software, running on real hardware, that will communicate with a Verilated core also running on that hardware and act like ... a simulated core. | 10:10 |
| ZipCPU | I'll say this, it's not how I've ever used Verilator before. Do you have any experience or background with Verilator? Have you simulated any cores with it before? | 10:11 |
| zump | ZipCPU: nope.. | 10:12 |
| zump | ZipCPU: so you're saying its not a "functional" simulation like I'm thinking, and it's more like a RTL simulator like quartus II like I used at university? | 10:13 |
| ZipCPU | I can't speak for quartus II--but I thought it was a development environment for an Altera FPGA, not a simulator ...? | 10:14 |
| ZipCPU | Verilator allows you to calculate logic outputs given logic inputs. You still need to provide those logic inputs, however. One of the most fundamental inputs you will need to provide is a clock tick. Without ticking the clock, nothing will happen. (It doesn't go and run on it's own, although you could create a separate task and communicate with it via some form of IPC.) | 10:15 |
| zump | yeah.. so I was thinking the verilated model could run in its own thread. | 10:16 |
| ZipCPU | It's doable. You'll be spending a bit of time writing your thread communications though | 10:17 |
| zump | except i have another problem | 10:17 |
| ZipCPU | Go on. | 10:17 |
| zump | and that's simulating data transfer | 10:18 |
| ZipCPU | You mean, something like a DMA data transfer? You can't do that via a piece of shared memory? | 10:18 |
| zump | The HW guys use some sort of system called AXI. I have to somehow remove that in each verilog block and replace it with, you know, memcpy. | 10:18 |
| ZipCPU | <Cradles head in hands and weeps> | 10:19 |
| zump | Haha | 10:19 |
| zump | thats probably my bigger problem... | 10:19 |
| zump | each core is heavily dependent on signals from system backplane | 10:20 |
| ZipCPU | <Still drying eyes> As I understand AXI, it is a bus interface similar, but different from, the wishbone interface I have become accustomed with. | 10:22 |
| zump | yeah its probably the same. i recall coming across wishbone/axi bridges | 10:22 |
| zump | so you were able to simulate wishbone in verilator? | 10:22 |
| ZipCPU | Sure! Simulating wishbone is easy. I wish every problem were that easy. | 10:23 |
| ZipCPU | Would your Verilator simulator have access to and command/read real hardware wires, or would it be simulating the actual hardware interaction as well? | 10:23 |
| zump | I had a look at the rtl before, and every core uses the 5 axi slave signals.. i have no idea how i would handle that in the verilator simulation.. maybe i could write some wrapper code to generate the correct AXI transactions? haha | 10:26 |
| zump | ZipCPU: How do you provide the correct IO for wishbone bus signals? | 10:26 |
| zump | in verilator | 10:26 |
| ZipCPU | So my big project can be found at http://opencores.org/project,zipcpu This is what I've been investing my time into for a while. | 10:28 |
| ZipCPU | In that project, in the trunk/bench/cpp directory, you'll find a program called 'zippy_tb.cpp'. This is the code for my Verilator simulation of my soft-core CPU. | 10:28 |
| ZipCPU | Within that file, you'll find code for wb_write(addr, value) and wb_read(addr). | 10:29 |
| ZipCPU | Basically you set the CYC and STB lines high, tick the Verilator model, drop the STB line when the STALL line is low, and then wait for the ACK line to go high. | 10:30 |
| ZipCPU | When ACK is high, read the data off the bus and drop the CYC line. | 10:30 |
| ZipCPU | (Oh, did I mention that when you set the CYC line, you also need to set the address, whether or not you are writing and if so the data lines ... and I think I've just about got it there.) | 10:31 |
| zump | ok, so in your software TB, you're faking a hardware transaction? | 10:31 |
| olofk | zump: What you need then is a BFM (Bus Functional Model) | 10:31 |
| olofk | I have written one for Wishbone | 10:31 |
| olofk | It allows you to do reads and wri | 10:32 |
| zump | olofk: got a link? | 10:32 |
| olofk | tes from a testbench | 10:32 |
| olofk | zump: https://github.com/olofk/wb_bfm | 10:32 |
| olofk | But that unfortunately won't run in verilator | 10:32 |
| zump | so if my scheme is to be successful, I would have to follow the AXI protocol while ticking the model correctly | 10:32 |
| olofk | yes | 10:33 |
| ZipCPU | Isn't that what you really want? | 10:33 |
| olofk | zump: Do you know if it's the full axi4, or axi4lite? | 10:33 |
| zump | probably light | 10:33 |
| olofk | Because I think there are several open source BFMs for Axi4lite | 10:33 |
| zump | but the BFM is still RTL... | 10:34 |
| olofk | Yes, but it will contain methods that you can call from sw | 10:35 |
| olofk | Instead of implementing the protocol in sw, which is probably more awkward | 10:35 |
| zump | so a BFM is basically an implementation of a bus protocol so i dont have to write it myself? | 10:36 |
| olofk | Yes, that's a quite accurate description | 10:38 |
| olofk | With API calls | 10:38 |
| olofk | I think your problem is quite interesting. I have been having similar thoughts for some time | 10:38 |
| olofk | Like using a high-level CPU/SoC simulator and only exchange a single peripheral core for an RTL model | 10:39 |
| olofk | _franck__ did some cool experiments in that domain for OpenRISC some time ago | 10:39 |
| ZipCPU | (olofk: I got lost at the task keyword in your BFM ... I've never used 'task's before.) | 10:40 |
| zump | I need to find a simple AXI slave RTL and do proof of concepts with it using verilator | 10:41 |
| olofk | ZipCPU: Tasks are allowed to consume time, while functions aren't (very similar to vhdl procedure/functions) | 10:41 |
| olofk | ZipCPU: task can also have as many inputs and outputs as you like, but doesn't have a return value | 10:41 |
| shorne | olofk: I kind of figured out another one of the gdb issues I was having. next onto varargs | 10:41 |
| ZipCPU | Yes, but ... how do they turn into synthesizable HDL, or can they only be used with the simulator? | 10:42 |
| olofk | zump: There's one thing to be aware of then. Verilator assumes that the code is synthesisable. My wb_bfm isn't | 10:42 |
| olofk | haha. That also answers ZipCPU's question :) | 10:42 |
| olofk | shorne: Cool. Sorry for leaving you alone for a while in the gdb jungle. | 10:43 |
| ZipCPU | Okay ... so a Verilog task would roughly be the equivalent of my C++ wb_write and/or wb_read calls. Neither is truly synthesizable. | 10:43 |
| shorne | its ok, I ended up having to debug gdb in gdb, and finally figure it out | 10:43 |
| olofk | shorne: I think for varargs, we should start pushing to stack when argnum >= TYPE_NFIELDS(func_type)) | 10:44 |
| zump | olofk: how come | 10:44 |
| olofk | ZipCPU: No. I use my BFM with event-based sims (Icarus, Modelsim etc) | 10:44 |
| shorne | olofk: yeah, I was planning to look back in the irc log to get those function names you figured out | 10:44 |
| ZipCPU | olofk: But if zump wants to use Verilator to create his core, and if verilator only works with synthesizable verilog, how would a non-synthesizable bfm help him? | 10:45 |
| olofk | shorne: And func_type is defined like this "struct type *func_type = value_type (function);" | 10:45 |
| olofk | ZipCPU: It won't, so I pointed out that | 10:46 |
| olofk | unless it's synthesisable of course | 10:46 |
| ZipCPU | <Reaches for the tissue again> | 10:47 |
| olofk | A third option (still going with verilator) would be to write a systemC wishbone model | 10:47 |
| olofk | systemC was created to model RTL stuff in C(++) | 10:47 |
| zump | I found an AXI4 BFM | 10:47 |
| zump | http://opencores.org/project,axi4_tlm_bfm | 10:48 |
| _franck__ | olofk: zump : it's kind of what I did here: https://github.com/fjullien/orpsoc-cores/tree/systemc_rework/cores/verilator_or1ksim_wb_master | 10:48 |
| olofk | zump: Reading a bit more carefully, it only implements AXi4stream Master | 10:48 |
| olofk | which is not what you're looking for | 10:48 |
| zump | noo00ooo | 10:49 |
| zump | https://github.com/sjaeckel/axi-bfm/tree/master/src | 10:49 |
| shorne | olofk: yup for 'if (TYPE_VARARGS (func_type))' | 10:49 |
| zump | does verilator support VHDL? | 10:50 |
| olofk | zump: Nope. Only Verilog and a subset of SystemVerilog | 10:50 |
| zump | Damn. some blocks are in VHDL | 10:51 |
| zump | do converters exist | 10:51 |
| olofk | zump: Is it pulpino you're working on? :) | 10:51 |
| ZipCPU | It still uses tasks as well--which you can't use in Verilog either. | 10:51 |
| zump | no.. i am working on something in bitcoin | 10:52 |
| olofk | ah ok. Just had to ask, because pulpino is completely verilog except for a VHDL UART :) | 10:52 |
| zump | ah ok... | 10:52 |
| olofk | zump: Related to KNC Miner? | 10:52 |
| zump | hah.. no. just a bunch of geeky guys | 10:52 |
| zump | somewhere else | 10:52 |
| zump | is it possible to convert from VHDL to verilog? | 10:53 |
| olofk | Not really | 10:53 |
| zump | dam.. | 10:53 |
| olofk | There is unfortunately very limited support for VHDL in the open source tools, and even more so for mixed-language simulations | 10:53 |
| ZipCPU | Sure it is. I'll be glad to bill you my services. How much do you need converted? ;P | 10:53 |
| olofk | Your best hope would be Icarus Verilog, which is gaining more VHDL features all the time | 10:54 |
| shorne | olofk: got varargs pushed to stack now too. just one failure in gnu_vector | 10:54 |
| olofk | But... if it's just a small UART, I'm not convinced you need the speed of verilator. You could use icarus or modelsim instead | 10:54 |
| olofk | shorne: Awesome!!! So close now | 10:54 |
| shorne | hmm, assertion failure... | 10:55 |
| olofk | zump: One way to do this that I have been thinking about is to build a testbench for your UART with a BFM, hook it up to a socket, and then send the register accesses over the socket from your software | 10:56 |
| olofk | I have been doing similar things before, and this is how we do JTAG currently | 10:56 |
| ZipCPU | zump: olofk: I've also got something similar running for my XuLA2-LX25SoC. The Verilator runs in a separate process, and the control software can access registers, get interrupts, etc. over a socket. | 10:57 |
| ZipCPU | That way I can use the same PC source code to interact with the Verilator code as I use to interact with the real XuLA2 board. | 10:58 |
| olofk | ZipCPU: Which interface do you use with the real board? | 11:00 |
| ZipCPU | The XuLA2 board connection is via the JTAG User function. I made it work like a UART that could send and receive characters, and then compressed a wishbone bus interface to work over that. | 11:01 |
| ZipCPU | Since it was a basic character interface, it could also run over a TCP socket as well. | 11:01 |
| olofk | ZipCPU: Aha.. a homebrewn solution | 11:01 |
| ZipCPU | It's actually a 3rd generation home-brew solution, and I've got a 4th generation one that's not quite complete yet. | 11:02 |
| olofk | ZipCPU: Have you seen the jtag_vpi backend in OpenOCD that _franck__ wrote? | 11:02 |
| ZipCPU | No. Care to tell? | 11:03 |
| shorne | olofk: all passing, but its a bit hacked | 11:03 |
| olofk | ZipCPU: As we normally use OpenOCD as a JTAG proxy to talk with our boards, _franck__ wrote a driver that sends the commands to a socket, so that we can instantiate a small testbench component in our sims and use the full JTAG stack in simulations | 11:04 |
| olofk | So for regular HW it's client->openOCD->JTAG adapter->(FPGA JTAG Core)->(Debug interface)->(CPU/Memory) | 11:05 |
| olofk | For simulations it's client->OpenOCD->Socket->(Testbench JTAG BFM)->(Debug interface)->(CPU/Memory) | 11:06 |
| ZipCPU | <Browsing jtag_vpi code now ...> | 11:06 |
| olofk | shorne: All right! Good job. | 11:07 |
| olofk | shorne: Have you booked the ticket to Bologna btw? | 11:07 |
| olofk | gtg | 11:07 |
| shorne | olofk: I dont think I can make it this year. It would be good, but have other travel plans this summary | 11:08 |
| ZipCPU | olofk: So in my case, I run ZipDBG->DevBus->WB/stream Converter->TCP/IP->Verilator->stream/WB converter->WB bus->(CPU debug port/peripherals/memory, etc.) for simulations | 11:10 |
| ZipCPU | and ZipDBG->DevBus->WB/stream Converter->Jtag/Cmds->LibUsb->uController->FPGA JTAG->stream/WB converter->WB bus->(CPU debug port/peripherals/memory, etc.) for the real hardware. | 11:11 |
| ZipCPU | Any program that wishes to access the hardware needs only to understand the DevBus interface, and then it looks/acts/feels like the hardware wishbone bus interface from there. | 11:12 |
| zump | thats a large stack | 11:16 |
| ZipCPU | zump: Well, it's really defined by the devbus interface. Take a look at that here: https://opencores.org/project,xulalx25soc in the trunk/sw/devbus.h file. | 11:19 |
| ZipCPU | I like to think that defines just about any bus interface you might ever need from a software standpoint. | 11:19 |
| ZipCPU | I built it to describe what I hoped would be a PCIe interface, but the backend has yet to be ported to PCIe. | 11:20 |
| shorne | olofk: latest gdb patch in case anyone interested https://gist.github.com/stffrdhrn/964bea59775a4be25fed3d73618adfdd#file-or1k-tdep-v2-diff-L4 | 11:25 |
| olofk | shorne: Thanks. I'll give it a spin later on | 12:33 |
| stolar | Where I can find a code/file responsible for multiplication system (I don't know if I translated it correctly - układ mnożący in polish, maybe in english properly it calls multiplier) in simulator or1ksim? I think it is related with Arithmetic Logic Unit in OpenRISC. Am i right? I need to know how to switch off this multiplier? | 14:58 |
| olofk | shorne: Getting 1 known failure with your patch on gnu_vector. Is that expected? | 17:10 |
| shorne | olofk: yes, I didnt look into the knowns | 17:39 |
| shorne | also I just found one issue when running full tests | 17:39 |
| shorne | basically with NARGS (varargs) its sometimes used for non varargs functions, so I have to check TYPE_VARARGS(ftype) too | 17:40 |
| shorne | I fixed it already, the main thing I am concerned about it my hack here: https://gist.github.com/stffrdhrn/964bea59775a4be25fed3d73618adfdd#file-or1k-tdep-v2-diff-L58 | 17:41 |
| shorne | usually if you call a function like 'print myfunc(big_i)' 'big_i' will be a variable on the target. | 17:43 |
| shorne | for for big things we pass the arguments by reference (pointers in regs) | 17:44 |
| shorne | if big_i is on the target its fine, it will have a pointer | 17:44 |
| shorne | but if we call with 'print myfunc((big_i_type){1,2,3,4,45,56})' then the type is fabricated. | 17:45 |
| shorne | and we need to 1. trasfer the struct to the target, 2. put a pointer in the register | 17:45 |
| shorne | So... we need to put it low in the stack. how? | 17:46 |
| shorne | I found some related failures in gdb.base/callfuncs.exp test fixed them (related to handling return as structure) | 18:06 |
| shorne | but then that broke another testing in gnu_vector (need to get all the edge cases correct) | 18:07 |
| shorne | ~total failures was 440, just fixed a few more and rerunning | 18:34 |
| shorne | now down to 404 | 18:41 |
| shorne | olofk: latest patch, 2 points I am not happy with (see fixme's in patch) https://gist.github.com/e7c1eab1394ab33b42ff25ff155f502c | 18:57 |
| shorne | but it works | 18:57 |
| shorne | RFC | 18:57 |
| shorne | https://gist.github.com/stffrdhrn/fc9999bf0b568895443cee939e873155#file-gdb-short-sum-L3100 | 19:10 |
| shorne | gdb test summary | 19:10 |
| --- Log closed Sat May 21 00:00:16 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!