TMS320F28388D: Signals Not Getting Through AOC

Hey Ed,

Do you see the correct CLB outputs if you connect them to a GPIO and probe the pin? It's possible the status of CLB_DBG_OUT_2 is always 0 when the AOC is bypassed.

Thank you,

Luke

Hi Luke,

I ran your experiment, and it seems that the signals are getting out the GPIOs.  So that reduces the issue to why the output of the AOC doesn’t match the output of the OLUTs.  Could it be that CLB_DBG_OUT_2 is showing the input to the BYPASS MUX in Figure 9-18, and when the AOC is bypassed, as you suggest, it always produces a 0?

Thank you,

Ed

Hi Ed,

Yes this is my assumption, although I have not worked with this register extensively. I can confirm this with the design team or other CLB experts if needed.

Thank you,

Luke

Hi Luke,

It seems like a good assumption.  It would be good to confirm it so that we don't get a surprise down the road somewhere because a slightly different setup was needed.

Thank you,

Ed

Hi Ed,

I've reached out to the design team to clarify this. I'll get back to you when I receive a response.

Thank you,

Luke

Hi Ed,

The design team provided the following annotated diagram to detail where the CLB_DBG_OUT and CLB_DBG_OUT_2 signals come from:

CLB_DBG_OUT_2.IN may be showing the boundary inputs to the CLB if you have not configured CLB_OUTPUT_COND_CTRL_O.SEL_RAW_IN.

Thank you,

Luke

Thank you Luke,

I believe that OUT_2 is CLB_DBG_OUT_2 and OUT is CLB_DBG_OUT.  Given that, with the exception of the pipe FFs, this matches what I had pictured, a good confirmation of my understanding.  The FFs would simply cause a delay of a maximum of one clock, so that is good to know.

But it still doesn’t explain why, when we are in bypass mode, OUT_2[7:0] is all zeros even when OUT[31:24] is all ones.  From the diagram, it seems that the BYPASS MUX would still reflect the OUTLUT input unless OUT_2[7:0] is connected to the output of Stage3.  And Stage 3 is 0 because it has been forced to 0 by the bypass setting or defaults to 0 and doesn’t change because it isn’t being used.

BTW, CLB_OUTPUT_COND_CTRL_0.SEL_RAW_IN is 0.  In fact all of the CLB_OUTPUT_COND_CTRL_x registers are 0 because they have not been initialized.  This should cause the cell output to be sent to the AOC.

Thank you,

Ed

Hey Ed,

I agree this doesn't quite make sense. I pointed this out to the design team, will keep you updated.

Thank you,

Luke

Hi Ed,

The design team responded back and confirmed that this diagram is correct. Can you confirm the following settings?

OUT[31:24] in non-zeros

CLB_OUTPUT_COND_CTRL_0.ASYNC_COND_EN is 0

OUT_2[7:0] is all zeros

I believe this is the case on your side, just ruling out any mistakes before testing this further. Once you confirm this I will replicate this on my side and provide a test case for the design team to test.

Thank you,

Luke

Hi Luke,

Sorry for the delay.  Yes, OUT is 0xFFxxxxxx, CLB_OUTPUT_COND_CTRL is 0x00000000, and OUT_2 is 0x00000000.

Regards,

Ed

Thanks Ed,

I will recreate this issue on my side and provide a test case for the design team to simulate, will get back to you once I receive their feedback.

Thank you,

Luke

Hi Ed,

I recreated this configuration on my side using SysConfig and see that CLB_DBG_OUT_2 has the correct values:

Note: I tested flipping output 0 to a 0 to test whether the change would be reflected in CLB_DBG_OUT_2.

Could you try this in SysConfig and let me know if you see the same issue on your side?

Thank you,

Luke