sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.Dziennik Jadwigi Ankiewicz, napisany w obozie koncentracyjnym na Majdanku w 1943 roku, jest jedynym oryginalnym świadectwem spisanym w całości wewnątrz murów obozu. Ta historia zasługuje na pamięć.
(English: The diary of Jadwiga Ankiewicz, written in the concentration camp at Majdanek in 1943, is the only original testimony written in its entirety within the camp's walls. This story is critical and deserves to be remembered.)
I did extensive research on this subject to find out provenance, etc. I concluded it is one of the most authentic stories of what it looked like at Majdanek. There is another one I just came across. I have not read it. It's another witness account - https://www.youtube.com/watch?v=REIhQCPF8FU If you can get ahold of the book, let me know. It is Jan Michalak.
There are some stories that history forces us to remember, and then there are those that seem to whisper to us across time, demanding to be heard. For me, it is Jadwiga's story.
Jadwiga was imprisoned at KL Lublin, more commonly known as Majdanek, during World War II. Yet, in the face of unspeakable horror, she did something extraordinary. She wrote. Her diary, penned between January 15 and May 17, 1943, stands as the only known original testimony written in its entirety within the camp's walls. Carrying a notebook and pencil was a capital offense, so every word she jotted down was an act of quiet, profound defiance.
She was a very talented writer. In the face of horror at Majdanek, her demeanor was unflinching. What strikes me most is her unique cursive script and, as the museum describes it, her ability to keep her head up with a positive attitude. Her writing is not just a historical document; it is a testament to the resilience of the human spirit. And it is documentation of what happened to her before she was supposedly released and joined the resistance force.
A Personal Journey to This Discovery
My own journey to find this diary was a lesson in persistence. I reached out to several institutions for help with research on related materials for ink, ridge, and other types of analysis, but most showed little interest with one line responses. It was disheartening. Some of the replies I received were one sentence replies stating, "I'm afraid not". They never bothered to ask who I was or what materials I was working with. It left me speechless and in disbelief.
That is why I am incredibly grateful to the State Museum at Majdanek. Of all of the folks I've interacted with in this arena, they at least replied. It is evident they have a current understanding of the depth of what happened before and after. Not only did they reply to my emails with kindness and professionalism, but they also provided me with scanned documents to work with before I even return. Their dedication to preserving this history, and helping others do the same, stands in stark contrast to the indifference I encountered elsewhere.
The Diary Itself
Thanks to their work, this invaluable diary has been published in a beautiful English-language edition. The book contains a reprint of the original diary, a full transcription, and extensive historical commentary that details Jadwiga's life, her family's fate, and the process of bringing this testament to the world. It was made possible through a grant from the Polish Ministry of Culture and National Heritage. The folks at the State Museum at Majdanek are clearly dedicated to remembrance.
You can find the diary and learn more about it at the museum's official bookstore: Majdanek. 15 I–17 V 43 r. Diary.
If you are going to purchase this book, I recommend that you order it directly from the Majdanek book store. Here is the English language link. Unfortunately, the book is no longer available in the US for purchase.
I won't tell you where. You wouldn't find it in your textbooks anyway.
And if I told you, you still wouldn't believe me.
I remember as a small child looking at the sky. When we were leaving. I remember the cold air and I remember the constant smell. I remember that road and your devotion and focus as we made our way out of there. I remember you holding my hand as we crossed the muddy courtyard on our way outside. It's still there. I remember my curiosity about a world I knew nothing about. It looks the same. Everything we know today, pushed back in time by about 40 years. I remember all the buildings and streets we passed when we left the city years ago. They look the same. I took a bus ride through the city recently and passed every one of them.
Your hand in mine, we walked thousands of miles.
sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.During my visit to the Jüdisches Museum Frankfurt am Main, I photographed this decorative plaque bearing the Schma Israel ("Hear, O Israel") — the central prayer of Jewish faith. Inscribed in both Hebrew and German, it was designed to hang on the eastern wall of a synagogue, facing Jerusalem. Its imagery is rich with Temple symbolism: the two columns represent the twelve tribes of Israel, crowned lions frame a radiant medallion with the name of God, and below sits the Ark of the Covenant, which once held the tablets of the law in the Holy of Holies.
What struck me was how a single object could distill so much - faith, history, exile, and longing for Jerusalem, into one visual composition. While similar plaques sometimes appeared in homes as Mizrah indicators of prayer direction, this particular piece was clearly made for a synagogue, as its formal design and Temple references suggest.
This plaque is a remnant of a German Jewish community that was nearly annihilated during the Shoah. Today, it survives as a witness – both to what was built and to what was lost.
A small but powerful reminder of the depth of German Jewish heritage.
sha512sum -c SHA512SUMS.CA42 47E8 9A5E FEAB 36DC 6A42 C547 9171 B69A 3CFB 887D B92C 3FB1 480A 2993 57A3.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.sha512sum -c SHA512SUMS.2969 AEB8 0A42 E021 5E66 4D93 BD9B C85E 0213 8166 415C 9171 2074 3657 B386 AF51.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.Between five and six million Polish citizens were murdered, three million of them Polish Jews. Much of the killing was carried out on that same soil: at Auschwitz-Birkenau, Treblinka, Sobibór, Bełżec, Majdanek, and Chełmno, all of them Nazi German camps and killing centers built in occupied Poland. Whole towns where no one came home. A civilization of a thousand years, destroyed in five.
The ideologies behind these crimes do not disappear by themselves. Each generation must carry that weight, and act on it.
The fields look ordinary now. The forests have grown back. The track is still there.
What remains is the duty to remember precisely. The names. The places. The dates. The silence in those places now is not empty. It is the shape of what was taken.
This is a shared history, and it cannot be told without Poland. For nearly a thousand years, from the Statute of Kalisz in 1264 through the academies of Kraków and Lublin, the printing houses of Warsaw, and the streets of Wilno, Polish Jews built one of the great civilizations of Europe. They were Polish citizens. They wrote in Polish, in Yiddish, and in Hebrew. They fought in Polish uprisings. They are buried in Polish soil.
To study this history through the objects, documents, and testimonies that preserve it, I recommend:
POLIN Museum of the History of Polish Jews
Warsaw
Ośrodek „Brama Grodzka – Teatr NN”
Lublin
Emanuel Ringelblum Jewish Historical Institute
Żydowski Instytut Historyczny, Warsaw
sha512sum -c SHA512SUMS.2969 AEB8 0A42 E021 5E66 4D93 BD9B C85E 0213 8166 415C 9171 2074 3657 B386 AF51.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.This is a photo that I took while walking around Auschwitz II-Birkenau in Oświęcim, Poland. The camp is huge. The barracks in the distance are to the left of the barracks where Edith Frank, Anne Frank, and Margot Frank supposedly stayed. Otto stayed at Auschwitz I.
I reached my arm through the fence to take this photo. It was a very important day.
sha512sum -c SHA512SUMS.2969 AEB8 0A42 E021 5E66 4D93 BD9B C85E 0213 8166 415C 9171 2074 3657 B386 AF51.ots file proves that SHA512SUMS existed at or before the Bitcoin block timestamp below.Memory means ensuring the immutability of truth over time. In the physical world, we use archives to preserve our stories. In the digital world, we use cryptography to protect identity, authorship, and trust.
A new threat posed by quantum computers now challenges this foundation. On a massive scale, it will be capable of erasing or falsifying the cryptographic records that define our digital lives.
To protect the integrity of our collective memory and prevent future attackers from stealing identities, I have moved beyond previous cryptographic standards and am today implementing the highest available level of security: post-quantum technology.
The Dual Threat: Shor and Grover
Quantum computing poses two distinct mathematical threats to modern cryptography. To understand the transition to post-quantum standards, it is essential to be familiar with both.
Shor's algorithm represents the existential threat. It efficiently solves the problems of integer factorization and discrete logarithms—the mathematical underpinnings of almost all classical public-key cryptosystems, including RSA, Diffie-Hellman, and elliptic curve cryptography (ECC). This is not merely a weakening, but a complete break. A sufficiently powerful quantum computer can derive private keys from public keys, thereby undermining fundamental identity systems.
Grover's algorithm targets symmetric cryptography and hash functions. It offers a quadratic speedup for brute-force searches, effectively halving the security strength of a key. This is why AES-256 is so crucial: even after Grover's reduction, it still offers 128 bits of effective security—a level that is practically unbreakable.
The most immediate threat is the SNDL (Store Now, Decrypt Later) attack. Encrypted traffic, identity credentials, certificates, and signatures can be intercepted today—while classical cryptography is still valid—and stored indefinitely. Once quantum technology matures, these archives can be retroactively decrypted or forged. If our cryptographic foundations fail, we also lose the ability to document our own digital history.
For years, elliptic curve cryptography—specifically P-384 (ECDSA)—was the gold standard in high-security environments. While P-384 offers approximately 192 bits of classical security, it possesses absolutely no resistance to Shor's algorithm. It was designed for a classical world, and that world is coming to an end.
Therefore, I have implemented ML-DSA-87 for Root CA and signing operations. ML-DSA-87 represents the highest security level among modern lattice-based standards (Category 5), computationally equivalent to AES-256. Choosing this level—rather than the widely adopted ML-DSA-65—ensures that my network's identity is established with the greatest possible security margin available today.
Post-quantum cryptography is no longer theoretical. It is now deployable, even on routers and mobile devices. I am running a customized OpenSSL 3.5.0 build on an AArch64 MediaTek Filogic 830/880 platform. This SoC is unusually well-suited for post-quantum workloads.
ML-KEM and ML-DSA rely heavily on polynomial arithmetic. ARM NEON vector instructions enable the parallel execution of these operations, thereby significantly reducing TLS handshake latency—even when handling large amounts of PQ key material.
Post-quantum keys are large. A public ML-KEM-1024 key comprises 1568 bytes, compared to 49 bytes for P-384. AArch64's 64-bit address space enables efficient management of these buffers and avoids the fragmentation issues of older architectures.
After installing the customized toolchain on the AArch64 target system, the post-quantum stack can be verified directly.
openssl list -kem-algorithms
ml-kem-1024
secp384r1mlkem1024 (high-security hybrid)
openssl list -signature-algorithms | grep -i ml
ml-dsa-87 (256-bit security)
The presence of these algorithms confirms that the platform supports both post-quantum key exchange (ML-KEM-1024) and quantum-resistant signatures (ML-DSA-87).
By migrating directly to ML-KEM-1024 and ML-DSA-87, I have bypassed the obsolete bottlenecks of the last decade. My network is no longer preparing for the quantum transition—it has already completed it. The rest of the industry will follow.
Parallelism on a time-sliced, preemptive operating system means the simultaneous execution of multiple schedulable entities over a time quantum. Both processes and threads can execute in parallel across multiple cores or processors. Concurrency and parallelism are at play on a multi-user system with preemptive time-slicing and multiple processor cores. Affinity scheduling refers to scheduling processes and threads across multiple cores so that their concurrent and parallel execution is close to optimal.
It's worth noting that affinity scheduling refers to the practice of assigning processes or threads to specific processors or cores to optimize their execution and minimize unnecessary context switching. This can improve overall system performance by reducing cache misses and increasing cache hits, among other benefits. In contrast, non-affinity scheduling allows processes and threads to be executed on any available processor or core, which can result in more frequent context switching and lower performance.As the switches are moved or the buttons are pressed, the seven-segment display is updated to reflect the numeric output frequency, and the output pin(s) are driven at the desired frequency. The onboard clock runs at 50MHz, and the signal on the output pins is set on the rising edge of the clock input signal (positive edge-triggered). At 50MHz, the output pins can be toggled at a maximum rate of 50 million cycles per second or 25 million rising edges of the clock per second. An LED attached to one of the output pins would blink 25 million times per second, not recognizable to the human eye. The persistence of vision, which is the time the human eye retains an image after it disappears from view, is approximately 1/16th of a second. Therefore, an LED blinking at 25 million times per second would appear as a continuous light to the human eye.
scaler <= compute_prescaler((to_integer(unsigned( SW )))*scaler_mlt);
gpiopulse_process : process(CLOCK_50, KEY(0))
begin
if (KEY(0) = '0') then -- async reset
count <= 0;
elsif rising_edge(CLOCK_50) then
if (count = scaler - 1) then
state <= not state;
count <= 0;
elsif (count = clk50divider) then -- auto reset
count <= 0;
else
count <= count + 1;
end if;
end if;
end process gpiopulse_process;The scaler signal is calculated using the compute_prescaler function, which takes the value of a switch (SW) as an input, multiplies it with a multiplier (scaler_mlt), and then converts it to an integer using to_integer. This scaler signal is used to control the frequency of the pulse signal generated on the output pin.Create Ed25519 SSH keypair (supported in OpenSSH 6.5+). Parameters are as follows:
-o save in new formatssh-keygen -o -a 128 -t ed25519 -f .ssh/ed25519-$(date '+%m-%d-%Y') -C ed25519-$(date '+%m-%d-%Y')
Create Ed448-Goldilocks GPG master key and sub keys.# gpg --quick-generate-key ed448-master-key-$(date '+%m-%d-%Y') ed448 sign 0
# gpg --list-keys --with-colons "ed448-master-key-08-03-2021" | grep fpr
# gpg --quick-add-key "$fpr" cv448 encr 2y
# gpg --quick-add-key "$fpr" ed448 auth 2y
# gpg --quick-add-key "$fpr" ed448 sign 2y
The 96boards CE specification calls for an optional JTAG connection. The specification also indicates that the optional JTAG connection shall use a 10 pin through hole, .05" (1.27mm) pitch JTAG connector. The part is readily available on most electronics sites. Breaking out the pins with long wires and shrink wrapping them is ideal for making sure that each connection is labeled and separate when connecting to a JTAG debugger. While a JTAG connection is not required for flashing or loading the bootloaders onto the board, the JTAG connection is useful for advanced chip-level debugging. The serial UART connection is sufficient for loading release or debug versions of bl0, bl1, bl2, bl31, bl32, the kernel, and userspace. Last but not least, ARM-powered boards, with 12V power input, often require external fans to keep the board cool. As seen in the below photos, two 5V fans were powered from an external power supply. Any work on microcontroller boards should be performed on a grounded surface. Proper grounding procedures should always be followed as most microcontroller boards contain ESD sensitive components.
In the below photos, a 96Boards SBC is mounted on an IP65, ABS plastic junction box for durability. The pins are extended and mounted with screws underneath the junction box. The electrical conduit holes on the side of the junction box are ideal for holding small, project fans. The remaining electrical conduit holes provide a clean place to place the remaining wires from the board - micro USB, USB-C, and 12V power.
The Kirin 960 SoC and on-board USB 3.0 make the HiKey 960 SBC an ideal platform for running a Linux Bridged firewall. The number of single-board computers with an SoC as powerful as the HiSilicon Kirin 960 is limited.
When compared with the Raspberry Pi series of single board computers (SBC), the HiKey 960 SBC is significantly more powerful. The Kirin 960 also stands above the ARM powered SoCs which reside in most commercial routers.
USB 3.0 makes the HiKey 960 board an attractive option for bridging or routing, filtering network traffic, or connecting to an external gateway via IPSec. Both network traffic filtering and IPSec tunneling can be computationally expensive operations. However, the multicore Kirin 960 is well suited for these types of tasks.
In order to be able to run an IPSec client tunnel and a Linux Bridged firewall connected over 1G ethernet links, certain kernel configuration modifications are needed. Furthermore, the Android Linux kernel for the HiKey 960 board does not boot on a standard Linux root filesystem because it is designed to boot an Android customized rootfs.
The latest googlesource Linux kernel (hikey-linaro-4.9) for Android (designed to boot Android on the HiKey 960 board) has been customized to remove the Android specific components so that the kernel boots on a standard Linux root filesystem, with the proper drivers enabled for network connectivity via attached 1000Mb/s USB 3.0 to ethernet adapters. The standard UART interface on the board should be used for serial connectivity and shell access. WiFi and Bluetooth have been removed from the kernel configuration. The kernel should be booted off of a microSDHC UHS-I card. The 96boards instructions should be followed for configuring the HiKey 960 board, setting the jumpers on the board, building and flashing the l-loader, firmware package, partition tables, UEFI loader, ARM Trusted Firmware, and optional Op-TEE. Links for the normal Linux kernel configuration, multi-interface bridge configuration, and single interface IPSec configuration are below. Additional kernel config modifications may be needed for certain types of applications.
mkdir /usr/local/toolchains cd /usr/local/toolchains/ TC=gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu wget https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-linux-gnu/$TC.tar.xz tar -xJf $TC.tar.xz export ARCH=arm64 export CROSS_COMPILE=/usr/local/toolchains/$TC/bin/aarch64-linux-gnu- export PATH=/usr/local/toolchains/$TC/gcc-aarch64-linux-gnu/bin:$PATH cd /usr/local/src git clone https://android.googlesource.com/kernel/hikey-linaro cd hikey-linaro git checkout -b android-hikey-linaro-4.9 make hikey960_defconfig make -j8
Bridged configuration, no ip addresses on dual nic interfaces. (crossover cable is useful for testing). Bridge interface obtains dhcp address (/11) from wlan router. Aliased interface added to br0 and assigned private subnet ip on different subnet (/8). Spanning tree set on bridge interface. Basic ebtables and iptables ruleset below.
brctl addbr <br> brctl addif <br> <eth1> <eth2> ifconfig <br> up ifconfig <eth1> up ifconfig <eth2> up brctl stp <br> yes dhclient <br> ifconfig <br>:0 <a.b.c.d/sn> up iptables --table nat --append POSTROUTING --out-interface <br> -j MASQUERADE iptables -P INPUT DROP iptables --append FORWARD --in-interface <br>:0 -j ACCEPT ebtables -P FORWARD DROP ebtables -P INPUT DROP ebtables -P OUTPUT DROP ebtables -t filter -A FORWARD -p IPv4 -j ACCEPT ebtables -t filter -A INPUT -p IPv4 -j ACCEPT ebtables -t filter -A OUTPUT -p IPv4 -j ACCEPT ebtables -t filter -A INPUT -p ARP -j ACCEPT ebtables -t filter -A OUTPUT -p ARP -j ACCEPT ebtables -t filter -A FORWARD -p ARP -j REJECT ebtables -t filter -A FORWARD -p IPv6 -j DROP ebtables -t filter -A FORWARD -d Multicast -j DROP ebtables -t filter -A FORWARD -p X25 -j DROP ebtables -t filter -A FORWARD -p FR_ARP -j DROP ebtables -t filter -A FORWARD -p BPQ -j DROP ebtables -t filter -A FORWARD -p DEC -j DROP ebtables -t filter -A FORWARD -p DNA_DL -j DROP ebtables -t filter -A FORWARD -p DNA_RC -j DROP ebtables -t filter -A FORWARD -p LAT -j DROP ebtables -t filter -A FORWARD -p DIAG -j DROP ebtables -t filter -A FORWARD -p CUST -j DROP ebtables -t filter -A FORWARD -p SCA -j DROP ebtables -t filter -A FORWARD -p TEB -j DROP ebtables -t filter -A FORWARD -p RAW_FR -j DROP ebtables -t filter -A FORWARD -p AARP -j DROP ebtables -t filter -A FORWARD -p ATALK -j DROP ebtables -t filter -A FORWARD -p 802_1Q -j DROP ebtables -t filter -A FORWARD -p IPX -j DROP ebtables -t filter -A FORWARD -p NetBEUI -j DROP ebtables -t filter -A FORWARD -p PPP -j DROP ebtables -t filter -A FORWARD -p ATMMPOA -j DROP ebtables -t filter -A FORWARD -p PPP_DISC -j DROP ebtables -t filter -A FORWARD -p PPP_SES -j DROP ebtables -t filter -A FORWARD -p ATMFATE -j DROP ebtables -t filter -A FORWARD -p LOOP -j DROP ebtables -t filter -A FORWARD --log-level info --log-ip --log-prefix FFWLOG ebtables -t filter -A OUTPUT --log-level info --log-ip --log-arp --log-prefix OFWLOG -j DROP ebtables -t filter -A INPUT --log-level info --log-ip --log-prefix IFWLOG
iptables -t nat -A POSTROUTING -s <clientip>/32 -o <eth> -j SNAT --to-source <virtualip> iptables -t nat -A POSTROUTING -s <clientip>/32 -o <eth> -m policy --dir out --pol ipsec -j ACCEPT
XOR logic gates are a fundamental component in cryptography, and many of the typical stream and block ciphers use XOR gates. A few of these ciphers are ChaCha (stream cipher), AES (block cipher), and RSA (block cipher).
While many compiled and interpreted languages support bitwise operations such as XOR, the software implementation of both block and stream ciphers is computationally inefficient compared to FPGA and ASIC implementations.
Hybrid FPGA boards integrate FPGAs with multicore ARM and Intel application processors over high-speed buses. The ARM and Intel processors are general-purpose processors. On a hybrid board, the ARM or Intel processor is termed the hard processor system or HPS. Writing to the FPGA from the HPS is typically performed via C from an embedded Linux build (yocto or buildroot) running on the ARM or Intel core. A simple bitstream can also be loaded into the FPGA fabric without using any ARM design blocks or functionality in the ARM core for a hybrid ARM configuration.
The following is a simple hardware design written in VHDL and simulated in ModelSim. The image contains the waveform output of a simulation in ModelSim. The HPS is not used. On boot, the bitstream is loaded into the FPGA fabric. VHDL components are utilized, and a testbench is defined for testing the design. The entity and architecture VHDL design units are below.
--three input xnor gate entity declaration - external interface to design entity
entity xnorgate is
port (
a,b,c : in std_logic;
q : out std_logic);
end xnorgate;
architecture xng of xnorgate is
begin
q <= a xnor b xnor c;
end xng;
--chain of xor / xnor gates using components and sequential logic
entity xorchain is
port (
A,B,C,D,E,F : in std_logic;
Av,Bv : in std_logic_vector(31 downto 0);
CLOCK_50 : in std_logic;
Q : out std_logic;
Qv : out std_logic_vector(31 downto 0));
end xorchain;
architecture rtl of xorchain is
component xorgate is
port (
a,b : in std_logic;
q : out std_logic);
end component;
component xnorgate is
port (
a,b,c : in std_logic;
q : out std_logic);
end component;
component xorsgate is
port (
av : in std_logic_vector(31 downto 0);
bv : in std_logic_vector(31 downto 0);
qv : out std_logic_vector(31 downto 0));
end component;
signal a_in, b_in, c_in, d_in, e_in, f_in : std_logic;
signal av_in, bv_in : std_logic_vector(31 downto 0);
signal conn1, conn2, conn3 : std_logic;
begin
xorgt1 : xorgate port map(a => a_in, b => b_in, q => conn1);
xorgt2 : xorgate port map(a => c_in, b => d_in, q => conn2);
xorgt3 : xorgate port map(a => e_in, b => f_in, q => conn3);
xnorgt1 : xnorgate port map(conn1, conn2, conn3, Q);
xorsgt1 : xorsgate port map(av => av_in, bv => bv_in, qv => Qv);
process(CLOCK_50)
begin
if rising_edge(CLOCK_50) then --assign inputs on rising clock edge
a_in <= A;
b_in <= B;
c_in <= C;
d_in <= D;
e_in <= E;
f_in <= F;
av_in(31 downto 0) <= Av(31 downto 0);
bv_in(31 downto 0) <= Bv(31 downto 0);
end if;
end process;
end rtl;
entity xorchain_tb is
end xorchain_tb;
architecture xorchain_tb_arch of xorchain_tb is
signal A_in,B_in,C_in,D_in,E_in,F_in : std_logic := '0';
signal Av_in : std_logic_vector(31 downto 0);
signal Bv_in : std_logic_vector(31 downto 0);
signal CLOCK_50_in : std_logic;
signal BRK : boolean := FALSE;
signal Q_out : std_logic;
signal Qv_out : std_logic_vector(31 downto 0);
component xorchain
port (
A,B,C,D,E,F : in std_logic;
Av : in std_logic_vector(31 downto 0);
Bv : in std_logic_vector(31 downto 0);
CLOCK_50 : in std_logic;
Q : out std_logic;
Qv : out std_logic_vector(31 downto 0));
end component;
begin
xorchain_instance: xorchain port map (A => A_in,B => B_in, C => C_in,
D => D_in, E => E_in, F => F_in, Av => Av_in,
Bv => Bv_in, CLOCK_50 => CLOCK_50_in, Q => Q_out,
Qv => Qv_out);
clockprocess: process
begin
while not BRK loop
CLOCK_50_in <= '0';
wait for 20 ns;
CLOCK_50_in <= '1';
wait for 20 ns;
end loop;
wait;
end process clockprocess;
testprocess : process
begin
A_in <= '1';
B_in <= '0';
C_in <= '1';
D_in <= '0';
E_in <= '1';
F_in <= '1';
wait for 40 ns;
A_in <= '1';
B_in <= '0';
C_in <= '1';
D_in <= '0';
E_in <= '1';
F_in <= '0';
wait for 20 ns;
A_in <= '0';
B_in <= '0';
C_in <= '1';
D_in <= '0';
E_in <= '1';
F_in <= '0';
wait for 40 ns;
BRK <= TRUE;
wait;
end process testprocess;
end xorchain_tb_arch;
entity xorgate is
port (
a,b : in std_logic;
q : out std_logic);
end xorgate;
architecture xg of xorgate is
begin
q <= a xor b;
end xg;
entity xorsgate is
port (
av : in std_logic_vector(31 downto 0);
bv : in std_logic_vector(31 downto 0);
qv : out std_logic_vector(31 downto 0));
end xorsgate;
architecture xsg of xorsgate is
begin
qv <= av xor bv;
end xsg;