ICE40UP5K : SPRAM geht, EBR geht nicht

[Edgar C. (ec-develo)]

Hallo zusammen,

seit Tagen versuche ich erfolglos, die EBRs des ICE40UP zum Laufen zu 
bringen.

Ich habe es auf verschiedene Arten versucht :
PMI-Template 'ram_dq', IP Catalog 'RAM_DQ', direkte Instanziierung von 
'PDP4K'.

Selbst bei erfolgreicher Synthese, Place & Route und trotz erfolgreicher 
Simulation kommen physikalisch immer nur Nullen aus den Datenausgängen.

Aufgefallen ist es mir, als ich den Softcore 'LXP32' nicht zum Laufen 
bekam, (trotz erfolgreicher Simulation) bis ich seine Register und das 
Programm-Rom als distributed Ram realisiert habe. Dann lief es auf 
Anhieb.

Nun habe ich auf meinem Testboard ein EBR mit seinen Adressen, Daten, 
Clock und WE auf LEDs bzw. Taster und Schalter geführt. Das Ergebnis ist 
das gleiche. Es kommen nur Nullen raus.

Ersetze ich das EBR durch ein SPRAM, dann funktioniert es. Code dafür 
siehe unten.

Hat jemand ein entsprechendes, physikalisch funktionierendes Beispiel 
zur Instanziierung eines EBR für mich? Mir gehen wirklich die Ideen aus 
und die Doku von Lattice ist auch alles andere als prickelnd.

Auf den angehängten Bildern ist der zufällige Power-Up-Inhalt einer 
Speicherzelle eines SPRAMs und die erfolgreich geschriebene und 
zurückgelesene '1' zu sehen.

P.S. Ich habe es natürlich auf mehreren Testboards ausprobiert um einen 
Exemplarfehler des ICE40UP auszuschließen.

-- Library and Use statements for IEEE packages
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

-- ***********************************
-- Funktionierendes Beispiel mit SPRAM
-- Die unteren 256 Adressen können
-- ausgelesen und mit 0x0101 bzw 0x0000 
-- beschrieben werden. Die unteren 8 Bit
-- des Datenwortes sind auf der ganz
-- rechten Anzeige zu sehen
-- ***********************************

library iCE40UP;
use  iCE40UP.components.sp256k;


entity sp256k_primitive is
  port(
    DIPSW    : in std_logic_vector( 7 downto 0); -- Eightfold DIP-Switch, OFF = '0', ON = '1'
    n_CONTROL  : in std_logic_vector( 4 downto 0); -- 5 push buttons, not pressed = '1', pressed = '0'
    n_SEGMENT  : out std_logic_vector( 7 downto 0); -- dp(7), f(6) .. a(0), '0' = ON, '1' = OFF
    n_DIGIT    : out std_logic_vector( 3 downto 0) -- digits 3/2/1/0, '0' = ON, '1' = OFF
  );
end entity;


architecture syn of sp256k_primitive is

  signal AD     : std_logic_vector(13 downto 0);
  signal DI    : std_logic_vector(15 downto 0);
  signal MASKWE  : std_logic_vector(3 downto 0);
  signal WE    : std_logic;
  signal CS    : std_logic;
  signal CK    : std_logic;
  signal STDBY  : std_logic;
  signal SLEEP  : std_logic;
  signal PWROFF_N  : std_logic;
  signal DO    : std_logic_vector(15 downto 0);

begin

  my_SP256K : SP256K
  port map (
    AD      => AD,
    DI      => DI,
    MASKWE    => MASKWE,
    WE      => WE,
    CS      => CS,
    CK      => CK,
    STDBY    => STDBY,
    SLEEP    => SLEEP,
    PWROFF_N  => PWROFF_N,
    DO      => DO
  );

  AD      <= "000000" & DIPSW;
  DI      <= "0000000" & not n_CONTROL(4) & "0000000" & not n_CONTROL(4);
  MASKWE    <= "1111";
  WE      <= not n_CONTROL(1);
  CS      <= '1';
  CK      <= not n_CONTROL(0);
  STDBY    <= '0';
  SLEEP    <= '0';
  PWROFF_N  <= '1';
  n_SEGMENT  <= not DO(7 downto 0);
  n_DIGIT    <= "1110";
  
end architecture;

[Mampf F. (mampf)]

Ich hatte mit diesen dämlichen EBRs auch eine Menge Ärger ... Von ICE40 
sollte man die Finger lassen :/

Irgendwann hat es dann doch geklappt:

https://github.com/shufps/troika_ice40/blob/master/fpga/source/troika.vhd#L68

Vielleicht hilft dir das weiter ... Ich hab die EBRs nicht als 
Komponente sondern als Arrays mit diversen Attributen definiert.

[Mampf F. (mampf)]

Ach - verwendest du die Radiant Software oder IceCube?

Falls letzteres, bitte installier dir Radiant - die funktioniert um 
einiges besser.

[Edgar C. (ec-develo)]

Hallo Mampf,

erst einmal vielen Dank für deine Antwort!

Ich habe mir dein Beispiel angesehen und es folgendermaßen umgesetzt

-- Library and Use statements for IEEE packages
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity ebrray is
  port(
    clk_i  : in std_logic;
    we_i  : in std_logic;
    addr_i  : in std_logic_vector(7 downto 0);
    data_i  : in std_logic_vector(15 downto 0);
    data_o  : out std_logic_vector(15 downto 0)
  );
end entity;

architecture syn of ebrray is

  -- state memory
  type mem_type is array (255 downto 0) of std_logic_vector(15 downto 0);
  signal mem0 : mem_type;
  
  -- unknown what this really does ... 
  attribute syn_ramstyle: string;
  attribute syn_ramstyle of mem0: signal is "rw_check";

begin
  write_ram : process (clk_i)
  begin
    if rising_edge (clk_i) then
       if we_i = '1' then
        mem0(to_integer(unsigned(addr_i))) <= data_i;
       end if;
    end if;
  end process write_ram;

  read_ram : process (clk_i)
  begin
    if rising_edge (clk_i) then
      data_o <= mem0(to_integer(unsigned(addr_i)));
    end if;
  end process read_ram;

end architecture;

