OpenCores
URL https://opencores.org/ocsvn/fade_ether_protocol/fade_ether_protocol/trunk

Subversion Repositories fade_ether_protocol

[/] [fade_ether_protocol/] [trunk/] - Rev 21

Rev

Go to most recent revision

Filtering Options

Clear current filter

Rev Log message Author Age Path
21 Changed the top entity for KC705, so that the FADE core is correctly reset
by the RESETMAC command.
Changed sending of the FCMD_RESET command form driver to the FPGA (as it
is not confirmed - the reinitialized core can't confirm the command).
Changed the receiver2t demo program so that it sends RESETMAC three times
before the transmission is started.

In the future, probably there should be a STATUS ioctl, which would
verify, that the core has been reset by RESETMAC.
Then the program should send RESETMAC, and afterwards read the STATUS,
verifying, that RESETMAC arrived FPGA. If not it should repeat the
above procedure (not implemented yet).
wzab 3515d 23h /fade_ether_protocol/trunk/
20 Cured problem with dta_eod missed, when buffer was full at the moment
when dta_eod was asserted.
It caused the client program to hang, as no end of data was transmitted
and no new data arrived...
wzab 3516d 14h /fade_ether_protocol/trunk/
19 The send_cmd function protected to attempt to call it if the Ethernet device was not
claimed before (previously it caused a problem with NULL pointer dereference
in the ioctl in kernel code).

Moved the Ethernet device name to a macro, so it is easier to modify it, when
someone tests in different machines (e.g. the 10Gb/s NIC for tests with
KC705 is p4p1, while 1Gb/s NIC for tests with Atlys is eth0)
wzab 3516d 16h /fade_ether_protocol/trunk/
18 Changed handling of commands so, that all commands are now confirmed - even start and stop
(which previously were not confirmed - successful reception of start was confirmed
by sending of data packets (what if there was no data at the moment?), successful
reception of stop was confirmed by end of data stream).
Added also flushing of data stream after reception of stop command.
The receiver2t.c implements suggested method of communication with the FADE driver.
One thread is responsible for reception and processing of data, while another thread
is responsible for sending of control commands.
wzab 3517d 12h /fade_ether_protocol/trunk/
17 Corrected mutex management in ioctl. wzab 3523d 16h /fade_ether_protocol/trunk/
16 Introduced inline functions simplifying reading and writing of packets' contents. wzab 3523d 17h /fade_ether_protocol/trunk/
15 The previous experimental implemenation for 10Gb/s links has been replaced with the
new, rewritten implementation, which uses sequential numbering of packets instaed
of "sets of packets". This allowed to simplify the driver, and improve its performance.
Additionally a possibility to send user defined commands to the FPGA was added.
wzab 3531d 15h /fade_ether_protocol/trunk/
14 Removed small mistake causing a combinatorial loop. wzab 3536d 16h /fade_ether_protocol/trunk/
13 Small correction in the kernel driver wzab 3538d 22h /fade_ether_protocol/trunk/
12 Added experimental version of my protocol, working with the 10Gb/s
link on the KC705 board.
The design has been initially tested, and is working, but it still
needs some improvments.
Please note, that this version uses the "jumbo" frames,
with 8192 bytes of user data in each packet (plus header).
Therefore it was necessary to make some changes in the kernel
driver.
wzab 3545d 18h /fade_ether_protocol/trunk/
11 Corrected small bug in eth_sender8 (which in fact should only
generate a compiler warning, as the resulting bit vector
was anyway correctly truncated...)
wzab 3702d 16h /fade_ether_protocol/trunk/
10 Updated test client program - receiver2.c

Added possibility to activate only selected slave in the command line.
Currently program services up to three slaves: 0, 1 and 2
To activate a slave, add its number as a program argument in the command line
(order doesn't matter).
wzab 4002d 14h /fade_ether_protocol/trunk/
9 Corrected serious bug in acknowledged packed number calculations, which lead to transmission
errors in high speed CPUs.
wzab 4003d 14h /fade_ether_protocol/trunk/
8 Adjusted parameters of the NCA (network congestion avoidance) alogorithm
to obtain higher throughput.
wzab 4007d 15h /fade_ether_protocol/trunk/
7 Shortened synchronization path for tx_start signal in the eth_sender blocks wzab 4007d 19h /fade_ether_protocol/trunk/
6 Further adjusted IFG lengths wzab 4008d 01h /fade_ether_protocol/trunk/
5 Decreased length of the intraframe gaps (IFG)
In 100Mb/s version - to 100bits (25 nibbles)
In 1Gb/s version - to 104bits (13 bytes)
wzab 4008d 16h /fade_ether_protocol/trunk/
4 Added lacking files PCK_CRC32_D4.vhd and PCK_CRC32_D8.vhd wzab 4034d 23h /fade_ether_protocol/trunk/
3 Added new version of the FPGA firmware, which does not rely on the Ethernet MAC core.
Now both versions are available.
The version with Ethernet MAC is in directory FPGA_with_MAC.
The version which handles directly Ethernet PHY is in directory FPGA_no_MAC
wzab 4035d 00h /fade_ether_protocol/trunk/
2 Initial submission of the implementation of the "fade" protocol. wzab 4191d 18h /fade_ether_protocol/trunk/

1 2 Next >

Show All

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.