SUN PHY

[ffierling]

I'd like to write an Access Code Prefixer for the 802.15.4 SUN PHY. I propose adding the functionality to the existing Access Code Prefixer with XML that generates this:

The Mode Switch, FCS and whitening are only used in 2FSK mode and would be ignored in OQPSK mode.

Is it possible to conditionally hide XML parameters?

Thoughts or suggestions?

[bastibl]

I don't know this PHY in detail, but isn't it strange that the "Access Code Prefixer" adds a FCS and applies whitening? Also the O-QPSK PHY use a FCS, but it's not added in this block. So this seems to be an unintuitive solution. It also looks like there is not much functionality shared between the modes. If it makes sense to combine these three steps (access code, FCS, and whitening) in one block for the 2FSK PHY, you could just create two separate blocks.

[ffierling]

I agree, Access Code Prefixer won't be a good name for the modified block. I think the CRC calculation should be moved from the MAC block into the PHY block. This makes sense because CRC calculation, whitening and FEC are specified in the PHY sections of the standard. Modern transceivers typically do all this and even some of the MAC functionality (like ACKs) right in the transceiver.

The OQPSK functionality is close enough to a subset of the 2FSK functionality that it could be put into one block. The CRC, FEC and whitening are shared amongst the dozen or so PHYs in 802.15.4.

Thoughts?

[ffierling]

I notice the IEEE802.15.4 module already has a PHR Prefixer block for messages and a Preamble and SFD Prefixer block for integers. What's the best architecture here? Develop small blocks that perform the processing to add the various fields (eg preamble, SFD, PHR, CRC, FEC, or whitening) that are flexible enough to connect in a flowgraph for the various PHYs, write one big block that does them all, or one block for each PHY? Would they all operate on messages?

[ffierling]

An advantage of a monolithic block is the PHR and corresponding stream processing for CRC, FEC, or whitening can be configured in the one place in a flowgraph.

[bastibl]

I'm not sure I understand. Generally, I would say

• the goal is not to mimic the structure of an ASIC. Even tough chips can generate ACKs, I would not add this MAC layer functionality into the PHY.
• the structure of the flow graph should be easy to grasp and it should be clear what's going on in the blocks. So having one block that can be put in different modes (where it unlocks different configuration options) is not good.
• It is not an advantage to put everything in one block, only to configure things in one place. It would mean that the optimal implementation would be a single incredibly complex block with multiple configuration interfaces all in one place.
• Finally, I would try to avoid reimplement similar functionalities. So if the PHYs, for example, use the same CRC. Then it makes no sense to duplicate the CRC in each PHY. In that case, I would just leave it in the MAC or create a separate block that adds it after the MAC.

But in any case, these are all secondary problems. If you are working on a new PHY, maybe the easier way is to just implement it without changing the existing blocks (too much). Then, in a second step, we could look into restructuring things.

[ffierling]

My mistake: the CRC (aka FCS) is defined in the MAC section of the spec. Only the bit fields indicating its length are in the PHY section.

[ffierling]

So if I understand correctly, this architecture for a SUN 2FSK PHY transmit path would be acceptable?

[bastibl]

Looks good. AFAIS, "PHR Whitener", "New PHR Prefixer", and "SHR Prefixer" are custom blocks that are just for your PHY. If so, I would just do that it in one step and not copy the data around several times. But this is also perfectly fine. The most important aspect is that the "PHR Whitener" can deal with the PDUs from the MAC block.

[ffierling]

Yes, per the other issue I'm going to rename "New PHR Prefixer" "SUN PHR Prefixer".

[bastibl]

I guess we can close this issue. Feel free to reopen if there are any other issues.