Ich denke, es ist soweit korrekt? Es wird jedenfalls synthetisiert.
Das habe ich dann als Komponente benutzt.

  --my_ram : spram_256x16
  my_ram : ebrray
    port map(
      clk_i  => clk_i,
      we_i  => we_i,
      addr_i  => addr_i,
      data_i  => data_i,
      data_o  => data_o
    );

Der Effekt ist leider der gleiche. Es wird ein EBR instanziiert und 
soviel ich sehe korrekt verdrahtet. Siehe Bild 1 (Technology View)

Auf der Siebensegmentanzeige bleibt es dunkel, trotz erfolgreicher 
Simulation (Bild 2)

Tausche ich das EBR gegen ein SPRAM, (Bild 3) leuchtet es munter, je 
nachdem welches Bitmuster ich ins RAM schreibe. Das entspricht auch 
exakt den beiden Simulationsergebnissen. Bild 2 und 4.

Es ist zum Mäusemelken !!!

Beim übersetzen gibt es jeweils eine einzelne Warning, die mir aber auch 
nicht so wirklich klar sind :

EBR =>
Warning  1009991  Map  WARNING - Instance 'my_ram.mem00_i2' is removed 
out, attached properties "ECO_MEM_BLOCK_POS=[0, 0] 
ECO_MEM_BLOCK_SIZE=[16, 256] ECO_MEM_ID=my_ram/mem0 ECO_MEM_SIZE=[16, 
256] ECO_MEM_TYPE=EBR" ignored.


SPRAM =>
Warning  1009991  Map  WARNING - Signal 'n_CONTROL_0__N_17' is removed 
out, attached properties "is_inv_clock= lineinfo=@1(55[9],55[14])" 
ignored.


Mittlerweile überlege ich, ob ich mir aus dem Project Icestorm die 
Definitionen des Bitfiles heraus suche (falls sie dort dokumentiert 
sind) und dann nachvollziehe, was an Konfiguration in das FPGA wandert.

Ich benutze übrigens die neueste Version von Radiant.

Und ich muss zugeben, dass ich immer noch nicht restlos die Nase voll 
habe.

Mir als (ewiger) Anfänger gefällt sowohl das Tool von der Bedienung her, 
als auch der ICE40UP von seinem Preis-Leistungs-Verhältnis.

Wenn es da nicht diese Klinken gäbe...

[Duke Scarring (Gast)]

Edgar C. schrieb:
> type mem_type is array (255 downto 0) of std_logic_vector(15 downto
> 0);

Änder mal den mem_type auf

type mem_type is array (0 to 255) of std_logic_vector(15 downto 0);

Sonst liest Du den EBR möglicherweise rückwärts aus.

Mit welchem Tool wird der ICE40UP gefüllt? Sind da auch explizit die 
EBRs mit erwähnt?

Duke

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

Also als RAM_DP habe ich ihn zumindest schon erfolgreich gelesen :), im 
Rahmen einer CCIR-Bildschirmsteuerung, die ich als Nachbau einer vor 35 
Jahren gezimmerten Hardware zusammengestrickt habe.

Allerdings kam das "Hello world!", welches auf dem Bildschirm 
dargestellt wird, hier erstmal nur aus einer Initialisierungsdatei. Ich 
muss mal sehen, wie ich dafür ein paar manuelle Eingaben von außen am 
einfachsten zimmern kann, um den RAM zu beschreiben. Vielleicht ja eine 
serielle Schnittstelle noch mit ins Design reinnehmen.

[Markus F. (mfro)]

Das hier kennst Du:

http://www.latticesemi.com/view_document?document_id=47775

??

Ich würde mal - wie im Beispiel - einen downto-Index probieren.

[Edgar C. (ec-develo)]

Duke Scarring schrieb:
> Edgar C. schrieb:
>> type mem_type is array (255 downto 0) of std_logic_vector(15 downto
>> 0);

Hallo Duke,

> Änder mal den mem_type auf
>

> type mem_type is array (0 to 255) of std_logic_vector(15 downto 0);
>

> Sonst liest Du den EBR möglicherweise rückwärts aus.

habe ich gemacht, aber es ändert sich nichts. Ich habe auch Adresse 0 
beschrieben und dann Adresse 255 ausgelesen. Ebenfalls ohne Erfolg.

> Mit welchem Tool wird der ICE40UP gefüllt? Sind da auch explizit die
> EBRs mit erwähnt?

Als Werkzeug benutze ich Lattice Radiant in der Version 2.0.2.281.2
Sowohl im Report als auch im Netlist Analyzer als auch im Physical View 
ist eindeutig ein EBR benutzt.

Als Programmer benutze ich den Radiant Programmer, als Gegenstück einen 
FT2232D auf meinem Testboard.

Das RAM kann ich mit Bitmustern füllen, die ich in Abhängigkeit von zwei 
Tastern an die Dateneingänge des RAM anlege.

data_i  <= not (n_CONTROL(4) & n_CONTROL(3) & n_CONTROL(4) & n_CONTROL(3) & n_CONTROL(4) & n_CONTROL(3) & n_CONTROL(4) & n_CONTROL(3) 
    & n_CONTROL(3) & n_CONTROL(4) & n_CONTROL(3) & n_CONTROL(4) & n_CONTROL(3) & n_CONTROL(4) & n_CONTROL(3) & n_CONTROL(4));

All das funktioniert wie gesagt mit einem SPRAM aber nicht mit einem EBR

[Edgar C. (ec-develo)]

Jörg W. schrieb:
> Also als RAM_DP habe ich ihn zumindest schon erfolgreich gelesen :), im
> Rahmen einer CCIR-Bildschirmsteuerung, die ich als Nachbau einer vor 35
> Jahren gezimmerten Hardware zusammengestrickt habe.
>
> Allerdings kam das "Hello world!", welches auf dem Bildschirm
> dargestellt wird, hier erstmal nur aus einer Initialisierungsdatei. Ich
> muss mal sehen, wie ich dafür ein paar manuelle Eingaben von außen am
> einfachsten zimmern kann, um den RAM zu beschreiben. Vielleicht ja eine
> serielle Schnittstelle noch mit ins Design reinnehmen.

Hallo Jörg,

es tut gut zu lesen, dass es auch Erfolge gibt. ;-) Aber sonst wären die 
Dinger ja auch schon vom Markt verschwunden, oder?

