vitaly_n

Всем привет! Дано: имеется некий абстрактный канал передачи данных. Имеется детектор, который как-то принимает (аналоговый) сигнал и выдаёт принятые символы Xi. Помимо этого детектор выдаёт дополнительную информацию о "качестве" приёма каждого i-го символа Li. Тут задача разбивается на две подзадачи - одна задача, если этот сигнал о "качестве детектирования" бинарный (0 или 1), вторая задача - если этот сигнал аналоговый (например, в диапазоне от 0 до 1). Теперь предположим, что по этому каналу мы передаём блоки информации с кодом контроля целостности блока, например, CRC. Этот CRC мы можем закодировать помехоустойчивым кодом с большей избыточностью, чем основной блок данных, если это поможет нам в решении задачи. Итак, мы принимаем блок данных. Считаем принятый CRC с вычисленным от принятого блока. Если расстояние Хэмминга не более определённой разработчиком кода величины, скажем, не более 1-2 ошибочных бит, то считаем, что это ошибки в приёме CRC, а сам блок данных принят без ошибок. Иначе считаем, что сам CRC принят без ошибок, а ошибки случились в блоке данных. Все коды, контролирующие и исправляющие ошибки, которые я видел, работают только с основным каналом передачи данных, вообще не принимая к сведению вот эту дополнительную информацию о качестве детектирования символа, которую мы-то можем получить от приёмного детектора. Обычно считается априори качество приёма всех символов одинаковым и вероятность ошибки в этом символе тоже одинаковая. Например, вычисляется синдром, который сразу нам показывает, какие символы были приняты ошибочно, чтобы по методу максимального правдоподобия выбрать наиболее близкое кодовое слово. Предлагается использовать информацию от детектора о качестве приёма для использования в качестве "синдрома", чтобы улучшить восстановление данных - считать вероятность ошибки в символе не постоянной, а выше у тех символов, у которых качество приёма ниже. Вопрос, собственно, вот в чём. Чую, что изобретаю велосипед. Соответственно, кто может подсказать, как это правильно называется по-русски и по-английски, чтобы задать вопрос гуглю, а то, может, сразу назвать автора и статью (книгу)?

Маркировка подходит, но в даташите только LGA 12 корпус, а тут 14 падов...

Большое спасибо!!!

Пожалуйста! Я знаю, что это 3-осевой акселерометр, но больше ничего про этот чип не знаю, а надо! Спасите-помогите!

Сделал процесс, тактируемый от референсного клока, который смотрит на LOCKED. Если LOCKED в течение 1 ms не поднялся (согласно DS162 PLL должен выставлять LOCKED max 100 us), то выставляю PLL_RESET на 50 ns (согласно всё тому же DS162 RST min 5 ns). С таким "костылём" вроде бы заработало. 30 раз питанием щёлкал - всегда заводится. Спасибо!

А кто бы его знал... Когда я его вывожу на пин - всё замечательно работает! Спасибо за подсказку! Попробую...

HELP! Ситуация такая. Имеется Spartan 6 45t в корпусе 484. На него заходит 100 МГц LVDS с хорошего кварцевого осциллятора. Загоняю это дело на PLL, получаю с него частоты 800 МГц (IOCLK для serdes), 160 МГц и 80 МГц (фаза 0 и фаза 180). Из этих двух 80 МГц при помощи ODDR2 и OBUFDS получаю выходной LVDS сигнал 80 МГц. Казалось бы, всё просто, как мычание. Однако, обнаружил пренеприятнейшее явление - при включении питания эта зараза не всегда запускается! Примерно 1 раз из 10 генерации на выходных ножках нет. Однако, если я изменяю проект - вывожу с PLL сигнал LOCKED на IOB пин, к которому подключен транзистор со светодиодом, чтобы визуально проконтролировать, эта сволочь запускается всегда! Т.е. отличие только в том, вывожу ли я LOCKED на пин или нет. Очевидно, дело вообще не в этом, а просто проект иначе раскладывается, но поведение удивительное. Подскажите, пожалуйста, на что обратить внимание, чтобы разобраться в проблеме? В UCF прописаны тайминги на входной клок 100 МГц (период 10 нс 50%), остальное ISE 14.7 само понимает из параметров конфигурации PLL. All constraints, само собой, met.

Разумеется есть. Я подозреваю, что у них проблема с отслеживанием переключения между ранками при чтении. Соответственно, могу предложить два варианта: 1) вручную отслеживать переход между ранками и дробить операцию чтения. 2) сделать свой интерфейс. Я, например, ещё для Spartan 6 сделал свой интерфейс DDR2, который вычитывал параметры модуля из SPD флэшки и соответственно подстраивался. (Не так страшен чёрт, как его малюют!) Именно так я обнаружил, что при чтении подряд нескольких пачек при переключении между ранками (сначала читали пачку из одного ранка, а потом хотим читать пачку из второго ранка) нужно между операциями чтения вставить хотя бы один такт паузы, в отличие от ситуации. когда мы читаем из одного ранка - тогда между пачками чтений никаких дополнительных пауз не требуется.

