Placement conflict between SB_IO (for RAM) and PLL?

[hoglet]

Hello all,

I've been working with BigEd to try to port the OPC-6 System to BlackIce. OPC is our one-page computing effort, more details of which can be found here:

OPC - One Page CPU

When we added the external SRAM to the project, we hit the following arachne error:

failed to place: placed 0 PLLs of 1 / 2

It would appear that using a PLL can constrain the the use of adjacent IO pins to be output only,

There is some information on these constraints on page 17 of the PLL design guide here:

PLL Placement Rules
- If any instance of PLL is placed in the location of the IO cell, then, an instance of SB_GB_IO cannot be placed in that particular IO cell.
- If an instance of ice40_PLL_CORE or ice40_PLL_2F_CORE is placed, an instance of SB_IO in “output-only” mode can be placed in the associated IO cell location.
- If an instance of ice40_PLL_PAD, ice40_PLL_2F_PAD, ice40_PLL_2_PAD is placed, the associated IO cell cannot be used by any SB_IO or SB_GB_IO.
- If an instance of ice40_PLL_2F_CORE, ice40_PLL_2F_PAD, ice40_PLL_2_PAD is placed, an instance of SB_IO in “output-only” mode can be placed in the right neighboring IO cell.

And also here, right at the bottom:

The PLL clock outputs are fed directly into the input path of certain IO tiles. In case of the 1k chip the PORTA clock is fed into PIO 1 of IO Tile (6 0) and the PORTB clock is fed into PIO 0 of IO Tile (7 0). Because of this, those two PIOs can only be used as output Pins by the FPGA fabric when the PLL ports are being used.

I'm starting to suspect that on BlackIce the FPGA pin assignment of the external RAM data bus is such that it's not possible to use either of the PLLs, which would be unfortunate.

Is this an issue that anyone else has worked through?

Dave

[hoglet]

A bit more background info (as I'm only allowed two links per post....)

The only other report of this problem also seems to be from a myStorm user:

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

In our case we have worked around the issue by simply not using the PLL for now and using a counter as a clock divider instead. With this we have been successful in using the external RAM with our OPC6 project. The BlackIce branch of which can be found here:
https://github.com/hoglet67/opc/tree/blackice/system/blackice.

regards

Dave

[BigEd]

(That's @mattvenn I believe)

[mattvenn]

using a PLL can constrain the the use of adjacent IO pins to be output only

Ah ha! I've been blocked with this for months. Unfortunately I need to PLL to create a higher frequency than the clock, so I hope there's a work around.

[ken.boak]

Dave,

Thanks for pointing this out.

Are there specific pins you can identify that are allocated to SRAM that need to be moved?

Ken

[hoglet]

Ken,

I want to try to create a minimal test case for this.

I suspect that moving D3 would be sufficient, but I would like to prove this.

Also, once we have a minimal test case it would be worth trying this on the Lattice iCEcube2 tools, just to confirm that it's not just a restriction being imposed by IceStorm.

I'll try to look at this today.

Dave

[hoglet]

I've done a bit more experimentation, and it seems the conflicting Ram Data pin is actually D[13] (pin 49). If I change the pin assignment of just D[13) to something else (e.g. pin 144) the design routes successfully.

Further, if I swap the pin assignments of D[13] (an inout) (pin 49) and RAM_OE (an output) (pin 45), the design routes successfully. This suggests the conflict is indeed happening in the input path of the IO cell associated with pin 49.

Our design only uses one PLL. I suspect if the second PLL was brought into use there would be further conflicts.

I'll do a bit more testing later.

Dave

[mattvenn]

further conflicts.

Clifford wrote a useful comment on my (non)issue here https://github.com/cseed/arachne-pnr/issues/64#issuecomment-324292251

The other PLL uses pin 128, also used by the SRAM. And as Clifford points out two IO pins on the corresponding IO blocks have to be set to PLL inputs or output only. So there may be other pins that are also conflicting.

If I disconnect the pad on the chip and solder a wire to it then I should be able to work around this. It seems there is no way to solve it in software.

Matt

[hoglet]

That's a very useful comment from Clifford.

I've just tried changing our design to use a SB_PLL40_2_PAD.

I now get a more useful error message:
fatal error: PLL at `16 33' conflicts with pin 128 input path

If I swap the pin assignments of D[3] (an inout) (pin 128) and RAM_OE (an output) (pin 45), the design routes successfully.

So it seems the conclusion is that to be able to use both PLLs, pin 49 (currently D[13]) and pin 128 (currently D[3]) would need to be swapped with output only signals.

Dave

[Folknology]

Are you suggesting swapping
D13 <=> RAM_OE
D3 <=> RAM_CS or RAM_WE
to solve the PLL issue?

Is D12 not effected?

[hoglet]

Is D12 not effected?

My experiments with the external clock being fed in on pin 129 suggest it's not affected. But I didn't test all possible configurations, and I haven't found any documentation that explains things clearly.

So the bottom line is I'm not 100% sure.

I would strongly suggest you create a test design that uses both PLLs and uses both outputs of each PLL. That should be the worst case.

Dave

[BigEd]

As a workaround for people with current boards, would the SRAM interface be OK if using just 8 data lines?

[hoglet]

As a workaround for people with current boards, would the SRAM interface be OK if using just 8 data lines?

Yes, 8-bits should be fine (as long as you choose them carefully).

Dave