../../rtl/common/cs_gen.v:8: error: Concatenation repeat may not be negative (-2).

[jahagirdar]

I am getting the above error message while running make.
Note: I am not using the docker image,

The complete log is as follows

master ✗ f3a9d8a 807d △ ➜ make keynsham
[ 33%] Built target gendefines
[100%] Built target generate
../../rtl/common/cs_gen.v:8: error: Concatenation repeat may not be negative (-2).
1 error(s) during elaboration.
verif/icarus/CMakeFiles/keynsham.dir/build.make:57: recipe for target 'verif/icarus/CMakeFiles/keynsham' failed
make[3]: *** [verif/icarus/CMakeFiles/keynsham] Error 1
CMakeFiles/Makefile2:400: recipe for target 'verif/icarus/CMakeFiles/keynsham.dir/all' failed
make[2]: *** [verif/icarus/CMakeFiles/keynsham.dir/all] Error 2
CMakeFiles/Makefile2:412: recipe for target 'verif/icarus/CMakeFiles/keynsham.dir/rule' failed
make[1]: *** [verif/icarus/CMakeFiles/keynsham.dir/rule] Error 2
Makefile:240: recipe for target 'keynsham' failed
make: *** [keynsham] Error 2

[jamieiles]

This doesn't reproduce for me using the latest master and the oldland-buildenv docker image. The repetitions in question are created from the yaml configs (check the various *_defines.v in the config subdir inside the build directory). It might be that the yaml wasn't processed correctly if you haven't changed anything - do you have any errors earlier in the build for missing tools perhaps?

[jahagirdar]

Debugging the verilog I suspect code like what we have in keynsham_irq might be the problem.
parameter bus_address = 32'h0;
parameter bus_size = 32'h0;

cs_gen #(.address(bus_address), .size(bus_size))
d_cs_gen(.bus_addr(bus_addr), .cs(bus_cs));

This will in cs_gen.v set
cs_mask_bits to 32
resulting in the 32-cs_mask_bits -2 on the next line to evaluate to 32-32-2 i.e. -2
resulting in the expression reducing to {32{1'b1},-2{1'b0}}
Which is what the linter is complaining about.

Am I missing something?

[jahagirdar]

Ah! I did not see your reply while composing my message.

1. Cmake went through without any error.
2. The *_defines.v are generated properly.
   My git checkout is not in /data/.... It is in a local home folder...

[jamieiles]

cs_mask_bits will only be 32 if the chip select covers the whole 32 bits and that doesn't happen anywhere, most are only around 4KB. When you say that the defines are generated correctly, are the contents valid e.g.:

`define SDRAM_CTRL_SIZE 32'h1000

which should give cs_mask_bits of 12.

[jahagirdar]

Yes, I am seeing the following

data/oldland/oldland-cpu/BUILD/config/sdram_ctrl_defines.v:`define SDRAM_CTRL_SIZE 32'h1000
data/oldland/oldland-cpu/BUILD/config/sdram_ctrl_defines.h:#define SDRAM_CTRL_SIZE 0x1000

[jamieiles]

Okay, that's normal. Check the other defines and see if there is an unexpectedly large or small size. Knowing which instance of cs_gen this is occurring for will make it easier to debug.

[jahagirdar]

Other than the SDRAM size other numbers look ok.
config/bootrom_defines.v:define BOOTROM_SIZE 32'h4000 config/irq_defines.v:define IRQ_SIZE 32'h1000
config/keynsham_defines.v:define ICACHE_SIZE 8192 config/keynsham_defines.v:define ICACHE_LINE_SIZE 32
config/keynsham_defines.v:define DCACHE_SIZE 8192 config/keynsham_defines.v:define DCACHE_LINE_SIZE 32
config/ram_defines.v:define RAM_SIZE 32'h1000 config/sdram_ctrl_defines.v:define SDRAM_CTRL_SIZE 32'h1000
config/sdram_defines.v:define SDRAM_SIZE 32'h2000000 config/spimaster_defines.v:define SPIMASTER_SIZE 32'h4000
config/timer_defines.v:define TIMER_SIZE 32'h1000 config/uart_defines.v:define UART_SIZE 32'h1000

config/bootrom_defines.v:define BOOTROM_ADDRESS 32'h10000000 config/irq_defines.v:define IRQ_ADDRESS 32'h80002000
config/ram_defines.v:define RAM_ADDRESS 32'h0 config/sdram_ctrl_defines.v:define SDRAM_CTRL_ADDRESS 32'h80001000
config/sdram_defines.v:define SDRAM_ADDRESS 32'h20000000 config/spimaster_defines.v:define SPIMASTER_ADDRESS 32'h80004000
config/timer_defines.v:`define TIMER_ADDRESS 32'h80003000

[jamieiles]

That all looks fine to me and I can't reproduce it here so you might need to try minimising the design to find out where it's going wrong.

[jahagirdar]

Ok. I will try to debug this further...
What I have tried till now is.

I ran Make with --trace option and it failed on this command

cd /prj/dyumnin/designw.in/hdl/BUILD/data/oldland/oldland-cpu/verif/icarus && BUILD_DIR=/prj/dyumnin/designw.in/hdl/BUILD/verif/icarus iverilog -Wall -Wno-sensitivity-entire-array -I/prj/dyumnin/designw.in/hdl/BUILD/verif/icarus -I/prj/dyumnin/designw.in/hdl/BUILD/verif/icarus/../../config -DOLDLAND_ROM_PATH="/usr/local/lib/" -c /prj/dyumnin/designw.in/hdl/BUILD/data/oldland/oldland-cpu/verif/icarus/oldland.cf -o /prj/dyumnin/designw.in/hdl/BUILD/verif/icarus/keynsham.vvp
../../rtl/common/cs_gen.v:10: error: Concatenation repeat may not be negative (-2).

I next tried generating the output of the preprocessor (-E flag) and checked the size values passed to the modules instantiated in keynsham_soc module. These look ok.

I tried constructing my own .cf file using the preprocessor output and iverilog was able to compile it.

So the next step would be figuring out why it works with the preprocessor output and not with the original code.

[jahagirdar]

I think I found it, iverilog see's 2 toplevel modules cpu_tb and simuart. simuart has a cs_gen instance at the toplevel which causes this problem.
A solution could be passing the -s cpu_tb flag to the iverilog commandline.