URL
https://opencores.org/ocsvn/srdydrdy_lib/srdydrdy_lib/trunk
Subversion Repositories srdydrdy_lib
Compare Revisions
- This comparison shows the changes necessary to convert path
/srdydrdy_lib/trunk/examples/bridge
- from Rev 21 to Rev 22
- ↔ Reverse comparison
Rev 21 → Rev 22
/doc/intro_ethernet.pdf
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
doc/intro_ethernet.pdf
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property
Index: doc/bridge_example.txt
===================================================================
--- doc/bridge_example.txt (nonexistent)
+++ doc/bridge_example.txt (revision 22)
@@ -0,0 +1,43 @@
+----------------------------------
+ Example Bridge / Switching Hub
+----------------------------------
+
+The bridge directory contains an example bridge built using
+srdy-drdy components. It could more accurately be called
+a switching hub, since it does not implement spanning tree
+or QoS.
+
+The bridge is designed for simplicity rather than efficiency,
+as the purpose is not to make a functioning product but to
+demonstrate use of the library.
+
+The bridge design pushes the bulk of the logic into each
+individual port, called a port_macro. The only global logic
+is the FIB (Forwarding Information Block) that contains the
+address lookup and learning logic, and a centralized ring
+arbiter.
+
+The port_macros are connected to each other via a ring interface.
+Only one packet can be transmitted on the ring at a time.
+The system is designed so that it has more ring bandwidth than
+the maximum amount of incoming traffic, so that the ring should
+not be the bottleneck for system performance.
+
+The bridge is designed to be output-queued, so that all packets
+are forwarded to their output port and the output port will
+drop packets if there is insufficient transmit bandwidth.
+
+The bridge handles all transmission errors on the input port,
+using the rx_fifo to drop packets which arrive with bad CRC.
+The parser waits until the end of packet is received to determine
+if the packet is good, and only sends the packet to the FIB
+if CRC is OK. Otherwise the parser errors the packet so it
+will be dropped in RX FIFO.
+
+Packets are transmitted and received using an 8-bit GMII interface.
+In order to create a higher-bandwidth internal interface, data
+is aggregated into 64-bit words to get 8x bandwidth. This gives
+the internal ring roughly 2x the bandwidth of all receiving ports
+combined.
+
+
Index: env/run
===================================================================
--- env/run (revision 21)
+++ env/run (revision 22)
@@ -6,7 +6,7 @@
which iverilog &> /dev/null
if [ "$?" == "0" ]; then
rm -f a.out
- iverilog -f bridge.vf tests/$TESTNAME.v $* |& tee compile.log
+ iverilog -f bridge.vf tests/$TESTNAME.v $* | tee compile.log
./a.out -lxt | tee run.log
else
vcs -full64 +v2k -R -I -f bridge.vf tests/$TESTNAME.v $*