@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? :)
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
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 :)
wow! I had no idea that DispalyPort would be that much more complex.
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
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
@reostat - I'm new to FPGA and appreciate sample code. thanks for sharing
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.
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
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 )
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 :)
I forgot how the code works
exactly my point )
@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
imo DVI on an HDMI connector is a perfectly fine solution
which is what we do atm
sxpert @sxpert has lots of SDI equipment ;)
@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
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.
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
@daveshah1 thanks for the clarification; I suppose I thought "icestorm" was the umbrella to describe all of the FPGA FOSS tools.
Well, the clue is in the name :)
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:
I think @emard has been using vhdl2vl to do automatic translation
It only works on simple VHDL though
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
Yes
Yosys only supports Verilog, and a small subset of SystemVerilog, but not VHDL
ok, thanks.
@daveshah1 yes, well - I guess not that simple:
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.
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:
@gojimmypi: the standard JTAG programming stuff only programs FPGA SRAM
So rebooting the board will "recover" it
@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)
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
ok, cool. thanks