ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting July 27th
zignig has joined #nmigen
cr1901_modern has quit [Ping timeout: 246 seconds]
Degi has quit [Ping timeout: 246 seconds]
cr1901_modern has joined #nmigen
Degi has joined #nmigen
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #nmigen
Degi has quit [*.net *.split]
_whitelogger has joined #nmigen
futarisIRCcloud has quit [Ping timeout: 244 seconds]
mithro has quit [Ping timeout: 260 seconds]
mwk has joined #nmigen
trabucayre has joined #nmigen
anuejn has joined #nmigen
proteus-guy has joined #nmigen
agg has joined #nmigen
emily has joined #nmigen
miek has joined #nmigen
Lofty has joined #nmigen
samlittlewood has joined #nmigen
loxodes has joined #nmigen
XgF has joined #nmigen
_florent_ has joined #nmigen
ktemkin has joined #nmigen
key2 has joined #nmigen
levi has joined #nmigen
whitequark has joined #nmigen
smkz has joined #nmigen
esden has joined #nmigen
emily is now known as Guest80879
esden has joined #nmigen
esden has quit [Changing host]
Cynthia has joined #nmigen
lkcl has joined #nmigen
mithro has joined #nmigen
futarisIRCcloud has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
emeb has quit [Quit: Leaving.]
nurelin has joined #nmigen
cesar[m] has joined #nmigen
jfng has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
levi has quit [Quit: Connection closed for inactivity]
<awygle> i wonder if tilelink is a better choice than wishbone for an open source interconnect standard
jeanthom has joined #nmigen
_whitelogger has joined #nmigen
Asu has joined #nmigen
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
_whitelogger has joined #nmigen
* zignig looks for tilelink-links.
<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:
<cesar[m]> m.d.sync += shift_reg.eq(shift_reg[1:])
<cesar[m]> If you want a shift-in:
<cesar[m]> m.d.sync += shift_reg.eq(Cat(self.shift_reg[1:], shift_in))
<cesar[m]> If you want a shift-out:
<cesar[m]> m.d.comb += shift_out.eq(shift_reg[0])
<FL4SHK> my assembler is going well
<FL4SHK> I'm setting up support for variables
<FL4SHK> like, in memory
<FL4SHK> that is to say, at CPU runtime
<zignig> FL4SHK: i have been following ,but your python style is crypic to me , what are you building ?
<zignig> *cryptic, silly filgers
<FL4SHK> zignig: my Python style cryptic?
<FL4SHK> in what way?
<zignig> *fingers
<zignig> your code is cool, but it takes some time for me to GROK.
<zignig> what are you building?
<FL4SHK> I am building an assembler
<FL4SHK> I'm not sure why my code is cryptic
<FL4SHK> I get what you mean when you say it's cryptic
<FL4SHK> I just don't know the why
<zignig> that is because you are a freaky weirdo like me.
<zignig> :P
<zignig> what kid of CPU are you tring to build ? to what end?
<FL4SHK> I need a basic one at least
<FL4SHK> I haven't started much work on the CPU itself yet
<FL4SHK> My goal is to make a video game console
<FL4SHK> right now, I'm just kind of stuck on the assembler, though
<zignig> just substructure?
<FL4SHK> Huh?
<FL4SHK> What do you mean?
<zignig> I see you are getting underthings going with python, where are you heading ? CISC , RISC , FL4SHK_SPECIAL ?
<FL4SHK> everything I make is RISC of some sort
<zignig> how many bits of instructions ?
<FL4SHK> the LARs stuff I've worked on isn't quite a normal RISC but is definitely in the same style
<FL4SHK> Usually I go with either a 32-bit or 16-bit instruction word
<FL4SHK> Might need to go with a 64-bit instruction word for the bigggg computer I want to work on
<zignig> cool! with FPGA, you can do that !!
<FL4SHK> I do FPGA dev for a living nowadays
<FL4SHK> but I'm self taught, largely
* zignig is reducing friction on so ASM is low pain
<zignig> 16 bit instructuions . no verilog , pure python.
<FL4SHK> so I've got a problem... I need to essentially store `kwargs` inside of a dictionary
* zignig needs a rem cycle
<zignig> gnite FL4SHK
<FL4SHK> good night
<zignig> FL4SHK: wrap all your instruction in a named tuple and deal with it in post ;
* zignig heads to freshly washed bed sheets
emeb has joined #nmigen
<_whitenotifier-b> [nmigen-boards] whitequark commented on issue #89: [RFC] handling boards that are very similar -
<_whitenotifier-b> [nmigen-boards] whitequark edited a comment on issue #89: [RFC] handling boards that are very similar -
<DaKnig> is there a general "reduce" function?
<whitequark> that works on value bits, or?
<DaKnig> I want to make pop count thing, would be nice to just `reduce (operator plus, vecotr)` or something
<whitequark> nmigen values are python containers that contain, well, bits
<DaKnig> that works on the bits yeah
<whitequark> you can use functools.reduce
<whitequark> functools.reduce(operator.add, val) works
<DaKnig> btw how do you use operator.add in this context :)
<DaKnig> just a lambda?
<whitequark> >>> import operator,functools
<whitequark> >>> s = Signal(16)
<whitequark> >>> functools.reduce(operator.add, s)
<whitequark> >>> from nmigen import *
<whitequark> (+ (+ (+ (+ (+ (+ (+ (+ (+ (+ (+ (+ (+ (+ (+ (slice (sig s) 0:1) (slice (sig s) 1:2)) (slice (sig s) 2:3)) (slice (sig s) 3:4)) (slice (sig s) 4:5)) (slice (sig s) 5:6)) (slice (sig s) 6:7)) (slice (sig s) 7:8)) (slice (sig s) 8:9)) (slice (sig s) 9:10)) (slice (sig s) 10:11)) (slice (sig s) 11:12)) (slice (sig s) 12:13)) (slice (sig s) 13:14)) (slice (sig s) 14:15)) (slice (sig s) 15:16))
<DaKnig> I love the s expression view lol
<DaKnig> this is freaking ugly :)
<DaKnig> thanks
<vup> for this case you could also just use `sum`
<whitequark> oh, totally
<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?
<whitequark> not quite
<whitequark> nmigen.vendor.xilinx_7series invokes vivado
<whitequark> nmigen_boards.<your board> only invokes the programmer, nothing else
<DaKnig> aha.
<DaKnig> how does nmigen.vendor.xilinx_7series know which device I have?
<Lofty> The board describes the chip to it
<Lofty> It just passes that information along
<DaKnig> ok.
<DaKnig> thanks for the explanation
<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
<DaKnig> not nmigen
<DaKnig> arty_z7 is a board by diligent
<DaKnig> why dont you just take one of those arty files and change it to your own board?
<lkcl> DaKnig: yeh that seems to be the consensus
<lkcl> it's a good idea, a good start
<lkcl> i mean, this thing's a monster - it's USD 2500 (!)
<DaKnig> what does it have in connectivity?
<DaKnig> I assume the RAM is connected to the ARM side...
<DaKnig> HDMI? VGA?
<daveshah> I think the ZC706 has RAM both on the ARM side and FPGA side
<lkcl> DaKnig: it's a full-length PCIe card.
<daveshah> most of the higher end Zynq and Zynq UltraScale boards do that
<daveshah> zcu104 has a SODIMM on the FPGA side which is extra nice
<lkcl> i think it has... yes, RAM on both.
<lkcl> Advanced memory interface with 1GB DDR3 component memory and 1GB DDR3 SODIM Memory
<daveshah> yeah, looks like it has a SODIMM on the FPGA side so you can upgrade it too
<DaKnig> fancy
<lkcl> who was it a couple of days ago who said they also had one. i think it was awygle
<lkcl> DaKnig: :) it was one of the options for running a full RocketChip RV64GC SMP core, 3 years ago.
<lkcl> you can get a full 64 bit IEEE754 FPU on it with plenty of room for everything else
Asu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
<FL4SHK> I built a bfloat16 FPU once
<FL4SHK> with, well, round towards zero
<FL4SHK> that was the only rounding mode
Asu has quit [Quit: Konversation terminated!]
<FL4SHK> what is the nMigen stdio thing?
<FL4SHK> kind of interested in displaying things on my VGA Monitor
<FL4SHK> was going to just make a scope
<FL4SHK> but a stdio type thing would also work
smkz has quit [Quit: smkz]
<awygle> It was not me
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
_whitelogger has joined #nmigen
smkz has joined #nmigen