ПЛИС и всё что с ними связано

Цитата:

---

Сообщение от Bolt

Вот тут не понял. Что, если взять с PLL две разных частоты и завести на два триггера, то автоматически избавимся от метастабильности?
Картинку с "плывущей" фазой двух синхросигналов относительно друг друга рисовать или сами представите?

---

Если на каждый из триггеров подать по разному клоку, то на их выходах получатся сигналы с частотой этих клоков, но задержанные на неопределённое время, зависящее от фазы луны, солнечного ветра и погоды на Марсе/Сникерсе/Баунти. И они не будут клоками.
Если на тактовые входы этих триггеров подать клок максимально имеющейся в системе частоты, а на входы данных триггеров подать 2 клока с PLL, то на выходах этих триггеров будут сигналы, сихронизированные с той максимальной частотой системы и они таки будут избавлены от метастабильности относительно этой самой частоты, но клоками они от этого не станут.
Если на тактовые входы всех триггеров, образующих систему тактирования, подать одну, максимально возможную частоту в системе тактирования, разместить их максимально близко друг к другу на отдельном кристалле (или максимально изолированной части общего кристалла) да запитать их от отдельного источника, то выходы этих триггеров, а вовсе не образующий их клок, подключенные к специально разведённым по площади всего кристалла линиям с минимальной задержкой, можно считать клоками, избавляющими от метастабильности те самые сигналы, описанные в предыдущем абзаце.

Цитата:

---

Сообщение от Bolt

Для лучшего понимания чего?

---

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

- - - Добавлено - - -

Цитата:

---

Сообщение от dosikus

Да у процессора 2 8ми битных порта чисто вход и 2 чисто выход.

---

Но память-то у него куда-то подключена?
Хоть 256 байт-то есть?

(которую корку, кстати, юзаешь?)

Цитата:

---

Сообщение от omercury

Ага, то есть Гарвардская архитектура - отдельно память программ, отдельно память данных, так?

---

Угу.

Цитата:

---

Сообщение от omercury

Теперь по организации памяти, я предлагаю такую - Вложение 70020

---

Я за. А что такое b7 и b15?

- - - Добавлено - - -

Цитата:

---

Сообщение от omercury

Но память-то у него куда-то подключена?
Хоть 256 байт-то есть?

(которую корку, кстати, юзаешь?)

---

ВотЪ - https://github.com/jaruiz/light52
Я так понимаю это продолжение сего https://opencores.org/projects/light52
На гите в доках вполне приличное описание .

Цитата:

---

256 bytes of IRAM -- fixed size

---

И сразу вопрос -
Автор использует свой конвертер hex => шаблон на VHDL , в верилоге я так понимаю можно hex сразу грузить?

Нашел здесь генератор синхроимпульсов VGA640x480 http://baltazarstudios.com/poem-fpga/
Прикрутил его к своему HDMI, пока 640х480.

https://dropmefiles.com/WI44s

omercury, как в верилоге прописывать константы и условную компиляцию - хочу тайминги перевести на 800х600 и что бы их ручками не перебивать.

Цитата:

---

// Module VGA_SYNC
//
// Generates output sync signals to drive VGA display in 640x480 pixel mode:
//
// Refresh rate: 60 Hz
// Vert. refresh: 31.46 kHz
// Pixel frequency: 25.175 MHz
//
// Horizontal timing (pixels) Vertical timing (pixels)
// Visible area: 640 480
// Front porch: 16 10
// Sync pulse: 96 2
// Back porch: 48 33
// Whole line: 800 525

module vga_sync (

input clk_in, // Input 25.175 MHz clock, this is a pixel clock for this VGA mode
input reset, // Input async. active low reset signal

output reg vga_hsync, // Output horizontal sync signal
output reg vga_vsync, // Output vertical sync signal

output reg disp_enable, // Set when a writable portion of display is enabled:
output reg[9:0] pix_x, // x-coordinate of an active pixel
output reg[9:0] pix_y // y-coordinate of an active pixel
);
//================================================== ====================

localparam SYNC_ON = 1'b0; // Define the polarity of sync pulses
localparam SYNC_OFF = 1'b1;

reg[9:0] line_count; // Line counter, current line
reg[9:0] pix_count; // Pixel counter, current pixel

always @( posedge clk_in or negedge reset )
begin
if (!reset) begin
line_count <= 0; // On a reset, restart counters from 0
pix_count <= 0;
end else begin

pix_count <= pix_count + 1;// Increment a pixel counter every clock time!

// This is a state machine based on a pixel count. Since VGA modes timings are
// based on a multiple of pixel counts, we add them up and generate syncs at
// proper times
case (pix_count)
0: vga_hsync <= SYNC_OFF;
16: vga_hsync <= SYNC_ON;
112: vga_hsync <= SYNC_OFF;
800: begin
line_count <= line_count + 1;
pix_count <= 0;
end
endcase

// Properly toggle vertical sync based on the current line count
case (line_count)
0: vga_vsync <= SYNC_OFF;
10: vga_vsync <= SYNC_ON;
12: vga_vsync <= SYNC_OFF;
525: begin
line_count <= 0;
end
endcase

// The following code defines a drawable display region and outputs
// disp_enable to 1 when within that region. Also, set the pixel coordinates
// (normalized to the top-left edge of a drawable region)
disp_enable <= 0;
pix_x <= 0;
pix_y <= 0;
if (line_count>=35 && line_count<515)
begin
if (pix_count>=160 && pix_count<800)
begin
disp_enable <= 1;
pix_x <= pix_count - 10'd160;
pix_y <= line_count - 10'd35;
end
end
end
end

