13. Использование библиотек. Конфигурирование содержимого конструкции в Verilog HDL

Использовании библиотек и схемы подключения к файлам Verilog HDL
Содержание

Первая часть статьи Конфигурирование содержимого конструкции и Синтаксис Library(библиотек).

13.4 Использование библиотек и конфигураций

В этом подпункте описываются потенциальные модели использования ссылок на конфигурации в командной строке. Он включен для пояснения.

Традиционная модель использования Verilog-симуляторов использует файловый подход, при котором исходные описания для всех ячеек в проекте задаются в командной строке для каждого вызова инструмента. С появлением симуляторов с компилированным кодом механизм конфигурации должен также поддерживать модель использования, которая позволяет предварительно компилировать исходные файлы, а затем ссылаться на предварительно скомпилированные объекты проектирования в командной строке. В этом подпункте объясняется, как конфигурации могут быть использованы в обоих этих сценариях.

13.4.1 Предкомпиляция в однопроходной модели использования

Однопроходная модель использования — это традиционная модель использования, с которой знакомо большинство пользователей. В этой модели использования все файлы исходных описаний предоставляются симулятору через командную строку, и только эти исходные описания могут быть использованы для привязки экземпляров ячеек в текущем проекте. Стратегия прекомпиляции в этой модели сценарий фактически анализирует каждое описание ячейки, предоставленное в командной строке, и сопоставляет его с библиотекой, не обращая внимания на то, используется ли эта ячейка в проекте. Инструмент может опционально проверить, существует ли ячейка в библиотеке, и, если она актуальна (т.е. описание источника не изменилось с момента последней компиляции ячейки), может пропустить перекомпиляцию ячейки. После компиляции всех ячеек в командной строке инструмент может найти ячейку верхнего уровня (обсуждалось в пункте 12) и двигаться вниз по иерархии, связывая каждый экземпляр по мере его появления в иерархии.

При такой модели использования нет необходимости в том, чтобы объекты библиотеки сохранялись от одного вызова инструмента к другому (хотя по соображениям производительности рекомендуется, чтобы они сохранялись).

Перевод Официального Стандарта Verilog HDL

13.4.2 Компиляция времени элаборации в однопроходной модели использования

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

13.4.3 Предварительная компиляция с помощью отдельного инструмента компиляции

При использовании отдельного инструмента компиляции необходимо, чтобы библиотечные ячейки сохранялись, поэтому скомпилированные формы должны существовать где-то в файловой системе. Точный формат и место хранения этих скомпилированных форм зависит от производителя или инструмента. Используя эту отдельную стратегию компилятора, исходные описания должны быть разобраны и скомпилированы в библиотеку с помощью одного или нескольких вызовов инструмента компилятора. Единственным ограничением является то, что все ячейки в design должны быть предварительно скомпилированы до связывания design (обычно с помощью вызова отдельного инструмента). При использовании этой стратегии инструменту, который фактически выполняет связывание, нужно сообщить только модуль(и) верхнего уровня проекта, который нужно связать, а затем он должен использовать предварительно скомпилированную форму описания ячейки(ей) из библиотеки для определения экземпляров и спускаться по иерархии вниз по проекту, связывая каждую ячейку по мере ее нахождения.

13.4.4 Соображения по поводу командной строки

В каждой из трех предыдущих стратегий либо правила связывания могут быть указаны через config, либо могут использоваться правила по умолчанию (из файла library map). В однопроходных моделях использования config может быть указана путем включения в командную строку файла описания ее источника. В случае, если config включает оператор design, то объявленная ячейка должна быть модулем верхнего уровня, независимо от наличия любых неподлежащих описанию ячеек в остальных исходных файлах. При использовании отдельного инструмента компиляции, инструменту, который фактически выполняет связывание, необходимо предоставить только спецификацию lib.cell для ячейки верхнего уровня и/или config, которая будет использоваться. При такой стратегии сам config также должен быть предварительно скомпилирован.

13.5 Примеры конфигурации

