[maior 0]

Если в оригинальном проекте на альтеру использовались lpm-модули (black-boxes): lpm_ram_dp/dq/cs, lpm_add_syb, lpm_mult - как грамотно, красиво и быстро перевести (перенести) все это (и весь проект) на xilinx. А может даже создать "универсальный", типа переключаемый через configuration для обеих платформ, проект. Для альтеры использoвался Аpex, для xilinx нужен Virtex. Все это для связки алдек-синплифай-IST с использованием VHDL как языковой основы. Просто я еще не имел дело с xilix и егоным ISE. А надо! Дайте пожалуйста несколько ценных указаний.

[bbg 0]

А в чем проблема-то? LPM - это "Библиотека Параметризуемых Модулей".

Там чистый ультра-переносимый HDL. Должно без проблем синтезироваться.

Хоть на Стратиксе, хоть на Виртексе. Канечна, мултиплаеры в Виртексе - это будет на совести ISE :)

[maior 0]

Неправильно! - LPM от альтеры это не код а блэк-боксы, на VHDL/AHDL/Verilog существует только их описание и istantiation rules. Реальные физические блоки логики вставляются на этапе "place&route", то есть при разводке кристала. Мой вопрос - как правильно обойти такую зависимость от вендора уже в исходном коде, чтобы облегчить миграцию с одного вендора к другому не меняя код в проекте (кроме разве что файла конфигурации), если в проекте есть блэк-боксы. Использовать последние необходимо, так как именно в этом случае достигается мксимальная производительность, гарантируемая вендором. Может есть такой гайд, как не используя явной декларации блэк-боксов, используя только VHDL код, обепечить таки их включение в проект для всех (или большинства вендоров), а не логически (но не физически!) эквивалентный код (какой-нибудь VHDL текст c Opencore, например), который и съест все ресурсы кристалла и реально работать нормально не будет.

[gab 0]

Неправильно! - LPM от альтеры это не код а блэк-боксы, на VHDL/AHDL/Verilog существует только их описание и istantiation rules. Реальные физические блоки логики вставляются на этапе "place&route", то есть при разводке кристала. Мой вопрос - как правильно обойти такую зависимость от вендора уже в исходном коде, чтобы облегчить миграцию с одного вендора к другому не меняя код в проекте (кроме разве что файла конфигурации), если в проекте есть блэк-боксы. Использовать последние необходимо, так как именно в этом случае достигается мксимальная производительность, гарантируемая вендором. Может есть такой гайд, как не используя явной декларации блэк-боксов, используя только VHDL код, обепечить таки их включение в проект для всех (или большинства вендоров), а не логически (но не физически!) эквивалентный код (какой-нибудь VHDL текст c Opencore, например), который и съест все ресурсы кристалла и реально работать нормально не будет.

<{POST_SNAPBACK}>

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

[bbg 0]

Пардон, оказывается, на телесистемах у вас уже целая дискуссия по этой темме..

Изменено 22 декабря, 2004 пользователем bbg

[maior 0]

Да уж, танцевать - так с музыкой и всем вместе!