LMH1219 Eye Opening Monitor

K.Fukui

Other Parts Discussed in Thread: LMH1219, LMH1218

Hello Team.

Please tell me about how to read the EOM from the LMH1219.

It has enabled the following three interrupt .
1)HEO/VEO threshold is reached.
2)CDR loses lock.
3)There is loss of signal(LOS) on IN0.

I will make the reading of this in the EOM counter(Reg0x25,0x26).

Then, it will be the same value can be read from the middle of the 4096 batch.

If I disable the interrupt, this does not happen like that.

It remains Interrupt Enable, or will not be able to read the EOM correctly?

Best Regards,

Fukui

over 9 years ago

0 Michael Lu (Santa Clara) over 9 years ago

TI__Mastermind 29655 points

Hi Fukui-san,

Thank you for your post, and sorry for the delay in response.

When you set the interrupts the CTLE/CDR Page Reg 0x56 for the LMH1219, the device treats these interrupts like a logical OR function, so if any of these three conditions occur, the value of the interrupt must be read back in Reg 0x54 to clear the interrupt. The value or status of the interrupt should not affect the ability to read the EOM data.

I have some questions to help me understand this issue:

1. From your description, it seems like you are setting Reg 0x56 = 0x0D. Is this correct?

2. What Reg 0x54 interrupt value are you reading back each time when you read the EOM for 4096 cycles?

3. Do you have a register read-out file to show the difference when reading back the EOM when the interrupt is enabled and when it is disabled?

Thanks,

Michael

0 K.Fukui over 9 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,

Thank you for the response.

I will answer your question.

1.Yes, it is correct.Reg0x56 set to 0x0D.

2.What meaning this question is to say that you are going to read immediately 0x54 if interrupt while reading the 4096 cycle has occurred?
If it is a no.
It has access to lmh1219 by switching the bus from two different processing systems.
Interrupt processing is kept waiting during the EOM read.
Did you mean, do I have a problem here?

3.Is this the raw data of the ”EOM 4096 words”?
Or is that of the source file of the EOM read sequence?
I can provide both.

I thought this from your answer, and whether the problem is to wait for the interrupt processing in the EOM reading.
Is my idea correct?

Thanks and Best Regards,
Fukui

0 Michael Lu (Santa Clara) over 9 years ago in reply to K.Fukui

TI__Mastermind 29655 points

Hi Fukui-san,

Please see responses to your numbered items:

1. Thanks for confirming.

2. I was asking if, in each EOM read cycle, if you are also reading the interrupt register. This means that you would be reading the interrupt 4096 times, one for each cycle. You mentioned that you are switching between two different processing systems, so you only read the interrupt AFTER the EOM read cycles (4096 times) are complete. Is my understanding correct? I do not see an issue with waiting to read an interrupt after you complete the EOM read cycle.

3. Please provide raw data of your read-out from the EOM sequence as well as the source file you used to read the EOM. I am interested to see what you are reading back. Please provide a read-out from your EOM sequence in two situations:
a) When you read the interrupt register during each EOM count (in other words, you read the interrupt register (0x54) 4096 times).
b) When you do not read the interrupt during the EOM count, then only read it once after you complete the EOM read sequence.

I have not attempted to run an interrupt read in the middle of reading back the EOM data, so I think you may experience an issue with reading back the interrupt register during the EOM read-back. I would like to see your read-out from the EOM and your source file to check this.

Thanks,

Michael

0 K.Fukui over 9 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,

Thank you for the response.
I've confirmed your response.

EOM read sequence is this.

1.RAW FF 04 07 //Select Channel Registers
2.RAW 3E 00 80 //Disable HEO/VEO(Different from the Programming Guide)
3.RAW 11 00 20 //Enable EOM
4.RAW 24 80 FF //Start Fast EOM (Different from the Programming Guide)
5.RAW 25 xx 00 //Read as burst of 2bytes and discard
6.RAW 25 xx 00 //Read as burst of 2bytes and discard
7.RAW 25 xx FF //Read as burst of 2bytes and save number of eye hits
8.Execute the above command for 4095 times (total 4096 times for 64X64 cells)
9.RAW 24 00 80 //Disable fast EOM
10.RAW 3E 80 80 //Enable HEO/VEO (Different from the Programming Guide)
11.RAW 11 20 20 //Power down EOM
(Because that it remains in Programming Guide is clean eye pattern could not be read,Step 2, 4, 10 has been changed.
*Please you tell me If you have a something ideas on this change.)

I think correct in your understanding for item number 2.

At step 7 and 8
----------
1st Read 0x25 and 0x26.
Read 0x54.
2nd Read 0x25 and 0x26.
Read 0x54.
3rd Read 0x25 and 0x26.<-For example, here in the interrupt occurs.
Read 0x54.
.
.
.
4096th Read 0x25 and 0x26.
Read 0x54.
----------

Rather than

