Semiconductor device and hardware virtualization method

Abstract

To provide a semiconductor device and a hardware virtualization method that reduce a delay when the utilization range of the semiconductor device is changed by an OS.SOLUTION: A semiconductor device 100 restricts an OS that can utilize a function block by an OS identifier written in an attribute register R3 where an accessible OS is restricted, creates, for each OS, the operation setting values of a first input unit 15, a second input unit 16 and a screen synthesizing unit 17, describes the created values in a setting value list stored in a shared memory 20. The first input unit 15, the second input unit 16 and the screen synthesizing unit 17 include respective mask circuits C1 to C3 each referring to the OS identifier in the attribute register R3, and prohibiting the writing of, in setting register groups R4 to R6 in the own block, the operation setting value described in the setting value list created by an OS other than the OS that has a utilization authority to the own block.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a semiconductor device and a hardware virtualization method, and more particularly to a semiconductor device and a hardware virtualization method in which a computing unit is shared by a plurality of operating systems. [Background technology]

[0002] In semiconductor devices that perform various processes based on programs, there is a hardware virtualization technology that processes while switching the range of hardware used by multiple OSs (Operating Systems). In such semiconductor devices, a memory protection mechanism is required to prevent interference between memory spaces used by multiple programs. Therefore, an example of a memory protection mechanism is disclosed in Patent Document 1.

[0003] The semiconductor device described in Patent Document 1 includes a sub-operation unit that executes part of a program executed by a main operation unit, and a shared memory shared by the main operation unit and the sub-operation unit. The sub-operation unit includes a memory protection unit that permits or prohibits access to the shared memory that occurs due to processing executed by the sub-operation unit, based on an access permission range address value provided by the main operation unit.

[0004] Furthermore, in the semiconductor device described in Patent Document 1, the main calculation unit executes a highly reliable trusted program and a non-trusted program that is less reliable than the trusted program, and the process of storing the access permission range address value in the register of the sub-calculation unit is performed by the trusted program. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2017-211980 A Summary of the Invention [Problem to be solved by the invention]

[0006] However, in the semiconductor device described in Patent Document 1, when switching the protected range of the memory, the switching process must be executed by a trusted program, which causes a delay in the switching process.

[0007] Other objects and novel features will become apparent from the description of this specification and the accompanying drawings. [Means for solving the problem]

[0008] According to one embodiment, the semiconductor device and hardware virtualization method restrict the OSs that can use a functional block by an OS identifier written to an attribute register that restricts the accessible OSs, and operation setting values ​​for the first input unit, the second input unit, and the screen compositing unit are created for each OS and listed in a setting value list stored in a shared memory, and the first input unit, the second input unit, and the screen compositing unit each have a masking circuit that refers to the OS identifier in the attribute register and prevents operation setting values ​​listed in the setting value list created by an OS other than one that has authority to use the block from being written to the setting register group of the block. Effect of the Invention

[0009] According to the embodiment, the semiconductor device and the hardware virtualization method can reduce the time required for the process of switching the utilization range of the hardware. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a block diagram of a semiconductor device according to a first embodiment. [Diagram 2] 2 is a block diagram illustrating a relationship between a mask circuit and a register in the semiconductor device according to the first embodiment. FIG. [Diagram 3] 4A to 4C are diagrams illustrating a first example of screen switching in the semiconductor device according to the first embodiment. [Figure 4] 10A to 10C are diagrams illustrating a second example of screen switching in the semiconductor device according to the first embodiment. [Diagram 5] FIG. 11 is a block diagram of a semiconductor device according to a second embodiment. [Figure 6] FIG. 11 is a block diagram illustrating the relationship between a mask circuit and a register in the semiconductor device according to the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] For clarity of explanation, the following description and drawings are omitted and simplified as appropriate. In addition, in each drawing, the same elements are given the same reference numerals, and duplicate explanations are omitted as necessary.

