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?

     thanks a lot once more
Nikos Tzanis
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to