Krys

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

Спасибо. А если у меня VHDL 2002, то получается никак?.. Мысль возникла: а не получится ли так сделать через процедуры? Написать процедуру, в которую подставить исходную широкую шину и затем её составляющие, а процедура заполнит составляющие в порядке их перечисления в качестве аргументов процедуры. Я понимаю, что при заранее известном количестве аргументов это вполне возможно. Но возможно ли это для заранее неизвестного количества аргументов? Было бы довольно-таки красиво. ...Ещё как вариант - написать их штук 10 для количества аргументов в диапазоне 1..10 ))) И пусть перезагружается, какая процедура нужна в данном случае. Смущает только, что все 10 раз нужно будет прикладывать мозги и вручную описывать разбор по индексам. Лучше конечно, чтобы по предыдущему варианту, для заранее неизвестного числа аргументов. Если это возможно. ... А ещё если возможно как идея: такую же процедуру навроде function "-"(L : UNRESOLVED_SIGNED; R : STD_ULOGIC) return UNRESOLVED_SIGNED; , т.е. когда аргументы перечисляются не в скобках, а слева и справа от значка. Но приведённый выше пример - это функция. Можно ли так для процедур? Если так можно, тоже было бы красиво. Например, называем процедуру ":" и записываем: delay_out : y1_mat_d_i : y1_mat_d_q : y2_mat_d_i : y2_mat_d_q; , где delay_out - это общий выход линии задержки, а далее - отдельные составляющие. Процедура должна у левого аргумента с самого лева отрезать часть, равную размеру правого аргумента, подставлять эту часть в правый аргумент, а остаток после отрезания выдавать как результат процедуры для следующей подобной операции в цепочке. Либо это должна быть не процедура, а функция. Но тогда другой вопрос: умеет ли функция менять один из аргументов (чтобы он был inout как бы).

Созрел ещё вопросик как претендент на гвоздика в крышку гроба VHDL )) Есть линия задержки: del_lat_i : delay generic map ( DATA_BW => BW_P, DEL => DUT_LAT ) port map ( clk => clk, -- clock -- Входные данные data_in => p_mat_i, -- Выходные данные data_out => p_mat_d_i ); Есть сигналы входа и выхода этой линии задержки: signal y1_mat_i, y1_mat_d_i, y1_mat_q, y1_mat_d_q : std_logic_vector(EXT_DATA_BW-5 downto 0); signal y2_mat_i, y2_mat_d_i, y2_mat_q, y2_mat_d_q : std_logic_vector(EXT_DATA_BW-1 downto 0); При том для общности случая ширина шин разная. Я бы хотел использовать один компонент линии задержки для задержки сразу всех сигналов, чтобы не нагромождать исходник. В верилоге я бы сделал примерно так (ниже будет симбиоз верилога и VHDL): del_lat_i : delay generic map ( DATA_BW => BW_P, DEL => DUT_LAT ) port map ( clk => clk, -- clock -- Входные данные data_in => {y1_mat_i, y1_mat_q, y2_mat_i, y2_mat_q}, -- Выходные данные data_out => {y1_mat_d_i, y1_mat_d_q, y2_mat_d_i, y2_mat_d_q} ); Фишка в том, что очень удобно не оперировать разрядностями отдельных шин при стыковке и расстыковке входа и выхода линии задержки. Как сделать нечто подобное на VHDL? Я знаю, что вход можно собрать в одну шину через значок &. Т.е. объявить общий сигнал входа, ему присвоить конкатенацию всех составляющих сигналов. Нет проблем. Проблема, как потом разобрать выходную шину на отдельные составляющие? Некрасивое решение в лоб заключается в том, чтобы явно указывать индексы начала и конца каждого составляющего сигнала внутри общей шины. Это становится крайне неудобно при большом количестве сигналов, особенно разной длины. И сводит на нет желание всё протянуть через один общий компонент задержки, уж лучше тогда налепить столько компонентов, сколько сигналов, и не морочиться с индексами вообще, и пофиг, что это резко увеличит портянку и снизит её читаемость...

