About SEMC SRAM I/F signal, UB#/LB# information for MIMXRT1170

[takayuki_ishii]

Hello community,

In SEMC of IMXRT1170, it can connect non-ADMUX SRAM with 16bit data bus width.

From Table 29-7, UB#(Upper Byte) and LB#(Lower Byte) signal are assigned to

SEMC_DM0 and SEMC_DM1 pin.

However, there is no explanation or waveform in the Reference Manual.

What should I refer to for information on the UB#/LB# signals when connecting non-ADMUX SRAM?

Best regards,

Ishii.

[mayliu1]

Hi @takayuki_ishii ,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.

Regarding your question, I think you can refer to this NXP RT community post.

Solved: Re: About UB/LB Signals behavior when SEMC is used as SRAM-I/F - NXP Community

Below is the timing diagram.

Wish it helps you

Best Regards

MayLiu

[takayuki_ishii]

Heillo @mayliu1 

Thank you for your suggestion.

The inquiry in that thread is the same as my question.
However, I don't understand the "solution" posted.

This is because NXP has provided no information about UB#/LB#.
Although it is marked as the solution, please review the response content.
I suspect the original poster probably gave up waiting for a response from NXP.

What I want to know is the timing of the UB#/LB# signals output from the i.MX RT1170 SEMC to control SRAM.
Since the signal names are UB#/LB#, I assume they are active low, but I need information on when they are asserted low and when they are negated high.

In a typical memory controller, UB#/LB# are driven high when not accessing the SRAM;
when accessing the low byte D[7:0], LB# is driven low;
when accessing the high byte D[15:8], UB# is driven low.

However, on the i.MX RT1170 SEMC I observe behavior where the signals are driven low in some state, and
when accessing the low byte D[7:0], UB# is driven high to disable low byte of SRAM;
when accessing the high byte D[15:8], LB# is driven high to disable high byte of SRAM.

Is this the behavior NXP intends?

Best regards,

Ishii.

[mayliu1]

Hi  @takayuki_ishii ,

Thanks for your updated information. 

I have internally confirmed that the timing diagram we have matches the one shown in that link.

Regarding your new question:
Yes, this is  the behavior NXP intends.

In 16‑bit Non‑MUX mode:

1: UB# and LB# are active low byte‑enable signals.

2: For read cycles, both UB# and LB# remain asserted (low), even for 8‑bit reads.

3: For 8‑bit write cycles, the unused byte lane is disabled by deasserting (driving high) UB# or LB#.

Wish it helps you

Best Regards

MayLiu

[takayuki_ishii]

Hello @mayliu1 ,

Thank you for your detail information.

Let me confirm two more points to clarify the operation of UB#/LB#.

In the case of "8-bit write cycle" shown in 3,

1. I think that ADV# is active(low) UB#/LB# keep low level. 

Is it correct?

2.  When does UB#/LB# become deasserting (High)?
Also, how long does it remain deasserting (High) for?

 a. WEL

 b. WEL + WEH

 c. WEL + WEH + CEH

 d. another value.

Please show an attached excel sheet.

Best regards,

Ishii.

[mayliu1 · Accepted solution]

Hi @takayuki_ishii ,

Thanks for your updated information.

Regarding your new questions, please refer to below:

Question 1: I think that ADV# is active(low) UB#/LB# keep low level. 

Is it correct?

Answer 1:  Not correct.

UB#/LB# are low during IDLE, CES and CEH states.

They keep activity during AS, AH, WEL, WEH states.

ADV# is low in AS state.

So when ADV# is active (low), UB#/LB# will be active, NOT always low.

Question 2: 

When does UB#/LB# become deasserting (High)?
Also, how long does it remain deasserting (High) for?

1. WEL
2. WEL + WEH
3. WEL + WEH + CEH
4. another value.

Answer 2: 

UB#/LB# become deasserting during AS, AH, WEL, WEH states.

Best Regards

MayLiu

[takayuki_ishii]

Hello @mayliu1 

Thank you for the detailed reply.

With the information you provided, I was able to confirm the behavior of the UB#/LB# signals.

However, since this behavior was unexpected,

I would appreciate it if you could consider adding it to the reference manual or datasheet.

Best regards,

Ishii.

[mayliu1]

Hi @takayuki_ishii 

Thanks for your updated information.

Sorry for my late reply. I was away on leave during the Chinese New Year holiday.

The update to the documentation you requested is now in progress.

Thank you for bringing this issue to our attention.

Best Regards

MayLiu