<rjo_>
sb0: if it is easy given the dds shared bus and the splitting of the registers, represent a dds channel as one signal for frequency and one for phase. you probably want to ignore the distiction of the different interpretations of phase and just take the POW.
<rjo_>
sb0: i think we might want a 0th order default handler that just takes rtio data verbatim.
fengling has quit [Ping timeout: 256 seconds]
fengling has joined #m-labs
<rjo_>
sb0: "timestamp" is the timestamp of the event, right? that coincides with now_mu() for outputs. for input events it doesn't. then you don't know when a given input event was actually read. but that might be fine, just pointing it out because it can make debugging a bit harder if an input event was the cause of something else.
<rjo_>
sb0: afaict the analyzer is only accessible through the netserver currently. if i wanted to freeze the analyzer from a kernel (because i detected an abnormal situation), would i just throw an exception and then hope nobody executes another kernel that continues filling the analyzer?
<sb0>
rjo_, yes, that dds handling is possible (with the first values possibly undefined as the relevant writes may have been pushed out of the ringbuffer, but that's a general problem which is only particularly present here)
<rjo_>
sb0: all channels will have unknown values initially until they are written the first time, right?
<sb0>
for inputs, unless there's a bug, timestamp is when the signal changed state, and rtio_counter is when it is read
<sb0>
as for freezing: yes (or that the new kernel does not fill the analyzer buffer)
<rjo_>
when do you let an input channel, where you only trigger rising, fall?
<rjo_>
sb0: but don't we usually return to the idle kernel and that can fill the buffer pretty quickly?
<rjo_>
could we either have the comms cpu intercept a special FreezeAnalyzer Exception or give ksupport to the kernel for controlling the analyzer?
<sb0>
what about having the kernel call a RPC on the host that doesn't return until some user action?
<rjo_>
sb0: for inputs it should probably fine to only have rtio_counter and timestamp. even if the third time, now_mu(), is different and might be relevant.
<rjo_>
then the kernel can just rpc the readout of the buffer.
<sb0>
I guess that works, and doesn't create much spaghetti in the runtime
<rjo_>
ack. let's take that as the comme il faut
<rjo_>
sb0: in misoc.stream with packetized, is the notion generally that sop/eop are valid during stb?
<sb0>
I asked _florent_ that question a few months ago but cannot find it in the irc log right now...
<_florent_>
sb0: you were using sof in dvi, AXI is using tlast, we can generally only have one delimiter and deduce the other, but I find code easier to understand and simulate with both
<rjo>
_florent_: but this putative convenience comes at a cost: what is supposed to happen if the sequencing is violated (eop before sop)? or what does stb before sop do?
<_florent_>
yes, in that case you can discard, I use this because this was close to Avalon ST
<_florent_>
but maybe we should use a standardized streaming bus: AXI or Avalon ST