Копаю PAL/FPGA. В целом, не только для Агата (Страница 2 из 3)

Продолжил ковырять тему матриц. Осваиваю Verilog. Экспериментирую с небольшой платкой, на которую запаяна epm3064.
Поставил max plus II и пару Quartus II (9 и 11). Пока читаю книжки и статьи и пишу мелкие тестовые проги.

Как-то сразу повезло попасть на два то ли бага, то ли фичи:

1)

module ac(x)
input x;
wire x = 1;

Вроде бы объявляю x как вход, но при этом могу ему же присвоить значение. Max Plus II это пропускает, похоже по ошибке.
При этом x становиться как бы локальной шиной (т.е. разрывается его связь с вышележащим модулем).
Квартусы ругаются на ошибку.

2)

always @(posedge s) begin
t1 <= t1 + 1;
case (x)
    3'bxx1: t1 <= 4;
    3'b11x: t1 <= 3;
endcase
end

В квартусе case работает только если варианты определены полностью (без "x"). Те, которые с 'x', тихо игнорируются и ничего не синтезируют.

В max plus II варианты с 'x' корректно синтезируются и потом работают в симуляции.

Вставлю свои 3 копейки по verilog и мышлению.

Целую неделю бился и решил свою задачку. Тут не важно какую, но мышление изменил снова :-)
В verilog цепи (wire) и регистры (reg) по умолчанию со знаком, даже однобитные. Поэтому операция инверсии бита ~ меняет знак.
Пример:
Сумматор с переносом.

wire A;
wire B;
wire S;               // сумма
wire P;               //бит переноса 

assign {P,S} = A + B;

Тут собственно будет работать как надо.
A=0 B=0 выход S=0 P=0,
A=0 B=1 выход S=1 P=0,
A=1 B=0 выход S=1 P=0,
A=1 B=1 выход S=0 P=1.
Но, если изменить суматор с инверсией А. Вот так:

assign  {P,S} = ~A + B;

То тут будет так:
A=0 B=0 выход S=1 P=1,
A=0 B=1 выход S=1 P=1,
A=1 B=0 выход S=0 P=0,
A=1 B=1 выход S=1 P=0.

То есть при инверсии единицы, получаем ноль с минусом :-)

Я решил так:

assign  {P,S} = $unsigned( ~A ) + B;

Спасибо за подсказки, но я ещё не захожу так далеко, чтобы думать о хорошем стиле.
Мне сейчас важно убедиться, что я правильно понимаю синтаксис языка и логику действий компилятора.
Я придумываю какие-то примеры, возможно и не удачные для практической реализации, но мне важнее, чтобы компилятор выдал какой-то конкретный фрагмент именно так, что мной было задумано. Если этого не происходит, я разбираю причины.

Например, я придумываю два модуля, в каждом из которых вычисляется какая-то функция. Причем с одними и теми же входными данными. И потом смотрю итог. Мне интересно, сообразит ли компилятор, что эту функцию можно реализовать в железе один раз,  а не дважды. Не соображает :(.

Дело в том, что компиляторы для традиционных языков программирования уже достигли очень приличной оптимизации кода.
Иногда речь заходит даже о том, что они могут давать код лучше, чем средний ассемблер -программист. И я сам это вижу: когда какой-нибудь небольшой кусок проги на C реально компилируется в такой же небольшой ассемблер-код. С выкидыванием всех неиспользуемых функций, с развёрткой выражений, подстановкой констант, удалением условий, которые никогда не выполнятся. И это ещё не всё: где-то в интеловских документах об оптимизации когда для 3-4 пней были и более изысканные примеры, когда в 3-5 ассемблер-команд компилировалось несколько арифметических выражений, да ещё и с условиями.

Кроме того, последние годы я замечаю, что компиляторы становятся не только эффективными внутри, но и снаружи:
они в warning'ах уже подсказывают многое, что как бы разрешено в языке, но может неоднозначно выглядеть и, вероятно,
является ошибкой. Они анализируют соответствия строки формата printf и фактических аргументов, соответствия типов
указателей, предупреждают о всяких "if (x=1)" и подобном. Недавно даже увидел предупреждение в какой-то конструкции вида:
"if () c(); else if () a(); else b();" что-то вроде "запутаетесь вы в своих else, однако".

И я вот пытаюсь понять, когда пишу какую нибудь фигню: эта фигня не должна компилироваться вообще или я придумал что-то вроде:

int x[10][20];

main() {
  printf("%d\n", x[3,5]);
}

Т.е. это плохой стиль, такая прога делает что-то совсем непонятное с точки зрения программиста, переходящего с паскаля на C, например. Но она даёт вполне предсказуемый результат с точки зрения документации на язык.

Я хочу оценить, на что способен verilog, мне хочется понять, что он видит в моих примерах.
Могу ли я расчитывать на то, что компилятор предупредит о проблемах или оптимизирует конфигурацию или же нужно самому заранее это всё делать максимально эффективно, даже в ущерб читаемости исходника ?

> 2А) В блоке always все действия происходят одновременно и параллельно по положительному фронту s. А ты же И инкрементируешь t1 И присваиваешь t1 значения. КАК ТАК??? Напомню: все происходит ОДНОВРЕМЕННО и ПАРАЛЛЕЛЬНО по клоку. Это НЕ ПРОГРАММА, которая выполняется последовательно... Меняй мЫшление! ;) Перестраивайся на синхронный дизайн.

