PCI Configuration access and Target State Machine...

How is a PCI target FSM related to a configuration read/write?
Considering that FRAME# is asserted for one clock cyle only. during
config read/write...

when FRAME# is asserted target is expected to latch the Address/Command
respectively.
because after that FRAME# will be de-asserted and DATA/Byte_Enable
follows.

Now with regards to the Target State Machine:
consider the transition of IDLE state to B_BUSY state ( as Describe in
Appendix B PCI Spec 3.0 ) it will only to B_BUSY state when FRAME# is
asserted and there's a Hit on address decode.
Consider this Hit signal:
Hit <= ( PCI_AD_REG = BAR0 ) AND MEM_EN else '0';

How can BAR0 be written to ( i.e. filled with 1's ) when the STATE
cannot escape from IDLE state since ( Hit is ZERO )?

Are my statements incorrect?
 

--
young_leaf

Sorry my previous message was incorrect,
"How can BAR0 be written to ( i.e. filled with 1's ) when the STATE
cannot escape from IDLE state since ( Hit is ZERO )? "

this should be:
How can BAR0 be written to when after IDLE state is BUSY state that is
when FRAME# is de-asserted it goes back to IDLE state? and FRAME# is
de-asserted; is this a STATE lock?
since its in IDLE state and FRAME# is de-asserted?

--
young_leaf

adventleaf@gmail.com wrote:

> Sorry my previous message was incorrect,
> "How can BAR0 be written to ( i.e. filled with 1's ) when the STATE
> cannot escape from IDLE state since ( Hit is ZERO )? "
> 
> this should be:
> How can BAR0 be written to when after IDLE state is BUSY state that is
> when FRAME# is de-asserted it goes back to IDLE state? and FRAME# is
> de-asserted; is this a STATE lock?
> since its in IDLE state and FRAME# is de-asserted?
> 
> --
> young_leaf

If you're suggesting that the state after the single-cycle FRAME# signal 
is an idle state, you are probably mistaken.

My recollection is that the FRAME# can - for a single word write - 
assert for only one cycle with the IRDY# and TRDY# following after that. 
   The state after the FRAME# before the other controls is not an idle 
state.

It's through the IDSEL that the device is identified.  The configuration 
writes will only be made to targets that are identified.  If the target 
is "dead" on the bus, and the PCI configuration cycle is not in the idle 
state because it started and wasn't finished, the cycle will abort ant 
_then_ return to the idle state.

John_H, its not that i'm saying the "after the single-cycle FRAME#
signal
is an idle state", what i mean is how can we follow state machine
design (as described in Appendix B of PCI Spec 3.0) to accomodate a
Configuration Read/Write....


---
young_leaf

"leaf" <adventleaf@gmail.com> wrote in message 
news:1142818282.728042.84490@i40g2000cwc.googlegroups.com...
> John_H, its not that i'm saying the "after the single-cycle FRAME#
> signal
> is an idle state", what i mean is how can we follow state machine
> design (as described in Appendix B of PCI Spec 3.0) to accomodate a
> Configuration Read/Write....
>
>
> ---
> young_leaf

Just as a little guidance, the Xilinx core I use has separate signals for 
configuration control - CFG_HIT, C_READY, and C_TERM - rather than the 
target control - BASE_HIT[7:0], S_READY, S_TERM, S_ABORT.

Perhaps your attempts to use the "hit" in your state machine is confused 
between configuration and target cycles? 

Does it mean that Configuration cycles are not part of the state
machine (IDLE, B_BUSY ect.. )?
i guess i was not able to recognized it.

Anyway, if that's the case that solves it partially if not i don't
know...

my Hit is ORed bar_hits (i have BAR0 and BAR1) ( assynchronous of pci
clock )

-- Hit Detection --------------------------
match <= ( (Pci_Ad_Reg(31 downto 2) = BAR_0)
                  OR
                (Pci_Ad_Reg(31 downto 4) = BAR_1) );

bar_hit_reg(0) <= '1' when ( match and ( cmdReg(1) = '1' ) ) else '0';
bar_hit_reg(1) <= '1' when ( match and ( cmdReg(0) = '1' ) ) else '0';
Hit <= ( bar_hit_reg(0) OR bar_hit_reg(1) ) ;
--------------------------------------------------


Pci_Ad_Reg is a registered Pci_Ad at rising edge of Pci_Clk...
is this advisable, also to register IRDY# and/or FRAME#?


---
Leaf

"leaf" <adventleaf@gmail.com> wrote in message 
news:1142877107.853006.74990@t31g2000cwb.googlegroups.com...
> Does it mean that Configuration cycles are not part of the state
> machine (IDLE, B_BUSY ect.. )?
> i guess i was not able to recognized it.
>
> Anyway, if that's the case that solves it partially if not i don't
> know...
>
> my Hit is ORed bar_hits (i have BAR0 and BAR1) ( assynchronous of pci
> clock )
>
> -- Hit Detection --------------------------
> match <= ( (Pci_Ad_Reg(31 downto 2) = BAR_0)
>                  OR
>                (Pci_Ad_Reg(31 downto 4) = BAR_1) );
>
> bar_hit_reg(0) <= '1' when ( match and ( cmdReg(1) = '1' ) ) else '0';
> bar_hit_reg(1) <= '1' when ( match and ( cmdReg(0) = '1' ) ) else '0';
> Hit <= ( bar_hit_reg(0) OR bar_hit_reg(1) ) ;
> --------------------------------------------------
>
>
> Pci_Ad_Reg is a registered Pci_Ad at rising edge of Pci_Clk...
> is this advisable, also to register IRDY# and/or FRAME#?
>
>
> ---
> Leaf

Whether to use registered or unregistered values is dependent on when the 
values are valid versus when you use them.  I was able to do what I needed 
done by looking at timing diagrams and signal descriptions.

I have a local version of the PCI spec, v2.3.  The state machine diagrams 
cover target and master.  *If* the configuration cycle were part of the 
target state machine, then the "hit" would include a configuration hit, not 
a BAR hit since your BAR is typically configured through configuration 
cycles.  *If* the target state machine covers configuration, you need to 
work in the config cycle qualifications (IDSEL asserted for the slot or 
device during the first cycle of FRAME#).

Happy travels. 

On 2006-03-19, adventleaf@gmail.com <adventleaf@gmail.com> wrote:
>
> when FRAME# is asserted target is expected to latch the Address/Command
> respectively.
> because after that FRAME# will be de-asserted and DATA/Byte_Enable
> follows.

For a config cycle you have to look at IDSEL instead.  The config
read/write commands are different from mem read/write.  IDSEL will
often be the same as one of the address lines, so you must ignore it
when the command is not a config cycle.

For an example try:

	http://www.ben.com/minipci/

Specifically you can see on:

	http://www.ben.com/minipci/verilog.php

the difference between cfg_hit and addr_hit.

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/

Ben,
Yes you're minipci design worked on my pc, i did somehow used it as a
reference, and somehow i have managed to port it into my new design,
unfortunately the former did'nt worked on all PC on our lab.

Back to the Topic, i have finished the the new design. And i think it
did comply on PCI 2.1 spec or even on 3.0 since i slightly used it as
reference for the New State Machine design. Anyhow, it still doesnt
work. I use Quartus-II 5.1 software for synthesis and simulation, other
people say it should use HDL-Simulation tools, or even Signal
analyzers...

Also i'm done with cfg_hit and addr_hit, i put it on another module,
Address Decoder module.

This is the simulation waveform if you want to see:
http://i1.tinypic.com/s5lj54.gif

note with regards to screenshot:
Will the bus master work with this kind of target (i.e. having Medium
Devsel timing)?
and with other timing of signals in that screenshot.
---
Young Leaf

On 2006-03-25, leaf <adventleaf@gmail.com> wrote:
> Yes you're minipci design worked on my pc, i did somehow used it as a
> reference, and somehow i have managed to port it into my new design,
> unfortunately the former did'nt worked on all PC on our lab.

I'm not sure which design you had problems with -- mine or your modified
version.  One thing to be aware of is that modern PCI bridge chipsets
have configurable clocks and the BIOS will disable a slot entirely if
it's not happy with the initial configuration requests to the card.  If
your code works at the first boot, you can often re-flash the card while
booted (provided the CPLD or FPGA tristates during the programming and
assuming your code comes up in a sane state without seeing a PCI RST).
However, if your card was not detected at boot, you probably can't reload
it and see it work unless you also restart the PC.

Also, my core did not generate PAR at all because the fan-in for the
necessary XOR wasn't possible in the small CPLD I was using.

> note with regards to screenshot:
> Will the bus master work with this kind of target (i.e. having Medium
> Devsel timing)?

The devsel timing has to meet the spec you put in your config space.
If you say "fast" and don't respond on the clock after the address
cycle, then the initiator could assume that no one will ever reply.
I'm not sure if (or even how) that would apply to config cycles.

Also, in your simulation you have a config space read at address '1'
which should really be a read at 0 with byte enables.  And you return
all '1's which would not be valid and could cause the problem I described
above with your BIOS.

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/