Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

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

Status
Not open for further replies.

linch

Junior Member level 1
Joined
Jul 20, 2001
Messages
15
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
38
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!
 

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
 

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!
 

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.
 

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 :cry:

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.
 

Hello :
Thanks very much for your answer ! :lol:
 

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

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.
 

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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top