Hi, just to be sure, in order to change the image size: I have to change the PCI_AMx fields for the respective image, the PCI_NUM_OF_DEC_ADDR_LINES and the PCI_IMAGEx for the desired number of images, right? Thanks, Adalbert _______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hi! PCI_IMAGEx does not select the number of images - it selects if image x is implemented. If you want to implement all six images, you have to define: PCI_IMAGE2 PCI_IMAGE3 PCI_IMAGE4 PCI_IMAGE5 Image 0 is used for configuration registers, and image 1 is implemented by default. You are right about the size of the images. Regards, Miha Dolenc ----- Original Message ----- From: adalbert.mueller@web.de> To: pci@opencores.org> Sent: Wednesday, January 07, 2004 11:10 AM Subject: [pci] PCI Image size _______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hi ,

yes, sorry, that's what i meant. Uncommenting for enable the image.

I set the PCI_NUM_OF_DEC_ADDR_LINES to12, the PCI_AM0, the PCI_AM1 to
20'hffff_f and the PCI_BA0_MEM_IO/PCI_BA1_MEM_IO to 1'b0.

This should lead to 2 x 4k memory windows, right? But in my case the
result is disappearing of the device. There's one case it appears, but
the windows's don't match to the desired values (1M instead 4K for
image0, image1 is set to 1M).

Are there maybe some known problems with optimisations?

Kind regards,

Adalbert


Miha Dolenc wrote:


is
_______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hi! For 4KB image, you have to set PCI_NUM_OF_DEC_ADDR_LINES 20. This leaves 12 (32 - 20) address lines for the offset - 4KB. In your case, 20 (32 - 12) address lines represent the offset, which gives a minimum image size of 1MB. Regards, Miha Dolenc ----- Original Message ----- From: "adalbert.mueller" adalbert.mueller@web.de> To: "Discussion list about free, open source PCI IP core" pci@opencores.org> Sent: Wednesday, January 07, 2004 1:15 PM Subject: Re: [pci] PCI Image size _______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hello,

unfortunatelly not working for me. In some configurations it works, in
others not. For me it seems still to be a timing problem.
But another question: In pci_pci_decoder.v and pci_wb_decoder.v there is
a parameter 'decode_len'. Isn't it neccessary to set it according to
the 'PCI_NUM_OF_DEC_ADDR_LINES' in pci_user_constants.v?
For me, it's no matter if changed or not, but I think these parameters
are not my problem.

Thank you for your patience,

Adalbert Müller



Miha Dolenc wrote:


