Использование TCL в разработке на FPGA

    Всем привет! Давно не писал статьи на любимую тематику и наконец-то созрел на что-то более-менее приличное и стоящее. В этой статье речь пойдет об очень интересной задаче, с которой инженер-разработчик сталкивается чуть ли не каждый день. Предлагаю вам посмотреть, каким образом можно использовать всю мощь и простоту TCL скриптов для проектирования на FPGA. В данной статье описание базируется на ПЛИС фирмы Xilinx, но это не отменяет возможностей TCL скриптов для кристаллов ПЛИС других производителей.


    Интересно? Поехали…

    Что такое TCL?


    TCL (Tool Command Language) — скриптовый язык высокого уровня для исполнения различных задач. Зачастую TCL применяется в связке с графической оболочкой Tk (Tool Kit), но в рамках этой статьи этот аспект рассматриваться не будет. Язык находит широкое применение в различных задачах автоматизации процессов:

    • Тестирование комплексных модулей, узлов, частей кода;
    • Скоростное прототипирование;
    • Создание графических интерфейсов для консольных приложений;
    • Внедрение в прикладные приложения и задачи.

    Так или иначе, основной функцией языка TCL является автоматизация рутинных задач, и существенное уменьшение времени, затрачиваемого на разработку. Программы на TCL не требуют компоновки и компиляции, что делает задачу отладки скриптов простой и незамысловатой. Интерпретатор TCL распространяется под свободной лицензией и доступен практически для всех платформ (во многих дистрибутивах Linux он доступен по умолчанию). Это означает, что вы можете без каких-либо ограничений использовать его в разработке частных программ и проприетарных приложений. На момент написания статьи актуальная версия TCL – 8.6. Для работы с TCL скриптами, их отладки и визуализации доступно множество дистрибутивов – MyTcl, TclKit, ActiveTcl и т.д. Цена за 1 лицензию ActiveTcl около ~1500$, что неоправданно для разработки коммерческих приложений. Из личной практики, большая часть разработчиков пользуется привычной командной строкой.

    Все программы на языке TCL состоят из команд, которые разделяются символом ";" или символом начала новой строки. Как и во многих других языках программирования, первое слово — команда, остальные слова — аргументы команд.

    command arg1 argt2 … argN

    Например:

    set NewValue “Hello World!”
    puts $NewValue

    Первая команда создает переменную NewValue, а вторая команда производит печать значения переменной в консоль. Для того, чтобы использовать переменные с пробелами используются кавычки. В остальных случаях они не требуются. Результат исполнения команд представлен на рисунке ниже:


    На мой взгляд, главное удобство языка TCL заключается в том, что любой аргумент команды может быть заменен другой командой. Для этого его необходимо поместить в квадратные скобки. На примере ниже я покажу эту возможность. Помимо всего прочего, TCL способен управлять поведением программы на основе различных событий. Это означает, что обработчик команд может выполнять те или иные действия не только по условию, записанному в скрипте, но и по всевозможным внешним событиям (изменение значение переменной во внешнем файле, захват данных в канале, завершение исполнения приложения, достижение счетчика таймера определенного значения и т.д.). Язык TCL богат набором команд, содержит достаточно удобные средства работы с массивами данных и регулярными выражениями. На TCL реализована возможность написания функций и процедур, доступно описание циклов и выражений по условию, что существенно облегчает написание код.

    Зачем вам TCL?


    Практически все разработчики на FPGA/ASIC рано или поздно сталкиваются с языком TCL в своих проектах. В современной разработке на ПЛИС скрипты TCL активно применяются для задач автоматизации и интеграции процессов. TCL входит во все ведущие САПР ПЛИС – Quartus для Altera, ISE Design Suite и Vivado для Xilinx. Что позволяет сделать TCL?

    • создание проекта (добавление исходных файлов, установка опций, иерархии дизайна, назначение файла верхнего уровня и т.д.),
    • синтез и трассировка (вплоть до создания независимых стадий с разными настройками),
    • тестирование законченных узлов, отдельных модулей и всего проекта целиком,
    • автоматическая генерация файлов ограничений (UCF / XCI) на базе шаблонов,
    • проверка временных ограничений для синтезированного и трассированного проекта.
    • задание параметров цепей, компонентов и примитивов ПЛИС, установка опций для IP-ядер,

    и т.д.

    Все эти стадии, так или иначе, являются базовыми операциями в процессе разработки на ПЛИС: от создания моделей поведения узлов на языках VHDL/Verilog до отладки законченного проекта в САПР на этапе синтеза и трассировки. Как правило, сложные проекты содержат большое число модулей, написанных разными разработчиками, несколько IP-ядер, файлы ограничений, библиотеки и пакеты функций. В итоге, законченный проект имеет некую иерархичную структуру и набор правил для подключения тех или иных модулей к требуемым узлам проекта. Разработчику сложно держать в голове знания о том, где и как должны находиться отлаженные модули и какие функции они выполняют, если в его работе они используются, но знания об их работе не требуются на этапе разработки (так называемые “black-box” модули). На помощь приходит TCL скрипт, который управляет структурой проекта и связывает требуемые узлы по заранее подготовленным шаблонам. Это обеспечивает гибкость в разработке и даёт возможность повторяемости законченных узлов при миграции от одного проекта к другому.

    Как правило, одновременно со стадией создания новых узлов для ПЛИС протекает стадия отладки этих узлов отдельно от проекта и в совокупности с законченной системой. Первичное моделирование проводится абстрагировано от ПЛИС на компьютере в специализированных САПР и средах моделирования: это Modelsim, ISim, Aldec Active-HDL и другие. Для реализации задачи отладки проектов на помощь также приходят TCL скрипты, позволяющие обрабатывать события, возникающие во время моделирования, и принимать решения по результатам работы модели. При отладке RTL-узла чисто на HDL языках может возникнуть сложность написания модели, поскольку любое изменение в поведении схемы приведет к необходимости изменения модели и наборов тестирования. Использование связки модели на HDL языке и TCL скриптах достаточно удобно и для многих решений позволяет ускорить процесс отладки, а также унифицировать сложные тесты.

    За стадиями написания кода и его отладки следуют привычные шаги синтеза, размещения и трассировки проекта в кристалле ПЛИС. Пожалуй, это один из самых сложных шагов, который требует больших вычислительных ресурсов рабочей станции и длительного времени исполнения до полного завершения. Скрипты TCL позволяют управлять событиями выполнения на каждой стадии, анализировать результаты тех или иных вычислений для достижения наилучших характеристик по разводке и трассировке проекта (объем занимаемых ресурсов, максимальные тактовые частоты, допустимые значения задержек по таймингам и прочее). Кроме того, TCL дает возможность исключить рутинные действия по выбору и смене настроек, повторному запуску стадий проверок, перезапуску конкретного этапа при создании файла прошивки ПЛИС. Такая автоматизация проектирования практически полностью исключает постоянное присутствие человека на этих стадиях.

    Надеюсь, что, дочитав до этих строк, вы уже убеждены в том, что TCL – удобная и мощная штука, которой крайне необходимо пользоваться в своих проектах. Ниже я разберу один из полезных скриптов, который используется нашей командой для создания проекта в среде Vivado, для добавления уже написанных файлов исходных текстов, всевозможных IP-ядер, файлов ограничений XCI и многое другое.

    TCL your FPGA!


    Рассмотрим один из самых простейших TCL скриптов для автоматического создания проекта на ПЛИС. Предварительные действия совсем минимальны: на локальной машине требуется наличие каталога с исходными текстами проекта, как показано на рисунке ниже.


    Для удобства я использую независимые каталоги для проектов, созданных в среде Xilinx ISE Design Suite и в Vivado, если это позволяет семейство ПЛИС (7 серия: Artix, Kintex, Virtex). Исходные файлы лежат в каталоге /src, проект vivado в одноименном каталоге, а проект для среды ISE создается в каталоге /ise, но результаты синтеза и разводки сохраняются в директории /implement. Все это сделано для удобства управления проектом в целом и независимого управления в разных средах. Также это делает иерархию более наглядной и избавляет вас от кучи мусорных файлов в исходниках. Отдельно следует отметить каталог /top в директории исходных текстов, где лежит файл верхнего уровня и необходимые файлы ограничений (для ISE это *.ucf файл, для Vivado это *.xdc файл).

    Проект содержит смешанные IP-ядра – старые, созданные в ISE и новые, созданные в Vivado. В каталоге core_k7 лежат все ядра, созданные в CoreGenerator для ISE. Они не регенерируются и не обновляются при использовании в проекте Vivado (причем файл *.vhd используется для моделирования, файл *.ngc – для синтеза, а файл *.xco в проект Vivado не добавляется). В каталоге /ipcores лежат новые ядра в формате *.xci, созданные непосредственно в среде Vivado. Следует отметить, что для каждого ядра требуется отдельная под-директория, иначе для IP-ядер в проекте устанавливается атрибут “LOCKED”, что не дает возможности обновлять ядра и регенерировать их для синтеза.

    Перейдем к описанию TCL скрипта:

    # Stage 1: Specify project settings
    set TclPath [file dirname [file normalize [info script]]]
    set NewLoc [string range $TclPath 0 [string last / $TclPath]-5]
    
    set PartDev "xc7k325tffg900-2"
    set PrjDir [string range $TclPath 0 [string last / $NewLoc]]
    set TopName [string range $NewLoc [string last / $NewLoc]+1 end]

    Первая строка ищет расположение TCL скрипта на локальной машине (находится в каталоге src/tcl) и создает строковую переменную с полным путём до файла.

    Во второй строке создается дополнительная переменная, из которой вырезается часть пути. Обе переменные нужны для того, чтобы в следующих переменных вручную не указывать путь до проекта и название файла верхнего уровня.

    Переменная PartDev содержит название кристалла ПЛИС. И это единственная переменная, которая меняется в проекте! Все остальные строки скрипта остаются НЕИЗМЕННЫМИ в любом проекте.

    # Stage 2: Auto-complete part for path
    set PrjName $TopName.xpr
    set SrcDir $PrjDir/$TopName/src
    set VivNm "vivado"
    set VivDir $PrjDir/$TopName/$VivNm
    
    cd $PrjDir/$TopName
    pwd
    
    if {[file exists $VivNm] == 1} { file delete -force $VivNm }
    file mkdir $VivNm
    cd $VivDir

    На следующей стадии создаются дополнительные переменные, которые определяют расположение исходных файлов, создают директорию vivado, если её нет и т.д. Хочу отметить, что я проверяю наличие директории vivado на локальной машине. Если директория существует – она удаляется и создается заново, чтобы не было никаких конфликтов в новом проекте.

    Команда cd меняет рабочую директорию, а команда pwd показывает расположение рабочей директории.

    # Stage 3: Find sources: *.vhd, *.ngc *.xci *.xco *.xdc etc.
    # This stage used instead of: add_files -scan_for_includes $SrcDir
    set SrcVHD [findFiles $SrcDir "*.vhd"]
    set SrcVer [findFiles $SrcDir "*.v"]
    set SrcNGC [findFiles $SrcDir "*.ngc"]
    set SrcXCI [findFiles $SrcDir "*.xci"]
    set SrcXDC [findFiles $SrcDir "*.xdc"]
    
    set SrcPCI [findFiles $SrcDir "cl_pcie*"]
    set NewLoc [string range $SrcPCI 0 [string last / $SrcPCI]-6]
    

    Здесь все примитивно и понятно – создаются переменные, определяющие названия всех исходных файлов в каталоге /src. Для поиска файлов используется процедура findFiles, к которой мы ещё вернемся.

    Отдельно производится поиск компонента узла PCI-E, который является базовой и неотъемлемой частью для всех наших проектов.

    # Stage 4: Find all subdirs for IP cores (VHD, XCO, NGC, EDN)
    set PrjAll {}
    lappend PrjAll $DirIps $DirAdm $SrcDir/core_v2_ise $SrcDir/core_v4_ise $SrcDir/core_v5_ise $SrcDir/core_v6_ise $SrcDir/core_k7 $SrcDir/TestBench
    
    set SrcSim {}
    for {set i 0} {$i < [llength $PrjAll]} {incr i} {
    	set SrcXXX [findFiles [lindex $PrjAll $i] "*.vhd"]
    	put $SrcXXX
    	foreach SrcAdd $SrcXXX {
    		lappend SrcSim $SrcAdd
    	}
    }

    На следующей стадии производится поиск всех IP-ядер в проекте. Причем в переменную SrcSim записываются названия файлов, которые используются для моделирования. Команда lappend в цикле добавляет к переменной другие значения, формируя массив, который на языке TCL называется листом. На этом подготовительная часть скрипта заканчивается и начинается создание проекта.

    # Stage 5: Create project and add source files
    create_project -force $TopName $VivDir -part $PartDev
    set_property target_language VHDL [current_project]
    
    add_files -norecurse $SrcNGC
    add_files -norecurse $SrcXCI
    export_ip_user_files -of_objects [get_files $SrcXCI] -force -quiet
    add_files $SrcVHD
    add_files -fileset constrs_1 -norecurse $SrcXDC

    Создаем проект, определяем файл верхнего уровня, устанавливаем тип кристалла ПЛИС (в данном примере это Kintex-7 K325T), добавляем найденные исходные файлы.

    # Stage 6: Set properties and update compile order
    set_property top $TopName [current_fileset]
    for {set i 0} {$i < [llength $SrcSim]} {incr i} {
    	set_property used_in_synthesis false [get_files [lindex $SrcSim $i]]
    }
    
    set NgcGlb [findFiles $DirIps "*.ngc"]
    for {set i 0} {$i < [llength $NgcGlb]} {incr i} {
    	set_property IS_GLOBAL_INCLUDE 1 [get_files [lindex $NgcGlb $i]]
    }
    set_property IS_GLOBAL_INCLUDE 1 [get_files $SrcPCI]
    

    Устанавливаем опции для файлов моделирования (исключаем из синтеза), задаем параметр GLOBAL_INCLUDE для ядер, используемых в узле PCI-E (это специфическая особенность, требуемая для наших проектов).

    # Stage 7: Upgrade IP Cores (if needed)
    report_ip_status -name ip_status 
    set IpCores [get_ips]
    for {set i 0} {$i < [llength $IpCores]} {incr i} {
    	set IpSingle [lindex $IpCores $i]
    	
    	set locked [get_property IS_LOCKED $IpSingle]
    	set upgrade [get_property UPGRADE_VERSIONS $IpSingle]
    	if {$upgrade != "" && $locked} {
    		upgrade_ip $IpSingle
    	}
    }
    report_ip_status -name ip_status

    На этой стадии производится поиск IP-ядер проекта в формате XCI, проверяется необходимость обновления версии ядра и параметр locked, на который влияет смена кристалла ПЛИС. После анализа ядер происходит обновление и выдается отчет об успешно завершенной операции.

    # Stage 8: Set properties for Synthesis and Implementation (Custom field)
    set_property strategy Flow_PerfOptimized_high [get_runs synth_1]
    set_property strategy Performance_ExtraTimingOpt [get_runs impl_1]
    
    launch_runs synth_1
    wait_on_run synth_1
    open_run synth_1 -name synth_1
    launch_runs impl_1 -to_step write_bitstream
    wait_on_run impl_1
    

    Завершающая стадия, на которой происходит установка настроек синтеза и трассировки – выбирается стратегия из списка доступных. Затем поочередно запускается синтез, размещение и трассировка до полной разводки прошивки ПЛИС.

    Как видно, использование скрипта позволяет избавить пользователя от рутинной работы по созданию проекта, добавлению новых файлов, обновлению IP-ядер и многих других однотипных вещей. Скрипт полностью автоматизирован и требует установки единственного аргумента – тип кристалла ПЛИС. Его можно задать как переменную в файле, либо как аргумент, который исполняется одновременно с запуском TCL-скрипта. На рисунке ниже приведен скриншот рабочей области проекта в среде Vivado, который был запущен с использованием скрипта:


    Отдельно следует обратить внимание на процедуру findFiles, с помощью которой можно производить поиск всех файлов в директории. Аргументы функции: basedir – каталог поиска, pattern – маска поиска.

    proc findFiles { basedir pattern } {
    
        set basedir [string trimright [file join [file normalize $basedir] { }]]
        set fileList {}
    	
        foreach fileName [glob -nocomplain -type {f r} -path $basedir $pattern] {
            lappend fileList $fileName
        }	
    	
        foreach dirName [glob -nocomplain -type {d  r} -path $basedir *] {
            set subDirList [findFiles $dirName $pattern]
            if { [llength $subDirList] > 0 } {
                foreach subDirFile $subDirList {
    		lappend fileList $subDirFile
                }
            }
        }
        return $fileList
    }

    Поиск выполняется в несколько шагов: определение рабочей директории как шаблона файла, создание списка по имени файла с указанием полного пути и формирование массива-списка типа list, если найденных файлов больше одного. Пример работы функции findFiles приведен на рисунке ниже. Для пояснения написан цикл, который выводит на экран все найденные файлы. Как видно, указывается полный путь до каждого файла.


    Скрипт запускается из командной строки, либо с использованием GUI приложения Vivado. В первом случае необходимо запустить Vivado TCL Shell и написать незамысловатую команду

    vivado –mode tcl –source %full_path/example.tcl

    Примечание: из командной строки можно запустить и графическую среду, поменяв режим запуска mode на gui.

    В среде Vivado скрипты запускаются незамысловато и просто: Menu -> Tools -> Run TCL Script…


    На этом знакомство с языком TCL завершается. На этом возможности автоматизации проектов не заканчиваются. В этом простом примере я хотел показать, как с использованием TCL скриптов можно автоматизировать проектирование на ПЛИС. Язык TCL является очень удобным, простым для понимания и самое главное – открытым для использования. По личным оценкам, внедрение скриптов в жизнь разработчиков позволяет в несколько раз уменьшить время на полное создание проекта от начальной до завершающей стадии, и оставить больше времени на «чистую» разработку (написание кода). Ниже приведены полезные ссылки для знакомства с TCL-скриптами на FPGA.

    Литература:



    Спасибо за внимание!
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 27

      0
      Может не в тему, но… Раньше у Xilinx, в предыдущих версиях (6 и ниже), использовались ISE, PlanAhead, FPGA Editor и т.д. В FPGA Editor была очень удобная фича — автоматическое добавление пробников в готовый дизайн. Если ножка ПЛИС не использовалась в дизайне, то можно было вывести любой сигнал на эту ногу, при этом «имплементейшн» не затрагивался. Для поздней отладки это иногда здорово сокращало время на поиск ошибки.
      Теперь, с 7 версии кристаллов и выше, Xilinx использует Vivado. Так вот пробников там нет, и у народа на форумах бомбит. При этом сотрудники Xilinx обещают уже который год добавить эту фичу, но ее все нет. Вместо этого они добавили tcl скрипт add_probe. Но для меня это костыль, очень неудобно, может кто-нибудь пользовался и/или как добиться удобства FPGA Editor?
        +1
        Несколько рекомендаций:
        — Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}
        — Комментировать большой кусок кода удобно конструкцией if 0 {… }
        — Тиклевский скрипт эстетичней бить на иерархию: отдельно дефайны с конфигурацией, отдельно процедуры, и т.д. Для вызова вложений используется команда source inc_file.tcl
          0
          Спасибо!
          Задам несколько вопросов, если не против.
          — Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?
          — Этим активно пользуюсь, не только в TCL :)
          — С процедурами — верно подмечено, я стараюсь так делать, если скрип разрастается до больших размеров. Вызов вложений тоже удобная штука (использую для стадий synthesis / implement). А вот дефайнами не пользовался. Можете пример привести?
            0
            > — Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?

            Во-первых, в строках если нужно уточнить где заканчивается имя переменной, и продолжается просто строка.
            Во-вторых, в Tcl имена-с-чёрточками понимаются везде, кроме подстановки, т.е.
            set my-variable 42
            puts ${my-variable}

            Если вы используете CamelCase, а не lisp-case, то причин брать всегда в скобки почти нет.
              0
              Собственно, под дефайнами я и имел ввиду задание констант для проекта -переменных, хешей и т.д.

              Удобна конвейерная работа, когда используется единый скрипт с flow, в котором лишь в начале подсовываются файл с дефайнами-переменными, списком RTL-исходников и файл с констрейнтами — применительно к конкретному проекту. По сути, ведь проекты отличаются только RTL, названием топ-модуля и констрентами. А flow один раз отладили, и можно использовать постоянно.
              К тому же, работа в консоли позволяет проводить распределенные вычисления, если у вас имеется большой кластер из серверов (для очень тяжелых проектов)

              По поводу переменных, предыдущий автор все верно написал. К примеру, вы хотите получить переменную
              set new-variable ${old-variable}311
              Если убрать скобки, транслятор ругнется, что нет такой переменной old-variable311. А префиксы и постфиксы на практике используются очень часто. Поэтому, проще сразу привыкнуть ставить скобки, и забыть о проблеме вообще.

              В дополнение к tcl очень полезно изучить еще какой нибудь make, perl и т.д. -они полезны для составления batch файлов для потокового запуска нескольких программ, чистке логов, архивации результа и т.д.
              К примеру, батч файл может содержать: очистку лога, запуск квартуса (исполняемый tcl скрипт), архивация результатов, затем запуск симулятора, а потом парсер ошибок по всем логам для выжимки сухого остатка. Запустили на ночь, и пошли спать.

              На самом деле, все описанное умещается в одно емкое словосочетание Design automation.
                0
                Понял, спасибо!

                Приму на вооружение ваши советы по поводу скобок, действительно полезно и не даст запутаться. :)

                По поводу скрипта для flow. Зачем подсовывать каждый раз новые исходники и явно это указывать? Я постарался отойти от этой стадии и автоматизировать процесс поиска исходных файлов, чтобы разработчикам по команде не нужно было думать о том, что и как поменять. В том скрипте, на котором построен мой пример, нужно задать в качестве аргумента только кристалл ПЛИС, а проект соберется сам: найдет исходники, добавит ядра, обновит их, если надо, запустит синтез и имплемент. Таким образом, разработчику вообще не надо думать, что там в этом скрипте написано и зачем. Если есть четкие правила по именованию файлов верхнего уровня и расположению исходников, ядер и файлов для моделирования, то сам скрипт получается ещё проще.

                С batch-файлами действительно удобно. Мы как раз сейчас активно занимаемся автоматизацией проектирования (особенно для сложных проектов с объемом ресурсов ПЛИС >80%), чтобы не запускать ручками процессы, а прийти и увидеть картинку по лучшей разводке. :)
                  0
                  Лучше работать со списками файлов-исходников, и списком дефайнов. Почему? Потому что и исходники, и дефайны могут быть разные — набор для поведенческого временного моделирования, набор для имплементации ПЛИС, и несколько наборов для ASIC. Автоматизация поиска и составления списков в данном случае — враг, поскольку увеличивает вероятность сделать ошибку там, где ее можно исключить вовсе.

                  Но я имел ввиду несколько другое — при миграции от одного проекта к другому у Вас остается тот же flow-скрипт, а меняются лишь подгружаемые tcl модули с дефайнами, списками и констрентами. Когда используете отлаженное flow, меньше делаете ошибок.
              0
              Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}

              Пардон, а можно ссылочку, где такое предлагается?


              По работе довольно много на Tcl пишу, и никогда фигурных скобочек у имен переменых не требовалось, только значок доллара.

                0
                https://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm 7й пункт Variable substitution

                Я тремя постами выше обьяснял, почему желательно фигурные скобки ставить. Транслятор в качестве названия переменной берет из текста все символы за долларом до пробела, либо то, что заключено в фигурных скобках.
              +1
              Спасибо за статью! Есть пара вопросов по изе.

              Оно все такое же глючное и падучее, как и раньше? Поменялись ли лицензионные ограничения для Webpack версии в последнее время или все такие же суровые?

              Сделали ли линуксовую версию утилиты FPGA View или ее так и забросили совсем на уровне Win32 приложения? Уж очень было прикольно смотреть на реальную топологию кристалла, а не на абстрактные квадратики со стрелочками в ISE.
                +1
                Добрый день!

                С лицензиями все по-старому. ISE вообще имеет свойство от версии к версии становиться только хуже. Благо, разработка закончилась на версии 14.7. К счастью, со всеми косяками можно совладать и привыкнуть к этим «особенностям» среды. Да, она все ещё глючная, но Vivado не менее глючная, чем ISE.

                Кроме того, на Windows 10 вообще отказываются работать 64-битные приложения от Xilinx. Программирование через Impact вообще не работает. Приходится сидеть в 32-битных ISE, PlanAhead etc. а программировать через 32-bit ChipScope Analyzer. Создать из bit файла mcs можно только через командную строку или TCL скрипт. Загрузить mcs во флешку — средствами ISE вообще не получилось. Моделирование в ISim частенько отваливается и вылетает. Такие вот пироги.

                Если вы про FPGA Editor под Linux, то ответа не знаю, не пробовал.
                  0
                  OMFG, понятно… Я просто надеялся на то, что есть хоть какой-то прогресс. А у других производителей ситуация отличается? Говорят, Quartus и вообще софт от Altera поживее.

                  Да, FPGA Editor, конечно же. Название забыл.
                    0
                    Я сейчас редко пользуюсь Quartus, но в нем вообще никогда не имел проблем, все очень интуитивно. Может быть из-за того, что он мне сейчас для работы нужен раз-два в месяц. Но в нем даже прошивку зашить проще, если в JTAG-цепочке стоит две разные ПЛИС: Altera и Xilinx.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Говорят, Quartus и вообще софт от Altera поживее.

                        Верно говорят. Причём, «поживее» — не то слово. Quartus по сравнению с Xilinx ISE — сверхстабильная и сверхудобная среда разработки. В нём просто работаешь, занимаешся делом, а не воюешь с глюками среды разработки, лезущими как тараканы из каждой щели.
                          0
                          А как там с поддержкой железа? Есть ли аналог FPGA Editor-а? Насколько удобно делать Place & Route?

                          Наконец, какие возможности предоставляются людям, которые просто хотят поиграться с демобордой и покопаться в недрах камушков, но не хотят платить за лицензию?
                            +1
                            Несколько не понял вопрос насчёт поддержки железа… Про какое «железо» речь? Если про чипы, то естественно, Quartus заточен под альтеровские матрицы.

                            По поводу аналога FPGA Editor-а ничего сказать не могу — мы не используем подобные инструменты в разработке.

                            Насчёт удобства Place & Route — опять-же не понял… FPGA это же не печатная плата — чтобы разводить её вручную. Фиттер Квартуса прекрасно справляется с поставленной задачей сам. Конечно, может появиться необходимость в «тонкой настройке» фиттера — в Квартусе для этого есть всё необходимое. Но в моей практике ни разу не возникло необходимости этим заниматься.

                            Ну а насчёт поиграться с демобордой — с этим проблем вообще нет никаких. Скачиваете Quartus II Web Edition (современное название — Quartus Prime Lite Edition), создаёте в нём проект под Вашу демоборду или нет, ещё проще, открываете какую-нибудь демку, идущую в комплекте с демобордой и вперёд и с песней — играйтесь наздоровье. Возможностей WEB-эдишена для этого более чем достаточно.
                              0
                              Спасибо, я думаю вы ответили на мои вопросы.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Place & Route — это размещение блоков на кристалле. Очень полезная вещь, если нужно, чтобы сигналы успевали дойти до следующего блока в одно и то же время. На работе в Xilinxe ISE такое использовал, когда боролся с проблемами сигналов на высоких частотах.
                                  Разрешите поинтересоваться — о каких частотах речь?
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Да, серьёзные частоты. На таких частотах вполне может понадобиться ручная доводка. Нам пока что выше 200 не приходилось делать.
                                        +1
                                        Вы говорите о полностью ручной расстановке и трассировке логических вентилей в ПЛИС через FPGA Editor, или вы делали расстановку путём добавления pblock-s на floorplanning? Если первое, то это действительно круто. А второй способ — вроде как типичное средство достижения требуемых тактовых частот. Нам в проектах с рабочей частотой 350МГц хватало расстановки pblocks нужным образом, иначе от разводки к разводке частоты получались всегда разные. Плюс, еще есть такая штука как Promote partitions, когда закрепленные блоки удачно разведены на требуемую частоту, и в дальнейшем эта разводка и размещение используются для уменьшения времени сборки прошивки (при условии, что внутри этих блоков логика не менялась).
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            Понял! Собственно, мы стараемся делать аналогично, если частоты обработки переваливают за 300 МГц. Как правило, основные проблемы таймингов связаны с длинными путями распространения сигналов. Часто спасает добавление триггеров в цепочку, но есть места, где этого сделать невозможно (узлы с обратными связями, например). Кстати, в этом плане у Vivado есть несомненный плюс — она без всех этих размещений для относительно простых проектов старается сделать максимально «хорошо», и ручное размещение практически не требуется.

                                            Но! Живой пример (против Vivado): в проекте используется два контроллера PCI-e gen3 x8 и два контроллера памяти DDR3 для Virtex-7. ISE с минимальной расстановкой по кристаллу и ограничениями через pblocks разводит за час, а Vivado либо не разводит вообще, либо разводит в разы дольше, и по таймингам проект у неё свести не получается.
                        0
                        del
                          0
                          Зачастую TCL применяется в связке с графической оболочкой Tk (Tool Kit), но в рамках этой статьи этот аспект рассматриваться не будет.

                          Про TK можно посмотреть здесь

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое