FPGA VGA Controller for 8-bit computer

[nockieboy]

Okay, I'm trying to add audio but I'm clearly not understanding how to do it.  I'm trying to get a sawtooth waveform sent out to the HDMI audio.  This is the source I'm working from:

Code: [Select]

module sawtooth
#(
    parameter int BIT_WIDTH = 16,
    parameter int SAMPLE_RATE = 48000,
    parameter int WAVE_RATE = 480
)
(
    input logic clk_audio,
    output logic signed [BIT_WIDTH-1:0] level = BIT_WIDTH'(0)
);

localparam int NUM_PCM_STEPS = (BIT_WIDTH + 1)'(2)**(BIT_WIDTH + 1)'(BIT_WIDTH) - 1;
localparam real FREQUENCY_RATIO = real'(WAVE_RATE) / real'(SAMPLE_RATE);
localparam bit [BIT_WIDTH-1:0] INCREMENT = BIT_WIDTH'(NUM_PCM_STEPS * FREQUENCY_RATIO);

always @(posedge clk_audio)
    level <= level + INCREMENT;
endmodule
And this is how I've integrated it into top.sv:

Code: [Select]

module top (

input  logic       clk_pixel,
input  logic       clk_audio,

output logic [3:0] tmds
);

parameter int AUDIO_BIT_WIDTH = 16 ;
parameter int SAMPLE_RATE = 48000  ;
parameter int WAVE_RATE = 480      ;

parameter BIT_WIDTH   = 12 ;
parameter BIT_HEIGHT  = 11 ;
parameter FONT_WIDTH  = 8  ;
parameter FONT_HEIGHT = 16 ;

localparam int  NUM_PCM_STEPS = (AUDIO_BIT_WIDTH + 1)'(2)**(AUDIO_BIT_WIDTH + 1)'(AUDIO_BIT_WIDTH) - 1;
localparam real FREQUENCY_RATIO = real'(WAVE_RATE) / real'(SAMPLE_RATE);
localparam bit  [AUDIO_BIT_WIDTH-1:0] INCREMENT = AUDIO_BIT_WIDTH'(NUM_PCM_STEPS * FREQUENCY_RATIO);

logic [15:0] audio_sample_word [1:0] = '{ 16'sd0, 16'sd0 } ;
logic signed [AUDIO_BIT_WIDTH-1:0] level ;

always @(posedge clk_audio) begin

  audio_sample_word <= '{ level + 16'sd1, level - 16'sd1 } ;
  level <= level + INCREMENT;
 
end
I think the issue is with setting audio_sample_word - don't think I'm doing it right.

[asmi]

BTW, your 24hz mode is format id #32, however, if a monitor wont do the basic #34, it probably wont do #32.  Also, the pixel clock frequency is wrong.  In the  CEA-861-D specs, it should be either 74.25Mhz for 24hz, or, 74.188MHz for telecin 23.98Hz.  There is no 74.16Mhz standard.  Do not get your tech information from Wiki please...

Did you miss the part where I said "it works with my monitor"?
And that is not a standard wiki either.

[asmi]

I think the issue is with setting audio_sample_word - don't think I'm doing it right.

I noticed you generate audio signal using different clock from the one used for serialization - are you sure there are provisions inside your HDMI component for proper CDC?
There are great many audio formats, but standard PCM uses unsigned format with middle values being zero, so for 16 bit samples 0x7fff/0x8000 is zero, 0xffff - maximal positive value, 0 - minimal negative value.

16'sd1

What is this?

[BrianHG]

I think the issue is with setting audio_sample_word - don't think I'm doing it right.

I noticed you generate audio signal using different clock from the one used for serialization - are you sure there are provisions inside your HDMI component for proper CDC?
There are great many audio formats, but standard PCM uses unsigned format with middle values being zero, so for 16 bit samples 0x7fff/0x8000 is zero, 0xffff - maximal positive value, 0 - minimal negative value.

16'sd1

What is this?

The author of the original code used 16'sd1 which means assigning a 16bit signed decimal value of 1.  I guess he did it this way since when he defined the 'logic'  he did not know he could have stated 'logic signed'...

[BrianHG]

Original author code for mute audio:

Code: [Select]

logic [15:0] audio_sample_word [1:0] = '{ 16'sd0, 16'sd0 } ;

always @(posedge clk_audio) begin

  audio_sample_word <= '{ audio_sample_word[0] + 16'sd1, audio_sample_word[1] - 16'sd1 } ;
 
