electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel_ has joined #nmigen
FL4SHK has quit [Ping timeout: 256 seconds]
FL4SHK has joined #nmigen
electronic_eel_ has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
bsmt has quit [Excess Flood]
bsmt has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 272 seconds]
PyroPeter_ is now known as PyroPeter
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
proteusguy has quit [Ping timeout: 246 seconds]
proteusguy has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
falteckz_ has quit [Quit: Leaving]
Bertl_oO is now known as Bertl_zZ
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 256 seconds]
peeps[zen] is now known as peepsalot
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #nmigen
jeanthom has joined #nmigen
korken89 has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
<korken89>
Is there something built into nMigen to declare signals in modules as input/outputs?
<korken89>
I quite like what I saw in anuejn's code where there was `self.signal @ DOWNWARDS` for example, and I'm thinking if something similar can be done for output/input definitions
<whitequark>
not yet, there is an open issue for that
<korken89>
Cool, I'll have a look!
_whitelogger has joined #nmigen
<anuejn>
korken89: you should be able to use the stream abstraction from that repo without most of the other stuff
<anuejn>
If you are intersested i can try to repackage some of that code as a seperate libray
<korken89>
I'm thinking about trying to lift out portions of it, it's quite handy for streams
<korken89>
Just one question that I am not sure of, how do you packet the data to send it over the FTDI FIFO? I mean, start of packet, etc etc to synchronize to the data stream on the PC side
<korken89>
The stream seems to be just that, a stream, without any synchronization added?
FL4SHK has quit [Ping timeout: 260 seconds]
FL4SHK has joined #nmigen
<korken89>
Btw, which is the recommended version to use right now of nMigen? Should one use the released 0.2 or follow the git master? 0.2 seems sort of "old" with its release last Feb.
<anuejn>
the aligning is a bit funky here because we want to avoid coppying the stream and one must request multiples of the buffer size from the ft601
<anuejn>
whitequark: what do you mean by "In cases like this it's OK to do cross-cutting changes through the entire vendor/ subdirectory; you don't need to change any platforms you aren't familiar with."?
<whitequark>
anuejn: I meant that making a change to build.plat and the relevant vendor platforms in one commit makes sense
<whitequark>
but the way I wrote it could be read as me asking you to fix *all* SDC-using platforms
<whitequark>
which I tried to clarify but probably just made it more confusing instead
<anuejn>
ah okay so I tested it for machxo and ecp5
<anuejn>
so these should be done in one commit and the others should be untouched?
<whitequark>
basically, what i want is one bug per commit, because when someone inevitably investigates the history to understand why it's like that, this will be the easiest to understand
<whitequark>
i end up doing massive amounts of VCS archaeology, which is why i'm so insistent on keeping an easy to understand history
<korken89>
whitequark: I'm quite amazed at the design and work that has gone into nMigen, and this makes me quite curious about its future! Is there some design document or similar about where nMigen is heading?
<whitequark>
korken89: I'm afraid there isn't a single document at the moment; after the 0.3 release I'll make sure to write one
<korken89>
No problem! :)
Bertl is now known as Bertl_oO
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
emeb_mac has joined #nmigen
SpaceCoaster has joined #nmigen
SpaceCoaster_ has quit [Ping timeout: 260 seconds]
<kmc>
yeah. I saw the one for lattice's eval board
<awygle>
so pip search is just ... busted now
<whitequark>
yep
<awygle>
i <3 python
<awygle>
the pip github issue where all the devs are like "wait do people actually use search" is darkly amusing too
<whitequark>
i didn't even know it existed until someone near me complained
<awygle>
i use it literally any time i install a package
<awygle>
to confirm 'yowasp-yosys' is actually yowasp-yosys and not YO We Are Stealing People's identity
<awygle>
or even just to figure out if it's yowasp-yosys, yosys-yowasp, python-yowasp-yosys, or whatever
<whitequark>
hm
<whitequark>
but... that doesn't work
<whitequark>
suppose someone tomorrow publishes all of yowasp's packages with the order reversed
<whitequark>
or, like, hijacks yowasp-nextpnr-nexus or something.
<whitequark>
on the web interface you can confirm i've actually published those, but not via pip search
<awygle>
then when i run pip search yowasp i'll see >1 result for yowasp-yosys and know something is up
<awygle>
as opposed to if i just guess
<awygle>
i didn't think of the web interface as an alternative i guess? the web interface feels more like a failure mode tbh, idk
<whitequark>
your use case seems to be one of those marginal ones where it provides just enough benefit to make a viable claim that it's useful, but then it totally falls apart if you examine it