FlipFlop initial value bei MachXO2?

[KaffeKocher (Gast)]

Hallo,

ich bin Anfänger und habe mich an einem UART versucht. Das hat auch 
soweit geklappt, nun wollte ich einen Ausgang einbauen, der informieren 
soll, ob das Schieberegister leer ist und die nächste Übertragung 
starten kann. Dazu habe ich ein Signal im UART angelegt (tx_empty), dass 
ein FlipFlop sein soll, den Ausgang davon herausgeführt und dieses 
Signal mit High initialisiert (Startzustand ist '1'). Jetzt passiert 
aber nichts mehr, die TopLevel Entity startet keine Übertragung mehr. Es 
scheint, dass tx_empty von Anfang an low ist.

uart.vhdl

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;
  
entity uart is
  generic (DATA_WIDTH: natural := 8; BAUDRATE: natural := 9600; CLOCKFREQ: natural := 1000000);
  port (
    clk: in std_logic;
    tx_data: in std_logic_vector(DATA_WIDTH-1 downto 0);
    tx_we: in std_logic;
    tx: out std_logic;
    tx_empty: out std_logic
  );
end uart;

architecture impl of uart is
  type state_t is (STATE_START, STATE_DATA, STATE_END);
  
  constant COUNTER_MAX: natural := CLOCKFREQ / BAUDRATE - 1;
  
  signal clk_counter: integer range 0 to COUNTER_MAX := 0;
  signal bit_counter: integer range 0 to DATA_WIDTH := 0;
  signal shift_register: std_logic_vector(DATA_WIDTH-1 downto 0) := (others => '0');
  signal state: state_t := STATE_START;
  signal tx_out: std_logic := '1';
  signal tx_empty_out: std_logic := '1';
begin
  tx <= tx_out;
  tx_empty <= tx_empty_out;
  
  process
  begin
    wait until rising_edge(clk);
    
    if state = STATE_START then
      if tx_we = '1' then
        tx_out <= '0';
      
        shift_register <= tx_data;
        
        tx_empty_out <= '0';
        
        clk_counter <= 0;
        bit_counter <= 0;
        
        state <= STATE_DATA;
      end if;
    elsif state = STATE_DATA then
      if clk_counter = COUNTER_MAX then
        clk_counter <= 0;
        
        if bit_counter = DATA_WIDTH then
          tx_out <= '1';
          state <= STATE_END;
        else
          tx_out <= shift_register(0);
          shift_register <= std_logic_vector(shift_right(unsigned(shift_register), 1));
          
          bit_counter <= bit_counter + 1;
        end if;
      else
        clk_counter <= clk_counter + 1;
      end if;
    else -- state = STATE_END
      if clk_counter = COUNTER_MAX then
        tx_empty_out <= '1';
        state <= STATE_START;
      else
        clk_counter <= clk_counter + 1;
      end if;
    end if;
  end process;
end impl;

toplevel.vhdl

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;

library work;
  use work.all;
  
entity test is
  port (tx: out std_logic; tx_empty_out: out std_logic);
end test;

architecture impl of test is
  signal clk: std_logic;
  signal tx_we: std_logic := '0';
  signal tx_empty: std_logic;
begin
  osc0: entity oscillator port map (clk => clk);
  uart0: entity uart generic map (DATA_WIDTH => 8, BAUDRATE => 9600, CLOCKFREQ => 2080000)
             port map (clk => clk, tx_data => "10100011", tx_we => tx_we, tx => tx, tx_empty => tx_empty);
             
  tx_empty_out <= tx_empty;
  
  process
  begin
    wait until rising_edge(clk);
    
    if tx_empty = '1' then
      tx_we <= '1';
    else
      tx_we <= '0';
    end if;
  end process;
end impl;

Danach habe ich die Bedingung in toplevel.vhdl rausgelassen und tx_we 
konstant auf '1' belassen, nun funktionierts. Ein Blick mit dem 
LogicAnalyzer bestätigt die Vermutung, dass tx_empty nicht den richtigen 
Startzustand hat. Aber warum? Aus tx_empty wird ein FlipFlop, das 
bestätigt auch die Netzliste. Oder werden non-zero initial ff values von 
MachXO2 gar nicht unterstützt? Ignoriert der Synthesizer den initialen 
Wert bei der Deklaration des Signals? Ich bin leider kein deut schlauer 
aus meiner Internetrecherche geworden, nur dass das nicht von allen 
FPGAs unterstützt wird. Achja ich nutze Lattice LSE zur Synthese. Bilder 
sind im Anhang.

Vielen Dank.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

KaffeKocher schrieb:
>  dass das nicht von allen FPGAs unterstützt wird
Es ist hier (abgesehen von Actels Antifuse FPGAs) eher die Toolchain, 
die Initwerte nicht unterstützt. Funktioniert es denn, wenn du die Logik 
invertierst (also 0=Frei)?

[KaffeKocher (Gast)]

Tatsächlich, beim invertierten Ausgang läuft er durch.
Also scheint es Lattice LSE nicht mitzumachen. Hab aber nichts in den 
Datenblättern gefunden, nur dass im HDL User Guide kein Gebrauch von 
Initialwerten gemacht wird.

[KaffeKocher (Gast)]

Jap habs nun ordentlich geändert nicht nur invertiert, gleiches 
Ergebnis. So läuft es jedenfalls. Der Startwert von tx ist allerdings 
auch nicht High sondern leider low. Die Toolchain ignoriert es einfach, 
leider nur ohne Warnung...

Aber warum sollte man so ein Feature nicht unterstützen, wo es doch der 
FPGA extra kann und es doch sehr nützlich ist? Vor allem toll, wenn man 
Unmengen an Komponenten hat, die ohne gar nicht funktionieren.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

KaffeKocher schrieb:
> Aber warum sollte man so ein Feature nicht unterstützen, wo es doch der
> FPGA extra kann
Welchen Synthesizer verwendest du?

[KaffeKocher (Gast)]

Lattice LSE in Diamond IDE (3.8).

http://www.latticesemi.com/Products/DesignSoftwareAndIP/FPGAandLDS/LatticeDiamond/LatticeSynthesisEngine.aspx

[Duke Scarring (Gast)]

KaffeKocher schrieb:
> Lattice LSE in Diamond IDE (3.8)
Test mal mit Synplify, das sollte doch auch dabei sein.

Duke

[KaffeKocher (Gast)]

Leider nur auf Windows, aber ich probiers trotzdem.

[Charles G. (Firma: Ingenieurbuero Gardiner) (cfgardiner)]

Meines Wissens unterstützen keine Synopsys Synthese Tools VHDL 
Initialwerte. Es muesste auch in den tausend Log Meldungen irgendwo so 
etwas stehen wie
"Warning: Initial values are not supported for synthesis"

Ob Initialwerte von den anderen Synthesetools unterstützt werden weiß 
ich nicht auswendig, portable im Sinne des "VHDL synthesisable subsets" 
ist es halt nicht.

Was du brauchst ist ein Reset Signal, egal ob synchron oder asynchron.

Es gibt natürlich auch andere Lösungen, z.B. einen Memory mit 
vordefinierten Inhalt definieren mit nur einem Bit, der beim loslaufen 
des Taktes seinen Inhalt invertiert, aber solche Lösungen sind meistens 
größer und umständlicher als ein einfacher Reset.

[Duke Scarring (Gast)]

Charles G. schrieb:
> Meines Wissens unterstützen keine Synopsys Synthese Tools VHDL
> Initialwerte
Das kann sein. Allerdings haben alle meine MachXO2-Designs keinen 
Reset und nutzen - teils intensiv - Initialwerte a la:

    signal config_array : config_array_t := default_config_array;
...
    constant config_c : config_type := (
        0      => to_slv( ident_gpio),
        1      => to_slv( no_reponse, 0),
        2      => std_ulogic_vector( to_unsigned( 8, 8)),
        others => default_slv8
    );
...
    config_array( 21) <= config_c;

Mir ist das bisher nur bei Altera Quartus und da speziell beim Debugging 
auf die Füsse gefallen:
Dort wird (ohne Meldung) die Logik invertiert, wenn der Initialwert 
gleich eins ist. Dann sehen die FSM-States und Flags im Debugger anders 
aus, als im Simulator...

Duke

[KaffeKocher (Gast)]

Also mit Synplify Pro tut es wie vorgesehen, tx und tx_empty sind bei 
t_0 high (siehe Bild).

Charles G. schrieb:
> Meines Wissens unterstützen keine Synopsys Synthese Tools VHDL
> Initialwerte. Es muesste auch in den tausend Log Meldungen irgendwo so
> etwas stehen wie
> "Warning: Initial values are not supported for synthesis"

Die gibt es auch, aber nur für das Schieberegister. Da hat er aber 
recht.

GSR will not be inferred because no asynchronous signal was found in the netlist.
WARNING - synthesis: Initial value found on instance \uart0/shift_register_i0_i0 will be ignored.
WARNING - synthesis: Initial value found on instance \uart0/shift_register_i0_i5 will be ignored.
WARNING - synthesis: Initial value found on instance \uart0/shift_register_i0_i1 will be ignored.
Applying 1.000000 MHz constraint to all clocks

Log ist im Anhang.

[Charles G. (Firma: Ingenieurbuero Gardiner) (cfgardiner)]

Entschuldige, aber das was du beschreibst ist gar kein Initialwert. Hier 
definierst du einen Constanten. Zuweisen tust du es erst später mit der 
Zeile
    config_array( 21) <= config_c;

Die Zuweisung ist vermutlich in einem Process oder ähnlich.

Bei der definition eines Constants muessen alle Elemente spezifiziert, 
sonst wäre es logischerweise kein Constant. Es ist nicht ganz das 
gleiche als was der OP machen will.

Was er machen will, ist schon bei einer signal Definition ein Initalwert 
zuweisen. DAS geht nicht. Ein FPGA/ASIC ist nun mal Ereignis gesteuert. 
Entweder ein Takt oder ein sonstiges Signal muss etwas auslösen. Als 
sonstiges gilt z.B. ein Reset Eingang. Woher soll das Synthese Tool 
sonst wissen welches Ereignis ein "lade InitialWert" auslösen soll? 
"FPGA Image von SPI laden fertig" ist dem Synthese Tool als Ereignis 
einfach nicht bekannt. Beim ASIC gibt es das sowieso nicht und die 
Synthese sollte hier agnostisch sein.

Der Zustand eines generischen FPGAs/ASICs unmittelbar nach dem Power-On, 
Lade-von-SPI etc. ist nun mal undefiniert. Dass bei den meisten FPGAs 
alle Flipflops den Wert '0' annehemen ist höchstens technologie bzw. 
herstellerbedingt. Annehemen kann (oder zumindest sollte) man es nicht.

Ausserdem, wenn du keinen sauberen Reset hast, kannst du nie und nimmer 
alles in einem definierten Zustand bringen ohne Power Cycle.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Charles G. schrieb:
> Was er machen will, ist schon bei einer signal Definition ein Initalwert
> zuweisen. DAS geht nicht.
Xilinx unterstützt Initialwerte schon seit geraumer Zeit (ISE 11 oder 
so). Und propagiert das komplette Weglassen des Resets z.B. im WP272.

> Dass bei den meisten FPGAs alle Flipflops den Wert '0' annehemen ist
> höchstens technologie bzw. herstellerbedingt. Annehemen kann (oder
> zumindest sollte) man es nicht.
Ja, man muss da offenbar noch immer den Synthesizer Users Guide in die 
Hand nehmen. Z.B. den auf Seite 69 unten:
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_1/ug901-vivado-synthesis.pdf

> Woher soll das Synthese Tool sonst wissen welches Ereignis ein "lade
> InitialWert" auslösen soll?
Der INIT-Pin am FPGA startet das Neuladen. Dorthin gehört der 
Reset-Taster. Und beim Laden wird in jedem SRAM-basierten FPGA sowieso 
jedes Flipflop "angefasst" und in einen definierten Zustand gebracht. 
Es ist also nur ein Problem der Toolchain (bis hin zum 
Bitstromgenerator), wenn sie es nicht kann.

KaffeKocher schrieb:
> Also mit Synplify Pro tut es wie vorgesehen, tx und tx_empty sind bei
> t_0 high (siehe Bild).
So kenne ich das auch, deshalb meine Frage nach dem Synthesizer. 
Allerdings meinte ich, dass die Lattice-Synthese das auch mal konnte. 
Arg neu ist die Technik ja nun nicht gerade. Immerhin haben wir das vor 
ewiger Zeit im Beitrag "Xilinx und die Resets" schon 
diskutiert...

[KaffeKocher (Gast)]

Lothar M. schrieb:
>> Woher soll das Synthese Tool sonst wissen welches Ereignis ein "lade
>> InitialWert" auslösen soll?
> Der INIT-Pin am FPGA startet das Neuladen. Dorthin gehört der
> Reset-Taster. Und beim Laden wird in jedem SRAM-basierten FPGA sowieso
> jedes Flipflop "angefasst" und in einen definierten Zustand gebracht.
> Es ist also nur ein Problem der Toolchain (bis hin zum
> Bitstromgenerator), wenn sie es nicht kann.

Ja so hab ich das auch verstanden und wollte mir jegliche Resetlogik 
sparen um weniger Ressourcen zu verbraten.

Im "Lattice Synthesis Engine for Diamond User Guide" kann ich leider 
nichts entdecken, außer dass BlockRAM so initialisiert werden kann, aber 
nichts über FlipFlops.

Zumindest hab ich schon mal die Info, dass alle Register genullt werden.

Are the registers in MachXO2 initialized to a known value after a re-configuration operation?

In MachXO2, during normal device power-up, all registers are initialized to zero.  The same is true for re-configuration operations.

http://www.latticesemi.com/en/Support/AnswerDatabase/2/6/6/2665.aspx

Vielleicht finde ich noch was...

[Charles G. (Firma: Ingenieurbuero Gardiner) (cfgardiner)]

KaffeKocher schrieb:
> Lothar M. schrieb:
>>> Woher soll das Synthese Tool sonst wissen welches Ereignis ein "lade
>>> InitialWert" auslösen soll?
>> Der INIT-Pin am FPGA startet das Neuladen. Dorthin gehört der
>> Reset-Taster. Und beim Laden wird in jedem SRAM-basierten FPGA sowieso
>> jedes Flipflop "angefasst" und in einen definierten Zustand gebracht.
>> Es ist also nur ein Problem der Toolchain (bis hin zum
>> Bitstromgenerator), wenn sie es nicht kann.
>
> Ja so hab ich das auch verstanden und wollte mir jegliche Resetlogik
> sparen um weniger Ressourcen zu verbraten.

Und wenn ich z.B. eine PC Steckkarte habe und ein Warm-Start machen 
will, soll dann auch jedes Mal das FPGA Image neu geladen werden nur um 
alles in einen definierten Zustand zu bringen? Da ist doch ein globales 
Reset Netz (GSR bei Lattice) deutlich einfacher (und schneller).

Wenn ich für Lattice entwickele interessiere ich mich auch nicht 
besonders dafür wie es Xilinx machen würde.

Die Synthese-Tool Hersteller haben in der Regel eher nach IEEE 1076.6 
"Standard for VHDL Register Transfer Level Synthesis" entwickelt und das 
ist nun mal eine Untermenge vom vollen VHDL Standard. Wenn man sein Code 
portabel (und nicht nur für Xilinx) schreiben will, gibt es halt gewisse 
Einschränkungen, mit denen man aber durchaus gut leben kann.

Und falls du dich mal von deinem Xilinx Biotop erfolgreich freigekämpft 
hast, wirdst du feststellen, dass so gut wie alle OEM EDA Tools ganz gut 
mit einer erprobten "Best Practice" zu bedienen sind.

>
> Im "Lattice Synthesis Engine for Diamond User Guide" kann ich leider
> nichts entdecken, außer dass BlockRAM so initialisiert werden kann, aber
> nichts über FlipFlops.

