Help me choose an FPGA to design network protocols

Hi all,
I have over a decade of experience in hardware design, but almost all of it
is in ASIC. I had done some FPGA projects in school, but nothing after tha
t. So after all these years, I want to work on some personal FPGA projects
(mainly to prepare myself for future job interviews). I have the following
two questions.
1. What is an FPGA board that I can buy for this purpose? I am probably loo
king to do something not too basic (since I already have a lot of experienc
e in design), at the same time I do not want to make it a super complicated
full time project either. I prefer Xilinx (but I am open) and something le
ss than $250 will be good. Note that question #2 might also affect the choi
ce of board.
2. Once I have the FPGA board, I would like to implement some design involv
ing network protocol (like TCP/IP, UDP, etc.). However, I have not worked o
n these network layers before and don't have an extensive knowledge on them
either (other than what I had read in school long ago), so I do not have a
very clear picture of what to do. Is there any open source design availabl
e on this? Or any projects with specific definitions that I can understand
and then start implementing?
Thanks!
Reply to
PM X
Loading thread data ...
There are lots of boards available under $100 but likely won't have networking support. Here is one with Ethernet for $200.
formatting link

It uses a Microsemi Smartfusion2 part which contains an ARM CM4 I believe.
This is often done with a CPU rather than hardware. TCP/IP protocols are very complicated.
As for Open Source, what's wrong with Linux? Or do I misunderstand?
--

Rick C
Reply to
rickman
#page-8
.
Sorry, I have some more newbie type questions. How does a board like the ab ove supposed to work considering the ARM core in there? My understanding is that whatever design I implement in HDL runs in the actual FPGA, and any a dditional software program that I also want to run goes to the ARM processo r? So we have two separate runs going on - one in the FPGA and the other in the ARM - and these two can communicate with each other?
One other thing I am confused about is that, are the development boards alw ays made by third parties using the FPGA from companies like Xilinx? Or doe s Xilinx ever make their own development board?
I am thinking about getting a board with Xilinx FPGA, probably one of the o lder Virtex ones. Found this on ebay:
formatting link
, any comments?
I meant some part of the TCP/IP stack implemented in actual hardware and ru nning in the FPGA. For example, a TCP Offload Engine, which implements the whole TCP/IP stack in hardware. Now, I understand that is something enormou s and do not want to work on something that big for just a side/hobby proje ct. But something in that area with less complexity is what I am looking fo r. I just don't have a good idea of what that could be, so having some clea r definition will help.
Reply to
PM X
Hmmm.... Yes, the ARM will run software written in your favorite sequential language (C, Python, etc) while the FPGA doesn't exactly "run" anything. HDL stands for Hardware Description Language. The HDL doesn't so much get compiled to something that "runs" like a computer program, but rather it is compiled to a configuration file that controls how the various elements of the FPGA hardware are interconnected. The hardware needed in the FPGA is "described".
Exactly how the two communicate depends on the vendor. Xilinx and Altera have similar offerings which their own interfaces between the CPU and the FPGA fabric. But basically the CPU program will perform port I/Os or perhaps DMA is used to move data between the FPGA and memory. I haven't done a project with this chip as yet.
The only boards I've seen made by the FPGA vendors tend to be a bit pricier than the ones made by third parties. That's not to say third parties don't make pricey boards, they span a wider range I guess. FPGA vendors make boards so they can sell their chips. Board vendors are selling boards and so make them as fully functional as they can for the price.
Why an older FPGA? Is it price?
As you may have figured out, I'm not a big fan of Xilinx. I keep hearing about all manner of issues with their in house tool, Vivaldo. It used to be XST, but the scrapped that. In fact, my very first FPGA design was a Xilinx and during a four month project (or maybe six, I don't recall exactly) I had to ditch tools twice. The first time was to drop the Orcad VHDL tool as it was largely non-functional, switching to the Xilinx tool. Then a second time when Xilinx dropped their earlier tool and only supported a new one. Later they came out with XST and now Vivaldo. I don't get that they have to keep tossing tools. It makes it hard to maintain lifetime support for your product.
On the other hand Lattice ditched the chip I have designed on a board I am still making good money from, *very* good money. Fortunately there is sufficient inventory that I won't have to redesign the board for a number of years. At least they use third party synthesis so it isn't a problem to keep supporting products over their lifetime.
I have *no* idea what that could be. As I mentioned, my understanding is the TCP/IP protocol in particular is *very* complex and people don't want to implement their own software on a CPU, much less in hardware. I'm not sure what an "offload engine" would be other than a dedicated CPU, optimized for TCP/IP. But if you have a CM4 in the device, why not use that?
To make a hybrid implementation with part of the TCP/IP stack in the CPU and part in the FPGA fabric would require you to intimately understand this algorithm. I believe I've read that a lot of the details are not in any specification, rather are coded in the applications. So you might need to reverse engineer one or more implementations.
--