endmodule

---

И здесь наверное надо добавить глобальный счетчик пикселей( АДРЕС) для вычитки из RAM?

Цитата:

---

Сообщение от dosikus

как в верилоге прописывать константы

---

`define
parameter
localparam

Цитата:

---

Сообщение от dosikus

и условную компиляцию

---

`ifdef / `ifndef - `elsif - `else - `endif

Цитата:

---

Сообщение от dosikus

И здесь наверное надо добавить глобальный счетчик пикселей( АДРЕС) для вычитки из RAM?

---

Ага, и сделать его вычисляемым из всех параметров.
Вот здесь пример.

- - - Добавлено - - -

Цитата:

---

Сообщение от dosikus

А что такое b7 и b15

---

Это я так старший бит данных обозвал.

Цитата:

---

Сообщение от dosikus

в верилоге я так понимаю можно hex сразу грузить?

---

Да, можно как и свой .mif, так и интел хекс.

- - - Добавлено - - -

Цитата:

---

Сообщение от dosikus

На гите в доках вполне приличное описание .

Цитата:

---

256 bytes of IRAM -- fixed size

---

---

Ага, но адресация 16-битная. :)

Цитата:

---

xdata_addr : out std_logic_vector(15 downto 0);

---

Вот это ж...
Modelsim напрочь не хочет симулить винегрет из верилога и вхдл...

- - - Добавлено - - -

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


// Module VGA_SYNC
//
// Generates output sync signals to drive VGA display in 640x480 pixel mode:
//
// Refresh rate: 60 Hz
// Vert. refresh: 31.46 kHz
// Pixel frequency: 25.175 MHz
//
// Horizontal timing (pixels) Vertical timing (pixels)
// Visible area: 640 480
// Front porch: 16 10
// Sync pulse: 96 2
// Back porch: 48 33
// Whole line: 800 525

module vga_sync (

input clk_in, // Input 25.175 MHz clock, this is a pixel clock for this VGA mode
input reset, // Input async. active low reset signal

output reg vga_hsync, // Output horizontal sync signal
output reg vga_vsync, // Output vertical sync signal

output reg disp_enable, // Set when a writable portion of display is enabled:
output reg[9:0] pix_x, // x-coordinate of an active pixel
output reg[9:0] pix_y // y-coordinate of an active pixel
);
//================================================== ====================

localparam SYNC_ON = 1'b0; // Define the polarity of sync pulses
localparam SYNC_OFF = 1'b1;

reg[9:0] line_count; // Line counter, current line
reg[9:0] pix_count; // Pixel counter, current pixel

always @( posedge clk_in or negedge reset )
begin
if (!reset) begin
line_count <= 0; // On a reset, restart counters from 0
pix_count <= 0;
end else begin

pix_count <= pix_count + 1'b1;// Increment a pixel counter every clock time!

// This is a state machine based on a pixel count. Since VGA modes timings are
// based on a multiple of pixel counts, we add them up and generate syncs at
// proper times




case (pix_count)
0: vga_hsync <= SYNC_OFF;
656: vga_hsync <= SYNC_ON;
752: vga_hsync <= SYNC_OFF;
800: begin
line_count <= line_count + 1'b1;
pix_count <= 0;
end
endcase

// Properly toggle vertical sync based on the current line count

case (line_count)
0: vga_vsync <= SYNC_OFF;
490: vga_vsync <= SYNC_ON;
492: vga_vsync <= SYNC_OFF;
525: line_count <= 0;

endcase


// The following code defines a drawable display region and outputs
// disp_enable to 1 when within that region. Also, set the pixel coordinates
// (normalized to the top-left edge of a drawable region)
disp_enable <= 0;
pix_x <= 0;
pix_y <= 0;
if (line_count>=0 && line_count<480)
begin
if (pix_count>=0 && pix_count<640)
begin
disp_enable <= 1;
pix_x <= pix_count;
pix_y <= line_count;
end
end
end
end

endmodule

На первый взгляд всё правильно.
В коде нет формирования изображения, blank (disp_enable) правильно учитывается? Растянутость и странная яркость может быть из-за отсутствия гашения.
Фото растянутого экрана можно?

Bolt, blank - disp_enable. Если оно подходит, в чем не уверен...
И все таки это какой-то глюк монитора на 640х480 .
Если я запускаю автонастройку на этом синхрогенераторе , что на переделанном что на оригинале - растягивает и все .
Помогает запуск чужой прошивки и автонастройка.

А может из-за того что я изображение по дикому делаю не учитывая ничего...

vga_r <= (px_x(6 downto 0)) and "11111111";
vga_b<= (px_x(6 downto 0)) and "11111111";


хрень какая-то ;)))))))

Вывел рамку по краям - все стало норм и автонастройка четко срабатывает.

vga_r <= "11111111" when px_x=0 or px_x=639 or px_y =0 or px_y=479 else (px_x(6 downto 0)) and "11111111";
vga_b<= "11111111" when px_x=0 or px_x=639 or px_y =0 or px_y=479 else (px_x(6 downto 0)) and "11111111";

Цитата:

---

Сообщение от dosikus

Вывел рамку по краям - все стало норм и автонастройка четко срабатывает.

---

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

Переделал на 800х600"60Hz.
Работает , рамка вписалась . Счас перепишу с константами и дефайнами и можно будет заняться ROM и RAM.
omercury, Я тут чЁ подумал , может пока сделать ROM с знакогенератором? И объем внутренней памяти уменьшим и работу 51ого облегчим ...

