OPENCORES.ORG

Hello!

Hello again!
           I looked into the matter more and have news.
    First of all, i located this post:
http://www.opencores.org/forums.cgi/cores/2001/11/00057
  In this lists' archives which was a hint into looking more in depth 
the synchronizers, as i have started. The first thing was to study all 
modules which accept signals from both clock domains (wbw_wbr_fifos.v , 
delayed_sync.v , delayed_write_reg.v and conf_space.v) to see if there 
were any signals that went from one clock domain to another, but not 
through a synchronizer. Fortunately, all such signals either went through 
the synchronizer_flop module, or were driven by the RAM instances (which 
accepted both clocks). The only exception to that is delayed_write_reg.v 
which does not use the synchronizer_flop module but uses a flip flop the 
same way as the _flop module. I didn't see any reason why it won't use the 
_flop module, so i hope i'm not missing anything.
  Next, i tried adding another flop after the single flop that the 
synchronizer_flop module uses. This caused the bridge to go in X state 
much less frequently. Specifically, while before it would go to X in 100 
Mhz Wishbone and 66 Mhz PCI at the first request that would go to the PCI 
bus, now it would only go with normal effort at place and route and only 
when requesting a burst write. Fortunately, adding another flop (therefore 
one cycle delay) doesn't seem to be a problem for the bridge, according to 
functional simulation and my understanding of the design.
  Lastly, although in the synchronizer_flop module there is a comment 
stating that this flop should not go into metastability from hold/setup 
time violations (but only if the input is Z or X), it does. I isolated the 
original synchronizer_flop module and made a short testbench that would 
use an 100 Mhz and 66 Mhz clocks and would supply as input a signal that 
acted like a clock with a 5 ns period. After generating a post PNR 
simulation model, the flop would go into X state (metastability) and stay 
there with the give testbench.
  The next step is to try replacing the synchronizer_flop module with 
another one. If that works well i'll let you know.

Thank you,
    George Michelogiannakis

On Fri, 1 Apr 2005, Mihelogiannakis giorgos wrote:

> 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:
>
>> 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
>>
>> _______________________________________________
>> http://www.opencores.org/mailman/listinfo/pci
>>
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/pci
>