WO2016099036A1 - 메모리 접근 방법 및 장치 - Google Patents

메모리 접근 방법 및 장치 Download PDF

Info

Publication number
WO2016099036A1
WO2016099036A1 PCT/KR2015/012317 KR2015012317W WO2016099036A1 WO 2016099036 A1 WO2016099036 A1 WO 2016099036A1 KR 2015012317 W KR2015012317 W KR 2015012317W WO 2016099036 A1 WO2016099036 A1 WO 2016099036A1
Authority
WO
WIPO (PCT)
Prior art keywords
lookup table
vector
data
banks
lookup
Prior art date
Application number
PCT/KR2015/012317
Other languages
English (en)
French (fr)
Inventor
조정욱
김석진
서동관
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to CN201580076202.7A priority Critical patent/CN107223237B/zh
Priority to US15/536,351 priority patent/US10409596B2/en
Priority to EP15870204.3A priority patent/EP3220274B1/en
Publication of WO2016099036A1 publication Critical patent/WO2016099036A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0207—Addressing or allocation; Relocation with multidimensional access, e.g. row/column, matrix
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0215—Addressing or allocation; Relocation with look ahead addressing means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
    • G06F12/0607—Interleaved addressing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9017—Indexing; Data structures therefor; Storage structures using directory or table look-up
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory

Definitions

  • the present invention relates to a method and an apparatus in which a processor accesses a memory, and more particularly, a vector processor gathers a plurality of data from a memory, and transfers the plurality of data back to the memory.
  • the present invention relates to a method and apparatus for scattering.
  • the processor can access the memory to read the data required for the operation and to store the result of the operation again.
  • the processor may execute a load instruction that reads data from the memory and a store instruction that stores the data in the memory.
  • the vector processor is a processor for rapidly performing the same iteration operation on a plurality of data constituting the vector, and may simultaneously read and process the plurality of data from the memory and store the result in the memory again.
  • the vector processor When the vector processor simultaneously reads a plurality of data from the memory or stores the plurality of data in the memory, the same memory bank is frequently accessed. In this case, the occurrence of a memory bank conflict causes a stall, which degrades the performance of the system.
  • the vector processor in order for the vector processor to read a plurality of data from the memory at the same time or store the plurality of data in the memory, it is possible to predict the memory bank collision and schedule the memory access of the vector processor based on the prediction to minimize the occurrence of the collision. Additional dedicated hardware may be required.
  • a processor may provide a method and apparatus for reading a plurality of data in the form of a lookup table from a memory or storing the plurality of data in the form of a lookup table in a memory.
  • the present invention also provides a computer-readable recording medium having recorded thereon a program for executing the method on a computer.
  • the technical problem to be achieved by the present embodiment is not limited to the technical problem as described above, and other technical problems may be inferred from the following embodiments.
  • FIG. 1 illustrates a structure diagram of a vector processor reading and writing data from a memory, according to an exemplary embodiment.
  • FIG. 2 illustrates a method in which a vector processor performs gathering and scattering, according to an embodiment.
  • FIG. 3 is a structural diagram of a vector processor according to an embodiment.
  • FIG. 4 illustrates a plurality of lookup tables generated on a main memory according to an exemplary embodiment.
  • FIG. 5 illustrates a plurality of lookup tables generated on a main memory according to an exemplary embodiment.
  • 6A is a structural diagram of a vector processor according to an embodiment.
  • 6B illustrates a method in which a vector processor synchronizes a plurality of lookup tables, according to an embodiment.
  • FIG. 7 is a structural diagram of a vector processor according to an embodiment.
  • 8A illustrates a method of performing a gather by a vector processor, according to an exemplary embodiment.
  • 8B illustrates a method of performing a gather by a vector processor, according to an exemplary embodiment.
  • FIG 9 illustrates a method of performing a scatter by a vector processor according to an embodiment.
  • FIG. 10 is a flowchart of a method of performing a gather by a vector processor, according to an exemplary embodiment.
  • 11 is a flowchart of a method of generating, by a vector processor, a plurality of lookup tables, according to an embodiment.
  • FIG. 12 shows a flowchart of a method for a vector processor to perform a scatter according to one embodiment.
  • FIG. 13 is a flowchart of a method of performing a gather and scatter by a vector processor according to an embodiment.
  • an apparatus generates a plurality of memory banks and a plurality of lookup tables that copy and store data necessary for a vector operation among data stored in the plurality of memory banks, and store data from the plurality of lookup tables. It may include a control unit for reading the vector data generated.
  • the control unit may include a lookup table generator that generates the plurality of lookup tables, and a gatherer that generates vector data by reading data from the plurality of lookup tables.
  • the control unit may generate one lookup table in each of the banks and generate the same number of lookup tables as the number of the plurality of banks.
  • the control unit may divide the plurality of banks into predetermined groups to generate one lookup table for each group, and the one lookup table generated for each group is interleaved in a plurality of banks belonging to the group. (interleaving) is characterized in that the stored.
  • the controller may access the respective lookup tables using an index vector composed of a plurality of randomly generated indexes, and read data stored at the index positions in the respective lookup tables. It features.
  • the control unit may separate the vector data, which is the result of performing a predetermined vector operation on the vector data, in element units and store the plurality of lookup tables.
  • the control unit stores the respective elements at predetermined index positions in the respective lookup tables.
  • the controller is further configured to store the data stored in the first index of the remaining unchanged lookup table. Update the changed value.
  • the apparatus may further include a switching unit including a plurality of sub-switch units corresponding to the respective look-up tables, wherein the plurality of sub-switch units approach a predetermined index position of each of the look-up tables. It is characterized by determining whether to allow.
  • the plurality of sub-switches may include a plurality of switches corresponding to the respective banks, and each switch may determine whether the control unit is accessible to the respective banks. .
  • the method may further include generating a plurality of lookup tables that copy and store data required for a vector operation among data stored in a plurality of memory banks, and read data from the lookup table to generate vector data. It includes a step.
  • the generating of the lookup table may include generating one lookup table in each of the banks and generating the same number of lookup tables as the number of the plurality of banks in each of the banks. do.
  • the generating of the lookup table may include: dividing the plurality of banks into predetermined groups to generate one lookup table for each group, and one lookup table generated for each group belongs to the group.
  • the plurality of banks may be stored in an interleaving form.
  • the method of generating vector data by reading data from the lookup table may include accessing the lookup table using an index vector composed of a plurality of randomly generated indices and accessing the respective lookup tables. Read data stored at the index position in the table.
  • a result of performing a predetermined vector operation on the vector data is divided into element units and stored as the plurality of lookup tables.
  • the storing of the plurality of lookup tables may include storing the respective elements at predetermined index positions in the respective lookup tables.
  • the storing of the plurality of lookup tables may include: if the value of data stored in the first index in one of the plurality of lookup tables is changed, the first data of the remaining unchanged lookup table is changed. The data stored in the one index is updated to the changed value.
  • the generating of the vector data by reading data from the lookup table may include generating the vector data by reading data existing at a predetermined index position within the respective lookup tables.
  • the storing of the lookup table may include storing the result vector data at predetermined index positions within the respective lookup tables.
  • reading data from the lookup table to generate vector data and storing the data as the plurality of lookup tables may include determining whether the respective banks are accessible.
  • a computer readable recording medium having recorded thereon a program for executing the method on a computer is provided.
  • FIG. 1 illustrates a structure diagram of a vector processor reading and writing data from a memory, according to an exemplary embodiment.
  • the main memory 110 may be a random access memory constituting a computer, a TV, a mobile phone, a mobile device, or the like, but is not limited thereto.
  • the 'main memory' refers to all or part of a memory constituting a storage device of a predetermined machine.
  • the main memory 110 may have a multi-bank structure composed of one or more memory banks (hereinafter, referred to as 'banks') to minimize memory conflicts.
  • the vector processor 180 is a processor capable of simultaneously processing a plurality of data, and the instructions in the vector processor 180 may be processed in the form of Single Instruction Multiple Data (SIMD) or Multiple Instruction Multiple Data (MIMD), but are not limited thereto. Do not.
  • SIMD Single Instruction Multiple Data
  • MIMD Multiple Instruction Multiple Data
  • the vector processor 180 reads a plurality of data from the main memory 110, generates a plurality of data in a vector form, performs a vector operation, and stores the result of the vector operation in the main memory 110 again.
  • the vector processor 180 can access the plurality of banks 120, 121, 122, 123, 124, 125, 126, 127 in the main memory 110 to simultaneously read or store the plurality of data.
  • the vector processor 180 may include a vector register 160.
  • the vector register 160 may store an address of a memory for accessing an element constituting a vector operation, and may be a register that may be read or written by a vector instruction.
  • the vector register 160 may be partitioned into a plurality of elements. For example, if the 16-byte vector register 160 stores an 8-way vector, the vector register 160 may consist of 8 elements, and one element may have a size of 2 bytes.
  • the vector processor 180 has a pipelined architecture, and a vector functional unit performing an operation every clock, and a vector load / loader for reading and storing data from a memory.
  • the storage unit may include a vector load / store unit, a scalar register for storing a memory address and a control signal, and a cross-bar connecting the registers.
  • the vector processor 180 may access the main memory 110 in various ways to read a plurality of data from the main memory 110 or to write a plurality of data to the main memory 110. .
  • the vector processor 180 may sequentially read a plurality of data from the main memory 110 while generating a vector form while increasing the memory addresses one by one.
  • the vector processor 180 may use a unit stride technique that performs a vector operation using the generated vector and sequentially stores the result in the main memory 110.
  • the vector processor 180 may increase the memory address by a constant value stored in a scalar register (not shown) and read a plurality of data from the main memory 110 to generate a vector form.
  • the vector processor 180 may use a stripe access technique that performs a vector operation using the generated vector, increases the performed result by a constant value in the same manner, and stores the result in the main memory 110 again.
  • the vector processor 180 may randomly read data from the main memory 110 and generate a plurality of read data in a vector form.
  • the vector processor 180 may use an indexed load and store technique that performs a vector operation using the generated vector and randomly stores the result in the main memory 110.
  • the index load / store method is a technique of reading data scattered in the main memory 110 using an index vector to generate a vector, and storing the result of the vector operation in the main memory 110 again.
  • reading a plurality of data scattered on the main memory 110 using an index vector is called gather, and using a index vector to scatter the plurality of data (ie, a vector) in the main memory 110. Saving is called a scatter.
  • the vector processor 180 performs a gather by reading data in each memory address calculated by adding a plurality of offset values stored in an index vector to a base address, and performing a vector register. In 160 it can be stored in the form of a vector.
  • an index vector stores 8 indexes, that is, a relative address of a memory in which 8 pieces of data are stored, and adds the base address to the index vector. Can read data from the address. The eight read data are stored in a vector form in the vector register 160.
  • Scatter operations are the inverse of gather operations.
  • the vector stored in the vector register 160 is divided into eight elements, and the offset of the index vector is stored in each memory address plus the base address.
  • the vector processor 180 reads or stores a plurality of data at the same time when performing the gathering and scattering, the same memory bank may be frequently accessed. In this case, the occurrence of a memory bank conflict may cause a stall, which may significantly degrade the performance and efficiency of the vector processor.
  • the vector processor 180 needs to simultaneously access the main memory 110 to read the plurality of data from the main memory 110 and to store the plurality of data in the main memory 110.
  • the main memory 110 may have a multi-memory bank structure, and the vector processor 180 may independently control an address of each memory bank. Additional memory systems (not shown) may be required.
  • FIG. 2 illustrates a method in which a vector processor performs gathering and scattering, according to an embodiment.
  • the vector processor 180 may include a plurality of lookup tables (shaded shades) 210, 220, 230, 240, 250, 260, 270, and 280 that copy and store data necessary for a vector operation among data stored in the main memory 110. ) Can be created.
  • the main memory 110 is a multi-bank structure composed of a plurality of memory banks.
  • the vector processor 180 collects a plurality of pieces of data stored at predetermined index positions of each lookup table from the generated lookup tables 210, 220, 230, 240, 250, 260, 270, and 280 to generate a vector form. Can be.
  • the vector processor 180 may include a plurality of data A, B, C, D, E, F, and G from each lookup table 210, 220, 230, 240, 250, 260, 270, or 280. , H) can be gathered.
  • the gathered plurality of data (A, B, C, D, E, F, G, H) is stored in vector form in vector register 160, and the vector in vector register 160 can be an operand of vector operation. have.
  • the vector processor 180 separates the vectors stored in the vector register 160 in element units and scatters them at predetermined index positions in the lookup tables 210, 220, 230, 240, 250, 260, 270, and 280. Can be.
  • the vector in the vector register 160 which is the target of the scatter, may be a result vector data which performs a predetermined vector operation on the gathered vector data and performs the operation.
  • FIG. 3 is a structural diagram of a vector processor according to an embodiment.
  • the main memory 110 may have a multi-bank structure.
  • the main memory 110 is composed of eight banks 120, 121, 122, 123, 124, 125, 126, and 127, and the vector processor 180 performs an 8-way vector operation. Assume
  • the vector processor 180 performs an 8-way vector operation and the vector register 160 stores an 8-way vector.
  • the vector processor 180 and the vector register 160 are not limited thereto. It is obvious that can process and store n-way vectors.
  • the vector processor 180 may include a gather unit 320 and a lookup table generator 340.
  • the vector processor 180 may include a controller (not shown) including a gather unit 320 and a lookup table generator 340.
  • the lookup table generator 340 may generate a plurality of lookup tables.
  • the lookup table generating unit 340 groups each of the banks 120, 121, 122, 123, 124, 125, 126, and 127 in the main memory 110 or a predetermined number of banks into a group, and then, respectively.
  • One lookup table can be created for each group of. That is, the lookup table generator 340 may generate a lookup table for each group by dividing the plurality of banks in the main memory 110 into N groups. N is an integer greater than one.
  • the lookup table refers to a table that copies and stores data necessary for a vector operation currently performed in the main memory 110. For example, when an image of 8K UHD level is to be improved, a Gaussian filter having a size of 16 ⁇ 16 may be applied in the raster order of the image. 256 Gaussian coefficients required to apply a 16 ⁇ 16 Gaussian filter may be scattered and stored on the main memory 110. According to an embodiment, the lookup table generator 340 may generate a plurality of lookup tables that copy and store data about all Gaussian coefficients scattered on the main memory 110 in an initialization step before performing image quality improvement. Can be.
  • the lookup table generator 340 may generate the same lookup table for all eight banks 120, 121, 122, 123, 124, 125, 126, and 127. have. In this case, eight lookup tables are generated, and each generated lookup table may be stored in each of eight banks 120, 121, 122, 123, 124, 125, 126, and 127.
  • the lookup table generator 340 may include the main memory 110 as a first group (bank 0 (120) and bank 1 (121)) and a second group (bank) as shown in FIG. Group 2 (122), bank 3 (123), third group (bank 4 (124), bank 5 (125)), fourth group (bank 6 (126), bank 7 (127)) You can create one lookup table for a group. In this case, four lookup tables are generated, and four generated lookup tables may be stored separately on two banks.
  • the lookup table generator 340 may include the main memory 110 as a first group (bank 0 (120), bank 1 (121), bank 2 (122), and bank 3 (123)). Grouping into a second group (bank 4 124, bank 5 125, bank 6 126, and bank 7 127) may generate a lookup table for each group. In this case, there are two lookup tables generated.
  • the lookup table generator 340 may generate a lookup table in consideration of a space on the main memory 110 storing the lookup table and the number of memory collisions generated by the vector processor 180 accessing the lookup table. The number of can be determined. That is, each lookup table requires storage space on the main memory 110, and as the number of generated lookup tables increases, the number of collisions occurring in the bank decreases. Thus, the number of lookup tables and the memory bank conflicts have a trade-off relationship. off) is present.
  • the lookup table generator 340 generates the lookup table by the number of banks 120, 121, 122, 123, 124, 125, 126, and 127, and the getter 320 has an element equal to the number of banks.
  • the getter 320 has an element equal to the number of banks.
  • the lookup table generator 340 may generate the lookup table at maximum (that is, for each bank), and select a predetermined number of banks in consideration of the storage space in which the lookup table is to be stored. You can create a lookup table for each group by grouping them into one group. When the lookup table generator 340 generates a lookup table for each group by grouping a predetermined number of banks into one group, each lookup table may be stored in a plurality of memory banks in an interleaving form. Can be. This will be described later in detail with reference to FIG. 5.
  • the gather unit 320 may read a plurality of data from the main memory 110 using the lookup table.
  • the plurality of data may be stored in the vector form in the vector register 160.
  • the gatherer 320 may access an index position of each lookup table existing on the main memory 110 by using an index vector composed of a plurality of randomly generated indices when accessing a plurality of lookup tables.
  • the gatherer 320 may generate an 8-way vector using a vector consisting of eight indices. More specifically, the gatherer 320 may read data by accessing a predetermined index position of each lookup table using a memory address obtained by adding each offset stored in the index vector to the base address.
  • the gatherer 320 reads data from a plurality of lookup tables, and generates vector data by gathering all data constituting the vector after a predetermined reading cycle.
  • FIG. 4 illustrates a plurality of lookup tables generated on a main memory according to an exemplary embodiment.
  • the main memory 110 has a size of 512KB (0x800x_0000 to 0x800x_FFFF) and each of the banks 120, 121, 122, 123, 124, 125, 126, and 127 has a size of 64KB.
  • 0x8000x to 0x807x described at the top of each bank 120, 121, 122, 123, 124, 125, 126, and 127 in Fig. 4 are memory start addresses of each bank.
  • the lookup table may be generated for each of eight banks or for a group of a predetermined number of banks in one group.
  • the plurality of lookup tables may be generated by the lookup table generator 340.
  • FIG. 4 illustrates a case where a lookup table is generated for each of eight banks
  • FIG. 5 illustrates a case where one lookup table is generated for each of two banks.
  • FIG. 4 shows only lookup tables 410, 415, and 420 for the bank 0 120, the bank 3 123, and the bank 7 127 of the eight banks, and the rest of the lookup tables are omitted. Also, for convenience of description, the data in each lookup table 410, 415, 420 has the same value as each index.
  • the lookup table generator 340 may generate the lookup tables in a two-dimensional array. That is, when the number of generated lookup tables is called I and the number of data required for the vector operation is called J, the lookup table may be generated as a two-dimensional array of I x J. Each lookup table can be distinguished by different upper addresses.
  • the two-dimensional array may be generated in an initialization step before the vector processor 180 performs a vector operation.
  • Fig. 4 there are eight banks (120, 121, 122, 123, 124, 125, 126, 127) and all lookup tables have been generated for each bank, so that the generated lookup tables are eight and each lookup table is 256. Because it contains data, a two-dimensional array of size 8 x 256 can be declared.
  • the vector processor 180 may perform gathering using software codes as shown in Table 1 below. It is obvious that the software code in Table 1 is just one embodiment of performing the gather and may be implemented in other forms.
  • “ret” is a vector generated by performing a gather operation.
  • the “ret” vector is an 8-way vector of unsigned short data. That is, the "I_intr_gather8_uh” function described in Table 1 can generate data by reading data from eight banks using eight indexes.
  • I_src1 is an 8-way index vector containing eight indices of unsigned short data. "I_src1.s0, _I_src1.s1, ..., _I_src1.s7" are index positions where data to be read from each lookup table exist and may be randomly generated indexes.
  • I_src2 is a lookup table declared as a two-dimensional array of unsigned character type. Each lookup table (_I_src2 [0: 7]) performs only one access. For example, data may be read from the lookup table of _I_src2 [0] using the index of _I_src1.s0 and data may be read from the lookup table of _I_src2 [1] using the index of _I_src1.s1. That is, the data can be read by changing the index for each lookup table. That is, even when a plurality of data is read from the main memory 110 using a randomly generated index vector, each of the eight data is read from different banks, so that no memory bank collision occurs.
  • FIG. 5 illustrates a plurality of lookup tables generated on a main memory according to an exemplary embodiment.
  • the lookup table 530 for the bank 0 120 and the bank 1 121 is generated, the lookup table 540 for the bank 2 122 and the bank 3 123 is generated, and the bank 4 124 is generated.
  • Each of the four lookup tables generated is stored separately in two banks.
  • the lookup table 350 is stored separately on the bank 0 120 and the bank 1 121
  • the lookup table 360 is stored separately on the bank 4 124 and the bank 5 125. Can be.
  • the lookup table may be stored in the form of interleaving 510 in a plurality of banks. That is, memory bank collisions can be minimized by alternately storing data located in adjacent memories in two different banks. For example, bank 0 (120) stores data of indexes ⁇ 0, 2, 4, ..., 252, 254 ⁇ , and bank 1 (121) stores ⁇ 1, 3, 5, ..., 253 , 255 ⁇ can be stored.
  • the vector processor 180 may perform a gather operation using software codes as shown in Table 2 below. It is obvious that the software code in Table 2 is just one embodiment of performing a gather operation and may be implemented in other forms.
  • data of even indexes is stored in bank 0 (120), bank 2 (122), bank 4 (124), and bank 6 (126), and bank 1 (121) and bank 3 (123). ),
  • the bank 5 125 and the bank 7 127 implement a lookup table in the form of interleaving 510 for storing odd index data, and the calling index vector is ⁇ even, odd, even, odd, even, In the case of an 8-way vector consisting of odd, even, and odd ⁇ , no memory bank collision occurs.
  • 6A is a structural diagram of a vector processor according to an embodiment.
  • the vector processor 180 may include a gather unit 320, a lookup table generator 340, and a scatter unit 630.
  • the gather unit 320 and the lookup table generator 340 have been described above with reference to FIG. 3 and thus will be omitted.
  • the scatterer 630 corresponds to an inverse process of the process performed by the gatherer 320. Therefore, although omitted below, the descriptions of the gatherer 320 and the lookup table generator 340 of FIGS. 2 to 5 are equally applicable to the scatterer 630 according to the embodiment of FIG. 6. .
  • the scatterer 630 may separate the vector data stored in the vector register 160 in element units and store the vector data again in a plurality of lookup tables.
  • the vector register 160 may store vector data as a result of performing a predetermined vector operation on vector data generated by the gather unit 320.
  • the scatterer 630 may perform scattering using software codes as shown in Table 3 below. It is obvious that the software code in Table 3 is just one embodiment of performing the scatter and may be implemented in other forms.
  • the "_intr_scatter8_uh” function may separate an 8-way vector stored in the vector register 160 in element units and store it in a predetermined position of a lookup table generated for each bank.
  • "I_src3" is a vector stored in the vector register 160 and may store a result vector of performing a vector operation.
  • "I_src3" is an 8-way vector of unsigned integer data.
  • I_src1 is an 8-way index vector of unsigned short data.
  • the function “_intr_scatter8_uh” may store _I_src3.s3 in the location of _I_src1.s3 of the lookup table _I_src2 [3].
  • 6B illustrates a method in which a vector processor synchronizes a plurality of lookup tables, according to an embodiment.
  • the lookup table generator 340 since the lookup table generator 340 generates the same plurality of lookup tables in the initialization step, the data of the plurality of lookup tables may be synchronized with each other. That is, unlike the gatherer 320, the scatterer 630 may change a value stored at a predetermined index position of each lookup table, and may update the same indexed value at the same index position of another lookup table.
  • the synchronization between the lookup tables may be implemented by the switching unit 745, which will be described later with reference to FIG.
  • the scattering unit 630 updates the value stored in the specific index of the specific lookup table because the element value of the vector stored in the vector register 160 is changed, the data stored in the specific index for the remaining lookup table is also updated. can do.
  • the value of the 12th index 620 of bank 0 120 is changed to X after the vector operation is performed, 12 of the remaining banks 120, 121, 123, 124, 125, 126, 127
  • the value of the first index position can also be updated to X.
  • the scatterer 630 does not necessarily need to change the values of all lookup tables to be the same in all cases.
  • the scatterer 630 may selectively perform the scatter operation by using the switching unit 745 described later with reference to FIGS. 8 to 10. have.
  • FIG. 7 is a structural diagram of a vector processor according to an embodiment.
  • the vector processor may include a gather unit 320, a scatter unit 630, a switching unit 745, and a lookup table generator 340.
  • the switching unit 745 may control access to each bank of the gather unit 320 and the scatter unit 630 to determine whether to perform gather and scatter on a predetermined index position of each lookup table.
  • the switching unit 745 may include a sub-switch unit (not shown) corresponding to each look-up table, and the sub-switch unit may include the gather unit 320 and the scatter unit 630 in predetermined banks in which the look-up table exists. You can decide whether to allow access to the index location of.
  • Each sub switch unit may have an on / off switch for each bank in which a plurality of lookup tables exist. That is, each sub-switch part may include the same number of switches as the number of banks, and each switch may determine whether the gather unit 320 and the scatter unit 630 are accessible to each bank.
  • the gather unit 320 cannot read data from the off-state bank, and the scatter unit 630 also cannot store data in the off-state bank.
  • the gatherer 320 and the scatterer 630 may perform gathering and scattering at predetermined index positions of the on-state bank, respectively.
  • the switching unit 745 may include eight sub-switch units. Each sub switch unit may include the same sub switch unit as the number of banks.
  • the vector processor 180 may perform a scattering by appropriately turning on a switch of each sub-switch unit in the switching unit 745. This will be described later with reference to FIG.
  • the vector processor 180 gathers one or two pieces of data from each lookup table to generate a vector form, only one or two switches in each sub-switch in the switching unit 745 are turned on ( Gather can be performed by setting to On). This will be described later with reference to FIG. 8.
  • 8A illustrates a method of performing a gather by a vector processor, according to an exemplary embodiment.
  • each lookup table is stored in an interleaving form in two banks.
  • the lookup table 850 is stored in an interleaved form in the bank 0 120 and the bank 1 121.
  • the gatherer 320 may generate two 8-way vectors by gathering two pieces of data for each lookup table.
  • the switching unit 745 may include four sub-switching units 810, 820, 830, and 840 corresponding to each lookup table.
  • Each of the sub switch units 810, 820, 830, and 840 may include eight switches equal to the number of banks 120, 121, 122, 123, 124, 125, 126, and 127.
  • the upper left switch in each sub-switch section 810, 820, 830, 840 controls access to each bank 0 (120), and the switch at the bottom right controls access to bank 7 (127). can do.
  • the switches in the sub-switch units 810, 820, 830, and 840 are illustrated by shading.
  • the upper leftmost part in the sub-switch part is referred to as the first switch, and the switches are numbered in the order from left to right, and then from top to bottom. That is, the switch at the bottom right of the sub switch units 810, 820, 830, and 840 is the eighth switch.
  • the getter unit 320 uses a sub-switch unit 810 in which first and second switches are on, and lookups stored in the bank 0 120 and the bank 1 121.
  • the data of indexes 0 and 5 of the table 850 may be read.
  • the getter unit 320 uses the sub-switch unit 830 in which the fifth and sixth switches are on, and the lookup stored in the banks 4 124 and 5 5.
  • the data of indexes 4 and 1 of the table 870 can be read.
  • 8B illustrates a method in which a vector processor performs gathering, according to an embodiment.
  • FIG. 8B illustrates a case in which lookup tables are generated one by one for each bank 120, 121, 122, 123, 124, 125, 126, and 127.
  • the switching unit 745 may include eight sub-switch units 815, 825, 835, 845, 855, 865, 875, and 885 corresponding to each lookup table.
  • Each sub switch unit 815, 825, 835, 845, 855, 865, 875, and 885 may include eight switches equal to the number of banks.
  • the vector processor 180 sets only one switch of the eight switches included in each sub-switch unit 815, 825, 835, 845, 855, 865, 875, and 885 to be in an on state.
  • One data existing at a predetermined index position can be read from each lookup table 818, 828, 838, 848, 858, 868, 878, 888.
  • the gather unit 320 stores the data stored in the index 0 of the lookup table 818 stored in the bank 0 120 using the sub-switch unit 815 in which the first switch is turned on.
  • the data stored in the index 7 of the lookup table 868 stored in the bank 5 125 may be read using the sub-switch unit 865 in which the sixth switch is turned on.
  • FIG 9 illustrates a method of performing a scatter by a vector processor according to an embodiment.
  • one lookup table stores four data and is stored in two banks in an interleaving form.
  • the lookup table 950 is stored in an interleaved form in the bank 0 120 and the bank 1 121. That is, indices 0 and 2 of each lookup table exist in even-numbered banks 120, 122, 124, and 126, and indices 1 and 3 exist in odd-numbered banks 121, 123, 125, and 127.
  • the scatterer 630 may divide the vectors stored in the vector register 160 in element units and scatter them in the lookup tables 950, 960, 970, and 980.
  • a vector previously stored in the vector register 160 is a 4-way vector, and that all elements of the vector are updated after the vector operation is performed.
  • the scatterer 630 stores the first element of the 4-way vector as the lookup table 950, stores the second element as the lookup table 960, and stores the third element as the lookup table 970.
  • the fourth element may be stored as the lookup table 980. That is, four elements may be scattered in different indexes in each lookup table 950, 960, 970, 980.
  • the plurality of lookup tables may need synchronization.
  • the vector processor 180 properly sets the eight switches present in each of the sub-switches 910, 920, 930, and 940 to the on state, thereby scattering all index positions in each lookup table. Can be performed.
  • the first, third, fifth, and seventh switches of the sub switch unit 910 may be turned on to store data in the index 2 of each lookup table 950, 960, 970, and 980.
  • the second, fourth, sixth, and eighth switches of the sub switch unit 920 may be turned on to store data in the index 3 of each lookup table 950, 960, 970, and 980.
  • first, third, fifth, and seventh switches of the sub switch unit 930 may be turned on to store data in index 0 of each lookup table 950, 960, 970, and 980.
  • the second, fourth, sixth, and eighth switches of the sub switch unit 940 may be turned on to store data in the index 1 of each lookup table 950, 960, 970, 980.
  • the vector processor 180 may perform scatter by setting only some of the switches of each sub-switch unit 910, 920, 930, and 940 to an on state.
  • Self-explanatory For example, although not shown in FIG. 9, only the first switch of the sub switch unit 910 may be turned on to store data at a position of index 2 of the lookup table 950 stored in the bank 0 120. .
  • only the fourth switch of the sub switch unit 920 may be turned on to store data at a position of index 3 of the lookup table 960 stored in the bank 3 123.
  • only the fifth switch of the sub switch unit 930 may be turned on to store data at a position of index 0 of the lookup table 970 stored in the bank 4 124.
  • only the eighth switch of the sub-switcher 940 may be turned on to store data in the position of index 1 of the lookup table 980 stored in the bank 7 127.
  • the gather unit 320, the scatter unit 630, the switching unit 745, and the lookup table generator 340 do not change the structure of the vector processor 180. It can be implemented by extending the generation of the lookup table and the load and store operations of the vector processor. Therefore, it is implemented in an intrinsic form that does not change the instruction set architecture (ISA) of the vector processor 180, so that the structure of the vector processor 180 may be implemented without modification or additional hardware.
  • ISA instruction set architecture
  • 10 to 13 are diagrams for describing a method of performing a gather and a scatter performed by the vector processor 180 illustrated in FIGS. 1 to 9. Therefore, even if omitted below, the above description of the vector processor 180 in FIGS. 1 to 9 may also be applied to the gather and scatter methods according to the exemplary embodiment of FIGS. 10 to 13.
  • FIG. 10 is a flowchart of a method of performing a gather by a vector processor, according to an exemplary embodiment.
  • the vector processor 180 may generate a plurality of lookup tables for the main memory.
  • the lookup table refers to a table that copies and stores data necessary for a vector operation currently performed among the data stored in the main memory.
  • the main memory may be a multi-bank structure.
  • the generated lookup table may be stored separately in each bank or banks of a plurality of banks.
  • the vector processor 180 may perform gathering by reading a plurality of data from the lookup table to generate vector data. More specifically, the vector processor 180 may perform a gather operation that reads a plurality of data from the main memory and stores the data in a vector register in a vector register using the generated lookup table.
  • the vector processor 180 may read data by accessing an index position of each lookup table existing in the main memory using an index vector composed of a plurality of randomly generated indexes.
  • 11 is a flowchart of a method of generating, by a vector processor, a plurality of lookup tables, according to an embodiment.
  • the vector processor 180 may determine the number of lookup tables to generate. According to an embodiment, the vector processor 180 considers a trade-off between a space in main memory storing a lookup table and a memory collision occurring when the vector processor accesses the lookup table. The number can be determined.
  • the vector processor 180 determines whether to generate the same number of lookup tables as the number of memory banks. If the number of lookup tables to be generated is equal to the number of banks, the vector processor 180 proceeds to step 1140. Passing
  • the vector processor 180 may separately store each generated lookup table in a plurality of banks.
  • the vector processor 180 may separately store each lookup table in a plurality of banks in an interleaving form. That is, memory bank collisions can be minimized by alternately storing a plurality of data in different banks.
  • the vector processor 180 may generate one lookup table for each bank. Each lookup table is stored in each bank.
  • FIG. 12 shows a flowchart of a method for a vector processor to perform a scatter according to one embodiment.
  • Steps 1020 and 1030 have been described above with reference to FIG. 10 and will be omitted.
  • the vector processor 180 may perform a scatter that stores vector data scattered in a lookup table.
  • the vector processor 180 may separate the vector stored in the vector register by element, and store the vector in the lookup table.
  • a vector operation is performed on the generated vector in step 1030, and the result vector data obtained by the operation is stored.
  • the result vector data may be stored as a plurality of lookup tables.
  • the vector processor 180 updates a value stored in a specific index of a specific lookup table for synchronization between lookup tables
  • the data stored in the specific index for the remaining lookup tables may be updated in the same manner. Can be.
  • FIG. 13 is a flowchart of a method of performing a gather and scatter by a vector processor according to an embodiment.
  • Steps 1020, 1030, and 1230 have been described above with reference to FIGS. 10 and 12 and will be omitted.
  • the vector processor 180 may determine whether to allow access to a predetermined index position of each lookup table in step 1310 before performing a gather (step 1030) or performing a scatter (step 1230). . That is, the vector processor 180 determines whether each lookup table is accessible to each bank in which the lookup table is stored, thereby determining the index position of the lookup table to which the gather (step 1030) or the scatter (step 1230) is to be performed. Can be.
  • vector data may be generated by reading data existing at a predetermined index position to which access is allowed in each lookup table.
  • the vector processor 180 may generate vector data by reading data stored at a predetermined position from a lookup table existing in an accessible bank.
  • the vector data may be stored at a predetermined index position to which access is allowed in each lookup table.
  • the vector processor 180 may store data at a predetermined position as a lookup table existing in an accessible bank.
  • the vector processor 180 may be applied to most processors that perform vector operations, such as a general purpose processor, a digital signal processing processor (DSP), an application specific instruction set processor (ASIP), and a graphic processing unit. Applicable
  • the method may be embodied as computer readable codes on a computer readable recording medium.
  • the computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM. CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and the like, and also include those implemented in the form of carrier waves such as transmission over the Internet.
  • the computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Complex Calculations (AREA)

