These are chat archives for ulx3s/Lobby

14th
Feb 2019
Oleg Stepanov
@reostat
Feb 14 2019 00:05 UTC
@gojimmypi new README looks quite comprehensive to me, kudos!
@daveshah1 so you can use HDMI connectors, cables, exact signalling standards etc free of charge for as long as you call it anything but HDMI? :)
emard
@emard
Feb 14 2019 00:18 UTC
HI I will check readme regarding how to get rid from zadig and back. As "gornjas" is maintainer of ujprog, I can't directly accept the patches so I recommend you first stabilize your fork of ujprog and we will pick it up as it stabilizes. Current main issue is 3Mbit is not working on windows, on linux it works
emard
@emard
Feb 14 2019 00:24 UTC
Regarding HDMI-DisplayPort. I tried to make it work 2 times on artix-7 board equipped with proper interface but it wont. The core of HDMI is simple and works like VGA. Even if it works, the core of DisplayPort will gobble up most of your 12K LUT for the same thing HDMI ups sh*t yes I wanna say GPDI would do in 100-500 LUT :)
gojimmypi
@gojimmypi
Feb 14 2019 00:27 UTC
wow! I had no idea that DispalyPort would be that much more complex.
emard
@emard
Feb 14 2019 00:32 UTC
It really is, see it's HUGE and currently doesn't work. If it works it should show white picture. To make useful picture, even more core parts must be added! see https://github.com/emard/FPGA_DisplayPort I tried it 2 times on 2 esa11 full featured boards (artix-7 100k LUT great board, made of most expensive parts on the market) but no picture on displayport monitor :( for me
Oleg Stepanov
@reostat
Feb 14 2019 03:46 UTC
if anybody new to FPGA (as myself) would be interested, here's my take on implementing an FSM as an instruction set in BRAM. Looks a bit cleaner compared to non-BRAM version (imho) and saves whopping 37 LUTs in exchange for 1 BRAM cell :D
gojimmypi
@gojimmypi
Feb 14 2019 04:08 UTC
@reostat - I'm new to FPGA and appreciate sample code. thanks for sharing
Oleg Stepanov
@reostat
Feb 14 2019 06:13 UTC

now if I could plug into the brains of @emard, @daveshah1 and other more experienced FPGA guys, here's my question. with SSD1331 I'm pretty much shifting bytes into SPI, thus what I need is a PISO (parallel in, serial out) shift register, right? my requirements are:

  • 8 bit input width
  • if there's more than 1 byte to shift into SPI, CS line should remain pulled low without interruption between the bytes. That is, shifting 16 bit word via 8-bit register should look no different from shifting it through 16 -bit register from the SPI's point of view

here's how I do it now. it does the trick yet it looks clumsy and I feel there should be a more elegant (and generic) solution for such a common problem. please point me to the right direction.

emard
@emard
Feb 14 2019 09:17 UTC
hmm well here's my hacky approach to this, I made a binary-to hex decoder from this oled ssd1331. Wire any 512 bits and you will see hex representation on display. It's vhdl, feel free to port to verilog :) https://github.com/emard/fpga_spi_oled
Oleg Stepanov
@reostat
Feb 14 2019 09:54 UTC
I saw this one while looking for examples on this exact problem. sadly my VHDL is even worse than my Verilog. and frankly, this particular piece of code is a mess ;)
... please pardon me for being brutally honest )
emard
@emard
Feb 14 2019 11:17 UTC
Yes know it's hacky&messy but it synthesizes to small LUT and it works :). If you report me a bug now, I would'nt be able to fix because I forgot how the code works :)
Oleg Stepanov
@reostat
Feb 14 2019 11:55 UTC

I forgot how the code works

exactly my point )

