<d1b2>
<Olivier Galibert> damn, quartus is so slow and it's not even a big design
<whitequark>
yeah
<d1b2>
<Olivier Galibert> much thanks for making the generated verilog as readable as reasonably possible, it helps finding my mistakes
<d1b2>
<Olivier Galibert> (like putting the DomainRenamer on the wrong submodule, duh)
<d1b2>
<Olivier Galibert> wow, the pll seems to work
<d1b2>
<Olivier Galibert> amaranth is so nice
<whitequark>
\o/
<whitequark>
it could be more readable actually, there's an open issue
gatecat has quit [Ping timeout: 255 seconds]
kmehall_ has quit [Ping timeout: 255 seconds]
kmehall has joined #amaranth-lang
gatecat has joined #amaranth-lang
<d1b2>
<Olivier Galibert> ok, I need to program the hdmi encoder using i2c. I think the smartest long-term is to plonk something generic-ish on wishbone and control it from minerva. I see no i2c master in -soc, is there a known wishbone interface I should follow to make it -soc eligible maybe eventually?
<whitequark>
not yet, it's a short term goal to develop such IP
<d1b2>
<Olivier Galibert> yeah, it looks fun too. So, no usual cpu interface for i2c we'd like to have?
<whitequark>
they're all so disparate...
<d1b2>
<Olivier Galibert> (especially if I stop at a simple i2c that's enough to program stuff on soldered on the same board, with none of the i2c edge cases)
<whitequark>
tbh developing a generic and well functioning I2C peripheral is so difficult
<whitequark>
I think it's fine if you go with your own custom stuff for a bit
<d1b2>
<Olivier Galibert> heh
<d1b2>
<Olivier Galibert> I'm looking at latsemi's doc for what they sell, holy feature creep batman
<gruetzkopf>
*so* many disparate and conflicting things to consider, and for "just" controlling HDMI encoders you shoudl be fine bitbanging it from software..
<whitequark>
lattice's one actually looks alright
<josuah>
taking all the clock stretching and multi-master arbitration away, is what's left reasonable enough?
<gruetzkopf>
also remove fast mode and 10bit..
<josuah>
would that be an 80% of the features with 20% of the code?
<whitequark>
clock stretching is a part of the spec and it is unavoidable
<josuah>
gruetzkopf: but is fast mode not only a matter of tuning the clock up without much software change?
<whitequark>
it's not hard to implement anyway?
<josuah>
all right! I thought it was part of what made it difficult.
<whitequark>
multi-master is nightmarish
<whitequark>
it's not really possible to do correctly, i think
<gruetzkopf>
ah sorry, HS mode, up to FM+ (1Mbit) is just increased clock)
<josuah>
oh so here lies the dragons
<whitequark>
for clock stretching, what you do is you output the clock as per your prescaler, but you clock your own logic with what's actually on SCL
<whitequark>
this causes some issues because I2C needs 90° phase shifted clocks internally
<d1b2>
<Olivier Galibert> clock stretching is the peripheral saying "please wait a little, I'm going to answer, honest" and that can happen at any time
<gruetzkopf>
the "fun" part is when the peripheral gets stuck there
<d1b2>
<Olivier Galibert> then your bus is fucked?
<whitequark>
you can't recover from that in general but you can clock 9 pulses and the bus gets released
<whitequark>
however this may have side effects
<d1b2>
<Olivier Galibert> does it? I thought stretching was the peripheral bringing scl to ground?
<whitequark>
oh sorry I was thinking of when the peripheral and the controller gets desynced
<d1b2>
<Olivier Galibert> also I don't see the point of having the prescaler in the i2c block, and especially making it programmable. It's gimme an enable on the wishbone bus clock and I'll go from there
<whitequark>
yeah if your peripheral gets stuck in clock stretching you can only reset
<whitequark>
re prescaler: what if your system frequency can change?
<whitequark>
Amaranth will have a configurable prescaler at least as an option
<josuah>
<whitequark> for clock stretching, what you do is you output the clock as per your prescaler, but you clock your own logic with what's actually on SCL
<josuah>
was feasibleNice! I thought about something like that, but did not know it would work.
<d1b2>
<Olivier Galibert> whitequark: but shouldn't a configurable timer/prescaler that generates an enable be a module by itself that can be connected to other modules?
<d1b2>
<Olivier Galibert> so you can have fixed or programmable just by swapping modules
<josuah>
although, while supporting it can be nice for an IP core, I am not eager to use it given what you illustrated
<whitequark>
Olivier: I agree, actually
<d1b2>
<Olivier Galibert> 🙂
<whitequark>
and that's the plan I have
<whitequark>
would have to sketch it out
<d1b2>
<Olivier Galibert> cool, the easy modularity of amaranth makes it easier that way, while still efficient
<whitequark>
yeah
<d1b2>
<Olivier Galibert> so there are two opposite possible designs. A serial design where I give bytes on a drq, switch to read at some point if needed, of a flat design where I go smbus-ish and consider that's it's a 128x256 array to write or read registers (128 addresses, 256 registers)
<d1b2>
<Olivier Galibert> wonder what's the smartest
<whitequark>
depends on your goals. the serial one is a lot more flexible. the memory-mapped one isn't exactly i2c
<d1b2>
<Olivier Galibert> my goal is programming my hdmi but also create something useful a little longer-term
<whitequark>
i'd suggest just bitbanging it
<whitequark>
right now we still don't have streams, any guidelines for stdio or SoC, or a process for onboarding new IP cores
<whitequark>
we will but it'll take a bit of time
<Chips4MakersakaS>
Are there much I2C peripherals that use clock stretching ?
<gruetzkopf>
by spec: every single one
<Chips4MakersakaS>
gruetzkopf: I would think most peripherals won't keep SCL low themselves or even have that feature in the hardware.
<whitequark>
it's usually the MCU-based I2C peripherals that do stretching
<whitequark>
but those are important
<whitequark>
people do MCU-based I2C all the time
<josuah>
and might not always tell you that there is an MCU
<josuah>
I had to guess for some sensors/PMIC/camera/...
<whitequark>
yes
<whitequark>
so you are usually rudely awakened to this fact and have to redo your I2C code
<whitequark>
often with bitbanging
<josuah>
i.e. the datasheet specifying errata for one particular firmware version that tells you succintly a number that happen to be an address at which to check ^_^
<josuah>
whitequark: do you mean some incompatible FPGA I2C module, or some hardare I2C not working with a sensor?
<whitequark>
both
<josuah>
oh :(
<whitequark>
it's not uncommon to have your hardware I2C module just not work with some sensor or the like
<whitequark>
and then you're in for pain and bodges etc
<josuah>
Nice! I wish more languages had documents like this!
<josuah>
Is the goal to make it some kind of standard for Amaranth? i.e. allowing multiple compatible implementations?
<whitequark>
no; the goal is to have a process for involving community in the evolution of the language and libraries, rather just having it all done by BDFL decree
<whitequark>
(I hate the idea of being a "BDFL" personally and it is also not sustainable for any project on long enough timescale)
<d1b2>
<Olivier Galibert> whitequark: the language and even more the environment/libs is young, so the benevolent leader model is at that point in the evolution a good idea, I tend to think. Otherwise it will end up as a bad design-by-comittee
<whitequark>
that's effectively how the RFC process currently works
<whitequark>
but I take issue with the "for life" part
<whitequark>
I don't even want to do this for a year, to be honest
<d1b2>
<Olivier Galibert> that will probably depends on how far you manage to push the project and the level of use by people in general
<whitequark>
yeah
<d1b2>
<Olivier Galibert> So, I've been thinking about it, here is the interface I plan to implement for my simple i2c. Two addresses. If you write, a byte is sent on the wire, with a start signal if the bus was idle, write returns when the byte has started being sent. If you read a byte is read from the bus, returns when the byte is fully there. The second address is the same but in addition you get a stop signal and bus idle afterwards. How's that
<d1b2>
for the cpu interface?
<d1b2>
<Olivier Galibert> prescale I keep as an external issue
<whitequark>
that sounds reasonable for a one-off peripheral
<whitequark>
you can't do a repeated start this way
<d1b2>
<Olivier Galibert> it's for the master, but yeah
<whitequark>
I meant SoC peripheral
<d1b2>
<Olivier Galibert> oh ok
<d1b2>
<Olivier Galibert> is repeated start useful/needed?
<d1b2>
<Olivier Galibert> not even sure what it is
<whitequark>
it says it's for multi-master, but that's not true
<whitequark>
some devices need a Sr instead of S
<josuah>
that can save a lot of time if writing large chunks of data over I2C, like calibration data, firmware, or even the whole configuration at once
<josuah>
oh my bad, I am mistaking it with something else
<whitequark>
burst writes?
<d1b2>
<Olivier Galibert> interesting. I don't need it, it could be optionally added as a third address
<d1b2>
<Olivier Galibert> the point is really to keep it simple both in amaranth and in riscv
<josuah>
the low-hanging fruits that are also tasty
<d1b2>
<Olivier Galibert> exactly
<d1b2>
<Olivier Galibert> and when you just want to talk to stuff soldered on the board if may not need all bells and whistles
<whitequark>
it's not an interface I would want to see upstream in -soc
<whitequark>
and I think jfng would agree
<d1b2>
<Olivier Galibert> I'm curious, why?
<whitequark>
false simplicity
<whitequark>
yes, it gets your specific use case done
<whitequark>
but it doesn't consider things like repeated start or NAKs from the peripheral
<whitequark>
it's fine for your design, of course, it's not even a criticism so much as me saying it doesn't meet the criteria for inclusion
<robtaylor>
could live in -orchard?
<whitequark>
shrug
<whitequark>
I'm not so enthusiastic about -orchard becoming a dumping ground for designs with known issues either
<whitequark>
or I mean that's fine but then I would recommend people not use it
<robtaylor>
i was thinking about this problem recently - it reminded me of gstreamer -good -bad -ugly
<whitequark>
gstreamer doesn't do the same thing
<robtaylor>
no, i mean the evolution of IP
<whitequark>
with gstreamer, there are external concerns (like codecs being patent encumbered) that drive it
<robtaylor>
well, that was -ugy
<robtaylor>
s/ugy/ugly/
<whitequark>
and -bad isn't really about evolution as about the dev team washing their hands off it. "sure it's broken, we know and we don't have the resources to fix it"
<robtaylor>
no, it was about evolution, for sure
<whitequark>
I'm actually happier if these -bad designs are not collected in one place anywhere and if people just copy and paste them across projects until something better appears
<robtaylor>
*speaking as one of the maintainers at some point, and having hired most of the gstreamer team at one point or other ;)
<whitequark>
ah okay, that's interesting
<whitequark>
that said, I don't think encouraging reuse of designs with known major flaws is something I want to do
<robtaylor>
but that doesnt really allow for incremental growth
<whitequark>
I don't think an I2C peripheral is something that requires incremental growth.
<robtaylor>
i mean almost everything in -bad went through a complete rewrite before ending in -good
<robtaylor>
but it at least gave a focal point for folks interested in that problem area to come together
<whitequark>
that's the better way in which it can go and I'm more fine with that, but in my experience it is much more common for designs with known major flaws to keep being reused for years with no one really fixing them
<whitequark>
Migen itself is an example
<robtaylor>
but yeah, commercailly we often started the stuff for that particuklar engagment in -bad, then rewrote/refactored over time and more usage till it was acceptable in -good
<robtaylor>
whitequark: agreed. I think it needs more than just a dumping ground repo
<robtaylor>
i mean, to use -bad you had to actually do something. usually involving the word "BAD" ;)
<robtaylor>
(as a user)
<robtaylor>
which is what we've generally only had in this space so far
<robtaylor>
robtaylor: which is what we've generally only had in this space so far
<whitequark>
I don't think this is really relevant for an I2C peripheral, though it would be for more complex ones
<robtaylor>
yep, though i do see lots of folks writijng i2c peripherals...
<robtaylor>
so at the minimum a focal point for that would be good
<whitequark>
frankly I think it needs someone with sufficient experience sitting down and writing one that's not terrible
<robtaylor>
(might also save us some engineering time... if there are folks happy to put the work in)
<robtaylor>
well, that also brings me onto another issue in this space - we don't really have that learning path
<whitequark>
whitequark: that will probably be me, I have learned a lot about real-world use of I2C working on Glasgow
<robtaylor>
so many times in the hardware space i hear folk "oh, someone with experience needs to do that" but there's very little pathway for someone to gain that experience at the moment
<adamgreig[m]>
I guess we really need the streams and other abstractions before we can think about a common i2c periph anyway though
<robtaylor>
whitequark: can't always be you though...
<adamgreig[m]>
I'm sure lots of us have i2c peripherals but I don't think there'd be any benefit to me sharing my particular one now for instance
<whitequark>
robtaylor: I'm going to have to review it anyway, and for something like I2C the engineering time is going to be less than review time
<whitequark>
adamgreig[m]: agreed
<adamgreig[m]>
Yea, for something esoteric like spacewire or maybe can it's perhaps different but for staples like i2c it's probably good to start it in house?
<whitequark>
adamgreig[m]: yeah
<robtaylor>
whitequark: in reality thats not really the question, thinking like that tends to just end up with one person doing everything and a lack of community scaling
<robtaylor>
whitequark: *nod*
<whitequark>
the other consideration is, work on the staples also involves baselining work, which is to say, documenting the processes and the requirements peripherals generally need to meet for inclusion
<d1b2>
<Olivier Galibert> Sr would be easy to add, even optionally (e.g. don't pay for what you don't need), but sure how to handle NAK though, a bus error may be a tad harsh
<whitequark>
robtaylor: generally I'm happier with less scaling but high quality peripherals than the opposite scenario
<whitequark>
but that's only if you put it as a binary choice
<whitequark>
the RFC process for example allows for as much community involvement right now as people are interested in, and provides structure for it
<d1b2>
<Olivier Galibert> we need -soc to eb a repository of stuff we can trust, and I really, really defer to wq to know what trustable is 🙂
<whitequark>
it's something I wanted for myself as much as for the project, because while skilled I am still limited in knowledge and experience (as is everyone else) and input from others results in significantly better design
<whitequark>
*right now as much as people are interested in it
<d1b2>
<Olivier Galibert> should I try to start a rfc on the topic of i2c master in the -soc repository so that ideas are hashed out? I'm gonna implement my thing since I need it now, but that's not an issue
<whitequark>
the thing for hashing out ideas is usually called a pre-RFC since there's no specific design yet
<whitequark>
("request for comments" is for comments on a specific design)
<d1b2>
<Olivier Galibert> How does that work, writing an issue?
<whitequark>
yes. "[pre-RFC] Ideas for an I2C peripheral interface" or something like that
<d1b2>
<Olivier Galibert> ok, I'll try to do that somewhere today then
<whitequark>
sounds good
<whitequark>
btw, should we keep IRC notifications in this channel, or move them to a separate one?
<d1b2>
<Olivier Galibert> well, good question, given you're way more active now (love that!) and it comes with an url making it take a lot of space on discord
<whitequark>
on Matrix too
<whitequark>
and it sends me phone notifications every time I comment or commit, heh
<d1b2>
<Olivier Galibert> indeed
<d1b2>
<Olivier Galibert> "I know I did that, you dumb computer"
<whitequark>
Rob Taylor: I agree that this creates scaling issues. However my strong preference here is to define processes and requirements that reliably result in high quality peripherals rather than have ad-hoc focal points and merely hope things work out
<whitequark>
There isn't anything special about how I think about Amaranth (and especially not about IP) that makes it special to me, it's a matter of writing it down and then enforcing it
<d1b2>
<Olivier Galibert> I've tried to put in your remarks too, because they're rather useful 🙂
<whitequark>
that's nice to hear
<d1b2>
<Olivier Galibert> What's the point of a MemoryMap?
<d1b2>
<Olivier Galibert> it seems to be both mandatory and kinda sorta useless in most of the cases
<whitequark>
it's for generating e.g. C headers
<josuah>
with something like that for silicon ASICs too, we would have likely fewer datasheets erratas!
<josuah>
rtl2pdf.py? :]
<whitequark>
yeah
kmehall has quit [Ping timeout: 255 seconds]
kmehall has joined #amaranth-lang
<d1b2>
<Olivier Galibert> ok, so... what's a resource?
<d1b2>
<Olivier Galibert> ok, self is accepted as a resource, so that works
<whitequark>
oh, in SoC the resource is something that describes the actual thing at the address range in the memory map
<whitequark>
for CSRs that would be the CSR bit map or something
<whitequark>
it's not entirely complete and the docs are utterly missing
<whitequark>
self works IIRC
<d1b2>
<Olivier Galibert> yeah, I'm building my i2c module that is a non-csr wishbone endpoint (because afaict you can't delay ack on csr anyway)
<d1b2>
<Olivier Galibert> and I noticed that MemoryMap was not providing a cs signal, so I wondering what good it was
<whitequark>
you cannot (intentionally, that would be a really bad design if you could)
<whitequark>
oh, speaking of bad design
<d1b2>
<Olivier Galibert> huho
<whitequark>
nevermind, we designed it correctly
<d1b2>
<Olivier Galibert> yay!
<jn>
fun anecdote about bad design: i have a piece of hardware where reading from the SPI controller's FIFO data register stalls the CPU forever, when there's nothing in the FIFO (and nothing coming later because there's no SPI transfer in progress)
<d1b2>
<Olivier Galibert> But I must say having MemoryMap entirely decorrelated from the address map decode is... kinda fascinating in an horrifying kind of way
<whitequark>
it's not entirely decorrelated? it's populated by the decoder
<whitequark>
MemoryMap is a structure for consumption of code that does not care at all about Amaranth things like Signals
<whitequark>
it's essentially a block diagram of your SoC
<josuah>
I thought it could be a location to plug .dot output support for it, but that is forgetting that yoysys might be able to
<cr1901>
>because afaict you can't delay ack on csr anyway <-- yea, CSR (at least litex, guessing amaranth-soc does the same) is basically the bare minimum register bus you can make. If you need anything more complex than "read/writes to regs complete in a single cycle", you need a different bus