Why this had to come first
The Kyttar chip is novel. It doesn't match any computation paradigm you can buy right now, so no existing software targets it. That's the whole point of the chip and it's also the immediate problem you hit on day one.
You can build any chip you want. That doesn't matter if nobody can program it, and nobody learns a chip that has no libraries to get real work done. So bootstrapping the chip and the company isn't enough on its own. There has to be software in place that people can pick up and start building with right away. That's what placeKYT is for.
In open-source DSP, everyone uses GNU Radio. The question was how to take GNU Radio and all the flowgraphs people have already written and port them onto Kyttar without a ton of pain, and do it so the architecture looks like something people actually want.
placeKYT is the middleware between the hardware and GNU Radio. That's the gap it fills.
What you actually get
placeKYT simulates what the chip will do today, before any silicon lands on your desk. When the chip ships, the same environment programs the real thing, streams data through it, and lets you change parameters while it runs.
The difference from an FPGA is that everything is assembly. The cores sit at a functional level instead of the logic level, so you're not staring at gates trying to figure out what went wrong. You get what a normal CPU debugger gives you: single-stepping, breakpoints, register inspection, and waveforms so you can watch data move through the cells. Work at the hardware level or up at the function level, whichever fits the problem in front of you. The same view spans the hardware, the assembly, and your GRC flowgraph.
If you already have a block library, you map straight from GRC to a physical placement on the chip. placeKYT does the place and route, or you do it yourself in the GUI. Once you're happy and there are no DRC violations, you push data from GNU Radio through the simulated chip and get the waveforms back out in GNU Radio. That loop works today.
Where AI comes in
If you don't have the blocks, you're stuck. You need blocks to do anything, and somebody has to sit down and write the assembly. So there's a big push right now to port known-good functionality out of GNU Radio and into placeKYT.
People are going to roll their eyes here. Oh great, another AI thing. But this is the right place for it. You've got a known-good reference with quantifiable results and an environment that's specific to Kyttar. The answer's already known and physics bounds the problem, so this is translation, not invention. AI handles that kind of work well. You give it the task, a known-good reference, and a pass/fail check, then let it run until it passes.
I don't have time to write all these blocks by hand. What I can do is write the rules for getting the job done and hand them to the agents. So I broke the blocks into tiers.
Tier one is the simple feed-through stuff. An NCO, a FIR filter, anything where data passes from input to output with no feedback loop. 26 of those are verified and running. Tier two is the feedback blocks, your AGCs, equalizers, timing recovery, and so on. These work too. I've built a handful of them by hand and they run fine. What I haven't cracked yet is a general rule for feedback that's clean enough to hand an agent and trust it to run on its own. Feedback has nuances that the feed-through blocks just don't, and I'm still figuring out how to describe them so an agent doesn't need me babysitting it. So tier two is real, but for now I build those by hand. Once I find the pattern and the knowledge base fills in, I expect these to be automatable too.
Memory for the agents
Every finished block writes what it learned back into a shared knowledge base that any agent can read later. When a normal team builds IP, tribal knowledge grows up next to the formal docs. Here the agents are the team, so they have to record that tribal knowledge themselves and pass it forward in writing. Misses and mistakes get logged so the next agent does better.
The reason any of this is tractable is that the instruction set is tiny and the cells are simple. It's layered. At the bottom is a single cell. Multicell blocks add inter-cell comms, which is its own short doc. On top of that is block-to-block routing, another doc. I'm deliberately not building one giant impossible-to-document thing. These are small pieces that talk to each other, and the experience stacks on top of itself, so the full context for a task fits in one window. That helps a person, and it helps an AI even more, because the limit there isn't breadth of knowledge, it's the size of the context window. Keep the pieces small and an agent can grab one and finish it fast.
My original idea with all of this was a chip programmed only in assembly. No compiler required. AI is the compiler. Once a block is made you stop thinking about it and just assemble the pieces. Small components compose into bigger ones, on up to a full system, and you can drop down to a single instruction or zoom out to multichip orchestration whenever you need. placeKYT rides on that architecture to get you working while the agents grind through the boring blocks.
I think this is where it's all headed anyway. People bring the ideas and the agents do the grind. Why build something so centralized that no single agent can hold it in its head?
Go break it
That's the state of it. It's rough, things are missing, and I'm still building pieces. Go give it a shot, the instructions are in the repo.
Any feedback helps, but here's the one I actually want. Forget bug reports for a second. What does your current DSP toolchain not do that you wish it did? What do you reach for every day that's missing here? That's the stuff that'll shape where this goes.