Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20707 Discussions

Simple Ethernet port.

Altera_Forum
Honored Contributor II
4,298 Views

I've been tasked with trying to get a simple ethernet port onto some of our specialty boards. For the most part they'd be used to send down control commands and read back simple status. Likely as not the physical connection would be a laptop ether-cable connected to the board but we might want to put them on the network during testing and debug so we don't want conflicts there. It'd be set up with its own IP Address and would respond to only those packets sent to that address. We purchased the Triple Speed Ethernet IP from Altera as wel as a newer Nios II dev brd. Now I've been going through ALL the Altera tutorials, (huge) documents and many other things as well and come to several conclusions. 

The big one is that we don't need an OS and hence don't really need the Nios processor. Its all too big and particularly too complicated for our needs. The "simple socket server" example alone is not at all simple, I can't even figure out where to plug in our set IP Address into it. 

I've been through all the Altera examples and they require at least two engineers, FPGA designer and Embedded Systems Programmer, to perform simple manipulations. I'm alone, FPGA designer. 

What we do need is a simple hardware register set Protocol Stack design. We're willing to buy the IP for such but don't yet know where to find it.  

Does someone out there know? 

Looking for all feedback on this!:confused:
0 Kudos
26 Replies
Altera_Forum
Honored Contributor II
937 Views

Thanks for all the help.

0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Are you sure you can't use the NIOS? It's really pretty darn simple to get ethernet running with it. Are you saying you don't have space in the FPGA for the NIOS or you don't have enough RAM space for the NIOS code? 

 

I use the NIOS running the InterNiche TCP/IP stack without an OS. 

 

Here are some things to consider... 

1 - You're going to have to define some kind of packet protocol to carry your information. You're going to have to do this regardless of whether you use a soft TCP/IP stack or a hard TCP/IP stack. The only difference is it's going to be much harder if you do it in gateware vs. C code. 

2 - If you've already gotten the simple socket server running, then you've already overcome 95% of the work involved in getting a TCP/IP stack running in your FPGA. How far along are you in implementing a TCP/IP stack in firmware? 

 

The only reason to move the TCP/IP stack into gateware in my opinion is speed. It doesn't sound to me like you need the speed for what you are doing so why go through the pain. 

 

BTW. The place to change the static IP address in the simple socket server is found in the "simple_socket_server.h" header file. Look for the following: 

 

--- Quote Start ---  

 

# define IPADDR0 192 

# define IPADDR1 168 

# define IPADDR2 1 

# define IPADDR3 234 

 

--- Quote End ---  

0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Well, here's the present target I've been given; 

1. No Embedded Systems Programmer available, I'm on my own and my C coding abilities are covered with a decade of dust. 

2. An EP2S90 device BUT; 

A: All MRAM is already dedicated to our own IP (not my design) 

B: NO external memory shall be put on the board! 

This leaves me with most of the M4K and M512 memory but not all of it. 

3. No UART into the final design, it must stand alone as an I/O port. I can use a UART in development but not on the board itself. 

4. When commands to the board are sent they shall be readily made available to our IP, 

if a request for status is received it shall send back such over the ethernet interface. 

5. It shall be 1Gbps capable. 

 

You use the iNiche TCP/IP without an OS? But everything in the Altera stuff ONLY uses the iNiche with the us-osII. 

I'm new to ethernet in an FPGA and I'm not an Embedded Systems Programmer. I see components like Lantronix Xport, which surely doesn't have an embedded processor, as well as read of ethernet designs using a simple micro-controller and didn't figure this would be as difficult as I now see it is.  

I began reading the Altera Embedded Design Handbook and quickly discovered that what I thought was a manual to help target me toward the total and reduced hardware system I was after was actually a software developers handbook. Particularly where it pointed me toward use of command line entry for compilation, writing my own 'make files' and TCL script files I was quickly shoved out of my realm. 

I tried to follow the simple_socket_server design source code and quickly got lost on the trail of all other sources called upon by it. 

I was looking to try and reduce the design from the NIOS II standard size the the small size since we only want an embedded routine running all the time and only interfacing to the TSE and some FIFO or registers to out IP.  

I know this is long but so is the issue.
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

May I be allowed to approach this from a higher level? 

 

What is the reason for wanting to use ethernet vs USB or UART? 

 

How many ALMs or LUTs are available in the part? 

