Modul erhält auf Grund der Architektur zwei Clocks, Lösung?

[Queck S. (Firma: Uni) (kiigass)]

Hi Leute

ich hab ein Problem, was auf den ersten Blick trivial scheint (und es 
vllt auch ist). Ich habe drei Module: A,B,C. A und B binden jeweils C 
ein und reichen das Clocksignal, welches sie von außen bekommen einfach 
an C weiter. Das Synthesetool sagt jetzt natürlich zu Recht, dass C zwei 
Clocks bekommt und bricht ab. Mein toller Plan war also einfach im Modul 
A das Clocksignal nicht weiter zu reichen an C. Aber das ist leider 
leichter gesagt als getan, denn wenn ich den Port auf "open" setze (in 
der port map von A) ist das Synthesetool damit auch nicht einverstanden.

Hat jemand nen Vorschlag für mich? Vllt bin ich auch betriebsblind...

thx for help

[Marius W. (mw1987)]

Ganz eindeutig ein Fehler in Zeile 42... Wenn du den behebst, dann 
sollte es funktionieren.

Gruß
Marius

[Der Weise (Gast)]

wenn A und B jeweils C einbinden, ergibt das nicht zwei Instanzen von C, 
die jeweils einen Clock bekommen?

[Queck S. (Firma: Uni) (kiigass)]

Für Marius

entity A is
  port(
    clk : in std_logic
  );
end A;

architecture Behavioral of A is

component C
  port (
    clk : in   STD_LOGIC
  );
end component;

begin

modulC : C
  port map(
    CLK =>  CLK
  );

entity B is
  port(
    clk : in std_logic
  );
end B;

architecture Behavioral of B is

component C
  port (
    clk : in   STD_LOGIC
  );
end component;

begin

modulC : C
  port map(
    CLK =>  CLK
  );

@ Der Weise: Das weiß ich nicht genau, aber ich denke dass das nicht so 
ist.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

vielleicht sollte C zwei unabhängig gepufferte "Ports" bedienen, dann 
kann es auch zwei unabhänige Clocks und Datenbusse verazten.

Namaste

[Queck S. (Firma: Uni) (kiigass)]

Winfried J. schrieb:
> vielleicht sollte C zwei unabhängig gepufferte "Ports" bedienen, dann
> kann es auch zwei unabhänige Clocks und Datenbusse verazten.
>
> Namaste

Wie genau meinst du das?

[Marius W. (mw1987)]

So wie du das oben beschrieben hast, bekommst du definitiv zwei 
Instanzen von C. Eine in A und eine in B. Wenn du nur eine Instanz haben 
möchtest, musst du ein Toplevel-VHDL anlegen, das 1 x A, 1 x B und 1 x C 
instanziert.

Gruß
Marius

[Queck S. (Firma: Uni) (kiigass)]

Marius Wensing schrieb:
> So wie du das oben beschrieben hast, bekommst du definitiv zwei
> Instanzen von C. Eine in A und eine in B. Wenn du nur eine Instanz haben
> möchtest, musst du ein Toplevel-VHDL anlegen, das 1 x A, 1 x B und 1 x C
> instanziert.
>
> Gruß
> Marius

Danke, dann bin ich schonmal nen Meter schlauer was das angeht. Aber das 
erklärt ja noch nicht, warum denn das Syntesetool die Meldung ausgibt:
"Xst:1534 - Sequential logic for node <dd> appears to be controlled by 
multiple clocks."

dd ist ein Signal im Modul C

[Marius W. (mw1987)]

Lad doch einfach den kompletten Source-Code hier hoch... Nicht nur ein 
"Schema" wie oben. Sonst wird das hier ein herumgestocher ohne Ende und 
darauf habe ich keine Lust.

Gruß
Marius

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

Das Problem liegt nicht in den geposteten Zeilen.

Queck Silber schrieb:
> dd ist ein Signal im Modul C
Dann zeig doch mal, was mit diesem Signal D im Modul C alles gemacht 
wird...

[Queck S. (Firma: Uni) (kiigass)]

Marius Wensing schrieb:
> Lad doch einfach den kompletten Source-Code hier hoch... Nicht nur ein
> "Schema" wie oben. Sonst wird das hier ein herumgestocher ohne Ende und
> darauf habe ich keine Lust.
>
> Gruß
> Marius

