<d1b2>
<louis> I'm in the seperate-flag-for-malformed-data camp
<d1b2>
<louis> And then display hatched or bordered or something. Having a tooltip for what the issue is would be useful too.
<d1b2>
<louis> If this is the same issue I'm thinking of, it's was that in AcquireData we do scale *= GetChannelAttenuation(chnum); but not offset *= GetChannelAttenuation(chnum);
<d1b2>
<louis> (fixed on DSLabs)
<azonenberg>
@louis: So in that case maybe what makes sense is two more methods for each filter (with default no-op implementations in the Filter class so that we don't have to refactor all existing filters immediately)?
<azonenberg>
one to get the malformed flag
<azonenberg>
and one to get the tooltip text for a decode event
<azonenberg>
which may be due to being malformed, or just other useful data we might want to present
<azonenberg>
as far as the offset goes
<azonenberg>
so yeah it looks like we send a scaled attenuation to the bridge correctly
<d1b2>
<louis> This seems like a reasonable immediate approach, but I think I lean more towards having some shared class for protocol bytes / transactions and consuming the "samples" directly in WaveformArea rendering code
<azonenberg>
Hmmmm yes agreed
<d1b2>
<louis> It also seems like a API mistake to directly expose color information from filters instead of exposing some enum type {TYPE_COMMAND, TYPE_DATA} and assigning colors in UI code, we could refactor that away at the same time
<azonenberg>
more scalable for when we gpu-ify decode rendering
<azonenberg>
yes
<d1b2>
<louis> This probably requires a little bikeshedding about how to best represent protocol data in a cross-protocol-compatible way.
<azonenberg>
yes
<d1b2>
<louis> Having a semantic type field would also be useful to filter what we want to see in the waveform area and in analyzers/csv export
<azonenberg>
Yeah. i mean if you look most of the existing decodes have this already
<azonenberg>
its just not unified
<azonenberg>
And re the ADL5205, that is something we would likely refactor out of existence
<azonenberg>
it would just turn into a metadata file for use with the new decode
<azonenberg>
unrelated: reading about DDR5. apparently DDR5 DIMMs take 12V power and include on-module PoL regulation
<azonenberg>
And they support DFE
<azonenberg>
DFE on a RAM interface @_@
<azonenberg>
please, give up the pretense of being a parallel bus
<azonenberg>
just go multilane serial like every other bus out there
d1b26 has joined #scopehal
d1b2 has quit [Remote host closed the connection]
d1b26 is now known as d1b2
<d1b2>
<Herr Brain> The trouble is that it would probably increase the already high latency too much. Also, I'm not sure how well a bunch of SERDES lanes would map to the internal architecture of the memory. Matching up commands to responses would be complicated with an asynchronous interface.
<d1b2>
<louis> The wish is to have a generic device decode filter with metadata for different chips? I tend to dislike that pattern since the generic part/config interpreter rapidly grows in complexity and I find myself wishing the config was just code instead.
<d1b2>
<louis> I'd rather see us refactor the filter machinery so that all that has to be in ADL5205Decoder.cpp is the ~60 lines that are actually the ADL5205 state machine/decoder, and the boilerplate is factored out into shared code.
<d1b2>
<louis> A lot of the exisitng complexity in that file (as a sample case) could be removed by pushing stuff like SetDefaultName and ValidateChannel into helpers in Filter, and all the GetX can go away with a refactor to shared protocol event objects
<azonenberg>
Yeah, makes sense. The exact details of how it's done is TBD
<azonenberg>
i think both approaches have their place
<azonenberg>
it depends on how complex the chip is
<azonenberg>
ValidateChannel is another thing i want to refactor
<azonenberg>
it should not be a method
<azonenberg>
there should be a descriptor object of some sort associated with each input to a filter
<azonenberg>
that says what's legal
<azonenberg>
and then the actual ValidateInput() logic should be done in the Filter class based on that
<d1b2>
<louis> agree
<azonenberg>
@Herr Brain: most buses on the far side of the memory controller already *are* async
<azonenberg>
separate tx and rx queues etc
<azonenberg>
also, SetDefaultName needs to go
<azonenberg>
the current scheme of having filters named foo(bar(baz), asdf) is nice at first
<azonenberg>
but with remotely complex filter graphs the names grow to obscene lengths quickly
<azonenberg>
and it becomes impossible to manage
<azonenberg>
i find myself constantly renaming filters to keep the name lengths in check
<azonenberg>
I don't have a good idea for how we could replace them
<azonenberg>
the simplest option is to have a global counter for how many objects of a given type have been created
<d1b2>
<louis> Sure, both do have their place. I guess I'm skeptical about how much code sharing could actually be done across chips, but it might be more than I think. My feeling is let's make a nicer API for writing simple decoders and if after writing 10x 50 line decoders it turns out they could become config for a state machine we could do it then
<azonenberg>
so for example you'd have Eye1, Eye2...
<d1b2>
<louis> Otherwise I fear that we will end up with an instance of the buisiness logic VM antipattern where the complexity of our config grows til' we wish it was just code
<azonenberg>
Yes
<azonenberg>
But i think for the common case of a chip that just has a bunch of config fields, some single and some multi bit, accessible via some register
<azonenberg>
some register interface*
<azonenberg>
we should be able to abstract it all out to "AJK is register 0x00 bit 3, QWER is register 0x01 bits 7:4" etc
<azonenberg>
@louis: anyway, so re SetDefaultName
<azonenberg>
the big problem with having autogenerated numeric names is you lose context of what the input is
<azonenberg>
e.g. Threshold1 is no longer obviously thresholding of C3
<azonenberg>
but at the same time if you keep that info it rapidly becomes unmanageable
<azonenberg>
Thoughts?
<azonenberg>
at this point i see the current approach as a problem, but am not sure if the simple numeric naming is the best solution
<d1b2>
<louis> UART(T~1 😛
<d1b2>
<louis> Yeah, that's an annoying issue.
<d1b2>
<louis> The only immediate thought I have is that some of the filters are "not important" to your understanding where the channel came from, often just the set of osc channels involved and the name of the final filter would be enough, e.g. UART(Threshold(ch0)) could become ch0 UART and be just as informative
<azonenberg>
Yeah
<azonenberg>
The question is how "clever" we want to try to get on this
<azonenberg>
vs having a simple, predictable, easy to understand approach
<azonenberg>
that you can just rename if you want something else
<azonenberg>
A good example of a potential strategy is to walk the filter graph all the way back to either a signal generation filter or a scope channel
<azonenberg>
on the first input
<azonenberg>
so the first input to your filter, firsti nput to that, etc
<azonenberg>
and then final filter block name would be based on block type and that first input
<d1b2>
<louis> I would collect the transitive closure and filter for what is a hardware channel or siggen, since we probably want e.g. ch0, ch1 I2C
laintree is now known as lain
<d1b2>
<louis> but yeah, that's what i was thinking
<azonenberg>
ok yeah. but we'd have to cap
<azonenberg>
imagine a GMII bus
<azonenberg>
GMII(D0, D1, D2, D3, D4, D5, D6, D7, D8, D9) is still a pretty fugly name
<azonenberg>
maybe the first 2 inputs max in a breadth first back search?
<azonenberg>
Gonna go poll twitter and see if we get any more ideas before i go build it
<d1b2>
<louis> Sure, that'd be reasonable. I think liberal use of ellipses would also be helpful, viz. GMII(D0, D1, ...) and the ability to right click -> go to filter graph (or even just left click highlighting it on the filter graph) would help a lot if you got lost
<azonenberg>
Yes. i think we can make more use of tooltips as well
bvernoux has quit [Quit: Leaving]
<azonenberg>
and lol, this isnt helpful :P so far twitter is evenly split between the two approaches
<azonenberg>
and now that we have more votes there's a strong favoring of my approach of walking the tree back