PIO implementieren: in + out oder inout?

Jörg W. schrieb:
> Nun habe ich im Hinterkopf, dass man auf Ebene einer Entity stets Busse
> für Eingang und Ausgang getrennt führt,

a) PIO auf Pins
Irgendwo muss der Input-Bus auf stabilen Pegeln gehalten werden. Dafür 
hat man bei nem FPGA/CPLD Möglichkeiten das von der Logik der Pins 
machen zu lassen. Musst du im Mapping dann so einstellen. Irgendwo kommt 
das I/O-Umschaltsignal ran und man benutzt Latches der Pin-Treiber, die 
sich vom Timing einigermaßen synchron spezifizieren lassen. Die willst 
du nicht in deiner Entity haben. Niemand möchte Latches in einer Entity 
haben.

b) PIO auf interne Busse
Meine Herangehensweise für Signale und Busse, die nie das Die verlassen, 
wäre einsynchronisieren und statt zu latchen, den Clock für das 
Einsynchronisieren zu gaten. Damit ist der input-Bus auch im Rahmen der 
gewünschten Timings stabil. Das möchte man aber auch nicht in der Logik 
bzw. Signalverarbeitung, die deine Entity darstellt, haben.

c) Umstellung auf getrenntes IO
Solltest du dich entscheiden, keinen PIO mehr zu wollen, sondern in 
Input was rein zu werfen und auf Output dann woanders zu lesen oder 
stumpf auf Out-Pins auszugeben, oder Verkettung mehrerer Entities zu 
einer digitalen Verarbeitungskette, musst du die IO-Umschaltung nicht 
aus deiner Entity herausoperieren.

d) Anschluss an IP-core als Peripherie
Da bekommst du ein Businterface passend zum IP-Core-Design mitgeliefert, 
was dann sowas ähnliches wie b) erledigt. Das ist dann bereits auf den 
Bus des IP-Cores abgestimmt (Timing etc.) und da ergibt es wenig Sinn, 
das 1. selber zu bauen und auch noch in die Entity zu integrieren.

mfg mf

Achim M. schrieb:
> Dafür hat man bei nem FPGA/CPLD Möglichkeiten das von der Logik der Pins
> machen zu lassen. Musst du im Mapping dann so einstellen. Irgendwo kommt
> das I/O-Umschaltsignal ran und man benutzt Latches der Pin-Treiber, die
> sich vom Timing einigermaßen synchron spezifizieren lassen. Die willst
> du nicht in deiner Entity haben.

OK, das ist dann die Stelle, die ich mir hier mal suchen muss (Lattice / 
SiliconBlue iCE40).

Jörg W. schrieb:
> Wo und wie passiert das?
Am übersichtlichsten im Toplevel. Denn nur dort, im "Toplevel" des 
FPGAs, also aussen an den Pins, existiert diese Funktion real.

Duke Scarring schrieb:
> Jörg W. schrieb:
>> (ggf. auch pullup, aber das ist erstmal egal)
> Leider haben die FPGA-Hersteller vergessen, den Pullup dynamisch
> aktivieren zu können.
Ja, das könnte man glatt "kollektives Versagen" nennen. Denn der 
Pullup(fet) ist ja eh' schon da und sogar schaltbar...

Unbekannter schrieb:
> Die machen das genauso: intern pro Datenrichtung ein Bus, nach extern
> ein inout mit Richtungsumschaltung.
Wow!
Hat das ein Erstsemesteraushilfspraktikant aus der SW-Abteilung gemacht?
Da findet man sowas:

1

    PROCESS (oe, bidir)          -- Behavioral representation 

2

        BEGIN                    -- of tri-states.

3

        IF( oe = '0') THEN

4

            bidir <= "ZZZZZZZZ"

5

            b <= bidir;

6

        ELSE

7

            bidir <= a; 

8

            b <= bidir;

9

        END IF;

10

    END PROCESS;

Falsch ist hier, dass a in der Sensitivliste fehlt --> Simu passt nicht 
zur Realität.
Und unnötig ist ein bidir, das sich unabhängig von oe immer auf b 
auswirkt.
Und ebenso unnötig ist ein Prozess für eine if-Abfrage.
Darüber hinaus könnte man die Beschreibung mit einem (others->'Z') 
wesentlich generischer machen.
Und abschließend sind Output-Enable Signale, die von aussen kommen, gern 
mal low-aktiv.

Ich würde das wie jedes meiner bidirektionalen Bussignale so schreiben:

1

    bidir <= a when oen='0' else (others->'Z');

2

    b     <= bidir;