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

Voters 18

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

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

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