<awygle>
whitequark: can you check out that CI failure on -boards? it passes locally and i didn't touch the failing file...
<whitequark>
known issue, will be fixed by 0.3
<awygle>
o, k
<awygle>
hashtag not-my-fault
<whitequark>
uh... think you can remove the pullups? it doesn't sound like such an amazing idea to me that every I2C peripheral should check for those
<whitequark>
why would you connect them like that anyway? too many spare FPGA balls?
<awygle>
no clue
<whitequark>
right. so if anyone ever comes up with a good reason to do that, we can put them back, but for now i think it should just be a board quirk
<awygle>
so the A7 board file would just use Resource directly?
<whitequark>
yup, with the same layout as I2CResource (so basically exactly what was there before)
<awygle>
yup
<awygle>
copy
<whitequark>
resources are effectively "dynamically typed" so there's always this escape hatch
<whitequark>
have something nonstandard? just splay it out in the board file
<awygle>
my stupid brain wants to figure out the git invocation that does the moral equivalent of "git cherry-pick -p <file> ^HEAD"
<awygle>
which is in no way a valuable use of time
<whitequark>
uhh, moment
<whitequark>
git checkout HEAD^ <file> ?
<awygle>
ah that does work doesn't it
<awygle>
thanks
<whitequark>
tfw you have the exact kind of brain damage required to understand git
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JTxUf
<_whitenotifier-f>
[nmigen/nmigen] whitequark d0e5c2a - Deploying to gh-pages from @ 0ef01b128227d2e551268438ff8132f9a255f9a0 🚀
lkcl has quit [Ping timeout: 272 seconds]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
lkcl has joined #nmigen
PyroPeter has quit [Ping timeout: 272 seconds]
PyroPeter has joined #nmigen
jeanthom has joined #nmigen
Asu has quit [Remote host closed the connection]
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
FL4SHK has quit [Ping timeout: 246 seconds]
hell__ is now known as Th3Fanbus
Th3Fanbus is now known as hell__
FL4SHK has joined #nmigen
FL4SHK has quit [Ping timeout: 256 seconds]
FL4SHK has joined #nmigen
emeb has joined #nmigen
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
Asu has joined #nmigen
korken89 has joined #nmigen
<korken89>
Hi all! I have been looking for examples and resources describing how to use a Wishbone bus, where I'd like to try and make a simple slave SPI <-> RAM block test design. Does anyone here have any resource they'd recommend? I was not able to figure out how to use a wishbone bus by looking at the code in nmigen-soc.
<lkcl>
korken89: we use an SRAM in LibreSOC i had to track it down from a Harry Ho patch, 1 sec
<lkcl>
there's more complex versions kicking about if you need them, just ask
<korken89>
Hmm, there is no need to make like a master/arbiter that controls the bus? I thought Inteface was only for connecting to the bus, so to say.
<whitequark>
wishbone can work in a point-to-point fashion
<whitequark>
e.g. if you have only a single CPU and a single SRAM you don't need an arbiter
<lkcl>
korken89: as whitequark says. an arbiter will have wishbone slave interface(s) on one side and master(s) on the other
<korken89>
Ahh, makes sense
<lkcl>
acting like a big "Muxer" in effect but for the entire Wishbone protocol.
<korken89>
Looking at the impl you linked, it does not seem to say if it is a master or a slave?
<korken89>
How is this defined?
<lkcl>
it's something you have to "know"
<lkcl>
how would an SRAM "control" a CPU?
<lkcl>
would an SRAM ever, on its own initiative, send out "requests" to a CPU?
<lkcl>
why would it ever need to do that? it wouldn't, would it?
<lkcl>
therefore, by logical deduction, it must be the *receiver* of requests, i.e. be the WB slave.
<lkcl>
likewise typically peripherals will also be WB slaves.
<lkcl>
and it will be the CPU that, by being the one to make the "requests", is by definition the WB master
<lkcl>
however a big surprise for me recently was, Staf Verhaegen's C4M JTAG code is *also* a WB Master
<lkcl>
then realised, of course, the JTAG interface has incoming requests to read/write memory, those get converted to WB requests, therefore of course it is the WB master
<lkcl>
all these things you just have to "know" or logically deduce.
<sorear>
strongly typed hdls like chisel and bluespec have a concept of port direction
<lkcl>
sorear: oh yeah very good point. and also a royal pain :)
<whitequark>
nmigen definitely needs the concept of a port direction
<lkcl>
working with IIT Madras i had to interrupt their lead engineer for over an hour *a day* going over the bluespec Reference Manual
<sorear>
hopefully with a better name than what FIRRTL did :p
<lkcl>
whitequark: it was sort-of what Record "Direction" was supposed to be for, wasn't it?
<whitequark>
sorear: i believe i was the person who complained enough that they changed it
<lkcl>
or was that more of a holdover from migen?
<lkcl>
lol
<whitequark>
lkcl: yes and no. like many things in migen, record directions were both practically useful and with serious design flaws
<whitequark>
it took me a while to figure out that Record was trying to do two mutually incompatible things and the solution to that is just to split it into two entities
jeanthom has quit [Ping timeout: 260 seconds]
<korken89>
Thanks for the clarification :)
<korken89>
I need to start getting something going, I have never used a bus before more than autogenerated AXI buses in Vivado before, but I'm hoping that a conceptual knowledge of Wishbone will be enough for me to crate small buses :)
<lkcl>
whitequark: ah very cool.
<chipmuenk>
Just throwing in a quick question: A student of mine has problems with the implementation of I2C on an iCEBreaker board using nMigen. Are there some fundamental limitations or has he not dug deep enough :-) ?
<lkcl>
korken89: at some point you will want to read the WB4 spec, it's easy to find. it's not a necessary pre-requisite because it's a "spec" not a "tutorial with explanation" however it will help fill in some gaps at some point
<korken89>
Absolutely! I mean, from what I can see is if I put data and address on the bus and wait for the correct signals I see the same data appear at the desired address
<korken89>
Quite simple and exactly the level of abstraction I'm looking for
<korken89>
Probably won't get me max perf, but that is not a concern right now :)
<whitequark>
chipmuenk: definitely no such limitations
<whitequark>
Glasgow uses nMigen and it has several I2C cores that work just fine
Asuu has joined #nmigen
<_whitenotifier-f>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JTxp2
<awygle>
so ValueCastable doesn't override any of the operators
<awygle>
which makes sense, and is kind of the whole point
<awygle>
but is there a convenient way to get all that functionality back that we could somehow nudge users towards?
<whitequark>
can you be more specific about "that functionality"?
<awygle>
i imagine in a lot of cases, a ValueCastable wants __add__ to do the cast and use the resulting __add__ implementation
<awygle>
unless we never hit that path because it'll get casted by nmigen before that...
<whitequark>
even more specific? because there's several different paths we might end up hitting
<whitequark>
the most obvious example is that some ValueCastable users want __add__ to return a Value, and some want it to return the same ValueCastable
<awygle>
uhh i'm not sure i can be more specific right this second, i'd have to refresh my memory. this came up when i was trying to implement Record in terms of ValueCastable a while back, and i've dumped state on that at this point
<whitequark>
PackedStruct is the former, pepijndevos_' (iirc) fixed point thing is the latter
<awygle>
basically switching Record(UserValue) to Record(ValueCastable) made a bunch of stuff break because operations weren't implemented
<whitequark>
ohhhh
<awygle>
which again, makes sense, but manually re-implementing them all felt like a lot of work at the time
<whitequark>
we can implement __getattr__
<whitequark>
with a deprecation notice.
<awygle>
__getattr__ on Record you mean?
<whitequark>
it'd just delegate to getattr(Value, x) itself
<whitequark>
yeah
<awygle>
yeah i think that's what i ended up doing (and fucking up ~4 times because i'm not that good at python lol)
chipmuenk has quit [Quit: chipmuenk]
<awygle>
so you said "with a deprecation notice", can you expand on that?
<awygle>
not sure what you want to notify on, since Record itself will be deprecated eventually
<whitequark>
you're right, what I said didn't make sense
<awygle>
in that case, do you think it would be helpful to mention that pattern (delegating __getattr__ to getattr(Value, x)) somewhere? it seems like it will end up being quite common. or if it's a bad pattern, should we mention that, and why?
<whitequark>
it's a bad pattern because it reintroduces all of the issues we had with UserValue
<whitequark>
what we should do is listen to feedback and figure out how to satisfy people's needs without making it a severe backcompat hazard
<awygle>
makes sense
<awygle>
i'll just make a mental note in case people start showing up like "uh so how do i do stuff with ValueCastable"
<whitequark>
sgtm
<d1b2>
<marble> Are there tutorials for nmigen-soc or its wishbone bus part? I read the speicification and began reading the chapter with the examples. The examples code I found online seems to use it in a hacky way and doesn't really show which parts of the bus are implemented by the library
<awygle>
whitequark: i finished the Record transition to UserValue on top of the current UserValue PR. do you want to review that before 0.3 or do it as part of 0.4? obviously after the current UserValue PR goes in
<whitequark>
marble: nmigen-soc is unfortunately not easy to use yet
<whitequark>
awygle: before 0.3, i think
<awygle>
mk
emeb_mac has joined #nmigen
<d1b2>
<marble> Ok
<awygle>
completely not nmigen-related but can i tell ssh to prefer my rsa key over my ecdsa key? or else tell git to retry through my keychain until it successfully pushes?
<d1b2>
<TiltMeSenpai> it should already do that I think?
<awygle>
oh this is a different problem actually. nvm
<awygle>
the rsa key never ends up in my keychain
<d1b2>
<marble> if nothing works you can tell git to use a specific key with GIT_SSH_COMMAND="ssh -i ~/.ssh/mycoolkey_ed25519" git ...
<d1b2>
<marble> ah
<d1b2>
<bob_twinkles> is there a good reference for how to get at device-specific blocks via nmigen (sorry my terminology might be bad, new to this stuff)
<d1b2>
<bob_twinkles> I'm trying to port the icebreaker-candy designs to nmigen as an exercise in learning the tools, but they rely on the PLL40 stuff and there doesn't seem to be a straightforward way to tell nmigen to load some existing verilog for a given module
<awygle>
Instance is what you're looking for
<awygle>
from memory, you need to add the verilog source file to the platform, and then give Instance the module name that verilog uses and it'll pick it up properly
<awygle>
as for references, i'm not totally sure. there's probably a few examples in nmigen-boards. there's definitely one in nmigen/vendor/lattice_ecp5.py (in create_missing_domain, to create the internal oscillator)
<awygle>
my current draft of the record transition can be found at https://github.com/awygle/nmigen/tree/RecordMigration . i know lkcl is worried i'm going to break records forever, so if he could run (some subset of) his tests against that branch that would be helpful.
<lsneff>
I'm probably completely missing it, but how do I write/read pins on my board?
<lsneff>
platform.request didn't work, but maybe I was requesting the wrong string?
Asuu has quit [Remote host closed the connection]
<awygle>
lsneff: how did you try to use platform.request?
<lsneff>
I tried `platform.request("A6")`, which seems to be the name under which the pin is registered in the board file
<_whitenotifier-f>
[nmigen] awygle commented on issue #501: Document how to use connectors from platform definitions - https://git.io/JTp4D
<awygle>
i have confidence whitequark thought the design through and there are good reasons for it working the way it does, but i admit i'd enjoy seeing a writeup of why, because it does seem kind of obscure to me too.
<awygle>
it makes sense if you are thinking in terms of resources, i guess. you can say "my rtc clock is on connector pins 6 and 7" and then after that you're talking about "my rtc clock" and not "pin A6".
<awygle>
but folks coming from verilog especially may not have that mental model
<d1b2>
<bob_twinkles> so I think Instance is doing what I want it to, but now I need a way to get at the actual clock line from the platform
<d1b2>
<bob_twinkles> since the PLL needs a reference clock to lock to
<awygle>
you can get the clock line from a domain with ClockSignal("domain_name")
<d1b2>
<bob_twinkles> I'm also not quite sure how to propagate the new high-frequency clock domain + reset based on PLL lock to downstream modules
<awygle>
(same for ResetSignal)
<d1b2>
<bob_twinkles> thanks!
<awygle>
"how to propagate" is the same thing but backwards. make a new ClockDomain, get its ClockSignal, m.d.comb = hs_clock_signal.eq(pll_output)
<awygle>
i think anyway
<awygle>
you might also be able to do clock_domain.clk = pll_output?
<awygle>
play around in that space, in any case. hopefully it should be pretty easy to tell when it starts working.
<d1b2>
<bob_twinkles> I think you need to explicitly create the clock domain for that to work, I was trying to figure out how to get like m.d.sync.clk to work but m.d.sync is a like deferred construction thunk for the actual clock domain
<awygle>
i believe you can get the sync ClockDomain object with ClockDomain("sync")
<d1b2>
<bob_twinkles> hmm, so what happens if I try to use like nmigen.lib.fifo stuff in my custom clock domain
<d1b2>
<bob_twinkles> since those are hard-coded to add things to m.d.sync
<awygle>
so, if the module uses "sync" internally, you use DomainRenamer to change that
<awygle>
if it's something like AsyncFIFO, those take domain names as constructor arguments
<awygle>
(unlike the stuff about Instance and Connector where i was trying to remember and wasn't confident, i solidly know what i'm talking about re: DomainRenamer)
<d1b2>
<bob_twinkles> heh 🙂
<d1b2>
<bob_twinkles> unfortunately my fastest debug tool doesn't have the bandwidth for a 30MHz clock so hopefully this Just Works
<_whitenotifier-f>
[nmigen] awygle commented on issue #501: Document how to use connectors from platform definitions - https://git.io/JTpBD
<vup>
also I think for some of the ice40 pll stuff you need an input without the input buffer right? Then you can use `platform.request("clock_resource_name", dir="-")`
<d1b2>
<bob_twinkles> hmm, that sounds possible. Right now it's going through some other stuff because nmigen is inserting its own clocking infrastructure
<lsneff>
Hmm, my fpga isn't loading the bootloader anymore, so it'll be a while before I can test out the pins
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
samlittlewood has quit [Ping timeout: 264 seconds]
<d1b2>
<bob_twinkles> hah, vup had it right. I got the syntax worked out to create a custom clock domain and now design packing is failing telling me that the signal going into the PLL isn't directly connected to a pad