Re: [RTnet-developers] some suggestions for the next TDMA version

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Jan Kiszka wrote:
> >> Karl Reichert wrote:
> >>> Jan Kiszka wrote:
> >>>> Karl Reichert wrote:
> >>>>> Hello,
> >>>>>
> >>>>> I'm currently working on getting RTnet working on an Infineon
> TriCore
> >>>>> 1130 and found some issues, which could be solved in the next major
> >>>>> TDMA version comming with RTnet. Would like to discuss these issues
> >>>>> to see other's opinion about that.
> >>>>>
> >>>>> The TriCore1 architecture is a little bit tricky. When you want to
> >>>>> send a frame over Ethernet, the host (the "cpu") has to write it
> into
> >>>>> a shared memory (available via FPI bus). Then the host writes a
> >>>>> special register to tell the DMUT (Data Management Unit Transmit) to
> >>>>> get this Frame from shared memory and write it into Transmit Buffer
> >>>>> TB. The TX block of the MAC takes the frame from TB and sends it to
> >>>>> MII, which will put it on the wire. All this can be found in detail
> >>>>> in [1], chapter 31.
> >>>>>
> >>>>> Here comes the problem: When sending request calibration frames, one
> >>>>> has to provide a transmission time stamp as close as possible to the
> >>>>> real transmission time. As the TriCore does not support changing the
> >>>>> frame after writing it into shared memory (by host), there is no way
> >>>>> for providing a real transmission time stamp. Only option is to put
> >>>>> the scheduled transmission time there which will have the effect,
> >>>>> that transmission time on the wire t_trans is always calculated to
> >>>>> long because the real transmission is done later.
> >>>> Unless you have to make the steps of writing to the shared mem +
> >>>> triggering the transmission preemptible, the solution is simple: just
> >>>> push out the local time taken right _before_ you start writing the
> >>>> frame. For your arch, that is the point "as close as possible" to the
> >>>> real tx date.
> >>>>
> >>>>> To fix this issue there will be a few possibilities, one comes here:
> >>>>> One could change TDMA.spec and allow slaves to send a two-parted
> >>>>> request calibration frame. First one has a don't care Transmission
> >>>>> Time stamp (marked as don't care by a bit or sth similiar). Slaves
> >>>>> will notice their transmission time stamp in their TXISR, and send
> it
> >>>>> in the second ReqCalFrm. This would make the whole process much more
> >>>>> precise, but of course requires changes in TDMA.spec.
> >>>> Yeah, that's how NTP and PTP work as well (follow-up message carrying
> >>>> the timestamp of the first one), IIRC. Would be possible to extend
> the
> >>>> specs, but there should be real hard needs for it.
> >>>>
> >>>> Again, as long as the tx timestamp is taken at a fixed date before
> real
> >>>> tx, TDMA can handle this (may one should clarify the spec in this
> >> regard).
> >>>> Jan
> >>>>
> >>> Well, the problem is that FPI bus is a shared bus, which will have the
> >> effect that in some cases it may take longer until the frame is on the
> wire
> >> and in some cases it may take less time. As a result, the tx timestamp
> is
> >> _not_ taken at a fixed date before real tx.
> >>
> >> OK, that sounds almost like a "hard need". What are the other users on
> >> this bus, and who is controlling the access (host or devices)? And what
> >> dimension would the jitter then have (10 of microseconds, more, or
> less)?
> >>
> >> Jan
> >>
> > Other users can be in general every device also connected to FPI bus. In
> my case, some memory is also connected to FPI, which has the effect, that
> host and all devices using this memory accessing the bus. As those devices
> may read/write async from/into the memory, there is no way to ensure stable
> times accessing this bus.
> > The dimension of the jitter is very depending on the situation. In my
> case, using only host and Ethernet-Controller, this value is always around 11
> µs, jitter is less then 2 µs. But this is really depending on the use
> case. If there would be other devices using the bus (USB, serial ...), the
> jitter will be much higher for sure. Would be worth to do some tests for
> that, but I'm lacking time ATM, I'm sorry. But they will be high, for sure.
> 
> Thinking about this a bit further: When you can face such high jitters
> on the FPI bus, won't your RX timestamps be impacted by them as well?
No, they don't because rx timestamp is taken by host in MACRXISR and there is no connection to FPI bus cause the interrupt isn't affected in any way with FPI.

> And will you compensate for the TX jittery also by uploading the final
> frames early enough before the scheduled slot time during normal
> operation?
> 
Yes, that's my strategy: Putting the frame already so close to MACTX unit that only transmit enable signal is set when slot starts.

> If you FPI bus is really that indeterministic as you fear, the whole
> system would be fairly unsuited for RT applications. I think I heard
> that Tricore is used heavily in industrial and automotive, isn't it? Are
> there better peripheral interfaces then? Well, at least for you
> scenario, those 2 us jitter would be _far_ better than what you get on
> any RTOS-managed platform, so no need to worry. Still, this requires
> some more analysis to be sure - and that means it may cost time... :)
> 
> Jan
It is deterministic, but only in special cases. You can asign priorities to units, so the unit with highest FPI priority will get the bus no matter what and then of course the jitter is very low and deterministic. Problems occur whenever you need more then one unit communication over FPi because in some cases it is necessary to not give highest priority to ETH unit.
So, to say it more clear: In my case, in my current situation, using only ETH unit and therefore having a very small jitter of only 2 us, a new TDMA draft is _not_ needed. But when one thinks a bit further those problems have to be faced. Using more units with the need for real time behavior will cause higher latency and let this problem grow.
So my idea was not really an urgent case, more sth to discuss when you look in the future ...

Karl
-- 
von Karl Reichert

NEU! +++ GMX empfiehlt DSL-Komplettpaket von 1&1  +++
Surfen und Telefonieren!*: http://www.gmx.net/de/go/dsl