topic Issue about Daisy-chain in i.MX Processors

Issue about Daisy-chain

tony_l_cai — Wed, 08 Apr 2015 10:55:20 GMT

Hi,all

In my opinion, when we use some pad's mux,we can select the pad and mux for the pad. And I think the mux can work,but why we need to select in the Daisy-chain register?

I think register is not necessary,could you give me a reason?

Re: Issue about Daisy-chain

igorpadykov — Thu, 09 Apr 2015 01:11:42 GMT

Hi tony

pad can be connected to several internal modules, so for

module outputs there are no problems, since only one module

can be selected with IOMUX. If pad is configured as input,

Daisy-chain register is added to select one input from

several possible pads.

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

Re: Issue about Daisy-chain

rjm — Wed, 27 Sep 2023 08:08:25 GMT

> If pad is configured as input, Daisy-chain register is added to select one input from several possible pads.

This also means: if any pad is selected as a desired module port as per IOMUXC, it will only be readable without further initialisation if the pad corresponds to the reset value of the appropriate SELECT_INPUT register! Am I right?

But more generally: in contrast with former MCU-families, modern MCUs can mux each pad individually to a range of port functions. This means that doubling a port feature is possible. No one would ever waste pads for doubling an output port. And doubling an input port is even a recipe for short circuits of internal buffers. No one would ever do this. NXP solves the latter problem. But where is the practical usage bonus? I don't see that.

Let me refer to the reference manual of the i.MX8plus. In section (table) 8.1.1.1. PDM_BIT_STREAM0 can be asssigned to six possible pads. Even all pads at the same time (which would make no sense at all without the "DAISY" feature). When I use the pad that is mentioned first, no further initialisaton of SELECT_INPUT is necessary.

The DAISY feature is explained in section 8.2.2.4. Here, what I wrote at the beginning is part of the description, but it suggests that the input register would only be needed if one is using the "daisy" feature.

The diagram is only in so far informative in that it shows that the input mux is not muxing pads, but muxing at an intermediate location.

Generally, the description lacks further information. Is daisy chain meant ad an internal feature or as facilitation of an external daisy chain, e.g. daisy chained SPI peripheral IC's? But in such a case one will hardly intend to add taps to a daisy chain. Hence, I question if DAISY is an appropriate term here. Simply input mux would fit better. Or am a missing a crucial "feature" point?

Re: Issue about Daisy-chain

Mestkim — Wed, 27 Sep 2023 08:53:52 GMT

The reference manual clearly shows what is DAISY.

Have DAISY, have more choices to avoid conflict. Just like you can 1,2,3,4,5,6, you only have 6 choices. But if you separate two group 1,2 and group 3,4,5,6. You will have 8 choices.

Not all of them have DAISY.

List i.MX6Q, i.MX6SX, i.MX6ULL, i.MX8MP.

Re: Issue about Daisy-chain

rjm — Wed, 27 Sep 2023 09:38:38 GMT

The pages you extracted show the mux architecture in a little bit more detail. I was not aware of these diagrams - thanks for attending. This diagram also explicitly annotates the input mux to register names ending on SELECT_INPUT[n].

Sorry that I don't follow your explanation. Your grouping (2 and 4) suggests a multiplication of 2x4=8. Hence something with two four muxes followed by a two mux. But the diagram(s) do not show this. I'd appreciate it if anyone is able to provide a concise explanation that point out the extra of daisy beyond simple port input to pad select. Perhaps it's only a matter of so called curse of knowledge (of experts).

For my own better overview, I annotated the iMX8plus table 8.1.1.1 with (green) highlighting of port entries that are also associated with an input mux. See the attached extraction of 25 table pages.

Edit: I made the following comments to the annotation in a text file:

EARC_PHY_SPDIF ? (not found in 8.1.1.1)
ENET1_RXEN = ENET1_RGMII_RX_CTL
ENET_QOS_GMII_MDI_I = ENET_QOS_MDIO
USDHC3_CARD_DET = USDHC3_CD_B