Sirko 0 24 декабря, 2011 Опубликовано 24 декабря, 2011 · Жалоба Да, при синхронизации от одного из фронтов таких проблем нет. Просто, я подумал, что компилятор сумеет задействовать и нарастающий и спадающий. Попробовал добиться результата схематически. Впринципе фокус прокатил, но: такая конструкция работает только при частоте клока менее, чем вдвое меншей от допустимой "чиповой". Так, что, видать, достичь тех же скоростей выполнения верилоговского кода можно, используя один фронт. Будем грызть дальше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
M@kar 0 24 декабря, 2011 Опубликовано 24 декабря, 2011 · Жалоба Просто, я подумал, что компилятор сумеет задействовать и нарастающий и спадающий. Тогда так можно сделать: always @(posedge clk or negedge clk) begin Но в реальных устройствах так лучше не делать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sirko 0 24 декабря, 2011 Опубликовано 24 декабря, 2011 · Жалоба "Тогда так можно сделать:" Пытался вчера. Увы :( Error (10239): Verilog HDL Always Construct error at MyFile_ONE.v(12): event control cannot test for both positive and negative edges of variable "clk" Error: Can't elaborate user hierarchy "m1:inst9" Error: Quartus II Analysis & Synthesis was unsuccessful. 2 errors, 1 warning Error: Peak virtual memory: 178 megabytes Error: Processing ended: Sat Dec 24 14:19:24 2011 Error: Elapsed time: 00:00:03 Error: Total CPU time (on all processors): 00:00:01 Error: Quartus II Full Compilation was unsuccessful. 4 errors, 1 warning Мне это мало что говорит, но оно - цвета красного. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
M@kar 0 24 декабря, 2011 Опубликовано 24 декабря, 2011 · Жалоба Как правило, при работе реальной схемы требуется, чтобы производительность была максимальной, т.е. схема только что и успевает отреагировать на один фронт сигнала, а уже начинается второй. Поэтому при реализации сложной цифровой схемы в рамках одного кристалла стараются, чтобы все было синхронно, по возможности, от одного клока, и, согласно, выше сказанному, от одного его фронта. Так что работайте с одним фронтом :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sirko 0 25 декабря, 2011 Опубликовано 25 декабря, 2011 · Жалоба Удивляюсь очередным наблюдениям input wire clk; output reg out = 0; output reg [15:0] counter = 0; // reg [15:0] data = 16'b1111_0000_0000_1111; parameter [15:0] data = 16'b1111_0000_0000_1111; always @(posedge clk) begin counter = counter + 1; out = data[counter[3:0]]; end Если использовать для данных data тип parameter, а не reg, то результат не соответствует требуемому. Так выглядит сигнал на выходе при использовании типа reg (что в принципе логично) А здесь - parameter. На выходе, в результате, какая-то ерунда. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
M@kar 0 25 декабря, 2011 Опубликовано 25 декабря, 2011 · Жалоба parameter data = 16'b1111_0000_0000_1111; А так не пробовали задавать? Если делать по-вашему, то он, видимо, будет матрицей 16 на 16. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sirko 0 25 декабря, 2011 Опубликовано 25 декабря, 2011 · Жалоба А чё? ?? Логика - отказывает :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Серокой 0 26 декабря, 2011 Опубликовано 26 декабря, 2011 · Жалоба Объясните задачу. Что требуется, чтобы при RAM_Address >= 7 загорелся светодиод? И зачем вам Complete как регистр, не понимаю. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sirko 0 26 декабря, 2011 Опубликовано 26 декабря, 2011 · Жалоба Задача (теоретически) не сложная, - записать во внешнюю SSRAM данные. Но на самом деле задача номер один освоить плиски. Я только-только пытаюсь их щупать и при малейших преткновениях - ступор. По сему названия и алгоритмы на данном этапе бессмысленны. Конкретно последнего вопроса - подрыгать ногой данными, которые хранятся в data. Но почему-то одни и теже данные, но находящиеся не в регистре, а в константе - ведут себя по разному. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 26 декабря, 2011 Опубликовано 26 декабря, 2011 · Жалоба А чё? ?? Логика - отказывает :( Вам уже писали про блокирующее/неблокирующее присваивание. Используйте неблокирующее <=. Разрядность для parameter указывайте в явном виде, по умолчанию там вроде 32 разряда и соответственно содержимое может быть не то. По поводу always @(posedge clk or negedge clk) На плис триггеры реализованы уже физически, это как правило D-триггеры. Для тактовой частоты на триггер заведен только один (!) вход. В том примере, который Вы привели результат должен быть одинаковым. И reg и parameter вырождаются просто в константы, у них будет одинаковая физическая реализация. Счетчик выдает одинаковые значения (на рисунке не видно)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Серокой 0 26 декабря, 2011 Опубликовано 26 декабря, 2011 · Жалоба Здесь я б использовал сдвиговый регистр. Без всякого счётчика. То есть примерно так: parameter init_data = 16'b1111_0000_0000_1111; reg [15:0] shift; wire out; always @ (posedge Clk or posedge Reset) if(Reset) shift <= init_data; else shift <= {shift[0], shift[15:1]}; assign out = shift[15]; Конструкция always @ (posedge Clk or posedge Reset) представляет собой D-триггер с асинхронным сбросом положительным уровнем. При сбросе регистр инициализируется данными, заданными переменной init_data. Далее, когда сброс уходит в ноль, на выход идёт 15-й разряд регистра, который в кольце сдвигается каждый такт. У вас, я смотрю, свежо "программное" мышление, то есть как писать программы, и оно доминирует над "железячным". :) Просто главное отличие, что в Си всё выполняется построчно, а здесь - параллельно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sirko 0 26 декабря, 2011 Опубликовано 26 декабря, 2011 · Жалоба Вам уже писали про... Используйте неблокирующее... Каюсь. Изначально я использовал именно неблокирующее. Но, когда пытался найти источник "непоняток", то попробовал заменить присваивание. В таком виде и "скопипастил" в топик. На симуляцию это не повлияло нисколько. Кстати, проблему с parameter я обнаружил. Как и предполагал, эта проблема - неграмотность моя. Модуль, у которого есть параметры, в графическом виде имеет меню для редактирования этих параметров. И эти параметры по умолчанию принимают те значения, которые были прописаны в коде модуля на момент "натягивания" его на схему. Дальнейшие изменения параметров в коде - не влияют на работу. Я этого не знал. и оно доминирует над Это точно. Пока что это так. Работу сдвигового регистра я представляю, просто осваиваю вариант с отдельными битами (пока-что всеми по очереди) Прокоментируйте, пожалуйста, синтаксис и работу этой строки: shift <= {shift[0], shift[15:1]}; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
M@kar 0 27 декабря, 2011 Опубликовано 27 декабря, 2011 (изменено) · Жалоба Прокоментируйте, пожалуйста, синтаксис и работу этой строки: shift <= {shift[0], shift[15:1]}; Здесь у вас осуществляется циклический сдвиг вправо (циклический сдвиговый регистр). Значение нулевого разряда переписывается в 15-ый разряд, а остальные сдвигаются вправо. Здесь пример есть, как это выглядит: http://ru.wikipedia.org/wiki/%D0%91%D0%B8%...%B2%D0%B8%D0%B3 Изменено 27 декабря, 2011 пользователем M@kar Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sirko 0 27 декабря, 2011 Опубликовано 27 декабря, 2011 (изменено) · Жалоба Логику сдвига я представляю. Я хочу понять синтаксис конкретно верилога. Т.е, насколько я понял, содержимое, заключенное в фигурные скобки, представляет из себя некий вектор. А сам вектор, поразрядно может быть набран из чего угодно. Непосредственно, в примере, сдвиговый регистр не сдвигается, а переприсваивается себе-же, только очередность бит меняется. И, рассуждая логически, должны работать и такие варианты: shift <= {shift[7], shift[6], shift[5], shift[4], shift[3], shift[2], shift[1], shift[0], shift[15:8]}; //"разворот" младшего байта shift <= {shift[0:7], shift[15:8]}; //аналогично shift <= {shift[3:0], data[3:0], shift[15:8]}; //Замена старшей младшего байта тетрады сторонними данными Правильно ли я сужу? Изменено 27 декабря, 2011 пользователем Sirko Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Серокой 0 28 декабря, 2011 Опубликовано 28 декабря, 2011 · Жалоба Правильно ли я сужу? Вторая строчка не будет работать. Просто компилятор не пропустит. И кстати, parameter обычно используют когда у вас подключается несколько модулей внутри, имеющих одинаковый RTL-код но их надо несколько по-разному сконфигурировать. Например, разная ширина шины данных, если это блоки памяти. А так, для присвоения по сбросу, по-моему, лишнее запутывание кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться