[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pci] FIFO
Hello, Oliver!
As you are not fixed on PCI, I'm not fixed on WISHBONE ;-). So - if you
like, you can do a WISHBONE master interface to start with or stick with PCI
verification. If you decide to work on WISHBONE master, let me know, since
we will have to talk about bursts a bit more - it is not in WISHBONE
specification yet, but we are working on some burst or CAB (consecutive
address burst) signal. Thanks for your advice on FIFO.
Hope to hear from you soon,
Miha Dolenc
----- Original Message -----
From: <oliver.amft@ch.abb.com>
To: <pci@opencores.org>
Cc: <mihad@opencores.org>
Sent: Wednesday, May 30, 2001 4:28 PM
Subject: [pci] FIFO
>
>
>
> Miha, you're right: The Xilinx architecture has some unpleasant width
> constraints for the BLOCK RAMs. For 40 bits you will need 3 of them but I
cant
> see why you want to separate the FIFOs (there are certainly some
performance
> penaltys regarding the smaller buffer size and the switching but thats
it). I
> would suggest a straight forward general fifo interface and allow the
system
> designer to select / integrate himself for a specific target technology (I
dont
> know if someone at Openocores already specified guidllines for technology
> dependent blocks). My recomendation is: 3xBRAMs (2x16x256entrys, 1x8x256
entrys)
> so you'll have some space left (8x256 Byte) and use it multiplexed: 40bits
x
> 64entrys x 4 fifos.
>
> Thanks for your suggestion (master/target verification). I'm not fixed on
PCI
> somehow but You and Tadej will do the Wishbone, right ?
> As PCI side interface will probably be ready some days earlier than
Wishbone it
> would be a good idea to start there: Which toolchain are you using for the
> designs?
>
> What has happend to the PCI board level simulation models maitained by
Ovidiu (I
> cant find the module "PCIsim" via CVS)?
>
> Cheers,
> Oliver
>
>
>
>
> |---------->
> | |
> | |
> |---------->
>
>------------------------------------------------------------------------|
> |"Miha Dolenc" <mihad@opencores.org>@opencores.org
|
> |2001-05-29 17:58
|
>
>------------------------------------------------------------------------|
>
>
>
> Please respond to pci@opencores.org
> Sent by: owner-pci@opencores.org
>
>
> To: <pci@opencores.org>
> cc:
> Subject: [pci] Re: Config Space
>
> Security Level:? Internal
>
>
> Hello!
>
> I have FIFO design almost ready. I'm still having some difficulties on
> how to implement two FIFOs in one Block SelectRAM+ for FPGA. Let me
> describe:
> For 40 bit wide FIFO, i need 3x16 bits ( or 2x16 + 1x8 - which is still
3 )
> of width. ( widest RAM in FPGA is 16). If I do separate blocks for
separate
> FIFOs, there would be 12 block RAMs used - that's too much since smaller
> FPGAs don't provide that many.
> Off course, I could use normal memory for FIFOs, but that takes up LUTs
> which means poor depth, and less space for logic.
> I think I have the solution now - I just have to test it. If my solution
> doesn't work, I'll come back to you for advice. ;-)
>
> I can see, that you are more interested in PCI than WISHBONE side of the
> bridge. Ovidiu said, that he'll do both master and target interfaces (
> that's cool ), but no one is working on verification yet. Would you be
> interested in that ( master and target compliance tests and so on )?
>
> Have fun!
>
> Miha Dolenc
>
> ----- Original Message -----
> From: <oliver.amft@ch.abb.com>
> To: <tadej@opencores.org>; <mihad@opencores.org>
> Sent: Tuesday, May 29, 2001 5:27 PM
> Subject: Re: Config Space
>
>
> >
> >
> >
> > Hi Miha & Tadej
> >
> > Thanks for your response. I'm still trying to get a bit more in depth
with
> the
> > specification - I've seen a lot of blocks already work in progress or
> assigned
> > to someone. Maybe I should stay with the advisory for the moment.
> > BTW how is it going with the fifo block? Do you already have some more
> detailled
> > block specifications for this? Status signaling, chosen the counter
> design...
> > let me know, if I can help!
> >
> > Cheers,
> > Oliver
> >
> >
> >
> >
> >
> > |---------->
> > | |
> > | |
> > |---------->
> >
> >------------------------------------------------------------------------|
> > |Tadej <tadej@opencores.org>@iza.mr2.si
> |
> > |2001-05-29 14:18
> |
> >
> >------------------------------------------------------------------------|
> >
> >
> > Sent by: tadejm@iza.mr2.si
> >
> >
> > To: Oliver Amft <oam@gmx.net>, pci@opencores.org
> > cc:
> > Subject: Re: Config Space
> >
> > Security Level:? Internal
> >
> >
> > Hi Oliver!
> >
> > I talked to Miha and we will have one more DEFINE command for that. If
> > you chose to have a HOST device, you can also chose not to use IMAGE 1
> > for accessing the "configuration registers". that way, you can use all
> > images (1 - 6) from PCI to WB.
> >
> > Thanx for suggestion
> >
> > Regards Tadej
> >
> >
> >
> > "Miha Dolenc" <mihad@opencores.org>@opencores.org
> > 2001-05-29 10:03
> >
> >
> > Hello!
> >
> > About your question:
> > If I understood you well, we are talking about access to extended
> > configuration space when the bridge is configured as Host (WISHBONE is
> host
> > bus in a system). WISHBONE processor will take full responsibility of
> > configuring the bridge and any other device residing on PCI bus.
WISHBONE
> > conf space BA is fixed and cannot be changed, while PCI BA must be set
(by
> > WISHBONE processor) to provide Read Only Access for conf space to PCI
> agents
> > on certain address (default is 0x00000000). As it is, we didn't think of
> > disabling this read only access to conf space.
> > Maybe - we could implement Address mask register for Configuration space
> > too.
> > All bits, except bit 31 (enable bit) would be fixed, and Read Only
access
> > could be disabled by software if it wrote a value of 0 to this bit. By
> that,
> > read only access for opposite side of the bridge would be disabled.
(That
> > would go for Host as well as Guest bridges).
> >
> > What do you think? Are we even talking about the same thing ;-) ?
> >
> > Have fun,
> > Miha Dolenc
> >
> >
> >
> >
>
>
>
>
>
>