Parallel GPIO Register Write to Pin Latency

[Gene1000]

What is the maximum latency between an R52 core write to a SIUL2 parallel GPIO output register (e.g., SIL2_0.PGPDO1) and the GPIO pins starting their transitions?

I understand that pin settings for RDSON and external loading will effect final rise/fall times, I'm just looking to understand latency internal to MCU.  I assume this latency would be identical for 3.3V, 1.8V/3.3V, and 1.8V pins.

[alejandro_e]

Hello @Gene1000,

The delay/latency you mention is usually internal information. However, depending on why you need those details, the S32E IBIS model or the S32Z17x17 IBIS model or the S32Z21x21 IBIS model, might help you with your problem. Please note that those are secure files, you will need to request access to be able to download them.

If you still need support, please let me know what exactly are you trying to solve with this information, there might be other ways to help you.

Thanks

[Gene1000]

Hi @alejandro_e,

Probably the easiest way to think about about the latency I'm interested in is basically reading a value from a parallel GPIO port doing some computations and writing the result back to another parallel GPIO port.

The computational time should be pretty small for what I need, maybe less than 100ns (at 800Mhz clock), so I want to make sure I understand any significant latency that would be caused by the parallel GPIO register reads/writes.

I'm not sure if the IBIS models would help here, I was under the impression they modeled more of the I/O driver level rise/fall times and don't really address instruction to register/pin timing, but please correct me as I have only looked at the IBIS file contents a bit and not used them in sim.

I appreciate your help.

[alejandro_e]

Hello @Gene1000,

I understand, however that information is not available to share, in fact, only a very small group would have access to that kind of details. Therefore I cannot shared them with you.  I apologize for the inconvenience. 

Regarding the IBIS model, you could use it to simulate our chip, for example with Cadence Sigrity, with that you can get an idea of the delay times between the silicon and the external pins. 

Let me know if I can help you with something else.

[Gene1000]

Hi @alejandro_e ,

It's unfortunate that information isn't publicly sharable.

I guess what I don't understand is that if I we wanted to spend ~$1500 usd, we could have the S32Z280-594EVB eval board (~1k) and S32 debug probe (~$500) in a day or two from the normal vendors that have it in stock.  Then we could take a basic design studio project and add a few lines of code and directly measure the latency I'm interested with on a scope.

I appreciate if you don't necessary have the specs I'm interested in at your finger tips, but not sure why something that is measurable within 15 minutes by anyone has a working setup in front of them is such closely held info?

As we would hate to spend $1500 to find out that the S32Z will not meet our needs in the first few hours with an eval setup, does NXP have any demo/lease options for an eval setup that would allow us to do our first pass assessment since specs we need don't seem readily available?

I would be interested in getting the IBIS files.  Again,  I don't believe any simulation with them will address the mcu clock cycles taken up by any bus activity, etc. required to get the read/write instruction to have a result at the I/O buffer.

At this point I have no idea as to what even an order of magnitude value for that latency might be...a few ns, 100's ns, a us, etc.?  Even that type of info would give me some confidence as to whether my 100ns calculation would be blown away or probably unaffected by the read-in, write-out port access latency.

Hope you can find someway to help us understand whether the s32z will meet our needs or not with respect to this aspect.

[alejandro_e]

Hello @Gene1000,

I apologize, I incorrectly assumed you already had either an evaluation board or a custom board, that is usually the customers' context when they reach out to us, and therefore I assumed you needed very precise and documented information. 

Now that you clarified that, I can totally test that, I do have some S32Z boards with me. However I won't be able to do it today, since I don't have an oscilloscope with me at this exact moment. I can perform the tests next week. 

just to be completely clear, are you planning to use the S32Z2 in 400BGA or 594BGA package? I don't think there will be much difference in the result, but it is better to match your future setup.

I apologize for the misunderstanding.

[Gene1000]

Hi @alejandro_e (please also see my previous reply),

I was thinking more about the test setup and realized there might be another/easier way to get some numbers w/o connecting up a scope.

Looking at the pad MUXing diagram on page 1942 of the ref manual, it seems the input and output paths (digital/analog) to a single pad should only interact at the pad.  So it seems that the latency could be obtained by measuring the time between doing a write to a parallel output port register (e.g., SIUL2_1.PGPDO0) and detecting the change by reading the the matching parallel input port(e.g., SIUL2_0.PGPDI0).

I was hoping to find an unused/routed GPIO on the 594 eval board (I downloaded the design for ref) with min pad loading, but all gpio pads seem used.  I think GPIO0 (a 3.3V io pad) might be the best since it is only connected to the MB connector (maybe you see something better).

