constant possible_values : t_int_array :=(4,8,12, n+4...1432,1436);
library IEEE;
use IEEE.std_logic_1164.all;
entity offset_generator is
port(
clk : in STD_LOGIC;
reset : in STD_LOGIC;
seed : in STD_LOGIC_VECTOR(32 downto 0);
result : out STD_LOGIC_VECTOR(10 downto 0)
);
end offset_generator;
architecture offset_generator of offset_generator is
signal s_result : STD_LOGIC_VECTOR(10 downto 0) := (others => '0');
type t_int_array is array(natural range 0 to 360) of natural range 0 to 1436;
constant possible_values : t_int_array :=(4,8,12,16,....,1432,1436);
signal s_seed : STD_LOGIC_VECTOR(32 downto 0) := (others => '0');
function GET_RANDOM (seed : in STD_LOGIC_VECTOR) return STD_LOGIC_VECTOR is
begin
return INSERT_IMPLEMENTATION_HERE;
end;
begin
result <= s_result;
process( clk )
begin
if (rising_edge(clk)) then
if (reset = '1') then
s_seed <= seed;
else
s_result <= GET_RANDOM(s_seed);
end if;
end if;
end process;
end offset_generator;
Greetings! I am trying to find best way for random generator in specific range and was wondering what are the best practices for now.
I have array of 360 numbers each of one is +4 of previous:
Code:constant possible_values : t_int_array :=(4,8,12, n+4...1432,1436);
And I'd like to have some function that accepts seed/code and output numbers from this array in random way. Numbers may also be not initially stored in array, but also generated in some function during execution. This will save some on-chip RAM.
For now I am still looking for proper way of such limitation pure LFSR, since it will just generate me random numbers, and not what I need. Maybe there is some graceful way to do it, to not add conditions like (if result > 1436 then generate again)
That's some example vhdl block I created for demonstration:
Code:library IEEE; use IEEE.std_logic_1164.all; entity offset_generator is port( clk : in STD_LOGIC; reset : in STD_LOGIC; seed : in STD_LOGIC_VECTOR(32 downto 0); result : out STD_LOGIC_VECTOR(10 downto 0) ); end offset_generator; architecture offset_generator of offset_generator is signal s_result : STD_LOGIC_VECTOR(10 downto 0) := (others => '0'); type t_int_array is array(natural range 0 to 360) of natural range 0 to 1436; constant possible_values : t_int_array :=(4,8,12,16,....,1432,1436); signal s_seed : STD_LOGIC_VECTOR(32 downto 0) := (others => '0'); function GET_RANDOM (seed : in STD_LOGIC_VECTOR) return STD_LOGIC_VECTOR is begin return INSERT_IMPLEMENTATION_HERE; end; begin result <= s_result; process( clk ) begin if (rising_edge(clk)) then if (reset = '1') then s_seed <= seed; else s_result <= GET_RANDOM(s_seed); end if; end if; end process; end offset_generator;
Wow. You couldn't come up with a more complex, resource intensive method?I suggest you use 9 bit LFSR. This will generate 1~511
then scale each value down to 359/511.
The scaling can be done as multiplication e.g.
359/511 = 0.7025 so pre-scale up by 2^10 to become round(0.7025*2^10) ~= 719
Now multiply each LSFR data by 719 and discard 10 LSBs.
Finally add two zeros as extra LSBs (this means x4)
Wow. You couldn't come up with a more complex, resource intensive method?I suggest you use 9 bit LFSR. This will generate 1~511
then scale each value down to 359/511.
The scaling can be done as multiplication e.g.
359/511 = 0.7025 so pre-scale up by 2^10 to become round(0.7025*2^10) ~= 719
Now multiply each LSFR data by 719 and discard 10 LSBs.
Finally add two zeros as extra LSBs (this means x4)
Wow. You couldn't come up with a more complex, resource intensive method?I suggest you use 9 bit LFSR. This will generate 1~511
then scale each value down to 359/511.
The scaling can be done as multiplication e.g.
359/511 = 0.7025 so pre-scale up by 2^10 to become round(0.7025*2^10) ~= 719
Now multiply each LSFR data by 719 and discard 10 LSBs.
Finally add two zeros as extra LSBs (this means x4)
You got absolute zero idea about this resource:Wow. You couldn't come up with a more complex, resource intensive method?
--- Updated ---
Wow. You couldn't come up with a more complex, resource intensive method?
--- Updated ---
Wow. You couldn't come up with a more complex, resource intensive method?
If you take the output of an LFSR and add two trailing zeroes, you’ll get what the OP needs. No need to multiply by 719. Maybe you should read what the OP actually asked for.You got absolute zero idea about this resource:
9 registers for LFSR
9 x 9 multiplier (for 719 scale value. )
The rest is bit discard, insert zeros.
no memory, no logic to reset LFSR if value exceeds limits
May be you misunderstood my calculations, it is meant precalculate for FPGA as scale factor 719
Read carefully the post and my suggestion. You need to be respectful to people not an arrogant dictator.
but he wants constrain the range to 1436, not more...If you take the output of an LFSR and add two trailing zeroes, you’ll get what the OP needs. No need to multiply by 719. Maybe you should read what the OP actually asked for.
Some attempt to implement itI suggest you use 9 bit LFSR. This will generate 1~511
then scale each value down to 359/511.
The scaling can be done as multiplication e.g.
359/511 = 0.7025 so pre-scale up by 2^10 to become round(0.7025*2^10) ~= 719
Now multiply each LSFR data by 719 and discard 10 LSBs.
Finally add two zeros as extra LSBs (this means x4)
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
entity offset_generator is
port(
clk : in STD_LOGIC;
reset : in STD_LOGIC;
seed : in STD_LOGIC_VECTOR(8 downto 0);
result : out STD_LOGIC_VECTOR(10 downto 0)
);
end offset_generator;
architecture offset_generator of offset_generator is
signal s_result : STD_LOGIC_VECTOR(10 downto 0) := (others => '0');
--type t_int_array is array(natural range 0 to 4) of natural range 0 to 1436;
--constant possible_values : t_int_array :=(4,8,12,16,1436);
signal s_lfsr : STD_LOGIC_VECTOR(8 downto 0) := (others => '1');
signal linear_feedback :std_logic;
signal s_temp : unsigned(17 downto 0);
begin
result <= s_result;
linear_feedback <= s_lfsr(8) xor s_lfsr(3);
process( clk )
begin
if (rising_edge(clk)) then
if (reset = '1') then
s_lfsr <= seed;
else
s_lfsr(8 downto 0) <= s_lfsr(7 downto 0) & linear_feedback;
s_temp <= unsigned(s_lfsr) * 719;
end if;
end if;
end process;
end offset_generator;
504 * 719 = 362376Some attempt to implement it
Code:library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; entity offset_generator is port( clk : in STD_LOGIC; reset : in STD_LOGIC; seed : in STD_LOGIC_VECTOR(8 downto 0); result : out STD_LOGIC_VECTOR(10 downto 0) ); end offset_generator; architecture offset_generator of offset_generator is signal s_result : STD_LOGIC_VECTOR(10 downto 0) := (others => '0'); --type t_int_array is array(natural range 0 to 4) of natural range 0 to 1436; --constant possible_values : t_int_array :=(4,8,12,16,1436); signal s_lfsr : STD_LOGIC_VECTOR(8 downto 0) := (others => '1'); signal linear_feedback :std_logic; signal s_temp : unsigned(17 downto 0); begin result <= s_result; linear_feedback <= s_lfsr(8) xor s_lfsr(3); process( clk ) begin if (rising_edge(clk)) then if (reset = '1') then s_lfsr <= seed; else s_lfsr(8 downto 0) <= s_lfsr(7 downto 0) & linear_feedback; s_temp <= unsigned(s_lfsr) * 719; end if; end if; end process; end offset_generator;
Here is quick simulation:
View attachment 194936
So let's take third output for example.
s_LFSR has value 0x1F8 (504)
s_temp is 0x19AC4 (105156)
It outputs some wrong numbers. In this case 504*719=362376 (0x58788)
That is true. LFSR of 9 bits generates pseudo numbers repeating every 511 values.Hi,
the problem with multiplication is that some numbers are preferred. In other words: you don´t get equal distribution.
Klaus
Added: and the random numbers are only "pseudo random". This means the order is always the same. It repeats.
Thus: you need to answer (yourself):
* is non equal distribution OK for your application
* is it OK if the order of the numbers repeat (equally)
In numbers: KAZ´s solution gives an equal row of 511 results (it repeats every 511 ticks)
Within these 511 results .. there are 359 different values. Thus 152 values with double occurance and 207 values with single occurance.
Klaus
Hi, it's ok if it will repeat since it's based on seed. Here is some information what I want to do:Hi,
the problem with multiplication is that some numbers are preferred. In other words: you don´t get equal distribution.
Klaus
Added: and the random numbers are only "pseudo random". This means the order is always the same. It repeats.
Thus: you need to answer (yourself):
* is non equal distribution OK for your application
* is it OK if the order of the numbers repeat (equally)
In numbers: KAZ´s solution gives an equal row of 511 results (it repeats every 511 ticks)
Within these 511 results .. there are 359 different values. Thus 152 values with double occurance and 207 values with single occurance.
Klaus
The seed just modifies the starting point ... but it does not modify the order.Hi, it's ok if it will repeat since it's based on seed.
if it is for "decrypting" for security reasons ... the given algorithm is not that secure. It is nthong better than having an 511 array with 359 different numbers. (some are double occurance)Board_1 is used for data permutation, and Board_2 is used for reverse permutation (Scramble/Descramble)
For first implementation it's ok to not have perfect distribution. And such low amount of possible values (360) is the limitation of algorithm for analog television (CVBS). There increasing steps for more complex permutation makes picture quality worse during descrambling.The seed just modifies the starting point ... but it does not modify the order.
if it is for "decrypting" for security reasons ... the given algorithm is not that secure. It is nthong better than having an 511 array with 359 different numbers. (some are double occurance)
Especially the double occurance makes it much harder to descramble, because you can´t know what the origin of this number is.
--> I recommend to use paper and pencil or excel or something else to verify whether your idea does work or not.
Klaus
Right now I generate two arrays[360] in java and then use them in fpga's. One array is for scrambling, other for descrambling. Idea itself works, image is scrambled and then descrambled with appropriate quality loose.I recommend to use paper and pencil or excel or something else to verify whether your idea does work or not.
My concern is the "double occurance". Did you focus on this ... with your test?Right now I generate two arrays[360] in java and then use them in fpga's. One array is for scrambling, other for descrambling. Idea itself works, image is scrambled and then descrambled with appropriate quality loose.
Have not yet tested double occurrence, but it should not have great impact I suppose.My concern is the "double occurance". Did you focus on this ... with your test?
Let´s say your genereated tabel looks like: {14, 22, 129, 8, 76, 14, 111, ...}
Mind the double occurance of {14}!
I don´t understand the term "quality lose" here. On a digial system there should be no quality loss at all.
Klaus
Yes, you are right. It's scrambling/descrambling and not proper encryption. But this is limitation of analog video. Stream cipher will require that transmitted data is the same on receiving end. But with analog it can not be guaranteed, since it will be also transmitted over air.strictly speaking, what you are achieving with your encryption is only a symbol substitution. this is hardly secure. there is a reason why we use standards in cryptography and not reinvent the wheel. Consider using a stream cipher, they can be lightweight.
your thread topic was generating random numbers ... using digital techniques, FPGA ... in so far the "loss of quality" is not related to the topic, and we don´t need to discuss ... we don´t even need to know about. (Still it might be another problem of your application). Correct me if I´m wrong.And this ADC/DAC conversions both with that BT.656 has format YCbCr 4:2:2 lead to loosing quality
Yes, generating numbers was original topic, but seems in discussion I had to provide more information about it.your thread topic was generating random numbers ... using digital techniques, FPGA ... in so far the "loss of quality" is not related to the topic, and we don´t need to discuss ... we don´t even need to know about. (Still it might be another problem of your application). Correct me if I´m wrong.
****
Back to the scrambling descrambling.
I understand the concept (at least in parts) .... but this is a pure digital part. The problem with your descrambler is, that you don´t get the same digital numbers than you scrambled. The signal flow is something like this.
input_data --> scrambled_data_Tx --> analog --> digital --> scrambled_data_Rx --> descrambler --> picture
If so, then you need to be aware that the scrambled_data_tx ... are not the same as scrambled_data_Rx
Mind: not because of loss of quality, but because of timing, phase shift, filtering, offset, noise, gain, nonlinearity.
So how is your concept to descramble the data stream on the Rx side?
Lets say you get unscrambled 123 ... then scramble it to 14 .. then transmit DA -> AD to 17 .... how do you get back the 123?
There will be small differences in the scrambled on the Rx side. Maybe +/- a couple of LSBs. .. because 17 now may be descrambled to 3 (rather far from 123)
***
I´m asking because I´m curious and have no idea how you solve it.
But if you are sure your concept can handle the problem ... then we don´t need to waste time to discuss it in detail.
Klaus
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?