gives a
_______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hi! The way you are describing things, it really seems like the timing problem. Did you set all the PCI IO constraints as specified in the PCI Specification? Did you select proper IO standard for the PCI IO signals? Regards, Miha Dolenc ----- Original Message ----- From: "adalbert.mueller" adalbert.mueller@web.de> To: "Discussion list about free, open source PCI IP core" pci@opencores.org> Sent: Thursday, January 08, 2004 11:55 AM Subject: Re: [pci] PCI Image size _______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hi! The way you are describing things, it really seems like the timing problem. Did you set all the PCI IO constraints as specified in the PCI Specification? Did you select proper IO standard for the PCI IO signals? Regards, Miha Dolenc ----- Original Message ----- From: "adalbert.mueller" adalbert.mueller@web.de> To: "Discussion list about free, open source PCI IP core" pci@opencores.org> Sent: Thursday, January 08, 2004 11:55 AM Subject: Re: [pci] PCI Image size _______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hi Adalbert and Miha, Adalbert, as you said, you are using ACEX1k100 device for the PCI Bridge implementation. It seems to me what you are having problems because of the either of the following three reasons: 1) Voltage level on the ACEX pins: did you activate the clamping diodes on the pins? What voltage level is your PCI bus (5V or 3.3V)? If it is 5V, you better use some buffers to protect the FPGA (for example, the chip IDTQS3861 with 4.3 V supply (5V through a diode with 0.7 V voltage drop) or 33 Ohm resistors on each PCI pin from PCI connector to the FPGA plus the internal clamping diodes on each FPGA pin) Here is some description from the ACEX 1k datasheet: PCI Pull-Up Clamping Diode Option ACEX 1K devices have a pull-up clamping diode on every I/O, dedicated input, and dedicated clock pin. PCI clamping diodes clamp the signal to the VCCIO value and are required for 3.3-V PCI compliance. Clamping diodes can also be used to limit overshoot in other systems. Clamping diodes are controlled on a pin-by-pin basis. When VCCIO is 3.3 V, a pin that has the clamping diode option turned on can be driven by a 2.5-V or 3.3-V signal, but not a 5.0-V signal. When VCCIO is 2.5 V, a pin that has the clamping diode option turned on can be driven by a 2.5-V signal, but not a 3.3-V or 5.0-V signal. Additionally, a clamping diode can be activated for a subset of pins, which allows a device to bridge between a 3.3-V PCI bus and a 5.0-V device. 2) Make sure you set all the parameters in pci_user_constants.v correctly (HOST or GUEST, number of images, and so on...). By the way, the parameter decode_len = 12 in pci_pci_decoder.v has nothing to do with the number of decoded address lines what you want to implement. It gets overriden in the file pci_target32_interface.v like this: pci_pci_decoder #(`PCI_NUM_OF_DEC_ADDR_LINES) decoder0 ( .hit (hit0_in), .addr_out (address0_in), .addr_in (address_in), .bc_in (bc_in), .base_addr (pci_base_addr0_in), .mask_addr (pci_addr_mask0_in), .tran_addr (pci_tran_addr0_in), .at_en (addr_tran_en0_in), .mem_io_space (mem_io_addr_space0_in), .mem_en (mem_enable_in), .io_en (io_enable_in) ) ; So, if you set PCI_NUM_OF_DEC_ADDR_LINES to 20 in pci_user_constants.v, this parameter will be changed automaticaly. And the most important: did you set correctly the following: `define ACTIVE_LOW_OE //`define ACTIVE_HIGH_OE It is very important as different FPGA have different voltage level to enable/disable output buffers. For example, XILINX FPGAs have active low oe, Altera Stratix FPGAs have active low, too. Sory, I had no time to check that for Altera ACEX 1k FPGAs. But this is very importanr !!!!!! And one more thing: did you disable the chip-wide output enable pin on the FPGA (using Quartus)? If it is not disabled, it could tri-state all pins on the FPGA. Here is, again, some information from the ACEX 1k datasheet: The chip-wide output enable pin is an active-high pin that can be used to tri-state all pins on the device. This option can be set in the Altera software. The built-in I/O pin pull-up resistors (which are active during configuration) are active when the chip-wide output enable pin is asserted. The registers in the IOE can also be reset by the chip-wide reset pin. 3) The original implementation of the PCI Bridge does not include memory instantiation for Altera FPGAs. What parameters did you set in pci_user_constants.v? `define FPGA //`define XILINX If you set it like this, you will miss some very critical information. In this case, generic two-port RAM model (synthesized from logic elemets) will be selected in the files pci_pci_tpram.v and pci_wb_tpram.v like this `ifdef PCI_PCI_RAM_SELECTED `else // // Generic two-port synchronous RAM model // // // Generic RAM's registers and wires // reg [dw-1:0] mem [(1pci-bounces@opencores.org [mailto:pci-bounces@opencores.org]On Behalf Of adalbert.mueller Sent: Thursday, January 08, 2004 8:32 AM To: Discussion list about free, open source PCI IP core Subject: Re: [pci] PCI Image size Hi, at first I tryed around with global constraints about setup/propagation delay/hold - times to the required values by PCI-spec, without success. Second step was setting special constrainst to pin to register delay. As a result, sometimes the device was found on bus, sometimes not. I changed for example the windowsize for the BAR's and after compiling the device can't be configured because the BAR's are not writeable or the device wasn't found at all. I just asked another colleague which has some experiences with logic programming and he mentioned that probably the device itself is to slow for the core. Altera's optimized core has the given hardware as minimum requirements (I'm using ACEX1k100FC256-2). Both, the FPGA and the system are currently running on 3.3V IO@33MHz. Therefore there should not be a problem. I even have some timing errors during timing analyzing i can't kill with adding some constraints (till now, but I try :-)). I don't know if on xilinx are similar problems, but according to the mailing list, it seems not to be the case. It seems fortuna is not on my side. :-(. Well, thanks a lot, Adalbert Miha Dolenc wrote: _______________________________________________ http://www.opencores.org/mailman/listinfo/pci _______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hi Adalbert and Miha,

Adalbert, as you said, you are using ACEX1k100 device for the PCI Bridge
implementation.
It seems to me what you are having problems because of the either of the
following three reasons:

1) Voltage level on the ACEX pins: did you activate the clamping diodes on
the pins?
What voltage level is your PCI bus (5V or 3.3V)? If it is 5V, you better use
some buffers to
protect the FPGA (for example, the chip IDTQS3861 with 4.3 V supply (5V
through a diode with 0.7 V
voltage drop) or 33 Ohm resistors on each PCI pin from PCI connector to the
FPGA plus the
internal clamping diodes on each FPGA pin)

Hi Adalbert and Miha,

Adalbert, as you said, you are using ACEX1k100 device for the PCI Bridge
implementation.
It seems to me what you are having problems because of the either of the
following three reasons:

1) Voltage level on the ACEX pins: did you activate the clamping diodes on
the pins?
What voltage level is your PCI bus (5V or 3.3V)? If it is 5V, you better

some buffers to
protect the FPGA (for example, the chip IDTQS3861 with 4.3 V supply (5V
through a diode with 0.7 V
voltage drop) or 33 Ohm resistors on each PCI pin from PCI connector to

FPGA plus the
internal clamping diodes on each FPGA pin)

Sebastian,

Of cause, you can connect two FPGAs together without any protection
if their I/O are at the same voltage level. It obvious.

We were talking about connecting an FPGA with 3.3V I/O directly
to 5V PCI bus.