The romulator FPGA image doesn't always meet timing when minor modifications are made to the verilog code.

[dennowiggle]

I found that when modifying FPGA verilog code that even though the code builds correctly without errors using the provided tools and scripts it doesn't always run correctly. Sometimes even removing a few lines of non-called verilog code will result in the FPGA going from working to not functioning at all, or partially functioning. Such as random spi errors causing partially missing data and a distorted image on canvas.html web page.

After going around in circles for many days I found that the recompiled verilog images likely did not meet timing despite no warning.

The installation instructions and script provided forces apio version 0.5.4 and uses the FPGA tools and versions assigned to this apio version. In windows subsystem for linux later versions of apio and tools will build the romulator image but with timing errors. (Note, only Raspberry Pi 64bit OS is supported in the newer tools for those using that for synthesizing/placing/routing). I upgraded to apio version 0.8.1 in WSL debain and timing errors are reported with this latest version. For example :

"ERROR: Max frequency for clock 'romulator.clk': 34.93 MHz (FAIL at 48.00 MHz).

Changing the clk clock frequency from 48MHz to 24MHz resolved the timing error reported by the packages in apio 0.8.1 and converted non-working code built by apio tools installed on version 0.5.4 to working.

I made the following clock change to the verilog code in enable_logic.v :

Change line from :
SB_HFOSC #(.CLKHF_DIV ("0b01")) inthosc(.CLKHFPU(1'b1), .CLKHFEN(1'b1), .CLKHF(clk));
to
SB_HFOSC inthosc(.CLKHFPU(1'b1), .CLKHFEN(1'b1), .CLKHF(clk));

[dennowiggle]

I still have apio version 0.5.4 installed on my Raspberry Pi. I synthesized the original FPGA verilog code from github and then ran a timing analysis with the command "apio time" that showed a max clock of 21MHz. This was the output.

[Sun Dec 11 08:11:36 2022] Processing upduino

icetime -d up5k -P sg48 -C "/home/pi/.apio/packages/toolchain-ice40/share/icebox/chipdb-5k.txt" -mtr hardware.rpt hardware.asc
// Reading input .asc file..
// Reading 5k chipdb file..
// Creating timing netlist..
Warning: timing analysis not supported for cell type HFOSC
// Timing estimate: 46.01 ns (21.74 MHz)
================================================================= [SUCCESS] Took 8.01 seconds =================================================================

I did play with the Lattice tool Radiant. Unfortunately Lattice & Synplify tools do not support initial conditions, despite the FPGA and yosys supporting them, so I can't generate a functional image to compare like with like. However I did see that Radiant also cannot meet timing and that the CRC32 design is where the critical timing path is. Another approach to generating CRC32 might improve timing there but lowering the clock to 24MHz and using the latest apio also works.

Hope that helps.

[dennowiggle]

While VRAM reads work now, this was in standalone mode (not plugged into the computer). When romulator is plugged into the computer the computer no longer works. I'm guessing timing of the address/data bus is messed up.

I will try and take a look in the week and learn about PLL's to see if they could be a solution. Perhaps constraints might help......

[dennowiggle]

A 24Mhz clock does work and meet timing if I back out the typo changes in "spi_flash_reader.v" detailed in thread for issue #19
#19 (comment)

My test computer is an Apple IIe which boots, runs code, and displays a 40 column mode remote screen on canvas.html with other changes I am playing with.

A more thorough approach to cleaning up the typo's in "spi_flash_reader.v" is still needed.......... [EDIT: ...Now done]