RU2691886C1 - Complex-functional unit for vlsi-type system on chip - Google Patents

Abstract

FIELD: data processing and transmission.SUBSTANCE: device is made with possibility of its operation in mode of master electronic device or in mode of slave electronic device in system of electronic devices, in which serial data communication via bus between master electronic device and at least two slave electronic devices, contains local memory, in which a descriptor table and a data storage area are located, a DMA controller for exchanging data between the system memory of the VLSI and the local memory of the unit, a bus controller for communicating data between the local block memory and the bus, a handler list handler for controlling operation of the DMA controller and the bus controller in accordance with descriptors in the local memory.EFFECT: technical result consists in automation of data exchange between electronic devices, providing possibility of use in real-time systems, and high level of reliability of transmitted information.1 cl, 12 dwg, 4 tbl

Description

The invention relates to the field of data networks. The application describes an interface complex-functional unit (SF-unit), designed for VLSI type "system on chip", designed to exchange data in accordance with the protocol.

In the course of work on the development of VLSI type "system on chip" (hereinafter SoC) for use in industrial computers, including controller equipment, relay protection and automation terminals and automated process control systems (APCS), a functionally finished SF block "TSI_controller", designed for software and hardware implementation of the protocol. Using the TSIcontroller SF block, data is exchanged on the bus with external devices in relation to SoC. SoC with the claimed SF-block manufactured by 28 nm CMOS technology. The SF block described in the application, depending on the application, supports one of the two protocols. The first protocol (TMB5000) is described in the application for the invention of EA No. 201700029 A1, published on February 28, 2018, and in the application for invention RU No. 2014111465, filed on 03/30/2018. The second protocol (TSI) is described in this application. When describing the SF block and protocol, the terms used have the following meaning:

“Data exchange protocol” or “data transfer protocol” - a set of rules and agreements that define the content, format, time parameters, sequence and error checking in messages exchanged between devices of the system.

“Master device” is a device that sends data to other devices and / or requests data from other devices, i.e. is the initiator in the exchange of data with the slave.

"Slave device" - a device that can exchange information only with the master device after the corresponding request is received from the master device.

"Interface Subscribers" - electronic devices, the exchange of data between which is carried out through the main serial interface.

“Bus” is a differential twisted pair of wires or a differential pair of conductors on a printed circuit board, through which data is transmitted in the form of electrical signals from the sender to the receiver.

“Shared bus” or “trunk” is a type of communication line in which all subscribers are connected to a common communication line. The common line of communication is used by all subscribers in turn. All messages sent by individual subscribers are heard by all other subscribers connected to the communication line, but the subscriber selects only messages addressed to him from the message flow.

A “word” is a string of bits that is considered as a whole when transmitted, received, switched, processed, displayed, and stored.

“Control package” is a block of data processed by network programs as a whole. The package consists of data that performs the role of service information necessary to implement the protocol.

"Information Package" is a data block processed by network programs as a whole. A packet consists of service data and payload that must be transferred.

The overall structure of the control or information package is determined by the composition of the package and its format.

“Composition” - various types of data contained in the package.

"Format" - the dimension and order of placement of various types of data.

“Message” is a sequence of transmitted control and information packets.

The hardware and software execution of the interface peripheral device depends on what protocol it is intended to implement and on the special requirements imposed on it.

From patent sources known input-output devices used to implement the following interfaces:

- A device is a communication interface (controller) for the Space Wire network (patent RU No. 2483351 C1 and patent RU No. 175049 U9) for multiprocessor computing systems with distributed information processing and for local computer networks created on the basis of the Space Wire technology [ECSS Standard ECSS- E-50-12A, "SpaceWire, Links, Nodes, Routersand Networks", Issue 1, European Cooperation for Space Data Standardization, February 2003]. This device is designed to collect information from a variety of sensors and other similar modules that do not have processor control when building distributed computing systems used in embedded applications, including onboard computing systems. The SpaceWire controller is formed by a receiver and transmitter with the necessary controls and interfaces. In the SpaceWire network, subscriber nodes are connected to a routing switch. A routing switch provides direct traffic between its input and output ports. A subscriber node differs from a switch in that the translation of data between its link ports is possible only under the control of the host device (that is, it is implemented by software).

