<tpb>
Title: Spidergon Networks On Chip · GitHub (at gist.github.com)
<promach>
Warning: Detected loop at \flit_data_output_are_valid[8] [0] in spidergon_top
PyroPeter has quit [Ping timeout: 250 seconds]
PyroPeter has joined #yosys
rohitksingh has quit [Ping timeout: 264 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 264 seconds]
dys has joined #yosys
jakobwenzel has joined #yosys
Cerpin has quit [Ping timeout: 272 seconds]
Cerpin has joined #yosys
Cerpin has quit [Ping timeout: 258 seconds]
Cerpin has joined #yosys
Cerpin has quit [Ping timeout: 268 seconds]
dys has quit [Ping timeout: 248 seconds]
dys has joined #yosys
emeb_mac has quit [Ping timeout: 245 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #yosys
pie_ has quit [Ping timeout: 252 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
adjtm_ has quit [Ping timeout: 248 seconds]
maikmerten has joined #yosys
<maikmerten>
hmmm... "Efinix Trion"... never heard of that FPGA before. Is now high-season for FPGA startups?
<maikmerten>
the higher-tier models have MIPI-PHY and (LP)DDR3... wonder if they're after machine vision
citypw has joined #yosys
pie_ has joined #yosys
jrolli has joined #yosys
emeb has joined #yosys
adjtm has joined #yosys
citypw has quit [Ping timeout: 272 seconds]
jakobwenzel has quit [Quit: jakobwenzel]
dys has quit [Ping timeout: 264 seconds]
dys has joined #yosys
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
SpaceCoaster has joined #yosys
Jybz has joined #yosys
maikmerten has quit [Remote host closed the connection]
smarter has quit [Quit: smarter]
smarter has joined #yosys
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 245 seconds]
Jybz has quit [Quit: Konversation terminated!]
shapr has joined #yosys
<shapr>
good afternoon!
<ZirconiumX>
Good evening
<shapr>
I recently acquired a fomu and I'd like to try installing something like j1a swapforth
<shapr>
should I expect yosys/icestorm/etc to build and work correctly straight out of the git repos?
<ZirconiumX>
shapr: The UP5K is a well-supported chip, so Yosys/nextpnr should work fine
<ZirconiumX>
Iceprog might, but I don't know too much about it
<shapr>
In that case, I'll stick with icestorm/yosys/nextpnr
* shapr
clones a bunch of things
emeb_mac has joined #yosys
<ZirconiumX>
nextpnr might take a while to build
<shapr>
I forget the order, icestorm -> yosys -> nextpnr?
<shapr>
I found instructions at one point
<ZirconiumX>
yosys -> nextpnr -> iceprog
<ZirconiumX>
yosys builds an optimised netlist, nextpnr turns that into a bitstream for the FPGA, iceprog uploads it to the FPGA
<ZirconiumX>
shapr: Don't expect anything earth-shatteringly fast with an ice40 though
<ZirconiumX>
But it's good for experiments
<emily>
I think shapr meant build order, in which case icestorm -> nextpnr can be parallel with yosys
<shapr>
emily: yes, thanks!
rohitksingh has joined #yosys
<emily>
ZirconiumX: you wouldn't complain about nextpnr build time if you had to do the pypy -> icestorm -> nextpnr bootstrap dance I did for nixpkgs updates.
<shapr>
I have several cores and a whole bunch of RAM on this laptop
<emily>
it takes like several hours pegging one core of your CPU to 100% with python2.7
<emily>
all so the icestorm and nextpnr builds can be faster for downstream users
<shapr>
I should really switch to nixOS *sigh*
<emily>
worse, the build wrapper makes it not even print the mandelbrot set it normally does on bootstrap :<
<ZirconiumX>
emily: fair point
<emily>
maybe I should just rewrite icestorm in Rust or something.
<shapr>
since I just got the fomu ~48 hours ago, I'm writing a blog post on how to get started loading micropython and bitstreams
<shapr>
step zero -> how to load the default bitstream when you screw up something
<shapr>
aw, icestorm build does not use many cores :-(
<emily>
again, python
* shapr
sighs
* shapr
shrugs
<emily>
I think it supports -jN though?
<shapr>
oh it does?!
<emily>
also pypy makes it faster.
* shapr
adds that to notes
<shapr>
probably won't make it into the blog post, because tools build once
<shapr>
emily: useful advice for package maintenance
<emily>
they only build once except when the releases are a year old and you need to use git to have support for a whole class of devices :p
<ZirconiumX>
<emily> maybe I should just rewrite icestorm in Rust or something. <--- Mistral's analysis tools are Rust
<emily>
ZirconiumX: ah, you're reverse-engineering Intel devices right? is that the codename?
<ZirconiumX>
Yup
<shapr>
I still don't know rust, but I've done some C++ and a bunch of Haskell, shouldn't be a big jump, right? :-D
<ZirconiumX>
It's a pun on Cyclone; the Mistral is a cold wind in the south of France
<ZirconiumX>
shapr: Both will help you, but you'll need to fight the borrow checker before you get Rust
<shapr>
I've heard scary stories
<emily>
shapr: the third key you'd need is linear logic.
<shapr>
ooh, I like linear logic
<ZirconiumX>
emily: Rust is affine though, right?
<shapr>
I kept thinking there must be some connection with the borrow checker
<shapr>
linear types hold values that must be used no more than once, and no less than once
<emily>
ZirconiumX: well, yeah. and it's more like it just has affine-logic-like substructural rules than it actually being a linear lambda calculus directly tbh
<emily>
shapr: affine = you can use (non-copiable) values at most once (it's ok to drop/deallocate them)
<shapr>
oh ok
<ZirconiumX>
The "at most" is actually "it's okay to forget them"
<emily>
(you can also take an exclusive mutable reference to such a value, *or* an arbitrary number of copiable immutable ones)
<shapr>
zero or one
<emily>
ZirconiumX: yeah... that wasn't true pre-1.0 though ;.;
* emily
would be happier with a true linear type system for a bunch of reasons
<shapr>
emily: I want to hear why!
<shapr>
reminds me a bit of Clean's uniqueness types
rohitksingh has quit [Ping timeout: 245 seconds]
<ZirconiumX>
Since you could build mem::forget in safe Rust, it was by definition a safe function
<shapr>
emily: do you have a blog or other social media account where you write about these things?
<ZirconiumX>
She's @lambdakitten on Twitter I think
<emily>
ZirconiumX: by that logic, any memory safety bug in a std function means that being memory unsafe is safe Rust
* shapr
follows
<emily>
I prefer to think of it as: the Rc implementation was unsafe
<emily>
ah, sorry for all the off-topic, though ^^;
<ZirconiumX>
emily: Which is why they get fixed rapidly :P
<emily>
it was seriously considered adding an automatic Leak trait and requiring it for Rc
<emily>
just dismissed for ergonomic reasons
<shapr>
I didn't get that
<ZirconiumX>
Things are only off-topic when people have valid on-topic things to talk about :P
<shapr>
ha, right
<shapr>
same for #haskell and other channels where I have ops
<ZirconiumX>
That's my rule
<emily>
shapr: as for reasons I'd like a linear type system: well, leak-freedom is a nice property when you can get it. I'd also prefer the more explicit rather than magic handling of destructors/deallocation that you'd get for that. it lets you add things like &out references, that you have to fill in with a value (think of e.g. placement-new in C++ (when you want to allocate an unboxed object in some already-existing space, like
<emily>
an element of a vector))
<shapr>
Are you saying that safe Rust can be used to build unsafe things? and the Leak trait was proposed for ... what's Rc ?
<emily>
this is all old irrelevant obsolete stuff :)
<tpb>
Title: The Pain Of Real Linear Types in Rust (at gankra.github.io)
<emily>
before Rust was stable, it was unsafe to leak objects without destructing them
<emily>
it is now considered safe to do so
<shapr>
oh, I see!
<emily>
because you could already construct reference cycles with e.g. reference counting
<shapr>
I have wondered how it's possible to build a cyclic data structure in Rust
<emily>
ZirconiumX: I forget if I've read the whole thing but I have talked to gankra on this topic a bit :)
<shapr>
or in any linear typed system
<emily>
ZirconiumX: tl;dr I'd change a lot of other things about Rust too and also I'll just point to "Ok having actually written this all out, it's better than I thought." :P
<ZirconiumX>
shapr: indexing
<emily>
shapr: either using indices into some heap rather than references or manually-checked unsafe code (the latter is used to implement most of the common things you'd find in a data structures text in the stdlib etc.)
<ZirconiumX>
If you have your data structure in an array and have each member hold an array index, you can build a data structure where stuff isn't owned
<emily>
which is a shame, but it still means a lot more of your code is getting checked for these rules than with C++ or something.
<ZirconiumX>
Rust has also grown a healthy(?) paranoia about any code which is marked `unsafe`
<emily>
ZirconiumX: (I came to Rust from Haskell also and was interested in substructural type systems before it, so I have a pretty biased FP-y angle on these things, admittedly. part of my reaction to checking out Rust after first seeing it years before when it was a lot less interesting and didn't have the borrow checker was "oh hey, someone finally made Linear ML: The Systems Language like I wanted")
<emily>
(ATS has had linear dependent types for years but nobody understands it so it doesn't count.)
<ZirconiumX>
I came to Rust from OCaml, not Haskell; I found OCaml *almost* there
<ZirconiumX>
Maybe if I'd been bothered enough to try F# instead I wouldn't be a Rustacean
<shapr>
whew, yosys build really does use all my cores
<ZirconiumX>
But yeah, Rust was designed by people who used ML and it shows :P
<shapr>
but not much memory
<emily>
it didn't show quite as much before niko basically got carte blanche to restructure the entire language :D
<tpb>
Title: GitHub - HackerFoo/poprc: A Compiler for the Popr Language (at github.com)
<ZirconiumX>
It says a lot to me that nMigen's native target is not Verilog but RTLIL, despite the obvious talent and skill of whitequark
<emily>
hackerfoo: oh, cool! I hadn't thought of concatenative linear languages before, heh
<emily>
seems like you might end up with some very, uh, elaborate mental state-tracking
<shapr>
I still haven't learned much verilog, even though ZipCPU spent a bunch of time helping me out
<ZirconiumX>
Verilog is a very tricky language
<hackerfoo>
The online version is currently a bit broken, but you can try it here with `:cv gcd`: http://hackerfoo.com/eval.html
<tpb>
Title: popr (at hackerfoo.com)
<emily>
(not being able to reasonably target RTL is another thing I don't like about Rust, though I can hardly blame them for not trying to go even lower-level than they already did ^^ )
<hackerfoo>
emily: It's not bad because concatenative languages make it easy to write very small functions.
<emily>
(pure call-by-name languages with some restrictions (like linear/affine typing) are actually well-suited to compilation to circuits, http://www.veritygos.org/ and https://clash-lang.org/ take advantage of this)
<tpb>
Title: Clash: Home (at clash-lang.org)
<shapr>
oh I do love clash
<shapr>
I have a clash t-shirt! I got it from christiaan!