[AlexRayne 7]

Здрасте всем.

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

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

есть ли какойто мотив использовать компоненты а не код? (симулятор может меньше ресурсов кушает, или надежность кода страдает?)

[AJIEKCEu 0]

Собственно это основная фишка языков описания аппаратуры.

Я например компонентами вставляю что-то достаточно большое и функционально законченное.

А счетчик, регистр и т.п. всегда быстрее в одну строчку написать.

 

Мне кажется особого мотива использовать компоненты нет. Есть мотив грамотно писать код :)

[LV26 0]

Собственно это основная фишка языков описания аппаратуры.

Я например компонентами вставляю что-то достаточно большое и функционально законченное.

А счетчик, регистр и т.п. всегда быстрее в одну строчку написать.

 

Мне кажется особого мотива использовать компоненты нет. Есть мотив грамотно писать код :)

 

Согласен. Кроме этого если несколько человек над проектом работает - то это единственный выход.

В принципе можно компоненты и в библиотеку загнать... но это дело вкуса.

[des00 25]

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

 

дык не пишите, это не обязательно, если кое что сделать заранее %)

 

что по мне, то

 

always_ff @(posedge clk) begin 
  pipa <= popa; 
end

 

быстрее (особено с шаблонами в редакторе) и понятнее чем вставлять сие как компонент %)

[SM 0]

Использование компонента (если этот компонент представляет какую-то физическую сущность технологии) оправдано в случаях:

- оптимизация чего либо вручную, если с этим не справляется синтезатор.

- вставление такого "нечто", которое не инферрится синтезатором из конструкций языка. Например PLL или DCS

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

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

 

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

[Mahagam 0]

Только натуральный код:

а) синтезатор иногда сам умный

б) переносимость

[SM 0]

Только натуральный код:

...

б) переносимость

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

[Beby 5]

Преимущественно пишу на языке, не гнушаюсь по мере надобности плотненько набивать код constraint'ами (для того, чтобы XST/MAP/PAR делали именно то, что я задумал).

 

Использование компонента (если этот компонент представляет какую-то физическую сущность технологии) оправдано в случаях:

- оптимизация чего либо вручную, если с этим не справляется синтезатор.

- вставление такого "нечто", которое не инферрится синтезатором из конструкций языка. Например PLL или DCS

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

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

 

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

С SM полностью согласен. Исходя из этих же соображений применяю компоненты для IBUF/OBUF, BUFG, DLL(DCM), RAMB (чтобы RAMB использовались именно так, как я задумал и не подавались GND сигналы на неиспользуемые входы данных - этот прием достаточно хорошо уменьшает лишнии связи в зоне RAMB). Для описания особо скоростных мест создал свою небольшую библиотеку (кристаллозависимую, очень плотно набитую RLOC), и использую её, чтобы жестко задавать взаимное расположение особых частей проекта.

[Mahagam 0]

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

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

что касается ASICов - то я ж с ними не работал. ничего сказать не могу. но вижу что граблей там куда больше чем с плисинами.

 

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

[andrew_b 15]

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

А умываться по утрам не забываешь?

[SM 0]

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

Это кто же Вас так жестоко дезинформировал? Или Вы не работали с такими ПЛИС, у которых есть блоки, поддерживающие даже полностью асинхронную работу? И если синтезаторы умнее Вас, это только минус Вам, но ни как не плюс синтезатору.

[Mahagam 0]

Это кто же Вас так жестоко дезинформировал? Или Вы не работали с такими ПЛИС, у которых есть блоки, поддерживающие даже полностью асинхронную работу? И если синтезаторы умнее Вас, это только минус Вам, но ни как не плюс синтезатору.

не. с такими ПЛИС не работал. пока что.

 

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

 

кстати, про ПЛИС с асинхронной памятью - это какие например? чисто энтомологический интерес.

[SM 0]

кстати, про ПЛИС с асинхронной памятью - это какие например? чисто энтомологический интерес.

старенькие ACEX, FLEX... Их мне до сих пор приходится юзать при прототипировании АСИКов, если нужна двухпортовая асинхронка...