06:28 <jwise0[m]> . o O ( wonder how feasible it is to have a yosys pass or Amaranth pass by default on glasgow applets to do CDC )

06:32 <whitequark[cis]> and how do you figure out which are the CDC requirements for each signal?

07:01 <whitequark[cis]> that an emulator?

07:02 <nemanjan00[m]> For wiegand, yes

07:02 <nemanjan00[m]> Just sending all 1's to one of those shitty backdoored reader-controller combos

07:03 <whitequark[cis]> backdoored?

07:03 <nemanjan00[m]> Yeah, most of those that come to Serbia can be opened with em4100 with id that is all 1's

07:03 <whitequark[cis]> wtf

07:20 <nemanjan00[m]> I am loving the ability to just remap pins as args... I do not have to think anymore which wire is TX and which is RX 😄

07:26 <whitequark[cis]> nice isn't it?

08:02 <jwise0[m]> similarly to CDC description in other CDC verification systems -- CDC tool understand what clocks have relationships to what through annotations, and then follows rules to infer what signals are associated with what clocks, and warns on known violations (e.g., D pin of a flop is connected to a signal associated with a... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/iATmaKklIBgQaxXRxCpvBQjW>)

08:03 <whitequark[cis]> Amaranth has CDC analysis as an open question and actually being able to do it requires a redesign of the internals (partially complete) so that it has an actual IR

08:03 <whitequark[cis]> sorry, open issue on the tracker, it's one of the very first

08:04 <whitequark[cis]> one big challenge with this is vendor primitives, whose ports are generally not annotated, and in some cases the annotations are extremely complex, bordering on arbitrary code (comparisons on parameters, etc; muxes at runtime also)

08:04 <whitequark[cis]> it's not clear who will e.g. go through the entire Xilinx primitive library and annotate it

08:05 <jwise0[m]> all true problems

08:05 <jwise0[m]> at the yosys level cans olve some of the IR issues but then you don't get nice symbolic info from Amaranth instantiations

08:05 <whitequark[cis]> and unless every primitive that's instantiated is annotated you will potentially have unbounded false positives (because "I don't know the domain" propagates across comb circuits)

08:06 <whitequark[cis]> > it's even a little easier in Glasgow because the PLL hierarchy is known in advance

08:06 <whitequark[cis]> this is not true, PLLs are all left to the use of applets themselves

08:06 <whitequark[cis]> the entirety of Glasgow works off the 48M clock generated by the FX2 from the 12M crystal (well, ignoring various RC clocks in jellybean ASICs)

08:06 <jwise0[m]> Glasgow is a little bit more nicely constrained because iCE40 just does not have that many primitives as compared to the xilinx hellscapes

08:07 <whitequark[cis]> yes, it definitely makes sense to start with ice40

08:07 <whitequark[cis]> but at the same time, it's easy to overfit for ice40, like what happened with the I/O buffer instantiations in Amaranth upstream

08:07 <whitequark[cis]> I think this is a worthy problem to solve but I don't see it really happening for Glasgow in any meaningful timespan

08:08 <whitequark[cis]> and I especially don't see it being reliable enough that automatic instantiation of CDC primitives is a thing

08:08 <whitequark[cis]> in addition, ice40 has weird I/O buffers

08:08 <whitequark[cis]> the tooling (vendor or yosys) cannot pack a flop into an IO buffer

08:08 <jwise0[m]> ahh. in that case you know at least the 48MHz clock I guess, and indeed you do have to have users specify CDC constraints for PLLs, though arguably the claim that 'if you instantiate a PLL, you have to specify its constraints' is a reasonable anti-footgun measure

08:08 <whitequark[cis]> so if you want registers in IO tiles (which you want because nextpnr doesn't have input/output delay constraints) you have to instantiate SB_IO manually

08:10 <jwise0[m]> one thing about CDC as opposed to STA is that for STA, it is completely wrong to say "I don't know, so it is fine". CDC-as-linter as opposed to CDC-as-prover is, however, a methodology that does make sense -- i.e., if we can *only* have CDC complain when it is pretty sure something bad has happened ('there is an outside world pin connected to the D pin of something on the 48MHz clock that is not part of a FFSynchronizer'), even that is a

08:10 <jwise0[m]> meaningful improvement for user ergonomics around novice digital designers

08:12 <jwise0[m]> this is, of course, all easy for me to say as someone who would not be the one doing the work. but if nothing else, it is something to think about, that there could meaningfully be an intermediate step to help users out if it becomes more of a support burden as users get unexpected results developing applets

08:13 <whitequark[cis]> CDC analysis continues to be a goal of Amaranth as a whole, so eventually this will exist

08:15 <jwise0[m]> nod

08:45 <whitequark[cis]> (got interrupted)

08:46 <whitequark[cis]> but I don't really see this being a big part of Glasgow in the short to medium term future, for better or worse

08:46 <whitequark[cis]> I do agree that the goals are desirable, I just don't see the developer resources for it

12:34 <whitequark[cis]> esden: just got the failure where register 0x00 could not be read again, but bizarrely, taking the glasgow out of the case did not help

12:34 <whitequark[cis]> so this is definitely not just the case; it is either debri or maybe a defect in the PCB?

12:35 <whitequark[cis]> I am going to cover SDA/SCL with kapton right now to see if that changes anything; presumably I will eventually get this failure again

14:04 <whitequark[cis]> esden: yeah, it's not the case and not the testpoints; something entirely different that seems mechanical in nature

15:03 <Attie[m]> good to know... any lockup detectable with a scope? (e.g: SCL stuck low)

15:06 <whitequark[cis]> haven't used a scope

15:06 <whitequark[cis]> it's failing more and more often ...

15:07 <Attie[m]> as in working-broken-working-broken-etc...?

15:08 <whitequark[cis]> yeah

15:08 <Attie[m]> weird

16:34 <davidrysk[m]> I get the following when doing `glasgow --version` on macOS:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KySVMYEmwGlUwmmfCXQlyjGI>)