Wennn du deinen Baustein eine Reset Eingang spendierst und in allen 
Process Blöcken einen Reset Pfad einbaust, werden alle Flipflops 
automatisch mit dem GSR Netz verbunden. Je nachdem, ob der Reset Code 
einen Flipflop auf '0' oder '1' setzt wird GSR mit dem Set oder Reset 
Eingang verbunden.

Das globale GSR Netz wird dann von deinem Reset Pin angesteuert.

>
> Zumindest hab ich schon mal die Info, dass alle Register genullt werden.
>

> Are the registers in MachXO2 initialized to a known value after a 
> re-configuration operation?
> 
> In MachXO2, during normal device power-up, all registers are initialized 
> to zero.  The same is true for re-configuration operations.
>

>
> http://www.latticesemi.com/en/Support/AnswerDatabase/2/6/6/2665.aspx
>
> Vielleicht finde ich noch was...

[KaffeKocher (Gast)]

Verstehe, d.h. der GSR wäre auch der portable Weg und der GSR wird 
sowieso genutzt um die Register zu initialisieren.

Den GSR darf nach Lattice nur als asynchronen Reset genutzt werden, 
schaltet der FPGA dann auch die Taktquellen aus, damit nichts schief 
gehen kann?

Habe nun eine Resetleitung hinzugefügt (GSR instantiiert und mit "rst" 
Signal verbunden). Jetzt beschwert sich der Synthesizer:

using initial value 'U' for rst since it is never assigned. VHDL-1303

Und behauptet, dass sich die ganzen Register in der UART Komponente nie 
ändern...

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;
  
library machxo2;
  use machxo2.all;
  use machxo2.components.all;

library work;
  use work.all;
  
entity test is
  port (tx: out std_logic; tx_empty_out: out std_logic);
end test;

architecture impl of test is
  signal clk: std_logic;
  signal rst: std_logic;
  signal tx_we: std_logic;
  signal tx_empty: std_logic;
begin
  gsr0: GSR port map (gsr => rst);
  osc0: entity oscillator port map (clk => clk);
  uart0: entity uart generic map (DATA_WIDTH => 8, BAUDRATE => 9600, CLOCKFREQ => 2080000)
             port map (clk => clk, rst => rst, tx_data => "10100011", tx_we => tx_we, tx => tx, tx_empty => tx_empty);
             
  tx_empty_out <= tx_empty;
  
  process
  begin
    wait until rising_edge(clk);
    
    if tx_empty = '1' then
      tx_we <= '1';
    else
      tx_we <= '0';
    end if;
  end process;
end impl;

Muss ich den GSR mit einem Inputpin verbinden? So wie bei diesem 
Beispiel? Davon habe ich bisher aber nichts gelesen.
https://github.com/bugblat/pif/blob/master/firmware/common/flashctl.vhd

[KaffeKocher (Gast)]

To use the Global GSR usage case, a GSR component must be instantiated
in the design and connected to the signal that is targeted as the reset signal,
usually a primary input.

Ok, so wie ich das verstehe, muss das Netz noch zusätzlich mit einer 
Signalquelle verbunden werden.

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;
  
library machxo2;
  use machxo2.all;
  use machxo2.components.all;

library work;
  use work.all;
  
entity test is
  port (tx: out std_logic; tx_empty_out: out std_logic);
end test;

architecture impl of test is
  signal clk: std_logic;
  signal rst: std_logic;
  signal tx_we: std_logic;
  signal tx_empty: std_logic;
  
  attribute pullmode  : string;
  attribute pullmode of rst: signal is "UP";   -- else floats
begin
  gsr0: GSR port map (gsr => rst);
  osc0: entity oscillator port map (clk => clk);
  uart0: entity uart generic map (DATA_WIDTH => 8, BAUDRATE => 9600, CLOCKFREQ => 2080000)
             port map (clk => clk, rst => rst, tx_data => "10100011", tx_we => tx_we, tx => tx, tx_empty => tx_empty);
             
  tx_empty_out <= tx_empty;
  rst <= '1';
  
  process
  begin
    wait until rising_edge(clk);
    
    if tx_empty = '1' then
      tx_we <= '1';
    else
      tx_we <= '0';
    end if;
  end process;
end impl;

Jetzt sind die Warnungen zwar weg, aber es läuft leider noch nicht. Mach 
ich was beim UART Reset noch falsch?

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;
  
entity uart is
  generic (DATA_WIDTH: natural := 8; BAUDRATE: natural := 9600; CLOCKFREQ: natural := 1000000);
  port (
    clk: in std_logic;
    rst: in std_logic;
    tx_data: in std_logic_vector(DATA_WIDTH-1 downto 0);
    tx_we: in std_logic;
    tx: out std_logic;
    tx_empty: out std_logic
  );
end uart;

architecture impl of uart is
  type state_t is (STATE_START, STATE_DATA, STATE_END);
  
  constant COUNTER_MAX: natural := CLOCKFREQ / BAUDRATE - 1;
  
  signal clk_counter: integer range 0 to COUNTER_MAX := 0;
  signal bit_counter: integer range 0 to DATA_WIDTH := 0;
  signal shift_register: std_logic_vector(DATA_WIDTH-1 downto 0) := (others => '0');
  signal state: state_t := STATE_START;
  signal tx_out: std_logic := '1';
  signal tx_empty_out: std_logic := '1';
