electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
proteus-guy has joined #nmigen
proteus-guy has quit [Ping timeout: 260 seconds]
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel_ has joined #nmigen
proteus-guy has joined #nmigen
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-guy has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
<tannewt>
what would be the best way to have an elaborate method also elaborate from the superclass?
<tannewt>
nvm, looks like I can call elaborate and set its result as a submodule
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-guy has joined #nmigen
proteus-guy has quit [Ping timeout: 244 seconds]
<d1b2>
<emeb> does nmigen have bit reduction logical operators?
<d1b2>
<edbordin> not a proper answer, but if the signals are iterable you could do import operator; reduced = reduce(operator.and_, signal)
<d1b2>
<emeb> thx - I'll try that
<d1b2>
<edbordin> massive caveat that I haven't learned nmigen yet, the above assumes that the & operator has been overloaded
<d1b2>
<emeb> well I tried using & and | as unary operators and it didn't work as in verilog so I assume that's not how it's done (if it can be done)
<d1b2>
<emeb> and it's not mentioned in any of the tutorials I've looked at
<d1b2>
<emeb> ...and I don't know where in the source to look for details on this
<d1b2>
<edbordin> I can see that the & binary operator is defined, just looking now to see if the bits are iterable (otherwise my suggestion probably won't work)
<d1b2>
<edbordin> actually looks like what you probably want is Value.any() / Value.all() which will do the reduction you want 🙂
<d1b2>
<TiltMeSenpai> if bits aren't iterable, you can do for i in range(signal.size().width); acc &= signal[i]
<d1b2>
<TiltMeSenpai> or Value.any()
<d1b2>
<edbordin> there is also Value.xor() to do an xor reduction
<d1b2>
<TiltMeSenpai> huh, those are actually really useful
<d1b2>
<TiltMeSenpai> especially the Value.xor(), easy parity bits
<d1b2>
<edbordin> it's almost like this was designed by someone who knows HDL really well 😛
<d1b2>
<TiltMeSenpai> yeah lmao
<d1b2>
<TiltMeSenpai> there's some really useful stuff because of how python works that hide around, like sum() works on iterables of Signals
<d1b2>
<emeb> so what if I want to do the reduction on only some of the bits in a signal?
<d1b2>
<edbordin> you can probably slice it first
<d1b2>
<TiltMeSenpai> yeah, slice it
<d1b2>
<emeb> so signal[..].any ?
<d1b2>
<TiltMeSenpai> Signals support the full python syntax I think, so signal[-1] is the last bit, signal[::2] is every other bit, etc
<d1b2>
<emeb> So it seems that all and any can't be used in expressions
<d1b2>
<edbordin> what error did you get?
<d1b2>
<emeb> (at least according to the Baruch tutorial)
<d1b2>
<edbordin> ah, he seemed to have been very methodical when he wrote that so I would believe him
<d1b2>
<emeb> so I guess I need to write some ugly iterator-based workarounds for this.
<d1b2>
<edbordin> well, keep in mind python has built in functions called any() and all() so he might be talking about those
<d1b2>
<edbordin> yeah I think he is saying you can't do any(signal), but from what I am seeing you can probably do signal.any()
<d1b2>
<emeb> ok
<d1b2>
<emeb> I'll try that. so if I'm interested in doing the any() on just the N lsbits of signal then I probably have to create an intermediate one first?
<d1b2>
<edbordin> signal[:N].any()
<d1b2>
<emeb> ah - forgot the ()
<d1b2>
<edbordin> ah yeah that would have thrown up a fun error hehe
<d1b2>
<emeb> ok, seems to have run w/o errors. thx for the help!
<d1b2>
<emeb> keeps forgetting that these things are methods w/o arguments
<d1b2>
<edbordin> @whitequark (cc: cr1901_modern) I got around to rebasing that sby asyncio branch, it probably still needs another look over to check I merged it properly but it seems to be working https://github.com/edbordin/SymbiYosys/tree/async
_whitelogger has joined #nmigen
Asu has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
electronic_eel_ is now known as electronic_eel
<DaKnig>
I have a module that doesnt use rst anywhere, on the verilog level, and yet it is still generated as an input signal
<DaKnig>
should I make an issue about this?
<DaKnig>
or is this intended
<Lofty>
I think it's always generated
<DaKnig>
but should it? I dont think so
<whitequark>
DaKnig: it's intended, if you don't want that, add a clock domain yourself
<cr1901_modern>
whitequark: I'm taking a break from working on this, but what do you mean by "allow setting arbitrary environment variables". Shouldn't remote builds work the same regardless of whether you're running directly from an interactive ssh session or whether you're using the paramiko client?
<cr1901_modern>
(And injecting vars the local side means this is no longer the case)
<whitequark>
cr1901_modern: I don't think they can truly work the same no matter how hard we try
<whitequark>
it's better to make the breakage easier to debug and work around
<cr1901_modern>
According to paramiko docs, it's no guarantee that setting env vars client side to send to server will work (thanks, very specific and helpful). But... lemme think about that. All your remaining requested changes are low bandwidth for me.
<cr1901_modern>
I'll do them in a bit
<cr1901_modern>
(At least if "setting env vars doesn't work" comes up in a bug report, then we can say "paramiko doesn't guarantee this works" :P)
<tannewt>
What is a record? Is it piece of verilog or some other hw language?
<whitequark>
cr1901_modern: oh, it's not paramiko's fault
<whitequark>
cr1901_modern: oh. scratch that I guess
<whitequark>
looks like the default ssh config is just `AcceptEnv LANG LC_*`
<cr1901_modern>
So what's wrong with sourcing a file for nmigen vars that's explicitly for nmigen vars in headless operation?
<cr1901_modern>
They can put it in their .profile or .bashrc as desired
<whitequark>
cr1901_modern: mostly the fact that it's yet another moving part
<cr1901_modern>
Ack. I'm not attached to it.
<whitequark>
but i don't see any way around it
<cr1901_modern>
Sourcing .profile is also probably reasonable.
<cr1901_modern>
If you have other ideas, I'm open to them as well. I need to rest for a bit.
<whitequark>
we can start with sourcing .profile and change this if it causes issues
<DaKnig>
if anybody is gonna make some kinda UI , dont force the user to open some obscure file to read *one line*
proteus-guy has quit [Ping timeout: 260 seconds]
<awygle>
tannewt: I'm not sure of the origin, but a record in nmigen is a somewhat messy conflation of the idea of a packed struct and the idea of an interface specifying a collection of signals and their direction
proteus-guy has joined #nmigen
Yehowshua has quit [Ping timeout: 245 seconds]
Asu has quit [Remote host closed the connection]
<kbeckmann>
Has anyone already started working on adding support for Gowin FPGAs in nmigen? If not, I might do a crude first attempt now. Would be nice to try out some nmigen designs on the Tang Nano, now that Mouser stocks Gowin FPGAs.
<Lofty>
Certainly worth a shot, kbeckmann
<Lofty>
Especially with Apicula
<Lofty>
Highly beta state, but
<kbeckmann>
cool yes that was my target
<kbeckmann>
just got to blinky so now i want to take it to the next level :)
<whitequark>
kbeckmann: i received my tang nano recently, so i can actually reproduce your results
<whitequark>
feel free to start
<kbeckmann>
oh that's great.
<DaKnig>
wait, its a 5$ FPGA board?
anuejn[m] has joined #nmigen
<kbeckmann>
it doesn't have a lot of LUTs but yeah, it's that cheap. includes an FT2232C (i think) as well for uart+programming
<DaKnig>
yeah I saw that, ~1k 4LUTs
<DaKnig>
the english on their website is flaulas
<sorear>
8MB, hmm
anuejn[m] is now known as test[m]
test[m] is now known as anuejn[m]
anuejn[m] is now known as anu3jn
<Lofty>
kbeckmann: just set your expectations for the hardware pretty low. What I've reversed of its timings makes the UP5K seem speedy.
<kbeckmann>
alright, that's fine. for now i am targeting a blinky :). i'll have some questions regarding abc9 later, not really sure how to use it.
<Lofty>
Sometimes it's just add water :P
anu3jn has quit [Quit: authenticating]
anu3jn has joined #nmigen
<Lofty>
On a tangential note, I've been experimenting with timings for my FPGA
<Lofty>
SkyWater is actually a lot faster than I was expecting
<Lofty>
I have a LUT7 with a 900ps propagation delay
<Lofty>
For comparison, Xilinx Series 7 and Intel Cyclone V are both 600ps for LUT6s
<Lofty>
On 28nm processes
<Lofty>
And a SkyWater LUT6 is 700ps or so
<anuejn>
uuuh nice
<Lofty>
(why do I get the feeling the major vendors have been holding back?)
<Lofty>
Anyway, even if I trade off delay for area by using the high-density cells instead, I'm at 1450ps for a LUT7
<Lofty>
Which honestly isn't so bad
<anu3jn>
A lut7?
<sorear>
are you sure the intel/xilinx numbers don't include any routing delay?
<Lofty>
Yes
<Lofty>
I'm using the ABC9 numbers, and I know from the Intel ones at least that they've very much LUT internal
<DaKnig>
Lofty: but how many LUT7 does it have and how much does it cost?
<DaKnig>
maybe Xilinx trades performance for cost or density?
<Lofty>
It's true that there's an area tradeoff
<Lofty>
As for how much my chip costs: I suspect it'll probably be one of a kind
<DaKnig>
LOL
<Lofty>
But hey, "designed and fabbed an open-source FPGA that can run actual code" looks pretty good on a CV I think
<whitequark>
reality: people who understand what that is don't look at CVs. people who don't will require "at least an MSc in computer science"
<anu3jn>
And hey, its a super cool learning process :)
<Lofty>
True, I guess
<anu3jn>
Lofty, are you planing on building a lut7 based fpga?
<anu3jn>
Or was this just some random side experiment?
<Lofty>
Well, there's the Google shuttle program, so I decided "why not"
<daveshah>
I expect some more synthesis work might be needed to make optimal use of lut7s
<daveshah>
will they be fracturable?
<Lofty>
Yes
<anu3jn>
Is there any literature on the optimal n for n-lut?
<Lofty>
Two pairs of LUT5s that share inputs
<daveshah>
nice
<sorear>
imo lut size is mostly set by an optimization trade between the delay/size of your LUTs and the delay/size of your routing network
<anu3jn>
Ah i see
<sorear>
routing cost is superlinear with size, which incentivizes larger luts
<anu3jn>
That makes sense
<sorear>
I don't have a clear idea how fracturability fits in here though
<cr1901_modern>
whitequark: Making remaining changes now. I forget... you want me to rebase all your requested changed into one commit or have them separate?
<Lofty>
anu3jn: a fair bit; LUT4s are the best tradeoff of delay/area product for non-fracturable LUTs, which is why they're so common
<Lofty>
sorear: fracturability and overprovisioning pushes the formula further to larger LUTs
<anu3jn>
Do you already know how (with what tool) you will do the macro grid layout of your chip?
<Lofty>
daveshah: 12 inputs, 4 outputs; you could argue it's LUT5 based with extra muxes up to LUT7
<daveshah>
any plan on how carry logic will fit into that?
<daveshah>
could probably have up to 4 adder bits in that structure
<Lofty>
If you have the LUTs do like sum and carry reduction of the inputs, yeah
<whitequark>
cr1901_modern: squash it all
<Lofty>
Or maybe generate/propagate for an LCU adder?
<cr1901_modern>
Yes, I could actually read the entire docs and do that too :).
<cr1901_modern>
>channel.set_combine_stderr(True)
<cr1901_modern>
I'm excited! I've wanted this feature in an FPGA build system for so long and it's almost here!
<sorear>
which vendors do carry lookahead and which just have hard majority gates?
proteus-guy has quit [Ping timeout: 260 seconds]
<Lofty>
sorear: Xilinx has carry lookahead. Beyond that... Intel has a kinda weird carry select and I'm not sure about the others
<daveshah>
ECP5 has some degree of carry lookahead, aiui
<daveshah>
ECP5 carry isn't that different to Xilinx functionally, although it is structured a bit differently primitive wise
proteus-guy has joined #nmigen
proteus-guy has quit [Ping timeout: 256 seconds]
<emeb>
Is there somewhere I can find an example of using a platform's connectors? All the examples I've seen so far just use named resources.
<_whitenotifier-b>
[nmigen] cr1901 synchronize pull request #461: SSH Client Support via Paramiko - https://git.io/JJarq
<cr1901_modern>
Damnit, I forgot something. Hold on...
<_whitenotifier-b>
[nmigen] cr1901 synchronize pull request #461: SSH Client Support via Paramiko - https://git.io/JJarq
<cr1901_modern>
whitequark: Should be ready, barring any last min changes you want
<kbeckmann>
yay, running blinky on tang nano with nmigen. but i have to clean up this mess a bit before commiting. also i think we need to add proper pin mappings somehow, not sure how though. currently using the raw pad names.
<kbeckmann>
i'll make it work with both eventually, but it was more fun to start with this :)
<whitequark>
yeah, that's ok, i was just not aware that the FOSS tools can do this
<cr1901_modern>
whitequark: Oooh I see what you mean now re: return values. Uhhh... encode/decode("utf-8") should work I think?
<cr1901_modern>
Anyways I would've caught this if my test script retrieved a text-mode artifact as well as binary one
<daveshah>
The FOSS gowin tools are definitely under-appreciated
<whitequark>
cr1901_modern: that should work i think
<cr1901_modern>
The build artifacts scheme makes SO much sense now that there's a remote strategy. I was scratching my head at why you did things this way before then
<cr1901_modern>
(i.e. copying an already existing local file to a tmp dir)
<whitequark>
yep
ryang14 has joined #nmigen
<whitequark>
i made a very similar script for artiq, but it was an awful hack and it never truly worked
<cr1901_modern>
Next we need a ZMODEM strategy :D
<whitequark>
(because the builds weren't sealed)
<whitequark>
the nmigen one does work
<cr1901_modern>
sealed?
<whitequark>
sell
<whitequark>
*well
<whitequark>
they could freely refer to anything in the host system
<whitequark>
by path
<whitequark>
in nmigen you have to add files with their content
<whitequark>
it's not actually enforced, which will weaken it, but also make it somewhat less annoying to use
ryang14 has quit [Ping timeout: 245 seconds]
<kbeckmann>
Lofty: how do i figure out how to map pads on a package to e.g. R11C10_IOBA ?
<cr1901_modern>
Is... is literal backslah legal in a POSIX path?
<Lofty>
Ugh, probably a question for Pepijn, kbeckmann
<kbeckmann>
oh sorry
<Lofty>
Gowin isn't really my area ^^;
<DaKnig>
linux allows this :)
<cr1901_modern>
huh...
jeanthom has joined #nmigen
<whitequark>
cr1901_modern: yes
<whitequark>
anything is ok except / and \0
<whitequark>
in a file/directory name that is
<whitequark>
this is kind of stupid and causes all sorts of problems, but arguably any other arrangement is basically the same just with different issues
<cr1901_modern>
Right...
<cr1901_modern>
In the docs for add_file, you say "The file name can be a relative path with directories separated by forward slashes (``/``)."
<whitequark>
the only way to soundly address this problem i can imagine is enforcing a specific encoding/character set in the kernel *and be able to do a lossless transformation for noncompliant data*
<cr1901_modern>
Is this intentional- i.e. the user's responsibility?
<whitequark>
i.e. the user provides a POSIX path
<cr1901_modern>
Okay, then pathlib.PurePosixPath will do the right thing like you said.
<whitequark>
the build system though might or might not use POSIX paths depending on whether your OS (for the local builds) is POSIX
<whitequark>
since windows also understands / as a path separator this requires no additional work from me, unless you use an UNC path as a root
<whitequark>
which is actually probably a bug that should be fixed, but on the other hand i bet every FPGA toolchain will break in amusing ways if you use UNC paths
<whitequark>
so it's not very urgent to fix it
<cr1901_modern>
I'm not about to try, tbh
<cr1901_modern>
>the build system though might or might not use POSIX paths depending on whether your OS (for the local builds) is POSIX
<cr1901_modern>
If by "build system" you mean the FPGA vendor tools- IME this only becomes an issue w/ cygwin. Which is a non-issue here :).
<cr1901_modern>
and it's not b/c of the path separators, but everything else
<whitequark>
cr1901_modern: i mean nmigen.build
<cr1901_modern>
The correct way to convert a backslash path to forwardslash path is to either do a string replace with os.path.sep or to split with os.path.sep and then do os.path.join.
<cr1901_modern>
Since BuildPlan files are already gonna be posixy, I'm not doing that dance.
<whitequark>
more like PosixPath.split or something
<emeb>
The board's not built yet so this isn't tested in hardware yet, but simulation looks good.
<whitequark>
emeb: very nice
<emeb>
whitequark: I'm sure my style needs work - it's very early days for me. But at least it builds.
<whitequark>
emeb: i skimmed your code real quick, nothing caught my eye, so i'm pretty sure there's nothing especially bad with the style
<emeb>
whitequark: Cool - thanks!
<whitequark>
i didn't try to review it carefully (and i don't even understand the domain) though
<d1b2>
<TiltMeSenpai> how do people sim gateware that has physical feedback and stuff?
<whitequark>
bottom line: good work
<whitequark>
TiltMeSenpai: have a concrete example?
<d1b2>
<TiltMeSenpai> I've just kinda been building and test/guessing ADC's/capsense stuff, but I'd rather be simming it, just not sure how to get started
<emeb>
thanks! I'll have boards to build in a few days and then I'll know for sure if it works.
<emeb>
TiltMeSenpai: you talking about trying to do mixed-signal simulation with the caps in the loop?
<d1b2>
<TiltMeSenpai> at a high level, sort of
<miek>
emeb: nice!
<emeb>
thx miek
<emeb>
Looking at the timing I got from nextpnr this should run > 100MSPS if I get a better ADC.
<emeb>
one wonders if the i/o is good enough for that...
<d1b2>
<TiltMeSenpai> the other possibility is I've been sort of working on something to report register values over USB using LUNA-based gateware, I guess that would be abusable as a limited ILA
<whitequark>
you are not using IO registers, so no
<d1b2>
<TiltMeSenpai> report rate is 1khz but you could write buffers and stuff
<emeb>
easy enough to add i/o regs.
<whitequark>
indeed
<miek>
luna's got an ILA too btw. there are a few outstanding bugs to work around, but i found it very useful for debugging amalthea things
<emeb>
usb-based?
<d1b2>
<TiltMeSenpai> oh cool I might need to look at how that's implemented
<d1b2>
<TiltMeSenpai> HID gives me a headache
<miek>
oh wait, i'm being dumb. it depends on having bits of LUNA hardware
<miek>
(it speaks SPI to the mcu on LUNA)
<d1b2>
<TiltMeSenpai> ah
<d1b2>
<TiltMeSenpai> I mean I could do something like make a glasgow applet that speaks the same SPI protocol 😛
emeb has quit [Quit: Leaving.]
<_whitenotifier-b>
[nmigen] cr1901 synchronize pull request #461: SSH Client Support via Paramiko - https://git.io/JJarq