neonkainside Oct 10 2019 at 00:52

Простая реализация небольших CAM на ПЛИС

3 min

5.5K

FPGA*

+12

Comments 21

JackKatch Oct 10 2019 at 10:47

Ещё бы переставил местами буквы в словах и было бы совсем понятно о чём реч. А по делу — что такое CAM, TCAM, BRAM и для чего так писать? (Подразумевается что кто то будет это читать)

neonkainside Oct 10 2019 at 10:53

Я хотя бы не потерял мягкие знаки. По делу — TCAM и CAM общепринятые обозначения, хотя из текста вполне можно понять, что это такое. Что такое BRAM (а иже с ним SRL16, XST, PnR и проч.) должно быть и так известно читающим хаб PFGA, никто же в статьях по программированию не разжевывает, что такое цикл, компилятор и регистры.

-4

JackKatch Oct 10 2019 at 15:01

Не обижайся друже, я просто спросил т.к. не понятно было. Читают статьи не только специалисты. Если бы хоть в заголовке расшифровка была, то вопросов бы не было.

neonkainside Oct 10 2019 at 15:20

Расставил ссылки

Mogwaika Oct 10 2019 at 19:53

А в каких задачах эти CAM применяются на плисах?

neonkainside Oct 10 2019 at 20:05

У меня в контроллере памяти в таком CAM будут храниться кое-какие признаки, нужные для синхронизации потоков. Потоков не будет больше 1000 одновременно, поэтому я не гнался за размером. А так, серьёзные CAM используются для таблиц в коммутаторах и в TLB.

Mogwaika Oct 10 2019 at 20:16

Синхронизации потоков чего?

neonkainside Oct 10 2019 at 20:26

Синхронизация данных для программных потоков в многоядерной вычислительной системе.

Mogwaika Oct 10 2019 at 20:38

Ясно. Я думал вы сетевой коммутатор делаете.
Мне просто тоже пару раз указывали, что непонятно пишу, когда статья узкоспециализированная, теперь понял каково это со стороны))
Я думаю до ката нужна предыстория описанием постановки задачи на один абзац и многие вопросы отпадут.

neonkainside Oct 10 2019 at 20:48

К сожалению более менее понятное описание будет в отдельной статье, здесь я постарался сконцентрироваться на CAM as is, это мне показалось достаточно самостоятельной темой. Возможно бы не прав.

amartology Oct 11 2019 at 11:32

Тема самостоятельная, но читать всегда интереснее, если перед глазами есть пример того, для чего оно может быть нужно.

eugenk Sep 15 2020 at 17:47

Кстати так и не понял, почему заминусовали. Хаб довольно специфический. И мне кажется по умолчанию должно предполагаться, что читающие его в курсе, хотя бы что такое BRAM. Жаль оценивать по срокам уже нельзя, а то бы поставил плюсик в качестве хоть какой-то, но компенсации :)))

Brak0del Oct 10 2019 at 10:57

CAM — content addresable memory, наверно.
BRAM — это устоявшееся у плисоводов сокращение от Block Random Access Memory (встроенных блоков памяти ПЛИС).
А по существу, у меня вопрос: зачем такие тяжелые плисины использовали, вроде overkill по ресурсам и ценнику?

neonkainside Oct 10 2019 at 11:03

Такие тяжёлые (если речь идёт про 325-й Кинтекс) просто потому, что CAM там маленький кусок большого дизайна. Так то у меня 32x256 например влезал в XC3S1400A и почти влезал 32x1024, если попрыгать чутка на нем, то влез бы.

Brak0del Oct 10 2019 at 11:04

CAM там маленький кусок большого дизайна

Теперь понятно, благодарю.

eugenk Sep 15 2020 at 10:01

