OPENCORES.ORG

Hello!

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@c...>
To: "Discussion list about free, open source PCI IP core"
<pci@o...>
Sent: Wednesday, March 30, 2005 10:01 PM
Subject: Re: [pci] PCI Bus at 66 Mhz

> 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:
>
> > 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@c...>
> > To: <pci@o...>
> > Sent: Tuesday, March 29, 2005 7:05 PM
> > Subject: [pci] PCI Bus at 66 Mhz
> >
> >
> >> 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
> >
> > _______________________________________________
> > http://www.opencores.org/mailman/listinfo/pci
> >
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/pci