- Known communication module for the network FlexRay (patent RU №2380841 C2). The FlexRay protocol operates using the time-division multiplex access method, according to which different fixed-to-subscriber devices are assigned different fixed time intervals during which these devices have the exclusive right to access the communication channel. The time intervals are repeated in each cycle, so the time at which the message is transmitted over the bus is precisely defined and access to the bus is deterministic. The subscriber network device FlexRay has its own processor and FlexRay bus controller (communication controller). In this case, the subscriber's processor generates and processes data transmitted via the FlexRay bus controller.

- Known SPI module for SPI serial peripheral interface (AV Evstifeev, AVR Microcontrollers of the Classic family of ATMEL company - 6th ed., Sr. - M .: Dodeka-XXI Publishing House, 2008, World Series electronics ”, pp. 273-344), adopted as a prototype for the claimed complex-functional unit of the system on a chip. The SPI module is implemented in AVR microcontrollers from Atmel's Classic family. The SPI module has two purposes. Through it, the microcontroller can be programmed (the so-called sequential programming mode). The second purpose of the interface is the organization of high-speed data exchange between the microcontroller and various peripheral devices, such as digital potentiometers, D / A converter, Flash ROM, etc.

Through this interface, data can also be exchanged between several AVR microcontrollers. When exchanging data via the SPI interface, the AVR microcontroller can operate both in the Master mode and in the Slave mode. At the same time, the user can set the transfer rate (four programmable values) and the transfer format (from low-order to high-order or vice versa).

One of the problems that confront developers of input-output devices is to maximally automate the process of exchanging data between network subscribers and, thus, relieve the processing power of the central processor (CPU). For this, the I / O devices are equipped with additional devices that could take the CPU load on the bus control and execution of the programmed sequence of messages on the bus. This will free up CPU resources for other work. Thus, a bus controller (US patent No. 4,805,137) is known, which is designed to transmit data according to the interface described in the standard MIL-STD-1553B, dated September 21, 1978, " designation of the US Department of Defense standard for a digital command data bus interface / command / response). This standard describes a centrally controlled backbone serial interface used in an electronic device system (“controller”, “remote terminal” and “monitor”). The MIL-STD-1553B interface functions asynchronously, in the command-response mode, in which only the bus “controller” initiates information exchange and transmission control. A system of electronic devices is a real-time system in which the “controller” and “remote terminals” must respond in strict time frames and any interaction with the CPU degrades the response of the system. A disadvantage of the known bus controller is that it only partially relieves the CPU from some bus management tasks. To do this, a “command block” is introduced into the bus controller, which is the main state machine and is designed to control the movement of data between registers and other modules in the bus controller in a programmed sequence, regardless of the CPU. The operation of the “command block” can be stopped when the CPU intervenes. Known bus controller for MIL-STD-1553B is implemented on a dual-purpose chip, which can perform the functions of both a "controller" and a "remote terminal".

A description of the system is known for implementing the "Bus Mastering" mode of peripheral devices in a computer system (US patent 5,905,912). The known system is designed to provide automatic data transfer between a computer system and its peripheral devices. The system is also designed to initiate and complete an automatic transaction. In addition, the system has the ability to process multiple transactions without the intervention of the computer system CPU. For the implementation of these tasks, the system for the "Bus Mastering" mode of peripheral devices in a computer system (in particular, a personal computer) consists of four main elements:

- DMA-controller (DMA controller), designed to transfer data to the memory of the computer system and from it.

- A list processor connected to the DMA controller for programming the DMA controller, generating and sending command signals to the DMA controller and obtaining the status of the DMA controller after the data transfer is completed. The list of descriptors is stored in the memory of the computer system. Descriptor list items describe every data transfer that the list processor initiates, controls, and terminates. A microcontroller or a computer CPU can be used as a list processor.

- The controller of the peripheral device (Device controller) connected to the DMA controller and the list processor, designed to respond to command signals from the list processor, transfer data to and from the DMA controller after the data transfer returns the completion status to the list processor. A USB controller, an IrDA controller, an IDE hard disk controller can be used as a peripheral controller. The use of a particular controller depends on the peripheral being monitored.

- Bus controller associated with the DMA controller and processor list. The bus controller implements the request to transfer data from the memory of the computer system to the DMA controller and the list processor. The list processor sends commands to the peripheral device controller and receives the completion status from the peripheral controller. The DMA controller transfers data blocks between the memory of the computer system and the peripheral controller. The disadvantage of the described system is that it does not provide a deterministic access time of the list processor to descriptors stored in the memory of the computer system, and, therefore, it cannot be used in real-time systems where the system must respond within the required rigidly fixed time ranges. .

