XC3S500E Ausgang setzen

Gast #2429756
Lesenswert?

Guten Tag miteinander!

Ich bin immernoch dran eine PCI Verbindung mit meinem Spartan-3e 
herzustellen und habe mir dazu insgesamt 4 Debug LEDs zusätzlich zur 
obligatorischen Done LED spendiert.

Diese sind an den Pins 47, 48, 49, 50 mit 270ohm vorwiderstand an GND 
angeschlossen. Das entspricht den Pins IO_L15P_3, IO_L15N_3, IO_L16P_3, 
IO_L16N_3, wenn mich nicht alles täuscht. Die Versorgungsspannung der 
Bank3 ist wie jede andere Bank 3,3V (VCCO_3).

Ich kämpfe damit, dass ich versucht habe per LEDs zu debuggen und dann 
festgestellt habe, dass gar nicht alle LEDs funktionieren. Die LEDs an 
48 und 49 bleiben aus. Nachdem ich die LEDs auf Funktion gemessen habe 
und den Durchgang zum Vorwiderstand geklingelt habe und dort keinen 
Fehler feststellen konnte, habe ich den Pegel gemessen und siehe da aus 
Pin48/49 kommt auch einfach kein high raus.

ucf file
1
NET "pci_clk" TNM_NET = "tnm_clk30";
2
TIMESPEC "TS_clk30" = PERIOD "tnm_clk30" 30 ns HIGH 50 %;
3

4

5
NET "pci_clk" LOC = P183;
6
NET "pci_clk" IOSTANDARD = LVCMOS33;
7

8
NET "led" LOC = P47;
9
NET "led1" LOC = P48;
10
NET "led1" LOC = P49;
11
NET "led1" LOC = P50;
12

13
NET "led" IOSTANDARD = LVCMOS33;
14
NET "led1" IOSTANDARD = LVCMOS33;
15
NET "led2" IOSTANDARD = LVCMOS33;
16
NET "led3" IOSTANDARD = LVCMOS33;

Quelltext
1
library IEEE;
2
use ieee.std_logic_1164.all;
3
use ieee.std_logic_arith.all;
4
use ieee.std_logic_unsigned.all;
5
use ieee.numeric_std.all;
6

7
entity pci is
8
    Port (   pci_clk     : in     STD_LOGIC;
9
        
10
        led        : out  STD_LOGIC;
11
        led1       : out  STD_LOGIC;
12
        led2       : out  STD_LOGIC;
13
        led3       : out  STD_LOGIC);
14
end pci;
15
 
16
architecture Behavioral of pci is
17

18
signal c : integer := 0;
19
signal x : std_logic:= '0';
20

21
begin
22

23
  process(pci_clk)
24
  begin
25
    if(rising_edge(pci_clk)) then
26
      
27
      if (c<14999999) then
28
         c <= c+1;
29
      else
30
         c <= 0;
31
         x <= not x;
32
      end if;
33
    end if;
34
  end process;
35
  led <= x;
36
   led1 <= '1';
37
  led2 <= '1';
38
  led3 <= '1';
39
end Behavioral;

So mehr habe ich nachdem ich Stück für Stück auskommentiert habe 
tatsächlich nicht mehr drin. Meine Frage ist jetzt:

Sind uU die Ausgangstreiber hops gegangen oder was ist mein Problem? 
Fehlt es an sonstigen Einstellungen?

Sehen tue ich aktuell: LED 0 blinkt auf meiner Platine und LED3 leuchtet 
dauerhaft.
Gast #2429775
Lesenswert?

Naja trotz allem immer wieder lustig auf was für Ideen man kommt um den 
Fehler zu suchen. Da werden Schaltpläne analysiert, Widerstände, LEDs 
und sonst was gemessen. Statt man einfach nochmals in Ruhe sein 
geschriebenen Mist überprüft und sich nicht nur mit überfliegen 
zufrieden gibt :)
Gast #2429783
Lesenswert?

sw1ft schrieb:
> Ich kämpfe damit, dass ich versucht habe per LEDs zu debuggen und dann
...
> PCI Verbindung mit meinem Spartan-3e
Bist Du Dir sicher, das Du ein PCI-Interface mit LEDs deuggen willst?
Wie schnell kannst Du gucken?!? Siehst Du die Signalwechsel mit 33 oder 
66 MHz?
Hast Du eigentlich eine funktionierende Simulation?
Ohne Simulation geht bei mir nix auf's FPGA-Board.


sw1ft schrieb:
> library IEEE;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_arith.all;
> use ieee.std_logic_unsigned.all;
> use ieee.numeric_std.all;
Aua. Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"

Duke
Gast #2429802
Lesenswert?

Oh, Danke für den Hinweis. Ja, ich habe nebenher eine Testbench 
geschrieben. Aber per Testbench sehe ich die Zustände der FSMs direkt 
über die Signale was leider auf meiner Karte nicht möglich ist. Und im 
zu überprüfen bis zu welchem State ich springe funktioniert es ansich 
recht gut. Kann natürlich auch sein das ich dabei zu engstirnig denke 
und es eine elegantere Methode gibt aber so fit bin ich mit der ganzen 
VHDL Geschichte (man sieht es an meinen Includes :) ) auch nocht nicht.

Danke Gruß
Gast #2429877
Lesenswert?

Auch Danke dafür,

um nochmals auf die veralteten librarys zum kommen. Verstehe ich es 
richtig, dass ich selbst den gemultiplexten DataAdr Bus als signed oder 
unsigned einlesen muss und somit die ganze STD_LOGIC_VECTOR Geschichte 
nicht mehr verwendet werden sollte?
Gast #2429916
Lesenswert?

sw1ft schrieb:
> Verstehe ich es
> richtig, dass ich selbst den gemultiplexten DataAdr Bus als signed oder
> unsigned einlesen muss und somit die ganze STD_LOGIC_VECTOR Geschichte
> nicht mehr verwendet werden sollte?
Nein, das hast Du falsch verstanden.

Schau Dir mal die Übersicht unter [1] an. Dort sind die offiziellen 
Konvertierungen zwischen den Datentypen dokumentiert. Die alten 
Synopsis-Bibliotheken gehen leider nicht sauber mit den Datentypen um. 
Dies verwirrt gerade Anfänger sehr. Dummerweise finden sich im Netz und 
in Büchern noch viele "vergiftete" Beispiele.
Immerhin gibt es erste Besserung in den "Language Templates" bei 
Xilinx...

[1] http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html
Moderator (Firma: Titel) Persönliche Seite #2429992
Lesenswert?

sw1ft schrieb:
> Ich muss also, sobald ich mit einem Vektor arithmetische Operationen
> durchführen will, entsprechend zum verwendeten Typ casten.
Korrekt.
Besser, du verwendest std_logic Vektoren nur an den Ports der Entity und 
rechnest/manupilierst alles innerhalb deiner Module mit signed/unsigned 
Vektoren oder mit Integern.

Natürlich kannst du an den Ports auch gleich Integer übergeben. Das 
führt aber dann eher mal zu Problemen bei der Portierung.
Und dann gabs da noch die Möglichkeit, die Signale in Records verpackt 
über den Port zu schleusen. Aber das ist dann eher für Fortgeschrittene, 
denn dort gibt es neue Fallstricke, in denen du dich verheddern 
kannst...

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren