Re: [pci] a simple PCI target module

[ezhcai@ntu.edu.sg]

Hi Markovic,

Thanks your kind advice. I agree that partition the design into small 
units may be benefit the timing, but I prefer the design style which 
makes the design easy, neat and more readiable. 
Since I'm busy doing something else, I'll go back to the PCI timing some 
time later. May I have ur email address so that I can contact you when 
I'm back to this design? My email: ezhcai@ntu.edu.sg

Thanks again,

Cai zhaohui

----- Original Message ----- 
From: Tadej Markovic <tadej@o... > 
To: pci@o...  
Date: Mon, 16 Jul 2001 23:08:50 +0200 
Subject: Re: [pci] a simple PCI target module 

> 
> 
> Hi again! 
> 
> On Wed, 27 Mar 2002, you wrote: 
> > I suppose the data from back end applications are from 
> synchronous RAM 
> > (such as RAM blocks in Virtex/Spartan-II), which is 
> synchronized before 
> > enter the PCI target. 
> > pls let me know if my thinking is wrong. 
> > 
> > Have a nice day, 
> > 
> > Cai zhaohui 
> > 
> 
> I will try to explain why this is not so simple. 
> First you must consider PCI timings constraints on IO signals. PCI 
> clock is just 
> one of the constraints. 
> If we have PCI clock 33MHz, we have 30 ns period. An output signal 
> from PCI 
> device 1 must be set in 9 ns after rising clock edge. We have 
> propagation 
> delay and 1 ns for clock jiter. Now we have just 7 ns (just some 
> have more) 
> before next rising clock edge to do, what ever we must do with this 
> signal. 
> So this are prety hard constraints on IO signals for FPGA. 
> 
> If you want to meet timings for output signals you have to register 
> output 
> signals and output enable signals before they are assigned to 
> output tristate 
> buffer (this buffer additionali delayes the signal). 
> 
> Input signals have from 1 to 3 ns delay on input pad, depends on 
> its fanout. If 
> you substratc this from 7 ns, then there is not much left. This 
> signals should 
> not be connected to BlockRAMs, othervice you will have 15 or more 
> ns delay. And 
> because this will not help for all input signals, you will also 
> have to preserve 
> hierarchy, so that synthesys tool will not optimize this equations 
> with other 
> similar equations. This optimization results in smaler area, but 
> also biger 
> delay. 
> 
> We put a lot of effort to meet all timings for our PCI bridge in 
> Spartan-II 
> with 150k gates and -5 speed grade (the slowest). And our PCI 
> bridge is not 
> just an interface, it includes a backend and we put it together 
> with a CRT (VGA) 
> core for a demo application. 
> 
> 
> Best regards, 
> 	Tadej 
> 
> 
> > ----- Original Message ----- 
> > From: sumnow <sumnow@2... > 
> > To: "pci@o... " <pci@o... > 
> > Date: Wed, 27 Mar 2002 17:0:39 +0800 
> > Subject: Re: [pci] a simple PCI target module 
> > 
> > > 
> > > 
> > > i think signals output to PCI bus should be 
> > > registered(synchronized) before they actually output to 
> bus, which 
> > > can prevent glitch on PCI bus. and so do OE signals. 
> > > 
> > > synchronized signals can also benefit synthesis process. 
> > > 
> > > just some opinions and i am also not sure about it. 
> > > 
> > > >Hi there, 
> > > > 
> > > >A simple PCI revision 2.1 target module has been 
> developed and 
> > > can be 
> > > >downloaded from 
> > > www.ntu.edu.sg/home/ezhcai/IPdesign/pcitarget.zip 
> > > > 
> > > >Any commets are very welcome. 
> > > > 
> > > >have a nice day, 
> > > > 
> > > >Cai zhaohui 
> > > > 
> > > 
> > 
> 
--
To unsubscribe from pci mailing list please visit http://www.opencores.org/mailinglists.shtml