Вам повезло с работодателем, это прогрессивный, продвинутый работодатель. А другой работодатель скажет: "Кааааааааааак? Обучаться да ещё и за мои деееньги? А в это время проекты будут стоять? Не умеешь - понизим зп на время обучения. Либо найдём кто умеет". Некоторым нужен сразу готовый специалист, чтобы он всё знал и умел. А вот у нас в Томске в некоторых предприятиях меняют работников... город студенческих, демпинг, студенты-конкуренты вытесняют ))) Даже если пожилой в годах специалист является продвинутым, прошаренным и находится на пике современных тенденций, всё равно к нему отношение со стороны работодателя уже настороженное... увы. И работу уже в годах побаиваются менять, даже если много что из себя представляют, ибо априорное недоверие типа старпёр, и всё )) Ну в верилоге же можно. Принцип как и при любых последовательных присвоениях переменных в любых языках программирования: если выше переменная уже определена, она может быть подставлена при вычислении результата ниже. И да, самое главное: не забывайте, что мы говорим о параметрах по умолчанию, т.е. когда они не заданы в вышестоящем модуле. Если они заданы - то и формулы не действуют, значения заменяются на те, которые напрямую заданы в вышестоящем модуле. Да, я уже тоже так попробовал - но это не чисто, т.к. может быть неудобно при длинных формулах, можно запутаться. Чтобы не запутаться, желательно разбить на несколько промежуточных переменных. А VHDL это не даёт... Спасибо, вот это пожалуй самое полноценное решение моей проблемы. В виду новичковости в VHDL я просто об этом не знал, что можно сделать unconstrained ))) Тогда определяю эти параметры WRAP_PROD_BITS : natural; -- число старших откидываемых битов от внутреннего произведения RND_PROD_BITS : natural; -- число округляемых битов от внутреннего произведения BW_PROD : natural := BW_IN * 2 - RND_PROD_BITS; -- разрядность внутреннего произведения BW_OUT : natural := BW_PROD - WRAP_PROD_BITS; -- разрядность выхода общей части как константы в вышестоящем модуле, они, естественно, имеют право рассчитываться по формулам. Всё, пожалуй, мой вопрос закрыт и решён. Гвоздик в крышку гроба пока придётся приберечь... )))

Спасибо, хитро Вы придумали. Но, как я понимаю, если я объявлю константу, я не смогу задать через неё ширину входного или выходного порта? Мне то надо параметризировать ширину порта, которая бы зависела от совокупности других дженериков. Ладно, невозможность ссылки дженериков друг на друга будет ещё одним гвоздём в крышке гроба VHDL... (я постепенно их коплю, чтобы потом вбить). Меня уволят за такие изречения? Вы самообучались на деньги работодателя на рабочем месте, почти наверняка. А работодатель наверняка в явную на это не соглашался ))) Рано или поздно это произойдёт. Нас запишут в старпёры, как и мы когда-то старую гвардию записывали... Ну вообще-то это был по большей части сарказм. Конечно, в каждой шутке... Но всё равно. Я же утрировал, на самом деле я бы хотел, чтобы это было не так, но увы это почти так и есть...

спасибо за помощь, всё сразу стало понятно. Всё объяснили наглядно, на пальцах, как раз для начинающих. И главное решение проблемы сразу указано. Щас побыстрому 299 страниц прочту (а главное вникну! (а потом ещё и всё и сразу запомню на всю жизнь с первого прочтения)), работа подождёт месяц-другой... ... а если без шуток, то русский читает инструкцию, когда уже совсем ничего не получается. Иначе некогда, с работы уволят. И это я думаю обосновано. Учиться надо было в вузе, и на всю жизнь. А во время работы - поздно, работодатель хочет только результат и бесится, когда ты ещё и самообучиться пытаешься за его счёт. Я вообще даже думаю написать какую-нибудь инструкцию типа Переход с Verilog на VHDL за 30 минуту ))) Потому что из всей этой макулатуры в 299 страниц реально нужно всего 10 шаблонов, а дальше копипастить, почти не разбираясь. Утрированно конечно, но мысль такая. Особенно руки опускаются разбираться досконально, до мелочей, в VHDL, на котором уже всем продвинутым инженерным сообществом поставлен крест...

тогда я не смогу параметризировать разрядность выхода p, который зависит от BW_OUT, который зависит от BW_PROD

да я пробовал и задавать значения по умолчанию - не помогает. На самом деле если я их не задал - я их обязан задать в явном виде при инстантировании компонента. А если уж и тогда не задал - то пусть ругается, но на то, что я их не задал в явном виде. Но я их задавал.