Отбой! Тревога оказалась ложной. Проблема была в разъёме - коротило на землю. Всем откликнувшимся спасибо! Извините!

XC6SLX45T FGG484DIV1645 D5046987A 2C

Всем привет! Имеется плата с Spartan 6 LX45T. Из неё выходит несколько пар LVDS_33 комплектами DATA+CLK (по две пары на разъём). Логика, выдающая сигналы на разъёмы, одинаковая. В UCF описаны идентично. Трансляция, map и PaR проходят без замечаний. Почти все разъёмы работают правильно, за исключением пары W10+Y10. Осциллографом смотрю - вижу, что напряжения на ней не LVDS_33. Один сигнал похож на LVCMOS33, а второй в нуле болтается. Меняю в UCF LOC у выходов c W10 и Y10 на какую-то другую пару в том же банке, например, Y17+AB17 - на этой паре осциллограммы вижу правильные. Проблема не в разводке. Идентичное поведение наблюдается на двух платах. Что за ерунда с W10 и Y10? Это лечится?

Всем привет! Прошу помощи. Кто-нибудь знает, как правильно пользоваться сигналами fc_* из ядра PCIe? Вообще суть проблемы такая. Имеется плата с Spartan 6 45T. Firmware предоставляет регистры для записи-чтения по инициативе процессора (как memory), через них задаётся, что делать. Потом firmware делает запросы к памяти (DMA). Я реализовал flow control по четвёртому методу DATA_FC из UG672. Значения Total_CplH и Total_CplD брал, как рекомендовано, из таблицы E-1 (для моего случая 32 и 256 соответственно), хотя там дальше говорится: In the case where infinite credits have been advertised to the Link Partner for a specific Credit pool, such as Completion Credits for Endpoints, the user application should use this value along with the methods described in Appendix E, Managing Receive-Buffer Space for Inbound Completions to avoid completion buffer overflow. И до поры, до времени всё работало замечательно, но вот я нарвался на то, что передача данных затыкается при работе с процессорным модулем ComExpress - запросы из FPGA MEMORY_READ ушли, а ответов на них не пришло. Подозреваю, что у этого модуля более суровые ограничения на число запросов в очереди. Решил посмотреть на то, какие значения выставляются на fc_ph, fc_pd, fc_nph, fc_npd, fc_cplh и fc_cpld для разных значений fc_sel в разные моменты времени. Должен сообщить, что значения эти выглядят странными и непонятными, причём, я не нашёл какого-то внятного user guide, чтобы там объяснялось, как этими сигналами правильно пользоваться для целей flow control. Например, для fc_sel=000 (Receive Credits Available Space) значения такие: fc_ph = 32, fc_pd = 211, fc_nph = 8, fc_npd = 8, fc_cplh = 40, fc_cpld = 211 (Крайне смущают очень маленькие значения для fc_nph и fc_npd.) для fc_sel=100 (Transmit Credits Available Space) значения такие: fc_ph = 12, fc_pd = 80, fc_nph = 12, fc_npd = 1, fc_cplh = 0x7F, fc_cpld = 0x7FF (в соответствии с таблицей 5-17 из UG672 значения 0x7F и 0x7FF обозначают Infinite credits available). Я правильно понимаю, что мне надо взять fc_nph = 8, fc_npd = 8 вместо 32 и 256 для Total_CplH и Total_CplD?

Имеется плата - FPGA Spartan 6 LX9, к ней присобачена SDRAM IS42S81600F-7TL. Частота CLK 128 МГц, CL=3, BL=1. Режим работы такой - прилетают данные, их записываем в SDRAM, вместо них вычитываем из SDRAM другие данные. Пока пакетов данных нет - крутим AUTOREFRESH с периодом примерно 90 нс. Столкнулся с вот какой неприятной проблемой - первое чтение после авторефреша почему-то задерживается - шина DQ из третьего состояния переходит в активное с опозданием, в результате я читаю не то, что должно быть прочитано, а то, что осталось висеть на шине после предыдущей записи. Потом идут ещё 300 с лишним циклов записи-чтения, они пишутся и читаются идеально, без вопросов. Проблема только с первым чтением после простоя, заполненного авторефрешами. Сдвигаю фазу клока стробирования чтения - становится заметно лучше, но не насовсем. Если при нулевой задержке все первые чтения неверные (но последующие чтения правильные!), то при задержке 1.9 нс неверных чтений остаётся где-то четверть, при задержке 2.9 нс неверных чтений процентов 10, задержка 3.9 нс - это уже перебор. Кто сталкивался с чем-то подобным?

Всё! Задача решена! Частота и фаза стоят, как вкопанные! Подобрал коэффициенты ПИД-регулятора, правда, сильно задрал П-компоненту, в результате управляющий сигнал на двигатель сильно скачет, но зато вал крутится очень равномерно и стабильно. Даже при старте воспроизведения с кассетой уползание фазы пренебрежимо мало. Потом как-нибудь аккуратно померю девиацию - доложу. А пока результат меня абсолютно устраивает. https://youtu.be/6T1rNlHNHKU