Рассмотрим следующий набор описаний источников:
// file top.v
module top(...);
    ...
    adder a1(...);
    adder a2(...);
endmodule
module foo(...);
    ... // rtl
endmodule

// file adder.v
module adder(...);
    ... // rtl
    foo f1(...);
    foo f2(...);
endmodule
module foo(...);
    ... // rtl
endmodule

// file adder.vg
module adder(...);
    ... // gate-level
    foo f1(...);
    foo f2(...);
endmodule
module foo(...);
    ... // gate-level
endmodule

// file lib.map
library rtlLib top.v;
library aLib adder.*;
library gateLib
adder.vg;
Все примеры в этом подпункте предполагают, что файлы top.v, adder.v и adder.vg компилируются с заданным файлом lib.map. В результате получается следующая структура библиотеки:
rtlLib.top //  из top.v
rtlLib.foo // из top.v
aLib.adder // из adder.v
aLib.foo // rtl из adder.v
gateLib.adder // из adder.vg
gateLib.foo // из adder.vg

13.5.1 Конфигурация по умолчанию из файла карты библиотеки

При отсутствии конфигурации поиск библиотек осуществляется в соответствии с порядком объявления библиотек в файле library map. Другими словами, все экземпляры модуля adder будут использовать aLib.adder (потому что aLib — первая объявленная библиотека, содержащая ячейку с именем adder), а все экземпляры модуля foo будут использовать rtlLib.foo (потому что rtlLib — первая библиотека, содержащая foo).

13.5.2 Использование пункта по умолчанию

Чтобы всегда использовать определение foo из файла adder.v, используйте следующую простую конфигурацию:
config cfg1;
    design rtlLib.top ;
    default liblist aLib rtlLib;
endconfig

Утверждение default liblist переопределяет порядок поиска библиотек в файле lib.map. Поэтому aLib всегда ищется перед rtlLib. Поскольку библиотека gateLib не включена в список liblist, описания сумматора и foo на уровне gate не будут использоваться.

Чтобы использовать представления на уровне вентилей для adder и foo, добавьте в конфигурацию следующее:
config cfg2;
    design rtlLib.top ;
    default liblist gateLib aLib rtlLib;
endconfig

Это приведет к тому, что представление строба всегда будет приниматься перед представлением rtl, используя определения модулей adder и foo из файла adder.vg. Представление top в формате rtl будет приниматься, поскольку представление строба отсутствует.

13.5.3 Использование условия ячейки

Чтобы изменить конфигурацию для использования rtl-представления сумматора и представления foo на уровне строк из gateLib, используйте следующее:
config cfg3;
    design rtlLib.top ;
    default liblist aLib rtlLib;
    cell foo use gateLib.foo;
endconfig

Пункт cell выбирает все ячейки с именем foo и явно связывает их с представлением вентилей в gateLib.

13.5.4 Использование условия экземпляра

Чтобы изменить конфигурацию так, чтобы сумматор top.a1 (и его потомки) использовал представление строба и сумматор top.a2 (и его потомки), используйте rtl-представление из aLib:
config cfg4
    design rtlLib.top ;
    default liblist gateLib rtlLib;
    instance top.a2 liblist aLib;
endconfig

Поскольку список liblist наследуется, все потомки top.a2 наследуют его список liblist из условия выбора экземпляра.

13.5.5 Использование иерархической конфигурации

Теперь предположим, что вся эта работа была проведена только над модулем сумматора, а конфигурация, использующая ячейку rtlLib.foo для f1 и ячейку gateLib.foo для f2, уже разработана. Тогда используйте следующее:
config cfg5;
    design aLib.adder;
    default liblist gateLib aLib;
    instance adder.f1 liblist rtlLib;
endconfig
Чтобы использовать эту конфигурацию cfg5 для экземпляра adder top.a2 и взять полный aLib adder по умолчанию для экземпляра top.a1, используйте следующую конфигурацию:
config cfg6;
    design rtlLib.top;
    default liblist aLib rtlLib;
    instance top.a2 use work.cfg5:config ;
