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

vv_gulyaev

Участник
  • Постов

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Участник
    Участник

Информация

  • Город
    Array
  1. Здесь я просто взял пример из архива с примерами от Vitis, чтобы проверить, как синтезируется проект, если rtl ядро pipelined с II=1 и при этом верхний уровень тоже указать pipelined c II=1. В итоге получается, что на версии 2022.1 такое не синтезируется, а на 2020.2 синтезируется. Про бесконечный цикл, спасибо за совет, побробую использовать.
  2. Попробую В Vitis HLS 2020.2 синтезировалось с #pragma HLS PIPELINE II=1. Спасибо! Буду использовать пока эту версию.
  3. Попробовал описанный вариант, но выдается та же ошибка, если использовать "#pragma HLS PIPELINE II=1" на верхнем уровне: ERROR: [HLS 200-1916] Ap_ctrl_chain blackbox module 'rtl_model' can not be used in pipeline region. Если же прагму не использовать модель синтезируется но в столбце Pipelined указано "no" example.cpp
  4. Здравствуйте! Есть HLS проект для Vitis HLS 2022.1, содержащий функцию, описанную на verilog. Функция подключена в проект как blackbox модуль, по всем правилам, описанным в документации. Для этой функции II=0 и Latency=2. Столкнулся со следующе проблемой. Если не использовать "pragma hls pipelined", то верхний уровень ситезируется. При этом в репорте видно, что blackbox функция определяется как pipelined (т.к. II=1), а верхний уровень нет. Если же на верхний уровень добавить "pragma hls pipelined", то выдается ошибка: ERROR: [HLS 200-1916] Ap_ctrl_chain blackbox module 'blackbox_module' can not be used in pipeline region. В качестве референсного примера взял проект misc_rtl_as_blackbox из HLS-Tiny-Tutorials и добавил такую прагму в example.cpp. Получил такую же ошибку: ERROR: [HLS 200-1916] Ap_ctrl_chain blackbox module 'rtl_model' can not be used in pipeline region. В документации не находил информации, что нельзя использовать blackbox модули в конвейерных топ уровнях. Наоборт, косвенно подтверждается, что можно: Сталкивался ли кто-либо с такой проблемой? misc_rtl_as_blackbox.7z
  5. Здравствуйте! Не смог найти детальную информацию по алгоритму восстановления сигнала MII_CRS из RMII_CRS_DV при преобразовании интерфейса MII в RMII. Если кто-то сталкивался с подобным вопросом, прошу помочь. Заранее спасибо.
  6. Может стоит перенести тему в соответствующий раздел?
  7. Исследую возможность использования ядра "LogiCORE IP Virtex-6 FPGA Embedded Tri-Mode Ethernet MAC Wrapper v2.2" доступ к его регистрам описывается через AXI4-Lite интерфейс (сигналы вида *s_axi *). С ядра выходят сигналы IPIF интерфейса (*ip2bus* и *bus2ip*). соответственно необходим преобразователь между двумя этими интерфейсами. На блок-схеме, приведенной в описании роль этого преобразователя выполняет блок "AXI-Wrapper", находящийся вне ядра в блоке "Ethernet Mac Block". Про "Ethernet Mac Block" пишут, что Проблема в том, что я не могу найти пример проекта с таким блоком.
  8. Недавно начал изучать программирование МК, поэтому осмелюсь спросить, что плохого в задержках в обработчиках прерываний?
  9. Второй МК должен реагировать как можно быстрей. Сейчас занято по 1 ноге на каждом МК (PB3 на первом и PB2 на втором).
  10. МК будут расположены на одной плате, так что о помехах пока особо не задумывался, но все же потребуется как-то их убирать. Я пока никак не обрабатывал изменение состояния входа, поэтому ничего не могу сказать о времени.
  11. Есть цепочка из МК. Один МК сделал какие-то действия и должен подать короткий сигнал второму. Я думал сделать это так: вывести импульс с PB3 одного на PB2 другого и по прерыванию обработать его. При отладке использовал один МК, т.е. заводил импульс на тот же самый МК. Хотелось бы чтобы этот импульс был как можно короче, но при разрешении прерывания (GIMSK = 0x40) этот импульс затягивается. При этом я еще никак не описывал процедуру обработки прерывания, только разрешил его.
  12. Собираюсь составить цепь из нескольких МК. Количество МК в цепи может менятьсь от 1 до 4. Соответственно, если имеем 2 и более МК, то вывод PB3 приходит на PB2 следующего МК, а если в цепи 1 МК, то на PB2 этого же. Как я подозреваю, если я выведу PB3 с одного МК на PB2 другого, то частота все равно уменьшится. Обработчик прерывания не описывается. Добавление строки GIMSK = 0x40; вносит искажение в сигнал.
  13. Использую МК ATtiny25. Частота работы 16 МГц. С порта PB3 вывожу импульс, который должен придти на порт PB2 этого же МК. Если разрешаю прерывание по входу INT0(PB2), то сигнал искажается (уменьшается частота). Можно ли как-нибудь предотвратить такое искажение? iint main(void){ PORTB = 0xFC;//set default value of pins DDRB = 0xEB;//set direction of pins // GIMSK = 0x40;//external pin interrupt is enabled MCUCR = 0x02;//interrupt by falling edge sei(); while(1){ flag = 0; if (!flag){ PORTB ^= 0x08; PORTB ^= 0x08; }; }; };
×
×
  • Создать...