Verilog (Xilinx): Virtual tristate or muxes?

(snip)

Early FPGAs had real tristate lines inside. With scaling, they required buffers along the way, and so most now have, as you note, virtual tristates. (Except that I/O buffers usually have real tristate, going off chip.)

As well as I know, virtual tristates are implemented as either virtual wired-AND or wired-OR. (In TTL terms, open collector or its complement.) That is probably more efficient than an actual MUX.

In verilog (and I presume VHDL) you can implement wired-AND or wired-OR, and it likely synthesizes just fine.

At some point, you should design for readability first, and let the tools do their job. If the logic looks like tristate, where the enables are available at the driving points, then virtual tristate, virtual wired-AND, or virtual wired-OR are probably best. If the select line is available close to the destination, then MUX is probably best.

Hope this helps,

-- glen

Oh good, you've stepped into one of the long running holy wars of FPGA design.

Respectfully, I'm going to disagree with Glen. Yes, the tools should be able to infer an AND/OR mux from the logic you wrote as a tristate. But it means that you've knowingly written code that says it does one thing and really does another. To my mind it's... unaesthetic. It breaks the rule that the point of code is to tell you the programmer what's going on, and then it should also synthesize.

Agree with Rob here. We just explicity use Wired-Or in our designs for things like this. I don't really see much use in using tristates in RTL code, when assigning to zero (when something's not used/not needed) is just as easy as assigning to 'z'. And as Rob notes, you're stating explicity what the tools are going synthesize.

Big note however, if you're using Vivado, the first versions of the tools didn't support Wired-Or/Wired-And. (It's worked fine forever in ISE). I think they've fixed it in a recent release...

Regards,

Mark

(snip)

Reading what I wrote again, I did not say that he should use tristate over wired-OR. I mostly suggested he should write for readability.

But a large fraction of HDL code says one thing and does another, at least if you look close enough. For one, they implement with LUTs instead of gates.

Also behavioral form is even more different from what it actually does, though I mostly try to write structural verilog.

Seems that the main difference betweeen tristate and wired-OR is that the chip doesn't overheat if you pull the line in two directions at the same time. That doesn't seem bad to me.

I believe that tristate, wired-AND, and wired-OR will all synthesize the same way, such that one should choose based on personal preference or personal aesthetics. (I tried not to emphasize one in the first post.)

I am not so sure that an actual MUX will synthesize the same. But the tools are improving all the time, so maybe they do that by now, too.

-- glen

Hi,

thank you all for your comments. The whole purpose of the exercise is to write the code in a way that is maintainable. That's fairly in-line with assigning 'z' in this case. I guess that's what I was looking for, to avoid hand-coding large numbers of explicit muxes.

As it turned out, one type of construct was missing completely from my Verilog vocabulary. Here is a simple example:

What I didn't know is that a later assignment does not "erase" an earlier one completely, but they combine. I wonder what logic applies if more than one value is non-z? Should find me a copy of the standard, or simulate.

I simulated and synthesized a short example, below. Simulation looks OK, and the LED on the board cycles through four brightness levels, as expected.

Cheers

Markus

module impl(input CLK32M, output reg LED); reg [26:0] ct = 0; reg e1, e2, e3, e4; wire a1 = e1 ? 0 : 'hz; wire a2 = e2 ? (ct[15:0] < 2048) : 'hz; wire a3 = e3 ? (ct[15:0] < 8192) : 'hz; wire a4 = e4 ? 1 : 'hz;

// multiple assignment with z wire nextLED; assign nextLED = a1; assign nextLED = a2; assign nextLED = a3; assign nextLED = a4;

always @(posedge CLK32M) begin ct

PS the blocking "temporary" assignments probably open up another can of worms when it comes to coding style and religion. Well, I guess they do the job here, usually I'd avoid them or comment carefully.

--------------------------------------- Posted through

ings

en

as

ls

Ok, I'll even it up at two apiece with a note of support for Glen's positio n...

The point of synthesizable code is to describe the behavior of the circuit, not necessarily its structure or implementation. To that end, there are di fferent situations where the behavior may be more clear when expressed as t ri-stated bus logic than wired-and or wired-or, or explicit multiplexer log ic.

For instance, if you are developing a highly configurable system (via gener ics or parameters) managing a configurable number of inputs to a mux (wired

-and, wired-or, or otherwise) is more cumbersome than multiple drivers of a single bus.

Also, some technologies may favor wired-and or wired-or for performance rea sons, and hard-coding a wired-or mux may not yield optimal results for all target technologies. Letting the synthesis tool handle translation of a tri

-state bus to the optimal mux topology is beneficial.

Finally, when "bidirectional" data needs to be exchanged, nothing beats the simplicity (and behavioral understandability) of a bidirectional tri-state bus, compared to the multitudes of explicit connections and multiplexers ( priorityless or not) required otherwise.

Tri-state descriptions can also be used to implement record-type ports with different "directions" on each element of the record. Such ports can be ea sily and simply connected to record signals, thus making the higher-level c onnectivity easier to recognize (without so many trees, the forest can be s een).

Andy