Das geht leider nicht aus zwei Gründen: Zum einen handelt es sich 
insgesamt um über 3000 Zeilen Code, zum anderen darf ich einige Teile 
davon nicht veröffentlichen. Aber ich glaube, dass der Inhalt der Module 
für das aktuelle Problem auch keine wirkliche Rolle spielt, denn das 
Clock-Signal wird ja nur von oben durchgereicht (wie im Schema oben). 
Die Architektur ist so, dass es ein übergeordnetes Modul gibt, welches 
sowohl A und B einbindet und das CLK an beide weiter gibt, dann kommt C. 
Also eine Art Rauten-Architektur. Beim Modul C handelt es sich um dieses 
hier: http://www.lothar-miller.de/s9y/archives/29-Division-in-VHDL.html

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

Nun, ich würde es so machen wie ich es auch mit diskreten Baugruppen 
machen würde. In VHDL kenne ich mich nicht aus, aber das Problem besteht 
immer wo verschieden Getaktete Systeme verbunden werden müssen. Und da 
helfen FiFo's(puffer) und separate Ports(Schnittstellen). Wie du das in 
VHDL umsetzt, das sollte eine schematische Übung sein.

Namaste

[Marius W. (mw1987)]

Ohne konkreten Code wird dir hier niemand helfen können. Kannst du 
wenigstens die Dateien für A, B und C und deren Toplevel-Design 
hochladen? Zur Not gehts auch mit A und B als "Black-Box". Aber je mehr 
Source-Code du uns zur Verfügung stellst, umso eher kann dir hier 
geholfen werden.

Gruß
Marius

[Queck S. (Firma: Uni) (kiigass)]

Marius Wensing schrieb:
> Ohne konkreten Code wird dir hier niemand helfen können. Kannst du
> wenigstens die Dateien für A, B und C und deren Toplevel-Design
> hochladen? Zur Not gehts auch mit A und B als "Black-Box". Aber je mehr
> Source-Code du uns zur Verfügung stellst, umso eher kann dir hier
> geholfen werden.
>
> Gruß
> Marius

ok ich werd das morgen früh mal abklären, was ich veröffentlichen darf. 
Vllt kommen wir dann ja weiter. Danke euch schonmal bis hierhin für eure 
Hilfsbereitschaft.

[Klaus (Gast)]

Queck Silber schrieb:
> dd ist ein Signal im Modul C

Zeig doch einfach mal genau den Prozess, von dem das Signal dd getrieben 
wird. Das sollte wahrscheinlich reichen um den Fehler zu finden.

[Queck S. (Firma: Uni) (kiigass)]

Ok gute Neuigkeiten der Chef sagt ich darf den ganzen Projektzweig 
veröffentlichen oO nungut...


Hier ist er:
http://www.darkenfalls.de/fileadmin/ECCv12.zip

Das Problem tritt auf, wenn man versucht das main-Modul zu 
synthetisieren. Ich nutze das Xilinx ISE WebPack. Das ganze soll am Ende 
auf einen Spartan3E.

Grundsätzlich geht es in diesem Zweig um Ver-/Entschlüsselung mit 
elliptischen Kurven und Diffi-Hellmann-Schlüsselaustausch. Später soll 
das Ganze vllt noch auf El-Gamal gebürstet werden. Momentan befindet 
sich das aber noch in der Entwicklung und ist deshalb an einigen Stellen 
etwas chaotisch und im Ganzen so gut wie gar nicht dokumentiert.

Ich bin natürlich offen für Vorschläge, wenn jemandem sonst noch was 
auffällt, außer dem hier geposteten Problem/Thema.

PS: Die Simulation funktioniert an sich. Dort gibt es nur ein Problem: 
Das Eingangssignal von dem Euklid-Modul wird an einigen Stellen (bzw 
einige Bits davon) "X".

Danke für eure Geduld

PPS: die Module die ich oben mit A, B und C bezeichnet habe sind hier: 
point_addition, point_doubling und divider2

[Klaus (Gast)]

   process 
   variable diff : unsigned(b-1 downto 0);
   begin
      wait until rising_edge(clk);
      ...
      if rst = '1' then  
      ...
      elsif clk'event and clk = '1' then

Ähm, warum fragst dort 2 mal das Signal clk auf die Flanke ab? Nimm mal 
das wait until rising_edge(ckl);  raus.

Und nebenbei: if clk'event and clk = '1' then  kannst du dann auch 
gleich schöner, nämlich so wie in der anderen Zeile als if 
rising_edge(clk) then  schreiben.

[Queck S. (Firma: Uni) (kiigass)]

meines Wissens nach ist die Zeile

wait until rising_edge(clk);

für den Simulator und die Zeile

if clk'event and clk = '1' then

