Здравствуйте. Не могу на RTL заставить синтезатор использовать выделенные межкаскадные связи BCOUT-> BCIN в DSP48 Xilinx. Если вставляю макрос DSP48, то такая связь работает, а если описывают просто на RTL через символы * и +, то не хочет подсоединять через выделенные, подсоединяет через обычные порты. В прикреплении реализовал умножитель 35 на 35 битов из примера Spartan-6 FPGA DSP48A1 Slice, стр. 29, там сигнал B использует выделенные межкаскадные связи BCOUT -> BCIN. В исходнике с помощью параметра можно переключаться между 2мя различными вариантами: через макрос и просто через конструкции языка. Никак не получается заставить синтезатор использовать эти выделенные связи по второму варианту. Как уже только не исхитрялся, и атрибут KEEP_HIERARCHY ставил, и USE_DSP48, фантазия кончилась... Пробовал в ISE и в Vivado. Вообще мне надо под SPARTAN6, а Vivado его не поддерживает, пришлось в Vivado выбрать Virtex7, а там архитектура DSP48 немножко другая... хотя суть та же. Исходник под Vivado не менял. А в таком виде Vivado тоже не справилась, не захотела увидеть и провести межкаскадные связи. Хотя вот в старом документе (в свежем этого абзаца уже нет) XST User Guide for Virtex-4, Virtex-5, Spartan-3, and Newer CPLD Devices на стр. 222 говорится:Я пробовал и включать, и отключать KEEP_HIERARCHY (см. исходники) - не помогло.

Может кому удавалось заставить синтезатор?

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

Была подобного рода проблема с Синплифаем и использованием dedicated входов-выходов PCIN PCOUT. Синплифай по какой-то своей непонятной логике иногда их использовал, а иногда нет. Это сильно сказывалось на времянке - частоты были высокие. Решилось всё тоже макросами, не вижу в данном случае ничего страшного. Когда нужно выжимать быстродействие не зазорно и до уровня макросов опускаться, ибо все синтезаторы немного тупят в тонких моментах.

З Ы. Возможно это - глюк XST. Попробуйте Синплифай на ваш код натравить.

Спасибо за опыт. К стати, в том же примере, который я реализовал, возможно использовать и PCOUT -> PCIN, но почему-то, согласно рисунку 1-17 авторы этого не предлагают. Ну и я не реализовывал.
Синплифай не честно, нужно ограничиваться стандартными инструментами. А то холивар получится нечистый )) Типа "вот RTL ничем не уступает, только надо очень хитрый синтезатор" ))) Таких оговорок быть не должно )))
У меня частота по результатам PAR в пустом кристалле 390МГц для SPARTAN6 (думаю, неплохо). При том одинаковая хоть с использованием выделенных путей, хоть без. Разница лишь в небольшом увеличении потребления рассыпухи.

ЗЫ: Вопрос на засыпку: Vivado использует XST или у неё свой синтезатор?

Что значит "стандартные инструменты"? Синтезаторов разных куча, под разные семейства ПЛИС. И синтезатор XST - явно не самый лучший. Начнём с того, что он даже SV синтаксис не понимает. Так зачем использовать неудачный инструмент при наличии альтернативы?
У Вивады - свой синтезатор. По моему имхо он малость ещё сыроват, но всё равно лучше чем XST.
390 MHz - это теоретический максимум для самого шустрого Спартана6 (индастриалы в таком спидгрейдё не делают). Соответствует даташиту.

Добрый день. Раз уж заговорили про симплифай.
Однажды было всё очень тесно и быстро в кристалле, а DSP не использованных было много.. Решили по максимуму использовать их возможности. В том числе и в качестве сдвиговых регистров, и для переходов между доменами. Спустя пару дней возни с симплифаем оставил это дело и решил использовать примитивы. Но не тут-то было - в RTL DSP стоит, в FPGA Editor виден, но.. не работает!
Уж тут пошло дело на принцип. Ещё спустя несколько дней заставил симплифай гарантированно синтезировать именно ту конструкцию из DSP, которую я задумал.
При этом выработал несколько правил:
1) Выносить конструкцию из ДСП в отдельный компонент с обязательным атрибутом syn_hier "fixed".
2) ПОЛНОСТЬЮ описывать архитектуру, применяя стандартные разрядности шин и даже внешние управляющие порты, которые в реальности использоваться не будут.
3) Обязательно применять атрибут syn_dspstyle(достаточно в целом к архитиктуре).
4) Применять syn_keep к регистрам, которые каким-либо образом могут быть оптимизированы синтезатором.
Возможно, здесь есть избыточность, но.. главное надёжность!
Пример конструкции из 4 ДСП: Нажмите для просмотра прикрепленного файла
Если говорить о XST, то не представляю как можно его заставить сделать подобное, если даже с симплифаем такие проблемы. А ведь в XST даже результат синтеза толком не посмотреть

