Xilinx IP-Cores und Netz-Namen?

[Hansi (Gast)]

Hallo!
Ich spiele gerade mit einem Sparten 3e Eval-Board rum und habe eine 
Frage, auf die ich nach intensivem (falschen?) Suchen leider keine 
Antwort gefunden habe.
Undzwar würde ich gerne mehrere von den Xilinx MUL-Cores einbinden. Aber 
die Ein-/Ausgangsnetze haben immer die selben Namen, die ich nicht 
verändern kann wie a,b usw.
Wenn ich jetzt z.B. einen 8-Bit MUL für mein Top-Modul generiere und 2 
16-Bit MULs für diverse untergeordnete Module, dann haben die alle die 
gleichen Netznamen.
Was macht man da denn sinvoller Weise?
War ich bloß nicht in der Lage im CoreGen die Option für die Benennung 
zu finden, oder löst man das anders?

Gruß,
der Hansi

[Silvia A. (silvia)]

Zeig mal deine Instanzierung

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

Hansi schrieb:
> Was macht man da denn sinvoller Weise?
Du bindest diese Cores dann ja als Komponenten in dein Design ein und 
verdrahtest die dort mit Signalen, die deine gewählten Namen haben...

Aber: warum unbedingt einen Multiplizierer als Core implementieren?
Eine Multiplikation wird doch ganz einfach synthetisiert...

[Hansi (Gast)]

Hallo, vielen Dank schonmal!

Das habe ich soweit aus dem Instanziierungstemplate von Xilinx 
übernommen und unten meine eigenen Signalnamen bei der Instanziierung 
eingefügt.


component mul16
  port (
  clk: in std_logic;
  a: in std_logic_vector(15 downto 0);
  b: in std_logic_vector(15 downto 0);
  p: out std_logic_vector(15 downto 0));
end component;



mul1: mul16
    port map (
      clk => clk,
      a => mul_a,
      b => mul_b,
      p => mul_p);



Ich meine, vielleicht habe ich einfach nur eine falsche Vorstellung von 
dem was hier passiert, aber ich muss doch im Port()-Bereich der Entity 
von dem Modul wo der core eingebunden ist die Ein- und Ausgänge angeben, 
also z.B.

entity Rechner is
Port (


  -- multiplier
        a: in std_logic_vector(15 downto 0);
  b: in std_logic_vector(15 downto 0);
  p: out std_logic_vector(15 downto 0);

und in meinen anderen Modulen sieht dass dann ähnlich aus, weil der 
Core-Generator immer a,b,p vergibt. Meinem Verständnis nach sind die 
dann alle mehr oder weniger verbunden.

@ Lothar

>Aber: warum unbedingt einen Multiplizierer als Core implementieren?
>Eine Multiplikation wird doch ganz einfach synthetisiert..

Also bei mir enthält eine Multiplikation von signed oder unsigned stets 
0.
Mit den Cores geht es dann wunderbar.
Aber selbst wenn ich da was falsch mache würde mich die Sache 
prinzipiell interessieren.


Gruß,
Hansi

[Christian R. (supachris)]

Du kannst auch problemlos sowas machen:

mul1: mul16
    port map (
      clk => clk,
      a => mul_a1,
      b => mul_b1,
      p => mul_p1);

mul2: mul16
    port map (
      clk => clk,
      a => mul_a2,
      b => mul_b2,
      p => mul_p2);

mul3: mul16
    port map (
      clk => clk,
      a => mul_a3,
      b => mul_b3,
      p => mul_p3);

Was links von => in der Port Map steht, ist nur abhängig von der 
Definition im Core in diesem Fall, rechts können deine Signalnamen 
stehen. Verbunden ist dann nix.

Viel sinnvoller ist aber die Multiplikation einfach mit * hinzuschreiben 
und den Rest den Sythesizer machen zu lassen. Man muss natürlich die 
richtigen libs einbinden, und das wäre in dem Fall ausschließlich die 
numeric_std

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

Hansi schrieb:
> bei mir enthält eine Multiplikation von signed oder unsigned stets 0.
Dann solltest du mal schauen, was der Synthesizer draus macht 
(RTL-Schematics). Evtl. kapiert der die Datentypen nicht, weil du (wie 
schon erwähnt) die falschen Libs verwendest...

[Hansi (Gast)]

Vielen Dank!

use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

Die Beiden habe ich eingebunden, sonst nichts.

Also STD_LOGIC dann weglassen?


Wie ist das denn dann: der IP-Core hat je nach Bitbreite eine Latenz von 
ein paar Takten.
Die * Operation ist dann vermutlich auch latenzbehaftet? Wäre ja wichtig 
zu wissen, damit ich in meiner state machine dann im nächsten Takt 
keinen Müll abhole.

>Dann solltest du mal schauen, was der Synthesizer draus macht
>(RTL-Schematics).

Hatte ich mal versucht, aber war leider nicht sehr aufschlussreich für 
mich.
Ich probiere es dann heut Abend nochmal, hab grad kein ISE hier zu 
Verfügung. :-)

[Hansi (Gast)]

Ok, meinen Google-Ergebnissen zufolge (die mich wieder in das Forum hier 
führten g) ist die Multiplikation kombinatorisch und damit nicht 
Latenzbehaftet. Jedenfalls nicht mehrere Takte bei meinen 50MHz. ;-)
Finde ich zwar wunderlich dass der Xilinx-Core dann ~3 Takte pro 
verwendetem 18x18 HW-mul haben will, aber was solls. Vielleicht habe ich 
das im Datenblatt von dem Core auch falsch verstanden. (Was ich aber 
irgendwie nicht glauben mag ^^)

Grüße,
Hansi

[Silvia A. (silvia)]

Die Signale der Componenten sind nur Local (also in der Componente) 
sichtbar. componenten werden so eingebunden.

[/VHDL]
    port map (
      clk => clk,
      a => mul_a,
      b => mul_b,
      p => mul_p);
[VHDL]

a,b,und p sind innerhalb deines Codes nicht sichtbar.
mul_a, mul_b und mul_p sind sie signale, die du verwenden musst, und die 
kannst du frei umbenennen.

>Finde ich zwar wunderlich dass der Xilinx-Core dann ~3 Takte pro
>verwendetem 18x18 HW-mul haben will
Eine Multiplikation kann in einem Takt gelöst werden, belegt dann aber 
viele resourcen. Der Core Generator kann das Platzsparender umsetzten, 
allesdings dann  mit den 3 Takten Latenz.

EDIT: der S3e hat auch Hardware Multiplizierer, wenn der Core die 
Verwendet, hast du wahrscheinlich "registered" angewählt

[Christian R. (supachris)]

Wenn der HW-MUL genommen wird, ist die erreichbare Geschwindigkeit 
abhängig von der Zahl der Register. Beschreibt man die Multiplikation 
rein kombinatorisch, kommt folgende Meldung:

Xst:2385 - HDL ADVISOR - You can improve the performance of the multiplier Add16x16/Mmult_Result by adding 3 register level(s).

Achso, die st_logic brauchst du schon auch. Aber keine alten Synopsis 
Libs wie std_logic_unsigned oder std_logic_signed benutzen.