<Falteckz>
Got it - though perhaps not difficult to add a metastability warning in the future
<whitequark>
it's not entirely trivial
<whitequark>
mostly because of instances
<Falteckz>
I don't understand the problem domain, I don't understand how nMigen works under the public API. I don't mean to trivialise the problem, only that I hope it can be solved :)
<whitequark>
the problem is that if you instantiate some verilog or vendor primitives you don't know which domain the inputs and outputs belong to
<Falteckz>
Ah yes, I see. Having only worked with the ICE40LP*8k/CM81 so far. There are very few vendor primatives other than IO and PLL blocks. So it's not something I've encountered or give consideration to.
<whitequark>
yep
<awygle>
whitequark: so the SRAMResource in nmigen-boards inverts some pins with PinsN (cs, oe, we) but not others (dm). is there some way we can make this clearer when using the resource? i just burned a fair bit of time on this (oops)
<Falteckz>
When you emit a vendor primative from nMigen, is the Verilog just templated through? I would have thought some sort of "Resource" object would be created that clearly defines inputs and outputs. Perhaps my lack of experience with primatives means I just don't understand the edge cases (or face cases I guess)
<Stary>
yeah, i've burned some time on sdramresource inverting its control pins (i was matching the datasheet, which uses !cs etc)
<whitequark>
awygle: hm
<whitequark>
should dm be inverted?
<whitequark>
if it's not inverted that's probably just a bug
<awygle>
i dunno, on this SRAM "dm" is ~UB and ~LB
<awygle>
which matches the comment, saying "dm = #UB, #LB"
<whitequark>
let me rephrase
<whitequark>
would you have lost less time if dm used PinsN?
<awygle>
no, probably not
<awygle>
i only noticed dm not being inverted when i discovered oe, etc being inverted
<awygle>
in retrospect it makes total sense that they are, it just caused me to wonder if it'd make more sense to request negation or not when instantiating the resource or something
<whitequark>
okay so the idea is that if you use platform, 1 = active. always. regardless of what the hardware does
<whitequark>
among other things this has the nice effect that requesting and not using a pin means you don't activate anything
<whitequark>
because toolchains tend to tie unused pins to 0
<whitequark>
so if you had say three SPI devices on a bus you could get a bus conflict if you requested and then not used CS#
<whitequark>
but since you request CS (inverted) it's ok
<awygle>
mhm
<whitequark>
i admit that it's possible that the novelty factor makes this not worth it
<whitequark>
so far this seems to surprise people exactly once
<whitequark>
so i'm not yet convinced that it's bad
<whitequark>
i mean, "1 = inactive" is also a gotcha... it's just one that most of us learned long ago
<awygle>
i don't hate the idea in principle, but i don't love having to go to nmigen-boards to look up the definition of an SRAMResource to figure it out. perhaps the problem really comes from "some SRAMs have active high data masks, some have active low byte masks".
<whitequark>
another thing
<whitequark>
wait what
<whitequark>
is that really the case?
<awygle>
well the SRAMResource is defined with "cs" and "dm", where dm is active high
<whitequark>
yes
<awygle>
and my SRAM is defined with ce and lb/ub, which are all active low
<whitequark>
argh
<whitequark>
which SRAMs have active high LB/UB?
<awygle>
i don't know for sure that a cs/dm sram exists but i assume it does because somebody made the resource after it
<_whitenotifier-b>
[nmigen] whitequark closed issue #406: Can't instantiate a Tristate without input - https://git.io/JfdWq
<whitequark>
FL4SHK: anyway, if you know how to send a github PR, feel free; if you don't, you can just email me a patch, or put it on paste.debian.net or something
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±12] https://git.io/JJTsf
<_whitenotifier-b>
[nmigen/nmigen] whitequark 554cc50 - Deploying to gh-pages from @ 8dd28fecc6348474d61d57fda5eedfbb78cdb7e9 🚀
<_whitenotifier-b>
[nmigen] whitequark commented on issue #24: Updated user guide introduction for nmigen. - https://git.io/JJTs3
<_whitenotifier-b>
[nmigen] whitequark closed issue #24: Updated user guide introduction for nmigen. - https://git.io/JJTss
<ktemkin>
gravejac: as I mentioned on Discord, whitequark has some simple code-poking changes I thought you could help with
<ktemkin>
whitequark: meet Jacob; one of the engineers I manage at GSG
<whitequark>
hi Jacob!
Falteckz has joined #nmigen
Asu has quit [Remote host closed the connection]
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/JJTGE
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±10] https://git.io/JJTGD
<_whitenotifier-b>
[nmigen/nmigen] whitequark 85ba498 - Deploying to gh-pages from @ fd5ee548b6e333c92877440524c116e09bdd7c73 🚀
<whitequark>
gravejac: so the first thing I wanted to ask you to do is to fix a longstanding issue with nMigen tests, stemming from my misunderstanding of the documentation
<gravejac>
Hello!
<whitequark>
where assertRaises() has an argument "msg" but it doesn't mean that there's a check that the exception's message matches "msg"; instead it's the message displayed when the assertion fails, which isn't very useful
<gravejac>
That sounds good
<whitequark>
the fix is really to use assertRaisesRegex instead of assertRaises, which takes the exception class and the message *regex*
<whitequark>
we have around two hundred assertRaises and assertWarns invocations which need to be changed to use the *Regex variants
<whitequark>
it's probably going to take longer to automate it than to do it manually
<Falteckz>
Surprised that it isnt a simple regex to regex that regex.
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±17] https://git.io/JJTnB
<_whitenotifier-b>
[nmigen/nmigen] whitequark 419fb31 - Deploying to gh-pages from @ f24f1b02e871d8c7af9ead26c615645ccfcb0016 🚀
<whitequark>
i mean i don't care how it's done as long as i'm not the one who has to come up with it and verify that it works...
<_whitenotifier-b>
[nmigen] whitequark commented on issue #378: Add shift left/right by constant amount - https://git.io/JJTnu
<_whitenotifier-b>
[nmigen] whitequark commented on issue #355: [RFC] Redesign UserValue to avoid breaking code that inherits from it - https://git.io/JJTnK