Maker Pro
Maker Pro

PCI interface

J

Jon Slaughter

Jan 1, 1970
0
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.

http://www.dell.com/content/topics/global.aspx/vectors/en/2004_pciexpress?c=us&l=en&s=corp

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
 
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
 
J

Jon Slaughter

Jan 1, 1970
0
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?

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
 
N

Nico Coesel

Jan 1, 1970
0
Jon Slaughter said:
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.)

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.
 
J

Jon Slaughter

Jan 1, 1970
0
Nico Coesel said:
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.


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.
 
P

petrus bitbyter

Jan 1, 1970
0
Jon Slaughter said:
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.

http://www.dell.com/content/topics/global.aspx/vectors/en/2004_pciexpress?c=us&l=en&s=corp

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

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
 
J

Jon Slaughter

Jan 1, 1970
0
petrus bitbyter said:
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.

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).
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.

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.

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.

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

http://www.national.com/appinfo/adc/ghz_adc.html

I have the 1500

and

http://www.national.com/pf/LM/LMH6555.html

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
 
N

Nico Coesel

Jan 1, 1970
0
Jon Slaughter said:
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

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.
 
N

Nico Coesel

Jan 1, 1970
0
petrus bitbyter said:
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.

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...
 
J

Jon Slaughter

Jan 1, 1970
0
Nico Coesel said:
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.

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
 
N

Nico Coesel

Jan 1, 1970
0
Jon Slaughter said:
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.

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.
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.

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.
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.

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.
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.

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

Jon Slaughter

Jan 1, 1970
0
Nico Coesel said:
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.

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.
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.

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.
 
P

Paul Hovnanian P.E.

Jan 1, 1970
0
Jon said:
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.

http://www.dell.com/content/topics/global.aspx/vectors/en/2004_pciexpress?c=us&l=en&s=corp

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*)

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.
 
N

Nico Coesel

Jan 1, 1970
0
Jon Slaughter said:
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
About the haystack. No, thats not true. You don't understand very well. You

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 :)
 
J

Jon Slaughter

Jan 1, 1970
0
Nico Coesel said:
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 :)

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.
 
N

Nico Coesel

Jan 1, 1970
0
Jon Slaughter said:
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.

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.
 
J

jasen

Jan 1, 1970
0
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)

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
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.

do you have a need to stream data to the PC faster than it can be displayed?
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?

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

Bye.
Jasen
 
J

Jon Slaughter

Jan 1, 1970
0
jasen said:
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.

Cool. I haven't thought about using a laptap but I guess it would be a good
idea.
SAS may be another option worth considering

Ok, I'll look into it. I don't know about anything about SAS.
do you have a need to stream data to the PC faster than it can be
displayed?

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.
pci express is faster and uses fewer pins... if you pick the right FPGA
there should be app-notes for PCI-Express

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
 
J

joseph2k

Jan 1, 1970
0
Jon said:
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

http://www.national.com/appinfo/adc/ghz_adc.html

I have the 1500

and

http://www.national.com/pf/LM/LMH6555.html

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
Take a look at this, it is spreading the data 8 ways just to handle a 500
Ms/s ADC. www.maxim-ic.com/appnotes.cfm/appnote_number/948
 
J

Jon Slaughter

Jan 1, 1970
0
Take a look at this, it is spreading the data 8 ways just to handle a 500
Ms/s ADC. www.maxim-ic.com/appnotes.cfm/appnote_number/948
--

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
 
Top