Мой «Hello World!» на FPGA или очередная версия UART

Можете пояснить, как работает ваш Мажоритарный элемент? Т.е. от каких ошибок от избавляет.

Блокирующие присваивания внутри тактируемого блока? Это грубая ошибка.

Я про вот этот кусок, например:


Чтобы понять что не так, посмотрите доклады Каммингса (один из разработчиков стандарта SystemVerilog, а именно так называется язык с 2009 года).
Или вот этот замечательный материал из университета Berkeley (сразу предупреждаю, их материал про конечные автоматы устарел — их следует писать в одном always блоке, а не в двух или трёх)

В Verilog есть комбинаторные блоки и тактируемые.
Круглые скобки после always @ — это список чувствительности (при изменении сигналов, описанных там, сработает блок). Если там стоит posedge или negedge, то блок будет тактируемым (фронтом или спадом соответственно; если и то, и другое, то DDR). Если просто имена сигналов или *, то комбинаторным (и будет срабатывать при любом изменении перечисленных сигналов). Reg может быть как в комбинаторном, так и в тактируемом блоке, а сам тип логики он не определяет. С типом wire можно использовать только assign, но не = или <=. Вообще reg и wire это дурные путающие абстракции, поэтому в SystemVerilog ввели универсальный тип logic.
Тактируемые:

always @ (posedge clk) begin
    a <= b;
end

Внутри этих блоков можно использовать ТОЛЬКО <= без всяких но и если.

Комбинаторную логику (которая срабатывает «мгновенно», а на самом деле со скоростью распространения сигнала, которая зависит от разводки) можно описать двумя способами:

assign a = b & (c > 0); // здесь a должен быть wire

ИЛИ

always @ (*) begin
    a = b & (c > 0); // здесь a должен быть reg
end

Здесь в списке чувствительности (в круглых скобках) можно записать значения сигналов через запятую, но лучше ставить *, тогда список чувствительности будет формироваться автоматически (туда будут включены все сигналы, от изменения значения которых может измениться состояние блока, т.е. все правые части присваиваний, условия при if и т.д.), а вручную его формировать ТОЛЬКО если нужно исключить какой-то сигнал оттуда.
В комбинаторных блоках ТОЛЬКО блокирующие присваивания.

Больше никаких конструкций в Verilog нет. <= в комбинаторных блоках или = в тактируемых — это или не имеющая смысла чепуха в первом случае или грубейшая ошибка во втором и так писать нельзя никогда.

P.S. Писать = внутри тактируемого блока можно. Если вам нужен генератор псевдослучайных чисел.

Поздравляю! Много разработчиков на FPGA когда-то писали свой UART)))

Вы можете перестать занимать PLL, решить вопрос «чтобы не завязавать скорость последующей обработки данных на скорость обмена по UART» и убрать мажоритарную логику и FIFO для данных. И сделать более практичное применение. Просто тактируете модуль частотой обработки данных, а в его параметрах прописываете значение частоты и скорости по UART. Из частоты и скорости можно получить длину счётчика бита UART. Упал Rx, включился счётчик. Дребезг по входу уже будет неважен. Хотя по идее в нормальных условиях и при правильно спроектированной схеме его и не должно быть — сигнал с RS232 надо заводить на FPGA через буфер. Досчитал счётчик до середины — считали бит. Сбрасываем счётчик и отсчитываем бит. Читаем. И так — весь байт. Бита чётности у вас нет, значит потом будет стоп-бит, на середине которого можно проверить его уровень и сбросить счётчик, опять начав ожидать старт-бит — таким нехитрым образом на каждом байте будет осуществляться тактовая подстройка приёма в FPGA под передатчик в ПК.

Искренне поздравляю! В нашем полку прибыло! :)))
Я тоже начинал в своё время именно с uart. Более того, любой мой проект начинается с того, что я копирую в него uart. И в дальнейшем подключаю к нему всю отладку и тестирование проекта. Исключительно удобная штука.

Для первого HDL-кода выглядит вполне недурно.