Leider funktioniert bei mir auch das Vor-Initialisieren mit Daten nicht.

Ich habe das Gefühl, dass vielleicht irgendein (Konfigurations-)Bit oder 
ein falsch stehender Konfigurationseingang die RAMs inaktiv hält, sodass 
sie nichts ausgeben. Aber ich habe keinen Schimmer, welcher oder warum.

Vielleicht bin ich auch nur zu doof für copy&paste

Welches Tool hast du denn benutzt? Radiant? in welcher Version?

[Edgar C. (ec-develo)]

Markus F. schrieb:
> Das hier kennst Du:
>
> http://www.latticesemi.com/view_document?document_id=47775
>
> ??
>
> Ich würde mal - wie im Beispiel - einen downto-Index probieren.

Hallo Markus,

mein Firefox meint gerade, ich hätte es schon zwei Mal herunter geladen 
;-)

Gelesen habe ich Teile davon auch schon. Ich werde es jetzt noch einmal 
gründlich durchackern und die Beispiele in meinen Code übernehmen.

[PCB (Gast)]

Eigentlich sind die EBRs nicht so schwer zu verwenden.
Es gibt dort aber Unterschiede. Z.B. hat nur die 256x16Bit Variante eine 
Bitmaske, die übrigens low-aktiv ist!

Beim Auslesen des EBR musst du auch die Verzögerung beachten.
Bei mir fielen die Daten bei einem 25MHz Takt erst nach einem halben 
Taktzyklus aus dem Speicher raus, oder besser gesagt waren sie am IO 
aktiv.

Was wirklich nervt ist, dass Lattice keine Timing-Daten für die EBRs in 
den Datenblättern angibt. Man muß selber mit einer 
Post-Synthese-Simulation herausfinden, ob die Timings mit deinem 
restlichen Design zusammenpassen.

Wo du noch ganz doll aufpassen musst, ist, dass du dich selber darum 
kümmern musst, dass es keine Konflikte mit der Schreib- und der 
Leseadresse gibt.
Oben in deinem VHDL-Code scheinst du das nicht zu haben!

Du kannst deinen EBR auch als ROM verwenden und ihn mit Werten 
vorinitialisieren. So könntest du z.B. testen, ob das mit dem Auslesen 
des Speichers generell funktioniert.

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

PCB schrieb:
> Du kannst deinen EBR auch als ROM verwenden und ihn mit Werten
> vorinitialisieren. So könntest du z.B. testen, ob das mit dem Auslesen
> des Speichers generell funktioniert.

Hatte ich vergessen zu schreiben: einen ROM hatte ich in meinem Design 
natürlich auch drin, als Zeichengenerator für den Bildschirm (5 x 7 
Matrix, also 128 (ASCII-Zeichen) x 8 (Zeilen) x 6 Bit für den ROM). Der 
funktionierte klaglos.

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

Edgar C. schrieb:
> Welches Tool hast du denn benutzt? Radiant? in welcher Version?

Ja, Radiant, sollte die aktuelle Version sein (2.0.1.281.2 - wer auch 
immer sich solche Nummern ausdenkt :).

[Andi (Gast)]

Bei den ICE40 werden zuerst die LUTs konfiguriert, und erst danach die 
EBRs initialisiert. Der FPGA legt aber seltsamerweise schon los, bevor 
die EBR Konfiguration abgeschlossen ist.
Ich bin daran, beim Entwickeln einer eigenen CPU mit ICE40 fast 
verzweifelt. Wenn ich den Testcode in Einzelschritten ausführte ging es, 
bei voller Geschwindigkeit tat sich nichts. Bis ich ein Startup-Delay 
mit einem Zähler einbaute, so dass die EBRs genug Zeit bekommen zum 
fertigkonfigurieren.

Vielleicht ist das ja auch die Lösung für deine Anwendung. 
Codevorschläge kann ich leider keine machen, da ich mich nur mit Verilog 
auskenne. Ich warte jeweils bis ein 17bit Zähler mit etwa 24 MHz 
getaktet voll durchgelaufen ist, und greife erst danach auf die BRAMs 
zu.

[Edgar C. (ec-develo)]

Edgar C. schrieb:
> Markus F. schrieb:
>> Das hier kennst Du:
>>
>> http://www.latticesemi.com/view_document?document_id=47775
>>
>> ??
>>
>> Ich würde mal - wie im Beispiel - einen downto-Index probieren.
>
> Hallo Markus,
>
> mein Firefox meint gerade, ich hätte es schon zwei Mal herunter geladen
> ;-)
>
> Gelesen habe ich Teile davon auch schon. Ich werde es jetzt noch einmal
> gründlich durchackern und die Beispiele in meinen Code übernehmen.

So, gründlich durchgeackert und keine Diskrepanzen zu meinen Designs 
festgestellt.

Bis auf die Tatsache, dass die in diesem Memory Usage Guide verwendeten 
Namen wie SB_RAM256x16 und SB_RAM256x16NR im aktuellen Radiant nicht 
mehr unterstützt werden.

Also weiter... Für Radiant gibt es die Hilfedatei Radiant20SP1_Help.pdf

Dort gibt es auf Seite 619 die gültigen Namen 'EBR_B' und 'PDP4K' mit 
den entsprechenden Erklärungen. Hatte ich aber auch schon ausprobiert.

Ein Stück tiefer ein weiterer Link auf Radiant20_migration_icecube2.pdf

Dort gibt es ein paar Beispiele in Verilog, die ich soweit verstehen 
kann. Kein Hinweis auf einen Fehler. Aber wieder ein neues Dokument 
namens FPGA-IPUG-02033-1-0-Memory-Modules.pdf

Dort werden die Memory 'Modules' beschrieben, also aus EBRs zusammen 
gesetzte Module z.B RAM_DQ. Die werde ich mir als nächstes zum 
wiederholten Mal ansehen.

[Edgar C. (ec-develo)]

Hallo PCB,

PCB schrieb:
> Eigentlich sind die EBRs nicht so schwer zu verwenden.

Davon bin ich bis letzte Woche auch ausgegangen ;-)
Und ich glaube, dass ich einfach nur eine Kleinigkeit übersehe.

