PCI FSM

[leaf]

To anyone familiar with PCI target core design:
consider this code: (part of the Target State Machine)

when IDLE =>
if (PCI_Frame_n = '0' and Hit = '0') then
nextState <= B_BUSY;
else
nextState <= IDLE;
end if;

when B_BUSY =>
...

i'm currently (re)developing my PCI target core so that it 'support'
the State machine design documented on the PCI Local Bus Specification
3.0

my question is that how can this state machine go to the next state if
PCI is doing a configuration read...
considering that:

Hit <= '1' when (( pci_ad = bar ) and mem_en ) else '0'; --// mem_en =
cben(1) during config reads...

NOTE:
configuration read: frame# is asserted, config register address is
placed on AD bus,
command is place in cben and idsel is asserted...
also note that frame# is asserted only for 1 clock cycle (config_read)
and this happens on second rising edge of "clk" lets assume...

in this case: valid Address (probably address of BAR0 4h) will only be
latched at second rising edge of "clk" also the command...
--------------------

following the State machine we have IDLE at first, and will be IDLE
until FRAME# is asserted (probably at second rising edge )
at this point there is valid address/conmmand on PCI bus.

but Hit is still ZERO since pci_ad = bar is FALSE...
(and hit will never be ONE since valid address/command to decode only
happen on second rising edge, for our example)...

At a PCI Target State Machine when is the time to latch Address and
Command for decoding? should it be done seperately from the FSM?

---
YOUNG_LEAF

 

[Kim Enkovaara]

leaf wrote:

To anyone familiar with PCI target core design:
consider this code: (part of the Target State Machine)
....
i'm currently (re)developing my PCI target core so that it 'support'
the State machine design documented on the PCI Local Bus Specification
3.0

I guess you read the beginning of the chapter about state machines in
the specification. It says "The state machines are for illustrative
purposes only and are included to help illustrate PCI protocol.
Actual implementations should not directly use these state machines"
My copy is PCI 2.2, but I guess the warnings are still there.

At least I found it easier to do the state machines with some extra states.
It made some places easier to handle, especially in the target side.

--Kim

 

[leaf]

Yes. but i have found many PCI IP Cores implementing the B_BUSY state
and many people adviced to have one...
Anyway
The real problem that i'm facing is how to relate the State Machine to
a Configuration read.
( in what state the actual writing to Configuration registers occur?
S_DATA? how is it able to go to that state)

BTW, if you have made a PCI core, did you implemented a address Hit
input to your state machine?

--
yl

 

[Kim Enkovaara]

leaf wrote:

The real problem that i'm facing is how to relate the State Machine to
a Configuration read.
( in what state the actual writing to Configuration registers occur?
S_DATA? how is it able to go to that state)

BTW, if you have made a PCI core, did you implemented a address Hit
input to your state machine?

I have Hit signal for the address, but also one extra check !FRAME&IDSEL
to identify configuration access. And my state machine has some extra states,
it goes to B_BUSY only as a exception. I have splitted the S_DATA to few
states that can be reached directly from the IDLE state.

There are many ways to do the PCI state machines and what I remeber
(I did the core long time ago) the ones in the standard can create
some nasty problems. Splitting some of the states makes coding
and debugging easier.

--Kim

 

[leaf]

Actualy i already have a working PCI core, but it does not work on
other pc i dont know why.
It has state: CONFIG_READ, CONFIG_WRITE, IO_READ,IO_WRITE, MEM_READ,
MEM_WRITE....
very specific though

BTW, with that Hit signal you how did you enable if to do the actual
writing to the BAR register....
i mean from IDLE state did you went directly to S_DATA (or the state in
which PCI write to Configuration register )?

Anyway, have you experienced the same problem that i have, ie. PCI not
working on other PC ( of different motherboard )?
But it has same PCI spec.

---
Leaf

 

[leaf]

ps.
i have implemented a DataPath:
DATAPATH: PROCESS (clk33)
BEGIN
if ( rising_edge(clk33) ) then
Pci_Ad_Reg <= ad;
Pci_Cben_Reg <= cbe_n;
Pci_Frame_n <= frame_n;
Pci_Irdy_n <= irdy_n;
end if;
END PROCESS;

Is it advisable to latch those signals?

---
Leaf

Ayon kay leaf:

Actualy i already have a working PCI core, but it does not work on
other pc i dont know why.
It has state: CONFIG_READ, CONFIG_WRITE, IO_READ,IO_WRITE, MEM_READ,
MEM_WRITE....
very specific though

BTW, with that Hit signal you how did you enable if to do the actual
writing to the BAR register....
i mean from IDLE state did you went directly to S_DATA (or the state in
which PCI write to Configuration register )?

Anyway, have you experienced the same problem that i have, ie. PCI not
working on other PC ( of different motherboard )?
But it has same PCI spec.

---
Leaf

 

[Kim Enkovaara]

leaf wrote:

Anyway, have you experienced the same problem that i have, ie. PCI not
working on other PC ( of different motherboard )?
But it has same PCI spec.

I would guess that it could be a timing problem (PCI timing is quite tight in
some places). I guess you have all the timing constraints from the standard in
your STA setup.

One possibility is also that you have something funny in the configuration space,
and the BIOS doesn't like that.

Usually it easiest to plug in a PCI bus analyzer and check what happens in the bus.
You can get quite "cheap" PCI analyzer software for example to new Tektronix
logic analyzers. It's nice to see what really happens in the bus.

--Kim