Build break one servant_ram i_wb_rst

[tomverbeure]

I'm running corescore straight out of the box with a clean install. (Or at least, I think it's clean, because the whole dependency chain is very opaque to me.)

I get the following error:

fusesoc run --target=intel_max10_devkit corescore
...
Error (12002): Port "i_wb_rst" does not exist in macrofunction "ram" File: /home/tom/projects/corescore_ws/build/corescore_0/src/corescore_0/rtl/emitter.v Line: 128

In ~/projects/corescore_ws/build/corescore_0/src/corescore_0/rtl/emitter.v, I indeed see the following:

   servant_ram
     #(.memfile (memfile),
       .depth (memsize))
   ram
     (// Wishbone interface
      .i_wb_clk (i_clk),
      .i_wb_rst (i_rst),              <<<<<<<<<<<<<<
      .i_wb_adr (wb_mem_adr[$clog2(memsize)-1:2]),
      .i_wb_cyc (wb_mem_cyc),
      .i_wb_we  (wb_mem_we) ,
      .i_wb_sel (wb_mem_sel),
      .i_wb_dat (wb_mem_dat),
      .o_wb_rdt (wb_mem_rdt),
      .o_wb_ack (wb_mem_ack));

And in /home/tom/projects/corescore_ws/build/corescore_0/src/serving_1.0.2/serving/serving_ram.v, I see:

module serving_ram
  #(//Memory parameters
    parameter depth = 256,
    parameter aw    = $clog2(depth),
    parameter memfile = "")
   (input wire          i_clk,
    input wire [aw-1:0] i_waddr,
    input wire [7:0]    i_wdata,
    input wire          i_wen,
    input wire [aw-1:0] i_raddr,
    output wire [7:0]   o_rdata,

    input wire [aw-1:2] i_wb_adr,
    input wire [31:0]   i_wb_dat,
    input wire [3:0]    i_wb_sel,
    input wire          i_wb_we,
    input wire          i_wb_stb,
    output wire [31:0]  o_wb_rdt,
    output reg          o_wb_ack);

There is, indeed, no i_wb_rst to be seen in serving_ram. There is also no i_wb_rst in the serving_ram repo.

So how can this possible have ever worked before??? I really want to love fusesoc, but every time I get near it, I get hit with incomprehensible dependency issues.

Tom

[tomverbeure]

Note to self...

To work around this:

• Create local copy of corescore repo:

  cd ~/projects
  git clone https://github.com/olofk/corescore.git
  cd corescore

• Edit ./rtl/emitter.v: comment out i_wb_rst on line 121

• create local workspace:

  mkdir workspace
  cd workspace

• Add fusesoc-cores

  fusesoc library add fusesoc-cores https://github.com/fusesoc/fusesoc-cores

  Don't do: fusesoc library add corescore https://github.com/olofk/corescore !!!

• Now run fusesoc with link to local copy of corescore, which is simply the directory right above the current one:

  fusesoc  --cores-root=../ run --target=intel_max10_devkit  corescore

[tomverbeure]

Ok. So it turns out that there are 2 serving_ram.v files: one under ./serving and one under ./servant.

The one under ./servant has i_wb_rst, but the one under ./serving does not.

I don't know what the best solution here, so I'll leave that to you, @olofk.

Tom

[olofk]

Thanks for reporting. This was fixed in the main branch of the serv repo a while ago but there was never a new release after that. I fixed it now by adding a servant 1.0.2-r1 to the fusesoc-cores library.

If you run fusesoc library update fusesoc-cores you should hopefully get the new version. Verify by checking with fusesoc core list that the core exists and that it shows up as a dependency in the fusesoc output when you run corescore

[olofk]

And I'm sorry about the issues you've encountered. Wanted to add also that your workaround is the correct and intended way of dealing with bugs or other issues in some dependency of your toplevel. A minor note is that it actually is ok in this situation to run fusesoc library add corescore https://github.com/olofk/corescore because the libraries you specify with --cores-root have higher priority than the ones in fusesoc.conf

Also, when I'm confused about which core is being picked up by fusesoc I generally run fusesoc core show <core> and look at the core root to see which version is used

[tomverbeure]

Got it!

I'll retry to check everything is working now once I get the chance, and then I'll close.

Thanks! Tom

[tomverbeure]

Things verified to be working now. Thanks!