ICE40UP PLL Problem

[Mampf F. (mampf)]

Guten Mittag,

ich versuche eine PLL in einem ICE40UP zu instanziieren und bekomme da 
einen sehr seltsamen Fehler.

u_osc : SB_HFOSC
    GENERIC MAP(CLKHF_DIV =>"0b00")
    port map(
        CLKHFEN  => nreset,
        CLKHFPU  => nreset,
        CLKHF     => HFOSC_CLK_48MHZ
    );
pll0 : pow1_pll
    port map (
        REFERENCECLK => HFOSC_CLK_48MHZ,
        PLLOUTCORE => open,
        PLLOUTGLOBAL => pll_clk,
        RESET => reset
    );

Die u_osc Instanz ist der interne Oszillator mit seinen 48MHz.

Wenn ich HFOSC_CLK_48MHZ als takt für meine anderen VHDL-Module 
verwende, funktioniert alles wunderbar.

Wenn ich aber die pll dazwischen schalte, schlägt der Fitter fehl.

I2712: Tool unable to find location for GB curl0.N_8_i_g_gb 
Error during global Buffer placement
E2055: Error while doing placement of the design
I2709: Tool unable to complete IOPlacement for the design

Ich weiß auch gar nicht, was das für ein komischer GB sein soll ...

Ich verwende die letzte iceCube2 aus Dez'2017.

Die PLL wurde mit dem Generator von iceCube2 erzeugt - ich hab aber eine 
andere PLL, die ich irgendwo gefunden hatte, auch schon ausprobiert - 
selber Effekt.

Hat jemand schon mal ähnliche Beobachtungen gemacht?

Viele Grüße,
Mampf

vollständigkeitshalber noch die erzeugte PLL (mit vhdl syntax 
highlighting^^):

module pow1_pll(REFERENCECLK,
                PLLOUTCORE,
                PLLOUTGLOBAL,
                RESET);

input REFERENCECLK;
input RESET;    /* To initialize the simulation properly, the RESET signal (Active Low) must be asserted at the beginning of the simulation */ 
output PLLOUTCORE;
output PLLOUTGLOBAL;

