<sorear>
it is _a_ open source interconnect standard; not sure how well it scales up and down
<zignig>
with a skim read of the spec... It looks pretty complex, state machines with opcodes at every interface.
<zignig>
that said , one thing did jump out at me. "TileLink is designed to be deadlock-free by construction", hooray !
<zignig>
althoug 6 data channels for a full bus would be a little phat.
<sorear>
Yeah they learned that lesson the hard way
<zignig>
awygle: have you considered using a SLIP link ? :P
<zignig>
sorear: what nmigen thing are you making at the moment ?
<sorear>
I was at the 2016 winter RISC-V workshop, Chris Celio was there with a MPW of BOOMv1 running a shell, he had to reset the thing every 15 minutes because the TileLink 1 L2 cache reliably locked up after a trillion cycles (of course you can never catch that in sim)
<zignig>
sorear: trillion cycle BSOD ! .
<zignig>
erk
<sorear>
(the code in rocket used to be "tilelink" and "tilelink2", idk exactly how the version numbers match up, but I know TL got completely redesigned after that incident)
<sorear>
zignig: none atm, I think I joined for glasgow reasons
<zignig>
and rightly so, it's not like they kept on releasing broken processors after a whole pile of look ahead and cache busting errors were found.
* zignig
needs to save some spendoolies for a glasgow.
Asu has joined #nmigen
<lkcl>
FL4SHK: ppm i *think* is temperature stability related. i've seen a circuit for a 6-bit DAC (for VGA) that used a 74 series buffer IC and then just some 75R -> 18K series resistors in each. they were 0.5% tolerance. it works really well.
<awygle>
it's either tilelink or I invent my own bus called BagelBus which is just WB4 but fully specified and with conformance tests
<awygle>
coming in 2023, released at Smoking Crater Conference outside the ruins of Las Vegas
<lkcl>
awygle: we need something beyond what WB can provide, as well. WB is what i term a "take-it-or-leave-it" contract type. where AXI4 (and others) have the ability to support "House Contract of Sale" protocols (3 phases: Offer, Exchange, Complete)
<lkcl>
"take-it-or-leave-it" means that *right now*, in this transaction, the *only* options are: "indicate success" or "indicate failure". yes-or-no.
<awygle>
yeah I remember you talking about that before, but I think something light like wb has value even if it doesn't cover the whole design space.
<lkcl>
"House Contract of Sale" has the Offer Phase, "*IF* i were to ask you to perform this write, *WOULD* it succeed, please tell me that"
<lkcl>
awygle: absolutely it does
<awygle>
but it has to be fully specified and have a way to verify conformance
<lkcl>
the problem comes when you want to try to use it for SMP. or parallel (speculative) behaviour. etc.
<zignig>
awygle: bagelbus ? nice name ;)
<awygle>
wishbone was a beagle, beagle sounds like bagel
<lkcl>
most peripherals (the main use of WB) are of the "take-it-or-leave-it" type.
<lkcl>
and for I/O you really do not want anything else.
<awygle>
I have zero interest in Linux capable microprocessors on FPGAs so the wb weight class is what I care about
<awygle>
I do recognize the needs of that community and hope tilelink or something like it fills those needs
<lkcl>
it would indeed be nice: the only slightly annoying thing is that converters tend to introduce latency
<zignig>
I recall a token ring style bus from a fpga OS, although the source evades me at the moment.
<zignig>
it was compact and pretty cool.
<lkcl>
awygle, btw, if you're going to be doing Formal Correctness Proofs of Wishbone, and what you're doing could be used by LibreSOC, we could arrange some NLNet donations for that.
* zignig
invokes zipcpu for Formal Correctnessness. <handwave>
<lkcl>
or, if you wanted to "have a go" at writing a Formal Proof for existing code (nmigen-soc, other) that we're using, then move on to writing your own WB4 implementation and leveraging the experience gained to write a better Formal Proof for *your* implementation, i'd be fine with that, too
<lkcl>
zignig: lol
<awygle>
zignig: was that Jan Grey's hoplite
<lkcl>
i like dan gisselquist's work :)
<awygle>
lkcl: interesting and worth considering. it's 3:30am tho here so...
<zignig>
oh yes, he is interesting person... and very ... specific.
<awygle>
I need sleep
<awygle>
Goodnight
<zignig>
awygle: gnite your awesomeness !
* zignig
arms himself with a large coffee to continue battling the register allocator.
jeanthom has quit [Ping timeout: 240 seconds]
<lkcl>
awygle, ooo been there. night
* zignig
has basic blocks and reentrant regsiters.
* zignig
happy dance
<zignig>
take that you 16bit metamorph.
<cesar[m]>
DaKnig: Regarding shift registers, I'd implement it as:
<DaKnig>
would it be translated into a tree-sum thing?
<DaKnig>
I have no idea what this is called
<DaKnig>
logarithmic time add
<whitequark>
the short answer is no, abc would have to optimize it
<whitequark>
which is why we perhaps should have a popcount operator or something
<whitequark>
it's just very niche
<whitequark>
we have .reduce_or() already, might have .reduce_add()
<DaKnig>
maybe `tree_reduce` or somehting like that
<DaKnig>
?
<DaKnig>
that takes a function as a first parameter
<whitequark>
possibly
<whitequark>
it's not clear that we actually need it
<DaKnig>
... I dont think I understand the tools in the process in my case. I put in some nmigen code, it calls yosys? outputs verilog? and vivado synths it? or does it just p&r?
<DaKnig>
does abc work at all in that flow? can I expect optimizations from yosys?
<whitequark>
no, if you don't synthesize with yosys, the existence of yosys is purely an implementation detail
<DaKnig>
what does yosys do then?
<whitequark>
it's just an overly complicated (in some ways) or far simpler (in some others) way to convert nmigen code to verilog
<whitequark>
i only actually use read_ilang;write_verilog
<whitequark>
there's no optimization going on
<DaKnig>
so nmigen generates ilang?
<DaKnig>
is that simpler to do?
<Lofty>
I thought nMigen ran some proc passes?
<whitequark>
nmigen maps very straightforwardly to ilang
<whitequark>
Lofty: it does but that's only because write_verilog has weird requirements for the input
<whitequark>
they aren't actually doing anything
<whitequark>
well
<whitequark>
any semantic transformation
<whitequark>
they just shuffle bits around a bit
<whitequark>
i could probably tweak the ilang backend a bit and make that unnecessary
<whitequark>
it also runs memory_collect for the same reason
<DaKnig>
then nmigen-boards passes the results , in my case, to vivado to synth and p&r, then flashes it to the device with another project, is that right?
<DaKnig>
I wonder if it would get better results if it passes through some optimizations with abc, then back to vivado. vivado is known for producing crap code in some cases...
<Lofty>
I...kinda doubt it
<Lofty>
You're vastly overestimating the capabilities of ABC :P
<DaKnig>
probably
<whitequark>
vivado uses abc
<whitequark>
well... most likely does, or at least did when i looked at it
<whitequark>
there are abc symbols in it, that's for sure
<Lofty>
I mean, based on that kind of thing Quartus still uses VPR
<Lofty>
I do hope they moved beyond simulated annealing though
<whitequark>
hmm
<daveshah>
Yeah Vivado definitely uses abc9
<daveshah>
It does more optimisations of its own though, compared to Yosys
<daveshah>
eg retiming doesn't use abc
<whitequark>
what does 9 in abc9 mean, anyway
<daveshah>
It's a version number
<daveshah>
9 is where the new xaig stuff was introduced
<daveshah>
It also introduces a whole new set of commands that are prefixed by & for some reason
<whitequark>
is there abc8
<daveshah>
Presumably, but I doubt it involves such a substantial new interface
<whitequark>
okay i see
<lkcl>
whitequark, daveshah: someone else on here mentioned they have a zc706, and i was sponsored with one as well.
<lkcl>
what would it take - what would be needed - to add it to nmigen boards?
<lkcl>
it's a zync 7045 processor rather than a 7020
<lkcl>
300k LUT monster
<DaKnig>
you just define your own class thing with all the params of the system, the resources, connectors, ... the name of the board, a function for flashing the bitstream...
<d1b2>
<Hedge> You can probably start by taking an existing zync target and change the chip that it refers to
<d1b2>
<Hedge> And then match the PinOut
<lkcl>
dlb2, Hedge: i was just thinking that - found the art_z7 which is a zynq 7020
<DaKnig>
the synth and p&r tools care about gate count