FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
proteus-guy has quit [Ping timeout: 244 seconds]
proteus-guy has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #nmigen
<awygle>
what's the best way to set up a module that needs to write to pins so i can usefully simulate it?
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-guy has joined #nmigen
proteus-guy has quit [Ping timeout: 240 seconds]
hitomi2507 has joined #nmigen
<d1b2>
<emeb> is there an arithmetic right shift in nmigen?
jeanthom has joined #nmigen
chipmuenk has joined #nmigen
jeanthom has quit [Ping timeout: 265 seconds]
jeanthom has joined #nmigen
<lkcl>
d1b2, emeb: don't think so, you kinda have to construct it. a double-sized sign-extended input followed by straight shift would do it then truncate the result
<jfng>
awygle: i'd go with a similar approach as the nmigen-stdio uart: pass the pins as optional parameters to the constructor, and expose the signals in the module interface
<jfng>
if pins are provided, these signals are driven by them
<jfng>
if pins is None, your simulation testbench can drive them
Asu has left #nmigen ["Konversation terminated!"]
<DaKnig>
lkcl: in most langs its simpler to just a/b
<DaKnig>
if a is signed, this would be arithmetic shift
<DaKnig>
s/b/(1<<b)
<_whitenotifier-b>
[nmigen] jeanthom opened issue #462: Pin direction and XDR can be set even if there is not matching subsignal - https://git.io/JJrcQ
<d1b2>
<emeb> @lkcl: thanks, that's kind of what I've converged on as a solution.
<d1b2>
<emeb> @agg: Interesting - I was going on the Baruch tutorial which says ">> shift right Logical, not arithmetic"
<d1b2>
<emeb> I need to take a closer look at the simulation results to see what's going on.
<agg>
emeb: I've just run a quick sim and `a>>b` is definitely arithmetic/sticky
<agg>
are your types definitely signed?
<agg>
if you're doing `a>>b` but a's shape is not signed, it won't sign-extend
d has joined #nmigen
d is now known as Guest86434
Guest86434 has quit [Client Quit]
<d1b2>
<emeb> @agg yes, my types are signed. It's probably working right - I was just misdirected by what I'd read in that tutorial.
<agg>
ack
<lkcl>
does anyone know how to do power-on resets and how to "control" them from a separately-clocked "debug" unit?
<lkcl>
i'm adding a DMI (like JTAG) interface to libre-soc, and one of the commands is "reset core"
<lkcl>
unfortunately at the moment, whenever "reset" is called through ResetSignal().eq(self.core_reset_i)
<lkcl>
that's a "global" reset signal that also resets the debug unit!
<lkcl>
wark-wark...
<lkcl>
so how do i create separate reset "domains" - one for the core and one for the debug unit?
<lkcl>
i've seen something about this before, about... a month ago?
<lkcl>
my first thought was: because ResetSignal() takes an argument about what clock domain it is associated with, to create a separate ClockDomain for the core
<lkcl>
and *replace* m.d.sync: m.d.sync = ClockDomain("core_clk")
<sorear>
i've seen a lot of cores with a ndreset (non-debug reset) global signal
<lkcl>
sorear, ah can you remember where? (and were they in nmigen)?
<sorear>
no, and definitely not
<jeanthom>
lkcl, create a separate ClockDomain for your debug TAP and use a domain renamer to use it in your debug TAP maybe?
<lkcl>
ah. yeh this is one of those "voodoo" things for nmigen: some wrapper recipe is needed
<lkcl>
jeanthom: thx just investigating
<lkcl>
looking that up... hmm DmainRenamer doesn't have a docstring
<jeanthom>
m.submodules.tap = tap = DomainRenamer("tapsync")(MyTAP())
<lkcl>
ah! nice!
<lkcl>
that looks quite straightforward
<lkcl>
jeanthom: ha, that seems to have done the trick (got a bug to deal with however the gtkwave looks good
<lkcl>
nice call
<lkcl>
basically i decided instead of putting the debug TAP into a renamed domain, to put the core into a renamed domain instead
<lkcl>
then
<lkcl>
core_sync = ClockDomain("coresync")
<lkcl>
m.domains += core_sync
<lkcl>
and finally
<lkcl>
comb += core_sync.clk.eq(ClockSignal())
<lkcl>
in the core module it assigns ResetSignal() to an external signal (self.core_reset_i)
hitomi2507 has quit [Read error: Connection reset by peer]
Asuu has joined #nmigen
<cr1901_modern>
whitequark: I know you don't take roll or anything like that, but due to prior engagement I won't be able to make the meeting I think
<whitequark>
cr1901_modern: that's ok
<whitequark>
unless you had something you need to specifically discuss?
<cr1901_modern>
No, the paramiko stuff has been going smoothly. So no need.
hitomi2507 has joined #nmigen
<_whitenotifier-b>
[nmigen] mglb opened pull request #463: Add initial support for Symbiflow toolchain for Xilinx 7-series - https://git.io/JJryz
<Lofty>
...Straight away, based on what I know of nmigen prior art that PR isn't going to fly, is it?
<DaKnig>
why not
<DaKnig>
sounds super helpful
<Lofty>
e.g. Lattice ECP5 has the same platform for both Trellis and Diamon
<Lofty>
It's not the adding support bit, I think. It's how it's added.
<DaKnig>
how would you choose in that case the toolchain?
<DaKnig>
pass to constructor or something?
<_whitenotifier-b>
[nmigen] Ravenslofty commented on pull request #463: Add initial support for Symbiflow toolchain for Xilinx 7-series - https://git.io/JJryi
<_whitenotifier-b>
[nmigen] Ravenslofty edited a comment on pull request #463: Add initial support for Symbiflow toolchain for Xilinx 7-series - https://git.io/JJryi
<DaKnig>
having a consistant standard is important.
<Lofty>
DaKnig: plus whitequark's point about it being up to the user is very valid
<whitequark>
that's really the only point there is to it
<Lofty>
I feel like the PR could have been merged quicker and with less hassle if somebody from symbiflow had asked about nmigen conventions before writing the code
<Lofty>
Maybe "could be merged" is better phrasing there
<whitequark>
i think there are two parts to this issue
<whitequark>
on one hand, nmigen does not (yet) clearly document these conventions
<awygle>
There's always a tension there IME, between wanting to respect the project conventions and not wanting to annoy maintainers with trivial questions
<awygle>
Or potentially trivial rather
<whitequark>
on the other hand, antmicro is almost pathologically bad at discovering and following *unspoken* conventions, from past experience
<Lofty>
One question I do have though: I don't think project x-ray has complete chip support, so what should a platform do if it encounters a chip it does not support?
<Lofty>
I think this would also apply for Mistral
<whitequark>
Lofty: the same thing as when you use a Vivado version too old for your chip
<whitequark>
let the synthesizer die
<whitequark>
or the onr
<whitequark>
*pnr
<Lofty>
Okay, that works
<DaKnig>
Lofty: I think its unsupported backend things
<DaKnig>
things the nmigen frontend cant know
<Lofty>
I mean, my own little experience with Antmicro is the QuickLogic flow
<Lofty>
Which...isn't great.
<whitequark>
i see Antmicro as a consulting shop with little experience per se working with established open-source projects that aren't corporate offshoots from something like Google
<whitequark>
so by taking on their pull requests you basically have to educate them first
<Lofty>
*sigh*
<Lofty>
I mean, both QuickLogic and X-Ray ship with VPR as place and route
<Lofty>
And as far as I can tell the main saving grace of using a 20-year-old place and route codebase is that you can modify the XML architecture file without rebuilding VPR
<Lofty>
It feels like a "move fast and break things" approach hit sunk-cost fallacy
<Lofty>
I dunno. I'm not touching VPR for Mistral
<Lofty>
(Mistral == open Cyclone V flow)
Asuu has quit [Read error: Connection reset by peer]
<awygle>
somebody should write a paper about why it's so hard for academic software to make the leap into the OSS community of practice
<awygle>
but nobody in the OSS community of practice would see it because it'd be academic
<awygle>
the second round of the shape conversion rfc
<lkcl>
VHDL has a "dictionary" type. it would be nice to have that (or know how to implement it in a compact fashion)
<lkcl>
it's basically a reduced (compact) form of a switch statement / LUT / Memory
<whitequark>
we had an issue about that, sec
<lkcl>
oh really? cool!
emeb has joined #nmigen
<_whitenotifier-b>
[nmigen] whitequark commented on issue #462: Pin direction and XDR can be set even if there is not matching subsignal - https://git.io/JJrQj
<lkcl>
oh - and PriorityPicker. RoundRobin's gone in (i believe?) - there's definitely a case for PriorityPicker because for e.g. priority-driven buses you absolutely have to give, for example, a shared bus RGBTTL master, absolute top priority.
<whitequark>
PriorityPicker just needs a pull request, it's clearly necessary and also clearly has a single good way to implement, so no need for an RFC
<lkcl>
reason: if anything else gets a higher priority, the scan lines on the monitor "blink" or you get corrupted data on the monitor
<whitequark>
just have someone from your team submit a PR
<lkcl>
ok cando
<awygle>
other than the shape thing I don't really have anything. I basically know what our next few things are and looking too far forward would just confuse things until they're done.
<lkcl>
DaKnig: ^ - c/f what we talked about yesterday
<lkcl>
whitequark: so where MutableSequence is the nmigen equivalent of python list, MutableMapping is the nmigen equivalent of python dict?
<whitequark>
yes
<lkcl>
very cool. and consequently a lot more than i first thought. i was initially thinking in terms of simple static lookups.
<DaKnig>
lkcl: dictionary in vhdl?
<lkcl>
DaKnig: well, what i thought was a dictionary. then realised it wasn't, however that the idea of having something dictionary-like in nmigen would be really nice
<lkcl>
as being much more compact than a continuous stream of If Elif Elif statements or a repeated Switch/Case batch.
<DaKnig>
lkcl: Array + python Enum would give yo the required constant lookup
<DaKnig>
I did that
<DaKnig>
tho I didnt use Enums
<DaKnig>
I used raw numbers
<DaKnig>
why? good question.
<DaKnig>
make a python dictionary, do all your business with the python enums:constant data, convert this in a single line for loop into a list and then make it into a Memory (or Array, rn Memory is better)
<whitequark>
I think there's nothing inherently wrong with having a dict equivalent of Array
<lkcl>
this code would be replaced with one line:
<whitequark>
it just needs to be designed (mainly minor concerns like naming) and implemented, and it's not clear anyone actually needed it at that point
<awygle>
whitequark: can you please close #381 with reference to #464?
<lkcl>
whitequark: my feeling is, it'd be one of those things that people have done in their own way, and consequently haven't thought _to_ ask, if you know what i mean.
<jfng>
a switch/case with a for loop isn't too bad imo, if you don't mind the indentation
<lkcl>
jfng: the point is that for/swithc/case loop - 10-15 lines - literally gets replaced by one dict instance.
<DaKnig>
wow lkcl, this reminds me of duffs device. disgusting. I agree we should make a dict thing lol
<_whitenotifier-b>
[nmigen] whitequark commented on issue #381: [RFC] Add a (more) general shape conversion operator - https://git.io/JJr7i
<_whitenotifier-b>
[nmigen] whitequark closed issue #381: [RFC] Add a (more) general shape conversion operator - https://git.io/JfGQv
<lkcl>
200+ characters of typing replaced with... 15-20
<whitequark>
awygle: done
<awygle>
thank you :)
<lkcl>
whitequark: pinged the libre-soc list about the meeting, i'll email jacob about #464
jeanthom has joined #nmigen
<Lofty>
I can't remember if we've had people misunderstand how range() works as a shape operator; i.e. you can get values beyond the upper limit of the range
<Lofty>
My memory feels like swiss cheese sometimes
<lkcl>
Lofty: ya get used to it :)
<_whitenotifier-b>
[nmigen] awygle commented on issue #451: `Switch` attribute for unique and/or full `Case`s - https://git.io/JJr7X
<lkcl>
i seem to recall from last week that the mathematical variant "hid" what was being converted to what
<awygle>
i don't remember seeing anybody complain about that, Lofty
<awygle>
fwiw
<Lofty>
I dunno. Maybe it's a bit of a straw man argument, then.
<whitequark>
Lofty: it is a real argument, and i've seen it play out in a different way in Clash
<whitequark>
so in Clash, you have a type, iirc it is called `Index n` or something like that
<whitequark>
it's basically equivalent to the range(n) shape
<lkcl>
that anything that's done explicitly gives an opportunity to throw an exception and consequently warn the developer if they missed something
<whitequark>
and in Clash, it is actually *undefined behavior* to have the value of a variable with that type go beyond `n`
<whitequark>
but... this doesn't necessarily transfer to nMigen nicely
<whitequark>
there's a reason we have shapes and not types
<Lofty>
Basically my opposition to prop 2 is that `v.as(range(N))` where N is smaller than the actual maximum bit value is unintuitive
<whitequark>
hmm
<whitequark>
yes, but that's the same problem as with Signal(range(N))
<Lofty>
True, yes. I feel like with Signal() you might be more consciously aware of staying within bounds
<whitequark>
however, your argument could be stronger for conversion operators because with those, we explicitly talk about mathematical value
<whitequark>
also, you'd be opposed to both 2 and 3 because of that, right?
<Lofty>
I dunno, to me having size as a bit width communicates that the language can only guarantee the result fitting within those bits better than a target shape
<_whitenotifier-b>
[nmigen] whitequark commented on issue #451: `Switch` attribute for unique and/or full `Case`s - https://git.io/JJr7b
<lkcl>
mm. ah. just checking nmigen.hdl.ast.Shape - i didn't realise that the width argument can be a range. ok Shape.cast() can take a range
<lkcl>
or an Enum
<whitequark>
lkcl: jsyk, that part is fully documented
<lkcl>
we use Signal(enumkls) a lot in libre-soc - it's really useful and important
<lkcl>
i take it "behind the scenes" Shape.cast() ends up being called?
<Lofty>
If the language is going to use shapes as a target, I'd like it to make stronger guarantees about it, or else only promise what it can actually achieve
<whitequark>
Lofty: I'm not sure if this can be done without turning nMigen into a completely different language
<whitequark>
(a strongly typed one, for one)
<Lofty>
That's kinda my point
<whitequark>
oh?
<lkcl>
(2) - v.as() - is therefore making me nervous. it would need a lot more understanding / reading-of-manuals to make sure it was used correctly.
<Lofty>
If it casts to a range(N), the most intuitive behaviour would be along the lines of a modulus operator. Since that's obviously not feasible, it shouldn't be possible to use ranges as a cast type
<lkcl>
where v.zero_extend(), v.sign_extend(), v.truncate() - they're all explicit, really clear, and have opportunities for exceptions to guide developers
<lkcl>
jacob's suggesting modulo truncation. mmm. on power-of-2 unsigned that's pretty straightforward / obvious. non-power-of-2 or signed (range, Enum), again makes me nervous.
<DaKnig>
@Lofty in this specific case I think VHDL does the right thing. you cant cast from larger integer types to smaller types. you can cast to a vector of bits, chop it, then cast back. the point is if you cant prove that the shape you cast to is large enough then it would cause problems which you wouldnt want. the modulus solution is unsatisfying. if you'd want to cast it to a different shape you have
<DaKnig>
to specify the exact steps to do so or let the tool figure out of its always provably fits.
<DaKnig>
well ofc I am in no position to say how nmigen should work
<DaKnig>
and this one is a lot different from how it works now.
<d1b2>
<TiltMeSenpai> when you create a Signal from a range, does it retain information about the original range used?
<d1b2>
<TiltMeSenpai> or does it just auto calculate the bit width
<DaKnig>
currently no
<d1b2>
<TiltMeSenpai> ok, cool
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<whitequark>
there's an open issue to preserve that, but it's a complex design problem
hitomi2507 has quit [Read error: Connection reset by peer]
chipmuenk has joined #nmigen
hitomi2507 has joined #nmigen
Guest79780 has quit [Quit: leaving]
chipmuenk has quit [Quit: chipmuenk]
hitomi2507 has quit [Quit: Nettalk6 - www.ntalk.de]
FFY00 has quit [Remote host closed the connection]
jeanthom has joined #nmigen
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
<cr1901_modern>
whitequark: If you're up for it, do you have any other feedback on #461?
Asuu has quit [Quit: Konversation terminated!]
<whitequark>
later
<cr1901_modern>
Ack.
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 260 seconds]
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 256 seconds]