spritetm / hadbadge2019_fpgasoc

FPGA SoC code and application example for Hackaday Supercon 2019 badge

Hackaday Supercon 2019 Badge: Gateware & 'OS' & SDK

Note

If you see anything wrong or missing, either here in the documentation or in the gateware or software, do not hesitate to file an issue, or even better, change it and file a push request.

Intro

This project contains the FPGA configurations for the badge, in the form of a SoC containing the processors and all peripherals. It also contains the software responsible for bootup and app selection and loading (boot and IPL) as well as the SDK you can use to create new apps.

Community

If you are hacking on the badge hardware, gateware or software. You can find fellow hackers in multiple places. Ask questions and share your projects in those channels.

• Hackaday.io Supercon 2019 Chat
• 1BitSquared Discord #supercon-fpga-badge channel
• Hackaday.io Hackaday Supercon 2019 Badge page

If you know of any other FPGA badge related communities and resources please add them here

How to use

In order to use this repository, aside from the badge itself, you'll need a toolchain compiled for your OS:

• Linux
• MacOSX
• Windows
• Docker image

You will also need a Micro-USB cable to connect to the badge, as well as 2 AA's (or another way to supply it with power, e.g. using the JTAG connector) to power it. Note that while the badge has a JTAG connector, using this should not be necessary in normal use, even if you want to change the FPGA load. An 3.3V USB-to-serial cable or board may be useful, the JTAG connector (J1, on the back of the badge) carries serial debug signals that allows you to use e.g. gdb in case of a crash.

After you have a toolchain, you'll need to set up this SDK. Clone this repository and grab the submodules, if you haven't already:

git clone --recursive https://github.com/Spritetm/hadbadge2019_fpgasoc
cd hadbadge2019_fpgasoc

From here, you can start hacking:

• You can just use the hardware and start your new design from scratch.
• You can modify the existing SoC to incorporate your own peripherals.
• Modifying the IPL is useful if you want to change the look of the menu or add extra features there.
• Finally, if you are happy with the existing hardware, you can write an app to make use of it.

Repo directory structure

• blink contains a trivial blinker project, useful to make sure your setup works.

• apps-sdk contains the SDK you can use to build apps that can be loaded by the IPL.

• app-helloworld contains a bare-bones test application that the IPL is able to load and execute.

• app-basic contains a Basic interpreter that can be used to run .bas files.

• app-audiodemo

• app-invaders

• app-flappy

• app-midi

• Other app-* directories contain example projects.

• soc contains the actual SoC that is the main FPGA load.

The soc folder at this point is a bit of a mess: it contains most of the 'base' Verilog code, as well as code for simulation of parts using Icarus, or the entirety using Verilator. Apart from this, the contents of the directories are:

• jtagload is a nearly-trivial program to convert a binary executable file into a svf file that can then be sent to the FPGA using OpenOCD. At the moment, the boot ROM only invokes a mode compatible with this when it doesn't find a proper IPL in flash.

• boot contains the bootloader, to be embedded in bram in the FPGA image. At the moment, it tests the SPI memory (takes a few seconds), then initializes the flash and loads the IPL from there. If it doesn't see a valid IPL, it waits for an app to be uploaded over JTAG.

• ipl contains the Initial Program Loader, aka IPL. The IPL mostly contains driver code, to be called through a syscall jump table at the beginning of the binary. It also has logic to load an initial program, and to use USB to set up the internal flash as a mass storage device so an attached PC can access it directly. It also contains a flash translation layer as well as a fatfs driver, so you can also access the files dropped by the PC programmatically. Finally, it contains the menu you see when the badge starts up, that allows you to select an app to run.

• hdmi contains all Verilog for the hdmi output.

• picorv32 is a submodule containing the PicoRV32 RiscV core.

• qpi_cache is the cache for and interface to the external SPI PSRAM.

• video contains the renderer and sequencing logic for the framebuffer.

• pic contains a PIC16F84 core which is intended to drive the attached LEDs.

• usb contains an USB device core.

• audio contains the audio subsystem.

hadbadge2019_fpgasoc's Issues

Unable to compile app-helloworld

When typing make from the app-helloworld folder I'm hit with the inability to find gcc (although this is in my path so not sure why):
make: /riscv32-unknown-elf-gcc: Command not found

Adding this line into the apps-sdk/sdk.mk file gets the make process running for a bit:
RISCV_TOOLCHAIN_PATH := /opt/riscv/bin

But then I run into a linker error:

