genii has quit [Quit: Welcome home, Mitch]
freemint has joined ##openfpga
OmniMancer has joined ##openfpga
Stary has quit [Ping timeout: 250 seconds]
Stary has joined ##openfpga
dh73 has quit [Quit: Leaving.]
ym has quit [Ping timeout: 265 seconds]
<tpw_rules> yes
<tpw_rules> with m.FSM("my_initial_state"): with m.State("my_initial_state"): m.d.comb += etc
freemint has quit [Ping timeout: 250 seconds]
nrossi has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
dh73 has joined ##openfpga
ym has joined ##openfpga
_whitelogger has joined ##openfpga
Bob_Dole has joined ##openfpga
_whitelogger has joined ##openfpga
davidw has joined ##openfpga
davidw is now known as Guest74185
david__ has quit [Ping timeout: 252 seconds]
dh73 has quit [Quit: Leaving.]
<ZirconiumX> On the other hand I'm pretty sure nMigen picks the first defined state as the default
<OmniMancer> daveshah: is the only reason you can include fixed connections because you know the full set of valid arcs apriori?
Guest74185 has quit [Read error: Connection reset by peer]
Bike has quit [Quit: Lost terminal]
<OmniMancer> is it common for not all interconnect wires to be connectable to all tile inputs?
<OmniMancer> I have started fuzzing routing pips
grantsmith has quit [Quit: ZNC -]
<daveshah> OmniMancer: Yes, although you should be able to add them through observation too
<daveshah> They are hard to avoid when you get to pnr
<daveshah> Yes, normally interconnect matrices are very sparse
<daveshah> Maybe 16 or 24 different possible drivers for a wire at most
grantsmith has joined ##openfpga
grantsmith has quit [Changing host]
grantsmith has joined ##openfpga
<azonenberg> OmniMancer: this is one of the key differences between CPLD-style crossbar interconnects and FPGA-style interconnects
<azonenberg> In a CPLD function block typically every signal can be connected to pretty much anywhere
<azonenberg> but you pay for that, they get huge and don't scale well
<azonenberg> Which is why nobody really uses that architecture anymore :p
<OmniMancer> so that is why CPLDs tend to be tiny compared to FPGAs?
<OmniMancer> daveshah: well for now I am just going to fuzz the generic names and sort out something to analytically add the fixed ones later
<daveshah> That makes sense
<OmniMancer> Yea I see about 23 possible drivers from the interconnect
<OmniMancer> I suspect there are some drivers from local outputs too
<OmniMancer> The up/down seems different from the left/right too
<OmniMancer> I will also need to try some different tiles
Zorix has quit [Ping timeout: 246 seconds]
<daveshah> 23 sounds about right
<daveshah> The last one might be a constant driver
<daveshah> Up/down will definitely be different from left/right
<OmniMancer> it might have a gnd source as well I have not added that to the list of sources it tries
<OmniMancer> How are connecting the q output of a slice to it's a input, say, handled?
<OmniMancer> I should possibly give my VM more cores
freemint has joined ##openfpga
<OmniMancer> This will take quite some time to check all the signals I have it going through
<OmniMancer> Still have to figure out how IOBs work
<daveshah> In general some q/f signals are an option for some LUT inputs
<OmniMancer> especially since there doesn't seem to be obvious space for any config for the ones on the top or bottom
<daveshah> There may not be that much of a pattern
<daveshah> I guess the config is squeezed in somewhere
<daveshah> IO don't need that many bits
<OmniMancer> I have a suspicion it might be a column somewhere in the middle
<OmniMancer> there are 2 columns on either side which are definitely not routing or PLBs
Zorix has joined ##openfpga
<pepijndevos> Has anyone made the digilent I2S2 pmod working with Yosys? Their examples are all xilinx stuff
<pepijndevos> Not too hard to port, but... maybe someone already did it
<OmniMancer> pepijndevos: How did you go about the bitstream documentation for the gowin part?
<pepijndevos> OmniMancer, at a friend now, can talk about that another time
<pepijndevos> we're trying to get this pmod to work with a bit of code we wrote two year ago, but not as east as hoped
<OmniMancer> I will ask at another time then :)
<OmniMancer> good luck with the PMod
<OmniMancer> pepijndevos: congrats on picorv32 running
<pepijndevos> :)
<OmniMancer> Is there any documentation on the nextpnr generic backend?
Jybz has joined ##openfpga
<OmniMancer> hmmm some bits implied by the CEMUX seem to be also used for routing the CE signals
<daveshah> That sounds just like ECP5
<daveshah> The inversion is separate
<daveshah> But driving with a constant is really part of the routing mux
<OmniMancer> The inversion?
<daveshah> search for CEMUX
<OmniMancer> ah, I suspect it has an invert bit and then can route gnd or the ce signal
<daveshah> F5B10 is a separate inversion bit
<OmniMancer> yea
<daveshah> F48B1 F54B0 connect it to 1
<daveshah> but can be inverted for 0
<daveshah> F48B1 F54B0 are part of the routing bits
<OmniMancer> ah
<OmniMancer> is that why the 0s are left out for when it's the CE signal?
<daveshah> ?
Asu has joined ##openfpga
<OmniMancer> When the CEMUX is set to CE it just has -s
ormiret has quit [Ping timeout: 264 seconds]
<daveshah> Oh yeah
<daveshah> that's correct
ormiret has joined ##openfpga
<daveshah> otherwise it would conflict with the routing bits
<OmniMancer> conflict how?
<daveshah> well it would be trying to set F48B1 F54B0 to 0
<OmniMancer> I think the Anlogic one is the same, except the constant is 0 not 1
<daveshah> but one of these might need to be set to 1 for routing
<daveshah> that makes sense
<OmniMancer> oh because the MUXes are 2-hot
<daveshah> yeah
<daveshah> it's quite a common pattern
<OmniMancer> yea I think I am seeing 2hot muxes here too
<daveshah> pedantically; it's two cascaded 1-hot muxes rather than 2-hot (imo 2-hot means any two bits can be set)
<OmniMancer> ah
<daveshah> Xilinx xc7 uses a similar pattern (UltraScale+ is 1-hot only)
<OmniMancer> does the cascading increase latency?
<daveshah> Yes, slightly, at the expense of reducing the number of routing bits and total transistor count
<daveshah> *at the advantage
<OmniMancer> mhmmm
<OmniMancer> Interestingly the CE lines seem only able to be connected to 2 tile interconnect wires
<daveshah> There might be some global to CE routing too
<OmniMancer> Yea I suspect it can be fed from gclks
<OmniMancer> but that will need more fuzzing later
<OmniMancer> at some point the ADC will need fuzzing
<pepijndevos> ERROR: PLL 'm_clk.uut' couldn't be placed anywhere, no suitable BEL found. Did you mean to use a PAD PLL ?
<pepijndevos> This is just with the output from icepll on the ice40
<pepijndevos> icebreaker, so up5k i guess
<daveshah> You need to use a _PAD PLL for the icebreaker
<pepijndevos> Can I tell icepll to do that?
<daveshah> I don't think so
<pepijndevos> Hmm, so I need to hunt down some datasheet for the correct names
<daveshah> Or just copy this example
<pepijndevos> ty
<pepijndevos> would maybe be useful to add an option to icepll
<daveshah> yeah
<pepijndevos> what is even an icestorm_lc and why do I have one *facepalm*
<pepijndevos> ERROR: failed to place cell '[1]_SB_DFFE_Q_11_D_SB_LUT4_O_I2_SB_LUT4_O_I2_SB_LUT4_O_I2_SB_LUT4_O_I3_SB_LUT4_O_I2_SB_LUT4_O_I2_SB_LUT4_O_LC' of type 'ICESTORM_LC'
<pepijndevos> Oh, thats just a logic slice?
<pepijndevos> ICESTORM_LC: 6112/ 5280 115%
<daveshah> Yeah
<pepijndevos> Time to break out the ECP5 I guess
<pepijndevos> such a simple code though, why is it using so much logic...
<OmniMancer> daveshah: is there a particular reason for the generic slice not supporting simultaneous LUT and FF outputs?
<pepijndevos> OmniMancer, I changed this a few days ago haha
<daveshah> OmniMancer: not all FPGAs allow that
<daveshah> eg iCE40
<OmniMancer> 24 bit signals are not exactly small?
<OmniMancer> daveshah: and how do you model only having them separate?
<daveshah> It now has separate outputs as pepijndevos said
<daveshah> He fixed that for gowin
<daveshah> But still only allows one at to be used at a time
<pepijndevos> Wait? what stops you frm using both?
<OmniMancer> pepijndevos: is your gowin generic backend available anywhere to look at?
<daveshah> The packer doesn't allow that because some FPGAs don't support that
<daveshah> I don't think the packer will ever use both at present?
<OmniMancer> is there any way to allow that being a setting?
<pepijndevos> daveshah, thought I had this morning: could you "infer" a packer from something like techmap files to once and for all solve "but my fpga has ..." for the generic slice
<daveshah> Nice idea but in practice becomes a massive PITA with non trivial constraints
<daveshah> The real arches tend to do minimal packing anyway
<daveshah> And be much more reliant on validity checks
<pepijndevos> right...
<daveshah> But if you want to try that approach, feel free to have a look at VPR
<pepijndevos> OmniMancer, uh, public release will be Soon(tm), but I could add you to the private repo maybe, if you give me a gitlab account name
<OmniMancer> pepijndevos I do not think I have a gitlab account yet
<sorear> which arch is OmniMancer working on?
<OmniMancer> Anlogic Eagle
<OmniMancer> sorear: ^^
<OmniMancer> is it common to have no clock inputs from the general interconnect?
<daveshah> No
<daveshah> But there might be some special general to clock routing, I suppose
freemint has quit [Ping timeout: 245 seconds]
<OmniMancer> Ah, yes that may be the case
<OmniMancer> but I will have to figure out how to convince the tools to produce such a thing to see how to provoke it
<sorear> is there a documentation deliverable for these projects?
<OmniMancer> sorear: as in?
<sorear> which has pretty pictures AND a lot of text
<sorear> symbiflow has the pretty tables but nobody's written the necessary explainers yet so it's still quite opaque
<OmniMancer> presumably there is eventually
<sorear> that was a question for you. do you plan to write human-readable, self-contained documentation for Anlogic FPGAs which I can read and, in principle, produce tools from
<OmniMancer> I will see how far I get
<OmniMancer> would adding the explainers for the symbiflow style tables to the symbiflow documentation be helpful?
<sorear> I don’t think I’ve seen them so I can’t say
Jybz has quit [Quit: Konversation terminated!]
<OmniMancer> I suppose my question is do you want documentation that consists of an explanation of how every piece works?
<sorear> If a piece exists and we know facts about it, those facts should be documented
<OmniMancer> many "facts" are currently conjecture inferred from naming of inputs in the vendor tools and the way the vendor tools behave
<sorear> I want there to be as much information on Ultrascale at 70 as there is about random early mainframes at 70. People will care about this, don’t let the knowledge die with you
<OmniMancer> daveshah: how do you determine which signals are used for the extra ones needed for distributed RAM?
<sorear> that was maybe a little harsh, sorry, I’m in a mood
<OmniMancer> Its okay, it just feels like a rather large burden...
ym has quit [Remote host closed the connection]
<OmniMancer> daveshah: in ECP5 what can the ends of the 6 span wires be connected to?
Bike has joined ##openfpga
jemk has quit [Remote host closed the connection]
jemk has joined ##openfpga
jemk is now known as Guest310
Guest310 has quit [Quit: leaving]
jemk_ has joined ##openfpga
jemk_ is now known as jemk
Guest74185 has joined ##openfpga
Guest74185 has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
davidthings has quit [Remote host closed the connection]
davidthings has joined ##openfpga
<pepijndevos[m]> Is there anywhere I can read about different bus standards? I hear ZipCPU talking about axi all the time, but also axi lite, this other thing I forgot. Just ran into axi stream?? I've not really used any bus at all
davidw has joined ##openfpga
davidw is now known as Guest30695
davidthings has quit [Read error: Connection reset by peer]
david__ has joined ##openfpga
Guest30695 has quit [Read error: Connection reset by peer]
<ZirconiumX> pepijndevos[m]: There are two main bus standards for you to google. AXI - used by mostly commercial silicon, and Wishbone - used mostly by opencores stuff
david__ has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
cr1901_modern has quit [Quit: Leaving.]
davidthings has quit [Remote host closed the connection]
davidthings has joined ##openfpga
zino has quit [Quit: Leaving]
david__ has joined ##openfpga
davidthings has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
Maya-sama has joined ##openfpga
hackkitten has quit [Ping timeout: 246 seconds]
<mwk> pepijndevos[m]: axi stream is what the axi bus (lite or otherwise) is made of
<mwk> you have 6 or so streams involved in a bus
<mwk> write request, write data, write reply, read request, read data, read reply IIRC
<whitequark> oooh, I finally understand it
<whitequark> I thought that was such a weird design...
<mwk> whitequark: ?
<mwk> axi?
<whitequark> axi yeah
<hackerfoo> AXI Stream is just a ready/valid stream. AXI is built pretty straightforward from streams, but full AXI supprts tagging with an ID to support multiple transactions.
<hackerfoo> So I
<hackerfoo> So I'm working on natively implementing AXI-lite in my language, which has natural support for ready/valid streams.
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` has joined ##openfpga
<hackerfoo> Rather than writing a bridge in Verilog.
X-Scale` is now known as X-Scale
<pepijndevos> wooow okay
<pepijndevos> So AXI is 6 times these data/ready/busy/done/whatever "stream" lines
<mwk> ready and valid
<mwk> 6 times, yes
<mwk> axi lite has fewer IIRC
<mwk> ready/valid is a pretty elegant thing btw
* mwk likes
<whitequark> ready/valid will be a core part of nmigen, yeah
<mwk> whitequark: oh, nice
<mwk> hm
<mwk> I need to finally have a look at that
* mwk adds "learn nmigen" to her todo
<pepijndevos> And what about Wishbone?
<mwk> oh, wishbone is much simpler
<pepijndevos> But actually I think my real question is more... in which scenarios should I be using a bus?
<mwk> axi is really stream-oriented and made for heavy pipelining
<mwk> while wishbone is dead simple and has one outstanding transaction
<TD-Linux> axi stream by itself is also how at least xilinx likes to expose accelerators etc on zynq. they have an axi dma peripheral that can read/write to axi streams
<whitequark> wishbone is also kind of pretty awful
<whitequark> it's usable just fine for really simple peripherals but even if you want just pipelining it gets really gnarly
<mwk> pepijndevos: any scenario when you want something to be doing random access to something else's memory or registers
<mwk> esp. when you have multiple clients
<ZipCPU> whitequark: That might depend upon which wishbone standard you are using
<mwk> and depending on your use case, the bus may range in complexity all the way from some dead simple arbiter to fullblown AXI
<ZipCPU> The B4 standard includes a "pipelined" option that pipelines much like AXI does
<whitequark> ZipCPU: yes, I know
<pepijndevos> And is this in any way related to LiteX and/or FuseSoC, or completely orthogonal? Just some other names I've seen being thrown around that I should maybe look into more...
<mwk> AXI/wishbone are bus *interfaces*
<whitequark> ZipCPU: I remember that I looked at it really closely a few weeks ago and found it not especially well designed
<mwk> liteX / fusesoc are actual *circuits* that use them inside
<whitequark> while writing integration code for nMigen
<mwk> (not sure which bus they use, but they definitely use something, everyone does)
<whitequark> I don't remember the exact details and I'm busy with something else so I'd rather not spend a hour with the spec again
<ZipCPU> Really? I'd be curious to hear what problems you found
<ZipCPU> Ah, oh, sorry
<ZipCPU> I'd still love to hear it sometime
<whitequark> I'll make sure to discuss this with you next time I find myself looking at it
<ZipCPU> Thanks!
<ZipCPU> pepijndevos: When do you need a bus? When communicating with anything that looks or acts like a memory
<whitequark> ZipCPU: oh, I remember at least one issue
<ZipCPU> Cool! What?
<whitequark> ZipCPU: look at section 5.1
<ZipCPU> B3 or B4?
* ZipCPU opens B4
<whitequark> B4.
<pepijndevos> Ah, that's a useful criteria, and explains why I have not used it much so far... not many things in my world look like memory. *Shared* memory I assume though, because just one module having its own BRAM seems waste of time to give it a bus.
<whitequark> so, it essentially says that ACK_O terminates a bus cycle. so far so good.
<whitequark> but it does not say whether ERR_O and RTY_O terminate a cycle.
<pie_> you sunk my battleship
<ZipCPU> whitequark: Ok, you are confusing the classic mode with the pipeline mode
<ZipCPU> Section 5.1 is about bridging between the two
<whitequark> am I?
<ZipCPU> Yes
<whitequark> does the pipelined mode not have ERR_O and RTY_O?
<ZipCPU> In classic mode, the ACK|ERR|RTY ends the bus cycle
<ZipCPU> In pipelined mode, the transaction completes with ACK|ERR|RTY, but you might have other transactions in the pipeline that will remain ongoing
<ZipCPU> You can also terminate a transaction before ACK|ERR|RTY by dropping CYC
<whitequark> where does the spec say that in pipelined mode the transaction completes with ERR|RTY?
<ZipCPU> You know I mean one beat of the transaction, right?
<whitequark> yes
<ZipCPU> Every beat gets a response of either ERR|RTY|ACK
<whitequark> I understand what you're saying
<whitequark> my problem is that the spec doesn't actually say this anywhere
<whitequark> it only mentions ACK
<whitequark> and their sample HDL code for converting classic<>pipelined is incorrect, if a transaction terminates with ERR|RTY|ACK
<ZipCPU> Let's try this: imagine ERR|RTY|ACK is equivalent to the AXI-lite (BVALID & BREADY)|(RVALID&RREADY)
<whitequark> I think you misunderstand my complaint
<whitequark> I also have common sense, and I can interpret whatever the spec omits according to that
<ZipCPU> Perhaps
<whitequark> I *shouldn't have to*.
<ZipCPU> As in, I might be misunderstanding your complaint
<whitequark> it should clearly explain the semantics of ERR|RTY|ACK.
<whitequark> as it is, it actually never says *anywhere* that RTY terminates a cycle.
<tpw_rules> ZipCPU: re wishbone pipelined, is it correct to say that for as long as CYC is asserted, one of (ERR, RTY, ACK) must be asserted exactly once for every clock cycle that STB is asserted?
<whitequark> I just searched it again to be sure.
<ZipCPU> ... for every clock cycle that STB && !STALL
<tpw_rules> i mean well e.g. if you error then all the future transactions are cancelled
<whitequark> yes, that's another aspect the spec doesn't actually explain
<ZipCPU> tpw_rules: That's certainly how I do it: ERR cancels everything on going
<ZipCPU> That's not necessarily in the spec, that's how I implement the spec
<ZipCPU> The spec does state that there should be one ERR|RTY|ACK for every (STB&!STALL)
<ZipCPU> It also says that the bus cycle can be terminated early (IIRC) by lowering CYC
<ZipCPU> whitequark: This confusion was one of those reasons why I wrote a set of formal properties for WB
<whitequark> ZipCPU: yes. IMO every bus should come with a formal specification, which takes precedence over the text.
<ZipCPU> :D
<whitequark> but if it does not, then the informal specification should at least be clear and unambiguous
<whitequark> the Wishbone B4 specification is not, which is why I have said that it is poorly designed / written.
<whitequark> (well, one of the reasons)
<ZipCPU> So it sounds like your issue is with the specificity of the text
<whitequark> this specific issue, yes.
<ZipCPU> I'll admit that, on my first ORCONF trip, that was one of the issues I wanted to discuss
<ZipCPU> My solution was to add definition where the text wasn't clear
<whitequark> in fact, I have initially implemented ERR|RTY behavior incorrectly (according to your explanation) in nMigen-SoC
<ZipCPU> For example, the text doesn't plainly state that if (STB) assert(CYC); You have to dig for that one.
<whitequark> but I thought that it is too ambiguous and just removed the implementation completely
<whitequark> as it turns out, that was the right thing to do
<ZipCPU> Feel free to use my formal properties to know if something works or doesn't
* ZipCPU doesn't use the RTY signal
<whitequark> I think I'll make ergonomics of formal properties a focus for nMigen 0.3, and integrate properties for some busses
<ZipCPU> WB and AXI-lite are easy. Avalon isn't that hard either.
<ZipCPU> AXI is a @#$@*& to get right
<whitequark> I can see that.
<ZipCPU> I have formal property sets for all of the above. Let me encourage you to use them.
<whitequark> do you think they can be distributed as a part of nMigen, eventually?
<ZipCPU> All but AXI, yes
<whitequark> nMigen uses a 2-clause BSD license.
<tpw_rules> ZipCPU: where in the world are you? dicussions came up with a friend about bringing you over
<pie_> ZipCPU: try to think back to when you werent an expert? :P
<ZipCPU> USA--not all that far out of DC, but far enough to be in horse country
<ZipCPU> After slaughtering our geese, we still have turkey's in the backyard
<pie_> something is probably wrong if whitequark makes a mistake in implementation from spec >.>
<tpw_rules> oh ok that's not horrendously far
<whitequark> I write bugs all the time.
<whitequark> I'm not particularly better at programming than most people.
<tpw_rules> *grimace/grin emoji*
<pie_> hm :p i dont wish to contest that
<pie_> but you do have a lot of experience
<ZipCPU> Heheh ... that's one of the reasons why I like formal in the first place. It makes it easier to double check your work
<whitequark> more persistent and focused, yes. though that comes with a cost.
<ZipCPU> pie_: You might be surprised at how little experience I actually have ... ;)
<pie_> ok fine ill just be quiet :p
<pie_> im just trying to say if a domain specialist cant get it right easily something is fucky
<whitequark> in fact it's exactly *because* I make mistakes all the time, I have so much interest in better language design and formal methods
<pie_> unless the inherent complexity is high, in which case ok sure
<pie_> whitequark: hard agree
<whitequark> also, my domain is compilers, not digital logic
<pie_> i cant tell
<pie_> :p
<ZipCPU> I am certainly not a domain specialist on AXI.... I only recently started working with it
<ZipCPU> (December, 2018 was my first formally verified AXI-lite design)
<pie_> (compilers are cool though, *wistful sigh*)
<whitequark> ironically, that could be why you're finding bugs in AXI designs from major companies
<whitequark> well, a part of the reason
<pie_> also yeah i wish specs came with formal models you could test stuff against and whatever
<whitequark> experienced people can end up brushing aside the brokenness they grew up (professionally) with
<pie_> im in the space of being interested in formal stuff but having not much of an idea how to practically use it in software dev
<whitequark> "oh, that's just how things always were"
<pie_> other than fighting with haskell and scratching my head about theorem provers
<pie_> whitequark: im young and it seems really easy to get stuck in something akin to that mindset
<whitequark> well, SVA is like easy mode for formal, compared to most other tools
<pie_> SVA?
<whitequark> (SVA is much much easier to use than, say, Kami)
<whitequark> SystemVerilog Assertions
* ZipCPU isn't young, but only has about 4yrs of intense experience with FPGAs
<whitequark> a sub-language of SV that lets you state formal properties
<whitequark> ZipCPU: that's probably similar to the entirety of my FPGA experience. maybe a bit more than that
<whitequark> and for the longest time I wasn't very serious about it
<pie_> oh @ systemverilog assertions
Zorix has quit [Ping timeout: 245 seconds]
Zorix has joined ##openfpga
rombik_su has joined ##openfpga
Asu has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
Maya-sama is now known as Miyu
Miyu is now known as hackkitten
dh73 has joined ##openfpga
awordnot has quit [Ping timeout: 245 seconds]
awordnot has joined ##openfpga
kbob has joined ##openfpga
kbob is now known as Guest13541
Guest13541 is now known as kernlbob
<kernlbob> Can anyone explain the relation between nMigen Resources and Records?
nrossi has quit [Quit: Connection closed for inactivity]
david__ has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
<whitequark> a Resource is a way to describe board pins in a structured way
<whitequark> if you request a Resource (by its name), the platform returns a Record that is connected to those pins in the way you request
davidw has joined ##openfpga
davidw is now known as Guest15525
davidthings has quit [Read error: Connection reset by peer]
Guest15525 has quit [Read error: Connection reset by peer]
rombik_su has quit [Ping timeout: 265 seconds]
Guest15525 has joined ##openfpga
egg has quit [Disconnected by services]
oeuf has joined ##openfpga
dh73 has quit [Quit: Leaving.]
freemint has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 276 seconds]
dh73 has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
<kernlbob> Is a Record unidirectional? Would it be wrong to put the three lines of a SPI interface into a Record?
<kernlbob> (Four if you don't forget ~CS)
rohitksingh has joined ##openfpga
Asu has quit [Remote host closed the connection]