Вместо инициированного холивара начался другой холивар, какой синтезатор лучше )))

Это не всем нужно. У меня исходник на вхдл, таковы правила предприятия.

Альтернатива, да не совсем. Она платная, а это сужает вероятность её применения. Получается такой ответ на мой холиварный вопрос, типа "вот RTL ничем не уступает, только надо заплатить бабок за крутой синтезатор". Работодатель скажет (и будет пожалуй по-своему прав), что желание писать на RTL (вместо макросов) не может являться экономическим обоснованием доп. затрат на покупку синтезатора. Купили тебе ISE (или Vivado), вот и работай в нём, а если тебе неудобно описывать макросами - то терпи, мы тебе и так зп платим, а ты хочешь ещё чтобы мы потратились на синтезатор.

Так что извините, не могу принять Вашу сторону, остаюсь на своей стороне, что платный Синплифай использовать не честно, холивар получится нечистый.

У меня сейчас нет возможности использовать Синплифай. Если у Вас есть немножко времени, Вы могли бы засинтезить мой пример в нём и посмотреть, появились ли каскадные связи? Там просто проект из двух исходников, один топовый, засинтезировать как есть.



Я в конечном счёте и это проделал, но для XST и Vivado не помогло.

Из этого пункта я только применил стандартные разрядности шин. И то только для XST, т.е. для SPARTAN6. Для Vivado и для VIRTEX7 там разрядности уже отличаются. Но факт в том, что оба синтезатора в целом прекрасно увидели DSP48 в моей конструкции языка, увидели перемножитель, увидели аккумулятор. Не увидели только межкаскадные связи.
А описывать внешние управляющие порты, которые использоваться не будут - это уже тогда мы скатываемся на уровень макросов. Их минус в громоздкости, ненаглядности и непортируемости. То же мы обеспечим и конструкциями языка, если всё-всё опишем. А нам это не надо, нам от описания конструкциями языка нужно получить преимущество.


Ну тут у меня по третьему пункту в настройках проекта стояло "авто" на использовании ДСП, но, раз ДСП он в целом увидел, то проблема не здесь. По пункту 4 - то же. Ничего не выкинул, поставил всё, что нужно. Только связи межкаскадные не провёл.




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


Я в Planahead схему смотрю, в принципе всё есть. Если проект большой и срочно - то иногда в ISE делаю View Technology Schematic. В принципе тоже почти всё показывает. Но это я касаемо проблем, подобных моей, говорю.
А Вы что не смогли посмотреть?

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


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



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


Ещё раз. Никакого холивара разводить не собираюсь. Грамотный развивающийся инженер должен ориентироваться во всех используемых в индустрии тулзах и подходах
даже если их и не использует по какой-то причине. Для того чтобы не загнуться профессионально. Ваш выбор как поступить - шашечки или ехать.


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

Как вариант можно делать компоненты-"обертки" для DSP48, выводить наружу только нужные сигналы (BCIN, BCOUT) и в коде использовать эти "обертки". Получается менее громоздко, более наглядно. Вопрос портируемости можно решить generic'ами.

Всё украдено до нас. У Хилых есть специальный макрос DSP48, который как раз выводит наружу только необходимые порты, а всю внутреннюю кухню скрывает.

Как-то пытался сделать подобные вещи, но нужно было использовать ACOUT-> ACIN для DSP48Е1. Причем:
1) Без использования pre-adder,
2) С использованием pre-adder (A+D). Причем на порт D заходила константа.

Никак, хотя XST все прекрасно понимает.

