<nickoe>
vup: mm, I may have a loo at that tomorrown, but I guess I need to understand/check the classes to see if they are even compatible.
lf_ has joined #nmigen
lf has quit [Ping timeout: 264 seconds]
lkcl has quit [Ping timeout: 240 seconds]
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
lkcl has joined #nmigen
sakirious02 has quit [Read error: Connection reset by peer]
sakirious02 has joined #nmigen
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 246 seconds]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
mwk_ is now known as mwk
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
Bertl_oO is now known as Bertl_zZ
levi has quit [Ping timeout: 260 seconds]
levi has joined #nmigen
pftbest has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined #nmigen
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
chipmuenk has joined #nmigen
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
_whitelogger has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
pftbest has joined #nmigen
<_whitenotifier>
[nmigen] nickoe commented on pull request #563: Unify Xilinx platforms into a single class, support more devices - https://git.io/JtREv
jjeanthom has joined #nmigen
jeanthom has quit [Read error: Connection reset by peer]
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 265 seconds]
chipmuenk1 is now known as chipmuenk
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
Balda has left #nmigen ["WeeChat 2.9"]
DasFehiler has joined #nmigen
<DasFehiler>
hello
<DasFehiler>
n1 nmigen VS verilog which is easier , also best FPGA board for starter?
<DasFehiler>
n1 here?...
<DasFehiler>
guess not
<DasFehiler>
auf Wiedershen!!!
DasFehiler has quit [Quit: Connection closed]
<_whitenotifier>
[nmigen] github-4o opened issue #585: [RFC] expose `strip-internal-attrs` option to cli-based interface - https://git.io/JtRX4
revolve has quit [Read error: Connection reset by peer]
<_whitenotifier>
[nmigen] mwkmwkmwk synchronize pull request #563: Unify Xilinx platforms into a single class, support more devices - https://git.io/JLcUA
<_whitenotifier>
[nmigen] codecov[bot] edited a comment on pull request #563: Unify Xilinx platforms into a single class, support more devices - https://git.io/JLcT8
<_whitenotifier>
[nmigen] mwkmwkmwk commented on pull request #563: Unify Xilinx platforms into a single class, support more devices - https://git.io/Jt0Ju
<_whitenotifier>
[nmigen] codecov[bot] edited a comment on pull request #563: Unify Xilinx platforms into a single class, support more devices - https://git.io/JLcT8
<_whitenotifier>
[nmigen] codecov[bot] edited a comment on pull request #563: Unify Xilinx platforms into a single class, support more devices - https://git.io/JLcT8
<_whitenotifier>
[nmigen] codecov[bot] edited a comment on pull request #563: Unify Xilinx platforms into a single class, support more devices - https://git.io/JLcT8
<d1b2>
<TiltMeSenpai> lol those are some loaded questions
<d1b2>
<TiltMeSenpai> re: nmigen vs varilog, nmigen provides a pretty unified interface, but it's very different than writing verilog
<d1b2>
<TiltMeSenpai> your nmigen "code" is actually a data structure representing your circuit, this lets you do some pretty cool stuff by writing conventional python aside your nmigen. People have been using that to make parameterizable crc cores and stuff
Lord_Nightmare has joined #nmigen
<d1b2>
<TiltMeSenpai> as far as "good starter FPGA boards", everything ice40/ECP5 bases is a good starting point, because those chips have the best open source toolchains currently, which lets you not deal with proprietary garbage
<DX-MON>
shame DasFehiler wasn't patient and left
<d1b2>
<TiltMeSenpai> oh
<d1b2>
<TiltMeSenpai> lol
<DX-MON>
looked over on IRC to see if they were still around
<d1b2>
<TiltMeSenpai> well I tried :/
<DX-MON>
also, I'd honestly say.. save for the docs thing.. nMigen would be the better starting point to learn
<DX-MON>
because not having to learn how to drive the tools while trying to learn how to describe hardware is <3
<d1b2>
<TiltMeSenpai> fun thing about verilog is "how easy is this to learn" depends on "what toolchain are you using"
<DX-MON>
uh.. and also "how well can you get your head around the timing and assignment model"
<DX-MON>
which is the exact reason I prefer VHDL fwiw
<DX-MON>
except I now far prefer nMigen
<Sarayan>
glasgow as a starting board? You're not going to blow it up immediatly with static electricity at least
<d1b2>
<TiltMeSenpai> that's been secondary to "how do I get this proprietary IDE to emit a bitstream to blink a light on my board" in my experience
<DX-MON>
the VHDL timing model is much more sane when you're used to synchronous 7400 logic and it bitching at you when you assign wrong is.. very nice
<d1b2>
<TiltMeSenpai> ;p;
<d1b2>
<TiltMeSenpai> lol
<d1b2>
<TiltMeSenpai> I don't think I've written any vhdl tbh
<DX-MON>
it's worth doing at least once, if you can get past how Ada it is
<d1b2>
<TiltMeSenpai> maybe, I've just been sticking to nmigen
<DX-MON>
that's fair
<d1b2>
<TiltMeSenpai> mostly because not having to deal with make/other build systems is nice
<DX-MON>
as for Glasgow as a starting board.. that's an interesting idea Sarayan.. writing a new applet is fairly straight-forward and all the build+deployment model etc is taken care of for you, so you literally hit the ground running
<d1b2>
<Olivier Galibert> Indeed
<d1b2>
<Olivier Galibert> (Sarayan here too_
<DX-MON>
but.. and this was the thing that tripped me up.. writing your first nMigen-only project after being used to Glasgow's framework.. has been a struggle bust to start with
<DX-MON>
(my HDL history is that I learned VHDL close to a decade ago as part of my degree thesis, wrote a whole pile of stuff in the following couple of years, then nothing till the end of last year.. when I started poking Glasgow applets and then the last few days as I learned nMigen and revived an old project of mine)
<d1b2>
<TiltMeSenpai> yeah, I think that's the big problem with Glasgow as a starting board. Eventually you're going to want to write something without the Glasgow support framework
<Sarayan>
heh, learned vhdl/fpga around 20 years ago as a way to control 32 adcs in parallel, found that rather nice, but didn't have the hardware to play with them again until recently
revolve has quit [Read error: Connection reset by peer]
<Sarayan>
isn't glasgow 100% nmigen at this point?
<d1b2>
<TiltMeSenpai> maybe like icebreaker/orangecrab? idk
<DX-MON>
it is mostly nMigen (there are still a couple of outstanding PRs from Attie to convert applets to pure nMigen from oMigen on the compat layer)
<DX-MON>
however, it's Glasgow-nMigen which.. effectively operates as a subdialect because of the way pin resources and then acessing those resources work vs the Platform system in pure nMigen
revolve has joined #nmigen
<DX-MON>
(don't get me wrong, that's no knock on either.. they're both brilliant.. but it does mean a pile of re-learning when moving from one to the other for the first time)
<Sarayan>
if they're that different that must annoy wq to no end
<DX-MON>
It's.. not so much they're very different.. but the Glasgow framework is doing some heavy lifting in you not having to write a driver stub for nMigen for every applet
<DX-MON>
learning how to write that boilerplate is the part I found problematic.. though I'm aware that's set to improve [it's a documentation problem..]
<DX-MON>
once you have it.. it's same-same
<DX-MON>
I hope that makes sense?
<d1b2>
<Olivier Galibert> Ah yeah, I see
pftbest has joined #nmigen
pftbest_ has quit [Ping timeout: 240 seconds]
emeb has quit [Quit: Leaving.]
emeb_mac has joined #nmigen
<modwizcode>
wow that was a fair bit of chat to catch up on :p
<modwizcode>
re: docs from a day or two ago, I was looking at that as a potential task and realized it wasn't really defined enough because there's a lot of semantics re: the desirable way to do something vs just a way to do it. Like should you get width of a signal with len(signal), signal.width, signal.shape().width (I think those are the three options)
<modwizcode>
Until some preferred structures are defined it's hard to make sane examples
<d1b2>
<DX-MON> aye, and to be fair on my tone.. I'm not whining about it.. I'm factually simply stating that it's what had me caught when switching over
<d1b2>
<DX-MON> also, with the way io resource records work atm.. it seems to me to make sense to prefer thing.width as len(thing) for those records returns the width of the i, o and oe signals combined
<d1b2>
<DX-MON> but of course I can't make that judgement [not my place]
<modwizcode>
Yeah I was mentioning it more because I think if those things can be hashed out then there's potential for more independent contribution to the docs afterwards
<vup>
modwizcode: as for `len(signal)` vs `signal.width` vs `signal.shape()`: use `shape()` when you care about it being signed or unsigned, `len(signal)` works for any `Value`, so you probably want to prefer that over `signal.width`, which only works with `Signal` and `Const` afaik
<d1b2>
<DX-MON> vup: the iobuf Record thing might want looking at then as that's a super serious foot-gun I smacked face-first into with porting OpenVizsla to nMigen [compat for now] from oMigen
<vup>
@DX-MON, does len(thing.{i,o,oe}) not work
<d1b2>
<DX-MON> assert sdram.dq.nbits == databits was the old code.. and to make that work.. assert len(sdram.dq.o) == databits which feels incredibly icky as it actually wants to validate the i, o and oe bit counts are all equal and are equal against databits
<d1b2>
<DX-MON> ie, it wants to be len(sdram.dq)
<d1b2>
<DX-MON> which returns, in this case, 16+16+16
<d1b2>
<DX-MON> databits is 16
<vup>
right
<vup>
i guess it depends on what your goal is
<vup>
`len(thing)` (should) always gives you the total number of bits of `thing`
<vup>
while width has a more context defined meaning
<d1b2>
<DX-MON> fun fact.. .width on a Record is not defined
<d1b2>
<DX-MON> unless I missed something
<d1b2>
<DX-MON> I have to go for a short while
<d1b2>
<DX-MON> be back soon-ish
<modwizcode>
Yeah I think the confusing thing was that some code (I think in the FIFO?) uses .width and len within lines of each other for the same thing. Also just looking at where things are defined I thought that somehow .width was defined on Value somehow but I really need to look at the code again so don't trust me on that.
<vup>
well `platform.request("thing")` gives back either a `Pin` or a `Record`, depending on wether `thing` is made up of Subsignals or not. The same applies recursively, so `thing.dq` has no subsignals, it is thus a `Pin` and `.width` is defined on `Pins` aswell
<vup>
modwizcode: is does? I don't see that in the FIFO code...
<vup>
but you are right, they are used both throughout the codebase, maybe it would make things less confusing if one would remove `.width` from `Signal` and `Const` and only leave it where it has a meaning different from "total number of bits in the thing"
<vup>
but maybe whitequark has a good reason for them
<modwizcode>
It might not have been the fifo code like I said I've been away from the codebase for too long to be sure, but it's definitely not clear from the current code which one is preferred, it sounds like len(xyz) should be basically universally preferred though
yuriks_ has joined #nmigen
ktemkin_ has joined #nmigen
Qyriad_ has joined #nmigen
yuriks has quit [*.net *.split]
ktemkin has quit [*.net *.split]
Qyriad has quit [*.net *.split]
JJJollyjim has quit [*.net *.split]
ktemkin_ is now known as ktemkin
yuriks_ is now known as yuriks
Qyriad_ is now known as Qyriad
* lkcl
waves to whitequark
<lkcl>
whitequark: we've gone out of "developing the SV standard" mode and are now into "implementing" mode.
<lkcl>
that means that the Dynamic SIMD Signal class will hit our critical path some time in... hard to say... the next 3 to 6 weeks
<lkcl>
i've put things off somewhat but we can't do that for much longer
<lkcl>
the reason i raise this is because we need code-redirection inside nmigen to make it possible to override Mux, Part, etc. following the exact paradigm of how operator.add (etc) call object.__add__()
<lkcl>
i would anticipate this to be in both Value and UserValue
<lkcl>
and for it to be strategically valuable far beyond what we're doing
<lkcl>
creation of FixedFPSignal, GaloisFieldSignal, ComplexNumberSignal, many many other abstractions where things like "__ge__" and "__mul__" do not match with what Signal.__ge__ (etc) provide
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<DX-MON>
vup: In this case, dq is comprised as a Pins.. which is then becomming a Record when .request()'d
<DX-MON>
because .request() is giving me the .i, .o and .oe signals bundled
<vup>
@DX-MON, well `.eq` is a `Pin` object, which inherits from `Record` and adds stuff like `.width`
<vup>
*`.dq`
<DX-MON>
uh.. but .dq in this context /isn't/ a Pin object.. it's a Record of the Pins object's resulting .i, .o and .oe signals.. and the width of that record is /not/ the width of the pins signal.. which is the issue I smacked face-first into
<DX-MON>
er.. pins object, not pins signal
<DX-MON>
taken from the Module in question: `sdram.dq is (rec sdram_0__dq i o oe), and has a width of 33 while sdram.dq.o has width 16`
<DX-MON>
which I formatted out using: `print(f"sdram.dq is {sdram.dq!r}, and has a width of {len(sdram.dq)} while sdram.dq.o has width {len(sdram.dq.o)}")`
<DX-MON>
and I was wrong.. the width isn't the simple addition of 3 16's.. that's len(i) + len(o) + 1.. so I'm guessing .oe is really actually 1-bit and replicated over all the subsignals
<DX-MON>
oooo.. I see what you're trying to say now vup.. I poked the .width signal and it does exist (yay) and is 16
<vup>
right, sorry if that was unclear
<DX-MON>
ok, using .width there does feel a lot less icky and I'm much happier with
jjeanthom has quit [Ping timeout: 246 seconds]
<pftbest>
d1b2, DX-MON: I've made a small hack in my nMigen build to track assignments: https://dpaste.com/CP23UUTBN
<pftbest>
it's not perfect but it's very simple
<anuejn>
I think that Pins is kind of a PackedStruct is almost always a footgun
<anuejn>
(as discovered by whitequark) and intended to go
<anuejn>
soon ish it will be replaced by a thing that cant be downcast to a thing where o/i/oe can be used as one flat thing (if I am not mistaken)
<anuejn>
lkcl: probably you just want to build your own wrappers around Mux, Part, etc. and just use them?
<anuejn>
It seems to me like a thing that can be easily done in downstream code (but I might be wrong here)