fatal error: failed to place: placed 0 PLLs of 1 / 2

mattvenn commented 7 years ago

Hi there, hope this is the right place to post this issue.

I'm using the ice40 8k fpga and the toolchain described by @cliffordwolf.

In my project I'm using SB_IO (for bidirectional port pins on some SRAM) and SB_PLL blocks (for a fast DVID clock).

arachne-pnr fails with the above error, and the line in arachne-pnr that is failing is

https://github.com/cseed/arachne-pnr/blob/master/src/pcf.cc#L283

It is the first clause (D_IN_0 is connected) that is true and causing the fail.

I tried making an MVP to show the issue but removing unrelated parts of the project also 'fixed' it. So I have left the project as is and pushed my development branch: https://github.com/mattvenn/fpga-virtual-graf/tree/blackice

I'm a beginner with FPGAs, but my guess is that the PLL has limited options for its connectivity and these have already been used by other parts of the project. Is there a way to choose to instantiate the other PLL the 8k device has? Or am I completely wrong here.

If there is any other information needed please ask.

ghost commented 7 years ago

Hi @mattvenn

Could you please give me the exact part of the HDL code which fails and how to reproduce it?, I've followed your git repo but is hard for me to understand, in few minutes, all the work you have been done until now.

Also, this is a very useful way to catch the attention from someone else for look into your issue :)

mattvenn commented 7 years ago

I hope this is more useful: https://github.com/mattvenn/fpga-virtual-graf/tree/pll-issue

clone the repo and run make

it should fail with this message:

fatal error: failed to place: placed 0 PLLs of 1 / 2 make: *** [i2c.asc] Error 1

Now take a look at i2c.v, there are 3 defines at the top. If any are commented the pnr succeeds.

arachne-pnr -v arachne-pnr 0.1+191+1 (git sha1 e83eecb, g++ 4.8.4-2ubuntu1~14.04.3 -O2)

And thanks for taking the time to look into this!

mattvenn commented 7 years ago

new thread on the mystorm forum implies this could actually be a hardware issue https://forum.mystorm.uk/t/placement-conflict-between-sb-io-for-ram-and-pll/224

cliffordwolf commented 7 years ago

There is a whole range of things wrong with this design:

When a PLL is enabled then the two IO pins on the corresponding IO block can only be used as PLL inputs or output-only. (That's why those pins are used for the LEDs on the IcoBoard: LEDs are inherently output-only.) This is the issue discussed on the mystorm forum.
When you drive a PLL from the neighboring IO PAD you need to use SB_PLL40_PAD, SB_PLL40_2_PAD, or SB_PLL40_2F_PAD, not one of the _CORE variants.
When you are using a _PAD PLL variant and you also need the source clock in the design, then you need to route the source clock through the PLL using the SB_PLL40_2_PAD primitive.

The following patch to the design makes make i2c.bin run through. Of course, the design won't really work because I had to disconnect DAT[3] from IO pin 128.

diff --git a/blackice.pcf b/blackice.pcf
index 61ccad6..b0623ec 100644
--- a/blackice.pcf
+++ b/blackice.pcf
@@ -131,7 +131,7 @@ set_io --warn-no-port ADR[17] 78
 set_io --warn-no-port DAT[0] 135
 set_io --warn-no-port DAT[1] 134
 set_io --warn-no-port DAT[2] 130
-set_io --warn-no-port DAT[3] 128
+# set_io --warn-no-port DAT[3] 128
 set_io --warn-no-port DAT[4] 125
 set_io --warn-no-port DAT[5] 124
 set_io --warn-no-port DAT[6] 122
@@ -150,7 +150,7 @@ set_io --warn-no-port RAMWE 120
 set_io --warn-no-port RAMCS 136

 ## Onboard 100Mhz oscillator
-set_io --warn-no-port clk 129
+set_io --warn-no-port clk_pin 129
 set_io --warn-no-port LED[0] 71 #LD4,!SS,p14_1
 set_io --warn-no-port LED[1] 67 #LD3,MISO,p14_2
 set_io --warn-no-port LED[2] 68 #LD2,MOSI,p14_3
diff --git a/i2c.v b/i2c.v
index f8d052c..bd33c04 100644
--- a/i2c.v
+++ b/i2c.v
@@ -4,7 +4,7 @@
 `define pll_fail2
 `define pll_fail3
 module top (
-   input  clk,
+   input  clk_pin,
    output [0:3] LED,
     output pixartclk,
     output pixart_reset,
@@ -19,6 +19,7 @@ module top (
     output RAMCS,
     output [31:0] PMOD
 );
+    wire clk;

     reg cam_clk;
     reg i2c_start = 1;
@@ -47,9 +48,9 @@ module top (
     );
 `ifdef pll_fail3
     //PLL details http://www.latticesemi.com/view_document?document_id=47778
-    SB_PLL40_CORE #(
+    SB_PLL40_2_PAD #(
         .FEEDBACK_PATH("SIMPLE"),
-        .PLLOUT_SELECT("GENCLK"),
+        // .PLLOUT_SELECT("GENCLK"),
         .DIVR(4'b1001),
         .DIVF(7'b1100100),
         .DIVQ(3'b011),
@@ -58,8 +59,9 @@ module top (
 //        .LOCK(lock),
         .RESETB(1'b1),
         .BYPASS(1'b0),
-        .REFERENCECLK(clk),
-        .PLLOUTCORE(clkx5)
+        .PACKAGEPIN(clk_pin),
+        .PLLOUTCOREA(clk),
+        .PLLOUTCOREB(clkx5)
     );
 `endif
   wire clkx5;

Alternatively we use the PLL on the other side of the chip. In this case we have to route the clock through the chip. For this we leave the Verilog design unchanged and use the SB_PLL40_CORE primitive, but we have to get rid of the assignment for pin 49 because this pin can not be used as input pin when the PLL on the other side of the chip is active:

diff --git a/blackice.pcf b/blackice.pcf
index 61ccad6..5354cdf 100644
--- a/blackice.pcf
+++ b/blackice.pcf
@@ -141,7 +141,7 @@ set_io --warn-no-port DAT[9] 60
 set_io --warn-no-port DAT[10] 56
 set_io --warn-no-port DAT[11] 55
 set_io --warn-no-port DAT[12] 52
-set_io --warn-no-port DAT[13] 49
+# set_io --warn-no-port DAT[13] 49
 set_io --warn-no-port DAT[14] 48
 set_io --warn-no-port DAT[15] 47

Closing this issue because afaict there is nothing wrong with arachne-pnr here.

mattvenn commented 7 years ago

Thanks Clifford. I don't fully understand your comments above, but it appears to me that this means the mystorm board can't work with its on board SRAM and a PLL. This is because both PLLs use pins that are already used by the SRAM's IO pins. Matt

cliffordwolf commented 7 years ago

Yes, this is correct. You could use one PLL and only use 15 RAM bits (or both PLLs and only use 14 RAM bits). But that might be pretty inconvenient for many applications..

mattvenn commented 7 years ago

Thank you Clifford.

On 23 August 2017 at 12:55, Clifford Wolf notifications@github.com wrote:

Yes, this is correct. You could use one PLL and only use 15 RAM bits (or both PLLs and only use 14 RAM bits). But that might be pretty inconvenient for many applications..

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cseed/arachne-pnr/issues/64#issuecomment-324294118, or mute the thread https://github.com/notifications/unsubscribe-auth/AAmtbF1ws5hYzM78WrG_TH63HOckUaF0ks5sbAUSgaJpZM4NvyNO .

-- Matthew Venn web mattvenn.net twitter @matthewvenn https://twitter.com/matthewvenn

YosysHQ / arachne-pnr

fatal error: failed to place: placed 0 PLLs of 1 / 2 #64