[0012] The semiconductor device described in the following embodiments is hardware shared by multiple OSs (Operating Systems), and a hardware virtualization technology is applied to switch hardware resources allocated to each OS. Specifically, the semiconductor device includes a set of setting registers in which operation setting values ​​are stored, and has multiple functional blocks that operate according to the operation setting values, and an attribute register that stores an OS identifier indicating the type of OS that has the authority to use the multiple functional blocks for each functional block. The operation setting values ​​used in the semiconductor device are created for each OS and are written in a setting value list stored in a shared memory shared by the multiple OSs. Furthermore, each of the multiple functional blocks has a mask circuit that refers to the OS identifier in the attribute register and prevents operation setting values ​​written in a setting value list created by an OS other than the OS that has the authority to use the functional block from being written to the setting register group of the functional block.

[0013] In the following description, as an example of a semiconductor device, a display device that synthesizes screen data generated by multiple OSs and changes the screen data to be synthesized by the synthesis process according to the situation will be described. The display device may be implemented as a display IP (Intellectual Property) that is incorporated as a part of a computing unit that executes a program. The display device uses a shared memory shared by multiple OSs, and a system including the display device and the shared memory is called a display system.

[0014] First embodiment First, a block diagram of a semiconductor device according to the first embodiment is shown in Fig. 1. In Fig. 1, a display device 10, which is a semiconductor device, is included as a part of a display system 100. In addition, in the display system 100, a shared memory 20 is shown as a semiconductor device independent of the display device 10. The display device 10 and the shared memory 20 may be housed in a single package, or may be formed on a single semiconductor chip.

[0015] In addition, in the display system 100 shown in FIG. 1, a main OS (for example, a Real Time OS (RTOS)) and a sub OS (for example, OpenOS1, OpenOS2) are shown as operating systems (hereinafter referred to as OS) that share the display device 10. The RTOS is, for example, an OS whose high level of safety is guaranteed by a high level of operation verification, and generates a functional safety screen that provides safety functions to users of the display system 100. On the other hand, OpenOS1 and OpenOS2 correspond to, for example, an OS created as an open source, or an OS whose commercial license is generally open to the public. In addition, OpenOS1 and OpenOS2 are configured to access the display device 10 via a hypervisor that arbitrates processing between the OSs. The number of OSs applied to the display device 10 is not limited to two, and at least one may be sufficient.

[0016] The display device 10 synthesizes images generated by the RTOS, OpenOS1, and OpenOS2 and displays them on a display (not shown). At this time, in the display system 100, it is necessary for the multiple OSs to set operation setting values ​​related to image synthesis in the registers in the display device 10. Also, virtualization technology is required for one display device 10 to read images generated by multiple OSs. In the display system 100, the RTOS is responsible for generating screens that are important for functional safety, such as the backup camera and warning messages, and display control of how images are synthesized, while screens that are not related to safety, such as navigation screens and entertainment screens, are generated by OpenOS1 and OpenOS2. Details of this display device 10 will be described later.

[0017] The shared memory 20 is a memory shared by the RTOS, OpenOS1, and OpenOS2. The shared memory 20 has a plurality of dedicated areas to which the OSs permitted to access are restricted. In the example shown in FIG. 1, a ROTS dedicated area and an OpenOS1 dedicated area are shown as dedicated areas set in the shared memory 20. An OpenOS2 dedicated area is also set in the shared memory 20, but is not shown in the figure. The ROTS dedicated area is a memory area in which the OSs that can access it are restricted to the RTOS. The OpenOS1 dedicated area is a memory area in which the OSs that can access it are restricted to the OpenOS1. The setting of these dedicated areas is set by a secure processor (not shown) when the display device 10 is started. In other words, the data in the RTOS dedicated area and the data in the OpenOS1 dedicated area are prevented from being interfered with by OSs other than the OSs that generated the data.

[0018] In addition, a first operation setting value list (e.g., a first display list) and first screen data (e.g., first display data) are stored by the RTOS in the RTOS dedicated area. A second operation setting value list (e.g., a second display list) and second screen data (e.g., second display data) are stored by the OpenOS1 in the OpenOS1 dedicated area.

