[Loki5000 0]

Вопрос касается языка VHDL.

Но обо всем по порядку.

Есть некая внутрикристальная шина. Типы сигналов этой шины описаны в packag-e. Ширина некоторых сигналов может

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

Например, ширина поля адреса и ширина поля данных.

Значения варьируемых параметров(то бишь ширины) определены в отдельном, "конфигурационном" packag-e.

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

А "конфигурационный" package в каждом проекте свой. Помимо этих package-й в библиотеку также входят компоненты

ядра шины и различных вспомогательных блоков.

 

Теперь встала задачка использовать в одном и том же проекте две одинаковые шины,

но с разными параметрами (с разной шириной данных). Да еще и с доступом из одной в другую.

 

Какие есть идеи? Как можно решить такую задачку?

 

Сам вижу 2 варианта, но у обоих есть недостатки.

 

Вариант 1.

Использовать тип unconstrained std_logic_vector для сигналов, ширина которых отличается в 2-х шинах.

Т.е. фактически полностью отказаться от "конфигурационного" packag-a.

Недостатком этого варианта является то, что под существующий вариант библиотеки (с "конфигурационным" packagе-м)

уже разработано множество компонентов (часть из которых требуется использовать и в этом проекте)

которые используют атрибут 'length для определения ширины поля данных.

Хотелось бы избежать их переделки.

 

Вариант2.

Сделать копию библиотеки с другим именем. И использовать обе эти библиотеки.

Недостатком этого варианта является то, что любое изменение в библиотеке придется делать дважды.

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

Возможно, этот недостаток можно обойти, если использовать ссылки на библиотеку work.

Тут у меня вопрос, если в проекте в двух разных библиотеках имеются одинаковые packag-и (одноименные).

И в обеих библиотеках есть компоненты ссылающиеся на этот package с помощью конструкции:

use work.package.all;

То будут ли в таком случае компоненты из разных библиотек ссылаться на package из своей собственной

библиотеки или нет? Или это будет зависеть от средства моделирования и синтеза?

Но даже если все получиться, то по меньшей мере придется править ссылки на библиотеку шины в блоках подцепленных

к копиям библиотеки.

[Loki5000 0]

Небольшое дополнение.

 

Помимо выше указанного недостатка Варианта 1.

Так же повсеместно используется присвоение с директивой others =>

Что не допускается при использовании типа unconstrained std_logic_vector.

[Maverick_ 15]

Вопрос касается языка VHDL.

Но обо всем по порядку.

Есть некая внутрикристальная шина. Типы сигналов этой шины описаны в packag-e. Ширина некоторых сигналов может

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

Например, ширина поля адреса и ширина поля данных.

Значения варьируемых параметров(то бишь ширины) определены в отдельном, "конфигурационном" packag-e.

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

А "конфигурационный" package в каждом проекте свой. Помимо этих package-й в библиотеку также входят компоненты

ядра шины и различных вспомогательных блоков.

 

Теперь встала задачка использовать в одном и том же проекте две одинаковые шины,

но с разными параметрами (с разной шириной данных). Да еще и с доступом из одной в другую.

 

Какие есть идеи? Как можно решить такую задачку?

 

Сам вижу 2 варианта, но у обоих есть недостатки.

 

Вариант 1.

Использовать тип unconstrained std_logic_vector для сигналов, ширина которых отличается в 2-х шинах.

Т.е. фактически полностью отказаться от "конфигурационного" packag-a.

Недостатком этого варианта является то, что под существующий вариант библиотеки (с "конфигурационным" packagе-м)

уже разработано множество компонентов (часть из которых требуется использовать и в этом проекте)

которые используют атрибут 'length для определения ширины поля данных.

Хотелось бы избежать их переделки.

 

Вариант2.

Сделать копию библиотеки с другим именем. И использовать обе эти библиотеки.

Недостатком этого варианта является то, что любое изменение в библиотеке придется делать дважды.

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

