From: strut911@hotmail.com (strut911) Newsgroups: comp.arch.fpga Subject: designing a protocol analyzer for proprietary serial bus Date: 6 Feb 2002 10:33:04 -0800 Organization: http://groups.google.com/ Lines: 23 Message-ID: <4379d3e0.0202061033.1fb0aadd@posting.google.com> NNTP-Posting-Host: 24.126.132.195 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1013020384 8874 127.0.0.1 (6 Feb 2002 18:33:04 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 6 Feb 2002 18:33:04 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!41654!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14016 hello. i have been given the task of designing a protocol analyzer for my company's proprietary serial bus to help speed up the software design. i guess that means it needs to be finished quickly because software is really struggling right now. i have never designed a protocol analyzer before, but my first instincts are that i will need an fpga, a bunch or RAM (or Block RAM) if the quantity is sufficient, and a microcontroller. the serial bus runs at a max speed of 25 mhz although it can be slower if needed. i think it would be no problem to hit that target in today's FPGAs. my main question would be how to partition the hardware and software to be optimal to the design. my first thoughts were to take the incoming serial data, dump it all to memory when some trigger condition is asserted, and then have software post-process it into the various protocol control or data fields. if it is this easy (i doubt it is), then my fpga requirements would be minimal. however, when i look at the ethernet protocol analyzer my company has, it looks quite a bit more sophisticated than my minimalist design. another idea i had was to forget the microcontroller, and dump the memory contents to a PC when the data acquisition is finished. that way, i can let the PC post-process all the data and put it in a nice, colorful gui. are my ideas too simplistic? strut911 ###### From: kayrock66@yahoo.com (Jay) Newsgroups: comp.arch.fpga Subject: Re: designing a protocol analyzer for proprietary serial bus Date: 6 Feb 2002 16:50:43 -0800 Organization: http://groups.google.com/ Lines: 34 Message-ID: References: <4379d3e0.0202061033.1fb0aadd@posting.google.com> NNTP-Posting-Host: 66.47.203.26 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1013043043 19624 127.0.0.1 (7 Feb 2002 00:50:43 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 7 Feb 2002 00:50:43 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14061 Is your approach too simplistic? No way man, its right on. Look at CATC's USB serial bus analyzer, thats what he did. For a onesy twosy kind of application you might even be able to get a data acquisition card or use a logic analyzer with a link to a PC (TCP/IP or HP-IB) as your front end and do the parsing in VB or whatever. My motto is "make the hardware soft, and make the software hard". Regards strut911@hotmail.com (strut911) wrote in message news:<4379d3e0.0202061033.1fb0aadd@posting.google.com>... > hello. > i have been given the task of designing a protocol analyzer for my > company's proprietary serial bus to help speed up the software design. > i guess that means it needs to be finished quickly because software is > really struggling right now. i have never designed a protocol analyzer > before, but my first instincts are that i will need an fpga, a bunch > or RAM (or Block RAM) if the quantity is sufficient, and a > microcontroller. the serial bus runs at a max speed of 25 mhz although > it can be slower if needed. i think it would be no problem to hit that > target in today's FPGAs. my main question would be how to partition > the hardware and software to be optimal to the design. my first > thoughts were to take the incoming serial data, dump it all to memory > when some trigger condition is asserted, and then have software > post-process it into the various protocol control or data fields. if > it is this easy (i doubt it is), then my fpga requirements would be > minimal. however, when i look at the ethernet protocol analyzer my > company has, it looks quite a bit more sophisticated than my > minimalist design. > another idea i had was to forget the microcontroller, and dump the > memory contents to a PC when the data acquisition is finished. that > way, i can let the PC post-process all the data and put it in a nice, > colorful gui. are my ideas too simplistic? > strut911