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

Bad0512

Свой
  • Постов

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

  • Посещение

Репутация

2 Обычный

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

  • Звание
    Знающий
    Знающий
  • День рождения 05.12.1972

Контакты

  • MSN
    Array
  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

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

5 857 просмотров профиля
  1. Как-то давным-давно исследовал вопрос "так какой счетчик всё-таки шустрее считает, обычный или на DSP ?". Использовал в качестве базовой архитектуры какой-то из Спартанов, не помню точно какой. Так вот в итоге получилось что приvерно до 32 бит обычный счётчик уделывает по времянке DSP-шный. Дальше побеждает DSP. В общем, fast carry logic - великая сила, а ведь были времена когда её в ПЛИС не было!
  2. Всё то же самое (копирование ранее сделанных компонентов) можно делать и методом cut&paste из ранее созданных проектов. Помещение в отдельную библиотеку как правило требуется только в случае, когда необходимы серьёзные модификации в УГО. Параметры или footprint можно легко править в конкретном инсансе компонента на схеме. При необходимости исправлений во многих однотипных инатансах = использовать групповое выделение.
  3. Сам пользуюсь методом "cut&paste" из проекта в проект, было время когда по требованию начальства пользовал и "библиотечный" подход. По моему мнению тут выбор определяет квалификация разработчика. Библиотечный подход больше подходит для не слишком опытных разработчиков и как правило предполагает, что либами занимается специально заточенный для этого человек. У этого человека как правило много разных задач от разных разработчиков, соответственно он возможно обладает более глубокими знаниями на тему "как правильно делать компонент", но к сожалению совсем не горит желанием читать даташиты, да и времени у него на это просто нет. Поэтому некоторые тонкие моменты от него ускользают. Кроме того при такой схеме работы возникает эффект "размывания ответственности". Ну то есть при нахождении проблемы в дизайне, порождённой кривым библиотечным компонентом не всегда тривиально найти виновника и как-то замотивировать его провести работу над ошибками. В случае когда важен работоспособный проект ("ехать а не шашечки") такая ситуация может сильно повредить делу. По поводу возражений о том что в случае либы поменять отдельный параметр на множестве однотипных компонентов значительно быстрее, чем в случае "безбиблиотечного" подхода могу сказать, что с помощью инструмента Find simlair objects подобные задачи решаются ничуть не медленнее, чем при "библиотечном" подходе. А уж какие чудеса умеет творить Smart edit при грамотном использовании...
  4. Нет проблем сделать под такие пины отдельный Part. Одна из проблем с hidden pin заключается в том, что цепь земли может называться и не GND, а в явном виде найти цепь, к которой подключены эти пины не так просто. Например, подумайте о людях, которые смотрят ваши схемы в формате пдф. Короче hidden pins - это очень плохо.
  5. А может быть правильнее будет всё-таки исправить ошибки и растащить налезающие друг на друга элементы шелкографии?
  6. Можно такое сделать с помощью hidden pin. Но это - очень плохая практика. Схема нужна для того, чтобы другие разработчики могли быстро понять ваш замысел, поэтому лучше не экономить на виртуальной бумаге и добавить таки отдельную ногу в УГО для этого пина. Ну и прицепить куда надо эту ногу явным способом.
  7. У вас в асинхронном ФИФО есть два клоковых домена - домен клока записи и домен клока чтения. Флажки(FULL,ALMOST_FULL,HALF_FULL), которые определяют заполненность фифошки привязаны к домену клока записи, а флажки(EMPTY,ALMOST_EMPTY,PROG_EMPTY), которые определяют наличие места в фифошке - привязаны к домену клока чтения. В принципе не очень важно на каком из этих двух клоков вы построите автомат управления, важно чтобы сигналы, которые управляют переходами в этом автомате были порождены от того же клока, на котором работает автомат. При необходимости эти сигналы надо пересинхронизировать на нужный клоковый домен.
  8. 1. Крайне желательно на спец. клоковый пин. 2. Подойдет любой клоковый пин. 3. Синхронности в любом случае вам уже не достичь, ибо два клока как минимум независимых вы уже имеете. Вместо обычного FIFO попробуйте использовать двухклоковый. Не забудьте что различные флажки привязаны к различным доменам клока когда будете делать автомат управления логикой работы всей системы. Управление переходами автомата сигналом из другого клокового домена - классическая ошибка. Вроде как бы всё и работает, но иногда улетает в непонятное состяние.
  9. Не совсем понимаю как модификация прошивки решит проблему отсутствия расходников?
  10. Ну это значит что в процессе вычисления ширины вектора путём суммирования нескольких параметров или выражений вполне может так случиться, что replication value будет равно нулю, и это - вполне легальная ситуация. Это уже SV синтаксис.
  11. Почитайте в стандарте про Replication operator : И заодно вот про это ;
  12. На SFP кроме Rx и Tx линков есть ещё некоторое количество управляющих GPIO - убедитесь, что вы их правильно устанавливаете.
  13. Да, конечно можете. Но макс. напряжение банка при этом будет 1.8v. То есть 16 LVCMOS_18 сделать можно, а 16 LVCMOS_33 нельзя. Это очень сильно зависит от используемого I/O стандарта (а их там много) , поэтому единую цифру привести проблематично. По максимальным частотам смотрите в DC/AC характеристиках раздел "Performance ...", однако там описаны лишь наиболее распространённые случаи.
  14. Можно создать отдельный класс полигонов и создать для него правило с высоким приоритетом.
  15. Делал когда-то подобные штуки с помощью атрибутов синтеза. max_fanout для вивады и syn_maxfan для синплифая. Вставлял эти атрибуты прямо в верилоговские исходники, но это очевидно плохой способ - надо аналогичные директивы писать в XDC/SDC файлы чтобы переносимость исходников не страдала.
×
×
  • Создать...