Timing/buffering issue with Digilent’s EPP on Basys2

fpgatimingverilogvhdl

I have a Digilent Basys2 FPGA, and I'm implementing the EPP interface described in http://www.digilentinc.com/Data/Products/ADEPT/DpimRef%20programmers%20manual.pdf. This allows a program called Adept to send and receive bytes from an FPGA design over the USB cable.

After following those instructions I had something that seemed to work. I could send bytes from Adept and they would be successfully displayed on the seven segment display. Unfortunately, when I sent a 100 byte file to be stored in register array, only 83 bytes arrived. (It's a bit tricky to debug in this situation, because there are only so many simple outputs on the FPGA, and using Adept to read the bytes back from the FPGA opens the possibility that it's the read implementation that's buggy. I ended up adding the ability to step through the array showing each byte in turn.)

I've rewritten my implementation a few times and looked at other people's examples (they were mostly in VHDL) but still it's not reliable. Some writes, even single bytes one at a time, are just not picked up by the design, though Adept does not report any error.

Update — tried VHDL sample design

I've now managed to run the code and design here: http://hamsterworks.co.nz/mediawiki/index.php/Digilent_EPP_Performance

It works, but a simple counter I added shows slightly more writes are performed than expected, in a few repeated tests I ran (reload the design, then send a file using Adept):

Expected    Got
  50        51 to 55
 100        105 to 108
 200        206 to 215

For the compiled C++ program from that tutorial, 1440000 = 0 (mod 256) bytes were sent, but the number written was 32 (mod 256) (I only have 8 LEDs!). In another the numbers were 1430000 = 240 (mod 256) vs 253 (mod 256).

So I still think there's a timing thing going on. Can anyone with a Basys 2 try the same experiment? My slightly altered VHDL is at https://gist.github.com/ejrh/6ba768499319e9945bd0

Small testcase from before I learned VHDL

I ended up with a small test case for EPP's WRITE signal:

input wire usb_write;  // in constraints file: NET "usb_write" LOC = "C2";
reg prev_write = 1;    // assume initially high
reg [9:0] write_count = 0;

always @(posedge mclk) begin
    if (usb_write != prev_write) begin
        write_count <= write_count + 1;
    end
    prev_write <= usb_write;
end

// display write_count on SSD
// display prev_write on LED 0

Usually when I send a byte using adept, write_count is incremented by 2, as expected. (WRITE goes low to write an address byte and a data byte, then returns to high). The LED stays lit between operations, indicating that prev_write is high.

But sometimes, the count is only incremented by 1, while the led still returns to high. It's as if different parts of my always @(posedge mclk) block were using different values of usb_write.

Is there some kind of buffering I need to do on these input/output wires? I haven't found any examples for this.

Later today I'll update the question with some of the actual EPP code I'm working with. I also mean to try one of the VHDL examples, though I'm new to VHDL.

Best Answer

Following this page https://embeddedmicro.com/tutorials/mojo/metastability-and-debouncing

I added buffering to the control signals sent by the host. They weren't in my original question, since I was having strange results even with just usb_write.

always @(posedge clk) begin
    astb_buf <= usb_astb;
    dstb_buf <= usb_dstb;
end

Buffering just these two has fixed it the data problems. The other signals are usb_write and usb_data[7:0], but these do not appear to need buffering at this point.

I have been able to send 100 and receive 100 bytes with no additions, losses or mutations, at which I'm relieved, as now I don't need to implement an error correcting protocol.

Related Solutions

RS232 output always follow with an extra 0x0b

Are you sure it's 0x0B? If it was 0x0A or 0x0D that would just mean you're appending a newline/carriage-return somewhere in the MCU's code (I would look at whether the printf you're using does this automatically).

As it is, 0x0B is the ASCII VT (vertical tab) character. This really smells like something is appending a trailing "end of line"/"end of serial buffer" flag character somewhere.

Assuming this is reliably and predictably appended at the end of every set of writes to the serial port, you may be able to just treat it as a bonus "end-of-packet" flag for your serial interface.

Considering the behaviour you are seeing, I would look into how the serial interface is implemented. It's also possible that whatever software you are using to send serial data to the MCU, your serial terminal (or other software) is appending the trailing character.

Have you put a logic analyser or DSO on the serial lines, to confirm the 0x0B is indeed coming from the MCU in the FPGA?

