Some notes on specific aspects of line-rate (highest speed at any given point in time) routers, which are typically implemented using dedicated hardware. Here's a tentative list of topics. There's no particular order or reason to these topics.
-
Performance requirements for a line-rate router. Router evolution over time.
-
Motivating the match-action or lookup model of routers.
-
The architecture of a line-rate router: Why are routers architected as a pipeline? (this is the area and power argument)
-
The cost of a line-rate router: Why is the pipeline model in silicon more effective than throwing an array of processors at the problem.
-
Memory performance models.
-
Why bypassing or operand forwarding doesn't work at line rate?
-
Building multi-ported memories from single-ported memories.
-
Dictionaries in hardware and their implementations (hash tables, cuckoo hashing, d-left, CAMs)
-
Dictionaries with inserts and deletes in the data-plane
- MAC learning
- d-left hash tables used for caching
-
TCAM implementations in hardware.
-
The partitioned Bloom Filter idea.
-
Using permutation networks in lieu of a multiplexer.
-
Some basics, required for building actual hardware.
- Writing hardware in Verilog.
- Using a silicon compiler like Synopsys DC.
- (maybe) writing hardware in Chisel.
- (maybe) formal verification of hardware.
-
Predication vs. branches in hardware
-
Dynamic vs. static data dependencies (x86 vs. VLIW/dataflow)
-
Parsing vs. lookup: Why do we need more parsers than pipelines for the same aggregate throughput?
-
The "market" case for programmability: Can we document the number of RFCs that routers are expected to implement, year on year? http://stanford.edu/~lavanyaj/papers/compiling15.pdf says it's 7000 RFCs, but it isn't clear how they get that number.
-
How does this compare to using delay slots in the MIPS architecture?
-
A first-order model for SRAM and DRAM cells. Ideally, a HSPICE simulation for these cells.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent