Почему этот Verilog использует 30 макроэлементов и сотни продуктов?

У меня есть проект, который потребляет 34 макроэлемента Xilinx Coolrunner II. Я заметил, что у меня была ошибка, и отследил ее до этого:

assign rlever = RL[0] ? 3'b000 :
                RL[1] ? 3'b001 :
                RL[2] ? 3'b010 :
                RL[3] ? 3'b011 :
                RL[4] ? 3'b100 :
                RL[5] ? 3'b101 :
                RL[6] ? 3'b110 :
                        3'b111;

assign llever = LL[0] ? 3'b000 :
                LL[1] ? 3'b001 :
                LL[2] ? 3'b010 :
                LL[3] ? 3'b011 :
                LL[4] ? 3'b100 :
                LL[5] ? 3'b101 :
                        3'b110 ;

Ошибка в том , что rleverи lleverв один бит в ширину, и мне нужно , чтобы они были три бита. Дурак я. Я изменил код, чтобы быть:

wire [2:0] rlever ...
wire [2:0] llever ...

так что было достаточно битов. Однако, когда я перестроил проект, это изменение стоило мне более 30 макроэлементов и сотен терминов продукта. Может кто-нибудь объяснить, что я сделал не так?

(Хорошая новость заключается в том, что теперь он симулирует правильно ... :-P)

РЕДАКТИРОВАТЬ -

Я полагаю, что я расстроен, потому что примерно в то время, когда я начинаю понимать Verilog и CPLD, происходит что-то, что показывает, что у меня явно нет понимания.

assign outp[0] = inp[0] | inp[2] | inp[4] | inp[6];
assign outp[1] = inp[1] | inp[2] | inp[5] | inp[6];
assign outp[2] = inp[3] | inp[4] | inp[5] | inp[6];

Логика реализации этих трех строк встречается дважды. Это означает, что каждая из 6 строк Verilog потребляет около 6 макроэлементов и 32 термина продукта в каждой .

РЕДАКТИРОВАТЬ 2 - Согласно предложению @ ThePhoton о переключении оптимизации, вот информация со сводных страниц, созданных ISE:

Synthesizing Unit <mux1>.
    Related source file is "mux1.v".
    Found 3-bit 1-of-9 priority encoder for signal <code>.
Unit <mux1> synthesized.
(snip!)
# Priority Encoders                                    : 2
 3-bit 1-of-9 priority encoder                         : 2

Так ясно, что код был признан чем-то особенным. Однако дизайн все еще потребляет огромные ресурсы.

РЕДАКТИРОВАТЬ 3 -

Я сделал новую схему, включающую только мукс, который рекомендовал @thePhoton. Синтез произвел незначительное использование ресурсов. Я также синтезировал модуль, рекомендованный @Michael Karas. Это также привело к незначительному использованию. Так что некоторое здравомыслие преобладает.

Очевидно, что мое использование значений рычагов вызывает ужас. Еще не все.

Окончательное редактирование

Дизайн больше не безумен. Однако я не уверен, что случилось. Я сделал много изменений, чтобы реализовать новые алгоритмы. Одним из способствующих факторов было «ROM» из 111 15-битных элементов. Это потребляло скромное количество макроэлементов, но многоусловий продукта - почти все те, что доступны на xc2c64a. Я ищу это, но не заметил этого. Я считаю, что моя ошибка была скрыта оптимизацией. «Рычаги», о которых я говорю, используются для выбора значений в ПЗУ. Я предполагаю, что когда я реализовал (отключенный) 1-битный приоритетный кодер, ISE оптимизировал часть ПЗУ. Это было бы довольно сложно, но это единственное объяснение, которое я могу придумать. Эта оптимизация значительно сократила использование ресурсов и заставила меня ожидать определенного базового уровня. Когда я исправил приоритетный кодер (согласно этой теме), я увидел издержки приоритетного кодера и ПЗУ, которые ранее были оптимизированы, и связал их исключительно с первым.

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

На данный момент эта вещь вписывается в xc2c64a; Я использовал 81% и 84% своих макроэлементов и терминов продукта соответственно. Конечно, теперь я должен проверить это, чтобы убедиться, что он делает то, что я хочу ...

