Inferred True Dual Port RAM für Xilinx und Altera

[P. K. (pek)]

Hallo zusammen

Mal wieder eine Frage zum Thema "inferred" BRAM. Und zwar versuche ich 
ein "true dual port ram with different aspect" zu erhalten.

Ein solches habe ich auf Altera am laufen. Die Datenstruktur dazu sieht 
so aus:

  type wordType is array (0 to (2**WDPOT)-1) of unsigned(WIDTH-1 downto 0);
  type memType  is array (0 to (2**(DEPTH-WDPOT))-1) of wordType;
  ...
  shared variable RamxD  : memType;

Kompiliere ich diese auf Vivado erhalte ich folgende Fehlermeldung:

CRITICAL WARNING: [Synth 8-3352] multi-driven net R2/RamxD[0][1][1] with 
1st driver pin 'R2/RamxD_reg[0][1][1]/Q' 
[D:/home_nobackup/vivadotraining/KCU105_HW/ram_2rw_2s_1c.vhd:246]
CRITICAL WARNING: [Synth 8-3352] multi-driven net R2/RamxD[0][1][1] with 
2nd driver pin 'R2/RamxD_reg[0][1][1]__0/Q' 
[D:/home_nobackup/vivadotraining/KCU105_HW/ram_2rw_2s_1c.vhd:222]
...

Die Synthese in ein BRAM misslingt.

Nach Anpassung an die Xilinx Coding-Styles sieht die Datenstruktur jetzt 
so aus:

  type memType  is array (0 to (2**DEPTH)-1) of unsigned(WIDTH-1 downto 0);
  ...
  shared variable RamxD  : memType;

Was in Quartus zum folgenden Resultat führt:

Error (10028): Can't resolve multiple constant drivers for net 
"RamxD[0][7]" at ram_2rw_2s_1c_xil.vhd(217)
Error (10029): Constant driver at ram_2rw_2s_1c_xil.vhd(203)

Im ersten Fall habe ich ein zweidimensionales Array of unsigned, 
übergeordnet Anzahl Worte im breiten Port, untergeordnet Anzahl Worte 
des schmalen Ports im breiten.
Im zweiten Fall habe ich ein eindimensionales Array of unsigned mit der 
Anzahl Worte im schmalen Port, beim Zugriff des breiten werden jeweils 
2^WDPOT schmale Worte bearbeitet.

Meine Frage: Hat jemand Ansätze für eine Lösung, welche sowohl für 
Altera und Xilinx ohne generate-Switch synthetisierbar ist?

[Falk B. (falk)]

@ P. K. (pek)

>Meine Frage: Hat jemand Ansätze für eine Lösung, welche sowohl für
>Altera und Xilinx ohne generate-Switch synthetisierbar ist?

Was spricht gegen ein passende Kapselung und direkte Instanzierung?

[P. K. (pek)]

Falk B. schrieb:
> Was spricht gegen ein passende Kapselung und direkte Instanzierung?

Instanziierung ist IMHO generell "böse", da mache ich die Arbeit bei 
jedem Device neu. Mit dem Inferieren habe ich die ~30 verschiedenen 
RAM-Typen des letzten Designs auf 3 inferierbare reduziert, sogar die 
Migration von Altera nach Xilinx hat, bis auf den beschriebenen Fall, 
tipp-topp geklappt.

[Falk B. (falk)]

@ P. K. (pek)

>> Was spricht gegen ein passende Kapselung und direkte Instanzierung?

>Instanziierung ist IMHO generell "böse", da mache ich die Arbeit bei
>jedem Device neu.

Dafür bekommst du EXAKT was du brauchst und musst nicht immer dem 
VHDL-Compiler genau aud die Finger sehen. Ausserdem kann man damit 
sämtliche SOnderfunktionen nutzen, welche beim inferieren niemals 
verfügbar sind (Spezielle Steuersignale, Verhalten der Ports bei 
gleichzeitigen Schreibzugriffen etc.)

> Mit dem Inferieren habe ich die ~30 verschiedenen
>RAM-Typen des letzten Designs auf 3 inferierbare reduziert,

Hmmm.

> sogar die
>Migration von Altera nach Xilinx hat, bis auf den beschriebenen Fall,
>tipp-topp geklappt.

Wie oft machst du das?

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

Falk B. schrieb:
> Dafür bekommst du EXAKT was du brauchst und musst nicht immer dem
> VHDL-Compiler genau aud die Finger sehen. Ausserdem kann man damit
> sämtliche SOnderfunktionen nutzen
Genau aus diesem Grund instantiiere ich die RAMs idR. auch manuell. Die 
FPGA-Hersteller basteln jedesmal neue Features an so ein RAM, und die 
Defaulteinstellung, die der Synthesizer aus einer generischen 
Beschreibung ermittelt, ist irgendwie immer (annähernd) diametral zu 
dem, was ich möchte...

[Rick Dangerus (Gast)]

P. K. schrieb:
> Instanziierung ist IMHO generell "böse", da mache ich die Arbeit bei
> jedem Device neu.
Da stimme ich Dir vollkommen zu. Das geht mir bei den 
Gigabit-Transceivern so. Das ist keine Freude...

Zu Deinem eigentlichen Problem: Die Frage für mich wäre, ob Dein 
gewünschtes Konstrukt im Standard steht und ob dieser von den 
Herstellertools umgesetzt wird.

Der letzte mir bekannte Standard ist der hier:
http://standards.ieee.org/findstds/standard/1076.6-2004.html

Die Aussage 'Status withdrawn' auf der Webseite irritiert mich 
allerdings.

Wenn der 'Dual-Port-RAM with diffrent data with' nicht im Standard 
steht, wirst Du momentan um eine Sonderbehandlung nicht drumherum 
kommen.

Rick