Всем привет!
Недавно начал писать диплом - и получил удар Verilog'ом, как обухом, по голове. Задача передо мною стоит невеликая, но с ходу окунаться в мир FPGA и низкоуровнего проектирования сложновато - поэтому попробую рассказать, что я хочу сделать и как хочу это сделать, а вас прошу высказать своё мнение - стоит ли так делать, или нет?

Я разрабатываю помехоустойчивый кодер - устройство, в которое входит поток битов (они должны делиться на блоки-слова по 7 бит) - внутри он преобразуется различными методами (кодирование Рида-Маллера - хитрое перемножение с матрицей), и на выходе мы встречаем блоки уже по 64 бита.

Использую для разработки Xilinx ISE WebPack 14.7, как язык описания - Verilog.

Как я представляю это себе на данный момент:
1. На входе, куда поступает непрерывный битовый поток, стоит регистр сдвига 1->8, упаковывающий всё в шину, чтобы дальше можно было работать с каждым битом на "отдельном проводе" (умножать каждый бит на вектор из матрицы). Если в реальности обрабатывать информацию поблочно так и принято, то этот блок "провод-шина" будет реализован чисто схемотехнически, как регистр с необходимым обвесом.
2. Реализация матрицы. Тут выходит на сцену Verilog. При выбранных мною параметрах кодирования, матрица ("порождающая", согласно алгоритму) будет иметь размерность 64x7 (7 строк). Фактически, она является постоянной и вполне определённой для каждого кода Рида-Маллера - так что можно её "захардкодить" как двумерный массив, но на мой взгляд это выглядит неэстетично. Хочется, конечно, реализовать её генерацию в зависимости от желаемых параметров кодирования, но я не уверен, что в проектировании железа и на вентильных матрицах в частности так поступают (ведь эта память неопределённого размера займёт немало места, и я не знаю, сможет ли матрица генерироваться каждый раз при поступлении в схему сигналов с другими параметрами кодирования, ведь это, по сути, нехилое изменение внутренней топологии схемы) - этот шаг больше подходит для классичесих языков программирования, как мне кажется.
3. Захардкодили мы матрицу, или нет - теперь просто перемножаем пришедший на неё блок информации на векторы, согласно позициям, которые занимают биты в исходном слове. Т.е. здесь опять очередь Verilog'а.
4. На выходе блока с матрицей получаем 64 символа. Если ход с регистром (п.1) подходит - в Xilinx ISE я нашёл от силы 16-разрядные регистры сдвига. Возникает вопрос - можно ли слепить из нескольких подобных один 64->1, сливающий шину воедино? Или модифицировать существующий (если его исходный код можно увидеть - я пока не докопался до него, но, по идее, такая возможность должна быть)? Или что?

Вот так, в структуре, на данный момент я вижу свою работу. Из всего текста выше (на случай, если многабукаф), вопросы: как реализовать в цифровой технике (а точнее - на FPGA) поблочную обработку поступающего битового потока и воссоединение его после воедино? И как стоит работать с матрицами констант? Задавать всё, что можно, жёстко, или пытаться наладить какую-то гибкость ради поддержания чувства прекрасного?

Буду премного благодарен толковым советам!

По поводу п 2. Если есть математика по которой считается новая матрица и нерезиновое число входов, задающих начальное значение с которого матрица считается, то можно сделать и инициализацию, записывая результаты скажем в двухпортовую память размерностью 64*7. Достоинство - фиксированный объем памяти. Недостаток - требование к ресурсам для начальной инициализации. Естественно инициализация требует усложнения и более трудоемка, делать или нет - решать вам, но дорогу осиливает идущий.
По п.4, если решили работать с верилогом/вшдл, то выбросьте из головы готовые схемные реализации и делайте регистры нужной длины. Даже при ограничениях в размере, есть возможность их соединения последовательно почти в неограниченном варианте.

