Precursor: From Boot to Root

I have always wanted a computer that was open enough that it can be inspected for security, and also simple enough that I could analyze it in practice. Precursor is a step towards that goal.

As a test, I made a one hour video that walks through the Precursor tech stack, from hardware to root keys. I feel it’s a nice demo of what evidence-based trust should look like:

The video is a bit of a firehose, so please refer to our wiki for more info, or open an issue to further the discussion.

Erratum #1: I had mistakenly attributed SpinalHDL as a subset of Chisel. SpinalHDL is actually a separately developed HDL by Charles Papon. It was developed contemporaneously with Chisel and inspired by many concepts in it, such as using Scala as the underlying language; but it is not affiliated with Chisel.

3 Responses to “Precursor: From Boot to Root”

  1. Todd says:

    Thank you for this fine work

  2. ben says:

    I understand litex/chisel generates verilog.. any reason why this couldn’t then be synthesized/pnr on any fpga? For ex. Lattice/xilinx tools seem to be the vendors of choice.. but what would prevent it from building for Microchip’s SmartFusion2?

    Also when using these newer open-source tools, how does one constrain the design , and create test-benches? Can this also done in python/scala, or do you need to use the vendor tool? I’m guessing debugging and single-stepping the risc-v code could use the standard eclipse/open-ocd?

    I’m interested in learning fpgas, (either with chisel3 , SpinalHDL , amaranthhdl, etc), any suggestions where to start?

    • bunnie says:

      The generic verilog output can target any FPGA, although there is some tuning of the verilog idioms to map better onto the primitives in some architectures (for example in the FIFOs for Migen there is a specific FIFO mode that generates verilog that maps into BRAMs, versus other modes that use distributed RAM).

      However, in the case of Precursor specifically, even though everything eventually turns into “verilog”, we make liberal use of direct instantiations of Xilinx hardware primitives as verilog modules. For example, we instantiate the I/O cells explicitly for the SPINOR, because we need intimate control over the input/output delay timings to achieve our target speeds. The Ed25519 block is also specifically coded to take advantage of the Xilinx DSP48E primitives, which contain a “hard macro” multiplier block, allowing us to achieve our performance and density metrics. These can be “unbound” by replacing these models with generic verilog descriptions and then targeting another FPGA family, but you won’t achieve the same performance and density.

      That being said, check out Enjoy-Digitals’ “FPGA 101” course:

      This is a great starting point.

Leave a Reply