+ Post New Thread
Results 1 to 9 of 9
  1. #1
    Junior Member level 1
    Points: 2,352, Level: 11

    Join Date
    Jul 2001
    Posts
    15
    Helped
    0 / 0
    Points
    2,352
    Level
    11

    The size limit of IO space in each BAR of a PCI card

    Hi :
    I read PCI SPEC 2.2. In page 203, it mentions that:
    "Devices that map control functions into IO space must not consume more than 256 bytes per IO Base Address register."

    What does "control functions" mean? Why there is such limit? :(

    Please help me to find an answer! Thanks very much!

    •   AltAdvertisement

        
       

  2. #2
    Junior Member level 1
    Points: 4,337, Level: 15

    Join Date
    May 2001
    Posts
    15
    Helped
    0 / 0
    Points
    4,337
    Level
    15
    I would say that the reason for such a limit that the IO space is very limited in a PC, if you want more just use Memory mapped instead

    /Konrad



  3. #3
    Junior Member level 1
    Points: 2,352, Level: 11

    Join Date
    Jul 2001
    Posts
    15
    Helped
    0 / 0
    Points
    2,352
    Level
    11
    Hi :
    Thanks for your reply. I remember that the total IO space in PC is "64KB". Comparing to 64KB, 256Bytes is not a reasonable limit.

    There must be other reasons!



  4. #4
    Member level 1
    Points: 2,377, Level: 11

    Join Date
    Feb 2002
    Posts
    37
    Helped
    4 / 4
    Points
    2,377
    Level
    11
    The motherboard uses IO space so the IO space available for expansion slots is a small slice of the total 64K. Use memory mapped registers.



  5. #5
    Full Member level 2
    Points: 3,509, Level: 13

    Join Date
    Jun 2002
    Posts
    148
    Helped
    14 / 14
    Points
    3,509
    Level
    13
    Also, the IO address lines in a PC are not all decoded in full. There are old (bad) ISA cards that "mirror" themselves several times over the IO space.

    This breaks the IO space in tiny fragments, hence the small limit on the amount of contiguous memory you can expect.

    Thank you, backwards compatibilty

    So you see a safe address allocation in IO space is hell, and you would be better off just putting your registers in noncached memory space instead.



  6. #6
    Junior Member level 1
    Points: 2,352, Level: 11

    Join Date
    Jul 2001
    Posts
    15
    Helped
    0 / 0
    Points
    2,352
    Level
    11
    Hello :
    Thanks very much for your answer !



  7. #7
    Junior Member level 1
    Points: 2,165, Level: 10

    Join Date
    Mar 2002
    Posts
    16
    Helped
    0 / 0
    Points
    2,165
    Level
    10
    I think, for control functions, it’s better to use I/O mapping, especially for first designs. Your will avoid problems with memory allocation in multitask operating systems, memory cashing, and many others.

    If I/O size isn’t enough, your can use “window” like access methods, multifunction devices, or try to enlarge it, requesting more I/O space (in some cases may work).



  8. #8
    Junior Member level 1
    Points: 2,352, Level: 11

    Join Date
    Jul 2001
    Posts
    15
    Helped
    0 / 0
    Points
    2,352
    Level
    11
    Hi Igorz:
    In other words, I can still build a PCI card which requires IO space more than 256Bytes. It will work if my PC has enough IO space for it.

    Is it correct? Thanks for your answer.



  9. #9
    Junior Member level 1
    Points: 2,165, Level: 10

    Join Date
    Mar 2002
    Posts
    16
    Helped
    0 / 0
    Points
    2,165
    Level
    10
    Hi Linch,

    of course, you can request more, then 256 I/O’s for one BAR, but no guarantee, whether will it work in your case or not.

    Best results (4K I/O, probably more) can be obtained for MS-DOS and old motherboards with minimum of periphery. Worst results (256 bytes I/O downto 0) => for latest Windows, or a heap of hardware on the computer.

    As far, as i can see, violation of PCI bus specifications is a usual practice for many small-series products designers, but obeying 256 I/O limit for one BAR seems to me more important than, for example, implementation of parity signal, latency timer etc.

    IMHO, using so much I/O’s or non-burst memory instead them, isn’t advisable, because it complicates design and may cause I/O ports shortage during Plug & Play. If your are going to use large amount of I/O ports, the best way to do so is to implement large amount of BAR’s with size of no more then 256 bytes, I presume.



--[[ ]]--