records in port declarations

[Christian Schleiffer]

Hi,

I have a design with quite a lot of Xilinx FPGAs on the same bus and I
would like to use records to make the port declarations smaller and
easier to read. The bus consists of some bidirectional and some
unidirectional signals. Now I'm wondering what the synthesis tools (XST
or Synplify) will do if I declare the whole record as inout. Will they
infer tristate buffers all over the designs, even though I'm only
writing or reading to the unidirectional signals?
Is it wise at all to group the different signal types in one record?
Thanks for any comments on this.

Best regards
Chris


--
Christian Schleiffer
Communication Security (COSY)
Dept. of Electr. Eng. & Information Science
Ruhr-University Bochum, Germany
http://www.crypto.rub.de
cschleiffer@crypto.rub.de

 

[Ben Jones]

"Christian Schleiffer" <usenet_NOSPAM_@schleiffer.net> wrote in message
news:4jthv4F9epfqU1@news.dfncis.de...

Hi,

I have a design with quite a lot of Xilinx FPGAs on the same bus and I
would like to use records to make the port declarations smaller and
easier to read. The bus consists of some bidirectional and some
unidirectional signals. Now I'm wondering what the synthesis tools (XST
or Synplify) will do if I declare the whole record as inout. Will they
infer tristate buffers all over the designs, even though I'm only
writing or reading to the unidirectional signals?

Last time I tried this, that's exactly what happened. Avoid inout like the
plague unless you really do mean a tri-state buffer.

Is it wise at all to group the different signal types in one record?

Yes - it certainly makes for less typing, and it allows you to easily modify
the set of signal that make up a particular interface without having to
change a million files.

Your best bet is to gang up all the input signals, all the output signals,
and all the bidirectional signals into their own record groups. It's not
ideal, but it's better than nothing - and it does work in XST and Synplify.
For smaller buses with few signals, this is usually overkill though.

Good luck!

-Ben-

 

[KJ]

"Christian Schleiffer" <usenet_NOSPAM_@schleiffer.net> wrote in message
news:4jthv4F9epfqU1@news.dfncis.de...

Hi,

I have a design with quite a lot of Xilinx FPGAs on the same bus and I
would like to use records to make the port declarations smaller and
easier to read. The bus consists of some bidirectional and some
unidirectional signals. Now I'm wondering what the synthesis tools (XST
or Synplify) will do if I declare the whole record as inout.

They will be quite happy to oblige (at least Synplify will, I haven't tried
of late with XST).

Will they
infer tristate buffers all over the designs, even though I'm only
writing or reading to the unidirectional signals?

And then they'll selectlively 'optomize' out the tri-state controls when
they see that the inputs are never being driven and that the outputs (not
inouts) are always being driven leaving tri-state controls only on the
inouts. All the record type is doing from a synthesis perspective is giving
a different name to signals. Since the name itself is irrelevant to the
synthesis operation, the tools generally don't care.

Is it wise at all to group the different signal types in one record?

As Ben pointed out it would be wiser to see if you can group the inputs into
one record, the outputs into another, the inouts into a third. Some reasons
for doing this would be

- Code clarity, declaring an input as an inout leads to headaches for those
picking up the code later on. If I picked up some code and saw use of
inouts everywhere it would probably give me the impression of a bit of
laziness on the part of the original designer unless it was just immediately
obvious why such a grouping was a good thing (and in certain cases, I think
it can be 'good'). In 'most' cases, one guys output is the other guys input
so grouping by mode into a record doesn't cause any readability issues with
the other FPGA designs in the overall board design. If that's not the case
though then using inouts throughout may be appropriate.

- Extra code that would not be needed were it not for grouping everything as
inouts (i.e. All elements of the record that are really only inputs would
also need to have the line of code that sets them to 'Z'). The cleanest way
to handle this would be to define a constant of the record type that is
being used where you set all elements to 'Z' regardless of the intended mode
(i.e. in, out, inout) and then have a line of code that sets the entire
signal to this constant. That way in one fell swoop all inputs will have a
'Z' driving them. The outs and inouts will have the 'Z' driving as well but
then will also have whatever real equations as well so they will be
overridden. Also, if you have to add or subtract elements to the record or
change the intended mode (less likely one would think) you won't have to
worry about forgetting one of these default assignment as long as it
compiles since adding/removing a record element without also updating the
magic constant that has all 'Z' will result in an immediate easy to fix
error when you compile it.

KJ

 

[Christian Schleiffer]

Ben Jones wrote:

Last time I tried this, that's exactly what happened. Avoid inout like the
plague unless you really do mean a tri-state buffer.

I was hoping that the optimization process will eliminate the buffers again.

Is it wise at all to group the different signal types in one record?

Yes - it certainly makes for less typing, and it allows you to easily modify
the set of signal that make up a particular interface without having to
change a million files.

That's what I was thinking of, since the hardware is custom made. The
bus signals might change later, you'll never know...

Your best bet is to gang up all the input signals, all the output signals,
and all the bidirectional signals into their own record groups.

Yes, I already thought about that. But still, having only one record for
the bus would look much nicer in the source ;-)

Bye
Chris

--
Christian Schleiffer
Communication Security (COSY)
Dept. of Electr. Eng. & Information Science
Ruhr-University Bochum, Germany
http://www.crypto.rub.de
cschleiffer@crypto.rub.de

 

[Christian Schleiffer]

KJ wrote:

Will they
infer tristate buffers all over the designs, even though I'm only
writing or reading to the unidirectional signals?

And then they'll selectlively 'optomize' out the tri-state controls when
they see that the inputs are never being driven and that the outputs (not
inouts) are always being driven leaving tri-state controls only on the
inouts.

Ok, that's what I hoped.

Is it wise at all to group the different signal types in one record?

As Ben pointed out it would be wiser to see if you can group the inputs into
one record, the outputs into another, the inouts into a third.

Seems, like this is where I'm heading.

Thanks a lot, cheers
Chris

--
Christian Schleiffer
Communication Security (COSY)
Dept. of Electr. Eng. & Information Science
Ruhr-University Bochum, Germany
http://www.crypto.rub.de
cschleiffer@crypto.rub.de

 

[Jonathan Bromley]

On Wed, 09 Aug 2006 13:13:53 +0200, Christian Schleiffer
<usenet_NOSPAM_@schleiffer.net> wrote:

having only one record for
the bus would look much nicer in the source ;-)

Have you looked at the interface construct in SystemVerilog?
It aims to deal with exactly this issue. Personally I think the
jury's still out on whether it's entirely successful, but it's
a very interesting approach. Sadly, synthesis support is
still somewhat limited, although Synopsys DC does a good
job with interfaces and I think Mentor Precision supports
them now. Don't know about Synplify, sorry.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Amal]

Jonathan Bromley wrote:

On Wed, 09 Aug 2006 13:13:53 +0200, Christian Schleiffer
usenet_NOSPAM_@schleiffer.net> wrote:

Have you looked at the interface construct in SystemVerilog?
It aims to deal with exactly this issue.

You don't need SystemVerilog , you just need to be paitient till
VHDL-200x comes out . Check out:
http://www.vhdl.org/vhdl-200x/vhdl-200x-ft/proposals/ft17_composite_interface_mode.txt

This is similar to SystemVerilog interfaces.

-- Amal