begin
  tx <= tx_out;
  tx_empty <= tx_empty_out;
  
  process (clk, rst)
  begin
    --wait until rising_edge(clk);
    if rising_edge(clk) then
    
      if state = STATE_START then
        if tx_we = '1' then
          tx_out <= '0';
        
          shift_register <= tx_data;
          
          tx_empty_out <= '0';
          
          clk_counter <= 0;
          bit_counter <= 0;
          
          state <= STATE_DATA;
        end if;
      elsif state = STATE_DATA then
        if clk_counter = COUNTER_MAX then
          clk_counter <= 0;
          
          if bit_counter = DATA_WIDTH then
            tx_out <= '1';
            state <= STATE_END;
          else
            tx_out <= shift_register(0);
            shift_register <= std_logic_vector(shift_right(unsigned(shift_register), 1));
            
            bit_counter <= bit_counter + 1;
          end if;
        else
          clk_counter <= clk_counter + 1;
        end if;
      else -- state = STATE_END
        if clk_counter = COUNTER_MAX then
          tx_empty_out <= '1';
          state <= STATE_START;
        else
          clk_counter <= clk_counter + 1;
        end if;
      end if;
    end if;
    
    if rst = '0' then
      clk_counter <= 0;
      bit_counter <= 0;
      shift_register <= (others => '0');
      state <= STATE_START;
      tx_out <= '1';
      tx_empty_out <= '1';
    end if;
  end process;
end impl;

[Charles G. (Firma: Ingenieurbuero Gardiner) (cfgardiner)]

KaffeKocher schrieb:
> Verstehe, d.h. der GSR wäre auch der portable Weg und der GSR wird
> sowieso genutzt um die Register zu initialisieren.

Im prinzip ja. Auf dem Lattice Silizium gibt es ein globales Netz (GSR), 
das an jeden Flipflop geführt wird, ähnlich wie ein Taktnetz. 
Typischerweise wird das als asynchroner Reset verwendet. Sofern Resets 
verwendet werden, tut die Synthese das Reset mit dem höchsten Fanout dem 
GSR Netz zuordnen. Ob das Netz mit dem Set oder Reset Eingang eines 
bestimmten Flipflops verbunden wird hängt von deinem VHDL code ab.

z.B. im folgenden Snippit wird der CLR Eingang vom Flipflop s_sig_1 
sowie der SET Eingang vom s_sig_2 mit i_rst_n verbunden  und über das 
GSR Netz geroutet. GSR wird zusätzlich mit dem Treiber vom i_rst_n Netz 
verbunden. Sinnvollerweise entweder ein physikalischer Baustein Pin oder 
eine interne Reset Statemaschine.

Process (i_clk, i_rst_n)
Begin
   if (i_rst_n = '0') then
      s_sig1  <= '0';
      s_sig_2 <= '1';
   elsif (rising_edge(i_clk)) then
      -- Functional code goes here
   end if;
End Process;


>
> Den GSR darf nach Lattice nur als asynchronen Reset genutzt werden,
> schaltet der FPGA dann auch die Taktquellen aus, damit nichts schief
> gehen kann?

Da ist vielleicht die Beschreibung nicht ganz deutlich. Richtig ist, nur 
die asynchrone SET bzw. CLR Flipflop Eingänge können Empfänger des GSR 
Netzes sein. Quelle (Treiber) des GSR Netzes kann aber beliebig sein so 
z.B. ein physikalischer Pin oder ein Flipflop in einer Reset State 
Maschine.

>
> Habe nun eine Resetleitung hinzugefügt (GSR instantiiert und mit "rst"
> Signal verbunden). Jetzt beschwert sich der Synthesizer:
>
>

> using initial value 'U' for rst since it is never assigned. VHDL-1303
>

>
> Und behauptet, dass sich die ganzen Register in der UART Komponente nie
> ändern...
>
>

> library ieee;
>   use ieee.std_logic_1164.all;
>   use ieee.numeric_std.all;
> 
> library machxo2;
>   use machxo2.all;
>   use machxo2.components.all;
> 
> library work;
>   use work.all;
> 
> entity test is
>   port (tx: out std_logic; tx_empty_out: out std_logic);
> end test;
> 
> architecture impl of test is
>   signal clk: std_logic;
>   signal rst: std_logic;
>   signal tx_we: std_logic;
>   signal tx_empty: std_logic;
> begin
>   gsr0: GSR port map (gsr => rst);
>   osc0: entity oscillator port map (clk => clk);
>   uart0: entity uart generic map (DATA_WIDTH => 8, BAUDRATE => 9600, 
> CLOCKFREQ => 2080000)
>              port map (clk => clk, rst => rst, tx_data => "10100011", 
> tx_we => tx_we, tx => tx, tx_empty => tx_empty);
> 
>   tx_empty_out <= tx_empty;
> 
>   process
>   begin
>     wait until rising_edge(clk);
> 
>     if tx_empty = '1' then
>       tx_we <= '1';
>     else
>       tx_we <= '0';
>     end if;
>   end process;
> end impl;
>

>

Mein Rat wäre die alternativ Syntax zu verwenden.
 process (rst_n, clk)
 begin
 if (rst_n = '0') then
 elsif (rising_edge(clk)) then
 end if;
 end proces;

An deinem Entity muss natürlich das rst Signal an einen Pin oder Reset 
FSM geführt werden.

> Muss ich den GSR mit einem Inputpin verbinden? So wie bei diesem
> Beispiel? Davon habe ich bisher aber nichts gelesen.

Nein, nicht persönlich. Die Verwendung des GSR Netzes wird inferiert. 
Deine Schaltung könnte theoretisch mehrere Resets haben. Wie oben 
erwähnt, das asynchrone Reset Signal mit dem höchsten Fanout wird über 
das GSR Netz geführt.

