PCIS3BASE

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Is it possible to use the low level SDRAM controller design example (sdr_ctrl.vhd) directly without the WISHBONE wrapper?

      Yes it is, but there are some additional things to consider:
      • SDRAM memory and its controllers are complex design elements, which cost weeks of development time to get them running. They are never easy to use, so take a careful look at the SDRAM memory data sheet, especially the parts about initialization and refresh.
      • Try to use the SDRAM controller ip-core in simulation. The VHDL SDRAM model has already been shipped with our board. You can download the Verilog version from Micron. Probably you will have to apply a delay time at the SDRAM controller outputs (VHDL: "foo <= bar after 2 ns;") to avoid the SDRAM models setup- and hold-time violations in a behavioral simulation.
      • Be sure to make a clock phase alignment between the internal design clock and the SDRAM clock. In our example this is done by using Xilinx application note 462 "Using Digital Clock Managers (DCMs) in Spartan-3 FPGAs". This document and appropriate VHDL/Verilog design files were available at:
        xapp462 *.pdf document
        xapp462 VHDL sources
        xapp462 Verilog sources

      Details on our demo SDRAM controller:
      • The burst length is fixed to two to transfer data in 32 Bit pieces (2x16 Bit SDRAM data bus width).
      • Supported commands:

        Quellcode

        1. constant NOP : std_logic_vector(2 downto 0) := b"111";
        2. constant READ : std_logic_vector(2 downto 0) := b"101";
        3. constant WRITE : std_logic_vector(2 downto 0) := b"100";
        4. constant PRECHARGE : std_logic_vector(2 downto 0) := b"010";
        5. constant AUTO_REFRESH : std_logic_vector(2 downto 0) := b"001";
        6. constant LOAD_MODE_REGISTER : std_logic_vector(2 downto 0) := b"000";

        LOAD_MODE_REGISTER and PRECHARGE are used for initialization only.
      • SDRAM refresh has to be done manually every 7.8 us by applying the AUTO_REFRESH command between data transfers or NOP commands.
      • Before SDRAM can be used it has to be initialized in the following sequence:
        1. Apply NOP for at least 100 us
        2. Apply PRECHARGE
        3. Apply AUTO_REFRESH every 7.8 us for 16384 times (takes together ~128 ms)
        4. Apply LOAD_MODE_REGISTER
        5. SDRAM controller is now ready for NOP, READ, WRITE and AUTO_REFRESH commands in normal operation

      • User interface (prefix “usr_”):
        1. Command interface (usr_cmd_i[2:0], usr_ack_o, usr_adr_i[22:0]): Except from the NOP command all other commands have to be held stable and valid at usr_cmd_i until usr_ack_o is asserted. For READ and WRITE commands the address at usr_adr_i has to be held stable and valid until usr_ack_o is asserted, too. For other commands the value at usr_adr_i is “don't care”. Note that the address input is 32 Bit/4 Byte aligned (2^23 x 4 Byte = 32 MByte). So you cannot address single memory cells, but burst-2 starting points.
        2. Data FPGA2SDRAM interface (usr_datai_i[15:0], usr_nextword_o): After a WRITE command is applied a valid data burst signal consisting of two 16 Bit words has to be put on usr_datai_i. The timing is given by usr_nextword_o, which is asserted for two clock cycles. Note that usr_nextword_o is asserted one clock cycle !!!before!!! data at usr_datai_i has to be valid. So it could be directly used as a FIFO read strobe signal. It could easily be delayed using a simple D-type flip-flop, if needed.
        3. Data SDRAM2FPGA interface (usr_datao_o[15:0], usr_valid_o): After a READ command a valid data burst signal consisting of two 16 Bit words appears at usr_datao_o. The timing is given by usr_valid_o, which is asserted for two clock cycles. usr_valid_o is asserted clock cycle aligned with valid data at usr_datao_o.

      CESYS development engineer / FPGA design

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von stefis ()

    • What is the purpose of ceDevice_EnableBurst API?

      EnableBurst() toggles the burst capability of the PCI controller. Burst significally increases the speed of transfers, as data isn't mixed with addresses each 4 bytes, so the transfer is done without much overhead.

      No burst: Address, Data, Address, Data, Address, Data, ...
      Burst : Address, Data, Data, Data, ..., Address, Data, Data, Data, ...

      You should use burst everywhere you can.
      Manfred Kraus
      Cesys GmbH

    • How do the three APIs ceDevice_EnableAddressPaging, ceDevice_ClearAddressPages and ceDevice_AddAddressPage impact the hardware?

      ... and what actually these APIs do when we call them from the software.


      The calls AddAddressPage(), ClearAddressPages() and EnableAddressPaging() are 100% pure software related things. The intension behind these calls are related to the fact that depending on the FPGA design, the address space of the board can be divided in different areas, where some areas should be used with burst, others without burst. Besides that, some areas may need addresses aligned to 32 bytes, some other 4 bytes. AddAdressPage()/ClearAddressPages() allows the user to define these areas with their respective properties.
      If EnableAddressPaging() is on (default), than every call to Read/WriteBlock() is checked against the active address map and throws an exception if the call has a wrong aligned address or size for the specific area, or if a transfer crosses 2 or more areas or the transfer touches an unconfigured area.In advance, the burst flag is automatically set depending on the setting done in AddAddressPage(). We add this to our API to prevent users from blue screens and computer stalls, based on wrong addressing/bursting.If dont this behaviour, simply call EnableAddressPaging(false), so you have full control on the whole address space, but you should handle EnableBurst() on your own, if you use a mixed interface.
      Manfred Kraus
      Cesys GmbH

    • Why is the onboard SPI FLASH memory not detected in the JTAG chain and how is it connected to the Spartan-3 1500 FPGA device?

      The ST M25P40 4 Mbit SPI Flash memory is not connected to the JTAG chain. It can only be accessed over a FPGA design like the WISHBONE example shipped with the board. The FPGA configuration bitstream cannot be booted from it. This FLASH is intended for storing data of user applications permanently. An additional FLASH for FPGA configuration bitstream is not needed, because PCIS3BASE is not intended for standalone use without a host PC and a software driven FPGA configuration over PCI is very fast. CESYS software API provides appropriate functions for downloading user FPGA designs.
      Extracted from provided pcis3base.ucf:

      Quellcode

      1. NET "pin_flash_s_n_o" LOC = "F20" | SLEW = FAST ;
      2. NET "pin_flash_c_o" LOC = "F21" | SLEW = FAST ;
      3. NET "pin_flash_d_o" LOC = "M22" | SLEW = FAST ;
      4. NET "pin_flash_q_i" LOC = "F19" ;
      CESYS development engineer / FPGA design