FEC на ПЛИС, пиарю красоту SV Опции

[johan]

Все по заветам Кена Чапмена(автора пикоблейза и Xilinx гуру): When creating each section of a design, simply ask, “Does this bit need to be reset”?
Все в системе определяется по сигналу валидности и состоянием конечного автомата, смысла сбрасывать другие сигналы нет. Помимо этого, на некоторых платформах (где триггер может быть только с одним типом сброса), можно потерять в ресурсе или производительности.

Благодарю за ответ.
Со временем тоже пришел к аналогичной философии: сбрасывать только то, что надо сбрасывать. Но иногда лень берет своё, и сбрасываю всё.
Недавно копался в интерконнекте Альтеры, и заметил, что они тоже "ленятся", и как-то общих рекомендаций и философии не прослеживается.
Видимо от самих разработчиков этих модулей зависит.

То сбрасывают всё:

Код

    
// altera_avalon_st_pipeline_base.v
// data1 - "широкие данные", включают в себя avalon-st startofpacket, endofpacket, data, channel и error, empty
always @(posedge clk or posedge reset) begin
if (reset) begin
  data1 <= 'b0;
  full1 <= 1'b0;
end
else begin
  if (in_ready) begin
    data1 <= in_data;
    full1 <= in_valid;
  end
end
end

А вот тут наоборот, сбрасывают только то, что надо

Код

// altera_st_delay_reg
always @(posedge clk or negedge reset_n) begin
   if (!reset_n)
      out_valid <= 1'b0;
   else
      out_valid <= in_valid;
end

always @(posedge clk) begin
   out_data          <= in_data;
   out_channel       <= in_channel;
   out_error         <= in_error;
   out_startofpacket <= in_startofpacket;
   out_endofpacket   <= in_endofpacket;
   out_empty         <= in_empty;
end

[des00]

Видимо от самих разработчиков этих модулей зависит.

Скорее от лени и прилежания Обычно после получения необходимой функциональности и закрепления результатов, я провожу ручной рефакторинг кода (удаляю все ненужное, делаю расширенные комментарии, правлю описания сбросов, убираю большинство варнингов синтеза и т.д.). Т.е. рассматриваю код как товарный продукт. Да это "шашечки", но зато всегда могу вернуться к коду и понять как он работает. Ну а кому то нужно "ехать" и они забывают заветы Ф. Брукса о том что написание кода это 15% от всего проекта

[des00]

1. BERtest + идеальный matlab style декодер.
2. идеальный RTL like декодер (один шаг до RTL реализации для любого разработчика). Содержит параметр pLLR_BY_CYCLE - количество метрик обрабатываемых за 1 такт. Должно быть меньше чем expansion factor.

Прикрепленные файлы

 ldpc_release_21042015.7z ( 14.94 килобайт ) Кол-во скачиваний: 96

 

[des00]

Wimax LDPC кодек со статической конфигурацией. Поддерживаемые скорости 1/2, 2/3B, 3/4A, 5/6.

Метод декодирования 2D normalized Min-Sum. Декодер работает с прямыми метриками, ширина интерфейса определяется количеством метрик обрабатываемых за 1 такт. Количество метрик за такт должно быть кратно размеру T матрицы H (24). expansion factor (Zf)

Результаты декодера на плис средние. Сыклон 4, спидгрейт с7, длина 2304, скорость кодирования 5/6, 8 метрик за 1 такт, разрядность метрики 5 бит: 11872LC, 6624Reg, 37 M9K, тактовая 210 МГц. Тормозит генерация адресов памяти, т.к. в ваймаксе есть нечетные сдвиги, что делает невозможным работу с блочком памяти в режиме больше 1 метрики.

Тестбенч бертест, кпск, 2/4/6/8/16 метрик за такт. Время декодирования = 2*((Niter + 0.5)*length/кол-во метрик за такт) + латентность порядка 30 тактов).

PS. Совсем забыл, для смены скорости кодирования для синтеза, нужно запустить моделирование этой скорости. К сожалению ква 9.1 не смог синтезировать генерацию таблицы адресов. Поэтому таблица генерируется и пишется в файл, ква уже работает с готовой таблицей

Прикрепленные файлы

 ldpc_release_13052015.7z ( 24.58 килобайт ) Кол-во скачиваний: 64

 

[des00]

1. Отучил кодер от ограничений на размер интерфейса 2^N кратный pT pZF, теперь любое числое кратное pТ pZF.
2. Оптимизировал управление конвейером в декодере, выиграл немного тактов.
3. Сделал декодер с разделенным входным буфером и более сложным управлением. В зависимости от размера блока памяти потребуется больше, но зато можно совместить последнюю полуитерацию декодирования с загрузкой рабочей памяти новыми данными.

