Verilator

No, sorry it hasn't.

It's a few weeks at least to fix it, which is why it's still there. If you're still game, I'll give guidance.

Hi Wilson,

Yes, I am game. This is the last major stumbling block before I can verilate my whole top-level. All the other problems I can "work" around. Although I imagine I will need plenty of hand-holding, the verilator code base is quite intimidating.

Regards,

Terry

BTW bug63 also discusses a similar issue.

It would be wonderful to have you contribute this; UNOPTFLAT is a huge pain, and everyone would be happy to see it go.

The basic problem is that busses which are in the path of circular logic need to get de-bussed before V3Order detects the code flow loop. So we need to detect and remove them by debussing. This code can be put anywhere between V3TraceDecl and V3Order phases - see Verilated.cpp for stage ordering. I'd probably put it right before V3Gate.

The easiest thing is to make a new stage with a new .cpp and .h file, that way your work won't collide. This code would have three rough stages:

• Write visit functions to follow the netlist, building a graph of the code flow, where a vertex is each net and block of logic. V3ClkGater is an example of this, V4Order is another example you'll need to reference. Delayed assignments are special as they break the dependency. "graphviz" is your friend in this; you can dump the graph and debug until it looks right.

• Now attempt to make the graph acyclic - it's just a function call - see V3Order.

• If the graph is cyclic there's ordering issues. Now the fun is to find why, and what busses to split up. A guess at an algorithm: Go through all of the acyclic nets, look for any that are multidimensional or multibit signals. Walk each logic block involved and for each signal in it that is cyclical build a data structure to remember what bit indexes (or slices of multidimensional array or memory) are referenced. See if there's a disjoint set; that tells what signals can be split.

• Once there's a list of signals to break up, call another visitor to do the edits appropriately. I think everywhere a signal is used on the right hand side, you can just concatenate the pieces together and V3Gate will deal with cleaning it up. The LHS of assignments may be a problem, but I think V3Const will clean that up reasonably well too; let's see what happens.

Hi Wilson,

Some colleagues of mine and I have been playing around with Verilator and we really like it (thanks!).

I have, however, run into the issue described here where Verilator identifies circular logic, even though the logic is not circular when examined at the bit or array level. I seem to run into it a lot when I use generate statements with wire arrays (e.g. a simple example would be a generated carry chain). Have there been any developments on this front? I know you previously said that fixing this would require at least a few weeks' work. I was curious...would it be any easier to get Verilator to distinguish between different parts of wire arrays (e.g. differentiating between my_wire⁰ and my_wire¹ when my_wire is declared as "wire [WIDTH-1:0] my_wire[N-1:0];")? If there's even a quick hack that can temporarily get me past this issue, it would still be useful for me.

Thanks, Omid

If you don't do any non-constant indexing, it would be a fairly easy hack, as long as you're willing to add a verilator pragma on the signal.

For example "wire [1:0] x" where "x⁰" and x¹" are the only thing used can easily be made two wires, or used together as "{x_1, x_0}", but it's too hard to handle "x[i]".