I'm working on a project which will contain lots of smaller modules written in VHDL, how in quartus can I make this manageable also to the point that I can test the smaller modules. I am trying to implement the DES encryption algorithm in VHDL, and for example one of my modules is the initial permutation. How can I achieve the unit testing of all my modules?
Structuring Large Quartus Projects
quartus-iivhdl
Related Solutions
Let's say that we want to do a good job of testing this, but without going through the entire 2^32 space of possible operands. (It is not possible for such adder to have such a bug that it only affects a single combination of operands, requiring an exhaustive search of the 2^32 space, so it is inefficient to test it that way.)
If the individual adders are working correctly, and the ripple propagation between them works correctly, then it is correct.
I would giver priority to some test cases which focus on stressing the carry rippling, since the adders have been individually tested.
My first test case would be adding 1 to 1111..1111 which causes a carry out of every bit. The result should be zero, with a carry out of the highest bit.
(Every test case should be tried over both commutations: A + B and B + A, by the way.)
The next set set of test cases would be adding 1 to various "lone zero" patterns like 011...111, 1011...11, 110111..111, ..., 1111110. The presence of a zero should "eat" the carry propagation correctly at that bit position, so that all bits in the result which are lower than that position are zero, and all higher bits are 1 (and, of course, there is no final carry out of the register).
Another set of test cases would add these "lone 1" power-of-two bit patterns to various other patterns: 000...1, 0000...10, 0000...100, ..., 1000..000. For instance, if this is added to the operand 1111.1111, then all bits from that bit position to the left should clear, and all the bits below that should be unaffected.
Next, a useful test case might be to add all of the 16 powers of two (the "lone 1" vectors), as well as zero, to each of the 65536 possible values of the opposite operand (and of course, commute and repeat).
Finally, I would repeat the above two "lone 1" tests with "lone 11": all bit patterns which have 11 embedded in 0's, in all possible positions. This way we are hitting the situations that each adder is combining two 1 bits and a carry, requiring it to produce 1 and carry out 1.
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
DES has a complexity of around 4700 gate equivalents. It's kind of small to be worrying about testing individual 'modules'.
DES historically was intended to only be implemented in hardware and the specification describes connectivity and order.
The Initial Permutation and Inverse Initial Permutation describe an 8 bit interface delivering ordered bits to and from two 32 bit registers (comprised of four 8 bit shift registers, that can be parallel read and loaded during rounds):
Initial Permutation
Inverse Initial Permutation
Note that barring LR and RL order the IP and IP-1 are symmetrical. It isn't necessary to test them individually, even depending on using a different interface size. There are known value tests that provide complete coverage for DES and allow a high degree of fault isolation, these could be used for BIST.
Permuted Choice 1 tells a similar tale to the Initial Permutation for loading key from an 8 bit interface into the C and D registers comprised of three 8 bit and one 4 bit left and right shifting registers with parallel output (for PC2):
And up to this point we've dealt with a total of 25 wires if you were to use an 8 bit wide interface. Regardless of the interface size, you can test those 25 or upto 184 wires with marching '1's, as long as you can observe the results externally.
Permuted Choice 2 describes tap off ordering from the C and D registers to produce a selected key for each round:
Permuted Choice 2
You can minimize the impact of the key by setting it to all '0's while testing other elements. DES can be completely tested in 291 vectors comprised of a 64 bit key value (including parity), a 64 bit input value, a 64 bit output value and a bit describing the encryption/decryption mode of a particular vector. Further the tests are ordered so you don't need redundant information:
(There may or may not be a parity error in one vector)
You might gather I've done at least one VHDL implementation. How the design hierarchy is organized is dependent on the interface bus width and how efficiently the DES algorithm executes (pre-scheduled keys, superscalar pipelining, ...). The 8 bit interface design model took about 2 1/2 days to implement and debug (having had experience writing C programs for implementing DES).
Addendum
From the following list of vhdl source files for a simple DES implementation:
You can get that this is an instantiated RTL model of the actual hardware. In an FPGA implementation the buffer models wouldn't be used. There's a top level test bench (des_tb.vhdl) that performs design validation, while synthesis starts at the top of the actual design (des.vhdl), which uses an 8 bit interface. The hierarchy is shown (with duplicate implementations removed)
The dslice elements are uniquified by S Box, and the organization is based on length of and number (locality) of wires (nets), in an organization seen in the first commercially available DES implementation (Fairchild 8414, four 40 pin bipolar chips each containing a byte of L, a byte of R, three bytes and a nybble of either C and D, and two masked S Box ROMs.
DES was originally specified to be implemented in hardware and VHDL is ideally suited for hardware description, while FIPS PUB 46 is an interoperability standard and not an implementation standard. Writing a VHDL model based on the interoperability standard, which isn't too bad from a software perspective can end up with a complex VHDL description that actually results in simple hardware (see the P. Ghosal paper's link (in comments) Table 1. In general we test connectivity in permutations that are simply wires, not their description accuracy, which is a text domain issue.
The state machine implements the Key Schedule, in this simple implementation by shifting the C and D registers either right or left by either one or two clocks before the next round of L and R are latched (registered).
So the point of this is two fold. First DES is simple in terms of hardware. The entire model including the test bench implemented entirely using signals ends up with 473 signals, including hierarchical represented distinct VHDL drivers. It wouldn't be that far off from a 64 bit interface implementation. Second that what we should be testing in a hardware design language is the accuracy of the resulting hardware, and not whether there are transcription errors modeling permutations like software.
You could test hierarchical design units separately. In this case the complexity is low enough that's not really needed. If I were going to write design units for permutations, I'd write C programs to translate tables for a known good C implementation of DES into VHDL (which is how the S Boxes are done here, although I did four different implementations, from LUTs to logic, to reduced complexity ROMs).
I also wrote a C Program to convert the 291 test vectors from NBS Special Pub 500-20 to VHDL, organized as key vectors, input vectors (plain), and output vectors (cipher, expected results).
In the case of testing permutations as design units separately, you could write a C program that generated thorough test cases as VHDL along with expected results and provide individual test benches.