<whitequark>
is there a stylesheet you're using or something?
<Falteckz>
Looks like the real name can be anything ASCII including colons and spaces, so that seems to be two votes yes for URL in the whois
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
<d1b2>
<Falteckz> Neat, I'm a bot.
<agg>
is it piping everything from 1bitsquared discord general room into nmigen or is there an nmigen-specific room on that discord server?
<d1b2>
<edbordin> there's an nmigen room
<Falteckz>
.There is an nmigen room on the server
<Falteckz>
and the irc bridge creates a "Bot" instance for each IRC user which is the hottest part
<d1b2>
<Stary> well, webhooks are allowed to specify a username for every message they send - so bridgebots end up using it as a workaround for lack of proper impersonation
<d1b2>
<Stary> it sucks a bit but works ok most of the time
<Falteckz>
That's a very neat feature.
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #nmigen
<agg>
a bit surprised freenode's ok with it not impersonating each discord user but i guess it's ok for small bots in single rooms
<agg>
there's various problems around that with the matrix to freenode bridges
<whitequark>
i'd prefer if it impersonated each discord user tbh
<Falteckz>
Connection limit per IP address?
<agg>
it makes for wicked netsplits when the bridge disconnects
<agg>
but this way means you can't tell from irc who's reading messages, can't tab complete nicks, etc, which is a shame
<esden>
humm, the real name seems to be cutting off the remainder of the url I added there
<esden>
at least looking at it here from IRCCloud
<Stary>
i see * [d1b2] (~d1b2@cdr.esden.net): 1BitSquared Discord Bridge https://1bitsquared.com
<whitequark>
it's one of the more blatant legacies of colonial crimes
<whitequark>
well, not even legacies, it's ongoing
<whitequark>
pretty awful situation no matter how you look at it
<Falteckz>
Yeah - not the only TLD to have this strife
jaseg has quit [Ping timeout: 272 seconds]
<Falteckz>
Plenty TLDs seem "fun" in English and so some companies open shells in a region to then use that domain
<Falteckz>
That that's less of a problem I think.
jaseg has joined #nmigen
<Falteckz>
I really take page faults for granted. When you're in an environment that just bricks on an invalid memory read instead of exploding, it's a struggle.
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-guy has joined #nmigen
PyroPeter_ has joined #nmigen
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/JJJ0L
<_whitenotifier-f>
[nmigen/nmigen] whitequark c202661 - docs: rewrite install instructions to be easier to understand.
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+2/-0/±15] https://git.io/JJJ0Y
<_whitenotifier-f>
[nmigen/nmigen] whitequark 28cc0de - Deploying to gh-pages from @ c20266164d76c6cf74c9337732555463b39721ba 🚀
<d1b2>
<edbordin> I mean, pipenv is more or less a chaotic approximation of npm
<Falteckz>
There have been a lot of issues opened about `--user` in .venv, in fact it's even worse as some people have `user=true` in their global pip config. So all venvs are broken.
<whitequark>
pretty much damn anything works better than the python status quo
<Falteckz>
Anyway, all the issues seem closed by stale[bot] now
<d1b2>
<edbordin> my main issue with pipenv is the CLI is almost as poorly designed as git
<whitequark>
i keep looking at pipenv and poetry but neither seems to be ready to introduce new users to
<d1b2>
<edbordin> it has that whole vibe where one command does wildly different things depending on what flags you give it
<d1b2>
<edbordin> poetry is something I meant to try but never did
<Falteckz>
I for one would welcome anything that isn't pip. Will put ear to the ground and cross fingers
<whitequark>
i think pip is actually one of the few reasonable parts
<Falteckz>
Well if we don't blame pip then where does the fault lie? pip is just an enabler for a poorly defined policy?
<whitequark>
as long as your pip isn't ancient and as long as you don't expect it to maintain a globally consistent set of packages with non-conflicting dependencies it works well
<whitequark>
is there 'the fault'?
<whitequark>
it seems pretty clearly a wicked problem
<d1b2>
<edbordin> I don't mind pip, but requirements.txt is a very limiting way of specifying project dependencies
<whitequark>
yeah
<d1b2>
<edbordin> well, at least if you opt to generate it from pip freeze it is
<Falteckz>
Apparently `--user` inside a `venv` should hard fail in later versions of pip/venv/python/something
<Falteckz>
Fix was meant to roll out Jan 2020
<d1b2>
<edbordin> cool, it should start appearing in distros in 2030
<Falteckz>
No joke, I'm still on Python2 for 90% of the projects I work on
<Falteckz>
Ubuntu doesn't seem to ship with anything higher than 3.6.7 either
<whitequark>
nmigen does still work on 3.6
<Falteckz>
Alright - seems if pip is up to date, omitting `--user` will not hard fail
<Falteckz>
So perhaps I was mistaken earlier
<Falteckz>
_Defaulting to user installation because normal site-packages is not writeable_
<Falteckz>
Seems fine as of pip 20 and Python 3.6.7
<Falteckz>
What's the procedure for installing nmigen-boards, I assume clone and setup.py ?
<whitequark>
yeah basically that
<tpw_rules>
Falteckz: ubuntu 20.04 ships with 3.8
<Falteckz>
I bet people were mad about that 😆
<Falteckz>
whitequark `WARNING: nmigen 0.2 does not provide the extra 'builtin-yosys'`
<whitequark>
yes, the docs are for an unreleased version
<whitequark>
the nmigen-yosys that got installed is a very cut down version that can only convert nmigen code to verilog (and a few more things in the future)
<whitequark>
the yosys that you can use to synthesize stuff is a part of the FPGA family toolchain which i do not document yet
<Falteckz>
Alright. No worries. I would usually have the entire toolchain installed anyway but thought I'd try this new bundled yosys wasm stuff
hitomi2503 has quit [Quit: Nettalk6 - www.ntalk.de]
<_whitenotifier-f>
[nmigen-soc] Fatsie opened pull request #21: [WIP]wishbone.Connector class - https://git.io/JJJhA
<_whitenotifier-f>
[nmigen-soc] codecov[bot] commented on pull request #21: [WIP]wishbone.Connector class - https://git.io/JJJjf
<_whitenotifier-f>
[nmigen-soc] codecov[bot] edited a comment on pull request #21: [WIP]wishbone.Connector class - https://git.io/JJJjf
<_whitenotifier-f>
[nmigen-soc] Fatsie commented on issue #18: Wishbone access from initiator bus with data_width smaller than the one of the subordinate bus. - https://git.io/JJJjT
<_whitenotifier-f>
[nmigen-soc] Fatsie commented on pull request #21: [WIP]wishbone.Connector class - https://git.io/JJJjO
<FL4SHK>
seems I can't get `cover` to work with my `past_rst` signal
<FL4SHK>
`Cover(loc.formal.past_rst)` won't work when `with m.If(rst): m.d.sync += loc.formal.past_rst.eq(0b1)`
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
craigo has joined #nmigen
craigo has quit [Quit: Leaving]
craigo has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
craigo has quit [Client Quit]
craigo has joined #nmigen
electronic_eel has quit [*.net *.split]
electronic_eel has joined #nmigen
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
jordigw has quit [*.net *.split]
alexhw has quit [*.net *.split]
FL4SHK has quit [*.net *.split]
XgF has quit [*.net *.split]
XgF has joined #nmigen
jordigw has joined #nmigen
FL4SHK has joined #nmigen
alexhw has joined #nmigen
<awygle>
whitequark, daveshah: is the weirdness around reprogramming the bitstream flash for ECP5 handled in nmigen or in nextpnr?
<awygle>
that is, making it accessible from user logic requires setting some kind of flag
<awygle>
(sorry for vagueness, i know how to do it in diamond but not in the oss tools)
<daveshah>
Actually nextpnr doesn't support that flag at the moment
<daveshah>
But it is inverse, you need to set the flag to get flash over JTAG while running
<daveshah>
the default is for the flash to be available to the fabric
<daveshah>
When it is supported, I would follow the same approach as Diamond - a SYSCONFIG line in the LPF - so the nMigen side could be shared
<awygle>
oh
<awygle>
hm. on further thought that doesn't make sense as the problem i'm having, which is that i can only program the device once and then i need to power cycle it to program it again.
<awygle>
but i'm only programming it over JTAG using the nmigen openocd flow
<daveshah>
Interesting
<daveshah>
I think someone (ktemkin ?) reported that they needed a REFRESH command added to the svf file
<daveshah>
for a similar reason
<awygle>
hm, i can try that if i can figure out how to do it in the platform file
<awygle>
which i probably can
<daveshah>
It would need the SVF file to be modified, I can't remember any more details tbh
<daveshah>
out of curiosity, how to subsequent attempts to program fail?
<daveshah>
awygle: using Sprite's decode_status_reg tool from the hadbadge, that gives
<daveshah>
Config: SRAM
<daveshah>
ISC enable
<daveshah>
Busy
<daveshah>
BSE error:No error
<daveshah>
Write enable
<daveshah>
Read enable
<daveshah>
so seems like it doesn't quite finish programming properly, but also doesn't actually report an error
<awygle>
cooool
<awygle>
i wonder if that means that it's actually programming, just not reporting quickly enough?
<daveshah>
possibly
<daveshah>
could try increasing some of the runtest delays or similar
<_whitenotifier-f>
[nmigen] whitequark commented on issue #418: Simulation of Verilog output doesn't match nMigen simulation - https://git.io/JJUUZ
<awygle>
it actually seems like that mask should allow passing?
<awygle>
oh no nvm
<awygle>
i did e wrong in my head
<ktemkin>
I do the REFRESH every time; and I think that was because somewhere Lattice said you needed to either do that or strobe PROGRAMN to multiple consecutive configs over jtag
<awygle>
ktemkin: how did you add the refresh to the svf?
<ktemkin>
but I think I wrote it from their recommended process, it worked, and then I didn't test without the REFRESH
<awygle>
that is unfortunate for me, but good to know regardless
<ktemkin>
what board are you using?
<awygle>
a custom one
<ktemkin>
what's doing your JTAG?
<awygle>
Lattice programming pod
<awygle>
it's an FT2232H i think
<ktemkin>
you can probably just create a second SVF with the refresh in it, and then run that first
<awygle>
yeah that's what i'm thinking too
<whitequark>
maybe we should add it to ecppack?
<ktemkin>
I think when I asked about that a while ago, daveshah had a reason it wasn't there
<_whitenotifier-f>
[nmigen] jeanthom commented on issue #418: Simulation of Verilog output doesn't match nMigen simulation - https://git.io/JJUTv
<ktemkin>
which might have just been "none of us have ever validated that it's useful/necessary"
<awygle>
oh is ecppack what's making the svf? that makes sense
<daveshah>
I think the reason it's not there is because I copied from the Lattice SVF generator with default settings and that didn't include it
<daveshah>
But I have a suspicion that their JTAG does send a REFRESH command at the start
<daveshah>
Weirdly, I've never needed it on any of the boards in my possession
<daveshah>
Is this a particularly old or new silicon revision?
<awygle>
it's a 12f? i have no idea what the silicon revision is
<daveshah>
What is the marking?
<daveshah>
In particular the third line
<awygle>
A9421R24
<ktemkin>
awygle: btw, do you have any SPI-flash related options in your platform, like SPI frequency or quad-SPI-mode, or anything like that?
<awygle>
i have a spi flash resource
<_whitenotifier-f>
[nmigen] whitequark commented on issue #418: Simulation of Verilog output doesn't match nMigen simulation - https://git.io/JJUTB
<awygle>
which is directed at the bitstream flash
<awygle>
but nothing else
<ktemkin>
er, sorry, I mean specifically ones related to bitstream generated; which would be in `ecppack_opts`
<ktemkin>
*bitstream generation
<awygle>
i'm not overriding ecppack_opts
<ktemkin>
mm, okay
<awygle>
the separate refresh svf is not helping
<ktemkin>
just wanted to make sure you weren't running into the odd behavior Greg Davill and I have seen sometimes
<awygle>
also, a second board appears to be reconfiguring just fine. which is... troubling.
<daveshah>
That sounds like a late 2019 part but still mask set A
<daveshah>
Like all the ones I have tried
<daveshah>
Maybe a very small percentage just need the refresh
<ktemkin>
I don't entirely see why it's necessary
<awygle>
an SVF for refresh would just shift 79 in to the IR, and Run-Test for a while, right?
<ktemkin>
it goes into initialization mode, and if given test cycles, clears the SRAM
<ktemkin>
but the instructions in the generated bitstream should splork over all of that SRAM anyway, so
<daveshah>
Yep
<daveshah>
One possibility is that the running bitstream causes enough SSO noise or whatever that JTAG is made unreliable at the start
<daveshah>
but I don't think you would get an error code like that
<awygle>
how many run-test cycles should i give it?
<awygle>
it seems to still be reporting Busy
<awygle>
(in the refresh case that is)
<daveshah>
Oh, there is nothing on your board that could be affecting the DONE pin btw?
<awygle>
i hate SVF, my kingdom for a loop...
<awygle>
uh lemme check
<daveshah>
Lattice have a loop extension :)
<awygle>
the done pin is hooked up to an unpopulated LED
<daveshah>
It is possible that it reports busy until done actually goes high
<daveshah>
does it have a pullup?
<awygle>
no
<daveshah>
there should be an internal one, but I'd be curious if adding one changed things
<daveshah>
if it's easy to do
<awygle>
i can certainly drop a scope on there at least
<awygle>
although i guess if the internal pullup is weak enough that might overpower it
<daveshah>
A scope doesn't help that much either, as you can't tell between done being set low internally, because config didn't finish; and done being pulled low externally or just not going high
<awygle>
mhm
<awygle>
i can put a pullup in place
<awygle>
by just shorting the led pad
<awygle>
do i need to do that for INITN as well?
<ktemkin>
before you go too much further
<ktemkin>
what's your JTAG frequency?
<awygle>
i have turned it down a fair bit
<awygle>
it initially was 25 MHz and i brought it down to 5
<trabucayre>
why not using DONE bit in status register( 0x3C) ?
<daveshah>
That is not set
<daveshah>
I can tell from the status register read awygle posted earlier
<awygle>
but doing so in usermode seems to have fixed the problem
<daveshah>
yeah, I suspect the pulled up to pulled down transition when entering user mode was the problem
<_whitenotifier-f>
[nmigen-soc] whitequark commented on pull request #21: [WIP]wishbone.Connector class - https://git.io/JJUkS
<ktemkin>
I'd suspect that after the first configuration, PROGRAMN is held at a voltage close to its threshold
<ktemkin>
and after that, flopping the nearby JTAG lines around could easily cause it to register as little strobes of PROGRAMN
<awygle>
thank you both for your help
<ktemkin>
np
<ktemkin>
that was a fun little mystery
<awygle>
and here i was just thinking "i hate this kind of crap" lol
<ktemkin>
it's a lot more fun when it's someone else's mystery
<awygle>
definitely
<ktemkin>
I remember trying to get configuration working for LUNA on the plane ride to 36c3; and that was a lot less fun
<FL4SHK>
you must be talking about a pre-corona plane ride
<ktemkin>
last December, yes
<whitequark>
interestingly plane rides are some of the safer means of transport right now due to the excellent filtration they have anyway
<FL4SHK>
right
<whitequark>
you'd *think* they wouldn't be, but they are
<FL4SHK>
that's neat
<FL4SHK>
at the very least, better than a bus
<FL4SHK>
or a train
<FL4SHK>
(not that I ever use those)
<sorear>
I wonder how the lower air pressure at cruise affects aerosol transport
<ktemkin>
I have less to worry about, since I already have had the COVID
<whitequark>
oh
<awygle>
i have a negative COVID test after several weeks of what sure _felt_ like the COVID, which makes me wonder if i waited too long to get tested (due to lack of availability) and an antibody test might be positive
<FL4SHK>
I haven't had the disease
<FL4SHK>
nor any disease recently...
<ktemkin>
it felt roughly like a porcupine was living in my lungs, and I have some fun lung damage leftovers
<FL4SHK>
oh my
<awygle>
oof :(
<awygle>
sorry to hear that
<ktemkin>
eh
* whitequark
vows to not go outside again for at least one more year
* awygle
remembers he needs groceries
<daveshah>
And we've got swine flu to look forward to too, by the sounds of things
<ktemkin>
I'm honestly just happy to have not died; given I'm immuno-wonk due to chronic disease anyway
<whitequark>
yeah...
<awygle>
i like "immuno-wonk" as a description
<hell__>
ouch
<daveshah>
Back on the programn issue I remember someone reporting a similar issue with the hadbadge once
<daveshah>
That usually doesn't use jtag but they were; and it also connects programn to an io
<daveshah>
I don't know if it has a pull-up though
<d1b2>
<286Tech> nMigen makes it so much easier to get stuff done, so it's all thanks to @whitequark and all other contributors 🙂
<whitequark>
\o/
<Falteckz>
!! I really can't wait to start implementing my first CPU with nMigen. I got started with Verilog but after burning a few hours on describing the logic it became an up hill struggle. Just looking at nMigen examples I can already imagine what I need to write. So I'm quite excited to get that opportunity.
<d1b2>
<286Tech> The problem is that I'm way too busy with getting my PhD (which involves ASICs and VHDL), and I simply don't have enough time to spend on languages/tools that make it more difficult than necessary to build stuff with.
<d1b2>
<286Tech> Of course I could write this all in VHDL/Verilog, but I wouldn't because it would take too much time.
<d1b2>
<286Tech> I seriously spent more time on dumping the raw image over to the FPGA board, because minicom interprets files as text and not as binary.
<d1b2>
<286Tech> 😂
<whitequark>
i, too, do not have enough time for verilog
<d1b2>
<286Tech> A simple cat marisa.data > /dev/ttyUSB1 solved the problem.
<d1b2>
<286Tech> I had to use VHDL for my ASIC stuff, because I need to instantiate specific cells. Yes you can do it with nMigen as well, but that was before I started using it.
<smkz>
nmigen is so good
<d1b2>
<286Tech> Wish I had started using it before.
<smkz>
so much less painful and frustrating that verilog
<d1b2>
<286Tech> yup
<d1b2>
<286Tech> Every time I'm still amazed at all the cool tools we have at our disposal. Many cool languages (nMigen, SpinalHDL, Clash, etc.) and non-bloated synthesis and PnR tools.
<d1b2>
<286Tech> That's why I appreciate all the hard work that all the people in this community put into it. ❤️
<Falteckz>
The part I'm most thankful of is a stdlib to be honest. Thank goodness I don't have to think about CDC. Not to mention something like wishbone or just adding a pipeline becomes easily composable. On top of that, something like nMigen can add build time assertions such as clock domain crossing or, if needed, assertions about signed-ness
<whitequark>
well, you do kinda have to think about CDC
<whitequark>
but you have something to build on
<whitequark>
and it's much harder to accidentally make a mistake
<d1b2>
<Darius> standard libraries define idioms which also help make code understandable/shareable between projects IMO
<whitequark>
yep
<awygle>
and Someday (TM) we'll track CDCs and it'll be even harder to make a mistake
<whitequark>
yep
<Falteckz>
They are somewhat tracked alright, right? Multiple Clock Domains cannot share Syncronous logic.
<awygle>
you can't write to something in multiple domains, but you can read from it from multiple domains, even without putting a synchronizer in between