[johan 0]

Все по заветам Кена Чапмена(автора пикоблейза и 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 25]

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

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

 

[des00 25]

1. BERtest + идеальный matlab style декодер.

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

ldpc_release_21042015.7z

[des00 25]

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

[des00 25]

1. Отучил кодер от ограничений на размер интерфейса 2^N кратный pT pZF, теперь любое числое кратное pТ pZF.

2. Оптимизировал управление конвейером в декодере, выиграл немного тактов.

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

 

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

ldpc_release_27052015.7z

[des00 25]

маппер и мягкий демапер для модуляций 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

[des00 25]

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

Как то совсем забыл про матлаб. В итоге весь ряд модуляций (правда матлабовские 32 и 128 отличаются от ахашных).

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

demapper_release_01092015.7z

[des00 25]

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

[des00 25]

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

[des00 25]

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

 

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

gsfc_ldpc_release_22062016.7z

[des00 25]

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

hamming_29062016.7z

[des00 25]

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

bch_erasure_04062018.zip

[negiin 0]

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

[dvladim 0]

Offtop.

Послушайте Денис, Вы не думали завести репозитарий на github например для всяких таких поделок?

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

[x736C 0]

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

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

стр.103-105.

 

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

 

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