Спасибо ThePhoton и Майклу Карасу за помощь. В дополнение к моральной поддержке, которую они оказали, чтобы помочь мне решить эту проблему, я узнал из документа Xilinx, опубликованного ThePhoton, и реализовал кодировщик приоритетов, предложенный Майклом.

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

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

Согласно Википедии , стандартный кодер приоритета нумерует свои входы от 1. То есть, если установлен младший значащий бит, он выводит 1, а не 0. Кодировщик приоритета Википедии выдает 0, когда ни один из входных битов не установлен.

Однако в руководстве пользователя XST Xilinx (стр. 80) приоритетный кодер ближе к тому, что вы кодировали. Входы пронумерованы от 0, поэтому, когда lsb входа установлен, он дает выход 0. Однако определение Xilinx не дает спецификации для вывода, когда все входные биты очищены (ваш код выведет 3'd7).

Конечно, руководство пользователя Xilinx определит, что ожидает программное обеспечение для синтеза Xilinx. Суть в том, что (*priority_extract ="force"*)для XST требуется специальная директива для распознавания этой структуры и получения оптимальных результатов синтеза.

Вот рекомендуемая форма Xilinx для кодера с приоритетом 8 к 3:

(* priority_extract="force" *)
module v_priority_encoder_1 (sel, code);
input [7:0] sel;
output [2:0] code;
reg [2:0] code;
always @(sel)
begin
    if (sel[0]) code = 3’b000;
    else if (sel[1]) code = 3’b001;
    else if (sel[2]) code = 3’b010;
    else if (sel[3]) code = 3’b011;
    else if (sel[4]) code = 3’b100;
    else if (sel[5]) code = 3’b101;
    else if (sel[6]) code = 3’b110;
    else if (sel[7]) code = 3’b111;
    else code = 3’bxxx;
end
endmodule

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

Я думаю, что вы можете получить это, создав модуль кодера Xilinx с

v_priority_encoder_1 pe_inst (.sel({~|{RL[6:0]}, RL[6:0]}), .code(rlever));

Я не собрал все биты, RL[6:0]чтобы получить 8-й входной бит, который сработает на выходе 3'b111, когда все биты RL будут низкими.

Для lleverлогики вы, вероятно, можете уменьшить использование ресурсов, создав модифицированный модуль кодировщика, следуя шаблону Xilinx, но требуя только 7 входных битов (ваши 6 бит LLплюс дополнительный бит, который повышается, когда остальные 6 все младшие).

Использование этого шаблона предполагает, что версия вашего ISE использует механизм синтеза XST. Кажется, что они меняют инструменты синтеза на всех основных версиях ISE, поэтому убедитесь, что документ, на который я ссылался, действительно соответствует вашей версии ISE. Если нет, проверьте рекомендуемый стиль в своей документации, чтобы увидеть, что ожидает ваш инструмент.

Ответ Фотона - превосходный. Я хотел бы добавить дополнительную информацию здесь для вашего рассмотрения. Это связано с тем фактом, что, несмотря на то, что у нас есть современные модные устройства FPGA и CPLD, использующие HDL и инструменты синтеза, может быть информативно присмотреться к вещам, разработанным много лет назад. Оставайся со мной, пока я прохожу это к моей рекомендации в конце.

Существуют дискретные логические части, которые выполняют функцию кодирования приоритетов. Логика, реализованная этими частями, существовала долгое время, когда было необходимо сократить количество транзисторов до минимума. Вы можете выполнить поиск в Интернете для логических деталей с общими номерами деталей, таких как 74HC148 или MC14532B, чтобы найти таблицы данных, которые содержат эквивалентные логические схемы для этих деталей. Приведенная ниже диаграмма является одним примером, взятым из спецификации TI для детали 74HC148 .

Эта логика реализует следующую таблицу истинности (взятую из той же таблицы данных):

Обратите внимание, что вышеуказанное семейство деталей использует низкие активные входные сигналы. В другом листе данных для детали ON Semiconductor MC14532B показана таблица истинности для функции кодера с использованием активных высоких входных сигналов, аналогично вашему примеру Verilog.

В этом же листе данных приведены логические уравнения для MC14532B следующим образом:

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