In addition to enabling the GPIO0 output buffer (SIUL2_0.MSCR0[OBE]), I think setting the slew rate to max might be a good idea to get the min latency value (SIUL2_0.MSCR0[SRE] = 100b. 

What's confusing about the datasheet (p1935-1937) is that the reset value for SRE = 000b, even thought for a 3.3v gpio that is reserved...not sure if it has an effect or not.   I would also be interested in why the max frequency (both p1937 and in the gpio datasheets) has the 3.3v gpio listed as a max 50MHz (input/output) for all settings except the slowest skew rate(111b) whereas the other iotypes (1.8/3.3. or 1.8) have a different frequency listed; note the datasheet (page 26) shows different RDSON_33 values for the 3.3v GPIO for each allowed SRE setting?

Also, if possible it would be helpful to know (using the performance timer) how long the store instruction took and how long the load instruction took to execute along with your thoughts or tests on whether multiple R-52 cores accessing different gpio port registers simultaneously would degrade latency significantly.

[alejandro_e]

Hello @Gene1000,

Here are the results of the test:

On rising edge

I did two for the rising edge since it seemed too fast, but got the same results

On falling edge:

The loop does the following:

    while (1)
    {
    	DIO_PTE->PGPDO = 0x8000;
        while(TRIG_PORT->PGPDI){}

        DIO_PTE->PGPDO = 0x0000;
        while(!TRIG_PORT->PGPDI){}
    }

 For the output I used GPIO48, connected to pin 3 of J244:

For the input I used GPIO4 connected to CAN0_TX:

Regarding the multicore access, you can see this diagram in the reference manual:

As you can see, the two RTUs use the same data path, so in practice, there can be a delay when accessing the same peripherals from two different RTUs.

Regarding your questions related to the configuration of the pins and ports, can you elaborate more on them? I did not quite understood exactly what you were asking.

Please note this tests were done using the SMU/M33 core.

Let me know if the tests I did gave you enough information.

Thanks

[Gene1000]

Hi @alejandro_e ,

I appreciate you response...

Before I ask too many question about the data could you:

1_ Provide me the project files so I can understand everything that might be going on with the core(s) and reference some of the C port names in terms of registers better.

2_ Explain where channel 1 and 2 of the scope were connected and what method of triggering the input pin was used. (also grounding of the scope probes and trigger signal).

3_ Verify whether or not jumpers (at J244 and J62) were removed from the pins you used.

Thanks again.

[alejandro_e]

Hello @Gene1000,

Please find my answers below:

1_ Provide me the project files so I can understand everything that might be going on with the core(s) and reference some of the C port names in terms of registers better.

I have send you the project in a private message.

2_ Explain where channel 1 and 2 of the scope were connected and what method of triggering the input pin was used. (also grounding of the scope probes and trigger signal).

I did not use a trigger method, I manually paused the scope and zoomed into the relevant part of the signal.

I grounded the scopes in the following test points:

3_ Verify whether or not jumpers (at J244 and J62) were removed from the pins you used.

I removed the jumpers from J62 but not from J244.

[Gene1000]

Hi @alejandro_e ,

A few more questions about the testing:

1_ Was the S32Z280-594EVB eval board plugged into an extension board? (https://www.nxp.com/design/design-center/development-boards-and-designs/S32X-MB)

2_ Your oscilloscope plots have 2 channels (Ch1, Ch2).  a) Where exactly was each probe connected and b) were any additional wires used? 

3_ The tests code you provided requires TRIG_PORT->PGDI to change for the program to continue running.  How did you get the value of TRIG_PORT->PGDI (DIO_PTA->PGDI) to change.

while(TRIG_PORT->PGPDI){}

4_ Since you are reading the whole port TRIG_PORT->PGDI (DIO_PTA->PGDI), and not masking GPIO4 how do we know none of the other pins are active (always 1) or changing during the test?

5_ Where in the code is GPIO4 configured as an input?  I only see this configuration data (Siul2_Port_Ip_Cfg.c) for that GPIO and I see ".outputBuffer = PORT_OUTPUT_BUFFER_ENABLED", so I would think the output driver of GPIO4 would be trying to fight any external changes to the pin level?