----------
1st Read 0x25 and 0x26.
2nd Read 0x25 and 0x26.
3rd Read 0x25 and 0x26.<-For example, here in the interrupt occurs.
.
.
.
4096th Read 0x25 and 0x26.
----------
different processing systems
Read 0x54.
----------

Those above are shown in a) of item number 3,and the thing that has been shown down in the b).
Is my thinking correct?

If unless the method of the above (a) of item number 3), as long as to say that not read EOM data correctly,
Problem to say that there is a need to re-examine here the way will be resolved.

Then, I'm sorry, it can not be immediately available in the circumstances of the equipment for the raw data.

Thanks and Best Regards,
Fukui

0 Michael Lu (Santa Clara) over 9 years ago in reply to K.Fukui

TI__Mastermind 29655 points

Hi Fukui-san,

Thank you for sharing the script.

1. Can you confirm whether you are implementing a) or b) in your script? It looks like you are using method a). Is this correct?

2. I believe something may be happening when you disable HEO/VEO monitoring so that Reg 0x54 reports an interrupt. Can you tell me what you are reading back from Reg 0x54? Which interrupt is being asserted?

3. In your original post, you mentioned: "the same value can be read from the middle of the 4096 batch." Does this mean the value in Reg 0x54 or the value in Reg 0x25 and Reg 0x26?

Thanks,

Michael

0 K.Fukui over 9 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,

Thank you for the response.

I will answer your question.

1.Ｉ'm using method b).

I will present a block diagram.

----------

B processing systems

1st Read 0x25 and 0x26.

2nd Read 0x25 and 0x26.

3rd Read 0x25 and 0x26.<-For example, here in the interrupt occurs.

4096th Read 0x25 and 0x26.

----------

A processing systems

Read 0x54.

----------

I am in charge of the B.

Is a system of B are doing a reading of the EOM.

The interruption is in need of is a system of A.

Basically it has only work with A, and connect the B when you want to check the eye pattern and HEO / VEO.

Please consider to operate A / B alternately when B is connected.

2.I do not read [Reg0x54].

　I will question the person in charge.

　I'm sorry,Please wait a little.

3.Is the value of the [Reg0x25 and Reg0x26].

Thanks and Best Regards,

Fukui

0 Michael Lu (Santa Clara) over 9 years ago in reply to K.Fukui

TI__Mastermind 29655 points

Hi Fukui-san,

Thanks for the block diagram. This was very helpful for me to get a better understanding of what is happening in your system.

Can you also ask the person in charge of System A whether the PLD implements something on the SDA/SCL line when an interrupt occurs? It looks like the LMH1218 is configured to output the interrupt on the LOCK_N pin. If the PLD responds by implementing something on the DRV_SCL and DRV_SDA line immediately when an interrupt occurs, this may be an issue if you are using System B to read EOM data.

In your block diagram, I see that DRV_SCL and DRV_SDA is shared by System B and A. If both systems attempt to take control of the bus at the same time, a line-contention issue will occur, likely resulting in the issue you are seeing in the EOM measurement, where Reg 0x25 and 0x26 are stuck reading the same value after an interrupt occurs.

Please check with the owner of System A to see what the PLD does when an interrupt occurs.

Regards,

Michael

0 K.Fukui over 9 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,

Thank you for your response, and sorry for the later reply.

Please let me check.

Did you mean in your statement [LMH1218] is [LMH1219]?

According to the PLD side, if an interrupt occurs even at system B is in operation in DRV_SCL and DRV_SDA line seem to be designed to not access.

I will check it.

Thanks and Best Regards,

Fukui

0 Michael Lu (Santa Clara) over 9 years ago in reply to K.Fukui

TI__Mastermind 29655 points

Hi Fukui-san,

Thanks for your detailed observation. Yes, I meant the LMH1219. Sorry for the confusion.

Regards,

Michael

0 K.Fukui over 8 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,

Reply sorry becomes slow.

It is the result of confirmation.

PLD side if during operation system B, even when the interrupt occurs for DRV_SCL and DRV_SDA line has become a design that does not access.
Bus contention did not occur.

I'm distressed.

What it is not anxious in the other?

Thanks and Best Regards,
Fukui

0 Michael Lu (Santa Clara) over 8 years ago in reply to K.Fukui

TI__Mastermind 29655 points

Hi Fukui-san,

I am having trouble understanding your post.

Are you saying that System B is not able to access the DRV_SCL or DRV_SDA line now?

Is it possible for you to provide scope shots of the SDA and SCL line so I can see what the signals look like when you try to access the line from System B?

Regards,

Michael

0 K.Fukui over 8 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,

I am sorry I can not explain it well.

System B has successfully accessed the DRV_SCL or DRV_SDA line.

I wanted to say that System A does not access the DRV_SCL or DRV_SDA line while system B is using the DRV_SCL or DRV_SDA line.

Thanks and Best Regards,
Fukui

0 Michael Lu (Santa Clara) over 8 years ago in reply to K.Fukui

TI__Mastermind 29655 points