Es steht dann auch eine Meldung in der Log Datei welches Netz 
tatsächlich verwendet wird. Ich glaube es gibt schon eine möglichkeit 
ein bestimmtes Netz an GSR zuzuweisen wenn man das GSR Primitiv in seine 
Schaltung selber instanziiert. Das GSR Primitiv ist eine Zelle mit nur 
einem Eingang (der Eingang/Treiber zum GSR Netz, sozusagen). Somit kann 
man die standard Syntheseauswahl überstimmen.


> https://github.com/bugblat/pif/blob/master/firmware/common/flashctl.vhd

[KaffeKocher (Gast)]

Mit Resetpin/taster funktionierts ziemlich gut.

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;
  
library machxo2;
  use machxo2.all;
  use machxo2.components.all;

library work;
  use work.all;
  
entity test is
  port (rst: in std_logic; tx: out std_logic; tx_empty_out: out std_logic);
end test;

architecture impl of test is
  signal clk: std_logic;
  signal tx_we: std_logic;
  signal tx_empty: std_logic;
  
  --attribute pullmode  : string;
  --attribute pullmode of rst: signal is "UP";   -- else floats
begin
  gsr0: GSR port map (gsr => rst);
  osc0: entity oscillator port map (clk => clk);
  uart0: entity uart generic map (DATA_WIDTH => 8, BAUDRATE => 9600, CLOCKFREQ => 2080000)
             port map (clk => clk, rst => rst, tx_data => "10100011", tx_we => tx_we, tx => tx, tx_empty => tx_empty);
             
  tx_empty_out <= tx_empty;
  
  process
  begin
    wait until rising_edge(clk);
    
    if tx_empty = '1' then
      tx_we <= '1';
    else
      tx_we <= '0';
    end if;
  end process;
end impl;

Die Frage ist, passt das so (außer dass im toplevel noch ein Reset 
fehlt)?

[Charles G. (Firma: Ingenieurbuero Gardiner) (cfgardiner)]

Ich waage es zu bezweifeln, dass das funktioniert wie du willst.

Mit dieser Zeile
gsr0: GSR port map (gsr => rst);

hast du zwar ein Sender am GSR Netz aber ich erkenne nicht wie die 
Synthese die Empfänger erraten soll. Wie gesagt, GSR wird in Silizium zu 
jedem Flipflop geführt aber nicht zwingend mit jedem Flipflop verbunden. 
Ob es verbunden wird hängt davon ab, ob die Synthese eine asynchrone 
SET/CLR Aktion an einem Flipflop aus deinem HDL code erkennt. Es wäre 
mir neu, dass Synplify jetzt Empfänger aus dem Initialwert inferiert 
aber ich mache ja meine Reset Netze anders. Kann gut sein ich hab's nur 
nicht bemerkt.

Die synplify docu für Lattice steht unter 
C:\lscc\diamond\3.8_x64\synpbase\doc z.B. (mehrere PDFs) da muesste es 
eigentlich drin stehen, ob Initialwerte unterstützt werden.

Noch ein Punkt, der interne Oszillator is relativ ungenau
osc0: entity oscillator port map (clk => clk);

Die Frequenz ist letzendlich vom Fertigungslos abhängig (Streuung kann 
gut mal 30% sein). Zum Üben, für Loopback oder wenn zwei UARTs im selben 
MachXO sind wird es vermutlich funktionieren aber nicht z.B. mit einem 
externen Mikrocontroller, oder jedenfalls nicht immer. Dafür bräuchtest 
du eine externe Taktquelle.

[KaffeKocher (Gast)]

Ich hab leider deinen Beitrag übersehen, du hast deinen kurz vor meinem 
abgesendet.

Also nun der aktuelle Stand.

toplevel.vhdl

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;
  
library machxo2;
  use machxo2.all;
  use machxo2.components.all;

library work;
  use work.all;
  
entity test is
  port (rst: in std_logic; tx: out std_logic; tx_empty_out: out std_logic);
end test;

architecture impl of test is
  signal clk: std_logic;
  signal tx_we: std_logic;
  signal tx_empty: std_logic;
begin
  gsr0: GSR port map (gsr => rst);
  osc0: entity oscillator port map (clk => clk);
  uart0: entity uart generic map (DATA_WIDTH => 8, BAUDRATE => 9600, CLOCKFREQ => 2080000)
             port map (clk => clk, rst => rst, tx_data => "10100011", tx_we => tx_we, tx => tx, tx_empty => tx_empty);
             
  tx_empty_out <= tx_empty;
  
  process (clk, rst)
  begin
    if rst = '0' then
      tx_we <= '0';
    elsif rising_edge(clk) then
      if tx_empty = '1' then
        tx_we <= '1';
      else
        tx_we <= '0';
      end if;
    end if;
  end process;
end impl;

uart.vhdl

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;
  
entity uart is
  generic (DATA_WIDTH: natural := 8; BAUDRATE: natural := 9600; CLOCKFREQ: natural := 1000000);
  port (
    clk: in std_logic;
    rst: in std_logic;
    tx_data: in std_logic_vector(DATA_WIDTH-1 downto 0);
    tx_we: in std_logic;
    tx: out std_logic;
    tx_empty: out std_logic
  );
end uart;

