Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronic 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.

Register Log in

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!
 

konrad

Junior Member level 1
Joined
May 16, 2001
Messages
15
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
46
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
 

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

sbob

Member level 1
Joined
Feb 13, 2002
Messages
37
Helped
4
Reputation
8
Reaction score
1
Trophy points
1,288
Activity points
261
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.
 

vomit

Full Member level 2
Joined
Jun 14, 2002
Messages
148
Helped
14
Reputation
28
Reaction score
4
Trophy points
1,298
Activity points
1,527
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.
 

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
Hello :
Thanks very much for your answer ! :lol:
 

igorz

Junior Member level 1
Joined
Mar 30, 2002
Messages
16
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
112
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).
 

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

igorz

Junior Member level 1
Joined
Mar 30, 2002
Messages
16
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
112
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.
Toggle Sidebar

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top