Re: [pci] FIFO

["Miha Dolenc" <mihad@opencores.org>]

Hello Oliver, all

    We were thinking about it some more, and it became clear, that your
proposition is best. Since we are targeting FPGA as well as ASICs, we have
to consider limitations of FPGAs. We plan to use Dual-port RAM blocks (e.g.
Block SelectRAM+ in Virtex or Spartan-II) memory primitives for FIFOs, but
the number and structure of these primitives in FPGA is limited. So if we
take your proposition, we can fit our core into some small FPGA devices and
what's more important: if we ever want to extend functionality to 64 bits,
it's just a matter of increasing width and some additional logic.

Thanx for your reply and hope to hear from you soon,
   Miha & Tadej

----- Original Message -----
From: <oliver.amft@ch.abb.com>
To: <pci@opencores.org>
Cc: <mihad@opencores.org>
Sent: Tuesday, May 22, 2001 6:03 PM
Subject: Re: [pci] FIFO


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