Этот релиз последний.

Прикрепленные файлы

 ldpc_release_27052015.7z ( 46.25 килобайт ) Кол-во скачиваний: 154

 

[des00]

маппер и мягкий демапер для модуляций BPSK, QPSK, 8PSK, QAM16, QAM32, QAM64, QAM128, QAM256, QAM1024.

Созвездия:
BPSK - повернуто на 45 грудусов
QPSK, QAM16-QAM256 - из доки от AHA.
8PSK - повернуто на 22.5 градуса.

Метрики квадратных КАМов, BPSK, 8PSK - конфигурируемой разрядности, остальные нечетные КАМы - фиксированные 4 бита. Метрики = логарифм отношения надежностей битов символа, при условии sigma^2 = 0.5

Результаты на арию 5 С5: демапер 623/791 ALM/Reg, частота за 300 МГц

Тестбенч простой, просто проверяет только жесткое решение.

ЗЫ. Разыскивается созвездие КАМ512. Можно свое нарисовать, но несколько часов терять не охота

Прикрепленные файлы

 demapper_release_31082015.7z ( 8.54 килобайт ) Кол-во скачиваний: 94

 

[des00]

ЗЫ. Разыскивается созвездие КАМ512. Можно свое нарисовать, но несколько часов терять не охота

Как то совсем забыл про матлаб. В итоге весь ряд модуляций (правда матлабовские 32 и 128 отличаются от ахашных).
Немного поэкспериментировал с ква, странно но generate for дал более хороший результат, чем процедурный for + перевел таблицы кам128 и 512 на использование разбиения таблиц блоками 8х8, вместо 16х16. Это дало суммарную экономию ~250 плиток. Итоговый результат на полный демаппер 852 ALM, 1076 регистров, частота упала до 280МГц (еще один слой регистров добавлять лень, да и целевая у меня 250).

Прикрепленные файлы

 demapper_release_01092015.7z ( 10.25 килобайт ) Кол-во скачиваний: 92

 

[des00]

LDPC Кодер (7154, 8176) для стандарта GSFC-STD-9100. При работе с 7ми битными словами параметры кодера для Aria V : 3610ALM/~275МГц, производительность > 1,5Гигабит в сек.

[des00]

LDPC Кодер (7154, 8176) для стандарта GSFC-STD-9100. При работе с 7ми битными словами параметры кодера для Aria V : 3610ALM/~275МГц, производительность > 1,5Гигабит в сек.

Кодер работал неправильно, вот что значит читать стандарты по диагонали Архив прибил.

NASA GSFC LDPC codec 7154/8176 (GSFC-STD-9100).

В аттаче : RTL кодер, декодер идеалка и самая медленная версия RTL декодера, работающая по 4 нода за такт и с не буферизированным выходом. Ресурсы для Арии 5 : ALM/REG/M10K 565/1218/24. Оцененная частота для С5 261.44 MHz. Более быстрые декодеры уже сами

Прикрепленные файлы

 gsfc_ldpc_release_14062016.7z ( 27.47 килобайт ) Кол-во скачиваний: 44

 

[des00]

Немного почистил код, оптимизировал сигналы готовности vnode/cnode движков, проверил режим работы с большим количеством метрик за такт.

Набираю информацию по F-LDPC кодам(GRA коды). Может у кого есть хорошая подборка?

Прикрепленные файлы

 gsfc_ldpc_release_22062016.7z ( 27.33 килобайт ) Кол-во скачиваний: 68

 

[des00]

Делаю подходы к TPC : кодер Хэмминга. Совершенный, расширенный, в систематической форме.

Прикрепленные файлы

 hamming_29062016.7z ( 4.05 килобайт ) Кол-во скачиваний: 67

 

[des00]

Появилось окно. Стало скучно. Таки добил старый TODO. БЧХ со стираниями, работает на лету, 250 мегабит на ария 5.

Прикрепленные файлы

 bch_erasure_04062018.zip ( 26.97 килобайт ) Кол-во скачиваний: 30

 

[Denisnovel]

Где можно почитать про декодер со стираниями? Можно ли их использовать для итеративного декодирования?

[dvladim]

Offtop.
Послушайте Денис, Вы не думали завести репозитарий на github например для всяких таких поделок?
Мне кажется это было бы удобнее, если Вашим работам разрешено находиться в открытом доступе.

[x736C]

Где можно почитать про декодер со стираниями? Можно ли их использовать для итеративного декодирования?

Р. Морелос-Сарагоса «Искусство помехоустойчивого кодирования. Методы, алгоритмы, применение».
стр.103-105.

В случае с БЧХ-кодами получаются две итерации декодирования.

dvladim, присоединяюсь.