Radiant: Place & Route schlägt fehl

Sven S. schrieb:

Hallo zusammen,

ich bin absoluter FPGA-Anfänger und versuche mich gerade an einem UPduino-v3.0 mit Radiant. FPGA ist ein Lattice UltraPlus ICE40UP5K.

Das Beispiel unter https://github.com/tinyvision-ai-inc/UPduino-v3.0/tree/master/RTL/radiant-reveal/rgb_blinky versuche ich gerade nach VHDL zu konvertieren. Beim Bauen des Projekts

es ist besser Verilog zu lernen als konvertieren. Dann hast keine Probleme :)

Passt da was mit dem RGBA_DRV - Module nicht ?

Schau mal da: https://stackoverflow.com/questions/50276929/using-the-sb-rgba-drv-primitive-in-vhdl

nach dem Report nutzt dein Design keine IO: "I/O Usage Summary (final): 0 out of 56 (0.0%) I/O sites used. 0 out of 36 (0.0%) bonded I/O sites used."

Und soll " PRIMARY "clkHSOSC" from comp "hsosc2.osc_inst" on site "HFOSC_R1C32", clk load = 16, ce load = 0, sr load = 0"

bedeuten, das nur 16 FF am Takt hängen ?

Hallo zusammen,

habe den Fehler gefunden. Meine Constraints waren falsch. Hatte zwei LED-Outputs vertauscht und damit waren diese nicht auf den korrekten Hardware-Pins für die jeweilige "Dual Function" des Hard-IP. Schade nur, dass in solchen Fällen keine (hilfreiche) Fehlermeldung ausgegeben wird.

Die Nutzung der IP-Blöcke "via library iCE40UP;" sowie "use iCE40UP.Components.all;" war übrigens korrekt für Radiant. Mit iceCube2 bräuchte man die anderen Libs wie im Stackoverflow Link.

Es ist auch korrekt, dass an der Clock gerade nur die 16 FF hängen. Da läuft momentan nur ein Counter drauf.

Alt und falsch:

1

ldc_set_location -site {39} [get_ports led_green]

2

ldc_set_location -site {40} [get_ports led_blue]

3

ldc_set_location -site {41} [get_ports led_red]

Neu und korrekt:

1

ldc_set_location -site {39} [get_ports led_blue]

2

ldc_set_location -site {40} [get_ports led_green]

3

ldc_set_location -site {41} [get_ports led_red]

Gruß Sven

habe den Fehler gefunden. Meine Constraints waren falsch. Hatte zwei LED-Outputs vertauscht und damit waren diese nicht auf den korrekten Hardware-Pins für die jeweilige "Dual Function" des Hard-IP.

Im VHDL code ist auch so eine Vertauschung bei der Instanziierung, das schien mir aber nicht besonders wichtig:

1

port map (

2

      CURREN   => '1',  -- I

3

      RGBLEDEN => '1',  -- I

4

      RGB0PWM  => led_red_int,  -- I

5

      RGB1PWM  => led_green_int,  -- I

6

      RGB2PWM  => led_blue_int,  -- I

7

      RGB2     => led_red,  -- O

8

      RGB1     => led_green,  -- O

9

      RGB0     => led_blue   -- O

10

    );

red_int wird auf RGB0* verdrahtet, led_red dagegen auf RGB2*, der selbe Mischmasch bei blue .

Schade nur, dass in solchen Fällen keine (hilfreiche) Fehlermeldung ausgegeben wird.

FPGA's sind eben auch hinsichtlich des IO-Pinings sehr komplex, da schaffen es die Tool-programmierer selten, alles abzutesten und aussagekräftig zu berichten was anVoraussetzunegn und Einschränkungen im Datenblatt genannt wird.

Wenn beim Zynq ein Schaltnild zu reviewen ist, nehm ich mir immer mehrere Stunden Zeit für den Review der MDIO (also Multiplexed Hardcore-Peripherals (I2C, UART,...) mit den User-IO) resp. nachschlagen der zulässigen Verdrahtungsmöglichkeiten im Datenblatt ( https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/MDIO-Interface ).

Da die FPGA_Firmware moch nicht erstellt ist, kann man nicht die tools für einen automatischen DRC (Design Rule Check) drüber laufen lassen.