Перейти к содержанию
    

spectr

Свой
  • Постов

    281
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о spectr

  • Звание
    Местный
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

4 060 просмотров профиля
  1. Можно попробовать вывести на пин в топлевел и сделать его виртуальным.
  2. Не-не, это не совсем то. Pre-, Center-, Post- показывает какой участок данных будет записываться сигналтапом при срабатывании триггера. Соответственно, будет записываться: 1. Pre: То что происходило ДО срабатывания триггера. 2. Center: То что происходило до и после срабатывания триггера (поровну - т.е. при длине сигналтапа 1024 сэмпла, будет записано 512 сэмплов до и 512 сэмплов после триггера). 3. Post: То что происходило после срабатывания триггера. Вам же надо настроить условия срабатывания триггера на вкладке Setup, которая рядом с времянкой: Если сигналов по-прежнему нет, то возможно они у вас объявлены как wire - такие и правда не видятся. Можно кинуть на порт или сделать его reg-ом. Если же это reg и он всё равно не видится, тогда добавьте перед его объявлением вот такую магию - она не даст фиттеру убить регистр, если он никуда не подключен: (*preserve, noprune*)reg packet_valid;
  3. Теоретически может, но на практике думаю нет, т.к. такая оптимизация инверсией вряд ли может затронуть сколь-нибудь большой кусок логики.
  4. По поводу добавления сигналов на времянку: ищите с включенным фильтром SignalTap: Pre-sysnthesis (или как-то так), он позволяет вытащить сигналы, которые еще не проварились фиттером в нечто непонятное. По поводу отображения: а у вас триггер-то настроен? А то такое ощущение что сейчас сигналтап работает в свободном режиме и вы конечно же не увидите (не успеете увидеть) транзакцию. Настройте срабатываение по триггеру - например, по перепаду какого-либо управляющего сигнала. Отключается в Assignments--Settings--Compiler settings--Advanced Analysis--NOT Gate Push-Back (выставить в Off).
  5. Китайцы, кстати, последнее время держат цены почти вровень с нашими магазинами. С доставкой может получиться и дороже, причем некоторые даже торговаться не хотят. П.С. по Китаю можете писать в личку.
  6. Ситуация разрешилась, всё заработало. У трансивера нужно было настроить следующие параметры: - Data rate = 622.08 (не изменилось) - TX local clock division factor = 2 (раньше было =1) - всё остальное без изменения С толку сбивает следующий пункт, который вычисляется автоматически - TX PLL base data rate, он почему-то равен 1244.16. Что это за параметр? Внятного описания в документации - нет. У меня вообще ощущение что это должен быть результатом деления 622.08 на 2, а не умножения как сейчас. Нет ли тут ошибки?
  7. В результате ряда экспериментов на serial loopback'e выяснилось что на tx_std_clkout выходит частота вдвое большая, чем надо. Ожидается 77.76, а выходит 155.52. Скорость передачи 622.08 Мбит/с, TX FPLL настроена корректно: - частота 311.04, параметры трансивера тоже: - Data rate = 622.08 - TX local clock division factor = 1 - PCS width = 8 bits Что интересно, RX часть трансивера работает отлично - CDR лочится и выдает ожидаемую 77.76 (ширина шины после десереализации - 8 бит). Теперь понятно почему RX не видит TX :)))) Но вот почему частоты приемного и передающего каналов различаются - ума не приложу пока.
  8. Если включить заворот post-CDR, то да, работает. Но в этом случае работает только PMA-часть трансивера, PCS не задействуется. Если же заворот выключить и руками завернуть параллельные шинки rx на tx (ну или просто подать константу), то не работает - на выходе ничего нет. Кстати, а какой частотой (каким значением) должен тактироваться передающий тракт (tx_coreclkin)? Такой же, которую выдает CDR после восстановления? Как-то не очень ясен этот момент. Есть подозрение что проблема в этом.
  9. Снова дошли руки до этого проекта. И возникла очередная заминка. С приёмом данных всё в порядке - поток приходит, разворачивается в байты и всё хорошо. Проблема с передачей - передатчик вообще ничего не передаёт. Совсем. Если включить pre- и post-CDR завороты, то на передающие пины данные выводятся, что говорит о том что уровень PMA работает нормально и проблема где-то выше - в PCS части. Измерительный прибор данные видит и успешно восстанавливает частоту. Но если завернуть поток на уровне PCS - после десериализации (ну например, соединить rx_parallel_data b tx_parallel_data), то на выходных пинах - тишина. TX часть не висит в сбросе - все сигналы индицируют что передатчик откалибровался и готов работать. Я перепробовал, пожалуй, все возможные варианты и ничего пока не помогает: - передавать биты задом наперед - двигать биты сигналом tx_bitslip - инвертировать полярность - крутить настройки TXPLL, integer, fractional режим - тактировать tx разными клоками И всё равно на выходе - 0. У кого это хозяйство работает - что вы делали для передачи?
  10. Вы пришли с утра на работу и, по-хорошему, вам надо запуллиться, дабы иметь актуальные исходники. И тут вдруг выясняется что ваш controller.v ночью подправил Вася Пупкин. Далее есть два варианта: 1. Если у Вас просто система контроля версий и всё. Вы злитесь и идете бить лицо Василию, попутно ломая ноги PM-у. Утрированно, конечно, но смысл в том что вы не будете знать причину изменений в коде и потратите время на пересогласование актуального сорца. Это, хотя и выстреливает очень редко, но методически - крайне плохо. 2. У Вас система контроля версий, которая не дает сделать коммит без подписи (возможно, содержащей определенные теги-метки). Вася Пупкин, после правки вашего controller.v вынужден описать в коммите что он там наделал. Вы получаете уведомляшку, после этого автоматом создается тикет в code-review и команда (Вы в том числе) смотрит чо он там понаписал посреди ночи. И уже после этого PM или тимлид подтверждает коммит, перекидывая его в рабочую ветку. Примерно так. Это, пожалуй, самый корректный вариант. Но он да, требует затрат на обучение всем этим CVS-ным штукам. Зато потом в репе всегда будет гарантированно собирающийся корректный актуальный проект. Итого, у систем контроля версий проблемы конечно есть, но то что описали Вы - имхо, чисто методологическая проблема на уровне организации работы команды.
  11. Вот здесь всё подробно расписано: https://www.altera.com/en_US/pdfs/literatur...ts_qii53009.pdf Вам нужен триггер типа Start/Stop. А Storate Qualifier работает так: по наступлению события запоминает одно состояние всех вытащенных в него сигналов. По следующему наступлению события - снова запоминает. И так, пока не заполнится весь буфер. Самый простой пример - захватить данные с SPI-АЦП, когда событием для захвата данных является сигнал того что сэмпл прочитан. В итоге получите форму АЦПированного сигнала, можно даже график построить там же.
  12. Привет! Такой вопрос - как можно в сигналтапе сделать триггер, который бы срабатывал если сигнал не меняется в течение какого-то времени? Мне надо отловить ситуацию когда сигнал (значение на шине) впервые становится отрицательным в течение, допустим, 5 тактов. Что-то я не нашел возможности проверить средствами сигналтапа значение предыдущего сэмпла (ни в advanced mode, ни в state machine mode). Единственный возможный вариант вижу - использовать конечный автомат с 5-ю состояниями, где в каждом состоянии проверять значение сэмпла и если он подходит условиям триггера - сохранять значения в режиме storage qualifier и переходить в следующее, а в противном случае сбрасывать очередь и уходить в начало автомата. Но получается что-то не то всё равно... Спасибо.
  13. Как раз сегодня ночью меня тоже осенило что возможно нужно питать трансиверные триплеты отдельными PLL-ками. В-общем, после ряда экспериментов оно наконец-то собралось - все 9 трансиверов в дуплексном двухскоростном режиме с поддержкой реконфигурации! То что мне и нужно! Структура проекта получилась следующая: 3 блока, каждый состоящий из: - FPLL с частотой 311.04 - PLL Reconfiguration controller - Трансивер в дуплексном режиме (External PLL - 2 штуки, TXPLL0=622.08, TXPLL1=2488.32, у обоих TXPLL - Bonding x1) 1 общий блок Transceiver Reconfiguration Controller (9 каналов, сгруппированные в 3 группы по 3 канала) FPLL питаются двумя клоками - один питает одну, второй клок питает оставшиеся две FPLL (а каждая FPLL в свою очередь питает по 3 канала каждого трансивера (точнее 6 каналов, т.к. 3 канала по 2 скорости)). Опорный клок для RXCDR - один общий. Клок/ресет для всех реконфигураторов - один общий. Что стоит отметить отдельно: 1. Я сначала пошел по простому пути и просто скопировал (копипастнул) трансивер с FPLL три раза. И оно не собралось. После тушения жопы и подключения мозгов оказалось что ему необходимо иметь не просто разные инстансы трансиверов, а именно разно созданные ядра, пусть и с одинаковыми в моем случае настройками. 2. FPLL тоже нужны в виде именно отдельно созданных IP-ядер. 3. Реконфигуратор трансивера допускается только одним инстансом (но в настройках можно разбить каналы на группы как нужно). Несколько реконфигураторов (например, 3 по 3 канала) - не собирает. 4. Реконфигуратор для FPLL можно использовать в виде одного ядра, просто скопипащенного 3 несколько раз. 5. Запитать 3 FPLL от одного клока не получилось - пришлось задействовать две клоковые ножки. Хочу отдельной строкой сказать спасибо DeadMazay за помощь!
×
×
  • Создать...