Чтобы не плодить темы, напишу в этой. Я новичок в VHDL, поэтому созрел такой вопрос: entity cm_add_m is generic ( BW_IN : natural; -- разрядность SUB : natural; -- если 1, то вычитание, если 0 - то сложение WRAP_PROD_BITS : natural; -- число старших откидываемых битов от внутреннего произведения RND_PROD_BITS : natural; -- число округляемых битов от внутреннего произведения BW_PROD : natural := BW_IN * 2 - RND_PROD_BITS; -- разрядность внутреннего произведения BW_OUT : natural := BW_PROD - WRAP_PROD_BITS; -- разрядность выхода общей части PP_INT : natural -- внутренние пайплайны, между каждыми DSP-блоками ); port ( clk : in std_logic; -- Клок работы модуля -- Входные данные add1, add2 : in std_logic_vector(BW_IN-1 downto 0); mult : in std_logic_vector(BW_IN-1 downto 0); -- Выходные данные p: out std_logic_vector(BW_OUT-1 downto 0) ); end cm_add_m; На блок generic, в частности на строчку BW_PROD : natural := BW_IN * 2 - RND_PROD_BITS; -- разрядность внутреннего произведения ISE ругается так: Active-HDL так: Я раньше на Верилоге писал, с такими конструкциями не было проблем. Получается нельзя заранее рассчитать значение параметра по умолчанию?

Сейчас как раз реализую БПФ. Я бы посоветовал Оппенгейма почитать, я там кое-что практическое для себя нашёл (применение БПФ для очень длинных последовательностей). Alan V. Oppenheim, Ronald W. Schafer. Discrete-Time Signal Processing (3rd Edition) (Prentice Hall Signal Processing) Hardcover – 2009 Есть и на русском, при том разные издания. А ещё для начинающих очень хорошо БПФ разжёвано у Ричард Лайнос Цифровая Обработка Сигналов 2006.

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

Вместо инициированного холивара начался другой холивар, какой синтезатор лучше ))) Это не всем нужно. У меня исходник на вхдл, таковы правила предприятия. Альтернатива, да не совсем. Она платная, а это сужает вероятность её применения. Получается такой ответ на мой холиварный вопрос, типа "вот RTL ничем не уступает, только надо заплатить бабок за крутой синтезатор". Работодатель скажет (и будет пожалуй по-своему прав), что желание писать на RTL (вместо макросов) не может являться экономическим обоснованием доп. затрат на покупку синтезатора. Купили тебе ISE (или Vivado), вот и работай в нём, а если тебе неудобно описывать макросами - то терпи, мы тебе и так зп платим, а ты хочешь ещё чтобы мы потратились на синтезатор. Так что извините, не могу принять Вашу сторону, остаюсь на своей стороне, что платный Синплифай использовать не честно, холивар получится нечистый. У меня сейчас нет возможности использовать Синплифай. Если у Вас есть немножко времени, Вы могли бы засинтезить мой пример в нём и посмотреть, появились ли каскадные связи? Там просто проект из двух исходников, один топовый, засинтезировать как есть. Я в конечном счёте и это проделал, но для XST и Vivado не помогло. Из этого пункта я только применил стандартные разрядности шин. И то только для XST, т.е. для SPARTAN6. Для Vivado и для VIRTEX7 там разрядности уже отличаются. Но факт в том, что оба синтезатора в целом прекрасно увидели DSP48 в моей конструкции языка, увидели перемножитель, увидели аккумулятор. Не увидели только межкаскадные связи. А описывать внешние управляющие порты, которые использоваться не будут - это уже тогда мы скатываемся на уровень макросов. Их минус в громоздкости, ненаглядности и непортируемости. То же мы обеспечим и конструкциями языка, если всё-всё опишем. А нам это не надо, нам от описания конструкциями языка нужно получить преимущество. Ну тут у меня по третьему пункту в настройках проекта стояло "авто" на использовании ДСП, но, раз ДСП он в целом увидел, то проблема не здесь. По пункту 4 - то же. Ничего не выкинул, поставил всё, что нужно. Только связи межкаскадные не провёл. А судя по богатому опыту моих коллег при использовании обоих синтезаторов есть свои недостатки в распознавании конструкций, в потреблении логики и даже в результирующей предельной тактовой. Один одно хорошо делает, другой другое. Я в Planahead схему смотрю, в принципе всё есть. Если проект большой и срочно - то иногда в ISE делаю View Technology Schematic. В принципе тоже почти всё показывает. Но это я касаемо проблем, подобных моей, говорю. А Вы что не смогли посмотреть?

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

