Enabling Master SPI port persistence.
The configuration bitstream contains optional Master SPI persistence bits. When the device completes
configuration and wakes up, it checks the persistent bits to determine if the Master SPI port is to remain
operational once in User Mode. This selection is independent of the CFG pins setting. A port enabled by
persistence is a Background Mode port. It mainly used for background self re-configuration upon SED failure when user set SED auto correction.
That's in TN1260
and more about SED in this document: https://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/PT/SoftErrorDetectionSEDUsageGuide.ashx?document_id=32323
So if you don't use self reconfiguration (no idea how that might be useful,as a n00b I don't really understand this) you set it to DISABLE
If user design needs to access FLASH (from running bitstream), MASTER_SPI_PORT=DISABLE must be there. Such bitstream must be stopped before JTAG can access FLASH. If ENABLE'd, then bitstream can't access FLASH but JTAG can then R/W FLASH while bitstream is running (not need to stop bitstream). By default JTAG programmers first send JTAG commands to stop currenty running bitstream and then flash, in order not to confuse the user.
Or is it too much of a pain to implement?
@ironsteel Yes I have USB KBD example in both verilog and vhdl here https://github.com/emard/ulx3s-misc/tree/master/examples/usb/proj/lattice/ulx3s/usbhid_host
Having my USB core, most USB low-speed keyboards on US2 port will technically work without any problem, hotpluggable and reliable
use .C_report_length_strict(1), to filter out some noise which will occassionally be reported
.C_report_length(8) should be for all standard keybards
will poke around alittle bit and see if I can get it working
I have one keyboard that runs USB protocol well but doesn't report any key to my driver
ulx3s latest toolchain release => https://github.com/alpin3/ulx3s/releases/tag/v2020.08.02
Ups this is wireless USB, must search better example
Hello, I wanted to have a 90 degree shifted clock. I was trying out the ecp5pll from @emard. I get it running and the clock adjustment seems to work, but somehow it does not get shifted for me. Is this currently not working with yosys and so forth, is there anything I have to take care of, or might it just be a bug on my side? Tried to search this chat a bit and just searched a bit on the internet but the things I found about it were quite old and not necessarily about my problem. Any ideas? I am using the vhdl version btw
There's some order of signals and small delays between them for dynamic shifting to work. https://github.com/emard/ulx3s-misc/blob/master/examples/sdram/memtest_mister/hdl/top/top_memtest.v#L73 here is module to control phase shifts by pressing of BTN for testing of SDRAM with variable phase shift of the clock to chip
ecp5pll has possibility for fine-precision phase adjustment but this simple BTN module doesn't generate proper phaseloadreg signal https://github.com/emard/ulx3s-misc/blob/master/examples/sdram/memtest_mister/hdl/btn_ecp5pll_phase.v#L51
I have done a low power shutdown and wake-on-RTC clock example https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/micropython-mcp7940n with this e-ink display shows picture without power https://github.com/emard/ulx3s/blob/master/doc/MANUAL.md#e-inke-paper-display
I have taken some time off implementing computers from 1984 to look at GPUs, and any Verilog implementations that I could find. If I am ever to implement computers from the mid-nineties onwards, I need to understand 3D GPUs. I found this which is very interesting - https://github.com/jbush001/NyuziProcessor. It is a CPU that implements general-purpose GPU (GPGPU) single-instruction multiple-data (SIMD) code, and which can be used to implement rasterization, shading etc. in software. It comes with a C compiler and is a general-purpose language that has been used to implement a variant of Unix and Doom. I am not sure if it will fit on an 85f. It looks exactly what I was looking for in an open source GPU.
The author (Jeff Bush) has a blog on it as well - https://jbush001.github.io/, which has more interesting stuff on GPUs including a full description of the the Raspberry Pi one, and a reference to another verilog GPU implementation.
I also looked at Jeff Bush's other repositories and found that I had ported one previously to an ice40 board - his Lisp FPGA implementation.
I also found this interesting project, which I have ported to the ulx3s -https://github.com/lawrie/FPGAWhack. It is also a type of parallel processing GPU,. with a CPU and an assembler, but the source of data is effectively limited to the x, y co-ordinates of a pixel and a frame number. There is a compiler (in python) that lets you enter an expression involving x, y and f, which calculates the pixel color. It can be used to generate interesting graphical output. There is more detail here - https://github.com/jbush001/FPGAWhack/wiki
@lawrie HI lawrie, great GPU-vacation. 85F is large and rare project use it fully and compile time will rise significantly so a part of preparation could be getting a free login on some supercomputing cluster for yosys compilation. Here is DOOM for ULX3S and 1h compile time on normal PC https://twitter.com/sylefeb/status/1288053013748289538
@daveshah1 can yosys actually split its processing on parallel cluster to get any speedup?