Продолжаю свою "эпопею".
Подключил к телевизору - все прекрасно, 800х600@60Hz.

Вообщем как-то так. Покритикуйте плиз.

Цитата:

---

module vga_sync(

input clk_in, // Input 25.175 MHz clock, this is a pixel clock for this VGA mode
input reset, // Input async. active low reset signal

output reg vga_hsync, // Output horizontal sync signal
output reg vga_vsync, // Output vertical sync signal

output reg disp_enable, // Set when a writable portion of display is enabled:
output reg[9:0] pix_x, // x-coordinate of an active pixel
output reg[9:0] pix_y, // y-coordinate of an active pixel
output reg[19:0] v_addr // VRAM address
);
//================================================== ====================

localparam SYNC_ON = 1'b0; // Define the polarity of sync pulses
localparam SYNC_OFF = 1'b1;

localparam HSYNC_START = 840-1;
localparam HSYNC_END = 968-1;
localparam LINE_END = 1056-1;
localparam VSYNC_START = 601-1;
localparam VSYNC_END = 605-1;
localparam FRAME_END = 628-1;
localparam integer H_ACTIV = 800;
localparam integer V_ACTIV = 600;


reg[9:0] line_count; // Line counter, current line
reg[15:0] pix_count; // Pixel counter, current pixel
reg[19:0] vaddr_count; // VRAM addres counter
always @( posedge clk_in or negedge reset )
begin
if (!reset) begin
line_count <= 0; // On a reset, restart counters from 0
pix_count <= 0;
vaddr_count<= 0;
end else begin

pix_count <= pix_count + 1'b1;// Increment a pixel counter every clock time!
vaddr_count <= vaddr_count + 1'b1;
if(vaddr_count==(V_ACTIV*H_ACTIV))
vaddr_count <=0;

// This is a state machine based on a pixel count. Since VGA modes timings are
// based on a multiple of pixel counts, we add them up and generate syncs at
// proper times

case (pix_count)
0: vga_hsync <= SYNC_OFF;
HSYNC_START: vga_hsync <= SYNC_ON;
HSYNC_END: vga_hsync <= SYNC_OFF;
LINE_END: begin
line_count <= line_count + 1'b1;
pix_count <= 0;
end
endcase

case (line_count)
0: vga_vsync <= SYNC_OFF;
VSYNC_START: vga_vsync <= SYNC_ON;
VSYNC_END: vga_vsync <= SYNC_OFF;
FRAME_END: line_count <= 0;

endcase


// The following code defines a drawable display region and outputs
// disp_enable to 1 when within that region. Also, set the pixel coordinates
// (normalized to the top-left edge of a drawable region)
disp_enable <= 0;
pix_x <= 0;
pix_y <= 0;
v_addr<=vaddr_count;
if (line_count>=0 && line_count<V_ACTIV)
begin
if (pix_count>=0 && pix_count<H_ACTIV)
begin
disp_enable <= 1;
pix_x <= pix_count;
pix_y <= line_count;
end
end
end
end

endmodule

---

Снова затык .
reg [7:0] vram [0:4095]; initial $readmemb("vram.bin", vram);
Подсовываю ему бинарник - лается Error (10170): Verilog HDL syntax error at vram.bin(1) near text Ë

Делаю так и подсовываю intel hex
reg [7:0] vram [0:4095]; initial $readmemh("vram.hex", vram);
лается Error (10170): Verilog HDL syntax error at vram.hex(1) near text :

Эбическая сила, оказывается hex и bin это текстовые файлы, первый с форматом типа 0A второй 01010101010.
И это полный п...

Binary и hex в понимании Verilog'а это немного другое.
Binary это текст 000 001 010 010...
Hex это текст 5A 00 FE D8...
https://timetoexplore.net/blog/initi...ory-in-verilog

Bolt, угу ужО осознал ...

- - - Добавлено - - -

Снова затык , растр полный но на экране мельтешение , нет ровной картинки.
Помогите...

Цитата:

---

module vga_sync(

input clk_in, // Input 25.175 MHz clock, this is a pixel clock for this VGA mode
input reset, // Input async. active low reset signal

output reg vga_hsync, // Output horizontal sync signal
output reg vga_vsync, // Output vertical sync signal

output reg disp_enable, // Set when a writable portion of display is enabled:
output reg[9:0] pix_x, // x-coordinate of an active pixel
output reg[9:0] pix_y, // y-coordinate of an active pixel
output reg[19:0] v_addr, // VRAM address count
output reg [7:0] data_out
);
//================================================== ====================

localparam SYNC_ON = 1'b0; // Define the polarity of sync pulses
localparam SYNC_OFF = 1'b1;

localparam HSYNC_START = 840-1;
localparam HSYNC_END = 968-1;
localparam LINE_END = 1056-1;
localparam VSYNC_START = 601-1;
localparam VSYNC_END = 605-1;
localparam FRAME_END = 628-1;
localparam integer H_ACTIV = 800;
localparam integer V_ACTIV = 600;

reg [7:0] vram [0:4095]; initial $readmemh("vram.txt", vram);

reg[9:0] line_count; // Line counter, current line
reg[15:0] pix_count; // Pixel counter, current pixel
reg[19:0] vaddr_count; // Pixel counter, current pixel
reg[7:9] temp_data;
always @( posedge clk_in or negedge reset )
begin
if (!reset) begin
line_count <= 0; // On a reset, restart counters from 0
pix_count <= 0;
vaddr_count<= 0;
v_addr =0;
end else begin

