2.0 KiB
Requirements
- 2 Gbps operation
- Handles both encrypt and decrypt
At reasonable FPGA speed of 250MHz, 2 Gbps requires a minimum width of 8 bits.
32 bits is a reasonable data width that would be common to see, and lets us have more breathing room while still maintaining line rate.
Module inputs and outputs
- clk
- rst
- data_in [31:0]
- data_valid
- data_ready
- data_last
- r [127:0]
- s [127:0]
- mac [127:0]
- mac_valid
There is no output backpressure. since the result is just a single 128 bit number, we don't need to have a ready signal. if you want to add backpressure, add a register slice on the output outside of this module.
the real requirement was to get something that works...
we can pipeline chacha20 as much as we want since it is trivially pipelined
since poly1305 takes in a 32 bit stream, we can redo chacha20 to work on 32 bits at a time instead of 256 bits. We could also reuse stages, so instead of needing all 20 stages we can just have 2 or something.
BUT since the number 1 requirement is to get it to work, lets just use what we already have.
okay they 512 bit chacha implementation is a bit crazy. the latency is too high. we need to come up with a way to do it 32 bits at a time.
each quarter round generates 128 bits, so we could do 1 quarter round at a time and get 128 bits per clock cycle, which is plenty fast.
if we do 1 quarter round per clock cycle, There are 20 rounds, each of which is 4 quarter rounds, so it would take 80 cycles.
Compared to the current implementation which has 20 rounds, but each round takes 7 cycles,
this has almost half the latency. We still need to store the full state between each round, which is 512 bits.
OHHH there is a big different here with encrypt vs decrypt. basically, it is always the encrypted packet that goes through poly1305. If the packet is being encrypted then it needs to get xored before going into poly1305. If the packet is being decrypted, then it needs to go through poly1305 in parallel with being xored.