PCI interface

Is it hard to design an interface that uses PCI(Express)? I want to create a way to dump data(such as from a dac or just digital logic) into a pc's memory and I want it to be fast as possible. Would using a PCI card be the most direct and fastest way or are there comparable interfaces such as 1394 or even USB 2.0 that would be much easier? I recall a while back(several years) seeing a tutorial on creating ISA interfaces and if I remember correctly it wasn't to hard. Now that we have PCI and 1394 I'm wondering which rought I should go. Right now I'm working with the parallel port and its just going to be to slow for my eventual needs. I see that the PCI bus can run about 500MB/s while USB 2.0 is about 60MB/s. I'd rather use the PCI Bus if possible although firewire is about 100MB/s. I also see that PCI-Express is about 1GB/s and AGP is around 2GB/s. (these are ofcourse the maximum bandwidth available)

My pipe dream is to use some 1.5GS/s ADC's I got and try to use them to design a pc based scope and/or logic analyzer. Probably to many technical issues that will limit the performance and effectiveness but even if I could get it to only operate at 1/100 that ability I would be happy(then I could worry about redesigning it).

What I'm worried about is all the setup, initalization, and communication procedures will just be to complex to dump data. USB 2 is nice but it seems to limit real time transfers to about 60MHz for an 8-bit oscope which means your probably getting a scope with a resolution of about 6MHz.

From what I remember, AGP has direct access to the memory and if its not to difficult one could design a scope that uses the AGP slot and either get a dual AGP MB or use a PCI video card for the video interface. Then one could just dump the data to the memory directly.

formatting link

Ofcourse I expect a lot of flames about the impossibility of this idea but whether its practical or not is not important to me. Its not that I expect to reach my goal but even if I get something that works decent would be nice. (Hell, even if it works at all would probably make me happy)

Basicaly what I want is a way to use PC memory has storage for sorta a digital storage oscope. The software side is not to diffcult but its getting the information into memory to actually to something useful with it and I want something a bit more than what the parallel port can do. USB 2.0 or firewire seems like an easy way to go but if I can get 10x more bandwidth from use a pci card then maybe its worth it if its not to much more complicated?

