[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[pci] Re: pci-digest V1 #28
remove
----- Original Message -----
From: "pci-digest" <owner-pci-digest@opencores.org>
To: <pci-digest@opencores.org>
Sent: Thursday, May 10, 2001 8:45 PM
Subject: pci-digest V1 #28
>
> pci@opencores.org pci-digest V1 #28
>
>
> ----------------------------------------------------------------------
> From: "Miha Dolenc" <mihad@opencores.org>
> Date: Thu, 10 May 2001 14:05:52 +0200
> Subject: [pci] Fw: PCI bridge status
>
> Hello,
> this is the conversation on pci bridge core between me an bbeaver, if
> anyone is interested.
>
> Regards,
> Miha Dolenc
>
>
> ----- Original Message -----
> From: <bbeaver@opencores.org>
> To: "Miha Dolenc" <mihaPCI@email.si>
> Sent: Wednesday, May 09, 2001 11:35 AM
> Subject: Re: PCI bridge status
>
>
> > I tried to mail to the mailing list, but it bounced.
> >
> > I am working on a PCI Host Bridge too.
> >
> > I would regret if we ended up with three of them. But I have to
> > admit that I am too busy to finish mine i the next month.
> >
> > I would like to suggest that you and I (and Tadej?) might
> > talk about the interface the PCI interface will present to the
> > host. Your manual is quite impressive (almost scary), and
> > I would like to benefit from your skills.
> >
> > I have used the Insilicon PCI controller, and it has terrible problems.
> > After thinking about things for a long time, I think my started verilog
> > PCI interface has a good, solid host interface. It will allow a user
> > to correctly implement the PCI ordering rules with 1 delayed read,
> > and I believe this will be the FIRST one around to make the claim.
> >
> > I will be unavailable all next week. I can only talk a little this week.
> >
> > Please, if you want, take a look at pci_blue_constants.vh.
> >
> > I have 3 FIFOs.
> >
> > The first FIFO is a Request FIFO, which the Host uses to initiate PCI
> > activity.
> > It has a 3-bit Type field.
> >
> > The Second FIFO is a Response FIFO. Data from Host requests flows
> > across this FIFO. It has a 4-bit Type Field.
> >
> > This FIFO ALSO carries PCI requests, initiated by an external PCI master.
> > This double-use of the FIFO forces the core to implement the ordering
> rules.
> >
> > The Third FIFO is used to send Memory data to the external PCI Master.
> >
> > This activity CANNOT share the Request FIFO, because then it would
> > be necessary for FIFO entries to hop over one-another in order to
> > meet the ordering rules.
> >
> > I will finish this. It is mostly in my head now. If you want, you could
> > look
> > at the type entries, and see if they would influence you in any way. I
> > would
> > be DELIGHTED if they ended up in your core, or in your manual.
> >
> > Got to go now. I will read mail maybe once or twice more before the
> > weekend, then I am off for a week. Then, back. If things go well at
> > work, I will FINALLY get to write some verilog at last.
> >
> > Pleased to meet you!
> >
> > Lawrence
> >
> >
> > -----Original Message-----
> > From: Miha Dolenc <mihapci@email.si>
> > To: bbeaver@opencores.org <bbeaver@opencores.org>
> > Date: Tuesday, May 08, 2001 10:25 AM
> > Subject: Fw: PCI bridge status
> >
> >
> > >Hi!
> > >
> > > I'm Miha and Damjan pointed me to you regarding PCI bridge core. I
> saw
> > >that your e-mail is not a part of pci mailing list, so I took a liberty
> to
> > >send you my last post. I thought you might be interested. Let me know if
> > you
> > >are. Or better yet, subscribe to PCI mailing list if you like ( it's not
> > >that busy ) and let others know what you are interested in also.
> > >
> > >Thanks for your time,
> > > Miha Dolenc
> > >
> > >
> > >----- Original Message -----
> > >From: "Miha Dolenc" <mihapci@email.si>
> > >To: <pci@opencores.org>
> > >Cc: <cores@opencores.org>
> > >Sent: Tuesday, May 08, 2001 7:17 PM
> > >Subject: PCI bridge status
> > >
> > >
> > >> Hello all!
> > >>
> > >> I have updated the specification with some waveforms so it became
> > more
> > >> readable. We have also shrunken it to "only" 1.6MB.
> > >>
> > >> It can still be found on OpenCores CVS on address
> > >>
> > http://www.opencores.org/cgi-bin/cvsget.cgi/pci/docs/pci_specification.pdf
> > >>
> > >> Now I think there is quite enough information about PCI bridge core
> > >> functionality for us to start working on RTL design ;-) (in Verilog if
> > >> possible). I will think over how tasks can be divided. If anyone has
> any
> > >> idea about the task that must be done and he/she is interested in doing
> > >it,
> > >> please notify other members of PCI team through this mailing list, so
> we
> > >> don't do same things twice.
> > >>
> > >> I would like to do WISHBONE slave interface if nobody else is
> interested
> > >in
> > >> that.
> > >>
> > >> Have fun,
> > >> Miha Dolenc
> > >>
> > >
> >
>
> ----------------------------------------------------------------------
> From: "Miha Dolenc" <mihad@opencores.org>
> Date: Thu, 10 May 2001 14:06:00 +0200
> Subject: [pci] Fw: PCI interface
>
> 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
> > >
> > >
> > >
> >
> >
>
> ----------------------------------------------------------------------
> End of pci-digest V1 #28
>