Port defined like d[9:2] is not indexed correctly when used in pcf file

[niels-moller]

Consider the following trivial ice40 design (main.vl):

module main(// Leds, labeled D2 - D9 on the board.
	    output [9:2] d);

   assign d[2] = 1;
   assign d[3] = 0;
   assign d[4] = 1;
   assign d[5] = 1;
   assign d[6] = 0;
   assign d[7] = 0;
   assign d[8] = 1;
   assign d[9] = 1;
endmodule // main

with the following main.pcf:

# Leds
set_io d[9] B5
set_io d[8] B4
set_io d[7] A2
set_io d[6] A1
set_io d[5] C5
set_io d[4] C4
set_io d[3] B3
set_io d[2] C3

Synthesis using

yosys -q -p 'synth_ice40 -json main.json' -f 'verilog' main.vl
nextpnr-ice40 --hx8k --json main.json --pcf main.pcf --asc main.asc

fails as follows:

Info: Importing module main
Info: Rule checker, verifying imported design
Info: Checksum: 0x292e1049

Warning: unmatched constraint 'd[9]' (on line 2)
Warning: unmatched constraint 'd[8]' (on line 3)
Info: constrained 'd[7]' to bel 'X5/Y33/io1'
Info: constrained 'd[6]' to bel 'X4/Y33/io1'
Info: constrained 'd[5]' to bel 'X4/Y33/io0'
Info: constrained 'd[4]' to bel 'X3/Y33/io1'
Info: constrained 'd[3]' to bel 'X3/Y33/io0'
Info: constrained 'd[2]' to bel 'X1/Y33/io0'
ERROR: IO 'd[0]' is unconstrained in PCF (override this error with --pcf-allow-unconstrained)
ERROR: Loading PCF failed.
2 warnings, 2 errors

If d[9:2] is replaced by d[7:0] in the .vl file, and the .pcf file is updated accordingly, synthesis works without errors.

Using arachne-pnr instead,

yosys -q -p 'synth_ice40 -blif main.blif' -f verilog main.vl
arachne-pnr -d 8k -p main.pcf -o main.asc main.blif

the .pcf file is accepted without complaints. (If it actually does the right thing, I'm not 100% sure. I'm still a newbie when it comes to these tools).

I'm using "Yosys 0.8+119 (git sha1 0fc6e2bf, gcc 8.2.0-13 -fPIC -Os)" and "nextpnr-ice40 -- Next Generation Place and Route (git sha1 67d2dcb)", both built from a git checkouts a few days ago.

BTW, building nextpnr using cmake-3.7.2 (debian stable, I think) didn't work out of the box, I had to patch it like

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 33a703d..3a50035 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -66,7 +66,7 @@ endif()
 find_package(Sanitizers)
 
 # List of Boost libraries to include
-set(boost_libs filesystem thread program_options)
+set(boost_libs filesystem system thread program_options)
 
 if (BUILD_GUI AND NOT BUILD_PYTHON)
     message(FATAL_ERROR "GUI requires Python to build")

[daveshah1]

This seems to be a Yosys issue as well as a nextpnr issue; as nothing reaches the JSON that would allow nextpnr to know the bounds of the port.

 "main": {
      "attributes": {
        "top": 1,
        "src": "range.v:1"
      },
      "ports": {
        "d": {
          "direction": "output",
          "bits": [ "1", "0", "1", "1", "0", "0", "1", "1" ]
        }
      },
      "cells": {
      },
      "netnames": {
        "d": {
          "hide_name": 0,
          "bits": [ "1", "0", "1", "1", "0", "0", "1", "1" ],
          "attributes": {
            "src": "range.v:2"
          }
        }
      }
    }

[niels-moller]

I see. I've filed yosys issue YosysHQ/yosys#784.

[zeldin]

Also, and perhaps unsurprisingly, if you change the output declaration of main into output [0:7] d (note the order of the bounds) and adjust all the indexes to be 0-7 instead of 2-9, the LEDs display an image which is the mirror of the correct one when using JSON and nextpnr (but the correct one with BLIF and arachne-pnr).

[niels-moller]

Yosys side now fixed, see YosysHQ/yosys#1122 which adds an "offset" attribute in the json output.

[niels-moller]

Is this problem fixed with commit 5cb9735 ?

Just built latest nextpnr (git sha1 19cb4ca) and yosys (0.8+588 (git sha1 f604aa17, gcc 8.3.0-6 -fPIC -Os) and reran the example, and I now get no errors, and only a single, reasonable, warning "No clocks found in design". And the assignments

Info: constrained 'd[9]' to bel 'X7/Y33/io1'
Info: constrained 'd[8]' to bel 'X6/Y33/io1'
Info: constrained 'd[7]' to bel 'X5/Y33/io1'
Info: constrained 'd[6]' to bel 'X4/Y33/io1'
Info: constrained 'd[5]' to bel 'X4/Y33/io0'
Info: constrained 'd[4]' to bel 'X3/Y33/io1'
Info: constrained 'd[3]' to bel 'X3/Y33/io0'
Info: constrained 'd[2]' to bel 'X1/Y33/io0'

I don't have the hardware at hand now, so I can't check if the result really works correctly, though.

[mmicko]

Confirmed working correctly now