Weiß jemand ob es wirklich sehr simple Ethernet interfaces gibt, die
vielleicht noch ein SPI oder I2C interface haben zur Konfiguration,
ansonsten aber per 8 Bit bus angesteuert werden. Ich denke an so ein
interface wie den FT245, was schön simpel ist. Ich will ja nur Ethernet
frames senden.
Würde dir eher einen fertigen Chip empfehlen, wie z.B. Wiznet W5500.
Der kann eigentlich schon alles was du brauchen könntest, ist über SPI
ansteuerbar und es gibt sehr viele Beispiele zur Ansteuerung Online.
Wenn du eh keine spezielle Anwendung hast würde ich die Zeit nicht
verschwenden mit nachentwickeln von fertigen Schaltungen.
Siehe Beitrag "Ethernet UDP FPGA Interface".
Wiznet 5500 tut's allerdings nicht fuer rohe Ethernet-Pakete, nur TCP
und UDP (mit Maengeln). Es ist auch zu schaffen, Wiznet-Kaefer im Netz
'abzuschiessen', dann muss man sich um eine einiges an
'Wiederherstellung' (Reset) von seiten des Geraets kuemmern. Wenn die
Hardware zuverlaessig schnell antworten und verifizierbar sein muss,
bleibt nur: MAC ins FPGA (offene Cores gibt es ja genug).
Martin S. schrieb:> offene Cores gibt es ja genug
Bitte links. Basteschrott auf github gibts viel aber getestete und
erprobte Macs sind teuer. Ich hatte dazu mal Firmen angefragt. So mit
mindestens 12k muss man rechnen.
Boris J. schrieb:> Martin S. schrieb:>> offene Cores gibt es ja genug>> Bitte links. Basteschrott auf github gibts viel aber getestete und> erprobte Macs sind teuer. Ich hatte dazu mal Firmen angefragt. So mit> mindestens 12k muss man rechnen.
Folge dem gegebenen Link (zweimal), dann findest du zu yol/ethernet_mac.
Gekaufte Cores integrieren allenfalls schneller, dafuer hat man dann
wieder Probleme mit OpenSource/freien Verifikationstools.
Ansonsten gibt's auch im Internet-Archiv zum Stichwort Hamsterworks noch
ein paar Implementierungen, die eignen sich aber weniger fuer SoC.
Martin S. schrieb:> Folge dem gegebenen Link (zweimal), dann findest du zu yol/ethernet_mac.> Gekaufte Cores integrieren allenfalls schneller
Haha der war gut. Hast du das Ding schonmal ans laufen bekommen?
Von opencores habe ich sowohl einen 1G als auch einen 10G-MAC in Betrieb
genommen. Welche genau kann ich mich nicht erinnern, funktionierte aber.
Ist also nicht alles "Bastelschrott", nur weil es open source ist.
https://opencores.org/projects?expanded=Communication%20controller
Die haben meist ein Wishbone-Interface. Wenn man bei dem was der TO
vorhat möglichst wenig selber machen möchte, nimmt man sich von dort
noch einen SPI-Core und bastelt einen Paket-FIFO dazwischen.
Ja, die kosten von Firmen lizenziert ein paar tausend Euro, aber
Hexenwerk ist das bei weitem nicht. Im Prinzip (mindestens) eine RX und
eine TX-FSM, die um Nutzdaten aus einem Paket-FIFO jeweils noch ein paar
mehr Daten drumrumbaut (TX) oder wegnimmt (RX). Mögliche Stolpersteine
sind Taktdomänensynchronisierung, FCS und Flusskontrolle, evtl. noch
variable IFG.
Was man leicht vergisst, ist eher noch die PCS, also 8b10b-Codierung und
Synchronisierung der Datenströme, Autonegotiation. In manchen Tools wird
die gleich als Bestandteil des MAC mit instanziiert. Im Xilinx
1G/10G/25G ETH Switching Subsystem gibt es eine PCS-Variante auch von
Xilinx kostenfrei.
Dennis E. schrieb:> Haha der war gut. Hast du das Ding schonmal ans laufen bekommen?
Auch das geht aus der Link-Kette hervor. Musste nur ein paar kleine
Anpassungen vornehmen, damit's mit Autobuffer-DMA auf dem SoC optimal
interagiert.
VHDL hotline schrieb im Beitrag #7102775:
> Ja, die kosten von Firmen lizenziert ein paar tausend Euro, aber> Hexenwerk ist das bei weitem nicht.
Wenn man die in sauberer Source bekommt, und es die Integration
erleichtert ist das legitim, die Integration verschlingt naemlich den
groessten Batzen, erst recht wenn der Core nicht/bedingt in die
Simulation gesteckt werden kann.
Martin S. schrieb:> VHDL hotline schrieb im Beitrag #7102775:>> Ja, die kosten von Firmen lizenziert ein paar tausend Euro, aber>> Hexenwerk ist das bei weitem nicht.>> Wenn man die in sauberer Source bekommt, und es die Integration> erleichtert ist das legitim, die Integration verschlingt naemlich den> groessten Batzen, erst recht wenn der Core nicht/bedingt in die> Simulation gesteckt werden kann.
Stimme ich zu. Ich wollte nur ausdrücken, dass man trotz der (für
nicht-geschäftlichen Gebrauch) relativ hohen Summen nicht davon ausgehen
muss, dass da sonstwas für aufwändige Funktionalität drin steckt.