.base                        = IP_SIUL2_0,
        .pinPortIdx                  = 4u,
        .mux                         = PORT_MUX_AS_GPIO,
        .safeMode                    = PORT_SAFE_MODE_DISABLED,
        .terminationResistor         = PORT_TERMINATION_RESISTOR_NOT_AVAILABLE,
        .receiverSel                 = PORT_RECEIVER_NOT_AVAILABLE,
        .currentReferenceControl     = PORT_CURRENT_REFERENCE_CONTROL_NOT_AVAILABLE,
        .pullConfig                  = PORT_INTERNAL_PULL_DOWN_ENABLED,
        .slewRateCtrlSel             = PORT_SLEW_RATE_CONTROL0,
        .rxCurrentBoost              = PORT_RX_CURRENT_BOOST_NOT_AVAILABLE,
        .inputBuffer                 = PORT_INPUT_BUFFER_ENABLED,
        .openDrain                   = PORT_OPEN_DRAIN_DISABLED,
        .outputBuffer                = PORT_OUTPUT_BUFFER_ENABLED,
        .inputMux                    = {
                                         PORT_INPUT_MUX_NO_INIT,

.

[alejandro_e]

Hello again,

Please find my answers below:

1_ Was the S32Z280-594EVB eval board plugged into an extension board? (https://www.nxp.com/design/design-center/development-boards-and-designs/S32X-MB)

The S32X-MB was not connected, I used only the S32Z280-594EVB.

2_ Your oscilloscope plots have 2 channels (Ch1, Ch2).  a) Where exactly was each probe connected and b) were any additional wires used? 

Channel 1 was connect to the pin header, with a female dupont cable, to get the voltage to the pin :

The voltage was taken from the first pin in J276:

Channel 2 is connected to the top part of the jumper in J244:

3_ The tests code you provided requires TRIG_PORT->PGDI to change for the program to continue running.  How did you get the value of TRIG_PORT->PGDI (DIO_PTA->PGDI) to change.

while(TRIG_PORT->PGPDI){}

it is the purple cable above. 

4_ Since you are reading the whole port TRIG_PORT->PGDI (DIO_PTA->PGDI), and not masking GPIO4 how do we know none of the other pins are active (always 1) or changing during the test?

I did some other test before, the only active bits were the ones of interest. Moreover, the change in the signal, viewed in oscilloscope, only occurred when connecting and disconnecting the purple cable. I tried to make the simplest program possible to reduce the processing delay.

5_ Where in the code is GPIO4 configured as an input?  I only see this configuration data (Siul2_Port_Ip_Cfg.c) for that GPIO and I see ".outputBuffer = PORT_OUTPUT_BUFFER_ENABLED", so I would think the output driver of GPIO4 would be trying to fight any external changes to the pin level?

