Hi,
follow up on ESPI (Enhanced Serial Peripheral Interface) protocol support - Logic 2 - Ideas and Feature Requests - Saleae
In eSPI single i/o it works as “expected”.
According to spec data is splitted over all lines in different mode (https://www.intel.com/content/dam/support/us/en/documents/software/chipset-software/327432-004_espi_base_specification_rev1.0_cb.pdf)
Any idea how to solve this?
@superhansi2013 The Clock line looks unstable (i.e. missing clock pulses in the recording). What sampling rate do you have set, and what is the frequency of the Clock line? Feel free to send over your capture file (in .sal file format) as well and we can take a look.
Hi, I tried different sample rates (125-500). Depending on the eSPI mode the clock is (Quad I/O) 50mhz (attached capture file, wrong results) or 20mhz (Single I/O - which is correct)
quadio.sal (2.3 MB)
The “unstable” clock is always the same, so I rather expect it to be TAR.
Thanks
@superhansi2013 Thanks for sending over your capture file. Is there any chance you can send me a capture file that samples digital channels at 500 MS/s? Unfortunately, 125 MS/s is likely too slow to accurately capture your clock.
We typically recommend sampling at a minimum of 4x the speed of the signal (e.g. 50 MHz would require at least 200 MS/s).
Hi, sure.
q500.sal (603.1 KB)
@superhansi2013 The CLK signal looks much better with the higher sampling rate!
Having said that, zooming into it still reveals inconsistent timing, not well sync’d to the data lines (CH2-5). At approximately 50 MHz, with multiple data lines being probed, I suspect parasitics from the test setup might be causing the inconsistent timing.
@superhansi2013 Upon second look, the CLK frequency seems to be higher than 50 MHz (closer to 100 MHz actually when looking at the edge-to-edge timing of the CLK signal).
Can you confirm the expected frequency of the CLK signal? Please keep in mind that our Logic Pro 8 digital bandwidth is limited to 100 MHz when a 500 MS/s sampling rate is used. Therefore, recording a 100 MHz clock (or close to it) is unfortunately pushing the limits of our device. The digital bandwidth will be lower when lower sampling rates are used.
Hi, we’re using pinheader to ensure proper connection & weak pull ups as requested per Intel design.
I know it is close in the limits of the device and quite “fast”, CLK is 66mhz at most (depending on SET_CONFIG), we’re however using 50mhz for all other but Single I/O Mode - I hereby refer to intel spec (Page 103)
Bits Frequency
000 20 MHz ← bringup
001 25 MHz
010 33 MHz
011 50 MHz ← operating desired
100 66 MHz
1.8V / 0.9 respectively is correct, so your suggestion is checking CLK?
Thanks
@superhansi2013 Thanks for confirming that. I’m guessing slow rise/fall times on the CLK edges are the culprit, which introduce errors on the edge timings as recorded by our Logic device. This might be worsened by our device’s 100 MHz bandwidth, and worsened further by the pull up resistors.
If you’ve maxed out the sampling rate of our device (500 MS/s), and have adjusted the voltage setting accordingly (1.8V setting == 0.9V threshold), then the next best place to look would be to ensure the clock signal arriving at the device’s input is as clean as possible, which may be difficult to achieve given the limitations I described above.
hm, taking into consideration the capture is correct - I rather assume the decoding is wrong as eSPI is e.g. <8byte> so probably a Analyzer is needed
@superhansi2013 The reason for my hunch for the edge timing errors on the CLK signal recording is shown in the image below.
The red lines I’ve drawn indicate where the sampling of bits occurs for our SPI analyzer (rising edges of the CLK signal). In most cases in your capture, the rising edges seem to fall on, or very close, to the edges of the data signals. Typically, the clock edges where sampling happens will lie near the center of the bit rather than near the edge to avoid decoding issues.
In all clock rising edges shown in the image above drawn with red lines, they all lie on the point where the data line is HIGH state, hence the decoding of 0xFF (i.e. all binary 1s).
@superhansi2013 Thanks for confirming the same results (MOSI 0x03 / MISO 0x0A) on another logic analyzer. I’m unfortunately not experienced enough with eSPI to understand the translation between MOSI/MISO → eSPI in case this is where you needed help.
interesting discussion and a good example to test my analyzer. You talked a lot about the clock signal and it’s poor progression.
Can you tell me, based on the “q500” capture file, the first data block (picture with the red lines) you want to send in your software? Then it is easier to compare, understand and check the analyzer.
Thanks
Hi @t.kammerer, I just trimmed the q500.sal capture file to only contain the data block that I referred to in my image with red lines, in case that’s what you were looking for.
TR_q500.sal (15.9 KB)
