Verilog (Xilinx): Virtual tristate or muxes?

[mnentwig]

Hi,

I've got some FPGA resources that are shared, for example RAM an
multiplier.
Instead of explicitly muxing the inputs, would it make sense to us
"virtual" tristate ports in connected modules?
I'd expect that if the enabling condition is the same as in an explici
mux, also the resulting implementation should be the same. Or not?

I haven't started any synthesis experiments yet, thought I'd ask firs
(even though we all know that a couple of months in the lab can save man
hours in the library...)

Cheers

Markus

---------------------------------------
Posted through http://www.FPGARelated.com

 

[glen herrmannsfeldt]

mnentwig <24789@embeddedrelated> wrote:

(snip)

I've got some FPGA resources that are shared, for example RAM and
multiplier.

Instead of explicitly muxing the inputs, would it make sense to use
"virtual" tristate ports in connected modules?
I'd expect that if the enabling condition is the same as in an explicit
mux, also the resulting implementation should be the same. Or not?

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

 

[Mark Curry]

In article <20140203082924.045c791c@rg.highlandtechnology.com>,
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

On Sat, 01 Feb 2014 15:48:08 -0600
"mnentwig" <24789@embeddedrelated> wrote:

Hi,

I've got some FPGA resources that are shared, for example RAM and
multiplier.
Instead of explicitly muxing the inputs, would it make sense to use
"virtual" tristate ports in connected modules?
I'd expect that if the enabling condition is the same as in an explicit
mux, also the resulting implementation should be the same. Or not?

I haven't started any synthesis experiments yet, thought I'd ask first
(even though we all know that a couple of months in the lab can save many
hours in the library...)

Cheers

Markus

---------------------------------------
Posted through http://www.FPGARelated.com

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

 

[glen herrmannsfeldt]

Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

On Sat, 01 Feb 2014 15:48:08 -0600
"mnentwig" <24789@embeddedrelated> wrote:

(snip)

I've got some FPGA resources that are shared, for example RAM and
multiplier.
Instead of explicitly muxing the inputs, would it make sense to use
"virtual" tristate ports in connected modules?

(snip)

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.

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 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.

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

 

[Rob Gaddi]

On Sat, 01 Feb 2014 15:48:08 -0600
"mnentwig" <24789@embeddedrelated> wrote:

Hi,

I've got some FPGA resources that are shared, for example RAM and
multiplier.
Instead of explicitly muxing the inputs, would it make sense to use
"virtual" tristate ports in connected modules?
I'd expect that if the enabling condition is the same as in an explicit
mux, also the resulting implementation should be the same. Or not?

I haven't started any synthesis experiments yet, thought I'd ask first
(even though we all know that a couple of months in the lab can save many
hours in the library...)

Cheers

Markus

---------------------------------------
Posted through http://www.FPGARelated.com

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.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[mnentwig]

Hi,

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

As it turned out, one type of construct was missing completely from m
Verilog vocabulary. Here is a simple example:
http://www.cs.indiana.edu/hmg/le/project-home/xilinx/ise_5.2/help/usenglish/fpgadesign/html/multi_verilog.htm

What I didn't know is that a later assignment does not "erase" an earlie
one completely, but they combine. I wonder what logic applies if more tha
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, a
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 <= ct + 1;

e1 = 0; e2 = 0; e3 = 0; e4 = 0;
case (ct[26:25])
2'b00: e1 = 1;
2'b01: e2 = 1;
2'b10: e3 = 1;
2'b11: e4 = 1;
endcase;

LED <= nextLED;
end
endmodule







---------------------------------------
Posted through http://www.FPGARelated.com

 

[mnentwig]

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

---------------------------------------
Posted through http://www.FPGARelated.com

 

On Monday, February 3, 2014 12:24:41 PM UTC-6, Mark Curry wrote:

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.

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

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

For instance, if you are developing a highly configurable system (via generics 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 reasons, 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 easily and simply connected to record signals, thus making the higher-level connectivity easier to recognize (without so many trees, the forest can be seen).

Andy