There are no guarantees with an unfortunate protocol design like this. But you can do at least as well as a UART does on asynchronous serial data. Let me explain.
Since you have already found the byte boundaries in the data stream, you can think of the header (H) byte as being similar to a UART start bit, and the idle (I) byte as being similar to an (optional) UART stop bit.
Set up a state machine that starts in an "idle" state, and searches for the next header byte, ignoring anything that isn't an H (including actual I bytes). Once you find an H, you then capture the next 3 data bytes regardless of their value. Then, depending on whether the next byte after that is H or not, you advance to the "header" or "idle" state.
Yes, just like a UART, this can get locked into a misalignment if the data packages (I prefer the term "packets") contain H bytes repeatedly, but unless the data is particularly pathological, the state machine should quickly align itself on the "real" headers — all it takes is one packet that does not contain a fake H byte.
If you can make sure that the ASIC doesn't send its first packet until the state machine is initialized, then there should be no problem. Otherwise, if the state machine is started at an arbitrary point in an already-running data stream, it can get into trouble. You can check for non-I bytes when you're in the "idle" state — this is an indication that you're out of alignment.
EDIT: The answer above was based on the mistaken assumption that the "H" byte comes before the data in any given packet; it turns out that I was wrong about that. However, I'm going to leave that part as-is, because that is by far the more common case. Below, I'll address the problem that the OP faces, which has the "H" byte following the data bytes.
In a situation like this, it is necessary to set up a pipeline (shift register) that can contain the complete 4-byte packet.
The bytes shift through the four registers across the top in sequence. The oldest byte (the LSB, which arrived first) ends up in the rightmost register at the same time that the "H" byte for that packet arrives in the leftmost register.
The state machine monitors the contents of the "H" register, and if it is in fact the "H" value when it is in the "header" state, its output is asserted, which enables the capture register in the second row, and also asserts the "valid out" signal.
The state diagram looks like this:
We start on the left, and sequence through the three data states before looking for the first H byte. If we're in the "header" state when we find an H byte, the previous three bytes MUST have been data bytes, so they get captured. We then cycle back through the three data states again to capture at least three more bytes before we start looking for the H again.
Unfortunately, this protocol can easily get out of sync if any packet that contains an "HD" (fake header) byte is also preceded by I (idle) bytes. In order for this implementation to stay in sync, at least one of the two conditions must be met:
- There are no HD bytes in the packets.
- There are no I bytes between packets.
Otherwise, there is simply no robust way to maintain packet alignment. As I said, this is an "unfortunate" choice of protocol on the part of the ASIC designer. If the H byte came first in the packet rather than last, these constraints would go away.