I’m accessing the config space because it seemed like the only way to know
if “my” board caused the interrupt, and to “clear” the signal.
The board uses an ACTEL FPGA with “ACTEL CorePCI” as it’s PCI core. The
register I’m accessing is the “Interrupt Control/Status Register” (0x48) as
documented here:
http://www.actel.com/ipdocs/CorePCI_DS.pdf
(Page 16, Table 15)
The document describes Version 5.41 of the ACTEL CorePCI, we’re using
Version 5.3, but the “Interrupt Control/Status Register” is the same in
both versions (and I didn’t find a description of the old version on the
net).
I’m using Bit 8 to test (and clear if necessary) the interrupt condition.
The program for the FPGA and the board were not developed in house, and I
just assumed that the guy who did the design & programming knew what he was
doing.
If you tell me it’s a design flaw I can’t (and won’t) argue with you, only
there’s nothing that I can do about it. There are thousands of boards in
use, and we can’t replace them all - I still have to find a way to fix this
problem without changing the hardware.
Thanks for your input anyway 
Cheers, Paul
Why are you accessing the PCI config space from the ISR?
It is a hardw
are misdesign, and was so since around 1999 when MS published
the PCI hardware design guidelines (as a .PPT file).
“No status and control registers in config space” - this is a
requirement.
Config space is only for some mode-con
trol registers which are touched only at
init or some mode changes,
but not during the usual device IO procedures.
This also means - do not ever touch the config space from the ISR.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> > …
Do they have the same Interrupt Control/Status Register somewhere in BARs?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
>
> I’m accessing the config space because it seemed like the only way to know
> if “my” board caused the interrupt, and to “clear” the signal.
> The board uses an ACTEL FPGA with “ACTEL CorePCI” as it’s PCI core. The
> register I’m accessing is the “Interrupt Control/Status Register” (0x48) as
> documented here:
>
> http://www.actel.com/ipdocs/CorePCI_DS.pdf
> (Page 16, Table 15)
>
> The document describes Version 5.41 of the ACTEL CorePCI, we’re using
> Version 5.3, but the “Interrupt Control/Status Register” is the same in
> both versions (and I didn’t find a description of the old version on the
> net).
>
> I’m using Bit 8 to test (and clear if necessary) the interrupt condition.
>
> The program for the FPGA and the board were not developed in house, and I
> just assumed that the guy who did the design & programming knew what he was
> doing.
>
> If you tell me it’s a design flaw I can’t (and won’t) argue with you, only
> there’s nothing that I can do about it. There are thousands of boards in
> use, and we can’t replace them all - I still have to find a way to fix this
> problem without changing the hardware.
>
> Thanks for your input anyway
> Cheers, Paul
>
> > Why are you accessing the PCI config space from the ISR?
> > It is a hardw
> are misdesign, and was so since around 1999 when MS published
> > the PCI hardware design guidelines (as a .PPT file).
> > “No status and control registers in config space” - this is a
> requirement.
> > Config space is only for some mode-con
> trol registers which are touched only at
> > init or some mode changes,
> but not during the usual device IO procedures.
> > This also means - do not ever touch the config space from the ISR.
> > –
>
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> > wrote in message news:xxxxx@ntdev…
> > > …
>
>
I checked the documentation again.
There is nothing in the BARs 
The documentation (written by the guy who
made the FPGA program) explicitly states that we have to use CONFIGURE_READ
and CONFIGURE_WRITE to access that register. Also I didn’t find anything in
the docs from ACTEL that suggests there there’d by any default mapping to a
BAR.
xxxxx@lists.o
sr.com schrieb am 17.10.2007 00:04:03:
Do they have the same Interrupt Control/Status Register somewhere in
BARs?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> >
> > I’m accessing the config space because it seemed like the only way to
know
> > if “my” board caused the interrupt, and to “clear” the signal.
> > The board uses an ACTEL FPGA with “ACTEL CorePCI” as it’s PCI core. The
> > register I’m accessing is the “Interrupt Control/Status Register”
(0x48) as
> > documented here:
> >
> > http://www.actel.com/ipdocs/CorePCI_DS.pdf
> > (Page 16, Table 15)
> >
> > The document describes Version 5.41 of the ACTEL CorePCI, we’re using
> > Version 5.3, but the “Interrupt Control/Status Register” is the same in
> > both versions (and I didn’t find a description of the old version on
the
> > net).
> >
> > I’m using Bit 8 to test (and clear if necessary) the interrupt
condition.
> >
> > The program for the FPGA and the board were not developed in house, and
I
> > just assumed that the guy who did the design & programming knew what he
was
> > doing.
> >
> > If you tell me it’s a design flaw I can’t (and won’t) argue with you,
only
> > there’s nothing that I can do about it. There are thousands of boards
in
> > use, and we can’t replace them all - I still have to find a way to fix
this
> > problem without changing the hardware.
> >
> > Thanks for your input anyway
> > Cheers, Paul
> >
> > > Why are you accessing the PCI config space from the ISR?
> > > It is a hardw
> > are misdesign, and was so since around 1999 when MS published
> > > the PCI hardware design guidelines (as a .PPT file).
> > > “No status and control registers in config space” - this is a
> > requirement.
> > > Config space is only for some mode-con
> > trol registers which are touched only at
> > > init or some mode changes,
> > but not during the usual device IO procedures.
> > > This also means - do not ever touch the config space from the ISR.
> > > –
> >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com
> > > http://www.storagecraft.com
> > > wrote in message news:xxxxx@ntdev…
> > > > …
> >
> >
> —
> NTDEV is sponsored by OSR
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
> To unsubscribe, visit the List Server section of OSR Online at http:
> //www.osronline.com/page.cfm?name=ListServer
From your attached spec, it seems like you should be able to map these
registers to bar2 such that it can be accessed through mem or i/o cycles.
see page 20 of your doc. Pay attention to DMA_IN_IO. Also take a look at
“Master Register Access” and table 21 on page 19.
They provide VHDL/verilog code, you can always modify it if it doesn’t work
as what their spec claims. shouldn’t be a big deal.
–
Calvin Guan
Principal Engineer
Broadcom Corporation
Connecting Everything(r)
wrote in message news:xxxxx@ntdev…
>
> I checked the documentation again.
> There is nothing in the BARs The documentation (written by the guy who
> made the FPGA program) explicitly states that we have to use CONFIGURE_READ
> and CONFIGURE_WRITE to access that register. Also I didn’t find anything in
> the docs from ACTEL that suggests there there’d by any default mapping to a
> BAR.
>
> xxxxx@lists.o
> sr.com schrieb am 17.10.2007 00:04:03:
>
>> Do they have the same Interrupt Control/Status Register somewhere in
> BARs?
>> –
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>> wrote in message news:xxxxx@ntdev…
>> >
>> > I’m accessing the config space because it seemed like the only way to
> know
>> > if “my” board caused the interrupt, and to “clear” the signal.
>> > The board uses an ACTEL FPGA with “ACTEL CorePCI” as it’s PCI core. The
>> > register I’m accessing is the “Interrupt Control/Status Register”
> (0x48) as
>> > documented here:
>> >
>> > http://www.actel.com/ipdocs/CorePCI_DS.pdf
>> > (Page 16, Table 15)
>> >
>> > The document describes Version 5.41 of the ACTEL CorePCI, we’re using
>> > Version 5.3, but the “Interrupt Control/Status Register” is the same in
>> > both versions (and I didn’t find a description of the old version on
> the
>> > net).
>> >
>> > I’m using Bit 8 to test (and clear if necessary) the interrupt
> condition.
>> >
>> > The program for the FPGA and the board were not developed in house, and
> I
>> > just assumed that the guy who did the design & programming knew what he
> was
>> > doing.
>> >
>> > If you tell me it’s a design flaw I can’t (and won’t) argue with you,
> only
>> > there’s nothing that I can do about it. There are thousands of boards
> in
>> > use, and we can’t replace them all - I still have to find a way to fix
> this
>> > problem without changing the hardware.
>> >
>> > Thanks for your input anyway
>> > Cheers, Paul
>> >
>> > > Why are you accessing the PCI config space from the ISR?
>> > > It is a hardw
>> > are misdesign, and was so since around 1999 when MS published
>> > > the PCI hardware design guidelines (as a .PPT file).
>> > > “No status and control registers in config space” - this is a
>> > requirement.
>> > > Config space is only for some mode-con
>> > trol registers which are touched only at
>> > > init or some mode changes,
>> > but not during the usual device IO procedures.
>> > > This also means - do not ever touch the config space from the ISR.
>> > > –
>> >
>> > > Maxim Shatskih, Windows DDK MVP
>> > > StorageCraft Corporation
>> > > xxxxx@storagecraft.com
>> > > http://www.storagecraft.com
>> > > wrote in message news:xxxxx@ntdev…
>> > > > …
>> >
>> >
>> —
>> NTDEV is sponsored by OSR
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>> To unsubscribe, visit the List Server section of OSR Online at http:
>> //www.osronline.com/page.cfm?name=ListServer
>
>
Thanks for the hint Calvin.
Of course that would mean changing the hardware, which is something we
might do for new boards, but we cannot replace the old ones.
From your attached spec, it seems like you should be able to map these
registers to bar2 such that it can be accessed through mem or i/o cycles.
see page 20 of your doc. Pay attention to DMA_IN_IO. Also take a look at
“Master Register Access” and table 21 on page 19.
They provide VHDL/verilog code, you can always modify it if it doesn’t
work
as what their spec claims. shouldn’t be a big deal.
Calvin Guan
Principal Engineer
Broadcom Corporation
Connecting Everything(r)
wrote in message news:xxxxx@ntdev…
> >
> > …