lutsabound has quit [Quit: Connection closed for inactivity]
seldridge has joined #yosys
digshadow has joined #yosys
cemerick has quit [Ping timeout: 272 seconds]
seldridge has quit [Ping timeout: 240 seconds]
lutsabound has joined #yosys
cemerick has joined #yosys
develonepi3 has quit [Remote host closed the connection]
cemerick_ has joined #yosys
cemerick has quit [Ping timeout: 240 seconds]
develonepi3 has joined #yosys
develonepi3 has quit [Client Quit]
cemerick_ has quit [Ping timeout: 240 seconds]
s1dev has joined #yosys
lutsabound has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #yosys
s1dev has quit [Ping timeout: 272 seconds]
lutsabound has joined #yosys
promach_ has joined #yosys
develonepi3 has joined #yosys
fsasm has joined #yosys
dys has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 260 seconds]
<shapr>
ZipCPU: do you use emacs to write verilog?
pie_ has joined #yosys
<ZipCPU>
shapr: Nah, I like linux too much I don't really need a different O/S
<ZipCPU>
In all seriousness, I'm very much given to gvim. I don't need the mouse, and I don't need the control key.
maikmerten has joined #yosys
<maikmerten>
hi there, I'm trying to give nextpnr a spin
<maikmerten>
that one looks exciting and overall completely awesome
<maikmerten>
just running into problem with pnr'ing a design of mine
<maikmerten>
Info: Packing special functions..
<maikmerten>
Abgebrochen
<maikmerten>
what(): _Map_base::at
<maikmerten>
terminate called after throwing an instance of 'std::out_of_range'
<maikmerten>
so... somehow my design triggers an illegal access to an internal data structure?
<maikmerten>
(the included blinky example just works - and it's a pleasure to see nextpnr do its thing in the GUI)
<maikmerten>
seeing picorv32 pulling itself together during placing is quite impressive
cemerick_ has joined #yosys
dys has joined #yosys
<daveshah>
maikmerten: do you use PLL global outputs? They aren't supported yet
<daveshah>
I expect we'll add them soon (use the core outputs as a workaround for now)
<maikmerten>
ah, I guess that's indeed the case
<maikmerten>
.PLLOUTGLOBAL(clk_pll)
<maikmerten>
so case closed ;-)
cemerick has joined #yosys
<maikmerten>
in the mean time I'll just admire the visualization nextpnr shows during packing other designs ;-)
<maikmerten>
in case of picorv32, it reminds me of T-1000 from Terminator 2 pulling itself together
cemerick_ has quit [Ping timeout: 272 seconds]
<maikmerten>
daveshah, yeah, the core output workaround seems to work nicely
dxld has quit [Quit: Bye]
dxld has joined #yosys
<shapr>
ZipCPU: recommended verilog tutorials? I have a safari books subscription, so something from o'reilly would be easiest
<ZipCPU>
Heheh ... None, sorry. I haven't read any Verilog books. Can I recommend some on line resources instead?
<shapr>
sure!
<ZipCPU>
asic-world would be one, it discusses the Verilog syntax. fpga4fun.com is another. It walks you through some of the simpler and more basic peripheral protocols
<ZipCPU>
Do you have a board to play with?
<shapr>
I have a beaglewire
<ZipCPU>
shapr: Have you seen my recommended Verilog learning course outline?
<shapr>
oh, lemme go look at that
<ZipCPU>
Give me a moment to put it on imgur again
<shapr>
ZipCPU: your https cert is broken
<ZipCPU>
:(
<maikmerten>
shapr, I "converted" from VHDL to Verilog via "Verilog by Example: A Concise Introduction for FPGA Design"
<shapr>
maikmerten: I'm converting from Java/Python/Haskell, so I'm not sure the best approach
<shapr>
maikmerten: but I will look into that book, I think I've seen it on safari, thank!
<shapr>
ZipCPU: is this also on zipcpu.com?
<maikmerten>
well, that book isn't exactly a "VHDL -> Verilog" thing - it doesn't really mention VHDL at all
<ZipCPU>
My ongoing thesis is that students don't spend enough time learning how to debug their designs, they instead just get thrown into making complex designs.
<ZipCPU>
shapr: It sort of *is* zipcpu.com
<maikmerten>
but I was able to live with the "concise"-part, given my hobby-VHDL skills
<shapr>
maikmerten: oh, sounds like that could work for me
<shapr>
ZipCPU: are you using letsencrypt for your SSL certificate?
<ZipCPU>
Not at all.
<ZipCPU>
I didn't have https at all originally since github pages didn't support them.
<shapr>
oh, I've heard it does now?
<ZipCPU>
Then when they started supporting https for non-github domains, I followed their instructions to get set up.
<shapr>
neato
<ZipCPU>
They said nothing about SSL certs, so ... now I need to figure out how to set (if possible) my own certs
<ZipCPU>
It's not ideal, but you can use it
<ZipCPU>
shapr: I take that back ... github pages has partnered with letsencrypt
<shapr>
nifty, did not know that
<shapr>
maikmerten: what got you into doing hobby FPGA designs?
<maikmerten>
shapr, well, a desire to understand computer design top-to-bottom
<maikmerten>
while my designs are always simple I can extrapolate from there and appreciate what real designers are doing
<shapr>
that makes sense
<maikmerten>
for instance, it's very satisfying to have developed a RISC-V core that executes code compiled on GCC
<maikmerten>
(in my case, a simple multi-cycle machine)
<maikmerten>
but even then a whole lot of challenges are visible that the "big boys" have arise
<maikmerten>
like "if I want to go to a pipelined scalar design, how do I keep that beast fed with instructions?"
<shapr>
I wouldn't consider developing your own core hobby level :-P
<maikmerten>
--> you gotta need a cache
<maikmerten>
--> you gotta have to have it coherent
<shapr>
ah, I've heard ZipCPU talk about that kind of thing, how to feed more instructions in fewer cycles
<maikmerten>
--> you gotta decide if write-through is your thing or if you can stomach write-back
<maikmerten>
and don't get me started on what interesting challenges lurk if you want to go superscalar, out-of-order
<maikmerten>
(that certainly is *not* trivial or hobby-level)
<shapr>
I have a hifive unleashed! but the fan died :-(
<maikmerten>
yeah, that one :-)
<shapr>
so I'm waiting for a new fan to arrive
<maikmerten>
oh, the hifive unleashed certainly is very intersting
<maikmerten>
I'd wished there was something more "consumer"-ready available
<shapr>
the hifive unleashed plus the expansion board is the closest thing that exists
<maikmerten>
something similar to a RPi
<shapr>
but, 2k for the expansion board was a bit too much for me
<maikmerten>
indeed
<shapr>
I might have bought it anyway if the FPGA were yosys-supported
<shapr>
I'm not willing to spend money on hardware that requires proprietary tools
<FL4SHK>
I'm mostly using yosys for the formal verification :V
<shapr>
FL4SHK: what other tools do you use?
<FL4SHK>
Icarus Verilog, Verilator
<FL4SHK>
proprietary synthesis things
<FL4SHK>
Icarus Verilog has a really nice feature that I'm using
<FL4SHK>
It can convert its support of SystemVerilog to Verilog-1995
<FL4SHK>
subject to a few limitations
<maikmerten>
oh, so one can transpile SystemVerilog to something yosys could process?
<FL4SHK>
yes!
<maikmerten>
wow, didn't know that!
<FL4SHK>
or, well, it's not full SystemVerilog
<FL4SHK>
but like, the synthesis subset
<FL4SHK>
that Icarus Verilog supports
<maikmerten>
well, I guess having "most" or "some" SV-features is better than having none at all ;-)
<FL4SHK>
Yes, I have some
<FL4SHK>
I'm a big fan of packages, packed structs, and enums especially
<maikmerten>
those sound very useful
<FL4SHK>
I extensively use those things
<FL4SHK>
formal verification makes some of that weird (not the packages mind you)
<maikmerten>
in my current Verilog designs, I muck around with preprocessor stuff like defines where in VHDL I used enums
<FL4SHK>
yeah, I grew tired of that quickly
<FL4SHK>
I'd sooner use m4 as the preprocessor
<FL4SHK>
I do extensively use the preprocessor to get around weird things in Icarus Verilog
<FL4SHK>
packed structs are extremely nice for module interfaces
<FL4SHK>
...downside is that they can't be parameterized, despite how EASY that'd be to support
<FL4SHK>
SystemVerilog itself doesn't permit that for some reason...
<maikmerten>
I'm also pretty tired of my lazy-horrible way to bind together my designs: I basically have each module in its own .v file and then `include them in a subsystem-toplevel
<FL4SHK>
I have no clue why.
<shapr>
My goal is to be using clash-lang at the end of my learning process.
<maikmerten>
and `define is workdir-relative! Yuck!
<maikmerten>
(by default)
<shapr>
fir coeffs x = dotp coeffs (window x)
<shapr>
where dotp as bs = sum (zipWith (*) as bs)
<qu1j0t3>
.b 80
<shapr>
maikmerten: if verilog is hobby fun, what do you do for work?
<maikmerten>
I'm a lecturer for computer science at a university of applied sciences
<shapr>
oh that's cool
<sorear>
The Verilog and SystemVerilog specs were merged in the 2000s, so “convert systemverilog to verilog” is kind of a category error
<maikmerten>
it certainly is a neat arrangement for me ;-)
<maikmerten>
given I can often somewhat adapt my hobby interests to work
<maikmerten>
s/adapt/transfer
<maikmerten>
too bad we don't have classes on digital design, that'd be great excuse to further go down that rabbit hole ;-)
<sorear>
I’ve gotten a bearing on OoO mostly by reading a bunch of slides and asking boomcpu too many questions
<FL4SHK>
sorear: okay, convert SystemVerilog to Verilog-1995 then
<FL4SHK>
maikmerten: closest I've gotten to be a lecturer is that I'm about to be a teaching assistant at my college for the class on processor implementation
<FL4SHK>
it's a required class for the computer engineering students
<FL4SHK>
I've implemented several CPUs, haha
<FL4SHK>
and I'm in the middle of implementing another one for my master's project...
<maikmerten>
FL4SHK, that sounds amazing :-)
<FL4SHK>
I honestly enjoy all the pieces of it
<FL4SHK>
instruction set design is really fun to me...
<FL4SHK>
I like the compiler side too :P
<maikmerten>
the compiler side is one of the most intimidating things (for me, at least)
<FL4SHK>
I agree with that, especially if you're talking, modifying an existing compiler
<maikmerten>
which is why I just went straight for RV32, where the heavy lifting was already done
<FL4SHK>
THAT is intimidating
<FL4SHK>
The farthest I've gotten was, I had straight line code being generated
<maikmerten>
yup, GCC is a beast, LLVM seems more modular, but still massive
<FL4SHK>
LLVM looks harder to actually get going
<FL4SHK>
but LLVM is better for targeting less conventional things
<maikmerten>
yeah, LLVM is used for everything imaginable
<FL4SHK>
I'd be interested in doing stuff with LLVM
<cr1901>
Neither of them are good for targeting less conventional things... and at least gcc has a PIC port. I don't think llvm targets anything w/ non-flat addr space
<maikmerten>
want code for your CPU? Here you go. Oh, you want GPU shader code? Well, there's a backend for that, too
<sorear>
gcc actually has targets in-tree for fun architectures like ia64 and sharc
<FL4SHK>
cr1901: emscripten
<FL4SHK>
LLVM can do THAT
<maikmerten>
that's the first time I hear "ia64" being referred to as "fun architecture" ;-)
<sorear>
LLVM only targets normal cpus and a GPU or two
<FL4SHK>
sure, by default
<FL4SHK>
but again I point to emscripten
<cr1901>
Wasn't there a 65816 backend you were working on?
<sorear>
Me? No
<cr1901>
No, FL4SHK
<maikmerten>
65816 backend? Someone wants a neat compiler for an Apple IIgs?
<FL4SHK>
SNES
<maikmerten>
oh, right
<maikmerten>
forgot that one
<FL4SHK>
I think that project's been forgotten
<FL4SHK>
or given up on
<shapr>
I know microsoft research ported both linux and windows to their E2 data graph CPU, I wish they'd release those changes
<maikmerten>
well, they'd release those once/if they make builds public
<maikmerten>
(the linux part)
<cr1901>
>at least gcc has a PIC port
<cr1901>
Err, Microchip* has a PIC port that they won't contribute upstream. So that shouldn't count either. But clearly they were willing to pay some ppl to make a port (poor souls)...
<maikmerten>
I'd assume the Linux changes wouldn't be thaaaaat involved, but the compiler might be
<shapr>
and during bouts of frustration, I get to play exapunks
lutsabound has quit [Quit: Connection closed for inactivity]
promach_ has quit [Ping timeout: 256 seconds]
maikmerten has quit [Quit: Verlassend]
dys has quit [Ping timeout: 244 seconds]
maikmerten has joined #yosys
dys has joined #yosys
<shapr>
I wish my cable connection weren't in my bedroom
<shapr>
I've built a tent for some of the blinding blue LEDs so I can sleep
<ZipCPU>
Sounds like a job for 3D PRINTER MAN!!!!
<shapr>
yeah, I should really go to the hackerspace where I'm still a member and just haven't visited in months
<shapr>
or I could run an ethernet cable under the door and over the divider and into the living room
<shapr>
I dunno
* shapr
reads more posts on ZipCPU.com
<shapr>
hmm
<shapr>
debugging bus over tcp/ip ?
<ZipCPU>
Absolutely!
<ZipCPU>
I do all my device interactions over TCP/IP.
<ZipCPU>
I like being able to move from the office to the bedside, without having to rewire any of my hardware.
<shapr>
makes sense
<shapr>
I have my beaglewire plugged into my wifi router
<shapr>
downside? BLINDING BLUE LIGHTS
* ZipCPU
is still waiting for 3d printer man to walk through the walls and solve the problem
<shapr>
I think I have the first printing of the beaglebone black, I remember that revision A1 of the BBB cut the LED brightness by about 50%
<shapr>
me and a pile of other people complained about having to shut down the BBB to be able to sleep in the NEXT room over
<shapr>
but I think whoever designed the BeagleWire chose those same original blue LEDs
<ZipCPU>
The BBB has the BBLs?
<shapr>
ha
<shapr>
I should go dig up my original BeagleBoneBlack
<shapr>
ZipCPU: so, how? do you scp a bitstream to the device?
<shapr>
http upload a bitstream?
<ZipCPU>
Most if not all of my designs allow me to write to the flash from within the command port.
<shapr>
the command port?
* shapr
starts googling
<ZipCPU>
I tend to call it a debugging bus
<shapr>
oh
<ZipCPU>
Typically it's a regular serial port that I've then put special sauce into on the FPGA side, so it can accept and respond to bus transactions.
<ZipCPU>
Then, on the host computer (the one with the actual serial port), I'll bridge the serial port to a TCP/IP port
<ZipCPU>
On newer designs, I use a pair of TCP/IP ports--one for the debugging bus, and another for the CPU's console port.
<shapr>
console port?
<shapr>
what does that do? you can read the cpu state over tcp?
<ZipCPU>
Absolutely!
<ZipCPU>
I can do that through the debugging bus though.
<shapr>
so why two ports?
<ZipCPU>
The console port allows the CPU access to a 7-bit I/O port, via printf and such
<maikmerten>
heh, in SPU32 I've got a tiny boot ROM (512 byte, of which 332 bytes are used) to allow pushing programs either into SRAM or into SPI Flash via UART. If no input on UART is provided for 500ms, the code will copy contents from the SPI Flash to RAM and execute
<ZipCPU>
That's not a bad approach, but ... not quite what I wanted myself.
<maikmerten>
yup :-)
<ZipCPU>
Since I'm so often doing development on and with the ZipCPU, I typically don't let the CPU startup without being told.
<ZipCPU>
Hence, on power up, I'll set memory and then registers using the debugging bus, then release the CPU from reset (w/ the same bus)
<shapr>
I wish I had a way to power up the BBB remotely
<shapr>
"shutdown -t 0 now" is great when I want to sleep without the blue LEDs
<shapr>
but
<ZipCPU>
Why not just turn the blue lights off?
<maikmerten>
I had a BBB myself a few years back. There was a way to turn of the LED.
<maikmerten>
*off
* ZipCPU
just found his code for controlling the LED's manually.
<shapr>
ZipCPU: is your code on github?
<ZipCPU>
No
<shapr>
aw
<ZipCPU>
Not for the BBB
<ZipCPU>
I think the "right" answer is to write a "0" into each of the LED controllers in /sys
<shapr>
I'll try that
<shapr>
so I want to do all my dev on my laptop, but would like to be able to send resulting bitstreams to the beaglebone, and I like the idea of tcp/ip connections giving me status info
<ZipCPU>
Absolutely!
<ZipCPU>
What kind of control connection do you have between your BBB and the FPGA? Is it a serial port, or something else?
<shapr>
"Programming is done by SPI interface. BeagleWire uses second BeagleBone SPI port. SPI frequency should be between 1Mhz and 25Mhz."
<shapr>
is that just about dumping a bitstream onto the FPGA?
<ZipCPU>
I built something similar to a SPI port once for a debugging bus
<ZipCPU>
SPI isn't that hard to work with.
<ZipCPU>
Yes
<ZipCPU>
Roughly
<ZipCPU>
But once you dump the bitstream onto the part, you then want to communicate with it (somehow)
<ZipCPU>
That's usually done over a separate port
<shapr>
"For communication between FPGA and ARM, GPMC can be used. This is an easy and efficient solution. BeagleWire software repository has special components for it. You can just map your logic in BeagleBone memory."
<shapr>
does that count as the separate port?
<ZipCPU>
That would be ideal---you wouldn't even need a debugging bus with a straight memory interface into your FPGA
<shapr>
ZipCPU: when you describe a separate debugging interface, does that mean you have tools that scrape the bits of ram inside the FPGA itself and export those values over tcp/ip ?
<ZipCPU>
Yes, I can read and write both RAM and flash from within the FPGA using the debugging interface.
<ZipCPU>
I can also pull traces out of the design, and so debug what's going on within it.
<shapr>
from reading about GPMC, I think it can only read/write to the 32MB of ram on the beaglewire board
<ZipCPU>
Only?
<ZipCPU>
As in .... that's all?
<shapr>
I don't know
<ZipCPU>
My typical debugging bus implementation gives me access to 4BG of address space. I can use that for RAM, for flash, and ... for any other modules I wish to control within the fpga
<shapr>
I'm still stuck finding the unknown unknowns
<shapr>
but hey, the newbie post is helping
<shapr>
blinky first!
lutsabound has joined #yosys
kuldeep has joined #yosys
<shapr>
ZipCPU: do you use graphical oscilloscope style applications fed from your debugging data?
maikmerten has quit [Remote host closed the connection]
<ZipCPU>
Yes, I use gtkwave
<ZipCPU>
shapr
<shapr>
oh, good to know
<FL4SHK>
how much would the full commercial version of yosys cost if I only wanted one license?
<ZipCPU>
FL4SHK: To my knowledge, they haven't released the full pricing schedule yet --- they are still working on the license server
<FL4SHK>
oooh
<FL4SHK>
alright.
<ZipCPU>
That said, I remember something about being able to purchase hours on a cloud machine, buying a site license for 20 seats, and purchasing a site license in general.
<FL4SHK>
...20 seats is more than I can afford or need
<ZipCPU>
The hourly price as I recall might easily fit within your budget, as long as you had your ducks in a row first.
<shapr>
why would you want a commercial license for yosys?
<shapr>
I'm confused
<FL4SHK>
full SystemVerilog support
<ZipCPU>
shapr: The commercial version of yosys provides support for full System Verilog, the full SV assertion language, and even VHDL.
<FL4SHK>
the ability to skip this stupid translation step
<FL4SHK>
It's bad enough that Icarus Verilog doesn't support as much of SystemVerilog as I'd like, but the converter makes a number of things awkward, and some stuff impossible.
X-Scale has quit [Ping timeout: 244 seconds]
<sorear>
just be aware that they're targetting the market segment with money i.e. not you
<ZipCPU>
I know Verilator offers full SV support, but that's more for simulation than formal verification
<sorear>
comparable established tools are mid-6-figures for a seat license
<FL4SHK>
does it have to be a seat license?
<FL4SHK>
and no, I don't have money yet, but no reason I won't later
<sorear>
a cadence license costs as much as a decent house in most of the US
<shapr>
!!!!
<shapr>
wow
<ZipCPU>
sorear: I'm expecting yosys to be offered at less than $100k for multiple seats
<FL4SHK>
yeah, that too
<FL4SHK>
...I only want the one seat
<shapr>
holy crap, FPGA tools are pricey
<ZipCPU>
We'll see what the offer ends up at, once they publish it.
* ZipCPU
may be convinced to run batch proofs for his blog sponsors, provided the code is publicly available on github
<sorear>
my understanding is that high-level formal is something that only really exists in ASIC tools, which are 1-2 orders of magnitude pricier than FPGA tools
<FL4SHK>
sounds like that's not the case here.
<ZipCPU>
No, that is the case here ... at least in terms of capability
<FL4SHK>
Hm?
<ZipCPU>
yosys has been used for ASIC development for some time.
<sorear>
do we know if anyone other than the guy who maintains the qflow website has ever done it?
<FL4SHK>
...there's definitely other stuff I think I could do if I wanted more flexibility
<FL4SHK>
but at that point I'm making my own compiler
<FL4SHK>
don't have time for that yet.
<ZipCPU>
sorear: Yes. Many
<sorear>
i'm all for encouraging people to write good-quality vhdl and sv support for the open sector
* ZipCPU
has thought about adding full SVA support to yosys
<sorear>
presumably this is difficult since it hasn't been done already
<FL4SHK>
I'm honestly really tempted to make another HDL which just compiles to Verilog
<ZipCPU>
Why not add on to yosys' parser?
<FL4SHK>
that might be of interest
<ZipCPU>
It's open, and I'm sure the team would welcome improvements
<FL4SHK>
what exactly is the state of yosys versus whatever the commercial thing is?
<shapr>
due to my many contacts, I have information that implies that some of the largest tech companies have chosen clash-lang as the standard for their future FPGA designs
<FL4SHK>
oooh neat
<shapr>
FL4SHK: I'd be happy to help you with Haskell if you want
<ZipCPU>
But, seriously, it would make more sense to support a standard language, such as SystemVerilog, than it would to write your own.
<sorear>
there's also "SpinalHDL" which forked off chisel a while ago
<shapr>
sorear: what's the difference?
<shapr>
sorear: do you know of more?
<FL4SHK>
ZipCPU: yeah but making my own HDL would be fun anyway
<sorear>
don't recall if Dolu shows up here, i've seen him in ##openfpga and #riscv
<shapr>
Haskell has several, but clash-lang does the most out of the many Haskell options
<sorear>
shapr: uhhh if you look at the documentation there's a page comparing it to the chisel version it forked from, i don't really know beyond that
<shapr>
ok, cool
<FL4SHK>
let's see if chisel's stuff would let me do stuff like SystemVerilog interfaces
<ZipCPU>
To my knowledge, chisel doesn't haver a formal verification portion of the language
<FL4SHK>
that's not something that'd hinder me as long as it generates Verilog
<FL4SHK>
keep in mind that I've already been having to generate Verilog :P
<ZipCPU>
You haven't seen the Verilog code the chisel translator creates
<FL4SHK>
that's true!
<FL4SHK>
...okay then maybe I'm back to doing my own HDL
<ZipCPU>
You don't want to extend what yosys does for SV?
<FL4SHK>
that'd work fine
* ZipCPU
's CPU slows down as a trace grows beyond 2GB
<FL4SHK>
that might honestly be the easiest thing to do lol
<ZipCPU>
I figure the two easiest improvements would be to add |-> and |=> capability.
<FL4SHK>
I use things like SystemVerilog packages, enums, and structs
<FL4SHK>
frequently
<FL4SHK>
those are the main things I'd *need*, but SystemVerilog interfaces would be even better
<ZipCPU>
The fun part is that most of the parser forms have already written for you.
<FL4SHK>
do they use a parser generator?
<FL4SHK>
gosh I hope it's ANTLR
<ZipCPU>
You mean ... like bison?
<FL4SHK>
yeah but ANTLR is a lottttt nicer than bison
<FL4SHK>
and can do more
<FL4SHK>
It can generate a visitor base class thing
<FL4SHK>
almost all the assemblers I've written, I've used ANTLR for... made the job easier
<ZipCPU>
Looking over yosys/frontends/verilog/verilog_parser.y, it looks like yosys uses bison
<FL4SHK>
that's not bad then
<FL4SHK>
I've used bison before.
<ZipCPU>
You've also got an example of how to create the SystemVerilog constructs in the Verific source files
<FL4SHK>
shoot, now I wish I had more free time
<ZipCPU>
:D
<shapr>
FL4SHK: if you get into learning Haskell, I would be happy to show you many cool tricks