Перейти к содержанию
    

ViKo

Модератор
  • Постов

    12 216
  • Зарегистрирован

Весь контент ViKo


  1. Предпочитаю идеальное решение. Жалко напрасно потраченных логических элементов.
  2. Не устраивает тем, что Quartus не объединяет в одном логическом элементе сумматор и триггер, а раскидывает, как захочет. На MAX+II на AHDL у меня счетчики выстраивались в линейку, с цепями переноса длиной в 24 элемента.
  3. Quartus 9.0, Altera ACEX 1K. Пытаюсь создать счетчик, чтобы укладывался компактно в логические элементы. Для начала - фиксированного размера (с generate - свои проблемы). Как-то так: module CountPrim #(parameter WIDTH = 4) ( input Reset_n, Clock, Enable, output [WIDTH-1:0] Count, output POut ); wire [WIDTH-1:0] Fb; // feedback wire [WIDTH-1:0] Lt; // look table wire [WIDTH-1:0] Cr; // carry out CARRY_SUM Cy0 (.sin(Fb[0]), .cin(1), .sout(Lt[0]), .cout(Cr[0])); DFFE Ff0 (.d(Lt[0]), .clk(Clock), .clrn(Reset_n), .prn(1), .ena(Enable), .q(Fb[0])); CARRY_SUM Cy1 (.sin(Fb[1]), .cin(Cr[0]), .sout(Lt[1]), .cout(Cr[1])); DFFE Ff1 (.d(Lt[1]), .clk(Clock), .clrn(Reset_n), .prn(1), .ena(Enable), .q(Fb[1])); CARRY_SUM Cy2 (.sin(Fb[2]), .cin(Cr[1]), .sout(Lt[2]), .cout(Cr[2])); DFFE Ff2 (.d(Lt[2]), .clk(Clock), .clrn(Reset_n), .prn(1), .ena(Enable), .q(Fb[2])); CARRY_SUM Cy3 (.sin(Fb[3]), .cin(Cr[2]), .sout(Lt[3]), .cout(Cr[3])); DFFE Ff3 (.d(Lt[3]), .clk(Clock), .clrn(Reset_n), .prn(1), .ena(Enable), .q(Fb[3])); assign Count = Fb; assign POut = Cr[3]; endmodule Но не получаю желаемого (см. картинку). Где-то промахнулся. Поможите, люди добрые!
  4. Я думаю, и с CPLD не прокатит. Это ж будет не просто инвертор, какие-то соединительные цепи будут участвовать. Инвертор нужно вывести в режим усилителя с помощью резистора между входом и выходом. Сомневаюсь. Но было бы любопытно...
  5. По поводу for - уже и не знаю... :unsure: По поводу <= в конкурирующих блоках - признаюсь, был неправ! В доказательство привожу файл, стр. 10 Эх, надо было раньше в него заглянуть :) Я ж учил :) 1996_CUG_presentation_nonblocking_assigns.pdf
  6. Это просто переменная цикла, не относящаяся к переменным, которым присваивается значение (внутри цикла, внутри блока). Речь должна идти не о ней. На всякий случай спрошу - разве я могу присвоить что-то i внутри цикла?
  7. Насчет = и <= в двух блоках - пока не все изучил, позже выскажусь. Если что - признаю что не прав. Не знаю. Читаю. Насчет цикла for - в пункте 9.6 нет упоминания ни блокирующих, ни неблокирующих присваиваний. И не должно быть. Как справедливо заметил SM, что захочу, то и поставлю. Так ведь я именно об этом и говорил! Опять все наизнанку вывернуто.
  8. В сообщениях 397...402 речь шла о том, как обойтись одними неблокирующими присваиваниями в операторе for. Естественно, речь должна идти не о переменной цикла. Это шутка такая. Я еще хотел написать что-то вроде: "А для for(i=0; i<=10;i++) не обойтись без присваиваний обоих типов?". Зачем придумывать казуистические примеры? assign n =... - того же вида. Шутка! :) Я не собираюсь использовать только = или только <=. Я говорил, что это можно делать, если захотеть. А также, я говорил, что два вида присваиваний призваны облегчить жизнь писателю. В том числе, и избежать гонок "малой кровью". По поводу одинакового поведения = и <= в конкурирующих блоках - давайте проверим. На симуляторе, на компиляторе. А насчет SystemC - кто знает, может в следующей версии Quartus будет его поддерживать. Я вчера полез сам почитать, скачал стандарт. Документ не хуже того, который здесь горячо цитируется.
  9. Потому что обновление переменных a и b будет происходить одинаково по времени и для =, и для <=. Ведь в приведенных блоках никаких других операторов нет. Задержек нет. Появился clk, изменились a и b. В самом блоке, в момент clk, или при выходе из блока в тот же момент clk. Согласны? Ну а дальше, как сказал...
  10. to Leka То, к чему тянется ваша душа, имеется в природе под названием SystemC. Я, правда, кроме названия, ничего про него не знаю. Советую обратить внимание. to SM Извиняюсь, поздно откликнулся. А если заменить на <= , то все станет однозначно? Да то же самое и будет. Ну и дальнейшие ваши выводы, как я думаю, неверные.
  11. to SM Вы считаете, что в операторе for(i=0, i<n, i++) используются блокирующие присваивания? А в assign a = b & c; - тоже?
  12. Если это ко мне претензия... Раскинув мозгами, я тоже пришел к такому выводу. Не связана никак структура ПЛИС и подобные "присваивания". Но и очень плохого ничего в таком коде не вижу. Работает. На референсные примеры кода я уж точно не претендую. Вообще эти присваивания - чисто облегчить жизнь "писателю". Можно обойтись одними = (интересно, несогласные с этим есть?) Чтобы писать "нормальные" конструкции, надо понять, как и почему возникают "ненормальные" :) Рискну даже высказать мысль, что можно обойтись и одними <= :)
  13. Похоже. Причем, даже такой модуль module tst( a, b ); output reg a; output reg b = 0; always @(a) begin b = 1; end endmodule Синтезируется в a=0, b=1
  14. Что вызывает начальный заход в блок? Висели себе a и b в нуле, никого не трогали. Событие - это изменение сигналов, к которым чувствителен блок. Дальше, действительно, при выходе из блока b=0, тут же b=1 - вот и событие. А началось с чего?
  15. Компилил то, что Вы предложили (т.е. не Вы, а Leka). module tst( a, b ); output reg a=0; output reg b=0; always@* begin a <= b; b <= 0; b <= 1; end endmodule Происходит вот что, как я думаю. Поначалу a=0, b=0. Блок должен сработать, когда b<=1. Задаст a<=b=1, потом b<=0, потом b<=1. После этого никаких событий (изменений) больше не возникает. Никаких вечных циклов. Вечное ожидание.
  16. Обновился :) Только как объяснить результат компиляции?
  17. Стандарт у меня 1995 года. Оттуда, откуда у всех :) Quartus скомпилировал, повесил на a и b по 1. Вот и гадайте теперь вместе с этим ...ным стандартом :)
  18. to Leka попробую ваш модуль to all Хочу внести ясность в неблокирующие присваивания. Две картинки из стандарта, говорящие о том, что результат нескольких <= для одной переменной непредсказуем и неопределен. Раздел 9.2.2. Может, об этом уже говорили. Но у меня сложилось мнение, что SM говорил обратное. В посте #282.
  19. Здесь, кажется, упоминалась книга Полякова. Мне она дала одно - сравнивая примеры на VHDL и Verilog, я выбрал Verilog. И не жалею! Все на Verilog!! SystemVerilog!!!
  20. По первому - тем лучше! Смелее ставьте = и <= :) Именно в такой последовательности! По второму - там как раз сначала идут блокирующие присваивания, а потом неблокирующие. Приведите пример обратного.
  21. Потому, что выполняет операторы попорядку. В первом случае он не нашел ничего, что бы ему помешало синтезировать схему. Не было ничего, что он должен был бы помнить до конца блока, и затем присвоить. Но делать так не желательно. Потому что последовательное выполнение операторов стандартом не гарантируется, как я понимаю.
  22. В первом случае, при sel = 1, count однозначно должен стать 1. Сначала - всегда в 0, потом - в зависимости от sel. Во втором count должен стать 1 по условию sel = 1, но по выходу из блока должен был бы стать 0 из-за неблокирующего присваивания. В последних приведенных вами примерах - все аналогично. Кстати - для понимания присваиваний - лучше не придумать!
  23. У меня все тот же Quartus 9.0, на картинке все видно. Видимо, у меня "тюнингованный" :) Лично меня абсолютно не смущает наличие в одном блоке = и <=. Главное, чтобы они не выполнялись одновременно для одной переменной. В данном случае есть проверка условия if..else. Эти части никогда не выполнятся вместе! "Элементарно, Ватсон!"
×
×
  • Создать...