Wednesday, 2018-03-21

*** tpb has joined #yosys00:00
*** sklv has quit IRC00:51
kc8apfshapr: ? I know of a bunch of FPGA and ASIC HDL engineering jobs00:54
kc8apfnot aware of any FPGA compiler projects00:54
kc8apfjust prjxray00:55
kc8apfmeh. Another team wants to program FPGAs with Haskell01:09
shapryeah, it's fun stuff01:10
shaprkc8apf: this is the third team I know doing that,, clash-lang, and now this one. Do you know others?01:10
kc8apfthere have been teams trying it at Google since 2005(?)01:12
shaprhuh, didn't know that01:12
*** xrexeon has quit IRC01:12
shaprreconfigure has it working, using Haskell to run go-lang on an FPGA01:13
*** AlexDaniel has quit IRC01:14
* qu1j0t3 (why wouldn't you just run Haskell on it)01:15
shaprqu1j0t3: that's been done too, but never hit production quality:
tpbTitle: 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
qu1j0t3holy shit.01:16
shaprdid not think the title would be that large01:16
qu1j0t3i'm glad it was.01:16
qu1j0t3i am very pleased to know about this. Relevant to my interests01:16
qu1j0t3i wonder how small an fpga it can fit in.01:16
shaprdon't know01:17
qu1j0t3i'd better study this one day when i get a vacation01:17
shaprbut last I heard the prototype required you to build the program in when you compiled it for the FPGA01:17
shapralso, graph reduction CPUs require *much* more memory bandwidth than every day CPUs01:17
shaprbut also allow parallel reduction01:18
sorearmodern architectures are close to the point where you are generically starved for memory bandwidth rather than available ALUs01:19
shaprsorear: yeah, thanks for making that explicit01:19
shaprI realize I should have said that01:19
shaprsorear: do you see a solution for that in the near future?01:19
pie_i havent heard of reconfigure.io01:19
pie_shapr, i wouldnt know but the only thing i can imagine helpin offhand is spatially local memory01:21
pie_problem there probably is...its spatially local01:21
pie_(..oh wait fpga already do this?)01:21
shaprNUMA systems?01:21
pie_(but its not a lot of memory)01:21
shapryeah, I just don't know.01:21
pie_disclaimer i have no fucking clue what im talking about01:22
sorearspatially 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
soreardesigns with scrachpads and explicit message passing can use less bandwidth but are much harder to program01:23
shaprmore lanes from memory to CPU? reduce latency via alien magic? what's the fix?01:23
sorearadding more hardware means that your program executes using the same amount of memory in half the time01:24
pie_oh is go, meh01:24
shaprpie_: but they are making money using a Go -> Haskell -> FPGA setup, so that's cool01:25
pie_true true01:25
sorearsilicon photonics will make communicating with memory cheaper and is worth followin01: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_oh god01:26
pie_fucking christ01:26
pie_i can just imagine pipelining involving "data on wire lag"01:27
shaprsorear: I hope we find a solution soon01:27
pie_so uhh propagation speed01:27
pie_do we already use that?01:27
soreara bit in 10G ethernet is 2cm long01: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 fore01:28
sorearwires *inside* chips are kinda bad transmission lines, they have too much resistance and too little inductance01:28
pie_i guess i was thinking more in-cpu01:28
pie_i see01:28
pie_also, clocks01:29
sorearso you can't really have multiple bits in flight at once, but longer wires do take longer to switch01:29
pie_i see01:29
sorearunless you have buffers ;)01:29
qu1j0t3pie_: The 6502 on a breadboard thing?01:30
qu1j0t3pie_: i thikn i still have that open in a browser window somewhere...01:30
pie_ah yeah that was it01:30
qu1j0t3he made a big deal out of his graphics engine01:31
* sorear needs to dig into the reduceron at some point and understand what its secret sauce is01:31
qu1j0t3i guess i'd be pretty excited if my breadboard were that big, and if i got off my ass, it should be01:31
pie_WARNING: DO NOT READ UNLESS YOU WANT TO WASTE A FEW HOURS this link was purple so this must be it
tpbTitle: View topic - Vulcan-74 - A 6502 Powered Retro MegaProject (at
qu1j0t3sorear: update us with what you find out. it looks pretty interesting to me.01:32
pie_i googled crazy 6502 breadboard lol01:32
qu1j0t3pie_: :D01:32
pie_qu1j0t3, kind of makes me thing of those big mixing tables and walls of modular synths or whatever01:32
pie_just get a table where the whole table surface is breadboard01:33
pie_man that sounds like it would be pretty cool01:33
pie_albeit immobile :P01:33
qu1j0t3hahaha why not a whole room01:33
pie_that makes no sense? :P01:33
qu1j0t3pie_: you're giving me ideas for my Future Lab01:33
qu1j0t3yeah it does01:33
pie_err, sorry for the hijack anyway01:33
qu1j0t3its like a pad of breadboards01:33
qu1j0t3don't unplug, just move 2 feet right01:34
qu1j0t3and i have enough scopes to have one every six feet01:34
qu1j0t3not a whole wall, just a strip at working height.01:34
qu1j0t3or all along a bench01:34
pie_i see01:34
qu1j0t3p. 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 called01:35
shaprpie_: GRIN by Urban Boquist?01:36
pie_no idea what that is01:36
tpbTitle: GRIN as intermediate representation for Lazy Functional Languages - Oliver Wyman Labs: Technical (at
shaprand that's my name as the first two words :-/01:36
pie_hm sounds interesting01:36
awygleThe Crazy Loper Guy thinks the memory bandwidth solution is asynchronous circuits and merging the CPU with RAM01:36
pie_awygle, well thats basically what we said minus the async?01:37
awyglepie_: yeah basically01:37
awygleBut you're not as crazy :-P01:37
pie_are you sure01:38
awygleI am surprised I've never seen "DRAM, but RAID0" proposed01:38
pie_just wait for my family history of mental illness to kick in01:38
pie_awygle, which raid is that again?01:38
pie_( qu1j0t3 misc )01:38
awyglepie_: striped01:39
awygleBut actually you probably want something closer to raid 101:39
pie_isnt that what ddr does? (i mean ive no idea)01:39
pie_isnt the problem be the bus bandwidth?01:39
sorearawygle: my laptop splits each cache line between 8 RAM chips01:40
kc8apfRAM is already heavily interleaved01:40
awygleI did a bad job explaining myself lol01:40
pie_maybe :P01:41
pie_disparity of mental models01:41
sorearWhat 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 of01:42
* pie_ actively seeks weird (cool) shit but doesnt have the background knowledge to proces it (yet)01:43
awyglepie_: I feel like you'd like Papers We Love01:44
qu1j0t3   awygle | The Crazy Loper Guy      || Stan. He has a name. Stan.    :-)01:44
qu1j0t3he;s on irc, too01:44
qu1j0t3he's done a drive-by of a channel i'm in01:45
pie_qu1j0t3, he sounds like you two would get along well :P01:45
pie_well ideologically anyway01:45
qu1j0t3wow, not sure whetehr to be flattered or not01:46
pie_well considering youve corrupted me quite a lot, probably the former01:46
qu1j0t3no, i like to think Stan is way farther out on the John Titor scale than i am01:46
pie_yeah i didnt think you were that far gone :P01:46
pie_(im sorry whos john titor)01:46
qu1j0t3thank goodness01: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
awygleWow, that's amazing.01:47
awygle"Subsequent closer examination of Titor's assertions provoked widespread skepticism" never change, Wikipedia01:48
qu1j0t3[Citation jet needed]01:48
pie_john titor scale. hah.01:57
* pie_ chuckles01:57
pie_sorear, pls make an IR for yosys that isnt vhdl :P01:57
sorearyosys already has an IR and it's not vhdl01:58
soreari don't know much more about it01:58
pie_oh ok i must have confused something01:59
*** emeb has quit IRC02:26
*** m_w_ has quit IRC02:45
*** dys has quit IRC02:58
*** digshadow has quit IRC03:23
*** digshadow has joined #yosys03: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 localization04:23
pie_i never did look into how inifiniband works04:23
pie_s/localization/localization. right?/04:23
sorearpie_: the problem that doesn't go away no matter what you do is energy04:24
pie_how does that come up04:24
pie_well besides the obvious clock speed power dissipation problem, but i dont see how that would apply here04:25
sorearthere's a statutory limit on the largest battery you can carry undeclared onto a US airplane04:25
sorearsince people like 8 hour battery life and they also like being able to fly with laptops, you're limited to 15-30W for a laptop04:26
sorearalso if you go much above that you start burning people's laps04:26
pie_but i dont see what that has anything to do with this :x04:26
pie_unless its just more memory bandwidth => faster cpu => more heat04:27
*** formalnewb has joined #yosys04:32
sorearpie_: 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_til 0.o04:34
soreartwice as many memory channels?  twice the capacitance, twice the power04:34
pie_is that why bus clocks are relatively low04:34
soreartwice the data rate on the same number of wires?  twice the frequency, twice the current, twice the power04:34
pie_(or just one of the many reasons)04:34
pie_well mumble mumble parasitics04:34
pie_ideal finite elements pls04:35
sorearI'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 better04:35
sorearas 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 here04:36
shaprsorear: I have a scar from this laptop04:41
formalnewbhow experienced in hdl design do you have to be to say you are an entry level professional?04:43
formalnewbi've designed a UART and some other basic stuff but i dont feel like ive done anything really complicated04:44
awyglei mean, you can call yourself whatever you want lol04:47
awyglei would say that's enough to apply for entry level _jobs_ if that's what you're asking04:48
formalnewbyeah pretty much05:11
formalnewbi mean ive done more complex stuff for my current work05:11
formalnewbits just usually i have a senior engineer helping architect and i implement it05:12
*** formalnewb has quit IRC05:30
*** kraiskil has joined #yosys06:36
*** rqou has quit IRC06:37
*** rqou has joined #yosys06:38
*** pie_ has quit IRC06:49
*** GuzTech has joined #yosys06:53
*** AlexDaniel has joined #yosys07:02
*** pie_ has joined #yosys07:10
*** SpaceCoaster has quit IRC07:11
*** SpaceCoaster has joined #yosys07:27
*** AlexDaniel has quit IRC07:37
*** pie_ has quit IRC07:58
*** GuzTech has quit IRC08:00
*** kraiskil has quit IRC08:11
*** leviathan has joined #yosys08:24
*** pie_ has joined #yosys08:27
*** GuzTech has joined #yosys08:29
*** leviathan has quit IRC08:30
*** leviathan has joined #yosys08:31
*** cemerick has joined #yosys08:44
*** AlexDaniel has joined #yosys09:04
*** kraiskil has joined #yosys09:18
*** kishore has joined #yosys10:02
kishoremodule 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       endmodule10:02
*** pie_ has quit IRC10:16
*** pie_ has joined #yosys10:33
*** kishore has quit IRC10:33
*** proteus-guy has joined #yosys10:34
*** FabM has quit IRC10:40
*** eduardo_ has joined #yosys11:07
*** eduardo__ has quit IRC11:11
ZipCPUawygle: (Responding to reddit) A* was always my favorite pathfinding algorithm from college.  There's a nice wikipedia page on it.11:32
awygleYes, I like it too11:33
awygleA nice, uncomplicated extension of djikstras11:33
awygleWhich yields a significant improvement11:34
ZipCPUWould you believe I've tried to use a variant of the A* algorithm for determining computer moves in Checkers?11:34
awygleThat sounds reasonable11:39
ZipCPUWhile 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 #yosys12:17
*** cemerick has quit IRC12:20
*** cemerick_ has quit IRC13:31
*** kraiskil has quit IRC14:06
*** swick has quit IRC14:10
*** swick has joined #yosys14:13
shaprZipCPU: nice!14:27
ZipCPUMornin, shapr!14:27
shaprmornin ZipCPU!14:28
shaprI'm in DC the rest of the week, should be a fun adventure.14:29
ZipCPUEspecially with the weather!14:29
ZipCPUWe'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
shaprsure, we're flying back to Atlanta on Sunday14:29
shaprMy gf is doing capstone stuff for her master's degree, so I'll not have much to do.14:30
*** AlexDaniel has quit IRC14:53
*** seldridge has joined #yosys15:03
*** clifford has quit IRC15:06
*** clifford has joined #yosys15:09
*** ChanServ sets mode: +o clifford15:09
*** digshadow has quit IRC15:29
*** promach__ has joined #yosys15:50
promach__For , why did "Tx_shift_reg_assertion" get optimized away ?15:51
tpbTitle: test_UART.v · GitHub (at
promach__I mean it does not show up in gtkwave15:52
ZipCPUpromach_: You realize you are programming hardware, not software, right?15:52
promach__ZipCPU: I do realized that15:53
promach__but ...15:53
ZipCPUProblem #1: The blocking assignment operator (=) is unrealiable in simulation and should be avoided where possible15:53
promach__it is formal verification, not simulation15:53
ZipCPUProblem #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, true15:54
ZipCPUThere is also a "keep" attribute that you (might) find valuable, but I'd fix the other problems first.15:54
*** m_w_ has joined #yosys16:04
*** cemerick_ has joined #yosys16:20
promach__ZipCPU: changing to style also does not help16:34
tpbTitle: test_UART.v · GitHub (at
*** digshadow has joined #yosys16:39
*** FabM has joined #yosys16:44
*** AlexDaniel has joined #yosys16:46
*** GuzTech has quit IRC16:50
*** emeb has joined #yosys16:51
ZipCPUpromach__: 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
ZipCPUPlace it into its own [email protected](*) block17:08
ZipCPUSeparate it from the logic creating it.17:09
promach__I just commented the assert() line and it does not help17:09
ZipCPUBTW: It's illegal to set a "wire" from within an always block ...17:09
ZipCPUYou need to use an "assign" statement for such values.17:10
ZipCPUWorse, 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 see17:10
ZipCPUso, 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
ZipCPUEven better ... you want variable names that will fit within an 80 column display when using 8-space tabs for indentation.  :P17:12
promach__what do you mean by 80 column display ?17:13
ZipCPUI mean my terminal has only 80 columns across, and hence when I try to examine your code within vi ... :P17:13
promach__mine one is 211x51 dimension17:14
*** AlexDaniel has quit IRC17:17
promach__ZipCPU: I am not really familiar with your predicate logic simplication mechanism17:18
ZipCPUif (A) assert(B); is the same as assert((!A)||(B));17:18
ZipCPUIs your code posted?17:19
*** proteus-guy has quit IRC17:21
*** proteus-guy has joined #yosys17:22
promach__ZipCPU: one moment17: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
tpbTitle: test_UART.v · GitHub (at
ZipCPUSomehow 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
promach__huh ? n8 ?17:32
ZipCPUGet some rest.  You are missing the silly stuff now.17:33
promach__silly stuff ?17:33
promach__I really need to sleep...17:33
shaprsleep helps17:33
promach__ZipCPU, shapr: good nite17:34
shaprZipCPU: I would enjoy meeting you, is weekday eve or weekend more convenient?17:34
shaprI promise that I won't try to convert you to the way of pure functional programming :-P17:34
qu1j0t3do eet17:37
shaprmostly because I'm worried FPGA design is exactly that17:38
*** promach__ has quit IRC17:39
*** digshadow has quit IRC17:40
*** forrestv has quit IRC17:41
*** rqou has quit IRC17:41
*** awygle has quit IRC17:41
*** rqou has joined #yosys17:41
*** FabM has quit IRC17:42
*** awygle has joined #yosys17:42
*** forrestv has joined #yosys17:46
*** proteus-guy has quit IRC17:54
*** cemerick has joined #yosys18:00
*** proteus-guy has joined #yosys18:01
ZipCPUshapr: Let's take this off channel.18:02
*** proteus-guy has quit IRC18:02
*** cemerick_ has quit IRC18:02
*** proteus-guy has joined #yosys18:03
*** proteus-guy has quit IRC18:10
*** digshadow has joined #yosys18:13
*** sklv has joined #yosys18:14
shaprZipCPU: sure18:24
*** GuzTech has joined #yosys18:38
*** dys has joined #yosys19:28
*** cemerick has quit IRC20:14
*** cemerick has joined #yosys20:16
*** cemerick has quit IRC20:17
*** cemerick has joined #yosys20:18
*** leviathan has quit IRC20:52
*** AlexDaniel has joined #yosys22:49
*** GuzTech has quit IRC23:25

Generated by 2.13.1 by Marius Gedminas - find it at!