Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
21615 Discussions

Video over IP Reference Design without Nios! Is it possible?

Altera_Forum
Honored Contributor II
1,153 Views

Hi 

The "Video over IP" reference design (AN-374) accepts IP packets and outputs Transport Streams (TS). It targets a board with External SDRAM for packet storage, External SRAM & Flash for Nios code & data storage. Design targets Stratix II & Stratix IV, despite its out-of-date user manual which claims Stratix II & Cyclone II. 

The reference design includes: 

  • Nios II 

  • Ethernet MAC 

  • UDP/IP 

  • RTP Receiver 

  • RTP Transmitter 

  • RTP to TS 

  • TS to RTP 

  • SOPC System which integrates IPs 

 

 

what we changed: 

My PCB has no external SDRAM or Flash for Nios code & data. Furthermore I don't have enough space available in the FPGA for Nios. Since I only need TSoIP receiver, and I have no external SRAM & Flash for Nios code & data, and because I don't have much space inside FPGA, I removed the Nios, RTP transmitter & TS to RTP. I also made some changes to design, so that I could get output TS sync lock in simulation. For now FEC is disabled to make debugging simpler. 

 

observations: 

After synthesis on Cyclone III, design works for a few minutes (different for different configs, sometimes a few seconds!) and we have TS sync lock at the output. Then it loses TS sync and hangs for ever. State machines are stuck at some states, waiting for some vents that never occur. Unfortunately different behaviors are observed. Some state machines stick to some states in some situations, where some others stay in some others in other situations. Tracing such events goes through SOPC generated files which are not understandable. It is not easy to understand what this component input or that output mean, to trace to the problem root. It seems that an arbitartor (not the arbiter in the user guide, an SOPC generated arbitrator) stalls writing to a buffer & reading from another buffer; but it never changes back for operation to continue. simulating the design for several minutes (for TS sync lock and then TS sync loss) is not possible, since it probably takes months long. 

 

my question: 

Since we removed Nios, we are suspicious that Nios is mandatory in this design. Documentation is not so detailed. As far as we understood, Nios issues IP, Port Number and Subnet Mask. It also has avalon interface to UDP/IP for some software debug commands (am i right? just debug???). We replaced IP, etc with constants. Since there is no Nios now, no command is sent to anywhere. 

is it correct to remove nios as we did or it is a mandatory component of this design? 

 

Sorry for my long post 

Thanks
0 Kudos
0 Replies
Reply