architecture impl of uart is
  type state_t is (STATE_START, STATE_DATA, STATE_END);
  
  constant COUNTER_MAX: natural := CLOCKFREQ / BAUDRATE - 1;
  
  signal clk_counter: integer range 0 to COUNTER_MAX;
  signal bit_counter: integer range 0 to DATA_WIDTH;
  signal shift_register: std_logic_vector(DATA_WIDTH-1 downto 0);
  signal state: state_t;
  signal tx_out: std_logic;
  signal tx_empty_out: std_logic;
begin
  tx <= tx_out;
  tx_empty <= tx_empty_out;
  
  process (clk, rst)
  begin
    if rst = '0' then
      clk_counter <= 0;
      bit_counter <= 0;
      shift_register <= (others => '0');
      state <= STATE_START;
      tx_out <= '1';
      tx_empty_out <= '1';
    elsif rising_edge(clk) then
      if state = STATE_START then
        if tx_we = '1' then
          tx_out <= '0';
        
          shift_register <= tx_data;
          
          tx_empty_out <= '0';
          
          clk_counter <= 0;
          bit_counter <= 0;
          
          state <= STATE_DATA;
        end if;
      elsif state = STATE_DATA then
        if clk_counter = COUNTER_MAX then
          clk_counter <= 0;
          
          if bit_counter = DATA_WIDTH then
            tx_out <= '1';
            state <= STATE_END;
          else
            tx_out <= shift_register(0);
            shift_register <= std_logic_vector(shift_right(unsigned(shift_register), 1));
            
            bit_counter <= bit_counter + 1;
          end if;
        else
          clk_counter <= clk_counter + 1;
        end if;
      else -- state = STATE_END
        if clk_counter = COUNTER_MAX then
          tx_empty_out <= '1';
          state <= STATE_START;
        else
          clk_counter <= clk_counter + 1;
        end if;
      end if;
    end if;
  end process;
end impl;

Die Netzliste sieht jetzt auch wesentlich besser aus. Set bzw. Reset 
sind nun mit dem GSR und dem Resetpin verbunden. Toplevel ist oben zu 
sehen, die Netzliste von UART ist ein bisschen zu groß geworden für ein 
Bild.

Charles G. schrieb:
> Die synplify docu für Lattice steht unter
> C:\lscc\diamond\3.8_x64\synpbase\doc z.B. (mehrere PDFs) da muesste es
> eigentlich drin stehen, ob Initialwerte unterstützt werden.

Ich schau eventuell noch mal nach, aber die GSR Lösung gefällt mir 
eigentlich recht gut.

Charles G. schrieb:
> Noch ein Punkt, der interne Oszillator is relativ ungenau
> osc0: entity oscillator port map (clk => clk);
>
> Die Frequenz ist letzendlich vom Fertigungslos abhängig (Streuung kann
> gut mal 30% sein). Zum Üben, für Loopback oder wenn zwei UARTs im selben
> MachXO sind wird es vermutlich funktionieren aber nicht z.B. mit einem
> externen Mikrocontroller, oder jedenfalls nicht immer. Dafür bräuchtest
> du eine externe Taktquelle.

Ja hab ich mir schon gedacht, war aber erst mal nur zum Üben. Ich nutze 
das MachXO2 Pico Board, da hat der FPGA leider keinen Quarz, wobei man 
höchstwahrscheinlich den Quarz vom FTDI IC auch nutzen kann. War bisher 
nur zu faul um nachzuschauen :)

Auf jeden Fall schon mal vielen Dank an alle!

[Holger (Gast)]

KaffeKocher schrieb:
> Ja hab ich mir schon gedacht, war aber erst mal nur zum Üben. Ich nutze
> das MachXO2 Pico Board, da hat der FPGA leider keinen Quarz, wobei man
> höchstwahrscheinlich den Quarz vom FTDI IC auch nutzen kann. War bisher
> nur zu faul um nachzuschauen :)
###################################
Pico Board habe ich auch, klasse Teil.
Ja klar geht das, hast du den Stromlaufplan von dem Pico Board.

Hast du schon mal versucht den Source Code von dem RefDesign des Pico 
Boards zu kompilen. Ich bekomme den für das Pico Board nicht gefittet, 
da der Speicher zu klein ist Typ 1200... . Somit ist das Lattice 
Ref.Design für das PicoBoard eigentlich zum Üben wertlos. So ein Mist 
aber auch.
Nur den orginal Refdesign BitFile kann ich da reinflaschen. Was denken 
die sich bei Lattice da nun dabei.

Gruss Holger.

[C. A. Rotwang (Gast)]

Lothar M. schrieb:

> Xilinx unterstützt Initialwerte schon seit geraumer Zeit (ISE 11 oder
> so). Und propagiert das komplette Weglassen des Resets z.B. im WP272.

Nein, vom kompletten Weglassen des resets steht nix in dem White Paper.


Da steht das man sich das globale Resetnetzwerk sparen kann, wenn man 
nur einzelne FF in den Reset schickt, also lokal. Synchronizer FF in den 
reset zwingen ist unnötig, bei FSM mag das anders aussehen. Deshalb ist 
das White Paper auch mit "Think Local, not Global" betitelt.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

C. A. Rotwang schrieb:
> Nein, vom kompletten Weglassen des resets steht nix in dem White Paper.
Es wird in diesem WP viel grundlegender gefragt, ob ein globaler Reset 
(Resetpin/Resettaster) überhaupt nötig ist. Und i.A. lautet die Antwort 
darauf: Nein!

Summary
A design implemented in a Xilinx FPGA does not require insertion of a global reset network.