Rick C
Reply to
rickman
Protocol stack offload engines have two fundamental "issues".
Firstly the time and latency required to get the packets to/from the main CPU. That significantly affects performance.
Secondly the point that TCP is and end-to-end protocol and will correct protocol errors between or in the endpoints. An offload engine becomes the endpoint, so errors between the offload engine and the main CPU will not be corrected.
The processing required to reliably transfer packets to/from the main CPU bears a lot of similarity to TCP!
TCP in FPGA makes sense where - the lowest latency is required, and - where simplifying assumptions can be made, and - where the end terminal logic is also done in the FPGA e.g. high frequency trading, where they put the business trading rules in hardware to minimise latency
Reply to
Tom Gardner
board-XKF4/181791876772
Yes. The newer Virtex boards cost a lot more (the ones using Virtex 6 or 7 run into thousands of dollars). The only reason I am thinking of Xilinx is because it is probably the most used FPGA (along with maybe Altera), so I thought having it on my resume mi ght provide some advantage.
Because the main purpose of this exercise is to design some network protoco l in real hardware (FPGA) so I can make myself marketable for jobs in that area. If the network protocol part is too complicated as a side project, th en I might just have to write some other (simpler) design and at least beco me familiar with the FPGA aspects of design.
Reply to
PM X
d running in the FPGA. For example, a TCP Offload Engine, which implements the whole TCP/IP stack in hardware. Now, I understand that is something eno rmous and do not want to work on something that big for just a side/hobby p roject. But something in that area with less complexity is what I am lookin g for. I just don't have a good idea of what that could be, so having some clear definition will help.
As a matter of fact, I am doing this to prepare myself for interviews in FP GA design role in high frequency trading (in maybe 3-6 months time). Is the re any simpler project that you could suggest that would be in the general area of network protocols (maybe like a stripped down version) that could b e implemented in FPGA? Thanks!
Reply to
PM X
Based on precisely *zero* evidence and only 30s thought, I would guess the networking stack is known technology, whereas business/trading rules are newer.
ISTR seeing horrendously expensive boards (worth about 1ms of HFT!) with large numbers of big FPGAs and networking. If that's correct then partitioning the trading rules across FPGAs might be interesting. Or not.
Reply to
Tom Gardner
Ok, that explains a lot. I would suggest that you start with learning IP stack software. Before you can implement it in the FPGA you have to understand it. So first learn IP stack software. Once you understand how that works you can decide how best to implement it in logic.
--

Rick C
Reply to
rickman
UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
For example:
formatting link

OK. It is only 10Base-T. But it's not that different than the 10GbE that we do.
You can get a crappy NIC and Basys 3 Artix 7 board for less than $200.00
formatting link

It won't be low latency (the NIC has an SPI serial interface) but it will teach concepts.
Rob.
Reply to
Rob Doyle
Thanks. Is this the board you are referring to?
formatting link

