Re: [pci] FIFO

[oliver.amft@ch.abb.com]

Hi Miha, all

I would prefer the address counters solution:
As far as I can see it this minimizes FIFO size and leads to an easier PCI
interface implementation (just one more counter for writes) in terms of bursts
and this should probably be one of the main goals. I'm not sure about Wishbone,
but it should not be difficult there either.

Cheers,
Oliver





To:   <pci@opencores.org>
cc:
Subject:  [pci] FIFO

Hi all!

Anyone interested in developing PCI bridge core, please join this
conversation!
I started working on FIFOs since everything else in a bride is built around
them. Now I'm in one dilemma regarding the structure of it:
In specs, we wrote that FIFO will store address, data, bus command, byte
enables and a few control signals in parallel. That makes it really
WIIIIIDE! Now what the dilemma is:
- we could do separate address and data entries ( good for PCI bad for
WISHBONE) and reduce width for 32 bits. Then, we would have to implement
additional counters for addresses within a burst - WISHBONE requires that
every data beat has its own address. PCI side would also have to implement
counters: WISHBONE performs burst write and we store it as one address and
several data entries. PCI master interface takes address out, performs
address phase and starts taking out data and performs several data phases.
During some data phase (presumably not the last), Target signals Disconnect,
which is not an error condition and PCI bridge is supposed to Retry
operation from disconnected address on. It must retry because this are
posted writes already acknowledged on WISHBONE bus. But here is a problem -
since address is the first data of transaction it is already gone - so PCI
side would also need address counter.

Reads are not such a problem, since they are delayed and only first address
is stored in separate register. If Target disconnects in the middle of a
burst read from pre-fetchable space, we just store that information in read
FIFO. When WISHBONE master retries the operation, data is provided until the
entry that was Disconnected. If it wants to read more, new delayed read
request is latched and performed as separate transaction.

What do you think? Suggestions, advices, anything that you can think of ;-)
!

Regards, Miha Dolenc