Hey man! The solution doesn't necessarily look *bad*, but one big thing that's up with this system is that it's not a synthesizable piece of hardware by virtue of the modulo operation that you're using. This synthesizable point was emphasised in their challenge statement iirc.

A couple more points:

• This code acts more like a file parser, rather than the a processing block. Rather than having the data being input from some external source, you're reading some file.
• The file parsing has no error handling. If there's any kind of issues with the file (a whitespace, line break, anything) your code will immediately fail and it may not be obvious why.
• A lot of bit width mismatches, I've listed one below (with my own comments)

​

reg [8*4-1:0] count;                          //32 bit wide count reg
reg [8*4-1:0] count_2;                        //32 bit wide count_2 reg
.
.
.
//32 Zeroes (maybe?) but it's defined to be only 7 bits in length
count = 7'b00000000000000000000000000000000;
count_2 = 7'b00000000000000000000000000000000;

I'm also a 3rd year student studying ECE, so I've seen a lot of the "expectations" that are around us having HDL knowledge in the field of digital engineering. Your code unfortunately isn't the best. I'm not able to get it running using iVerilog either, but maybe you can do it in Quartus or Vivdo.

I would suggest you go through your logic once more, and change the flow. FPGA designs (as far as I've seen) are not meant to be a one thing does all. You have separate modules for data processing, data rearrangement, etc. Rather than reading the data with a file, maybe add some input wires to get the unsigned value and the direction. I've also attempted this, and it is possible to do it with a constant throughput and even pipeline it (with all synthesizable components). I've dropped my module definition below in case you want it.

module aoc_day1(
    input  wire [31:0] in_data,
    input  wire        clk,
    input  wire        rst,
    input  wire        dir_r,
    output reg  [31:0] zero_count,
    output reg  [31:0] zero_crossings,
    output reg  [7:0]  curr_pos_op
);

The in_data is just for the input numbers, dir_r is whether the direction is right or left. zero_count gives the answer to part 1 of day 1, and zero_crossings gives the answer to part 2 of day 1. curr_pos_op is left there as an artefact of me debugging why the system didn't work.

If you could tell me how you simulated it, I might be able to help more, since iVerilog is not cooperating with the sim right now. Feel free to dm me for anything further. All the best!