Здравствуйте. Не могу на 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 в виде конструкций языка ничем не уступает применению громоздких макросов, имеющему кучу своих минусов. Пока что применение макросов выигрывает. Пусть и пренебрежимо незначительно. mult35x35.rar

Добавление: одна и та же ошибка в Planahead от ISE 14.5, 14.6 и 14.7. Новее нету...

Нужно уже осуществлять переход в Виваду, при том насовсем ))) Keep Hierarchy - не всегда лучший способ, вы теряете возможность оптимизации между модулями, пусть даже самыми мелкими. Мы например умышленно держим эту опцию выключенной. Есть другие способы, как указать констрейн, когда модуль не выделен в отельную ветвь иерархии.

Только увидел сообщение. Если проблема ещё не решена, могу помочь, я на этом собак ел недавно )) Предлагаю начать всё с нуля в следующей последовательности. 1. Провести синтез, где этот блок никак не законстрейнен. 2. Запустить PlanAhead -> Post-Synthesis 3. В нём задать нужный Вам констрейн, т.е. сздать Pblock. 4. Сохранить результаты работы PlanAhead. Открыть *.ucf, убедиться в наличии нужных изменений. 5. Продолжить последующие процедуры после синтеза (имплемент, транслэйт, мап, пар и т.д.).

Это я понял. "Этого" Вы имеете в виду параметр "read cores", о котором я говорил? Если да, то мой ответ: ну дак установите этот параметр при сборке конечного проекта! Я считаю, что так (устанавливать этот параметр) будет правильнее. А спрятать буферы внутрь корки иногда очень удобно, чтобы была готовая законченная вещь: например готовый DDR контроллер или GTX полностью весь-весь, который остаётся только подключить к выходным пинам топового файла.

Всем здравствуйте! Пытаюсь следовать этой инструкции, чтобы создать *.ngc-шку с полной разводкой модуля. Застрял на стадии фиксации разводки (Fix Instances) в Planahead с такой ошибкой: ERROR: [PlanAhead 12-1405] Cannot mark the 'bel' location of instances fixed, 'Element SLICE_X196Y161.A6LUT is not routable as there are 6 input pins and A6 cannot be used because of LUT5 usage.' Рылся и по этому форуму, и гуглил в нете. Нашёл похожую проблему, но решение было вручную двигать такие элементы в нужное место. Мне это не подходит, т.к. элементов слишком много. Моё дополнительное наблюдение: ошибка возникает только (но не для всех!) для SliceM, а для SliceL - всё нормально. И проблема только, если развелось в A6LUT, в другие позиции (B-D) - всё нормально. Интересно, что маппер как-то развёл этот модуль, и ему не показалось, что LUT в такую позицию нельзя затолкать. И более того, это работает на железке. А планахеду значит это размещение не нравится, он его считает ошибочным. Что можно сделать, чтобы избавиться от этой ошибки, но не вручную, а каким-то групповым способом? Заранее спасибо.

Я бы не был так категоричен. Не обязательно Partial Reconfiguration. Достаточно просто разбить на партиции, руководствуясь Hierarchical Design Methodology (UG748). Но можно ещё создать *.ngc-шку: http://electronix.ru/forum/index.php?showt...mp;#entry316405

Сейчас с этим колупался, оказалось, это требование не так и обязательно. Если буферы уже интегрёные в корку, то в настройках синтезатора надо поставить read cores и указать пути к корам точно те же, что и пути для implement.

Да, всё проверено. Подтверждаю: $display печатает в консоль ISE (нужно только там найти, сообщений то много), а $finsh позволяет вызывать ошибку синтеза. Код как в моём первом посте.

Спасибо, попробую

Здравствуйте, коллеги. Посоветуйте, пожалуйста, как в коде Verilog сенерировать ошибку, чтобы она вылезла на этапе синтеза, а также анализа файлов перед симуляцией при определённом условии. Хочу сделать защиту от дурака, сравнить определённые параметры и сделать так, чтобы при таком условии синтез или анализ файлов перед симуляцией не завершились бы успешно. Можно с каким-либо показом нужного сообщения в консоль. Использую Xilinx. ISE, XST для синтеза. Cadence SimVision для симуляции. Заранее спасибо. Для симуляции реализовал вот так: // foolish protection :) initial begin if(f_ceillog2(P_N) > FIXED_LAT) begin $display("Error! Fixed latency less than hardware achievable!"); $finish(); end end Остаётся вопрос на этапе синтеза.

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