Cu + Ft "Unknown port name" and Yosys Failures (V2)

Help Request
1

Hello -

I’m trying a fresh, new project with 2.0.32 and am having issues that I don’t understand.

(Note I’m using the V2 boards.)

My setup is the Cu with the Yosys toolchain. Project zip file is attached.

Well, the project is simple enough. Cu + Ft, basic hookups.

I get two odd errors.

From the “ft_plus_v2.acf”:

  • Warning at line 4 offset 8: Unknown port name “ft_wakeup”. This constraint will be ignored.
  • Warning at line 5 offset 8: Unknown port name “ft_reset”. This constraint will be ignored.

They are warnings, I can live with them. But I’m a little concerned that the “ft_reset” line is not hooked up any “rst” signal, nor can it be!

The next is when I try and build the project using yosys, I get the following:

Refusing to write adjacent to "/path-to/Projects/alchitry/n00b/build/source/simple_dual_port_ram.v" because that path does not end in ".sv"
sv2v exited with status: 1

Howver, “simple_dual_port_ram.v” is added automatically as part of the “ft.luc” module.

Are these bugs, or just symptoms showing that I don’t know what I’m doing?

To reproduce:

  • Create a new Cu V2 project (blinker.luc)
  • Set the toolchain to “Yosys”
  • Add the Ft+ module
  • Add the Ft+ constraints
  • Use the following for “alchitry_top.luc”
module alchitry_top (
    input clk,              // 100MHz clock
    input rst_n,            // reset button (active low)
    output led[8],          // 8 user controllable LEDs
    input usb_rx,           // USB->Serial input
    output usb_tx,          // USB->Serial output
    input ft_clk,
    input ft_rxf,
    input ft_txe,
    inout ft_data[32],
    inout ft_be[4],
    output ft_rd,
    output ft_wr,
    output ft_oe

) {
    
    sig rst                 // reset signal
    
    .clk(clk) {
        reset_conditioner reset_cond
        .rst(rst) {
            blinker my_blinker
        }
    }
    
    always {
        reset_cond.in = ~rst_n     // input raw inverted reset signal
        rst = reset_cond.out       // conditioned reset
    }
    
    always {
        led = 8x{my_blinker.blink} // blink LEDs
    }
    
    always {
        usb_tx = usb_rx // echo the serial data
    }
    
    ft usb3(#BUS_WIDTH($width(ft_data)),.clk(clk),.rst(rst),.ft_clk(ft_clk),.ft_be(ft_be),.ft_data(ft_data))
    
    always {
        ft_rd = usb3.ft_rd
        ft_wr = usb3.ft_wr
        ft_oe = usb3.ft_oe
        usb3.ft_rxf = ft_rxf
        usb3.ft_txe = ft_txe
    }

    always {
        // FIXME just hook these up for now
        usb3.ui_din = $width(ft_data)x{1bz}
        usb3.ui_din_be = $width(ft_be)x{1bz}
        usb3.ui_din_valid = 1bz
        usb3.ui_dout_get = 1bz
    }

}

Any help would be appreciated, thank you!

n00b.zip (10.0 KB)

2

The first issue is a mistake, the second is a bug.

The new Ft boards also have reset and wakeup lines. Set them to 1 if you don’t plan to use them. See the Ft example project for an example. (It’s also built into Labs as a template)

The second issue came from a recent change where I stopped marking Verilog files as SystemVerilog as that has some intended consequences. I clearly forgot to then add an exclusion for them when running files through the SystemVerilog to Verilog converter needed for Yosys. I’ll fix this in the next release (probably Tuesday next week). If you can, in the meantime either roll back to 2.0.29 or use iCEcube2.

3

Aha! Thank you!

I did not realize that templates included an Ft project - there are no scrollbars on the menu expansion, so I thought that the only options were the first few.

I appreciate the Verilog / SystemVerilog buglet, too - no worries on the bugfix timing, I’m still very much in the exploration phase.

Cheers!