> Es gibt dort aber Unterschiede. Z.B. hat nur die 256x16Bit Variante eine
> Bitmaske, die übrigens low-aktiv ist!
>
> Beim Auslesen des EBR musst du auch die Verzögerung beachten.
> Bei mir fielen die Daten bei einem 25MHz Takt erst nach einem halben
> Taktzyklus aus dem Speicher raus, oder besser gesagt waren sie am IO
> aktiv.

Ich stieß auf das Problem, als ich den LXP32-Softcore ausprobiert habe, 
der mit schnuckeligen 24 MHz läuft (mit distributed ram).

Aber mittlerweile bin ich mit meiner Fehlersuche so weit, dass ich nur 
noch ein einzelnes EBR quasi statisch mit entprellten Tasten und LEDs 
püfe, sodass das Timing keine Rolle spielt.


> Wo du noch ganz doll aufpassen musst, ist, dass du dich selber darum
> kümmern musst, dass es keine Konflikte mit der Schreib- und der
> Leseadresse gibt.
> Oben in deinem VHDL-Code scheinst du das nicht zu haben!

Ok

> Du kannst deinen EBR auch als ROM verwenden und ihn mit Werten
> vorinitialisieren. So könntest du z.B. testen, ob das mit dem Auslesen
> des Speichers generell funktioniert.

Genau das funktioniert ja auch nicht! Es kommen nur Nullen raus, egal ob 
ich das Teil vorinitialisiere oder versuche, es per Hand zu beschreiben.

Das ist doch echt nicht normal, zumal es problemlos mit einem SP256K 
geht. Also das manuelle Beschreiben und Auslesen! Vorinitialisieren geht 
bei denen ja nicht.

[Edgar C. (ec-develo)]

Jörg W. schrieb:
> PCB schrieb:
>> Du kannst deinen EBR auch als ROM verwenden und ihn mit Werten
>> vorinitialisieren. So könntest du z.B. testen, ob das mit dem Auslesen
>> des Speichers generell funktioniert.
>
> Hatte ich vergessen zu schreiben: einen ROM hatte ich in meinem Design
> natürlich auch drin, als Zeichengenerator für den Bildschirm (5 x 7
> Matrix, also 128 (ASCII-Zeichen) x 8 (Zeilen) x 6 Bit für den ROM). Der
> funktionierte klaglos.

Ja, mach mich nur neidisch, LOL! Das Vorinitialisieren habe ich 
probiert. Es kommen trotzdem nur Nullen raus.

[Edgar C. (ec-develo)]

Andi schrieb:
> Bei den ICE40 werden zuerst die LUTs konfiguriert, und erst danach die
> EBRs initialisiert. Der FPGA legt aber seltsamerweise schon los, bevor
> die EBR Konfiguration abgeschlossen ist.
> Ich bin daran, beim Entwickeln einer eigenen CPU mit ICE40 fast
> verzweifelt. Wenn ich den Testcode in Einzelschritten ausführte ging es,
> bei voller Geschwindigkeit tat sich nichts. Bis ich ein Startup-Delay
> mit einem Zähler einbaute, so dass die EBRs genug Zeit bekommen zum
> fertigkonfigurieren.
>
> Vielleicht ist das ja auch die Lösung für deine Anwendung.
> Codevorschläge kann ich leider keine machen, da ich mich nur mit Verilog
> auskenne. Ich warte jeweils bis ein 17bit Zähler mit etwa 24 MHz
> getaktet voll durchgelaufen ist, und greife erst danach auf die BRAMs
> zu.

Das ist ein super Hinweis (für später, hoffentlich). Danke Dir!

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

Edgar C. schrieb:
> Ja, mach mich nur neidisch, LOL! Das Vorinitialisieren habe ich
> probiert. Es kommen trotzdem nur Nullen raus.

Ich probiere mal, noch eine Funktion einzubauen, um ein paar Zeichen zu 
füllen (mittels des Mäuseklaviers am Demo-Board), danach kann ich dir 
das Projekt gern zum Vergleichen mal geben.

[PCB (Gast)]

Gut, ich habe bisher nur mit icecube2 gearbeitet, da hatte ich keine 
Probleme mit instaziierten EBRs.

In den einem Dokument zur Migration von icecube2 nach Radiant steht 
aber, dass es in Radiant einen Wizard gibt, der dir instaziierbaren Code 
erzeugt.
Hast du das mal ausprobiert?

[Edgar C. (ec-develo)]

Jörg W. schrieb:
> Edgar C. schrieb:
>> Ja, mach mich nur neidisch, LOL! Das Vorinitialisieren habe ich
>> probiert. Es kommen trotzdem nur Nullen raus.
>
> Ich probiere mal, noch eine Funktion einzubauen, um ein paar Zeichen zu
> füllen (mittels des Mäuseklaviers am Demo-Board), danach kann ich dir
> das Projekt gern zum Vergleichen mal geben.

Ich kann dir auch gerne eines meiner Boards zuschicken, falls dir das 
nicht zu aufdringlich ist. Zum Behalten oder gegen Erstattung der 
Rückversandkosten, natürlich. Vielleicht ist ja auch irgendwas 
Konzeptionelles faul, obwohl es trivial aufgebaut ist und ansonsten 
alles problemlos läuft.

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

Edgar C. schrieb:
> Ich kann dir auch gerne eines meiner Boards zuschicken, falls dir das
> nicht zu aufdringlich ist.

Ist es mir nicht - ich bin allerdings auf diesem Gebiet totaler 
Anfänger. Hatte mir das Demo-Board von denen gekauft, weil es relativ 
preiswert ist und dennoch ein vergleichsweise modernes FPGA beinhaltet.

Wir können gern auch beiden machen. Mein Code ist wirklich kein 
Geheimnis.

[Edgar C. (ec-develo)]

PCB schrieb:
> Gut, ich habe bisher nur mit icecube2 gearbeitet, da hatte ich keine
> Probleme mit instaziierten EBRs.
>
> In den einem Dokument zur Migration von icecube2 nach Radiant steht
> aber, dass es in Radiant einen Wizard gibt, der dir instaziierbaren Code
> erzeugt.
> Hast du das mal ausprobiert?

Ja, aber das ist schon ein paar Tage her und ich werde es morgen noch 
mal ausführlich testen. Danke dir!

[PCB (Gast)]

