Pull to refresh
12

User

6
Subscribers
Send message

Соглашусь, эти сигналы групповые и действуют на весь LAB/CLB, единичный триггер "выбивает" своих братьев). Если про это забывать при проектировании, то можно потом поплатиться. Скорее всего по этому синтезаторы и стараются так не делать)

А про сбросы я олдскульный сторонник Ken Chapmen, который свое мнение выразил в wp272 "Get Smart About Reset: Think Local, Not Global". Сторонник настолько, что порой рекомендуемые стили RTL описаний, которые студенты используют на лекциях с обобрения преподавателей вызывают как минимум недоумение)

я ж имею право его дохера-разрядным сделать (например, просто integer объявить). А синтезатор со своей стороны имеет право старшие разряды убрать, если они ни на что не влияют.

Можете сделать его любым, остальное определится крутостью синтезатора по разбору вашей логики. В каких то базовых простых случаях ему хватает мозгов понять что старшие биты не используются, но если условий много или счетчик реверсивный или еще что-то может и не хватить. Да и в целом типизация в SV есть, сделали нужные локальные параметры, описали типы и вперед, без таскания кучи logic [PIPA_W-1 : 0] pipa; по коду)

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

Но, позвольте только немного "покритиковать".

Стрелка 1 — момент семплирования (оба устройства защёлкивают входы), 2 — момент выставления следующего бита (drive/shift):

У вас картинка не совсем верная относительно MISO, по ней мастер защелкивает мусор, т.к.попадает на фронт.

Использовать Pure verilog в наш 21 век? Понимаю что скорее всего дело в икарусе, но мир RTL разработки ушел значительно дальше с тех пор. Некоторые элементы показанного кода, на текущий момент, считаются плохим стилем во многих компаниях. Например: константы на дефайнах, отсутствие оперторных скобок если выражение занимает более чем 1 строку и т.д.

Секвенциальный - не совсем понимаю почему вместо перевода sequential logic - "последовательная логика" использован такой англицизм. Да, в начале статьи вы упомянули что используете собственные термины, но тем не менее)

Эталонную модель для отладки все же более правильно писать в behaviour стиле, не в стиле RTL. Потому что в таком случае, как вы сами заметили, у вас еще появляются баги эталонной модели, в том числе из-за ее параллельности. Наверное тут тоже сказывается влияние pure verilog и икарус, т.к. в SV делать это намного проще.

Про метастабильность сигналов расписано правильно, но в контекте MISO я бы не был так уверен что она ему нужна. Да, этот сигнал асинхронен относительно системной тактовой частоты, но он синхронен относительно частоты SPI (в вашей IP это "частота" момента семплирования). При используемом вами методе индексирования бита при записи, эффекты отсутствия(как и присутствия) синхронизатора по MISO могут вылезти с ростом частоты, но с учетом того что в вашем IP предполагается SPI clk <<< System CLK, полагаю что этого не будет. Никакие управляющие структуры от этого сигнала у вас не зависят.

Это не столько критика вашего решения, сколько отметка факта что "слепая" борьба с метастабильностью не есть хорошо. Это сделает например "невозможным", по мнению части людей, разработку SPI слейва где частота SPI = 50-100МГц. Ведь там, для синхронного дизайна, для надежного оверсемплинга нужно уходить на тактовые за 300МГц)

Если рука тянется написать always @(posedge clk or posedge some_signal) где some_signal — не сброс, остановитесь и перечитайте главу 6.

Несколько категорично, есть плис с триггерами с возможностью асинхронной установки без использования инверсии выходного сигнала) Причем вы используете сыклон4, у него в архитектуре есть "бесплатные" по вашей терминологии синхронная установка и сброс, вы можете использовать их и не тратить один вход у люта. Правда старые квартусы не очень любят их использовать при синтезе конечно, но думаю что в новых эту проблему решили.

Полагаю что этот пункт вы указали потому что в большинстве ПЛИС из того что точно есть это асинхронный сброс) Наверное стоит несколько раскрыть категоричность данного пункта статьи)

Спасибо еще раз за статью, переслал знакомым "молодым бойцам" для экономии времени обьяснения им "зачем мне эта верификация, я пишу сразу рабочий код")

Ни в одном из этих применений ни отношение EbN0/EsN0, ни приближение к пределу Шеннона ничего не скажут заказчику.

Вам конечно виднее, но как человек который разработал и внедрил большое количество различных кодеков FEC в системы радиосвязи, могу сказать что заказчики всегда смотрят на кривые кодирования(энергетику). Вы же пишете не только про системы данных и провода, а именно про системы радиосвязи. А без кривых кодирования нет базы. ИМХО любые попытки подменить стандартую метрологию, похожи на попытки выдать желаемое за действительное)

Беру пазу на изучение ваших ссылок и статей.

Спасибо за литературу, посмотрю.

