sgstair has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
sgstair has joined ##openfpga
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
<pie__> hackerfoo: oh huh.
<pie__> hackerfoo: didnt know symbiflow was a google project?
rohitksingh has quit [Ping timeout: 276 seconds]
mickdermack has joined ##openfpga
uovo has joined ##openfpga
oeuf has quit [Ping timeout: 268 seconds]
<hackerfoo> pie__: It's a project to which Google contributes.
<GenTooMan> hackerfoo Google has a huge engineering staff so would not be a surprise.
<kc8apf> It's a project started at Google
ZipCPU has quit [Quit: ZNC 1.6.4 -]
zng has quit [Quit: ZNC 1.7.2 -]
zng has joined ##openfpga
ZipCPU has joined ##openfpga
ZipCPU|Alt has joined ##openfpga
ZipCPU|Alt has quit [Client Quit]
freemint has quit [Ping timeout: 264 seconds]
m_w has quit [Quit: leaving]
pie__ has quit [Ping timeout: 245 seconds]
<hackerfoo> Other contributors are welcome, though. Development is done in the open through public GitHub repos and a public IRC channel, and there are many smaller tasks for people who can't work on the project full time.
Bike has quit [Quit: Lost terminal]
<hackerfoo> The team at Google is small (4 people), so any help is appreciated.
rohitksingh has joined ##openfpga
pie_ has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
_whitelogger has joined ##openfpga
Jybz has joined ##openfpga
<pepijndevos[m]> Need to scroll back further later but this hls talk is really fascinating
<pepijndevos[m]> I has this course about DSP algorithms and it had all these retiming and scheduling algorithms, and I kept thinking there should be a way to use this power without something stupid like compiling c++ to hdl
<pepijndevos[m]> And it's the kind of innovation I am exited to see as a result from open source synthesis tools
pie_ has quit [Ping timeout: 276 seconds]
Jybz has quit [Quit: Konversation terminated!]
Miyu has joined ##openfpga
hackkitten has quit [Ping timeout: 276 seconds]
hackkitten has joined ##openfpga
Miyu has quit [Ping timeout: 265 seconds]
mkru has joined ##openfpga
emeb_mac has quit [Ping timeout: 240 seconds]
mkru has quit [Remote host closed the connection]
<azonenberg> hackerfoo: oh, that's public knowledge now?
<azonenberg> back in the early days it was a kind of "black project" with people laundering commits through private gmail addresses etc because google didnt want to risk getting sued or something
<azonenberg> people were on company time working on the project but in a deniable fashion
OmniMancer has joined ##openfpga
pie_ has joined ##openfpga
hackkitten has quit [Quit: Leaving]
hackkitten has joined ##openfpga
<daveshah> Pretty sure this is the first time it's been mentioned in public
ym has joined ##openfpga
<hackerfoo> You can easily check which GitHub users are contributing Google-owned code because they should be part of the Google organization on GitHub.
<hackerfoo> We use our personal email because because it seems more in the spirit of open source, and some of us had existing open source work.
<daveshah> Mmm, I've had some trouble with demarcating work and non-work code; with my former employer taking a lot of credit for stuff I did in my own time and somewhat against the will of my employer
<hackerfoo> Google has a process for formally approving personal projects, which I followed for PoprC.
<hackerfoo> And there's some protection under California law, but it has a giant hole in it, so it's best to get approval in writing.
<daveshah> It's not so much credit as a legal sense as much as behaving as if it's their project when in many ways it isn't
<hackerfoo> There's not much you can do about that in a nice way, if they aren't willing to talk about it.
<daveshah> Indeed, I have left them anyway now for a few other reasons
<emily> lol, typical google NDA stealth on display
<emily> what happened to people being afraid to even reference codenames?
vup2 has quit [Quit: No Ping reply in 210 seconds.]
TD-Linux has quit [Ping timeout: 245 seconds]
GityUpNow has quit [Ping timeout: 245 seconds]
grantsmith has quit [Ping timeout: 245 seconds]
grantsmith has joined ##openfpga
grantsmith has quit [Changing host]
grantsmith has joined ##openfpga
linzhi-sonia has quit [Ping timeout: 245 seconds]
eightdot has quit [Ping timeout: 245 seconds]
vup has joined ##openfpga
TD-Linux has joined ##openfpga
linzhi-sonia has joined ##openfpga
eightdot has joined ##openfpga
pepijndevos has quit [Ping timeout: 240 seconds]
<hackerfoo> emily: SymbiFlow is a public project. No NDAs needed.
<hackerfoo> But I want to be clear that I don't speak for the company or the project.
pepijndevos has joined ##openfpga
<hackerfoo> I just want to promote it so we can get more contributors.
<hackerfoo> PoprC is NOT a Google project, and was started long before I joined Google.
<hackerfoo> I guess I promote PoprC mostly just because I like talking about it.
<nats`> hackerfoo, maybe changing the name one day will be a good idea :D
<nats`> I can't find anything on google even by adding fpga, hdl or language
<hackerfoo> It doesn't have a lot of users yet :)
<hackerfoo> My next goal is adding an AXI interface so I can put a bunch of functions written in Popr on an FPGA card in my computer and pipe data through them.
<nats`> just took a quick look is it a stack based language ?
<hackerfoo> Because that would be cooler than using LEDs and switches.
<hackerfoo> nats`: no, not really
<hackerfoo> It's concatenative, though, where concatenation is function composition.
<emily> not stack based but RPN, you could say
<hackerfoo> Only constants (including functions) can be named.
<hackerfoo> Yeah, it's postfix. I tried prefix, like Haskell, but it didn't work as well.
GityUpNow has joined ##openfpga
freemint has joined ##openfpga
<pepijndevos> hackerfoo, whoa, popr seems very interesting, will have to look at it later
<hackerfoo> pepijndevos: Thanks
<pepijndevos> This is some thing I made a while ago hehe
<pepijndevos> The idea that concatenative langugages are really funcional and can be statically typed rather than some stack blah really fascinates me
<pepijndevos> hackerfoo, specifically, this:
<pepijndevos> The idea that this would map nicely to HDL is something I have not considered
<hackerfoo> I think of each word as building a graph rather than manipulating a stack.
<pepijndevos> Right
<pepijndevos> Trying to remember what this Hadoop thing was that was basically very stream oriented
<hackerfoo> I was surprised how easy the IR was to convert to Verilog. In some ways it's easier than C.
<pepijndevos> Maybe Cascalog, Stork, or Spark, at least something stream oriented.
Asu has joined ##openfpga
Asu has left ##openfpga ["Konversation terminated!"]
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
cr1901_modern has quit [Ping timeout: 240 seconds]
genii has joined ##openfpga
<GenTooMan> sigh sometimes yosys can be very frustrating.
<ZirconiumX> GenTooMan: How os?
<ZirconiumX> *so
freeemint has joined ##openfpga
freemint has quit [Read error: Connection reset by peer]
<GenTooMan> It loves to optimize things but is too aggressive. This kind of troubles reminds me of the issue (2011-2013) in the optimizer in C/C++ ignoring the volatile keyword meaning and removing reads and writes that were required.
<emily> that "issue" in C++ has never gone away and volatile is being deprecated in the latest standard
<whitequark> the solution is obviously to not use verilog for anything
<ZirconiumX> I'm sure pepijndevos will be happy to hear that
<ZirconiumX> :P
<whitequark> i'm not sure vhdl is much better to be honest :p
<pepijndevos> I've not had any footnuke experiences with vhdl ;)
<whitequark> there are verilog programmers who don't have any such experience with verilog
<whitequark> you kinda have to go beyond n=1
<GenTooMan> whitequark that's why I have been working with nmigen instead.
<daveshah> ime, Yosys doesn't optimise enough for 50% of things and optimises too much away for the other 50%
<daveshah> Therefore it's perfect :p
<pepijndevos> Well, most behavior seems pretty sane, explicit, and well defined. Stuff like signedness, wire/register, sync/async, casting, where Verilog just silently does the oposite of what I want 9/10 times.
<whitequark> ok, let me rephrase
<whitequark> vhdl is much better than verilog in many ways, but i'm not sure if it's good enough
<pepijndevos> (not claiming vhdl is perfect)
<whitequark> then again being much better than verilog is such a low bar
<pepijndevos> Oh definetely. The number one reason I'm excited about open source synthesis is to have some innovation on the language font.
<whitequark> have i mentioned a cute idea i've had here?
<whitequark> being able to instantiate nmigen modules from verilog
<whitequark> (with yosys)
<ZirconiumX> nmigen is more or less a frontend for direct RTLIL
<pepijndevos> Uh... not knowing nmigen, what currently stops you from instantiation nmigen modules in verilog?
<mwk> pepijndevos: parametrization, basically
<whitequark> ^
<mwk> when you instantiate a parametrized module in verilog, yosys basically has to do something like template instantiation in c++
<mwk> inserts parameter values everywhere, unrolls generate-for loops, applies generate-if conditions
<ZirconiumX> Unrelated, but since daveshah is around: for the ECP5 a PFUMX is a mux for two LUT4s into a LUT5, and a L6MUX21 is a mux for two LUT5s into a LUT6, right?
<mwk> doing that with nmigen would require actually calling from yosys into nmigen
<whitequark> yep
<whitequark> i want to make it generic
<whitequark> something like a blackbox
<daveshah> ZirconiumX: Yes, although L6MUX21 is also used for LUT7s out of two LUT6s
<pepijndevos> So you'd basically add a `read_nmigen` command to yosys?
<whitequark> but yosys knows to call some filter process to get the body of the blackbox
<whitequark> nope
<whitequark> it would be driven entirely without yosys scripting
<whitequark> you'd say something like...
<ZirconiumX> daveshah: Cheers, and interesting to note
<mwk> pepijndevos: that also applies to vhdl and verilog interworking, btw
<mwk> you can get to fun stuff like vhdl in turn instantiating a verilog parametrized module
<whitequark> (* filter = "python3 -m nmigen.lib.fifo instantiate AsyncFIFO" *) AsyncFIFO #(width=16, depth=4) fifo (.read_clk(rc), .write_clk(wc), ...);
<pepijndevos> mwk, yea... I noticed. This is something ghdl does not do yet.
<mwk> so basically whatever manages the whole synthesis has to be able to call both frontends at will, until the whole thing converges
<daveshah> It gets even more fun when you consider hierarchical references too (not that Yosys supports them in most cases anyway)
<mwk> well, not converges, just ends...
<pepijndevos> Hmmm, I think it'd be nicer if it'd work the same as verilog modules, rather than filter magic. So you can just read_verilog and read_nmigen and read_vhdl all the things and have them refer to each other.
<whitequark> pepijndevos: that's impossible
<whitequark> (well, for read_nmigen)
<pepijndevos> why?
<whitequark> an nmigen design is just a bunch of python files
<whitequark> you can't extract even the list of modules from it
<whitequark> hmm
<whitequark> but maybe it *should* be possible
<whitequark> so we'd have something like
<whitequark> "this nmigen file is an entry point and it lists exactly the modules that can be instantiated if you read_nmigen it"
<whitequark> well, it'd be less "read_nmigen" and more like "read_rpc", right?
<mwk> hmm
<mwk> sounds nice
<whitequark> so if you do `read_rpc [cmdline]` then the command at [cmdline] is called and tells yosys which blackboxes it provides
<daveshah> Or, generate an RTLIL file with blackboxes and the process to call
<mwk> or "connect_rpc"? we're not really reading anything
<whitequark> daveshah: one problem with that is ports
<daveshah> That's managed for Verilog
<whitequark> i mean
<emily> it'd be nice to have a protocol based on JSON or protobufs or just... anything other than CLI back and forth, especially since there will be plenty of potential setup cost / optimization opportunities for multiple instantiations
<pepijndevos> I mean... a frontend takes source code an produces RTLIL, the fact that nmigen has to invoke Python to produce code doesn't seem that relevant?
<emily> tbh I'd rather it be more like read_nmigen for the user and that's defined in terms of some lower-level RPC thing the user doesn't have to think about
<whitequark> daveshah: does a yosys blackbox have to declare ports upfront?
<whitequark> i guess not
<whitequark> since you can use generate statements for that in verilog
<emily> pepijndevos: but nmigen modules can make decisions in Python code based on the things it's parameterized over
<mwk> I... think so?
<mwk> hm
<emily> pepijndevos: so an instantiation later in Verilog can cause the need to execute different Python code
<mwk> but that probably depends on where in the process you are, and I've only been working on the later step
<emily> it can't just be a one-pass thing
<mwk> s
<pepijndevos> emily, but as I understand, verilog also does this, where it produces rtlil but keeps the source around for if you initiate it later with different generics.
* mwk looks at hierarchy pass
<whitequark> pepijndevos: yosys has built-in knowledge of verilog
<whitequark> yosys does not have built-in knowledge of nmigen
<emily> ah, ok. I imagine that involves a lot of built-in knowhow about Verilog in Yosys though
<daveshah> whitequark: abstract modules from read_verilog -defer don't have ports
<emily> I doubt you could do something quite so fluent with CPython
<whitequark> when yosys needs to instantiate a verilog abstract module, it effectively calls into itself
<whitequark> and by definition it has more visibility into itself than into nmigen
<whitequark> daveshah: oh hm, what do they do have?
<pepijndevos> whitequark, so can't this built-in knowlege be extended for vhdl and nmigen and other things?
<daveshah> whitequark: literally just the module name (and src attribute)
<whitequark> pepijndevos: why should it be?
<daveshah> e.g. for picorv32.v
<daveshah> autoidx 1
<daveshah> attribute \src "picorv32.v:2809"
<daveshah> attribute \cells_not_processed 1
<daveshah> module $abstract\picorv32_wb
daveshah has quit [Excess Flood]
daveshah has joined ##openfpga
<pepijndevos> Seems like eventually you'd want to be able to cross-instantiate modules between languages
<whitequark> does yosys really have to intrinsically understand nmigen, clash, hardcaml, chisel, and whatever new hdl someone comes up with in a year?
<emily> whitequark: because C++ is a richer glue than shell and text IO
<emily> you could still make integration for a new language fairly lightweight and easy
<emily> but not needing to recompile yosys doesn't seem like an obvious goal
<daveshah> Yosys does already have plugin support
<emily> especially when glasgow is pinning specific yosys versions anyway
<daveshah> (using .so)
<whitequark> emily: glasgow is irrelevant here
<pepijndevos> whitequark, well, not built-in, but it'd be useful if a module could teach it about his
<whitequark> there won't be any verilog in glasgow
<pepijndevos> *this
<whitequark> only nmigen
<emily> I think using IPC of some sort of reasonable, but it should be some proper JSON protocol or something rather than a super ad-hoc "run this command line in the shell" thing.
<whitequark> emily: i mean, obviously? you still have to tell it where to find what it needs to run
<emily> or it could just communicate over a unix socket or whatever
<whitequark> yeah good luck doing that on windows
<emily> modulo portability concerns but my point is that one process for instantiation isn't going to scale very well
<emily> you kind of want one python process doing all the instantiations and not re-evaluating your whole design every time
<whitequark> yes
<whitequark> that's what i'm saying
<whitequark> 14:32 < whitequark> but maybe it *should* be possible
<whitequark> 14:32 < whitequark> so we'd have something like
<whitequark> 14:32 < whitequark> "this nmigen file is an entry point and it lists exactly the modules that can be instantiated if you read_nmigen it"
<whitequark> 14:33 < whitequark> well, it'd be less "read_nmigen" and more like "read_rpc", right?
<pepijndevos> btw, in my head I kind of pronounce nmigen like so
<whitequark> read_rpc -file /tmp/socket; read_rpc -file \\.\pipe\somepipe; read_rpc -command python3 -m nmigen whatever
<whitequark> or i guess connect_rpc yeah
<whitequark> i wonder if you could actually emulate this with tcl in vivado
<whitequark> i think you might be
<emily> pepijndevos: hahaha
<emily> note to self: nijmegen perfect confusing name for an nmigen-inspired HDL
<emily> I think whitequark would substantially prefer this to my previously floated suggestion of O'Migen for OCaml Migen.
<whitequark> ;w;
<whitequark> pepijndevos: i actually have no idea how to pronounce anything
<pepijndevos> Maybe I'll get over the python-embedded part of nmigen one day and try it... all these with blocks remind me of
<gruetzkopf> unix socket server would work in modern windows
<mwk> pepijndevos: what.... what have you done
<pepijndevos> XD
<GenTooMan> he didn't implement prolog horn clauses at least?
freeemint has quit [Ping timeout: 245 seconds]
<GenTooMan> I suppose how to pronounce nmigen would be "interesting" but it probably doesn't matter, ... yet. People aren't arguing over how to pronounce it just using it, which I think is a better use of time.
emeb has joined ##openfpga
<ZirconiumX> GenTooMan: migen rhymes with pigeon
<ZirconiumX> Milkymist Generator
<emily> I bet you say jif too.
<emeb> smidgen
<hackerfoo> About adding other support for other languages to Yosys, maybe it can be decomposed into a set of synthesis libraries, the same way LLVM isn't a single compiler, but a set of libraries for making compilers.
<hackerfoo> Then nmigen could work with these libraries through Python's FFI.
<daveshah> I believe Yosys can already be used like this
<daveshah> it can be built as a shared library and even used as a Python module (although the latter is a bit experimental)
<whitequark> this suggestion severely overestimates how easy it is to get FFI to work
<whitequark> LLVM's public interface is its C API (which I maintain), and it's still quite difficult to use it reliably
<whitequark> Yosys' public interface is RTLIL
<whitequark> so if you wanted Yosys to expose RTLIL programmaticaly to FFI, you'd have to define a C API on top of it
<emily> (this is why I was suggesting JSON RPC)
<whitequark> in case of LLVM, some people emit textual LLVM IR, but it doesn't have any guarantee of stability, whereas its C API does
<whitequark> in case of Yosys there is something of an opposite situation, it has an unstable C++ API, and stable-ish RTLIL
<hackerfoo> whitequark: RTLIL won't allow interaction between frontends, right?
<whitequark> define interaction
<hackerfoo> If it's just generating IR, that's easier than an API.
<hackerfoo> But you need something more if you want calls between frontends to pass parameters.
<whitequark> sure, so what i'm saying is that yosys can mediate it
<hackerfoo> What you really need is a sort of linker.
<whitequark> a linker for RTLIL is called `cat`
<hackerfoo> But I guess Python code could do anything with the parameters, hence iteration.
<whitequark> no, not at all, i don't think
<whitequark> look at how verilog abstract modules work
<hackerfoo> whitequark: it's called place and route.
<whitequark> shrug. you could make any sort of useless comparison with machine code toolchains. that's not insightful at all.
<hackerfoo> But I mean, the way that linkers can resolve symbolic locations.
<mwk> synthesis is not compilation
<whitequark> consider how abstract verilog modules work in yosys
<mwk> there are some parallels, but expecting everything to have an equivalent is just misleading yourself
<hackerfoo> Yeah, it's all really loose analogies. Let's stop.
<whitequark> yosys sees an instance -> yosys calls back into (its own) verilog frontend with a list of parameters -> yosys integrates the RTLIL returned by frontend back
<whitequark> now, consider how abstract (as in generic) nmigen modules would work in yosys
<mwk> but if you really want a parallel
<whitequark> yosys sees a (foreign, nmigen) instance -> yosys calls back into (foreign) nmigen frontend (via rpc) with a list of parameters -> yosys integrates the RTLIL returned by frontend back.
<mwk> imagine you want to use STL, the C++ library, from rust
<hackerfoo> The point is, if you could defer parameters to a deterministic solver (not Turing complete), it could be used by any language.
<mwk> a linker won't help you with that
<emily> mwk: I really don't want to imagine that.
<hackerfoo> And then just have nmigen emit constraints for the solver.
<whitequark> that's never going to work even for verilog
<whitequark> verilog elaboration isn't deterministic, you can read files.
<emily> hackerfoo: basically you're saying yosys should handle all the parameterisation in RTLIL?
<whitequark> or just use DPI-C
<emily> that's basically asking it to take up the mantle of a sufficient HDL itself
<emily> which is difficult when there's such a large degree of parameterization in existing designs that depends on executing real-world Python code etc. to resolve
<mwk> also, verilog parameter instantiation is probably Turing-complete alreadt
<emily> you'd then be in the business of compiling Python to something-like-generic-Verilog/VHDL
<emily> and at that point probably whitequark quits
<whitequark> oh, i've already considered and rejected that idea
<hackerfoo> emily: Yeah, I guess. Is solving for parameters really that complex? I haven't used migen/nmigen.
<whitequark> nonstarter
<emily> hackerfoo: a parameter is literally just a Python variable.
<emily> it could be a boolean or whatever.
<emily> you can branch on it.
<emily> you can branch on arbitrary Python computations made with it.
<emily> you'd have to translate arbitrary Python code to the IR, in other words.
<whitequark> in practice, it is common for nmigen parameters to e.g. influence port names and widths
<emily> so you can no longer be a simple Python eDSL
<hackerfoo> Sure, but does it need to be?
<emily> unless you want to completely change the architecture
<emily> and make nmigen a fundamentally different kind of language
<whitequark> it would be extremely challenging, if possible at all, to represent even that simple transformation in RTLIL
<emily> (also, in practice compiling arbitrary Python would be intractable.)
<whitequark> hackerfoo: don't forget that your architecture *doesn't even work for Verilog*
<whitequark> (and I assume VHDL too)
<whitequark> since you can do all these things just fine in plain old Verilog
<hackerfoo> I haven't used either much yet, so I haven't explored the dark corners, but I'm a big fan of simple languages.
<hackerfoo> And also provable termination (non-Turing complete subsets.)
<whitequark> simple languages can be nice if you never go outside of the domain they're tailored for
<mwk> hackerfoo: they you're not in luck
<whitequark> if you need something more complex, you're stuck in a puzzle, trying to express what you need
<emily> hackerfoo: I think any proposal which makes yosys unable to compile Verilog can be safely summarized as a non-starter.
<whitequark> i'm not interested in puzzles
<emily> you can feel free to create your own useless toolchain that works with no existing HDLs though
<mwk> since expanding verilog parametrized modules is already turing-complete
<hackerfoo> Yeah, I guess.
<hackerfoo> It's not something I plan to work on, so these are just half-thought out ideas.
<emily> don't get me wrong, I like provable termination too
<emily> but I don't think HDL parameterization is simple enough to delegate to a lowest-common-denominator IR.
<whitequark> ^
freeemint has joined ##openfpga
<emily> there are very flexible forms of metaprogramming being used extensively in practice for hardware
<daveshah> I do think it might be interesting to have something that can handle a _subset_ of what parametrisation allowed
<emily> and it's not too viable to reduce the power and flexibility of metaprogramming when the "target" (hardware) is so fundamentally weak and fixed at runtime
<daveshah> To allow formal verification of modules/map rules for all possible parameter values
<whitequark> yes
<mwk> hmm
<mwk> that would be nice
<whitequark> that is something i'm interested in
<whitequark> but i don't have the first clue of how to actually do it for real designs
<whitequark> and i suspect yosys will not be the place where this happens
<daveshah> `for` loops create a bit of a problem
<whitequark> you'd probably have to build a new FV-oriented toolchain from scratch
<emily> daveshah: yeah, a system that did try to solve these kinds of problem would be interesting
<emily> and tbh I'd love to work on one
<daveshah> The simplest hack would be turning parameters into extra "inputs" and just creating circuits for generates
<emily> but it's a large enough project in complexity and scope of unsolved problems that you'd hope you'd get a degree or grant or two out of it :v
<whitequark> daveshah: :/
<whitequark> i guess that could work
<emily> beautiful
<daveshah> Making width-generic implementations of operators would be "fun"
<emily> nand-oriented computing
<emily> RTLIL partial evaluator
<emily> lambdaRTLIL.
<whitequark> yeah
<whitequark> i feel like embedding "soemthing like RTLIL" in "something higher-order" would be nice
<emily> ok how about we embed "literal RTLIL" in "Tcl which is higher-order because you have strings"
<emily> think of the code reuse
<mwk> aaaaaaaaaa
<whitequark> ;w;
<emily> verilog parameterization is not strong enough to parameterize stuff by other circuits, right? i.e. in a higher-order way
<emily> nmigen, clash, etc. can do that but I guess it just won't be exposed to other languages
<mwk> emily: aaaaaaaaaaaa
<emily> I feel like those are the truly useful kinds of parameterization but interoperation for them sounds ... difficult.
<mwk> hm
<emily> mwk: what have you got against abstractions? ;w;
<mwk> oh wait, you mean like passing a module name to use as a submodule by your module?
<mwk> then not aaaaaa, that actually sounds very nice
<mwk> I thought you wanted to introspect the circuit contents from verilog...
<emily> :D
<emily> that *does* sound exciting but not quite what I was proposing, no
<emily> but yeah, more like being able to pass modules around
<emily> and even generate modules dynamically on the fly
<daveshah> You can do a lot of horrible things with the Yosys "scripts in wires" extension
<mwk> what exten... oh
<daveshah> `script -scriptwire`
Sellerie has quit [Quit: Ping timeout (120 seconds)]
<daveshah> Sadly it doesn't support here-documents (unlike usual Yosys scripts), so Verilog-in-Verilog isn't possible
<emily> ;w;
<emily> I just want to remind everyone that the International Criminal Court can read the logs to this channel.
<mwk> arrested for metaprogramming crimes?
freeemint has quit [Ping timeout: 264 seconds]
<GenTooMan> same goes with numerous spy agencies across the world.
Sellerie has joined ##openfpga
Sellerie has quit [Client Quit]
cr1901_modern has joined ##openfpga
<whitequark> aaaah
<emily> jesus.
OmniMancer has quit [Quit: Leaving.]
<Hoernchen> what kind of heresy is this?
<daveshah> Oh shit Yosys can execute shell scripts in commands, so perhaps we can do nmigen elaboration already
<daveshah> *shell commands
<daveshah> with `yosys -p "script -scriptwire top/runme" scriptwire.v`
<whitequark> this is fucking cursed
<mwk> now we just need support for the _yosys_autorun_ wire
<emily> daveshah: you know, nobody forced you to bring this into the world.
<emily> it's beautiful, but aren't you at least a little worried about it consuming everything else
<ZirconiumX> daveshah: is this holey beep level? :P
<daveshah> And really please don't run this snippet :)
<emily> alright, yosys is cancelled. everyone can pack up and go home
<whitequark> ahaha
<GenTooMan> it's not the end of the world, but you can see it from here...
freeemint has joined ##openfpga
mumptai has joined ##openfpga
ym has quit [Read error: Connection reset by peer]
* hackerfoo uploaded an image: Screenshot from 2019-09-24 10-10-23.png (79KB) < >
<hackerfoo> ^ A trace from `[dup] map` in Popr
<hackerfoo> `in0`/`out0` is the input/output. Notice that it toggles `in0_ready` but not `out0_valid`, so `[1 2 3...]` becomes `[1 1 2 2 3 3 ...]`
promach has joined ##openfpga
<hackerfoo> This is one kind of higher order function that even Haskell can't do.
<pepijndevos> hackerfoo, I'm trying to read your tutorial, but I don't really get the : False not [] pushl example
Sellerie has joined ##openfpga
<pepijndevos> Oh wait maybe I get it... so in the first example there is a False, and the push connects it to the not, and in the second example false not are already connects, and the whole connected thing gets connected into the block??
<pepijndevos> Now trying and failing at the swab example...
rohitksingh has joined ##openfpga
<pepijndevos> Every time I think I've got it I en up with no result at all, an error, or the same thing I started with. My basic approach is to pop them out of the box, swap them, and push them back...
<pepijndevos> But something about how things connect and in what order is broken in my head
<pepijndevos> : [A B] pull pull swap swap2 swap swap2 pushl pushl
<pepijndevos> [B A]
<pepijndevos> A thing of beaty -.-
Jybz has joined ##openfpga
<hackerfoo> pepijndevos: So, I changed the behavior of the repl since I wrote that.
<hackerfoo> Because people were failing on the `swab` exercise, but I guess I broke what I was trying to illustrate with `False not [] pushl`.
<hackerfoo> Type `:lim 1` to fix it.
<pepijndevos> So what changed?
<hackerfoo> The compiler doesn't reduce inside quotes, but the repl will reduce up to the limit, so that the printed result makes more sense.
<hackerfoo> To understand why the `:lim 1` behavior can be frustrating, try `[1 2 3] [+] map`
<pepijndevos> What does it mean to reduce inside quotes?
<pepijndevos> Eh... I get not result
<hackerfoo> The result is correct from PoprC's point of view, because a quote that isn't consumed (by taking it apart with ap) doesn't need to be computed.
<hackerfoo> You should get `[...]` with `:lim 1`, but `[2 3 4]` with a higher limit.
<pepijndevos> Eh nope, no result with anything I try
<hackerfoo> Oh, sorry: `[1 2 3] [1+] map`
<pepijndevos> ahhh
<pepijndevos> I still don't get how that relates to the other two examples...
<hackerfoo> Popr is aggressively lazy. You can think of quotes of holding suspended computations, possibly missing inputs.
<pepijndevos> What's the "correct" way to write swab?
<hackerfoo> *of quotes as
<hackerfoo> Any way that works should be equivalent.
rohitksingh has quit [Ping timeout: 245 seconds]
<hackerfoo> This is the case for most simple functions.
<pepijndevos> I just want to be blown away by your superior solution, compaerd to my dozen steps
<pepijndevos> Oh, need to go. Will catch up later.
rohitksingh has joined ##openfpga
<hackerfoo> You can check with `:bc swab`. You should get equivalent bytecode however you implement it.
<hackerfoo> I would just write `[swap] .`, but I didn't introduce `.` yet.
<hackerfoo> For fun, you can look at the Verilog it generates with `:cv swab`.
pie_ has quit [Ping timeout: 276 seconds]
Jybz has quit [Quit: Konversation terminated!]
<hackerfoo> A version not using `.` is `swab: popr swap popr swap pushl pushl`
<hackerfoo> Ah, but the bytecode isn't equivalent.
<hackerfoo> This is because they *are* different, try `[A B C]`.
<hackerfoo> So `swab` was not well specified.
<hackerfoo> So there's a bug and a half in my tutorial.
ym has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 265 seconds]
rohitksingh has joined ##openfpga
emeb_mac has joined ##openfpga
gnufan_home has joined ##openfpga
<TD-Linux> is there a recent comparison of diamond vs nextpnr anywhere? I personally don't care but might be handy for replying to haters
<whitequark> well, for one, you don't have to crack nextpnr to use it.
<TD-Linux> yeah tbh arguing about routing quality is a great position to be in. it means that all the more important problems are solved :)
rohitksingh has quit [Ping timeout: 265 seconds]
mumptai has quit [Quit: Verlassend]
freeemint has quit [Remote host closed the connection]
freeemint has joined ##openfpga
pepijndevos has quit [Ping timeout: 246 seconds]
gnufan_home has quit [Quit: Leaving.]
pepijndevos has joined ##openfpga
Hoernchen has quit [Ping timeout: 246 seconds]
Hoernchen has joined ##openfpga
feuerrot has quit [Ping timeout: 246 seconds]
feuerrot has joined ##openfpga
implr has quit [Ping timeout: 245 seconds]
implr has joined ##openfpga
Bike has joined ##openfpga