Shared storage device and automotive device including same

Abstract

The embodiment of the invention provides shared storage equipment and automobile equipment comprising the same. An automotive device includes an electronic control unit, a shared storage device, and a system memory device. An electronic control unit sends a code request. The shared storage device includes a non-volatile memory device that stores code segments that form an entire code corresponding to a code request, and a storage controller that stores the code segments based on characteristic information of each code segment. One or more of the stored code segments are loaded from the non-volatile memory device into the buffer memory. The system memory device receives the one or more code segments from the buffer memory and stores the one or more code segments, and outputs the one or more code segments to the electronic control unit. The electronic control unit receives one or more code segments from the system memory device, and overlays the one or more code segments to the executable code set, and executes a function based on the executable code set.

Description

Technical Field

[0001] The present disclosure relates to a shared storage device mounted on an automobile device. Background Art

[0002] With the rapid development of semiconductor devices, autonomous driving vehicle technology using semiconductor devices is constantly developing.

[0003] Autonomous vehicles are evolving from a centralized architecture consisting of a single electronic control unit (ECU) to a zone-based architecture consisting of a central ECU and multiple regional ECUs. In a zone-based architecture, the regional ECUs control nodes to form network zones within the vehicle, while the central ECU controls the regional ECUs. Summary of the Invention

[0004] One aspect provides a shared storage device that can quickly and efficiently load code data to a corresponding electronic control unit (ECU) via a system memory during runtime.

[0005] Another aspect provides an automotive device including a shared memory device, thereby improving operational performance using limited resources.

[0006] According to one aspect of one or more embodiments, an automotive device is provided, comprising: an electronic control unit (ECU) configured to send a code request; a shared storage device including a nonvolatile memory device and a storage controller, the nonvolatile memory device configured to store a plurality of code segments forming an entire code corresponding to the code request, and the storage controller configured to load at least one of the plurality of code segments from the nonvolatile memory device into a buffer memory based on characteristic information of each of the plurality of code segments; and a system memory device configured to receive and store at least one code segment from the buffer memory, and output the at least one code segment to the ECU that sent the code request. The ECU receives the at least one code segment from the system memory device, overwrites the at least one code segment into an executable code set, and executes a function based on the executable code set.

[0007] According to another aspect of one or more embodiments, a shared storage device is provided, comprising: a nonvolatile storage device configured to store a plurality of code segments forming an entire code; and a storage controller including a segment table and a buffer memory, the segment table configured to store characteristic information of each of the plurality of code segments. The storage controller receives a code request from a host, reads at least one code segment from the nonvolatile storage device based on the characteristic information corresponding to the code request, and transmits the read at least one code segment to the host via a system memory device.

[0008] According to another aspect of one or more embodiments, an automotive device is provided, comprising: an electronic control unit (ECU) configured to execute a function based on an executable code set including a main code and an overlay area; a shared storage device including a non-volatile memory device and a storage controller, the non-volatile memory device storing a plurality of code segments forming at least one code, and the storage controller accessing the non-volatile memory device and reading the code segments based on characteristic information corresponding to a code request received from the ECU; and a system memory device configured to receive the code segments read from the storage controller and transmit the code segments to the ECU that transmitted the code request. The automotive device updates the executable code set by overwriting the code segments received from the system memory device to the overlay area. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The above and other aspects will become more apparent by describing in detail exemplary embodiments thereof with reference to the accompanying drawings, in which:

[0010] Figure 1 is a conceptual diagram for explaining an automotive device according to some embodiments;

[0011] Figure 2 is a block diagram of an automotive device according to some embodiments;

[0012] Figure 3 is a conceptual diagram for explaining an ECU based on a central / regional architecture according to some embodiments;

[0013] Figure 4 is used to explain the Figure 3 A conceptual diagram of the operation of a central ECU based on a central / regional architecture;

[0014] Figure 5 According to some embodiments Figure 2 A block diagram of a non-volatile memory controller for an automotive device;

[0015] Figure 6 According to some embodiments Figure 2 Block diagram of regional ECU of automotive equipment;

[0016] Figure 7 According to some embodiments Figure 2 A block diagram of an input / output memory management unit (IOMMU) of an automotive device;

[0017] Figure 8 and Figure 9 is a flow chart illustrating the operation of an automotive device according to some embodiments;

[0018] Figure 10 is a block diagram for explaining the operation of an automotive device according to some embodiments;

[0019] Figure 11 shows a segment table according to some embodiments;

[0020] Figure 12 is a schematic diagram for explaining access frequencies of code segments according to some embodiments;

[0021] Figure 13 is a schematic diagram for explaining address inheritance of code segments according to some embodiments;

[0022] Figure 14 is a flow chart illustrating the operation of an automotive device according to some embodiments;

[0023] Figure 15 is a conceptual diagram illustrating the operation of an automotive device according to some embodiments;

[0024] Figure 16 is a flow chart illustrating the operation of an automotive device according to some embodiments;

[0025] Figure 17 is a conceptual diagram illustrating the operation of an automotive device according to some embodiments;

[0026] Figure 18 is a conceptual diagram explaining the operation of an automobile device according to some embodiments;

[0027] Figure 19 is a flow chart illustrating the operation of an automotive device according to some embodiments;

[0028] Figure 20 is a flow chart illustrating the operation of an automotive device according to some embodiments. DETAILED DESCRIPTION

[0029] In related-art vehicle architectures, each ECU includes a separate nonvolatile memory device. However, as ECUs in autonomous vehicles have evolved into centralized and regional architectures, both central and regional ECUs now operate using shared nonvolatile memory devices. Discussions are currently underway regarding the connection and operation methods between these centralized and regional ECUs and shared nonvolatile memory (or storage) devices.

[0030] For example, in a zone-based architecture, each zone ECU can add or modify functionality through firmware updates. To optimize and optimize the memory of each zone ECU, code data can be read from a shared non-volatile memory device and executed into each zone ECU. Since code data reading and execution must occur during the runtime of each zone ECU, the code loading time from the non-volatile memory device has a significant impact on the performance of the autonomous vehicle.

[0031] The present disclosure relates to software stored on one or more of a plurality of computer-readable media that controls an automotive device 1 to drive one or more devices implementing various embodiments and enables the automotive device 1 to interact with a human user (e.g., a driver). The software includes, but is not limited to, device drivers, operating systems, development tools, and / or application software. The computer-readable medium includes a computer program product that performs all or some of the processing performed in implementing various embodiments (when the processing is distributed). The computer code device of the present disclosure can be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), Java classes, and complete executable programs. In addition, for better performance, reliability, and / or cost, some processing can be distributed.

[0032] As used in this specification, the phrase "at least one of A, B, or C" includes within its scope "only A," "only B," "only C," "A and B," "B and C," "A and C," and "A, B, and C."

[0033] Figure 1 is a conceptual diagram for explaining an automotive device according to some embodiments. Figure 2 is a block diagram of an automotive device according to some embodiments.

[0034] refer to Figure 1 and Figure 2 The automotive device 1 includes a central architecture and a regional architecture. In some embodiments, the automotive device 1 includes central electronic control units (ECUs) 10-1 and 10-2 (ECU0) and regional ECUs 20-1 to 20-6 (ECU1).

[0035] Central ECUs 10-1 and 10-2 can perform overall control to ensure that each component in automobile device 1 operates normally. Regional ECUs 20-1 to 20-6 can perform different tasks, for example, to control a designated area assigned to the regional ECU or communicate with other non-designated areas, independent nodes, or servers.