Abstract

복수의 메모리 뱅크(Bank)와 복수의 메모리 뱅크에 저장된 데이터 중 벡터 연산에 필요한 데이터를 복사하여 저장한 복수의 룩업 테이블을 생성하고, 생성된 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 제어부를 포함하는 장치가 개시된다.

Description

메모리 접근 방법 및 장치
본 발명은 프로세서(Processor)가 메모리에 접근하는 방법 및 장치에 관한 것으로, 보다 구체적으로는 벡터 프로세서(Vector Processor)가 메모리로부터 복수의 데이터를 게더(Gather)하고, 복수의 데이터를 다시 메모리로 스캐터(Scatter)하는 방법 및 장치에 관한 것이다.
프로세서(Processor)는 연산에 필요한 데이터를 읽어오고 연산 결과를 다시 저장하기 위해 메모리에 접근할 수 있다. 예를 들어, 프로세서는 메모리로부터 데이터를 읽는 로드 명령어(Load Instruction) 및 메모리에 데이터를 저장하는 저장 명령어(Store Instruction)을 실행할 수 있다.
초기 프로세서 기술에서는 하나의 명령으로 하나의 데이터를 처리하는 방식(Single Instruction Single Data)을 채용한 스칼라(Scalar)프로세서를 채용하였다.
그러나 스마트폰, 고해상도 텔레비전 등의 보급화되면서 영상 처리, 비전 처리, 화질 처리 또는 그래픽 렌더링(Graphic rendering)과 같은 분야에서 대용량 데이터의 처리가 가능한 프로세서의 필요성이 증대되었다. 이에 따라, 단일 명령으로 복수의 데이터를 처리하는 방식(Single Instruction Multiple Data)을 채용한 벡터(Vector) 프로세서의 사용이 보편화되었다. 벡터 프로세서는 벡터를 구성하는 복수의 데이터에 대해 동일한 반복 연산을 고속 수행하기 위한 프로세서로, 메모리로부터 복수의 데이터를 동시에 읽어 처리한 후 결과를 다시 메모리에 저장할 수 있다.
벡터 프로세서가 메모리로부터 복수의 데이터를 동시게 읽거나 또는 복수의 데이터를 메모리에 저장하기를 수행할 때, 동일한 메모리 뱅크를 접근하는 경우가 빈번히 발생한다. 이 경우 메모리 뱅크 충돌(Memory Bank Conflict)의 발생으로 스톨(Stall)을 야기하여 시스템의 성능이 저하된다.
따라서, 벡터 프로세서가 메모리로부터 동시에 복수의 데이터를 읽거나 복수의 데이터를 메모리에 저장하기 위해서는, 메모리 뱅크 충돌을 예측하고 예측을 기반으로 벡터 프로세서의 메모리 접근을 스케줄링하여 충돌의 발생을 최소화할 수 있는 전용 하드웨어가 추가적으로 필요할 수 있다.
그러나, 추가적인 하드웨어로 인해 프로세서의 전체 면적이 증가될 수 있으며, 설계의 복잡도는 높아진다. 또한 소프트웨어의 복잡한 구현은 프로세서의 또 다른 성능저하를 야기할 수 있다.
프로세서가 메모리로부터 룩업 테이블(Lookup table)형태의 복수의 데이터를 읽거나, 복수의 데이터를 메모리에 룩업 테이블 형태로 저장하는 방법 및 장치를 제공할 수 있다.
또한, 상기 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록 매체를 제공하는데 있다. 본 실시 예가 이루고자 하는 기술적 과제는 상기된 바와 같은 기술적 과제로 한정되지 않으며, 이하의 실시 예들로부터 또 다른 기술적 과제들이 유추될 수 있다.
도1은 일 실시예에 따른 벡터 프로세서가 메모리로부터 데이터를 읽고 쓰는 구조도를 나타낸다.
도2는 일 실시예에 따른 벡터 프로세서가 게더 및 스캐터를 수행하는 방법을 나타낸다.
도3는 일 실시예에 따른 벡터 프로세서의 구조도를 나타낸다.
도4는 일 실시예에 따른 메인 메모리 상에 생성된 복수개의 룩업 테이블을 나타낸다.
도5는 일 실시예에 따른 메인 메모리 상에 생성된 복수개의 룩업 테이블을 나타낸다.
도6a은 일 실시예에 따른 벡터 프로세서의 구조도를 나타낸다.
도6b은 일 실시예에 따른 벡터 프로세서가 복수의 룩업 테이블을 동기화시키는 방법을 나타낸다.
도7은 일 실시예에 따른 벡터 프로세서의 구조도를 나타낸다.
도8a는 일 실시예에 따른 벡터 프로세서가 게더를 수행하는 방법을 나타낸다.
도8b는 일 실시예에 따른 벡터 프로세서가 게더를 수행하는 방법을 나타낸다.
도9는 일 실시예에 따른 벡터 프로세서가 스캐터를 수행하는 방법을 나타낸다.
도 10은 일 실시예에 따른 벡터 프로세서가 게더를 수행하는 방법의 흐름도를 도시한다.
도 11는 일 실시예에 따른 벡터 프로세서가 복수의 룩업 테이블을 생성하는 방법의 흐름도를 도시한다.
도 12 는 일 실시예에 따른 벡터 프로세서가 스캐터를 수행하는 방법의 흐름도를 도시한다.
도 13은 일 실시예에 따른 벡터 프로세서가 게더 및 스캐터를 수행하는 방법의 흐름도를 도시한다.
일 실시예에 따른 장치는 복수의 메모리 뱅크(Bank), 및 상기 복수의 메모리 뱅크에 저장된 데이터 중 벡터 연산에 필요한 데이터를 복사하여 저장한 복수의 룩업 테이블을 생성하고, 상기 복수의 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 제어부를 포함할 수 있다.
일 실시예에 따른 상기 제어부는, 상기 복수의 룩업 테이블을 생성하는 룩업 테이블 생성부, 및 상기 복수의 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 게더(Gather)부를 포함한다.
일 실시예에 따른 상기 제어부는, 상기 각각의 뱅크에 하나의 룩업 테이블을 생성하여, 상기 복수의 뱅크들의 개수와 동일한 개수의 룩업 테이블을 생성하는 것을 특징으로 한다.
일 실시예에 따른 상기 제어부는, 상기 복수의 뱅크들을 소정의 그룹으로 나누어, 상기 그룹별로 하나의 룩업 테이블을 생성하고, 상기 그룹별로 생성된 하나의 룩업 테이블은 상기 그룹에 속하는 복수개의 뱅크에 인터리빙(interleaving)형태로 저장되는 것을 특징으로 한다.
일 실시예에 따른 상기 제어부는, 랜덤(random)하게 생성된 복수의 인덱스로 구성된 인덱스 벡터를 이용하여 상기 각각의 룩업 테이블을 접근하고, 상기 각각의 룩업 테이블 내의 상기 인덱스 위치에 저장된 데이터를 읽는 것을 특징으로 한다.
일 실시예에 따른 상기 제어부는, 상기 벡터 데이터에 소정의 벡터 연산이 수행된 결과 벡터 데이터를 엘리먼트 단위로 분리하여 상기 복수의 룩업 테이블로 저장한다.
일 실시예에 따른 상기 제어부는, 상기 각각의 엘리먼트를 상기 각각의 룩업 테이블 내의 소정의 인덱스 위치에 저장한다.
일 실시예에 따른 상기 제어부는, 상기 복수의 룩업 테이블들 중 어느 하나의 룩업 테이블 내의 제1인덱스에 저장된 데이터의 값이 변경되면, 변경되지 않은 나머지 룩업 테이블의 상기 제1인덱스에 저장된 데이터를 상기 변경된 값으로 갱신한다.
일 실시예에 따른 상기 장치는, 상기 각각의 룩업 테이블에 대응하는 복수의 서브 스위치부로 구성된 스위칭부를 더 포함하고, 상기 복수의 서브 스위치부는 상기 제어부가 상기 각각의 룩업 테이블의 소정의 인덱스 위치에 접근하는 것을 허용할지 여부를 결정하는 것을 특징으로 한다.
일 실시예에 따른 상기 복수의 서브 스위치부는, 상기 각각의 뱅크와 대응되는 복수의 스위치를 포함하고, 상기 각각의 스위치는 상기 각각의 뱅크에 대한 상기 제어부의 접근 가능 여부를 결정하는 것을 특징으로 한다.
일 실시예에 따른 방법은, 복수의 메모리 뱅크(Bank)에 저장된 데이터 중 벡터 연산에 필요한 데이터를 복사하여 저장한 복수의 룩업 테이블을 생성하는 단계, 및 상기 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 단계를 포함한다.
일 실시예에 따른 상기 룩업 테이블을 생성하는 단계는, 상기 각각의 뱅크에 하나의 룩업 테이블을 생성하여, 상기 각각의 뱅크에 상기 복수의 뱅크들의 개수와 동일한 개수의 룩업 테이블을 생성하는 것을 특징으로 한다.
일 실시예에 따른 상기 룩업 테이블을 생성하는 단계는, 상기 복수의 뱅크들을 소정의 그룹으로 나누어, 상기 그룹별로 하나의 룩업 테이블을 생성하고, 상기 그룹별로 생성된 하나의 룩업 테이블은 상기 그룹에 속하는 복수개의 뱅크에 인터리빙(interleaving)형태로 저장되는 것을 특징으로 한다.
일 실시예에 따른 상기 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 단계는, 랜덤(random)하게 생성된 복수의 인덱스로 구성된 인덱스 벡터를 이용하여 상기 각각의 룩업 테이블을 접근하고, 상기 각각의 룩업 테이블 내의 상기 인덱스 위치에 저장된 데이터를 읽는 것을 특징으로 한다.
일 실시예에 따른 방법은, 상기 벡터 데이터에 소정의 벡터 연산이 수행된 결과 벡터 데이터를 엘리먼트 단위로 분리하여 상기 복수의 룩업 테이블로 저장한다.
일 실시예에 따른 상기 복수의 룩업 테이블로 저장하는 단계는, 상기 각각의 엘리먼트를 상기 각각의 룩업 테이블 내의 소정의 인덱스 위치에 저장하는 것을 특징으로 한다.
일 실시예에 따른 상기 복수의 룩업 테이블로 저장하는 단계는, 상기 복수의 룩업 테이블들 중 어느 하나의 룩업 테이블 내의 제1인덱스에 저장된 데이터의 값이 변경되면, 변경되지 않은 나머지 룩업 테이블의 상기 제1인덱스에 저장된 데이터를 상기 변경된 값으로 갱신하는 것을 특징으로 한다.
일 실시예에 따른 상기 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 단계는, 상기 각각의 룩업 테이블 내에서 접근이 허용된 소정의 인덱스 위치에 존재하는 데이터를 읽어 상기 벡터 데이터를 생성하고, 상기 복수의 룩업 테이블로 저장하는 단계는, 상기 결과 벡터 데이터를 상기 각각의 룩업 테이블 내에서 접근이 허용된 소정의 인덱스 위치에 저장하는 것을 특징으로 한다.
일 실시예에 따른 상기 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 단계 및 상기 복수의 룩업 테이블로 저장하는 단계는, 상기 각각의 뱅크에 대한 접근 가능 여부를 결정하는 단계를 포함한다.
일 실시예에 따른 상기 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록 매체가 제공된다.
이하에서는 도면을 참조하여 실시 예들을 상세히 설명한다. 본 명세서에 기재된 실시 예와 도면에 도시된 구성은 본 발명의 일 실시 예에 불과할 뿐이고, 본 발명의 기술적 사상을 모두 대변하는 것은 아니므로, 본 출원시점에 있어서 이들을 대체할 수 있는 다양한 균등물과 변형 예들이 있을 수 있음을 이해하여야 한다.
도1은 일 실시예에 따른 벡터 프로세서가 메모리로부터 데이터를 읽고 쓰는 구조도를 나타낸다.
메인 메모리(110)는 컴퓨터, TV, 휴대 전화, 모바일 장치 등을 구성하는 랜덤 억세스 메모리(Random Access Memory)일 수 있으나 이에 제한되지 않는다.
이하 '메인 메모리'라 함은, 소정의 기기(Machine)의 기억 장치를 구성하는 메모리의 전체 또는 일부 영역을 의미한다. 일 실시예에 따른 메인 메모리(110)는 메모리 충돌을 최소화시키기 위해 하나 이상의 메모리 뱅크(Memory Bank)(이하 '뱅크'라 한다)로 구성된 다중 뱅크 구조일 수 있다.
벡터 프로세서(180)는 복수의 데이터를 동시에 처리할 수 있는 프로세서로, 벡터 프로세서(180)내의 명령어는 SIMD(Single Instruction Multiple Data) 또는 MIMD(Multiple Instruction Multiple Data)형태로 처리될 수 있으나 이에 제한되지 않는다.
벡터 프로세서(180)는 메인 메모리(110)로부터 복수의 데이터를 읽어 복수의 데이터를 벡터 형태로 생성하여 벡터 연산을 수행하고, 벡터 연산이 수행된 결과를 다시 메인 메모리(110)에 저장할 수 있다. 벡터 프로세서(180)는 동시에 복수의 데이터를 읽거나 저장하기 위해 메인 메모리(110)내의 복수의 뱅크(120, 121, 122, 123, 124, 125, 126, 127)에 접근할 수 있다.
벡터 프로세서(180)는 벡터 레지스터(160)를 포함할 수 있다. 벡터 레지스터(160)는 벡터 연산을 구성하는 요소를 접근하기 위한 메모리의 주소를 저장할 수 있고, 벡터 명령에 의한 읽기 또는 쓰기가 가능한 레지스터이다.
벡터 레지스터(160)는 복수의 엘리먼트로 파티션되어 있을 수 있다. 예를 들어, 16바이트의 벡터 레지스터(160)가 8-way 벡터를 저장한다면, 벡터 레지스터(160)는 8개의 엘리먼트로 구성되며, 하나의 엘리먼트는 2바이트의 크기를 가질 수 있다.
도1에서는 도시되지 않았으나 벡터 프로세서(180)는 파이프라인 구조(pipelined architecture)를 가지고 매 클록(clock)마다 연산을 수행하는 벡터 기능부(Vector Functional Unit), 메모리에서 데이터를 읽고 저장하는 벡터 로드/스토어부(Vector Load/Store Unit), 메모리 주소 및 제어 신호를 저장하기 위한 스칼라 레지스터(Scalar Register), 레지스터를 연결하는 크로스바(Cross-bar)를 포함할 수 있다.
일 실시예에 따른 벡터 프로세서(180)는 메인 메모리(110)로부터 복수의 데이터를 읽거나 또는 메인 메모리(110)에 복수의 데이터를 쓰기 위해, 다양한 방법으로 메인 메모리(110)에 접근할 수 있다.
예를 들어, 벡터 프로세서(180)는 메모리 주소를 하나씩 증가시키면서 순차적으로 메인 메모리(110)로부터 복수의 데이터를 읽어와 벡터 형태로 생성할 수 있다. 벡터 프로세서(180)는 생성된 벡터를 이용하여 벡터 연산을 수행하고, 수행된 결과를 다시 순차적으로 메인 메모리(110)에 저장하는 단위 활보(Unit Stride) 기법을 이용할 수 있다.
또한 예를 들어, 벡터 프로세서(180)는 메모리 주소를 스칼라 레지스터(미도시)에 저장된 상수 값만큼 증가시키며 메인 메모리(110)로부터 복수의 데이터를 읽어와서 벡터 형태로 생성할 수 있다. 벡터 프로세서(180)는 생성된 벡터를 이용하여 벡터 연산을 수행하고 수행된 결과를 동일한 방법으로 상수 값만큼 증가시키며 메인 메모리(110)에 다시 저장하는 활보 접근(Stride Access) 기법을 이용할 수 있다.
또한 예를 들어, 벡터 프로세서(180)는 메인 메모리(110)로부터 데이터를 랜덤하게 읽고, 읽어온 복수의 데이터를 벡터 형태로 생성할 수 있다. 벡터 프로세서(180)는 생성된 벡터를 이용하여 벡터 연산을 수행하고 수행된 결과를 다시 랜덤하게 메인 메모리(110)에 저장하는 기법인 인덱스 로드/스토어(Indexed Load and Store) 기법을 사용할 수 있다. 인덱스 로드/스토어 방법은 인덱스 벡터를 사용하여 메인 메모리(110)에 흩어진 데이터를 읽어 벡터를 생성하고, 벡터 연산을 수행한 결과를 다시 메인 메모리(110)에 저장하는 기법이다.
일반적으로 인덱스 벡터를 사용하여 메인 메모리(110) 상에 흩어진 복수의 데이터를 읽는 것을 게더(Gather)라 하고, 인덱스 벡터를 사용하여 복수의 데이터(즉, 벡터)를 메인 메모리(110)에 흩어지게 저장하는 것을 스캐터(Scatter)라 한다.
일 실시예에 따른 벡터 프로세서(180)는 인덱스 벡터에 저장된 복수의 오프셋(offset)값을 베이스 주소(base address)와 합하여 계산된 각각의 메모리 주소에 있는 데이터들을 읽어와서 게더를 수행하고, 벡터 레지스터(160)에 벡터 형태로 저장할 수 있다.
예를 들어, 8-way 벡터 연산을 수행하는 벡터 프로세서(180)의 경우, 인덱스 벡터에는 8개의 인덱스, 즉 8개 각각의 데이터가 저장된 메모리의 상대 주소가 저장되어 있고, 이를 베이스 주소와 합하여 해당 주소의 데이터를 읽어올 수 있다. 읽어온 8개의 데이터는 벡터 레지스터(160)에 벡터 형태로 저장된다.
스캐터 연산은 게더 연산의 역과정이다. 벡터 레지스터(160)에 저장된 벡터를 8개의 엘리먼트로 분리하여 인덱스 벡터의 오프셋을 베이스 주소에 더한 각각의 메모리 주소에 각각 저장한다.
그러나 벡터 프로세서(180)가 게더 및 스캐터를 수행할 때 복수의 데이터를 동시에 읽거나 저장하게 되면 동일한 메모리 뱅크를 접근하는 경우가 빈번히 발생할 수 있다. 이 경우 메모리 뱅크 충돌(Memory Bank Conflict)의 발생으로 스톨(stall)을 야기하여 벡터 프로세서의 성능과 효율성이 크게 저하될 수 있다.
상술한 바와 같이, 벡터 프로세서(180)는 복수의 데이터를 메인 메모리(110)로부터 읽고, 복수의 데이터를 메인 메모리(110)에 저장하기 위해 메인 메모리(110)에 동시에 접근할 필요가 있다. 따라서, 벡터 프로세서(180)가 메인 메모리(110)에 동시 접근하기 위해서 메인 메모리(110)는 다중 메모리 뱅크 구조일 수 있으며, 벡터 프로세서(180)는 각 메모리 뱅크의 어드레스를 독립적으로 제어할 수 있는 메모리 시스템(미도시)을 추가적으로 필요로 할 수 있다.
도2는 일 실시예에 따른 벡터 프로세서가 게더 및 스캐터를 수행하는 방법을 나타낸다.
벡터 프로세서(180)는 메인 메모리(110)에 저장된 데이터 중 벡터 연산에 필요한 데이터를 복사하여 저장한 복수의 룩업 테이블(음영색 부분)(210, 220, 230, 240, 250, 260, 270, 280)을 생성할 수 있다. 메인 메모리(110)는 복수의 메모리 뱅크로 구성된 다중 뱅크 구조이다.
벡터 프로세서(180)는 생성된 룩업 테이블(210, 220, 230, 240, 250, 260, 270, 280)로부터 각각의 룩업 테이블의 소정의 인덱스 위치에 저장된 복수의 데이터를 게더하여 벡터 형태로 생성할 수 있다.
일 실시예에 따른 벡터 프로세서(180)는 각각의 룩업 테이블(210, 220, 230, 240, 250, 260, 270, 280)로부터 복수의 데이터(A, B, C, D, E, F, G, H)를 게더할 수 있다. 게더된 복수의 데이터(A, B, C, D, E, F, G, H)는 벡터 레지스터(160)에 벡터 형태로 저장되고, 벡터 레지스터(160)내의 벡터는 벡터 연산의 피연산자가 될 수 있다.
벡터 프로세서(180)는 벡터 레지스터(160)에 저장된 벡터를 엘리먼트 단위로 분리하여 각각의 룩업 테이블(210, 220, 230, 240, 250, 260, 270, 280)내의 소정의 인덱스 위치에 스캐터할 수 있다. 스캐터의 대상이 되는 벡터 레지스터(160)내의 벡터는, 게더하여 생성된 벡터 데이터에 소정의 벡터 연산을 수행하고, 연산이 수행된 결과 벡터 데이터일 수 있다.
상술한 바와 같이, 벡터 프로세서(180)가 메인 메모리(110)의 복수의 뱅크에 접근하여 게더 및 스캐터를 수행할 때 메모리 뱅크의 충돌이 발생한다면, 성능이 크게 저하된다. 이하, 일 실시예에 따른 벡터 프로세서(180)가 룩업 테이블을 이용하여 게더 및 스캐터를 수행하여 메모리 뱅크 충돌 횟수를 감소시키는 방법이 도3내지 도10을 참조하여 상세히 후술된다.
도3는 일 실시예에 따른 벡터 프로세서의 구조도를 나타낸다.
상술한 바와 같이 메인 메모리(110)는 다중 뱅크 구조일 수 있다. 설명의 편의를 위해 메인 메모리(110)는 8개의 뱅크(120, 121, 122, 123, 124, 125, 126, 127)로 구성되어 있으며, 벡터 프로세서(180)는 8-way 벡터 연산을 수행한다고 가정한다.
도3에서 벡터 프로세서(180)는 8-way 벡터 연산을 수행하고, 벡터 레지스터(160)가 8-way 벡터를 저장하는 것으로 도시하였으나, 이에 제한되지 않고 벡터 프로세서(180) 및 벡터 레지스터(160)는 n-way 벡터를 처리하고 저장할 수 있음은 자명하다.
일 실시예에 따른 벡터 프로세서(180)는 게더(Gather)부(320) 및 룩업 테이블 생성부(340)를 포함할 수 있다. 또한 벡터 프로세서(180)는 게더부(320) 및 룩업 테이블 생성부(340)를 포함하는 제어부(미도시)를 포함할 수 있다.
일 실시예에 따른 룩업 테이블 생성부(340)는 복수의 룩업 테이블을 생성할 수 있다. 룩업 테이블 생성부(340)는 메인 메모리(110) 내부의 뱅크(120, 121, 122, 123, 124, 125, 126, 127) 각각에 대해서 또는 소정의 개수의 뱅크를 하나의 그룹으로 묶은 다음 각각의 그룹 별로 하나의 룩업 테이블을 생성할 수 있다. 즉, 룩업 테이블 생성부(340)는 메인 메모리(110) 내부의 복수의 뱅크들을 N개의 그룹으로 나누어 그룹별로 하나의 룩업 테이블을 생성할 수 있다. N은 1보다 큰 정수이다.
룩업 테이블은 메인 메모리(110)에 존재하는 현재 수행하는 벡터 연산에 필요한 데이터를 복사하여 저장하고 있는 테이블을 말한다. 예를 들어, 8K의 UHD급의 영상을 화질 개선을 수행하고자 할 때, 이미지의 래스터(raster) 순서대로16x16 크기의 가우시안 필터를 적용할 수 있다. 16x16 크기의 가우시안 필터를 적용하기 위해 필요한 256개의 가우시안 계수는 메인 메모리(110)상에 흩어져서 저장되어 있을 수 있다. 일 실시예예 따른 룩업 테이블 생성부(340)는 화질 개선을 수행하기 전의 초기화 단계에서, 메인 메모리(110)상에서 흩어져서 존재하는 모든 가우시안 계수에 대한 데이터를 복사하여 저장하고 있는 룩업 테이블을 복수 개 생성할 수 있다.
일 실시예에 따른 룩업 테이블 생성부(340)는 도4에 도시된 바와 같이 8개의 뱅크(120, 121, 122, 123, 124, 125, 126, 127)에 대해 모두 동일한 룩업 테이블을 생성할 수 있다. 이 경우, 생성되는 룩업 테이블은 8개가 되며, 생성된 각각의 룩업 테이블은 8개의 뱅크(120, 121, 122, 123, 124, 125, 126, 127) 각각에 저장될 수 있다.
또한 일 실시예에 따른 룩업 테이블 생성부(340)는, 도5에 도시된 바와 같이 메인 메모리(110)를 제1그룹(뱅크0(120), 뱅크1(121)), 제2그룹(뱅크2(122), 뱅크3(123)), 제3그룹(뱅크4(124), 뱅크5(125)), 제4그룹(뱅크6(126), 뱅크7(127))으로 그룹핑하고 각각의 그룹에 대해 하나의 룩업 테이블을 생성할 수 있다. 이 경우, 생성되는 룩업 테이블은 4개가 되며, 생성된 4개의 룩업 테이블은 2개의 뱅크 상에 분리되어 저장될 수 있다.
또한 일 실시예에 따른 룩업 테이블 생성부(340)는, 메인 메모리(110)를 제1그룹(뱅크0(120), 뱅크1(121), 뱅크2(122), 뱅크3(123)), 제2그룹(뱅크4(124), 뱅크5(125), 뱅크6(126), 뱅크7(127))으로 그룹핑하고 각각의 그룹에 대해 룩업 테이블을 생성할 수 있다. 이 경우, 생성되는 룩업 테이블은 2개가 된다.
일 실시예에 따른 룩업 테이블 생성부(340)는 룩업 테이블을 저장하는 메인 메모리(110)상의 공간과 벡터 프로세서(180)가 룩업 테이블을 접근함으로서 발생하는 메모리 충돌 횟수를 고려하여, 생성할 룩업 테이블의 개수를 결정할 수 있다. 즉, 각각의 룩업 테이블은 메인 메모리(110)상의 저장 공간이 필요하고 생성된 룩업 테이블의 개수가 많아질수록 뱅크에서 발생하는 충돌 횟수는 감소하므로 룩업 테이블의 개수와 메모리 뱅크 충돌은 상충 관계(Trade off)가 존재한다.
다시 말하면, 룩업 테이블 생성부(340)가 뱅크(120, 121, 122, 123, 124, 125, 126, 127)의 개수만큼 룩업 테이블을 생성하고, 게더부(320)가 뱅크의 개수와 동일한 엘리먼트 개수로 구성된 벡터를 생성하는 경우 복수 개의 데이터를 동시에 랜덤하게 읽어도 하나의 메모리 뱅크에는 하나의 접근만 수행된다. 이 경우 메모리 뱅크 충돌은 발생하지 않지만 룩업 테이블들을 저장하는 공간이 최대가 된다. 그러나, 소정의 개수의 뱅크 별로 룩업 테이블을 하나씩 생성한다면 메모리 뱅크 충돌 횟수는 증가하나 룩업 테이블을 저장하는 공간은 감소할 수 있다.
룩업 테이블 생성부(340)는 벡터 프로세서(180)의 성능을 중요시 한다면 룩업 테이블을 최대로(즉, 뱅크별로) 생성할 수도 있고, 룩업 테이블이 저장될 저장 공간을 고려하여 소정의 개수의 뱅크를 하나의 그룹으로 묶어 각각의 그룹에 대해 하나의 룩업 테이블을 생성할 수 있다. 룩업 테이블 생성부(340)는 소정의 개수의 뱅크를 하나의 그룹으로 묶어 각각의 그룹에 대해 룩업 테이블을 생성하는 경우에, 각각의 룩업 테이블은 인터리빙(interleaving) 형태로 복수의 메모리 뱅크에 저장될 수 있다. 이는 도5을 참조하여 상세히 후술한다.
게더(Gather)부(320)는 룩업 테이블을 이용하여, 메인 메모리(110)로부터 복수의 데이터를 읽을 수 있다. 복수의 데이터는 벡터 레지스터(160)에 벡터 형태로 저장될 수 있다. 게더부(320)는 복수의 룩업 테이블 별로 접근할 때 랜덤하게 생성된 복수의 인덱스로 구성된 인덱스 벡터를 이용하여 메인 메모리(110)상에 존재하는 각각의 룩업 테이블의 인덱스 위치에 접근할 수 있다.
예를 들어, 게더부(320)는 8개의 인덱스로 구성된 벡터를 인덱스 벡터를 이용하여8-way 벡터를 생성할 수 있다. 보다 구체적으로, 게더부(320)는 인덱스 벡터에 저장된 각각의 오프셋을 베이스 주소와 합한 메모리 주소(address)를 이용하여 각각의 룩업 테이블의 소정의 인덱스 위치에 접근하여 데이터를 읽을 수 있다.
게더부(320)는 복수의 룩업 테이블로부터 데이터를 읽음으로서, 일정한 읽기 사이클(Reading Cycle) 후에 벡터를 구성하는 모든 데이터를 게더하여 벡터 데이터를 생성할 수 있다.
도4는 일 실시예에 따른 메인 메모리 상에 생성된 복수개의 룩업 테이블을 나타낸다.
일 실시예에 따른 메인 메모리(110)의 크기는 512KB(0x800x_0000 부터 0x800x_FFFF 까지)이고 각각의 뱅크(120, 121, 122, 123, 124, 125, 126, 127)들은 64KB 의 크기이다. 도4의 각 뱅크(120, 121, 122, 123, 124, 125, 126, 127)의 상단에 기재된 0x8000x~0x807x 는 각 뱅크의 메모리 시작 주소이다.
상술한 바와 같이 룩업 테이블은 8개의 뱅크 각각에 대해 또는 소정의 개수의 뱅크들을 하나의 그룹으로 묶고 각각의 그룹에 대해서 생성될 수 있다. 복수의 룩업 테이블은 룩업 테이블 생성부(340)에 의해 생성될 수 있다.
도4는 8개의 뱅크 각각에 대해 룩업 테이블이 생성되는 경우를 도시하며, 도5는 2개의 뱅크별로 하나의 룩업 테이블이 생성되는 경우를 도시한다.
도4는 8개의 뱅크들 중 뱅크 0(120), 뱅크3(123), 뱅크 7(127)에 대한 룩업 테이블(410, 415, 420)만 도시하였으며 나머지 룩업 테이블들은 생략하여 도시하였다. 또한 설명의 편의를 위해 각각의 룩업 테이블(410, 415, 420)내의 데이터는 각 인덱스와 동일한 값을 가지는 것으로 도시하였다.
일 실시예에 따른 룩업 테이블 생성부(340)는 룩업 테이블들을 2차원 배열 형태로 생성할 수 있다. 즉, 생성된 룩업 테이블의 개수를 I 라고 하고, 벡터 연산에 필요한 데이터의 개수를 J 라고 할 때, 룩업 테이블은I x J 의 2차원 배열로 생성될 수 있다. 각각의 룩업 테이블은 상위 주소를 달리하여 구별될 수 있다.
2차원 배열은 벡터 프로세서(180)가 벡터 연산을 수행하기 전에 초기화 단계에서 생성될 수 있다. 도4에서 뱅크는 8개(120, 121, 122, 123, 124, 125, 126, 127)이고 뱅크 각각에 대해 모두 룩업 테이블이 생성되었으므로, 생성된 룩업 테이블은 8개이고 각각의 룩업 테이블은 256개의 데이터를 포함하고 있으므로 8 x 256 크기의 2차원 배열이 선언될 수 있다.
일 실시예에 따른 벡터 프로세서(180)는 아래 표1과 같은 소프트웨어 코드를 이용하여, 게더를 수행할 수 있다. 표1의 소프트웨어 코드는 게더를 수행하는 일 실시예일 뿐이며 다른 형태로 구현될 수 있음은 자명하다.
표 1
ushort8 _I_intr_gather8_uh(ushort8 _I_src1, uchar** _I_src2){　　ushort8 ret;　　 ret = (ushort8)(0, 0, 0, 0, 0, 0, 0, 0);　　　　 ret.s0 = _I_src2[0][_I_src1.s0];　　 ret.s1 = _I_src2[1][_I_src1.s1];　　 ret.s2 = _I_src2[2][_I_src1.s2];　　 ret.s3 = _I_src2[3][_I_src1.s3];　　 ret.s4 = _I_src2[4][_I_src1.s4];　　 ret.s5 = _I_src2[5][_I_src1.s5];　　 ret.s6 = _I_src2[6][_I_src1.s6];　　 ret.s7 = _I_src2[7][_I_src1.s7];　　　　 return ret;}
표1의 코드를 참조하면, "ret"는 게더 연산을 수행하여 생성된 벡터이다. "ret" 벡터는 unsigned short 형의 데이터로 구성된 8-way 벡터이다. 즉, 표1에 기재된 "I_intr_gather8_uh" 함수는 8개의 인덱스를 사용하여 8개의 뱅크로부터 데이터를 읽어와 벡터를 생성할 수 있다.
"I_src1" 는 unsigned short 타입의 데이터로 구성된 8개의 인덱스를 포함하는 8-way 인덱스 벡터이다. "I_src1.s0, _I_src1.s1, ... , _I_src1.s7" 은 각각의 룩업 테이블로부터 읽어올 데이터가 존재하는 인덱스 위치이며 랜덤하게 생성된 인덱스일 수 있다.
"I_src2"는 unsigned character형의 2차원 배열로 선언된 룩업 테이블이다. 각각의 룩업 테이블(_I_src2[0 : 7])은 하나의 접근만 수행된다. 예를 들어, _I_src2[0]의 룩업 테이블로부터는 _I_src1.s0의 인덱스를 이용하여 데이터를 읽고 _I_src2[1]의 룩업 테이블로부터는 _I_src1.s1의 인덱스를 이용하여 데이터를 읽을 수 있다. 즉, 각각의 룩업 테이블 별로 인덱스를 달리하여 데이터를 읽을 수 있다. 즉, 랜덤하게 생성된 인덱스 벡터를 사용하여 메인 메모리(110)로부터 복수의 데이터를 읽어도 8개의 데이터 각각이 서로 다른 뱅크로부터 독출되므로 메모리 뱅크 충돌은 발생하지 않는다.
도5는 일 실시예에 따른 메인 메모리 상에 생성된 복수개의 룩업 테이블을 나타낸다.
즉, 뱅크0(120)과 뱅크1(121)에 대한 룩업 테이블(530)을 생성하고, 뱅크2(122)와 뱅크3(123)에 대한 룩업 테이블(540)을 생성하고, 뱅크4(124)와 뱅크5(125)에 대한 룩업 테이블(550)을 생성하고, 뱅크6(126)과 뱅크7(127)에 대한 룩업 테이블(560)을 생성할 수 있다.
생성된 4개의 룩업 테이블 각각은 2개의 뱅크에 분리되어 저장된다. 예를 들어, 룩업 테이블(350)은 뱅크0(120)과 뱅크1(121)상에 분리되어 저장되고, 룩업 테이블(360)은 뱅크4(124)와 뱅크5(125)상에 분리되어 저장될 수 있다.
일 실시예에 따른 룩업 테이블은 복수의 뱅크에 인터리빙(interleaving, 510)형태로 저장될 수 있다. 즉, 인접한 메모리에 위치한 데이터를 서로 다른 두 개의 뱅크에 번갈아가면서 저장함으로서, 메모리 뱅크 충돌을 최소화할 수 있다. 예를 들어, 뱅크0(120)에는 {0,2,4, ..., 252, 254}의 인덱스의 데이터를 저장하고 뱅크1(121)에는 {1,3,5, ..., 253, 255}의 인덱스를 저장할 수 있다.
일 실시예에 따른 벡터 프로세서(180)는 아래 표2과 같은 소프트웨어 코드를 이용하여, 게더 연산을 수행할 수 있다. 표2의 소프트웨어 코드는 게더 연산을 수행하는 일 실시예일 뿐이며 다른 형태로 구현될 수 있음은 자명하다.
표 2
ushort8 _I_intr_gather8_uh(ushort8 _I_src1, uchar** _I_src2){ ushort8 ret; ret = (ushort8)(0, 0, 0, 0, 0, 0, 0, 0); ret.s0 = _I_src2[0][_I_src1.s0]; ret.s1 = _I_src2[0][_I_src1.s1]; ret.s2 = _I_src2[1][_I_src1.s2]; ret.s3 = _I_src2[1][_I_src1.s3]; ret.s4 = _I_src2[2][_I_src1.s4]; ret.s5 = _I_src2[2][_I_src1.s5]; ret.s6 = _I_src2[3][_I_src1.s6]; ret.s7 = _I_src2[3][_I_src1.s7]; return ret;}
표2의 코드에서, 변수에 대한 설명은 표1에서와 동일하므로 생략한다. 표1과 다른 점은, 최종적으로 반환되는 벡터 "ret"를 구성하는 8개의 엘리먼트들 중 두 개의 엘리먼트씩 같은 룩업 테이블을 참조하여 생성된다는 것이다. 예를 들어, "ret"의 첫 번째와 두 번째 엘리먼트는 룩업 테이블(530)을 참조하여 읽어온 데이터이고, 세 번째와 네 번째 엘리먼트는 룩업 테이블(540)을 참조하여 읽어온 데이터이다.
생성되는 룩업 테이블의 개수를 감소시킨다면 복수의 엘리먼트가 하나의 룩업 테이블을 참조하게 되므로 메모리 뱅크 충돌 횟수는 증가하지만, 상술한 바와 같이, 복수의 뱅크에 존재하는 하나의 룩업 테이블을 인터리빙 형태로 구현한다면, 메모리 충돌 횟수를 최소화할 수 있다.
도5에서 도시된 바와 같이, 뱅크0(120), 뱅크2(122), 뱅크4(124), 뱅크6(126)에는 짝수 인덱스의 데이터를 저장하고, 뱅크1(121), 뱅크3(123), 뱅크5(125), 뱅크7(127)에는 홀수 인덱스의 데이터를 저장하는 인터리빙(510) 형태로 룩업 테이블이 구현되어 있고, 호출하는 인덱스 벡터가 {짝수, 홀수, 짝수, 홀수, 짝수, 홀수, 짝수, 홀수}로 구성되어 있는 8-way 벡터인 경우 메모리 뱅크 충돌은 발생하지 않는다.
도6a은 일 실시예에 따른 벡터 프로세서의 구조도를 나타낸다.
일 실시예에 따른 벡터 프로세서(180)는 게더(Gather)부(320), 룩업 테이블 생성부(340) 및 스캐터(Scatter)부(630)를 포함할 수 있다. 게더부(320)와 룩업 테이블 생성부(340)는 도3을 참조하여 상술하였으므로 생략한다.
스캐터부(630)는 게더부(320)에서 수행되는 과정의 역과정에 해당한다. 따라서, 이하 생략된 내용이라 하더라도 도 2내지 도5에서 게더부(320) 및 룩업 테이블 생성부(340)에 관하여 기술된 내용은 도6의 실시 예에 따른 스캐터부(630)에도 동일하게 적용된다.
스캐터부(630)는 벡터 레지스터(160)에 저장된 벡터 데이터를 엘리먼트 단위로 분리하여 다시 복수의 룩업 테이블에 저장할 수 있다. 벡터 레지스터(160)에는 게더부(320)가 생성한 벡터 데이터에 소정의 벡터 연산이 수행된 결과 벡터 데이터가 저장되어 있을 수 있다.
일 실시예에 따른 스캐터부(630)는 아래 표3과 같은 소프트웨어 코드를 이용하여, 스캐터를 수행할 수 있다. 표3의 소프트웨어 코드는 스캐터를 수행하는 일 실시예일 뿐이며 다른 형태로 구현될 수 있음은 자명하다.
표 3
void _I_intr_scatter8_uh(ushort8 _I_src1, ushort** _I_src2, ushort8 _I_src3){　　　　　　　　　　　_I_src2[0][_I_src1.s0] = _I_src3.s0;　　　　　　　　　　　_I_src2[1][_I_src1.s1] = _I_src3.s1;　　　　　　　　　　　_I_src2[2][_I_src1.s2] = _I_src3.s2;　　　　　　　　　　　_I_src2[3][_I_src1.s3] = _I_src3.s3;　　　　　　　　　　　_I_src2[4][_I_src1.s4] = _I_src3.s4;　　　　　　　　　　　_I_src2[5][_I_src1.s5] = _I_src3.s5;　　　　　　　　　　　_I_src2[6][_I_src1.s6] = _I_src3.s6;　　　　　　　　　　　_I_src2[7][_I_src1.s7] = _I_src3.s7;}
표3의 코드를 참조하면, "_intr_scatter8_uh" 함수는 벡터 레지스터(160)에 저장된 벡터(8-way vector)를 엘리먼트 단위로 분리하여 뱅크 별로 생성된 룩업 테이블의 소정의 위치에 저장할 수 있다. "I_src3"는 벡터 레지스터(160)에 저장되어 있는 벡터로서 벡터 연산이 수행된 결과 벡터를 저장하고 있을 수 있다. "I_src3"는 unsigned integer 형의 데이터로 구성된 8-way 벡터이다.
"I_src1"는 unsigned short 형의 데이터로 구성된 8-way 인덱스 벡터이다. 예를 들어, "_intr_scatter8_uh" 함수는 _I_src3.s3을 룩업 테이블 _I_src2[3]의 _I_src1.s3 의 위치에 저장할 수 있다.
도6b은 일 실시예에 따른 벡터 프로세서가 복수의 룩업 테이블을 동기화시키는 방법을 나타낸다.
상술한 바와 같이, 초기화 단계에서 룩업 테이블 생성부(340)는 동일한 복수개의 룩업 테이블을 생성하므로, 복수의 룩업 테이블의 데이터는 서로 동기화될 수 있다. 즉, 스캐터부(630)는 게더부(320)와 달리, 각각의 룩업 테이블의 소정의 인덱스 위치에 저장된 값을 변경하고, 다른 룩업 테이블의 동일한 인덱스 위치에도 변경된 값으로 동일하게 갱신할 수 있다. 이러한 룩업 테이블 간의 동기화는 도7을 참조하여 후술할 스위칭부(745)에 의해 구현될 수 있다.
다시 말하면, 스캐터부(630)는 벡터 레지스터(160)에 저장된 벡터의 엘리먼트 값이 변경되어 특정 룩업 테이블의 특정 인덱스에 저장된 값을 갱신한다면, 나머지 룩업 테이블에 대한 특정 인덱스에 저장된 데이터 역시 동일하게 갱신할 수 있다.
예를 들어, 벡터 연산이 수행된 후 뱅크0(120)의 12번째 인덱스(620)의 값이 X로 변경되었다면, 나머지 뱅크들(120, 121, 123, 124, 125, 126, 127)의 12번째 인덱스 위치의 값도 동일하게 X로 갱신할 수 있다.
그러나 스캐터부(630)는 모든 경우에 반드시 모든 룩업 테이블의 값을 동일하게 변경할 필요는 없으며, 도8내지 10을 참조하여 후술할 스위칭부(745)를 이용하여 선택적으로 스캐터 연산을 수행할 수 있다.
도7은 일 실시예에 따른 벡터 프로세서의 구조도를 나타낸다.
일 실시예에 따른 벡터 프로세서는 게더(Gather)부(320), 스캐터(Scatter)부(630), 스위칭부(745), 룩업 테이블 생성부(340)를 포함할 수 있다.
스위칭부(745)는 게더부(320) 및 스캐터부(630)의 각 뱅크에 대한 접근을 제어하여, 각각의 룩업 테이블의 소정의 인덱스 위치에 대해 게더 및 스캐터를 수행할지 여부를 결정할 수 있다. 스위칭부(745)는 각각의 룩업 테이블에 대응되는 서브 스위치부(미도시)를 포함할 수 있으며, 서브 스위치부는 게더부(320) 및 스캐터부(630)가 룩업 테이블이 존재하는 뱅크들 내의 소정의 인덱스 위치에 접근하는 것을 허용할지 여부를 결정할 수 있다.
각각의 서브 스위치부는 복수의 룩업 테이블이 존재하는 각 뱅크들에 대한 온(On)/오프(Off) 스위치를 가질 수 있다. 즉, 각각의 서브 스위치부는 뱅크들의 개수와 동일한 개수의 스위치를 포함하고 각 스위치는 각각의 뱅크에 대한 게더부(320) 및 스캐터부(630)의 접근 가능 여부를 결정할 수 있다.
서브 스위치부가 특정 뱅크에 대한 스위치를 오프(Off)시켰다면, 게더부(320)는 오프 상태의 뱅크로부터 데이터를 읽을 수 없고, 스캐터부(630) 역시 오프 상태의 뱅크에 데이터를 저장할 수 없다. 또한, 특정 뱅크에 대한 스위치가 온(On)되었다면, 게더부(320) 및 스캐터부(630)은 온-상태의 뱅크의 소정의 인덱스 위치에 대해 각각 게더와 스캐터를 수행할 수 있다.
예를 들어, 메인 메모리(110)에 8개의 뱅크가 존재하고, 뱅크 당 한 개의 룩업 테이블이 생성되어8개의 룩업 테이블이 존재하는 경우, 스위칭부(745)는 8개의 서브 스위치부를 포함할 수 있고, 각각의 서브 스위치부는 뱅크의 개수와 동일한 서브 스위치부를 포함할 수 있다. 벡터 프로세서(180)는 복수개의 동일한 룩업 테이블을 동기화시킬 필요가 있는 경우, 스위칭부(745)내의 각각의 서브 스위치부의 스위치를 적절하게 온(On)상태로 만들어 스캐터를 수행할 수 있다. 이는 도9를 참조하여 후술한다.
또한, 벡터 프로세서(180)가 각각의 룩업 테이블로부터 한 개 또는 두 개의 데이터를 게더하여 벡터 형태로 생성하는 경우, 스위칭부(745)내의 각각의 서브 스위치부 내의 한 개 또는 두 개의 스위치만 온(On)상태로 설정하여 게더를 수행할 수 있다. 이는 도8을 참조하여 후술한다.
도8a 는 일 실시예에 따른 벡터 프로세서가 게더를 수행하는 방법을 나타낸다.
설명의 편의를 위해, 벡터 연산에 필요한 데이터의 개수는 8개이고, 각각의 룩업 테이블은 두 개의 뱅크에 인터리빙 형태로 저장되어 있다고 가정한다. 예를 들어, 룩업 테이블(850)은 뱅크0(120)과 뱅크1(121)에 인터리빙 형태로 저장되었다. 게더부(320)는 룩업 테이블 별로 두 개의 데이터를 게더하여 8-way 벡터를 생성할 수 있다.
스위칭부(745)는 각각의 룩업 테이블과 대응되는 4개의 서브 스위치부(810, 820, 830, 840)를 포함할 수 있다. 각각의 서브 스위치부(810, 820, 830, 840) 내에는 뱅크(120, 121, 122, 123, 124, 125, 126, 127)의 개수와 동일한8개의 스위치를 포함할 수 있다. 각각의 서브 스위치부(810, 820, 830, 840) 내의 가장 좌측 상단의 스위치는 각 뱅크0(120)에 대한 접근을 제어하고, 가장 우측 하단의 스위치는 뱅크7(127)에 대한 접근을 제어할 수 있다.
서브 스위치부(810, 820, 830, 840)내의 스위치 중 온(On)상태로 설정된 스위치는 음영 처리하여 도시되었다. 이하, 서브 스위치부 내에서 가장 좌측 상단을 첫 번째 스위치라고 지칭하고 왼쪽에서 오른쪽의 순서로, 그 다음은 위에서 아래의 순서로 스위치에 순번을 매긴다. 즉, 서브 스위치부(810, 820, 830, 840)내의 가장 우측 하단의 스위치는 여덟 번째 스위치이다.
일 실시예에 따른 게더부(320)는 첫 번째, 두 번째 스위치가 온(On)되어 있는 서브 스위치부(810)를 이용하여, 뱅크0(120)과 뱅크1(121)에 저장되어 있는 룩업 테이블(850)의 인덱스0과 5의 데이터를 읽을 수 있다. 또 예를 들어, 게더부(320)는 다섯 번째, 여섯 번째 스위치가 온(On)되어 있는 서브 스위치부(830)를 이용하여, 뱅크4(124)와 뱅크5(125)에 저장되어 있는 룩업 테이블(870)의 인덱스4와 1의 데이터를 읽을 수 있다.
도8b 는 일 실시예에 따른 벡터 프로세서가 게더를 수행하는 방법을 나타낸다.
도8b는 룩업 테이블이 뱅크 별(120, 121, 122, 123, 124, 125, 126, 127)로 하나씩 생성된 경우를 도시한다. 스위칭부(745)는 각각의 룩업 테이블에 대응되는 8개의 서브 스위치부(815, 825, 835, 845, 855, 865, 875, 885)를 포함할 수 있다. 각각의 서브 스위치부(815, 825, 835, 845, 855, 865, 875, 885) 내에는 뱅크의 개수와 동일한 8개의 스위치를 포함할 수 있다.
일 실시예에 따른 벡터 프로세서(180)는 각각의 서브 스위치부(815, 825, 835, 845, 855, 865, 875, 885)에 포함된 8개의 스위치 중 하나의 스위치만 온 상태로 설정하여, 각 룩업 테이블(818, 828, 838, 848, 858, 868, 878, 888)로부터 소정의 인덱스 위치에 존재하는 한 개의 데이터를 읽을 수 있다.
예를 들어, 게더부(320)는 첫 번째 스위치가 온(On)되어 있는 서브 스위치부(815)를 이용하여, 뱅크0(120)에 저장된 룩업 테이블(818)의 인덱스0에 저장되어 있는 데이터를 읽고, 여섯 번째 스위치가 온(On)되어 있는 서브 스위치부(865)를 이용하여, 뱅크5(125)에 저장된 룩업 테이블(868)의 인덱스7에 저장되어 있는 데이터를 읽을 수 있다.
도9 는 일 실시예에 따른 벡터 프로세서가 스캐터를 수행하는 방법을 나타낸다.
설명의 편의를 위해, 하나의 룩업 테이블은 4개의 데이터를 저장하고 있으며, 두 개의 뱅크에 인터리빙 형태로 저장되어 있다고 가정한다. 예를 들어, 룩업 테이블(950)은 뱅크0(120)과 뱅크1(121)에 인터리빙 형태로 저장되었다. 즉, 각 룩업 테이블의 인덱스 0, 2 는 짝수 번째 뱅크(120, 122, 124, 126)에 존재하며, 인덱스 1, 3은 홀수 번째 뱅크(121, 123, 125, 127)에 존재한다.
일 실시예에 따른 스캐터부(630)은 벡터 레지스터(160)에 저장된 벡터를 엘리먼트 단위로 분리하여 룩업 테이블 (950, 960, 970, 980)로 흩어지게 저장할 수 있다.
예를 들어, 기존에 벡터 레지스터(160)에 저장되어 있었던 벡터가 4-way 벡터이고, 벡터 연산이 수행된 후 벡터의 모든 엘리먼트가 갱신되었다고 가정한다. 스캐터부(630)는 4-way의 벡터의 첫 번째 엘리먼트를 룩업 테이블(950)로 저장하고, 두 번째 엘리먼트를 룩업 테이블(960)로 저장하고, 세 번째 엘리먼트를 룩업 테이블(970)로 저장하고, 네 번째 엘리먼트를 룩업 테이블(980)로 저장할 수 있다. 즉, 4개의 엘리먼트는 각각의 룩업 테이블(950, 960, 970, 980)내의 서로 다른 인덱스에 흩어지게 저장될 수 있다.
그러나 상술한 바와 같이, 복수의 룩업 테이블은 동기화가 필요할 수 있다. 벡터 프로세서(180)는 각각의 서브 스위치부(910, 920, 930, 940)에 존재하는 8개의 스위치를 적절하게 온(On) 상태로 설정하여, 각각의 룩업 테이블 내의 모든 인덱스 위치에 대해 스캐터를 수행할 수 있다.
즉, 서브 스위치부(910)의 첫 번째, 세 번째, 다섯 번째, 일곱 번째 스위치를 온(On)하여 각 룩업 테이블(950, 960, 970, 980)의 인덱스 2에 데이터를 저장할 수 있다.
또한, 서브 스위치부(920)의 두 번째, 네 번째, 여섯 번째, 여덟 번째 스위치를 온(On)하여 각 룩업 테이블(950, 960, 970, 980)의 인덱스3에 데이터를 저장할 수 있다.
또한, 서브 스위치부(930)의 첫 번째, 세 번째, 다섯 번째, 일곱 번째 스위치를 온(On)하여 각 룩업 테이블(950, 960, 970, 980)의 인덱스 0에 데이터를 저장할 수 있다.
또한, 서브 스위치부(940)의 두 번째, 네 번째, 여섯 번째, 여덟 번째 스위치를 온(On)하여 각 룩업 테이블(950, 960, 970, 980)의 인덱스1에 데이터를 저장할 수 있다.
결과적으로 각각의 룩업 테이블(950, 960, 970, 980)내의 인덱스0부터 3까지 저장된 모든 데이터가 갱신될 수 있다.
룩업 테이블의 동기화가 필요 없는 경우, 벡터 프로세서(180)는 각각의 서브 스위치부(910, 920, 930, 940)중 일부의 스위치만 온(On) 상태로 설정하여 스캐터를 수행할 수 있음은 자명하다. 예를 들어, 도9에는 도시되지 않았지만, 서브 스위치부(910)의 첫 번째 스위치만을 온(On)하여 뱅크0(120)에 저장된 룩업 테이블(950)의 인덱스2의 위치에 데이터를 저장할 수 있다. 또한, 서브 스위치부(920)의 네 번째 스위치만을 온(On)하여 뱅크3(123)에 저장된 룩업 테이블(960)의 인덱스3의 위치에 데이터를 저장할 수 있다. 또한, 서브 스위치부(930)의 다섯 번째 스위치만을 온(On)하여 뱅크4(124)에 저장된 룩업 테이블(970)의 인덱스0의 위치에 데이터를 저장할 수 있다. 또한, 서브 스위치부(940)의 여덟 번째 스위치만을 온(On)하여 뱅크7(127)에 저장된 룩업 테이블(980)의 인덱스1의 위치에 데이터를 저장할 수 있다.
일 실시예에 따른 게더(Gather)부(320), 스캐터(Scatter)부(630), 스위칭부(745), 룩업 테이블 생성부(340)는 벡터 프로세서(180)의 구조를 변경하지 않고, 룩업 테이블의 생성 및 벡터 프로세서의 로드와 스토어 연산만을 확장하여 구현될 수 있다. 따라서, 벡터 프로세서(180)의 ISA(Instruction set architecture)를 변경하지 않는 인트린직(Intrinsic)형태로 구현되어 벡터 프로세서(180)의 구조 수정 또는 추가적인 하드웨어 없이 구현할 수 있다.
이하 일 실시예에 따른 벡터 프로세서(180)가 메모리에 접근하여 데이터를 게더 및 스캐터를 수행하는 방법이 도10 내지 13 의 흐름도를 참조하여 후술된다. 도10내지 13는 도1내지9에서 도시된 벡터 프로세서(180)에서 수행되는 게더 및 스캐터를 수행하는 방법을 설명하기 위한 도면이다. 따라서, 이하 생략된 내용이라 하더라도 도1내지9에서 벡터 프로세서(180)에 관하여 이상에서 기술된 내용은 도10내지 13의 일 실시 예에 따른 게더 및 스캐터 방법에도 적용된다.
도 10은 일 실시예에 따른 벡터 프로세서가 게더를 수행하는 방법의 흐름도를 도시한다.
단계 1020에서, 벡터 프로세서(180)는 메인 메모리에 대해 복수의 룩업 테이블을 생성할 수 있다. 룩업 테이블은 메인 메모리에 저장된 데이터 중 현재 수행하는 벡터 연산에 필요한 데이터를 복사하여 저장하고 있는 테이블을 말한다. 메인 메모리는 다중 뱅크구조일 수 있다. 생성된 룩업 테이블은 각각의 뱅크 또는 복수의 뱅크의 뱅크에 분리되어 저장될 수 있다.
단계 1030에서, 벡터 프로세서(180)는 룩업 테이블로부터 복수의 데이터를 읽어 벡터 데이터를 생성하는 게더(Gather)를 수행할 수 있다. 보다 구체적으로, 일 실시예에 따른 벡터 프로세서(180)는 생성된 룩업 테이블을 이용하여, 메인 메모리로부터 복수의 데이터를 읽어와 벡터 레지스터에 벡터 형태로 저장하는 게더 연산을 수행할 수 있다.
단계 1030에서, 벡터 프로세서(180)는 랜덤하게 생성된 복수의 인덱스로 구성된 인덱스 벡터를 이용하여 메인 메모리 상에 존재하는 각각의 룩업 테이블의 인덱스 위치에 접근하여 데이터를 읽을 수 있다.
도 11는 일 실시예에 따른 벡터 프로세서가 복수의 룩업 테이블을 생성하는 방법의 흐름도를 도시한다.
단계 1110에서, 벡터 프로세서(180)는 생성할 룩업 테이블의 개수를 결정할 수 있다. 일 실시예에 따른 벡터 프로세서(180)는 룩업 테이블을 저장하는 메인 메모리상의 공간과 벡터 프로세서가 룩업 테이블을 접근함으로서 발생하는 메모리 충돌 횟수의 상충 관계(Trade off)를 고려하여, 생성할 룩업 테이블의 개수를 결정할 수 있다.
단계 1120에서, 벡터 프로세서(180)는 메모리 뱅크의 개수와 동일한 개수의 룩업 테이블을 생성할 것인지 판단하여, 생성하는 룩업 테이블의 개수가 뱅크의 개수와 동일하다면 단계 1140으로 넘어가고 그렇지 않으면 단계 1130으로 넘어간다.
단계 1130에서, 벡터 프로세서(180)는 생성된 룩업 테이블 각각을 복수의 뱅크에 분리하여 저장할 수 있다. 일 실시예에 따른 벡터 프로세서(180)는 룩업 테이블 각각을 복수의 뱅크에 인터리빙 형태로 분리하여 저장할 수 있다. 즉, 복수의 데이터를 서로 다른 뱅크에 번갈아가면서 저장함으로서 메모리 뱅크 충돌을 최소화할 수 있다.
단계 1140에서, 벡터 프로세서(180)는 뱅크 별로 하나의 룩업 테이블을 생성할 수 있다. 각각의 룩업 테이블은 각각의 뱅크 내에 저장된다.
도 12 는 일 실시예에 따른 벡터 프로세서가 스캐터를 수행하는 방법의 흐름도를 도시한다.
단계 1020 과 단계 1030은 도10를 참조하여 상술하였으므로 생략한다.
일 실시예에 따른 벡터 프로세서(180)는 벡터 데이터를 룩업 테이블로 흩어지게 저장하는 스캐터(Scatter)를 수행할 수 있다.
단계 1230 에서, 일 실시예에 따른 벡터 프로세서(180)는 벡터 레지스터에 저장된 벡터를 엘리먼트 단위로 분리하여 다시 룩업 테이블에 저장할 수 있다. 벡터 레지스터에 저장된 벡터는 단계 1030에서 생성된 벡터에 벡터 연산을 수행하고, 연산이 수행된 결과 벡터 데이터가 저장되어 있으며, 단계 1230에서 결과 벡터 데이터를 다시 복수의 룩업 테이블로 저장할 수 있다.
단계 1230에서, 일 실시예에 따른 벡터 프로세서(180)는 룩업 테이블 간의 동기화를 위해, 특정 룩업 테이블의 특정 인덱스에 저장된 값을 갱신하면, 나머지 룩업 테이블에 대한 특정 인덱스에 저장된 데이터 역시 동일하게 갱신할 수 있다.
도 13은 일 실시예에 따른 벡터 프로세서가 게더 및 스캐터를 수행하는 방법의 흐름도를 도시한다.
단계 1020, 단계 1030, 단계 1230은 도 10 및 도12를 참조하여 상술하였으므로 생략한다.
일 실시예에 따른 벡터 프로세서(180)는 게더를 수행(단계 1030)하거나 스캐터를 수행(단계 1230)하기 전에, 단계 1310에서 각 룩업 테이블의 소정의 인덱스 위치에 대해 접근 허용 여부를 결정할 수 있다. 즉, 벡터 프로세서(180)는 각각의 룩업 테이블이 저장된 각 뱅크에 대해 접근 가능 여부를 결정함으로서, 게더(단계 1030) 또는 스캐터(단계 1230)를 수행할 대상이 되는 룩업 테이블의 인덱스 위치를 결정할 수 있다.
단계 1030에서, 각각의 룩업 테이블 내에서 접근이 허용된 소정의 인덱스 위치에 존재하는 데이터를 읽어 벡터 데이터를 생성할 수 있다. 일 실시예에 따른 벡터 프로세서(180)는 접근이 가능한 뱅크에 존재하는 룩업 테이블로부터 소정의 위치에 저장된 데이터를 읽어 벡터 데이터를 생성할 수 있다.
단계 1230에서, 벡터 데이터를 각각의 룩업 테이블 내에서 접근이 허용된 소정의 인덱스 위치에 저장할 수 있다. 일 실시예에 따른 벡터 프로세서(180)는 접근이 가능한 뱅크에 존재하는 룩업 테이블로 소정의 위치에 데이터를 저장할 수 있다.
일 실시예에 따른 벡터 프로세서(180)는 범용 프로세서, 디지털 신호처리 프로세서(DSP), 응용특화 명령어 셋 프로세서 (ASIP), 그래픽 처리 장치(Graphic Processing Unit) 등의 벡터 연산을 수행하는 대부분의 프로세서에 적용 가능하다.
한편, 방법은 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM. CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다.
또한, 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
본 발명은 특정한 최상의 실시 예와 관련하여 설명되었지만, 이외에 본 발명에 대체, 변형 및 수정이 적용된 발명들은 전술한 설명에 비추어 당업자에게 명백할 것이다. 즉, 청구영역은 이러한 모든 대체, 변형 및 수정된 발명을 포함하도록 해석한다. 그러므로 이 명세서 및 도면에서 설명한 모든 내용은 예시적이고 비제한적인 의미로 해석해야 한다.