По поводу частоты семплирования:
UART является асинхронным интерфейсом — без передачи синхросигнала и без восстановления частоты из данных. Скорость передачи данных по сути «оговаривается» заранее, определить её из потока данных довольно проблематично.
Но даже если оба устройства знают на какой частоте они обмениваются данными, данные частоты всё равно не будут идентичными. Во-первых, в каждом устройстве в общем случае будет свой источник тактирования (кварц, генератор, что угодно), имеющий внутренний дрифт. Во-вторых, часто невозможно получить целочисленное деление тактовой частоты для подходящего baud rate в UART: контроллер например работает на 24МГц, а чтобы получить 115200, нужно 24МГц разделить на 208.(3).
В общем к чему это я всё — семплировать входящие данные лучше на как можно большей частоте. К примеру, распространённым механизмом является работа приёмника на частоте x16: по заднему фронту входного сигнала (начало старт-бита) отсчитываем 8 тактов, попадая таким образом на середину бита; далее через каждые 16 тактов читаем значение входного бита. С точки зрения частотной ошибки мы можем себе позволить расхождение по частоте на ±8 периодов нашей частоты семплирования (т.к. точка семплирования в таком случае выпадет за пределы бита), и соответственно на ±1 период частоты семплирования на бит.
На первом такте при начале старт-бита мы заведомо не знаем попал ли наш отчёт ровно на задний фронт или нет, точность этого — как раз один период частоты семплирования. Соответственно при более низкой частоте (как х4 в вашем случае) стартовая ошибка может быть больше, а запас по отклонению частот — меньше.

По поводу использования блокирующих и неблокирующих присваиваний:
«Идеологически правильный» код потенциально может привести к формированию защёлок (latch) в синтезе: блок always @(*) комбинаторный, следовательно для каждого из сигналов, используемых в левой части присвоений, должны быть описаны все условия ветвления. В данном примере это обходится (возможно, по счастливой случайности) наличием блокирующих присваиваний сигналов перед ветвлениями, что по сути станет неявным присваиванием во всех ветвлениях, где это не описано явно. Примерно так развернутся эти присваивания:

always @(*)
begin
	if(nreset) begin
		if(div4 == 2'd0) begin
			case(s)
				4'd0: begin
						sendstart = 1'b1;
						canfetch = 1'b0;
					end
				4'd9: begin
						sendstart = 1'b0;
						canfetch = wr;
					end
				4'd10:
					begin
						sendstart = 1'b0;
						canfetch = wr;
					end
				default:
					begin
						sendstart = 1'b0;
						canfetch = 1'b0;
					end
			endcase		
		end else begin
			sendstart = 1'b0;
			if(s < 4'd9) begin
				canfetch = 1'b0;
			end
			else begin
				canfetch = wr;
			end
		end
		
		if(canfetch && idle) begin
			sendstart = 1'b1;
		end
		else begin
			sendstart = 1'b0;
		end
	end else begin
		sendstart = 1'b0;
		canfetch = 1'b0;
	end
end	

Собственно, если бы присваивания были неблокирующими, ваш вариант скорее всего работал бы некорректно (не помню как в Verilog, но в VHDL повторное неблокирующее присваивание в блоке считается ошибкой).
Вне зависимости от того, блокирующие у нас присваивания или неблокирующие, пропуск одной из веток приведёт к тому, что синтезатор не будет знать, что ему делать с сигналом в данном условии, и примет решение создать элемент памяти. Но т.к. в блоке не указаны фронты (а то и вообще комбинаторный список чувствительности), будет установлена защёлка. Мета-пример подобной ситуации:

always @(*)
begin
	if(nreset) begin
		if(canfetch) begin
			sendstart = 1'b1;
		end
	end else begin
		sendstart = 1'b0;
	end
end	

Что должно происходить с сигналом sendstart при nreset == 1 и canfetch == 0? Выходит, что он должен сохранить своё текущее состояние. Но для этого нужен элемент памяти, т.к. ситуация невозможна, если использовать только комбинаторные элементы.

Вот мне совершенно не нравиться «идеологически правильный» код передатчика. Как уже писали выше это потенциальный источник ошибок. На мой взгляд лучше использовать конструкцию always (@postedge clk) и внутри описывать нужную логику.