Wouldn't it be more sensible to have one module for converting the AXI-Lite (I presume?) memory map interface to the specific input format of your processor, and then have the processor pull data from this adaptor when it needs it? That way still all handling of inputs is done in the same place.

Edit: maybe, what it comes down to is: Should the register bank be responsible for storing the state the compute unit is working on, or should the compute unit store that state itself? In my opinion, that responsibility lies with the compute unit. The compute unit shouldn't have to rely on the register bank not changing while its working.

I'm noting down this conetrace for the future though, seems like a useful tool, and they seem to be doing a closed beta of sorts.

Whereas for regular people, an upswing means nothing, whereas a downswing means job loss, mortgage rate hikes, etc.

The goal is to get consistent synthesis to 450MHz such that I can use a narrower 256-bit instead of a 512-bit interface, while maintaining full bandwidth. I've got it working at an FMax ranging 440-490MHz, though there's still some edge cases I need to hammer out.

https://github.com/pc2/sus-xrt

I think improving the safety of hardware design is a noble goal, and certainly there is much that can be improved over Verilog & VHDL's incredibly brittle baseline.

Though for dynamic latency safety, my intuition tells me the problem space is undecidable. Sure one could prove the correctness of various kinds of dynamic latency pipelines, and as research progresses you'll include more and more such constructs, but it'll always remain possible to construct a correct but unprovable dynamic pipeline.

Given that, shouldn't we take a leaf out of Rust's book, and instead give the user tools to build abstractions which internally contain unprovable but correct black magic, yet on their interface provide a safe, static latency count.

Take for instance SUS' SlowState. It abstracts over an internal state, and the user provides a pipeline to update this internal state. Now, if we were to update the state twice, before the change has had time to propagate through the pipeline, that would be an error. SlowState prevents you from doing so by statically measuring the length of the update pipeline, and only allowing updates once it has cleared. Implementing SlowState requires some unsafe, but it can provide a safe interface upholding its requirement.

> We will edit su.c to prevent the overflow by maintaining a counter, i, and verifying it against the buffer size during the read loop. I initially attempted a fix using pointer arithmetic, but the 1973 C compiler didn’t like it, while it didn’t refuse the syntax, the code had no effect. I settled on a simpler index-based check instead.

I'm tooting my own horn with this, as I'm building my own language for doing the actual designing. It's called SUS.

Simple things look pretty much like C:

  module add :
    int#(FROM:-8, TO: 8) a,
    int#(FROM: 2, TO: 20) b -> 
    int c {
    c = a+b
  }

It's a very young language, but me, a few of my colleagues, and some researchers in another university are already using it. Check it out => https://github.com/pc2/sus-compiler

This means that if I walk into a random croissant shop and buy a croissant, I don't subsequently have 2 days of food poisoning.

Arguably, healthier being the default is also good. The less I personally need to think about this, the more I can think about other more useful things.