SB_PLL40_CORE pow1_pll_inst(.REFERENCECLK(REFERENCECLK),
                            .PLLOUTCORE(PLLOUTCORE),
                            .PLLOUTGLOBAL(PLLOUTGLOBAL),
                            .EXTFEEDBACK(),
                            .DYNAMICDELAY(),
                            .RESETB(RESET),
                            .BYPASS(1'b0),
                            .LATCHINPUTVALUE(),
                            .LOCK(),
                            .SDI(),
                            .SDO(),
                            .SCLK());

//\\ Fin=48, Fout=80;
defparam pow1_pll_inst.DIVR = 4'b0010;
defparam pow1_pll_inst.DIVF = 7'b0100111;
defparam pow1_pll_inst.DIVQ = 3'b011;
defparam pow1_pll_inst.FILTER_RANGE = 3'b001;
defparam pow1_pll_inst.FEEDBACK_PATH = "SIMPLE";
defparam pow1_pll_inst.DELAY_ADJUSTMENT_MODE_FEEDBACK = "FIXED";
defparam pow1_pll_inst.FDA_FEEDBACK = 4'b0000;
defparam pow1_pll_inst.DELAY_ADJUSTMENT_MODE_RELATIVE = "FIXED";
defparam pow1_pll_inst.FDA_RELATIVE = 4'b0000;
defparam pow1_pll_inst.SHIFTREG_DIV_MODE = 2'b00;
defparam pow1_pll_inst.PLLOUT_SELECT = "GENCLK";
defparam pow1_pll_inst.ENABLE_ICEGATE = 1'b0;

endmodule

[Klakx (Gast)]

die Beschreibung in Lattice ist etwas wage, jedoch glaube ich, dass dies 
prinzipiell gehen müsste.

GB wird der GlobalBuffer für den Takt sein. Vielleicht musst du noch 
manuell einen GB dazwischen instantiieren.

[Mampf F. (mampf)]

Klakx schrieb:
> GB wird der GlobalBuffer für den Takt sein. Vielleicht musst du noch
> manuell einen GB dazwischen instantiieren.

Ja das ist seltsam ...

Wenn man den PLLOUTGLOBAL verwendet, funktioniert es nicht (mit oder 
ohne zusätzlichem SB_GB).

Wenn man den PLLOUTCORE verwendet, funktioniert es auch nicht - es 
scheint aber dann zu funktionieren, wenn man dann noch einen SB_GB an 
den Ausgang baut.

Muss ich mir noch weiter anschauen ... Ich war schon fast verzweifelt 
...^^

*edit*: Ich frag mich, wieso die ice40 nicht vom normalen Diamon 
unterstützt wird ... Dieses iceCube2 ist totaler Mist.

[Mampf F. (mampf)]

Also reproduzierbar ...

interner Oszi auf PLL und dann den PLLCLKCORE auf einen SB_GB und dann 
als Systemtakt - funktioniert wunderbar.

[Christoph Z. (christophz)]

Mampf F. schrieb:
> *edit*: Ich frag mich, wieso die ice40 nicht vom normalen Diamon
> unterstützt wird ... Dieses iceCube2 ist totaler Mist.

Das liegt an der Geschichte der ICE* FPGAs, die wurden nämlich nicht von 
Lattice selber entwickelt sondern von der Firma SiliconBlue, die dann 
von Lattice inkl. iceCube2 aufgekauft wurde.

Aber ja, ist schade, dass sie dass in den Jahren seither nicht in 
Diamond eingepflegt haben.

[Andi (Gast)]

Es gibt in der Zwischenzeit eine neue IDE für die UltraPlus FPGAs, nennt 
sich Radiant. Das soll wohl mal Diamond ablösen, aber im Moment wird nur 
der ICE40-UP unterstützt.

Die UltraPlus Einbindung in IceCube ist sehr schlecht. Da stimmt vieles 
nicht, vor allem auch die Timingangaben. Anscheinend willst du mit der 
PLL einen 80 MHz Clock erzeugen. Das ist für fast alles viel zu hoch, 
meine Erfahrung ist, dass schon 48 MHz meist nicht funktionieren, auch 
wenn die Timinganalyse das für gut befindet.

Eine andere Alternative ist Yosys/Icestorm, die freie OpenSource 
Toolchain für ICE40. Da wird der UltraPlus auch unterstützt. Synthese 
und Routing geht viel schneller, aber die erzeugte Logik ist meist 
langsamer, als bei IceCube und Radiant.

[Mampf F. (mampf)]

Andi schrieb:
> Es gibt in der Zwischenzeit eine neue IDE für die UltraPlus FPGAs,
> nennt
> sich Radiant. Das soll wohl mal Diamond ablösen, aber im Moment wird nur
> der ICE40-UP unterstützt.

Vielen Dank für den Tipp!

Hab ich mir runtergeladen und ausprobiert - macht einen wesentlich 
besseren Eindruck :)

> Die UltraPlus Einbindung in IceCube ist sehr schlecht. Da stimmt vieles
> nicht, vor allem auch die Timingangaben. Anscheinend willst du mit der
> PLL einen 80 MHz Clock erzeugen. Das ist für fast alles viel zu hoch,
> meine Erfahrung ist, dass schon 48 MHz meist nicht funktionieren, auch
> wenn die Timinganalyse das für gut befindet.

Ja, du hast recht ... Das Timing-Tool sagt nun statt 75MHz sowas um die 
43MHz ... Schon etwas enttäuschend, aber dafür sind das 
Low-Power-Devices.

[Mampf F. (mampf)]

Mit Radiant trat das PLL-Problem übrigens auch nicht auf ... Das 
iceCube2 können die echt in die Tonne treten.

Kann es sein, dass ich der einzige Mensch auf der Welt bin, der die 
dedizierten Open-Dran-Outputs der ICE40 für **LEDs** verwenden möchte?

Das ist ein Ding der Unmöglichkeit ... Ich bin wohl echt Xilinx und 
Altera verwöhnt, Lattice hat mich schon immer angekotzt und jetzt weiß 
ich auch wieder weshalb xD

Ein Beispiel, wo ich wieder nicht weiter komme:

entity de1 is
port (
...
  led_found : out std_logic;
...
);

architecture impl1 of de1 is
...

COMPONENT BB_OD
PORT(
        T_N : IN std_logic := 'X';
        I : IN std_logic := 'X';
        O : OUT std_logic := 'X'
        B : INOUT std_logic := 'X');
);
END COMPONENT;
...

