61–70 of 76 posts
> Pure Silicon Demo Coding: No CPU, No Memory, Just 4k Gates ok, but silicon is doped so it's slightly impure, and CPUs are also silicon and memory is also silicon. you actually meant "4K gates, no clock, no synchronization, no timing" and maybe a little "not exactly sure when the output is rea... is rea... is ready"
The HAKMEM sine/cosine generator is such an elegant choice - it's numerically stable in fixed-point and requires only adds and bit-shifts. Perfect for hardware. I used a similar approach once for generating test patterns in an FPGA.
The fact that you can iterate on this in simulation, then deploy to actual silicon via Tiny Tapeout for $150 is honestly mind-blowing. We're living in the future.
Earlier quoted context omitted.
that doesnt seem like a good tradeoff...
Hardware takes 20 years to learn how to build properly. Software takes 1 year under someone smart in a production environment. People that conflate the two... longer or more likely never.. =3
That's very funny.
This is absolutely wild. Rendering graphics with just combinational logic and no frame buffer is the kind of constraint that breeds creativity. The HAKMEM sine/cosine generator is such an elegant choice - it's numerically stable in fixed-point and requires only adds and bit-shifts. Perfect for hardware. I used a similar approach once for generating test patterns in an FPGA. The fact that you can iterate on this in si…
This is absolutely wild. Rendering graphics with just combinational logic and no frame buffer is the kind of constraint that breeds creativity. The HAKMEM sine/cosine generator is such an elegant choice - it's numerically stable in fixed-point and requires only adds and bit-shifts. Perfect for hardware. I used a similar approach once for generating test patterns in an FPGA. The fact that you can iterate on this in si…
How does this compare to CORDIC for sin/cos generation? Which is more accurate, etc ?
This is absolutely wild. Rendering graphics with just combinational logic and no frame buffer is the kind of constraint that breeds creativity. The HAKMEM sine/cosine generator is such an elegant choice - it's numerically stable in fixed-point and requires only adds and bit-shifts. Perfect for hardware. I used a similar approach once for generating test patterns in an FPGA. The fact that you can iterate on this in si…
How does this compare to CORDIC for sin/cos generation? Which is more accurate, etc ?
CORDIC: - Iterative algorithm (needs multiple clock cycles) - Accuracy improves with more iterations - Generates both magnitude and phase - Typical hardware implementation: 12-16 iterations for decent precision
HAKMEM (Item 149): - Single-cycle computation (just two adds per step) - Uses the recurrence: x' = x - εy, y' = y + εx - Accuracy depends on word width and epsilon choice - Numerically stable in exact arithmetic if ε² < 2
This is absolutely wild. Rendering graphics with just combinational logic and no frame buffer is the kind of constraint that breeds creativity. The HAKMEM sine/cosine generator is such an elegant choice - it's numerically stable in fixed-point and requires only adds and bit-shifts. Perfect for hardware. I used a similar approach once for generating test patterns in an FPGA. The fact that you can iterate on this in si…
It's really cool but it doesn't seem practical at all. They aren't setting up print runs, just one-offs (https://tinytapeout.com/faq/#how-many-chips-will-i-receive-c...) and $150 could get you... many orders of magnitude more power than that.
... For that matter, apparently the microcontroller in the dev kit is a https://en.wikipedia.org/wiki/RP2040 , which seems like a beast in comparison. And it's still available for less than $1 USD on PiShop.
No x, no y, just Z is a pattern so often used by chatGPT it has started to bleed into common usage by people who maybe aren't even using an LLM.
x=CPU y=Memory Z=4k gates
Earlier quoted context omitted.
Are there any open or at least standard FPGAs that the open source community flock to? Last time I looked into FPGAs, it was mostly closed architecture and proprietary tools
Not for anything mid to higher range, but I believe there's open source tooling for some of the older Lattice and Xilinx parts. I would say for me it's not as big a deal as on the software side, because each vendor's hardware tends to be pretty different from each other anyway.
Earlier quoted context omitted.
Not for anything mid to higher range, but I believe there's open source tooling for some of the older Lattice and Xilinx parts. I would say for me it's not as big a deal as on the software side, because each vendor's hardware tends to be pretty different from each other anyway.
Dang, sounds like there’s still a bit of lock in. That’sa shame
For example, I've taken code optimized for Xilinx, ran it for another vendor, and resource count ballooned because stuff that was built-in/free on one wasn't on the other. It's a lot of work to truly make generic code and usually just means switching out modules per vendor.