The SF block described in this application is a peripheral SoC block intended for use in computers for physical process control systems (controller equipment, relay protection and automation terminals and process control systems), which are real-time systems. The correctness of the functioning of real-time systems is determined not only by the correctness of the calculations, but also by the time at which the desired result is obtained. If the time requirements are not met, the system is considered to have failed.

The purpose of the invention is to develop a peripheral interface SF-block for systems on a chip of a class of microprocessors or microcontrollers, providing data transmission in accordance with the protocol described in the application. The SF block should be designed in such a way as to maximally automate the process of data exchange between electronic devices. The SF block must provide deterministic reaction time for its use in real-time systems. SF block must provide a certain level of reliability of the transmitted information. The SF block must be able to operate in both master mode and slave mode, as well as in monitor mode.

The technical result is achieved by the fact that the interface SF block for VLSI type system-on-chip is designed in such a way that it can operate as a master electronic device and a slave electronic device with an electronic device system in which serial data is exchanged over the bus between the master electronic device and at least two slave electronic devices. The SF block contains a local memory in which the descriptor table and a storage area are located, a DMA controller for exchanging data between the VLSI system memory and the local block memory, a bus controller for exchanging data between the local block memory and the bus, a handler a list of descriptors designed to control, in accordance with the descriptors in the local memory, the operation of the DMA controller and the bus controller.

Brief Description of the Drawings:

FIG. 1 is a block diagram of a system in which subscribers are connected to a common trunk link;

FIG. 2 - block diagram of SoC blocks;

FIG. 3 is a block diagram of the SF block, in which data flow is shown by lines (control signals not shown);

FIG. 4 - transfer of logical zero and one in the Manchester-2 code;

FIG. 5 - data packet sync and control burst sync;

FIG. 6 - data packet structure (DATA);

FIG. 7 - control package structure (CTRL);

FIG. 8 - information package structure (CTRL + DATA);

FIG. 9 - the format of messages "write data to the slave device";

FIG. 10 - message format "broadcast message";

FIG. 11 - “read data from slave device” message format;

FIG. 12 - the message format "the inability of the slave to issue the requested data."

In order to exchange data 1 (Fig. 1) according to the protocol described in the application, a system is used in which data is exchanged between subscribers (2, 3, 4) via bus 5. For data exchange, it is enough that at least one of subscribers contained the master electronic device (Master) 6 (hereinafter the master device) and at least two subscribers contained a slave electronic device (Slave) 7 and 8 (hereinafter the slave device). Data exchange in the system occurs on a specified cycle.

For example, in a programmable logic controller (PLC), subscribers 2, 3 and 4 are the central processor unit, input module and / or output module, and the internal digital bus RV is used as bus 5. FIG. 1 also shows field (low) level devices, namely, a rotational speed sensor 9 connected to an input module; a 3rd engine 10 connected to an output module 4. Also shown in FIG. 1, the data exchange system between subscribers contains subscriber 11 with an electronic monitor device (Monitor) 12, designed to “listen” for traffic on bus 5. In a PLC, such a subscriber may be a backup central processor unit. Only one of the two redundant PLC CPU modules can be active at the same time. If a central processor unit with a master (Master) fails, another central unit with a monitor device (Monitor) takes over the initiation of information exchange on the bus. The subscriber can be an intelligent sensor and / or an intelligent electric drive 13 connected via the slave electronic device 14 directly to the bus 5. The monitor 12 can be used as the master device 6, the slave device 7 and the device 12 as described in this application , which is a peripheral interface unit SoC (SoC) 15. The SF-unit supports work with duplicated tires 5 and 16.

SoC 15 (Fig. 2) contains the following main functional units: one or several central processors (CPU) 17, internal system memory (SRAM) 18, input-output devices 19 (one or several input-output devices described in the SF-1 application unit 19), and a memory controller (MS) 20, designed to control the input and output of data from external memory (SDRAM) 21. The main functional units are interconnected by interconnects block (blocks) (INTERCONNECT UNIT (S)) 22. Central processor 17 is the central processing and control unit the work of SoC.

The SF-unit 19 can operate in one of three modes: “Master”, “Slave”, “Monitor”.

