Address Latch ohne Reset ohne Einsynchronisieren

Michael S1. schrieb:
> Funktioniert ein solches Address-Latch ohne Reset und ohne
> Einsynchronisieren des asynchronen Latch-Impulses störungsfrei?

Nein.
Denn es kann vorkommen, dass manche latched_address_o gelatcht werden, 
und manche nicht.

Hmm, warum?
Der latch Impuls ist doppelt so lang wie ein Systemclockzyklus.
Da sollte man beim Abtasten des latch_enable_i doch eigentlich immer 
einen 0/1 Übergang erwischen.

Was müsste man denn Deiner Meinung nach tun um es sicher zu machen?

Es werden für jedes latched_address_o und für last_latch_enable ein FF 
erzeugt.
Die FF für latched_address_o haben einen Dateneingang der wahrscheinlich 
stabil ist (ich nehme an, die Adressen liegen längere Zeit stabil an) 
und eine CE Eingang, der die Setup- oder Hold Zeit verletzt.
In diesem Fall kann das FF latched_address_o die Adresse übernehmen oder 
nicht.

Auch das FF für last_latch_enable verletzt die Setup- oder Holdzeit.
Falls es in diesem Fall aber das latch_enable übernimmt, aber 
latched_address_o nicht, dann wird latched_address_o bei der nächsten 
Taktflanke nicht mehr getriggert,

Michael S1. schrieb:
> Was müsste man denn Deiner Meinung nach tun um es sicher zu machen?

latch_enable_i einsynchronisieren.
Damit verzögert sich das ganze um einen Takt.
Es hängt jetzt von Deinem System ab, ob die Adressen lange genug stabil 
liegen, oder ob man diese auch abtakten muss.

Ich würde mal diesen Ansatz vorsehen:

1

entity address_latch is

2

    generic

3

    (

4

        width : integer := 16

5

    );

6

    port

7

    (

8

        clk_i             : in  std_logic;                           -- system clock (200Mhz)

9

        latch_enable_i    : in  std_logic;                           -- latch on rising edge (20ns wide pulse)

10

        address_data_i    : in  std_logic_vector(width-1 downto 0);  -- input data

11

        latched_address_o : out std_logic_vector(width-1 downto 0);   -- latched data

12

        latched_valid_o   : out std_logic -- active for one cycle if adress is valid

13

    );

14

end address_latch;

15

16

architecture address_latch_architecture of address_latch is

17

    signal latch_enable_sr : std_logic_vector(2); 

18

begin

19

20

    latched_adress_o <= address_data_i when rising_edge(latch_enable_i);

21

    latch_enable_sr  <= latch_enable_sr(0) & latch_enable_i  when rising_edge(clk_i);

22

    latched_valid_o  <= '1' when latch_enable_sr="01" else '0';

23

24

end address_latch_architecture;

Aber es gilt auf jeden Fall, was Klaus Falser schrieb im Beitrag 
#3295956:
> Damit verzögert sich das ganze um einen Takt.

Und wenn ich latched_address_o stabil haben möchte bis zum nächsten 
latch_enable_i?
Müsste ich das dann nochmal latchen mit dem valid signal?
Das kommt mir irgendwie zu kompliziert vor.

Warum verändet sich latched_address_o bei Deiner implementierung 
überhaupt, wenn keine steigende Flanke des enable kommt?

In diskreter Hardware benutzt man dafür ja gern transparente Latches. 
Die haben ja auch den den Vorteil, dass die Adressen am Ausgang früh 
anliegen und die Addressdecoder mehr Zeit haben.

Es wird immer vor ungewollten latches in FPGAs gewarnt, aber warum nicht 
ein gewolltes transparentes Latch im FPGA implementieren?

Oder anderst gefragt: Was könnte folgender Code böses tun?

1

entity address_latch is

2

    generic

3

    (

4

        width : integer := 16

5

    );

6

    port

7

    (

8

        latch_enable_i    : in  std_logic;                           -- latch on rising edge (20ns wide pulse)

9

        address_data_i    : in  std_logic_vector(width-1 downto 0);  -- input data

10

        latched_address_o : out std_logic_vector(width-1 downto 0)   -- latched data

11

    );

12

end address_latch;

13

14

architecture address_latch_architecture of address_latch is

15

begin

16

17

    latch_address : process( latch_enable_i )

18

    begin

19

        if latch_enable_i = '1' then

20

            latched_address_o <= address_data_i;

21

        end if;

22

    end process;

23

24

end address_latch_architecture;

Michael S1. schrieb:
> Oder anderst gefragt: Was könnte folgender Code böses tun?
Der Code an sich ist nicht böse. Aber der Witz kommt dann, wenn dieses 
asynchrone Latch auf den Rest des synchronen Designs trifft...

BTW: VHDL muss nicht unbedingt geschwätzig sein.
Ich hätte das so geschrieben (und richtigerweise ist das Latch bei low 
transparent, wenn auf die steigende Flanke gespeichert wird):

1

        latched_address_o <= address_data_i when latch_enable_i='0';

Im Moment des latchens passiert nichts synchrones, lediglich asynchrone 
Addressvergleicher fangen an sich einzustellen. Wenn dann die 
einsynchronisierten read oder write zu arbeiten beginnen sind Adressen 
und daraus generierte chip selects bereits lange stabil.

Ist damit die "Achse des Bösen" gebannt?

Michael S1. schrieb:
> die einsynchronisierten read oder write
Ja, das wird dann hoffentlich beachtet werden.

Danke, ich verstehe das so: Dann hat das Lothars FPGA Papst Segen ;)

Grosses Indianerehrenwort: rd und wr  werden nur einsynchronisiert 
benutzt!

Michael S1. schrieb:
> Grosses Indianerehrenwort: rd und wr  werden nur einsynchronisiert
> benutzt!
Und die Adresse bleibt hoffentlich während des gesamten Zyklus stabil...