Catherine

> Is the thought that there would be an `m.d.comb += Display(f’foo {bar}’}`? Yes. > I don’t imagine that yosys has anything useful it could do with Display It should...

> Something more like `m.d.comb += Display(s, *args, **kwargs)` which does the equivalent of `s.format(args, kwargs)` except in `$display` language? Yep. > Also, is there an RTLIL equivalent? Not yet,...

Yes, it would make perfect sense as a workflow. Do you have any preferences regarding an exported API here?

It wouldn't be hard to make it iterative; the VCD writer isn't, but only due to limitations of the VCD file format.

I think it would be an appropriate and highly useful feature to have: your workaround is... let's say suboptimal (no shade but it's pretty inefficient), and what @awygle wants here...

Okay, so I think we have two basic problems here that are essentially separate: * Given a platform PLL instance (following the vendor conventions), perform frequency calculations, both in forward...

> I think the PLL should definitely create the clock constraints This isn't usually necessary because the backend toolchain already knows the output frequency if you constrained the inputs. But...

> These are the polynomial equations that describe the relationship between the input and output frequencies, and the multiplication and division (integer) values, right? Yes, with integer solutions, and some...

> The data representation should express the equations symbolically using a symbolic expression library I assume. Something like that. It's not clear if we can use an existing library or...

For now I actually think it makes sense to collect PLL equations in this issue in human-readable form while the rest of the design is being worked on; the data...