Возможно, этот недостаток можно обойти, если использовать ссылки на библиотеку work.

Тут у меня вопрос, если в проекте в двух разных библиотеках имеются одинаковые packag-и (одноименные).

И в обеих библиотеках есть компоненты ссылающиеся на этот package с помощью конструкции:

use work.package.all;

То будут ли в таком случае компоненты из разных библиотек ссылаться на package из своей собственной

библиотеки или нет? Или это будет зависеть от средства моделирования и синтеза?

Но даже если все получиться, то по меньшей мере придется править ссылки на библиотеку шины в блоках подцепленных

к копиям библиотеки.

Я выбрал бы второй вариант.

То будут ли в таком случае компоненты из разных библиотек ссылаться на package из своей собственной

библиотеки или нет?

Будут так как в списке подключаемых библиотек Вы пропишете конкретную библиотеку в созданном описании цифровой схемы. Пример ниже

 

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

use work.Const_type.all; -- вот тут названия будут разные

 

entity proverka is

 

Port (

CLK : in std_logic;

rst : in std_logic;

x : my_array;

y : my_array;

 

s : out std_logic_vector (10 downto 0) );

end proverka;

 

architecture behavioral of proverka is

 

begin

 

.....

[Sefo 0]

Я выбрал бы второй вариант.

 

Будут так как в списке подключаемых библиотек Вы пропишете конкретную библиотеку в созданном описании цифровой схемы. Пример ниже

 

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

 

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;


entity Top is
  port
    (           
      .........
    );
end;

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

architecture RTL of Top is
                                 
component A
  port
    (           
      CLK : in std_logic;
      rst : in std_logic;
      x : my_array;
      y : my_array;
    );
end component;

component B
  port
    (           
      CLK : in std_logic;
      rst : in std_logic;
      x : my_array;
      y : my_array;
    );
end component;

У них ведь my_array разные, а как это объяснить синтезатору?

[Loki5000 0]

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

use work.Const_type.all; -- вот тут названия будут разные

 

entity proverka is

 

Port (

CLK : in std_logic;

rst : in std_logic;

x : my_array;

y : my_array;

 

s : out std_logic_vector (10 downto 0) );

end proverka;

 

architecture behavioral of proverka is

 

begin

 

.....

Так а я как раз хочу в этом месте оставить одинаковые названия!

т.е. ссылаться на одноименные packag-и находящиеся в разных библиотеках.

У каждого компонента в его библиотеке свой package. А т.к. вместо имени библиотеки я хочу подставить work,

то указанная строчка будет выглядеть одинаково в компонентах из разных библиотек.

Вопрос будет ли это работать?

Я использую менторовский HDL Designer, и могу соотвественно во второй библиотеки сделть просто link на файл с архитектурой из первой.

Оставив тем самым единственный "исходник", а значит все изменения в нем будут распространяться на обе библиотеки сразу.

 

Вариант 3.

А как на счет использования конфигураций для решения указанной задачи?

Кто-нибудь использовал их в таком ключе?

[Sefo 0]

Вопрос касается языка VHDL.

 

:a14:

 

Хороший вопрос. Надо будет на выходных подумать как лучше разрешить проблему.

[Loki5000 0]

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

...

У них ведь my_array разные, а как это объяснить синтезатору?

Да, сопряжение компонентов из разных библиотек это еще отдельная задачка.

Вижу пока такой вариант:

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

Затем этот интерфейс подключается к блоку, содержащему в себе всю часть схемы относящуюся ко 2-ой шине.

А внутри этого блока происходит преобразование стандартных типов уже в типы 2-ой шины (2-ой библиотеки).

Таким образом, в top-e объявляется 1-ая библиотека, а в этом блоке 2-ая библиотека.

Тем самым мы избегаем неопределенности и соответственно необходимости развернутого указания типов.

 

 