[0036] For example, regional ECU 20-1 can control nodes in the right front door area, while regional ECU 20-2 can control nodes in the left front door area. For example, the nodes in each area may include controllers such as lidar sensors, distance sensors, image sensors, actuators, and motor control units (MCUs). Central ECU 10-1 sends master control signals to regional ECUs 20-1 and 20-2 based on status signals received from these regional ECUs. Regional ECUs 20-1 and 20-2 can generate separate control signals based on the master control signal from central ECU 10-1 to drive the controllers.

[0037] Figure 3 is a conceptual diagram for explaining an ECU based on a central / regional architecture according to some embodiments. Figure 4 is used to explain the Figure 3 Conceptual diagram of the operation of a central ECU based on a central / regional architecture. Figure 5 According to some embodiments Figure 2 Block diagram of a nonvolatile memory controller for automotive equipment. Figure 6 According to some embodiments Figure 2 A block diagram of the first ECU of an automotive device. Figure 7 According to some embodiments Figure 2 Block diagram of an input / output memory management unit (IOMMU) of an automotive device.

[0038] refer to Figures 2 to 7 The automobile device 1 may include a central ECU (ECU0) 10 and first ECUs (ECU1) 20-1 to 20-6 (hereinafter referred to as regional ECUs 20) connected to a system bus 50, a plurality of nodes (e.g., a sensor 31, an actuator 35, and a microcontroller unit (MCU) 37) connected to the regional ECUs 20, an input / output memory management unit (IOMMU) 40, a system memory device 200, and a shared storage device 100.

[0039] The central ECU (ECU0) 10 generally controls the regional ECUs (ECU1) 20 and other components of the vehicle device 1. In some embodiments, the central ECU 10 may also be referred to as a central control unit, central ECU, autonomous driving stack, or autonomous driving computer. For example, the central ECU 10 may process data collected by nodes connected to the regional ECUs 20 (e.g., sensors 31, actuators 35, and MCU 37), perform driving control in conjunction with the regional ECUs 20, and communicate with external systems to handle real-time traffic information, cloud services, updates, and the like. In some embodiments, the central ECU 10 may manage the vehicle device 1's safety system, manage software updates, and / or perform self-diagnostic functions.

[0040] Regional ECUs (ECU 1) 20 typically control nodes categorized by function, location, and the like. Regional ECUs 20 may also be referred to as regional control units, regional ECUs, or regional control units, but embodiments are not limited thereto. Regional ECUs 20 detect the environment surrounding automotive equipment 1 and control the operation of automotive equipment 1 via various sensors 31, actuators 35, and / or microcontroller units (MCUs) 37. Regional ECUs 20 transmit their status and regional control information to central ECU 10 and may receive central control signals from central ECU 10.

[0041] In some embodiments, the regional ECU (ECU 1) 20 may include a sensor ECU, a control ECU, a communication ECU, a safety ECU, a power control ECU, a power ECU, and the like. For example, the sensor ECU may be electrically connected to multiple sensors in a region, receive sensed values from the sensors to extract environmental information, and transmit the extracted environmental information to the central ECU 10. For example, the power ECU may be electrically connected to multiple power elements in a region, monitor the status of the power elements, notify the central ECU 10 of the monitoring results, and, based on the monitored status of the corresponding power element, independently or under the control of the central ECU 10, perform regional power control operations on at least one power element.

[0042] In some embodiments, as Figure 3 As shown, the regional ECU 20 may include regional ECUs for different areas, namely, a regional ECU 21 (ECU11) for the left rear area, a regional ECU 22 (ECU12) for the left front area, a regional ECU 23 (ECU13) for the right rear area, and a regional ECU 24 (ECU14) for the right front area. The regional ECUs 21, 22, 23, and 24 may respectively include a plurality of electrically connected MCU groups 37a, 37b, 37c, and 37d. Each of the MCU groups 37a, 37b, 37c, and 37d may include a plurality of MCUs, and each of the MCUs controls the regional control elements connected thereto. For example, the regional ECU 21 may receive status information of the control elements in the left rear area and operation control information of the MCU group 37a, and may control the operation of the MCU group 37a independently or under the control of the central ECU 10. Although Figure 3 Each of the MCU groups 37a, 37b, 37c and 37d shown in the figure includes three MCUs, but this configuration is merely an example, and in some embodiments, the MCU groups may have different numbers of ECUs, and in some embodiments, the number of MCUs may be greater or less than three.

[0043] refer to Figure 2 and Figure 4 The central ECU (ECU0) 10 executes instruction codes for performing various functions. In some embodiments, the instruction code as the main signal of the central ECU 10 may be associated with the function executed by each regional ECU 20. For example, assume that the code data for executing a first function is Function1, and the code data for executing a second function is Function2, and the first and second functions are executed by regional ECUs 21 and 22, respectively.

[0044] The automotive device 1 uses a single piece of code data to execute at least one function in a central ECU 10 or a regional ECU 20. For example, the code data executed in each central ECU 10 or each regional ECU 20 (which is the entire code for executing the function) can be divided into smaller code segments. For example, the code data for executing a first function can include multiple first code segments. The first code segment is a functional segment, and its block size can vary.

[0045] The code data Function1 is code data of a first function and may include three code segments Z11 , Z12 , and Z13 , while the code data Function2 is code data of a second function and may include two code segments Z21 and Z22 .

[0046] The central ECU 10 and / or the regional ECUs 20 can perform software updates to ensure stable operation and enhance the performance of the automotive device 1. Software updates to the ECU 10 and / or the regional ECUs 20 can be used to improve algorithms, fix bugs, and / or add new features. These software updates can be performed via over-the-air (OTA) updates or via a wired or wireless network from an official service center. The code data for the updated software is stored in the shared storage device 100 via the OTA update or via a wired or wireless network. The central ECU 10 and / or the regional ECU 20 can then send a code update request to the shared storage device 100 during a system restart or during operation of the automotive device 1. The shared storage device 100 reads the code data corresponding to the code update request and loads the read code data into the system memory 210. The system memory 210 stores the code segments of the loaded code data and transmits the code segments to the central ECU 10 and / or the regional ECU 20. Each entity (e.g., the central ECU 10 or the regional ECU 20) that sends a code request to the shared storage device 100 can be referred to as a host device.

[0047] refer to Figure 2 and Figure 6According to some embodiments, the regional ECU (ECU1) 20 may include a regional processor 24, a regional memory 25, and device input / output interfaces 26a, 26b, and 26c (I / O1, I / O2, and I / O3). The regional processor 24 uses data from the regional memory 25 to perform specific functions. For example, the regional processor 24 can perform corresponding functions by executing a code set transferred from the system memory 210 and stored in the regional memory 25.

[0048] The device input / output interfaces 26 a , 26 b , and 26 c may be connected to corresponding device groups (eg, sensors 31 a to 31 c and actuators 35 a to 35 c ).

[0049] The system memory device 200 may include a system memory 210 and a system memory controller 201. The system memory 210 may be accessed through the system memory controller 201. The system memory controller 201 may be connected to the system bus 50 and may control access to the system memory 210 from other components of the automobile device 1. The system memory controller 201 may manage operations of storing data (e.g., writing data) from the system memory 210 in the non-volatile memory device 400 or storing data (e.g., reading data) from the non-volatile memory device 400 in the system memory 210. For example, the system memory controller 201 may control operations of storing intermediate data generated during the operation of each central ECU 10 and / or each regional ECU 20 in the system memory 210 or reading intermediate data required for the operation of each central ECU 10 and / or each regional ECU 20 from the system memory 210.