begin
...
  led0: BB_OD port map (
      T_N => '1',
      I => not found,
      O => led_found,
  );
...
end impl1;

Den Pin led_found hab ich an einen der 3 Pins gehängt, die OD-Outputs 
haben.

Jetzt meckert mich der Mapper an, dass das nicht geht:

ERROR - Pin [39], which supports Ports of type [BB_OD or OB_RGB] does 
not support placement of Port [led_found] with type [BB_B]. Please check 
for the device's IO placement limitations and change the port's locate 
Constraint to a compatible pin.

Hat jemand eine Idee, was ich falsch mache?

Muss man die Pins in der Entity evtl anders definieren?

[Andi (Gast)]

Wenn du die OD Pins nur für LED-Ausgänge verwenden willst, geht das am 
Einfachsten mit dem IP Primitive: SB_RGBA_DRV in IceCube, beim Radiant 
heisst das nun einfach RBG (um den Umstieg nicht zu einfach zu machen 
wurden viele IPs umbenannt).
Jedenfalls kannst du damit auch die LED Ströme einstellen.

In Verilog, mit Radiant sieht die Instanzierung dann etwa so aus:

RGB rgbled (
  .CURREN(1'b1),
  .RGBLEDEN(1'b1),
  .RGB0PWM(leds[0]),   //das sind die LED Steuersignale 1=ON
  .RGB1PWM(leds[1]),
  .RGB2PWM(leds[2]),
  .RGB2(rgbpin[2]),    //das sind die Pins, als Ausgänge definiert
  .RGB1(rgbpin[1]),
  .RGB0(rgbpin[0])
);

defparam rgbled.CURRENT_MODE = "0";
defparam rgbled.RGB0_CURRENT = "0b000001";    //so etwa 2 mA
defparam rgbled.RGB1_CURRENT = "0b000001";
defparam rgbled.RGB2_CURRENT = "0b000001";

Ich hoffe du kannst das in VHDL übersetzen.

[Mampf F. (mampf)]

So, mittlerweile bin ich so weit, dass meine Schaltung mit dem ice40up 
läuft.

Das hat dann wirklich funktioniert ... interner Oszillator an die PLL 
und das als Systemtakt.

Aber ich muss einem Andi(Gast) recht geben ... Die 75MHz von icecube2 
sind utopisch und sogar die 45MHz von Radiant sind zu optimistisch.

Auf 24MHz läuft es - mit 40MHz nicht.

Muss mal schauen, wo das Mittel ist, wo es zuverlässig läuft.

Aber immerhin schön stromsparend mit 45mW.

[Stefan (Gast)]

Gibt es die iCE40 UltraPlus auch ohne das NVCM, welches als OTP 
ausgeführt ist?
Ich weiß, passt nicht ganz hier rein.

Vielen Dank.

[Mampf F. (mampf)]

Stefan schrieb:
> Gibt es die iCE40 UltraPlus auch ohne das NVCM, welches als OTP
> ausgeführt ist?
> Ich weiß, passt nicht ganz hier rein.

Neben NVCM kannst du den internen RAM nutzen - oder ein externes 
SPI-Flash dran hängen.

Also zusammengefasst:

- NVCM
- internes RAM (flüchtig) über SPI-Slave Interface
- externes SPI-Flash über SPI-Master Interface

[Stefan (Gast)]

Danke Dir für die Info.
Ich habe die iCE40UP's durch Zufall letztes Jahr in der Elektor gesehen, 
aber noch nicht tiefergehend beleuchtet. Mal sehen, vielleicht lohnt der 
Einstieg. War bisher auf Xilinx und Altera festgenagelt.

Einen schönen Abend Dir.

LG

Stefan

[Mampf F. (mampf)]

Stefan schrieb:
> Danke Dir für die Info.
> Ich habe die iCE40UP's durch Zufall letztes Jahr in der Elektor gesehen,
> aber noch nicht tiefergehend beleuchtet. Mal sehen, vielleicht lohnt der
> Einstieg. War bisher auf Xilinx und Altera festgenagelt.

Ja, ich auch :)

Ich bin nur auf die ice40 gekommen, weil ich einen FPGA gesucht hab, der 
(für den Port eines bestehenden Projekts) genügend Resourcen hat, 
nicht-volatil (sein kann) und ein Package hat, für das $2-Platinen vom 
Chinesen reichen :)

