Jump to content

    

Не понимаю источник проблемы на Verilog

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

Попробовал добиться результата схематически.

post-29795-1324718884_thumb.png

Впринципе фокус прокатил, но:

post-29795-1324719242_thumb.png

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

 

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

 

Будем грызть дальше.

Share this post


Link to post
Share on other sites
Просто, я подумал, что компилятор сумеет задействовать и нарастающий и спадающий.

Тогда так можно сделать:

always @(posedge clk or negedge clk) begin

Но в реальных устройствах так лучше не делать.

Share this post


Link to post
Share on other sites

"Тогда так можно сделать:"

Пытался вчера.

Увы :(

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

 

Мне это мало что говорит, но оно - цвета красного. :)

Share this post


Link to post
Share on other sites
Как правило, при работе реальной схемы требуется, чтобы производительность была максимальной, т.е. схема только что и успевает отреагировать на один фронт сигнала, а уже начинается второй. Поэтому при реализации сложной цифровой схемы в рамках одного кристалла стараются, чтобы все было синхронно, по возможности, от одного клока, и, согласно, выше сказанному, от одного его фронта.

Так что работайте с одним фронтом :rolleyes:

Share this post


Link to post
Share on other sites

Удивляюсь очередным наблюдениям

    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 (что в принципе логично)

post-29795-1324823181_thumb.png

 

А здесь - parameter. На выходе, в результате, какая-то ерунда.

post-29795-1324823324_thumb.png

Share this post


Link to post
Share on other sites

parameter data = 16'b1111_0000_0000_1111;

А так не пробовали задавать? Если делать по-вашему, то он, видимо, будет матрицей 16 на 16.

Share this post


Link to post
Share on other sites

Объясните задачу. Что требуется, чтобы при RAM_Address >= 7 загорелся светодиод?

И зачем вам Complete как регистр, не понимаю. :)

Share this post


Link to post
Share on other sites

Задача (теоретически) не сложная, - записать во внешнюю SSRAM данные.

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

 

Share this post


Link to post
Share on other sites
А чё? ??

Логика - отказывает :(

Вам уже писали про блокирующее/неблокирующее присваивание. Используйте неблокирующее <=. Разрядность для parameter указывайте в явном виде, по умолчанию там вроде 32 разряда и соответственно содержимое может быть не то.

По поводу

always @(posedge clk or negedge clk)

На плис триггеры реализованы уже физически, это как правило D-триггеры. Для тактовой частоты на триггер заведен только один (!) вход.

В том примере, который Вы привели результат должен быть одинаковым. И reg и parameter вырождаются просто в константы, у них будет одинаковая физическая реализация. Счетчик выдает одинаковые значения (на рисунке не видно)?

Share this post


Link to post
Share on other sites

Здесь я б использовал сдвиговый регистр. Без всякого счётчика.

То есть примерно так:

 

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-й разряд регистра, который в кольце сдвигается каждый такт.

 

У вас, я смотрю, свежо "программное" мышление, то есть как писать программы, и оно доминирует над "железячным". :) Просто главное отличие, что в Си всё выполняется построчно, а здесь - параллельно.

Share this post


Link to post
Share on other sites

Вам уже писали про... Используйте неблокирующее...

Каюсь. Изначально я использовал именно неблокирующее. Но, когда пытался найти источник "непоняток", то попробовал заменить присваивание. В таком виде и "скопипастил" в топик. На симуляцию это не повлияло нисколько.

 

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

 

и оно доминирует над

Это точно. Пока что это так.

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

 

Прокоментируйте, пожалуйста, синтаксис и работу этой строки:

shift <= {shift[0], shift[15:1]};

Share this post


Link to post
Share on other sites
Прокоментируйте, пожалуйста, синтаксис и работу этой строки:

shift <= {shift[0], shift[15:1]};

Здесь у вас осуществляется циклический сдвиг вправо (циклический сдвиговый регистр). Значение нулевого разряда переписывается в 15-ый разряд, а остальные сдвигаются вправо. Здесь пример есть, как это выглядит: http://ru.wikipedia.org/wiki/%D0%91%D0%B8%...%B2%D0%B8%D0%B3

Edited by M@kar

Share this post


Link to post
Share on other sites

Логику сдвига я представляю.

Я хочу понять синтаксис конкретно верилога.

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

Непосредственно, в примере, сдвиговый регистр не сдвигается, а переприсваивается себе-же, только очередность бит меняется. И, рассуждая логически, должны работать и такие варианты:

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]}; //Замена старшей младшего байта тетрады сторонними данными

 

Правильно ли я сужу?

Edited by Sirko

Share this post


Link to post
Share on other sites
Правильно ли я сужу?

 

Вторая строчка не будет работать. Просто компилятор не пропустит.

 

И кстати, parameter обычно используют когда у вас подключается несколько модулей внутри, имеющих одинаковый RTL-код но их надо несколько по-разному сконфигурировать. Например, разная ширина шины данных, если это блоки памяти.

А так, для присвоения по сбросу, по-моему, лишнее запутывание кода.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this