Виаком
телефон
поискпоиск входаккаунт корзинакорзина


на складе в Киеве под заказ

не выполнен вход

 

Новости компании



03.10.2012

Системное проектирование в оболочке QSYS. Заметки практика

Загрузить статью в PDF (0,05 Мб) >>

Третью статью цикла (cм. 1 и 2, а также №№ 6, 7 "CHIP NEWS Украина") об особенностях проектирования на ПЛИС Altera мы решили посвятить выявленным нами неточностям, "багам" в работе с оболочкой. Такого рода "баги" есть в любых сложных системах и, как правило, в официальной литературе об этом не сказано ничего или сказано вскользь. Поэтому разработчику приходится обращаться в службу сервиса производителя, которая часто реагирует достаточно вяло, или же самостоятельно искать варианты решения проблемы на соответствующих форумах. Мы же хотим избавить пользователя системы Qsys от этих мытарств хотя бы в тех случаях, когда неточность была выявлена нашими практикующими инженерами.

Вспоминаются слова замечательного артиста Аркадия Райкина (из напутствия директора завода молодым инженерам): "Забудьте индукцию и дедукцию — давайте продукцию!". Первое, что поддается сомнениям, это преимущество стандартных интерфейсов (см. 1или "CHIP NEWS Украина", № 7). Qsys поддерживает только AVALON или AXI! Другие внутри оболочки просто нельзя использовать. Тут подсказка: внутри-то - нельзя, а вот снаружи - можно, т. е. если вы выведете сигналы своего нестандартного интерфейса наружу и объедините их вне оболочки Qsys, то все очень даже работает. О неудобствах таких решений писалось в предыдущей статье, повторяться не будем. Но! Системы получаются работоспособными и "по росту" разработчика (имеется ввиду профессиональный уровень). Только не забудьте: для того, чтобы ваш компонент было возможно интегрировать в систему, он должен содержать хотя бы один стандартный интерфейс.

Тут надо остановиться и сделать несколько предостережений тем, кто проектирует свои компоненты для Qsys или SOPS Builder (предшественник Qsys).

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

Второе - не все ранее созданные и распространявшиеся компоненты можно использовать в Qsys. Более того - не все версии Qsys (соответствующие версиям Quartus) одинаково поддерживают одни и те же компоненты! И это несмотря на внешне нормальное поведение и самой оболочки, и генераторов используемых ядер. Особенно это касается компонентов от партнеров Altera. Внимательно изучите документацию на компонент, который собираетесь применять: МОЖНО ли его в вашей среде использовать.

Третье — с мостами в последних версиях Qsys происходит что-то непонятное. Поэтому иногда сгенерированную, полностью отлаженную и успешно работающую систему, спроектированную, например, в среде Qsys Quartus 11.1 SP2 будет просто невозможно (даже с переделками/доделками) использовать в среде QsysQuartus 12, включая и SP2. Нонсенс, но такой факт имеет место. Тут поможет только полная переделка системы под "норов" установленного у вас Quartus… Или (что значительно надежнее) тщательное изучение того, какие мосты как и в какой последовательности генерируются системой. Благо, документация есть, и она должна быть всегда под рукой. А дальше - можно и руками поправить, если проект сложный и время дорого. Ведь файл, сгенерированный для системы — открытый и допускает любое обычное для "верилоговских" файлов использование/ редактирование. Сделаю отступление для людей, использующих для сравнения файлов различные редакторы (типа Araxis-megre, Ultracompare, и т. п.) - сверить файлы при различных генерациях (даже одной и той же системы!) для выявления изменений очень затруднительно из-за произвольного порядка включения блоков и мостов в тело файла системы (файл топ-уровня). А если учесть, что в этом "файлике" может быть более 12000 строк, изменять/исправлять его надо очень осторожно.

Четвертое - используйте отдельные проекты для создания, отладки и обкатки своих компонентов. Это сильно упрощает поиск ошибок и уменьшает время, потраченное на отладку проекта в целом. Тут сделаю замечание по порядку включения вашего ядра в систему: простые доверьте включать Qsys-у, а вот сложные, многофайловые, требующие своих временных построений при компиляции и анализа временных соотношений, лучше всего включать с помощью .qip файла и формировать в проекте в отдельной директории. Немного хлопотно, надо поработать руками, зато гибкость при отладке или замене на новую версию компонента отличная! Результат - если в компоненте, оформленном подобным образом, не изменялись интерфейсы подключения, то, заменив его файлы на новые, не понадобится даже регенерировать систему. Просто компилируйте.

Пятое - помните, что все интерфейсы и прочие атрибуты вашего компонента находятся в файле <имя файла>.tcl. Файл текстовый, редактирование руками доступно и даже может быть в ряде случаев рекомендовано, особенно если компонент сложный, а интерфейсов много. Его даже можно заранее написать для компонента или создать, например, заготовку.