für das Synthesewerkzeug. Ich lasse mich gerne eines besseren belehren, 
aber ich habe persönlich die Erfahrung gemacht, dass der Simulator 
meckert wenn die erste Zeile fehlt und das Synthesetool wenn die zweite 
fehlt. Nur so wie es oben steht geht beides ohne Fehlermeldung. Aber wie 
gesagt, ich lass mich gerne eines besseren belehren, denn du hast 
natürlich recht, dass es doppelt (redundant) ist.

PS: Ich habs grad nochmal probiert: Wenn ich die erste Zeile weglasse, 
macht der Simulator gar nichts mehr (ich nehme an er hängt sich in einer 
Endlosschleife auf). Die Umformulierung von "if CLK'event and CLK ='1' 
then" nach "if rising_edge(clk) then" klappt problemlos.

[Klaus (Gast)]

Die beiden Zeilen sind nicht redundant (im Sinne, dass die zweite 
eigentlich unwirksam weil doppelt ist) sondern es sind tatsächlich 2 
Taktflangenabfragen die dann den Prozess steuern. Und das bemängelt der 
Synthesizer dann zu recht, wenn soetwas gibt es in einem FPGA nicht.

Beide Zeilen funktionieren sowohl für die simulation, als auch für die 
Synthese.

Aber: bei einem Process der nur ein wait until am anfang hat, darf die 
sensitivity list fehlen, bei der anderen variante nicht! Wenn du also 
einen asynchonen Reset in die ursprüngliche Implementierung von loathar 
einfügen möchtest, kannst du das wait until durch

if rst = '1' then  
      ...
elsif rising_edge(clk) then

ersetzten. Dann musst du aber eine sensitivity list angeben:

process(clk, rst)

[Queck S. (Firma: Uni) (kiigass)]

Das heißt dann, dass wenn ich einen synchronen Reset möchte, ich 
eigentlich die Zeile mit dem

elsif clk'event and clk = '1' then

 in

else

 umwandeln kann? Denn dann würde ja immer noch die erste Zeile den 
Prozess takten, die if-Abfrage würde Reset prüfen und je nach Zustand 
einen der beiden Zweige durchlaufen. Das probier ich gleich mal aus.

[Klaus (Gast)]

Ja, für einen synchronen Reset dann einfach else schreiben und alles 
andere so lassen.

[Queck S. (Firma: Uni) (kiigass)]

wunderbar, ich glaube es ist gelöst, ich habs grad umgesetzt und es 
lässt sich sowohl simulieren als auch synthetisieren.

Danke dir!

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

Queck Silber schrieb:
> meines Wissens nach ist die Zeile
> wait until rising_edge(clk);
> für den Simulator und die Zeile
> if clk'event and clk = '1' then
> für das Synthesewerkzeug
Tja, so ist das, wenn man ungefragt Zeug zusammenkopiert... :-P
Und ich dachte schon, in meiner Divisionroutine wäre da noch ein Fehler.

Zum Hintergrund:
http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html

[Queck S. (Firma: Uni) (kiigass)]

stimmt, aber dem Dividierer fehlte noch ein Reset.^^

Außerdem würde mich interessieren ob man den auch für signed Operanden 
umschreiben kann.

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

Queck Silber schrieb:
> stimmt, aber dem Dividierer fehlte noch ein Reset.^^
LOL...
Glaube ich nicht, dass ein Dividierer einen Reset braucht. Niemals. 
Bestenfalls der Entwickler und die Buchautoren der letzten 20 Jahre 
meinen das.... :-)

Dazu auch das Xilinx WP272 und ähnliche.

> Außerdem würde mich interessieren ob man den auch für signed Operanden
> umschreiben kann.
Sicher.

[Queck S. (Firma: Uni) (kiigass)]

Ich hab mich missverständlich ausgedrückt, ich brauche einen Reset an 
dem Dividierer, weil ich sonst nicht wüsste wie ich das machen könnte. 
Ich stand dem Problem gegenüber, dass der Dividierer noch am Arbeiten 
war, ich aber nicht warten wollte bis er fertig ist. Also brauchte ich 
eine Möglichkeit ihn zurück zu setzen.

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

Queck Silber schrieb:
> Also brauchte ich eine Möglichkeit ihn zurück zu setzen.
Das ist in diesem Fall nur irgendein Signal das von aussen kommt und 
dann die FSM auf den IDLE-Zustand überführt. Mit einem Reset (im 
landläufigen Sinn) hat das eigentlich nichts zu tun.

[Queck S. (Firma: Uni) (kiigass)]