[0019] The display list is a list of multiple elements, with each element being a register address ADD in the display device 10 and an operation setting value SET to be stored in the register specified by that address. The display device 10 acts as a master and reads the display list from the shared memory 20, and for each element, writes the operation setting value SET stored in the data field to the register having the register address ADD pointed to by the address field.

[0020] The display data is image or video data generated by the RTOS and OpenOS 1. This display data may include video from a rear camera.

[0021] Here, the display device 10 will be described in detail. As shown in Fig. 1, the display device 10 has an access protection unit 11, a start control unit 12, a memory access unit 13, a DL input unit 14, a first input unit 15, a second input unit 16, a screen synthesis unit 17, and a display control unit 18. In the display device 10, the first input unit 15, the second input unit 16, the screen synthesis unit 17, and the display control unit 18 are functional blocks that perform specific processing, and the other processing blocks can also be positioned as control blocks that control the operation of the functional blocks.

[0022] The access protection unit 11 sets permission authority for each OS in registers within the display device 10 based on a protection range setting value set by the secure processor when the display system 100 is started, and prevents each OS from accessing registers other than those for which it has permission authority.

[0023] The start control unit 12 has a first screen update register (for example, a screen update register R1), a second screen update register (for example, a screen update register R2), and an attribute register (for example, an OS attribute register R3). In the example shown in FIG. 1, the access protection unit 11 configures the screen update register R1 and the OS attribute register R3 to be accessible only by the RTOS, and the screen update register R2 to be accessible only by OpenOS1 and OpenOS2. The screen update register R1 stores an address indicating the storage position of the first display list by the RTOS. The screen update register R2 stores an address indicating the storage position of the second display list by OpenOS1. The screen update register R1 may store a size value indicating the size of the first display list, and the screen update register R2 may store a size value indicating the size of the second display list. The size value indicating the size of the display list may be included in the header of the display list, and when the size value is described in the header of the display list, the size value is not stored in the screen update registers R1 and R2. In the OS attribute register R3, an OS identifier indicating the type of OS that has the right to use the first input unit 15, the second input unit 16, and the screen composition unit 17 is stored for each functional block by the RTOS. This OS identifier is, for example, ID1 for the RTOS, ID2 for OpenOS1, and ID3 for OpenOS2.

[0024] Then, in response to at least one of the screen update register R1, the screen update register R2, and the OS attribute register R3 being updated, the startup control unit 12 issues a read request to the memory access unit 13 to read the display list from the shared memory 20 using the address and size values ​​stored in the screen update register R1 and the screen update register R2.

[0025] The memory access unit 13 associates the operation setting value included in the display list read in response to the access request received from the start control unit 12 with a read OS identifier (e.g., a read ID) indicating the OS corresponding to the screen update register in which the address information included in the access request is stored, and transmits the associated operation setting value to the first input unit 15, the second input unit 16, and the screen synthesis unit 17. The memory access unit 13 transfers the operation setting value to a setting register having the address value of the setting register associated with the operation setting value. The memory access unit 13 automatically generates a read ID based on which register the screen update register that issued the access request was.

[0026] Furthermore, the memory access unit 13 reads screen data from the shared memory 20 in accordance with an access request from the first input unit 15 and the second input unit 16. Then, the memory access unit 13 transfers the read screen data to the functional block that has issued the access request.

[0027] The DL input unit 14 receives from the memory access unit 13 information regarding the display list, which is among the information read by the memory access unit 13 from the shared memory 20, and a read ID associated with the read information, and transmits this information to the first input unit 15, the second input unit 16, and the screen synthesis unit 17.

[0028] The first input unit 15 has a mask circuit C1 and a setting register group R4. The setting register group R4 stores operation setting values ​​transferred from the DL input unit 14. The mask circuit C1 also refers to the OS identifier in the OS attribute register R3, and prevents operation setting values ​​written in a display list created by an OS other than the OS having the authority to use the own block from being written to the setting register group R4 of the own block.

