<mcc111[m]>
sporniket omnitechnomancer: So… do I have this right, the HDMI is *not* being handled by the board, it's just wires run through to the FPGA, but not all the wires in the port are actually passed through? I wonder why they did that, could it really have cost more to draw a couple extra traces…
mindw0rk has quit [Ping timeout: 255 seconds]
<omnitechnomancer>
On the colorlight breakout yes the diffpairs are wired to diffpair IOs and no HDMI tx is present. The likely reason for the rest of the signals being absent is that there are already not quite enough IOs for the connectors on the board
<mcc111[m]>
omnitechnomancer: Thank you for explaining
<omnitechnomancer>
I think if I were to do a breakout I would probably do magjacks (at least have the footprints) and probably drop one PMOD connector, have a dedicated SPI and UART to the programming micro (rather than sharing) probably have optional tap points for them too, and at least hook up the rest of the HDMI connector signals
<omnitechnomancer>
That warning is that the IDCODE of the FPGA on the module is the one with SerDes
<mcc111[m]>
Do you mean, the module it tried to build for expected SerDes and they are not found, or the module on my desk has SerDes?
<mcc111[m]>
I saw you and sporniket mentioning SerDes earlier, I looked it up on wikipedia and their description of it makes a lot of sense but I don't have personal knowledge of how the SerDes would be applied.
<omnitechnomancer>
Reading the message closely it is the bitstream built for SerDes but the FPGA not having them (the bitstreams are compatible otherwise)
<omnitechnomancer>
SerDes is a generic term somewhat but here refers to the hardware used to run high speed serial links
<omnitechnomancer>
Having dedicated hardware blocks on the FPGA allows higher speeds since the fabric doesn't have to run at the bit clock
<mcc111[m]>
omnitechnomancer: Okay. And this is a limitation of the actual ECP5 chip I bought, not the ext board?
<mcc111[m]>
It sounds like that's an unfortunate limitation, but it seems unlikely it would impact the blinkable LED.
<omnitechnomancer>
What is a limitation? The i5/i9 modules do not use the M models with SerDes and don't break the dedicated pins out
<omnitechnomancer>
Does the blinky request the LED resource? Also which platform is it using?
<omnitechnomancer>
Ah I see the trouble, the ECP5 platform that template uses is the VersaECP5 board platform, so it will almost certainly not have the led on the same io pin
<mcc111[m]>
<omnitechnomancer> "Ah I see the trouble, the ECP5..." <- Okay, great. So I think what I need to do is either change it to use the colorlight i5 board from amaranth-boards, or create a new colorlight i9 board and compare the pins in the wuxx project verilog. (I think the two colorlight ext boards are the same, assuming that the colorlight i5 board in amarnath-boards is the MuseLAB board)
<omnitechnomancer>
If you look in the pull requests there is an i9 board one, that may help comparing them
<omnitechnomancer>
The breakout boards are the same but I am not sure the FPGA pin assignments are the same between them
<whitequark[cis]>
alternatively: each IO pin is a PHY
<whitequark[cis]>
just a very simple one
<galibert[m]>
"You're a PHY ! You're a PHY ! You too you're a PHY !"
adamgreig[m] has joined #amaranth-lang
<adamgreig[m]>
mcc111: yea, the fundamental problem is the template-fpga repo is just for the VersaECP5Platform, it doesn't have any way to know you actually wanted a colorlight i9, and they have somewhat different FPGAs and totally different pin assignments (ie where the clock is coming in, where you want the LED to be going out, etc). ecpdap is saying "you are trying to program an LFE5U-45 (what it's detected on the i9) with a bitstream built
<adamgreig[m]>
for an LFE5UM-45 (what's fitted on the Versa board fpga-template is targeting); normally programming wouldn't work at all, but those two FPGAs are compatible enough that you can just replace the ID check in the bitstream with the correct ID and then programming succeeds, which ecpdap does for you
<adamgreig[m]>
(in fact the theory is they're actually the exact same except for a different ID programmed for market segmentation, but in theory the difference is your one "doesn't have" SERDES and the versa one "does have" serdes)
Wanda[cis] has joined #amaranth-lang
<Wanda[cis]>
if by "theory" you mean "it's blindingly obvious that it's the same chip", yes
<adamgreig[m]>
Has anyone actually tried using the serdes on the non-m labelled chips? I also firmly believe they're the same (hence writing this feature for ecpdap) but I've never actually heard of it being verified
<adamgreig[m]>
They go to the bother of fusing a different idcode, they could also fuse off the serdes
<Wanda[cis]>
hm
<Wanda[cis]>
are they even bonded out on ecp5?
<Wanda[cis]>
eg. Xilinx makes the question moot on spartan 6 by simply not bonding out the transceiver pins, including the power pins
<Wanda[cis]>
so there's no way it could work
<adamgreig[m]>
on most packages the balls are present but "nc" for the lfe5u and serdes/power for lfe5um
<adamgreig[m]>
on the smaller 256-ball packages there's no serdes balls and you can't buy an lfe5um in them
<adamgreig[m]>
i haven't tried measuring it, I guess even a multimeter might check just how nc the balls are before bothering soldering one to a test board
<adamgreig[m]>
I do have a bunch of lfe5um in use on lfe5u boards where those balls are left nc, because I couldn't buy the lfe5u at the time, but never tried the other way around
<Wanda[cis]>
oh, I see
<Wanda[cis]>
then it's worth a shot, I suppose
<Wanda[cis]>
but there's high chance they're doing binning, so the transceivers may be ... wonky
<zyp[m]>
IIRC somebody did the multimeter check and found they seemed to be connected somehow
<adamgreig[m]>
I seem to remember seeing that much
<zyp[m]>
but I'm not aware of anybody actually trying the serdes functionality yet
<omnitechnomancer>
the platform in cradle doesn't have the two RGMII interfaces
sporniket has joined #amaranth-lang
<sporniket>
True, as I said I started it with just the things I was able to test. I will reuse more of the work done by others with time, and contribute my self, but for my first milestone I just wanted to get an HDMI blinking.
Darius has quit [Ping timeout: 258 seconds]
sporniket has quit [Quit: Client closed]
<galibert[m]>
blinking hdmi is not good
<galibert[m]>
monitors hate that :-)
<mcc111[m]>
<sporniket> "about board platform, long ago..." <- Okay, awesome! After pulling in the i9 boardfile from this PR I could make the colorlight colored light blink.
<mcc111[m]>
I did have to comment out "openFPGALoader" in the `super().required_tools` because I'm using ecpdap instead of openFPGALoader.
<mcc111[m]>
Is it really correct that a tool can be in required_tools even if it's only needed for programming, not building?
<mcc111[m]>
Also: it looks like the i9 boardfile is from 2022. What would need to happen for it to get merged into amaranth-boards? Is there testing I could do to verify it's correct?
<mcc111[m]>
* i9 boardfile PR is from
<galibert[m]>
the problem with -boards is that chaterine is unhappy for good reasons with the current implementation of platform
<galibert[m]>
that does not encourage merging new stuff
<whitequark[cis]>
please do not speak for me, galibert
<whitequark[cis]>
the main reason the i9 boardfile isn't merged is just that I didn't have time to do it
<galibert[m]>
Sorry, removed
<whitequark[cis]>
we do need to set up procedures to make sure it's easier to do, but I don't think there's any issue with merging that one in particular if it's tested
<whitequark[cis]>
thank you
<whitequark[cis]>
the issues you mention exist but they're more structural and long term
<whitequark[cis]>
it doesn't preclude merging board files
<whitequark[cis]>
it just needs a bit of my time
<galibert[m]>
Yeah, quite reasonable
<whitequark[cis]>
also, I'm in the process of redesigning the way stdio cores will work with jfng, which will actually solve a lot of the issues with amaranth-boards
<mcc111[m]>
whitequark[cis]: Is it a problem that the i9 (and i5; the one checked in now) refuse to build without openfpga, even though it is not actually a requirement for the *build* step (only the *program* step)?
<whitequark[cis]>
openfpga?
<whitequark[cis]>
I'm confused
<galibert[m]>
openfpgaloader
<whitequark[cis]>
oh.
<whitequark[cis]>
mcc111: I think we have a bunch of board files like this... it's an inconsistency/deficiency in the system
<mcc111[m]>
ok. thanks for the explanations
<mcc111[m]>
and yeah sorry i keep mixing openfpga and openfpgaloader up
<mcc111[m]>
analogue openfpga really is \a bad name
<galibert[m]>
There is a similar issue with not being able to generate verilog for ecp5 if you don't have nextpnr-ecp5, that kind of stuff. But it's hard to say what you're going to do
<galibert[m]>
And command not found is not a very good user interface
<mcc111[m]>
would a possible fix be to have required_tools optionally be a dictionary instead of an array? { "*": "yosys", "build": "", "program", "openfpga" } for example.
<whitequark[cis]>
that would need an RFC
<galibert[m]>
Huhuhu, I almost answered that but didn't dare :-)
<mcc111[m]>
whitequark[cis]: okay. maybe i'll write one
<galibert[m]>
There is a need for changes in that area, going step by step would be perfectly sane
<jfng[m]>
we have nothing particular on the agenda today, so we can talk about anything you want
<jfng[m]>
galibert: i'm working on the changes to `MemoryMap` that will allow us to port every other -soc elaboratables to Components
<jfng[m]>
should be ready this evening
<galibert[m]>
That will be so cool
<jfng[m]>
otherwise, Catherine and I have been fleshing out the metadata for the Peripheral API, which should result in some RFCs in the coming week or so
<jfng[m]>
and also on our future verification strategy for -stdio cores
<whitequark[cis]>
yep, I've got a lot of confidence in that we'll have a good strategy for verifying I/O cores soon (and systems with I/O cores)
jjsuperpower has quit [Ping timeout: 248 seconds]
<whitequark[cis]>
at first just Python, later CXXRTL
<galibert[m]>
Verifying means what exactly?
<galibert[m]>
Testing, formal proving?
<whitequark[cis]>
both but at this stage primarily unit testing
<galibert[m]>
Good start. Do you think it’s possible to have an equivalent of coverage measurement for netlists ?
<jfng[m]>
besides traditional unit test coverage metrics (python -m coverage ...) is that even a thing ?
<galibert[m]>
I was thinking more like coverage of the possible enable signals, enum values, that kind of ideas?
<galibert[m]>
Whether some parts of the netlist end up constant for the set of tests
<galibert[m]>
whether all ifs have been enabled on all paths, all cases "taken", etc
<jfng[m]>
i don't know for simulation, but that MCY tool seems to do that for formal ?
<galibert[m]>
Seems to be.. fuzzing?
<jfng[m]>
agreed that python coverage is not going to help much here, except for static parameters
<galibert[m]>
I think Catherine 's work on the new IR/netlist could open the door to that kind of tools
<whitequark[cis]>
there is toggle coverage
<whitequark[cis]>
which is a good start
jjsuperpower has joined #amaranth-lang
jjsuperpower has quit [Ping timeout: 260 seconds]
jjsuperpower has joined #amaranth-lang
<crzwdjk>
I am definitely interested in better stdio cores and also in their verification.
<galibert[m]>
I'm not sure I understand yet what -stdio is supposed to cover but Ill be happy to learn
<whitequark[cis]>
SPI<>Stream converter for example
<crzwdjk>
SPI flash reader? Or does that go on top of the SPI-stream converter?
<galibert[m]>
that's not -soc?
<whitequark[cis]>
nope, that's -stdio
<crzwdjk>
You can use streams without any kind of CPU, and I do
<whitequark[cis]>
-soc has Stream (of SPI control/data words) <> Wishbone
<galibert[m]>
you can use wishbone without any kind of cpu
<whitequark[cis]>
-soc does not in fact imply there is a CPU
<galibert[m]>
yeah
<whitequark[cis]>
but it does imply there is a "system" on the "chip"
<whitequark[cis]>
(computing system involving computer buses)
<crzwdjk>
But "bus" seems to me to be a different abstraction from "stream", and I suppose -soc is about buses and -stdio is about streams. Makes sense.
<whitequark[cis]>
basically
<whitequark[cis]>
it's possible (though not very likely currently) that the two would get merged
jjsuperpower has quit [Ping timeout: 248 seconds]
GenTooMan has quit [Ping timeout: 248 seconds]
GenTooMan has joined #amaranth-lang
catlosgay[m] has joined #amaranth-lang
<catlosgay[m]>
mcy is slightly different from other forms of coverage
<catlosgay[m]>
mutation coverage is primarily useful for testing how complete your assertions are
<catlosgay[m]>
whereas you can very much still do toggle/enum etc coverage in formal (and sim)
<catlosgay[m]>
but those test that your environment (mainly stimuli in sim and assumptions in formal) tests interesting parts of the state space, and gices confidence it isnt overconstrained
<catlosgay[m]>
s/gices/gives/
<catlosgay[m]>
whereas mutation coverage checks that the assertions specify a fairly constrained set of behaviours and mutating the design (in ways that hopefully introduce behaviours similar to what you might expect from a design bug) is caught by your checkers
<catlosgay[m]>
fwiw ive seen mutation coverage get relatively little interest industrially compared to toggle coverage/fsm coverage etc type metrics