end
Get rid of:
audio_sample_word <= '{ audio_sample_word[0] + 16'sd1, audio_sample_word[1] - 16'sd1 } ;

just add these 2 lines:
audio_sample_word[0] <= audio_sample_word[0] + INCREMENT;
audio_sample_word[1] <= audio_sample_word[1] + INCREMENT;

And change:
logic [15:0] audio_sample_word [1:0] = '{ 16'sd0, 16'sd0 } ;
to:
logic signed [15:0] audio_sample_word [1:0] = '{ 16'sd0, 16'sd0 } ;

This should make a buzz.

Code: [Select]

logic signed [15:0] audio_sample_word [1:0] = '{ 16'sd0, 16'sd0 } ;

always @(posedge clk_audio) begin

audio_sample_word[0] <= audio_sample_word[0] + INCREMENT;
audio_sample_word[1] <= audio_sample_word[1] + INCREMENT;
 
end


[nockieboy]

Nope - still not getting any sound.  I've attached my test project as I'm not convinced it isn't something I've done.  I've got to tap out for tonight now, but will continue to plug at this during the week.

[BrianHG]

Nope - still not getting any sound.  I've attached my test project as I'm not convinced it isn't something I've done.  I've got to tap out for tonight now, but will continue to plug at this during the week.

Test 1, go to the 'audio_clock_regeneration_packet.sv', line 41/42 and replace 41 disabling 42.
Then undo the above localparam change.  Though Quartus 9.1 doesn't like the 'real', the newer ones do.
Let me know if this works.  If it does, I think I will re-write the line properly getting rid of that annoying 'real' as some versions of Quartus don't like multiplying by tiny fractions in the middle of everything.

I do not like how Quartus's parameter handles the 'real' term as it cannot be used in the same way as Q9.1.

I do not like the newer Quartus relying on Modelsim to simulate your design.  Modelsim is a great tool for simulating code, however, it does not reflect any mistakes/differences Quartus' compiler may make when it compiles the same code and it does not do proper timing simulations down to the FPGA fabric like the old Q9.1 with the older FPGAs.    The old simulator simulated the actual final compiled fabric giving a dead on output, not a gate level simulation with timing approximation by a third party simulation tool.

(Also, the code you sent me no longer has the patches for 1080p @ 30Hz)

[BrianHG]

Here you go.
Try to erase all the other old projects as they differ in revisions.
And I cleaned up some of the stuff.

[nockieboy]

Here you go.
Try to erase all the other old projects as they differ in revisions.
And I cleaned up some of the stuff.

All good - 480p output with audio tone. 

[BrianHG]

Ok, it's that " real' " in the localparam in the audio section.  I'm going to fix it so that the " real' " isn't needed.

Do a test for 720p.
Remember that we lie to the 'altlvds_tx', but you will find that out quick.
Make the PLL as close to 74.25MHz otuput as possible.
Recompute the needed video frame rate.
Remember, 720p is not 60fps exactly, I have listed the proper output frame rates and you need to calculate the error/change so the audio scheduler can send the right number of packets.

[BrianHG]

Give this V2 a test.
Still 480p.  No 'real' used anywhere in the localparams.
If it works, try it at 720p.
Then, get onto a new master CV video card with the first most important DDR3 interface.

[nockieboy]

Give this V2 a test.
Still 480p.  No 'real' used anywhere in the localparams.
If it works, try it at 720p.
Then, get onto a new master CV video card with the first most important DDR3 interface.

Works nicely - also in 720p.  Have attached the project running in 720p mode as I've added a couple of parameters to top.sv, so that the screen mode can be changed from the schematic page and PLL without having to go into top.sv to change code/values within.

[BrianHG]

Ok, let's see a DDR3 controller.
Remember to use the CV in the project, except use a -7 as we will slightly overclock the -8.
Remember, we will want to enable ODT (On Die Termination) in the DDR3 chip.
Also, 2 or 3 ram ports would be nice.

We also know the minimum allowed clock frequency for the DDR3 is 303MHz & you will have a source oscillator clock of 27MHz.  Though many large fractional divisions are possible, smaller whole numbers are preferred.  2 targets for the ram controller would be 27*12=324MHz.  This should just make it as 303MHz was guaranteed by Intel with any CV chip.  Funny how all speed grade versions of the CV, -8, -7, -6 all have the same limit, yest with the IO speed and LVDS, all 3 increase in speed according to the data sheet.  Intel's speed grades are BS.  Somehow their DDR3 controller bypasses the IO's limitations on the -8 chip.