/opt/riscv/lib/gcc/riscv32-unknown-elf/9.2.0/../../../../riscv32-unknown-elf/bin/ld: build//apps-sdk/gloss//crt0.o: in function `.L0 ':
/home/mike/compile/hadbadge2019_fpgasoc/apps-sdk/gloss/crt0.S:20: multiple definition of `_start'; /home/mike/compile/hadbadge2019_fpgasoc/app-helloworld/build/apps-sdk/gloss/crt0.o:/home/mike/compile/hadbadge2019_fpgasoc/apps-sdk/gloss/crt0.S:20: first defined here
collect2: error: ld returned 1 exit status
../apps-sdk/sdk.mk:111: recipe for target 'helloworld.elf' failed
make: *** [helloworld.elf] Error 1

Any idea where I'm going wrong?

home for docs: Windows Ten Minute Setup Guide

I wrote a quick setup guide for Windows.

https://gist.github.com/alanvgreen/daff0777002aa9f31e79b3e47bad6e71

Where's the right place for this? I don't think there's a straight forward way to send a pull request for the project's wiki pages.

Add HDMI encoder that does audio

For instance https://github.com/charcole/NeoGeoHDMI has support for audio, we can see if we can use that, or at least the audio islet generator. That should give a more HiFi sound.

no doom makefile

verilator doesn't operate clk24

I'm looking at integrating new bits into the SOC, so I want to check they work.
My design uses the 24 and 48 mhz clock, but only the 48 and 96 mhz clock is supplied by verilator.
Is there a reason for this?

Windows RiscV development Example Issue.

I am admittedly green with RiscV so perhaps I am overlooking something relatively basic, but I am having trouble trying to follow this basic walk-through in the docs: https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/master/doc/toolchain-win.md

I have modified my main.c file and it seems to have compiled fine using the make command as far as I can tell. I copied the resulting .elf file to the board and I do see it show up in the main menu list.

I modified main.c as directed in the doc changing the "Hello World!" string value.

The issue comes when I run the app on the board. The app does launch and seem to run without crashing, but on the screen I am still seeing "Hello World!" as the text on the screen. As far as I can tell my edits to the main.c file are having no effect. The app continues to look exactly like it does when I run the un-modified hello world app.

Are there any steps required that have been left out of the doc page linked above that I may be missing which could cause my app to essentially ignore my changes to the "Hello World!" String

README how-to links 404

The Linux/Mac/Windows links appears to all be 404 in the How to use section of the README.md

IPL elf loader doesn't handle __constructor__ or __destructor__ attributes

I tried to use the attribute((constructor)) to force my sin table init code to run before main(), but alas, the elf loader doesn't seem to process those. I might fix this, filing so I remember to look into this.

frame buffer problem causes horizontal line problems at specific y positions

Expected behaviour

drawing a horizontal line by setting pixels in the frame buffer should result in a single pixel wide line on the display.

Resulting behaviour

• Drawing a line at y = 2 works as expected
• Drawing a line at y = 3 results in 2 short lines with a pixel space between them
• Drawing a line at y = 4 results in 2 px wide line in some places
• Drawing a line at y = 5 works as expected
  

To reproduce

• Clone https://github.com/mattvenn/had-badge-draw-app/tree/linetest
• make and copy to badge
• button up draws a 200 pix horizontal line at y = 2
• button right draws at y = 3 (with glitches as described above)
• button down draws at y = 4 (with glitches as above)
• button left draws at y = 5 which works as expected

Need sprite/tile priority

At this moment, sprites are always drawn as the top layer, that is, over everything else. It would be nice if this was selectable, so we can have e.g. the player character go behind something drawn on a tile layer.

PCM click fix causes violation of 48 MHz constraint

With the changes in #118, making the soc/ errors with:

ERROR: Max frequency for clock                  '$glbnet$clk48m': 46.22 MHz (FAIL at 48.00 MHz)

Get 2nd CPU to work

There's a 2nd, fully functional RiscV CPU in the SoC. At the moment, it's not really usable as the software does not support it.

• Create code to take it out of reset and have it jump to a start routine, with a stack that makes sense
• Implement spinlocks. Either in hardware or using Peterson's algorithm
• Hook up newlib lock functions, especially __malloc_lock and friends, to spinlock
• Create cross-CPU interrupts

IPL: USB doesn't come back up after running app

Possibly because apps don't poll USB by default. Perhaps we should disconnect and reconnect running app, or find some way to guarantee USB stays alive?

App-allocated interrupts keep firing after app returns

We should kill all interrupts that the IPL does not use and reset their handlers to the default, or run the risk of either the IPL or the next executed app crashing because an interrupt vector points nowhere.

Pmod Connector Labels Reversed

Small issue... The schematic has the pinout for the Pmod wrong. A surprising claim for the sloppiest standard I've ever seen.

Slop not withstanding, everything's very consistent on one point: Pin 1 is on the opposite end from the supply lines, and the numbering is as if two 6-pin Pmods are sitting next to each other.

PMOD	Function
1	Pmod.1
2	Pmod.2
3	Pmod.3
4	Pmod.4
5	GND
6	VCC
7	Pmod.7
8	Pmod.8
9	Pmod.9
10	Pmod.10
11	GND
12	VCC

This excerpt from the LPF file shows the correct way, I think.

LOCATE COMP "pmod[0]" SITE "B13" ;#a1
LOCATE COMP "pmod[1]" SITE "A13" ;#a2
LOCATE COMP "pmod[2]" SITE "C15" ;#a3
LOCATE COMP "pmod[3]" SITE "B15" ;#a4
LOCATE COMP "pmod[4]" SITE "D16" ;#b1
LOCATE COMP "pmod[5]" SITE "A14" ;#b2
LOCATE COMP "pmod[6]" SITE "C16" ;#b3
LOCATE COMP "pmod[7]" SITE "A15" ;#b4
# These Pmod assignments are incorrect
# LOCATE COMP "pmod[0]" SITE "A15" ;#a1
# LOCATE COMP "pmod[1]" SITE "C16" ;#a2
# LOCATE COMP "pmod[2]" SITE "A14" ;#a3
# LOCATE COMP "pmod[3]" SITE "D16" ;#a4
# LOCATE COMP "pmod[4]" SITE "B15" ;#b1
# LOCATE COMP "pmod[5]" SITE "C15" ;#b2
# LOCATE COMP "pmod[6]" SITE "A13" ;#b3
# LOCATE COMP "pmod[7]" SITE "B13" ;#b4

DFU support

See https://github.com/smunaut/had2019-playground/tree/master/projects/bootloader for the actual bootloader code.

Also would need to add Runtime DFU descriptors to the IPL and a way to reboot into the bootloader.
Since I would configure the bootloader to auto-boot the app, we would need a way to tell the bootloader the user requested it. I think putting a specific value at a given address in PSRAM would do. (Boot loader will also not auto-boot if a button is pressed but I'd like the auto-reboot to DFU from Runtime to work).

License

What is the feeling about putting a GPLv3 license on thadbadge2019_fpgasoc?

My interest in having a license is that my employer, while supportive of open source contributions, has processes that are much simpler for me to follow if the repository has a an OSI approved license. I'm guessing that some supercon attendees will be in a similar situation.

IANAL but, looking through the source I see a wide range of licenses, including GPLv2 and LGPLv3 licensed code, so it looks like GPLv3 would be appropriate.

I'm happy to send a patch adding a license notice.

Workarounds required for tinyprog on Ubuntu 18.04

I'm running Mint 19 which is effectively Ubuntu 18.04. I have tinyprog working fine on this system on my laptop, but my desktop doesn't want to play nicely with tinyprog. I get the following error despite being in the dialout group and having permissions:
[Errno 16] could not open port /dev/ttyACM0: [Errno 16] Device or resource busy: '/dev/ttyACM0'

After much mucking about I believe I've found a workaround. Here's the workflow I followed:

Install tinyprog

1. Clone the badge repository: git clone https://github.com/Spritetm/hadbadge2019_fpgasoc.git --recursive
2. cd hadbadge2019_fpgasoc/TinyFPGA-Bootloader/programmer/
3. sudo python3 setup.py install

Use workaround if necessary

If you get the Device or resource busy error when doing a make flash try this and then run the flash command again:
sudo systemctl stop ModemManager.service

Not sure why this fixes it , I found it here: https://discourse.tinyfpga.com/t/new-tinyprog-problems-under-ubuntu/1148

Ndjdb

Make a branch for Supercon 2019 snapshot

Please create a branch that will maintain a snapshot of the project at the end of Supercon 2019 weekend. Call it "Supercon 2019" or maybe "Version 1.0".

Then we can continue working in the main branch with updates such as:

• Fix problems that are breaking changes, such as #126
• Update had19_prod.lpf to include entries deliberately missing. (Supercon RGB LED challenge.)
• Etc...

soc verilator very slow

The soc verilator executable is now too slow to test riscv executables that manipulate the display.

I believe that change that caused the reduced speed is the new 96MHz PSRAM controller. (Hooray for faster memory!)

If there's any amount of effort involved, verilator probably isn't worth fixing, but raising as issue in case there's a quick fix possible.

Add backlight control

• Add PWM thing for backlight to SoC
• Add control method to IPL

Need toolchain and compilation instructions

I've put together the steps I've used sucessfully here:
https://gist.github.com/szczys/f4ec190bfe5ceaf851ca03e4f9090393

Not working on one of my machines is the tinyprog. It seem the pip3 repo install method should work but so far I get a device or resource busy on ttyACM0 that I haven't been able to work out yet.

I'll keep working on it but wanted to open this issue in case anyone else was also snooping around on this topic.

Unable to flash helloworld app

With the closing of #7 I can successfully compile the helloworld app into an .elf file. With the most up-to-date SoC and IPL the badge comes to life and it mounts as mass storage. I have copied the elf file over to it, but I'm not sure how to then flash (run?) the app. The file is persistent between power cycles, but it doesn't seem to actually run on the badge.

Gfx: Sprites use pal entry 0x100 as transparent instead of 0x1FF

need to look into why this is, also change helloworld/flappy/... when this is fixed

Video glitches, mostly sprites

Need to figure out:

• Sprites: when enabled (and possibly scaled), they mess up the first column of the LCD. Possibly related: when scaling sprites, there's sometimes extra crap drawn on the left side.
• Gfx subsystem in general: sometimes the screen is drawn a bit lower for one frame. Possibly some interaction between the frame buffer DMA reader and the rest of the gfx hardware? If any, if DMA doesn't return framebuffer bytes, the GFX hardware stalls. (Unless the FB layer is disabled... hmmm, can test that.)

Possible issue with clock on U18

It is hard to gauge the severity of this, but Lattice is pretty adamant that clocks entering the FPGA fabric really ought to do so via a clock pin. Their Diamond tools won't even permit a design where the clock comes in on a general port.

The ECP5 and ECP5-5G device has dedicated pins, called PCLK pins, to bring an external clock source into the FPGA and allow them to be used as FPGA primary clocks. These inputs route directly to the Primary clock net- work, or to Edge clock routing resources. A dedicated PCLK clock pin must always be used to route an external clock source to FPGA logic and I/O.

If an external input clock is being sourced to a PLL, then in most cases the input clock should use a dedicated PLL input pin. SERDES reference clocks also have dedicated SERDES reference clock pins. The ECP5 and ECP5-5G device allows a PLL reference clock or a SERDES reference clock to come from an external Primary Clock (PCLK) pin and route through the Primary clock network to drive the reference clock to the SERDES or the input of a PLL.
--TN1263 - ECP5 and EXP5G PLL/DLL Design and Usage Guide
-- https://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/EH/TN1263.ashx?document_id=50465

This is also covered in a Lattice FAQ entitled "Why must I use a Primary Clock Input for a clock instead of a general purpose pin?"

Lattice recommends always using Primary Clock (PCLK) inputs for clocks. An exception is when a clock input is routed directly to a single PLL then a dedicated PLL input should be used. If multiple PLLs are using the same input clock then a PCLK Input should be used and preferenced with a "USE PRIMARY ". This will route the clock to all PLLs while keeping the clock on Primary clock routing.
...Lattice does not characterize general routing for clocks and over Process / Voltage / Temperature there can be a huge percentage of variation in jitter, duty cycle distortion, and delay in these clocks.
-- http://www.latticesemi.com/en/Support/AnswerDatabase/2/4/7/2475

It looks like the clock signal enters the board on a non-clock pin, U18. This may be the cause of some clock problems. Switching the clock to L18, for example, (currently an LED) which is such a clock pin satisfies the requirement and permits Diamond to proceed.

soc svf upload failed

After running make then make prog in the soc folder, got the following error:

Error: tdo check error at line 31012
Error:     READ = 0x0001e00
Error:     WANT = 0x0000100
Error:     MASK = 0x0002100

Time used: 2m56s701ms 
svf file programmed failed

Any ideas? @Spritetm ?

Thanks!

error: conflicting types for 'GFXSPRITES'

Previously, GFXSPRITES was manually declared in each main.c. Commit 251348f added a declaration to apps-sdk/sdk.h so the manual declaration now triggers a compiler error.

Will generate pull request removing the (now) duplicate declarations.

     CC main.c
/home/roger/coding/hadbadge2019_fpgasoc/app-badgetris/main.c:37:11: error: conflicting types for 'GFXSPRITES'
   37 | uint32_t *GFXSPRITES = (uint32_t *)0x5000C000;
      |           ^~~~~~~~~~
In file included from /home/roger/coding/hadbadge2019_fpgasoc/app-badgetris/main.c:7:
../apps-sdk/sdk.h:45:17: note: previous declaration of 'GFXSPRITES' was here
   45 | extern uint32_t GFXSPRITES[];
      |                 ^~~~~~~~~~
../apps-sdk/sdk.mk:82: recipe for target '/home/roger/coding/hadbadge2019_fpgasoc/app-badgetris/build/main.o' failed
make: *** [/home/roger/coding/hadbadge2019_fpgasoc/app-badgetris/build/main.o] Error 1

Broken autoexec.elf will also break IPL

If there is an autoexec.elf present, IPL will try to run it on startup. If the autoexec.elf is bad (with an infinite loop) it also freezes up IPL. While in this state, the badge will not work as a USB mass storage device.

If the user reboots the badge, they're back in the same place and they can't access flash to delete the bad autoexec.elf.

How to get out of it: Modify IPL source code so it looks for some file name other than autoexec.elf. (Preferably an elf that will exit properly, or one that does not exist.) Flash that IPL and reboot the badge to restore access to USB mass storage.

Do we care about putting in any additional mitigation? It is certainly an option for us to say "Yep, it'll happen, and that's how you get out of it."

Frame counter in GFX_REGS ?

What do you reckon about adding a couple of GFX registers to count these things?

(a) total frames since reset,
(b) lines since start of frame.

Being able to see the current frame number would be useful for apps doing animation - including the IPL menu. Knowing the number of lines since start of frame might help someone avoid tearing issues in certain complicated scenarios.

I'm happy to send a pull request - just wanted to make sure this kind of thing wasn't against the early-90's aesthetic :)

Implement yield() syscall

So it can callback the USB stuff.

make app-helloworld fails with link errors

Steps:

1. $ cd app-helloworld
2. $ make clean; make

Result: Compile fails with link error
Expected result: successful compilation

There are many errors of this form:
LD helloworld.elf
/opt/riscv/lib/gcc/riscv64-unknown-elf/9.2.0/../../../../riscv64-unknown-elf/bin/ld: /opt/riscv/lib/gcc/riscv64-unknown-elf/9.2.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-calloc.o): ABI is incompatible with that of the selected emulation:
target emulation elf64-littleriscv' does not match elf32-littleriscv'

It seems that the compiler is producing riscv32 .o files, but the .a file is riscv64.

Something that worked: Recompiling the riscv compiler to get a riscv32 toolchain, and changing the makefiles to use riscv32-unknown-elf-* binaries instead of riscv64-unknown-elf binaries results in a successful build.

I think the problem is that, even though the riscv64-unknown-elf-* toolchain can produce and work with 32 bit binaries, the libraries are all 64 bit. I could not work out how to make the riscv64-unknown-elf toolchain work with 32 bit libraries. I think the right fix is probably just a little documentation.

Few questions about HDMI and power source

Hi to all,
does someone has HDMI, power and USB schematics?
It really looks very similar to our board.
And if our board was reference we are really fine with that it is board that is opened from beginning.
Only downside is that if you did use our board as reference you could contact us and send us one sample, we would gladly help in making badge even better. This way we see some possible mistakes that we cannot confirm...
I think if we want opensource hardware along with toolchain to be even more successful we really need collaborate more!
I did try direct contact before opening issues but still no answer...

Toolchain doesn't work under Windows CMD

The toolchain doesn't (yet) work under Windows CMD. Here are two attempts, one without V=1 and one with:

C:\Users\Alan\hadbadge\hadbadge2019_fpgasoc\app-helloworld>make
"    " CC crt0.S
The syntax of the command is incorrect.
make: *** [C:\Users\Alan\hadbadge\hadbadge2019_fpgasoc\apps-sdk/sdk.mk:106: C:/Users/Alan/hadbadge/hadbadge2019_fpgasoc/app-helloworld/build/apps-sdk/gloss/crt0.o] Error 1

C:\Users\Alan\hadbadge\hadbadge2019_fpgasoc\app-helloworld>make V=1
process_begin: CreateProcess(NULL, true CC crt0.S, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [C:\Users\Alan\hadbadge\hadbadge2019_fpgasoc\apps-sdk/sdk.mk:105: C:/Users/Alan/hadbadge/hadbadge2019_fpgasoc/app-helloworld/build/apps-sdk/gloss/crt0.o] Error 2

This is using the latest toolchain from https://github.com/xobs/ecp5-toolchain/releases/tag/v1.6.1.

I have set RISCV_TOOLCHAIN_PATH and PATH to point to the toolchain. I have verified that I can run the tools

I've had success building using Windows Subsystem for Linux (WSL).

Need hardware timer for C code

Apps written in C need access to some reliable hardware timer to implement non-blocking delays.

• Could be a 32-bit register that increments every millisecond
• @Spritetm mentioned it might be possible to add an indication of the 60 Hz vblank signal

Pull new version of Badgetris submodule (no with audio, thanks Elliot!)

Elliot's music for Badgetris has been incorporated in that repo. Please update the submodule when you have a chance.

cache state at reset leads to first 0x2000 addresses returning invalid data

I'm working on a formal proof of the qpi cache, and though I'm not finished I've found a potential issue.

The cache doesn't have valid lines, instead, if there is a tag in the tag memory that matches the incoming address, the cache line is assumed valid.

The initial fill for the tag_data memory is all 0s for first way, and all 1s for the second.
So (with default settings), the first 0x2000 addresses will return invalid data. (note the found_tag line is high for first 0x2000 addresses).

If the cache is used so that those addresses are always written to at boot, then this wouldn't be a problem, but we should probably put at least a warning in the description at the top of the file.

For the formal proof I am just making the solver choose addresses above 0x2000 to validate, but thought I'd post this for discussion.

Cannot compile soc

Why typing make in the soc folder I'm first hit with an error about unconstrained pins.

Using template $paramod\$lut\WIDTH=4\LUT=16'0111000100000000 for cells of type $lut.
Using template $paramod\$lut\WIDTH=4\LUT=16'0000000011010111 for cells of type $lut.
No more expansions possible.
<suppressed ~20545 debug messages>
Removed 0 unused cells and 21554 unused wires.

45.31. Executing HIERARCHY pass (managing design hierarchy).

45.31.1. Analyzing design hierarchy..
Top module:  \top_fpga

45.31.2. Analyzing design hierarchy..
Top module:  \top_fpga
Removed 0 unused modules.

45.32. Printing statistics.

=== top_fpga ===

   Number of wires:              26757
   Number of wire bits:          45012
   Number of public wires:        1575
   Number of public wire bits:   14029
   Number of memories:               0
   Number of memory bits:            0
   Number of processes:              0
   Number of cells:              28388
     CCU2C                        1128
     DP16KD                         32
     EHXPLLL                         2
     JTAGG                           1
     L6MUX21                      1630
     LUT4                        16441
     MULT18X18D                      8
     ODDRX1F                         8
     OSCG                            1
     PFUMX                        4034
     TRELLIS_DPR16X4               555
     TRELLIS_FF                   4485
     TRELLIS_IO                     62
     USRMCLK                         1

45.33. Executing CHECK pass (checking for obvious problems).
checking module top_fpga..
found and reported 0 problems.

45.34. Executing BLIF backend.

45.35. Executing JSON backend.

Warnings: 23 unique messages, 23 total
End of script. Logfile hash: 63e3f25c68
CPU: user 88.84s system 0.61s, MEM: 1302.07 MB total, 1272.42 MB resident
Yosys 0.9+231 (git sha1 fda94311, gcc 7.4.0-1ubuntu1~18.04.1 -fPIC -Os)
Time spent: 25% 7x techmap (23 sec), 18% 22x opt_clean (16 sec), ...
nextpnr-ecp5 --json soc.json --lpf had19_proto2.lpf --textcfg soc_out_synth.config --45k --package CABGA381 --speed 8  --pre-pack clock-constrainsts.py --seed 2
Info: Importing module top_fpga
Info: Rule checker, verifying imported design
Info: Checksum: 0xd290047b

ERROR: IO 'sao1[0]' is unconstrained in LPF (override this error with --lpf-allow-unconstrained)
0 warnings, 1 error
Makefile:45: recipe for target 'soc_out_synth.config' failed
make: *** [soc_out_synth.config] Error 255

If I add the suggested --lpf-allow-unconstrained flag to the makefile:

--- a/soc/Makefile
+++ b/soc/Makefile
@@ -42,7 +42,7 @@ $(PROJ).json $(PROJ).blif: $(SRC) $(SRC_SYNTH) $(EXTRA_DEPEND)
                          synth_ecp5 -top top_fpga -json $(PROJ).json -blif $(PROJ).blif"
 
 %_out_synth.config: %.json clock-constrainsts.py
-       nextpnr-ecp5 --json $< --lpf $(CONSTR) --textcfg $@ --45k --package CABGA381 --speed 8  --pre-pack clock-constrainsts.py --seed 2
+       nextpnr-ecp5 --lpf-allow-unconstrained --json $< --lpf $(CONSTR) --textcfg $@ --45k --package CABGA381 --speed 8  --pre-pack clock-constrainsts.py --seed 2
 
 %_out.config: %_out_synth.config bram_replace/bram_replace$(EXE) rom.hex
        bram_replace/bram_replace$(EXE) -l 8192 -r $< $@ rom.hex

I still cannot build the soc:

ERROR: Max frequency for clock                  '$glbnet$clk48m': 49.34 MHz (FAIL at 50.00 MHz)
Info: Max frequency for clock            '$glbnet$vid_pixelclk': 68.47 MHz (PASS at 30.00 MHz)
Info: Max frequency for clock                  '$glbnet$clkint': 279.25 MHz (PASS at 25.00 MHz)
Info: Max frequency for clock '$glbnet$hdmi_encoder.clk_125MHz': 343.52 MHz (PASS at 140.02 MHz)

soc/ila/default-tiles.tsx points to a nonexistent file

I wanted to use the Tiled application (https://www.mapeditor.org/) to edit the tilemap.tmx file in app-helloworld.

In the app-helloworld, tilemap.tmx file points to default-tiles.tsx:

https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/master/app-helloworld/tilemap.tmx#L3

That file seems to be expecting a png file:
https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/master/soc/ipl/default-tiles.tsx#L3

But in the repo is only included a tga file:
https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/master/soc/ipl/tileset-default.tga

This causes Tiled application to complain when attempting to edit tilemap.tmx in the hello world demo that it can't find the png file.

If I open the tga file up in macos preview and then export it as a png file, then the Tiled application is happy and I can edit it.

Should the PNG version be added in addition/instead of the tga file? Or should the default-tiles.tsx be edited to look for the tga file instead?

Unable to upload blink bit file

I've followed the instructions here:
https://github.com/mohitbhoite/hadbadge2019_fpgasoc/blob/master/doc/soc-dev.md
On reboot, it appeared nominally the same, so I'm not sure how to tell if I was successful with uploading the latest build (my badge had the original image from the conference already installed).

cd ..
cd blink

I tried the same sequence of steps within the /blink/ directory, expecting to see one or more LEDs to begin blinking (I'm unclear how long to hold SW7; I release before executing 'make dfu_flash'). However, when the device reboots, it still appears to have the conference code installed (showing a splash screen followed by the menu listing the elf files). I believe I have failed to upload the blink bit file.

I have successfully loaded in a modified "Hello World" elf with my name, so I appear to have good communication with the unit (the unit also reboots itself after I run 'make dfu_flash').

I'm running Windows 10.

git terminal output after running 'make', then 'make dfu_flash':
Info: [ 81394, 81549) |******
Info: [ 81549, 81704) |****
Info: [ 81704, 81859) |******
Info: [ 81859, 82014) |********
Info: [ 82014, 82169) |***********
ecppack --svf-rowsize 100000 --spimode qspi --freq 38.8
--svf blinky.svf --input blinky_out.config --bit blinky.bit
dfu-util -d 1d50:614a,1d50:614b -a 2 -R -D blinky.bit
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2019 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
No DFU capable USB device available
make: *** [Makefile:31: dfu_flash] Error 74

Scott@Laptop MINGW64 ~/hadbadge/hadbadge2019_fpgasoc/blink (master)
$ make dfu_flash
dfu-util -d 1d50:614a,1d50:614b -a 2 -R -D blinky.bit
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2019 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 1d50:614b
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0101
Device returned transfer size 4096
Copying data from PC to DFU device
Download [=========================] 100% 1032329 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!

Add Badgetris! as submodule

I have a stable version of this ready. Is adding this as a submodule the best way to include it in the project?

git submodule add https://github.com/szczys/badgetris-2019supercon.git app-badgetris

Known issues:

• Background image has some flicker in the lower third of it. I'm unsure if this is my code an issue with the IPL.

Maximum display pitch is 512

Testing with video/verilator_main, it seems the maximum value FB_PITCH is 512. When I choose a larger value (e.g 513 or 516), every second frame is messed up.

Digging around in gtkwave, it looks as though neither dma_start_addr or write_vid_addr_next are being reset (which should happen around line 600 in vid_linerenderer.v)

I'm not sure if this is just a simulation problem or if it affects the hardware.

There's code for a repro on the "bug-report" branch of my clone: https://github.com/alanvgreen/hadbadge2019_fpgasoc/tree/bug-report

From the soc/video directory:
$ make verilator-build/Vvid&&verilator-build/Vvid -s 8 -f 5

Show 'start SOC from internal memory' when booted from cart

The IPL allows you to boot from cart, and you can actually boot a custom SoC and IPL from the cartridge. However, confusingly, when booted from the cart, the IPL will still give you the option to boot from cart. ToDo: if we detect we're botoed from cart, show 'Boot from FPGA bitstream' on internal flash instead.

HelloWorld writes twice to line 19

If you write to Y=19 using fprintf the text will appear on both line 18 and line 19

To reproduce, change the Y value to 19 and run the app:

diff --git a/app-helloworld/main.c b/app-helloworld/main.c
index d050145..14f0c2d 100644
--- a/app-helloworld/main.c
+++ b/app-helloworld/main.c
@@ -58,7 +58,7 @@ void main(int argc, char **argv) {
        //buffered.
        fprintf(f, "\033C"); //clear the console. Note '\033' is the escape character.
        fprintf(f, "\0335X"); //set Xpos to 5
-       fprintf(f, "\0338Y"); //set Ypos to 8
+       fprintf(f, "\03319Y"); //set Ypos to 8
        fprintf(f, "Hello World!\n"); // Print a nice greeting.
        //Note that without the newline at the end, all printf's would stay in the buffer.

Visual artifacts visible in scaling operation

While working on the "Xbox One" style splash screen, I substituted the flying white 3D ball by scaling a white 2D circle. For scaling I copied gfx_set_xslate_val() from soc/ipl/main.c without zero understanding of how GFX_REG works.

When running at the desired full speed, the result is acceptable, but some people's eyes are fast enough to perceive "something is wrong" even if they can't perceive details of what.

When I slow the animation down with a delay of 100 instead of just 1, we can see visual artifacts including the following:

• The X/Y position is shifting instead of staying on (xcenter,ycenter)
• Tearing
• Sometimes, for just a flash, the tiles are in completely incorrect places. (~12s mark)

https://youtu.be/u6LBOS6nGJ4

In case there have been multiple versions, this is the version of gfx_set_xslate_val() I copied/pasted.

void gfx_set_xlate_val(int layer, int xcenter, int ycenter, float scale, float rot) {
	float scale_inv=(1.0/scale);
	float dx_x=cos(rot)*scale_inv;
	float dx_y=-sin(rot)*scale_inv;
	float dy_x=sin(rot)*scale_inv;
	float dy_y=cos(rot)*scale_inv;
	float start_x=-xcenter;
	float start_y=-ycenter;
	
	int i_dx_x=64.0*dx_x;
	int i_dx_y=64.0*dx_y;
	int i_dy_x=64.0*dy_x;
	int i_dy_y=64.0*dy_y;
	int i_start_x=(-start_x+start_x*dx_x-start_y*dx_y)*64.0;
	int i_start_y=(-start_y+start_y*dy_y-start_x*dy_x)*64.0;
	
	GFX_REG(GFX_TILEA_OFF)=(i_start_y<<16)+(i_start_x&0xffff);
	GFX_REG(GFX_TILEA_INC_COL)=(i_dx_y<<16)+(i_dx_x&0xffff);
	GFX_REG(GFX_TILEA_INC_ROW)=(i_dy_y<<16)+(i_dy_x&0xffff);
}

Use sine lookup table for animations in IPL menu

So, there's a lot of sin() and floats used in the IPL menu, both for the wobbling of the main header as well as for the sine scroller. This is terribly slow, the main menu is incapable of running at a full 60FPS at this moment; the net result is that mass storage is slow as it doesn't get enough CPU time. It would be good if someone reworked this into a quarter-sine lookup table instead, so we can use integer-only logic.

Broken link in README.md

https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/master/doc/soc_dev.md

TinyFPGA-Bootloader URL requires SSH key

In .gitmodules, all paths are https with the exception of the TinyFPGA-Bootloader one. This can be changed to an https url without breaking anything, allowing this repo to be checked out on a system with no github keys configured.

Signals on GENIO bus while TinyProg active

Starting some interfacing, I was very surprised to see signals on the cartridge IO (eg. 48MHz on genio[0], aka GENIO1)

I thought it must be some exotic ECP5 boot mode, but looking further it looks like debug output for TinyProg!

  assign genio[0] = clk_48mhz;
  assign genio[1] = 0;
  assign genio[2] = usb_tx_en?usb_n_tx:usb_n_rx;
  assign genio[3] = usb_tx_en?usb_p_tx:usb_p_rx;
  assign genio[4] = flash_sck;
  assign genio[5] = flash_cs_i;
  assign genio[6] = flash_mosi;
  assign genio[7] = flash_miso;
  assign genio[27:8] = 'h0;

Should they be there? Someone putting hardware on that port might reasonably expect that their lines don't get busy during Tinyprog...

Maybe OK in most cases, but could cause problems...