Jump to content

    

AlexZabr

Свой
  • Content Count

    900
  • Joined

  • Last visited

Everything posted by AlexZabr


  1. Большим опытом в FPGA пока похвастаться не могу, но на данный момент делается иерархический проэкт где есть несколько своич модулей и несколько библиотечных вендора (PLLи, память). С графикой не работал (кроме как лет 10 тому в MAX PLUS II), пока устраивает HDL. В VHDLе вполне устраивают instatiations, хороший текстовый редактор (для меня - Notepad ++) для кода очень помогает не путаться и легко "сводить концы к концами" в тексте даже в относительно больших иерархиях.
  2. Кажется у меня в проэкте балаган со сбросами (есть счетчики, модули памяти (FIFO) и т.д.). В timing симуляции при изменении сброса (в коде) тем или иным блокам/счетчикам вдруг перестают работать другие счетчики и/или модуль FIFO... Наткнулся на рекоммендации использования GSR (библиотечная компонета глобального Resetа которая вроде сбрасывает все что сбрасывается в чипе по комманде со входа), читал в хелпе, не уверен что понял все на 100%. Там есть примеры кода, но как-то кучно... вроде нужно использоватх атрибуты для синтезатора согласно хелпу (во избежании сокращения сего элемента синтезатором), использовал их, но так и не понял дало ли результат. RTL viewer не показывает никакого элемента GSR, поведение в timing simulation не изменилось. Буду благодарен ежели кто поделится своим опытом использования GSR в FPGA/CPLD Латиса, т.е. как правильно кодировать и использовать его.
  3. сорри, не совсем понял.. :cranky: вы имеете ввиду засинхронизировать асинхронный сигнал сброса и его затем его подать на счетчик ? это возможно обеспечит необходимый setup/hold на FFs сброса относительно клока, но тогда вся идея асинхонного сброса пропадает... или я ошибаюсь ?
  4. Уже во втором совем дизайне наблюдаю такую картину: если у счетчиков сброс асинхронный - они не будут работать а всегда заткнуты в состянии сброса (по нулям например) несмотря на то что сигнал сброса деактивировался и клок бежит ОК. Как только меняю код на синхронный сброс - начинают работать ОК. Это относится к timing simulation, в functional асинхронный работает ОК. Почему ? для инфо: работаю с Латисом.
  5. Сорри, почему-то в свое время не получил уведомления форума от ответах... Сейчас вернулся к продолжению свого проэкта. Первая фаза проэкта - небольшая, но в свое время приобрел ECP2 (50E) EVB посему буду пробовать на нем. Займет думаю не более 10-15 процентов логики чипа, 2-3 PLLя и немного памяти (EBR). Частоты - низкие, проблем с таймингами вроде не ожидаю...как новичок в FPGA пока слабо представляю средства и способы борьбы с проблемами тайминга....
  6. Спасибо за ответы. Проблема прояснилась 3ь кратным перечитыванием соотв. доков Латиса и общением с их саппортом. В отличие от приведенного примера Альтеры, у Латиса дело обстоит так: Если физический входной клок используется в дизайне только как вход/а PLLя - вход вешается на любой IO либо dedicated primary clock input (PCLK). Если один вход должен идти на более чем один PLL - если высокие частоты и требуется по возможности избежать/уменьшить injection delay - желательно вход повесить либо IO которое примерно посередине между PLLями (а их физическое местоположение известно из datasheet - обыьно симмтрично по бокам чипа), либо запараллелить routing клока на борту и подавать его на те IO которые являются предпочтительными входами конкретных PLLeй. Они рекоммендуются (такие входа) в процессе PAR согласно размещенным PLLям. Если-же входной клок не идет на PLLи а идет на логику, либо кроме PLLей идет еще и на логику, лучше брать PCLK входа которые физически размещеный вближе к PLLю либо между ними если более одного. Но всеэто важно на достаточно высоких частотах, там где injection и skew важны (ну и для менчшего jitterа лучше PCLK ессно, как обычно). В моем случае данная тема не сильно актуальна ибо частота низкая. Насчет подачи низких частот на PLLи - в приципе, в простейшем варианте, и для соотв. FPGAев Латиса 13 MHz - низковато для PLLей, но есть у основных семейств, где например 4 PLLя, есть специалчные входа для 5-10nF кондюков (обычно они рекоммендуют 5.6nF), PLLCAP. При наличие такого кондюка, на соотв. PLLCAP входе (он dedicated только для этого, не работает как IO), привязанный к нему PLL может работать со входами от 2MHz. У семейства с которым я работаю есть 4 PLLя, но толчко два из них привязаны к двум PLLCAP входам, т.е. только два оопределенных PLLямогу работать одновременно на низких частотах. Это как раз мой случай. У меня из входной 13 MHz нужно сделать треть входной и 5.2 MHz, на одном не подобрать комбинацию, пришлось использовать два, оба со своими PLLCAP.
  7. Спасибо. PLLe то вприципе и внешние есть, но не в этом суть, я конечно-же имею ввиду FPGAевские. А что например у Альтер в этом плане ? (я с Альтеровкими FPGAями не знаком) Говорится ли там заводить клок не на обычный dedicated клоковый вход а на специальные которые предназначены как клоковые ехода PLLей ? И указывается ли там что внешние выхода PLLей нужно выводить на спецаильные пины а не на общие I/O ?
  8. Буду благодарен за помощь в пояснении ситуации ибо для меня это ново. У меня есть проэкт где наряду с написанными блоками (иерархия) есть генерированные блоки 2х PLLей и памяти. Сейчас распределяю ноги чипа и появился вопрос/неясность: есть один входной клок (13 MHz). Он внутри идет на два PLLя, каждый из которых производит более низкие частоты нужные для проэкта. У чипа ессно есть dedicated клоковые входа по разным банкам. Вопрос - как правильно распределять входа/выходы клоков ? Справедливо ли считать что если входной физический клок подается на внутренние PLLи то его нужно подавать не на dedicated клоковые входа а на определенные IO ? Насчет выходов PLLя - если выход идет наружу (как клок внешней системе), нужно ли обычно в FPGAях подавать его на определенные/специальные пины или можно распределять на обычные логические IO ? В целом вопросы относятся к обще-FPGAйной тематике, но для конкретности - для меня актуален Латис ECM2 (50E). Спасибо.
  9. Во первых, предложил-бы модераторам открыть постоянную/приколотую ветку где бы можно было-бы "рапортовать" насчет "проверенных" багов сред разработки vendors, т.е. багов которые подтврждены вендорами (например пользователь наткнулся на проблему в среде/процессе, доложил саппорту Альтеры/Xilinxа/Латиса и т.д.) и действительно получил от них подтвербдение существования проблемы а также путь ее workaround). Думаю оно бы съэкономило кучу времени и головной боли всем нам. По делу: Проблема актуальна тем кто работает с ispLever 7.1 (Латис) со встроенным Active-HDL (Lattice version). При попытке запуска симулятора в среде ispLever при выборе test-benchа проэкта и кликании на симулацию (functional или timing) - запускается Active-HDL, компилирует сорсы как положено, но затем падает с ошибкой о том что не найден top module. T.e. симуляции не происходит. Причина: top module для Альдека - test bench проэкта (не топ модуль сорса кода), и он почему-то не "подбирается" автоматически скриптом. Т.е. смысл ошибки в том =то Альдек не находит test bench. Этого не случалось в версии 7.0 (там был ModelSim). Альдек признает сей баг (known issue) и обещают его исправление в версии 7.2 их среды (release ожидается в течении нескольких недель). Workaround: 1. В ручную: после запуска Альдека из среды ispLever 7.1 как обычно, после того как он упадет на сей ошибке - в Альдеке идти в его окно Design Browser (слева вверху), в закладке Files выбрать test bench проэкта. Затем в меню Simulation выбрать Initialize simulation в результате чего в окне Design Browser активисируется закладка Structure. В ней выбрать test bench, right click -> Add to Waveform - этим кидаем сигналы в графическое окно симулятора. Затем запускаем симуляцию нужного вида. 2. Написать в саппорт Альдека насчет сей проблемы пиркладывая ваш проэкт. В ответ они подтвредят проблему, извинятся и пришлют свой скрипт который вы вызываете из консоли Альдека. Надеюсь сей пост съэкономит время и головнюу боль поиском несуществующей проблемы проэкта другим.
  10. Вопрос решен. Говорил с саппортом Альдека - вместе запустили. Видимо при запуске из среды vendorа (ispLever Латиса в мосем случае) не передается почему-то "завязка" на test bench проэкта и в Альдеке нужно отдельно указывать на test bench в качестве top-module после чего - инициализация симулятора -> вызов waveform и запуск симулятора. При Modelsimе такого не наблюдал - вызов его из среды vendorа сразу указывал всю структуру проэкта включая test-bench и не требовалось вручную его пдоключать. Наверно зависит от скриптов/макро которые вызываются автоматически при вызове симулятора из среды vendorа...
  11. Спасибо, но я работаю из среды ispLever (Латис) и в среде проэкт собран правильно, синтезируется ОК. В среде я обычно обозначаю test bench и мне даются опции симуляции (functional, functional post-map, timing). Т.е. среда, вызывая симулятор сама передавала ему собранный проэкт с правилчной иерархией и больше ничего не нужно было. Так предыдущие дизайны и работали. А тут чегой-то застрял.... :cranky:
  12. Ага, это для меня ново. Т.е. я могу и в теле entity до ports (но тогда они постоянны для всех architectures данной entity) ? На практике, имея одну architecture для entity - все-равно где вписывать constants или зависит от компайлера ?
  13. Че-то начал спотыкаться на элементарных вещах... Где должна определяться constant (для обычного VHDL сорса, не package) - в теле entity (если да то до ports ?) ? Или в теле architecture наряду с signals ? То-же правило относиться и к test bench так ?
  14. Есть test-bench на проэкт. При вызове симулятора (functional на данном этапе) из среды ispLever - он вроде все компилирует нормально, но в самом конце, перед началом запуска - падает выдавая ошибку: # Error: vsim: cannot select specified top-level Скриптовая комманда которая это видимо дает (в консоли): vsim StimModule_Unknown -PL pmi_work -L ovi_ecp2 -L pcsc_work Test bench наьодится в проэкте, завинчен на чип (т.е. верхняя иерархия проэкта, как делаю обычно), вроде все должно быть ОК... :cranky: Может кто имеет понятие что вызывает такого рода ошибку в Active-HDL (версия 8.1) ? Спасибо.
  15. Чегой-то затмение нашло.... :cranky: Есть lpf файл (констрейн файл в среде ispLever) который пытаюсь присобачить к проэкту, забыл как. Заранее благодарен...
  16. Спасибо. Вычитал коротенький пост на форумах Латиса что LPC - неьно вроде контейнера содержащего конфигурацию сгенерированного модуля для последующего использования/изменения. Но вроде для синтеза оно не употребляется и нужен ее VHDL/Verilog код который и используем в дизайне. Сейчас выкинул из проэкта LPC, оставил только VHDL сорсы подключенные через instances, компилируется вроде нормально.
  17. В прощкте использую генерируемые коры памяти и PLLей. Работаю с Латисе (ispLever). После конфигурации кора в IPexpressе, он опционально генерирует LPC файл который автоматов добавляет в проэкт. Так-же генерируется VHDL сорс кора. Я стыкую все это в top модуле (тоже VHDL), т.е. все VHDL модули стыкуются посредством components instantiation и так формирую проэкт. С другой стороны в проэкте уже существуют LPC файлы генерированных модулей. При сборке проэкта получаю предупреждение может быть проблема в интерпретации ибо у меня в проэкте присутствуют и LPC и VHDL файлы одного и того-же имени (сгенерированые коры). Как правильно понимать наличие LPC ? Заменяет ли LPC файл сгенерированного кора его VHDL сорс в сборке проэкта ? Или-же если я его са собираю в top модуле (в коде VHDL) из сгенерированных VHDL модулей, может быть LPC файлы излишни и их лучше убрать из проэкта ? Спасибо.
  18. Я пока для себя не уверен в чем преймущество наличия "Солид"ной модели элект. элементов на плате перед определением геометрии элементов в самом Альтиуме и затем, после разводки платы сохранять 3D модель платы в STEPS. Ведь то что важно - это конечный результат, т.е. механики проверят 3D моделх цельной разведенной платы с элементами на ней, а не отдельные элементы без привязки к плате. Ессно, лично мое мнение, не сильно пока искушенное практикой...
  19. Ну тут спорить трудно, везде есть свои плюсы и минусы. В Альтиуме наверно плюс в том что оно привязано к схематику и например изменения в распиновке FPGA проэкте отражаются в схеме и на PCB. Насчет уиверсальности платформы - не уверен. Ведь и так-то пишем на универсальном HDLе (VHDL, Verilog), затем синтезатор тоже подключаем как отдельный тул (Synplify/Precision), симулятор тоже в свой тул (Modelsim/Active-HDL). А P&R все равно нужно брендовкий FPGAя. В общем , не вижу особых преймуществ перед обычным подходом, т.е. средой бренда, кроме как интеграции со схематиком и PCB. Хотя конечно заманчиво оставаться в одной среде на весь цилк. Насчет NanoBoard - тоже когда-то задумывались на эту тему - опять-же не решились, предпочли брендовкий dev. board на чип под который думается работать в обозримом будущем. Гораздо дешевле. Для наших конкретных нужд NanoBoard показался слишком наворочен, 60-70% ненужных вещей, а платить 70% стоимости не охота. Хотя он может и подошел-бы для тех кто работает с несколькими брендами FPGA. Вообще-то конечно за неимением практического мнения, было-бы интересно услышать мнения тех кто работал/ет с ним. Дык я бы предположил как раз наоборот: мне кажется обычно начинают с Aльтиума, а затем вдруг обнаруживают что там есть возможности FPGA...
  20. Обратный процесс еще проще, сделал его тоже, отдал механикам на проверку с их 3D моделью всей системы в Солиде. Но у меня уже были определени все 3D модели элементов на плате, саму механику платы (полная 3D модель) они мне дали в STEPS. Из нее определил точный shape PCB борта, сделал разводку (она простая у меня в данном случае, я не профессиональный layoutник), и полуьил полный 3D всей платы. Ее отдал в STEPS механикам на проверку в полной сборке системы.
  21. Около темы: сегодня первый раз синтегрировал механику с PCB в плане модели. Механики дали STEP модель, загрузил ее в PCB, сделал из нее борд и залил layout. Получилось на удивление гладко. Сам процесс (как и смежные процессы) хорошо описаны в appl. Альтиума: Integrating MCAD Objects and PCB Designs. PDF находится в Helpах Альтиума Summer 08.
  22. То что ужас ночи в одних руках может быть радостью дня в других... Работаю с Leverом 7.0 и 7.1, правда пока с простыми дизайнами - проблем нет. Просто дело привычки (как и привыкать к тулам Альтеры, Xilinxа и т.д.). Знаю людей работающих с Латиссом в сложных вещах - тоже нормально. Не без проблем ессно (как и в тулах других производителей), но работать можно вполне сносно. Насчет Альтиума - я тоже рассматривал их FPGA тулы интегрированные в среду вместо (или наряду) с ispLeverом, советовался тут на форумах, пока устойчивое мнение было таково что лучше оставаться с родной средой производителя. Более гладко.
  23. Так может там via как раз и между pads и выведены ? Хотя наверно ежели это FBGA то наверно даже между ними не обойтись без microvia...