| *** tpb has joined #yosys | 00:00 | |
| *** sklv has quit IRC | 00:51 | |
| kc8apf | shapr: ? I know of a bunch of FPGA and ASIC HDL engineering jobs | 00:54 |
|---|---|---|
| kc8apf | not aware of any FPGA compiler projects | 00:54 |
| kc8apf | just prjxray | 00:55 |
| shapr | kc8apf: https://careers.google.com/jobs#!t=jo&jid=/x/functional-programming-compiler-engineer-google-building-41-1600-amphitheatre-3710200982 | 00:57 |
| kc8apf | meh. Another team wants to program FPGAs with Haskell | 01:09 |
| shapr | yeah, it's fun stuff | 01:10 |
| shapr | kc8apf: this is the third team I know doing that, reconfigure.io, clash-lang, and now this one. Do you know others? | 01:10 |
| kc8apf | there have been teams trying it at Google since 2005(?) | 01:12 |
| shapr | huh, didn't know that | 01:12 |
| *** xrexeon has quit IRC | 01:12 | |
| shapr | reconfigure has it working, using Haskell to run go-lang on an FPGA | 01:13 |
| *** AlexDaniel has quit IRC | 01:14 | |
| * qu1j0t3 (why wouldn't you just run Haskell on it) | 01:15 | |
| shapr | qu1j0t3: that's been done too, but never hit production quality: https://github.com/tommythorn/Reduceron | 01:16 |
| tpb | Title: GitHub - tommythorn/Reduceron: FPGA Haskell machine with game changing performance. Reduceron is Matthew Naylor, Colin Runciman and Jason Reichs high performance FPGA softcore for running lazy functional programs, including hardware garbage collection. Reduceron has been implemented on various FPGAs with clock frequency ranging from 60 to 150 MHz depending on the FPGA. A high degree of parallelism allows Reduceron to implement graph evaluation very efficiently. This fork aims to continue development on this, with a view to practical applications. Comments, questions, etc are welcome. (at github.com) | 01:16 |
| shapr | yikes | 01:16 |
| qu1j0t3 | holy shit. | 01:16 |
| shapr | did not think the title would be that large | 01:16 |
| qu1j0t3 | i'm glad it was. | 01:16 |
| qu1j0t3 | i am very pleased to know about this. Relevant to my interests | 01:16 |
| qu1j0t3 | i wonder how small an fpga it can fit in. | 01:16 |
| shapr | don't know | 01:17 |
| qu1j0t3 | i'd better study this one day when i get a vacation | 01:17 |
| shapr | but last I heard the prototype required you to build the program in when you compiled it for the FPGA | 01:17 |
| shapr | also, graph reduction CPUs require *much* more memory bandwidth than every day CPUs | 01:17 |
| shapr | but also allow parallel reduction | 01:18 |
| sorear | modern architectures are close to the point where you are generically starved for memory bandwidth rather than available ALUs | 01:19 |
| shapr | yup | 01:19 |
| shapr | sorear: yeah, thanks for making that explicit | 01:19 |
| shapr | I realize I should have said that | 01:19 |
| shapr | sorear: do you see a solution for that in the near future? | 01:19 |
| pie_ | i havent heard of reconfigure.io | 01:19 |
| pie_ | shapr, i wouldnt know but the only thing i can imagine helpin offhand is spatially local memory | 01:21 |
| pie_ | problem there probably is...its spatially local | 01:21 |
| pie_ | (..oh wait fpga already do this?) | 01:21 |
| shapr | NUMA systems? | 01:21 |
| pie_ | (but its not a lot of memory) | 01:21 |
| shapr | yeah, I just don't know. | 01:21 |
| pie_ | disclaimer i have no fucking clue what im talking about | 01:22 |
| shapr | heh | 01:22 |
| sorear | spatially local memory is the only thing you can do, and what we've been doing for years (caches move data closer to the cores that use them) | 01:23 |
| sorear | designs with scrachpads and explicit message passing can use less bandwidth but are much harder to program | 01:23 |
| shapr | more lanes from memory to CPU? reduce latency via alien magic? what's the fix? | 01:23 |
| sorear | adding more hardware means that your program executes using the same amount of memory in half the time | 01:24 |
| sorear | s/memory/energy/ | 01:24 |
| pie_ | oh reconfigure.io is go, meh | 01:24 |
| shapr | pie_: but they are making money using a Go -> Haskell -> FPGA setup, so that's cool | 01:25 |
| pie_ | true true | 01:25 |
| sorear | silicon photonics will make communicating with memory cheaper and is worth followin | 01:25 |
| pie_ | ive gone from maybe ill get around to playing with clash in the next few months to next few weeks (???) | 01:25 |
| sorear | (IMO silicon photonics is most interesting in the high end, since once your data is on fiber instead of copper you can send it a km instead of 20cm with no increase in energy per bit) | 01:26 |
| pie_ | hm | 01:26 |
| pie_ | oh god | 01:26 |
| pie_ | fucking christ | 01:26 |
| pie_ | i can just imagine pipelining involving "data on wire lag" | 01:27 |
| shapr | sorear: I hope we find a solution soon | 01:27 |
| pie_ | so uhh propagation speed | 01:27 |
| pie_ | lol | 01:27 |
| pie_ | do we already use that? | 01:27 |
| sorear | yes | 01:27 |
| sorear | a bit in 10G ethernet is 2cm long | 01:27 |
| pie_ | actually not really related, qu1j0t3 there was that 74xx computer (iirc?) thread where the dude was doing crazy shit like that? (hmm doesnt sound quitre right) | 01:28 |
| pie_ | (might have just been stabilizatoin related stuff) | 01:28 |
| pie_ | sorear, true, im not sure what i was going fore | 01:28 |
| pie_ | *fore | 01:28 |
| pie_ | ... | 01:28 |
| pie_ | *for | 01:28 |
| sorear | wires *inside* chips are kinda bad transmission lines, they have too much resistance and too little inductance | 01:28 |
| pie_ | i guess i was thinking more in-cpu | 01:28 |
| pie_ | i see | 01:28 |
| pie_ | also, clocks | 01:29 |
| sorear | so you can't really have multiple bits in flight at once, but longer wires do take longer to switch | 01:29 |
| pie_ | i see | 01:29 |
| sorear | unless you have buffers ;) | 01:29 |
| qu1j0t3 | pie_: The 6502 on a breadboard thing? | 01:30 |
| qu1j0t3 | pie_: i thikn i still have that open in a browser window somewhere... | 01:30 |
| pie_ | ah yeah that was it | 01:30 |
| qu1j0t3 | he made a big deal out of his graphics engine | 01:31 |
| * sorear needs to dig into the reduceron at some point and understand what its secret sauce is | 01:31 | |
| qu1j0t3 | i guess i'd be pretty excited if my breadboard were that big, and if i got off my ass, it should be | 01:31 |
| pie_ | WARNING: DO NOT READ UNLESS YOU WANT TO WASTE A FEW HOURS this link was purple so this must be it http://forum.6502.org/viewtopic.php?f=4&t=3329 | 01:32 |
| tpb | Title: 6502.org View topic - Vulcan-74 - A 6502 Powered Retro MegaProject (at forum.6502.org) | 01:32 |
| qu1j0t3 | sorear: update us with what you find out. it looks pretty interesting to me. | 01:32 |
| pie_ | i googled crazy 6502 breadboard lol | 01:32 |
| qu1j0t3 | pie_: :D | 01:32 |
| pie_ | qu1j0t3, kind of makes me thing of those big mixing tables and walls of modular synths or whatever | 01:32 |
| pie_ | just get a table where the whole table surface is breadboard | 01:33 |
| pie_ | man that sounds like it would be pretty cool | 01:33 |
| qu1j0t3 | LOL | 01:33 |
| pie_ | albeit immobile :P | 01:33 |
| qu1j0t3 | hahaha why not a whole room | 01:33 |
| pie_ | that makes no sense? :P | 01:33 |
| qu1j0t3 | pie_: you're giving me ideas for my Future Lab | 01:33 |
| qu1j0t3 | yeah it does | 01:33 |
| pie_ | err, sorry for the hijack anyway | 01:33 |
| qu1j0t3 | its like a pad of breadboards | 01:33 |
| qu1j0t3 | don't unplug, just move 2 feet right | 01:34 |
| qu1j0t3 | and i have enough scopes to have one every six feet | 01:34 |
| pie_ | haha | 01:34 |
| qu1j0t3 | not a whole wall, just a strip at working height. | 01:34 |
| qu1j0t3 | or all along a bench | 01:34 |
| pie_ | oh | 01:34 |
| pie_ | i see | 01:34 |
| qu1j0t3 | p. cool idea pie_++ | 01:35 |
| pie_ | well yeah thats basically the whole table breadboard? | 01:35 |
| pie_ | sorear, im not sure how this is related to the reduceron but iirc i was looking into it at the same time as this other thing, something about graph IRs (might be just something i made up), uhhh...what was it called | 01:35 |
| shapr | pie_: GRIN by Urban Boquist? | 01:36 |
| pie_ | no idea what that is | 01:36 |
| shapr | https://tech.labs.oliverwyman.com/blog/2005/11/01/grin-as-intermediate-representation-for-lazy-functional-languages/ | 01:36 |
| tpb | Title: GRIN as intermediate representation for Lazy Functional Languages - Oliver Wyman Labs: Technical (at tech.labs.oliverwyman.com) | 01:36 |
| shapr | and that's my name as the first two words :-/ | 01:36 |
| pie_ | hm sounds interesting | 01:36 |
| awygle | The Crazy Loper Guy thinks the memory bandwidth solution is asynchronous circuits and merging the CPU with RAM | 01:36 |
| pie_ | awygle, well thats basically what we said minus the async? | 01:37 |
| awygle | pie_: yeah basically | 01:37 |
| awygle | But you're not as crazy :-P | 01:37 |
| pie_ | are you sure | 01:38 |
| pie_ | *yet | 01:38 |
| awygle | I am surprised I've never seen "DRAM, but RAID0" proposed | 01:38 |
| pie_ | just wait for my family history of mental illness to kick in | 01:38 |
| pie_ | awygle, which raid is that again? | 01:38 |
| pie_ | ( qu1j0t3 misc https://www.flickr.com/photos/limpfish/29210807271 ) | 01:38 |
| awygle | pie_: striped | 01:39 |
| awygle | But actually you probably want something closer to raid 1 | 01:39 |
| pie_ | isnt that what ddr does? (i mean ive no idea) | 01:39 |
| pie_ | isnt the problem be the bus bandwidth? | 01:39 |
| pie_ | s/be// | 01:39 |
| sorear | awygle: my laptop splits each cache line between 8 RAM chips | 01:40 |
| kc8apf | RAM is already heavily interleaved | 01:40 |
| awygle | I did a bad job explaining myself lol | 01:40 |
| pie_ | maybe :P | 01:41 |
| pie_ | disparity of mental models | 01:41 |
| sorear | What I don't understand is why they did "each cache line takes 8 bytes from each of 8 RAM chips" and not "each cache line is in one RAM chip, and 8 of them can process 8 misses concurrently" | 01:41 |
| pie_ | sorear, interaction combinators is what is was thinking of | 01:42 |
| * pie_ actively seeks weird (cool) shit but doesnt have the background knowledge to proces it (yet) | 01:43 | |
| awygle | pie_: I feel like you'd like Papers We Love | 01:44 |
| qu1j0t3 | awygle | The Crazy Loper Guy || Stan. He has a name. Stan. :-) | 01:44 |
| qu1j0t3 | he;s on irc, too | 01:44 |
| qu1j0t3 | he's done a drive-by of a channel i'm in | 01:45 |
| pie_ | qu1j0t3, he sounds like you two would get along well :P | 01:45 |
| pie_ | well ideologically anyway | 01:45 |
| qu1j0t3 | wow, not sure whetehr to be flattered or not | 01:46 |
| pie_ | well considering youve corrupted me quite a lot, probably the former | 01:46 |
| qu1j0t3 | no, i like to think Stan is way farther out on the John Titor scale than i am | 01:46 |
| pie_ | yeah i didnt think you were that far gone :P | 01:46 |
| pie_ | (im sorry whos john titor) | 01:46 |
| qu1j0t3 | thank goodness | 01:46 |
| awygle | "John Titor is a name used on several bulletin boards during 2000 and 2001 by a poster claiming to be an American military time traveler from 2036" | 01:46 |
| awygle | Wow, that's amazing. | 01:47 |
| awygle | "Subsequent closer examination of Titor's assertions provoked widespread skepticism" never change, Wikipedia | 01:48 |
| qu1j0t3 | [Citation jet needed] | 01:48 |
| pie_ | lol | 01:51 |
| pie_ | john titor scale. hah. | 01:57 |
| * pie_ chuckles | 01:57 | |
| pie_ | sorear, pls make an IR for yosys that isnt vhdl :P | 01:57 |
| sorear | yosys already has an IR and it's not vhdl | 01:58 |
| sorear | i don't know much more about it | 01:58 |
| pie_ | oh ok i must have confused something | 01:59 |
| *** emeb has quit IRC | 02:26 | |
| *** m_w_ has quit IRC | 02:45 | |
| *** dys has quit IRC | 02:58 | |
| *** digshadow has quit IRC | 03:23 | |
| *** digshadow has joined #yosys | 03:42 | |
| pie_ | re: the ram speed stuff, the problem is bus speed right? so if you want more speed you make more bus, but i imagine that has its issues (space?) , so more bus with less bus is spatial localization | 04:23 |
| pie_ | i never did look into how inifiniband works | 04:23 |
| pie_ | s/localization/localization. right?/ | 04:23 |
| sorear | pie_: the problem that doesn't go away no matter what you do is energy | 04:24 |
| pie_ | how does that come up | 04:24 |
| pie_ | well besides the obvious clock speed power dissipation problem, but i dont see how that would apply here | 04:25 |
| sorear | there's a statutory limit on the largest battery you can carry undeclared onto a US airplane | 04:25 |
| sorear | since people like 8 hour battery life and they also like being able to fly with laptops, you're limited to 15-30W for a laptop | 04:26 |
| sorear | also if you go much above that you start burning people's laps | 04:26 |
| pie_ | but i dont see what that has anything to do with this :x | 04:26 |
| pie_ | unless its just more memory bandwidth => faster cpu => more heat | 04:27 |
| *** formalnewb has joined #yosys | 04:32 | |
| sorear | pie_: traces on a PCB have a lot of capacitance, and driving them at multiple GHz requires a *significant fraction of total system power* | 04:33 |
| pie_ | aha | 04:34 |
| pie_ | til 0.o | 04:34 |
| sorear | twice as many memory channels? twice the capacitance, twice the power | 04:34 |
| pie_ | is that why bus clocks are relatively low | 04:34 |
| sorear | twice the data rate on the same number of wires? twice the frequency, twice the current, twice the power | 04:34 |
| pie_ | (or just one of the many reasons) | 04:34 |
| pie_ | well mumble mumble parasitics | 04:34 |
| pie_ | ideal finite elements pls | 04:35 |
| sorear | I'm not quite sure? GDDR5 runs a much higher frequency over a smaller number of data lines compared to DDR4, and I wish I understood the tradeoffs better | 04:35 |
| sorear | as a general rule GPU hardware is more sensitive to BW and less sensitive to latency than CPU latency, which must be the driver of the differences, but I don't always see how to get from there to here | 04:36 |
| shapr | sorear: I have a scar from this laptop | 04:41 |
| formalnewb | how experienced in hdl design do you have to be to say you are an entry level professional? | 04:43 |
| formalnewb | i've designed a UART and some other basic stuff but i dont feel like ive done anything really complicated | 04:44 |
| awygle | i mean, you can call yourself whatever you want lol | 04:47 |
| awygle | i would say that's enough to apply for entry level _jobs_ if that's what you're asking | 04:48 |
| formalnewb | yeah pretty much | 05:11 |
| formalnewb | i mean ive done more complex stuff for my current work | 05:11 |
| formalnewb | its just usually i have a senior engineer helping architect and i implement it | 05:12 |
| *** formalnewb has quit IRC | 05:30 | |
| *** kraiskil has joined #yosys | 06:36 | |
| *** rqou has quit IRC | 06:37 | |
| *** rqou has joined #yosys | 06:38 | |
| *** pie_ has quit IRC | 06:49 | |
| *** GuzTech has joined #yosys | 06:53 | |
| *** AlexDaniel has joined #yosys | 07:02 | |
| *** pie_ has joined #yosys | 07:10 | |
| *** SpaceCoaster has quit IRC | 07:11 | |
| *** SpaceCoaster has joined #yosys | 07:27 | |
| *** AlexDaniel has quit IRC | 07:37 | |
| *** pie_ has quit IRC | 07:58 | |
| *** GuzTech has quit IRC | 08:00 | |
| *** kraiskil has quit IRC | 08:11 | |
| *** leviathan has joined #yosys | 08:24 | |
| *** pie_ has joined #yosys | 08:27 | |
| *** GuzTech has joined #yosys | 08:29 | |
| *** leviathan has quit IRC | 08:30 | |
| *** leviathan has joined #yosys | 08:31 | |
| *** cemerick has joined #yosys | 08:44 | |
| *** AlexDaniel has joined #yosys | 09:04 | |
| *** kraiskil has joined #yosys | 09:18 | |
| *** kishore has joined #yosys | 10:02 | |
| kishore | module dff (clk,reset, q, d); input clk, reset, d; output q; reg q; always @ (posedge clk ) begin if (reset == 1) q <= 0; else q <= d; end endmodule | 10:02 |
| *** pie_ has quit IRC | 10:16 | |
| *** pie_ has joined #yosys | 10:33 | |
| *** kishore has quit IRC | 10:33 | |
| *** proteus-guy has joined #yosys | 10:34 | |
| *** FabM has quit IRC | 10:40 | |
| *** eduardo_ has joined #yosys | 11:07 | |
| *** eduardo__ has quit IRC | 11:11 | |
| ZipCPU | awygle: (Responding to reddit) A* was always my favorite pathfinding algorithm from college. There's a nice wikipedia page on it. | 11:32 |
| awygle | Yes, I like it too | 11:33 |
| awygle | A nice, uncomplicated extension of djikstras | 11:33 |
| awygle | Which yields a significant improvement | 11:34 |
| ZipCPU | Would you believe I've tried to use a variant of the A* algorithm for determining computer moves in Checkers? | 11:34 |
| awygle | That sounds reasonable | 11:39 |
| ZipCPU | While the resulting strategy probably wasn't good enough for a grand master, and while it was quite memory intensive, it was good enough to beat my instructor--who wasn't expecting the game I was writing to be nearly as challenging. | 11:41 |
| *** cemerick_ has joined #yosys | 12:17 | |
| *** cemerick has quit IRC | 12:20 | |
| *** cemerick_ has quit IRC | 13:31 | |
| *** kraiskil has quit IRC | 14:06 | |
| *** swick has quit IRC | 14:10 | |
| *** swick has joined #yosys | 14:13 | |
| shapr | ZipCPU: nice! | 14:27 |
| ZipCPU | Mornin, shapr! | 14:27 |
| shapr | mornin ZipCPU! | 14:28 |
| shapr | I'm in DC the rest of the week, should be a fun adventure. | 14:29 |
| ZipCPU | Especially with the weather! | 14:29 |
| ZipCPU | We're not all that far away. Once the weather clears, feel free to holler at we might have a chance to meet if you'd like. | 14:29 |
| shapr | sure, we're flying back to Atlanta on Sunday | 14:29 |
| shapr | My gf is doing capstone stuff for her master's degree, so I'll not have much to do. | 14:30 |
| ZipCPU | :D | 14:30 |
| *** AlexDaniel has quit IRC | 14:53 | |
| *** seldridge has joined #yosys | 15:03 | |
| *** clifford has quit IRC | 15:06 | |
| *** clifford has joined #yosys | 15:09 | |
| *** ChanServ sets mode: +o clifford | 15:09 | |
| *** digshadow has quit IRC | 15:29 | |
| *** promach__ has joined #yosys | 15:50 | |
| promach__ | For https://gist.github.com/promach/454cba2c790db7925e176eee61bb1fe5#file-test_uart-v-L189 , why did "Tx_shift_reg_assertion" get optimized away ? | 15:51 |
| tpb | Title: test_UART.v · GitHub (at gist.github.com) | 15:51 |
| promach__ | I mean it does not show up in gtkwave | 15:52 |
| ZipCPU | promach_: You realize you are programming hardware, not software, right? | 15:52 |
| promach__ | ZipCPU: I do realized that | 15:53 |
| promach__ | but ... | 15:53 |
| ZipCPU | Problem #1: The blocking assignment operator (=) is unrealiable in simulation and should be avoided where possible | 15:53 |
| promach__ | it is formal verification, not simulation | 15:53 |
| ZipCPU | Problem #2: The arrays you are setting are actually a set of wires. They need to be set on all clocks. (You might wish to set them using assign statements instead.) | 15:54 |
| promach__ | yeah, true | 15:54 |
| ZipCPU | There is also a "keep" attribute that you (might) find valuable, but I'd fix the other problems first. | 15:54 |
| promach__ | sure | 15:55 |
| *** m_w_ has joined #yosys | 16:04 | |
| *** cemerick_ has joined #yosys | 16:20 | |
| promach__ | ZipCPU: changing to https://gist.github.com/promach/454cba2c790db7925e176eee61bb1fe5#file-test_uart-v-L152 style also does not help | 16:34 |
| tpb | Title: test_UART.v · GitHub (at gist.github.com) | 16:34 |
| *** digshadow has joined #yosys | 16:39 | |
| *** FabM has joined #yosys | 16:44 | |
| *** AlexDaniel has joined #yosys | 16:46 | |
| *** GuzTech has quit IRC | 16:50 | |
| *** emeb has joined #yosys | 16:51 | |
| ZipCPU | promach__: Try this. Remove the assert from the same always @(*) block as the assignment. Then make certain that the value is *always* assigned. | 16:56 |
| promach__ | ZipCPU: remove the assert() ? what ?! | 17:08 |
| ZipCPU | Place it into its own always@(*) block | 17:08 |
| ZipCPU | Separate it from the logic creating it. | 17:09 |
| promach__ | I just commented the assert() line and it does not help | 17:09 |
| ZipCPU | BTW: It's illegal to set a "wire" from within an always block ... | 17:09 |
| ZipCPU | You need to use an "assign" statement for such values. | 17:10 |
| ZipCPU | Worse, you are only setting this value on some clocks, not all clocks. This means you are inferring a latch and ... may not be getting the logic you are intending. | 17:10 |
| promach__ | i see | 17:10 |
| promach__ | okay | 17:10 |
| ZipCPU | so, perhaps you want an: assign Tx_shift_reg_assertion[Tx_shift_reg_index] = (Tx_shift_reg_index > (INPUT_DATA_WIDTH-cnt)) || (!transmission_had_started) || (!UART_is_transmitting) ||(shift_reg[Tx_shift_g_index] == i_data[i_data_index[Tx_shift_reg_index])); | 17:12 |
| ZipCPU | Even better ... you want variable names that will fit within an 80 column display when using 8-space tabs for indentation. :P | 17:12 |
| promach__ | what do you mean by 80 column display ? | 17:13 |
| ZipCPU | I mean my terminal has only 80 columns across, and hence when I try to examine your code within vi ... :P | 17:13 |
| promach__ | mine one is 211x51 dimension | 17:14 |
| *** AlexDaniel has quit IRC | 17:17 | |
| promach__ | ZipCPU: I am not really familiar with your predicate logic simplication mechanism | 17:18 |
| ZipCPU | if (A) assert(B); is the same as assert((!A)||(B)); | 17:18 |
| ZipCPU | Is your code posted? | 17:19 |
| *** proteus-guy has quit IRC | 17:21 | |
| *** proteus-guy has joined #yosys | 17:22 | |
| promach__ | ZipCPU: one moment | 17:30 |
| promach__ | Warning: Identifier `\Tx_shift_g_index' is implicitly declared at ../rtl/test_UART.v:149. | 17:30 |
| promach__ | Warning: Wire test_UART.\Tx_shift_g_index is used but has no driver. | 17:30 |
| promach__ | for https://gist.github.com/promach/454cba2c790db7925e176eee61bb1fe5#file-test_uart-v-L138-L169 | 17:31 |
| tpb | Title: test_UART.v · GitHub (at gist.github.com) | 17:31 |
| ZipCPU | Somehow I get the feeling you didn't do as I was recommending. ;) | 17:31 |
| promach__ | ZipCPU: shall I come back in the morning ? | 17:31 |
| promach__ | I feel so drowsy now... | 17:31 |
| ZipCPU | n8 | 17:32 |
| promach__ | huh ? n8 ? | 17:32 |
| ZipCPU | Get some rest. You are missing the silly stuff now. | 17:33 |
| promach__ | silly stuff ? | 17:33 |
| promach__ | I really need to sleep... | 17:33 |
| ZipCPU | Yes. | 17:33 |
| shapr | sleep helps | 17:33 |
| promach__ | ZipCPU, shapr: good nite | 17:34 |
| shapr | ZipCPU: I would enjoy meeting you, is weekday eve or weekend more convenient? | 17:34 |
| shapr | I promise that I won't try to convert you to the way of pure functional programming :-P | 17:34 |
| qu1j0t3 | do eet | 17:37 |
| shapr | mostly because I'm worried FPGA design is exactly that | 17:38 |
| *** promach__ has quit IRC | 17:39 | |
| *** digshadow has quit IRC | 17:40 | |
| *** forrestv has quit IRC | 17:41 | |
| *** rqou has quit IRC | 17:41 | |
| *** awygle has quit IRC | 17:41 | |
| *** rqou has joined #yosys | 17:41 | |
| *** FabM has quit IRC | 17:42 | |
| *** awygle has joined #yosys | 17:42 | |
| *** forrestv has joined #yosys | 17:46 | |
| *** proteus-guy has quit IRC | 17:54 | |
| *** cemerick has joined #yosys | 18:00 | |
| *** proteus-guy has joined #yosys | 18:01 | |
| ZipCPU | shapr: Let's take this off channel. | 18:02 |
| *** proteus-guy has quit IRC | 18:02 | |
| *** cemerick_ has quit IRC | 18:02 | |
| *** proteus-guy has joined #yosys | 18:03 | |
| *** proteus-guy has quit IRC | 18:10 | |
| *** digshadow has joined #yosys | 18:13 | |
| *** sklv has joined #yosys | 18:14 | |
| shapr | ZipCPU: sure | 18:24 |
| *** GuzTech has joined #yosys | 18:38 | |
| *** dys has joined #yosys | 19:28 | |
| *** cemerick has quit IRC | 20:14 | |
| *** cemerick has joined #yosys | 20:16 | |
| *** cemerick has quit IRC | 20:17 | |
| *** cemerick has joined #yosys | 20:18 | |
| *** leviathan has quit IRC | 20:52 | |
| *** AlexDaniel has joined #yosys | 22:49 | |
| *** GuzTech has quit IRC | 23:25 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!