.base                        = IP_SIUL2_0,
        .pinPortIdx                  = 4u,
        .mux                         = PORT_MUX_AS_GPIO,
        .safeMode                    = PORT_SAFE_MODE_DISABLED,
        .terminationResistor         = PORT_TERMINATION_RESISTOR_NOT_AVAILABLE,
        .receiverSel                 = PORT_RECEIVER_NOT_AVAILABLE,
        .currentReferenceControl     = PORT_CURRENT_REFERENCE_CONTROL_NOT_AVAILABLE,
        .pullConfig                  = PORT_INTERNAL_PULL_DOWN_ENABLED,
        .slewRateCtrlSel             = PORT_SLEW_RATE_CONTROL0,
        .rxCurrentBoost              = PORT_RX_CURRENT_BOOST_NOT_AVAILABLE,
        .inputBuffer                 = PORT_INPUT_BUFFER_ENABLED,
        .openDrain                   = PORT_OPEN_DRAIN_DISABLED,
        .outputBuffer                = PORT_OUTPUT_BUFFER_ENABLED,
        .inputMux                    = {
                                         PORT_INPUT_MUX_NO_INIT,

I configured it as an input output, just for simplicity, therefore you can see the input and output buffer configured, it is easier to see in the pins tool:

 Please let me know if you have more questions.

[Gene1000]

Hi @alejandro_e ,

Thank you for the complete explanation, now I think I can ask/discuss the test/data a bit better.

1_ Relating to that GPIO4 pin, in the configuration you have it with both input and output drivers active.  Why doesn't attaching a wire to +3.3V supply cause excessive current draw on that pin assuming the output buffer is set for logic 0.

This is a 3.3V IO (port voltage VDD_IO_G is only allowed to be 3.3V). I'm not sure what the output driver will do since the SRE value of 000b selected is a reserved value.  But typical output resistance of the 3.3V output buffer is

So it would seem the I = V/R = 3.3 / 50 Ohms = ~66mA could damage an IO...but maybe there is some protection there or I'm not understanding why the output buffer being enabled for the pin you are driving from the 3.3V supply might not be bad.

You mentioned selecting input/output for the direction in the configuration, but I don't see any pin setting in the code that reflects that other than both input and output buffers are enabled like he pin configuration tool also shows.

Question is why driving the pin in this configuration (output buffer enable) is OK?

2_ For both the rising edge and falling edge plots, I can maybe understand the long rise/fall time of Ch1 since it is being switched by your wire (inductance, etc.).  But I'm confused by the equivalent and slow rise time of the GPIO48 signal generated by the MCU.  GPIO48's (Probe Channel 2) rise/fall time is on the order of 10us, this would limit the clock frequency on that pin to 50kHz (1/(10us rise + 10 us fall); that's not even enough to support 115.2k baud serial communications?...just seems really slow.  

Keep in mind that latency core to IO should have nothing to do with how fast the IO line transitions when the data eventually reaches the port buffer.

Is there something that could be loading the pin or causing this?

3) The input high level voltage threshold has a min of 0.7 * VDD_IO = 0.7 * 3.3V  = 2.31V.

Looking at the 2 rising edge plots, it seems GPIO48 output seems to start rising at almost the same time as the input GPIO4, even thought the change should not be detected until the signal is at least above the 2.31V value.

4_ From the same Table 10 from the datasheet the maximum Input low level threshold voltage is 0.3 * VDD_IO = 0.3 * 3.3V = 0.99V.

If we assume the GPIO4 signal input buffer transitioned from 1 to 0 somewhere between 0.99V and 0V then its really hard to estimate a latency because GPIO48 starts to fall within this same window.

 

Overall Comments:

The rise/fall times for GPIO48 seem unexpectedly long, basically something seems wrong to me.  The slow rise/fall time on the input GPIO4 make it hard to know when the input transitioned with any time certainty.  The fact that GPIO48 started rising before GPIO4 was even close to a reasonable threshold voltage is very confusing.

I would think if there was a lot of bounce in contacting the wire to GPIO4 it would be in the plots, so don't think that's it.

Could the scope have some low pass filter setting turned on?

Keep in mind I'm trying to determine latency on the order 10's to 100ns.

I would suggest triggering GPIO4 from another GPIO output to have a fast transition signal for CH1 probe, but the fact the GPIO48 looks slow means there is more going on.

Please let me know your thoughts. 

[alejandro_e]

Hello @Gene1000, 

Sorry for the late reply. I re-tested but now with a different scope configuration, this is, the same program and probe position.

Here are the results, which are more reasonable:

Note that this is using the SMU core, no clocks were modified. This results can be improved by increasing the core frequency and using the RTU instead.

Thanks

[Gene1000]

Hi @alejandro_e ,

I was finally able to figure out that I needed to manually download and install the 32ZE Real-Time Drivers into S32 Design Studio (at least version 3.6 apparently) to get the pin configuration tool to work for the project files you sent:

So I wanted to clarify my point #1 above regarding pin settings:

As you mentioned all three configured IOs are set for input/output so that means both input and output buffers are enabled:

I would think with the output drivers enabled on "TRIG" pin it would not be compatible with driving the pin from and external signal (or 3.3V source).

The second point I was trying to make in #1 above was regarding the slew rate settings.  From the IOMUX spreadsheet attached to the reference manual, the IO pad types (1.8/3.3 or 3.3)  of each of the 3 configured pins can be determined:

So GPIO1 (LED) and GPIO4 (TRIG) are 3.3V type IO pins while GPIO48 (GPIO_48) is a 1.8/3.3V IO type.

In the pin configuration tool, both GPIO1 and GPIO4 have "slew rate control" value set to a reserved value for 3.3V io types.  Therefore, I was unsure how the output pad (oscilloscope channel 2) of your test would behave in terms of slew rate (rise/fall time).

Now that I can look at your project more, I was also looking at the clock configuration tool and I think the M33 is only set to run at 48MHz compared to its 400MHz potential.

While I don't think this clock speed has anything to do with the slow rise/fall times, it seems running at the full speed or better yet running the test on one of the R52's at 800MHz would give the best numbers.

@alejandro_e, I'm still looking for some data that can give me some confidence that the S32Z has the potential to meet my needs.  But looking at the present data, I'm not convinced that an 800MHz chip (even an SoC) would loose to an Arduino by orders of magnitude when it comes to direct IO control latency.

Also, now that I've looked at the development board closer I think there is a better test we could do with a single jumper across 2 pins to generate the trigger source for an input pin that is then read by the MCU and used to send an output signal (i.e., no hand wire triggering).

  I would be willing to write up the code, etc. if you could run the test on your eval board (if possible, are there any issues with me starting with the same example code you used, but for the faster R52 core instead of M33?).

Thanks,

Darrell

[alejandro_e]

Hello again,

Once you have analized the data in the last images please let me know if it makes more sense to you.

Regarding the test with the R52, faster clock speed and with a trigger signal instead of a simple wire trigger. What I wanted is to give you results as fast as possible, and although that test you mentioned is a somewhat outside the scope of the support we offer in this community, I may be able to do it, but it may take me a considerable amount of time, not because it is particularly hard, but because I have to do it while still working on other support tickets.

Please let me know if the current information is enough or if you need another test with a faster configuration.

Thanks 

Thanks for your patience

[Gene1000]

Hi @alejandro_e ,

Looks like our posts "crossed":), thanks for your efforts!

