[Krys 2]

Здравствуйте. Не могу на 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 говорится:

If your design contains several interconnected macros, where each macro can be implemented on DSP48, XST attempts to interconnect DSP48 blocks using fast BCIN/BCOUT and PCIN/PCOUT connections. Such situations are typical in filter and complex multiplier descriptions. XST can build complex DSP macros and DSP48 chains across the hierarchy when Keep Hierarchy (KEEP_HIERARCHY) is set to no. This is the default in ISE® Design Suite.

Я пробовал и включать, и отключать KEEP_HIERARCHY (см. исходники) - не помогло.

 

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

 

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

mult35x35.rar

[Bad0512 2]

Здравствуйте. Не могу на 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. Попробуйте Синплифай на ваш код натравить.

 

[Krys 2]

Спасибо за опыт. К стати, в том же примере, который я реализовал, возможно использовать и PCOUT -> PCIN, но почему-то, согласно рисунку 1-17 авторы этого не предлагают. Ну и я не реализовывал.

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

У меня частота по результатам PAR в пустом кристалле 390МГц для SPARTAN6 (думаю, неплохо). При том одинаковая хоть с использованием выделенных путей, хоть без. Разница лишь в небольшом увеличении потребления рассыпухи.

 

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

[Bad0512 2]

Спасибо за опыт. К стати, в том же примере, который я реализовал, возможно использовать и PCOUT -> PCIN, но почему-то, согласно рисунку 1-17 авторы этого не предлагают. Ну и я не реализовывал.

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

У меня частота по результатам PAR в пустом кристалле 390МГц для SPARTAN6 (думаю, неплохо). При том одинаковая хоть с использованием выделенных путей, хоть без. Разница лишь в небольшом увеличении потребления рассыпухи.

 

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

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

У Вивады - свой синтезатор. По моему имхо он малость ещё сыроват, но всё равно лучше чем XST.

390 MHz - это теоретический максимум для самого шустрого Спартана6 (индастриалы в таком спидгрейдё не делают). Соответствует даташиту.

 

[TRILLER 0]

Добрый день. Раз уж заговорили про симплифай.

Однажды было всё очень тесно и быстро в кристалле, а DSP не использованных было много.. Решили по максимуму использовать их возможности. В том числе и в качестве сдвиговых регистров, и для переходов между доменами. Спустя пару дней возни с симплифаем оставил это дело и решил использовать примитивы. Но не тут-то было - в RTL DSP стоит, в FPGA Editor виден, но.. не работает!

Уж тут пошло дело на принцип. Ещё спустя несколько дней заставил симплифай гарантированно синтезировать именно ту конструкцию из DSP, которую я задумал.

При этом выработал несколько правил:

1) Выносить конструкцию из ДСП в отдельный компонент с обязательным атрибутом syn_hier "fixed".

2) ПОЛНОСТЬЮ описывать архитектуру, применяя стандартные разрядности шин и даже внешние управляющие порты, которые в реальности использоваться не будут.

3) Обязательно применять атрибут syn_dspstyle(достаточно в целом к архитиктуре).

4) Применять syn_keep к регистрам, которые каким-либо образом могут быть оптимизированы синтезатором.

Возможно, здесь есть избыточность, но.. главное надёжность!

Пример конструкции из 4 ДСП: DSP_Style.vhd

Если говорить о XST, то не представляю как можно его заставить сделать подобное, если даже с симплифаем такие проблемы. А ведь в XST даже результат синтеза толком не посмотреть :)

[Krys 2]

Что значит "стандартные инструменты"? Синтезаторов разных куча, под разные семейства ПЛИС. И синтезатор XST - явно не самый лучший.

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

 

Начнём с того, что он даже SV синтаксис не понимает.

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

 

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

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

 

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

 

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

 

 

 

1) Выносить конструкцию из ДСП в отдельный компонент с обязательным атрибутом syn_hier "fixed".

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

 

2) ПОЛНОСТЬЮ описывать архитектуру, применяя стандартные разрядности шин и даже внешние управляющие порты, которые в реальности использоваться не будут.

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

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

 

 

3) Обязательно применять атрибут syn_dspstyle(достаточно в целом к архитиктуре).

