Page 8 of 8

Posted: Tue Jan 17, 2012 9:02 pm
by ElEctric_EyE
fachat wrote:
...You cannot say from such an observation if the pseudo-random noise is "noisy enough" unless you a) specify your concrete requirements and b) do a proper statistical analysis.

André
A proper statistical analysis I am not prepared to do... However, what I can do is a power-up of the TFT without doing a CLRSCR and truly see a randomness based on Quantum Mechanics of the powerup threshold of transistors inside the SRAM which is part the TFT ASIC. I know the SSD1963 controller has such an embedded SRAM for the video buffer.
I'll try a few more close up comparison pics before the end of today, but more likely tomorrow.

Also, there are some variables I could change in the code, but as it is now the 16-bit pattern will not repeat until after 2,147,483,647bits/16. For a TFT requiring 800x480x3=1,152,000 bytes to fill up a screen, there should be no repeating patterns...
I have DATA_OUT feeding DATA_IN and the cpu.:

Code: Select all

//------------------------------------------------------------------------------
//    File Name:  PRBS_ANY.v
//      Version:  1.0 
//         Date:  6-jul-10
//------------------------------------------------------------------------------
//
//      Company:  Xilinx, Inc.
//  Contributor:  Daniele Riccardi, Paolo Novellini
// 
//   Disclaimer:  XILINX IS PROVIDING THIS DESIGN, CODE, OR
//                INFORMATION "AS IS" SOLELY FOR USE IN DEVELOPING
//                PROGRAMS AND SOLUTIONS FOR XILINX DEVICES.  BY
//                PROVIDING THIS DESIGN, CODE, OR INFORMATION AS
//                ONE POSSIBLE IMPLEMENTATION OF THIS FEATURE,
//                APPLICATION OR STANDARD, XILINX IS MAKING NO
//                REPRESENTATION THAT THIS IMPLEMENTATION IS FREE
//                FROM ANY CLAIMS OF INFRINGEMENT, AND YOU ARE
//                RESPONSIBLE FOR OBTAINING ANY RIGHTS YOU MAY
//                REQUIRE FOR YOUR IMPLEMENTATION.  XILINX
//                EXPRESSLY DISCLAIMS ANY WARRANTY WHATSOEVER WITH
//                RESPECT TO THE ADEQUACY OF THE IMPLEMENTATION,
//                INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR
//                REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE
//                FROM CLAIMS OF INFRINGEMENT, IMPLIED WARRANTIES
//                OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
//                PURPOSE.
//
//                (c) Copyright 2010 Xilinx, Inc.
//                All rights reserved.
//
//--------------------------------------------------------------------------
// DESCRIPTION
//--------------------------------------------------------------------------
//   This module generates or check a PRBS pattern. The following table shows how  
//   to set the PARAMETERS for compliance to ITU-T Recommendation O.150 Section 5.
//    
//   When the CHK_MODE is "false", it uses a  LFSR strucure to generate the
//   PRBS pattern.
//   When the CHK_MODE is "true", the incoming data are loaded into prbs registers
//   and compared with the locally generated PRBS 
// 
//--------------------------------------------------------------------------
// PARAMETERS 
//--------------------------------------------------------------------------
//   CHK_MODE     : true =>  check mode
//                  false => generate mode
//   INV_PATTERN  : true : invert prbs pattern
//                     in "generate mode" the generated prbs is inverted bit-wise at outputs
//                     in "check mode" the input data are inverted before processing
//   POLY_LENGHT  : length of the polynomial (= number of shift register stages)
//   POLY_TAP     : intermediate stage that is xor-ed with the last stage to generate to next prbs bit 
//   NBITS        : bus size of DATA_IN and DATA_OUT
//
//--------------------------------------------------------------------------
// NOTES
//--------------------------------------------------------------------------
//
//
//   Set paramaters to the following values for a ITU-T compliant PRBS
//------------------------------------------------------------------------------
// POLY_LENGHT POLY_TAP INV_PATTERN  || nbr of   bit seq.   max 0      feedback   
//                                   || stages    length  sequence      stages  
//------------------------------------------------------------------------------ 
//     7          6       false      ||    7         127      6 ni        6, 7   (*)
//     9          5       false      ||    9         511      8 ni        5, 9   
//    11          9       false      ||   11        2047     10 ni        9,11   
//    15         14       true       ||   15       32767     15 i        14,15   
//    20          3       false      ||   20     1048575     19 ni        3,20   
//    23         18       true       ||   23     8388607     23 i        18,23   
//    29         27       true       ||   29   536870911     29 i        27,29   
//    31         28       true       ||   31  2147483647     31 i        28,31   
//
// i=inverted, ni= non-inverted
// (*) non standard
//----------------------------------------------------------------------------
//
// In the generated parallel PRBS, LSB is the first generated bit, for example
//         if the PRBS serial stream is : 000001111011... then
//         the generated PRBS with a parallelism of 3 bit becomes:
//            data_out(2) = 0  1  1  1 ... 
//            data_out(1) = 0  0  1  1 ...  
//            data_out(0) = 0  0  1  0 ... 
// In the received parallel PRBS, LSB is oldest bit received
//
// RESET pin is not needed for power-on reset : all registers are properly inizialized 
// in the source code.
// 
//------------------------------------------------------------------------------
// PINS DESCRIPTION 
//------------------------------------------------------------------------------
//
//      RST          : in : syncronous reset active high
//      CLK          : in : system clock
//      DATA_IN      : in : inject error (in generate mode)
//                          data to be checked (in check mode)
//      EN           : in : enable/pause pattern generation/check
//      DATA_OUT     : out: generated prbs pattern (in generate mode)
//                          error found (in check mode)
//
//-------------------------------------------------------------------------------------------------
// History:
//      Version    : 1.0
//      Date       : 6-jul-10
//      Author     : Daniele Riccardi
//      Description: First release
//-------------------------------------------------------------------------------------------------
// no timescale needed