[0029] Then, the first input unit 15 requests screen data from the shared memory 20 based on the operation setting values ​​stored in the setting register group R4, and transfers the screen data read in response to the request to the screen synthesis unit 17. Here, the operation setting values ​​stored in the setting register group R4 include multiple pieces of information related to the screen data, such as the save destination address of the screen data, the format of the screen data, the resolution, and the screen size.

[0030] The second input unit 16 has a mask circuit C2 and a setting register group R5. The setting register group R5 stores operation setting values ​​transferred from the DL input unit 14. The mask circuit C2 also refers to the OS identifier in the OS attribute register R3, and prevents operation setting values ​​written in a display list created by an OS other than the OS having the right to use the own block from being written to the setting register group R5 of the own block.

[0031] Then, the second input unit 16 requests screen data from the shared memory 20 based on the operation setting values ​​stored in the setting register group R5, and transfers the screen data read in response to the request to the screen synthesis unit 17. Here, the operation setting values ​​stored in the setting register group R5 include multiple pieces of information related to the screen data, such as the save destination address of the screen data, the format of the screen data, the resolution, and the screen size.

[0032] The screen synthesis unit 17 has a mask circuit C3 and a setting register group R6. The setting register group R6 stores operation setting values ​​transferred from the DL input unit 14. The mask circuit C3 also refers to the OS identifier in the OS attribute register R3, and prevents operation setting values ​​written in a display list created by an OS other than an OS having the right to use the block from being written to the setting register group R6 of the block.

[0033] Then, the screen synthesis unit 17 performs synthesis processing on the screen data read by the first input unit 15 and the second input unit 16 based on the operation setting values ​​stored in the setting register group R6, and generates output screen data. Here, the operation setting values ​​stored in the setting register group R6 include a plurality of pieces of information related to the output screen data, such as screen configuration information on which images are to be arranged and how in the generated output screen data, the format of the screen data, the resolution, the screen size, etc.

[0034] The display control unit 18 displays a screen on a display (not shown) based on the output screen data generated by the screen synthesis unit 17 .

[0035] The display device 10 according to the first embodiment has a feature in the configuration of the mask circuit, the screen update registers R1 and R2, and the OS attribute register R3. FIG. 2 shows a block diagram for explaining the relationship between the mask circuit and the registers of the semiconductor device according to the first embodiment.

[0036] As shown in Fig. 2, a setting register address ADD and an operation setting value SET are described for each entry in the display list of the shared memory 20. In the example shown in Fig. 2, a first display list generated by the RTOS is stored at address A1 and is composed of n entries ENT11 to ENT1n. Also, a second display list generated by OpenOS1 is stored at address A2 and is composed of m entries ENT21 to ENT2m.

[0037] 2, the mask circuit C1 of the first input unit 15 has an ID matching unit 31 and an address decoder 32. The mask circuit C2 of the second input unit 16 has an ID matching unit 33 and an address decoder 34. The mask circuit C3 of the screen synthesis unit 17 has an address decoder 36. Here, the ID matching units 31, 33, and 35 are all functionally the same. The address decoders 32, 34, and 36 are all functionally the same.

[0038] A collation unit (e.g., an ID collation unit) verifies whether the read ID matches an OS identifier corresponding to the own block among the OS identifiers (e.g., ID1, ID2) stored in the OS attribute register R3. The address decoder decodes the address ADD of the setting register transmitted from the DL input unit 14 and sets the setting register specified in the display list to a write-enabled state. Here, the address decoder executes the decoding process only when the corresponding ID collation unit determines that the read ID transmitted from the DL input unit 14 matches the OS identifier stored in the OS attribute register R3 for the own block. In other words, the mask circuit permits rewriting of the operation setting value to the setting register group of the own block when the collation unit determines that the read ID matches the OS identifier corresponding to the own block stored in the OS attribute register R3.

[0039] 2, the usage authority of the first input unit 15 and the screen synthesis unit 17 is set to RTOS. As a result, writing to the setting register group R4 of the first input unit 15 and the setting register group R6 of the screen synthesis unit 17 is inhibited except for the operation setting value SET described in the first display list. In addition, the usage authority of the second input unit 16 is set to OpenOS1, and writing to the setting register group R5 of the second input unit 16 is inhibited except for the operation setting value SET described in the second display list.

[0040] Furthermore, when any one of the screen update register R1, screen update register R2, and OS attribute register R3 is rewritten, the start control unit 12 rewrites the setting register group R4 to setting register group R5. At this time, the start control unit 12 does not change the access rights to the screen update register R1, screen update register R2, and OS attribute register R3.

[0041] An example of the screen update process performed by OpenOS1 will be described below. When OpenOS1 performs a screen update, the process is performed through the following four steps. (Step S1) OpenOS1 writes the operation setting values ​​to be applied after the screen update to the second display list via the hypervisor. (Step S2) OpenOS1 rewrites the address and size values ​​of the screen update register R2 to read the rewritten second display list. At this time, since the authority to access the screen update register R2 is given to OpenOS1, OpenOS1 accesses the screen update register R2 without the intervention of the RTOS process. (Step S3) In response to the screen update register R2 being rewritten, the start control unit 12, memory access unit 13, and DL input unit 14 operate, and the setting register group R5 of the second input unit 16, whose OS attribute is set to OpenOS1, is rewritten with the operation setting values ​​after the screen update. (Step S4) The start control unit 12 notifies OpenOS1 of the current status by an interrupt notification.

[0042] Furthermore, in the display device 10, the hardware allocation to the OS by hardware virtualization is changed. Even when changing the range of resources to be used in this way, the display device 10 can reduce communication between the OSs. Therefore, FIG. 3 shows a diagram for explaining a first example of screen switching in the semiconductor device according to the first embodiment.

[0043] The example shown in Fig. 3 shows a state where the reverse gear of the vehicle is switched on and off while the navigation screen is displayed by OpenOS 1 and OpenOS 2. In addition, in the example shown in Fig. 3, five input units, from the first input unit to the fifth input unit, are provided as the input unit.

[0044] When the reverse gear is off, the display system 100 gives the authority to use the first and second input units to OpenOS1, the authority to use the third to fifth input units to OpenOS2, and the authority to use the screen synthesis unit to the RTOS. This is realized by the RTOS giving an OS identifier that provides such authority to the OS attribute register R3 of the startup control unit 12. Then, OpenOS1 generates screen data for the left half of the screen, and OpenOS2 generates screen data for the right half of the screen.

[0045] In the example shown in Fig. 3, OpenOS1 generates a background image and a route image, and provides them to the screen synthesis unit via the first input unit and the second input unit. OpenOS2 generates a background image, a direction indication image, and an information image, and provides them to the screen synthesis unit via the third input unit, the fourth input unit, and the fifth input unit.

[0046] When the reverse gear is switched to the on state, the RTOS rewrites the OS attribute register R3 in the display system 100 to switch the usage authority of the first input unit, the second input unit, the third input unit, and the screen synthesis unit to the RTOS. In addition, the usage authority of the fourth input unit and the fifth input unit is not set, so that they are stopped.

[0047] When the reverse gear is on, the RTOS provides a backup camera image as an input to the first input unit, and generates a guide line indicating the planned route of the vehicle and a message image for warning the driver. The guide line is then provided to the second input unit, and the message image is provided to the third input unit.

[0048] 4 is a diagram for explaining a second example of screen switching in the semiconductor device according to the first embodiment. The example shown in Fig. 4 is an example in which a warning display related to functional safety is overlaid on a navigation screen displayed by OpenOS1 and OpenOS2.

