Works on ULX3S (Lattice ECP5)

[shreekumar3d]

Hi !

Filing this to report that I've been able to get this to work on the ULX3S board (based on Lattice ECP5, 12K gates).

Due to compile issues with the open source toolchain of the ULX3S, I ended up using Lattice Diamond...

Tested default settings - 640x480, and 48k stereo audio (externally driven). Had to make some changes to suit the ECP5 (in the serializer module). Also some changes for compilation.

Will be updating with more results & changes soon.

Thanks
-- Shree

[sameer]

Awesome!!! This is fantastic news 🎉

I would really appreciate it if you could make a pull request for or share those serializer changes. Hoping to support as many of the major platforms as possible.

[shreekumar3d]

Yes, will submit a PR after I cleanup a bit.

Looking at serializer.sv, can you tell me what the defines do ? The defines I see are ALTERA_RESERVED_QIS & MODEL_TECH. Is XILINX an implicit define is some way ?

For Lattice, I have used a platform specific primitive ODDRX1F. I'll want to add a define for this too.

[sameer]

XILINX an implicit define is some way ?

Sort of...I read on a Xilinx forum somewhere that the one way to distinguish Vivado is the presence of SYNTHESIS. ALTERA_RESERVED_QIS is for Quartus and MODEL_TECH is for test runs with modelsim. It's not perfect but it seems to work.

If there's a similar platform flag for Lattice, it could be another `else `ifdef PLATFORM section before the platform-less serializer. That way it targets only synthesis for Lattice.

[shreekumar3d]

Ok. Looks like Lattice Diamond also defines SYNTHESIS. So I get compile errors with the existing code.

I couldn't find if Lattice Diamond automatically sets up a specific flag to help distinguish it. Documentation is sparse & hard to find. Plus, I am new to FPGAs toolchains. Working through this.

Is ALTERA_RESERVED_QIS setup by vendor tools automatically ?

[sameer]

Is ALTERA_RESERVED_QIS setup by vendor tools automatically ?
Yes, that comes with Intel FPGA tooling as far as I've seen.

Ok. Looks like Lattice Diamond also defines SYNTHESIS.

Good find! If there's a Lattice specific flag, we could put that implementation above that one. So it gets picked instead of hitting the Xilinx implementation.

Plus, I am new to FPGAs toolchains

No worries, I am working with some very rough understanding too 🙂

I'll also try to look for a flag. Either that or maybe there is a Xilinx flag and SYNTHESIS can be used for Lattice

[sameer]

Hi @shreekumar3d ,

Would you be able to share the changes you made as a PR? We can build on top of it from there to support Lattice out of the box.

[shreekumar3d]

Hi @sameer - apologies for the long delay. I got busy with a few things & lost track of this. I will update this thread with the changes this weekend.

[sameer]

No worries!

[gamelaster]

It's been two years, but it would be possible to share your changes please @shreekumar3d ? Thanks!

[shreekumar3d]

It's been two years, but it would be possible to share your changes please @shreekumar3d ? Thanks!

Right. I wanted to cleanup the code and then submit a PR etc so that it merges clean - mostly was getting tripped in the defines . But then you know what happens when you end up in a lot of work. This just slipped off my list of things to do.

The important change was in the serializer module, IIRC. Something that works is good enough for now, right ?

[gamelaster]

@shreekumar3d anything that works will be very helpful, even if it's not cleaned up. Thank you 😊

[xolod79]

@gamelaster @sameer
Hello, I offer the support code for Lattice ECP5 chips. This requires integration into serializer.sv, but it works and has been tested by me at 832x600 resolution and 32 MHz pixel clock in Lattice Diamond 3.13 and Synplify Pro.
Code borrowed from https://github.com/BrunoLevy/learn-fpga/blob/master/Basic/ULX3S/ULX3S_hdmi/HDMI_test_DDR.v

serializer.sv

module serializer
#(
    parameter int NUM_CHANNELS = 3,
    parameter real VIDEO_RATE
)
(
    input logic clk_pixel,
    input logic clk_pixel_x5,
    input logic reset,
    input logic [9:0] tmds_internal [NUM_CHANNELS-1:0],
    output logic [2:0] tmds,
    output logic tmds_clock
);

 // Modulo-5 clock divider.
   reg [4:0] TMDS_mod5=1;
   wire      TMDS_shift_load = TMDS_mod5[4];
   always @(posedge clk_pixel_x5) TMDS_mod5 <= {TMDS_mod5[3:0],TMDS_mod5[4]};
   
   // Shifters
   // Every 5 clocks, we get a fresh R,G,B triplet from the TMDS encoders,
   // else we shift.
   reg [9:0] TMDS_shift_R=0, TMDS_shift_G=0, TMDS_shift_B=0;
   always @(posedge clk_pixel_x5) begin
      TMDS_shift_R <= TMDS_shift_load ? tmds_internal[2] : {2'b00,TMDS_shift_R[9:2]};
      TMDS_shift_G <= TMDS_shift_load ? tmds_internal[1] : {2'b00,TMDS_shift_G[9:2]};
      TMDS_shift_B <= TMDS_shift_load ? tmds_internal[0] : {2'b00,TMDS_shift_B[9:2]};	
   end

   // DDR serializers: they send D0 at the rising edge and D1 at the falling edge.
 ODDRX1F ddr_R (.D0(TMDS_shift_R[0]), .D1(TMDS_shift_R[1]), .Q(tmds[2]), .SCLK(clk_pixel_x5), .RST(1'b0));
 ODDRX1F ddr_G (.D0(TMDS_shift_G[0]), .D1(TMDS_shift_G[1]), .Q(tmds[1]), .SCLK(clk_pixel_x5), .RST(1'b0));
 ODDRX1F ddr_B (.D0(TMDS_shift_B[0]), .D1(TMDS_shift_B[1]), .Q(tmds[0]), .SCLK(clk_pixel_x5), .RST(1'b0));

// The pixel clock, still the same as before.
assign tmds_clock = clk_pixel;

// Note (again): tmds[3:0] is generated automatically by LVCMOS33D mode in ulx3s.lpf

endmodule

[sameer]

Hi, thank you for sharing this! I'll make sure it gets merged in