Your new data looks much, much, much, more consistent with what I would expect...bouncing in the wire signal when disconnected and pulled down by the internal pull down resistor, and fast rise when connecting to 3.3V, along with the GPIO48 output signal having a rise/fall time << 1us, to fast to judge on your scopes time scale, the way it should be), etc. etc.

Unfortunately for my needs I was hoping for much lower latency than 2.4us (<100ns).

However, the question that is still a bit unanswered is whether this latency is due to the M33 core and slow clock, or just inherent to the peripheral bus structure?

I know the R-series (R52) cores are designed to be real-time and have a different peripheral interface bus than the M33...but without test data (or that top secret information you spoke of about internal architecture) I have no idea as to what parts of that 2.4us latency are attributable to the core vs. common parts like the SIUL, etc.?

Since your test setup is giving data that is plenty good enough to estimate a latency, I would say that if you can get to it , trying the same thing on an R52 core at 800MHz would be valuable to me so that I can have a definite conclusion.

If you can get to another test, besides changing the Core to an R52 and Core Clock to 800MHz, are there any other clocks that feed the busses/peripheral that would help reduce latency?

Thanks again for your time!

[alejandro_e]

Hello @Gene1000,

Yes it seems that we missed each other by a couple of minutes.

Regarding the tests, I can test using the R52 cores, however I will not be able to modify the clocks as it may require too much time to make it work correctly.

Other than the core and its clocks, the program could be faster if done in assembler. The SIUL0 clocks are have not other option in S32DS, only FIRC at 48MHz. In case you need to test this setups, I would recommend doing the test on your side, you can contact one of our distributors, they may be able to lend you a board for some time to perform the test.

Please allow me some time to repeat the test with the R52 core, I will get back to you.

[Gene1000]

Hi @alejandro_e ,

"Other than the core and its clocks, the program could be faster if done in assembler."

I was wondering about the compiled code also so I did an object dump of "main.o":

Looks like about 5 instructions max, so execution time (w/o GPIO peripheral stalls) is probably around 5 * 1/48MHz ~= 100ns.

So majority of the 2.4us latency is probably not related to loop instruction time, but rather the peripheral load/store instruction time/stalls.  Increasing the clock to 800MHz would bring thie processing time down maybe to <10nS, But that still leaves essentially 2.3us or so for the whole transaction..

If this clocks have any other benefits in terms of the peripheral bus is unclear to me.

"however I will not be able to modify the clocks as it may require too much time to make it work correctly"

In case I wanted to get a board and test at the fastest clock, what references are available for adjusting clocks.  I figured bumping up the clocks (at least on the cores) would be straight forward or there would be some good examples to get it to work.  Should I be concerned that there is some "magic" to getting things to run reliably at datasheet specs of 800MHz (seems 1GHz devices are not available yet based on part number)?

Cross our fingers that simply jumping to the R52 cores has some impressive results.

Thanks again for your time.

[alejandro_e · Accepted solution]

Hello @Gene1000,

I apologize for such a late reply, I was not able to perform the tests before. I was finally able to perform the same test but with the R52 core, however I got a slightly worse result, since the SIUL_0  and SIUL_1 for GPIO48 and GPIO4 respectively, are closer in the system to the SMU, as you can see in the architecture image I uploaded before. Regarding the clock configuration, please check AN13631 - S32Z2/E2 Progressive Clock Frequency Switching, there you will see the steps needed to configure a faster clock either for the SMU or R52 cores.

Again, sorry for such a late reply. 

[Gene1000]

@alejandro_e ,

No problem with the delay, I appreciate these aren't "off the top of your head" types of questions and needed some real work.

Hopefully some day an app note will come out with some performance benchmarks for the S23Z that encompass latency, throughput, etc. under various conditions to provide some data as a starting point.

I read over the app note on progressive clock switching...good thing is that is doesn't seem impossibly complex.  To bad the examples don't just have that built in so that you can specify some clocks when working with the examples (at least when used on the eval board).

Thanks again for your help, I think I have some expectations now for what to expect in terms of my latency question.