If so, this board doesn't seem to have SPI (at least no listed in the description). Also, do you think this board has enough capacity (in terms of logic elements, etc.) to support a fairly complicated design like UDP/IP?
Reply to
PM X
I'd start bottom-up.
First, get the PHY working. You probably want a single speed without any rate switching (eg 1G, 10G), because anything else gets messy with clock reconfiguration. The choice will likely depend on your board. (You can't really test it at this point). Hopefully your board vendor has example code for this.
Then drop in a vendor MAC component. I've used the Altera ones and they're not too bad: there are pipes on the side for streams in and out which are easy to deal with. There is a memory mapped interface for configuration - you may need to implement that to configure it, or maybe the defaults are OK. (To configure, use a soft core - NIOS or Microblaze or whatever).
On the subject of board choice, I'd suggest avoiding anything with an external MAC chip (external PHY is OK) because they expect to be driven from a processor, while on FPGA it's all about packet pipes. Likewise a MAC as part of a CPU subsystem (eg a Zynq PS, Altera SoC-FPGA HPS) should be avoided because they usually have the same problem, as well as being awkward poorly-documented third-party IP where you essentially have to use the Linux driver.
Once you have the MAC working, you have layer 2 packets in and out (you can see MAC addresses etc). Then you can start building up the layers (eg do IP and ARP). The MAC will probably give you some help for layer 2 (eg compute checksums for you) but you're on your own after that.
Building up the layers is something you can simulate, while doing the plumbing of the MAC you can only test in hardware. I'd suggest writing a testbench that simulates pushing layer 2 packets between two simulated endpoints, and you can replace that by MAC+PHY on hardware when necessary.
If you want experience of networking on FPGA, you don't need to do a full TCP stack to do that: much of the principles of pushing packets about and dealing with vendor IP cores is the same irrespective of the packet format. If it makes you think about latency and meeting timing, that's a useful thing.
If you want to learn about the vagaries of TCP, IPv6, etc I'd suggest starting from software first. Maybe find some NIC with a non-scary interface and program it directly (with no OS support). I'm thinking something old like a PCI NE2000 (eg RTL8139) that isn't as complex as a modern card - the Intel gigabit E1000(e) series (8254x, 8257x, I21x) are well documented but a bit more complex. While you can do this from FPGA, it's much harder to debug.
Theo
Reply to
Theo Markettos
Right off the bat I'm not much of an expert so maybe some that are more experienced can comment. Have you looked at the Digilent Arty Artix 7 FPGA board? It's inexpensive at $99, and has a built in Ethernet Physical, and it mentions that it comes with A MAC IP so you are off to a start. It has 35K cells so I'm not familiar if that would be enough to implement the rest of the needed logic. It has both Arduino, and Pmod connectors so if desired you can add an external Ethernet module that are available in several chip versions.
<
formatting link
Here is one external Ethernet adapter, there are many other available from other places.
<
formatting link
>
--
Cecil - k5nwa
Reply to
Cecil Bayona
What do you mean it doesn't have SPI? SPI is a simple shift register interface which can *easily* be implemented in an FPGA (or MCU) using the GPIOs.
Do you mean ISP, in system programming? If it doesn't have ISP how do you load your design?
--

Rick C
Reply to
rickman
It's a FPGA, you can add SPI easily, there are IPs for free to allow that to happen.
In my post I was also going to mention the BASYS-3 board, I left it out because the Arty Board has a ton of memory available that this one doesn't but this on has a lot of switches and LED which can be handy.
--
Cecil - k5nwa
Reply to
Cecil Bayona
I meant I didn't see a (dedicated) SPI interface. But you're right. SPI protocol just needs 4 general purpose pins, so using GPIOs should do it.
Reply to
PM X
hat
.00
OK, thanks. I will check out both of them. What is the largest design you ( or someone you know) have implemented on these boards? The Artix line seems to be lower end than Virtex line, so trying to get an idea if they can sup port somewhat complicated designs.
Reply to
PM X
Nothing Fancy, that is why in my earlier post I mentioned that I don't have a lot of experience. I been working a 32 bit stack based CPU, but it's a work in progress, I'm still sorting it out, it taken less than 20% of the chip, but a stack CPU are rather simple compared to other CPU's, when finished it should be pretty nice, most instructions take one clock to execute, and it used packed instructions, 5 instructions to a word fetch. Originally it was on a Lattice Brevia2, I am now converting it to a Artix-7 board, but there is software involved too so it's going slow and I'm learning as I go.
--
Cecil - k5nwa
Reply to
Cecil Bayona
No sure what "lower end" means in technical terms. I expect the Artix line of FPGAs will easily support somewhat complicated designs for reasonable values of "somewhat complicated".
I suggest you not give much credence to marketing information and consider the chip specifications. For the most part the important issue is the LUT count. Otherwise the extra features are only useful if you need them.
--

Rick C
Reply to
rickman
Just a comment on your stack processor. I've done some design work with stack processors and read about a lot of designs. In my humble opinion, if you have multiple cycle instructions, you are doing it wrong. I don't want to steal the thread. If you care to discuss this we can start another thread.
--

Rick C
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.