<ZirconiumX>
Vinalon: the N means inverted, that is that a 1 gets pulled low
<ZirconiumX>
Yes
<Vinalon>
Cool, thanks - I'm trying to debug a SPI module without a logic analyzer, which involves some guesswork...
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
<Vinalon>
So, I've also been trying to shrink a design some, and I've noticed that the built-in syntaxes often use more LUTs than writing the logic out.
<Vinalon>
like, 'If/Elif' chains use fewer LUTs than switch cases, and 'x & 0b11' is usually more efficient than 'x[:1]'
<Vinalon>
er, 'x[:2]'...y'all know what I mean
<Vinalon>
Things like 'a.as_signed() < b.as_signed()' also use more than logic which checks the MSbit and performs conditional unsigned comparison.
<Vinalon>
Is there a concise explanation for that, or do I have to do a bunch of research on what sort of logic can fit into a 4-LUT?
<ZirconiumX>
Vinalon: there's a lot of cargo culting here, so I'll try to sort out what I can
<ZirconiumX>
"x & 0b11" and "x[:2]" should boil down to the same thing: take the last two bits of the wire.
<ZirconiumX>
If/Elif chains become a multiplexer tree
<ZirconiumX>
While Switch evaluates all values at the same time
<Vinalon>
ohh, interesting
<Vinalon>
It does sort of feel like some of the differences are from optimizations that the synthesizer makes, which probably aren't intuitive
<ZirconiumX>
"a.as_signed() < b.as_signed()" should actually produce better code (a single comparison, rather than a multiplexer and comparison)
<ZirconiumX>
And finally, think of a LUT-N as being any function of N variables
<ZirconiumX>
No matter how complex the expression is, if it's made of four variables, it will fit in a LUT4
<Vinalon>
I'm comparing the signed less-than to "((a[31] == b[31]) & (a < b)) | (a[31] > b[31])"
<Vinalon>
okay, so it's basically an arbitrary truth table? That makes sense, thanks
<ZirconiumX>
"lookup table"
<awygle>
"else" and "elif" almost feel like antipatterns tbh. i always double-check that i need them.
<ZirconiumX>
That's what LUT stands for, because it *is* an arbitrary truth table
<Vinalon>
Can the synthesizer re-use LUTs to perform similar functions in different places?
<awygle>
no. or, not without a lot of help - you'd basically have to manually tell it to. you'd know if you were doing it.
<ZirconiumX>
Not "similar", but "identical"
<ZirconiumX>
A & B & C & D != A & B & C & Q
futarisIRCcloud has joined #nmigen
<Vinalon>
okay, so if I have 'a & 0xF' in some places and 'a[:4]' in others, would I expect to see less resource usage by using one or the other everywhere?
<Vinalon>
(assuming they both have the same overhead, which might not be true)
<ZirconiumX>
I'd pick the more readable one, a[:4]
<Vinalon>
yeah, that's what I want to do, but sometimes it seems to inflate the design by 10s-100 LUTs
<ZirconiumX>
Fundamentally, FPGA synthesis is heuristics working on heuristics working on heuristics
<Vinalon>
I'm probably doing a lot wrong, though; a simple 32-bit softcore shouldn't take many more than 1000 LUTs, right?
<ZirconiumX>
If a pattern matches in one case but not another, then that can cascade into a notably different result
<Vinalon>
well anyways, it sounds like I shouldn't draw conclusions about efficiency from small differences that show up from building one design.
<ZirconiumX>
Vinalon: Minerva is 3K, PicoRV32 1400
<Vinalon>
Thanks for all the context!
<ZirconiumX>
Both are not particularly *complex* softcores
<ZirconiumX>
Vinalon: to be honest, as long as it fits on the chip your optimisation goal should predominantly be Fmax.
<Vinalon>
yeah, I was hoping to get down to 1500-2000 for something with no multiply/divide instructions, no I-cache, no mis-aligned memory access, etc
<ZirconiumX>
If you don't flatten the design in Yosys you get per-module resource usage statistics
<Vinalon>
yeah, I was hoping to get it small so that it would be possible to add a few peripherals and make small custom SoCs that fit in something cheap and hand-solderable
<ZirconiumX>
So synth_ice40 -noflatten
<Vinalon>
yeah, I tried that yesterday and saw that most of the usage comes from the ALU (~800), CSRs (~1200), and decoder/CPU/whatever (~1800)...I'm thinking of just re-doing the glue logic
<Vinalon>
thanks for the advice
<ZirconiumX>
WQ built an optimal ALU for Boneless
<ZirconiumX>
Or at least something that synthesises into it
<tpw_rules>
idk if it matters but i love boneless
<Vinalon>
neat - what's Boneless?
<tpw_rules>
which is why my pull request should be acccepted >:(
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<Vinalon>
oh cool, an open-source 16-bit CPU - that looks awesome
<Vinalon>
and there's even a block diagram in the ALU comments! Thanks for the tip
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Max SendQ exceeded]
FFY00 has joined #nmigen
FFY00 has quit [Max SendQ exceeded]
FFY00 has joined #nmigen
FFY00 has quit [Max SendQ exceeded]
FFY00 has joined #nmigen
FFY00 has quit [Max SendQ exceeded]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Max SendQ exceeded]
FFY00 has joined #nmigen
chipmuenk has joined #nmigen
<whitequark>
tpw_rules: sorry, i've been really overloaded lately
<whitequark>
your PR is sitting there in my inbox
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-3>
[nmigen] whitequark commented on issue #347: DriverConflict raised on entire signal when independently driving individual bits from submodules - https://git.io/JvNXn
<_whitenotifier-3>
[nmigen] whitequark closed issue #347: DriverConflict raised on entire signal when independently driving individual bits from submodules - https://git.io/JvNcf
<_whitenotifier-3>
[nmigen] whitequark commented on issue #347: DriverConflict raised on entire signal when independently driving individual bits from submodules - https://git.io/JvNXc
<whitequark>
tpw_rules: tbh if you rebase the PR so it doesn't have weird commits in it i could probably merge it much faster
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #nmigen
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
_whitelogger has joined #nmigen
Asu has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
electronic_eel_ has joined #nmigen
electronic_eel has quit [Ping timeout: 256 seconds]
Vinalon has quit [Ping timeout: 260 seconds]
<whitequark>
awygle, jfng, anyone else interested: something i've been thinking about lately is C++ blackboxes in cxxrtl
<whitequark>
currently the idea is that write_cxxrtl would write a header with some definitions like `struct bb_p_uart_phy : cxxrtl::blackbox { value<1> w_rdy; value<8> w_data; ... }` and your code would have to provide a few functions for those
<whitequark>
specifically, a static function that instantiates a subclass of the blackbox, implementing eval() and commit() for it
<whitequark>
any opinions?
<whitequark>
an option i also considered would be to *not* generate a class definition for the blackbox, just reference it and expect user code to provide it, then you don't have to have write_cxxrtl emit a header, which is a bit awkward
<whitequark>
but then you could get errors from deep in the guts of the generated code, which is bad
<whitequark>
and you'd have to rebuild the generated code each time, which is also bad
electronic_eel_ has quit [Ping timeout: 250 seconds]
electronic_eel has joined #nmigen
<jfng>
how would parameters be supported ? e.g. parity for the uart phy
<whitequark>
you would get the parameters and attributes as some sort of array in c++
<whitequark>
probably something like `static unique_ptr<bb_uart_phy> bb_uart_phy::create(std::string name, std::initializer_list<blackbox::parameter> parameters, std::initializer_list<blackbox::attribute> attributes)` would be the signature of the factory method
<tpw_rules>
whitequark: i hardly know how git works but i'll look into it
<whitequark>
tpw_rules: yeah which is why i offered to do it myself
proteus-guy has quit [Quit: Leaving]
proteus-guy has joined #nmigen
Vinalon has joined #nmigen
<awygle>
good morning
<awygle>
that seems pretty reasonable
<awygle>
i pretty strongly prefer generating a header, or at least writing out the class definition, to just referencing it
<whitequark>
right, ok
<whitequark>
the issue with generating a header (a minor one) is that yosys has a mode where it writes backend output to stdout
<whitequark>
which is pretty nice
Vinalon has quit [Remote host closed the connection]
Vinalon has joined #nmigen
<awygle>
that is nice
<awygle>
i'm not especially married to the header
<awygle>
i just don't want to be guessing class definitions
<whitequark>
i can just generate both
<whitequark>
depending on the mode
<whitequark>
i.e. `write_cxxrtl -header` requires specifying a filename
<whitequark>
but by default it writes out the definitions inline so you can do #include "gen.cc"
<awygle>
seems sensible
thinknok has joined #nmigen
Sarayan has quit [Ping timeout: 246 seconds]
Sarayan has joined #nmigen
<awygle>
reading ktemkin's luna example and realizing how very very little i know about usb...
<whitequark>
keep. it. that. way.
<awygle>
i mean
<awygle>
i'd be happy to
<awygle>
but also, i need to make a usb thing do things
<whitequark>
aw
<awygle>
nothing too exotic tho so hopefully i'll be able to just skim the surface instead of drowning
<awygle>
(actually on further reflection i don't know enough about usb even to know if it's exotic)
<whitequark>
i kind of want to ask but also kind of don't
<awygle>
can i do CDC-ADM, DFU, and Mass Storage on a single PHY? how does that work? lol
<whitequark>
yeah absolutely
<whitequark>
will the operating systems actually let you use all three? hell no
<MadHacker>
awygle: Absolutely. You may regret choosing to do so, however. :)
<awygle>
ruh roh
<adamgreig>
i have spent the whole day writing usb firmware for an stm32, i wish i was writing gateware or indeed anything not usb :p
<whitequark>
windows has bizarre issues related to composite usb devices
<whitequark>
you might have to write an inf file for it to work
<adamgreig>
"hmm my device already does these two features but i have a few endpoints left over, maybe i can add support for cmsis-dap"
<whitequark>
no signatures or kernel drivers, just an inf file
<MadHacker>
You can always lie and not be a composite device and instead literally pretend to be a hub with the devices plugged in. Which is totally what a composite device is supposed to be, but... yeah.
<whitequark>
you also HAVE to have a notification endpoint for CDC-ACM
<whitequark>
the spec oesn't require it and for a usb serial dongle you wan't
<whitequark>
but if you don't do it, linux will flat out reject your device no matter the rest
<whitequark>
this eats one interrupt endpoint you might have wanted to use for something else
<whitequark>
(it can't stall either, has to nak all the time)
<MadHacker>
awygle: I think you may be getting a general impression here of what USB's like.
<awygle>
MadHacker: yes lol
<awygle>
how many interrupt endpoints do you get?
<awygle>
is that a limited resource?
<whitequark>
as many as your PHY supports
<whitequark>
well
<whitequark>
not the PHY
<whitequark>
the MAC, though no one calls it that. the core that actually talks to the PHY for you
<adamgreig>
the "SIE" serial interface engine, if you ask some people
<whitequark>
"whatever is connected to your AHB"
<awygle>
the MAC is gateware? on the other side of e.g. ULPI from the PHY?
<whitequark>
yeah
<MadHacker>
Except you have a limit of 32 endpoints, except on a tuesday, when you have 31 unless it's a waning gibbous moon.
<awygle>
(oh my scenario is "fpga attached to phy via ulpi")
<whitequark>
wait, do you have gateware or a microcontroller?
<whitequark>
oh
<whitequark>
ok then you don't really have EP restrictions like that
FFY00 has quit [Remote host closed the connection]
<awygle>
the concept is to expose a serial port to the soft CPU on the FPGA for remote control stuff, expose an attached SD card as Mass Storage, and expose the FPGA flash over DFU. in decreasing order of both criticality and my confidence it is possible.
FFY00 has joined #nmigen
<whitequark>
that seems very much doable if you care only about linux
<whitequark>
if you add windows and macos to the equation, i'm not so sure anymore, it will likely be a pain in the ass
<whitequark>
i did very very similar things on the fx2
<awygle>
would it be possible to expose all three to linux and only one (e.g. the SD card) to windows+mac without undue PITAness?
<awygle>
or is that not how it works
<whitequark>
you don't know what OS you're talking to, and you can't know that
<whitequark>
besides trying to detect differences in the host stack or something
<whitequark>
well
<awygle>
i figured that but i thought i might be able to like, set a "primary" endpoint or something :shrug:
<whitequark>
you *sort of* can detect that
<whitequark>
haha no
<whitequark>
you can hide the other endpoints
<whitequark>
oh
<whitequark>
you know usb-modeswitch?
<awygle>
nno
<awygle>
i don't think so
<whitequark>
so, some lte modems pretend they're cd roms at first
<awygle>
ohhhh this weird thing. i had a flash drive that did this.
<whitequark>
you install the driver, it issues a control request, it switches to the actual modem thing
<MadHacker>
U3 flash drives do it, yep.
<whitequark>
this obviously does not work on linux
<whitequark>
well, usually
<whitequark>
some of them do it, i'm not sure how
<awygle>
adamgreig: thanks!
<plaes>
you can also have multiple USB endpoints
<whitequark>
multiple USB endpoints is fine in this case
<awygle>
i was having a hard time finding material between "it's Manchester encoding" and "here's how to write a Linux driver"
<whitequark>
the problem is the device descriptor
<whitequark>
i second adamgreig's suggestions, good material
<Vinalon>
adamgreig: slightly OT, but d'you know of any good resources on STM32 USB peripherals? The reference manuals are very sparse...
<adamgreig>
Vinalon: no it's all cursed, blame synopsys
<Vinalon>
okay, I'll go back to sacrificing goats. Thanks :)
<adamgreig>
i'm on a call rn but could give some pointers happily later
<adamgreig>
i have a fully from scratch usb firmware for stm32f0 working quite happily so know most of the cursed bits
<adamgreig>
Vinalon: 50% is the very weird CSRs which are different to everything else on an ST chip because they weren't made by ST
<Vinalon>
oh, cool - mostly I remember being confused by the endpoint numbering, since it seemed like they want you to configure each one unidirectionally but endpoint 0 is always supposed to be bidirectional channel
<adamgreig>
right, it has one register per endpoint address, and that register handles both directions
<whitequark>
control endpoints are so cursed
<whitequark>
you can have a control endpoint EP1
<whitequark>
but no software on earth will let you talk to it
<whitequark>
nor does it make any damn sense to have one
<adamgreig>
you eventually start to see why so many things just misuse HID
<adamgreig>
idk, control transfers are kinda nice though
<adamgreig>
i like just having a "this is a vendor request with this request type and this bit of data"
<adamgreig>
obviously you can just stick those on ep0 (and I do)
<adamgreig>
but it's a bit cursed that all interfaces share the same control endpoint since in theory the interfaces can be unrelated
<adamgreig>
s/control transfers/setup transfers/
<adamgreig>
no, I do mean control transfers x_x
<whitequark>
control transfers ought to have an unlimited number of stages imo
<whitequark>
or at least both "unlimited in" + "unlimited out"
<whitequark>
then they'd be actually useful
<Vinalon>
ohh, so the 'EA' bits set "endpoint addresses" as USB documentation talks about them, regardless of which 'epN' register is written to?
<adamgreig>
Vinalon: yes it's very cursed but that is correct
<Vinalon>
okay...then do you need to use two 'epN' registers with the same 'ea' address for bidirectional transfers?
<adamgreig>
"The USB peripheral behaves in an undefined way if multiple endpoints are enabled having the same endpoint number value." lol
<adamgreig>
no, each EPnR register handles both in and out transfers for its EA
<adamgreig>
you set STAT_TX and STAT_RX to tell it what to handshake (ack/nak/stall or disabled) to control what it will do for transfers in each direction
<Vinalon>
huh, good to know. It's been a few months since I was trying to figure it out with the WB series, but this'll help a lot when I get back around to that. Thank you!
<adamgreig>
np, feel free to ask about it whenever
<adamgreig>
whitequark: my configuration descriptor bundle is exactly 64 bytes so as to not have to implement multiple transfers, i too wish you had unlimited stages
<adamgreig>
can't wait to add one more endpoint
<MadHacker>
I nearly cried when mine (in gateware) passed that point and I had to do that too. :(
<whitequark>
adamgreig: ouch
<ktemkin>
usb is obsessed with threes, though
<adamgreig>
tbh i did implement longer control transfers but it was gross and kept a bunch of state where I didn't want it, so took it out when i realised i didn't quite need it
<adamgreig>
it's buried in my git history ready for the day i need a slightly longer string/descriptor/etc
<adamgreig>
ktemkin: threes?
<ktemkin>
if everything didn’t have a start, maybe a middle, and an end, how would you confuse all the protocol levels for it?
<adamgreig>
it certainly wouldn't do to make it simpler would it
<ktemkin>
adamgreig: control transfers have three stages so you can confuse the three parts of them with the three parts of transactions
<adamgreig>
i got into a mess by calling the zero-length write responses to control transfers 'ack' in my code
<adamgreig>
"transmit_ack"... oh, no
<ktemkin>
try writing a usb analyzer stack and having a sane view of what a packet is
<adamgreig>
i don't envy you that
<ktemkin>
it took me two iterations of my usb training just to get out of the habit of arbitrarily calling bundles of bytes in a stream “packets of data”
<ktemkin>
I wish they’d just have come up with a naming scheme that didn’t ascribe special meaning to words like “transaction” or “transfer”
<MadHacker>
Could be worse. I first learned to do USB on a PIC18F2550. Ew.
<adamgreig>
yep! i am implementing a higher-level protocol that uses transfers [usb] to transfer [dap protocol] a 'transfer' command [dap protocol] which contains multiple 'transfers' [swd/jtag]
<ktemkin>
I was advising a team of university students working on their capstone project; these poor students had a sponsor “customer” at the company down the street
<ktemkin>
little local business called IBM that had started over there and poisoned the groundwater with PCB solvents
<ktemkin>
(this was a decade or so ago when I was still university faculty)
<ktemkin>
and they wanted to get UART data from a PC to an FPGA as part of their final design
<ktemkin>
so I recommend they use a chip like an FTDI; this thing’s a one-off, so it doesn’t even make sense to save the dollar by writing firmware for a USB uC
<ktemkin>
their IBM “customer” lost his mind at the idea of using another chip to do USB, and at their public review in front of a room full of ~300 industry folks screamed about their “incompetence” for not just implementing USB on the FPGA, as “it’s just a simple state machine”
<adamgreig>
yiikes
<ktemkin>
pretty much every time I write any USB anything, I think back to that guy’s vehement assertion and wish I had his level of skill so I could skip all the damned fiddly bits and just bang out that simple USB fsm
<adamgreig>
probably just a couple lines of verilog, assuming you don't use any linebreaks
<ktemkin>
if you think about it, it’s just around a thousand LUT4s of constants
<adamgreig>
one really long hex number if you just write the bitstream by hand
<adamgreig>
presumably your students were just napping in the lecture that covered it
<Vinalon>
hehe - I once had a math teacher who liked to end lectures by shouting, "Simple is not the same as easy!"
<whitequark>
lol
<ZirconiumX>
NiGHTS> Quote #66: "Beware: it is impossible to simultaneously understand and appreciate USB." (added by ZirconiumX at 01:27 PM, February 14, 2018
<ZirconiumX>
It still holds true two years later
<Sarayan>
ktemkin: it's just serial anyway, how complicated can it be?
<whitequark>
one of my high school teachers thought D+ and D- were two parts of a dual simplex channel
<whitequark>
i tried to tell him he was wrong but i don't think it took
<Sarayan>
it's differential except when it isn't, right?
<whitequark>
to be fair, i'm pretty sure i was very wrong about undefined behavior in c++ back then (more wrong than he was, anyway)
<whitequark>
yes
<whitequark>
and more importantly, always half duplex
<ZirconiumX>
And generally "don't speak until spoken to", right?
<ZirconiumX>
i.e. there's no way for a device to initiate a transfer
<whitequark>
yes
<Sarayan>
so, easy, right?
<Sarayan>
you just have to answer messages when they come in. Simple state machine
<Sarayan>
damn, I've put sarcasm all over the channel again
<ktemkin>
Sarayan: I mean, there’s only two but values to deal with anyway, how hard can it be?
<ktemkin>
just J and K
<ktemkin>
*bit values
<whitequark>
what about SE0 *hides*
<ktemkin>
oh and sometimes SE0; so there’s thee bit values to worry about
<ktemkin>
nice and easy~
<thinknok>
y u no talk about SE1
<whitequark>
you know it's bad when your -sarcastic pretense of protocol- would work better than the actual thing
<ktemkin>
whitequark: I’m on mobile, I can’t type my joeks fast enough
<ktemkin>
~~anyway, I’m glad we have this nice, flexible protocol so we can finally cover the most common use cases like *squints at notes* ... wait, does this say “establish a pair of unidirectional connections that act like a UART”?~~
<whitequark>
lol
<Sarayan>
and for your next challenge, bluetooth pre-4.0 over usb!
<whitequark>
that's like going "this plague isn't enough, let's have a war, too"
<Vinalon>
Is there a high-speed differential UART-ish protocol? It'd be sort of cool to have a simple megabaud serial channel
<whitequark>
rs-422?
<Sarayan>
Vinalon: errr, ethernet? ;-)
<thinknok>
Vinalon, UART over LVDS ? :-)
<Sarayan>
more seriously, pci-e maybe?
<whitequark>
that's gigabaud not megabaud
<whitequark>
and impractical to use for a loooot of applications of usb
<whitequark>
you don't want a pci-e mouse
<Vinalon>
sounds like 'yes', then :)
<Sarayan>
well, you could have live video on your mouse
<whitequark>
you could dissipate enough watts in your mouse it'll be hot to touch, how about that
<Sarayan>
errr, self-heating mouse, nice
<awygle>
it'd even come with a _bonus_ connection for the power for the self-warming feature
<thinknok>
usb mouse with usb power delivery
<thinknok>
what a dream
<ktemkin>
pci-e is a great idea; I’ve always been disappointed that my mouse can’t bus master
<tpw_rules>
go back to ps/2 then
<whitequark>
ouch
<whitequark>
i mean
<whitequark>
strictly speaking
<whitequark>
the ps/2 mouse does bus master (the ps/2 bus)
<daveshah>
Serial mice are well and truly in the master category too :D
<ktemkin>
I mean, technically speaking, it’s pretty easy to bus master the USB bus, too
<ktemkin>
it just makes the host a bit unhappy
<daveshah>
bus mastering by exploiting the USB stack
<ktemkin>
that’s one way
<daveshah>
dma, the hard way
<ktemkin>
another is to find a hub that doesn’t mind forwarding packets to downstream peers, which exist
<ktemkin>
and then you just inject your own e.g token packets in the interpacket delay after a transaction
<ktemkin>
none of your peer devices know where those packets are coming from; so you’re the bus master now
<whitequark>
lol
<whitequark>
amazing
<whitequark>
that's horrifying
<whitequark>
i hate it
<ktemkin>
I know this works because I’ve done it by accident
<ktemkin>
and thanks, I try ^^
<ktemkin>
this discussion reminds me of back when I had to implement hypervisor stuff specifically for the Surface Pro, which only had two USB ports and a DisplayPort; and I wanted UART output
<ktemkin>
and the damned thing wouldn’t do the usual trick where you’d use frequency modulate data out the pc speaker (whose freq can be modified with a single portio write)
<whitequark>
aaaaa
<ktemkin>
I did terrible things via usb for a bit; and then gave up and just bitbanged UART using the GPIO in the intel GPU that are used for DDC, and just had UART on the DisplayPort
<whitequark>
aaaaaaaaaaaaaaaaaaaaaaaa
<ktemkin>
I’m pretty sure in a just world I’d have been banned from using a computer a long time ago
<ktemkin>
‘course, if you want to you can bingbang UART out the USB lines using the PORTSC1 register
<ktemkin>
or in
<ktemkin>
bits [11:10] are the state of D+/D-; and bits [19:16] let you e.g. force the lines to J or K
<ktemkin>
and you can do dual simplex by toggling the pull resistors rather than using those bits, if you don’t mind it being slow
thinknok has quit [Ping timeout: 272 seconds]
<MadHacker>
re: mice bus mastering, I'm half surprised no optical mice work by sending the image across the bus.
<MadHacker>
If the latency were better I suspect they would.
<Vinalon>
maybe you could run machine learning on the image and market it as an 'AEye' mouse :P
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 256 seconds]
Asuu has quit [Remote host closed the connection]
<Vinalon>
I have a question about the Wishbone bus implementation in nmigen-soc: I'd like to use something like a Decoder to switch between two bus Interfaces based on the address.
<Vinalon>
But when I use a Decoder, it seems like only the 'dat_r' value is actually switched depending on the address. The 'fanout' signals like 'cyc' and 'stb' get propagated to both buses regardless of address, and the 'fanin' signals like 'ack' get asserted if either bus asserts their signal.
<Vinalon>
Is there a way to switch all of the bus signals depending on address, so that fanout signals will only be sent to the addressed bus and fanin signals from every other bus will be ignored?