Thursday, 2018-07-12

*** tpb has joined #yosys00:00
*** luismarques has joined #yosys00:10
*** emeb_mac has joined #yosys00:36
*** digshadow has quit IRC01:15
*** pie__ has joined #yosys01:38
*** promach_ has quit IRC01:39
*** pie_ has quit IRC01:42
*** luismarques has quit IRC01:43
*** pie___ has joined #yosys02:11
*** pie__ has quit IRC02:14
promachBy the way, ZipCPU, did you faced any issue regarding tcl85 during yosys installation ?02:15
*** m_w has quit IRC02:19
ZipCPUNo.  I had no issues.02:22
ZipCPUOr at least none that I can remember.02:22
promachShould I create a github issue on this because I am not sure if this is really problem with yosys makefile because I only have problem in Ubuntu but not in arch linux ?02:31
ZipCPUI had no problems in Ubuntu 16 or 18.02:32
ZipCPUI'd be hesitant to create a github issue yet.02:32
promachok, let me check this again over the weekend. Probably I made some mistake02:32
ZipCPUOne other thing ... .I have tcl8.6 installed, not tcl8502:33
promachme too02:33
ZipCPUDo you have libtcl8.6 installed?02:34
promachlibtcl8.6 is already installed at the requested version (8.6.8+dfsg-3)02:35
ZipCPUHow about tcl-dev and tcl8.6-dev ?02:35
promachalready installed02:37
promachtcl-dev is already installed at the requested version (8.6.0+9)02:37
promachtcl8.6-dev is already installed at the requested version (8.6.8+dfsg-3)02:37
ZipCPUSo .... what issue are you struggling with?02:38
promach[100%] Building yosys02:38
promach/usr/bin/x86_64-linux-gnu-ld: cannot find -ltcl8.502:38
promachcollect2: error: ld returned 1 exit status02:38
promachMakefile:458: recipe for target 'yosys' failed02:38
ZipCPUIs this an older yosys, with build remains around from a prior build?02:39
ZipCPUAs in, might your yosys have been built at one time when your system had tcl8.5?02:40
promach[email protected]:~/Downloads/yosys$ git log -102:41
promachcommit 8b92ddb9d2635c30636b17ff3d24bc09a44b8551 (HEAD -> master, origin/master, origin/HEAD)02:41
promachAuthor: Clifford Wolf <[email protected]>02:41
promachDate:   Fri Jun 29 19:24:58 2018 +020002:41
promach    Fix verific eventually handling02:41
ZipCPUFor example, if I grep tcl yosys-config, I only get references to tcl8.6, and -ltcl8.6 ... no references to tcl8.5.02:41
promach    Signed-off-by: Clifford Wolf <[email protected]>02:41
promach[email protected]:~/Downloads/yosys$02:41
*** proteus-guy has quit IRC02:43
ZipCPUAnother question: If you run "tclsh", and then type "info tclversion" at the command line, what response does it give?02:44
promachit gave 8.502:45
ZipCPUYour tcl install is 8.5 then, not 8.6.  What's broken?02:46
ZipCPUPerhaps you need to reinstall tcl8.6?02:46
promachjust finish reinstallation of tcl8.602:49
promachbut still having 8.502:49
promachas the output of "info tclversion"02:50
ZipCPUWhat does /usr/bin/tclsh point to?02:50
promach[email protected]:~/Downloads/yosys$ whereis /usr/bin/tclsh02:51
promachtclsh: /usr/bin/tclsh /usr/bin/tclsh8.6 /opt/Xilinx/SDK/2017.2/bin/tclsh /opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/tclsh /opt/intelFPGA/17.1/quartus/bin/tclsh /usr/share/man/man1/tclsh.1.gz02:51
ZipCPUTry instead "ls -l `which tclsh`02:51
promach[email protected]:~/Downloads/yosys$ ls -l `which tclsh`02:52
promach-rwxr-xr-x 1 root root 1290 Jun 16  2017 /opt/Xilinx/SDK/2017.2/bin/tclsh02:52
ZipCPUPerhaps you might wish to adjust your path.02:52
promachthe issue comes from /opt/Xilinx/SDK/2017.2/.settings64-Software_Development_Kit__SDK_.sh02:59
ZipCPUSee ... you didn't need to submit a yosys github issue after all!03:00
*** pie___ has quit IRC03:26
*** _whitelogger has quit IRC04:01
*** _whitelogger has joined #yosys04:03
*** danieljabailey has quit IRC04:07
*** cr1901_modern has quit IRC04:28
*** seldridge has joined #yosys04:36
*** emeb has quit IRC04:37
*** proteus-guy has joined #yosys04:49
*** seldridge has quit IRC05:12
*** cr1901_modern has joined #yosys05:57
*** dys has joined #yosys06:18
*** jaafar has quit IRC06:32
*** Guest16831 has left #yosys06:52
*** emeb_mac has quit IRC07:01
*** dys has quit IRC07:41
*** proteus-guy has quit IRC07:44
*** proteus-guy has joined #yosys07:45
*** digshadow has joined #yosys07:57
*** proteus-guy has quit IRC08:00
*** grummel has quit IRC08:05
*** grummel has joined #yosys08:06
*** X-Scale has quit IRC08:15
*** jwhitmore has joined #yosys08:17
*** cr1901_modern has quit IRC08:27
*** cr1901_modern has joined #yosys08:29
*** jwhitmore has quit IRC08:52
*** cr1901_modern1 has joined #yosys08:57
*** cr1901_modern has quit IRC08:58
*** maartenBE has quit IRC09:47
*** maartenBE has joined #yosys09:50
*** ZipCPU has quit IRC10:36
*** ZipCPU has joined #yosys10:53
*** pie___ has joined #yosys11:17
*** m_t has joined #yosys11:20
*** jwhitmore has joined #yosys11:51
*** X-Scale has joined #yosys11:58
*** jwhitmore has quit IRC12:34
*** jwhitmore has joined #yosys12:50
*** luismarques has joined #yosys12:52
*** ric96 has joined #yosys13:11
ric96I have just started to use the ice stick and only a couple of weeks since i've written my first verilog.13:11
ric96Had a question regarding BRAM.... I am able to get 1 block working win MODE0 (256x16), what is the best way to get all 16 blocks working?13:11
ric96my current code:
tpbTitle: module ram1( input clk, input [7:0] addr, input [15:0] din, input write_en - (at
daveshahric96: if you increase address or data width, Yosys should infer multiple blocks13:14
ric96daveshah: i did, for some reason it limits to only 5 block and goes into READ/WRITE Mode 313:15
tpbTitle: module ram1( input clk, input [7:0] addr, input [15:0] din, input write_en - (at
daveshahric96: is that not working then?13:15
daveshahwhat error/problem are you seeing?13:16
ric96daveshah: no its not, i guess13:17
ric96I am looking for 256x16 configuration on 16block that gives me my 64k of BRAM13:17
ric96this is the yosys output that i am getting instead13:18
daveshahric96: going into mode3 is the correct solution here afaics, as it results in less extra decoding logic13:18
daveshahit functions correctly, right?13:18
tpbTitle: Parameter \WRITE_MODE = 3 Parameter \READ_MODE = 3 Parameter \INIT_0 = 256'000 - (at
daveshahric96: why do you thing mode 3 is a problem?13:19
ric96daveshah: even if i go to mode 3, still limits me to only 5 blocks13:19
ric96instead of full 16 blocks13:20
daveshahric96: first of all mode 3 is correct behaviour, not a problem, if you think about the resultant output it will require less decoding logic than mode 0. limiting to 5 blocks seems to be a separate problem13:20
daveshahwhat happens when you go above 5 blocks. what error do you get? is it in Yosys or arachne-pnr?13:20
ric96i can use mode 3, not an issue. issue is limiting to 5 block, sorry wasn't clear13:21
daveshahric96: yes. what is the problem you see when you exceed 5 blocks. what is producing the error? yosys or arachne-pnr?13:21
ric96daveshah: don't know new to this... posted the output above if you can figure out13:23
daveshahric96: are you resizing your address input to the module? it looks like the address input to the module is only 8 bits. This means the top parts of your memory are never accessed, so Yosys will optimise them away13:24
ric96daveshah: yes i am resizing >
tpbTitle: module ram1( input clk, input [7:0] addr, input [15:0] din, input write_en - (at
daveshahric96: no you are not, have a look at line 413:26
daveshahthis means that the address to the memory, however wide the internal address signal is, can only be between 0 and 25613:26
daveshah*0 and 25513:26
daveshahso yosys will optimise away any unused memory above that13:26
ric96daveshah: oh.... ok let me try again after resizing13:27
mattvennyosys optimising things away has caught me out many times too! But if you capture the output of the synthesis, you can grep for remove and see all the stuff not being used13:29
mattvennalso, yosys show gives you a visualisation of what is actually inferred13:30
mattvennvery useful
ric96daveshah: nope... still stuck at 513:39
daveshahric96: can you post your design now?13:40
daveshahalso, make sure you are actually checking the Yosys output netlist or the arachne-pnr resource count13:40
daveshahthe Yosys command line output you posted before was more about elaborating module configurations and may not be repeated for every BRAM in the design, I'm not sure13:41
tpbTitle: module ram1( input clk, input [11:0] addr, input [15:0] din, input write_e - (at
tpbTitle: After packing: IOs 15 / 96 GBs 0 / 8 GB_IOs 0 / 8 LC - (at
daveshahric96: clearly by the number of IO something is using that BRAM module. Where is the BRAM module being used? How much memory is actually being used (I'll guess less than 20kBit...)13:52
ric96daveshah: just writing zero in the initial block13:55
daveshahric96: what top level module contains ram1?13:55
ric96And writing one bit in the top module... Yes it does.13:55
daveshahric96: if you only write one bit, Yosys will optimise away the other bits13:56
ric96daveshah: yikes... Ok I'll write to all blocks and see if that works.. thanks13:58
daveshahric96: Yosys can be pretty smart, at least some of the time :-P13:59
mattvennI still have questions about this14:09
*** emeb has joined #yosys14:09
mattvennmost recently I was working on an FFT project, and I hadn't used the output of the FFT for anything14:09
mattvennso I could simulate it and show it worked14:09
mattvennbut couldn't get an understanding of LUT usage as I changed the number of FFT bins14:10
mattvennbecause I couldn't convince yosys I was using it!14:10
mattvennI'd like to know what rules yosys uses to know if something should be optimised out14:11
*** seldridge has joined #yosys14:13
*** promach_ has joined #yosys14:13
awygleI don't know what the specific rules are, but in general, anything attached to a top-level port will be kept14:35
ric96daveshah: BRAMs        16 / 16 FINALLY!!! Thanks for the help14:40
ric96daveshah: one more thing, better way to zero all ram bits without the for loop, that takes too long to process in yosys14:42
daveshahric96: I think the only other option is to use $readmemh and a file full of zeros14:44
ric96ok, i'll give that a go, anything is better than a for loop that takes forever14:44
*** xa0 has quit IRC14:54
*** xa0 has joined #yosys15:01
*** jaafar has joined #yosys15:16
*** maikmerten has joined #yosys15:30
*** m_t has quit IRC15:33
maikmertenI'm trying to design a board to attach 512Kx8 SRAM to the Lattice HX8K breakout board - it doesn't come with any RAM. Now, sadly none of the 40-pin connectors (one for each I/O-Bank fo thh FPGA) have enough I/O-pins to drive the 30 signals I need (19 address, 8 data, 3 control), so I need to spread over two headers15:34
maikmertenwhich means two I/O-banks being involved15:35
maikmertenI wonder if this introduces some timing skew, e.g., with one bank being offset slightly15:35
maikmertenwhich means I wonder if I should take some care to make sure that, e.g., all address, data and control lines are assigned to one bank only - and not smeared across15:36
daveshahmaikmerten: I doubt it will be significant compared to other sources of skew tbh15:37
daveshahwhat speed are you planning on running at?15:37
maikmertenwell, between 20 and 40 MHz, whatever ends up being stable15:37
maikmerten(it's 10ns SRAM, but I don't trust the signal routing on the breakout, the pin headers, and whatever board design I come up with)15:38
awygleyeah i don't see why the bank used would be significant in this case, except maybe for your own sanity15:38
maikmertenokay, thanks15:39
maikmertenI guess I'll still try to keep the same "class" of signal on one single bank15:39
maikmertenbut perhaps the routing will make me reconsider ;-)15:40
awygleyeah don't put a spoon in your eye over it15:43
maikmertenfor reference: This is a board I designed for one of those very cheap Cyclone-II boards:
tpbTitle: Pasteboard Uploaded Image (at
maikmertenthat worked for 50 MHz15:44
maikmerten(didn't try higher)15:44
awygleyeah i've run 100 MHz over 100-mil headers before15:45
awyglei would have put some series termination on the board though. unless the i/o are slew rate adjustable15:46
maikmertenthey are not ;-)15:48
maikmertennot sure if there's a "one size fits not all, but most" approach to series-termination though. I guess for a proper value one would have to make some educated guesses on the impedance and whatnot15:49
maikmerten"In most designs, a value of R = 25 Ω to 30 Ω is recommended"15:51
awyglefor 50 Ohm lines (which is what i almost always use for impedance control) 22 or 27 ohms is a decent guess for most drivers15:51
awyglelol oh hey look at that15:52
awygleyeah that matches my intuition/experience15:53
awyglei wish IC manufacturers spec'd output impedance15:54
maikmertensurprisingly, apparently, in many cases intuition seems to work just fine as long as frequencies remain "low"15:54
awygleintuition works OK at higher frequencies too, it's just different intuition :p15:55
awyglethe most valuable intuition to have is knowing when you need to run the simulation tbh15:55
*** mjoldfield has quit IRC15:57
*** mjoldfield has joined #yosys15:57
maikmertenI'm a computer scientist, not an electronic engineer, and when it comes to PCB stuff, I usually end up being lucky, I guess. I may be doing some ill-conceived hocus-pocus in some cases though. For instance, keeping as much GND-fill on the board as possible (no islands allowed), which might be counter-productive in some cases, I guess.15:57
mattvenn 19 address for 512kx8?15:59
maikmerten(and yeah, simulation rocks. As long as one has enough data - or intuition - to get the parameters right)16:00
maikmertenmattvenn, yup16:00
mattvennoh yeah16:00
maikmerten2^19 = 52428816:00
mattvennsounds like loads of pins for only 512k!16:00
ric96daveshah: anyway to force yosys to use different read/write mode... Its seems to be only happy with mode 316:01
maikmertenno col/row multiplexing there ;)16:01
daveshahric96: it's picking mode 3 for a good reason16:01
ric96Defaults to that mode no matter what16:01
daveshahif you want to use another mode, instantiate the primitive yourself. But I don't know why you need mode 0, this sounds like an XY problem tbh16:01
mattvennI've just been testing Kevin Hubbard's hyperram breakout16:01
awyglemaikmerten: ground fills are fine as long as they're well stitched and you pull them back from anything you're analyzing with microstrip formulae16:03
maikmerten(as for other hocus-pocus (i.e. stuff I do that is not backed up by proper data): Avoiding routing signals through vias if possible, although this doesn't appear to be a problem per-se - BGA escape-routing usually relies heavily on vias)16:03
maikmertenah, thanks :)16:05
awyglevias add inductance but aren't a big problem in themselves. and sometimes they're unavoidable, and sometimes going too far out of the way to avoid them adds *more* inductance. what you really want to look at is reference planes, but that's a more complicated topic.16:06
* awygle is making a list of future blogs...16:07
*** proteus-guy has joined #yosys16:19
*** dys has joined #yosys16:48
*** tinyfpga has quit IRC16:52
*** tinyfpga has joined #yosys16:54
*** pie___ has quit IRC16:58
*** emeb has quit IRC17:04
*** mjoldfield has quit IRC17:10
*** mjoldfie_ has joined #yosys17:10
*** emeb has joined #yosys17:18
maikmertenone of the weird features of the HX8K breakout board: On the four headers, the VCCIO{0-3} for the respective I/O-bank is accessible, but only on one the VCC33 line is available. The VCCIO-lines are derived from VCC33 via a filter-arrangement (an inductance, an 1-Ohm resistor, some capacitors) and it feels "wrong" to derive power for the SRAM from there... that one can source up to 180 mA when in full swing17:19
daveshahpersonally I'd replace at least the 1-ohm resistor with a 0-ohm resistor, if you are comfortable replacing an SMD resistor17:20
daveshahi'm not convinced the 1-ohm resistor will be doing much anyway17:20
maikmertenyeah, but OTOH I guess someone put some thought into that...17:22
maikmertenalso, given that I need to spread over two headers, I can just take VCC33 from the one that I'll occupy anyways17:22
maikmertenit's just funny that on all headers, in the schematics, there is a very clear note: "MAKE PWR TRACES CAPABLE OF 1A"17:23
daveshahtbh Lattice, thought and development boards don't always go together17:23
daveshahthere've been critical errors with PLL supplies before now17:23
maikmerteneven on those that don't expose VCC3317:23
maikmerten(and the linear regulator for VCC33 can deliver like 650 mA max)17:24
maikmerten(okay, continuous current - and that note may be for spikes or whatever)17:24
maikmertenyeah, I've heard of one particularly inexpensive board that just forgot decoupling on the PLL supply completely17:25
maikmertendespite there being a hardware design checklist that isn't even hard to read17:25
maikmerten(and not being very long)17:25
daveshahand then people copy them because they think they are a golden reference (which they should be) ...17:26
maikmertenyay, VPP2V5 is derived from the 3.3 Volts supply... relying on a diode to drop 0.7 Volts17:27
maikmerten(I think that 2.5 Volts is only used for the NVCM stuff, which I'll sure never use)17:28
maikmertenI would think the voltage drop of the diode would be current-dependant, though, and the current here should be very low...17:29
daveshahif you look in detail, many of their boards use a schottky diode that drops nowhere near 0.7v...17:29
maikmertenI'll just take this as a hint that their chips are somewhat robust ;-)17:30
maikmertenooooh, I think that "filter arrangement" (inductor, resistor, capacitors) for the VCCIO-lines might be a valiant effort to ensure a proper power-on sequence17:33
daveshahmaybe, sounds a bit dodgy17:35
maikmertenbecause, /me being naive, I wouldn't expect there to be much noise to filter out from a linear voltage regulator17:35
daveshahI've never seen an iCE40 fail due to bad power up sequencing TBH17:35
daveshahI suspect it could be to stop noise getting in from external devices17:36
maikmertenyeah, hmmm...17:37
awyglethe 1 ohm resistor is probably for power measurements.17:56
awygleand the filtering could be an attempt to keep the VCCIOs from cross-contaminating17:57
daveshahyes, power measurement makes sense17:57
awygleit does sound a bit weird though tbh17:58
awygleany standard 1R resistor should handle 180 mA from a power dissipation perspective though. and dropping 0.18 V should be fine.17:59
*** jwhitmore has quit IRC18:16
*** jwhitmore has joined #yosys18:17
*** pie___ has joined #yosys18:18
mjoldfie_It would be easy enough to solder a bit of wire across the resistor or pads even if you don't like SMD soldering.18:21
*** promach_ has quit IRC18:34
*** pie___ has quit IRC18:45
*** m_w has joined #yosys19:34
*** cr1901_modern1 has quit IRC19:58
*** cr1901_modern has joined #yosys19:58
*** jwhitmore has quit IRC20:11
*** maikmerten has quit IRC20:22
mithroSo, when I run "proc" in yosys I'm getting the following20:45
mithroWarning: Replacing memory \storage with list of registers. See ../../../../vpr/mem/vpr_sp_ram.sim.v:1820:46
mithroAnd yosys becomes very slow....20:46
daveshahmithro: most likely you're doing something that Yosys does not support generating a memory for20:48
daveshahThis means is explodes to lots of registers20:48
mithroI'm obviously doing something really stupid :-P20:48
mithroAnd it's probably because I've divided the hierarchy to much20:49
daveshahmithro: yeah,  memory recognition is probably done before flattening20:51
mithrodaveshah: -- trying to emulate this ->
tpbTitle: symbiflow-arch-defs/single_port_ram_mixed.sim.v at xml-no-parent · mithro/symbiflow-arch-defs · GitHub (at
daveshahmithro: yeah, I don't think Yosys would support an async write port if that's what's going on20:55
mithrodaveshah: Yeah - I think it's because -- that is "just" the combinational part of the mem20:56
tpbTitle: symbiflow-arch-defs/vpr_sp_ram.sim.v at xml-no-parent · mithro/symbiflow-arch-defs · GitHub (at
daveshahmithro: yeah, that's nowhere near what Yosys would be expecting or able to deal with20:57
daveshahAlso, a nice synthesis/simulation mismatch in that always block20:57
mithrodaveshah: Yeah, I feel like if I did more verilog I would know WTF I'm doing here :-)20:58
mithrodaveshah: But I don't do it that much20:58
mithroI have the gut feeling that it is a very strange way to do a memory cell :-P20:59
daveshahmithro: I've never seen a async write memory cell in HDL before21:00
daveshahIt's not something you'd ever see in an ASIC or FPGA21:00
shapris there a collection of things you can do in FPGA that you can't do in an asic?21:01
daveshahUnclocked read ports are extant though21:01
daveshahshapr: yeah, initialised RAM and DFFs mostly21:01
daveshahPartial reconfiguration too21:01
daveshahAlthough you can do that in an ASIC with a eFPGA21:01
shaprneat, thanks21:03
daveshahshapr: as far as I know, initial statements are ignored in ASIC synthesis21:04
daveshahEverything must be reset if you want it to be at a known value21:04
mithrodaveshah: So you recon that the issue is the WE code...?21:06
daveshahmithro: I think if you add a clock to the write port it will work21:07
shaprmakes sense, that's the part bunnie described in his risc-v vs meltdown/spectre blog post. I was unaware of that previously.21:12
mithrodaveshah: This would be a more normal way of describing this memory21:18
tpbTitle: Snippet | IRCCloud (at
daveshahmithro: No, that mix of blocking and non blocking assignments is still horrible21:19
daveshahLet me find a good example21:19
*** jwhitmore has joined #yosys21:20
tpbTitle: Snippet | IRCCloud (at
daveshahmithro: couldn't find a good example of this to hand but this above should be vaguely correct21:28
daveshahFor a single port ram with clocked write and unclocked read, if that's what you want21:28
awygleit looks like in order to match the picture he sent that addr and wen and wedata all need to be registered21:29
daveshahUpdated example accordingly21:30
daveshahI don't feel like the what the picture describes is really correct, it would be a race condition between wen and wdata/addr unless you were very careful21:32
daveshahI've never seen registered wen into an async memory as opposed to just a clocked write port with a wen input21:32
awygleout would definitely be very glitchy21:32
awyglei have no idea why you'd implement something that looked like that21:32
daveshahIt seems to be a contrived example for VPR rather than anything you would practically want21:34
daveshahThey claim that the output port is combinational. But a combinational output port without any combinational inputs seems very odd21:35
mithroYou make async ram synchronous by adding registers?21:41
daveshahYes, although the reality is a bit more complicated than just adding a register in front21:42
mithroSo if the "cloud" is a combinational block21:43
daveshahNot least because of the we/data race we just discussed21:43
daveshahmithro: I think the example structure is simply from a timing point of view, rather than a real world implementation21:44
daveshahOr a sensible HDL implementation21:44
mithroYes, that is correct - it is talking from a timing point of view21:45
mithroIf you replace cloud with just some random combinational logic rather than memory (like a DSP hard logic) does it make more sense?21:48
daveshahmithro: yes, a DSP is a much better example21:49
daveshahThe memory write port is by nature not purely combinational, which was the problem21:50
*** jwhitmore has quit IRC21:50
daveshahIn a typical DSP structure you would have configurable registers at the input and output, plus configurable pipeline registers in the middle21:50
daveshahIf only the input registers were enabled it would match that structure21:51
mithroHow does a write port actually work? Is it more like a tristate? When WEN is low it doesn't drive anything into the cells?21:52
daveshahmithro: No, it would be closer to the enable input of a latch I suppose21:53
daveshahOf course it would be decoded so only a single location was selected21:53
mithroReally, I think what that diagram is trying to show is delay T after the clock edge the output is stable?21:53
daveshahmithro: yes21:54
daveshahNormally I've seen that implemented just using a high clock to Q time rather than the combined sequential and combinational approach21:55
mithroSo the clock signal for the storage latches must be, wen & clk ? IE wen is working like a clock enable for a write clock?21:56
daveshahmithro: yeah, in a clocked write port it would look a bit like that21:56
*** emeb has quit IRC22:30
*** dys has quit IRC22:34
*** emeb has joined #yosys22:44
*** promach_ has joined #yosys22:59
mithrodaveshah: I guess you should probably be asleep - but the dsp_XXX tests at feel a bit better...23:04
tpbTitle: symbiflow-arch-defs/utils/vlog/tests at 5ee753c532f567797984440ad92c1f9395fd0cb5 · mithro/symbiflow-arch-defs · GitHub (at
*** seldridge has quit IRC23:23

Generated by 2.13.1 by Marius Gedminas - find it at!