Also, do you have the ability to add standard digital-IO on the MCU? If you do, you could write a small bit-bang serial routine, to localize whether the 0x0b is being appended in the serial receive or serial transmit section of the MCU.

We won't be able to give much more advice without knowing the specifics of your setup.
What toolchain/FPGA soft-core/FPGA-type are you using?

Electronic – Implementing the Digilent EPP

Thanks to some help from Hamster I managed to get it working.

My code had many problems but the main thing I was doing wrong was not supporting write commands.

Here is my VHDL:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
--use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity DeppSwitches is
    Port(
        mclk     : in std_logic;
        EppDB       : inout std_logic_vector(7 downto 0);
        EppAstb : in std_logic;
        EppDstb  : in std_logic;
        EppWR    : in std_logic;
        EppWait  : out std_logic;
        Led     : out std_logic_vector(7 downto 0);
        sw      : in std_logic_vector(7 downto 0);
        btn     : in std_logic_vector(4 downto 0);

        stepCurrOutDebug : out std_logic_vector(7 downto 0);
        stepNextOutDebug : out std_logic_vector(7 downto 0)
    );
end DeppSwitches;

architecture Behavioral of DeppSwitches is
    signal    busEppOut: std_logic_vector(7 downto 0); -- Channel to send bits to pc
    signal    busEppIn: std_logic_vector(7 downto 0); -- Address that the pc sends to fpga
    signal    busEppData: std_logic_vector(7 downto 0); -- Bits to send to PC

    signal peripheralWait: std_logic := '0';

    constant stepIdle: std_logic_vector(7 downto 0)     := "0000" & "0000";
    constant stepReadA: std_logic_vector(7 downto 0)    := "0001" & "0000"; -- PC Read from FPGA Address
    constant stepReadD: std_logic_vector(7 downto 0)    := "0010" & "0000"; -- PC Read from FPGA Data
    constant stepWriteA: std_logic_vector(7 downto 0)   := "0100" & "0000"; -- PC Write to FPGA Address
    constant stepWriteD: std_logic_vector(7 downto 0)   := "1000" & "0000"; -- PC Write to FPGA Data

    signal stepCurr: std_logic_vector(7 downto 0) := stepIdle;
    signal stepNext: std_logic_vector(7 downto 0);
begin
    Led <= sw;

    -- Handshake signal used to indicate when the peripheral is ready to accept data or has data available.
    EppWait <= peripheralWait;

    -- Data bus direction control. The internal input data bus always
    -- gets the port data bus. The port data bus drives the internal
    -- output data bus onto the pins when the interface says we are doing
    -- a read cycle and we are in one of the read cycles states in the
    -- state machine.
    busEppIn <= EppDB;
    EppDB <= busEppOut;

    -- Hook the data bits to the switches
    busEppData <= sw;

    -- We need this to see the state when debugging
    stepCurrOutDebug <= stepCurr;
    stepNextOutDebug <= stepNext;

    -- Advance the state machine
    process(mclk)
    begin
        if rising_edge(mclk) then
            stepCurr <= stepNext;
        end if;
    end process;

    process(mclk)
    begin
        if rising_edge(mclk) then
            case stepCurr is                    
                when stepIdle =>
                    peripheralWait <= '0';
                    busEppOut <= "ZZZZZZZZ";

                    if EppDstb = '0' then 
                        if EppWr = '0' then
                            stepNext <= stepWriteD; -- PC Write to FPGA Data
                        else
                            stepNext <= stepReadD; -- PC Read from FPGA Data
                        end if;
                    end if;

                    if EppAstb = '0' then 
                        if EppWr = '0' then
                            stepNext <= stepWriteA; -- PC Write to FPGA Address
                        else
                            stepNext <= stepReadA; -- PC Read from FPGA Address
                        end if;
                    end if;
                -------------------------------------------------

                when stepReadD | stepReadA =>
                    busEppOut <= busEppData;
                    peripheralWait <= '1';

                    if EppDstb = '1' then
                        stepNext <= stepIdle;
                    end if;
                -------------------------------------------------

                when stepWriteD | stepWriteA =>
                    peripheralWait <= '1';
                    if EppDstb = '1' then
                        stepNext <= stepIdle;
                    end if;

                when others => stepNext <= stepIdle;
            end case;
        end if;
    end process;

end Behavioral;

My C++ program was just fine. You can see the code in the main post.

Best Answer

Related Solutions

RS232 output always follow with an extra 0x0b

Electronic – Implementing the Digilent EPP

Related Topic