The SF block 19 (Fig. 3) contains a handler 23 of the list of descriptors (hereinafter referred to as OSD) with a DMA controller 24, an array of control and status registers 25, a local memory 26, a bus controller 27, a low level I / O block 28. The SF block includes multiplexers (not indicated by a position). The SF block can work with one bus 5, and supports work with duplicated tires 5 and 16.

As bus 5, M-LVDS can be used - low-voltage low-voltage differential signaling technology described in TIA / EIA-899-2002 international industrial standard (Electrical Characteristics of Multipoint-Low-Voltage Differential Signaling (M-LVDS) Interface Circuitsfor Multipoint Data Interchange). Multipoint LVDS (M-LVDS) is designed for multipoint bidirectional communication. To do this, carry out half-duplex data transmission on a single bus.

Data exchange of the IP-block with the main functional units of the SoC 15 is carried out through the system buses AXI 29 and / or ARV 30.

Local memory 26 of 8 KB in size with the organization of 2048x32 is located inside the SF block. When the SF block is used as the master device, the access of the OLD 23 to the descriptors takes 1 clock. This provides a deterministic task acquisition time (control information), which is of great importance for real-time systems.

Depending on the operation mode of the SF block, local memory has a different organization. In the “Master” mode, the table 31 of descriptors and the memory area 32 for data are located in the local memory 26. The memory area 32 for data is intended for intermediate storage of data to be transmitted and received data.

Table 31 of the descriptors contains:

- control information for forming a transaction on the bus;

- the address of the data buffer in system memory;

- the result of the transaction (updated after the transaction).

In the descriptor, the system software records such data as slave addresses, address space numbers, address space sizes, polling period of a specific address space of a specific slave, direction of operation (read / write), type of operation (data space or configuration space), end-of-interrupt mask data exchange on the bus from the current descriptor and the period of the exchange cycle. When creating a descriptor table, it is necessary that there is enough space in the local memory for a data packet of maximum length.

In the “Slave” mode, the table of address space description is located in local memory, and the address space is a memory area for storing useful data.

* Spare - a sign of reserved bits, the developer can set the logical value independently.

* ADP - a sign of adaptive reading of useful information. Takes one bit of a word. Changing the value of this bit is possible in the message type reading data from the slave device. The value of this bit changes the slave device in the sent information packet, if the address space actually contains fewer words of useful data than the master requested.

Block 28 provides basic input and output functionality for bus 5. The input and output functionality of unit 28 does not change depending on the mode of the SF block. Block 28 contains receivers 33 and 34, transmitter 35, shadow FIFO buffers 36 and 37, a bus error detector (handler) 38, a multiplexer 39 of FIFO buffers and a bus health monitoring unit 40. The data received from the bus 5 and / or tires 5 and 16, go to the receivers 33 and 34, and then to the FIFO buffers 36 and 37. The FiFO buffer size is 256 words. After the end of data reception, the bus error detector 38 analyzes the errors and then uses data from that FIFO buffer, which did not have any errors in the reception process. It is possible to diagnose the following errors: CRC errors, Parity bit errors, Manchester code errors and errors in the data transfer process caused by the failure of tire drivers. The bus health monitoring unit performs its function by comparing the transmitted and received data.

The OSD 23 processes the rows from the descriptor table. It contains a DMA controller 24 for exchanging data between local and system memory. Controls the operation of the DMA controller 24 and the operation of the bus controller 27. The DSD 23 is designed to work with both “adhering to the bus cycle” (the time interval for which one pass should occur throughout the descriptor table) and “without the absence of tracking for the bus cycle”. When "respecting the bus cycle", if the passage through the entire descriptor table is carried out before the end of the bus cycle, the SF-block goes into standby mode with an interrupt request. In the case when the processing time of the descriptors has exceeded the bus cycle time, the SF block requests an interrupt, while the DSD continues to work, and the countdown of the new bus cycle begins as soon as the processing of the first descriptor begins. “Without no tracking of the bus cycle”, the OSD proceeds to processing the first descriptor immediately after processing the last one. The switching on and off of the DSD occurs only after the end of the processing of the current transaction.

The bus controller 27 implements the logic of the Master, Slave or Monitor modes. The bus controller 27 transfers data between block 28 and local memory 26, forms control packets, updates statistics registers.