Weiter oben dein VHDL-Code, wo du auch die Bilder von der Simulation 
abgehängt hast, kann zumindest mit den EBRs nicht funktionieren.

Die EBRs sind ein sogenannter Pseudo-Dual-Port-RAM.
Du hast einen Lese- und einen Schreibport die beide jeweils einen 
eigenen Adress- und Datenbus besitzen.
Du kannst beide Ports sogar mit unterschiedlichen Takten ansteuern.
Damit es keine Konflikte gibt, musst du dafür sorgen, dass am Lese- und 
am Schreibport zum selben Zeitpunkt nicht dieselbe Adresse anliegt!
Weil ansonsten nicht sicher ist, ob beim Lesen die korrekten Daten 
rausfallen.

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

PCB schrieb:
> Damit es keine Konflikte gibt, musst du dafür sorgen, dass am Lese- und
> am Schreibport zum selben Zeitpunkt nicht dieselbe Adresse anliegt!

Das ist ja aber nicht sein primäres Problem, sondern er bekommt ja nicht 
einmal völlig ohne Schreibvorgänge die Initialdaten aus seinem Speicher 
raus.

[PCB (Gast)]

Gibts denn irgendwelche neuen Erkenntnisse?

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

PCB schrieb:
> Gibts denn irgendwelche neuen Erkenntnisse?

Erstmal nur die, dass ich auf dem Board des TE bislang einen ROM auch 
noch nicht zum Laufen bekommen habe. :-/  Er hat aber gerade mächtig 
anderweitig zu tun, und ich muss natürlich nun noch einkreisen, woran 
das genau liegen könnte. Offensichtlich ist es jedenfalls erstmal nicht 
…

[Edgar C. (ec-develo)]

Jörg W. schrieb:
> PCB schrieb:
>> Gibts denn irgendwelche neuen Erkenntnisse?
>
> Erstmal nur die, dass ich auf dem Board des TE bislang einen ROM auch
> noch nicht zum Laufen bekommen habe. :-/  Er hat aber gerade mächtig
> anderweitig zu tun, und ich muss natürlich nun noch einkreisen, woran
> das genau liegen könnte. Offensichtlich ist es jedenfalls erstmal nicht
> …

Jepp. Umzugskartons packen sich leider nicht von alleine :-)

Aber ich konnte es nicht sein lassen, bin gerade kurz zur Firma und habe 
Oskar und Lötkolben geschwungen. Leider wieder erfolglos.

Ich habe mir, wie besprochen, die Spannungsversorgung angeschaut.

Beide Spannungen (1,2V und 3,3V) laufen recht sauber hoch und sind 
stabil.
Allerdings war das FPGA nicht geladen und es lief kein Takt. Das werde 
ich morgen testen.

Ich habe die 3V3 mit einem Ferrit Bead und einem fetten 47uF am Eingang 
des Reglers gegenüber den 1V2 leicht verzögert. Die 1V2 laufen also 
zuerst hoch, bei ca. 0,5V beginnt auch die 3V3 zu steigen.

Laut Datenblatt ist das so empfohlen. Es gibt sogar noch eine weitere 
Bedingung in der Reihenfolge der I/O-Spannungen. Allerdings wird kein 
Grund dafür angegeben. Ein Hinweis auf den Grund findet man in dem User 
Guide für das Lattice-eigene Evalboard "iCE40 UltraPlus Breakout Board". 
Dort steht auf Seite 11:

The power supplies on the iCE40 UltraPlus Breakout Board are simplified 
and suitable for booting from the external SPI flash. The power supply 
sequencing does not conform to the NVCM boot requirements as specified 
in DS1056, iCE40 UltraPlus Family Data Sheet. The user may encounter 
intermittent boot success and/or higher than specified startup
currents when attempting to boot from NVCM.

Auf diesem Board wird ein Doppel-Spannungsregler verwendet, dessen 
Regler unabhängig voneinander betrieben werden. Also ebenfalls kein 
Sequencing.

Das NVCM rühre ich nicht an. Ich benutze direkte Programmierung bzw ein 
SPI-Flash.

To be continued.

[Edgar C. (ec-develo)]

Tagesupdate

Jörg war so freundlich, einen Sekundenzähler in VHDL zu schreiben, 
dessen aktueller Stand auf dem 7-Segment-Display meines Testboards 
ausgegeben wird.

Wird der Hex zu 7-Segment-Dekoder als case-Anweisung implementiert, 
funktioniert die Schaltung klaglos. Wird er als Tabelle in einem EBR Ram 
(Rom) abgelegt, funktioniert die Schaltung nur, wenn man das Bitfile ins 
Flash brennt und das FPGA sich daraus selbst konfiguriert.

Schreibt man das selbe Bitfile direkt ins FPGA, bleibt die Anzeige 
dunkel.

Beim case geht beides.

Weh Tee Eff?

Nun muss ich mir das Config-Inteface einmal unter die Lupe nehmen.

In jedem einzelnen Fall geht das Config Done Flag auf aktiv, das sagt 
mir die Led, die daran hängt. Ich achte stets darauf, denn zumindest bei 
Xilinx heißt das, dass sowohl die Anzahl der Clocks/Bits als auch die 
Prüfsumme in Ordnung waren.

Ob das bei Lattice auch so ist, muss ich nun raus suchen.

Und dann muss ich einmal schauen, ob ich den Effekt auch bei meinen 
eigenen Designs sehe.

[Mampf F. (mampf)]

Edgar C. schrieb:
> Schreibt man das selbe Bitfile direkt ins FPGA, bleibt die Anzeige
> dunkel.

Wie genau machst du das? Ich kenne leider deine Hardware und deinen 
Programmer nicht ...

[Edgar C. (ec-develo)]

Mampf F. schrieb:
> Edgar C. schrieb:
>> Schreibt man das selbe Bitfile direkt ins FPGA, bleibt die Anzeige
>> dunkel.
>
> Wie genau machst du das? Ich kenne leider deine Hardware und deinen
> Programmer nicht ...

Ich habe mir ein eigenes Eval-Board gebaut auf dem neben Schaltern, 
Taster, Leds und Siebensegmentanzeigen hauptsächlich ein ICE40UP5k-SG48, 
ein FT2232D und ein Flash-Baustein drauf sind. Die Verdrahtung und die 
logische Teilschaltung siehst du in den ersten drei angehängten Bildern.

