String properties require quotes if they are quoted strings. My processing of Yosys JSON might be messing this up and need to be fixed. So for example:

EX #(.PROP1("TRUE"), .PROP2(16'h1234)) ex();

Should actually be encoded as:

{
  .key = "PROP1"
  .textValue = "\"TRUE\""
},
{
  .key = "PROP2"
  .textValue = "16'h1234"
}

That make sense?

Yes, that makes sense. I hadn't actually checked that the JSON frontend was doing.

I'm still not sure if encoding two fundamentally different types of property into a string is the best option with access to all the power of a proper schema; storing bit vector parameters as a vector of bytes/32-bit words/etc would seem easier to work with to me.

storing bit vector parameters as a vector of bytes/32-bit words/etc would seem easier to work with to me.

This immediately runs into problems with LUTs (64-bits) and BRAM init strings (256-bits). As a future extension, we could add a varint property field, but I think operating on verilog encoded strings is probably the right short-term answer.

This immediately runs into problems with LUTs (64-bits) and BRAM init strings (256-bits).

Yes, that's why I suggested a vector of bytes/words

I think operating on verilog encoded strings is probably the right short-term answer.

Don't have a massive problem with this provided that the semantics are well defined so we don't end up in a situation where different tools have slightly different ideas of what Verilog encoded string means (ime these kinds of differences tend to cause big problems with EDIF interoperability).

I think operating on verilog encoded strings is probably the right short-term answer.

Don't have a massive problem with this provided that the semantics are well defined so we don't end up in a situation where different tools have slightly different ideas of what Verilog encoded string means (ime these kinds of differences tend to cause big problems with EDIF interoperability).

So the initial solution here is to require that user supplied primitive cell parameters follow the format of the default parameters of the library definition (in the device database)! So if the device database primitive cell default is 64'b0, then it is required that the parameter use verilog binary bit strings. If the default is 256'h0, then it is required that use verilog hex bit strings. This is something that I've been planning on writing up in a docs folder, but wanted to get a basic non-timing driven P&R up and running before doing so.

One way to handle the Nexus use of c-style hex constants (e.g. 0x0) is maybe to provide a format library in the documentation of possible ways to format bitstrings.

I think operating on verilog encoded strings is probably the right short-term answer.

Don't have a massive problem with this provided that the semantics are well defined so we don't end up in a situation where different tools have slightly different ideas of what Verilog encoded string means (ime these kinds of differences tend to cause big problems with EDIF interoperability).

I've tried to address this in #19, take a look with that in mind.