Шестое - не увлекайтесь иерархией в Qsys. Трудно установить допустимое количество потоковых задержек (interconnect pipeline) ввиду трудностей с использованием/выводом на верхний уровень некоторых сигналов, в том числе и тактовых (по поводу сигналов — имеется соответствующая errata от Altera). Например, при построении системы, содержащей мощное 24-канальное ядро 10GBASE-RPHY, контроллеры DDR3 и RLDRAM и подсистему 1G ETHERNET так и не удалось получить даже подобия правильной работы в варианте разбиения проекта на, неважно, две или три подсистемы. В то же время система, сделанная "по старинке" (т. е. без иерархии), успешно генерировалась и столь же успешно работала. Справедливости ради следует сказать, что простые примеры, которые приводятся в документации для иллюстрации возможностей иерархии, успешно компилируются и работают. Вообще надо отметить ориентирование всех примеров на аппаратуру демонстрационных плат Altera (dev. boards). Это обстоятельство определяет и некоторое количество ошибок и неточностей в документации на Qsys и (особенно!) на ядра компонентов. Эти неточности делают в ряде случаев невозможным выполнение ядром некоторых функций в составе изделия. Ведь в демонстрационной плате (и в проекте для нее) такого просто не было предусмотрено. Поэтому относитесь к документации не как к догме, а как к руководству к действию. Ошибаемся не только мы, хотя наши ошибки - наиболее вероятные. В качестве подтверждения сказанного выше можно привести ошибку в проекте, демонстрирующем работу ядра DDR3. Из-за неправильного подключения сигнала soft_reset систему просто невозможно загрузить из ПЗУ, хотя она замечательно работает при запуске из консоли NIOS2 SBT Eclips. Более того - невозможно программировать этот самый загрузочный ПЗУ (неважно какой - или последовательный типа EPCS, или параллельный CFI) средствами SBT! Система просто останавливается из-за невозможности правильно сбросить NIOS. А поиск ошибки (особенно из-за характера замечаний, выдаваемых при этом SBT) вообще уводит в сторону от проблемы, заставляя искать причину в интерфейсе подключения конфигурационной памяти.

Теперь - вообще самое "преступное". При генерировании/создании сложных систем возникает потребность в моделировании этих самых систем. Для этого в состав пакета Quartus входит Modelsim в двух вариантах - бесплатном (с ограниченным количеством строк моделируемого кода) и требующем дополнительной лицензии, но не имеющем подобных ограничений варианте ModelsimAE. Важно правильно сгенерировать и файлы для симуляции проекта, и тестовую систему для моделирования! В предыдущей статье упоминалось, где и как это подключить в Qsys. Тут сразу сделаю замечание для тех, кто пользуется VHDL и использует ядра , написанные на Verilog или SystemVerilog: получится одновременное использование двух языков при моделировании, а это может и не поддерживаться поставляемым в комплекте с Quartus Modelsim-ом. И для тех, кто, наоборот, использует в качестве основного языка Verilog, а подключает VHDL файлы, могут возникнуть те же самые проблемы. Для самых последних версий (11.1 и 12.0) авторы этого уже не проверяли, так как используют в работе полную версию ModelsimSE, которая предназначена для многоязычного моделирования. Запускать моделирование системы лучше всего используя NIOS2 SBT, так как в этом случае происходит правильное и корректное формирование/подключение контекста памяти в систему. И вот уже даже при моделировании ваша система может, поработав, зависнуть безо всяких видимых причин! В этом случае опять же рекомендуем внимательно проверить сгенерированные Qsys-ом мосты (если все остальное, разумеется, проверено и в норме). Если у вас есть опыт по использованию интерфейсов AVALON, можете просто исключить из состава системы некоторые из мостов вручную и выполнить соединение блоков "напрямую". Это особенно полезно, если в этих блоках системы не предполагается арбитраж, а соединения происходят в обход основных шин адреса/данных AVALON. Примером может служить подключение пользовательского компонента с двумя интерфейсами к шинам адреса/данных NIOS2 (один интерфейс) и контроллеру внешней памяти (второй интерфейс). Сказанное выше (удаление мостов) в этом случае может быть произведено для интерфейса, связанного с внешней памятью. Быстродействие системы после такого изменения резко возрастает, а сбои (зависания) пропадают. Но это уже, как говорят, только для опытных пользователей.

Теперь о работе с SBT. Самое неприятное тут - это случай, когда при правильно установленном пакете Quartus ваша система не может найти интерфейса программирования (USB-Blaster, например). Хотя программатор, вызываемый из оболочки собственно Quartus-а, работает успешно и все находит. В этом случае предлагается использовать системную консоль и подачу команд из нее. Однако это резко ограничивает возможности, предоставляемые SBT для отладки вашего проекта. Выходом из этой ситуации, как правило, является либо полная переустановка Quartus, либо установка его на другой машине.

В заключение хотелось бы упомянуть о правильной работе с анализом временных соотношений. Создавая собственные компоненты, не забывайте, если это необходимо, создавать для них и .sdc файлы. Это как раз и выполняется в ходе обкатки создаваемого компонента в отдельном проекте. Внимательно следите за появляющимися изменениями или errata на применяемые вами компоненты. Помните, что в ряде случаев в документах прямо указывается, что можно игнорировать, а что — нельзя. Для тех, кто по каким-либо причинам еще не успел освоить Time Quest Timig Analizer рекомендую произвести простой поиск в интернете: переведенной на русский язык документации и примеров, вместе с разъяснениями как этим пользоваться, сейчас много. Выберите подходящий. Одно не допускается - работа без учета ошибок временных соотношений или просто их игнорирование. Успешных вам проектов!

Для получения дополнительной информации обращайтесь к официальному дистрибьютору компании Altera в Украине- ООО "Виаком" 03061, г. Киев, пр. Отрадный, 95-с, тел./факс: (044) 507-02-02 (многоканальный), добавочный номер 130 - технический консультант Игорь Коврига, igor.kovryga@biakom.kiev.ua




 
изготовление печатных плат | плис altera | микроконтроллеры atmel | магазин электронные компоненты | разъёмы amphenol | трансформаторы hahn | okw | tyco | vicor | marquardt | инструмент pro'skit