|
Message
From: Mihelogiannakis giorgos<mihelog@c...>
Date: Wed Mar 30 22:01:31 CEST 2005
Subject: [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
>
|
 |
Browse