Der Stand meiner Messungen und Erkenntnisse der letzten beiden Abende:

1. Ich denke, dass Radiant stets korrekte Schaltungen synthetisiert
2. Das Problem liegt offenbar in der Konfiguration

Ich bin blauäugig davon ausgegangen, dass der Radiant Programmer, also 
die Software von Lattice, meinen FT2232D erkennt. Tut er auch irgendwie. 
Allerdings eignet sich die D-Type nicht, um 6MHz auf SCK auszugeben und 
das ist die Defaulteinstellung. Ich habe also die ganze Zeit einen 
Sägezahn als SCK gehabt und es ist ein Wunder und ein Unglück dazu, dass 
überhaupt etwas im FPGA ankam. (ICY40_TCK_Clock_Default.gif)

Zum Glück gibt es eine Option im Programmer "Programming Speed Settings"
Damit bekommt man eine ordentliche Clock von z.B. 1 MHz hin 
(ICY40_TCK_Divided_by_6.gif) und auf den ersten Blick schienen mir auch 
die Daten zu den Flanken zu passen. (ICY40_Data_to_FPGA_vs_TCK.gif) 
(ICY40_Data_from_FPGA_vs_TCK.gif)

Auch die Integrität aller Signale ist ok.

Allerdings zeigt FPGA-TN-02001-3.2 iCE40 "Programming and Configuration" 
vom März dieses Jahres etwas grundlegend anderes, als ich an meiner 
Schaltung messe (ICY40_Start_of_Configuration.gif) 
(FPGA-TN-02001-3.2__SPI_Peripheral_Mode_Configuration.gif)

So ist bei mir der Ruhepegel der Clock Null statt Eins und während des 
SPI_SS - High-Pulses kommen keine 8 dummy clocks.

Und was soll ich sagen... es funktioniert immer noch nicht. Programmiert 
man das CRAM mit "Fast Configuration", geht CDONE auf high, aber die 
Schaltung mit den EBRs funktioniert nicht. Programmiert man das CRAM mit 
"Program, Verify", kotzt er nur eine Fehlermeldung aus.

Ich denke, ich werde als Nächstes bei Lattice nachfragen, ob der FT2232D 
überhaupt unterstützt wird.

[PCB (Gast)]

Der Programmer von Lattice arbeitet auch mit einem FTDI-Chip. Ich kann 
dir aber gerade nicht sagen mit welchem.

[PCB (Gast)]

Aprospros, bekommt dein FPGA eigentlich einen Takt von außen?

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

PCB schrieb:
> Ich kann dir aber gerade nicht sagen mit welchem.

FT2232H - das ist Edgar schon bewusst. ;-) Er nahm nur an, dass es in 
erster Linie auf die in den FTDIs verbaute MPSSE ankommt, nicht auf den 
tatsächlichen Chip, daher hat er einen FT2232D benutzt.

PCB schrieb:
> Aprospros, bekommt dein FPGA eigentlich einen Takt von außen?

Nö, arbeitet mit dem internen Taktgenerator. Reicht für diese einfachen 
Anwendungen (ist ja ein Lehr- und Spiel-Board) an sich auch.

[Edgar C. (ec-develo)]

Jörg W. schrieb:
> PCB schrieb:
>> Ich kann dir aber gerade nicht sagen mit welchem.
>
> FT2232H - das ist Edgar schon bewusst. ;-) Er nahm nur an, dass es in
> erster Linie auf die in den FTDIs verbaute MPSSE ankommt, nicht auf den
> tatsächlichen Chip, daher hat er einen FT2232D benutzt.

Ganz genau ;-)

>
> PCB schrieb:
>> Aprospros, bekommt dein FPGA eigentlich einen Takt von außen?
>
> Nö, arbeitet mit dem internen Taktgenerator. Reicht für diese einfachen
> Anwendungen (ist ja ein Lehr- und Spiel-Board) an sich auch.

Ebenfalls ;-)

Wie ich gerade gesehen habe, kann man die Stromtreiberfähigkeit der 
FTDI-Ausgänge im angeschlossenen EEPROM separat für die beiden Ports A 
und B einstellen. Per Default liefern sie 4mA je Ausgang, ich habe sie 
für Port A auf 12mA umgestellt und nach einem Powercycle sieht die Clock 
selbst bei 6MHz halbwegs akzeptabel aus.

Sonst hat sich aber nichts geändert.

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

Ja, das hatte ich auch schon probiert.

Naja, im Zweifelsfalle muss man halt den Umweg über den SPI-Flash gehen.

Jetzt muss ich nur noch iceprog (aus der "icestorm"-Suite) dazu bringen, 
dass es mit deinem Flash zurecht kommt; mit dem des 
Lattice-Breakout-Boards hat es kein Problem. Der Radiant-Programmer 
unter Linux funktioniert schlicht gar nicht (das "Program"-Icon bleibt 
immer ausgegraut), sodass ich bislang immer noch eine Extrarunde über 
Windows drehen muss. Zusätzlicher Vorteil: während der 
Lattice-Programmer erstmal eine Ewigkeit seinen "Dödelbalken" hin und 
her schiebt, legt iceprog sofort los und ist nach wenigen Sekunden 
fertig.

[PCB (Gast)]

Jörg W. schrieb:
> PCB schrieb:
>> Aprospros, bekommt dein FPGA eigentlich einen Takt von außen?
>
> Nö, arbeitet mit dem internen Taktgenerator. Reicht für diese einfachen
> Anwendungen (ist ja ein Lehr- und Spiel-Board) an sich auch.

Der interne Takt soll aber nicht so genau sein.

Ich habe mal einen Auszug von dem Schaltplan von meinem Board 
angehangen.
Vielleicht hilft das ja weiter.

In meinem Design hatte ich selber mal das Problem, dass das Ziehen von 
CRESET_B auf '0' beim Hochfahren dazu geführt hat, dass sich das FPGA 
nur in sehr wenigen Fällen das Image aus dem Flash geholt hat.

Ebenso hatte ich auch Startup Probleme, wo es nur sehr schwierig 
einzugrenzen war, dass es am VHDL-Code lag.

[Edgar C. (ec-develo)]