module PRBS_ANY(RST, CLK, DATA_IN, EN, DATA_OUT);

  //--------------------------------------------		
  // Configuration parameters
  //--------------------------------------------		
   parameter CHK_MODE = 0;
   parameter INV_PATTERN = 0;
   parameter POLY_LENGHT = 31;
   parameter POLY_TAP = 3;
   parameter NBITS = 16;

  //--------------------------------------------		
  // Input/Outputs
  //--------------------------------------------		

   input RST;
   input CLK;
   input [NBITS - 1:0] DATA_IN;
   input EN;
   output reg [NBITS - 1:0] DATA_OUT = {NBITS{1'b1}};;

  //--------------------------------------------		
  // Internal variables
  //--------------------------------------------		

   wire [1:POLY_LENGHT] prbs[NBITS:0];
   wire [NBITS - 1:0] data_in_i;
   wire [NBITS - 1:0] prbs_xor_a;
   wire [NBITS - 1:0] prbs_xor_b;
   wire [NBITS:1] prbs_msb;
   reg  [1:POLY_LENGHT]prbs_reg = {(POLY_LENGHT){1'b1}};

  //--------------------------------------------		
  // Implementation
  //--------------------------------------------		

   assign data_in_i = INV_PATTERN == 0 ? DATA_IN : ( ~DATA_IN);
   assign prbs[0] = prbs_reg; 
   
   genvar I;
   generate for (I=0; I<NBITS; I=I+1) begin : g1
      assign prbs_xor_a[I] = prbs[I][POLY_TAP] ^ prbs[I][POLY_LENGHT];
      assign prbs_xor_b[I] = prbs_xor_a[I] ^ data_in_i[I];
      assign prbs_msb[I+1] = CHK_MODE == 0 ? prbs_xor_a[I]  :  data_in_i[I];  
      assign prbs[I+1] = {prbs_msb[I+1] , prbs[I][1:POLY_LENGHT-1]};
   end
   endgenerate

   always @(posedge CLK) begin
      if(RST == 1'b 1) begin
         prbs_reg <= {POLY_LENGHT{1'b1}};
         DATA_OUT <= {NBITS{1'b1}};
      end
      else if(EN == 1'b 1) begin
         DATA_OUT <= prbs_xor_b;
         prbs_reg <= prbs[NBITS];
      end
  end

endmodule

Posted: Wed Jan 18, 2012 12:41 pm
by ElEctric_EyE
This first pic is the "natural" randomness after powerup (10 min's no prior power). They're large pics but detail is needed here.
Image

This is after plotting pseudo random LSB only:
Image

Posted: Tue Feb 07, 2012 4:37 pm
by ElEctric_EyE
My work in trying to port HESMON has been put on the backburner. dclxvi(Bruce) has been very generous in his time to create a very Compact monitor for the 65Org16, that can display memory contents, store values in multiple consecutive memory locations, and go(run) a program/subroutine. This is basically all I wanted to do with HESMON.

At this point, it allows me the freedom to experiment with I/O registers more easily than having to re-program the FPGA for some very simple tests involving different I/O cores (testing I2C core from opencores.org).

Currently, I have successfully modifed C'mon to display 2 ascii characters per 16bit memory location. I am currently working on some registers within C'mon to change the number memory locations the memory dump routine spits out horizontally and vertically to accomodate different character sizes. In the future I will need to add a memory Paint command, as well as Save and Load commands. Also a Quit command, once I get my OS a little more in order, so I can enter and exit C'mon.

Posted: Wed Feb 08, 2012 8:29 pm
by fachat
Just a short analysis - the two pictures you posted are clearly different in their statistical properties. Just open them with gimp, look at Tools -> Color Tools -> Curves

While both pictures have all similar red and green curves (number of occurrences per color value), one has blue similar to the other colors, but the other picture has much less blue, about half of it.

Besides, the color occurrence curves look like Gaussian distributions, but the maximum is different. So in one of the pictures, the maximum of red pixels is shifted to darker red values, while the Gaussian distribution of the blue value curves is wider than the green ones (with approx. same maximum).

Nothing against using them. Just depends on your definition of "good enough".

(Just my $0.02 - but now I'll keep it at that :-)
André

Posted: Wed Feb 08, 2012 9:38 pm
by ElEctric_EyE
Andre, Thanks for your 2 cents!

Keep in mind I am only plotting the LSB of the pseudo-random 16bit number.

There is one reason I like this method and 1 reason I dislike this method. I like this method ,represented in Verilog, because it is simple and pure digital however it is a repeating function which I dislike, no matter how long the function lasts.

In V1.2 I will investigate a digitized analog noise source, and how much real estate this will take. I have read 1 diode, some cap's/res's and a comparator. More research is needed...

Re: Software for the 65Org16.x (formerly 6502 SoC Project)

Posted: Sat May 12, 2012 1:08 am
by ElEctric_EyE
...So Feb 8th 2012, was my last post on this thread. Much time has lapsed because I'd decided to pursue the .b core and to learn to 'hack' enough of Verilog in order to modify BigEd's modification of Arlet's core. I wish I could say I have learned some Verilog....
Honestly though, I can say I've learned some syntax in the language. Also, I have learned FPGA internals are nothing more than Flip-Flops and Multiplexers.

The .b core has been finalized here, and I've made many macro's to support the opcode additions.

I've already used the 65C02 PUSH/PULL opcodes and the variable barrel <shift> opcodes successfully.

Next, I would like to modify the assembly of the PLTCHR routine to take advantage of the 15 additional accumulators, and use them instead of using zeropage blockRAM as much as possible...

Re: Software for the 65Org16.x (formerly 6502 SoC Project)

Posted: Tue May 29, 2012 1:48 pm
by ElEctric_EyE
I found and corrected some bit pattern errors in opcodes ADC/SBC/AND/ORA/EOR. All addressing modes of these opcodes can have 1of16 accumulator source and 1of16 destination, i.e. 256 opcodes per addressing mode per instruction. So far in my macro's, I've defined all of them for immediate and zero page addressing modes. I came across the errors while trying to figure out why the new PLTCHR routine was not working. Still testing, but I thought I should post an update on the macros (on Github) just in case anyone was trying to do simulations with them.

Re: Software for the 65Org16.x (formerly 6502 SoC Project)

Posted: Wed May 30, 2012 11:42 am
by ElEctric_EyE
Instead of running certain macros through ISim, I thought it was best to just run the whole PLTCHR routine through, now modified for the .b core (1st step). The routine modifies the A acc only once by ORing the incoming ascii value with an ATTBUT register, modifying the upper 9 bits for choice of font, size, color, and plot enable. The B accumulator is used when further modification of the A accumulator is needed, like ANDing off bits to get certain values, etc. The C accumulator is used as well.
My brain feels like and old rusty machine working with assembly after so much board design, then dabbling with verilog and finally troubleshooting stuff!

There is a mod I have my eyes on, another modification for V1.2 of the board when the time comes. I found out in the newhavendisplay forums, that a 32-pin connector can be soldered to the existing pads labelled CON2 on the 800x480 TFT board and make use of a 16-bit interface. That way instead of sending 3 bytes per pixel, I could send a single 16-bit word in 5-6-5 (R-G-B) format for greater speed. For the software, it will mean some odd numbered shifting I think.

Back to the simulations!

Re: Software for the 65Org16.x (formerly 6502 SoC Project)

Posted: Wed May 30, 2012 6:50 pm
by ElEctric_EyE
Alright got it working! Found some 'artifacts' from some of my careless editing after copying and pasting for new macros that resulted in wrong values for some of the STA[A..Q] opcodes in some of the addressing modes. Updated Github. I could see in the simulations WE was not going high...

Also, I found about 3 errors in my assembly.

I am satisfied now this .b core has been tested in a more complicated real world scenario and no problems were found in the verilog code for the .b core. However, there is one issue I noticed in the past and again noticed more recently in simulations regarding NOP. I believe it must be removed from the load_reg section as it seems to interfere with some register values.

Now it is time to solder in the SDRAM and add Arlet's video & SDRAM controller modules.