[pci] Fw: PCI interface

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

Hello!

    Me and Tadej have been working on some issues with bbeaver and I'm
sending this to mailing list for anyone that might be interested.

Regards,
    Miha Dolenc

----- Original Message -----
From: <bbeaver@opencores.org>
To: "Miha Dolenc" <mihad@opencores.org>
Cc: "Lawrence Butcher" <bbeaver@opencores.org>; <tadej@opencores.org>
Sent: Thursday, May 10, 2001 12:53 PM
Subject: Re: PCI interface


> First, Tadej, Hi.
> Yes, Miha, you can forward my mail to the mailing list if you think it has
> value.
>
> Tadej, I see a note that you are asking about FIFOs.
> There are many ways to implement FIFOs.
>
> Key issues are the size of the FIFO and whether it will be used to talk
from
> one clock domain to another, or whether it has both side running on the
> same clock.  A secondary issue is whether you can say before-hand whether
> one side will have a faster clock than the other.
>
> The PCI_Blue_Interface, which I have roughly sketched out, and presently
> available
> in super-alpha-because-only-part-done mode on the opencores webpage, has
> an example of a FIFO.
>
> Fifos meant to have both the in side and the out side running on the same
> clock
> can be simple.  You can write data and an indication that the data is
valid
> at
> the same time.
>
> Fifos meant to go from one clock domain to another are more difficult.
>
> I wrote the FIFO Control logic to operate in one of 2 modes:
> 1) Write Side Clock runs faster than Read Side Clock.
>     In this case, I write data into the FIFO on one clock, and on the
>    next clock I write the indication that the data is valid.  On the Read
>   side, the data is available the same clock that the full indication
> occurs.
> 2) Write Side Clock runs slower than Read Side Clock.
>    In this case, I write the Data and Full indication the same clock.  The
>   Read side must look for a data available indication, and read the data
>   the NEXT clock.
>
> Of course, the FIFO will work fine if the clock relationship is different
> than above.  It just won't be as fast as it could be.
>
> I also used the standard technique of sending a grey-code indication
> of the Read and Write addresses across the clock boundry.  Grey-code
> counters have the davantage that you are wrong in at most 1 bit if you
> look at a value in one clock domain which was written in the other.
>
> NOTE NOT ALWAYS TRUE.  This feature depends greatly on the
> delays being balanced for the different counter bits.
>
> I also wrote the FIFOs so that their size could be one of 3 values (or 4?)
> I can support 3, 5, 7, and 15 entry FIFOs, I think.
>
> I also wrote the FIFO so that it could be implemented with flops and
MUXes,
> which will be the likely way to do it in a chip, or with Xilinx 2-port RAM
> cells.
> (I used the ones which are 16 bits per CLB.)
>
> Please, if you are interested, look at the FIFO in the pci_blue_interface.
> Sorry if you don't like the bit-at-a-time style.  I thought this would
help
> if Xilinx SRAMs needed to be manually instantiated.
>
> Miha:
>
> The Request Spare entries are there because I figured out how to use
> 7 and 15 types in the 2 FIFOs, not 8 and 16.  By leaving a spare, I figure
> I can fix things later.
>
> Every PCI Master needs to be a PCI Slave, too.  So it isn't obvious that
> they should be written seperately.  On the other hand, a PCI Target
> can surely not have a master.  Therefore, it seems fine to write a Target
> without regard for Mastership issues.
>
> I really wish I had made more progress on this, because it is very clear
> in my mind how to progress.  But I can't work on it for at least several
> weeks.
>
> The wishbone interface should assume that it is doing Memory Reads and
> Memory Writes if a normal reference is made.  I would think that extra
> register references, or extra address lines,  would be needed to issue a
> different type of PCI reference.
>
> Bursts would be especially hard, because there is no way for a PCI Master
> to change it's mind about the length of a burst once a data item is
offered.
> If the master said "here comes one word, with more to follow" and the
> wishbone
> interface decided to NOT offer more data, the PCI protocol is violated.
Not
> good.
>
> One way to fix this is to collect write data into ANOTHER FIFO before it
> is offered to the PCI interface,  That way you can look at several entries
> in
> the FIFO at once, and discover if a Burst is possible.
>
> The pci_blue_interface has a host side and a PCI side.  The two sides
> communicate TOTALLY through FIFO's.  No out-of-band signals.  (OK, Reset
> goes through a different route.  Should that use the spare commands?)
> Neither side is aware of the depth of the FIFO's.  The user can substitute
> FIFOs, as long as the control logic acts as expected, to get an area or
> bus speed advantage.
>
>
> All for now:
>
> Blue Beaver
>
>
> -----Original Message-----
> From: Miha Dolenc <mihad@opencores.org>
> To: bbeaver@opencores.org <bbeaver@opencores.org>
> Date: Thursday, May 10, 2001 2:17 AM
> Subject: PCI interface
>
>
> >Hello,
> >
> >    it's me again. I've looked at pci_blue_constants.v and I'm impresed
how
> >well a specs written in verilog with extensive use of commentary can turn
> >out.
> >
> >OK, here is my comment:
> >I like your interface very much and I have a few questions for you:
> >1. I didn't quite understand PCI_HOST_REQUEST_SPARE request and what it
> will
> >be used for
> >
> >2. Do you think you could concentrate your efforts in PCI master
interface
> >first - we already have a member that is interested in developing PCI
> >target, so they can be developed concurently. I would forward him your
> >pci_blue_constants and he would comment to.
> >
> >3. Is this pci_blue_constants file pretty much finished or it will be
> >changed a lot in the future. If it's almost done, someone can start doing
a
> >WISHBONE interface that would connect to your PCI interface.
> >
> >4. What PCI bus commands do you intend to support and how a host can
> request
> >a use of specific bus command.
> >
> >4. How much problems would it cause you if you do an interface, that
would
> >only contain PCI master state machine, without configuration and status
> >registers and FIFO's ? Or the other way arround - how much problems will
we
> >have, if we want to use your PCI master without conf. regs and FIFOs.
> >Request types you defined would stay the same - some would be unused.
> >Let me tell you, what I have in mind:
> >Control logic for PCI modules of our bridge would be separated from state
> >machines. Control logic would take care of transaction ordering (which
> would
> >be the same as yours in the first version of the bridge).
> >I mean, this control logic would not issue a read request to your PCI
> master
> >until all writes are completed on PCI bus. It would also control the
FIFOs.
> >Why I think this is better? If we want to do an extension of
functionallity
> >of PCI bridge (I'm sure we will, because when the first version is done,
I
> >think more people will get interested in helping out), we can just change
> >control logic, add more FIFO depth etc. and leave PCI interface as it is.
> >That's good because PCI interface is not an easy one to do! And you could
> >concentrate more on PCI bus protocol!
> >
> >Please, tell me what you think about all this - I could be very wrong
since
> >I don't have that much experience.
> >Can I CC our comunications on pci mailing list, so others can see what's
> >going on?
> >
> >And, HAVE FUN ON YOUR VACATION!
> >
> >Regards,
> >    Miha Dolenc
> >
> >
> >
>
>