PCB schrieb:
> Jörg W. schrieb:
>> PCB schrieb:
>>> Aprospros, bekommt dein FPGA eigentlich einen Takt von außen?
>>
>> Nö, arbeitet mit dem internen Taktgenerator. Reicht für diese einfachen
>> Anwendungen (ist ja ein Lehr- und Spiel-Board) an sich auch.
>
> Der interne Takt soll aber nicht so genau sein.
>
> Ich habe mal einen Auszug von dem Schaltplan von meinem Board
> angehangen.
> Vielleicht hilft das ja weiter.
>
> In meinem Design hatte ich selber mal das Problem, dass das Ziehen von
> CRESET_B auf '0' beim Hochfahren dazu geführt hat, dass sich das FPGA
> nur in sehr wenigen Fällen das Image aus dem Flash geholt hat.
>
> Ebenso hatte ich auch Startup Probleme, wo es nur sehr schwierig
> einzugrenzen war, dass es am VHDL-Code lag.

Ja, Danke dir! Im Prinzip ist meine Verschaltung genau so.

Der Takt soll laut Lattice bei jedem Device recht stabil sein, aber 
zwischen den einzelnen Devices soll es +/- 10% Differenz geben. Sprich, 
ein FPGA, das mit 48,000 MHz läuft, tut dies recht stabil, wohingegen 
ein anderes recht stabil mit 50 MHz läuft.

Da mein Board nur eine einzige Schnittstelle nach außen hat, nämlich die 
Serielle, bestimmt auch sie die Anforderungen an das Timing. Und da 
hatte ich vor, mich auf 115,2 kbaud zu begrenzen und 
Exemplar-Abweichungen wegzukalibrieren.

[Edgar C. (ec-develo)]

Jörg W. schrieb:
> Ja, das hatte ich auch schon probiert.
>
> Naja, im Zweifelsfalle muss man halt den Umweg über den SPI-Flash gehen.

Und mit den 12mA-Treibern, Default Clock Divider (also 6MHZ) und dem 
Umweg über das Flash, funktioniert jetzt auch endlich eines meiner 
eigenen Designs mit EBRs.

Oh Happy Day :-)

Erst einmal vielen Dank an alle, die sich um mein Thema bemüht haben. 
Ein besonders großes Dankeschön an Jörg, natürlich.

Ich werde trotzdem noch bei Lattice nachhaken und hier berichten, was an 
Feedback von denen kommt.

[Edgar C. (ec-develo)]

Jörg W. schrieb:

> Jetzt muss ich nur noch iceprog (aus der "icestorm"-Suite) dazu bringen,
> dass es mit deinem Flash zurecht kommt;

Aha? Kann das iceprog denn auch cram direkt beschreiben?

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

Edgar C. schrieb:

> Aha? Kann das iceprog denn auch cram direkt beschreiben?

Ja, auf dem Breakout-Board klappt das.

Gut, ob's mit dem FT2232D (statt des 2232H) klappen wird, kann ich dir 
natürlich noch nicht sagen :), aber es sollte ja zumindest mit dem Flash 
auch auf deinem Board irgendwie funktionieren, nicht nur auf dem von 
Lattice.

Da bin ich gerade dran, icestorm hatte mich sowieso schon interessiert.

[Edgar C. (ec-develo)]

Jörg W. schrieb:
> Edgar C. schrieb:
>
>> Aha? Kann das iceprog denn auch cram direkt beschreiben?
>
> Ja, auf dem Breakout-Board klappt das.
>
> Gut, ob's mit dem FT2232D (statt des 2232H) klappen wird, kann ich dir
> natürlich noch nicht sagen :), aber es sollte ja zumindest mit dem Flash
> auch auf deinem Board irgendwie funktionieren, nicht nur auf dem von
> Lattice.
>
> Da bin ich gerade dran, icestorm hatte mich sowieso schon interessiert.

Cool. Ein Test mit 12mA-Ausgängen und CRAM direkt könnte zeigen, ob es 
an dem Algorithmus der Radiant Programmer-SW liegt.

[PCB (Gast)]

Habe nicht so ganz verstanden, was jetzt das Problem war und wie du es 
lösen konntest.
Bin gerade selber dabei, mein altes Design zu erweitern und werde vom 
ICE5LP1K auf den ICE40HX4K umsteigen.
Die Unterschiede zwischen den verschiedenen Typen der ice40-Serie sind 
ja nicht ganz so groß.

[Edgar C. (ec-develo)]

PCB schrieb:
> Habe nicht so ganz verstanden, was jetzt das Problem war und wie du es
> lösen konntest.

Kann ich nachvollziehen ;-)


Kurz zusammengefasst...

1. Das Signal SPI_CLK vom FT2232D war unbrauchbar. Die Ursache ist klar 
und es gibt eine Lösung.

Ursache war die geringe Treiberleistung von 4mA in Verbindung mit der 
Default-Frequenz von 6 MHz.

Die Treiberleistung konnte mittels FTProg im EEProm auf 12mA umgestellt 
werden.

Nun ist die Clock korrekt, das Flash kann zuverlässig programmiert 
werden und das FPGA bootet zuverlässig daraus.

Verwirrend war, dass manche Designs trotzdem liefen und manche nicht.

2. Noch ungeklärt ist, warum der direkte Download in das CRAM trotz der 
korrigieren Clock nicht funktioniert.

Das, was der Oskar aufzeichnet, ist nicht das, was laut TN-02001-3.2 zu 
sehen sein sollte. So ist die Ruhelage der Clock invertiert und es 
fehlen Clockpulse vor dem eigentlichen Bitstrom.


Das liegt aber ausschließlich in der Hand der Radiant-Programmer-SW.

[PCB (Gast)]

Ah OK :)

Wird dein FPGA eigentlich vom Diamond Programmer unterstützt?

Und könnte das mit dem CRAM daran liegen, dass du dafür eventuell MISO 
und MOSI vertauschen musst?
Ich meine, dass du ja quasi den Flash und das FPGA am SPI-Bus hängen 
hast und du kannst entweder den Flash direkt über den Programmer 
programmieren oder das FPGA.

Ich muß zugeben, dass ich bisher glaube immer nur den Flash programmiert 
habe und wundere mich gerade, ob das überhaupt funktionieren kann, wenn 
das FPGA und der Flash an derselben Chip-Select-Leitung hängen.

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