Claims (15)

  1. 복수의 메모리 뱅크(Bank); 및
    상기 복수의 메모리 뱅크에 저장된 데이터 중 벡터 연산에 필요한 데이터를 복사하여 저장한 복수의 룩업 테이블을 생성하고, 상기 복수의 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 제어부를 포함하는 장치.
  2. 제1항에 있어서, 상기 제어부는,
    상기 복수의 룩업 테이블을 생성하는 룩업 테이블 생성부; 및
    상기 복수의 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 게더(Gather)부를 포함하는 장치.
  3. 제1항에 있어서, 상기 제어부는,
    상기 각각의 뱅크에 하나의 룩업 테이블을 생성하여, 상기 복수의 뱅크들의 개수와 동일한 개수의 룩업 테이블을 생성하는 것을 특징으로 하는 장치.
  4. 제1항에 있어서, 상기 제어부는,
    상기 복수의 뱅크들을 소정의 그룹으로 나누어, 상기 그룹별로 하나의 룩업 테이블을 생성하고,
    상기 그룹별로 생성된 하나의 룩업 테이블은 상기 그룹에 속하는 복수개의 뱅크에 인터리빙(interleaving)형태로 저장되는 것을 특징으로 하는 장치.
  5. 제1항에 있어서, 상기 제어부는,
    랜덤(random)하게 생성된 복수의 인덱스로 구성된 인덱스 벡터를 이용하여 상기 각각의 룩업 테이블을 접근하고, 상기 각각의 룩업 테이블 내의 상기 인덱스 위치에 저장된 데이터를 읽는 것을 특징으로 하는 장치.
  6. 제1항에 있어서, 상기 제어부는,
    상기 벡터 데이터에 소정의 벡터 연산이 수행된 결과 벡터 데이터를 엘리먼트 단위로 분리하여 상기 복수의 룩업 테이블로 저장하는 것을 특징으로 하는 장치.
  7. 제6항에 있어서, 상기 제어부는,
    상기 각각의 엘리먼트를 상기 각각의 룩업 테이블 내의 소정의 인덱스 위치에 저장하는 것을 특징으로 하는 장치.
  8. 제6항에 있어서, 상기 제어부는,
    상기 복수의 룩업 테이블들 중 어느 하나의 룩업 테이블 내의 제1인덱스에 저장된 데이터의 값이 변경되면, 변경되지 않은 나머지 룩업 테이블의 상기 제1인덱스에 저장된 데이터를 상기 변경된 값으로 갱신하는 것을 특징으로 하는 장치.
  9. 제6항에 있어서,
    상기 각각의 룩업 테이블에 대응하는 복수의 서브 스위치부로 구성된 스위칭부를 더 포함하고,
    상기 복수의 서브 스위치부는 상기 제어부가 상기 각각의 룩업 테이블의 소정의 인덱스 위치에 접근하는 것을 허용할지 여부를 결정하는 것을 특징으로 하는 장치.
  10. 제9항에 있어서, 상기 복수의 서브 스위치부는,
    상기 각각의 뱅크와 대응되는 복수의 스위치를 포함하고,
    상기 각각의 스위치는 상기 각각의 뱅크에 대한 상기 제어부의 접근 가능 여부를 결정하는 것을 특징으로 하는 장치.
  11. 복수의 메모리 뱅크(Bank)에 저장된 데이터 중 벡터 연산에 필요한 데이터를 복사하여 저장한 복수의 룩업 테이블을 생성하는 단계; 및
    상기 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 단계를 포함하는 방법.
  12. 제11항에 있어서, 상기 룩업 테이블을 생성하는 단계는,
    상기 각각의 뱅크에 하나의 룩업 테이블을 생성하여, 상기 각각의 뱅크에 상기 복수의 뱅크들의 개수와 동일한 개수의 룩업 테이블을 생성하는 것을 특징으로 하는 방법.
  13. 제11항에 있어서, 상기 룩업 테이블을 생성하는 단계는,
    상기 복수의 뱅크들을 소정의 그룹으로 나누어, 상기 그룹별로 하나의 룩업 테이블을 생성하고,
    상기 그룹별로 생성된 하나의 룩업 테이블은 상기 그룹에 속하는 복수개의 뱅크에 인터리빙(interleaving)형태로 저장되는 것을 특징으로 하는 방법.
  14. 제11항에 있어서, 상기 룩업 테이블로부터 데이터를 읽어 벡터 데이터를 생성하는 단계는,
    랜덤(random)하게 생성된 복수의 인덱스로 구성된 인덱스 벡터를 이용하여 상기 각각의 룩업 테이블을 접근하고, 상기 각각의 룩업 테이블 내의 상기 인덱스 위치에 저장된 데이터를 읽는 것을 특징으로 하는 방법.
  15. 제 11항 내지 14항 중 어느 한 항에서 수행되는 방법을 컴퓨터에서 실행시키기 위 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
