Async slower than Sync? TCB Single Shot on 2 Series

[SimonMerrett]

I'm using EXTCLK, events, RTC, TCBs and CCL on ATtiny3227. The 10 MHz EXTCLK is feeding RTC

  RTC.CLKSEL = RTC_CLKSEL_EXTCLK_gc;    // Use the incoming 10 MHz signal

I am generating a waveform output representing the RTC divided by 256 using events (clocked by the RTC clock - EXTCLK)

  EVSYS.CHANNEL3 = EVSYS_CHANNEL3_RTC_PIT_DIV256_gc; // set up channel 3 generator to be RTC divided by 256
  EVSYS.USERCCLLUT3B = EVSYS_USER_CHANNEL3_gc; // the other LUT input from Event Channel 3: prescaled RTC
  Logic3.enable = true;               // Enable logic block 3
  Logic3.input0 = in::event_b;           // Event B
  Logic3.input1 = in::masked;         // mask input 1
  Logic3.input2 = in::masked;         // mask input 2
  Logic3.output_swap = out::pin_swap;      // Set logic block 3 alternative output pin or PA5 (ATtiny))
  Logic3.output = out::enable;        // Enable logic block 3 alternative output pin or PA5 (ATtiny))
  Logic3.filter = filter::disable;    // No output filter enabled
  Logic3.truth = 0xAA;                // Set truth table - HIGH only if input 0 is high - for testing only
  Logic3.init();
  Logic::start();

Then I'm feeding the RTC_DIV256 level event into TCB1 and when that fires (at TCB1.CCMP match), it starts the single shot on TCB0. On the EVOUTC pin I am sending the pulse event when my single shot timer completes/matches TCB0.CCMP.

  TCB0.CCMPL = 0x7B;                              /* Compare or Capture low byte value*/
  TCB0.CCMPH = 0x0;                               /* Compare or Capture high byte value*/
  TCB0.CTRLB =  TCB_ASYNC_bm    |        /* Asynchronous Enable: enabled. Gives a tighter pulse feedback loop */
  TCB_CNTMODE_SINGLE_gc;                   /* Single Shot. This is key for generating controlled pulses */ 
  TCB0.EVCTRL = 1 << TCB_CAPTEI_bp    /* Event Input Enable: enabled. */
                  | 0 << TCB_EDGE_bp              /* Event Edge: disabled. We only want one input edge to trigger a pulse */
                  | 0 << TCB_FILTER_bp;            /* Input Capture Noise Cancellation Filter: disabled */
  TCB0.CTRLA = TCB_CLKSEL_CLKDIV1_gc            /* CLK_PER (divide by 2 prescaler) */
               | 1 << TCB_ENABLE_bp ;            /* Enable: enabled. Turn the timer on! */