Charles G. schrieb:
> Da ist vielleicht die Beschreibung nicht ganz deutlich. Richtig ist, nur
> die asynchrone SET bzw. CLR Flipflop Eingänge können Empfänger des GSR
> Netzes sein. Quelle (Treiber) des GSR Netzes kann aber beliebig sein so
> z.B. ein physikalischer Pin oder ein Flipflop in einer Reset State
> Maschine.
Und das ist es dann auch, was Altera analog zu Lattice empfiehlt: den 
Reseteingang nicht direkt auf einen Eingangspin, sondern erst mal in 
die jeweilige Taktdomäne eintakten, damit der Reset eben tatsächlich 
synchron inaktiv(!) wird.
Zu einem komplett asynchronen Reset sagt z.B. der Altera DRC folgendes:

Warning: (Medium) Rule R102: External reset signals should be synchronized using two cascaded registers.

... und zwar getaktet von der jeweiligen Taktdomäne der betroffenen 
Flipflops.

Und das ist der Knackpunkt: es gibt 1 einziges GSR Netz, dann geht das 
Einsynchronisieren auf 1 Takt problemlos. Lustig und interessant wird 
es, sobald eine zweite (unabhängige) Taktdomäne im FPGA werkelt. Denn 
die bräuchte zum synchronen Deaktivieren des Resets ja "ihr eigenes GSR" 
Netz... :-O

Letztlich ist diese "Sonderbehandlung" der Xilinx FPGA den umschaltbaren 
Flipflops geschuldet, die entweder snychron oder asynchron arbeiten 
können (Lattice und Altera können da eh' nur den asynchronen Modus). Es 
empfihelt sich also für optimale Performance, die Betrachtungen wie im 
Beitrag "Re: Hardware mit VHDL "richtig" beschreiben." oder im 
Xilixnx WP231 für "seine" Plattform kurz durchzuspielen.

[KaffeKocher (Gast)]

Holger schrieb:
> KaffeKocher schrieb:
>> Ja hab ich mir schon gedacht, war aber erst mal nur zum Üben. Ich nutze
>> das MachXO2 Pico Board, da hat der FPGA leider keinen Quarz, wobei man
>> höchstwahrscheinlich den Quarz vom FTDI IC auch nutzen kann. War bisher
>> nur zu faul um nachzuschauen :)
> ###################################
> Pico Board habe ich auch, klasse Teil.
> Ja klar geht das, hast du den Stromlaufplan von dem Pico Board.

Stimmt, das geht. Kurze Frage, der Quarz ist ja an so einem "dedicated 
clock pin" angeschlossen. Kann ich nun den Takt einfach direkt von dem 
Pin mithilfe eines Eingangs im Toplevel bekommen, der auf diesen Pin 
konfiguriert ist oder muss ich noch irgendwas instantiieren? So wie es 
für mich aussieht, geht das tatsächlich so einfach.

Holger schrieb:
> Hast du schon mal versucht den Source Code von dem RefDesign des Pico
> Boards zu kompilen. Ich bekomme den für das Pico Board nicht gefittet,
> da der Speicher zu klein ist Typ 1200... . Somit ist das Lattice
> Ref.Design für das PicoBoard eigentlich zum Üben wertlos. So ein Mist
> aber auch.

Nein habe ich noch nicht, aber ich kanns gerne mal ausprobieren, wo 
gibt's denn den Quellcode?

Hast du auch mal auf Größe optimieren lassen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

KaffeKocher schrieb:
> Kann ich nun den Takt einfach direkt von dem Pin mithilfe eines Eingangs
> im Toplevel bekommen
Ja, die Toolchain erkennt den Takt und fügt den nötigen Clockbuffer 
automatisch ein.

[KaffeKocher (Gast)]

Lothar M. schrieb:
> KaffeKocher schrieb:
>> Kann ich nun den Takt einfach direkt von dem Pin mithilfe eines Eingangs
>> im Toplevel bekommen
> Ja, die Toolchain erkennt den Takt und fügt den nötigen Clockbuffer
> automatisch ein.

Danke, manchmal kann es so einfach sein :)

[Holger (Gast)]

KaffeKocher schrieb:
> Nein habe ich noch nicht, aber ich kanns gerne mal ausprobieren, wo
> gibt's denn den Quellcode?
>
Allles dabei im RefDesign.. USART SPI_ROM TEMP_SENSOR
Link: Für den Zip.
http://www.latticesemi.com/alpha-mxo2-pico-kit#_C5AFA0531C10491E9706210E995C7F0F

Oben ist so ein Reiter_Menue_BAR .via Mouseklick ..kannst du noch den 
Pdf Doku Stuff da separat Downloaden.

> Hast du auch mal auf Größe optimieren lassen?

War ja ein fertiges Project ... via *.ldf Project File.
Da geht man davon aus das der so eingestellt ist, um das Project zu 
kompilen.

Gruss Holger.

[Holger (Gast)]

Holger schrieb:
> Oben ist so ein Reiter_Menue_BAR .via Mouseklick ..kannst du noch den
> Pdf Doku Stuff da separat Downloaden.

[Holger (Gast)]

@Kaffekocher hier mein Thread für Lattice PICO Board.
Beitrag "Lattice MachXo2 Bat.Powerd Stand Alone Soc"

Damit kann man prima lernen ... nur halt der Fitter packt das RefDesign 
nicht. Comiler geht.

Viel Erfolg .. Gruss Holger.

[Holger (Gast)]

@Kaffekocher
Hier.. so kannst du mit den ZIP Files lernen.
Gruss Holger.