nathanrossi/meta-hdl

HDL tools layer for OpenEmbedded

meta-hdl's Issues

Correct place for lm32 cross compiler?

We frequently use the LatticeMico32 soft-CPU from Lattice in our FPGA designs. For this we need a lm32 cross compiler. The lm32 architecture is in upstream binutils and gcc, so in theory should be pretty easy to support?

Unlike RISC-V the LatticeMico32 is pretty much only ever used on FPGAs as a soft-core. Where would be the correct place to add this cross compiler? Would it make sense to be part of this repository?

issues when building for ECP5

Hi Nathan,

Thanks a lot for your work.

Trying to do the build for versa-ecp5 I found the following problems in meta-hdl (using current master):

• the checksum for the licenses (in LIC_FILES_CHKSUM) for litespi and litex-pythondata-software-picolibc recipes are incorrect. When the build fails it gives the value that should be in the recipes

• The build for linux-on-litex-vexriscv fails when building bios.elf. The problem seems to be the toolchain and the fact that a linux toolchain (provided by meta-oe?) is used instead of a bare-metal toolchain. I don't know what would be the best way to fix this. As a test I prepended PATH with the toolchain mentioned in linux-on-litex-vexriscv repository (installed in my build PC) so that the wrappers generated in do_create_toolchain_wrappers() in litexnative.bbclass point to this toolchain, and the it stopped failing.

• The name of the generated .bit and .svf files are hardcoded to "top.bit" and "top.svf" in linux-on-litex-vexriscv.bb but for this target the generated files are "versa_ecp5.bit" and "versa_ecp5.svf".

If there is any stable tag/commit I should be using instead of 'master' branch please let me know.

I would also like to know if anyone could tell me how much work it would take to make this build work for a Xilinx Nexys4DDR target, either with the Vivado toolchain or with the open source ones.

Thanks!

Add support for LiteX and friend repositories

• https://github.com/enjoy-digital/

The "big three" would be;

• litex
• liteeth
• litedram

The smaller ones would be;

• litepcie
• litescope
• litevideo
• litesata
• liteusb

Add FuseSoC/Edalize integration

Hi,

I learned about this project from a presentation. Very nice. Have you considered integrating with FuseSoC and Edalize to handle more complex RTL designs?

Does it make sense for programming tools to be part of this layer?

Most FPGAs need some type of tool to program them (normally via USB). Does it make sense for these programming tools to be part of this layer?

Some examples that would be good to support;

• OpenOCD
• iceprog from icetime
• xc3sprog
• tinyprog

Add recipe for Chisel

https://chisel.eecs.berkeley.edu/

• Requires Scala/JVM (meta-java for JDK)
  • needs sbt - https://github.com/sbt/sbt
• https://github.com/freechipsproject/firrtl
• Requires verilator?

Add vpr from Verilog to Routing for another FOSS PnR option

The SymbiFlow project is supporting Verilog to Routing's vpr tool as a place and routing option for the ice40, ecp5 and artix7 FPGA parts.

VtR is more research focused than nextpnr but hopefully will soon provide similar type of functionality.

You can see how we build VtR in our conda packages here -> https://github.com/timvideos/conda-hdmi2usb-packages/blob/master/vtr/build.sh

riscv32 cross compiler seems to have issues with libgloss?

When trying to build MACHINE=picosoc bitbake picosoc-hx8k you need the riscv32 cross compiler. However, there seems to be an issue where libgloss package.

WARNING: libgloss-3.0.0-r0 do_package: QA Issue: libgloss: Files/directories were installed but not shipped in any package:
  /usr/lib/lib
  /usr/lib/lib/libnosys.a
  /usr/lib/lib/nosys.specs
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
libgloss: 3 installed and not shipped files. [installed-vs-shipped]

It seems weird that the path has two lib values in it.

Add Project X-Ray to fpga-tools

Similar to Project Trellis, Project X-Ray aims to support Xilinx 7-series bit stream format.

Project X-Ray

Project X-Ray aims at documenting the Xilinx 7-series bit-stream format, a prerequisite to building Open Source tools to generate bit-streams for those devices. The information currently on this page is a sneak preview for the kind of information Project X-Ray will provide.