Так в том всё и дело, что если это технически невозможно, то почему компилятор не сообщает об ошибке ?
Или всё таки есть некая договорённость внутри языка, которая говорит о том, что условные выражения имеют приоритет перед безусловными ? Может она там мультиплексер синтезирует в ответ, который при совпадении case отключит инкремент.

> 2Б) Для case с вариантами 'x' есть casex. И для case с вариантами 'z' есть casez.

Вот тут интересно: это было введено в поздних версиях языка или max plus не даёт ошибок потому что просто опять косячит ?

Т.е. case предназначен только для полностью определённых случаев и в моём примере должна была возникнуть ошибка компиляции ?
Выкопал стандарт языка, не знаю - актуальный или нет:
http://www.csit-sun.pub.ro/~cpop/Verilo … synver.pdf

Тут говорится: "A case item consists of an expression (usually a simple constant) or a list of expressions separated by commas, followed by
a colon (:).". Как бы нечёткое определение. Т.е. для case вроде как и не запрещены xxx. С другой стороны, для casex:
"A case item can have expressions consisting of... A constant containing z, x, or ?"

> 2В) Для case очень и очень желательно default-вариант.

Иначе что будет ? Ненужное усложнение схемы или путаница ?
Например, я делаю параллельный сдвиговый регистр:

module preg(clk, wire [1:0] mode, [7:0] data, [7:0] q)
always @(posedge clk) begin
  case (mode)
    2'b01: q <= q < 1;
    2'b10: q <= q > 1;
    2'b11: q <= data;
  endcase
end

По логике вещей, мне не нужна тут комбинация mode==00 - это просто хранение данных в q.
Я расчитываю получить из case обычный дешифратор режима из трёх комбинаций двухвходовых элементов И и парочкой НЕ.
Что мне даст default ? Будет ли польза от того, что я добавлю пустой "default: ;" ?

Эээ..какие небылицы? Как додумался так и рассказал, я только учусь :-)

А за логическое отрицание спасибо. Я про него думал, но почему оставил на потом. Да все работает так же как с @unsigned.
Это ж тоже все к "мышлению" ? :-)