Anyways, Let the flames begin.... although it would be appreciated if someone actually has some useful comments. If you are going to say it is impossible or virtually impossible then atleast have the decency to state why. (If you think I cannot do it then that is a different store that I do not want to hear. I'm hear to learn and I can still learn by *trying*)

Thanks, Jon

Reply to
Jon Slaughter
Loading thread data ...

Memory is cheap, so why not buffer a capture sweep to some ram which is local to the adc and then use whatever method is easiest to get the data into the PC?

John

Reply to
jrwalliker

Thats was one idea I had but I wonder why most pc scopes do not do this? Most just have a few KB and at most a few MB. I imagine that it is probably more difficult to design a high speed memory controller. I just figure that since the pc already has all this stuff one should take advantage of it.

It just seems like its probably much more complicated? (and its complicated enough I suppose.)

Thanks, Jon

Reply to
Jon Slaughter

A PC can't handle the bandwidth for a prolonged period. Besides, you'll need some processing to display the signal. Processing -say- 1 GB of data takes a while even if you have a fast processor.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

I'm not going to display the data in real time. Atleast that doesn't have to be an option. In any cause the display of the signal is at a far smaller resolution than the signal itself so you can ignore a lot of the data. The high bandwidth is for non-realtime analysis such as zooming in on the signal or data analysis. It doesn't do you much good to view a signal thats going by at 1Ghz because your eyes can't follow it unless its periodic. But if you have a history you can scroll through even if its not periodic. Ofcourse you'll still end up ignoring most of the samples or need some inteligent software to make it easier to traverse the history.

Reply to
Jon Slaughter

"Jon Slaughter" schreef in bericht news:pDYSh.2206$ snipped-for-privacy@newssvr17.news.prodigy.net...

formatting link

Jon,

I ever did ISA-bus interfacing. Just what you want. Collecting data and writing it directly in the PC memory. I used a dual port memory controller which could not be accessed by the PC during activity on the other port. It was not easy but it could be done as I had the specifications of signals and timing of the ISA bus. But times are changing. FAIK the full specifications of PCI and PCI-express are not in the public domain. But even if you can find them, it's far from easy to implement. Much more complicated, much more critical timing and much higher speeds then the old ISA. Guess you need some expensive equipment too. Besides, it's no use to reinvent this wheel. You can buy chip(set)s or VHDL/Verilog sources. (You can find some interesting VHDL/Verilog sources in the public domain but I don't know about PCI.) If you overcome this problems, you can still not write into the memory directly. Todays hardware does its own memory mapping and you cannot control this with user level software. That's why you need special video drivers when using video controllers that need direct memory access. They have to interfere in the lowest level low level software. It can all be done. It has been done already after all. But I consider it too impractical for your desires.

One more thing to think about. Once you have a fast way to get data from a AGP/PCI card into the memory, you still need to gather this data and sent it to the card.

IMHO the most important part of your design is the input amplifier and the AD converter. (And it's the part I'm most interested in.) Once you have the digital data, it can relativly easy be buffered and sent to a computer in a more convenient way and speed.

petrus bitbyter

Reply to
petrus bitbyter

formatting link

Yeah, but maybe I could hack an old PC. There pretty cheap and I threw all mine away. There are ways to get directly at memory and I used to do a lot of low level protected mode programming. Also I could take control of the mapping write a small os and kernel and bypass working directly in windows. Ofcourse this then presents its own set of problems. But since I'm do not need real time display of the signal I do not see anything but getting the data in memory as the problem. (if you have all the data in memory or even cached then you can look at it when you want).

yeah. But this are not difficult to do. Ofcourse doing it well is a totally different story. I can, right now, take a simple audio ADC and use the parallel port to gather the data and then display the waveform on screen. If I took that 192khz sampling rate and tried to do it with 100mhz then I'm screwed. I'm not talking about a necessarily great digitizing system but just something that has all the basics down. (Conversion, storage, and manipulation/display) This is mainly for learning purposes and not trying to make the next best pc scope.

But I'm not to concerned with that side of it as I can hack together some stuff for education purposes(which means that I'm not worried about performance or quality). I can figure out how to improve it once I have something to work with if that ends up being my goal. The issue I'm having is scalability. I can I scale up a simple ADC with say a few mega samples/sec to one of several hundred? I can't see how I can do this because of the technical issues involved. If I can shift as much as possible to the pc then I can spend more time on the things that I cant.

Chances are I'll end up using USB and have to limit my sampling rate to something that is reasonable.

What I have is at

formatting link

I have the 1500

and

formatting link

I also have several smaller ADC's that I can use and a few articles about running them in interleaved and parallel mode for either improved sampling rate or improved SNR.

I do realize that chances are I will not be able to make something good even if it does work but I can learn a lot in trying and it can help out in some other things I want to do.

Thanks, Jon

Reply to
Jon Slaughter

If you ignore data, you'll be cutting important information. You'll need to present the user something which contains all information. This is the well known peak-detect mode available on every usefull DSO. Still, you could sample first, show later. Showing data while sampling will be a lot harder.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

With some hacking it is pretty easy to get a blazing fast PCI design going without having to mess with drivers at all! The basic transaction of PCI is not so difficult to implement if there are no other devices on the bus.

You can use several PCI Express to PCI bridges on one card in a slot with multiple PCI Express lanes. This way you can create multiple PCI busses on the card (like 64bit 133MHz busses which can convey almost

1GB/s). Connecting an FPGA is not a big issue since the termination issues which usually come along with with PCI are as good as absent. You control both master and slave.

Now the trick is to emulate a well know ethernet card and pack your data into UDP packets and pump the information into the PCI busses.

Now the software is a breaze, assign IP addresses to the cards, open a socket and listen for incoming data. With some care, platform independance comes for free...

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

your only ignoring information for viewing purposes. The user has control of how much of the information they want to see.

Showing the data in real time is not harder as you can just show every

1000th sample. If your sampling at 1GS/s then this means you have reduced the sampling rate to 1M. This is not difficult to display. If it is then only show ever 10000th sample. Ofcourse now your ignoring a huge amount of data... but guess what? Its in memory! So if the user wants to go back and look more closely at a specific part of the signal then they can and you will pull in more samples... not so much that your wasting processing displaying two or more samples per pixel. Just can't happen.

The point is, that all the real data is in memory and you display only what actually can be understood. You cannot display more than about 1000 samples on a standard monitor at any given time. This is independent of the time those samples represent. You cannot display more than one sample per pixel because you only have one pixel. You can but your just wasting time drawing something that won't be seen. The same idea happens in 3D graphics optimization. You do not display objects that cannot be seen by the viewport because its a waste of processing. Without that simple idea you could not have real time 3D graphics that you have today.

But you kinda have it right. You do sample first and show later(obviously there is a latency) but you also sample and show simulataneously. But you do not show anything that is wasteful. You show enough to give the user an idea of the waveform and not any more.

Actually it would be more effective to do some sort of averaging on all the samples than just ignoring blocks and this will get a true representative of the waveform removing the higher frequencies and making it more appropriate for viewing.

If you need an sample, Take a square wave at 100hz with some sinusoidal noise of 1mhz

Suppose your sampling this at 1Ghz. Now do you really think you have to display all the samples on the monitor? Do you even think that you could? If you did and your viewing this signal in memory and not in real time then your monitor would have to be 1 billion pixels wide to actually show every sample. Even if that were the case it would probably need to be several hundred(a guess) feet wide just so your eyes could differentiate the pixels. (if you scaled the pixels so the monitor could fit on a desk then they would be to small to see).

Now take the square wave in the example. Suppose you set the time base so that you see 3 periods. Do you think you'll be able to detect that noise? Ofcourse it depends on the amplitude but we'll assume its small. Sure you might see some of the effects but you'll get a very good idea of the wave form(double you'll see anything but a perfect square wave though in this case). Now suppose you want to see if there whats really going on. Just "zoom in". Zoom in on a corner of the square wave. You'll can now bring in more samples and you'll be looking at more bandwidth of the waveform.

