Jump to content

    

Perdachillo

Участник
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

0 Обычный

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Получается память будет двухпортовая? Один порт будет добавлять (или перезаписывать) записи во время поступления нового Mac адреса, а второй порт (параллельно этому) будет опрашивать последовательно все записи и декрементировать счётчики реализуя механизм устаревания? Попробую. Я почему-то думал, что generate сам по себе создаёт несколько отдельных модулей
  2. Хорошая идея, получится настраиваемый компромисс между количеством тактов для сброса и объёмом памяти. Да, надо весь механизм с устареванием сюда грамотно засунуть. Если использовать ram для хранения информации о валидности, а не регистры, то это несколько усложняет это дело По простому походу не выйдет) придётся засесть.. Смотрю ещё протокол RSTP, и он подразумевает такие случаи, когда необходимо не просто очистить таблицу, а очистить только записи маков, которые относятся к определённому порту назначения. Чувствую, что с этим тоже повожусь. Спасибо за помощь!
  3. То есть сделать массив регистров по количеству записей в таблице коммутации, где каждый регистр будет содержать флаг валидности записи в таблице? Если вы это имели в виду, то я держу в голове этот способ. Смущает, что он все таки прилично логики займёт.
  4. В любом случае, записи как то надо похерить, причём не одну конкретную, а все сразу
  5. Хорошо, спасибо. Этим и займусь.
  6. Я думал имеется в виду готовое решение. А почему cam очищать не нужно? Предположим мне пришёл сигнал, который говорит, что топология изменилась данные о местоположение узлов в сети недействительны (в таблице) . А затем пришёл пакет с данными с определённым MAC адресом назначения. Моё устройство начинает адрес назначения искать в таблице и находит запись, но она же недействительна и использовать её нельзя.
  7. CAM у меня нет, к сожалению, есть только ПЛИС) Предположим я добавлю флаг валидности у записей в таблице. При изменении топологии мне придётся у всех записей снимать этот флаг? Чем тогда это в корне отличается от обычного обнуления? То есть в одном случае я получается один бит в ноль сбрасываю, а в другом все. Или я что то не понял? Поскольку это таблица коммутации, то мне при чтении ячейки неизвестно понадобиться ли мне её ещё раз читать. Она там должна храниться, пока не придёт сигнал изменение топологии, либо пока таймер устаревания не закончится.
  8. Необходимо сделать, что то типа таблицы коммутации, которую при изменении топологии сети требуется очищать. Таблицу я сделал на основе трёхмерного массива. Запись в неё, и соответственно чтение, производится по хэшу, который считается на основе MAC адреса. Как раз для обработки коллизий память и сделана трехмерной. Другого варианта, как все это сделать я честно говоря не нашёл Спасибо, поищу там
  9. Обычно я так и делаю, просто беру мегафункции Quartus. Но в данном случае мне не хотелось бы ставить мультиплексоры на входе портов data и wraddr у модуля RAM. Да и просто возник интерес, по каким принципам Quartus определяет, что является памятью, а что нет? Мб какой документ есть, где это затрагивается?
  10. Всем привет. Пытаюсь реализовать очистку памяти путем последовательной записи во все ячейки нулей. Возникли трудности в понимании того, чем руководствуется Quartus, когда разводит RAM на логике, а когда на блоках памяти. Например, изначально я сделал трехмерную память с по-отчетной записью данных (в том числе и при очистке), при этом чтение происходит областями. Получилось что-то типа byte enabled simple dual port ram, но только отчет равен не байту, а другому заданному значению: logic [DEEP_BACKET-1:0][WIDTH_RECORD-1:0] ram [0:N_BUCKET-1]; logic [$clog2(N_BUCKET*DEEP_BACKET)-1:0] clear_cnt; logic clear_val; always_ff@(posedge clk or posedge clear_table) begin if (clear_table) clear_val <= 1'd1; else if (clear_cnt == N_BUCKET*DEEP_BACKET - 1) clear_val <= 1'd0; end always_ff@(posedge clk) begin if (clear_val) clear_cnt <= clear_cnt + 1'd1; end always_ff@(posedge clk) begin if (clear_val) ram[clear_cnt[$clog2(N_BUCKET)-1:0]][clear_cnt[$clog2(N_BUCKET*DEEP_BACKET)-1:$clog2(N_BUCKET)]] <= '0; else begin if(we) begin ram[waddr][be] <= wdata; end q <= ram[raddr]; end end В данном случае Quartus все развел на блоках памяти. Однако, в таком случае для полной очистки памяти требуется N_BUCKET*DEEP_BACKET тактов. Чтобы снизить это время, я попытался разбить трехмерную память на несколько двумерных: logic [$clog2(N_BUCKET)-1:0] clear_cnt; logic clear_val; always_ff@(posedge clk or posedge clear_table) begin if (clear_table) clear_val <= 1'd1; else if (clear_cnt == N_BUCKET - 1) clear_val <= 1'd0; end always_ff@(posedge clk) begin if (clear_val) clear_cnt <= clear_cnt + 1'd1; end genvar i; generate for (i = 0; i < DEEP_BACKET; i++) begin: slice_table logic [WIDTH_RECORD-1:0] ram [0:N_BUCKET-1]; always_ff@(posedge clk) begin if (clear_val) ram[clear_cnt] <= '0; else begin if (we & be == i) begin ram[waddr] <= wdata; end q[i*WIDTH_RECORD +: WIDTH_RECORD] <= ram[raddr]; end end end: slice_table endgenerate Здесь очистка будет производится всего за N_BUCKET тактов. Но Quartus развел все это дело на логике. Почему? И в том и в другом случае, запись в каждый момент времени ведется только в один адрес. Пересечения условий быть не может. Аналогично с чтением.
  11. Turbo Trellis Coded Modulation

    Продолжаю разбираться с темой, des00 спасибо за наводки. Дело дошло до декодера. Возник вопрос и он скорее по символьному алгоритму MAP. Поскольку мы оперируем в TTCM символами, необходимо использовать символьный алгоритм декодирования MAP. Вот схема упрощенного декодера для бинарного MAP и для символьного MAP. Как вы можете заметить, в случае с TTCM мы не можем отделить внешние LLRe от систематических (канальных) LLRs, поскольку в одном символе передается и систематическая часть и биты четности. Поэтому между декодерами, в качестве априорной информации, передается LLRe&s (а не просто LLRe, как в бинарном случае декодера). Так же известно, что нельзя использовать систематическую информацию дважды (имеется в виду при обмене информацией между составными декодерами). Так вот, собственно сам вопрос: Следует ли из всех этих умозаключений, что TTCM без выкалывания использовать нельзя? Ведь в случае отсутствия выкалывания, мы будем использовать систематический LLR дважды. Вероятнее всего я где то ошибся в рассуждениях, поскольку натыкался на упоминания про unpunctured ttcm. Только вот где ошибаюсь понять не могу. Нашел тут еще неплохую книжку в которой коротко объясняется TTCM и достаточно подробно описывается символьный MAP алгоритм.
  12. Turbo Trellis Coded Modulation

    Прикреплять больше 2 мб не могу, ссылка на гугл диск. 1. Б. Скляр Цифровая связь – тут неплохо объясняются турбокоды и TCM отдельно. 2. Lect9_TCM_07_4 – основные тезисы TCM и TTCM 3. Bandwidth-Efficient Turbo Trellis-Coded Modulation Using Punctured Component Codes 4. TRELLIS AND TURBO CODING Iterative and Graph-Based Error Control Coding 5. Оценка параметров канала для решетчатой турбо-кодовой модуляции в системах с ортогональным частотным уплотнением 6. Near-Capacity Turbo Trellis Coded Modulation Design Based on EXIT Charts and Union Bounds По 3 вопросу, там походу действительно для лучшего понимания добавили. Нашел несколько схем кодера с модулятором после мультиплексора. На счет 2 вопроса. С одной стороны, несистематический код обеспечивает больший просвет, чем систематический: Собственно поэтому и возник вопрос почему бы не использовать несистематический кодер в TTCM. Но с другой стороны так же написано, что в турбокодах используется, как правило, RSC (recursive systematic convolutional), а не NSC (nonsystematic convolutional): Как я понял, "значительно более высокие результаты" достигаются за счет рекурсивности. Почему бы тогда не использовать связку рекурсивный + несистематический? На счет 1 вопроса, я кажется разобрался, в случае с турбокодами, мы по сути можем по очереди выкалывать биты четности с первого и со второго кодера, при этом не трогать систематические биты. В случае же с TTCM так просто не получится, поскольку мы выкалываем символы, которые содержат и систематическую часть и биты четности вместе. Если мы также поочереди без перемежителя начнем выкалывать символы, то потеряем полезную информацию.
  13. Добрый день, уважаемые форумчане. Пытаюсь разобраться с турбо-решетчато кодированной модуляцией (TTCM), возникло пару вопросов. Буду очень благодарен, если кто-нибудь поможет разобраться. Нашел схему ТРКМ кодера, она состоит из двух систематических сверточных кодеров, перемежителя и посимвольного деперемежителя. Как я понял, деперемежитель здесь поставили для обеспечения правильного выкалывания. Он гарантирует, что информационный бит обрабатывают либо верхним кодером, либо нижним, но никогда двумя одновременно и, следовательно, при выкалывании полезная информация не пропадет (поправьте, если ошибся). Вопрос такой: 1. Можно ли производить выкалывание без деперемежителя? В схемах с просто турбокодерами я не встречал деперемежителя, хотя там часто использовалось выкалывание. 2. Почему в ТРКМ используется систематический кодер? Для формирования "свободных битов"? 3. Зачем в схеме используется два 8PSK mapper? По логике можно поставить один после селектора. Спасибо.