endconfig

Пункт binding указывает, что конфигурация work.cfg5:config должна использоваться для разрешения привязок экземпляра top.a2 и его потомков. Это в объявление конфигурации cfg5 определяет точное связывание для самого экземпляра top.a2. Остальная часть cfg5 определяет правила связывания потомков top.a2. Обратите внимание, что пункт instance в cfg5 относится к собственному модулю верхнего уровня, adder.

13.6 Отображение информации о привязке библиотеки

Должна быть предусмотрена возможность отображения фактической информации о привязке библиотеки для экземпляров модуля во время моделирования. Спецификатор формата %l или %L должен выводить информацию о привязке library.cell для экземпляра модуля, содержащего ключевое слово display (или другой текстовый вывод). Это аналогично спецификатору формата %m, который печатает имя иерархического пути содержащего его модуля.

Он также должен иметь возможность использовать VPI для отображения информации о привязке. Следующие свойства VPI должны существовать для объектов типа vpiModule:

  • vpiLibrary — имя библиотеки, в которую был скомпилирован модуль
  • vpiCell — имя ячейки, связанной с экземпляром модуля
  • vpiConfig- имя библиотеки.cell конфигурации, управляющей привязкой экземпляра модуля

Эти свойства должны быть строкового типа, аналогично свойствам vpiName и vpiFullName.

13.7 Примеры отображения библиотек

При отсутствии конфигурации можно осуществлять базовое управление порядком поиска в библиотеке при привязке дизайна.

Когда используется конфигурация, она отменяет правила, указанные в этом подпункте.

13.7.1 Использование командной строки для управления поиском библиотек

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

Рекомендуется, чтобы все совместимые инструменты использовали «-L \<имя_библиотеки>» для указания этого порядка поиска.

13.7.2 Примеры спецификации пути к файлу

Например:

Дан следующий набор файлов:
/proj/lib1/rtl/a.v
/proj/lib2/gates/a.v
/proj/lib1/rtl/b.v
/proj/lib2/gates/b.v
Из библиотеки /proj следующие абсолютные спецификации пути_файла разрешаются, как показано на рисунке:
/proj/lib*/*/a.v =/proj/lib1/rtl/a.v, /proj/lib2/gates/a.v
.../a.v =/proj/lib1/rtl/a.v, /proj/lib2/gates/a.v
/proj/.../b.v =/proj/lib1/rtl/b.v, /proj/lib2/gates/b.v
.../rtl/*.v =/proj/lib1/rtl/a.v, /proj/lib1/rtl/b.v
Из каталога /proj/lib1 следующие относительные параметры пути_файла разрешаются, как показано на рисунке:
../lib2/gates/*.v = /proj/lib2/gates/a.v, /proj/lib2/gates/b.v
./rtl/?.v = /proj/lib1/rtl/a.v, /proj/lib1/rtl/b.v
./rtl/ = /proj/lib1/rtl/a.v, /proj/lib1/rtl/b.v

13.7.3 Передача нескольких спецификаций пути

Например:
library lib1 "/proj/lib1/foo*.v";
library lib2 "/proj/lib1/foo.v";
library lib3 "../lib1/";
library lib4 "/proj/lib1/*ver.v";
При оценке из каталога /proj/tb следующие исходные файлы должны быть отображены в объявленную библиотеку:
../lib1/foobar.v - lib1 // потенциально соответствует lib1 и lib3. Поскольку lib1
                        // включает имя файла, а lib3 указывает только каталог; lib1
                        // имеет приоритет
/proj/lib1/foo.v - lib2 // имеет приоритет над спецификациями путей lib1 и lib3
/proj/lib1/bar.v - lib3
/proj/lib1/barver.v - lib4 // имеет приоритет над спецификацией пути lib3
/proj/lib1/foover.v - ERROR // соответствует lib1 и lib4
/test/tb/tb.v - work // не соответствует никаким спецификациям библиотеки.