[0049] The state in FIG. 4 where no warning display is performed is the same as the state in FIG. 3 where the reverse gear is off. When a situation occurs in which the RTOS determines that a warning display is necessary, in the display system 100, the RTOS rewrites the OS attribute register R3 and switches the use authority of the fourth input unit and the fifth input unit from OpenOS2 to the RTOS. In response to the rewriting of the OS attribute register R3, the start control unit 12 interrupts and notifies OpenOS2 that the use authority of the functional block has been changed. As a result, OpenOS2 switches the process so that the background image, the direction indication image, and the information screen are generated as one navigation composite image as screen data to be provided to the third input unit. In the example shown in FIG. 4, the RTOS generates a first warning image and provides it to the fourth input unit, and generates a second warning image and provides it to the fifth input unit.

[0050] As described above, the display device 10 according to the first embodiment prevents interference between operations of the OSs by restricting the access authority to the registers in the display device 10 for each OS by the access protection unit 11, even when the display device 10 is used by multiple OSs. Also, in the display system 100, the operation setting values ​​of the functional blocks are stored as a display list in an area dedicated to each OS, and are read into the display device 10 by the addresses stored in the screen update registers R1 and R2, the access authority of which is restricted in the display device 10. In this way, the display system 100 prevents interference between processes of the OSs. In other words, in an environment where multiple OSs coexist, the display device 10 can flexibly switch the allocation of hardware resources while preventing interference between the operations of the OSs in a hardware manner.

[0051] RTOS is a trusted program whose safety is ensured by a very high level of operation verification. On the other hand, OpenOS has a lower verification level than RTOS and can be regarded as an untrusted program. Therefore, the OpenOS version is often changed. In such an environment where RTOS and OpenOS are mixed, when communication between RTOS and OpenOS occurs, the operation of RTOS needs to be re-verified with the change in the OpenOS version. At this time, the re-verification of RTOS requires a high level of verification, which increases the burden in terms of time and cost. However, in the display system 100 using the display device 10, since communication between OSs does not occur, re-verification of RTOS is not required even if the OpenOS is changed, and the burden in terms of time and cost required for re-verification can be significantly reduced.

[0052] Furthermore, in the display device 10 according to the first embodiment, when changing the OS operation setting values, there is no need for communication between OSs or for changing the registers accessed by each OS, and therefore the processing required to change the operation setting values ​​can be speeded up.

[0053] Furthermore, by using the display device 10 according to the first embodiment, it is possible to display information related to functional safety using an RTOS that has undergone high-level verification, without interference from the OpenOS, which has undergone a lower level of verification than the RTOS.

[0054] Embodiment 2 In the second embodiment, a display system 200 including a display device 10a which is another embodiment of the display device 10 according to the first embodiment will be described. In the description of the second embodiment, the same components as those in the first embodiment will be denoted by the same reference numerals as those in the first embodiment, and the description thereof will be omitted.

[0055] Fig. 5 shows a block diagram of a display system 200 including a display device 10a according to the second embodiment. As shown in Fig. 5, the display device 10a has a start-up control unit 12a, a first input unit 15a, a second input unit 16a, and a screen synthesis unit 17a, instead of the start-up control unit 12, the first input unit 15, the second input unit 16, and the screen synthesis unit 17 of the display device 10.

[0056] The start-up control unit 12a is obtained by adding an exclusive use setting register R11, error registers R12 and R13, and a status register R14 to the start-up control unit 12. The exclusive use setting register R11 and the error register R12 are registers to which only the RTOS is given access rights. The error register R13 and the status register R14 are registers to which only the OpenOS (e.g., OpenOS1) is given access rights.

[0057] The first input unit 15a is obtained by replacing the mask circuit C1 of the first input unit 15 with a mask circuit C11. The second input unit 16a is obtained by replacing the mask circuit C2 of the second input unit 16 with a mask circuit C12. The screen synthesis unit 17a is obtained by replacing the mask circuit C3 of the screen synthesis unit 17 with a mask circuit C13.

