Comments 21
У меня в контроллере памяти в таком CAM будут храниться кое-какие признаки, нужные для синхронизации потоков. Потоков не будет больше 1000 одновременно, поэтому я не гнался за размером. А так, серьёзные CAM используются для таблиц в коммутаторах и в TLB.
Синхронизация данных для программных потоков в многоядерной вычислительной системе.
Мне просто тоже пару раз указывали, что непонятно пишу, когда статья узкоспециализированная, теперь понял каково это со стороны))
Я думаю до ката нужна предыстория описанием постановки задачи на один абзац и многие вопросы отпадут.
К сожалению более менее понятное описание будет в отдельной статье, здесь я постарался сконцентрироваться на CAM as is, это мне показалось достаточно самостоятельной темой. Возможно бы не прав.
BRAM — это устоявшееся у плисоводов сокращение от Block Random Access Memory (встроенных блоков памяти ПЛИС).
А по существу, у меня вопрос: зачем такие тяжелые плисины использовали, вроде overkill по ресурсам и ценнику?
Как раз сейчас о чём-то похожем думаю. Хочу чтобы процессор на плисине пореже лазил в SDRAM и почаще пользовался BRAM. Иными словами сделать для него кеш. Вспомнил что мельком видел на хабре Вашу статью, и сейчас полез читать. К сожалению не нашел ничего, о чём бы я сам не подумал. Единственно совершенно не понял, как тут можно использовать BRAM. А так получается дороговато. Если линейка кеша 64 байта(как у x86, x86_64), то на один BRAM(Spartan-7) кеша придется использовать 64 таких регистра-компаратора как у Вас. Что делать? Увеличивать размер ячейки кеша ??? Не лучший вариант.
Если у вас вообще нет кеша, то почему бы не попробовать BRAM, адресуемый хешем адреса? При записи просто записываем по адресу, равному хешу от целевого адреса в BRAM сам целевой адрес и слово данных. При чтении проверяем, действительно ли в ячейке BRAM, адресуемой хешем целевого адреса, лежит требуемый целевой адрес: нет — промах, да — попадание.
Промахов, конечно, будет больше из-за коллизий, чем при реализации via CAM.
Промахов, конечно, будет больше из-за коллизий, чем при реализации via CAM.
Таки на случай коллизий можно организовать цепочки значений для каждого адреса.
Имхо, всё украдено до нас, много интересных кейсов и вариаций можно глянуть у Jacob в «Memory Systems: Cache, DRAM, Disk».
Можно, можно opening adressing hast table использовать для цепочек прямо в том же BRAM, но, по-моему, это излишнее усложнение. (Только стоит помнить, что OAHT ведёт себя хорошо при таблице, заполненной, примерно, не более, чем на 2/3 — вот ещё усложнение.)
Впрочем, нужно эксперементировать на реальных прецедентах использования. Лучше начать с простого без цепочек и поиграться с хеш-функцией.
Имхо, всё украдено до нас, много интересных кейсов и вариаций можно глянуть у...
С этим я не спорю )
Фактически каждый бит в линии заменяется адресуемым набором из 16 (до 128) битов. Положим кеш состоит из нескольких блоков, и в каждый блок мы кладём данные из строго определённого диапазона адресов основной памяти, и никакие другие. Тогда физический адрес можно разбить на три части:
— Младшие биты — смещение относительно начала линейки кеша.
— Средние биты — ключ поиска в ассоциативной памяти.
— Старшие биты — адрес блока кеша.
Если адрес блока кеша мы подаём в качестве адреса на нашу память, заменяющую триггеры, на компараторы подадутся как раз нужные ключи для сравнения.
Таким образом один такой контроллер сможет управлять сразу множеством блоков кеша. Практически бесплатно экономим дохренищща ресурсов кристалла!
Простая реализация небольших CAM на ПЛИС