PCB schrieb:
> ob das überhaupt funktionieren kann, wenn das FPGA und der Flash an
> derselben Chip-Select-Leitung hängen.

Das funktioniert mit diesen lustigen "kreuz und quer"-Jumpern. Steckst 
du sie so

   o===o

   o===0

hast du eine Variante, steckst du sie so

   o   o
   I   I
   I   I
   o   o

die andere.

Macht das Lattice-Breakout-Board auch so.

[PCB (Gast)]

Für mich ist Zeit fürs Wochenende :D

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

Edgar C. schrieb:
> Aha? Kann das iceprog denn auch cram direkt beschreiben?

Gerade mal auf dem Breakoutboard meinen BAS-Generator nochmal getestet: 
ja, der funktioniert tatsächlich (und damit er das tut, muss auch EBR 
klappen), und das iceprog braucht laut Logicanalyzer gerade mal 170 ms, 
um das komplette Design in den RAM zu laden. :-o

Dagegen rödelt der Radiant Programmer ja endlos durch die Kante …

[Edgar C. (ec-develo)]

Jörg W. schrieb:
> Edgar C. schrieb:
>> Aha? Kann das iceprog denn auch cram direkt beschreiben?
>
> Gerade mal auf dem Breakoutboard meinen BAS-Generator nochmal getestet:
> ja, der funktioniert tatsächlich (und damit er das tut, muss auch EBR
> klappen), und das iceprog braucht laut Logicanalyzer gerade mal 170 ms,
> um das komplette Design in den RAM zu laden. :-o
>
> Dagegen rödelt der Radiant Programmer ja endlos durch die Kante …

Sieht so aus, als würde er immer wieder alle möglichen Ports nach 
Programmern absuchen, bevor er loslegt :-(

Ich habe noch eine Bitte... könntest du mein Board mit FTProg mal auf 
12mA updaten (falls du es noch nicht getan hast) und dann das Bitfile 
deines ICY_BLINK !!mit!! EBR per iceprog direkt in das CRAM laden?

Wenn das funktioniert, hätte ich noch ein wenig argumentativen Stoff für 
meine Anfrage bei Lattice.

> klappen), und das iceprog braucht laut Logicanalyzer

Hast du vielleicht auch einen Schrieb davon? Mich würde interessieren, 
ob das Protokoll des iceprog der Lattice-TN entspricht.

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

Das iceprog kommt derzeit mit deinem Board noch gar nicht klar. Ich 
möchte es zumindest gern für den Flash aber hinbekommen (da der ja mit 
dem Lattice-Programmer funktioniert). Wenn es dann auch noch mit CRAM 
geht, wäre das natürlich noch besser.

Einen LA-Trace von einem CRAM-Upload auf das Breakout-Board kann ich dir 
geben. Ist mit einem Saleae gemacht, aber selbst wenn du den nicht hast, 
deren Software kann man frei runterladen, dort kannst du dir den 
reinziehen.

[Christoph Z. (christophz)]

Jörg W. schrieb:
> Ist mit einem Saleae gemacht

Falls du mal ein paar mehr Features und mehr Protokolldekoder möchtest:
https://sigrok.org/

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

So, nun die Auflösung des Knotens.

iceprog benutzt zwei Features des FT2232H, die beim D nicht unterstützt 
sind. Das erste ist, dass sie (obwohl das der Default ist), explizit den 
1:5 Vorteiler für den Takt aktivieren. Das hat natürlich beim D gar 
keinen Sinn, führt aber dazu, dass ab diesem Moment alles durcheinander 
kommt.

Nachdem ich diese Aktion auf die H-Chips eingeschränkt habe, 
funktionierte Flash-Upload im iceprog (also gleiche Situation wie im 
Radiant).

Das zweite sind offenbar die "(mindestens) 49 Dummy Bits" am Ende. Um 49 
Bits zu senden, wurde beim iceprog (und möglicherweise auch bei Radiant) 
auf die Dummy-Kommandos 0x8E/0x8F zurück gegriffen, die es wiederum auch 
nur bei den H-Chips von FTDI gibt. Dabei ist die Lösung ganz einfach: 
man sendet 7 komplette Bytes und damit halt 56 Bits. Macht das Kraut 
nicht fett, aber danach geht's auch mit dem D-Chip und CRAM-Upload. Auch 
mit vollen 6 MHz, trotz der etwas „schrägen“ Signalformen, die Edgar 
dokumentiert hat.

[Christoph Z. (christophz)]

Jörg W. schrieb:
> So, nun die Auflösung des Knotens.

Gratulation und Hut ab vor eurer Hartnäckigkeit in  der Freizeit!

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

Jörg W. schrieb:
> und möglicherweise auch bei Radiant

Ein USB-Trace zeigt, dass der Radiant-Programmer exzessiv das Kommando 
0x8F benutzt. Damit dürfte der FT2232D bei ihnen schlicht und ergreifend 
"unsupported" sein.

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

Christoph Z. schrieb:
> Gratulation und Hut ab vor eurer Hartnäckigkeit in  der Freizeit!

Naja, reverse engineering von Kommunkationsprotokollen habe ich ja auch 
bei AVRs schon genügend gemacht. ;-)

Es war einfach zu schade um Edgars schöne Entwicklungsplattform. Ich 
finde, er hat sich da eine schöne FPGA-Lernplattform geschaffen, auf der 
ein FPGA-Anfänger allerlei Krams findet, um mit mehr als nur ein paar 
Simulationen loslegen zu können.

[Edgar C. (ec-develo)]

Jörg W. schrieb:
> Christoph Z. schrieb:
>> Gratulation und Hut ab vor eurer Hartnäckigkeit in  der Freizeit!
>
> Naja, reverse engineering von Kommunkationsprotokollen habe ich ja auch
> bei AVRs schon genügend gemacht. ;-)
>
> Es war einfach zu schade um Edgars schöne Entwicklungsplattform. Ich
> finde, er hat sich da eine schöne FPGA-Lernplattform geschaffen, auf der
> ein FPGA-Anfänger allerlei Krams findet, um mit mehr als nur ein paar
> Simulationen loslegen zu können.

Danke für die Blumen, allerseits ;-) Und vor allem Danke an Jörg, der 
den Löwenanteil zum Knacken des Rätsels beigetragen hat.