How many M4K blocks are available in the part? 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Well, those above me are looking toward using ethernet in our boards from here forward versus any other method. I think they're dreaming of a "pie-in-the-sky" as they're possibly looking at 10Gbps ethernet in the future to replace the 2.5Gbps sFPDP presently used to transfer large blocks of data off our boards. I've told them that that isn't realistic but I don't think they believe me. 

Why ethernet over USB (forget RS232 or 422 or any less than multi-Gbps serial or parallel interface)? Again that was they're decision. 

How many ALMs or LUTs? I don't know but one of the people who made the decision saw a suggested Altera footprint for this that was some 4000+ registers and decided it was acceptable. I haven't found that design such that it meets the other limitations. 

How many M4K blocks? Theoretically all 408 of them in the present target device. I've been told by the IP designer that he's used all 4 MRAM blocks and needs them but his design is not yet complete. If I need all 408 M4K blocks I could successfully argue to get them.
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

I guess you're right, drop TSE, Nios and even using a GX device and just buy one of the products from Lantronix or T.I. or others that have the ethernet connection canned in a single simple package. 

Oh well, it was worth the try.
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

I'm using NIOSII + uCOSII + Interniche and a UDP modified version from the single socket server. 

 

I am very interested in using the Interniche stack TCP_IP without SO. How can I do it?
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Well, I'm not finding it easy but easy was what I was after. It really depends on your skill set, what your near term and long term target goals are and how much you can invest in it. 

 

Don't get discouraged, no matter where you go they're all the same. These are excellent capabilities to have and will make your career bloom but its not easy! 

 

Now reading the advertising and tutorial literature does not prepare you for what's in store. On the hardware side it can be relatively simple if you only want to use what they give you in the tutorials. Going beyond those to customizing for particular project use can be quite an awakening. 

 

Don't get discouraged! Remember they're nearly all the same. 

 

For hardware I quickly discovered that you really do need to read Volumes 4 and 5 of the Quartus II Handbook. That is discouraging especially when, as a hardware engineer, you discover you'll have to learn to write software just to be able to simulate your designs. Also the SOPC Builder is buggy, it has its own tendencies to hang or crash at odd times. Apparently its all created by the use of script files and seems to be cobbled together. When you read that some of its outputs are written to .html files (yet those files aren't for putting on the web) it seems clear that they just hired a bunch of students to put it together cheaply. 

 

Still don't get discouraged, it can be used to design an embedded system on an FPGA. 

 

Do make sure your understanding of just how to properly assemble a basic microprocessor based system is good enough. I have to blow two plus decades of dust off mine. 

 

Now as to ethernet capability. This is a technology, outside the basic microprocessor system, that has evolved to require one to run it. If your just going to use a NIOS development board and its on board MAC chip you should be fine. The SOPC has the connection for that and the tutorials will get you there. If your going to use an IP instead then read up on it and gain an understanding of just how it works. 

 

As to the iNicheStack, well that's software. This is where the tutorials and the supporting software tools begin to branch away from each other. The tutorials all use the IDE but if you read the beginning of the "Embedded Design Handbook" you'll see that the IDE is about to go away. The problem is what will be left is not for the beginner, that too is stated in the beginning of the "Embedded Design Handbook". 

 

Again don't be discouraged. 

 

When you read the tutorial on the iNicheStack it does state clearly that modifying it requires a good knowledge of Sockets. I don't have that myself, yet, and if you're going to use it as given you should be fine. If you need to modify it then you'll need to find yourself some good books on the subject. I don't have any suggestions toward this yet. 

 

Now as to UCOSII, well now you're looking at a different career. At this point now you are becoming an Embedded Systems Programmer, a carreer very different from an FPGA designer/Hardware Engineer. This follows well the replacement tool set for the IDE but this entire system is not for the beginner. You have a huge amount of reading and learning to do. 

 

I still say don't be discouraged! If you gain a good understanding of the above you'll do well in your career. If you master any one of them you'll be made for life! 

Good Luck!
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Now I have to interject. Gentlemen, the terms hardware engineer and software engineer are dying fast. You must become a design engineer with the ability to cross that line at least somewhat. I am an FPGA / PCB design engineer. However, I also have an extensive software skill set and indeed have a minor in Computer Science. The days of hardware design being seperate from software design are disappearing. You can't design your board and then throw it over the wall to the software engineer and ask him to test it for you.  

 