Hi Fukui-san,

Thanks for the clarification. So far, my understanding of the issue is the following (please let me know if I misunderstood anywhere):

1. System B is reading the EOM and the read-back values show the same value.

2. System A does not access the DRV_SCL or DRV_SDA while System B is using the line.

3. System A only checks whether an interrupt occurred (read Reg 0x54) after an EOM read sequence has occurred.

Can you request the owner of System A to set Reg 0x56 = 0x00 so that it does not check for any interrupts? I want to know if this will fix the EOM read-back issue. Again, if you have access to the SDA/SCL lines and can probe the signals and show them on a scope, that may be helpful for us to debug.

Thanks,

Michael

0 K.Fukui over 8 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,
Thank you for writing with easy text.
I am sorry for poor English ability.

1, 2, 3 are correct in your understanding.
However, it is the system A side that checks 0x54.
At that time, System B does not do anything for the SDA / SCL Line.

When all interrupts are invalidated, trying by setting 0x56 = 0x00 from system B side.
When [Reg 0x56 = 0x00] is set, EOM can be read correctly.

As for the signal to the SDA / SCL line, there are those of the logic analyzer, is that OK?
How can I provide it?

Thanks and Best Regards,
Fukui

0 Michael Lu (Santa Clara) over 8 years ago in reply to K.Fukui

TI__Mastermind 29655 points

Hi Fukui-san,

No worries about your English! You are doing great. I'm happy to help, and thank you for your patience while I have been asking many questions about your system.

From your description, it looks like there is some relationship between an interrupt occurring and you reading the EOM correctly. Can you send both a logic analyzer output and a scopeshot of the SDA and SCL line taken from an oscilloscope? I want to see if there are notable signs of bus contention when you are running the system and Reg 0x56 is set to activate interrupts.

While we investigate, I have another question. As a possible solution, would it be acceptable for you to disable interrupts while you are reading your EOM by setting Reg 0x56=0x00, then re-enable interrupts on Reg 0x56 after you finish reading the EOM?

Thanks,

Michael

0 K.Fukui over 8 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,

I'm sorry for the late reply.

I present two scope shots of the Oscilloscope.

It is from around the start position.

Both systems A and B are moving on the first sheet.

Only the system A is moving on the second sheet.

Please let me know if you have any other points you would like to see.

Thanks and Best Regards,

Fukui

0 K.Fukui over 8 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,

I could not post it well.

I will present a Logic Analyzer output.

Please let me know if you have any other points you would like to see.

and

About the method of "As a possible solution, would it be acceptable for you to disable interrupts while you are reading your EOM by setting Reg 0x56=0x00, then re-enable interrupts on Reg 0x56 after you finish reading the EOM?" you said.

Now I'm reading EOM in that way.
But that is not the way I want.

Thanks and Best Regards,

Fukui

0 Michael Lu (Santa Clara) over 8 years ago in reply to K.Fukui

TI__Mastermind 29655 points

Hi Fukui-san,

I spent more time looking into this issue and believe I may know what's going on after reproducing your issue in our lab.

With Reg 0x56[3] = 1 to enable HEO/VEO interrupt, I read back the following EOM result in SigCon Architect:

With Reg 0x56[3] = 0 to disable HEO/VEO interrupt, I read back the following EOM result in SigCon Architect:

The issue you are seeing is not related to SDA/SCL line contention as I originally thought.

There are competing mechanisms within the LMH1219 when both HEO/VEO Threshold Interrupt is activated (Reg 0x56[3] = 1) and the EOM is read back simultaneously.

- When enabling the HEO/VEO Threshold Interrupt, the LMH1219 periodically monitors the HEO/VEO in order to flag Reg 0x54[3] when the HEO or VEO threshold is not met.

- If you attempt to run an EOM capture while this HEO/VEO Threshold Interrupt is enabled, a mechanism in the EOM will compete with the HEO/VEO interrupt monitor, since the EOM requires HEO/VEO information to obtain the eye. This results in a corrupt eye capture readout, just like you observed.

To prevent the competing situation from occurring in the LMH1219 when you read back, I suggest the following:

1. Disable the HEO/VEO Threshold Interrupt by setting Reg 0x56[3] = 0 before you begin the EOM capture.

2. After completing the EOM capture, re-enable the HEO/VEO Threshold Interrupt by setting Reg 0x56[3] = 1 again.

Thanks,

Michael

0 K.Fukui over 8 years ago in reply to Michael Lu (Santa Clara)

Prodigy 140 points

Hi Michael-san,

Thank you for your detailed investigation.
It is to say that between HEO/VEO threshold interrupt is enabled, I cannot capture the EOM.

Thank you for your cooperation over the long time.

Fukui

0 Michael Lu (Santa Clara) over 8 years ago in reply to K.Fukui

TI__Mastermind 29655 points

Hi Fukui-san,

Yes, your understanding is correct.

Regards,

Michael

Interface

Interface forum

LMH1219 Eye Opening Monitor