[0058] In the display device 10a according to the second embodiment, the inclusion of the start control unit 12a, the first input unit 15a, the second input unit 16a, and the screen composition unit 17a allows for improved debugging of applications running on each OS. Hereinafter, the function blocks of the start control unit 12a, the first input unit 15a, the second input unit 16a, and the screen composition unit 17a will be described in detail.

[0059] FIG. 6 shows a block diagram for explaining the relationship between the mask circuit and the register of the semiconductor device according to the second embodiment. Since the mask circuits C11 to C13 have the same configuration, in the example shown in FIG. 6, the mask circuit is shown only for the first input unit 15a among the first input unit 15a, the second input unit 16a, and the screen synthesis unit 17a. In addition, in FIG. 6, the reference character of the OS attribute register R3 corresponding to the first input unit 15a is R3a, and the reference character of the occupancy setting register R11 is R11a. The reference character of the OS attribute register R3 corresponding to the second input unit 16a is R3b, and the reference character of the occupancy setting register R11 is R11b. The reference character of the OS attribute register R3 corresponding to the screen synthesis unit 17a is R3c, and the reference character of the occupancy setting register R11 is R11c.

[0060] As shown in FIG. 6, the mask circuit C11 is obtained by adding a selector 41 to the mask circuit C1. The value stored in the occupancy setting register R11 is an occupancy flag value that becomes a selection signal for the selector 41. This occupancy flag value indicates whether to use a value stored in the OS attribute register R3a or a preset fixed value (e.g., ID1 indicating RTOS) as an OS identifier to be provided to a matching unit (e.g., ID matching unit 31). The occupancy flag value is stored in the occupancy setting register R11 for each functional block. Then, the selector 41 switches the OS identifier to be provided to the ID matching unit 31 between the value stored in the OS attribute register R3a and a fixed value (e.g., ID1 indicating RTOS) according to the occupancy flag value. In the example shown in FIG. 6, if the occupancy flag value is 0, the fixed value is provided to the ID matching unit 31, and if the occupancy flag value is 1, the value of the OS attribute register R3a is provided to the ID matching unit 31. It is assumed that the occupancy flag value is switched for each functional block by an instruction from the RTOS.

[0061] The status register R14 monitors and holds the occupancy flag value stored in the occupancy setting register R11. The error registers R12 and R13 hold the monitored values ​​of the occupancy flag value, the read ID input to the ID matching unit 31 in the mask circuit, and the register address (e.g., the output value of the address decoder) that designates the register included in the set register group.

[0062] In the display system 200 according to the second embodiment, the input and output of the mask circuit are monitored by the error registers R12 and R13 and the status register R14, thereby improving the debuggability of the software. Also, by storing an occupancy flag value in the occupancy setting register R11, the RTOS can temporarily change the authority to use the functional block, thereby further improving the debuggability.

[0063] The invention made by the inventor has been specifically described above based on the embodiments, but it goes without saying that the present invention is not limited to the embodiments already described, and various modifications are possible without departing from the gist of the invention. [Explanation of symbols]

[0064] 10, 10a display device 11 Access Protection Department 12, 12a Start control section 13 Memory Access Unit 14 DL input section 15, 15a First input section 16, 16a Second input section 17, 17a Screen composition section 18 Display control section 20 Shared Memory 31, 33, 35 ID matching section 32, 34, 36 Address Decoder 41 Selector 100, 200 display system C1~C3, C11~C13 Mask circuit R1, R2 Screen update register R3 OS Attributes Register R4~R6 Setting register group R11 Occupancy setting register R12, R13 Error registers R13 Error register R14 Status Register

Claims