PCT/KR2015/012317 2014-12-15 2015-11-17 메모리 접근 방법 및 장치 WO2016099036A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201580076202.7A CN107223237B (zh) 2014-12-15 2015-11-17 用于存储器访问的方法和装置
US15/536,351 US10409596B2 (en) 2014-12-15 2015-11-17 Method and apparatus for performing vector operations using look up tables
EP15870204.3A EP3220274B1 (en) 2014-12-15 2015-11-17 Method and apparatus for memory access

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2014-0180501 2014-12-15
KR1020140180501A KR102357863B1 (ko) 2014-12-15 2014-12-15 메모리 접근 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2016099036A1 true WO2016099036A1 (ko) 2016-06-23

Family

ID=56126864

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2015/012317 WO2016099036A1 (ko) 2014-12-15 2015-11-17 메모리 접근 방법 및 장치

Country Status (5)

Country Link
US (1) US10409596B2 (ko)
EP (1) EP3220274B1 (ko)
KR (1) KR102357863B1 (ko)
CN (1) CN107223237B (ko)
WO (1) WO2016099036A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11809339B2 (en) 2020-03-06 2023-11-07 Samsung Electronics Co., Ltd. Data bus, data processing method thereof, and data processing apparatus

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109496306B (zh) 2016-07-13 2023-08-29 莫鲁米有限公司 多功能运算装置及快速傅里叶变换运算装置
WO2019168739A1 (en) * 2018-02-27 2019-09-06 Google Llc Large lookup tables for an image processor
KR102545189B1 (ko) * 2018-09-07 2023-06-19 삼성전자주식회사 스토리지 장치, 스토리지 시스템 및 스토리지 장치의 동작 방법
US11226822B2 (en) 2019-05-27 2022-01-18 Texas Instmments Incorporated Look-up table initialize
KR102316271B1 (ko) * 2019-08-29 2021-10-22 동국대학교 산학협력단 데이터 저장장치의 주소 맵핑 테이블 운용 방법
US11630667B2 (en) * 2019-11-27 2023-04-18 Advanced Micro Devices, Inc. Dedicated vector sub-processor system
KR20220145656A (ko) * 2021-04-22 2022-10-31 에스케이하이닉스 주식회사 호스트 및 이를 포함하는 컴퓨팅 시스템
US11836527B2 (en) * 2021-08-02 2023-12-05 Nvidia Corporation Accelerating table lookups using a decoupled lookup table accelerator in a system on a chip
KR102545175B1 (ko) * 2022-05-02 2023-06-20 삼성전자주식회사 어드레스 테이블을 포함하는 메모리 장치, 및 메모리 컨트롤러의 동작 방법

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6430672B1 (en) * 2000-07-17 2002-08-06 International Business Machines Corporation Method for performing address mapping using two lookup tables
US20060012603A1 (en) * 2004-07-13 2006-01-19 Lindholm John E Simulating multiported memories using lower port count memories
US20090150644A1 (en) * 2007-12-10 2009-06-11 Electronics And Telecommunication Research Institute Apparatus and method for reducing memory access conflict
WO2011075170A1 (en) * 2009-12-15 2011-06-23 Memoir Systems, Inc. System and method for storing data in a virtualized high speed memory system
US20140047197A1 (en) * 2012-08-09 2014-02-13 Texas Instruments, Incorporated Multiport memory emulation using single-port memory devices

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7093102B1 (en) 2000-03-29 2006-08-15 Intel Corporation Code sequence for vector gather and scatter
US7305540B1 (en) * 2001-12-31 2007-12-04 Apple Inc. Method and apparatus for data processing
US20130212353A1 (en) * 2002-02-04 2013-08-15 Tibet MIMAR System for implementing vector look-up table operations in a SIMD processor
AU2003245447B2 (en) * 2002-09-06 2009-08-27 United States Postal Service Method and system for efficiently retrieving secured data by securely pre-processing provided access information
KR100800552B1 (ko) * 2005-06-13 2008-02-04 재단법인서울대학교산학협력재단 벡터 메모리, 이를 구비한 프로세서 및 그 데이터 처리방법
US7627735B2 (en) 2005-10-21 2009-12-01 Intel Corporation Implementing vector memory operations
US7441099B2 (en) * 2006-10-03 2008-10-21 Hong Kong Applied Science and Technology Research Institute Company Limited Configurable SIMD processor instruction specifying index to LUT storing information for different operation and memory location for each processing unit
US8191056B2 (en) 2006-10-13 2012-05-29 International Business Machines Corporation Sparse vectorization without hardware gather/scatter
JP5232845B2 (ja) * 2009-09-30 2013-07-10 京セラドキュメントソリューションズ株式会社 画像処理装置およびそれを用いる画像形成装置
US20130185540A1 (en) * 2011-07-14 2013-07-18 Texas Instruments Incorporated Processor with multi-level looping vector coprocessor

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6430672B1 (en) * 2000-07-17 2002-08-06 International Business Machines Corporation Method for performing address mapping using two lookup tables
US20060012603A1 (en) * 2004-07-13 2006-01-19 Lindholm John E Simulating multiported memories using lower port count memories
US20090150644A1 (en) * 2007-12-10 2009-06-11 Electronics And Telecommunication Research Institute Apparatus and method for reducing memory access conflict
WO2011075170A1 (en) * 2009-12-15 2011-06-23 Memoir Systems, Inc. System and method for storing data in a virtualized high speed memory system
US20140047197A1 (en) * 2012-08-09 2014-02-13 Texas Instruments, Incorporated Multiport memory emulation using single-port memory devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3220274A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11809339B2 (en) 2020-03-06 2023-11-07 Samsung Electronics Co., Ltd. Data bus, data processing method thereof, and data processing apparatus