sxpert
@sxpert
Feb 14 2019 15:09 UTC
@daveshah1 most of the patenting is linked to the useless DRM they try to force upon us...
@daveshah1 in fact, given the choice between HDMI and SDI, I'd take SDI any time
that would require a -5G part though, but still it's much simpler than displayport
David Shah
@daveshah1
Feb 14 2019 15:14 UTC
imo DVI on an HDMI connector is a perfectly fine solution
which is what we do atm
sxpert @sxpert has lots of SDI equipment ;)
gojimmypi
@gojimmypi
Feb 14 2019 21:46 UTC
@emard is this the pass-thru app that was likely used on my ULX3S before shipping it to me?
I ran make in /ulx3s-passthru/proj/ulx3s-v2.0-12f
then started receiving a ton of "find ... permission denied" errors as the script decided to search beyond my WSL Ubuntu, so I stopped it.
and sure enough, there
is a fairly aggressive search for diamond
image.png
Is there a requirement for me to have Lattice Diamond installed? The free version? Are there icestorm tools available? As I'm a newbie, now sure if migration from Diamond to icestorm is something I want to experiment with on the only ULX3S board I have.
David Shah
@daveshah1
Feb 14 2019 21:53 UTC
The free Diamond is fine for the ULX3S, although from experience it can take a day or two for your account to be approved
The open source flow for the ECP5 is not icestorm but Yosys, nextpnr and Trellis
There is no realistic chance of irreparable damage to the ULX3S in any case
gojimmypi
@gojimmypi
Feb 14 2019 22:02 UTC
@daveshah1 thanks for the clarification; I suppose I thought "icestorm" was the umbrella to describe all of the FPGA FOSS tools.
David Shah
@daveshah1
Feb 14 2019 22:03 UTC
Well, the clue is in the name :)
gojimmypi
@gojimmypi
Feb 14 2019 22:06 UTC
LOL - yes, I suppose so :)
so here's a newbie question:
can I use Yosys, nexpnr. Trellis for VHDL?
this does not look like Verilog:
David Shah
@daveshah1
Feb 14 2019 22:09 UTC
I think @emard has been using vhdl2vl to do automatic translation
It only works on simple VHDL though
gojimmypi
@gojimmypi
Feb 14 2019 22:11 UTC
ah. I'll check that out. I'd think the passthru app should be fairly simple...
so I assume the answer is "no": the toolchain is for only Verilog
David Shah
@daveshah1
Feb 14 2019 22:11 UTC
Yes
Yosys only supports Verilog, and a small subset of SystemVerilog, but not VHDL
gojimmypi
@gojimmypi
Feb 14 2019 22:12 UTC
ok, thanks.
gojimmypi
@gojimmypi
Feb 14 2019 22:54 UTC
@daveshah1 yes, well - I guess not that simple:
image.png
emard
@emard
Feb 14 2019 23:08 UTC
I guess the ulx3s-passthru bitstream is by default shipped to you, when you have OLED and ESP32 in box then it makes sense to load the board with passthru. Other boards without OLED and/or ESP32 are probably shipped with f32c with FAT filesystem on config flash to run self-test application at power up. You can erase config flash and ESP32 with whatever you want and flash back to "factory default" from my ulx3s-bin repository. ULX3S is unbrickable.
passthru is old source and it needs updated makefile like in prjtrellis-dvi. Yes it tries to find diamond. Passthru is very simple and it could be ported done using opensource tools only. I'm using vhd2vl. For most simple vhdl examples it works great. It can't convert if VHDL source is complex/advanced and has functions and packages.
gojimmypi
@gojimmypi
Feb 14 2019 23:14 UTC
The "unbrickable" is encouraging... however I also want to ensure I'm actually equipped to recover from any mishaps ;)
is this the binary for passthru:
David Shah
@daveshah1
Feb 14 2019 23:16 UTC
@gojimmypi: the standard JTAG programming stuff only programs FPGA SRAM
So rebooting the board will "recover" it
gojimmypi
@gojimmypi
Feb 14 2019 23:20 UTC
@daveshah1 - that's a good to know; but how can I tell if any of the uploaders are also (instead?) writing to FPGA SRAM? (thanks for answering such noob questions)
David Shah
@daveshah1
Feb 14 2019 23:21 UTC
In general you have to go through a fairly tedious process involving Diamond Deployment Tool to create a SVF file to program flash, and this will be very slow
Otherwise, you are just programming SRAM
gojimmypi
@gojimmypi
Feb 14 2019 23:21 UTC
ok, cool. thanks