Connect with us

PCI interface

Discussion in 'Electronic Design' started by Jon Slaughter, Apr 11, 2007.

Scroll to continue with content
  1. 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
     
  2. Guest

    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
     
  3. 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
     
  4. Nico Coesel

    Nico Coesel Guest

    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.
     

  5. 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.
     
  6. 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
     
  7. 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
     
  8. Nico Coesel

    Nico Coesel Guest

    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.
     
  9. Nico Coesel

    Nico Coesel Guest

    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...
     
  10. 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
     
  11. Nico Coesel

    Nico Coesel Guest

    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.
     
  12. 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.
     
  13. 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.
     
  14. Nico Coesel

    Nico Coesel Guest

    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 :)
     
  15. 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.
     
  16. Nico Coesel

    Nico Coesel Guest

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

    jasen Guest

    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
     
  18. 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
     
  19. joseph2k

    joseph2k Guest

    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
     
  20. 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
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-