ja da gebe ich dir Recht, weil die Initialisierungen ja auch sowie so in 
den ersten Zuständen gemacht werden.

Mein Problem war, dass ich nicht genau feststellen konnte in welchem 
Zustand der Divider grade ist (von außen), dh sollte er nicht in "idle" 
sein und ich gebe von außen (einen Takt lang) Daten drauf und setze 
"start" auf 1, dann passiert (im Divider) überhaupt nichts. Wenn ich 
dann darauf warte, dass "busy" auf 0 geht bekomme ich zwar ein Ergebnis, 
aber unter Umständen nicht das was ich erwarte. Wie würdest du das 
lösen?

[Duke Scarring (Gast)]

Ich würde mir das not IDLE (= busy) nach außen führen. Das kannst Du 
dann in einer passenden State-Machine verwenden.

Duke

[Queck S. (Firma: Uni) (kiigass)]

Das funktioniert nicht so ohne weiteres, weil "busy" nicht initalisiert 
= 'U' ist, solange "start" noch nie 1 war

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

Dann schreib das hin:

    busy      : out  STD_LOGIC := '0';

[Queck S. (Firma: Uni) (kiigass)]

ich habs so ähnlich gemacht, es funktioniert an sich auch.

when idle => 
   if (start='1') then 
      z <= prepare; 
      busy <= '1';
   else 
      busy <= '0';
   end if;

(so btw: die Defaultwerte wie du, Lothar, ihn oben angegeben hast, 
gelten die auch für die Synthese?)

Was ich speziell tue ist folgendes: Im übergeordneten Modul habe ich 
eine Konstruktion:

...
when z1 =>
   if div_busy = '0' then
      div_start <= '1';
      folge_zustand <= z2;
   else
      div_start <= '0';
      folge_zustand <= z1;
   end if;
...

Ich warte also darauf, dass der Dividierer fertig ist und starte ihn 
dann neu, sollte er beschäftigt sein. Wenn er sowie so grade nichts zu 
tun hat wird er direkt gestartet. Das funktioniert auch, aber 
leider/offensichtlich ist diese Methode deutlich langsamer als den 
Divider mit dem von mir eingefügten Reset "zurück zu setzen" (Aufs Ganze 
bezogen ca. Faktor 4).

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

Queck Silber schrieb:
> (so btw: die Defaultwerte wie du, Lothar, ihn oben angegeben hast,
> gelten die auch für die Synthese?)
Wenn der jeweilige Port ein Flipflop ist (getaktete Übergabe), dann ja.

Queck Silber schrieb:
> den Divider mit dem von mir eingefügten Reset "zurück zu setzen"
Warum macht der Core denn gerade was, wenn du das so einfach abbrechen 
kannst. Dann ist doch die aktuelle Berechnung unnötig...   :-/

[Queck S. (Firma: Uni) (kiigass)]

Lothar Miller schrieb:
> Warum macht der Core denn gerade was, wenn du das so einfach abbrechen
> kannst. Dann ist doch die aktuelle Berechnung unnötig...   :-/

Das liegt daran, dass dort mehrere Prozesse laufen, die zum Teil im 
Kreis laufen. Einer von denen hatte diesen Divider gestartet, ohne dass 
ich es eigentlich wollte. Sicherlich hätte ich den Prozess auch einfach 
abstellen können mit einem CE, aber ich hatte mich für diese Option 
entschieden, weil sie mir in dem Moment einfacher erschien und auch 
immer noch tut. Denn das Abstellen der anderen Prozesse würde das 
Problem mit sich bringen, dass ich an jeder Stelle, an der dieser 
verwendet werden soll ihn wieder einschalten müsste. So schmeiß ich 
einfach die anderen Prozesse die grade nicht dran sind einfach raus und 
reiße die Kontrolle an mich. Dazu muss man sagen, dass der gesamte 
Ablauf der Berechnungen eher sequenziell ist, während die Module 
natürlich parallel laufen. Ich habe also alle Module laufen, die 
fröhlich ihre Berechnungen machen, aber nur ein "aktives" welches grade 
mit den "richtigen" Daten rechnet und wo mich deshalb auch das Ergebnis 
interessiert. Deshalb darf dieses aktive Modul den anderen dann einfach 
die Ressourcen wegnehmen.

[Jimbo (Gast)]

>Ich lasse mich gerne eines besseren belehren,
>aber ich habe persönlich die Erfahrung gemacht, dass der Simulator
>meckert wenn die erste Zeile fehlt und das Synthesetool wenn die zweite
>fehlt.

Man merkt, dass es mit der Erfahrung weit her ist ;-)