[0050] The system memory 210 can be used as a buffer memory for temporarily storing data received from the shared storage device 100 or to be transmitted to the shared storage device 100. In some embodiments, the system memory 210 may include a volatile memory such as a random access memory (RAM) or another dynamic storage device (e.g., dynamic RAM (DRAM), static RAM (SRAM), or synchronous DRAM (SDRAM)). In some embodiments, the system memory 210 may include a non-volatile memory. The non-volatile memory may be, for example, a read-only memory (ROM) or another static storage device (e.g., programmable ROM (PROM), erasable PROM (EPROM), or electrically erasable PROM (EEPROM)).

[0051] In some embodiments, the system memory controller 201 and the system memory 210 may be implemented as separate semiconductor chips. In some embodiments, the system memory controller 201 and the system memory 210 may be integrated into the same semiconductor chip.

[0052] In some embodiments, the system bus 50 may be, for example, a Peripheral Component Interconnect (PCI) or PCI-Express (PCIe) bus, or a Non-Volatile Memory Express (NVMe) over Fabric (NVMe-oF) bus with network capabilities. In some embodiments, the system bus 50 may communicate via communication links other than PCIe, including but not limited to Compute Express Link (CXL), Serial Attached SCSI (SAS), Serial ATA (SATA), and / or Cache Coherent Interconnect for Accelerators (CCIX). In some embodiments, as Figure 7 As shown, the system bus 50 may include an interface for connecting components of the automotive device 1 to a network structure, and thus may be referred to as a root complex interface. The root complex interface 50' may include one or more root ports that may be used to connect the shared storage device 100 to the system memory device 200. In other words, the shared storage device 100 may be connected to the system memory device 200 via the root complex interface 50'.

[0053] The shared memory device 100 may include a memory controller 300 and a plurality of nonvolatile memory devices 400. The nonvolatile memory devices 400 may be controlled by the memory controller 300.

[0054] The shared storage device 100 may include a plurality of non-volatile memory devices 400 for storing data according to requests from each central ECU 10 and / or each regional ECU 20. For example, each of the non-volatile memory devices 400 may include at least one of a solid-state drive (SSD), an embedded memory, or a removable external memory. If the non-volatile memory device 400 is an SSD, the shared storage device 100 may be a device that complies with the NVMe standard.

[0055] If the non-volatile memory device 400 is an embedded memory or an external memory, the shared storage device 100 may be a device that complies with the Universal Flash Storage (UFS) standard or the embedded MultiMediaCard (eMMC) standard. Each central ECU 10 and / or regional ECU 20 and the shared storage device 100 may generate and transmit data packets according to the adopted standard protocol.

[0056] In some embodiments, reference Figure 2 and Figure 5 , the memory controller 300 may include a segment analyzer 310 , a segment controller 320 , a segment table 330 , an address translation and control (ATC) request manager 340 , and a buffer memory 350 .

