Richard AplinI've got a bit carried away in the weeds with adding bells and whistles to my xilinx stuff (and it's broken right now) but I uploaded a .bit and .svf (use whichever your jtag supports), which zips some pixels along the top row of each scan. It's just a very rough thing from last week so you can see some pixels light up.
Programming this image won't affect your board; reset it and it's back to normal.
Note that on this image I used pin 7 on the input connector (that's the male connector on the left of the back, the top-left pin) as a chip reset, so jumper it to GND to make stuff work.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Richard, the whole purpose of the 12 bit space is to allow for a gamma ramp of the intensity values.
Are you sure? yes | no
well sure, it's great they used a 12-bit driver, I find 8 bits insufficient for LED modulation, I usually go for 10 to 12 myself depending on the required dynamic range (I used 16 bits on a 500W RGB driver I did) but in terms of the pixels you send to the NX4, I feel 8 bits is ample. In the xilinx stuff I'm playing with I use two 8-bit frame buffers, then upconvert to 12 bit via a lookup table before blending and global intensity control
Are you sure? yes | no
Gotcha. I've been using 10 in my designs. Upload that source :)
Are you sure? yes | no
Curiously, Barco claims the NX-4 system is capable of 16-bit colors. Not sure yet how they manage that, some magic with the grayscale input maybe.
Are you sure? yes | no
Maybe they're using the dot correction on top of the 12 bits?
Are you sure? yes | no
They could be using the dot correct for extra bits (although I'm not sure it works like that, the datasheet is a bit unclear, but you don't get any light output if the d.c. is set to zero). They could also be dithering the pixels; if the max TI driver clock rate is 20mhz and you have to load (16x3x6rows=288) pixels per frame (*12 bits=3456) then you can refresh the tile at 5.7khz; a 4-bit temporal dither on that would still give you 361fps so it sounds doable ... but I think it's more likely just marketing; 16bpp is an extremely high resolution for a small LED.
Are you sure? yes | no
Scratch my request - I'm up and running with verilog.
Are you sure? yes | no
I can confirm that this bitstream works, although mine displays on row 4... go figure. Also the first LED on each segment is stuck on red, is that an intentional feature?
Are you sure? yes | no
yeah that's how it's meant to to look, was just random testing :-) The row select is an odd one; mine displays on the second row of six but I imagine it's fairly arbitrary. Clearly the CPLD on the front PCB expects some sort of control sequence to step through the rows. It's odd they put that chip on there; I can't quite see what their thinking was, it doesn't seem necessary; I'd kinda expect just three control lines from the main FPGA (row select 0..7) or even just 6 discrete row select lines. hmm
Are you sure? yes | no
Upload the code :) I need a project to start with since I'm new at this Xilinx toolchain.
Are you sure? yes | no
btw the 8->12 bit conversion doesn't result in any meaningful loss of visual resolution; the eye's response means that much of the 12bit space isn't useful (looks the same) so I used the cie1931 curve to upconvert it.
Are you sure? yes | no
By 'carried away' I mean I've implemented dual framebuffer (so you can load one while displaying the other) with programmable fading between the two, SRAM and Flash controller, 8 bit -> 12 bit pixel conversion via a programmable lookup table, and in terms of host interfaces SPI interface and WS2812 emulation (UART, I2C etc coming). I'm still wrinking out various bugs, and I still haven't figured out the row mux select yet (!) but hey... Verilog is fun
Are you sure? yes | no