Че-то меня заинтересовала эта инверсия :)
Залез в стандарт 1364-2001 :
4.1.6: A reg data type shall be treated as an unsigned value unless explicitly declared to be signed.
А вот про wire такого чёткого определения не удалось найти :(.

Про case и default:
в документе от Synopsys (на который я давал ссылку) говорится следующее:
компилятор сам решает, синтезировать ли case в приоритетеный энкодер или в мультиплексер.
Но ему можно подсказать это опциями: //parallel_case или //full_case (возможно, это есть только в компиляторах synopsis).
Также влияет наличие default либо полный/не полный список всех возможных комбинаций case.

Нужно учитывать, что если вы во всех возможных комбинациях case задаёте значение какому-нибудь reg,
то этот reg может быть пострен как wire (т.е. синтезируется просто коммутатор). В то время как при не полном описании возможных
комбинаций (т.е. когда переменная может не менять значение в case) reg будет именно регистром.

Суть: что с default, что без него - это не плохие комбинации. Но они могут неожиданно для разработчика становиться
очень непохожими между собой в железе, что приведёт, как обычно, к внезапно уплывшим таймингам.

> И почему у тебя вместо сдвига идет сравнение?
Ошибся просто.

> Цампутер не умеет читать твои мысли.
А ему не надо читать.
Если ему не хватает моего описания или оно противоречит стандарту языка - он должен сказать об ошибке.
Если же противоречий нет - он должен синтезировать схему в соответствии со стандартом.
И всё.

Но он, в случае двойного "T1<="  не сообщает об ошибке синтеза. Значит либо он косячит либо стандарт как-то допускает такое описание. Надо порыться в описании стандарта...

Как сделать в verilog многократную генерацию модуля (создание экземпляров) с различными аргументами?

То есть у меня есть текст:

wire [30:0] c1, [30:0] c2;

mod mod_1(c1[2], c2[2]);
mod mod_2(c1[3], c2[4]);
mod mod_3(c1[4], c2[8]);
mod mod_4(c1[5], c2[16]);

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

for (integer x = 2, integer y = 2; x < 5; x = x+1, y = y * 2) begin
  mod(c1[x], c2[y]);
end;

но for допустим только внутри always. Есть какое-то решение ?

for при синтезе.

Нарисовал моргалку - плавно зажигает и гасит светодиод :))

module epm3064_led_morg(input clock, output led);

  parameter WIDTH = 26;
  wire [WIDTH-1:0] clock_chain;
  clock #(WIDTH) clock1 (clock, clock_chain);

  assign led = clock_chain[25] ? (clock_chain[3:0] > clock_chain[24:21]) :
                            (clock_chain[3:0] < clock_chain[24:21]);
endmodule

module clock #(parameter WIDTH)(input clock, output reg [WIDTH-1:0] div);
  genvar i;
  generate
    always @(posedge clock) div[0] <= ~div[0];
     for (i = 1; i < WIDTH; i = i + 1) begin : CLOCK
       always @(posedge div[i-1]) div[i] <= ~div[i];
     end
  endgenerate
endmodule

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

> Тот же эффект получился? Ресурсы те же получились?

Я с этого начинал :) Знаю, что те же рессурсы будут. Но ещё раз: я хочу добиться того, чтобы компилятор создавал такую схему, как мне хочется. Сейчас дело не в оптимальности схемы, а том, чтобы понимать язык и его транслятор.

Вот мне сейчас нужно сделать статический case:

case (mode)
  0: led = x1;
  1: led = x2;
  2: led = x3;
  3: led = x4;
endcase

mode - регистр, управляется с клавиатуры.
Компилятор упорно предлагает мне сделать led триггером либо mode - константой.
Я знаю, что могу нарисовать какое-то выражение вида led = (mode == 0) ? x1 : (mode == 1) ?..........
Но я хочу чтобы использовать case, чтобы иметь более читаемую конструкцию.
И на выходе получить синтезированный коммутатор.
И пока не получу именно такой результат - дальше не пойду.

Тут как бы простое правило: если led объявлен регистром, и case стоит в блоке always, у которого в списке чувствительности стоит положительный или отрицательный фронт какого-либо сигнала (но не mode!), то тогда led и станет регистром (D-триггер). И осторожно с блокирующим присваиванием!
Если же в списке чувствительности always-блока стоит просто mode (или *), то будет мультиплексор! И даже если led объявлен регистром или case не в always-блоке, все равно будет мультиплексор на комбинаторике!

Ты уверен в своей логике?

Устранение дребезга - большая и мутная тема... По крайней мере на FPGA (хоть и есть асинхронный сброс, но проблемно его использовать). Но в MAX-е вполне можно юзать асинхронные сброс и установку - как бы классическую схему устранения дребезга.

1) Я же тебе сразу посоветовал MAX7000S! А с MAX3000 есть ограничения... С ТТЛ прокатит, с CMOS нет, но можно opendrain.
2) Сейчас точно не помню, но вроде как +-16 мА они могут качать... На шину - нет проблем.
3) Названия говорят сами за себя... Кури шиты даташные. ;)
4) Не знаю о чем речь... Оно тебе надо?... ;)

Определение регистра, второй абзац.