PCI Configuration access and Target State Machine...

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

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

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.

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:

Specifically you can see on:

the difference between cfg_hit and addr_hit.

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:

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.

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.

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 i was wrong when i said that the design didnt't work in all PC on our lab, but its rather didn't work for all but it did somehow on my PC but not with others, and that's the main problem i faced which forced me to re-design using the State machine design as described on Appendix B of PCI 3.0 Spec

To add, the former design that i made based on your mini pci worked well on my pc only and other pc in our lab with the same motherboard. It worked because i was able to read/write to the registers of back-end device.

Sorry for not making the screenshot more readable, but that was 10h, i'm writing to BAR0 and reading it back. the resulting data is FFFFFF08 ( Memory and 256 bytes).

ps. when BUS MASTER reads configuration especially the Status register w/c has the devsel timing, how long will it Assert IRDY#, because at this moment still doesn't know the devsel timing for this spefic Device?

Young Leaf