|
|
|
|
We were told to accomplish a task based on the Feistel cipher.
In a Feistel cipher the plaintext, P, to be encrypted is split into two equal size parts L0 and R0 such that P = L0R0. A function F is applied to one half of the plaintext, combined with a key, and the result is XOR’d with the other half of the plaintext.
Somehow, the simulator says that "cant connect gate's outp...". However, I was unable to see the full error message.
The error occurs in line "Xor(x=r10, y=f30, out=ciphertext[0]);"
and the chip was:
CHIP FeistelEncryption {
IN plaintext[16], key[8];
OUT ciphertext[16];
PARTS:
}
|
|
Administrator
|
I have no idea how r10 or f30 are defined, so there's no way to tell what is going wrong.
You are likely trying to connect a gate's output to another gate's output (or the chip's input) or possibly you are creating a loop.
Need to see the full code to do any better.
I would recommend making an Xor8 part that is a 8-bit bitwise Xor. This would make your code for this chip a lot easier to write and debug.
|
|
|
Many thanks, I have figure out the problem.
It seemed that ciphertext[0] cannot be the input of a Xor chip... dunno why but it was.
I added "Xor(x=r10, y=f30, out=r30, out=ciphertext[0]);" and used r30 as a new input, it worked.
In regard to Xor8, the tools(builtinchips) we are allowed to use is limited, Xor8 is not in the list:(
Now the problem goes to the .cmp with .tst. May take myself more time to deal with it.
|
|
Administrator
|
The Xor8 is not a built-in chip. You would have to create it. That should be fair game since it is just you designing all the logic but logically partitioning it into two files. You could ask if you are allowed to define helper chips.
The reason that you can't use ciphertext[0] as an input is because it is defined as an output of your chip. You also can't take sub-busses (or individual signals) of anything other that a chip input or output.
These restrictions are just a consequence of the very simple HDL simulator that the authors wrote to support this project. So they provided a different way to accomplish the same logical objectives, as you've discovered.
Glad you found a solution.
I might recommend more meaningful signal names. Perhaps I'm just not seeing the big picture of your naming convention, but having a signal named r30 which is the XOR of signals named r10 and f30 imparts no meaning that I can fathom.
|
|
|
Because we were told to accomplish this function in a single .hdl, so i dont think we can make another Xor8. And the r10 f30 something just represents Function 1 0, Right 3 0. haha.
There is another question: if I want to write this program in HACK assembly, how can i split the initial plaintext[16] into 2 equal parts?
The method i think of is to judge whether it is greater than, for example, 1000000, and than minus it to split. After that we can store it into different RAM. But that requires lots of work(16 bit).
I wonder whether there exists a simple way to split them up? Because bitwise Xor can be figured out easily.
|
|
Administrator
|
If it has to be in a single .hdl file, then you have no choice. Not the best from a design standpoint, but there can be all sorts of practical reasons for such a restriction.
To split the plaintext into two separate bytes you use bit masking (sometimes called bit banging) and the fact that logical AND preserves the other value if one input is a 1 and clears it if it's a 0. To join them back together you use the fact that logical OR preserves the other value if one input is a 0 and sets it if it's a 1.
HighByte = FullWord & 0xFFFF0000
LowByte = FullWord & 0x0000FFFF
Process HighByte and LowByte separately
FullWord = HighByte | LowByte
If your processing can put anything into the other half, you need to reclear it before combining them.
|
|
Locked