Хороший вопрос. Надо будет на выходных подумать как лучше разрешить проблему.

Спасибо. Буду рад любой помощи!

[Maverick_ 15]

Так а я как раз хочу в этом месте оставить одинаковые названия!

т.е. ссылаться на одноименные packag-и находящиеся в разных библиотеках.

У каждого компонента в его библиотеке свой package. А т.к. вместо имени библиотеки я хочу подставить work,

то указанная строчка будет выглядеть одинаково в компонентах из разных библиотек.

А в чем сложность изменения одной строчки? Почему вы хотите оставить одинаковые названия?

[Loki5000 0]

А в чем сложность изменения одной строчки? Почему вы хотите оставить одинаковые названия?

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

Одна копия будет ссылаться на одну библиотеку, а вторая на другую.

Блоки постоянно совершенствуются. Изменения придется делать в обеих копиях.

А использовать обе копии одного и того же блока на одном уровне иерархии будет нельзя, т.к. имена типов буду совпадать.

Если использовать развернутые имена типов или вообще переименовать их, то это уже далеко ни одна строчка.

А точнее это то же самое, что еще одна копия шины и всех блоков под нее отличающихся только названием библиотеки и названиями типов.

Т.е. все разработки x2

[Loki5000 0]

Попробую описать проблему по-другому.

Имеется некоторый компонент, состоящий из иерархии более мелких под-компонентов.

Компонент и все под-компоненты используют некий под-тип (subtype) определенный в общем для этих компонентов packag-e.

Стоит задача использовать в проекте 2 экземпляра (instanc-a) этого компонента отличающихся друг от друга определением под-типа (subtype).

Т.е. использующих разные (каждый свой) packag-и для определение этого под-типа.

 

Например.

Имеется контроллер памяти способный работать с памяться разной ширины (n = 8, 16,.. бит).

При этом он использует под-тип: subtype st_MemData is std_logic_vector(n-1 downto 0); определенный в packag-e.

Где n задается взависимости от ширины используемой памяти.

 

Как использовать 2 экземпляра этого контроллера в одном и том же проекте для 2-х памятей разной ширины?

 

Чтобы один экземпляр используя тип st_MemData работал, например, с std_logic_vector(7 downto 0)

а второй, используя тот же тип st_MemData работал с std_logic_vector(15 downto 0)?

 

:help:

 

Вот нашел обсуждение этой же проблемы на буржуйском форуме:

 

http://www.velocityreviews.com/forums/t293...dl-package.html

 

Тут она описана по-другому, но смысл тот же.

[des00 25]

Попробую описать проблему по-другому.

Имеется некоторый компонент, состоящий из иерархии более мелких под-компонентов.

Компонент и все под-компоненты используют некий под-тип (subtype) определенный в общем для этих компонентов packag-e.

Стоит задача использовать в проекте 2 экземпляра (instanc-a) этого компонента отличающихся друг от друга определением под-типа (subtype).

Т.е. использующих разные (каждый свой) packag-и для определение этого под-типа.

 

Например.

Имеется контроллер памяти способный работать с памяться разной ширины (n = 8, 16,.. бит).

При этом он использует под-тип: subtype st_MemData is std_logic_vector(n-1 downto 0); определенный в packag-e.

Где n задается взависимости от ширины используемой памяти.

 

Как использовать 2 экземпляра этого контроллера в одном и том же проекте для 2-х памятей разной ширины?

 

Чтобы один экземпляр используя тип st_MemData работал, например, с std_logic_vector(7 downto 0)

а второй, используя тот же тип st_MemData работал с std_logic_vector(15 downto 0)?

 

не вижу проблемы вообще :)

 

1. заворачиваем два контроллера в aplication specific wrapper. Это позволит вам отвязаться от типизации

2. собираем два контроллера как разные compilation unit.

3. интегрируем их в проект как компоненты разных compilation unit.

 

