BracketMaster has quit [Ping timeout: 245 seconds]
hitomi2507 has quit [Read error: Connection reset by peer]
hitomi2507 has joined #nmigen
hitomi2508 has joined #nmigen
hitomi2507 has quit [Read error: Connection reset by peer]
hitomi2508 has quit [Ping timeout: 258 seconds]
<_whitenotifier-f>
[nmigen] jfng opened issue #498: Support for generated clock constraints - https://git.io/JU4fg
<jfng>
^ idk if this is a desirable feature, but i'm currently needing it for a project
hitomi2508 has joined #nmigen
<_whitenotifier-f>
[nmigen] mithro commented on issue #498: Support for generated clock constraints - https://git.io/JU4J4
proteusguy has quit [Ping timeout: 264 seconds]
<_whitenotifier-f>
[nmigen] whitequark commented on issue #498: Support for generated clock constraints - https://git.io/JU4YZ
proteusguy has joined #nmigen
emeb has joined #nmigen
hitomi2508 has quit [Quit: Nettalk6 - www.ntalk.de]
jjeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 244 seconds]
Asu has joined #nmigen
<_whitenotifier-f>
[nmigen-boards] Fatsie commented on pull request #111: Arty S7 OpenOCD Support - https://git.io/JU4ZQ
<_whitenotifier-f>
[nmigen-boards] Fatsie commented on pull request #111: Arty S7 OpenOCD Support - https://git.io/JU4nC
moony has quit [Remote host closed the connection]
moony has joined #nmigen
_whitelogger has joined #nmigen
<whitequark>
meeting time!
<whitequark>
i'm unfortunately still not feeling well, so let's only discuss blockers on today's one, keeping various improvements for the future
<whitequark>
i know jfng is still waiting on a PR review, let me do that right now
<whitequark>
anyone else?
<jfng>
oh, no hurry for #27 if you're unwell, especially since it's not a blocker
* Lofty
watches the crickets chirp
<Lofty>
I think we can defer things if you're not doing well, WQ
<whitequark>
jfng: alright, reviewing that PR was easy, i believe it didn't really deviate from the consensus we came to previously?
<whitequark>
lgtm
<jfng>
nope, i tried to stick to what was agreed upon
<Lofty>
I did get somebody inform me that vendor.intel needs to handle some other primitives for MAX V, and also 10 Series
<Lofty>
But again, that's an "improvement"
<jfng>
but i was wary of the breaking changes, e.g. the additional restriction on frozen memory map
<jfng>
ok then, will merge once i figure out how to migrate downstream lambdasoc, with deprecation warnings etc
<jfng>
thank you !
<whitequark>
jfng: I think that's completely fine, the old behavior of `freeze` was incidental-ish, IIRC
<whitequark>
as in, it was convenient to implement it that way, and I documented what I implemented
<whitequark>
your new behavior is certainly closer to the spirit of what freeze() should be doing
<whitequark>
since, for example, the old name+behavior could have easily misled downstream API users into thinking that they can cache the resources whereas they could have not
<jfng>
IIRC the old behaviour was voluntarily lenient in order to not break existing code that e.g. assigned the bus interface of a csr mux, before adding elements to it
<whitequark>
hmm
<whitequark>
I could be misremembering
<jfng>
now, if you get e.g. csr_mux.bus, you cannot add elements to it anymore
<jfng>
so users must be careful about the order in which they do stuff
<whitequark>
ah yes
<jfng>
now, that i think about it, this is not documented enough, so i'll add that before merging
<whitequark>
sounds good. I can see how this might cause problems in the future, but I'm inclined to think that such problems should be solved by improving design downstream of .freeze()
<whitequark>
i.e. if the order requirements are problematic, perhaps we can provide a builder object that takes care of that
<whitequark>
(we'll need one anyway to conveniently define CSRs)
<jfng>
something like a csr.Bank, that would have an underlying Multiplexer, and a more user-friendly interface ?
<whitequark>
yup, that's the general idea
<whitequark>
that was one of the things I was going to spend time on after nmigen 0.3
<whitequark>
still do, in fact
<whitequark>
*still planning to
<jfng>
i think we would need something like that anyway, because doing `elem = csr.Element; csr_mux.add(elem)` can get very verbose
<whitequark>
yes
<whitequark>
that's what my remark earlier was about
<whitequark>
since we need it anyway, the order dependencies probably don't matter
<jfng>
agreed
<whitequark>
Lofty: re MAX V, I will probably not have time to dig into that soon, so it would be best if someone contributed those
<Lofty>
Yeah, I have a patch which has the primitives at least
<whitequark>
cool!
<Lofty>
Basically, the altiobuf IP cells don't exist for CPLDs
<Lofty>
So instead you have to use the low level primitives
<Lofty>
My life is going to be such a nightmare trying to get people to use Mistral over Quartus
<Lofty>
;~;
<awygle>
oh shit, meeting
<awygle>
my bad
* awygle
has vacation brain
<cr1901_modern>
Yea I forgot too. :(
emeb_mac has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
Asu has quit [Ping timeout: 258 seconds]
jjeanthom has quit [Ping timeout: 256 seconds]
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 258 seconds]
<_whitenotifier-f>
[nmigen-boards] cr1901 commented on pull request #111: Arty S7 OpenOCD Support - https://git.io/JU4gG
cr1901_modern1 has quit [Ping timeout: 244 seconds]
<_whitenotifier-f>
[nmigen-boards] cr1901 edited a comment on pull request #111: Arty S7 OpenOCD Support - https://git.io/JU4gG
<awygle>
what happens if i word-select off the end of a signal?