Golikov

В какой точке дизайна:)? Вы понимаете что у вас во всех точках вашего кристалла время фронта клока разное? При этом если клок идет по специальным выровненным деревьям, то сигнал с триггера пойдет по другим цепям и разойдется с клоком просто капитально. надо использовать сигнал в условии, но не как клок. НЕ НАДО always @(posedge clk) CLOCK <= ~CLOCK; always @(posedge CLOCK) ... НАДО always @(posedge clk) CLOCK <= ~CLOCK; always @(posedge clk) if(CLOCK) .... каких? надо как сорс использовать выход регистра, а не регистр. А имя просто дать, как я понимаю.

create_generated_clock The source of the generated clock, specified by -source, is a port, pin, register, or net in the design. All waveform modifications are relative to this point. If more than one clock feeds the source node, the -master_clock option must be used to specify which clock to modify. то есть выход вашего регистра это - сорс клока. А имя это просто чтобы его называть. Так что ИМХО у вас неправильный источник вся задержка сети начнет считаться от этой точки, чтобы учесть задержку от нормального клока, вроде есть ключик типа мастер клок или что-то типа того.

Да возьмите и попробуйте на верилоге описать настоящую 2 портовую память для ксалинкса и альтеры, да так чтобы она еще технологическими блоками правильно заменялась и лишних регистров не натыкала? Там еще все усугублялось тем что был спартан 6, и как следствие нет поддержки SV, а у альтеры 2 портовая штатно как раз именно на SV описывается. И да, никто не обещал что ошибок и варнингов не будет, там как раз было много всего. В основном конечно битва за то чтобы все правильно легло в технологические блоки ПЛИС, которые у каждого свои и со своими нюансами.

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

Систем верилог приятен для синтеза, но практически бесценен для верификации и симуляции. ModelSim вроде с ним дружит, так что тестбенчи можно писать на нем и под ксалинкс младших серий в случае внешних симуляторов. это вы ничего не изменили, правильно parameter [2:0] DEVIDER = 3'd4; а еще правильнее и размерность сделать параметром. Более того синтезатор еще и хитрый, он понимает что 16 бит умножить на 16 бит в общем случае будет 32 бита, и тоже ругнется. Как и при сложении 3 бит и 3 бит, он в общем случае ожидает 4 битный ответ и при присвоении в 3 битную переменную ругнется. С счетчикам counter <= counter + 1'b1; Работает. Ровно как и counter <=0; Несмотря на то что 0 в этом случае 32 битный, он однозначно расширяется и сужается до любой размерности, потому что он 0. В прочих случаях надо заводить wire сигнал правильной размерности, в него присваивать математическое выражение, а потом его правильно обрезав сохранять в регистры. Почему нет? Ресет не клок в ксалинксе он спец цепей не имеет (в альтере асинхронный вроде как имеет спец путь). В любом случае независимо от того какой ресет синхронный или асинхронный его снятие всегда пересинхронизируют на рабочую частоту модуля, так что все будет ок. Кстати ксалинкс больше рекомендует синхронные сеты и ресеты, у них в ячейках спец входы есть, а вот асинхронный у них кажется только сброс. А какие еще могут быть варианты? Если у вас нет пути сигнала, то как его получить. Конечно можно взять сделать нетлист, найти сигнал и к нему прикрутить руками что-то, но это не верно стратегически. Он же и пооптимизироваться может по ходу пьесы, и объединиться с чем-то. Правильно действительно просто пробросить его прямо отдельной линией через всю иерархию, так как будто бы он был с самого начала. схема конфигурации ПЛИС на последних этапах просто дергает сет или ресет ячеек, устанавливая их в заданное значение. То есть это не такой хитрый элемент который после включения питания придумывает свое состояние, это просто работа механизма загрузки конфигурации ПЛИС.

а там настройка есть во что перевести спец ноги по окончанию конфигурации она задана? И еще был какой-то вариант доступа через мего функцию к спец ногам.

Ранее не синтезируемые конструкции начинают потихоньку переходить в синтезируемые. Так что такие конфузы возможны. Описали в литре что выкидывается данная кострукция, а потом бабах и уже не выкидывается. Не знаю с какой серии, но у ксалинкса начальное состояние тех элементов может быть как 1 так и 0, и задается в прошивке, поэтому естественно было подержать синтезируемость инициализации. Альтера вроде как имеет только одно нулевое состояние для всех элементов после старта, но тоже поддержала эту конструкцию на синтезе за счет того что ставит инверсию до и после тех элементов которые в начале должны быть 1.