4) Применять syn_keep к регистрам, которые каким-либо образом могут быть оптимизированы синтезатором.

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

 

 

 

 

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

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

 

 

А ведь в XST даже результат синтеза толком не посмотреть :)

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

А Вы что не смогли посмотреть?

 

[Bad0512 2]

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

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

неоднократно было подтверждено фактами.

 

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

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

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

написания коммерческого кода.

 

 

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

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

 

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

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

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

 

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

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

 

 

 

[Amurak 0]

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

 

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

[Bad0512 2]

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

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

[sallador 0]

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

 

Как-то пытался сделать подобные вещи, но нужно было использовать ACOUT-> ACIN для DSP48Е1. Причем:

1) Без использования pre-adder,

2) С использованием pre-adder (A+D). Причем на порт D заходила константа.

 

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

 

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

 

 

 

[Krys 2]

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

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

Про адекватность предприятия поржал ))) Но руководство обидится, если прочитает. Военка российская, всё по стандарту. А по стандарту VHDL.

Я к стати непротив холивара в данном случае, не стыдитесь ) Я собственно холивар и развёл. Просто ради академической истины, что ли...

 

 

2) С использованием pre-adder (A+D). Причем на порт D заходила константа.

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

 

[Krys 2]

Хочу похвастаться своими успехами.

Вот такую схему:

реализовал вот таким кодом:

(* use_dsp48 = "yes" *) reg addsub_pp, muxzero_pp;
(* use_dsp48 = "yes" *) reg  [DIN_BW-1 : 0] din_pp, cin_pp, din_pp2, cin_pp2;
(* use_dsp48 = "yes" *) reg  [DIN_BW*2 - 1 : 0] mult;
(* use_dsp48 = "yes" *) reg  [ACC_BW - 1 : 0] acc;
(* use_dsp48 = "yes" *) wire [ACC_BW - 1 : 0] dsp48_z; // z input of post-adder

// dsp48 slice logic
always @(posedge clk) begin
   addsub_pp   <= addsub;
   muxzero_pp  <= muxzero;
   din_pp      <= din;
   cin_pp      <= cin;
   din_pp2     <= din_pp;
   cin_pp2     <= cin_pp;

   mult <= din_pp2 * cin_pp2;
   if(addsub_pp == 0) begin
       acc <= dsp48_z + mult;
   end else begin
       acc <= dsp48_z - mult;
   end
end
assign dsp48_z = muxzero_pp ? acc : 0; 

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

Радуюсь, что удалось обойтись вот такой малой кровью, а то поначалу светила перспектива описывать DSP48 как макроблок (неприятная рутина).

 

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

[Timmy 1]

Хочу похвастаться своими успехами.

Радуюсь, что удалось обойтись вот такой малой кровью, а то поначалу светила перспектива описывать DSP48 как макроблок (неприятная рутина).

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

[Krys 2]

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

[Krys 2]

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

// separating I and Q components of the local beamformers signal and the one from adjacent FPGA
wire signed [bEAM_BW-1 : 0] loc_i, loc_q, adj_i, adj_q;
assign loc_i = fifo_out         [bEAM_BW   -1 : 0      ];
assign loc_q = fifo_out         [bEAM_BW*2 -1 : BEAM_BW];
assign adj_i = adj_data_f_al    [bEAM_BW   -1 : 0      ];
assign adj_q = adj_data_f_al    [bEAM_BW*2 -1 : BEAM_BW];

// pipeline registers inside of adder DSP block
(* use_dsp48 = "yes" *) reg signed [bEAM_BW-1 : 0] loc_i_int, loc_q_int, adj_i_int, adj_q_int;
always @(posedge clk) begin
   loc_i_int <= loc_i;
   loc_q_int <= loc_q;
   adj_i_int <= adj_i;
   adj_q_int <= adj_q;
end
// adder itself
(* use_dsp48 = "yes" *) reg signed [bEAM_BW-1 : 0] sum_i, sum_q;
always @(posedge clk) begin                                     
   sum_i <= loc_i_int + adj_i_int;
   sum_q <= loc_q_int + adj_q_int;
end

BEAM_BW = 16. Предположил, что синтезатор "считает", что слишком жирно ставить сумматор для складывания 16 битов. Поставил 30 - не полегчало.

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

(* use_dsp48 = "yes" *)