17:24 <dne> looks like the 2nd item under https://docs.python.org/3/whatsnew/3.12.html#other-language-changes

17:58 <Wanda[cis]> <davidrysk[m]> "I get the following when doing..." <- > <@_discord_169816341568684032:catircservices.org> I get the following when doing `glasgow --version` on macOS:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/NbtcxmFpXlLHeRFyEqjTmDad>)

17:59 <Wanda[cis]> I'll clean that up

18:06 <_whitenotifier> [glasgow] wanda-phi opened pull request #485: database.jedec: fix SyntaxWarning. - https://github.com/GlasgowEmbedded/glasgow/pull/485

18:14 <Wanda[cis]> unfortuntely we have been unable to run glasgow on Python 3.12 until very recently due to... sigh reasons

18:15 <galibert[m]> python being python?

18:16 <SnoopJ> aiohttp was part of it IIRC

18:16 <Wanda[cis]> no, due to aiohttp neglecting to make a release that works on Python 3.12 for ages

18:16 <galibert[m]> Ah, that's annoying

18:16 <Wanda[cis]> they still haven't, really; we're relying on an aiohttp beta.

18:17 <SnoopJ> they fixed the main problem *well* before the 3.12 release because other people who tested ahead of time reported it, but there's Other Stuff that is delaying a real release

18:17 <galibert[m]> "Note that the cchardet project is known not to support Python 3.10 or higher. "

18:17 <galibert[m]> beautiful

18:17 <SnoopJ> which is weird because I think the bugs in question were present before 3.12 entered the picture and they just happened to notice them now?

18:18 <Wanda[cis]> basically they tied releasing a 3.12-supporting version with a major bump

18:18 <galibert[m]> Oh, that's annoying

18:18 <Wanda[cis]> despite the only thing actually required for 3.12 support being a dependency bump for cython

18:19 <galibert[m]> Oh, that's very annoying

18:19 <SnoopJ> yes it is

18:20 <Wanda[cis]> btw, glasgow also isn't currently tested on Python 3.13 because of multidict, another aio-libs project, using private Python symbols that got removed.

18:20 <SnoopJ> extension modules use only the public API challenge

18:21 <galibert[m]> Hmmm, my arch which has been updated not so long ago is still on 3.11

18:21 <Wanda[cis]> yeah

18:21 <Wanda[cis]> ... I wonder why

18:21 <galibert[m]> I actually wonder, arch tends to be up-to-date

18:23 <Wanda[cis]> well

18:23 <Wanda[cis]> so the reason is... exactly this

18:23 <Wanda[cis]> they cannot update python version before testing that basically everything they have is actually 3.12-compatible

18:23 <Wanda[cis]> and it is demonstrably not, since they package aiohttp.

18:24 <galibert[m]> Oh

18:24 <galibert[m]> Duh

18:24 <Wanda[cis]> (I have no idea if it is the only blocker or not, but that's the general reason in these cases)

18:25 <galibert[m]> Trying to find out where the list of blocker is (because I'm certain there is one somewhere)

18:30 <galibert[m]> Oh great, the forums require 60 secondes between searches

18:32 <SnoopJ> :|

18:50 <davidrysk[m]> I'm assuming it's unlikely one would be able to run multiple applets on the same glasgow? (Need uart and jtag, probably will just find my uart adapters)

18:53 <Wanda[cis]> that's a long-standing design issue, https://github.com/GlasgowEmbedded/glasgow/issues/180

18:54 <Wanda[cis]> basically: you cannot currently, but that's very much something that's intended to be supported some day, there's just a bunch of infrastructure needed first

20:25 <esden[cis]> Catherine: ok, based on that it is much more likely that your Glasgow is "just":tm: flaky. IIRC the one I sent you was a reworked unit from an assembly run where I was struggling to get them put together right. So it is unfortunate but not surprising if it is some cold solder joint that is causing issues. I will have to send you another unit to replace it.

20:25 <esden[cis]> (there were only a few units in that troublesome build, and this is all I could send you at the time...)

20:26 <esden[cis]> Sorry it is causing confusion and annoyance. :(