LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Sponsors
  • Mirrors
  • Logos
  • Contact us
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Pci > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: "Charles Krinke" <ckrinke@p...>
    Date: Tue, 16 Jul 2002 13:18:00 -0700
    Subject: RE: [pci] IRDY & TRDY
    Top

    Dear Miha:
    	Thank you for replying to my question. I heard you were on vacation and
    hope that it was restful for you. Let me try to get into the meat of the
    questions and see where we go. First of all, let me describe my setup. I
    have a 33Mhz oscillator coming into the VirtexE on GCK1. It then drives the
    internal system controller (to generate PCI RST), the "blue beaver" arbiter,
    PCI_BRIDGE32 and all of the PCI interface signals come out on two Mictor
    connectors to a daughter board with trace lengths of about 3 inches to a PCI
    connector into which I have plugged a PCI extender card (4 inch trace
    lengths, logic analyzer connected here) and then a Cyclone PCI730 containing
    an XScale 80200 microprocessor and 80312 PCI bridge. It is the 80312 that is
    generating PCI configuration transactions.
    	I have copied the pci_crt.ucf file from the app directory and put the
    relevant in before and out after statements into my TOP.ucf where I am
    instantiating the PCI_BRIDGE32. I have defined IOSTANDARD as PCI33_3 for the
    PCI interface pins (except for PCICLK, which is TTL). Timing constraints are
    tough to meet as you know, but near as I can tell, they are met as the
    Xilinx ISE toolchain says "all timing constraits met".
    	What I suspect is happening is that the 80312 de-asserts IRDY right at the
    rising edge of the CLK or within 2NS after the rising edge. My analyzer time
    resolution is 2NS so I have that much uncertaintity in the measurement. In
    looking at the simulation, I can see that the IRDY signal is asserted longer
    then the 80312 asserts. I am suspecting that the newer 80312 is pushing the
    PCI spec more then the slightly older chips that you might have used in your
    testing.
    	My current thinking is going along the direction that line 711 in
    pci_target32_sm.v may not need the and qualifier ~pci_irdy_reg_in and I can
    say that commenting that one input to the 5 input and gate that creates the
    load_to_conf_out pulse does allow writes to proceed. I am most interested in
    your thoughts regarding this change to the state machine.
    	I will make another pdf file on Friday and forward it to you with all of
    the control signals shown between the Intel 80312 and the PCI_BRIDGE32 in
    the FPGA. Its just that I need to wait until then so I can be away from the
    heat of battle. Basically, I work in my home office on Friday and live in a
    cubicle Monday-Thursday where it is difficult to concentrate.
    
    Charles
    
    
    
    
    

    ReferenceAuthor
    Re: [pci] IRDY & TRDYMiha Dolenc

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.