-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >On Mon, 19 Oct 2015 11:28:13 +0200 >hiro <23h...@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-----