Re: [9fans] RUDP and/or others

[Aleksandar Kuktin <akuktin@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>On Mon, 19 Oct 2015 11:28:13 +0200
>hiro <23hiro@gmail.com> wrote:
>
> Do I understand correctly, you just want to avoid having to implement
> the complexities of TCP on an fpga? If there was a TCP IP core would
> you buy it?
> Why does VNC require an fpga, are you going to transfer enormous
> resolutions? If yes then I personally would use UDP and a lossy and
> loss tolerant compression.
> If not I would use TCP and no FPGA.

The idea here is to implement a FOSH computer. Currently, I'm pilfering
a lot of technology from Milkymist but I already had to write my own
bits of hardware - so far only a memory controler. I wasn't happy with
what Milkymist was using so I wrote my own. By the time I finish, I'll
probably also implement the framebuffer with the video output. Gigabit
ethernet is also somewhere in the pipeline and will probably get
implemented, *if* I can get its analog bits to work properly. I already
have a working 10BASE-T implementation (and some other things) so I'm
not a newbie at this.

However, because of the severe speed limits imposed by the
implementation technology (FPGA), this computer will never be
particularly fast. If you want to play pretty video games and watch
pretty CGI videos, the obvious solution is to have a separate computer
serve as the CPU server and renderer with the bitty box being a
terminal.

One option is to do the normal software based processing. But once you
do the math, you realize that either you won't be sending a lot of
data or your FPGA CPU won't be doing a lot of processing because of the
interaction between system components contending to access the main
memory.

The main memory is implemented as DDR1 SDRAM. DRAM *really* doesn't
like random memory accesses - the kind CPU will execute. You can
optimize the memory controller to serve the CPU well, but then you are
left in a bind when it comes time to implement the DMA because it
has the exact opposite memory access profile. Not having the DMA is
completely and absolutely out of the question, ofcourse.

You can use, perhaps, wide memory buses and well optimized cache line
sizes to perform DMA in short bursts, but each DMA-CPU switchover is
expensive because (unless you get really lucky) you need to open and
close memory pages. This sets an upper limit to the data transfer
before the human usability of the system tanks.

Streaming 1280x1024x24 video at 25 fps is, you guessed it, way beyond
that limit.

So the solution, I believe, is to perform DMA at the different point,
specifically, between the network interface and the framebuffer/video
card. This scheme completely bypasses the main memory, leaving the CPU
to run at full capacity but has the drawback that now the framebuffer
has to talk network. The obvious hack is to have the CPU initiate,
handshake and configure the connection and then hand it over to the
framebuffer for data transfer. The obvious problem is that the
framebuffer STILL needs to talk network, albeit not whole protocols but only the grindy parts, leaving the more intricate bits to the CPU.

Did I mention network analysis needs to be on-the-fly? Yeah, there
ain't enough memory on the chip to store the whole network packet, and
there aren't enough I/O pins on the device to store it off-device. So
you just have to handle the packet literally as it is zooming past you. Receive the headers, analyze if the packet is for us or the CPU (and
route it there if that's the case), read the application headers, set
up the datapath, ram data into the video DRAM and maybe
invalidate/rollback the whole operation if any of the myriad checksums
indicate a transmission error. Yes, we're checksumming. :)

I'm not saying it's possible, I'm only saying that I'll try and that I
need a simple transport protocol to help me do it. :)

I chose VNC because (a) it's actually a pretty neat protocol and (b)
it's all over the place. You could use it to interface to a whole host
of applications. VNC, on its side, requires a reliable transport. TCP
is way too complicated for a few thousand gates of digital logic (I
think) and UDP is not reliable enough. So, I went looking.

- -- 
Svi moji e-mailovi su kriptografski potpisani. Proverite ih.
All of my e-mails are cryptographically signed. Verify them.
- --
You don't need an AI for a robot uprising.
Humans will do just fine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBAgAGBQJWJVWaAAoJEKa4cgqNx31/YBwP/i5ZiM6kh04rn2IaVSxYSqwq
tDMH0xf3dyMxOl8Wm6NltH48T+CXs7ukZ41DPuwcZFaLttRRtydOFgwtpmTy3aBm
wkCCwNNjsttP6vABaKiGKcLVN+1yGgcBuN/9X6r3Yp7AXtHZKhnGHabmVFs/jYtN
QlMbVtBtp8DrTx2u+t1TVbUTpywvW5JGXcwNIKpjFSz7fL+QA2uIO5tz7KLuyK/x
COFW8rcglTAX7pvDpyRYUevk/eZw1uoiayh2TVV2KQuISIS3QrG+TmLsI9JxonnK
A2KXUPKslhShJ+I539VdYNvgKiiVCFnxAyqGBDK+N0T96mFQZfOll/gZ34OotUKa
iimY6JAfgM/zXyWpAt3cUTHvUHgX+4TzCpKVDkru364RmHQNRqxUlCILLcIjWkoc
tTk8P1UN0fQxGoITLcnQHnT7+MUVzxpdtMud5kHSjXKGIddG6WMlN38W6uyXJjPK
Lezfar5X7eTMUMvqsUHiNMLEfKto1B/Fl6BCsJuz2QJmanqScXF2+5XmE9DEXXG/
wMu6m2FSIBe96jh/wMOdCc6udHG2VcR9MKqsQlCsYGaPiCK27s4O0PJbU0rkSsfz
16gRZfkSOrrNst+SFCQhdwHbBYDoQWKBakowI7Ta2pWwK/7rsaefKhkMLADlspnb
kH2YTuHtT1LzeGIlc9PZ
=3WfL
-----END PGP SIGNATURE-----