HLA - Support Input from another HLA - Logic 2 - Ideas and Feature Requests

Voters 19

E
S
P
J
C
+ 13 voters
J
J
A
R
N
T
A
M
J
A
L

HLA - Support Input from another HLA

Open
Subscribe

Tim

enable a hla to use another hla as input, so the stream parser could be used by another hla data layer which will only use the information: packet start, packet type data.data ... and show only an higher layer of the data interpretation.

30-06-2021 -

Activity Newest / Oldest

Jui Yen

This feature would be an amazing add. In the meantime is there any alternative that one would recommend?

I have a proprietary protocol that can be parsed by the async serial analyzer well. Currently I am working on creating a HLA (named HLA_low) to decipher the contents for better readability/searchability (e.g., byte 0 means address, bytes 1 and 2 are lengths, etc.). If possible, I would like to create another HLA that is even higher level (named HLA_high), such that it can look at the different complete messages and determine the underlying context (e.g., messages 1 through 4 are part of a get data transaction).

The way I am thinking about implementing this is that:

* HLA_low's decode will process/annotate each frame + figure out if a complete message has been received.
* HLA_high's decode does not process all frames, but instead use the decode call as a notification to find out if HLA_low has seen a complete message. If so, it will look into the key fields in that message to identify the context + keep track of the relevant frame start/end times, so that ultimately it can generate a context frame that is 1 or more complete messages wide.

Tim

Thanks for commenting your use case for this feature! We don't have a workaround for allowing an HLA as an input to another HLA. Your best bet at the moment would be to implement HLA_high as a fully contained extension.

Tim

discuss.saleae.com/t/hla-as-input-analyzer-for-other-hla/2663
"is it possible to set a (custom) HighLevelAnalyzer as the Input Analyzer of another HighLevelAnalyzer?

E.g. process a stream of bytes by the Async Serial analyzer. These bytes are decoded by some custom HLA. The produced frames are then decoded further by another HLA: Async Serial → HLA1 → HLA2.

I tried the HLA py code from the example, but I can only select the Async Serial analyzer as Input Analyzer (not the other analyzer)."

Tim

discuss.saleae.com/t/possible-to-have-an-hla-read-analyzerframe-s-emitted-from-another-hla/2434/2
"It seems like the HLA settings windows now only let you pick from low level protocol analyzers as the input? Is that by design, or is there someplace I need to indicate that the output frames from an HLA can be used as input to a next layer?

I’m trying to build some generic JTAG decoders and want to be able to separate the layers so I can support various combinations of wire protocols and targets.

I currently have low level analyzers that can read BSW and 4-wire, and an HLA JTAG state machine that can hook into either of those. Now trying to make the reg decoders for various targets that can read in the output of the state machine HLA."

Richard

Hi, my organization uses 10s of Saleae logic analyzers across the globe, thank you for a great product! I would like to also vote for this issue, it would be very powerful to be able to have a HLA built on another HLA. In my particular use case, we're decoding SPI traffic, and when a specific memory range is addressed, we'd like to be able to decode those bytes into the underlying C struct that is flowing across the SPI.

Neel

github.com/shuffle2/NandAnalyzer/issues/1
Hi @nbanerje . Do you plan to support stacking HLAs on top of each other? Ideally the C++ and python analyzers could just be fully interchangeable and freely stackable. However, a more constained example would be the github.com/FSecureLABS/bitlocker-spi-toolkit extensions. Currently it's 2 HLAs which share most code because they are not stackable. A better solution would be, for example: [SPI] -> [TPM SPI (decode to simple register read/write on bus)] -> [decode to status/FIFO level] -> [decode specific tpm commands] -> [...]. You can see the chain could grow quite long if you want to break the decoders apart to make them modular.

Jonathan

This would also solve ideas.saleae.com/b/feature-requests/support-multi-byte-spi-hla-frame-type/ since they could use the output from the "SPI transaction framer" HLA as the input to theirs.

Jonathan

This would make the COBS decoder HLA (github.com/jonathangjertsen/cobs-decoder-hla ) more useful - it is used for framing binary data, but you typically have some packet format (message ID, length, checksum, payload etc) on top of that as well. Currently you need to fork it if you want to parse the packets.

Peter Jaquiery

Tim

(#61610)
Original idea from this ticket