Also Published As

Publication number Publication date
KR102357863B1 (ko) 2022-02-04
US10409596B2 (en) 2019-09-10
EP3220274B1 (en) 2022-03-16
CN107223237B (zh) 2021-09-21
EP3220274A1 (en) 2017-09-20
EP3220274A4 (en) 2017-11-22
KR20160072620A (ko) 2016-06-23
US20170344369A1 (en) 2017-11-30
CN107223237A (zh) 2017-09-29

Similar Documents

Publication Publication Date Title
WO2016099036A1 (ko) 메모리 접근 방법 및 장치
WO2016186463A1 (en) Method for launching a second application using a first application icon in an electronic device
WO2018113239A1 (zh) 一种卷积神经网络的数据调度方法、系统及计算机设备
WO2019245348A1 (en) Neural processor
WO2019088470A1 (en) Processor and control methods thereof
US20070067778A1 (en) System and method for communication in a multithread processor
WO2015156596A1 (en) Hardware-based memory management apparatus and memory management method thereof
EP3030960A1 (en) Method for displaying and an electronic device thereof
JP2826028B2 (ja) 分散メモリ型プロセッサシステム
WO2018161580A1 (zh) 广播的控制方法、装置、存储介质及电子设备
WO2015012607A1 (en) Method for displaying and an electronic device thereof
WO2019221377A1 (ko) 블록체인 기반 트랜잭션 관리 시스템 및 그 동작 방법
WO2018124331A1 (ko) 그래프 처리 시스템 및 그래프 처리 시스템의 동작 방법
WO2017095195A1 (ko) 시스템 리소스 관리를 위한 방법 및 장치
EP2693343A1 (en) Parallel processing system and parallel processing system operation method
JP4695124B2 (ja) 動画像符号化における動き探索装置
WO2022092988A1 (en) A memory device for an artificial neural network
WO2021246818A1 (ko) 뉴럴 네트워크 프로세싱 방법 및 이를 위한 장치
WO2019132235A1 (ko) 메모리 장치 및 그 데이터 처리 방법
WO2015102266A1 (en) Processor and method of controlling the same
WO2018021620A1 (ko) 병렬 프로세싱 유닛 및 이를 포함하는 컴퓨팅 디바이스, 그리고 쓰레드 그룹 스케줄링 방법
WO2021020762A1 (en) Processor and control method thereof
WO2013015569A2 (ko) 시뮬레이션 장치 및 그의 시뮬레이션 방법
WO2016023509A1 (zh) 呈现文件的方法和文件呈现装置
WO2023063711A1 (en) Multimedia file playing method and apparatus for rotatable device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15870204

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15536351

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2015870204

Country of ref document: EP