vitaly_n

Сделал процесс, тактируемый от референсного клока, который смотрит на 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

---

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

Нисколечко! Было. Перерисовывал. Только где сейчас красивый экземпляр - не знаю.

Да, именно на таком принципе я разработал в 1992 году стабилизатор скорости вращения коллекторного двигателя для кассетного магнитофона. Работало просто замечательно! Схема примечательна тем, что выход фазового детектора сразу же используется в качестве ШИМ тока двигателя.

Взял датчик Холла из флопповода и посмотрел им на магнит ротора. Имеется 8 полюсов - 4 S и 4 N, приблизительно равномерно расположенных и приблизительно одинаково намагниченных. Взял программу SimInTech, задал в ней свою систему и добавил округление до целого (регистр ШИМ 8-битный). Если без округления переходный процесс довольно быстро устаканивался, то с округлением до целого процесс не устаканивается, а на нём образуется "пила" малой амплитуды. Т.е. мой цифровой ПИД-регулятор привносит грубость в управление, что приводит к возникновению автоколебаний ещё и по этой причине.