<FFY00>
that repo build nightly packages every day
<FFY00>
what I am proposing is to notify the channel if for some reason any of them happens to fail
<FFY00>
if one fails, the build is stopped
<FFY00>
so you would get a max of one notification per day
<HackerFoo>
FFY00: Do you just use the latest commit for everything? That's going to break on anything that requires a coordinated update.
<FFY00>
yes
<FFY00>
there is no way around it
<FFY00>
if it happens in the same day then there is no issue
<HackerFoo>
Why? Can't you specify the revision?
<FFY00>
yes, but I won't be updating the revisions manually
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #symbiflow
<HackerFoo>
This might not produce a useful set of packages as often as you'd hope. At least in my experience.
az0re has quit [Ping timeout: 240 seconds]
<FFY00>
well, yes
<FFY00>
the that have releases are in the official repos
<FFY00>
the others are just provided as is
<FFY00>
I don't have time to be frequently updating the packages
<FFY00>
and that would force me to keep track of what is happening in the upstream
epony has quit [Read error: Connection reset by peer]
eponym has joined #symbiflow
craigo has quit [Ping timeout: 246 seconds]
eponym has quit [Quit: reconfigure]
epony has joined #symbiflow
andrewb1999 has quit [Ping timeout: 272 seconds]
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 264 seconds]
citypw has joined #symbiflow
kgugala_ has quit [Quit: -a- Connection Timed Out]
kgugala has joined #symbiflow
enriq has joined #symbiflow
epony has quit [Quit: reconfigure]
epony has joined #symbiflow
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 258 seconds]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
OmniMancer has joined #symbiflow
andrewb1999 has joined #symbiflow
enriq has joined #symbiflow
kgugala_ has quit [Ping timeout: 256 seconds]
kgugala has joined #symbiflow
mangelis has quit [Ping timeout: 256 seconds]
mangelis has joined #symbiflow
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined #symbiflow
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined #symbiflow
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined #symbiflow
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined #symbiflow
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sky36 has joined #symbiflow
craigo has joined #symbiflow
<sky36>
Hey! struggling to get the symbiflow-examples running on my arty7_100t. The tests in symbiflow-arch-defs do have support. I presume there are problems in my environment. Unsure how to move over the built files for the arch-defs into the /opt/symbiflow/xc7/... directory in an appropriate manner to add support.
enriq has joined #symbiflow
<sf-slack>
<acomodi> Hi @sky36. Currently 100T is not yet supported in the symbiflow-examples. However, if you have built the 100T in arch-defs already, you could create a new directory under `/opt/symbiflow/.../share/symbiflow/arch/`. The files you would need to copy there are the following
<sky36>
@acomodi - the typical format from the github instructions produces /share/arch/ rather than /share/symbiflow/arch/
<sky36>
Also, the github tar comes with the xray database
<sky36>
I am attempting to move the files from the tar you provided into the older structure
<sky36>
(I attempted to start fresh, and suffered errors with the 'pack' command
<sf-slack>
<acomodi> Yeah, there have been some changes in the install package which need to be integrated. This is a current work in progress. At the moment, it would be required to just move the files in the old structure as you did
<sf-slack>
<acomodi> what kind of errors are you seeing?
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 272 seconds]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sky36>
Currently yosys is telling me that it cannot load the xdc.so plugin
<sky36>
when I attempt to build the counter example
<sky36>
ERROR: Can't load module `./xdc': /opt/symbiflow/xc7/conda/envs/xc7/bin/../share/plugins/xdc.so: cannot open shared object file: No such file or directory
enriq has joined #symbiflow
<sf-slack>
<acomodi> Ok, there have been an update with the SymbiFlow/yosys version. I am experiencing the same issue with the latest conda package right now. To overcome this, you could set a specific yosys version which work (this needs to be done also for yosys-plugins.
<sf-slack>
<acomodi> GIve me a second to retrieve the correct versions
<sf-slack>
<acomodi> All right, so the conda package version of yosys would be `0.8_3925_g6bccd35a` . I see that the yosys-plugins already have pinned version, so no need to update that
<sf-slack>
<acomodi> The version needs to be added to the environment.yml file under `examples/xc7`
<sky36>
excellent! - it seems to have gone further this time. Now I am suffering problems with vpr
<sky36>
Unsure whether I should use gdb to find the source of the segmentation fault
kgugala_ has quit [Read error: Connection reset by peer]
<sf-slack>
<acomodi> Ah, right... forgot about that. The VPR version used in the current symbiflow-examples is out of date and compatible with the "old" install package. If you wish to use the newer architecture (100T) You would need to update also VTR (this will generate issues with the other devices though)
kgugala has joined #symbiflow
<sf-slack>
<acomodi> `8.0.0.rc2_4003_g8980e4621` this version should work fine
<sky36>
Ah - my next problem is unexpected arguments to the vpr command
<sky36>
cd build && pack -e top.eblif -d xc7a100t_test -s /home/timothy/FPGA/SymbiFlow/symbiflow-examples/examples/xc7/counter_test/counter.sdcVPR FPGA Placement and Routing.Version: 8.1.0-dev+8980e4621Revision: v8.0.0.rc2-4003-g8980e4621Compiled: 2020-07-06T22:51:58Compiler: GNU 7.3.0 on Linux-4.15.0-1028-gcp x86_64Build Info: Release IPO
<sky36>
VTR_ASSERT_LEVEL=2University of Torontoverilogtorouting.orgvtr-users@googlegroups.comThis is free open source code under MIT license.Unexpected command-line argument '--quick_check_route'usage: vpr architecture circuit [--pack] [--place] [--route] [--analysis] [--disp {on, off}] [--save_graphics {on, off}] [--graphics_commands
<TMM>
hi all, I've been looking at the symbiflow-litex-linux example, but I can't actually get Linux to build. I'm trying to generate a new SoC with litex using their linux-on-litex repository but it doesn't really seem to have support for symbiflow, and a naive attempt to get it to use symbiflow (by changing how the board gets initialized) doesn't really work as there's a dependency on vivado hardcoded in one of the build scripts. This is my first
<TMM>
foray into anything symbiflow or FPGA to begin with so I'm kind of unsure where to start unraveling this. I'm getting some help on #litex also which I'm trying to use. I was kind of hoping that someone here maybe documented some of the steps they took?
<sky36>
@acomodi I updated the prjxray folder to the latest version in the github, I get the ame error with the old and new versions
<sf-slack>
<acomodi> Ya, from the tarball linked you would need take the `prjxray_create_place_constraints` script and replace the one in the "old" install tar
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sky36>
Slowly making progress! had to also move over generate_constraints and edit the grid and pinmap paths to point to the right directories
<sky36>
placing worked, now we're routing
<sf-slack>
<acomodi> Great, hopefully the installation step is going to be updated soon, so all these manual steps you have performed will not be required anymore to be able to build for the 100T devices as well
<sky36>
I certainly hope so! - on the very last step right now
<sky36>
bitstream is suiciding
<sky36>
prjxray.fasm_assembler.FasmLookupError: Segment DB LIOB33, key LIOB33.IOB_Y0.LVCMOS12_LVCMOS15_LVCMOS18_LVCMOS25_LVCMOS33_LVTTL_SSTL135.IN_ONLY not found from line 'LIOB33_X0Y93.IOB_Y0.LVCMOS12_LVCMOS15_LVCMOS18_LVCMOS25_LVCMOS33_LVTTL_SSTL135.IN_ONLY'
<sf-slack>
<acomodi> Ok, one last step, you would need to update the database with the most recent one
<sky36>
Yep - I cloned the pjxray from github
enriq has joined #symbiflow
<sf-slack>
<acomodi> Ok, so from the `prjxray/database` dir grab the artix7 directory and replace the one under `symbiflow/xc7/install/share/prjxray/prjxray-db`
<_whitenotifier-b>
[symbiflow-arch-defs] acomodi opened issue #1578: Remove `test` from full-devices that are packed in the install tarball - https://git.io/JJtCp
<sky36>
yep - cd build && write_bitstream -d artix7 -f top.fasm -p xc7a100tcsg324-1 -b top.bitWriting bitstream ...Traceback (most recent call last): File "/opt/symbiflow/xc7/install/bin/python/prjxray/utils/fasm2frames.py", line 306, in <module> main() File "/opt/symbiflow/xc7/install/bin/python/prjxray/utils/fasm2frames.py", line 294, in main
<sky36>
run( File "/opt/symbiflow/xc7/install/bin/python/prjxray/utils/fasm2frames.py", line 199, in run raise fasm_assembler.FasmLookupError('\n'.join(missing_features))prjxray.fasm_assembler.FasmLookupError: Segment DB LIOB33, key LIOB33.IOB_Y0.LVCMOS12_LVCMOS15_LVCMOS18_LVCMOS25_LVCMOS33_LVTTL_SSTL135.IN_ONLY not found from line
<sky36>
pjxray-db is correctly updated, with the old version it doesnt see "xc7a100tcsg324" at all
<sf-slack>
<acomodi> Hmmm, probably then is the other way around, Try to get the older version of the db (the one found in the original install tarball) and grab the xc7a100tcsg324 from the new one
<sf-slack>
<acomodi> Aha, got it, it is actually a fasm2frames issue. I was wrong. The updated version of the db was all right
<sf-slack>
<acomodi> You would need to replace the fasm2frames script from the prjxray updated repo (prjxray/utils/fasm2frames.py) to the /bin/python/ dir
<sky36>
hmm interesting...
<sky36>
cool! got the bitstream file
<sf-slack>
<acomodi> Nice!
<sky36>
Does symbiflow have a tool to flash it - or
<sky36>
really appreciate it - it would've taken me days to figure this out on my own
<sky36>
can finally have a better, more streamlined workflow without using the nasty vivado cringe suite
<sky36>
Do you have any idea of timescale of when the 100t will be added to the examples?
<sf-slack>
<acomodi> @sky36 No problem ;) Regarding the timescale, there are a couple of things to get fixed. Probably it is in the order of days, worst case a few weeks.
enriq has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
<sky36>
Amazing, i'm very optimistic. Thanks to everyone for a lot of the hard work that's gone into this - I didn't believe an open source toolchain existed when I first heard about it!
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined #symbiflow
<litghost>
TMM: Which instructions were you following?
<TMM>
litghost: it doesn't actually use litex but has a prebuild verilog output generated by litex
<litghost>
TMM: There are some outstanding issues around consuming the output of LiteX directly that we are working on. Some have open PR's, and some are in active development
<litghost>
TMM: I can see if I can find the notes about the outstanding changes between the LiteX output and something that works
<TMM>
litghost: ok, that would be great because the example isn't entirely complete either. The json file to describe the images is missing, and lxterm only runs at 115200 at most. So there's some issues with the example even. Or I did something incredibly dumb. I have to admit that this is the first thing I've ever done with an FPGA at all. I'm trying to work out how all of this fits together, it's a little daunting at first.
<litghost>
TMM: Absolutely. We are actively trying to burn down issues that prevent the LiteX output from working directly with the toolchain.
<sf-slack>
<acomodi> TMM: FYI, there is the possiblity to load the Linux images also with ethernet. (There is a wiki describing how to setup the net interface https://github.com/timvideos/litex-buildenv/wiki/Networking). One thing to notice is that the UDP port would need to be set to 69 instead of 6069. Using ethernet is much faster than the 115200 baud rate with lxterm
<tpb>
Title: Networking · timvideos/litex-buildenv Wiki · GitHub (at github.com)
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined #symbiflow
<TMM>
sf-slack: right, to see it working that would be nice! But I kind of need to be able to generate my own socs :) What I'm planning to do requires me to add some opcodes to the cpu :)
<andrewb1999>
kgugala / acomodi: I've been talking to mitho about instability in the prjxray-db sdf generation and was wondering if you could take a look at fixing this. I needed to make changes to prjxray-db to get some of my work merged, but now the new database generated runs into sdf issues in arch-defs CI. Not being able to get a new database merged into arch-defs is holding back merging a lot of my other work.
<sf-slack>
<kgugala> andrewb1999: can you link a PR with unstable sdf?
<tpb>
Title: A New Simulated Annealing Schedule by HackerFoo · Pull Request #1205 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<litghost>
HackerFoo: I don't think I disagree at a high level. It would be good to get a rational from the VTR devs for why QoR improvements are flagged. Do you remember if we directly resolved that question?
<HackerFoo>
I don't think it has been resolved, but I can see why they would want to know if e.g. CPD went down to something physically impossible.
<HackerFoo>
So it probably makes sense to just adjust the lower limits.
sky36 has quit [Remote host closed the connection]
<TMM>
litghost: is there anything someone who's main claim to fpga fame is some blinking leds can do to help with this?
<litghost>
TMM: Sorry, can rephrase your question? I'm not certain I understood you.
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<TMM>
litghost: you said there were a bunch of things still being worked on. I just wondered if someone with very limited experience can do anything useful there.
<litghost>
TMM: Absolutely. Do you have experience with C++ or python? If not, simply updating the documentation for the symbiflow-example could be useful right now. Give me a minute while I look over our burndown list
enriq has joined #symbiflow
az0re has joined #symbiflow
<TMM>
litghost: yeah, I write C++ for the Godot game engine, it's my job now. :)
<HackerFoo>
TMM: Nice
<TMM>
HackerFoo: thanks! :D
<litghost>
TMM: So something we want to do is propagate clocking constraints through yosys transformations. In particular, yosys adds IBUF and BUFG's as part of it's passes. So an inpad named "clk" is still "clk" before the IBUF, but after the IBUF is named something like "\$iopadmap.clk", etc. I believe LiteX relies on simply constraining the inpad "clk" in it's xdc
<litghost>
TMM: We want something to propigate input clock constraints from the xdc to follow yosys transformations where the relevant net is split, so that when it comes time to run the design into VPR, the constraints are supplied on the new nets
<litghost>
TMM: We've handled this to date by modifying LiteX's clock constraints to match any transformed net names
<litghost>
TMM: There is also a need to have something propigate clock constraints from the input of the PLL/MMCM to the output of the PLL/MMCM
<TMM>
OK, this is a little over my head but it feels maybe not too far over my head. Parsers and compilers are a hobby of mine so I think once I understand the problem a bit better I can probably fix it. I'll try to understand what some of the terms mean and go through the yosys code. Also: TCL gross ;)
<litghost>
TMM: TCL is super gross, but it is what we got :(
<TMM>
Is there a minimal problem verilog file that should synthesize but doesn't due to this?
<litghost>
TMM: Any design that leaves off the IBUF and BUFG when synthesized with yosys will have the new nets
<TMM>
Right, but so far all I've done is blink some LEDs :) I'll first learn enough verilog to encounter the problem then
<litghost>
TMM: So blinking some LEDs will manifest this issue, if you tried to constrain the clock
<litghost>
TMM: However blinky is typically simple enough that clock constraints are not required
<litghost>
TMM: However designs like LiteX have tighter (and weirder) timing constraints than something like blinky
<litghost>
TMM: Post-synthesis, yosys will insert a IBUF between the input "clk" and create a new net after the IBUF
<litghost>
TMM: In designs without the explicit BUFG, there will be a similar insertion between the net from the IBUF and the output for the BUFG
<TMM>
OK, I think I see. So this problem would manifest itself in the yosys json files, right?
<litghost>
TMM: Sort of. To be clear, the issue is communicating the constraints from the input XDC/SDC file down to VPR
<litghost>
TMM: VPR sees 3 clock nets (the pad net, the net that is the output of the IBUF, and the net that is the output of the BUFG)
<litghost>
TMM: By default, none of these nets will be constrained
<litghost>
TMM: If the input SDC is passed directly to VPR, only that first net (the pad to the IBUF input) will be constrained
<litghost>
TMM: However the "right" behavior is to have a clock tree that originates at the IBUF, propigates through the IBUF, through the BUFG, etc
<litghost>
TMM: MMCM/PLL propigation is also highly valuable, as ideally for static MMCM/PLL configuration, the tooling would be able to generate the correct constraints on both the input to the PLL, and the output
<TMM>
OK, so, I maybe got this entirely wrong but: Yosys generates a new wire between the bufg and whatever comes after it. Instead this wire shouldn't be there but be connected to the input clock pad?
<litghost>
TMM: Yosys's behavior is correct, we want that BUFG. It is actually very important that it be there.
<TMM>
I'm trying! Thanks for your patience.
<litghost>
TMM: What we need to do is take the initial SDC (constraint the input pad), and have it accurately reflect the final clock tree going into place and route
<TMM>
Is it OK if I type out my current understanding? Because I don't see how these constraints fit in
<litghost>
Sure
<TMM>
OK, so, the sdc file in the case of the counter describes says that the maximum clock propagation delay is 10ns. So this means that no set of gates as a whole can take longer than 10ns to propagate the clock and do whatever logic they were going to do. Correct?
<TMM>
I'm talking about `create_clock -period 10 bufg`
<TMM>
What yosys does is generate a gate-level description of the circuit described in the verilog file. but it can't know about these physical delays, right?
<TMM>
That would be up to the routing and placement tool, to fit the gates that yosys generated into the actual physical gates of the chip.
<TMM>
And whether or not that 10ns clock propagation can be achieved can't be known until then, right?
<litghost>
TMM: More specifically, yosys is working at a different abstration level than the P&R tool, and cannot do precise clock constraining. Some physical synthesis is done, but I don't believe it is constraint driven today
<litghost>
TMM: Adding more physical synthesis is future work
<TMM>
I'm not arguing :) I'm trying to put to words the way I think this is supposed to work
<litghost>
TMM: But it is correct that the P&R tool has a more complete and precise model of the underlying hardware.
<litghost>
TMM: This is a little tangent to the actually need. The need to is express the clocking constraints on the nets downstream of the buffering clock objects (e.g. the IBUF and the BUFG, and/or PLL/MMCM).
<TMM>
Because I'm not entirely sure what yosys can do with the clock contraint information, so I guess I'm not sure what exactly should happen. Is the constraint encoded as a sort of metadata in the RTL? If so is what needs to happen that the clock constraint 'simply' (I'm assuming it's not that simple) needs to be tracked so that the RTL contains the whole chain up from clk to bufg (and the implicint IBUF)? So that the R&P tool can know that all
<TMM>
those components share that 10ns constraint
<litghost>
TMM: The P&R tool uses the input clock constraints to drive the optimization to meet the constraint. If the constraint is absent or missing, then the optimization will focus on the wrong parts
<litghost>
TMM: The goal is to take a clock constraint on the pad (e.g. "input clk") and propigate those constraints to the downstream nets, so that the P&R tool does the right thing
<TMM>
right, and the P&R tool (in the case of counter) needs to know that the clk and bufg wires should be counted together to meet the 10ns constraint? So if bufg takes 1ns, it should be able to know that the implicit ibuf now has 9ns left?
<litghost>
TMM: > So if bufg takes 1ns, it should be able to know that the implicit ibuf now has 9ns left?
<litghost>
TMM: That's not quiet right
<litghost>
TMM: The IBUF or BUFG actually create a relationship between the input and the output
<litghost>
TMM: So it isn't a direct subtraction
<litghost>
TMM: However as a first cut, the relationship can be assumed to be 0 delay, as a first cut
<litghost>
TMM: The reality is more complicated, but that is something that can be added later
<litghost>
TMM: The precise description of the BUFG input to output relationship is that the BUFG adds some delay and some jitter/variance
<litghost>
TMM: However most clocked elements in the design should be downstream of the BUFG, so the delay through the BUFG is immaterial
<litghost>
TMM: Only in the case where a piece of logic is capturing an edge that was launched from the other side of a buffer would the delay through the buffer factor in
<litghost>
TMM: For now, simply propigating the relationship as 0 delay and 0 jitter through the IBUF and BUFG is a good first approximation, with TBD constants to factor in the true pre- post- buffer delays
<TMM>
I guess maybe I'm not 100% clear on what 'propagating through' means exactly. Is that metadata for P&R? Or does it actually change the netlist from yosys?
<litghost>
TMM: The netlist does not change. The constraints should change, and/or be added too
<litghost>
TMM: So a constraint on just the input pad, becomes the input pad, the IBUF output and the BUFG output. In the case of a clock generation element, there is a relationship between the PLL input and output (e.g. phase shift and/or frequency change)
<litghost>
TMM: So as an example, the user says "create_clock -period 10 clk", which is then propigated to a net "clk_bufg". In that case, a new constraint can be added simply as "create_clock -period 10 clk_bufg"
<litghost>
TMM: If there is a delay though the element, then the propigated constraint would something like "create_clock -waveform {1 6} clk_bufg" (for a 1 ns delay through the element)
<TMM>
oh, so the work should generate a new sdc file?
<litghost>
TMM: Yes
<litghost>
TMM: VPR SDC also supports clock uncertainity (e.g. jitter) via "set_clock_uncertainty"
<litghost>
TMM: The SDC input format to VPR supports expressing both delay through clocking elements and jitter through elements, but we don't have something that takes a fully elaborated netlist from yosys and just an input pad constraint, and creating the "full" constraint description for the clock network
<TMM>
ah, ok, that part I really didn't understand. So should this be a tool that runs separately from yosys that takes the json file and does this analysis or should yosys spit out an sdc file as well as the various other files?
<TMM>
And I guess I don't fully understand how something at that level can know how much delay and jitter there is going to be. Isn't that dependent on the actual silicon?
<TMM>
And I presume the clock integrity related to the speed?
<litghost>
TMM: It is dependent on the silicon. The initial tool though can just propigate assuming 0 delay / 0 jitter as a first step
<litghost>
TMM: As for whether this lives outside of yosys or inside as a plugin or yosys script is part of the work
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<litghost>
TMM: We have an XDC plugin that we were thinking could be used to capture the clock constraints from the XDC input, but that is not currently wired to create even a simple XDC -> SDC passthrough
<TMM>
OK, not knowing any of the workings of yosys, on the face of it it seems that just a verilog parser should be able to figure this out, but I guess you'd have to know what names yosys is going to use to generate the sdc file
<zyp>
so to put it simply, yosys is transforming the nets so that the constraints for the input doesn't match the names in the output, so the constraints also needs to be transformed to match?
<litghost>
zyp: It isn't always just a name transformation, somethings it is a duplicate and rename. That is what I've been meaning by "propigate"
<litghost>
zyp: But your gist is pretty close
<TMM>
OK, I guess I have some idea on what needs to happen. I'll take a stab at understanding what yosys does exactly and if there's some output formats or logs I can use to understand what's happening
<litghost>
TMM: After yosys is done with synthesis, the netlist can be described in any number of formats, e.g. json, eblif, edif, verilog
<TMM>
OK, I will do my best! Thanks a lot for your time. I think I have enough to at least come back with more clever questions later :)
<TMM>
And, thanks for working on this. I have been interested in working on fpgas forever but I've never had any interest in using a non-free tool to do it
maartenBE has quit [Ping timeout: 256 seconds]
<litghost>
TMM: Have a fun time, this stuff is pretty cool. I believe trying to figure this out is actually a good entry point
<zyp>
TMM, absolutely agree on that last point :)
<zyp>
I bought my first fpga devboard 13 years ago, and I'm still a FPGA novice, since the tools have been putting me off every time I've tried doing anything
maartenBE has joined #symbiflow
emilazy has quit [Ping timeout: 240 seconds]
emilazy has joined #symbiflow
mithro has quit [Ping timeout: 246 seconds]
brent has quit [Ping timeout: 260 seconds]
guan has quit [Ping timeout: 246 seconds]
y2kbugger has quit [Ping timeout: 244 seconds]
elms has quit [Ping timeout: 240 seconds]
benreynwar has quit [Ping timeout: 260 seconds]
tucanae47 has quit [Ping timeout: 260 seconds]
diamondman has quit [Ping timeout: 246 seconds]
futarisIRCcloud has quit [Ping timeout: 260 seconds]
daveshah has quit [Ping timeout: 244 seconds]
ric96 has quit [Ping timeout: 246 seconds]
ovf has quit [Ping timeout: 260 seconds]
pdp7 has quit [Ping timeout: 265 seconds]
_florent_ has quit [Ping timeout: 260 seconds]
sorear has quit [Ping timeout: 244 seconds]
ktemkin has quit [Ping timeout: 246 seconds]
nickray has quit [Ping timeout: 240 seconds]
perillamint has quit [Ping timeout: 260 seconds]
bubble_buster has quit [Ping timeout: 246 seconds]