Comments 11
Может у кого то есть объяснения или точная информация, почему ячейки именно таких размеров, то комментарии приветствуются
Первое что приходит в голову - 9-й бит - это бит четности. На старых материнках 286 и 386 почти всегда использовалась оперативная память с аппаратным контролем четности (ибо техпроцесс тогда был неважнецкий, память могла дохнуть прям на ходу). Потом в эпоху 486 и выше от контроля четности стали отказываться и почти все планки пошли без доп. микросхемы. Планки поделились на серверные (с аппаратным контролем) и несерверные. Может, эхо тех времен.
Не совсем понятно, причем тут режимы конфигурации.
1024 × 8 и 1024 × 9 ; 512 × 16 и 512 × 18; 256 × 32 и 256 × 36 - очевидно же что в режимах слева неиспользуемые биты просто отбрасываются логикой дешифрации и не используются. Но физически эти биты никуда не деваются, они есть. А вопрос был - для чего их изначально сделали с таким запасом.
За Альтеру не скажу, а вот в Xilinx (там такая же петрушка), например для RAMB36E1, это область памяти четности данных (шина DIPA, 4 бита шириной). В зависимости от конфигурации блока она может как использоваться, так и нет.
9-й бит в каждом байте -- это именно что контрольный бит. Есть применения, где надо защищаться от возможных сбоев информации в памяти -- и там контрольные разряды необходимы. Это не обязательно контроль по чётности; скажем, если использовать слово данных шириной 64 бита, т.е. 8 байтов, имеем 8 контрольных разрядов -- и этого достаточно, чтобы реализовать код Хэмминга и иметь возможность обнаруживать любые двойные ошибки и корректировать одиночные.
Но, поскольку это ПЛИС, никто не заставляет использовать "лишние" биты для контроля. Скажем, в PicoBlaze (мелкий-мелкий проц от Хилинха) команда кодируется 18 битами, если память не изменяет -- разработчик как раз использует особенность блочной памяти, где у каждого байта предусмотрен дополнительный бит.
Позвольте высказать свое долекое от дилетанского (В ХУДШУЮ СТОРОНУ) мнение. Если бы 9 бит был бы битом контроля, то на входе записи байтов в массив памяти стояло бы какое-то логическое устройство формирующее этот бит для записи. Но как мне кажется в архитектуре Плис этого нет, но наверное можно запрограмировать такую функцию если необходимо и использовать, так как конфигурация организации массива памяти позволяет этоорганизовать разработчиком
Но как мне кажется в архитектуре Плис этого нет, но наверное можно запрограмировать такую функцию если необходимо и использовать, так как конфигурация организации массива памяти позволяет этоорганизовать разработчиком
Во многих архитектурах ПЛИС в каждой брамке есть блок ЕСС. Скрин из мануала на брамки Xilinx:
Для начала хотелось бы выделить два основных свойства внутренней памяти ПЛИС
Важное свойство брамок low-latency доступ. Про это вспоминают всегда, когда проектируют устройства с большими требованиями к памяти и решают, что оставить в ПЛИС, а что держать в DDR и т.д. Ещё одно важное свойство -- высокий параллелизм. Ведь брамок на кристалле может быть сотня или тысяча, у каждой свои независимые порты (или порт), и при желании можно обращаться к каждой в каждом такте.
Насчёт свойства удобства, имхо, это что-то неизмеримое.
Да, видим, что каждый наш модуль занял по 1 M9K, но задействовал не полностью и я пока не встречал, чтобы Quartus автоматических оптимизировал такое использование внутренней памяти ввиду её архитектуры.
Синтезатор не умеет читать мысли. Ресурс памяти -- это не только про объём, но и про использование портов в том числе во времени. В данном случае проектировщик знает свой проект и то, что может безболезненно уменьшить производительность системы в 4 раза (ведь было 4 независимых буфера, а остался один), а синтезатор этого угадать не может. Если это знание отразить в коде, возможно, синтезатор приятно удивит.
IMHO, изначально BRAM использовались вместе с умножителями. Их ширина была 18 бит, соот. коэффициенты из памяти брались словами по 18-бит. По одному - два BRAM на умножитель, они и на кристалле рядом расположены. Я так думаю.
Внутренняя память ПЛИС, которой всегда не хватает