Регистровый файл: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
[отпатрулированная версия][отпатрулированная версия]
← Предыдущая правка
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
м {{Шаблон:Технологии CPU
 
(не показаны 32 промежуточные версии 21 участника)
Строка 1: Строка 1:
Регистровый файл ('''register file''') - модуль [[микропроцессор]]а (CPU), хранящий в себе [[регистры процессора]]. Современные регистровый файлы, используемые в [[СБИС]] обычно реализованы как многопортовый массив быстрой статической памяти [[SRAM]]. Такие массивы SRAM отличаются явным разделением портов чтения и записи, тогда как классическая многопортовая SRAM обычно позволяет как читать так и записывать через любой порт.
'''Регистровый файл''' ('''register file''') — модуль [[микропроцессор]]а (CPU), содержащий в себе реализацию [[регистры процессора|регистров процессора]]. Современные регистровые файлы, используемые в [[СБИС]], обычно реализованы как многопортовый массив быстрой статической памяти [[SRAM (память)|SRAM]]. Такие массивы SRAM отличаются явным разделением портов чтения и записи, тогда как классическая многопортовая SRAM обычно позволяет как читать, так и записывать через любой порт.


== Связь с архитектурой ==
[[Система команд]] микропроцессора (архитектура) практически всегда определяет набор регистров, которые будут хранить данные для обработки функциональными устройствами чипа. В простейших процессорах такие ''архитектурные регистры'' отображаются один-в-один в физический регистровый файл. В более сложных ЦПУ используется [[переименование регистров]] (register renaming), которое позволяет динамически изменять соответствие между аппаратными и архитектурными регистрами во время исполнения. <!-- The register file is part of the [[instruction set architecture|architecture]] and visible to the programmer, as opposed to the concept of transparent [[CPU cache|caches]]. -->
[[Система команд]] микропроцессора (архитектура) практически всегда определяет набор регистров, которые будут хранить данные для обработки функциональными устройствами чипа. В простейших процессорах такие ''архитектурные регистры'' отображаются один в один в физический регистровый файл. В более сложных ЦПУ используется [[переименование регистров]] (register renaming), которое позволяет динамически изменять соответствие между аппаратными и архитектурными регистрами во время исполнения. <!-- The register file is part of the [[instruction set architecture|architecture]] and visible to the programmer, as opposed to the concept of transparent [[CPU cache|caches]]. -->


== Implementation ==
== Реализация ==
⚫
[[Файл:regfile array.png|right]]
Традиционно регистровый файл реализуется как массив запоминающих ячеек, считываемый вертикально. Слова расположены в горизонтальных строках (word lines), и при чтении ячейки выдают своё значение на вертикальные битовые линии (Bit lines). В нижней части эти линии подключены к усилителям, которые преобразуют сигналы с ячеек, ослабленные при передаче, в булевые сигналы полной амплитуды. В левой части расположены декодеры, активирующие строку, соответствующую заказанному регистру или регистрам. Большие регистровые файлы иногда организуются как мозаика из нескольких отраженных и повернутых более простых регистровых файлов.


Регистровые файлы содержат по одной строке слов на каждый порт, по одной битовой линии на бит слова для каждого порта чтения и по две битовые линии на бит слова для каждого порта записи. Также каждая ячейка должна иметь входы питания V<sub>dd</sub> и земли V<sub>ss</sub>. Следовательно, с увеличением количества портов площадь, требуемая под разводку<!-- wire pitch area -->, растет квадратично, а площадь, занимаемая транзисторами, — линейно. В какой-то момент, возможно, будет более оптимально по площади или по задержкам иметь несколько регистровых файлов с дублирующейся информацией и половиной портов чтения в каждом, чем один большой регистровый файл сразу со всеми портами чтения.
⚫
[[Image:regfile array.png|right]]
⚫
<!--
The usual layout convention is that a simple array is read out vertically. That is, a single word line, which runs horizontally, causes a row of [[bit cell]]s to put their data on bit lines, which run vertically. Sense amps, which convert low-swing read bitlines into full-swing logic levels, are usually at the bottom (by convention). Larger register files are then sometimes constructed by tiling mirrored and rotated simple arrays.


Например, регистровый файл в целочисленном АЛУ микропроцессора [[MIPS (архитектура)|MIPS]] [[R8000]], имеющий 9 портов чтения, 4 порта записи, содержащий 32 64-битных регистра и реализованный на [[техпроцесс]]е 0,7 мкм, имеет такие размеры, что хорошо различим невооруженным глазом даже на расстоянии порядка 30 см.
Register files have one word line per entry per port, one bit line per bit of width per read port, and two bit lines per bit of width per write port. Each bit cell also has a Vdd and Vss. Therefore, the wire pitch area increases as the square of the number of ports, and the transistor area increases linearly. At some point, it may be smaller and/or faster to have multiple redundant register files, with smaller numbers of read ports, than a single register file with all the read ports. The [[MIPS architecture|MIPS]] [[R8000]]'s [[integer (computer science)|integer]] unit, for example, had a 9 read 4 write port 32 entry 64-bit register file implemented in a 0.7&nbsp;µm process, which could be seen when looking at the chip from arm's length.


===Decoder===
=== Декодер ===
* Декодер обычно разделён на предекодер и decoder proper.
* Декодер является последовательностью элементов И (AND-gate), которые выставляют линии слов.
* Для каждого порта чтения или записи требуется один декодер. К примеру, если файл имеет 4 порта чтения и 2 порта, в нём будет 6 линий слов в каждой ячейке памяти в массиве и 6 элементов И (AND-gate) на каждый ряд в декодере. <!-- При этом Note that the decoder has to be pitch matched to the array, which forces those AND gates to be wide and short -->


=== Массив ===
* The decoder is often broken into predecoder and decoder proper.
[[Файл:regfile cell.png|right|frame|Типичный регистровый файл с 3 портами, в котором возможно одновременное чтение из 2 регистров и запись в 1 регистр, состоит из ячеек, похожих на изображенную.]]
* The decoder is a series of AND gates that drive word lines.
* There is one decoder per read or write port. If the array has four read and two write ports, for example, it has 6 word lines per bit cell in the array, and six AND gates per row in the decoder. Note that the decoder has to be pitch matched to the array, which forces those AND gates to be wide and short


Базовая схема битовой ячейки:
===Array===
* Состояние хранится в паре [[Инвертор (логический элемент)|инверторов]].
* Чтение происходит через транзистор NMOS на битовую линию (транзистор открывается линией слов данного порта)
* Данные записываются замыканием одной или другой стороны на землю через два NMOS-транзистора.
Итак, каждый порт чтения требует один дополнительный транзистор на каждую ячейку, порт записи требует 4 транзистора.


⚫
<!--The basic scheme for a bit cell:
[[Image:regfile cell.png|right|frame| A typical register file -- "triple-ported", able to read from 2 registers and write to 1 register simultaneously -- is made of bit cells like this one.]]

⚫
The basic scheme for a bit cell:
* State is stored in pair of inverters
* State is stored in pair of inverters
* Data is read out by nmos transistor to a bit line.
* Data is read out by nmos transistor to a bit line.
* Data is written by shorting one side or the other to ground through a two-nmos stack.
* Data is written by shorting one side or the other to ground through a two-nmos stack.
* So: read ports take one transistor per bit cell, write ports take four!
* So: read ports take one transistor per bit cell, write ports take four!

Возможно множество улучшений:
* Совместное использование линий между ячейками, например, Vdd и Vss
* Линии чтения часто предзаряжаются до некоторого уровня между Vdd и Vss
…

Many optimizations are possible:
Many optimizations are possible:
* Sharing lines between cells, for example, Vdd and Vss.
* Sharing lines between cells, for example, Vdd and Vss.
* Read bit lines are often precharged to something between Vdd and Vss.
* Read bit lines are often precharged to something between Vdd and Vss.
* Read bit lines often swing only a fraction of the way to Vdd or Vss. A sense amplifier converts this small-swing signal into a full logic level. Small swing signals are faster because the bit line has little drive but a great deal of parasitic capacitance.
* Read bit lines often swing only a fraction of the way to Vdd or Vss. A sense amplifier converts this small-swing signal into a full logic level. Small swing signals are faster because the bit line has little drive but a great deal of parasitic capacitance.
* Write bit lines may be braided, so that they couple equally to the nearby read bitlines. Because write bitlines are full swing, they can cause significant disturbances on read bitlines.
* Write bit lines may be braided, so that they couple equally to the nearby read bitlines. Because write bitlines are full swing, they can cause significant disturbances on read bitlines.
* If Vdd is a horizontal line, it can be switched off, by yet another decoder, if any of the write ports are writing that line during that cycle. This optimization increases the speed of the write.
* If Vdd is a horizontal line, it can be switched off, by yet another decoder, if any of the write ports are writing that line during that cycle. This optimization increases the speed of the write.
* Techniques that reduce the energy used by register files are useful in [[low-power electronics]]<ref>
* Techniques that reduce the energy used by register files are useful in [[low-power electronics]]<ref>
[http://d.wanfangdata.com.cn/NSTLHY_NSTL_HY633772.aspx "Energy efficient asymmetrically ported register files"]
[http://d.wanfangdata.com.cn/NSTLHY_NSTL_HY633772.aspx «Energy efficient asymmetrically ported register files»]
by Aneesh Aggarwal and M. Franklin. 2003.
by Aneesh Aggarwal and M. Franklin. 2003.
</ref>
</ref>
⚫
-->
== Микроархитектура ==
Во многих реализациях регистровых файлов нет специальной защиты от попыток записи в одну и ту же ячейку сразу из нескольких портов записи. Вместо этого аппаратура планирования инструкций должна гарантировать, что на каждом такте не более одной инструкции будет производить запись в любую ячейку. Если же запланировано несколько инструкций, пишущих в одну ячейку, то только одна из них должна иметь включенной линию «write enable» (разрешение записи).


Пара встречно включенных инверторов требует некоторого времени для стабилизации состояния после начала операции записи, в течение которого чтение из ячейки либо будет более долгим, либо вернет мусор. Поэтому во многих реализациях вводятся проходные (bypass) мультиплексоры, которые могут замыкать записываемые данные непосредственно на порты чтения, когда происходят одновременные запись и чтение в один регистр. Эти проходные мультиплексоры часто являются лишь одной из частей более сложной сети байпасов<!-- может стоит заменить на "проходов"? -->, которая пересылает результаты непосредственно между различными функциональными устройствами процессора, без ожидания их записи в регистры (то есть если на данном такте одно ФУ требует на входе данные, являющиеся выходом другого ФУ на предыдущем такте, они могут быть пересланы по байпасу, а не через запись и чтение в регистровый файл, которые могут потребовать несколько тактов. Чтение происходит из байпасов, запись же в регистр происходит одновременно с работой первого ФУ).
==Microarchitecture==
⚫
<!--
⚫
The register file is usually pitch matched to the datapath that it serves. Pitch matching avoids having the many busses passing over the datapath turn corners, which would use a lot of area. But since every unit must have the same bit pitch, every unit in the datapath ends up with the bit pitch forced by the widest unit, which can waste area in the other units. Register files, because they have two wires per bit per write port, and because all the bit lines must contact the silicon at every bit cell, can often set the pitch of a datapath.


⚫
Area can sometimes be saved, on machines with multiple units in a datapath, by having two datapaths side-by-side, each of which has smaller bit pitch than a single datapath would have. This case usually forces multiple copies of a register file, one for each datapath.
Most register files make no special provision to prevent multiple write ports from writing the same entry simultaneously. Instead, the instruction scheduling hardware ensures that only one instruction in any particular cycle writes a particular entry. If multiple instructions targeting the same register are issued, all but one have their write enables turned off.


⚫
The [[Alpha 21264]] (EV6), for instance, had two copies of the integer register file, and took an extra cycle to propagate data between the two. The issue logic tried to reduce the number of operations forwarding data between the two. The [[MIPS architecture|MIPS]] R8000 floating-point unit had two copies of the floating-point register file, each with four write and four read ports, and wrote both copies at the same time.
The crossed inverters take some finite time to settle after a write operation, during which a read operation will either take longer or return garbage. It is common to have bypass multiplexors that bypass written data to the read ports when a simultaneous read and write to the same entry is commanded. These bypass multiplexors are often just part of a larger bypass network that forwards results that have not yet been committed between functional units.


⚫
Processors that do [[register renaming]] can arrange for each functional unit to write to a subset of the physical register file. This arrangement can eliminate the need for multiple write ports per bit cell, for large savings in area. The resulting register file, effectively a stack of register files with single write ports, then benefits from replication and subsetting the read ports. At the limit, this technique would place a stack of 1-write, 2-read regfiles at the inputs to each functional unit. Since regfiles with a small number of ports are often dominated by transistor area, it is best not to push this technique to this limit, but it is useful all the same.
⚫
The register file is usually pitch matched to the datapath that it serves. Pitch matching avoids having the many busses passing over the datapath turn corners, which would use a lot of area. But since every unit must have the same bit pitch, every unit in the datapath ends up with the bit pitch forced by the widest unit, which can waste area in the other units. Register files, because they have two wires per bit per write port, and because all the bit lines must contact the silicon at every bit cell, can often set the pitch of a datapath.


⚫
The [[SPARC]] ISA defines [[register window]]s, in which the 5-bit architectural names of the registers actually point into a window on a much larger register file, with hundreds of entries. Implementing multiported register files with hundreds of entries requires a lot of area. The register window slides by 16 registers when moved, so that each architectural register name can refer to only a small number of registers in the larger array, e.g. architectural register r20 can only refer to physical registers #20, #36, #52, #68, #84, #100, #116, if there are just seven windows in the physical file.
⚫
Area can sometimes be saved, on machines with multiple units in a datapath, by having two datapaths side-by-side, each of which has smaller bit pitch than a single datapath would have. This case usually forces multiple copies of a register file, one for each datapath.


⚫
To save area, some SPARC implementations implement a 32-entry register file, in which each cell has seven «bits». Only one is read and writeable through the external ports, but the contents of the bits can be rotated. A rotation accomplishes in a single cycle a movement of the register window. Because most of the wires accomplishing the state movement are local, tremendous bandwidth is possible with little power.
⚫
The [[Alpha 21264]] (EV6), for instance, had two copies of the integer register file, and took an extra cycle to propagate data between the two. The issue logic tried to reduce the number of operations forwarding data between the two. The [[MIPS architecture|MIPS]] R8000 floating-point unit had two copies of the floating-point register file, each with four write and four read ports, and wrote both copies at the same time.


⚫
This same technique is used in the [[R10000]] register renaming mapping file, which stores a 6-bit virtual register number for each of the physical registers. In the renaming file, the renaming state is checkpointed whenever a branch is taken, so that when a branch is detected to be mispredicted, the old renaming state can be recovered in a single cycle. (See [[Register renaming]].)
⚫
Processors that do [[register renaming]] can arrange for each functional unit to write to a subset of the physical register file. This arrangement can eliminate the need for multiple write ports per bit cell, for large savings in area. The resulting register file, effectively a stack of register files with single write ports, then benefits from replication and subsetting the read ports. At the limit, this technique would place a stack of 1-write, 2-read regfiles at the inputs to each functional unit. Since regfiles with a small number of ports are often dominated by transistor area, it is best not to push this technique to this limit, but it is useful all the same.
⚫
<!- — To do: R10K map file had lots of ports and few bits of width, and so it used a different layout, with bit lines running parallel to word lines, and state bits being global wires running perpendicularly. — ->
-->


⚫
The [[SPARC]] ISA defines [[register window]]s, in which the 5-bit architectural names of the registers actually point into a window on a much larger register file, with hundreds of entries. Implementing multiported register files with hundreds of entries requires a lot of area. The register window slides by 16 registers when moved, so that each architectural register name can refer to only a small number of registers in the larger array, e.g. architectural register r20 can only refer to physical registers #20, #36, #52, #68, #84, #100, #116, if there are just seven windows in the physical file.

⚫
To save area, some SPARC implementations implement a 32-entry register file, in which each cell has seven "bits". Only one is read and writeable through the external ports, but the contents of the bits can be rotated. A rotation accomplishes in a single cycle a movement of the register window. Because most of the wires accomplishing the state movement are local, tremendous bandwidth is possible with little power.

⚫
This same technique is used in the [[R10000]] register renaming mapping file, which stores a 6-bit virtual register number for each of the physical registers. In the renaming file, the renaming state is checkpointed whenever a branch is taken, so that when a branch is detected to be mispredicted, the old renaming state can be recovered in a single cycle. (See [[Register renaming]].)
⚫
<!- - To do: R10K map file had lots of ports and few bits of width, and so it used a different layout, with bit lines running parallel to word lines, and state bits being global wires running perpendicularly. - ->
⚫
-->
== Примечания ==
== Примечания ==
{{примечания}}
{{примечания}}


== Ссылки ==
== Ссылки ==
* [http://citeseer.ist.psu.edu/farkas95register.html Register File Design Considerations in Dynamically Scheduled Processors] — Farkas, Jouppi, Chow — 1995 (obsolete?)
* [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.586 Register file design considerations in dynamically scheduled processors] — Farkas, Jouppi, Chow — 1995
* [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.586 Register file design considerations in dynamically scheduled processors] — Farkas, Jouppi, Chow — 1995


== См. также ==
== См. также ==
* [[:en:Sum addressed decoder]]
* [[:en:Sum addressed decoder]]
* [[Иерархия памяти]]


{{Шаблон:Технологии CPU}}
{{Технологии CPU}}

[[Категория:Микропроцессоры]]
[[Категория:Цифровые системы]]


[[Категория:Технологии процессоров]]
[[de:Registerspeicher]]
[[fr:Banc de registres]]
[[ja:レジスタファイル]]
[[zh:寄存器阵列]]
[[en:Register file]]

Текущая версия от 12:37, 3 декабря 2020

Регистровый файл (register file) — модуль микропроцессора (CPU), содержащий в себе реализацию регистров процессора. Современные регистровые файлы, используемые в СБИС, обычно реализованы как многопортовый массив быстрой статической памяти SRAM. Такие массивы SRAM отличаются явным разделением портов чтения и записи, тогда как классическая многопортовая SRAM обычно позволяет как читать, так и записывать через любой порт.

Связь с архитектурой

[править | править код]

Система команд микропроцессора (архитектура) практически всегда определяет набор регистров, которые будут хранить данные для обработки функциональными устройствами чипа. В простейших процессорах такие архитектурные регистры отображаются один в один в физический регистровый файл. В более сложных ЦПУ используется переименование регистров (register renaming), которое позволяет динамически изменять соответствие между аппаратными и архитектурными регистрами во время исполнения.

Реализация

[править | править код]

Традиционно регистровый файл реализуется как массив запоминающих ячеек, считываемый вертикально. Слова расположены в горизонтальных строках (word lines), и при чтении ячейки выдают своё значение на вертикальные битовые линии (Bit lines). В нижней части эти линии подключены к усилителям, которые преобразуют сигналы с ячеек, ослабленные при передаче, в булевые сигналы полной амплитуды. В левой части расположены декодеры, активирующие строку, соответствующую заказанному регистру или регистрам. Большие регистровые файлы иногда организуются как мозаика из нескольких отраженных и повернутых более простых регистровых файлов.

Регистровые файлы содержат по одной строке слов на каждый порт, по одной битовой линии на бит слова для каждого порта чтения и по две битовые линии на бит слова для каждого порта записи. Также каждая ячейка должна иметь входы питания Vdd и земли Vss. Следовательно, с увеличением количества портов площадь, требуемая под разводку, растет квадратично, а площадь, занимаемая транзисторами, — линейно. В какой-то момент, возможно, будет более оптимально по площади или по задержкам иметь несколько регистровых файлов с дублирующейся информацией и половиной портов чтения в каждом, чем один большой регистровый файл сразу со всеми портами чтения.

Например, регистровый файл в целочисленном АЛУ микропроцессора MIPS R8000, имеющий 9 портов чтения, 4 порта записи, содержащий 32 64-битных регистра и реализованный на техпроцессе 0,7 мкм, имеет такие размеры, что хорошо различим невооруженным глазом даже на расстоянии порядка 30 см.

Декодер

[править | править код]
  • Декодер обычно разделён на предекодер и decoder proper.
  • Декодер является последовательностью элементов И (AND-gate), которые выставляют линии слов.
  • Для каждого порта чтения или записи требуется один декодер. К примеру, если файл имеет 4 порта чтения и 2 порта, в нём будет 6 линий слов в каждой ячейке памяти в массиве и 6 элементов И (AND-gate) на каждый ряд в декодере.

Массив

[править | править код]
Типичный регистровый файл с 3 портами, в котором возможно одновременное чтение из 2 регистров и запись в 1 регистр, состоит из ячеек, похожих на изображенную.

Базовая схема битовой ячейки:

  • Состояние хранится в паре инверторов.
  • Чтение происходит через транзистор NMOS на битовую линию (транзистор открывается линией слов данного порта)
  • Данные записываются замыканием одной или другой стороны на землю через два NMOS-транзистора.

Итак, каждый порт чтения требует один дополнительный транзистор на каждую ячейку, порт записи требует 4 транзистора.

Микроархитектура

[править | править код]

Во многих реализациях регистровых файлов нет специальной защиты от попыток записи в одну и ту же ячейку сразу из нескольких портов записи. Вместо этого аппаратура планирования инструкций должна гарантировать, что на каждом такте не более одной инструкции будет производить запись в любую ячейку. Если же запланировано несколько инструкций, пишущих в одну ячейку, то только одна из них должна иметь включенной линию «write enable» (разрешение записи).

Пара встречно включенных инверторов требует некоторого времени для стабилизации состояния после начала операции записи, в течение которого чтение из ячейки либо будет более долгим, либо вернет мусор. Поэтому во многих реализациях вводятся проходные (bypass) мультиплексоры, которые могут замыкать записываемые данные непосредственно на порты чтения, когда происходят одновременные запись и чтение в один регистр. Эти проходные мультиплексоры часто являются лишь одной из частей более сложной сети байпасов, которая пересылает результаты непосредственно между различными функциональными устройствами процессора, без ожидания их записи в регистры (то есть если на данном такте одно ФУ требует на входе данные, являющиеся выходом другого ФУ на предыдущем такте, они могут быть пересланы по байпасу, а не через запись и чтение в регистровый файл, которые могут потребовать несколько тактов. Чтение происходит из байпасов, запись же в регистр происходит одновременно с работой первого ФУ).

Примечания

[править | править код]

Ссылки

[править | править код]

См. также

[править | править код]
Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=Регистровый_файл&oldid=110852474