[Angel 0]

Существует такое понятие как стиль программирования.

Кто что думает по этому поводу.

В атаче некоторые соображения.vhdl2proc.pdf

[des00 25]

Существует такое понятие как стиль программирования.

Кто что думает по этому поводу.

В атаче некоторые соображения.vhdl2proc.pdf

<{POST_SNAPBACK}>

 

Хмм занятный документ, подход к двухпроцессной архитектуре интересен, но не всегда возможен. А вот идея с интерфейсами с помошью записей ИМХО очень даже ничего.

[andrew_b 14]

подход к двухпроцессной архитектуре интересен, но не всегда возможен. А вот идея с интерфейсами с помошью записей ИМХО очень даже ничего.

Фтопку. Старик Оккам был прав.

Не понимаю любовь аффтора к асинхронным процессам.

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

[des00 25]

Не понимаю любовь аффтора к асинхронным процессам.

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

<{POST_SNAPBACK}>

Но ведь любая схема состоит из комбинационной части и регистровой части, какая разница где совместить все это, в одном процессе или в двух. Другое дело что в в случае с асинхронными процесами гораздо легче ошибиться и "сделать" ненужные latch, в верилоге 2001 с этим проще. :)

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

 

ИМХО стиль програмирования быть должен, что бы код был "читабельне" но как найдти оптимум ..... :)

[ASN 0]

Angel

Да ужё года два как используем. В больших проекта нормально. А когда IDE научатся подерживать извлечение структуры записей из пакетов (аля автодополнение как SE, VCA и подобные) - вообще будет хорошо. И, кстати, IMHO, с применением записей код становится меньше. Да и дисциплинирует. Можно посмотреть на SystemC - там такой же подход.

[des00 25]

Angel

Да ужё года два как используем. В больших проекта нормально. А когда IDE научатся подерживать извлечение структуры записей из пакетов (аля автодополнение как SE, VCA и подобные) - вообще будет хорошо. И, кстати, IMHO, с применением записей код становится меньше. Да и дисциплинирует. Можно посмотреть на SystemC - там такой же подход.

<{POST_SNAPBACK}>

Можно вопрос? не могли бы вы прояснить зачем в этой доке в пакете делают объявление компонента ? Что бы в архитектуре объекта, более высокой иерархии, не объявлять его ?

[ASN 0]

des00

Как я понял - да. Но этого мы не делаем. :)

Просто с записями сокращается пространство имён. Легче отлаживать весь проект. Да и моделируется он значительно быстрее. Очень удобно документировать.

Я сам сначала негативно относился к предложенной идее. Коллеги убедили :).

Сейчас по другому уже в трудно.

[des00 25]

des00

Как я понял - да. Но этого мы не делаем.  :)

Просто с записями сокращается пространство имён. Легче отлаживать весь проект. Да и моделируется он значительно быстрее. Очень удобно документировать.

Я сам сначала негативно относился к предложенной идее. Коллеги убедили :).

Сейчас по другому уже в трудно.

<{POST_SNAPBACK}>

понял спасибо

[andrew_b 14]

Другое дело что в в случае с асинхронными процесами гораздо легче ошибиться и "сделать" ненужные latch

Во-во, лишня сущность --- лишняя степень свободы для ошибки.

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

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

 

не могли бы вы прояснить зачем в этой доке в пакете делают объявление компонента ? Что бы в архитектуре объекта, более высокой иерархии, не объявлять его ?

Начиная с VHDL'93 можно спокойно жить без деклараций компонентов.

[Angel 0]

Хмм занятный документ, подход к двухпроцессной архитектуре интересен, но не всегда возможен. А вот идея с интерфейсами с помошью записей ИМХО очень даже ничего.

<{POST_SNAPBACK}>

 

Почему не всегда возможен?

[des00 25]

Хмм занятный документ, подход к двухпроцессной архитектуре интересен, но не всегда возможен. А вот идея с интерфейсами с помошью записей ИМХО очень даже ничего.

<{POST_SNAPBACK}>

 

Почему не всегда возможен?

<{POST_SNAPBACK}>

 

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

[Angel 0]

Для двухпроцессной архитектуры:

например, есть два компонента А и В.

 

component А

port (

rst : in std_logic;

clk : in clk_type;

pcli : out pcl_in_type;

pclo : in pcl_out_type);

end component;

 

component В

port (

pcli : in pcl_in_type;

pclo : out pcl_out_type);

end component;

 

Port map не привожу, думаю и так понятно как они соединяются.

Так вот, вопрос если в А используется только один сигнал pclo.start (кроме того в типе pclo есть и еще сигналы). Компилятор предупреждает что остальные не используются. На это что не обращать внимания? Или надо по другому все это переписать?

[des00 25]

Для двухпроцессной архитектуры:

например, есть два компонента А и В.

 

component А

    port (

        rst  : in std_logic;

        clk  : in clk_type;

        pcli  : out pcl_in_type;

        pclo  : in pcl_out_type);

    end component;

 

component В

    port (

        pcli  : in pcl_in_type;

        pclo  : out pcl_out_type);

end component;

 

Port map не привожу, думаю и так понятно как они соединяются.

Так вот, вопрос если в А используется только один сигнал pclo.start (кроме того в типе pclo есть и еще сигналы). Компилятор предупреждает что остальные не используются. На это что не обращать внимания? Или надо по другому все это переписать?

<{POST_SNAPBACK}>

 

по идее для входов нужно задать константные значения,

выходы сделать open

[Angel 0]

Если выходы сделать open, то как тогда если будет третий компонент:

component С

port (

rst : in std_logic;

clk : in clk_type;

pcli : out pcl_in_type;

pclo : in pcl_out_type);

end component;

 

Который использует те выходы В, которые будут open?

[des00 25]

Если выходы сделать open, то как тогда если будет третий компонент:

component С

    port (

        rst  : in std_logic;

        clk  : in clk_type;

        pcli  : out pcl_in_type;

        pclo  : in pcl_out_type);

    end component;

 

Который использует те выходы В, которые будут open?

<{POST_SNAPBACK}>

вот если будет третий компонент, который использует эти выходы, то open выходы делать не надо.

Их можно и вообще не объявлять, но тогда ИМХО это не есть правило хорошего тона