Hello everyone, Sorry to grab your attention for yet another time. The reason this time is difficulties in making the PCI bus run at 66 Mhz. According to the timing report while generating a post PNR simulation model for the PCI bridge, the minimum clock for the PCI bus is 14.2 ns, which means that 66 Mhz is possible. Therefore, i set the PCI66 constant which changes a setting in the configuration space (to indicate that it's capable of 66 Mhz) and makes the testbench produce a PCI llock with 15 ns period. Functional simulation works fine, and there is no difference in how the bridge operates. However, post PNR simulation model is not so cooperative. Although configuration space accesses have no problem (since they don't use the PCI bus), when it comes to producing configuration space cycles on the PCI bus, the PCI bus monitor sees that: *** monitor - PCI Real OE signals have X's {F, I, D_T_S, AD, CBE, PERR} 'bxx0xx0 which -of course- is what one can see at the waveform. This happens when a read is requested from address 000001e5 (CNF_DATA register if i am not mistaken) which would produce a configuration read cycle on the PCI bus. After that, everything seems damaged in a way, even outputs to the other side of the bridge are in X state when they were supposed to be at 1. Continuing with requests (othe requests) does not help. Post-map simulation model has the same problem, while post-translate doesn't. If you are using Xilinx ISE as i am, all project properties are at their default values, while the board is xc2vp70 (family Virtex2P) , speed grade -6 and device package ff1517. Thank you very much in advance for nay help you can provide, George Michelogiannakis _______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hi! I don't remember if I asked this before: Does PNR meet I/O timing constraints also? What clock do you use on the WISHBONE bus? PCI/WB clock ratio can be a problem in timing simulations, since flip-flops between clock domains can have setup/hold time violations. If possible, use same clock for WISHBONE and PCI. The other solution is to disable setup/hold checks on the synchronization flip-flops. Best Regards, Miha Dolenc ----- Original Message ----- From: "Mihelogiannakis giorgos" mihelog@csd.uoc.gr> To: pci@opencores.org> Sent: Tuesday, March 29, 2005 7:05 PM Subject: [pci] PCI Bus at 66 Mhz _______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hello!
The problem was with a 100 Mhz Wishbone clock, and 66 Mhz on the PCI
bus. I tried changing the clocks (for example 33 Mhz on the WB and 66 on
the PCI bus) and everything looked good until a burst write was requested,
when everything went X again. I also tried 66 Mhz on both Wishbone and PCI
and all went fine until a burst write wqs requested again. The "all X"
problem occured earlier, when tried to generate configuration cycles on
the PCI bus, in the 100 Mhz WB and 66 Mhz PCI case.
PNR seems to meet I/O constraints with no problem. Unfortunately using
the same clock for wishbone and pci wasn't the solution. Do you think the
problem is only in the pci_synchronizer_flop.v module, and thus if a
custom one was made, nothing else would be needed to make the bridge fully
functional? Lastly, what do you mean disable setup/hold checks on the
synchronization flops? I did not set any explicit checks for those FFs.

Thank you !
George Michelogiannakis

On Wed, 30 Mar 2005, Miha Dolenc wrote:


flip-flops

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

Hi! I have another idea ;) The PNR tool most probably treats paths crossing the clock domains false. That means you can still have some setup/hold violations that have to be taken care of when doing timing simulations. Did you try to compile the design with the same clock constraints on the PCI and WISHBONE and than simulate with the same clock? Regards, Miha Dolenc ----- Original Message ----- From: "Mihelogiannakis giorgos" mihelog@csd.uoc.gr> To: "Discussion list about free, open source PCI IP core" pci@opencores.org> Sent: Wednesday, March 30, 2005 10:01 PM Subject: Re: [pci] PCI Bus at 66 Mhz _______________________________________________ http://www.opencores.org/mailman/listinfo/pci

Hello!
I did some tests with various clock combinations today. I was in
quite a rush, when i do more i'll let you know.
The situation started becoming "interesting" after adding a DCM from
Xilinx's core generator to the wishbone clock. This had to be done to fix
the big delay some outputs to the wishbone side had. My goal is to make
the wishbone side (which is now really IPIF) run at 100 Mhz which
according to Xilinx ISE is doable, but the outputs to the IPIF (wishbone)
side had, in some cases, a delay of >10 ns.
After adding the DCM, the outputs behaved fine, but the problem as i've
already described (PCI bus signals go and stay in X state in certain times
of the testbench - possibly different for different clock combinations)
became worse. Namely, 100Mhz/33 (100 IPIF, 33 PCI) had the X problem. I
tried adding a DCM to the PCI clock as well.
The bridge runs fine under 33/33 Mhz. However, it does not in 66/66
Mhz, even if both clock inputs are driven by a single clock (output of the
DCM module). 100/66 with the PCI clock also under DCM also does not work.
At all these tests the clock constraints were modified accordingly, and
they were met at all times.
I'll do more tests for clock combinations as well as DCM or not DCM for
the PCI bus, but the IPIF (wishbone) side apparently has to use DCM to
avoid the long output delays.
I looked through the synchronization module, and noticed that only one
flip flop is used for each direction. As far as i know, this can cause
problems especially if one clock is not a multiple of the other. I will
try adding a second, or maybe a third, flip flop in each direction, but
i'm wondering (and haven't yet investigated i admit) if there are any
signals that go from one clock domain to another and don't use the
synchronization module. This will cause a problem since all the signals
that do go though that module will be delayed for one more cycle, whereas
the ones that don't will not.

Do you think the problem lies in the synchronization module? I still
haven't determined why exactly the PCI bus goes in X state though.

Thank you very much,
George Michelogiannakis


On Fri, 1 Apr 2005, Miha Dolenc wrote:

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