Deferring architecture choice in SystemVerilog

One size may not fit all instances of a design component. For example, depending on the timing context, a fast and expensive implementation may be justified for one instance, but be overkill for another. You could try to figure out all those details, and lock them down with configurations, but it would be better to defer these choices to the tools, letting them adapt fluidly to changes in context.

In SystemVerilog one way to describe alternative implementations is with nested modules (23.4). For example, suppose the module has an output port “out” of type “T”. Then for each alternative implementation, you could declare a nested module with only one port — an output port of that same type “T” — but pick up the inputs from the surrounding module scope instead of using port connections. Suppose further that there are three nested modules named “fast”, “little” and “medium”.

T Impls[3];

fast fast(Impls[0]);
little little(Impls[1]);
medium medium(Impls[2]); always @(posedge clk) begin assert final ($size(Impls.unique) == 1); out <= Impls[0]; end

The simulator (via the assertion) would check that indeed the implementations do yield the same results, and an intelligent synthesis tool would understand this implication of the assertion and preserve all implementation options until there is enough contextual information to make an optimal choice.

Advertisements

Tell me (anonymous OK)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s