a question in the pci interface design

R

rat

Guest
Hi,friends
I am designing a pci target interface with cpld. And I want to meet the
66Mhz pci timing requirement with lattice's ispMACH 4256V-5 (Tpd=5ns). It
seems that it is hard to meet the Tsu (<= 3ns) requirement with all of the
input pins. One way is to register every signal at the input side, just like
pipeline. But is it possible to register the IRDY signal? from my
understanding, I have to check the IRDY every clock phase in a transaction
to see if the data is valid to send or receive, and the target has to
respond immediately ( from example, in a single data phase read transaction,
once irdy is asserted and data is valid at some posedge of clock, we should
deassert the trdy signal immediately)
Any suggestion is welcome:) Thanks!

Regards

BTW: is the performance of the Altera QuartusII web edition worse than ISE
webpack or Lattice's tool? I synthesize the same design in Quartus and
Lattice's ispLevel starter ( with synplicity lattice edition), in Quartus,
the device choosed is max3128a-5, in ispLevel, device is ispMACH4128v-5. But
the timing analysis result is so different, ispMACH is better. What is the
problem?
 
Hi,

There are some enhancements in the architecture that make the ispMACH
better than the Max7k (or Max3k).
1. Have you tried the ispExplorer in the ispLEVER software? This tool
gives you the opportunity to optimize your design and make a
comparison between different settings.
2. Study the architecture and make use of it.
3. work with your local FAE to find a solution, he will be able to
judge the settings and the design.

Best regards

On Wed, 30 Jun 2004 10:00:50 +0800, "rat" <rattt@col.edu.cn> wrote:

Hi,friends
I am designing a pci target interface with cpld. And I want to meet the
66Mhz pci timing requirement with lattice's ispMACH 4256V-5 (Tpd=5ns). It
seems that it is hard to meet the Tsu (<= 3ns) requirement with all of the
input pins. One way is to register every signal at the input side, just like
pipeline. But is it possible to register the IRDY signal? from my
understanding, I have to check the IRDY every clock phase in a transaction
to see if the data is valid to send or receive, and the target has to
respond immediately ( from example, in a single data phase read transaction,
once irdy is asserted and data is valid at some posedge of clock, we should
deassert the trdy signal immediately)
Any suggestion is welcome:) Thanks!

Regards

BTW: is the performance of the Altera QuartusII web edition worse than ISE
webpack or Lattice's tool? I synthesize the same design in Quartus and
Lattice's ispLevel starter ( with synplicity lattice edition), in Quartus,
the device choosed is max3128a-5, in ispLevel, device is ispMACH4128v-5. But
the timing analysis result is so different, ispMACH is better. What is the
problem?
Click to expand...
 
"rat" <rattt@col.edu.cn> wrote in message news:<cbt6sg$2p58$1@mail.cn99.com>...
Hi,friends
I am designing a pci target interface with cpld. And I want to meet the
66Mhz pci timing requirement with lattice's ispMACH 4256V-5 (Tpd=5ns). It
seems that it is hard to meet the Tsu (<= 3ns) requirement with all of the
input pins. One way is to register every signal at the input side, just like
pipeline. But is it possible to register the IRDY signal? from my
understanding, I have to check the IRDY every clock phase in a transaction
to see if the data is valid to send or receive, and the target has to
respond immediately ( from example, in a single data phase read transaction,
once irdy is asserted and data is valid at some posedge of clock, we should
deassert the trdy signal immediately)
Any suggestion is welcome:) Thanks!

Regards

BTW: is the performance of the Altera QuartusII web edition worse than ISE
webpack or Lattice's tool? I synthesize the same design in Quartus and
Lattice's ispLevel starter ( with synplicity lattice edition), in Quartus,
the device choosed is max3128a-5, in ispLevel, device is ispMACH4128v-5. But
the timing analysis result is so different, ispMACH is better. What is the
problem?
Click to expand...
Hi,

I do not believe it is possible to register all the PCI inputs, nor
the IRDY signal, for PCI. I've never seen anyone do this. Every PCI
core I've ever seen has logic between many pins and the first bank of
registers, and IRDY and TRDY are two of the critical signals given
their high fanout. This does result in very tight Tsu timing, but
that's fundamental to the standard.

The MAX 7000A family is not 66 MHz PCI compliant. To get to 66 MHz,
you have to use the faster MAX 7000B family.

Vaughn
Altera
 
rat wrote:
Hi,friends
I am designing a pci target interface with cpld. And I want to meet the
66Mhz pci timing requirement with lattice's ispMACH 4256V-5 (Tpd=5ns). It
seems that it is hard to meet the Tsu (<= 3ns) requirement with all of the
input pins. One way is to register every signal at the input side, just like
pipeline. But is it possible to register the IRDY signal? from my
understanding, I have to check the IRDY every clock phase in a transaction
to see if the data is valid to send or receive, and the target has to
respond immediately ( from example, in a single data phase read transaction,
once irdy is asserted and data is valid at some posedge of clock, we should
deassert the trdy signal immediately)
Any suggestion is welcome:) Thanks!

Regards

BTW: is the performance of the Altera QuartusII web edition worse than ISE
webpack or Lattice's tool? I synthesize the same design in Quartus and
Lattice's ispLevel starter ( with synplicity lattice edition), in Quartus,
the device choosed is max3128a-5, in ispLevel, device is ispMACH4128v-5. But
the timing analysis result is so different, ispMACH is better. What is the
problem?


Hi
Click to expand...

Our PCI target core registers every signal, IRDY and TRDY too.
It works greatly, and it was used in about 11 commercial products.

Regards,
Laurent Gauch
www.amontec.com
 
Our PCI target core registers every signal, IRDY and TRDY too.
It works greatly, and it was used in about 11 commercial products.

Regards,
Laurent Gauch
www.amontec.com
Click to expand...
register FRAME, too?
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top