pix_count <= pix_count + 1'b1;// Increment a pixel counter every clock time!
vaddr_count <= vaddr_count + 1'b1;
if(vaddr_count==(V_ACTIV*H_ACTIV))
vaddr_count <=0;

// This is a state machine based on a pixel count. Since VGA modes timings are
// based on a multiple of pixel counts, we add them up and generate syncs at
// proper times

case (pix_count)
0: vga_hsync <= SYNC_OFF;
HSYNC_START: vga_hsync <= SYNC_ON;
HSYNC_END: vga_hsync <= SYNC_OFF;
LINE_END: begin
line_count <= line_count + 1'b1;
pix_count <= 0;
end
endcase

case (line_count)
0: vga_vsync <= SYNC_OFF;
VSYNC_START: vga_vsync <= SYNC_ON;
VSYNC_END: vga_vsync <= SYNC_OFF;
FRAME_END: line_count <= 0;

endcase


// The following code defines a drawable display region and outputs
// disp_enable to 1 when within that region. Also, set the pixel coordinates
// (normalized to the top-left edge of a drawable region)
disp_enable <= 0;
pix_x <= 0;
pix_y <= 0;
v_addr<=vaddr_count;
if (line_count>=0 && line_count<V_ACTIV)
begin
if (pix_count>=0 && pix_count<H_ACTIV)
begin
disp_enable <= 1;
pix_x <= pix_count;
pix_y <= line_count;
//data_out <=vram[vaddr_count];
end
end





end
end

always @( posedge clk_in)
begin
data_out <= vram[vaddr_count[11:0]];
end
endmodule

---

Цитата:

---

Сообщение от dosikus

Снова затык , растр полный но на экране мельтешение , нет ровной картинки.

---

Что и как мельтешит?
Рябь? Вертикальные линии рассыпаются на пиксели? Или что?

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

vaddr_count считает всегда, до значения V_ACTIV*H_ACTIV, и за один кадр успевает пройти больше одного цикла, вот картинка и бежит по экрану. Считать надо только если область видимая, и сбрасывать в ноль по синхроимпульсам.

Благодарствую, бум исправлять.

Привязал счетчик адресов vram к счетчикам пикселей. Усе взлетело .
Теперь буду знакогенератор осмысливать.

Кстати , везде где не смотрю, на верилоге воротят нос от Case.
Чем оно так чревато и чревато ли?

Цитата:

---

case (line_count)
0: vga_vsync <= SYNC_OFF;
VSYNC_START: vga_vsync <= SYNC_ON;
VSYNC_END: vga_vsync <= SYNC_OFF;
FRAME_END: line_count <= 0;

---

По мне так вполне читаемый декодер получается, или у мну взгляд от С зашоренный?

Я активно использую case, особенно, если много значений. Прочитал где-то, что длинные if then else хуже по быстродействию.
Главное - описать все значения анализируемого в case сигнала, особенно в асинхронных блоках, чтобы не получилось защелки.
Тут может помочь default.

IanPo, case удобен только программисту. В железе он преобразуется в дешифратор а потом опять в шифратор, это всё прекрасно видно в RTL. Это не особо важно для жирной FPGA, но критично для CPLD. Правильно сказали за варианты: если case не полный (например, для 5ти битного числа следует описать все 32 варианта, так или иначе), то синтезатор начинает сходить с ума и мешает кашу.

А вот if это всего лишь атомарная логическая операция. При этом, даже сравнение вида Temp[4:0] == 5'h13 (которое в RTL показывается как сравнение) сворачивается в чипе в обычную AND функцию, которую, к слову, можно описать и самому (для вышеуказанного примера это будет Temp[4] & ~Temp[3] & ~Temp[2] & Temp[1] & Temp[0]). Если в кейсе всего 3 случая, то 3 таких if заметно выгодны, кроме организации варианта с default.

В конечном итоге, тем кто собрался всерьёз писать на xHDL я настоятельно советую изучать и цифровую схематехнику. Это позволяет описать будущую схему гораздо эффективнее.

Цитата:

---

Сообщение от dosikus

Кстати , везде где не смотрю, на верилоге воротят нос от Case.
Чем оно так чревато и чревато ли?

По мне так вполне читаемый декодер получается,

---

Очень удобный оператор, для твоего случая - самое оно.
(в моём vgu можешь убедиться)

Сам использую где не чревато,
ибо чревато и ещё как...

Цитата:

---

Сообщение от IanPo

Я активно использую case, особенно, если много значений. Прочитал где-то, что длинные if then else хуже по быстродействию.
Главное - описать все значения анализируемого в case сигнала, особенно в асинхронных блоках, чтобы не получилось защелки.
Тут может помочь default.

---

Цитата:

---

Сообщение от HardWareMan

IanPo, case удобен только программисту. В железе он преобразуется в дешифратор а потом опять в шифратор, это всё прекрасно видно в RTL. Это не особо важно для жирной FPGA, но критично для CPLD.

---

Во, видишь?
Два диаметрально противоположных мнения
и оба неправильные... :)
Ща объясню...

Цитата:

---

Сообщение от dosikus

или у мну взгляд от С зашоренный?

---

И это в том числе.

Видишь ли, в ПЛИС нет последовательных операций, логика не ждёт, когда закончится одна операция и начнётся другая, весь код выполняется одновременно.
То есть, условно говоря, основной цикл, все подпрограммы и прерывания работают одновременно, всем гуртом.

Ща:

В чём "цимус" оператора case?
В том, что он отрабатывает все условия внутри себя одновременно, в отличие от, допустим, if-elseif-else - они отрабатывают условия последовательно - сначала первое, потом второе и так далее до конца. На каждую обработку тратится время (задержка внутри компаратора и ключей, соединяющих всю требуху внутри ПЛИС в общую схему), на каждый цикл сравнения, а ведь все они находятся внутри тактового блока, и в конечном итоге задержка накопится до такой степени, что часть условий просто перестанет обрабатываться - на них тупо не хватит времени за период тактового сигнала, и это при в общем-то корректной схеме (IanPo тут прав, а неправ HardWareMan). С другой стороны, у параллельного оператора case есть свои ограничения - он не может выделять приоритеты (покажу ниже) (HardWareMan тут прав, а неправ IanPo), зато он более "высокочастотный". И тут снова алаверды HardWareMan-у, ибо рабочими лошадками тут являются в основном CPLD.
Либо жирные FPGA за несколько тыщ долларов штучка (снова HardWareMan прав)... :)

Рассмотрим такой пример: есть, кроме всего прочего, 2 сигнала, один из которых должен быть обработан в текущем цикле, но только один из них, независимо, пришли они раздельно или одновременно. Пока неважно, который именно, сейчас пусть будет любой.
назовём их wire in1 и wire in2
Соберём их в общую шину для оператора case - wire [1:0] in = {in1, in2};
Теперь обработаем несколькими вариантами:
case (in)
2'b10 : <operators>
2'b01 : <operators>
....
Эта конструкция отработает неправильно, точнее не всегда правильно. Правильно она отработает только когда сигналы будут приходить раздельно, а если вдруг вместе, то не сделает ничего...
Чтобы сделало, надо, чтоб отрабатывался и второй сигнал, добавим его:
case (in)
2'b10, 2'b11 : <operators>
2'b01, 2'b11 : <operators>
....
Вообще на самом деле это, конечно, бред...
(кто знает, по которой ветке здесь ломанётся case? ;))...
Коллизия видна невооружённым взглядом.
Зато if-elseif отработает правильно
if(in1) <operators>
elseif(in2) <operators>
Он выполнит первое условие, если оно произошло, независимо от того, произошло ли событие само по себе, либо одновременно с in2.
Условие задачи выполнено.
Правда в случае одновременных in1 и in2 этот селектор проигнорирует in2.

Есть ещё один селектор - casex, в котором x означает любое (1 или 0) значение, но, во-первых, с ним в нашей задаче получается та же каша, что и с простым case, а во-вторых, проверяет он условия так же, как и if-elseif-else последовательно, то есть имеет недостатки как одного, так и другого..., но бывает удобным при множественном выборе. Ну и бонусом выступает его приоритетность, будет выполнено условие, которое выше по тексту.

В общем универсальной затычки на все случаи жизни нет, для каждой конкретной задачи надо выбирать то, что будет правильно работать именно с ней.

P.S.
Извини, что не сразу отвечаю, на работе, как ни странно, приходится работать...

omercury, а вот если бы ты оформил 2 параллельных ifа то они бы работали одновременно (одинаковая задержка) и "весили" бы минимально:

Код:

---

// Общий блок внутри begin/end
if (in1 & ~in2) begin ... end
if (~in1 & in2) begin ... end
// Конец общего блока

---

Вот эти два условия внутри одной пары begin/end будут работать одновременно и займут каждый по одному элементу 2И (инвертирование входа не является отдельным ресурсом) и будут управлять каждый своим begin/end. Вложенные if/else нужны именно там, где они нужны, например в генераторе синхросигналов развертки VGA: на строке Х мы активируем кадровый импульс присвоив триггеру 1, а на строке Y, соответственно, снимаем. Причем, если его вынести "за скобки" (т.е. за пределы работы самого счётчика строк) он продолжит работать правильно, но при этом управление счётчиком не будет влиять на этот кусок схемы, дополнительно тратя на это ресурсы. Именно так, длинные цепочки мультиплексоров (схема влияния ifоф) могут быть прилично сокращены и умение сформулировать логическую схему в этом как раз и помогает, о чём я уже говорил выше.

- - - Добавлено - - -

PS case в верилоге может объединять несколько значений под один begin/end блок, как и в С. Это бывает тоже необходимо.

- - - Добавлено - - -

PPS

Цитата:

---

Сообщение от omercury

if-elseif-else - они отрабатывают условия последовательно - сначала первое, потом второе и так далее до конца. На каждую обработку тратится время (задержка внутри компаратора и ключей, соединяющих всю требуху внутри ПЛИС в общую схему), на каждый цикл сравнения, а ведь все они находятся внутри тактового блока, и в конечном итоге задержка накопится до такой степени, что часть условий просто перестанет обрабатываться - на них тупо не хватит времени за период тактового сигнала, и это при в общем-то корректной схеме (IanPo тут прав, а неправ HardWareMan).

---

Если источник всех операторов if в каскаде един и внешний (т.е. данные сравнения в ifах не зависят друг от друга, а такое в 99% написанного кода) то все компараторы отработают одновременно. А вот уже их результат будет подан на цепочку мультиплексоров, задержка который всяко меньше полноценного компаратора (который в большинстве случаев всё равно преобразуется во многовходовый И). Причем, синтезатор с некоторой версии умеет их сворачивать в сбалансированное дерево, если логика схемы это позволяет - это тоже уменьшает задержку.

пример

Это:
https://jpegshare.net/images/c3/20/c...b9e9ce9c8d.png
Сворачивается в это:
https://jpegshare.net/images/8b/30/8...02c1684c8e.png

[свернуть]

- - - Добавлено - - -

