comments inline.... 2012/3/18 Nikos Tzanis <[email protected]>
> On 17/3/2012 8:00 μμ, Paul Kyzivat wrote: > > Nikos, > > > > Following on to what has been said... > > > > Typically one would not set out to solve a problem in hardware unless > > there has been a demonstrated problem solving it in software. And, as > > Brandon says, you can't realistically expect to do the *whole* job in > > hw, so you will need something that can host the software part. So > > really you are talking about building a hw accelerator for a sw > > implementation. > > > > So, I would recommend looking around for a suitable sw implementation, > > and then study what could be accelerated. This probably makes no sense > > at all in a single user endpoint. There *might* be something to gain in > > a server, such as an SBC. > > > > Good luck, > > Paul > > > > On 3/17/12 12:31 PM, Brandon W. Yuille wrote: > >> The biggest problem I foresee is that you're trying to do something in > >> hardware which is normally done in software. With Nataraju's list I > >> would say the only point you can realistically accomplish in hardware > >> would be point 1. He also forgot to mention you'll need to handle > >> potentially the Ethernet MAC layer (must be hardware), IP/ARP, and UDP > >> transport which all could be done in hardware. With everything else > >> you're probably going to need to implement a soft core or use an > >> external cpu. Without one, you'd be attempting a monolithic problem that > >> most likely couldn't be built in under a year. So if you end up using a > >> cpu you may as well do all the protocol layers in software along with > >> the parsing to make your task easy. > >> > >> Good luck, > >> Brandon > >> > >> On 03/17/2012 08:51 AM, Nataraju A.B wrote: > >>> Tzanis, > >>> > >>> Simplest proposition would be to use the bottom-up approach. > >>> > >>> start with > >>> 1. Parser (encode/decoder) module > >>> 2. Transaction module (initially you design this module one for > UA > >>> only, exclude proxy specific > >>> processing to start with - for simplicity only) > >>> 3. Dialog module > >>> 4. Session module > >>> 5. Some application on top of SIP. > >>> > >>> One more suggestion would be to go through the OSIP / asterisk / > others... > >>> First you understand the basics, then you can proceed with VHDL based > >>> implementation... > >>> > >>> hope this helps... > >>> > >>> Thanks, > >>> Nataraju A B > >>> > >>> 2012/3/17 νικος τζανης<[email protected]> > >>> > >>> > >>>> Hello , I am a student and i was asked to implement sip in fpga . I > have > >>>> studied the rfc 3261 but i dont know where to start from .Sip is a > >>>> transaction based protocol . Do you have any idea on how to do this > thing? > >>>> I have found system offload engine (SOE) implementations but i want to > >>>> implement the whole transition model in vhld . Any help would be > >>>> appreciated . > >>>> > >>>> > >>>> Nikos Tzanis > >>>> _______________________________________________ > >>>> Sip-implementors mailing list > >>>> [email protected] > >>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >>>> > >>>> > >>> > >>> > >> _______________________________________________ > >> Sip-implementors mailing list > >> [email protected] > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > First of all thank you for the quick replies .I want you to know that I > m not trying to implement a commercial porduct but to go as far as i can > for educational reasons. So a simple model with them main features of > SIP would be ok . The first module(parser) is almost ready .When a > message arrive , i can find all the header-header value pairs and save > it in memory . Where a cpu could easilly find them . Surely a cpu is > needed , but if i could create standard messages too(with the minimum > fields required. To,From,Cseq,Call-id,Max Forward,Via . ) . I mean if > hardware could find these stored values and send the message ? But how > to go from the simple transaction model to vhld???where can i find the > techniques? > [ABN] if the parser is already being implemented in vhdl, next step i suggest you to try out is to integrate with the transaction and upper layer functions implemented in C/C++ code (probably you can take it from osip stack). This combination shall perform better (w.r.t processing time) than implementing complete OSIP stack written in C/C++ language. A different opinion/question altogether, if it is for educational purposes, is there a particular requirement to use vhdl ???? if not experimenting with complete osip stack is a better option. The only advantage i see in your scenario is faster message processing. if you think of maintainability try out anything with complete OSIP stack, that would provide you a better insight into SIP stack functionality. > thanks a lot once more > Nikos Tzanis > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Thanks, Nataraju A.B. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
