41
November 2016
I
ndustrial
C
ontrol
& C
omputing
our device has to provide just the commu-
nication part of the system. In this case the
device must support a flexible and high speed
interface to the system CPU (host) with cer-
tain synchronization capabilities for event
handling and data exchange. To support also
a wide range of legacy systems, other lower
speed interfaces like UART and SPI should be
available too.
Turning to small network nodes requiring
low- to mid-performance to compute an
application, our ideal device should be a SoC
(System on Chip) with its own CPU able to
process both the communication protocol
and the application. Performance often comes
along with high power dissipation. Many
products in the automation arena are sensitive
with respect to power and temperature. Rea-
sons include that they run in a high-tempera-
ture environment, use small housing without
active cooling measures, and others. Thus our
solution should include certain power-saving
features in order to relax the typical perfor-
mance/power barrier. Last but not least our
ideal single-chip device provides a kind of
communication-specific flexibility to support
a multi-protocol capability for a wide range of
the industrial Ethernet protocols. This should
cover both groups as already described. All
this should be available in an ASSP-type
device to enjoy a price advantage from low to
high volumes. OK, so far so good. Does any-
body have this ideal device?
At this point, thinking about the requirements
of Industry 4.0 networks and multi-proto-
col capabilities, Renesas developed the R-IN
Engine hardware (R-IN: Renesas Industrial
Network). The architecture of this function is
perfectly suited for different Industrial Ether-
net protocols and is more or less, as a distinct
and independent block, already used in differ-
ent Renesas product families.
The R-IN Engine architecture shown in fig-
ure 4 is first and foremost a sub-system
with an ARM Cortex-M3 CPU and all on
SoC-required components: memory blocks
for instructions, data and other functions,
interrupt controller and the corresponding
multi-master bus system to different internal
and external device re-sources, as well as the
ability to debug. The multi-master bus allows
concurrent data transfers between different
areas without the requirement to interrupt the
internal or external host CPU. When looking
to the networking further components for
Ethernet communication are included as well:
a Gigabit Ethernet switch with three ports,
one internal and two external (as already
described). Further on the R-IN Engine
includes an Ethernet MAC with associated
DMA controller and required buffer memory
explicitly used for Ethernet data transfers. In
order to implement one protocol of the sec-
ond group, the communication data path
can be switched with respective multiplexers
from the standard Ethernet path (IEEE 802.3
Switch and MAC) to the IE protocol control-
ler of the second group.
Beyond this purely functional approach
to support industrial networks, the R-IN
Engine includes some accelerators replac-
ing functions which nowadays are typically
implemented solely in software. In terms of
real-time requirements the processing of net-
work functions is decisively speeded up with
these accelerators at central points in the com-
munication.
The HW-RTOS accelerator primarily supports
the software execution with automated and
prioritized task scheduling. Moreover this
special hardware supports task synchroniza-
tion via event flags, semaphores andmailboxes,
as well as a general task and time manage-
ment. Last but not least certain RTOS func-
tions can directly be executed by a number of
interrupt signals without any involvement of
the R-IN CPU. Being closely connected to
the CPU, HW-RTOS can sometimes highly
accelerate both the processing of the stack
software and the actual application. As the
term accelerator clearly indicates, everything
inside HW-RTOS is calculated by hardware
in a very fast and deterministic way without
the typical delays and jitter found in software
solutions. From the software perspective the
use of the HW-RTOS accelerator is based on
a μItron library with a documented API and
the related SW parts allowing a smooth proj-
ect start. Therefore HW-RTOS is completely
transparent for the user and does not require
a detailed knowledge of the control structures
of this accelerator.
When receiving or sending a frame byte the
CheckSum accelerator automatically calcu-
lates on-the-fly the 4-byte checksum placed at
the end of Ethernet frames. This calculation
is solely done by the accelerator without load-
ing the R-IN CPU. In the receive direction the
correctness of the data can be checked in a
single step by comparing the calculated FCS
(frame check sequence) value with the frame
FCS field in the received frame. By contrast
Embedded News & Know-how Newsletter