Стойте - стойте! Как так сначала синтезатору, а потом симулятору? Да нет конечно. Можно написать толпу не синтезируемых конструкций и прекрасно их видеть на симуляции. Вообще VHDL как способ описания схемы для литературы и симуляции - это его первичное назначение, функцию создания схемы прекрутили позже. Если мы говорим о пост синтез симуляции, то да, сначала синтезатор, а потом симулятор, но в этом случае он уже не использует начальный RTL, он идет по нет листу, который тоже rtl, но уже переработанный в связь элементов. И тут вообще процессов то и не будет, будет список ячеек и связей, разве что в моделях ячеек. А в начальном варианте симулятор идет по rtl коду и синтезатор по нему же. Только один с учетом списка чувствительности, а другой без, вот как бы и все... про изменение и фронты - ок. принимается, правда скорее придирка. Просто для асинхронных сбросов-установок важен именно уровень а не фронт, ну не важно... про защелкивается и обрабатывает процесс - не принимается. Процесс может быть без клока, и там ничего не щелкается, а комбинируется, то есть важен прямо таки факт обработки, а не изменение данных. Ну то есть тут мне кажется что все же терминология важна. Для Мур, кроме блоков и мегофункций для каждого семейства есть книжечка какие конструкции хочет видеть синтезатор для того или иного поведения, в 99% случаев у альтеры и ксалинкса они совпадали, но различия все же были. Стоит на эти книжечки ориентироваться, тем более что у вас 3 семейства. Мы в таких местах делали ветвление через `ifdef ALTERA `elsif XILINX, не помню VHDL аналога, годная практика имхо:)

1. vector = {DATA_SIZE{1'b1}}; vector = {DATA_SIZE{1'b0}}; 2. хз, стилей много разных, уверен мой хороший:) но я его не могу показать:)))) 3. обычно тестбенчи к верилогу пишут на систем верилоге, это продолжение языка, с большими бонусами. В частности концепция UVM. Поищите SystemVerilog for verification. На чистом верилоге тестбенчи беднее 4. Ой, забываем про систем верилог если у вас не вивада). Исе и план ахед его не поддерживает. Начальные значения можете задавать при объявлении reg [DATA_SIZE - 1 : 0] MyData = {DATA_SIZE{1'b1}}; или в блоке initial begin end или через сброс, синхронный, асинхронный. У ксалинкса технологические ячейки поддерживают начальную установку в заданное значение, так что все работает корректно. В случае асинхронной установки (у ксалинкса есть только сброс) ячейка на уровне схемы ставиться с инверсией, и все входящие значения инвертируются, то есть как бы получается ячейка со сбросом в 0, но за счет инвертера как бы сбрасывается в 1. Это делает синтезатор, вам парится не надо. 5. доступ по иерархии в тестбенчах через точку. my_module.my_in_module.my_signal, можно в $display, можно в вейформ, можно присвоить куда, можно через форс задать.

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

не верно в корне:) во-первых не по обоим фронтам, а по изменению. во-вторых не защелкивать, а обрабатывать процесс. в-третьих не синтезатору, а симулятору. Когда вы пишите в список чувствительности клок, вы что говорите синтезатору работать по обоим фронтам? А когда вы не пишите в списке сигналы обрабатываемые под клоком, вы что говорите их игнорировать? Надо просто правильно понимать что список чувствительности отвечает за события запуска процесса на просчет при симуляции. Синтезатор же работает со схемой, которая работает непрерывно, без событий. Отсюда есть некая условность перевода текста в схему. И да, мы имеем место именно игнорирования списка чувствительности, потому что независимо от того что вы в нем напишите, синтезатор создаст свой список, удовлетворяющий описанию процесса. Добавить пропущенные сигналы, пропустит лишние. И наверное можно утверждать что так сделают почти все используемые синтезаторы.

как я надеюсь мы уже выяснили на нескольких страницах до, список чувствительности не влияет на синтез. Поэтому в обоих конструкциях может быть с 2008 года process(All), тогда синтез совпадет с симуляцией. Но если мы хотим оптимизации, то для синхронного сброса в списке только клок, для асинхронного клок и сброс. Но влияет это только на симуляцию. Естественно для правильного описания элементов необходимо следовать код стайлам от производителя синтезатора. Про фронты это сравнение с verilog, там в always блок необходимо явно включать posedge(reset) для того чтобы сброс стал асинхронным, то есть как бы его фронт, а на самом деле там же не фронт, а уровень...

ну позвольте, синхронность и асинхронность сброса записывается в процессе, и однозначно определяется описание не зависимо от списка чувствительности. синхронный сброс if(clk'event and clk = '1') then if(reset = '1') then ... асинхронный сброс if(reset = '1') then ... else if(clk'event and clk = '1') then тут все трактуется однозначно, читается даже правильнее чем в верилоге с фронтом на ресете, и потому особенно становиться непонятно зачем к этим конструкциям надо еще сверху разные списки чувствительности делать.

Да просто VHDL любит чтобы одно и тоже было написано несколько раз в нескольких местах. Все мощь синтезируемой части языка описывается внутри процесса, а список чувствительности лишь оптимизация для симулятора и читабельность, если хотите для человека. Ну а то что синтезируемое подмножество меньше симулируемого, ну так это просто жизнь... Не вижу кстати разницы между process() begin end process; и always @() begin end Хотя нет вижу, запись на 1 слово короче:)

1. Я проверял на ISE, интернет проверял и на Quartus, Vivado я практически уверен будет солидарна. 2. А это важно:)? Думаете у вас получится разный результат в зависимости от источника сигнала? Это и есть основной тезис последних страниц, правда его списывают на нашу молодость и пытаются оспорить опытом, к слову сказать неподтвержденным экспериментами, таким эмпирическим опытом :)