The strange thing is the response of the TCB0 single shot event pulse, with respect to the RTC_DIV256 edges (remember, that's coming out of a LUT, not e.g. a WO or CLKOUT). When I set the TCB0.CTRLB ASYNC bit, the pulse is two clock cycles slower than when I leave the ASYNC bit cleared.

ASYNC = 1:

ASYNC = 0:

I understand that the single shot mode can take two clock cycles to commence timing (note that my TCB0.CCMP is set back from 0x80 by several counts to deal with the fixed offset which seems to occur in the propagation between TCBs, events and LUTs). Everything on this system is clocked by the input EXTCLK, so there shouldn't be any mixed clock domain issues for anything which is SYNC. But I can't see anything in the docs that would explain why ASYNC is slower than SYNC in TCB0 EVOUT.

Please shout if you can see where this or any other signal propagation delays may be coming from. If anyone would like to test this, please say and I will provide a minimal example.

---

EDIT

I have re-read the TCB section on single-shot mode. I think it might explain the observed behaviour after all. Although it appears when the signal of interest to be counted is (or synchronous with) the peripheral clock the ASYNC offers no advantage.

22.3.3.1.7 Single-Shot Mode
The Single-Shot mode can be used to generate a pulse with a duration defined by the Compare (TCBn.CCMP)
register, every time a rising or falling edge is observed on a connected event channel.
This mode requires TCB to be configured as an event user and is explained in the Events section.
When the counter is stopped, the output pin is set low. If an event is detected on the connected event channel, the
timer will reset and start counting from BOTTOM to TOP while driving its output high. The RUN bit in the Status
(TCBn.STATUS) register can be read to see if the counter is counting or not. When CNT reaches the CCMP register
value, the counter will stop, and the output pin will go low for at least one counter clock cycle (TCB_CLK), and a new
event arriving during this time will be ignored. After this, there is a delay of two peripheral clock cycles (PER_CLK)
from when a new event is received until the output is set high.When the EDGE bit of the TCB.EVCTRL register is
written to ‘1’, any edge can trigger the start of counter. If the EDGE bit is ‘0’, only positive edges will trigger the start.
The counter will start counting as soon as the peripheral is enabled, even without triggering by an event, or if the
Event Edge (EDGE) bit in the Event Control (TCBn.EVCTRL) register is modified while the peripheral is enabled.
This is prevented by writing TOP to the Counter register. Similar behavior is seen if the Event Edge (EDGE) bit in
the Event Control (TCBn.EVCTRL) register is ‘1’ while the module is enabled. Writing TOP to the Counter register
prevents this as well.
If the Event Asynchronous (ASYNC) bit in the Control B (TCBn.CTRLB) register is written to ‘1’, the timer will react
asynchronously to an incoming event. An edge on the event will immediately cause the output signal to be set. The
counter will still start counting two clock cycles after the event is received.

So, my TCB0.CCMP is aiming for 0x80. I have to reduce that by one count (clock cycle) to account for the single cycle duration of the event pulse. I then have to reduce it by two further counts (clock cycles) for the initialisation / start timing delay of TCB0 in single shot synchronous mode. And if I want to use single shot asynchronous mode, I need to reduce it by a further two counts (clock cycles). Well, at 0x7B, I am five clock cycles short in single shot synchronous mode, so I don't know where those two additional counts (clock cycles) go.

EDIT 2022-12-02 I have amended code throughout this discussion that I have posted to use the more correct TCBn.CCMPL write, before writing TCBn.CCMPH immediately after to ensure both bytes are set (just writing to TCBn.CCMP is not the best way to do it).

[SpenceKonde]

I would try retesting with a very simple case:

Pick a pin. Set it output
Adjust the duration of the pulse to be shorter and the window on your scope to be wider so you will be able to see it from start to finish.
connect scope probes to timer output, and to the pin you chose above
Disable the TCB.
Configure thje timer to start countiing on the rising ende of event
Set the count to the TOP value to prevent the glitch during convfiguration as they say in the
Set event generator to the output pin
Set event user to timer
Enable the timer, set scope to take single trigger.

Wait for a few seconds, then use a single clock method to drive the pin high, eg digitalWriteFast(PIN_PA4,HIGH);
or
VPORTA.OUT |= 1<<4; // This method is only single clock for the 28 BPORT registers, and the 4 GPIORS.\

Either way it is rendered as sbi VPORTA 1<<4 (don't generalize this to other registrers. On any register outside the I/O space the compiler would instead generate lds (3 clocks 2 words) ori (1 word 1 clock) sts (2 word 2 clock for 7clocks and 3 words instead of 1 of each, since cbi nd sbi only work on the first 32 registers, and are the only ones that are atomic.

When that pin is your generator, it''s rising will trigger the scope, and you'' then see the beginning and end of the pulse (and if you've got mo0re than 2 channels you can watch the system clock too to make it more clear.

Those two beginning to end traces should make whatever is going on a lot more clear, whilst removing all the confounding variables of a wacky source of events and configurable logic - because I agree that the problem is single shot mode specifically. If that still reproduces the problem complain to microchip, because that would imply you found movel silicon errata.

[SimonMerrett]

Good idea to simplify/isolate things. I am getting more befuddled though. Took me a little while to get something working.

/* Async TCB Event Test
    Test to see if there is a difference in initialisation / response time between TCB
    in Single Shot mode if it is set to Async or Sync mode

              P P P P P P
              A A C C C C
              1 0 5 4 3 2
              | | | | | |
              o_o_o_o_o_o
       PA2 -o|           |o- PC1
       PA3 -o|  ATtiny   |o- PC0
       GND -o|           |o- PB0
       VDD -o|  x27      |o- PB1
       PA4 -o|           |o- PB2
       PA5 -o|___________|o- PB3
              o o o o o o
              | | | | | |
              P P P P P P
              A A B B B B
              6 7 7 6 5 4
*/
void setup() {
  EventSys_init();
  TCB0_init();
  PORTC.DIRSET |= PIN2_bm; // EventOutC
  PORTA.DIRSET |= PIN4_bm // Just use to trigger TCB0 start single shot mode on rising edge
                  | PIN5_bm; // TCB0 WO
}

void loop() {
  TCB0_set_sync();
  PORTA.OUTTGL = PIN4_bm;
  PORTA.OUTTGL = PIN4_bm;
  delay(5000); // wait longer after sync

  TCB0_set_async();
  PORTA.OUTTGL = PIN4_bm;
  PORTA.OUTTGL = PIN4_bm;
  delay(2000); // wait less time after async
}

void TCB0_init(void)
{
  TCB0.CCMPL = 0xF;                           /* Compare or Capture */
  TCB0.CCMPH = 0x0;                           /* Compare or Capture */
  TCB0.CNT = 0xF;                            /* We don't want the single shot to fire straight away, so we set this equal to TCB0.CCMP */
  TCB0.CTRLB = TCB_CCMPEN_bm                  /* waveform ouput enable - to compare with trigger pulse and clock waveforms */
               | TCB_CNTMODE_SINGLE_gc ;       /* Single Shot. Synchronous */
  TCB0.EVCTRL = 1 << TCB_CAPTEI_bp            /* Event Input Enable: enabled - to start timing */
                | 0 << TCB_EDGE_bp            /* Event Edge: disabled. We only want rising input edge to trigger the timer */
                | 0 << TCB_FILTER_bp;         /* Input Capture Noise Cancellation Filter: disabled */
  TCB0.CTRLA = TCB_CLKSEL_CLKDIV1_gc          /* CLK_PER (no prescaler) */
               | 1 << TCB_ENABLE_bp ;         /* Enable: enabled. Turn the timer on! */
}

void EventSys_init(void)
{
  EVSYS.CHANNEL0 = EVSYS_CHANNEL0_PORTA_PIN4_gc; // set up channel 0 generator to be PA5 level
  EVSYS.USERTCB0CAPT = EVSYS_USER_CHANNEL0_gc; // TCB0 start single shot begins on rising PA5 level
  EVSYS.USEREVSYSEVOUTC = EVSYS_USER_CHANNEL0_gc;      // route the TCB0 overflow event to the output pin C
}

void TCB0_set_sync(void)
{
  TCB0.CTRLA |= 0 << TCB_ENABLE_bp ;         /* Enable: disabled. Turn the timer off! */
  TCB0.CTRLB = TCB_CCMPEN_bm | TCB_CNTMODE_SINGLE_gc;           /* Turn async off */
  TCB0.CTRLA |= 1 << TCB_ENABLE_bp ;         /* Enable: enabled. Turn the timer back on! */
}

void TCB0_set_async(void)
{
  TCB0.CTRLA |= 0 << TCB_ENABLE_bp ;         /* Enable: disabled. Turn the timer off! */
  TCB0.CTRLB = TCB_ASYNC_bm | TCB_CCMPEN_bm | TCB_CNTMODE_SINGLE_gc;           /* Turn async on */
  TCB0.CTRLA |= 1 << TCB_ENABLE_bp ;         /* Enable: enabled. Turn the timer back on! */
}

with external clock 10 MHz and millis()/micros() on TCA0.

Here is the sync version:

And here is the async version:

One of the strangest things to me is that my CCMP was 0xF and yet I have the signal / waveform output highh for 19 clocks in async and 15 clocks in sync. I'm not sure this matches the datasheet description above. What do you think? And I find it also very strange that the waveform output is so different (with the async rising much faster) between pure waveform output and what happens when it has been through the LUT (which I cannot imagine adding delay using an asynch signal). Perhaps it should be the TCB0 CCMP event pulse, rather than the waveform output that I measure but I have deadbugged this ATtiny3227 and would need to solder another fine pitch wire to get EVOUTA/B available for a second EVSYS output. Maybe later.

[mosqu-ito]

In your second chunk of code here there is a comment that suggests you intended to change the CLK_PER prescaling, but did you in fact change it?

[SimonMerrett]

No, that's a messy leftover comment. Thanks for asking though.

There is a mistake in my implementation of Spence's suggested test: instead of probing the actual pin that is the trigger GPIO, I am probing the EVOUTC pin, which is not the same signal, necessarily (it has been through the event system). I shall have to actually do the soldering to gain access to another pin (breakout PCB is waiting on a couple of other components).

[SpenceKonde]

Well guess what I'm adding to my Tindie store? A freshly assembled batch of Rev. D ATtiny3227 PCBs ;-) no need to dead bug anything. Signals do take a finite length of time to pass through stages of the event system and the CCLs. You can demonstrate it by comparing a LUT with a truth table of 0b00000001, input 0 set to feedback and enable pin input. Or set the LUT - or the output pin - as a generator channel, set the CCLs eventA user to and use that as input 0. You;l see different speeds in both cases. But That's not, I don't think, exactly what's happening here. I'd first perform due dilligence by putting a _NOP(); or between those two toggle instructions. mostly as a sanity check I would also try instead of the port registers, doing it the fast way, with the VPORTs. and seeing how that changed behavior ``` digitalWriteFast(PIN_PA4,HIGH); digitalWriteFast(PIN_PA4,LOW)'; ``` or the equivalent but less readable ``` VPORTA.OUT |= 1<<4; VPORTA.OUT &= ~(1<<4); ``` Single bit set or clear in a register in the low I/O space (like the VPORTS) can be done in a single clock cycle. So I'd expect your code to do a 2 clock pulse, and my suggestion to do a 1 clock pulse (and in all cases, the clock pulses could be elongated wiith nops. You can use multiple in a row, or 2 clocks in 1 word with _NOPNOP (I think, if not you'll be able to next version.) You're either geting a 2 clock sync delay from the wrong edge, or a 4 clock sync delay and neitehr of those really make sense. I really think this is a Microchip support question, unrelated to anything the core has control over. Is this supposed to a syncronization delay of 2 clocks like I'd expect or is it four?" If they say that 4 system clocks is expected I'd love to see their explanation of where that is described in the datasheet, because I don't think it is. I've read that datasheet very carefully...

[SimonMerrett]

Thanks @SpenceKonde - sorry for the delay. I amended the loop() as per your suggestion, before moving on to the test. All the other code is the same:

void loop() {
  TCB0_set_sync();
  VPORTA.OUT |= 1 << 4;
  //_NOP();
  VPORTA.OUT &= ~(1 << 4);
  delay(5000); // wait longer after sync

  TCB0_set_async();
  VPORTA.OUT |= 1 << 4;
  //_NOP();
  VPORTA.OUT &= ~(1 << 4);
  delay(2000); // wait less time after async
}

Which produces the following traces:

So, it looks like the single clock pin command is working and _NOP() introduces the expected additional clock cycle delay when uncommented. However, the 19 cycle single shot period has not changed. So I'll try fixing my test to be closer to your original suggestion.

[SimonMerrett]

Just fixed the original test to match your suggestion better. I.e. I have not triggered the scope on the event caused by the pin rising edge but instead on the pin itself (it was an unprobed pin, with the probe on EVOUTC pin - now I'm not using the EVOUTC peripheral mode but am probing the same pin and toggling that instead of the previously unprobed pin).

void setup() {
  EventSys_init();
  TCB0_init();
  PORTC.DIRSET |= PIN2_bm; // EventOutC
  PORTA.DIRSET |= PIN4_bm // Just use to trigger TCB0 start single shot mode on rising edge
                  | PIN5_bm; // TCB0 WO
}

void loop() {
  TCB0_set_sync();
  VPORTC.OUT |= 1 << 2;
  //_NOP();
  VPORTC.OUT &= ~(1 << 2);
  delay(5000); // wait longer after sync

  TCB0_set_async();
  VPORTC.OUT |= 1 << 2;
  //_NOP();
  VPORTC.OUT &= ~(1 << 2);
  delay(2000); // wait less time after async
}

void TCB0_init(void)
{
  TCB0.CCMPL = 0xF;                           /* Compare or Capture */
  TCB0.CCMPH = 0x0;                           /* Compare or Capture */
  TCB0.CNT = 0xF;                            /* We don't want the single shot to fire straight away, so we set this equal to TCB0.CCMP */
  TCB0.CTRLB = TCB_CCMPEN_bm                  /* waveform ouput enable - to compare with trigger pulse and clock waveforms */
               | TCB_CNTMODE_SINGLE_gc ;       /* Single Shot. Synchronous */
  TCB0.EVCTRL = 1 << TCB_CAPTEI_bp            /* Event Input Enable: enabled - to start timing */
                | 0 << TCB_EDGE_bp            /* Event Edge: disabled. We only want rising input edge to trigger the timer */
                | 0 << TCB_FILTER_bp;         /* Input Capture Noise Cancellation Filter: disabled */
  TCB0.CTRLA = TCB_CLKSEL_CLKDIV1_gc          /* CLK_PER (no prescaler) */
               | 1 << TCB_ENABLE_bp ;         /* Enable: enabled. Turn the timer on! */
}

void EventSys_init(void)
{
  EVSYS.CHANNEL2 = EVSYS_CHANNEL2_PORTC_PIN2_gc; // set up channel 0 generator to be PA5 level
  EVSYS.USERTCB0CAPT = EVSYS_USER_CHANNEL2_gc; // TCB0 start single shot begins on rising PA5 level
  //EVSYS.USEREVSYSEVOUTC = EVSYS_USER_CHANNEL0_gc;      // route the TCB0 overflow event to the output pin C
}

void TCB0_set_sync(void)
{
  TCB0.CTRLA |= 0 << TCB_ENABLE_bp ;         /* Enable: disabled. Turn the timer off! */
  TCB0.CTRLB = TCB_CCMPEN_bm | TCB_CNTMODE_SINGLE_gc;           /* Turn async off */
  TCB0.CTRLA |= 1 << TCB_ENABLE_bp ;         /* Enable: enabled. Turn the timer back on! */
}

void TCB0_set_async(void)
{
  TCB0.CTRLA |= 0 << TCB_ENABLE_bp ;         /* Enable: disabled. Turn the timer off! */
  TCB0.CTRLB = TCB_ASYNC_bm | TCB_CCMPEN_bm | TCB_CNTMODE_SINGLE_gc;           /* Turn async on */
  TCB0.CTRLA |= 1 << TCB_ENABLE_bp ;         /* Enable: enabled. Turn the timer back on! */
}

And as far as I can see, the only difference from previous findings is that you can see a ~10 nanosecond propagation delay from the pin edge to the event edge (in previous traces above). So the edges are slightly offset from each other, whereas they were aligned before. But the 4 clock cycle setup and 19 clock cycle duration for a CCMP request of 0xF is still there. Do you think this warrants a support query with Microchip? Or am I misreading stuff?

[SimonMerrett]

I opened a ticket with Microchip support a few days ago and they have just assigned someone who said

Hi Simon,
Thanks for contacting Microchip Support.
Working on the case. Will get back to you at the earliest.

So that's positive. I linked to this discussion in the ticket, to save repeating everything above. So maybe you can let them know any further thoughts if you post here in the near term.

[SimonMerrett]

Microchip came back with:

Hi Simon,
Good day!
We can reproduce this issue at our end and the issue has been reported to the internal team. We will get back to you once we get a further update from the team.

so acknowledgement at a minimum. 👍 Will see what the internal team makes of it.

[SpenceKonde]

I'm guessing another entry on the errata list that doesn't get fixed

[mosqu-ito]

Always easier to downrate the specs than to uprate the reality. You're an impressive duo. Note to self: don't mess with Simon, he can find bugs right down on the metal.

[SimonMerrett]

The best bit is discussing the things I can't explain to myself here. It's only this community that means I'm not left with the assumption that I have failed to read the datasheet properly or configure the peripherals properly in code.

[SimonMerrett]

I have an update from Microchip support on the TCB event user behaviour:

Our AVR team have investigated this further, and believe the behavior is correct when the TCB single-shot mode is configured as a synchronous event user (TCB.CTRLB ASYNC=0). First take a look at the EVSYS Block Diagram, Figure 15-1, on page 126 of the ATtiny3227 datasheet. When the event generator is asynchronous, the 1 setting is used on the multiplexer. This means that the signal from the event generator is first delayed 2 clock cycles by the two D flip-flops, passed thru the multiplexer, and then sent forward to the channel mux for the sync event user. So there are already 2 clock cycles of delay on the signal when it arrives at the TCB. Then there is an additional delay of 2 clock cycles inside the TCB before the output is set high, as described in the single-shot mode section of the TCB chapter. Thus, the total delay is 4 cycles, composed of 2 inside the EVSYS (Figure 15-1) and 2 inside the TCB peripheral.

The team is still investigating the case when TCB is an asynchronous event user (TCB.CTRLB ASYNC=1). That case is more complicated and will take some additional time.

And a little while later, they came back with:

Our AVR team have further investigated the case when TCB single-shot mode is configured as an asynchronous event user (TCB.CTRLB ASYNC=1). In this case, the device is NOT behaving as described in the datasheet. According to the EVSYS Block Diagram, Figure 15-1, on page 126 of the ATtiny3227 datasheet, when the event user is asynchronous, the event generator signal is passed straight thru with no synchronization delay. Then, as mentioned in the Single-Shot Mode section of the TCB chapter, if ASYNC=1, an edge on the event will immediately cause the output signal to be set and the counter should start counting two clock cycles after the event is received. However, the measurements on the device show that the counter starts counting four clock cycles after the event is received. There is definitely a discrepancy between the datasheet and the silicon behavior when TCB is an asynchronous event user.

So, we have been seeing async running slower than expected. I've asked if this will end up in errata but maybe @SpenceKonde wants to add it to his own list in this repo.

[mosqu-ito]

That's pretty cool, Simon. So many of us (well, me anyway) would have just shrugged and moved on, but you got to the bottom of it. Thanks.

[SpenceKonde]

If yo describe it and let me know what parts it happens on I'd be happy tp put it onto the errata lists.

Async events on otherwise sync devicves is something thy seem to strugle with (like not surprising, it sounsds hard.

Apparently the second about pin interrupts having a 3 clock retrigger delay on partially async but not fullty async pins is also backwards.

Of course, it is, because the async event source needs to get synchronized to the system clock!

[SimonMerrett]

Latest from Microchip support:

After checking with internal team, so far, it is likely the behavior may affect all tiny0/1/2 and mega0 series (sharing the same TCB macro), but it needs confirmation by design team. We are waiting for their reply and will come back to you.

[SimonMerrett]

I have a final answer from Microchip:

Below provided is the feedback from the internal team.

“Since the event is async, the TCB will start counting 2-3 cycles after the async event is received, but since the PWM is set/cleared one clock cycle delayed compared to the counter value the PWM output ends up, in this mode, being 3-4 clock cycles longer than defined by the CMP setting.

It is the same for all: tiny0/1/2, mega0, AVR DA/DB/DD”

With this confirmation, the behavior affects all tiny 0/1/2, mega0, AVR Dx families (sharing the same TCB macro).

So this affects lots of parts. Hope it isn't a problem for anyone else.

[SpenceKonde]

Thanks for update. I dobt suppose theycmenrioned if it was silicon errata (it not working but some day we hope to fix it maybe, or a datasheet clarifucation type issue so i know what to say in the errata summary?or a a datasheet clarification? " oh, did we say it would do something else ? Let me see that datasheet, u can clear that right up" * holding a marker*

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Thu, Dec 1, 2022, 20:40 SimonMerrett ***@***.***> wrote: I have a final answer from Microchip: Below provided is the feedback from the internal team. “Since the event is async, the TCB will start counting 2-3 cycles after the async event is received, but since the PWM is set/cleared one clock cycle delayed compared to the counter value the PWM output ends up, in this mode, being 3-4 clock cycles longer than defined by the CMP setting. It is the same for all: tiny0/1/2, mega0, AVR DA/DB/DD” With this confirmation, the behavior affects all tiny 0/1/2, mega0, AVR Dx families (sharing the same TCB macro). So this affects lots of parts. Hope it isn't a problem for anyone else. — Reply to this email directly, view it on GitHub <#735 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW6YJZELO22QVWZXGNDWLFHQRANCNFSM53A33LAQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[SimonMerrett]

I've asked them as the rest of the reply didn't give any insight on that front.