In any case even if you displayed this in real time and you were sampling at

1GS/s your monitor doesn't have hight enough refersh rate to display anything above about 10^5hz. (assuming standard monitor and refresh rate of 100hz). Even if it could display at 1Mhz your eyes only work at about 35hz or so it won't make a difference.

Ofcours say your doing RF and you have a carrier frequency of 100mhz. You could display the total wave form or just demodulate and then display that. In this case I suppose you'll want to demodulate before you digitize it but you could sample first and then demodulate afterwards in software. Ofcourse it will take time to demodulate in the sofware and your limiting the carrier frequency by the sampling rate.

In any cause the main use of what I want to do is not a real time display of a signal but a history of it. Ofcourse one wants real time feed back and this can easily be accomplished. You don't have to show the full signal in real time to actually see whats going on.

Jon

Reply to
Jon Slaughter

You'll have to. In one way or another you can't tell which sample is important and which is not. Some Tek scopes solve this by showing an arched area in which the signal moved. This involves evaluating all samples and determine minimum and maximum values.

You've found a very good analogy; like you need to process samples you can't 'see', you'll need to deal with objects which cast a shadow on certain areas or emit light even though they may be outside the viewport or too small to render.

That sounds like a pretty useless oscilloscope to me. Lecroy actually made DSOs like that -completely useless-.

I want an oscilloscope which shows the imperfections of a signal (ringing, overshoot, edges). If you don't know an anomaly is there, you won't zoom into a piece of a signal. In your scenario, the user would need to go through all the data with a comb looking for the needle in the haystack.

An oscilloscope is never real-time. There is always dead-time between sweeps.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

No, thats not real time rendering(well, its becoming that way). That is ray tracing but games now days use ray casting. You cannot ray trace in real time yet to any significant degree.