С точки зрения поддержки разных симуляторов проблем не вижу вообще. С точки зрения синтеза зависит от используемого синтезатора.

 

Например путь на альтере, с использованием только квартуса :

для не последних чипов я бы выбрал такой :

1. собираем vqm файлы

2. подключаем vqm файлы как файлы проекты

для последних чипов немного сложнее

1. собираем qxp файлы

2. подключаем qxp файлы как файлы проекта

 

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

 

Удачи!!! %)

[Loki5000 0]

1. заворачиваем два контроллера в aplication specific wrapper. Это позволит вам отвязаться от типизации

2. собираем два контроллера как разные compilation unit.

3. интегрируем их в проект как компоненты разных compilation unit.

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

А как сделать его таковым? Т.е. как его отладить?

С точки зрения поддержки разных симуляторов проблем не вижу вообще.

Надеюсь вы согласитесь, что моделировать нетлисты с целью отладки - лишено смысла.

 

Так что

не вижу проблемы вообще :)

позвольте не согласиться, проблема тут есть!

[des00 25]

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

А как сделать его таковым? Т.е. как его отладить?

 

Надеюсь вы согласитесь, что моделировать нетлисты с целью отладки - лишено смысла.

 

Так что

 

позвольте не согласиться, проблема тут есть!

 

я разве что то говорил о нетлистах? вы смотрите слишком узко, повторюсь еще раз, на примере симулятора.

 

1. заворачиваем два контроллера в aplication specific wrapper. Это позволит вам отвязаться от типизации

 

т.е. заворачиваем ваши компоненты с конфигурируемыми шинами во врапперы заточенные под конкретную шину. Т.е. был компонент my_conf_ram_ctrl из которого торчат recordы/типы, а стало два компонента my_ram_ctrl_data_x8, my_ram_ctrl_data_x32 из которого торчат обычные типы общего применения (по сути расплетаем веник).

 

2. собираем два контроллера как разные compilation unit.

 

создаем две либы my_ram_ctrl_data_x8_lib/my_ram_ctrl_data_x32_lib и компилируем контроллеры + настройки + враперы порознь. Имеем две функциональные модели для быстрого моделирования.

 

3. интегрируем их в проект как компоненты разных compilation unit.

 

в вашем проекте создаете ваши новые шины, с нужными вам типам например axi_8_bit/axi_32_bit и к этим типам подключаете врапперы. затем просто

 

vsim -L my_ram_ctrl_data_x8_lib -L my_ram_ctrl_data_x32_lib work.my_uut_tb

 

вы можете отлаживать что хотите и как хотите. Если будет найдена ошибка в компонентах my_conf_ram_ctrl вы правите ее, а затем вызовом vsim -c do compile_ram_ctrl_libs.do получаете новые либы для симуляции. Вероятность ошибки минимум.

 

Все элементарно, просто и понятно, это же ООП в чистом виде :). Вы же делаете application specific проект, тащить туда конфигурируемые хвосты это лишний геморрой.

[Sefo 0]

 

Похоже, решить задачу именно так, как Вы хотите можно только отказавшись от конфигурационного package и перейдя на использование generic. Правда, возможность такого перехода сильно зависит от содержимого package с типами сигналов.

 

Вы могли бы выложить оба package (конфигурационный и с типами сигналов) и описание топового Entity для шины? Поскольку решение желаемой Выми "красоты" если и можно найти, то только для конкретного примера.

 

Вариант 3.

А как на счет использования конфигураций для решения указанной задачи?

Кто-нибудь использовал их в таком ключе?

 

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

[des00 25]

Сделать копию библиотеки с другим именем. И использовать обе эти библиотеки.

Недостатком этого варианта является то, что любое изменение в библиотеке придется делать дважды.

 

PS для 3-х проектов на основе общего ядра я веду 3 ветки разработки, когда нахожу ошибку в базовом ядре в какой либо ветке, то простой svn merge решает все проблемы на внесение изменений в другие