PPPS Кстати, стэйт-машина, оформленная через case с некоторой версии синтезатора корректно распознаётся и сворачивается в компактную логику, причём RTL позволяет прям выделить этот блок. Я, правда, только один раз такое замутил, как-то не особо нужно было.

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

Цитата:

---

Сообщение от HardWareMan

omercury, а вот если бы ты оформил 2 параллельных ifа то они бы работали одновременно (одинаковая задержка) и "весили" бы минимально:

Код:

---

// Общий блок внутри begin/end
if (in1 & ~in2) begin ... end
if (~in1 & in2) begin ... end
// Конец общего блока

---

Вот эти два условия внутри одной пары begin/end будут работать одновременно и займут каждый по одному элементу 2И (инвертирование входа не является отдельным ресурсом) и будут управлять каждый своим begin/end.

---

Да именно так.
Но предыдущий if они таки подождут...

Цитата:

---

Сообщение от HardWareMan

Вложенные if/else нужны именно там, где они нужны, например в генераторе синхросигналов развертки VGA: на строке Х мы активируем кадровый импульс присвоив триггеру 1, а на строке Y, соответственно, снимаем. Причем, если его вынести "за скобки" (т.е. за пределы работы самого счётчика строк) он продолжит работать правильно, но при этом управление счётчиком не будет влиять на этот кусок схемы, дополнительно тратя на это ресурсы. Именно так, длинные цепочки мультиплексоров (схема влияния ifоф) могут быть прилично сокращены и умение сформулировать логическую схему в этом как раз и помогает, о чём я уже говорил выше.

---

case там тоже прекрасно отработает, ибо условий во-первых не так много, а, во-вторых, нет дублирующихся условий - все константы разные.

Цитата:

---

Сообщение от HardWareMan

PPS

Если источник всех операторов if в каскаде един и внешний (т.е. данные сравнения в ifах не зависят друг от друга, а такое в 99% написанного кода) то все компараторы отработают одновременно.

---

Нет, они будут срабатывать последовательно потому, что каждый последующий if должен проверить - сработал ли предыдущий.

Цитата:

---

Сообщение от omercury

Нет, они будут срабатывать последовательно потому, что каждый последующий if должен проверить - сработал ли предыдущий.

---

Ты пример в моём посте посмотри (я обновил, ты мог упустить), компараторы сработают одновременно. Результат будет отрабатываться согласно приоритета. А это несколько разные вещи (полноценный компаратор однозначно медленнее простого мультиплексора).

- - - Добавлено - - -

PS В примере, правда, все ifы равноправны, но даже если бы я их выстроил через else поменялся бы только порядок обработки результата на конкретно заданный мною, а не выбранный синтезатором. В примере приоритетно обрабатывается только 1 регистр, который общий для всех условий. Остальные события работают независимо друг от друга. Такой немного кривой пример, но суть и так понятна.

Цитата:

---

Сообщение от HardWareMan

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

---

Он процитирован, и кажется идентичным отображённому в посте.
Венрёмся к условию задачи:

Цитата:

---

Сообщение от omercury

2 сигнала, один из которых должен быть обработан в текущем цикле, но только один из них, независимо, пришли они раздельно или одновременно.

---

Валидные значения: 'b01, 'b10 и 'b11
Блок case, также, как и if/else, выполняет только одну ветку из всех условий, находящихся в блоке.
Чтоб сделать наглядней абсурдность ситуации, заменим <operators> на установку и сброс триггера.
блок

Код:

---

case (in)
2'b10 : reg <= 1'b1;
2'b01 : reg <= 1'b0;

---

обработает одно из двух валидных состояний, пропущено значение 'b11

блок

Код:

---

if(in1) reg <= 1'b1;
elseif(in2) reg <= 1'b0;

---

обработает один из 3х доступных вариантов
а что сделает это?

Цитата:

---

Сообщение от HardWareMan

Код:

---

// Общий блок внутри begin/end
if (in1 & ~in2) begin ... end
if (~in1 & in2) begin ... end
// Конец общего блока

---

---

- - - Добавлено - - -

Цитата:

---

Сообщение от HardWareMan

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

---

Тут собеседник-то не всегда понимает, а ты про синтезатор.

- - - Добавлено - - -

И вообще, о чём-то не о том мы...
Речь шла о том, что для разных ситуаций бывают удобными разные решения, а не о том, как выкрутиться из всех случаев каким-то одним.

Цитата:

---

Сообщение от HardWareMan

В конечном итоге, тем кто собрался всерьёз писать на xHDL я настоятельно советую изучать и цифровую схематехнику. Это позволяет описать будущую схему гораздо эффективнее.

---

Цитата:

---

Сообщение от HardWareMan

всегда заглядывайте в RTL, чтобы посмотреть как именно вас понял синтезатор

---

К этому добавлю ещё.

Заглядывать надо не только в RTL, но и в fitter, там тоже бывают неожиданные решения, но уже от оптимизатора.

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

Цитата:

---

Сообщение от omercury

Он процитирован, и кажется идентичным отображённому в посте.

---

Я там добавил спойлер с примером.

Цитата:

---

Сообщение от omercury

Вернёмся к условию задачи:

Валидные значения: 'b01, 'b10 и 'b11
Блок case, также, как и if/else, выполняет только одну ветку из всех условий, находящихся в блоке.
Чтоб сделать наглядней абсурдность ситуации, заменим <operators> на установку и сброс триггера.
блок

Код:

---

case (in)
2'b10 : reg <= 1'b1;
2'b01 : reg <= 1'b0;

