Hallo,
ich habe (sinngemäß) den folgenden VHDL-Schnipsel für ein CPLD:
1
P1:process(S1)
2
begin
3
iffalling_edge(S1)then
4
ifV='0'then
5
Q<=...
6
endif;
7
endif;
8
endprocess;
9
10
P2:process(S2)
11
begin
12
ifrising_edge(S2)then
13
ifV='1'then
14
Q<=...
15
endif;
16
endif;
17
endprocess;
ISE meldet bei der Synthese
ERROR:Xst:528 - Multi-source in Unit <test> on signal <Q>; this signal
is connected to multiple drivers.
Drivers are:
Output signal of FDCE instance <Q>
Output signal of FDCE instance <Q_ren>
Den entsprechenden Schaltplan könnte ich vermutlich aufmalen. Aber wie
sage ich es in VHDL?
Den Beitrag #130895 hier kenne ich, aber die Lösung steht noch aus.
Mit dem Takt hat das wenig zu tun. Zwei dürfen und können eh nicht auf
ein Signal arbeiten.
Schreibe mal für jedes Signal einen Prozess, so, dass es nur dort vorkom
mt.
vhtl schrieb:> Den entsprechenden Schaltplan könnte ich vermutlich aufmalen.
Zeichne doch mal das Flipflop mit 2 Takteingängen und gib einen TTL
Baustein an, der das kann. Denn auf Q werden mit 2 unabhängigen Takten
Daten geschrieben. Ich kenne ein solches Bauteil nicht. Und schon gar
nicht innerhalb eines CPLDs...
vhtl schrieb:> Was mir einfällt...
Das hat mit der ursprünglichen Beschreibung aber nicht mehr viel zu tun.
Was sind denn die Signale? Woher kommen die Takte und was hat das V
damit zu tun?
> ISE meldet bei der Synthese>> ERROR:Xst:528 - Multi-source in Unit <test> on signal <Q>; this signal> is connected to multiple drivers.
Das ist mehreres falsch in dem Code:
Das signal Q wird in mehreren processen gesetzt, jeder process wird
sinngemäß nach der Synthese zu einem Signaltreiber (driver). der eingang
des FF ist also mit mehrere treibern (mulitiple driver) beschaltet, das
ist illegal. Das selbe szenario hättest du wenn du zwei Ouput-pins eines
µC kurzschliesst.
Auf weitere Fehler wurde bereits im thread hingewiesen.
Lothar M. schrieb:> vhtl schrieb:>> Den entsprechenden Schaltplan könnte ich vermutlich aufmalen.> Zeichne doch mal das Flipflop mit 2 Takteingängen und gib einen TTL> Baustein an, der das kann.
Ja, meine Vermutung war falsch. :-) Beim Nachdenken bin ich aber auf die
Version 2 gestoßen.
>> Was mir einfällt...> Das hat mit der ursprünglichen Beschreibung aber nicht mehr viel zu tun.
Ich finde, das ist zumindest von der Intention her equivalent.
> Was sind denn die Signale? Woher kommen die Takte und was hat das V> damit zu tun?
Die Takte sind eigentlich nur Signale, vglb. einem "Output Enable". Da
jedoch ein Zähler involviert ist, benötige ich die Flanken. Über V wird
gesteuert, welches OE-Signal Priorität hat.
Ich könnte auch zwei getrennte Zähler verwenden (Q1 und Q2), dann gäbe
es das Problem nicht - ich muß aber FFs sparen.
Da sonst niergendwo ein Takt ist, will ich hierfür nicht extra einen
einführen... Wir reden ja von einem kleinen CPLD.
vhtl schrieb:> benötige ich die Flanken
Man baut sich üblicherweise eine Flankenerkennung und zählt dann.
> Wir reden ja von einem kleinen CPLD
In diesem Fall muß man tatsächlich mit FF geizen...
Duke
Packt die Lösung mal gleich wieder weg, bevor sie einer kopiert!
Das ist das Schlechteste, was man bauen kann, weil so das finale Q
gleich gegenüber zwei Prozessen ansynchron ist.
Das Gebastel geht mehr in Richtung Analogdesign und hat mit synchronem
Schaltungsentwurf nichts zu tun.
Weltbester FPGA-Pongo schrieb im Beitrag #4779334:
> Packt die Lösung mal gleich wieder weg, bevor sie einer kopiert!
Welche denn? Oder beide?
@Noro: Finde ich viel besser, danke!
> Das ist das Schlechteste, was man bauen kann, weil so das finale Q> gleich gegenüber zwei Prozessen ansynchron ist.
Genau, das soll asynchron sein. Ein Gewurschtel aus 74s ist ja auch
nicht synchron.
> Das Gebastel geht mehr in Richtung Analogdesign und hat mit synchronem> Schaltungsentwurf nichts zu tun.
Nun, der zweite Teilsatz ist richtig. :-) Aber nix für ungut, ich habe
schon verstanden, das ein FPGA genau einen Takt hat, von dem alles
abhängt.
dfIas schrieb:> Das wissen wir ja nicht, ob es so gemeint ist. Vielleicht eher so?...> Q <= Q1 when V = '0' else Q2;> Sieht mir nämlich eher danach aus, als ob V darüber entscheidet, wie> sich Q verhält. 'or' wäre dann genauso falsch wie 'and' oder 'xor'.
Ja, Du hast Recht, so war das gemeint. Ich habe mir in dem Noro-Beispiel
noch je einen else-Zweig
1
else
2
Qx<=(others=>'Z');
3
endif;
hinzugedacht, dann wäre es doch gleich, oder?
Wobei noch zu prüfen wäre, ob es überhaupt synthetisiert werden kann und
ob sich die Anzahl der FFs nicht wieder verdoppelt.