08:51 <purdeaandrei[m]> Could you clarify? Does 2-lane streams mean 2-(lane streams) or (2-lane) streams?

08:51 <purdeaandrei[m]> Does each lane have it's own i_en?

08:51 <purdeaandrei[m]> s/it's/its/

08:53 <purdeaandrei[m]> Currently the latch only extends the o[1] beat, because we always output data in pairs in DDR mode. Do we desire to be able to only output one of those? And if we only output o[0], then to have the stretcher automatically replicate to o[1], and if we only output o[1] then have the stretcher take o[0] from the latch?

08:53 <purdeaandrei[m]> * stretcher take a value for o[0] from

09:11 <purdeaandrei[m]> oh, you said here that it's a single stream

09:12 <purdeaandrei[m]> So then I think we would also need an o_en for each lane

09:27 <purdeaandrei[m]> So here you mean, instead of portname.i[0], it should be lane[0].portname.i, right?

09:27 <purdeaandrei[m]> Also what does `<1` mean in your message?

09:29 <purdeaandrei[m]> * So here you mean, instead of i_stream.p.port.portname.i[0], it should be i_stream.p.lane[0].portname.i, right?

09:32 <purdeaandrei[m]> Oh, ignore the second to last question, you already specified it for `.o` so should be the same for `.i`. Although I'm not sure about the always-valid aspect of i_stream, cause the first, or first two samples would not be valid

09:32 <vegard_e[m]> less that one sample per cycle presumably means one sample every N cycles

09:33 <purdeaandrei[m]> ah, okay, so the baud-limited case

12:34 <purdeaandrei[m]> In the case of SDR or divisor!=0 mode, the outputs are going to be down-converted from 2-lane to serially issued 1-lane. Then how about the response? It feels clean to up-convert the inputs to 2-lane, and have QSPIController be agnostic of what the ratio is, that is: it should always have sck=0 in lane0, sck=1 in lane1, and always sample the result from lane1

12:36 <purdeaandrei[m]> if there's one `i_en` per stream transaction, then that would turn into two `i_en`s per lower level IOStreamer transaction, then some module would register those two `i_en`s, and present both to the user

12:39 <purdeaandrei[m]> if there's one i_en per lane, then the lower level IOStreamer would have to pass through ancillary data about which lane `i_en` belongs to, and whether it's the last one or not. (otherwise the upconverter module wouldn't know that it doesn't have to wait for the second lane after it receives lane 0), and then for cleanliness the input stream would also need `i_en` fields, to tell you which lanes contain valid data and which don't.

12:40 <purdeaandrei[m]> Starting to feel like one i_en per 2-lane transaction is better

12:40 <purdeaandrei[m]> also this would just complicate things too much

15:35 <whitequark[m]> no o_en, one i_en per lane

15:35 <whitequark[m]> nothing outside of lanws

15:35 <whitequark[m]> s/lanws/lanes/

15:35 <whitequark[m]> that is the design I'm proposing

15:36 <purdeaandrei[m]> how about meta?

15:37 <purdeaandrei[m]> Also see my later messages, wouldn't that make one i_en per lane undesirable?

15:37 <whitequark[m]> that goes into the lane too

15:38 <whitequark[m]> I'm too tired to look into it, but the short answer is that stuff outside of lanes breaks the entire design, so I don't think there are objections to it I will find convincing

15:38 <whitequark[m]> (since you can only use lane converters if nothing exists outside of lanes)

15:40 <whitequark[m]> I'll have to read your messages sometime when I'm not tired, and I have no idea when that will happen

15:40 <whitequark[m]> maybe after I quit my job or something

15:42 <purdeaandrei[m]> Is a lane converter a concept that already exists? Isn't it just a stream transformer that will change from 2-lane to 1-lane and vice versa?

15:42 <whitequark[m]> yes

15:42 <purdeaandrei[m]> then I don't understand why it can't have stuff outside of lanes

15:43 <purdeaandrei[m]> cause it has access to the non-lane data

15:44 <whitequark[m]> well what if it receives two different meta and has to pack it into one?

15:44 <whitequark[m]> it can't do that

15:44 <whitequark[m]> so it should never be in that situatio

15:44 <whitequark[m]> s/situatio/situation/

15:44 <purdeaandrei[m]> but if meta by definition is outside of lanes, then it can only receive one meta

15:45 <whitequark[m]> consider the 1-lane to 2-lane case

15:45 <whitequark[m]> it takes 2 payloads to form one

15:45 <purdeaandrei[m]> yes, but that will start out with a 2-lane to 1-lane, and then we know the meta is the same for both 1-lane payloads

15:45 <whitequark[m]> nope

15:46 <whitequark[m]> the lane converter is a generic piece of infra, not one specific to this use case

15:46 <whitequark[m]> in any case, I don't want to discuss this until I'm not feeling sick every day

15:47 <whitequark[m]> or at least, this sick

15:47 <whitequark[m]> it's incredibly exhausting

15:47 <purdeaandrei[m]> I hope you'll get better soon

15:47 <whitequark[m]> don't get your hopes up

15:47 <whitequark[m]> it might take months

15:51 <whitequark[cis]> thanks

15:51 <WilfriedKlaebe[m> whitequark[m]: Best wishes!

15:52 <purdeaandrei[m]> Alright, well, I'll come up with some code that will follow the guidelines that you already layed out, as much as as I can, and then whenever you feel you are able we can talk about it. Please don't allow my interest to feel like pressure on you. It's more important to take care of yourself.

15:57 <whitequark[m]> thanks

16:34 <purdeaandrei[m]> When it comes to 1-lane to 2-lane conversion I think the following are the only possibilities:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PjxCwNCZSxmyOAJcdkvDJBxq>)

16:34 <purdeaandrei[m]> I don't think there's any other option

16:39 <purdeaandrei[m]> btw, 2a) would also need some form of introspection, cause with 2a) it becomes absolutely necessary to also have a lane_valid bit, to tell the receiver where data is present. So that means the output lanes have more members than the input lanes.

16:41 <purdeaandrei[m]> whitequark (@_discord_182174208896401419:catircservices.org) Apologies for the question and feel free to ignore, but should by code be 2a) or 2b)? Cause it will have a massive impact on its structure.

16:41 <whitequark[m]> I really don't want to discuss this topic and it's incredibly stressful that you're making me to

16:42 <purdeaandrei[m]> Apologies

16:42 <whitequark[m]> open source is making me miserable

16:42 <whitequark[m]> maybe I should quit it

16:43 <whitequark[m]> even if I say things like "I'm too sick to discuss this" people just don't listen

16:43 <purdeaandrei[m]> I'm sorry, I'm stopping on this