Помогите разобраться с библиотеками (VHDL) Опции

[Elf]

Всем привет и с наступающим Новым годом,

Наработав некоторое кол-во проектов (VHDL, Quartus) решил свалить более-менее универсальные компоненты и функции в пользовательскую библиотеку - в результате пришел к выводу, что не знаю как это сделать. Стал читать описания - продвинулся не сильно. Помогите разобраться с некоторыми вопросами:

1) Для примера (VHDL, Quartus)- библиотека парам. модулей: Library- LPM ... package -lpm_components...File - lpm_pack.vhd.
Если открыть файл - то он содежит пакет с объявлениями компонентов, а где хранятся собственно описания? Как вся эта "кухня" работает? Я поймал себя на том, что просто "втыкал" library и use, и не особенно задумывался по этому поводу.

2)Как подобно примеру приведенному выше создать собственную библиотеку.

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

Спасибо.

Сообщение отредактировал Elf - Dec 27 2006, 11:44

[Oldring]

Про Quartus не скажу ничего. Использовал билиотеки для Моделсима.

Все VHDL модули объекты компилируются в какие-то библиотеки. Новые объекты всегда компилируются в библиотеку с логическим именем WORK. Потом (при компиляции другого модуля) эту библиотеку можно использовать под другим именем как ресурсную библиотеку. Связь логических имен библиотек с путями на диске в принципе должна задаваться в настройках среды для каждого компилируемого модуля - логическое имя библиотеки не хранится в самой библиотеке. Иногда эти настройки глобальные. Директива VHDL 'library' вводит в текущее пространство имен логическое имя библиотеки.

В принципе, после объявления имени библиотеки можно использовать объекты из нее сразу без директивы use - написав полное имя объекта с указанием библиотеки. К сожалению, не все среды это поддерживают, хоть и обязаны. Директива use вводит указанные имена из библиотеки в текущее пространство имен - чтобы можно было использовать эти имена без префикса библиотеки.

Еще в начале каждого модуля неявно написано:

Код

library STD, WORK;
use STD.STANDARD.all;

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

[BSV]

Все VHDL модули объекты компилируются в какие-то библиотеки. Новые объекты всегда компилируются в библиотеку с логическим именем WORK.

Вот и неправда Ваша, можно указать ModelSim'у в какую библиотеку компилировать каждый файл. Это очень удобно, например, при поведенческом (до синтеза) моделировании проектов с большим числом компонентов (или состоящие из нескольких ПЛИС) - компоненты компиляем в одну библиотеку (для каждой ПЛИС - в свою), тестбенч - в другую.

Если прописать свою библиотеку в modelsim.ini лежащий в папке с ModelSim'ом, то она будет доступна всегда, каким бы образом моделирование ни запускалось.

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

[Oldring]

Все VHDL модули объекты компилируются в какие-то библиотеки. Новые объекты всегда компилируются в библиотеку с логическим именем WORK.

Вот и неправда Ваша, можно указать ModelSim'у в какую библиотеку компилировать каждый файл. Это очень удобно, например, при поведенческом (до синтеза) моделировании проектов с большим числом компонентов (или состоящие из нескольких ПЛИС) - компоненты компиляем в одну библиотеку (для каждой ПЛИС - в свою), тестбенч - в другую.

А вот и правда моя. У каждой физической библиотеки могут быть разные логические имена. Кроме того, библиотеки бывают рабочими и ресурсными. Рабочей называется та единственная библиотека, в которую компилируется текущий модуль. У нее при компиляции всегда есть логическое имя WORK. Конечно, при компиляции разных модулей это могут быть разные физические библиотеки. Читайте LRM.

Кстати, довольно удобно. Если нескорлько модулей компилируются в одну библиотеку - друг к другу они могут ссылаться через имя библиотеки WORK, а не под тем именем, под которым библиотека будет использоваться потом как ресурсная.

[vleo]

А вот и правда моя. У каждой физической библиотеки могут быть разные логические имена. Кроме того, библиотеки бывают рабочими и ресурсными. Рабочей называется та единственная библиотека, в которую компилируется текущий модуль. У нее при компиляции всегда есть логическое имя WORK. Конечно, при компиляции разных модулей это могут быть разные физические библиотеки. Читайте LRM.

Кстати, довольно удобно. Если нескорлько модулей компилируются в одну библиотеку - друг к другу они могут ссылаться через имя библиотеки WORK, а не под тем именем, под которым библиотека будет использоваться потом как ресурсная.

Да, проверил, Вы правы :-) Однако, я бы уточнил - можно собирать сразу в другую библиотеку, указав ее компилятору.

Например, в Aldec AHDL указывается какая библиотека будет рабочей в установках проекта,
в других имеющихся под рукой системах можно указать компилятору в какую библиотеку класть модуль:

ModelSim:
vlib xyz
vcom -93 -work xyz a.vhd,

в GNU-HDL:
ghdl -a --work=xyz a.vhd

в Free-HDL:
gvhdl -l xyz a.vhd

Но создается виртаульная библиотека work, только на время сборки модуля, как синоним. Вот пример этого, считая,
что компилируем вышеуказанными командами:

Код

---------------- a.vhd -----------------
entity E1 is
port (signal a: in bit; signal b: out bit);
end;

architecture A of E1 is
begin
   b <= not a;
end;

------------------------------------------------------

entity E2 is end;