Или что 16-разрядные сдвиговые регистры у Хилинха -- это LUTы, работающие в режиме сдвигового регистра (описано в документации на соответствующую ПЛИСину). Никакого исходного кода для этого, естественно, нет -- это готовый низкоуровневый примитив, прямо отображаемый на железо. При желании можно использовать такие примитивы и конструировать из них то, что требуется, но обычно лучше описывать требуемую логику работы (поведение), а не схему, реализующую эту логику, и предоставить формирование схемы Изе. Правда, вручную нередко можно сделать эффективнее, но это и сложней, дольше, и непереносимо (приходится закладываться на конкретное семейство ПЛИС, и при переходе на другое, даже той же фирмы, созданный таким образом код может потребовать существенных переделок). В общем, ручное кодирование схемы имеет смысл только тогда, когда надо выжать максимум или же когда "логическое" описание уж очень неэффективно по сравнению со "схемным" -- а такую ситуацию ещё нужно придумать

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Математика - слишком сложное определение для того, что там происходит По факту матрица, которую я буду использовать, строится простым чередованием 0 - 1 в таком духе:
11111111
00001111
00110011
01010101
И, пожалуй, главное (чего я почти не коснулся в посте) - матрицы отличаются друг от друга размерностью, а не наполнением (бОльшие матрицы - просто расширенные меньшие). Т.е. одной паре чисел, задающей код RM(r,m), соответствует ровно одна матрица уникального размера. И изначально я хотел, чтобы была возможность задавать параметры кода и соответственно генерировать под них матрицу, но теперь думаю, что если и делать так - то разрешать менять числа-параметры только в меньшую сторону, чтобы при желании можно было работать не со всем массивом памяти (использовать менее "мощный" код), но нельзя было выйти за максимально возможный размер этого массива (те же 64x7).

Хорошо, пожалуй в самом деле лучше держать проект "чистым" и "однородным" - к тому же уже представил, как можно по-человечески реализовать на HDL простой регистр, и в Интернете, думаю, точно найдутся подсказки в этом направлении

SII, спасибо за подробное разъяснение! Пожалуй, займусь логикой

З.Ы. Пока что на языке Верилога представляю себе описание регистра (например, первого) как массив памяти длиной 7 бит (изначально заполненный нулями), где по каждому, например положительному, фронту тактовой последовательности хранимое в каждой ячейке значение, начиная с предмладшего бита, переносится в следующую ячейку (и старшему биту назначается пришедший извне) - а каждые 7 импульсов происходит назначение ("выгрузка") содержимого регистра желанной шине. В ту сторону копаю?

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

О, раз тему подняли, то спрошу ещё по делу

Пытаюсь оседлать синхронизацию. По моей текущей задумке, информационный сигнал должен поступать к нам через один такт после прихода на кодер по отдельному проводу импульса "Поехали!" от источника сигнала. Т.е. слова будут приходить поочерёдно (ибо выходное слово длиннее в 8 раз) с промежутками в N времени, каждое - после такого предпреждающего импульса.
Что я хочу сделать? Чтобы сигнал тактирования в кодере в целях синхронизации запускался после прихода импульса "Поехали!" (и умолкал после прихода последнего бита слова - такой функционал уже реализован), так как из-за пространственного разноса источника и кодера (и управления источником со стороны кодера) промежутки между словами могут оказаться неравномерными.
Программа "минимум" - реализовать запуск после прихода "Поехали!" тактирования с захардкоженной частотой (пока тестирую через написание verilog test fixture), программа "оптимум" - реализовать тактирование импульсами длительностью, равной вышеупомянутому "Поехали!".

Вопрос по программе "минимум" - можно ли в Verilog test fixture привязать "нулевое время" к наступлению какого-нибудь события? Т.е. отрицательного фронта сигнала "Поехали!", например. В интернете подобных примеров ещё не находил - до сих пор описываю тактирование как простое
Или в Xilinx ISE можно реализовать генератор тактов полноценным отдельным модулем (который бы и управлялся тем самым "Поехали!")?

Вопрос по программе "оптимум": можно ли на Verilog или в самой ISE измерить длительность одиночного импульса и задать по ней своё тактирование? Или, ещё лучше - "сфотографировать" этот импульс и, опять же, зациклить?

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

ЗЫ. Вопрос, с которого, наверное стоило и начинать - а как на практике реализуют смещение от начала импульса, чтобы стробирование проводилось по устоявшемуся значению сигнала? Потому что сначала я думал, что эта проблема меня не тронет, а теперь из-за небольших задержек (в 3-4 элемента) получаю иголочки, да не на ёлочке

Тут изображён результат моделирования счётчика, который после прихода "count_on" на каждый седьмой тактовый импульс выдаёт сигнал "CB4CE_7" (который в том числе отключает счёт до прихода нового "count_on").

Можно. Делаю так, описываю сдвиговый регистр (минимум два разряда) в который на частоте тактирования (период должен быть меньше длительности ловимого сигнала) заталкивается сигнал.
Затем по состоянию регистра 01 или 10 можно выделить передний или задний фронт.
По оптимуму - если длительность сигнала много выше одного-двух периодов тактирующего сигнала, то используя "детектор фронтов" можно запускать и останавливать счетчик, на выходе которого будет длительность сигнала в тактах. Обычно делаю для этого тот же сдвиговый регистр но на три разряда и по состояниям:
001 - обнуляю счетчик;
011 - разрешаю счет;
100 - останавливаю счет.
С иголочками - поставьте между выводом результатов и счетчиком параллельный регистр (можно затактировать инверсией, но это не всегда хорошо) мелкая дрожь перестанет докучать.
По графику, наличие "красной зоны" у сигнала косвенно свидетельствует об одновременной попытке влияния нескольких источников на сигнал (возможно из разных модулей/эвентов). На vhdl это решается через промежуточный сигнал.

Meteor, спасибо за скорый ответ!
Насчёт программы "минимум" - или ты не понял моего вопроса, или я - твоего ответа
Я спрашивал относительно верилоговских файлов, которые создаются специально для тестирования отдельных модулей - в которых задаются состояния сигналов на входах с привязкой ко времени. Хотя пока я писал это, то уже, кажется, понял, что если в этих файлах.V мы описываем все состояния входов вручную, то и все эти условные зависимости отпадают - должны быть учтены в самом модуле. А в тестовом файле всё предопределено Так что, если меня просветлило в нужную сторону - то в тестовом файле так и нужно оставлять простое "перещёлкивать каждые N наносекунд", а в модуле уже воплощать описанный тобой регистр, который решит - пора, или не пора?)

Насчёт иголочек и красной зоны - я, честно говоря, думал, что эта красная зона - и есть неопределённость, возникающая из-за "иголочки", которая возникает из-за крохотного несовпадения фронтов Думаю, стоит показать схему, чтобы не возникало смуты.


Коротко схему опишу: Это счётчик CB4CE и компаратор COMP4, сбрасывающий счётчик по каждому седьмому импульсу. Мне нужно получать управляющий импульс (на CB4CE_7) по каждому седьмому такту clk_in. Так как компаратор сбрасывет счётчик моментально и всё пропадает (в т.ч. сигнал с выхода компаратора), я сделал ответвление с выхода счётчика на правый триггер FDC (через элемент "И", символизирующий приход седьмого импульса), чтобы запомнить сигнал на один такт (по идее, можно использовать и моментальный сигнал с выхода компаратора, но в таком случае на выходе ничего не появлялось. Видимо, в моей реализации оно появлялось только по счастливой случайности в рез-те моментального совпадения фронтов ) Всё работало, как надо, но только в постоянном режиме - я начал реализовывать схему "одинарного" счёта - по приходу управляющего импульса count_on и с ожиданием этого импульса в любой момент. Тут мне понадобилось добавить самописный delay_1, чтобы запомнившееся в правом FDC значение сбрасывалось через такт той же "единицей", которая в него значение и записала, а также добавить левый FDC - чтобы разовый "count_on" при помощи Vcc превращался в постоянное "1" для входа CE счётчика до сброса, который произойдёт при приходе седьмого импульса
результат накоженного и насхемотехниченного - на рисунке в предыдущем посте
Пока писал - понял, что главная проблема, видимо, всё-таки в занесении всех значений в триггеры в шаткий миг переключения - поэтому иногда получается хорошо, иногда - ничего, иногда - иголочки с непонятным финалом.
И насчёт использования сигнала с выхода счётчика или компаратора - либо эта проблема решится занесением значений в стабильном состоянии, либо:
как вытащить моментальный каприз компаратора и превратить его в человеческий импульс нормальной длительности другими методами?

А почему не делать импульс просто при состояни счетчика 0? Тогда он будет длиться целый такт. И еще, CB2CE вам даёт обалденно асинхронную схему. Поэтому и приходится вычислять все задержки до и после реализации. ПЛИС предполагают реализацию проекта, по возможности, максимально синхронно. Тогда нет такой проблемы как "иголочки".

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