[0057] The segment analyzer 310 analyzes the logical block address (LBA) associated with the namespace ID (NID) or virtual function ID (VFID) within each nonvolatile memory device 400 to determine whether the LBA or VFID corresponds to a normal area storing general user data or a code area storing code. Figure 4 When at least one code segment in the code data Function1 is requested, the memory controller 300 reads the requested code segment (eg, Figure 4 When reading the requested code segment from the non-volatile memory device 400, the storage controller 300 may use an overlay method at runtime, taking into account the size of the code data or memory optimization. For example, each central ECU 10 and / or regional ECU 20 may create an executable code set by loading the code segment Z13 output from the corresponding non-volatile memory device 400 into the system memory 210, and then execute the first function, in which the main code and the requested code segment (e.g., code segment Z13) are overwritten. In order to efficiently load the code segment, the storage controller 300 may determine whether a specific area storing the code segment in each non-volatile memory device 400 is a code area.

[0058] Specifically, the segment analyzer 310 scans a specific area in each non-volatile memory device 400 that is continuously written and then read only, and considers the specific area as a candidate code area where multiple code segments are located. The shared storage device 100 stores a complete code executed to perform a function in units of multiple code segments. The function can be predetermined. Multiple code segments are continuously written to an area within each non-volatile memory device 400. The area can be predetermined. Then, when the multiple code segments are loaded into the system memory device 200, the shared storage device 100 only performs periodic read operations on the area storing the multiple code segments.

[0059] The segment analyzer 310 determines the region storing the code segment as a code region based on the read access frequency of the region, based on the location and read access frequency of the region, based on whether data update has been performed, etc. The segment analyzer 310 monitors the characteristic information of the code segment stored in the code region, and stores the address information indicating the storage location of the code segment as characteristic information in the segment table 330. In some embodiments, for each code segment, the characteristic information may include requester information associated with the main code, address information, code segment size information, read access frequency information, hit rate, etc. For example, the characteristic information may be as follows: Figure 11 The records shown are in segment table 330, which is described in more detail below.

[0060] When the physical address corresponding to the logical address of a specific code segment recorded in the segment table 330 in the address translation cache (ATC) 500 does not exist, the ATC request manager 340 sends an address translation request to the IOMMU 40. The IOMMU 40 responds to the address translation request and allocates a new physical address to be mapped to the logical address included in the address translation request. The ATC request manager 340 then stores the allocated physical address in the address translation cache 500 and the segment table 330.

[0061] The buffer memory 350 stores data used for the operation of the memory controller 300. For example, the buffer memory 350 may temporarily store code data for software update before transferring the code data to the nonvolatile memory device 400, or may load data stored in the nonvolatile memory device 400 into the buffer memory 350 and then transfer the loaded data to the system memory 210.

[0062] Although not shown, in some embodiments, the storage controller 300 may further include a host interface and / or a memory interface. In some embodiments, the storage controller 300 may include an error correction code (ECC) engine and / or an advanced encryption standard (AES) engine. The host interface may serve as an interface for each central ECU 10 and / or each regional ECU 20, and the memory interface may serve as an interface for each non-volatile memory device 400.

[0063] The shared storage device 100 may also include an address translation cache (ATC) 500. Commands sent from each central ECU 10 and / or each regional ECU 20 include a logical address and may be commands to read, write, or erase data at a physical address corresponding to the logical address in the system memory 210. The address translation cache 500 stores mapping information between logical addresses and physical addresses. If there is no physical address corresponding to the logical address included in the command in the address translation cache 500, the storage controller 300 may send an address translation request to the IOMMU 40 before accessing the system memory 210 through direct memory access (DMA).

[0064] refer to Figure 2 and Figure 7 The IOMMU 40 performs memory address translation, memory protection, and virtual memory / cache management during access to data in the system memory device 200. Specifically, the IOMMU 40 may include a translation agent (TA) 41 and an address translation and protection table (ATPT) 42.

[0065] The translation agent (TA) 41 may include hardware, firmware, and / or software that translates addresses into physical addresses for PCIe or NVMe transactions. In an embodiment, the storage controller 300 may send an address translation service (ATS) request to the TA 41 via the root complex interface 50'. The TA 41 responds to the ATS request by referencing the ATPT 42 and sends back an ATS response via the root complex interface 50'.

[0066] The Address Translation and Protection Table (ATPT) 42 stores address translation information processed by the TA 41 for processing PCIe and / or NVMe requests to the ATS, such as DMA read or write operations.

[0067] In some embodiments, the IOMMU 40 can manage the logical address mapping from each central ECU 10 and / or each regional ECU 20 to the physical memory pages in the system memory 210 to provide a larger logical address space by expanding the physical space of the system memory 210. Each non-volatile memory device 400 includes areas for different types of memory cells, such as a single-level cell (SLC) area, a multi-level cell (MLC) area, and / or a default area for triple-level cells (TLC) or higher-level cells. Each SLC stores one bit, while each MLC, TLC, or quad-level cell (QLC) stores two or more bits. The memory controller 300 has a faster access speed to the SLC area than to the MLC area, and the access speed to the MLC area is faster than the access speed to the default area. The access speed to the buffer memory 350 within the memory controller 300 can be faster than the access speed to the SLC area.

[0068] The memory controller 300, and in particular the segment controller 320, can migrate and store code segments in one of the buffer memory 350, the SLC area, the MLC area, or the default area based on the access frequency of the code segments recorded in the segment table 330. Specifically, based on the access frequency of the code segments recorded in the segment table 330, the segment controller 320 can migrate the storage location of the code segments in each non-volatile memory device 400 to improve the loading speed of the code segments. In some embodiments, the most frequently and recently accessed code segments are stored in the buffer memory 350, and the storage locations of the code segments are migrated and stored in the SLC area, the MLC area, and the default area (for TLC or higher-level cells) in descending order of access frequency, and their previous physical addresses ("rollback addresses (PBAs)") and new physical addresses ("segment addresses (PBAs)") are recorded together in the segment table 330.

[0069] The logical address included in the command sent by each central ECU 10 and / or each regional ECU 20 can be converted into a physical address by the TA 41. By mapping the physical address to the logical address, the physical address can be stored in the address translation cache (ATC) 500 for use in, for example, DMA read or write operations. The memory controller 300 of the shared memory device 100 can check the address translation cache 500 to determine whether a physical address corresponding to the logical address included in the read / write command exists in the system memory 210. If a physical address corresponding to the logical address included in the read / write command exists in the address translation cache 500, the memory controller 300 can use the corresponding physical address to access the system memory 210.

[0070] The logical address that has been converted into a physical address can be stored in the address translation cache (ATC) 500. In order to access the system memory 210 in response to a read or write request from each central ECU 10 and / or each regional ECU 20, the memory controller 300 can check the address translation cache 500 to determine whether there is a logical address corresponding to the specific physical address. If the logical address corresponding to the specific physical address exists in the address translation cache 500, the memory controller 300 uses the corresponding logical address for the read operation without sending a separate address translation request to the IOMMU 40. If there is no corresponding logical address, an address translation request is sent to the TA 41. In response to the address translation request, the TA 41 allocates a new logical address that can be mapped to the specific physical address. The memory controller 300 stores the allocated logical address in the address translation cache 500.

[0071] Figure 8 and Figure 9 is a flow chart illustrating the operation of an automotive device according to some embodiments.

[0072] refer to Figure 8 , the vehicle system starts (S10). For example, the vehicle system of the vehicle device 1 can be started. In response to the system startup of the vehicle device 1, code for executing a specific function can be loaded from the shared storage device 100 (S11). For example, the central ECU 10 or the regional ECU 20 can load the main code and / or some code segments associated with the first function from the shared storage device 100. Operations related to the first function can be executed based on the loaded code (S12). For example, operations related to the first function can be executed based on the loaded main code.

[0073] While executing the first function, the regional ECU 20 monitors whether the additional code segment is loaded (S13). For example, the regional ECU 20 may determine whether the additional code segment is loaded. If it is determined that the additional code segment is not loaded (S13, No), the regional ECU 20 continues to execute operations based on the loaded code segment (S18).

[0074] On the contrary, if it is determined to load the additional code segment (operation S13, YES), a code request for the additional code segment is sent to the shared storage device 100. For example, the central ECU 10 or the regional ECU 20 may send a code request for the additional code segment to the shared storage device 100 (S14).

[0075] In response to receiving the code request, the shared storage device 100 verifies the request information. For example, the code request may include request information such as requester information regarding the regional ECU 20 that sent the code request, master code information, address information of the requested code segment corresponding to the code request, and / or size information of the requested code segment. Based on the request information, the storage controller 300 identifies characteristic information of the requested additional code segment via the segment analyzer 310 and stores the characteristic information in the segment table 330. For example, the characteristic information may include at least one of the requester information, master code information, the logical / physical address of the requested code segment, the access frequency of the requested code segment to the non-volatile memory device 400, or the size of the requested code segment.

[0076] The requested additional code segment may be transferred to the system memory device 200 (S15). For example, the shared storage device 100 may transfer the requested additional code segment to the system memory device 200. The additional code segment may be stored and transferred (S16). For example, the system memory device 200 may store the additional code segment and transfer the additional code segment received from the shared storage device 100 to the regional ECU 20. The regional ECU 20 may load the received additional code segment into an overlay area (S17). The overlay area may correspond to the code requesting the additional code. In some embodiments, the code requesting the additional code may be the main code. For example, the regional ECU 20 may load the received additional code segment into an overlay area or zone corresponding to the code loaded in operation S11. An operation based on the loaded additional code segment may be performed (S18).

[0077] The automobile device 1 can be periodically or irregularly updated with firmware through external control (e.g., via OTA update or via a network). When a firmware update occurs, the automobile device 1 may need to perform a comprehensive code update on both the central ECU 10 and the regional ECUs 20, or only perform a code update on at least one of the regional ECUs 20 used for a specific function. In some embodiments, a comprehensive code update can be requested by the central ECU 10, and a code segment can be loaded into both the central ECU 10 and the regional ECUs 20. Alternatively, a comprehensive update can be requested by the regional ECU 20, and a code segment can be loaded into each regional ECU 20. Figure 9 How to perform code update on one of the zone ECUs 20 by external control during firmware update is described.

[0078] refer to Figure 9 , a firmware update can be received (S20). For example, the OTA master device can initiate a firmware update of the regional ECU 20. The updated firmware data can be received and stored in the shared storage device 100 (S21). For example, the automotive device 1 can receive updated firmware data via OTA update, and store the updated firmware data in the shared storage device 100 via OTA update. Once the updated firmware data is received, the automotive system can be restarted (S22). For example, the automotive device 1 can be restarted. The main code can be loaded from the shared storage device 100 (S23). For example, the regional ECU 20 loads the main code stored in the shared storage device 100 (i.e., the updated main code). In some embodiments, the regional ECU 20 can further load some code segments together with the main code.

[0079] Steps S24 to S30 are similar to Figure 8 The regional ECU 20 may perform operations associated with the loaded main code based on the loaded main code (S24). During operation, the regional ECU 20 may determine whether to load a code segment (S25). The code segment may be a newly added code segment as part of a firmware update, or may be a replacement for an existing code segment. If it is determined not to load a code segment (operation S25, No), the regional ECU 20 continues to perform operations based on the loaded main code and / or code segment (S30).

[0080] On the other hand, if it is determined that the code segment is to be loaded (operation S25, yes), the regional ECU 20 may send a code request for the code segment to the shared storage device 100 (S26). The shared storage device 100 may then transfer the requested code segment corresponding to the code request to the system memory device 200 (S27), and the system memory device 200 may store the code segment and may transfer the code segment received from the shared storage device 100 to the regional ECU 20 (S28). The received code segment may then be newly added as part of a firmware update, or may be a replacement for an existing code segment.

[0081] The zone ECU 20 may load the received code segment into an overlay area corresponding to the loaded main code ( S29 ), and may perform an operation based on the loaded code segment ( S30 ). Figure 8 and / or Figure 9 The illustrated process may be executed for each area ECU 20 .

[0082] So far, references have been Figure 8 and Figure 9 The code request and code segment loading of each area ECU 20 are described, but Figure 8 and Figure 9 The embodiment of the present invention can also be directly applied to the code request and code segment loading of the central ECU 10.

[0083] Figure 10 is a block diagram for explaining operations of an automobile device according to some embodiments.

[0084] refer to Figure 10 After the system is started, the regional ECU 21 reads the main code and code segments that need to be executed or will be executed from the shared storage device 100 through the system memory device 200, and stores the read main code and code segments as an executable code set (such as Figure 8 Operations S11 and S12 or Figure 9 The regional ECU 21 starts the operation of the first function F1 based on the initial executable code set. Thereafter, if additional code segments (such as Figure 8 Operation S13 or Figure 9 The regional ECU 21 sends a code request (e.g., #1-Z13 request) for the first function F1 to the shared storage device 100. The code request may be in Figure 8 Operation S14 or Figure 9 The code request is sent in operation S26.

[0085] In response to receiving the code request, the memory controller 300 verifies the request information included in the code request. The request information may include, for example, requester information about the requester device that sent the code request, information about the master code, address information of the requested code segment corresponding to the code request, and / or the size of the requested code segment. The memory controller 300 stores characteristic information of the requested code segment corresponding to the request information in the segment table 330.

[0086] The memory controller 300 sets an executable code set including the main code information and stores the executable code set as characteristic information in the segment table 330. The executable code set is a data packet executed by the zone ECU 21 to execute the first function F1. The executable code set includes the main code information Z1MC and an overlay area (#2-Z1 code set). The main code information Z1MC may include header information for the entire main code. The overlay area may contain one or more code segments corresponding to the main code information Z1MC, including the current code segment and subsequent code segments.

[0087] If, as in the related art, the main code and the related code segments are transferred together to the regional ECU whenever a code update is performed, the regional memory (see Figure 6 ) needs to be increased, and due to the larger size of the entire code, the burden of code loading may increase. In addition, considering the trend of implementing various functions in automotive devices and the operation of regional ECUs in combination with other ECUs (e.g., the central ECU and other regional ECUs), the transmission of the entire code may reduce operational efficiency. Therefore, in an embodiment, at the time of system startup of the automotive device 1, the central ECU 10 and the regional ECUs 21 and 22 can load and execute the executable code set from the shared storage device 100 and the system memory device 200. Then, during operation, the central ECU 10 and / or the regional ECUs 21 and 22 can newly read the read-only code segment from the shared storage device 100 and the system memory device 200 to overwrite the newly read code segment onto the overlay area of the executable code set, thereby improving both loading speed and operational efficiency.

[0088] The memory controller 300 reads at least one code segment (eg, Figure 10 In the embodiment shown, the segment controller 320 reads the code segment Z13 corresponding to the physical address in the nonvolatile memory device 401 with reference to the segment table 330, and loads the read code segment Z13 into the buffer memory 350.

[0089] The memory controller 300 loads the code segment Z13 previously stored in the buffer memory 350 into the system memory 210 via the system memory controller 201 (#4 - Load). The system memory controller 201 then transmits the loaded code segment Z13 to the requester, i.e., the regional ECU 21 (#5 - Transfer Code Data). The regional ECU 21 stores the received code segment Z13 in its regional memory 25, and the regional processor 24 of the regional ECU 21 continues to execute the first function F1 by loading (or overwriting) the stored code segment Z13 into the overlay area of the transfer code set Z1 that has been stored during operation.

[0090] Figure 11 shows a segment table according to some embodiments, and Figure 12 is a diagram for explaining access frequencies of code segments according to some embodiments.

[0091] refer to Figure 11 Since the size of the regional memories 25 of the regional ECUs 21 and 22 is limited, the regional ECUs 21 and 22 can load only the code segments required for currently executing or about to execute the first function F1 and the second function F2 from the non-volatile memory device 400 into their regional memories 25 through the system memory 210.

[0092] To this end, the segment table 330 stores characteristic information of the code segment to facilitate fast loading of the code segment from the non-volatile memory device 400. The characteristic information includes a segment identifier (ID) containing requester information (e.g., whether any one of the central ECU 10 and the regional ECU 20 has requested the code segment), a requested logical address (LBA), a current physical address (or physical segment address) (PBA) mapped to the requested logical address, a previous physical address (or fallback address (PBA)) of the segment ID, a block size of the requested code segment, an access frequency (Frequency) of the requested code segment, and access information (e.g., a hit rate) for applying a least recently used (LRU) algorithm.

[0093] Specifically, the non-volatile memory device 400 divides and stores the entire code for executing at least one function into multiple code segments based on the physical / functional characteristics of each of the multiple code segments. For example, for code coverage operations in the central ECU 10 and the regional ECUs 21 and 22, the storage controller 300 analyzes and verifies the characteristic information of the multiple code segments through the segment analyzer 310 when storing the multiple code segments, and stores the characteristic information in the segment table 330. The segment controller 320 can load the requested code segments from the non-volatile memory device 400 in units of pages or blocks based on the characteristic information, and can transfer the loaded code segments to the system memory device 200.

[0094] In response to receiving a code request, the segment controller 320 verifies whether the code request originates from the same requester or ECU based on the segment ID (e.g., process address space ID (PASID), requester ID (RID), NID, or VFID) of the code segment stored in the buffer memory 350. The requester device that sent the code request can be selectively identified not only by the NID and VFID, but also by the PASID and / or RID of the target NMVe or PCIe device. For convenience, the NID and VFID are described as requester information below, but the embodiment is not limited thereto, and in some embodiments, various other IDs can also be used as requester information.

[0095] The segment controller 320 reads a series of code segments having the same NID or VFID as the segment ID from the nonvolatile memory device 400. The segment controller 320 reads a series of code segments referencing a current physical address corresponding to the logical address of the code segment in the nonvolatile memory device.

[0096] For example, as previously referenced Figure 10 As described above, the executable code set stored in the regional memory 25 of each of the regional ECUs 21 and 22 includes main code (Code) for scheduling and loading code segments, an overlay area (Overlay area), and code-related data (Data).

[0097] The main code is the main function (eg, Figure 10 “Z1MC”), the main code exists in the regional memory 25 of the regional ECU 21.

[0098] For example, it is assumed that the code segments Z11, Z12 and Z13 of the first function F1 executed by the zone ECU 21 are respectively Figure 11 , corresponding to the segment IDs Seg1_0, Seg2_0, and Seg3_0 in the first function F1. Code segments Z11, Z12, and Z13 can have the same block size or different block sizes. For example, the block size of the code segment "Override Code 1" (Seg1_0) can be 4, the block size of the code segment "Override Code 2" (Seg2_0) can be 1, and the block size of the code segment "Override Code 3" (Seg3_0) can be 3. In this example, the segment controller 320 can identify the requester information of the zone ECU 21 and the segment ID ("Segment ID (Namespace, VF)"), logical address ("Segment Address (LBA)"), current physical address ("Segment Address (PBA)"), block size ("Offset (Block Size)"), frequency ("Frequency"), and hit rate ("HitRatio") of the code segment corresponding to the first function F1 from the characteristic information in the segment table 330.

[0099] The overlay area is an area where code segments are loaded, which have the same NID or VFID and are arranged in the order defined by the segment ID of the code segment in the segment table 330. The overlay area is an area where the code segment (hereinafter referred to as the first code segment) that is currently being loaded into the non-volatile memory device 400 or is about to be executed is stored. The overlay area is an area where an additional code segment (hereinafter referred to as the second code segment) is requested to be replaced with the first code segment or covered by the first code segment during operation. The size of the overlay area can be equal to or slightly larger than the largest block size among all code segments. Figure 10 and Figure 11 In the example of , the size of the coverage area can be equal to or larger than the block size of the code segment "coverage code 1", and its maximum block size is 4.

[0100] The code-related data includes data that performs a function together with the first code segment or the second code segment.

[0101] exist Figure 10 and Figure 11 In the example shown in FIG, segment IDs Seg1_0, Seg2_0, and Seg3_0 are mapped to the same NID, namely, 0x0. NID 0x0 is the ID of the regional ECU 21, while NID 0x1 is the ID of the second ECU 22. If code segments Z11, Z12, and Z13 are to be loaded in the order of Z11, Z12, and Z13 according to the main code, the segment controller 320 may reference the segment table 330 to load code segments Z11 and Z12. Code segments Z11 and Z12 may be loaded from the nonvolatile memory device 400 at system startup, and code segment Z13 may be loaded from the nonvolatile memory device 400 during operation. Code segments Z11, Z12, and Z13 are read from the stored physical addresses, namely, 0x8000_0000, 0x8000_4000, and 0x8000_5000, respectively.

[0102] The segment table 330 includes the access frequencies of the code segments Z11, Z12, and Z13. The memory controller 300 can store the locations of the code segments based on the access frequencies of the code segments recorded in the segment table 330. The access frequency indicates how often each code segment is read in a given cycle. Figure 12 The segment controller 320 counts the number of times each code segment is accessed within a unit time window. The memory controller 300 can change the storage location of the code segment to one of the buffer memory 350, the SLC (single-level cell) area, the MLC (multi-level cell) area, and the TLC (triple-level cell) area based on the access frequency level of the code segment.

[0103] Specifically, refer to Figure 12For convenience, code segments Seg1_0, Seg2_0, Seg3_0, Seg4_1, and Seg5_1 are shown as code segment 1, code segment 2, code segment 3, code segment 4, and code segment 5, respectively. Code segment 1 is accessed 4 times, code segment 2 is accessed 2 times, and code segment 3 is accessed 1 time. Code segments 4 and 5 are each accessed 2 times.

[0104] In some embodiments, the access frequency of code segments can be measured and recorded as a level. The access frequency of the most frequently accessed code segment (i.e., code segment Seg1_0) can be recorded as a high level of 1, the access frequency of the least frequently accessed code segment (i.e., code segment Seg3_0) can be recorded as a low level of 3, and the access frequency of code segment Seg2_0 can be recorded as a medium level of 2. The access frequency of code segments Seg4_1 and Seg5_1 can also be recorded as a level of 2.

[0105] The storage location of the code segment in the nonvolatile memory device 400 may vary from the buffer memory 350 to the SLC area to the MLC area to a default area of TLC or higher-level cells depending on the access frequency level of the code segment.

[0106] For example, code segment Seg1_0 is the most frequently accessed code segment with an access frequency level of 1, and code segment Seg1_0 can be stored in the buffer memory 350 within the storage controller 300, code segment Seg2_0 with an access frequency level of 2 can be stored in the SLC area of the non-volatile memory device 400, and code segment Seg3_0 is the least frequently accessed code segment with an access frequency level of 3, and code segment Seg3_0 can be stored in the default area of the non-volatile memory device 400.

[0107] The segment table 300 may manage characteristic information of the code segment using an LRU method. Since the segment table 330 has a limited size, it is possible to optimize resources by retaining recently used information while deleting obsolete information.

[0108] For example, the LRU information in the characteristic information of the code segment may be hit rate information. For example, the segment controller 320 may delete the code segment information in order of the hit rate from lowest to highest. For example, the code segment Seg3_0 having a hit / miss ratio close to 0% may be deleted from the segment table 330 because the code segment Seg3_0 is rarely accessed during a request.

[0109] Figure 13 is a diagram for explaining address inheritance of code segments according to some embodiments.

[0110] refer to Figure 13, from the perspective of the file transfer layer (FTL), each non-volatile memory device 400 may perform wear leveling for life management.

[0111] As a result of wear leveling, the physical address of the code segment may change. If the location of the block storing the code segment changes due to wear leveling, the storage controller 300 can manage and store both the block information before the change ("Segment Address (PBA)") and the block information after the change ("Rollback Address (PBA)") as characteristic information of the code segment. In the rollback block within each non-volatile memory device 400, the original data is retained until an erase operation is performed. Therefore, the FTL can allocate random specific blocks to record the original data and parity data to ensure integrity, and designate the random specific blocks as rollback blocks to prepare for deleting the rollback blocks.

[0112] For example, for a specific code segment, the memory controller 300 manages a physical address (eg, PBA=0x10_000), lifetime information (eg, EC=1), and code block information (eg, Segment_blk=1).

[0113] Lifespan information is associated with the lifespan of each block of nonvolatile memory device 400 that stores a specific code segment. Wear leveling ensures that all blocks within each nonvolatile memory device 400 are evenly utilized. Unlike areas storing regular data, code storage areas are rarely updated and therefore have a lower erase count (EC). As the EC difference between the code storage area and the regular data storage area increases, blocks with a higher or average EC are intentionally found to relocate data.

[0114] When wear leveling is performed, the EC of the wear-leveled previous physical address increases by 1. During wear leveling, a block with the highest EC may be selected from among a plurality of replacement blocks to inherit each wear-leveled block, thereby managing the life of each nonvolatile memory device 400 .

[0115] The code block information is an indicator for indicating whether the data stored at each specific physical address is a code block storing a code segment. For example, when a code segment is stored, Segment_blk=1, and when data other than a code segment is stored, Segment_blk=0.

[0116] exist Figure 13In the example shown in FIG1 , the code segment stored at PBA: 0x10_0000 is migrated to PBA: 0x20_0000 through the first wear leveling process and is inherited by PBA: 0x20_0000, which has a higher EC of 5 (i.e., EC=5). As a result of the first wear leveling process, the EC of PBA: 0x10_0000, which currently has an EC of 1 (i.e., EC=1), is increased to 2 (i.e., EC=2). In addition, since PBA: 0x10_0000 is no longer the current physical address but becomes the previous physical address, the code block information of PBA: 0x10_0000 changes from Segment_blk=1 to Segment_blk=0. The previous physical address (ie, PBA: 0x10_0000) may then be stored in the segment table 330 as a fallback address along with the current physical address (ie, PBA: 0x20_0000) to prepare for any future issues with wear leveling.

[0117] exist Figure 13 In the example shown in FIG2 , the code segment stored at PBA: 0x20_0000 is migrated to PBA: 0x30_0000 through the second wear leveling process and is inherited by PBA: 0x30_0000, which has a higher EC of 100 (i.e., EC=100). As a result of the second wear leveling process, the EC of PBA: 0x20_0000, which currently has an EC of 5 (i.e., EC=5), is increased to 6 (i.e., EC=6). In addition, since PBA: 0x20_0000 becomes a rollback address, the code block information of PBA: 0x20_0000 changes from Segment_blk=1 to Segment_blk=0. The previous physical address (i.e., PBA: 0x20_0000) can then be stored in segment table 330 as a rollback address together with the current physical address (i.e., PBA: 0x30_0000). At the same time, since the code segment address is a physical address, it needs to be mapped with the logical address included in the code request from the requester device. The mapping between the logical address and the physical address can be based on Figure 14 and Figure 15 The embodiment shown or Figure 16 and Figure 17 The embodiment shown operates as shown.

[0118] Figure 14 is a flowchart illustrating the operation of an automotive device according to some embodiments, and Figure 15 is a conceptual diagram illustrating the operation of an automobile device according to some embodiments.

[0119] refer to Figure 14If the current physical address of the requested code segment in the system memory 210 is known, the memory controller 300 may be able to quickly access the system memory 210 to obtain the requested code segment ("DMA") and transfer the requested code segment to the local memory 25 of the requester device ("Code Data Transfer").

[0120] Specifically, refer to Figure 15 In response to receiving a code request from a requester device, if there is no physical address corresponding to the code request (i.e., no corresponding physical address in the system memory 210 in the segment table 350), the ATC request manager 340 sends a request to the IOMMU 40 ( Figure 7 The TA 41 sends an address translation request (#1—Requesting Address Translation). The TA 41 allocates a physical address corresponding to the address translation request (#2—Getting Address) and transmits the allocated physical address to the ATC request manager 340. The ATC request manager 340 maps the allocated physical address with the characteristic information of the requested code segment, stores it in the segment table 330, and stores the allocated physical address in the address translation cache 500 (#3—Updating the Physical Address with the Logical Address).

[0121] Since code segments are stored in each nonvolatile memory device 400 by being classified based on the access frequency of the code segments, and the code segments can be accessed based on the physical addresses of the code segments mapped in the segment table 330, the physical addresses of the code data in the system memory 210 can be accessed more quickly based on the information in the segment table 330 without sending a physical address allocation request to the TA 41 each time.

[0122] Figure 16 is a flowchart illustrating the operation of an automobile device according to some embodiments of the present disclosure, and Figure 17 is a conceptual diagram illustrating the operation of an automobile device according to some embodiments.

[0123] refer to Figure 16 If the logical address corresponding to the code request is unknown, the memory controller 300 may send an address translation request to the TA 41 within the IOMMU 40 to facilitate access to the system memory 210 having the logical address.

[0124] When a requester device (e.g., the local ECU (ECU1) 20) issues a code request ("Code Request"), the memory controller 300 sends a read command ("Read Command") to the non-volatile memory device 400. The non-volatile memory device 400 reads data from the physical address corresponding to the logical address included in the read command and transfers the read data to the memory controller 300 ("Data (tR+tDMA)"). However, if the physical address corresponding to the code request is unknown, the memory controller 300 sends an address allocation request to the TA 41 within the IOMMU 40, and the TA 41 allocates a new physical address in the system memory 210. The memory controller 300 then stores the requested code segment at the allocated physical address in the system memory 210. The system memory 210 transfers the code data stored at the allocated physical address to the requester device that has issued the code request ("Code Data Transfer").

[0125] refer to Figure 17 In some embodiments, if the address translation cache 500 is not available in the shared storage device 100, or if the address translation cache 500 is not used, the storage controller 300 directly sends an address translation request (#1—Request Address Translation) to the TA 41 within the IOMMU 40. The TA 41 then sends an address translation service response (#2—Update Physical Address) including a new physical address corresponding to the address translation request.

[0126] The memory controller 300 updates the segment table 330 using the physical address sent by the TA 41 as the characteristic information of the corresponding code segment. Then, when reading a subsequent code segment to be overwritten, the memory controller 300 reads the subsequent code segment based on the characteristic information in the segment table 330.

[0127] Figure 18 is a conceptual diagram explaining operations of an automobile device according to some embodiments.

[0128] refer to Figure 18 , as previously referenced Figure 9 As described above, when the firmware of the regional ECUs 21 and 22 is updated, the central ECU 10 outputs code requests (#1-code requests) for transmitting the updated first function F1 and second function F2 to the regional ECUs 21 and 22, respectively. For example, the first function F1 executed in the regional ECU 21 may include code segments Z11, Z12, and Z13, while the second function F2 executed in the regional ECU 22 may include code segments Z21 and Z22. In some embodiments, Figure 18 Instead, the code request may be sent directly from the zone ECUs 21 and 22 to the shared storage device 100 .

[0129] The memory controller 300 checks the requester information included in each code request in the segment table 330. The memory controller 300 identifies the requester information (e.g., the NID of the zone ECUs 21 and 22) and the code region associated with the requester information, reads a plurality of code segment sets corresponding to the code request from the identified code region (e.g., the code region 401), and stores the code segment sets in the buffer memory 350.

[0130] The memory controller 300 reads the code segment set associated with the main code from the nonvolatile memory devices 401 and 402 into the system memory 210 (#2—Load), and transfers the requested code segment from the code segment set stored in the system memory 210 to the regional memories 25 of the regional ECUs 21 and 22 (#3—Transfer Code Data). The regional ECUs 21 and 22 overwrite the code segments stored in their regional memories 25 onto the overlay area of the transferred code segment and continue to execute the first function F1 and the second function F2, respectively.

[0131] Figure 19 is a flowchart illustrating the operation of an automobile device according to some embodiments of the present disclosure, and Figure 20 is a flow chart illustrating the operation of an automotive device according to some embodiments. Figure 20 , A1 shows operation S200 when the shared storage device 100 includes the ATC 500 , and A2 shows operation S300 when the storage controller 300 does not include the ATC 500 .

[0132] refer to Figure 19 and Figure 20 If it is determined that an additional code segment is required during execution of the code associated with the specific function, the ECU 10 or 20 outputs a code request (S100). The memory controller 300 checks the segment table 30 to identify characteristic information corresponding to the code request from the segment table 300 (S110). Specifically, the memory controller 300 identifies the code area and address in the nonvolatile memory device 400 from the characteristic information stored in the segment table 330. The memory controller 300 reads at least one code segment corresponding to the code request (S120).

[0133] Thereafter, the storage controller 300 determines whether mapping information for a physical address corresponding to the requested logical address associated with the read code segment exists (S130). If such mapping information exists (S130, yes), the storage controller 300 may send the read code segment to the corresponding physical address in the system memory 210 (S150). The system memory 210 sends the code segment to the ECU 10 or 20 (S160), which stores the code segment in its local memory 25 and overwrites it (S170), thereby updating the existing executable code set. The ECU 10 or 20 continues to execute a specific function based on the updated executable code set (S180).

[0134] On the contrary, if there is no such mapping information (S130, No), then Figure 20 Address translation is performed as shown.

[0135] Specifically, refer to Figure 20 If the shared memory device 100 includes the address translation cache 500, operation S200 is performed. The memory controller 300 sends an address translation request to the TA 41 of the IOMMU 40 (S210). The TA 41 of the IOMMU 40 allocates a new physical address based on the ATPT 42 and sends an address translation service response to the address translation cache 500 (S220). The segment controller 320 receives the new physical address from the address translation cache 500 and transfers the requested code segment to the new physical address within the system memory 210 (S230).

[0136] Alternatively, if the shared memory device 100 does not include the address translation cache 500, operation S300 is performed. The memory controller 300 sends the requested code segment to the IOMMU 40 without sending the physical address corresponding to the logical address of the requested code segment (S310), and the TA 41 of the IOMMU 40 allocates a new physical address based on the ATPT 42 and transfers the requested code segment to the new physical address within the system memory 210 (S320).

[0137] According to the aforementioned embodiment, even if the code for executing a specific function or a new function continues to be updated and stored in the shared storage device 100, the automotive device 1 can quickly load the updated code into the system memory 210 using the code segment information stored in the storage controller 300. In addition, by loading only the code segment that is a part of the entire code into the system memory 210, the automotive device 1 can effectively utilize the limited resources of the system memory 210.

[0138] The embodiments of the present disclosure have been described above with reference to the accompanying drawings, but the embodiments are not limited thereto and can be implemented in various different forms. It will be understood that the various embodiments can be implemented in other specific forms without changing the technical spirit or subject matter of the present disclosure. Therefore, it should be understood that the embodiments set forth herein are illustrative in all aspects and not restrictive.

Claims

1. An automotive device, comprising: an electronic control unit configured to send a code request; a shared storage device comprising a nonvolatile memory device and a storage controller, the nonvolatile memory device being configured to store a plurality of code segments forming an entire code corresponding to the code request, and the storage controller being configured to load at least one of the plurality of code segments from the nonvolatile memory device into a buffer memory based on characteristic information of each of the plurality of code segments; as well as a system memory device configured to receive the at least one code segment from the buffer memory, store the at least one code segment, and output the at least one code segment to the electronic control unit that sent the code request, The electronic control unit receives the at least one code segment from the system memory device, overwrites the at least one code segment into an executable code set, and executes a function based on the executable code set.

2. The automotive device according to claim 1, wherein The shared storage device includes a segment table containing the characteristic information, and For each of the plurality of code segments, the characteristic information includes requester information, logical address, current physical address, size information, access frequency information, and hit rate of the electronic control unit.

3. The automotive device according to claim 2, wherein: The characteristic information also includes a previous physical address of each of the plurality of code segments and the current physical address.

4. The automotive device according to claim 3, wherein: When a code segment corresponding to the requested logical address corresponding to the code request cannot be read from the current physical address in the nonvolatile memory device, the memory controller reads the at least one code segment based on the previous physical address in the nonvolatile memory device.

5. The automotive device according to claim 2, wherein The memory controller selectively deletes the characteristic information of the at least one code segment from the segment table based on the hit rate of each of the plurality of code segments.

6. The automotive device according to claim 1, wherein The storage controller includes: a segment analyzer configured to determine a code region based on a location, a read access frequency, and an update status of the nonvolatile memory device, and extract the characteristic information of each of the plurality of code segments stored in the code region, a segment table storing the characteristic information of each of the plurality of code segments that have been extracted, a segment controller configured to read the at least one code segment corresponding to the code request from the code area of the nonvolatile memory device based on the characteristic information and output the at least one code segment, and The buffer memory is configured to store the at least one code segment that has been read and output the at least one code segment to the system memory device.

7. The automotive device according to claim 6, wherein: The nonvolatile memory device includes a single-layer cell region, a multi-layer cell region, and a default region, and The segment analyzer is configured to store or migrate the plurality of code segments to one of the buffer memory, the single-level cell region, the multi-level cell region, or the default region based on the read access frequency of each of the plurality of code segments.

8. The automotive device according to claim 1, further comprising a conversion agent, in, When the physical address of the at least one code segment requested by the code request does not exist, the shared memory device receives a newly allocated physical address for the logical address included in the code request from the conversion agent, and sends the at least one code segment to the newly allocated physical address in the system memory device.

9. The automotive device according to claim 8, wherein The shared memory device maps the newly allocated physical address with the logical address, and updates the characteristic information of the at least one code segment corresponding to the code request.

10. A shared storage device, comprising: a nonvolatile memory device configured to store a plurality of code segments forming an entire code; and a memory controller comprising a segment table and a buffer memory, the segment table being configured to store characteristic information of each of the plurality of code segments, The storage controller receives a code request from a host, reads at least one code segment from the nonvolatile memory device based on the characteristic information corresponding to the code request, and transmits the read at least one code segment to the host through a system memory device. The shared storage device according to claim 10 , wherein: The host is configured as: Execute functions based on an executable code set consisting of main code, overlay areas, and code data, updating the set of executable code by overwriting the at least one code segment received from the system memory device into the overlay area, and The function is executed based on the updated set of executable codes.

12. The shared storage device according to claim 11, wherein: The memory controller extracts a code area from the nonvolatile memory device based on a location, an access frequency, and an update status of an area storing the plurality of code segments, and stores address information of the code area in the segment table.

13. The shared storage device according to claim 10, wherein: The memory controller stores the characteristic information of each of the plurality of code segments in the segment table, and The characteristic information includes the host's requester information, logical address information, current physical address information, size information, access frequency information, and a hit rate of each of the multiple code segments.

14. The shared storage device according to claim 10, wherein: The storage controller further includes an address translation cache storing mapping information between logical addresses and physical addresses. When there is no mapping information of a physical address corresponding to the logical address included in the code request, the storage controller sends an address conversion request to the conversion agent, and In response to receiving an address translation service response to a newly allocated physical address that has been newly allocated by the translation agent, the memory controller sends the read at least one code segment to the newly allocated physical address in the system memory device.

15. The shared storage device according to claim 10, wherein: When mapping information of a physical address corresponding to the logical address included in the code request does not exist, the storage controller transfers the at least one code segment that has been read to an input / output memory management unit, and the input / output memory management unit transfers the at least one code segment to a newly allocated physical address corresponding to the logical address in the system memory device.

16. An automotive device, comprising: an electronic control unit configured to perform functions based on a set of executable code comprising a main code and an overlay area; a shared storage device including a nonvolatile memory device and a storage controller, the nonvolatile memory device storing a plurality of code segments forming at least one code, and the storage controller accessing the nonvolatile memory device based on characteristic information corresponding to a code request received from the electronic control unit and reading the code segments; as well as a system memory device configured to receive the code segment that has been read from the memory controller and to send the code segment to the electronic control unit that sent the code request, The automobile device updates the executable code set by overwriting the code segment received from the system memory device into the overlay area.

17. The automotive device according to claim 16, wherein: For each of the plurality of code segments, the characteristic information includes a segment identifier indicating requester information of the electronic control unit, and a logical address, a physical address, a size, an access frequency, and least recently used information of the code segment, and The memory controller stores the characteristic information of each of the plurality of code segments.

18. The automotive device according to claim 17, wherein The memory controller sequentially reads the plurality of code segments associated with the functions executed by the electronic control unit from the nonvolatile memory device based on the characteristic information, stores the plurality of code segments that have been sequentially read in a buffer memory, and transmits the plurality of code segments to the system memory device.

19. The automotive device according to claim 17, wherein The characteristic information also includes an erase count and a previous physical address mapped to the logical address.

20. The automotive device according to claim 17, wherein The nonvolatile memory device includes a single-layer cell region, a multi-layer cell region, and a default region, and The segment analyzer of the memory controller is configured to store or migrate the plurality of code segments to one of a cache memory, the single-level cell area, the multi-level cell area, or the default area based on the access frequency of each of the plurality of code segments.

Images