---

обработает одно из двух валидных состояний, пропущено значение 'b11

блок

Код:

---

if(in1) reg <= 1'b1;
elseif(in2) reg <= 1'b0;

---

обработает один из 3х доступных вариантов
а что сделает это?

Цитата:

---

Сообщение от HardWareMan

// Общий блок внутри begin/end
if (in1 & ~in2) begin ... end
if (~in1 & in2) begin ... end
// Конец общего блока

---

---

Ровно то же самое, что и в твоём примере с case. 1 условие из двух. Ведь мы же хорошие мальчики и переносим сигналы условия в свой тактовый домен, верно? И у case точно такие же требования. Ну а чтобы модифицировать мой пример под твой пример, то надо описать вот так:

Код:

---

// Общий блок внутри begin/end
if (in1 & ~in2) begin ... end
if (~in1 & in2) begin ... end
if (in1 & in2) begin ... end
// Конец общего блока

---

Что касается твоего:

Код:

---

if(in1) reg <= 1'b1;
elseif(in2) reg <= 1'b0;

---

То он тоже обработает один из 2х доступных вариантов:
1. in1=1, тогда он по приоритету сработает и значение in2 проигнорируется.
2. in1=0, тогда проанализируется значение in2.
И согласись, это совсем не то, что ты описал как {1,0}:{0,1}:{1:1}. Это будет соответствовать вот такой таблице:

Код:

---

in1 in2 res
 1  x  #1
 0  1  #2
 0  0  --

---

Мой пример для этого будет выглядеть вот так:

Код:

---

// Общий блок внутри begin/end
if (in1) begin ... end
if (~in1 & in2) begin ... end
// Конец общего блока

---

В общем, следует понимать, что все условия на одном уровне в одном блоке обрабатываются одновременно. Но так как мы и так избавляемся от метастабильности (а кто не избавляется, то сам себе злобный буратино) то можно сказать, что case это лишь красивое описание группы таких условий. Причем даже твой случай в case можно описать как комбинация 2'b1x + 2'b01 и оно сработает. Т.е., в большинстве случаев case и группа if в одном блоке решение равноправное. А вот случаи, когда красивее то или иное решение есть. В случае с case это когда надо организовать условие с default. Надеюсь, не надо объяснять в чём сила этого самого default? А в случае с набором условий - да хоть мой пример выше. Или иногда надо организовать несколько значений, которые проще описать в виде логического уравнения, например (in1 | (in2 & ~in3)). Потому как это ведет к перечислению всех вариантов, которые попадают под эту формулу в одном условии case. А в случае данной формулы это будет целых 5 значений. Хотя, если константы именованы то case тупо нагляднее, о чём я и говорил: удобство для погромиста.

Ну таки посмотрим в RTL , попробую оценить сам а вы ткните если вру.







https://d.radikal.ru/d27/1909/72/f3f8acc6d556.jpg

pix_count - cчетчик вверх с параллельной загрузкой, со сбросом при значении 1056-1 - длина всей строки с со всеми причиндалами.




https://d.radikal.ru/d31/1909/31/f04df40a4d25.jpg


CASE(pix_count) - декодер hsync .
Вот это и есть то что HardWareMan описал - дешифратор на Equal и затем шифратор на NOR и OR ?

- - - Добавлено - - -

Да и , пробую симулировать в Modelsim , естественно пока только один этот модуль ,без PLL и HDMI, да и тестбенчи пока не готов писать , гружу вручную добавляю тактовую и вручную делаю сброс.
Все отображается и работает , почти все - кроме данных в vram. Как это исправить или Modelsim не грузит сторонние файлы?


https://c.radikal.ru/c39/1909/65/e1444c9287a7.jpg

https://b.radikal.ru/b25/1909/b3/d90a3bbba2ff.jpg

Цитата:

---

Сообщение от dosikus

https://d.radikal.ru/d27/1909/72/f3f8acc6d556.jpg
pix_count - cчетчик вверх с параллельной загрузкой, со сбросом при значении 1056-1 - длина всей строки с со всеми причиндалами.

---

Это не синхронный дизайн здорового человека. У тебя MUX21 и так делает нормальное синхронное обнуление на шаге h4F1 = 1055. Так зачем этот асинхронный сброс?

- - - Добавлено - - -

И еще, ты старайся указывать размерность жгута. Ато он у тебя расширяется до стандартных 32 бит. Понятно, что фиттер потом урежет до используемого количества, но чётко указанная размерность делает схему в RTL чище.

Цитата:

---

Сообщение от HardWareMan

Это не синхронный дизайн здорового человека. У тебя MUX21 и так делает нормальное синхронное обнуление на шаге h4F1 = 1055. Так зачем этот асинхронный сброс?

---

Наверняка он здесь :
always @( posedge clk_in or negedge reset )
begin
if (!reset) begin
line_count <= 0; // On a reset, restart counters from 0
pix_count <= 0;
v_addr <=0;
end else begin

Цитата:

---

Сообщение от HardWareMan

И еще, ты старайся указывать размерность жгута. Ато он у тебя расширяется до стандартных 32 бит. Понятно, что фиттер потом урежет до используемого количества, но чётко указанная размерность делает схему в RTL чище.

---

А это скорей всего я внес здесь :

localparam integer H_ACTIV = 800;
localparam integer V_ACTIV = 600;

Ибо рассчитывал адресc vram - H_ACTIV*V_ACTIV, синтез мне обрезал результат до 16бит.
Потом расчет переделал на v_addr <= ((pix_y*800)+pix_x);
и про то забыл..

