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?
you could in theory process submodules separately but you would get a less optimal result that way
FlexGripPlus is also very interesting, but VHDL : https://github.com/Jerc007/Open-GPGPU-FlexGrip-
@daveshah1 Recently I upgraded Yosys after a 6 month hiatus. My impression is that Yosys has slowed down a lot. The 6 mo's old Yosys took I think about 4 mins to compile a fx68K retro system, the current Yosys takes about 8. I can time exactly if that is helpful. Maybe some extra passes were added in the past 6 months? One of the attractions of Yosys (for me) is its fast turn-around as compared to the vendor tools. Would it make sense to have a "fast" mode for development of designs that do not need full optimization? I.e. a bit like compiling C without optimizations during development? Maybe I should direct this question to Clifford instead of you?
Maybe the analogy to C goes further. Back when C was developed, separate compilation of modules was one of its features, and the reason were the slow compilers (or the slow hardware if you like) of the time - standard Pascal at the time could only do whole program compilation. A related design point is the sqlite library. It has many source files, but for for ease of usage for distribution it is all combined into one big source file (the "amalgamation"). Somewhat to my surprise, compilers get more optimizations in the amalgamated source than in the separate source files. My point is: maybe a bit of inefficiency during development is acceptable for most designs and it accelerates the development cycle noticeably.
Sharing a small audio demo I made for ULX3S:
https://github.com/dan-rodrigues/ics-adpcm/tree/master/demo
It uses ULX3S to demo the ADPCM decoder / mixer core in the root of the repo. (thanks Emard for dacpwm.v)
https://github.com/dan-rodrigues/ics-adpcm/tree/master/demo
It uses ULX3S to demo the ADPCM decoder / mixer core in the root of the repo. (thanks Emard for dacpwm.v)
https://www.ebay.com/itm/PCM5102-I2S-Interface-DAC-Decoder-GY-PCM5102-I2S-Player-Module-for-Raspberry-Pi/183853870696?hash=item2ace8b6e68:g:C-gAAOSwYbZdCvX1 thanx for this demo! Besides SPDIF and HDMI, this i2s module for 5$ can also produce very clear sound and is directly pluggable to ulx3s
@emard I am trying to get back to TI-99/4A work with the ULX3S, i.e. looking to continue the SDRAM work sometime this week. Just checking if there's been some further work with SDRAM controllers to have a perhaps more recent starting point (I haven't read all the 100+ recent messages yet)
Thanks @emard , I was thinking of soldering headers to the board at some point to try a few peripherals like that
For HDMI audio I did see this repo, it is in SV but when I get a chance I'll try running it through sv2v and see if the output is workable with OSS toolchain:
https://github.com/hdl-util/hdmi
I would just try SPDIF but I don't think I have any equipment that accepts it
@Speccery I'd be glad to get 99/4A equipped with SDRAM for complete expandable space. @pnru_gitlab has made for QL https://github.com/lawrie/ulx3s_ql/blob/master/src/sdram.v the latest SDRAM controller. I suggest you try it first maybe it will just work or we can ask Paul for support :)
Thanks for sharing @drr I plan on doing some audio demos. Currently working in vhdl on ISE but want to port to fully open source ICE40 and Verilog (have an iCEBreaker and ULX3S on order). My demos will be streaming using a Python script running on the PC side using serial over USB communication with async.v on the FPGA (source from https://www.fpga4fun.com/SerialInterface.html). I really like the idea of using Icestudio to create my projects in a visual style. Do any of you guys use Icestudio?
I should also be ordering a MIDI Pmod at some point. Just waiting for @goran-mahovlic to get back to me when he's finished testing
ULX3S boards are packed and ready, I am just waiting for some papers from CrowdSupply
I was just checking out https://github.com/fpgawars/icestudio#supported-boards. Any chance of ULX3S support?
Ahh yes I should have looked at the source. All ULX3S boards are supported (https://github.com/FPGAwars/icestudio/tree/develop/app/resources/boards)
I'm pretty blown away by the team here. You guys seem to be adding support for everything under the sun. It's going to be an extremely versatile board with tonnes of tools and examples to play with