1. a first input unit and a second input unit including a setting register group in which operation setting values ​​are stored, and reading screen data from a shared memory shared by a plurality of OSs in accordance with the operation setting values; a screen synthesis unit including a setting register group in which the operation setting values ​​are stored, the screen data read by the first input unit and the second input unit being subjected to synthesis processing in accordance with the operation setting values ​​to generate output screen data; an attribute register that stores, for each functional block, an OS identifier indicating a type of an OS that has a right to use the first input unit, the second input unit, and the screen composition unit; the operation setting values ​​of the first input unit, the second input unit, and the screen synthesis unit are written in a setting value list that is created for each of the OSs and stored in the shared memory, The first input unit, the second input unit, and the screen synthesis unit each have a mask circuit that refers to the OS identifier in the attribute register and prevents the operational setting values ​​listed in the setting value list created by an OS other than an OS that has authority to use the block from being written to the setting register group of the block.

2. a first screen update register, which is restricted from access by OSs other than a main OS responsible for generating a functional safety screen among the plurality of OSs, and which stores first address information relating to an address of a first setting value list created by the main OS among the setting value lists; a second screen update register that restricts access from an OS other than a sub-OS responsible for generating a functional non-safety screen among the plurality of OSs, and stores second address information relating to an address of a second setting value list created by the sub-OS among the setting value lists; 2. The semiconductor device according to claim 1, wherein the operational setting values ​​of the first input section, the second input section and the screen synthesis section are rewritten in response to at least one of the first address information and the second address information being rewritten.

3. 3. The semiconductor device according to claim 2, wherein the first setting value list and the second setting value list each have information about a size of the list itself.

4. a start control circuit which issues a request to access the setting value list based on address information stored in the first screen update register and the second screen update register in response to updating of any one of a value of the first screen update register, a value of the second screen update register, and a value of the attribute register; a memory access unit that transmits the operation setting value read in response to the access request to the first input unit, the second input unit, and the screen composition unit in association with a read OS identifier that indicates an OS corresponding to a screen update register in which the address information included in the access request is stored, 3. The semiconductor device of claim 2, wherein the mask circuit has a comparison unit that checks whether the read OS identifier matches the OS identifier corresponding to the own block among the OS identifiers stored in the attribute register, and when the comparison unit determines that the read OS identifier matches the OS identifier, the mask circuit allows the operational setting value to be rewritten to the setting register group of the own block.

5. an occupancy setting register for storing an occupancy flag value indicating whether a value stored in the attribute register or a preset fixed value is to be used as the OS identifier to be provided to the collation unit for each of the functional blocks; a selector that switches the OS identifier to be provided to the collation unit between a value stored in the attribute register and the fixed value according to the occupancy flag value; The semiconductor device according to claim 4 , further comprising:

6. a status register that monitors and holds the occupancy flag value stored in the occupancy setting register; an error register for holding a value obtained by monitoring the occupancy flag value, the read OS identifier input to the collation unit, and a register address designating a register included in the set register group; The semiconductor device according to claim 5 , further comprising:

7. a plurality of functional blocks including a setting register group in which operation setting values ​​are stored and which operate in accordance with the operation setting values; an attribute register that stores an OS identifier indicating a type of an OS having a right to use the plurality of functional blocks for each of the functional blocks; The operation setting values ​​are written in a setting value list that is created for each of the OSs and stored in a shared memory shared by a plurality of the OSs; The semiconductor device includes a mask circuit that prevents the operational setting values ​​listed in the setting value list created by an OS other than an OS that has authority to use the block from being written to the setting register group of the block by referring to the OS identifier in the attribute register.

8. A hardware virtualization method for a semiconductor device that accesses a shared memory including a setting register group in which operation setting values ​​are stored, the shared memory operating in accordance with the operation setting values, a plurality of function blocks shared by a plurality of OSs, a plurality of registers, and a plurality of restricted areas in which an access range is restricted for each of the plurality of OSs, comprising: setting an attribute register for storing an OS identifier indicating a type of OS having authority to use the plurality of functional blocks for each of the functional blocks; The operation setting values ​​are created for each of the OSs, and are written in a setting value list stored in the shared memory; A hardware virtualization method for a semiconductor device that prevents the operational setting values ​​listed in the setting value list created by an OS other than an OS that has authority to use the functional block from being written to the multiple functional blocks of the functional block by referring to the OS identifier in the attribute register.

Images