Цитата:

---

Сообщение от dosikus

Наверняка он здесь :
always @( posedge clk_in or negedge reset )
begin
if (!reset) begin
line_count <= 0; // On a reset, restart counters from 0
pix_count <= 0;
v_addr <=0;
end else begin

---

А, ну да. Для полностью синхронного дизайна никогда не используй список чувствительности более одного сигнала. Для этого тебе следует сделать вот так:

Код:

---

reg [1:0]SynRes;
always @( posedge clk_in )
begin
  // Синхронизация сброса
  SynRes[1:0] <= {SynRes[0],reset};
  if (SynRes[1] & ~SynRes[0]) begin // Либо так: if (SynRes[1:0] == 2'b10) begin
      line_count <= 0;          // On a reset, restart counters from 0
      pix_count <= 0;
      v_addr <=0;
  end else begin

---

2 бита это если нужно отловить конкретно перепад, здесь я отлавливаю 1 => 0. Если перепад не нужно (сработка по уровню), то достаточно одного бита, главное это засинхронизировать его (перенести в текущий тактовый домен). В идеале, список чувствительности блока always должен содержать только тактовый сигнал, причем либо posedge, либо negedge. И не обязательно мастерклока. Т.е., если ведомый блок always у тебя не имеет перекликания с другими always блоками, то его тактовая может быть выходом триггера предыдущего блока. Но это уже с опытом придёт.

И ещё, обязательно усвой разницу инверсии между ~ и !. Она принципиально разная.

Стало :

https://b.radikal.ru/b21/1909/18/d8297ca84942.jpg

Ай, красиво. А что сказал time_quest? Какой получился fmax?

Угу, еще бы я им пользоваться умел ...

Цитата:

---

Сообщение от dosikus

А это скорей всего я внес здесь :

localparam integer H_ACTIV = 800;
localparam integer V_ACTIV = 600;

Ибо рассчитывал адресc vram - H_ACTIV*V_ACTIV, синтез мне обрезал результат до 16бит.
Потом расчет переделал на v_addr <= ((pix_y*800)+pix_x);
и про то забыл..

---

Это автоматом проще рассчитывается:

Код:

---

parameter hcnt_Width = $clog2(LINE_END);                        //Ширина горизонтального счётчика, вычисляемое
parameter hAct_Width = $clog2(H_ACTIV);                        //Ширина шины адреса по горизонтали, вычисляемое
parameter vcnt_Width = $clog2(FRAME_END);                        //Ширина вертикального счётчика, вычисляемое
parameter vAct_Width = $clog2(V_ACTIV);                        //Ширина шины адреса по вертикали, вычисляемое
parameter VRAM_Width = vAct_Width + hAct_Width;        //Ширина шины адреса памяти, вычисляемое

reg pix_count [hcnt_Width-1:0] = 0; // Горизонтальный счетчик
reg line_count [vcnt_Width-1:0] = 0; // Вертикальный счетчик

wire [VRAM_Width-1: 0] VRAM_Addr = {line_count [vAct_Width-1:0], pix_count [hAct_Width-1:0]);

---

Когда наводишь мышь в окне проект манагера на какой-либо модуль, в тултипе Квартус показывает значения parameter.
localparam не показывает(((

Цитата:

---

Сообщение от dosikus

Угу, еще бы я им пользоваться умел ...

---

В простейшем случае ничего особо и не надо.
В Compilation Report в окне Table of content найди в дереве TimeQuest Timing Analiser и выбери в нём медленные модели.
Что-то он там по-любому наанализировал...
Вложение 70073

Олег, ок порядок наведем, счас затык в другом - ранее как и писал - может сделаем знакогенератор ?

omercury, нужно только SDC файл создать, со требуемой частотой.

dosikus, вот у тебя pix_count только либо обнуляется, либо считает в плюс, верно?
https://b.radikal.ru/b21/1909/18/d8297ca84942.jpg
А ты вынеси его за скобки, типа вот так:

Код:

---

reg [1:0]SynRes;
always @( posedge clk_in )
begin
  // Синхронизация сброса
  SynRes[1:0] <= {SynRes[0],reset};
  // Счетчик пикселей
  if ( (SynRes[1] & ~SynRes[0]) | (pix_count == h41F) ) pix_count <= 0; else pix_count <= pix_count + 1;
  // Остальная логика
  if (SynRes[1] & ~SynRes[0]) begin // Либо так: if (SynRes[1:0] == 2'b10) begin
      line_count <= 0;          // On a reset, restart counters from 0
      v_addr <=0;
  end else begin

---

И посмотри, какая красота появится в твоём RTL (только поправь настоящие константы и размерности, я там просто что-бы понятно было написал). Суть посыла такая: синтезатор, к сожалению, не умеет объединять некоторые события сам, справедливо полагая, что они имеют некоторый приоритет, описанный программистом. Однако, схемотехник сразу скажет - тут и тут лишнее, можно упростить. И если ты знаешь что и как - это не сложно объяснить синтезатору. Основная цель - сократить число управляющих цепей. В данном случае цепь сброса счётчика pix_count может быть объединена с цепью обнуления при счёте. Желательно всегда стремиться к уменьшению вложенности управляющих цепей (это те, которые условия), а так же стараться объединять цепи, ведущие к одному результату.

А в целом, тут ситуация как с блок-схемами алгоритма при обычном программировании - все настойчиво игнорируют этот момент, а потом получают спагетти-код. А ведь описать код по блок-схеме реально быстро и просто, я пробовал. Правда, в институте, когда на кафедре АСУ учился. :)