I'm not going to argue about it any more. You don't have to understand or believe what I'm saying. Your ringing example is no counter example though because you still cannot see the higher frequency components. There is always a band limiting aspect after the conversion and your not taking that into account. That or you act like I'm going to only display the such a small portion of the total spectrum of the signal to make it useless. That is not the case. I will display what is only necessary for real time and leave the rest for non-real time purposes.

I guess we have two different approaches. My goal is not to see the complete signal in real time but have a history of the whole signal so I can go look back at it. For example, I could use a scope like this as a logic analyzer. A digital signal is simply a signal. I would digitize it, go look at it and see what happened. With a analog scope this is impossible because you have no way to see the history. If you try to view it in real time then chances are you'll not catch anything because it went by too fast. If you have the whole signal stored in memory then you can easily go back and do processing on it and view it. You can even view it for ringing and such and get all the details you need up to the bandwidth/sample rate of the conversion. Ofcourse even if its not in real time you don't need to display unnecessary information that the user cannot process.

About the haystack. No, thats not true. You don't understand very well. You can have triggers, intelligent searches, etc... I'd take that ability to be able to go back and look at some instant of the signal that was momentary than loose it for ever. Ofcourse if your dealing with several seconds of a signal samples at about 1GS/s then it would probably take you several days to find some random event that happened. Having some intelligent way to go through the signal would move that down to a few mins. Similary to how a word processing application works. If your looking for every instance of some word you do not have to manually search through the whole document.

You could have something like "bookmarks" that set a bookmark when a search "trigger" occured. This way you can very easily navigate to specific events. I'm sure there are many other things one can come up with to make it easier to work with.

Reply to
Jon Slaughter

formatting link

There are some PCI Bus interface chips around. Google returns some info.

Also, take a look at opencores.org for some FPGA solutions that might be adaptable for your application.

--
Paul Hovnanian     mailto:Paul@Hovnanian.com
------------------------------------------------------------------
 Click to see the full signature
Reply to
Paul Hovnanian P.E.

I have a very very thourough understanding what I'm talking about here. Wait a few more months and see for yourself. Start saving your money :-)

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

What your talking about and what you understand what your talking about is totally different from what I'm talking about and what I understand about it.

Again, you seem to think that monitor resolution is infinite. Its not. You also think that the eye has infinite capabilities too. Its not. Once you realize this then maybe we'll finish the dicussion.

Reply to
Jon Slaughter

I realize this very well and that's why I've come up with nifty

-tested- solutions that deal with the problem of showing signals on a limited resolution screen in a very efficient way.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

If your're designing new hardware go with PCI-express, it's replacing PCI and (in its x8 ansd x16 versions) AGP as a bonus you'll be electrically compatible with PCMCIA Expresscard which is replacing PCMCIA PC-Card in laptops etc.

SAS may be another option worth considering

do you have a need to stream data to the PC faster than it can be displayed?

pci express is faster and uses fewer pins... if you pick the right FPGA there should be app-notes for PCI-Express

Bye. Jasen

Reply to
jasen

Cool. I haven't thought about using a laptap but I guess it would be a good idea.

Ok, I'll look into it. I don't know about anything about SAS.

Yes, only for memory storage. The alternative is to include a large amount of local memory on the scope itself and just stream a portion to the pc for display. This is an alternative but I feel it would be much more complicated creating a such a design that works at the high speeds that I need them to. Having a fast interface with the PC is ultimately going to be better in any case though.

Ok, thanks. I'll look into it. I'm still months if not years from actually tackling this. I'm thinking about just building something slower at first and use something like USB 2.0 or firewire and then work out all the details for that. Afterwards I'll try to step it up a bit.

Thanks again, Jon

Reply to
Jon Slaughter

formatting link

Take a look at this, it is spreading the data 8 ways just to handle a 500 Ms/s ADC.

formatting link

--
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
 Click to see the full signature
Reply to
joseph2k

Yes, the 1GS/s ADC I'm using does a similar thing where it splits the conversion into two data paths to reduce the individual memory speed.

Looks like a good article. I'll try to read it soon as I think it will definitely come in handy.

Thanks, Jon

Reply to
Jon Slaughter

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.