Verwende den QFN48 mit 5k ... Echt toll, dass es sowas mittlerweile gibt 
:)

[Mampf F. (mampf)]

Kleines Update zum Timing ...

Die 45MHz, die Radiant errechnet hat, hab ich nun doch funktionierend 
erreicht - schuld war ein 1 Ohm-Widerstand in der 1,2V Leitung zur 
Strombestimmung.

Ich hatte im Eval-Board von Lattice solche Widerstände gesehen und 
dachte mir, wird schon passen - die Idee ist im Prinzip gut.

War wohl doch nicht so gut in der Praxis ;-)

[Duke Scarring (Gast)]

Normalerweise messe ich den Strom über ein Zwischenkabel, welches nur 
temporär vewendet wird.
Mit einen 'normalen' eingeschleiften Multimeter zum Strommessen hatte 
ich auch schon den Effekt, das Vcc nicht mehr ausgereicht hat.
Du kannst ja 0,1 Ohm statt 1 Ohm verwenden...

Duke

[Jörg W. (dl8dtl) (Moderator)]

Ich krame mal den alten Thread wieder raus:

Mampf F. schrieb:
> ERROR - Pin [39], which supports Ports of type [BB_OD or OB_RGB] does
> not support placement of Port [led_found] with type [BB_B]. Please check
> for the device's IO placement limitations and change the port's locate
> Constraint to a compatible pin.

Hast du das eigentlich je aufgelöst bekommen?

Ich kann den Pin zwar (ohne die BB_OD-Komponente) in den constraints 
zuweisen, aber bekomme dann einen vergleichbaren Fehler:

Error  71003024  Project  ERROR - Pin [41], which supports Ports of type [BB_OD or OB_RGB] does not support placement of Port [LED] with type [BB_B]. Please check for the device's IO placement limitations and change the port's locate Constraint to a compatible pin.

Nichtsdestotrotz wird das Design ordentlich synthetisiert und gemappt, 
wenn man den Fehler ignoriert, dann gibt es nur noch:

Info  52291017  Map  INFO - Port 'LED' is located on BB_OD pad '41'. Its IO buffer is mapped to BB_OD accordingly. Please notice PULLMODE is not applicable to BB_OD.

Aber es wäre natürlich interessant, wie man so einen BB_OD-Pin richtig 
deklariert.

(Dass es mit der RGB-Primitive klappt, ist ein anderer Punkt. Das haben 
sie ja letztlich auch als VHDL-Beispiel in ihrem Demoprojekt drin.)

[Mampf F. (mampf)]

Jörg W. schrieb:
> Ich krame mal den alten Thread wieder raus:
>
> Mampf F. schrieb:
>> ERROR - Pin [39], which supports Ports of type [BB_OD or OB_RGB] does
>> not support placement of Port [led_found] with type [BB_B]. Please check
>> for the device's IO placement limitations and change the port's locate
>> Constraint to a compatible pin.
>
> Hast du das eigentlich je aufgelöst bekommen?

Nope, ich hab dann keine BB_OD o.ä. benutzt und die Ports direkt als 
Ausgänge für LEDs benutzt.

Das hat problemlos funktioniert.

Ist ja schon eine  Zeit her, aber ich kann mich erinnern, dass ich da 
eeewig nach diesem Problem gegoogelt hab und keine Lösung gefunden 
hatte.

Mir ist damals noch aufgefallen, dass Radiant viel besser funktioniert 
als diese IceCube-IDE. Aber das wirst du vermutlich schon verwenden.

[Jörg W. (dl8dtl) (Moderator)]

Mampf F. schrieb:

> Nope, ich hab dann keine BB_OD o.ä. benutzt und die Ports direkt als
> Ausgänge für LEDs benutzt.

Ja, wahrscheinlich ist es eh am sinnvollsten, diese drei Ports dediziert 
zu benutzen, zumal ja auf dem Demoboard eine schöne RGB-LED dran hängt.

> Mir ist damals noch aufgefallen, dass Radiant viel besser funktioniert
> als diese IceCube-IDE. Aber das wirst du vermutlich schon verwenden.

Ja, das benutze ich.