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.
> One other thing I am confused about is that, are the development
> boards always made by third parties using the FPGA from companies
> like Xilinx? Or does Xilinx ever make their own development board?
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.
>>> 2. Once I have the FPGA board, I would like to implement some
>>> design involving network protocol (like TCP/IP, UDP, etc.).
>>> However, I have not worked on 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 available
>>> on this? Or any projects with specific definitions that I can
>>> understand and then start implementing?
>>
>> 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?
>
> I meant some part of the TCP/IP stack implemented in actual hardware
> and 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 enormous and do not want to work on something that big
> for just a side/hobby project. But something in that area with less
> complexity is what I am looking for. I just don't have a good idea of
> what that could be, so having some clear definition will help.
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