Hardware is utterly worthless without something to make use of it. 

 

Now with regards to the Ethernet offering from Altera: 

1 - I have been extremely pleased with SoPC builder. I don't think I've ever had it crash on me and it is extremely simple to use. The truth is that Altera has invested significant amounts of money in SoPC builder and the Avalon fabric. It generates a very minimal amount of files and the file structure is very simple. If you truly want that proven to you, go use Xilinx's EDK for a day. I use both regularly and I can easily tell you that EDK will likely have you giving up on embedded soft-core processors forever. 

 

2 - I don't know how Altera could make it much easier. Basically you drop in an ethernet MAC and the TCP/IP stack and it works right off the bat. Now if you want to modify the Simple Socket Server example, you need to know sockets. But that has nothing to do with Altera or Ethernet. Sockets are what they are and they would be the same level of difficulty no matter where you were trying to implement them. 

 

3 - If you are going to do anything useful with ethernet then truly you are going to need some software skills (be they yours or someone else's). Sockets and TCP/IP are not hardware elements. With regards to ethernet, once you get past the lowest layer of the ISO model, you are no longer hardware. Now you may purchase some IC's that implement a TCP/IP stack but really all you've done is paid someone else to do the software for you. 

 

If you need help, then don't spend your time pouring over the documentation if it's not helping you understand what it is you need to do. Come here and ask for help. There are many individuals experience and for them this stuff might be easy.  

 

The first time I implemented ethernet on the NIOS, I had not had any prior experience with sockets programming. But I was able to get it running with a little time investment. 

 

The problem I see with Bob's requirements is they are basically telling him to implement Gigabit capable ethernet using zero resources. Now if you really want to go down the path of trying to implement a TCP/IP stack in the NIOS using only the onchip RAM ... We can see if that's possible. 

 

With regards to using the InterNiche TCP/IP stack in superloop mode (no Operating System), There is a patch available on the internet for the version of the stack that was released with version 7.1 of the Altera tools. We ran the patch on that version then ported the changes over to 7.2. We still use that version of the stack to run in superloop mode even though we are using version 9.0 of the Altera tools. 

http://www.nioswiki.com/user:admin/%22super_loop%22_nichestack 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

I'm not really sure how to respond to this. 

 

My bosses (finger in face) have told me that they don't want me to change my career and become an Embedded Systems Programmer. Note: They see this as not just a programmer for Nios processors but ANY embedded system. 

 

I and several others here are pretty strictly FPGA hardware engineers. (We also have Software Engineers [some of the best in the world], Embedded System Programmers [but none available] and a good number of the finest scientific minds in the world. We are MIT!) I can't go into details but we've done things with Altera FPGAs that when talking to other engineers at trade shows or even Altera FAEs they say "you can't do that!" Well we do and will continue to do so. 

We've invoked several high speed serial interfaces before, the latest being sFPDP, and never needed an embedded processor or software within the FPGA design before. 

 

I first bought Nios (I) when it first came out and despite never having a use for it I did manage to keep a license to it over others objections. From time to time I've gone through the tutorials again when I could to keep a basic knowledge of it in hand. 

I have used Xilinx's EDK, not for ethernet, and did find it relatively easy to use at the time. 

It has its own issues but I got positive results faster than I'm getting now with Nios. (you brought it up) 

 

As to SoPC Builder, well, I feel you're too close to the tool on the creation side/experience and cannot see the difficulty for the truly uninitiated. I've seen this many times before and have been the same way myself when trying to explain my designs to others. 

The crashes and hang ups I've experienced are real and I did submit SRs for them. They occurred on Altera designs in support of older Nios dev brd designs, for Stratix EP1S10 and Cyclone EP1C20 boards. (I see they are no longer sold but the Nios II v9.0 documentation clearly states support for them and I have both.) Having now read Quartus II Version 9.0 Volume 4 this should not have happened nor should the work of or suggestions of the SR servicers been necessary. 

 

As to the other things about SoPC, well again none of them look very good from the outside. When I read that the final I/O assignments from an SoPC design are written to a ,html file the software designers around here laughed. Its from them that I was told about students. From my perspective, having once done this years ago, it should have been written, at least, to a .txt file or something that will open within the Quartus editor. 

 

Lastly the career choice. Some near ten years ago I did both software and hardware. The software wasn't just little C code things, I created real time or GUI interfaces, depending on need, for embedded processing systems some of which are still used today. However at that time I saw the tool sets for both software designing and ,particularly, FPGA designing become more and more complicated requiring deeper and deeper knowledge of not just the tools but many other things. I knew I had to make a career decision, software OR hardware. At the time I had one software project before me and seven hardware projects - hardware. My bosses liked my decision. 

 

I don't totally disagree with your view and want to pursue embedded programming but I'll have to do so on my own time. From what I can see you are a software guy who does some FPGA hardware on the side but don't get close to the silicon. 

I'm a hardware guy who does FPGA design, high speed printed circuit design (magic! aka. Dr. Howard Johnson), component selection (beyond the FPGA), system testing/debugging and integration, etc.  

My PLD/FPGA experience goes back to 16V8 PALs. My first Altera designs were in EP610 engineering samples using DATA I/O ABEL because that was all there was. I went from ABEL to AHDL via the first versions of MAXPLUS. I now do all my designs in VHDL (sponsor requirement). And we've always pushed the limits here because its what we do. 

 

So when I complain of the need to write software, scripting files, to make the software work its because I have a very large hat closet already. When a software tool is pitched to me as being "easy to use" I expect not to have to write my own software for it to be so. 

 

If I may make a suggestion; 

The TSE-SGDMA tutorial (and probably the "standard" and "full") Nios dev brd design. 

Rewrite. Create it from scratch. Go through all the steps of selecting the components, why, adjusting their settings, why, and build the design in the tutorial. Like wise do the same for, say, the simple socket server software design. Go through all the steps , explain why choices are made and compile the design in the command shell (if that's really the way things are going). 

Look, think of it this way. 

A few times I've gone to local Altera conferences and hear the same comments from other engineers "Where are all the young engineers?" 

I know where, I see them here. They learned FPGA design using the ISE! Why? Because the tutorials were good enough to get them to learn how to. 

If you make the tutorials (and tools) complete and easy to follow (and use) and your sales people can show these College Professors this (try telling them they need to learn to be both hardware and software[Good Luck!]) then you'll really see some positive results for Altera.
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

I'm certainly not going to claim the years of experience that you have. And I hope I didn't insult your background. That was not my intent. 

 

I have a Bachelor's and Master's degree in Electrical Engineering. I do all my own FPGA and PCB design (including multi-gigabit interfaces). I'm the one who spends the long hours matching impedance and trace lengths and analyzing the stackup and finding out which plane to reference to and on and on and on. I'm also the one who spends the countless hours taking return loss measurements and performing TDR analysis and fiddling with passive component values to get the eye looking as clean as it can be. I hate to use the term magic though. It's only magic when we don't understand it. Magicians are also called illusionists. 

 

Now it so happens I have a minor in Computer Science and I exploit that knowledge to make me a better hardware design engineer. It seems this difference is what makes us both incapable of seeing things from the other's perspective. And I apologize for this shortcoming on my part. 

 

I don't work for Altera so you'll have to pass your suggestions on to your FAE. 

 

Is there something specific that those of us here in the forum can do to help you implement ethernet in your design (Xilinx or Altera)?
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Sorry about "bragging" earlier but whenever I submit an SR or go to the forums I feel treated as though I don't know what I'm about. In some cases, like this one, I may not but I only go to these when I've run through near everything I can find, try everything I can think of and I'm finally frustrated. 

SRs are the worst, they take too long in response and usually tell me to read the document I've just quoted them without an answer. 

Anyway, 

I had mentioned earlier that there are available single components like Lantronix XPORT which have built in them an ethernet interface capability yet clearly don't have an embedded processor. Something similar to that would be an excellent FPGA IP and I was hoping someone knew where I could buy such since I'm not finding it. 

 

P.S. I did go and download the InterNiche "Super Loop" .zip you suggested but haven't yet looked at it.
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Oh yeah, I have tried to pass such suggestions onto Altera but so far they don't seem to be listening.

0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Well there are certainly gateware only ethernet IP out there. For example, Altera and Xilinx both have Video over ethernet reference designs that don't require a processor. These obviously implement some limited UDP/IP functionality. 

 

Would these help: 

1 - A non-processor ethernet reference design from Altera: 

http://www.altera.com/support/refdesigns/ip/interface/ref-triple-speed-ethernet-data-path.html?gsa_pos=7&wt.oss_r=1&wt.oss=ethernet 

 

2 - A non-processor video over IP reference design from Altera: 

http://www.altera.com/support/refdesigns/sys-sol/broadcast/ref-video.html 

 

FYI I obtained the above by simply doing a search on keyword "ethernet" on Altera's website. 

 

3 - Video over IP reference design from Xilinx: 

http://www.xilinx.com/publications/prod_mktg/pn0010973.pdf 

 

4 - Board reference design using ethernet from Xilinx (Uses PowerPC): 

http://www.xilinx.com/support/documentation/boards_and_kits/ug355.pdf 

 

5 - Gigabit ethernet reference design from Xilinx (Uses PowerPC): 

http://www.xilinx.com/support/documentation/application_notes/xapp536.pdf?archived 

 

6 - Another Xilinx app note using a 3rd party TCP/IP stack: 

http://www.xilinx.com/support/documentation/application_notes/xapp546.pdf?archived 

 

7 - A university project VHDL TCP/IP stack: 

http://www.itee.uq.edu.au/~peters/xsvboard/index.html 

 

8 - You might consider reading this. I think it does a good job of illustrating the complexity involved in doing a UDP/IP stack in an FPGA. TCP is only more difficult. 

http://www.design-reuse.com/articles/12012/an-analysis-of-fpga-based-udp-ip-stack-parallelism-for-embedded-ethernet-connectivity.html 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Thank you for assembling the information. I basically confirms my previous opinion, that it's feasible and also meaningful for a lot of applications, to build an TCP or UDP stack without relying on an embedded processor doing the housekeeping. Also the existing hardware TCP chips like WIZNET show, that it's possible in an ASIC. 

 

I think, the decision to use NIOS II or a pure VHDL design should mainly depend on the system specification, but existing knowledge can play a role, of course.
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

Thank you for the feedback. I'll be looking hard at those other options.

0 Kudos
Altera_Forum
Honored Contributor II
937 Views

I've had some experience writing a processor-free Ethernet interface, so if you're interested in going that path I can direct you towards the protocol documentation that you'll need. Writing your own state machines for UDP, ICMP, and ARP takes about 3 weeks. UDP really is worlds simpler then TCP. 

 

The huge benefit you get with running communications through a processor is that it's much easier to add in support for various protocols. I'm not familiar with InterNiche, but you may want to start trying to lower expectations about how versatile the system will be.  

 

The InterNiche device I checked out supports all the protocols you'll need, but an important part of TCP is the ability to fragment and reassemble packets, even when the fragments come in out of order. It's not clear to me if the InterNiche will be able to do this in the FPGA or if it expects software to reassemble packets. If you're receiving small packets, this shouldn't matter. 

 

The Design-Reuse document is very thorough, but the RARP they mention is now replaced with DHCP.
0 Kudos
Altera_Forum
Honored Contributor II
937 Views

I'm already reading a huge amount of documentation (practically as I write this) but I do need more and what you're suggesting I don't yet have so please do point me. Thank you.

0 Kudos
Altera_Forum
Honored Contributor II
937 Views

www.faqs.org (http://www.faqs.org) has all the documentation for Ethernet protocols, pretty much going back to smoke signals. The important and intelligible ones are: 

UDP Protocol: http://www.faqs.org/rfcs/rfc768.html 

IP Protocol: http://www.faqs.org/rfcs/rfc791.html 

ICMP Protocol (Useful to ping devices): http://www.faqs.org/rfcs/rfc792.html 

TCP: http://www.faqs.org/rfcs/rfc793.html 

 

Also, an excellent tool you'll need is Wireshark, which lets you look at messages going through your computer's Ethernet port. 

Edit: Wireshark is a piece of software, from Wireshark.org
0 Kudos
Altera_Forum
Honored Contributor II
829 Views

FYI. Yes the Interniche TCP/IP stack does support and handle fragmented packets. Bear in mind it's all handled in software. Basically the stack interacts with the MAC driver such that incoming packets are just shoved into buffers in memory. Then the stack can operate on them as it pleases.  

 

The only thing implemented in gateware is potentially the MAC and optionally you can implement a hardware checksum for the stack to improve performance. 

 

Obviously the main benefit you're going to get from TCP is a guarantee that your data will be delivered. If you're going to use UDP then you'll have to implement your own handshaking to make sure the packet gets to it's destination. 

 

Jake
0 Kudos
Reply