В итоге простые вещи, связанные с DSP48 стараюсь делать так: unisim primitive DSP48 описываю на нужный функционал в отдельном vhd файле и подключаю его как компонент. Атрибуты задаются внутри и неиспользуемые ноги за пределы компонета не выводятся. В крайнем случае вытаскиваю через generic связку INMODE, OPMODE, ALUMODE. Поскольку раньше такое приходилось делать часто - рука набита именно на этот способ.

Заранее спасибо. У меня почти аналогичный путь (только VHDL в самом конце) и аналогичные позывы от VHDL )))) Но деваться некуда, пришлось освоить и использовать.
Про адекватность предприятия поржал ))) Но руководство обидится, если прочитает. Военка российская, всё по стандарту. А по стандарту VHDL.
Я к стати непротив холивара в данном случае, не стыдитесь ) Я собственно холивар и развёл. Просто ради академической истины, что ли...


Раз уж упомянули предсумматор, то обнародую свой опыт. Делал комплексный умножитель 18х18, написал всё конструкциями языка. XST увидела DSP48, но сделала в нём только умножитель и аккумулятор. Я удивился. Скормил Виваде. Та и предсумматор увидела. Я успокоился.

Хочу похвастаться своими успехами.
Вот такую схему:
Нажмите для просмотра прикрепленного файла
реализовал вот таким кодом:

Т.е. это простой перемножитель комплексных чисел с накоплением суммы нескольких произведений (взятие линейной комбинации входных сигналов с применением некоторых весовых коэффициентов), реализованный в последовательной форме, когда одна операция делается за несколько тактов. Здесь необходимо переключать сложение-вычитание, а также в некоторые моменты времени начинать накопление с начала, для чего подавать 0 вместо обратной связи.
Радуюсь, что удалось обойтись вот такой малой кровью, а то поначалу светила перспектива описывать DSP48 как макроблок (неприятная рутина).

ЗЫ: это всё скушал XST под Spartan-6.

Действительно, так гораздо лучше. А что получается если убрать слой pp2 ?

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

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

BEAM_BW = 16. Предположил, что синтезатор "считает", что слишком жирно ставить сумматор для складывания 16 битов. Поставил 30 - не полегчало.
В настройках синтеза в ISE стоит -use_dsp48 = Auto. Предположил, что в коде что-то криво описано, и такой сумматор в принципе невпихуем в DSP. Поставил Auto Max - реализовало на DSP. Т.е. код получается нормальный? Тогда почему же не синтезирует при Auto? Ему же русским по белому написано в коде:
(* use_dsp48 = "yes" *)

Не могу сказать за XST (это нигде явно в доках не описано), но Синплифай ведёт себя так : сумматор будет сделан на DSP только если один из операндов суммирования есть результат умножения (это если речь про выходной сумматор) или если сумма далее по коду умножается на что-то (входной сумматор). В остальных случаях лепит сумматоры на логике.

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

Вообще идея использовать DSP блоки в качестве сумматоров довольно странная. В современных ПЛИС за счёт логики переноса производительность сумматоров на DSP и на "рассыпухе" практически сравнялась.
Поэтому гробить DSP блоки на банальное суммирование как-то не очень рационально.

вопрос чисто принципиальный. Синтезатор ослушался прямого указания в виде (* use_dsp48 = "yes" *).

За XST не скажу, но в Симплифае это всего лишь рекомендация.

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

Не знаю, как на verilog, а на VHDL мне помогло атрибут прописать не для сигнала, а для entity, в котором сделал обычный сумматор как отдельный компонент.

Мне "как отдельный компонент" не хочется - нарушается читабельность. У меня этих DSP-шек в одном файле описывается несколько, и умещается всё это в один экран кода, читабельность на высоте )))
Если уж делается "отдельный компонент", то можно и макроблок вставить, а там уже резвиться и использовать полный функционал, который, например, я не смог реализовать на RTL в первом сообщении этой темы.

Ещё некоторая дополнительная информация от моего коллеги, что невозможно на RTL написать соединение PCOUT -> PCIN, если эти порты находятся в разных модулях: https://forums.xilinx.com/t5/Welcome-Join/C...ros/td-p/754013