architecture A of E2 is
signal x,y : bit;
begin
  u1: entity work.E1(A)
  port map (x,y);
end;
------------------------------------------------------

library xyz;
entity E3 is end;

architecture A of E3 is
signal x,y : bit;
begin
  u1: entity xyz.E1(A)
  port map (x,y);
end;

Что касается Quartus то смотрите 3 способа: страница 8-13 "Quartus II Version 6.0 Handbook", volume 1.
Самый прямолинейный - в Project Navigator/Design Files ПКМ на файле, Properties/Library - вписывается имя библиотеки,
то есть для нашего примера xyz.

[Oldring]

Да, проверил, Вы правы :-) Однако, я бы уточнил - можно собирать сразу в другую библиотеку, указав ее компилятору.

Например, в Aldec AHDL указывается какая библиотека будет рабочей в установках проекта,
в других имеющихся под рукой системах можно указать компилятору в какую библиотеку класть модуль:

http://electronix.ru/forum/index.php?s=&am...st&p=192511

конструкция library xyz; вводит в пространство имен модуля имя xyz как логическое имя некоторой библиотеки. Любой. Ничего больше. Логическое имя WORK описывать не нужно - оно введено в пространство имен с самого начала.

В разных модулях одна и та же физическая библиотека может быть под разными именами. Согласно стандарту связь между логическими библиотеками и физическими библиотеками задается в настройках VHDL системы. Система должна позволять такую связь устанавливать. Нравится GNU-HDL вводить при компиляции модуля в физическую библиотеку xyz связь логическое имя xyz = физическая библиотека xyz в дополнение к обязательному логическое имя work = физическое имя xyz - это их право. Но VHDL система не обязана так поступать, по крайней мере, без явной просьбы программиста.

Кроме того, если GNU-HDL не позволяет логическое имя xyz связать не с физической библиотекой xyz, а, скажем, с физической библиотекой abc - он нарушает требования LRM.

[vleo]

http://electronix.ru/forum/index.php?s=&am...st&p=192511



Кроме того, если GNU-HDL не позволяет логическое имя xyz связать не с физической библиотекой xyz, а, скажем, с физической библиотекой abc - он нарушает требования LRM.

Это что-ли наезд на gnu-HDL? Его поведение совершенно аналогично поведению vcom (ModelSim). А уж укладывается ли поведение vcom в IEEE-1076 - Вам виднее. Безусловно, там есть возможность связать любую физическую библиотеку с логическим именем. Но, те, что собраны под определенным именем, в рабочей директории проекта сразу под такими именами доступны, без дополнительных настроек.

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

Если провести аналогию с C, то требование стандарта звучит так, чтобы не было строгой привязки, то есть в
одной программе пишем:

#include <stdio.h>

а в другой пишем
#include <xyz.h>

а имеем в виду одно и тоже. Да на том же VHDL у Вас в одих модулях написаное:
library ieee;
use ieee.std_logic_1164.all;

а в других надо думать:

library xyz;
use xyz.std_logic_1164.all;

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

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

p.s. Делаю, специально для Вас, чтобы на эту тему не дискутировать

VHDL стандарт это самый лучший, самый справедливый стандарт в мире, те, кому что-то в нем не нравится - профессионально не пригодны, читать и перечитывать до просветления.

[Oldring]

Это что-ли наезд на gnu-HDL? Его поведение совершенно аналогично поведению vcom (ModelSim). А уж укладывается ли поведение vcom в IEEE-1076 - Вам виднее. Безусловно, там есть возможность связать любую физическую библиотеку с логическим именем. Но, те, что собраны под определенным именем, в рабочей директории проекта сразу под такими именами доступны, без дополнительных настроек.

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

Если провести аналогию с C, то требование стандарта звучит так, чтобы не было строгой привязки, то есть в
одной программе пишем:

#include <stdio.h>

а в другой пишем
#include <xyz.h>

а имеем в виду одно и тоже. Да на том же VHDL у Вас в одих модулях написаное:
library ieee;
use ieee.std_logic_1164.all;

а в других надо думать:

library xyz;
use xyz.std_logic_1164.all;

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

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

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

p.s. Делаю, специально для Вас, чтобы на эту тему не дискутировать

VHDL стандарт это самый лучший, самый справедливый стандарт в мире, те, кому что-то в нем не нравится - профессионально не пригодны, читать и перечитывать до просветления.

Это Ваше личное мнение - я такого не писал. Приведите конкретную цитату из стандарта, которая Вам не нравится - будет предмет спора по поводу стандарта. До сих пор спор был только о реализациях и о неправильном понимании стандарта.

P.S. Кстати, vcom - безусловно, не пример безупречной реализации VHDL. То есть он конечно поддерживает язык лучше, чем большинство синтезаторов. Но ряд не совсем тривиальных конструкций у меня отказывались в нем работать. IMHO если бы MSVC так поддерживал плюсы - компанию-разработчика бы растерзали.

P.P.S Кстати, это интересный вопрос - что произойдет с Вашим примером в моделсиме, если не отмаппировать предварительно логическое имя библиотеки xyz в физическую библиотеку xyz при помощи vmap, или если указать в качестве аргумента vcom -work имя физической библиотеки, начинающееся с цифры, но предварительно отмаппировать xyz в эту библиотеку. Я лично так никогда не пытался делать. Подозреваю, что в первом случае библиотека xyz будет все-таки не найдена, а во втором - будет все нормально.