I would recommend your outputs be flops. It would be a cleaner output signal and easier to do timing analyses. It takes time (few nano seconds) to calculate the tx value after the clock with combinational logic. During that time the intermediate values are being transmitted and causing noise. This noise will can get worse from resistance an capacitance in ...
I would recommend a using modern Verilog header:
output reg prescaledCLK
adding bit size to your constants is best practice. 'b0 for all zeros with auto sizing. 0 is an integer likely only 32 bits long which can get you in trouble if you start applying to regs bigger than than 32 bits.
The use of initial ...
non-blocking one, which is better for sequential circuits.
It is not better per-se but it is the correct way to simulate a flip-flop.
always @* begin
a = b;
always @(posedge clock) begin
a <= b ;
In the examples above nothing would go wrong if you used the wrong type but think about
always @(posedge clock) ...
As with all questions on codereview, some of the comments below is just opinion and there are always several ways of doing things. However my personal style preferences have evolved over many years of debugging my own (and other people's) code!
First some style comments on the code itself:
always@(posedge m_axi_clk) begin
Unless you're stuck with very ...
Let's start with your imports. You should get rid of those you don't need, e.g. System.IO, import Data.Either.Extra (fromRight). Next, you shouldn't mix integral and floating point calculations, unless you're fine with imprecise results. For example, integerLog will give the wrong answer around 1024:
ghci> integerLog (2^1023)
ghci> integerLog (2^...
I'm no Verilog expert. However, it's clear that if you just keep adding 1 to a 4-bit counter and letting it wrap around, then prescaledCLK would just be the most significant bit of counter. You should be able to eliminate the conditional, I think.
Why are the inputs signed, are you working with negative dimensions?
Most FPGAs have dedicated logic for multiplication so you usually can simply write x*y without having any issues. For better or worse, manually writing it out like you did could impact optimization. Be aware your multiply truncates most of the MSB bits. An 8-bit times 8-bit input would ...
From a style/best practice your code looks pretty good. The only glaring error is that your module multiflipflop_ack is missing port directions.
output wire dout, // Was 'wire', could also be 'output logic'
input clk_in, // Was 'wire'
input clk_out // Was 'wire'
From a design perspective I see one issue in LogicUnit. Out is an inferred latch because it is not assigned in all conditions of Op. The risks associated with these latches and how to use them property (when needed) have already been discussed on other Stack Exchange sites; such as here on Electrical Engineering Stack Exchange and here on ...
For the design
The biggest issues with your code is out is an inferred latch because the condition f == 3'b011 is undefined. This type of latch is not ideal as they can cause area and timing issues. To remove the latch, simply assign out to a determinate value; out = a, out = b, out = 0, or other constant (not out = out which is still a latch).
Have I made any rookie mistakes or committed major sins against Verilog style?
Overall it is coded very well and easy to read, no Verilog sins (unlikely to synthesize if there were). Clean Verilog-2001 syntax utilizing ANSI style header and @*.
The only potential error I could spot (without building a testbench) is with f_pc, regs, e_*, and most d_* ...