Electronic – Linux on a Xilinx FPGA without EDK

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.

I used to work in a job that had a contract requirement that we could reconstruct our integrated circuit designs and simulations for twenty years. That was a battle we fought over and over again, so I have had some experience with the painful process of "archiving" a complex design.

1) If the design has tight timing constraints then it may be necessary to synthesize/optimize a number of times before all of the timing issues are uncovered and the timing constraints are "fully and correctly specified" as Dave Tweed puts it. This is particularly true if you incorporate any third-party IP, or if the person doing the synthesis is not the author of the HDL.

2) While the synthesis process is deterministic it is also subject to a vast number of variables. Some of these are hidden from the user. While I would say you should be able to get the same binary if you run exactly the same tools on the same computer on the same HDL with the same constraints on the same day, I would be hesitant to guarantee that any given binary could be reproduced exactly next week.

3) This is most certainly true. New versions of the design tools routinely break existing designs. It's not about some seed for a random number generator, it's about changes in the optimization algorithms and changes in the characterization data of the physical part. Because these changes are proprietary information they are largely hidden from the user and can appear to have a random nature.

4) This is typically true. The binary bitstream is the end result of the entire synthesis and optimization process. Most vendors hide the format of this data and may even encrypt it, which is why you can't find open-source FPGA design tools that go all of the way to the chip.

5) Is there ever any reason to store the NGC? I'll turn that around: can you justify that there is no information whatsoever in the NGC that cannot be obtained from whatever you are calling the "final design"?