Notices by TheZoq2 (thezoq2@mastodon.social)

@whitequark @dmbaturin @dramforever Oh, being able to set CORS headers would have made a lot of tings easier for me in the past

@whitequark @gsuberland That's easy Surfer can live reload the underlying file (as long as the names don't get moved around)

I don't _think_ we have a way to load waves from a string via wasm but that's easy enough to add, I can look at that in the next few days

@whitequark @gsuberland How embeddable are we talking here? You can absolutely throw a Surfer instance into a tab on the playground and have it show waves (assuming you have a VCD string you can hand over)

Some automation (like adding signals on the top level) automatically should also be pretty easy

@whitequark Damn, that is extremely cool

@whitequark I... uhhh... damn, that sucks :/

@whitequark Oh never mind then :D

~~Maybe you need an exhaustive list of projects you didn't build on your website too~~

@whitequark You should! Especially with such a wide variety of projects.

It took me a long time to realize you were the original author of solvespace for example

@whitequark @wren6991 Needs more tcl

@wren6991 I love it when I learn about basic things missing from gtkwave like this :D

Glad you like Surfer :)

@whitequark @tom_verbeure @wren6991 time for a repost

@karotte I'd be curious how many i2c targets actually ignore clocks that are too fast

@wren6991 @whitequark You may be interested in https://sonic-rv.ics.jku.at/. I don't know the full technical details but it does allow fully in-browser simulation of a few risc-v cores.

Given that it uses GHDL I assume that this has a backend and doesn't simulate in-browser but I could be wrong. Maybe @lcsklmmr knows more

@whitequark @wren6991 Oh true, I forgot that the cxxrtl is probably way easier to just build and embed in wasm, I should give this a try

@wren6991 The only piece missing from that puzzle at this point is a good verilator wasm port. (There is one but it is several years old and has a few annoying limitations, like not allowing >64 bit signals iirc)

After *checks notes* 8 months, I finally got around to doing another Surfer release 🎉

The change log is long with lots of big and small changes, my favorites being the new wasm based translators, and improvements to the waveform control protocol.

I also took the opportunity to set up automatic builds of the VSCode extension from `main` so it will be in sync with the rest of our binaries :)

Full change log at https://gitlab.com/surfer-project/surfer/-/blob/main/CHANGELOG.md?ref_type=heads#040---2025-11-06

#fpga #asic #verilog #vhdl

@whitequark @multisn8 I too want to know what this abomination is

@whitequark Oh yeah, quickscope is like 100 lines of HDL and 200 lines of client code. Probably much better to re-implement something similar in Amaranth :D

A Surfer plugin for Amaranth would be super cool. My goal from the start was to have more HDLs do rich translation with it but I only added the wasm system for that recently

@whitequark If you want to copy that system, you'll have to implement a Surfer plugin for Amaranth types (can be used for both Sim and this) https://docs.surfer-project.org/translator_docs/index.html

You could also do the unwrapping when generating the vcd file too, I just did it this way because I already have the Surfer translation infrastructure in place

@whitequark Shouldn't be that hard, it is essentially 3 parts

Quickscope itself that runs on the hardware, it just serializes an arbitrary value https://gitlab.com/TheZoq2/quickscope

The client (./client) does reads the serialized data from the serial port (main.rs), and for the Spade integration, works out which which top module was used for the quickscope instantiation (spade.rs). It then writes the .vcd file -> top module mapping which the Spade plugin for Surfer looks for https://gitlab.com/spade-lang/spade/-/tree/main/spade-surfer-plugin?ref_type=heads

Here it is in use, with newly added Surfer integration so it shows actual Spade values instead of just bit vectors :)