Open Cores MAC mit Avalon Schnittstelle auf NIOSII EPM Demo Board

Beim Kompilieren bekomme ich die Fehlermeldung:

Error: Cannot use value BYPASS of parameter CLOCK_ENABLE_INPUT_A with 
device family Cyclone in altsyncram megafunction

Ok- er will den altsyncram für den Speicher des MAC auf eine weise 
initialisieren wie so mein alter
Cyclone 1 nicht unterstützt:

altsyncram  altsyncram_component (
    .wren_a         (wren_a     ),
    .clock0         (clock      ),
    .wren_b         (wren_b     ),
    .address_a      (address_a  ),
    .address_b      (address_b  ),
    .data_a         (data_a     ),
    .data_b         (data_b     ),
    .q_a            (q_a        ),
    .q_b            (q_b        ),
    .aclr0          (1'b0       ),
    .aclr1          (1'b0       ),
    .addressstall_a (1'b0       ),
    .addressstall_b (1'b0       ),
    .byteena_a      (1'b1       ),
    .byteena_b      (1'b1       ),
    .clock1         (1'b1       ),
    .clocken0       (1'b1       ),
    .clocken1       (1'b1       ),
    .clocken2       (1'b1       ),
    .clocken3       (1'b1       ),
    .eccstatus      (           ),
    .rden_a         (1'b1       ),
    .rden_b         (1'b1       )
);

was wäre eine alternative?

Ah-- jetz komm ich der sache shcon näher:

unter "defparam" habe ich  altsyncram_component.intended_device_family = 
"Cyclone" gesetzt aber ich weiss nicht wodurch ich die BYPASS ersetzt 
soll-
die Dokumentation für Cyclon1 macht mich auch nciht schlauer....

 defparam
       CLOCK0_component.address_reg_b = "CLOCK0",
        altsyncram_component.clock_enable_input_a = "BYPASS",
        altsyncram_component.clock_enable_input_b = "BYPASS",
        altsyncram_component.clock_enable_output_a = "BYPASS",
        altsyncram_component.clock_enable_output_b = "BYPASS",
        altsyncram_component.indata_reg_b = "CLOCK0",
        altsyncram_component.intended_device_family = "Cyclone",
        altsyncram_component.lpm_type = "altsyncram",
        altsyncram_component.numwords_a = DEPTH,
        altsyncram_component.numwords_b = DEPTH,
        altsyncram_component.operation_mode = "BIDIR_DUAL_PORT",
        altsyncram_component.outdata_aclr_a = "NONE",
        altsyncram_component.outdata_aclr_b = "NONE",
        altsyncram_component.outdata_reg_a = "UNREGISTERED",
        altsyncram_component.outdata_reg_b = "UNREGISTERED",
        altsyncram_component.power_up_uninitialized = "FALSE",
        altsyncram_component.read_during_write_mode_mixed_ports = 
"DONT_CARE",
        altsyncram_component.widthad_a = clogb2(DEPTH-1),
        altsyncram_component.widthad_b = clogb2(DEPTH-1),
        altsyncram_component.width_a = 32,
        altsyncram_component.width_b = 32,
        altsyncram_component.width_byteena_a = 1,
        altsyncram_component.width_byteena_b = 1,
        altsyncram_component.wrcontrol_wraddress_reg_b = "CLOCK0";

Ich habe jetzt einfach mal die "Bypass" durch "Normal" ersetzt:

 altsyncram_component.clock_enable_input_a = "NORMAL",
 altsyncram_component.clock_enable_input_b = "NORMAL",
 altsyncram_component.clock_enable_output_a = "NORMAL",
 altsyncram_component.clock_enable_output_b = "NORMAL",

Ich behersche keine Verilog und weiss nciht was das für auswirkungen 
haben kann.
Die Zeile
 CLOCK0_component.address_reg_b = "CLOCK0",
hatte ich falsch gepostet, es muss
altsyncram_component.address_reg_b = "CLOCK0",
  heissen.

Ja- die synthese klpappt jetzt mit diesen
einstellungen ... nun muss ich den Ethernet Stack zum laufen bringen

hmm jetzt hänge ich an der nächsten stellt-
es geht um einen Treiber für den TDK 78Q2120C Phy um ihn mit dem 
OpenCores MAC zubetreiben.... hat da jemand erfahrungen mit?

Laut dokumentation werden ja nur diese 4 Phys von dieser 
eth_ocm_phy_init();
auf anhiep unterstütz:

1.The Intel LXT972A 10/100 Ethernet PHY.
2.The Marvell 88E1111 10/100/1000 Ethernet PHY (used on the StratixIIGX 
Audio/Video development board).
3.The National Semiconductor DP83848C 10/100 PHY (used on the Cyclone 
III embedded development kit).
4.The Vitesse 8641 10/100/1000 Ethernet PHY.

ok- ich versuche jetzt selbst einen treiber zu schreiben-
dabei ist mir aufgefallen das ich die register des Phy nicht
auslesen kann.
Diese werden doch über die diesen MDIO gelesen, der
eigendlich wie eine sPI schnittstelle funktioniert.

da der OpenCores MAC keinen Bidirektionalen MDIO hat,
sondern einen MDI und MDO wird wohl dieser MDOE nach dem ich
oben gefragt hatte, dafür
sein festzulegen wann geschrieben wird, und wann gelesen wir (????)

ich habs jetzt einfach mal mit VHDL so verdrahtet:
if (mOE = '0') then mio <= mO; else mI <= mio;  end if;

> ich habs jetzt einfach mal mit VHDL so verdrahtet:
> if (mOE = '0') then mio <= mO; else mI <= mio;  end if;

das funktioniert so nicht, da der Ausgangstreiber nicht abgeschaltet
wird.

Mach es so, als concurrent statement:

1

MI <= mio;

2

mio <= mO when mOE = '0' else 'Z';

Cheers, Roger

oh-- danke das war mir nicht richtig klar..
es wurde zwar übersetzt, aber der wert den ich dann aus dem
register gelesen habe war  immer 1 ... :-P

wenn ich ihn hochomig schalt wie du geraten hast bekomm ich aber
trotzdem einen festen wert (7FEF) für alle register... ?!??!

ich vermute ich hab da noch einen groben fehler....

bist du sicher dass dein output enable low aktiv ist?
wenns direkt vom OC EMAC kommt dann:

1

mio <= mO when mOE = '1' else 'Z';

Cheers, Roger

ja genau- es muss eine 1 sein-
bekomme aber trotzdem nur FFFF aus dem register geliefert , da
er immer die selbe adresse liest....

mI <= mio;
mio <= mO when mOE = '1' else 'Z';

führt zu folgendem ergebniss-
das kann doch nicht ganz sein.... oder?

nach dem trace zu urteilen ist der Ausgang bei mOE = '0' eingeschaltet, 
was ja eben falsch ist.

Cheers, Roger

Hallo!

entschuldige die späte Rückmeldung- aber ich musste erst ein paar Sachen 
austesten-
Ich bin fast ab verzweifeln.

Oben der Trace war falsch-  wenn ich allerdings auf moE='1' reagiere
sieht das ergebnis- nicht besser aus (Anhang)

Das komische ist, das es hin und wieder funktioniert- ich hab schon das
Datenblatt von dem Phy rauf und runter gelesen, und alles mögliche 
versucht...
Es geht mal, und mal liest er nur 0xFFFF aus dem Phy Register.

Ich hab sogar mal ein Oszi an den MIO angeschlossen, und da kommt 
wirklich nichts raus,
genau wie im trace -- komisch ist nur, das ich zwischen takt 382 und 408
so ein komisches rauschen  (bis 50 mVolt)auf dem MIO pin hab - wo er ja 
eigentlich auf "hochohmig" geschaltet sein sollte...

ich denke mal es liegt am Phy? ich hab schon den resetausgang von dem
Phy auf den Ausgang geführt, und den Mac und den Phy gleichzeitig 
Resetet.
Ich habe verschiedene Netzteile probiert... ich weiß nicht mehr was ich 
noch testen soll...

Als ausgangstandart für MIO hab ich LVTTL 3,3 Volt ... könnte es damit
irgendwie zusammenhängen?
Im Phy Datenblatt steht CMOS....

Hallo!

jetzt hab ich die lösung gefunden --> eine kombination aus falschem 
datenblatt
und meiner Dummheit.

Die haben den quarz für den 25 Mhz takt von dem Phy einfach waggelassen 
(im datenblatt ist er aber eingezeichnet!)
wenn ich ihn mit ner PPL vom FPGA takte geht es dann ohne probleme....

...ich fragm ich nur warum es vorher auch manchmal funktioniert hat... 
;o)

Das sieht schonmal ganz gut aus....

eth_ocm_phy_init(&ETHCHIP)

meldet:

[eth_ocm_phy_init] Found THK 78Q2120C PHY.
[eth_ocm_phy_init] Waiting on PHY link...OK. x=5558, PHY STATUS=782d
[eth_ocm_phy_init] Full Duplex is 0


ich frag mich jetzt wie es weiter geht----

Bevor ich einen Stack darauf aufsetzte sollte ich da nicht
besser versuchen von hand ein packet zu verschicken und
es z.B mit etherReal zu emfangen.....