The work of the SF-block in the “Master” mode: the system software generates a table of descriptors in the local memory and configures the SF-block. By launching the OSD 23, in order, it reads and processes the descriptors from the local memory. According to the “control information” from the OSD descriptor 23, the corresponding commands are sent to the DMA controller 24. In parallel, the bus controller 27 waits for signals from the OSD 23 to “write” or “read” the data to the slave device. Upon receipt of such a command from OSD 23, the bus controller 27 performs a sequence of actions corresponding to the type of request. In the case of “writing” data to the slave device, the following actions are performed: using the DMA controller, the data received via the AXI system bus is loaded into the local memory. The bus controller 27 reads the data from the local memory and transmits it to the bus. Upon completion of the data transfer, the bus controller 27 informs the DSD 23 of this and goes into standby mode of a new command. After the processing of the “control information” descriptor is completed, the DOS 23 updates the “transaction result” descriptor in the local memory and proceeds to process the next descriptor. Thus, the following data flow can be traced: system bus - DMA - local memory - bus controller.

In the case of “reading” the data from the slave, the following actions are performed: the bus controller 27 reads the data from the bus and transfers them to the local memory, from where the data is transferred to the AXI system bus using the DMA controller 24. Upon completion of the transfer of data from the local memory, the bus controller 27 informs the DSD 23 of this and goes into standby mode of a new command.

After the processing of the “control information” descriptor is completed, the DOS 23 updates the “transaction result” descriptor in the local memory and proceeds to process the next descriptor. Thus, the following data flow can be traced: bus - bus controller - local memory - DMA - system bus.

Thus, at the beginning of work, the system software initializes the SF-block once, then the SF-block, without the intervention of the system software, performs each cycle of data exchange over the bus, transferring the data to the system memory. Thus, it is possible to automate the work of the SF-block and, thereby, unload (release) the resources of the central SoC processor for other work.

After the end of processing the descriptor table, an interruption can be formed, after which it is possible to update the descriptor table data with the system software.

Work of the SF block in the Slave mode: The SF block in the Slave mode implements the logic of access to its address spaces via bus queries. The address space is a memory area located in local memory and containing useful data. Each address space is described in the address space description table. The system software at the start of work once initializes the SF block, after which the data transfer or receive transactions are carried out automatically without the involvement of the system software. Access to local memory is possible only via the ARV bus. In slave mode, the DSD is not active and data exchange via the DMA controller is not available. Upon launch, the bus controller 27 waits for receiving a control / information packet from block 28, after which it processes the packet and contacts the local memory at the page address equal to the data address space number from the control packet. At this address in the local memory is the description of the requested address space. One of its fields "Memory address" is the address of the first data word in the local memory, corresponding to this address space. If the request was for recording, then incoming data is recorded at this address. If the request was read, then data is read from this address. After the processing of the control / information packet is completed, an interruption may be triggered, according to which the system software updates data.

The work of the SF-block in the “Monitor” mode: The SF-block in the “Monitor” mode performs the function of collecting and writing to the system memory of all traffic going on the bus. The control and data packets are recorded. Each packet coming from the bus is supplemented with a special descriptor that goes before the data and is written to the system memory. In this case, only informational words are recorded, the words CRC are discarded. Only those packets are written to the memory, with the reception of which no errors occurred. If errors occur in the process of receiving the received packet is discarded, and the corresponding flag will be set. Working in the Monitor mode is similar to working in the Master mode using extraordinary descriptors. In the “Monitor” mode, the OSD 23 has the same functionality as in the “Master” mode.

In the SF block, the possibility of changing the length of a CRC (CRC polynomial length register), initial CRC value (initial CRC value register) and CRC polynomial (polynom CRC value register) is implemented in the mode described in the TSI protocol application.

All information on the bus is transmitted in the code "Manchester-2". This bipolar phase-manipulated code has a zero DC component, which is very important in high-speed transmission applications. Coding 0 and 1 is performed not by the level, but by the signal front in the middle of the clock interval (Fig. 4), which allows for bit-wise synchronization of the transmitter and receiver over the transmitted information in a wide range of deviations of the carrier frequency. Two types of sync signal (FIG. 5) are defined, which allow the hardware, therefore, quickly, to determine and distinguish the beginning of the data packet from the control packet.

A data packet (DATA) (FIG. 6) has a format of one or more 32 bit data words, which completes the 32 bit control word. In front of them is a clock signal (3 bits), the polarity of the first half of which is negative, and the second half is positive. Data words (useful information) - the actual data exchanged between subscribers and for the transmission of which a data packet is used. The CRC-32 checksum word is intended to verify the integrity of all data transmitted in a packet. The CRC-32 calculation is used.

The check package (Fig. 7) has a format of 32 bit information word and 32 bit word of checksum. Before them is a clock signal (3 bits), the polarity of the first half of which is positive, and the second half is negative. The control package can perform the function of the beginning and end of the communication session, the confirmation of the receipt of the information packet, the request for the information packet. Control data is the data needed by the subscriber to determine whether they have completed tasks and indicate their status.

A packet (Fig. 8), including a control packet and a data packet, is called an information packet (CTRL + DATA).

The protocol supports two types of address spaces on the slaves:

- main space (target information exchange);

- configuration space (slave control).

Up to 255 electronic devices are addressed by bus (and one address for broadcast exchanges). Each device addresses up to 256 address spaces, the size of which is from 1 to 256 words in the main address space and 1 word in the configuration space. The size of one word is 32 bits.

Consider the possible message formats that are exchanged between the master (Master) and slave (Slave) devices by sending each other control and information packets:

- Format 1 "write data to the slave device" (Fig. 9).

- Format 2 "broadcast message" (Fig. 10).

- Format 3 "reading data from a slave device" (Fig. 11).

- Format 4 "impossibility of the slave device to issue the requested data when reading data from the slave device" (Fig. 12).

Consider the main messages (Fig. 9-12) between the master and the slave electronic devices.

Format 1 is designed to transfer data from the master to the slave - “writing data to the slave (Slave)” (Fig. 9). The master device transmits the information packet (CTRL + DATA). The slave receives an information packet, calculates the checksums (CRC-32) of the 32-bit overhead and 32-bit word (s) of the data (payload) and compares their values with the checksum values received from the master. Depending on the result of the comparison of checksums, the slave either ignores the write request or accepts execution. In any case, the slave device sends a response control packet (CTRL) to the master device, in which the bits [2: 0] of the "control word" (table 4) have values corresponding to the "status tags" of the transaction.

Format 2 is designed to transmit data from the master device to all slaves - the “broadcast message” (Fig. 10). The master device transmits the information packet (CTRL + DATA) (in the "Terminal address" field 0xFF is the broadcast address), and the slave devices receive the information packet, calculate the checksums (CRC-32) of the 32-bit service information and 32-bit word ( words) data (useful information) and compare their values with the values of the checksums received from the master device. Depending on the comparison result of the checksum, the slaves either ignore the write request or accept it. In this message format, the master device does not expect a “response packet” from the slave devices after transmitting the information packet.

Format 3 is intended for receiving data of a slave device by a master device - “reading data from a slave device (Slave)” (Fig. 11). The master sends the control packet (CTRL) to the slave and releases the bus. The addressed slave device accepts the control packet, calculates the 32-bit overhead CRC-32 checksum and compares its value with the checksum value received from the master. Depending on the result of the comparison of checksums, the slave either ignores the read request or accepts execution. Upon successful comparison, the slave device seizes the bus and sends a response information packet (CTRL + DATA) to the master device. The master device receives a reply information packet from the slave and calculates the CRC-32 checksums of 32-bit overhead information and the word (s) of the data (payload) and compares their values with the checksum values received from the slave. If the checksums are successfully compared, the information packet is considered to be received - data reading from the slave device is completed.

Format 4 "it is impossible to issue the requested data" (Fig. 12) is a special case of format 3, in which "reading data from a slave device (Slave)" occurs. The master sends the control packet (CTRL) to the slave. The slave receives the control packet, calculates its checksum and compares its value with the checksum value received from the master. If the checksums do not match, the slave device ignores the read request and sends a response control packet (CTRL) to the master device, in which the bits [2: 0] of the "control word" (table 3) have values corresponding to the status indicators of the transaction.

Claims (1)

Interface complex-functional unit for VLSI type system-on-chip, made with the possibility of its operation in the master electronic device mode or in the slave electronic device mode in the electronic device system, in which serial data is exchanged over the bus between the master electronic device and at least two slave electronic devices, characterized in that it contains a local memory in which the descriptor table and a data storage area, a DMA controller, are located, rednaznachenny for exchanging data between the system memory and VLSI local memory unit, a bus controller, for exchanging data between the local memory unit and the tire, the handler descriptor list for controlling the operation of DMA-controller and the bus controller in accordance with the descriptors in local memory.

Images