Дико извиняюсь, но честно говоря вообще не понял, как что-то подобное можно сделать на BRAM. Нет, оно понятно, что там можно искать. А если озаботиться сортировкой, то можно даже применить бинарный поиск вместо линейного. Но смысл-то всего, это искать за один такт! Не знаю как тут BRAM поможет… Просветите уж неуча! :))))
Как раз сейчас о чём-то похожем думаю. Хочу чтобы процессор на плисине пореже лазил в SDRAM и почаще пользовался BRAM. Иными словами сделать для него кеш. Вспомнил что мельком видел на хабре Вашу статью, и сейчас полез читать. К сожалению не нашел ничего, о чём бы я сам не подумал. Единственно совершенно не понял, как тут можно использовать BRAM. А так получается дороговато. Если линейка кеша 64 байта(как у x86, x86_64), то на один BRAM(Spartan-7) кеша придется использовать 64 таких регистра-компаратора как у Вас. Что делать? Увеличивать размер ячейки кеша ??? Не лучший вариант.

ikle Sep 17 2020 at 10:22

Если у вас вообще нет кеша, то почему бы не попробовать BRAM, адресуемый хешем адреса? При записи просто записываем по адресу, равному хешу от целевого адреса в BRAM сам целевой адрес и слово данных. При чтении проверяем, действительно ли в ячейке BRAM, адресуемой хешем целевого адреса, лежит требуемый целевой адрес: нет — промах, да — попадание.

Промахов, конечно, будет больше из-за коллизий, чем при реализации via CAM.

Brak0del Sep 17 2020 at 12:50

Промахов, конечно, будет больше из-за коллизий, чем при реализации via CAM.

Таки на случай коллизий можно организовать цепочки значений для каждого адреса.
Имхо, всё украдено до нас, много интересных кейсов и вариаций можно глянуть у Jacob в «Memory Systems: Cache, DRAM, Disk».

ikle Sep 18 2020 at 01:07

Можно, можно opening adressing hast table использовать для цепочек прямо в том же BRAM, но, по-моему, это излишнее усложнение. (Только стоит помнить, что OAHT ведёт себя хорошо при таблице, заполненной, примерно, не более, чем на 2/3 — вот ещё усложнение.)

Впрочем, нужно эксперементировать на реальных прецедентах использования. Лучше начать с простого без цепочек и поиграться с хеш-функцией.

Имхо, всё украдено до нас, много интересных кейсов и вариаций можно глянуть у...

С этим я не спорю )

eugenk Sep 23 2020 at 10:54

И как Вы это себе представляете ??? Ну хорошо, набрали из BRAM буфер на 16К слов. Если так, то хеш должен быть 14-битный. При 1М адресном пространстве вероятность коллизии 1/64. А их тоже придётся как-то разрешать! Что время либо ресурсы. А скорее и то и другое. Я тут ниже ещё один коммент написал про использование мелкой памяти на LUT вместо регистров. Наверно буду делать всё-таки как-то так. Вообще тема интересная. Смотрел на opencores, реализаций кеш-памяти там не нашел.

eugenk Sep 15 2020 at 12:48

Придумал небольшое улучшение Вашей приблудины. Дело в том что у Xilinx есть мелкая память на основе LUT. Если мне не изменяет мой склероз, библиотечные примитивы на 16, 32, 64 и 128 бит. Можно в том что Вы называете Cam Line заменить каждый триггер на такую вот память. Что это даёт:
Фактически каждый бит в линии заменяется адресуемым набором из 16 (до 128) битов. Положим кеш состоит из нескольких блоков, и в каждый блок мы кладём данные из строго определённого диапазона адресов основной памяти, и никакие другие. Тогда физический адрес можно разбить на три части:
— Младшие биты — смещение относительно начала линейки кеша.
— Средние биты — ключ поиска в ассоциативной памяти.
— Старшие биты — адрес блока кеша.
Если адрес блока кеша мы подаём в качестве адреса на нашу память, заменяющую триггеры, на компараторы подадутся как раз нужные ключи для сравнения.
Таким образом один такой контроллер сможет управлять сразу множеством блоков кеша. Практически бесплатно экономим дохренищща ресурсов кристалла!

Show the best of all time