[BrianHG]

Get cracking on the DDR3...
You got maybe 2-3 months left to get your new PCB built and functioning enough to begin working on your own...

[BrianHG]

Though this hasn't altered our current project's functionality, this patch for the 'audio_clock_regeneration_packet.sv' > 'real < workaround fixes a rounding error with the multiply of 1.1 so that it works exactly how the original author intended.

New lines 42 & 43.

Code: [Select]

// This parameter works around the >'real < bug in Quartus versions prior to Quartus v12.
localparam int CYCLE_TIME_STAMP_COUNTER_WIDTH = $clog2(20'(int'((VIDEO_RATE * int'(N) / 128 / (AUDIO_RATE/1.1)) ))); // Account for 10% deviation in audio clock

Please update all your source files.

[BrianHG]

Ok, here is the latest HDMI encoder with audio support.
This version has uses the Altera's altlvds_tx serializer & has the following parameters:

Code: [Select]

    // Set to 1 to activate the external clk_pixel_x5 input.
    // Set to 0 to automatically internally generate a PLL for the TMDS TXD clock.
    // Using 0 will usually use an additional PLL if Quartus cannot merge the required clock with an existing external PLL.
    parameter bit  USE_EXT_PLLx5 = 1'b1 ;

    // Tells the ALTLVDS_TX serializer what the approximate source pixel clock is.  Only needs to be within 1 MHz.
    // Only used when USE_EXT_PLLx5 is disabled.
    // You may lie here and state your pixel clock is only 74MHz or 64MHz allowing compile for -7/-8 Cyclone FPGAs
    // while still truly running a 74.25MHz pixel clock, 742.5mbps when using either LVDS or emulated LVDS_E_3R IO standard.
    parameter int PIXEL_MHZ = 27,

    // Invert the TMDS channels, 0 thru 2, and 3 for the clock channel.
    // IE - Swaps the +&- pins of the LVDS output pins for ease of PCB routing.
    parameter bit INV_TMDS0 = 1'b0,
    parameter bit INV_TMDS1 = 1'b0,
    parameter bit INV_TMDS2 = 1'b0,
    parameter bit INV_TMDS3 = 1'b0,


The changes were done in the original GitHub's 'hdmi.sv' and saved as a new source file 'hdmi_altlvds.sv'.
Video mode #34, 1080p@29.97Hz, 74.25MHz pixel clock  was added to the supported video mode list.
Also, a pure sine wave 1KHz test audio tone was added with the generator source code 'Sine_1KHz_16b_48ksps.sv'.

Nockieboy, Please let me know if this works.

If good, there are 2 other changes I want to add after looking into getting a DDR3 controller going.
1.  An improved audio sample input section which doesn't rely on a 48KHz PLL output which causes clock domain problems between the pixel clock and audio clock.
2.  Make this generator able to in-system software switch between all the video modes & have the PLLs automatically re-configure.

Download the attached project.

[nockieboy]

Works perfectly. 

[nockieboy]

Don't suppose I could ask for a quick bit of help with this Verilog, please?

What I'm trying to do is create an array of bytes which the module sends via an SPI module.  Worked fine with a parameter array set in the block schematic.  But now I'm trying to make the array more flexible, so I can set the values of the bytes and the number of bytes to transmit whilst the HDL is running.  Now I'm hitting a block - it's probably because I don't understand the arrays well enough.

I'm trying to copy the parameter array init_cmds into the cmd_queue during reset, so the module can pass those bytes out to the SPI tx module when it comes out of reset.  Problem is, it's not working and I'm likely just getting garbage transmitted.  I've tried simulating (using Quartus II, not Modelsim), but can't seem to get the cmd_queue register to appear in the simulation as it's probably getting compiled out or something.  Not getting any errors on compile, though.

The key lines (I think) are these (taken out of context):

parameter int max_cmds                 = 32                ; // maximum command_queue length
parameter int num_init_cmds            = 2                 ; // no. of initial commands in queue  **** this is actually 12, set in the Block Schematic
parameter int init_cmds[num_init_cmds] = '{ 8'h00, 8'h00 } ;    **** again, this has 12 bytes set in the Block Schematic

logic [7:0] cmd_queue[max_cmds] ;
logic       num_queue  = 0      ;

cmd_queue[0:(num_init_cmds - 1)] <= init_cmds[0:(num_init_cmds - 1)] ;
num_queue   <= num_init_cmds ;

tx_data  <= cmd_queue[cur_cmd] ;

Full code below:

Code: [Select]

/*
 * Simple USB interface control module to test the MAX3421E USB chip
 *
 * J.Nock 2021
 */

module control (

   input logic        clk,
   input logic        reset,     // active LOW
   input logic        gpx,
   input logic        m_int,
   input logic  [7:0] rx_data,
   input logic        done,
   input logic        KEY1,      // user buttons, active LOW
   input logic        KEY2,
   input logic        KEY3,
   input logic        KEY4,
   
   output logic       start,
   output logic [7:0] tx_data,
   
   output logic [7:0] LED_1,     // EasyFPGA-specific 7-segment display to
   output logic [7:0] LED_2,     // show read values from SPI
   output logic       LED_3      // USB connection detection LED

);

parameter int max_cmds                 = 32                ; // maximum command_queue length
parameter int num_init_cmds            = 2                 ; // no. of initial commands in queue
parameter int init_cmds[num_init_cmds] = '{ 8'h00, 8'h00 } ;

logic [7:0] rx_buff1   = 8'b0   ;
logic [7:0] rx_buff2   = 8'b0   ;
logic [3:0] cur_cmd    = 0      ; // current command in pipeline (max 16)
logic       old_done   = 1'b0   ; // edge-detect for done signal
logic       tx_done    = 1'b0   ; // tx_done flag so commands is only sent once
logic       buff_swtch = 1'b0   ; // when buff_swtch is HIGH, record Rx'd data (this ignores data Rx'd during CMD transmission)

logic       old_int    = 1'b0   ;
logic [7:0] cmd_queue[max_cmds] ;
logic       num_queue  = 0      ;
logic       int_req    = 1'b0   ;
logic       conn_LED   = 1'b1   ; // LOW to light LED for connection events

wire        int_edge   = ( !old_int && m_int ) ; // int_req goes HIGH on posedge of m_int

always @( posedge clk ) begin

   LED_1   <= rx_buff1 ;
   LED_2   <= rx_buff2 ;
   LED_3   <= conn_LED ;
   old_int <= m_int    ; // update m_int edge detector
   
   if ( int_edge ) begin // interrupt posedge detected
   
      //int_req <= 1'b1 ; // set int_req flag
     
   end
   
   if ( !KEY1 || !reset || !gpx ) begin
     
      cmd_queue[0:(num_init_cmds - 1)] <= init_cmds[0:(num_init_cmds - 1)] ;
      num_queue   <= num_init_cmds ;
      old_done    <= 1'b0  ;
      rx_buff1    <= 8'b0  ;
      rx_buff2    <= 8'b0  ;
      cur_cmd     <= 3'b0  ;
      tx_done     <= 1'b0  ;
      tx_data     <= 8'b0  ;
      start       <= 1'b0  ;
     
   end
   else if ( int_req && tx_done ) begin // MAX3421E is requested our attention and we're not transmitting on SPI
   
      int_req <= 1'b0 ; // reset int_req flag
     
      /* TODO:
       * 1) Read R25
       * 2) Check bits we want to action (b5 initially for CONDETIRQ)
       * 3) Update an LED on the dev board
       */
     
      conn_LED <= !conn_LED ; // Switch on/off the LED to show an event was detected
     
      // 4) Write a 1 to b5 in R25 to ack the int
      /*cmd_queue[0] <= 202   ; // Write to R25
      cmd_queue[1] <= 32    ; // Set b5 (CONDETIRQ) to 1 to reset it
      num_queue    <= 2     ; // 2 commands in the queue
      cur_cmd      <= 3'b0  ;
      tx_done     <= 1'b0  ;*/
   
   end
   else begin // reset & gpx HIGH
      // Buffer RX'd data if done goes HIGH,
      // otherwise keep old_done LOW
      if ( old_done && !done ) begin // negedge detected for done signal
         
         if ( buff_swtch ) begin
         
            rx_buff1 <= rx_data  ; // buffer the received data
            rx_buff2 <= rx_buff1 ;
           
         end
         old_done   <= 1'b0        ;
         buff_swtch <= !buff_swtch ;
         
         if ( cur_cmd < num_queue ) begin
           
            tx_done <= 1'b0 ; // reset tx_done to send next byte
           
         end
         else begin // EOL
           
            tx_data  <= 8'b0 ; // end of transmission - last byte sent
            tx_done  <= 1'b1 ; // one-shot stays high to prevent more bytes being
            cur_cmd  <= 3'b0 ; // transmitted but everything else is reset
            start    <= 1'b0 ;
           
         end
         
      end
      else begin
         
         old_done  <= done    ;
         
      end
     
      if ( !tx_done && ( cur_cmd < num_queue ) ) begin // if cmd hasn't been sent already and cmd isn't 0
         
         tx_data  <= cmd_queue[cur_cmd] ;
         start    <= 1'b1               ;
         tx_done  <= 1'b1               ;
         cur_cmd  <= cur_cmd + 1'b1     ;
         
      end
      else if ( !tx_done && ( cur_cmd == num_queue ) ) begin // reached end of commands array
         
         tx_data  <= 8'b0 ;
         start    <= 1'b0 ;
         cur_cmd  <= 3'b0 ;
         
      end
      else begin
         
         start    <= 1'b0   ; // make start a one-clk pulse
         
      end
   
   end // reset & gpx high
   
end

endmodule


EDIT: No matter, fixed it by referring back to our HW_REGS code in the GPU project.

[BrianHG]

Here is the latest version of Geo_ellipse.
Finally, everything is 100% Systemverilog with an authentic fully featured Modelsim testbench.

Good with Quartus 13 & up.  Just open the project and do a 'Start Analisys and Synthesis', then run simulation tool 'RTL simulation'.  Everything should startup automatically.  Or, you can manually add the files to your own Modelsim project.

This testbench has been setup for RTL simulation only.

From within Modelsim, to reset the simulation, quick re-compile and rerun the simulation type/run script:
do ../../ellipse_rerun_rtl.do

The text file 'ellipse_commands_in.txt' contains the simulation drawing coordinates.
The format is as follows:
Filled <0,1>, Quadrant<0,1,2,3>, Xcenter<signed#>, Ycenter<signed#>, Xradius<unsigned#>, Yradius<unsigned#>

The testbench will run as many commands you list in in the .txt file.
After simulation, all the generated ellipse's coordinates will be stored in:
ellipse_generated_results.txt
as well as full logic waveform in the wave display.

Be gentle, this is my first semi-extravagant use of a testbench file & modelsim.

@Nockieboy, I found a few harmless coding issued in the original source 'ellipse_generator.sv' which I patched.  You might as well update the main GPU with this new file.

(Update coming in next post.  Stand-alone Model-sim project, Don't need to run Quartus, just Modelsim.)

[BrianHG]

Ok, here is the stand-alone Modelsim Ellipse Generator project.

Code: [Select]

* To setup simulation,Start Modelsim, The goto 'File - Change Directory' and select this files directory.
 * Then, for altera users, in the transcript, type:
 * do setup_altera.do
 *
 * For non-altera users, just type:  (This one is fine for altera users as well.)
 * do setup.do
 *
 * To run the simulation, (also does a quick recompile) type:
 * do run.do

No Quartus needed.

File 'ellipse_commands_in.txt' contains the draw commands.  Instructions inside the file.
Yes, the test bench reads and extracts commands from an ascii test file and renders the results by injecting the commands while simulating the HDL.  The 'do run.do' recompiles any changes in any of the source files and runs again.  After the sim has stopped, manually injecting commands will work, but those commands will no longer be added to the output files.  Breaking/stopping a simulation early during the run & changing core registers, then continuing will effect the output files during that run.

Generated file 1 'ellipse_generated_results.txt' has a table of the rendered coordinates from the rendered commands inputs.

Generated file 2 'ellipse_generated_bitmap.bmp' has a picture of the rendered ellipse command inputs.
(Yes, you are reading right, I got Modelsim rendering a raster .bmp picture file directly from a simulation.)

For Xilinx or generic modelsim users who might want to try, this should work with any vendor's modelsim.  Instead of executing the 'do setup_altera.do', just execute 'do setup.do' as this project doesn't use any altera dedicated functions.  Once setup, the 'do run.do' will still setup and run the simulation properly.

Let me know if the bitmap show properly.

[BrianHG]

Next, simulation of the full Geometry unit with a text script file describing the commands by name.

-Wave output on the simulator.
-Text out log file of the command being executed with ns position on the wave, pixel xy coord out, color, pixel address out, ect as a spreadsheet.
-Second text file with the pixel memory writer's access read and write operations.
-Import of ram and font file from existing GPU so that we can simulate blitter texting and transparency functions.
-Incremental additional commands in the middle of the simulation without restarting.
-and finally a bitmap picture rendered after each new added command to see what's going on.

With this, who needs a Z80 or GPU PCB...

[BrianHG]

Ok, I cleaned up and finalized the HDMI encoder with a new automatic PLL generator module.
Everything is documented here: https://www.eevblog.com/forum/fpga/hdmi-dvi-encoder-with-audio-smart-quartus-pll-integration-in-systemverilog/msg3430622/#msg3430622

[nockieboy]

Latest Cyclone V GPU schematics attached.  Have had a little time to go through them and update the video output to the current DVI/HDMI output and removed the VGA out to make some space on the PCB for the USB interface, which I'm still working on (slowly!)

I haven't connected up the DVI/HDMI to the FPGA yet, as I haven't really got much of an idea where I'll be connecting the DDR3 to, so I suspect there may be some alterations required to the existing connections without adding more until that's finalised.

Particular attention is needed on the last page and power supplies - I'm starting to think about connections between the SDRAM and the FPGA and I suspect I need to connect up some termination resistors somewhere, somehow?  Also, the DDR3 needs a reference voltage - how would be best to supply this?  Will it mean another power supply on the board?

[asmi]

Particular attention is needed on the last page and power supplies - I'm starting to think about connections between the SDRAM and the FPGA and I suspect I need to connect up some termination resistors somewhere, somehow? 

As a rule of thumb, you only need dedicated termination if your traces are "electrically long", which means the length is a significant fraction of wavelength ("the magic number" is 10-15%). For 400 MHz, wavelength is 60 cm, so you will need to worry about termination if your traces are longer than 60-90 mm. Practically this means that if you only use a single DDR3 memory device and it's physically close to FPGA, your traces will most likely be shorter than that.
That said, you've got to treat these rules of thumb for what they are, and as such if in doubt I normally run board level simulations to figure out if I need termination, and if so, what is the best value for it. Even if you won't have any termination for address/control lines, you still should have differential termination for the clock line (typically it's a 100 Ohm resistor between + and - traces) as close to the receiver pins (memory device) as possible. I always use a 0402 resistor which is placed under memory chip right next to breakout vias which go to the top layer to the clock balls. This way I minimize the stub length.
What makes or breaks DDR3 interface is a layout. Here are few rules that need to be observed:
1. adjacent traces are at least 2H away from each other (where H - distance between a trace and a reference plane), and at least 1H in breakout regions (under BGAs as typically there is not enough space for 2H spacing).
2. reference plane(s) MUST be contiguous and should not have any cutouts under all DDR3-related traces. Again, this is not always possible under BGA, but do your best to satisfy this. Breaks in reference plane leads to BIG impedance discontinuity of traces (~50 Ohm to 80-90 Ohm) and causes signal reflections.
3. Clock lines have to be the longest traces among all DDR3 traces. See attached picture ("borrowed" from IMX6 datasheet) for all length matching rules. If the datasheet/user guide/application note for your FPGA calls for different tolerances, you them instead of what I posted.
4. Each additional transition between signal layers causes impedance breaks too, so minimize layer changes for data traces. Try your best to limit them to a single via on each end (in breakout regions of memory device and FPGA).

Also, the DDR3 needs a reference voltage - how would be best to supply this?  Will it mean another power supply on the board?

There are devices designed specifically for this task - for example TPS51200. But in your case you can likely get away using a simple resistive divider - two 1K resistors with parallel 10nF filter caps, as well as a single 1uF decoupling cap between a midrail and the ground. At least that's how I've been doing it, and so far all my DDR2/3/3L interfaces always worked from the first revision. Just make sure this midrail is away from noisy traces.

[BrianHG]

Hi Nockieboy,

     I engineered a nice complete SystemVerilog test-bench scripting & now a BMP saver which can support any resolution.  It's now wired up to the ellipse generator and operates on decoding any commands in the source script ascii file.  This is 3/4 the work necessary to running/driving a simulation of your entire geometry unit's processing as all the leg work of decoding commands and calling tasks to drive the inputs can now be added.

    I placed the ellipse standalone version here to take a look at:

https://www.eevblog.com/forum/fpga/systemverilog-example-testbench-which-saves-a-bmp-picture-and-executes-a-script/msg3436876/#msg3436876

    Please let me know if the script setup is adequate before I paste in the full geometry unit.