Чтобы понять о чем я толкую надо почитать внимательно и что-то повторить. самое простое это sample_and: process(d) begin a <= b & c; end process; посмотреть симуляцию, и посмотреть итоговую схему. Я даже дам вам подсказку, попробуем в симуляции менять b и c не трогая d и наблюдаем за а. Потому пытаемся по итоговой схеме прикинуть как будет вести себя железо, и совпадет ли оно с симуляцией...

Есть некая фундаментальная разница между powerPC и ARM, хотя у ксалинкса есть цинки Так же есть некая разница между внешней ПЛИС и ПЛИС на шине проца в одном кристалле, хотя когда в качестве примера АРМа приводят атмеловский это заставляет подозревать...

нет, не может. это будет латч с разрешением что ли%:) он просто не станет триггером, потому что нужно не значение клока а фронт, событие. То есть нет аналога ВХДЛьного clk'event внутри алвейса,

если написать always(posedge clk or negedge reset_n) begin if(reset_n == 1'b1) .... else .... end могут быть проблемы, синтез и симуляция действительно могут разойтись. ну и конечно же симуляция честно отрабатывает фронты асинхронных сигналов, а реальная схема отрабатывает уровни. То есть always(posedge clk or posedge set) begin if(set == 1'b1) a <= b; else .... end в симуляции в а засовывается b по фронту set, и меняй не меняй b после фронта - пофиг. В реальной схеме, Если set стоит в 1, то изменение b будет проходить на a. А влияние на поведение, - это пропуск слова posedge, хотя я сейчас что-то задумался....

так и делаем:)

не очень понял о чем это в контексте сказанного. Я не говорил о схеме синхронизации, я говорил о критерии синхронности, ну да ладно... Конечно же нет, потому что это верный способ провалить частоту минимум в 4 раза. Просто на самом деле знаю что там происходит и что такое мета-стабильность, и гонка сигналов. Поэтому я и могу сделать правильный SPI slave, который естественно не пересинхронизируется во время приема-передачи на рабочую частоту схемы.

С чего вдруг то? тут мы возвращаемся к предложенной схеме sample_and: process(d) begin a <= b and c; end process; тут пропущены все сигналы, и если бы синтезатор смотрел на список чувствительности он бы вообще не смог бы ее синтезировать, в железе данная схема вообще невозможна. Скорее всего это и приводит к решению игнорировать этот список синтезатором. Для синтезируемого подмножества схем, список не меняет их поведение, он только может сделать так что схема становится не реализуемой и все....

Переступите через свой опыт, пожалуйста... и проверьте что будет на самом деле:) единственное я имел ввиду, конечно a <= b and c; просто давно не писал на VHDL... И да, когда будите проверять не поленитесь посмотреть технологическую схему после синтеза, а то и сделать пост синтез симуляцию Какая каша простите? Если входы этой схемы - это выходы регистров на той же частоте - ничего не будет, все будет работать штатно. Если выход этой схемы не идет на вход никакого регистра, то опять же все будет работать штатно и правильно. В том то и дело что НЕВАЖНО!!!!! синтезатор просто игнорирует список чувствительности и синтезирует схему по внутреннему описанию процесса! Это верно как минимум для ISE, Quartus, кто там еще остался симплифай? Вроде как он тоже себя так ведет.

тут то все на самом деле просто. Если схема работает по фронту одного сигнала, то она синхронная относительно этого сигнала. Если в ней есть реакции на фронты и уровни нескольких сигналов, которые не имеют зависимости между собой, то части схемы управляемые разными сигналами - асинхронны друг другу. А что делать с SPI slave при взаимодействии с мастером из внешнего мира?

Интересный вывод. То есть попытка полностью понять что происходит, понять инструмент и в деталях управлять процессом - это молодость:)? Вы как я понимаю точно знаете что будет да? А на основании чего вы это заявляете? Вы как я понял сторонник "деды так делали и мы так будем" :))) так вот может иногда стоит по молодецки поэкспериментировать? А заодно нам дуракам расскажете что получилось. Вот это мне демонстрирует полное непонимание или не владение темой. С чего вдруг то надо обязательно так делать? Более того засунут под клок приведенную схему вы создаете огромное количество проблем, чисто комбинаторная схема лишена мета-стабильности просто по определению :) Если не понимаете, спросите я объясню. Плохо видите) Вы не хотите слушать что вам говорят, и вешаете ярлыки не разобравшись. Весь интернет и форумы основных производителей ПЛИС вместе с их суппортом считают что никак, но Мур другого мнения. Правда в силу нашей молодости он не хочет нам объяснить деталей:( Именно, в этом и был смысл примера, но видать он был слишком молодецким%) Более того попытки защелкнуть комбинаторику в триггера без синхронизации, вот тут то как раз все встанет в полный рост с мета-стабильностью, гонками сигналов и прочими проблемами. Это к тезису что синхронный дизайн всегда благо. И есть один очень хороший пример sample_and: process(d) begin a <= b & c; //тут ошибка надо было a <= b and c; end process; Уважаемый Мур прокомментируете что будет при синтезе и симуляции данной схемы