С моей точки зрения такое представление ближе к физическому смыслу и облегчает понимание. Из рисунка видно, что с кодом Рида-Соломона вероятность безошибочного приема падает до нуля при вероятности ошибки в канале более 0,07, а при голографическом кодировании безошибочный прием обеспечивается при вероятности ошибки 0,4 (40% передаваемых бит искажены).

Точки зрения бывают и разные, но стандартную метрологию это не отменяет). Коэффицент ошибок в канале, в котором вообще нет информации это 0.5. Коды РС я бы вообще не рассматривал в качестве альтернативы, т.к. они исправляют символ и их корректирующая способность сильно зависит от распределения ошибок. При неудачном стечении обстоятельств можно получить корректирую способность по битовым ошибкам в 2^"размер поля" раз меньше чем при самом удачном случае)

Сравнивать разные методы по этому показателю можно, но как понять, каков максимально допустимый процент ошибок?

matlab - bertool, там можно выбрать нужную модуляцию, задать пороги EbN0, получить кривые для некодированной модуляции. Потом перевести в EsN0(SNR) и сравнить или воспользоваться функцией berawgn и EsN0 = EbN0 + 10*log(bit_per_symbol)

Но проще, при наличии кодека, провести стандартный bertest на наборе хотя бы 1е6 бит.

Мне кажется что стандартная метрология более наглядно покажет ваш кодек, в том числе с точки зрения понимания сколько еще есть энергии до предела Шенона.

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

Статья интересная, как и тема FEC в целом. Спасибо.

А можно поделиться списоком базовой литературы по вопросу? Хотя бы материалы рекомендованные к начальному рассмотрению?

Не совсем понимаю использованную метрологию в первом рисунке. Обычно кодеки соревнуются в кривой BER/FER vs EbN0(EsN0). Вот такое "выворачивание" характеристики вносит сумятицу в анализ результатов, особенно для тех кто не в теме, из-за того что кривая кодирования, в области низких отношений EbN0/EsN0 очень плавная и там увеличение ошибок в 2 раза, это не "огого в 2 раза", это "всего" 0.1-0.2дБ..

Например, возьем тот же стандартный VL-SNR DVB S2x. Самый дальнобойный его вариант VL-SNR set 1 BPSK-S 1/5 (pi/2 BPSK 1/5 Spreading Factor 2) обеспечивает BER меньше 1е-6 при EsN0 ~= -9.5дБ. Его избыточность 1/10. Делается "за копейки левой задней ногой". Вот как это можно сравнить с вашими результатами?

Народ, вы не позорьтесь, ЦАП настройте. А то ваш найквист, всем найквистам найквист: ни в одну маску спектра не войдет, соседние каналы положены наглухо. Вангую что у вас не выставлены режимы ЦАПа: где-то offset binary вместо signed two compliment или наоборот.

Прекрасная статья, но "матрица пермутации" это уже совсем ни в какие ворота. Вы же сами пишете "матрица перестановок", зачем вот так сильно над языком издеваться.

Не путаю. На этой книге выросло не одно поколение модемщиков. Гуглить по ключевым словам Nezami Rf Architectures

Не путаю, на этой книге выросло не одно поколение модемщиков. Легко гуглится по ключевым словам Nezami Rf Architectures и бла бла бла.

Портировать вам никто не мешает, но играть параметрами фильров, петель, ару и прочим гораздо проще в среде типа симулинка.

Упорство конечно похвально. Но зачем заниматься разработкой модема в слепую? Учебник по связи незами, там, в нескольких главах описано как правильно делать когерентый демодулятор: согласовнная фильтрация, восстановление несущей, символьной частоты, синхронизация потоков данных и т.д. И вот как раз базовые модели модемов в симулинке, от модемных гуру, доступные в сети в этом очень хорошо помогают)

Докучи в статье еще куча пафоса. Копейками названо 150т.р при медианной по стране ~40т.р это как? Автор давно по стране то ездил и смотрел как работают замкадом, например в какой нить Сибири. Что такого должен делать коллектив сеньоров, ну положим человек 20 за 300-500т.р в месяц каждый на руки, чтобы их места были экономически обоснованы? Вот такую статью от автора я бы почитал)

Для начала "ремонт" приборов по гарантии. Дальше будет видно. К сожалению, как понимаю, закон о защите прав потребителей не работает в случае договоров между юрлицами. Будь я физиком было бы намного проще.

Потому что негодования здесь нет. Вместо него легкий троллинг компании выпустившей сырой и не проработанный прибор на рынок и кинувшей покупателей своей продукции, сменой функциональности прибора "задним" числом. Кто-то скажет что это норма, но меня это как минимум удивляет) Также удивляет как вообще приборы, не выдерживающие заданную скорость трафика, получили государственный сертификат средства измерения.

Согласен. Поэтому и написал сразу: вполне возможно что просто не обновляли номер. Но ИМХО качество - оно в мелочах, даже в таких как строка копирайта.

Тоже так подумал, но серийные номера приборов есть на фото 8689 и 8785. Т.е. приборов выпущено как минимум 100 штук. Кто-то же их использует, не лежат же они на складе.

Information

Rating
4,717-th
Registered
Activity