compact bus description

[alb]

Hi everyone,

I was wondering if there's any way to describe a bus 'type' and declare
it to be a port, where the bus has signals going in and out of an entity.

I certainly know that registers can group elements together but then
when declared as ports they can be of in/out/inout mode only [1].

On a practical side, assuming I want to have a wishbone bus, can I group
all the signals in a sort of "macro port" which can be mapped more
easily? I certainly realize that an 'in' port on one side should be an
'out' one on another side.

In my testbenches I usually 'abstract' the physical interface with some
sort of type definition which then is mapped into the physical port
through a set of functions but would that be advisable for synthesis?

Any hint/suggestion/comment is appreciated,

Al

[1] I intentionally omitted 'buffer' and 'linkage', the first being
essentially the same as 'out' in vhdl-2008 and the second being
something I've never understood the reason for :-/

 

[KJ]

I was wondering if there's any way to describe a bus 'type' and declare
it to be a port, where the bus has signals going in and out of an entity.

Other than to declare all signals as 'inout', there is no way to group signals together and have individual elements have different modes.

If you do declare everything as 'inout', then you need to add statements in the architecture to tri-state all of the signals that you would like to be 'in'.

Kevin Jennings

 

[Mike Treseler]

I was wondering if there's any way to describe a bus 'type' and declare
it to be a port, where the bus has signals going in and out of an entity.

I agree with KJ, but I don't understand your requirement.

On a practical side, assuming I want to have a wishbone bus, can I group
all the signals in a sort of "macro port" which can be mapped more
easily? I certainly realize that an 'in' port on one side should be an
'out' one on another side.

Since the wishbone bus is wired through the fpga fabric, there can't be a an internal node, other than a pin driver, that requires bidirectional operation.

In my testbenches I usually 'abstract' the physical interface with some
sort of type definition which then is mapped into the physical port
through a set of functions but would that be advisable for synthesis?

It's not required for synthesis. Only in the case of simulating multiple devices, could such an abstraction be useful. I always start with a fpga pin level testbench. Anything complicated in the fabric can be covered with functions and assertions. Finding or making a "good enough" model for externaldevice can sometimes be a problem, but at the pin level I also have the option of putting a scope on it.

Any hint/suggestion/comment is appreciated,

OK.

1. Use complex functions and types as needed for synthesis because they areeasy to test statically even if they are unlikely to be reused.

2. Sim whatever you can at the fpga device entity pin level first.

-- Mike Treseler

 

[alb]

Hi KJ,

Other than to declare all signals as 'inout', there is no way to
group signals together and have individual elements have different
modes.

has this feature ever been considered for an upgrade in the language?
With the growing need to have an on-chip bus or network, wouldn't an
easier way to 'connect' components help?

I actually see current component mapping a bit cumbersome; you need to
have ports and signals to wire them together. If those ports which
belong to the same interface can be 'combined' to some extent the
interconnect task could potentially be easier.

Moreover what is the benefit of having a signal for the port map? Unless
the signal is used in the architecture where components are wired
together (which I tend to avoid), it seems that signal declaration is
highly redundant:

<code>
-- ...
signal a;
signal b;

begin

component_0: foo
port map (
a => a,
b => b,
);

component_1: foo
port map (
a => b,
b => a,
);
-- ...
</code>

The need to pass through a signal also forces the port map to be present
for both components, while in general if a port of component_a is
assigned to a port of component_b, the opposite is implicitly valid.

What if the following code was valid:

<pseudo-code>
component_0: foo
port map (
a => component_1.b,
b => component_1.a,
);
</pseudo-code>

Since there's never a free lunch, what is the downside of having such a
feature? I certainly did not go through the full definition of what can
be a 'combined' port and there are certainly pitfalls and technical
obstacles which might prevent this.

Believe me I do not want to start a flame, I might be a little
provocative but my intent is to see whether the language can evolve further.

Al

 

[HT-Lab]

Hi KJ,



has this feature ever been considered for an upgrade in the language?

Yes, both mixed in/out ports in records and SV Interfaces are being
considered for the next language revision, see:

http://www.eda.org/twiki/bin/view.cgi/P1076/CollectedRequirements

Anybody can join the group,

Regards,
Hans
www.ht-lab.com

 

[alb]

Hi Mike,

I agree with KJ, but I don't understand your requirement.

It is possible that I do not clearly know what I want and that I might
have wrongly stated what I want, therefore I certainly understand your
possible lack of understanding .

I would like to declare 'something' that defines my connection (being it
wishbone, or whatever else) with a single name identifier so that when I
connect it to other components I do not need to care about port
assignment the way I do now.

Since the wishbone bus is wired through the fpga fabric, there can't
be a an internal node, other than a pin driver, that requires
bidirectional operation.

while I agree with you that internal nodes do not have bidirectional
operations, the tristate logic model might facilitate the functional
description (leaving the tool instantiate all the necessary muxes).

It is not seldom that I define an internal data bus as tristated while
several sources may want to drive it.

It's not required for synthesis. Only in the case of simulating
multiple devices, could such an abstraction be useful. I always start
with a fpga pin level testbench. Anything complicated in the fabric
can be covered with functions and assertions. Finding or making a
"good enough" model for external device can sometimes be a problem,
but at the pin level I also have the option of putting a scope on
it.

Assuming the logic 'contains' multiple 'devices' of the same type which
need to be connected together, the possibility to alleviate the wiring
effort might be useful.

[]

1. Use complex functions and types as needed for synthesis because
they are easy to test statically even if they are unlikely to be
reused.

what do you mean by 'test statically'?

2. Sim whatever you can at the fpga device entity pin level first.

This is my main mantra! I first concentrate on the pin level because I
know that in the field, that's nearly the only thing I can access. This
adds an extra effort (and logic) in order to make each state observable.

Too often though I jumped in projects where these aspects weren't really
put in at the design stage and when it comes to verification it becomes
a mess. That is why I recently started to look into assertions to
investigate the possibility to increase observability without changing
the hardware.

 

[Rob Gaddi]

Hi everyone,

I was wondering if there's any way to describe a bus 'type' and declare
it to be a port, where the bus has signals going in and out of an entity.

I certainly know that registers can group elements together but then
when declared as ports they can be of in/out/inout mode only [1].

On a practical side, assuming I want to have a wishbone bus, can I group
all the signals in a sort of "macro port" which can be mapped more
easily? I certainly realize that an 'in' port on one side should be an
'out' one on another side.

In my testbenches I usually 'abstract' the physical interface with some
sort of type definition which then is mapped into the physical port
through a set of functions but would that be advisable for synthesis?

Any hint/suggestion/comment is appreciated,

I've done several projects using an internal WISHBONE bus. In each and
every one of them, my code is peppered with t_wb_mosi and t_wb_miso,
which mean whatever they happen to mean for that particular project.

It's unfortunate and obnoxious, but not the end of the world.

 

[Anssi Saari]

Other than to declare all signals as 'inout', there is no way to group signals together and have individual elements have different modes.

If you do declare everything as 'inout', then you need to add statements in the architecture to tri-state all of the signals that you would like to be 'in'.

So basically the way to do this sort of thing is still having separate
records for inputs and outputs. I googled and you wrote about this in
2006, saying that tools are usually smart enough to figure out which
signals are actually inouts... So are you sure the tri-stating is
actually needed?

BTW, does anyone know what happened to the proposals for SystemVerilog
like interfaces in VHDL? For example, here is one proposing direction
for signals in records:
http://www.vhdl.org/vhdl-200x/vhdl-200x-ft/proposals/ft17_composite_interface_mode.txt

Was this just rejected?

 

[HT-Lab]

On 19/11/2013 08:43, Anssi Saari wrote:
...

BTW, does anyone know what happened to the proposals for SystemVerilog
like interfaces in VHDL? For example, here is one proposing direction
for signals in records:
http://www.vhdl.org/vhdl-200x/vhdl-200x-ft/proposals/ft17_composite_interface_mode.txt

Was this just rejected?

Don't think so:

http://www.eda.org/twiki/bin/view.cgi/P1076/BlockInterfaces

It is a popular enhancement,

Regards,
Hans
www,ht-lab.com

 

[rickman]

Hi Mike,



It is possible that I do not clearly know what I want and that I might
have wrongly stated what I want, therefore I certainly understand your
possible lack of understanding .

I would like to declare 'something' that defines my connection (being it
wishbone, or whatever else) with a single name identifier so that when I
connect it to other components I do not need to care about port
assignment the way I do now.

I understand what you are looking for. You wish to wrap up all the
details of a bus interface in a port into one structure, one name. But
as far as I know, there is no way to do this in VHDL. We have records
for combining data declarations of different types. But we have nothing
that can function more widely in a port map for combining IO types.

while I agree with you that internal nodes do not have bidirectional
operations, the tristate logic model might facilitate the functional
description (leaving the tool instantiate all the necessary muxes).

It is not seldom that I define an internal data bus as tristated while
several sources may want to drive it.

Yes, the hands off approach to hardware design, almost like designing
software.

It's not required for synthesis. Only in the case of simulating
multiple devices, could such an abstraction be useful. I always start
with a fpga pin level testbench. Anything complicated in the fabric
can be covered with functions and assertions. Finding or making a
"good enough" model for external device can sometimes be a problem,
but at the pin level I also have the option of putting a scope on
it.

Assuming the logic 'contains' multiple 'devices' of the same type which
need to be connected together, the possibility to alleviate the wiring
effort might be useful.

[]

1. Use complex functions and types as needed for synthesis because
they are easy to test statically even if they are unlikely to be
reused.

what do you mean by 'test statically'?

2. Sim whatever you can at the fpga device entity pin level first.

This is my main mantra! I first concentrate on the pin level because I
know that in the field, that's nearly the only thing I can access. This
adds an extra effort (and logic) in order to make each state observable.

Too often though I jumped in projects where these aspects weren't really
put in at the design stage and when it comes to verification it becomes
a mess. That is why I recently started to look into assertions to
investigate the possibility to increase observability without changing
the hardware.

Ignoring the power of a simulation only because you can't duplicate it
in the field is a bit like... well, I can't even come up with an
analogy. That makes no sense to me. I test at all levels as I design
hardware. Then I test the total entity in ways that can be duplicated
in the field, but more importantly come from the spec. All you can do
is to test each requirement of your design. If you can't test that from
the outside of the design looking in, does it matter as a requirement?
That applies to both the simulation and the physical object.

 

[Mike Treseler]

while I agree with you that internal nodes do not have bidirectional
operations, the tristate logic model might facilitate the functional
description (leaving the tool instantiate all the necessary muxes).

True, but the necessary muxes and control logic could also be inferred directly in a single process entity. Value flow is my preferred abstraction. Synthesis can sort out the muxes.

It is not seldom that I define an internal data bus as tristated while
several sources may want to drive it.

That's another way to do it. Not quite as close to the metal though.

what do you mean by 'test statically'?

Hide assertion declarations (synthesis translate_off) after the process template to test the synthesis functions. That way I can get terminal output that tests the actual synthesis functions and other declarations every time vsim elaborates the synthesis code with debug_c true.

This is my main mantra! I first concentrate on the pin level because I
know that in the field, that's nearly the only thing I can access. This
adds an extra effort (and logic) in order to make each state observable.

Too often though I jumped in projects where these aspects weren't really
put in at the design stage and when it comes to verification it becomes
a mess. That is why I recently started to look into assertions to
investigate the possibility to increase observability without changing
the hardware.

I agree that synthesis code assertions of some sort are needed to debug complex control functions. Sometimes rewriting old code and rolling your own functions
is faster. Sometimes work is just hard.

-- Mike Treseler

 

[KJ]

has this feature ever been considered for an upgrade in the language?

With the growing need to have an on-chip bus or network, wouldn't an

easier way to 'connect' components help?

Yes it has, see this link
http://www.eda.org/twiki/bin/view.cgi/P1076/BlockInterfaces

VHDL language standards are currently being proposed, here is the home page for that group.
http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome

What if the following code was valid:



<pseudo-code>

component_0: foo

port map (

a => component_1.b,

b => component_1.a,

);

</pseudo-code>



Since there's never a free lunch, what is the downside of having such a

feature? I certainly did not go through the full definition of what can

be a 'combined' port and there are certainly pitfalls and technical

obstacles which might prevent this.



Believe me I do not want to start a flame, I might be a little

provocative but my intent is to see whether the language can evolve further.

If you want to change the language, then you need to take your suggestion to the proper forum which is at the links I posted earlier.

Kevin Jennings

 

[KJ]

So basically the way to do this sort of thing is still having separate

records for inputs and outputs. I googled and you wrote about this in

2006, saying that tools are usually smart enough to figure out which

signals are actually inouts... So are you sure the tri-stating is

actually needed?

I don't recall ever writing that 'tools are usually smart enough to figure out which signals are actually inouts' even if it was seven years ago.

You have to tri-state the 'inputs' since they are declared as 'inout' whichmeans that they drive the signal. If you have no driver specified becauseyou are using it as an input, the implicit driver is 'U'. No other signalthat is supposed to be able to drive that signal will be able to override the 'U'.

Kevin Jennings

 

[alb]

Hi KJ,

has this feature ever been considered for an upgrade in the
language?

[]
Yes it has, see this link
http://www.eda.org/twiki/bin/view.cgi/P1076/BlockInterfaces

VHDL language standards are currently being proposed, here is the
home page for that group.
http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome

thanks again for the pointers. I'm actually trying to go through the
page in order to understand what was the evolution. My experience in
language definition is scant at best, but I guess that I'll definitely
learn something from this process.

[]

If you want to change the language, then you need to take your
suggestion to the proper forum which is at the links I posted
earlier.

I believe that my experience and knowledge is still too shallow to be of
any use at that level, but I'll certainly stick around and through some
thoughts if found appropriate.

The fact that a feature like this has been taken into consideration
already alleviates part of my discomfort that led me to post here in the
first place.

Al

 

[Andy]

You have to tri-state the 'inputs' since they are declared as 'inout' which
means that they drive the signal. If you have no driver specified because
you are using it as an input, the implicit driver is 'U'. No other signal
that is supposed to be able to drive that signal will be able to override
the 'U'.

If I'm not mistaken, if you explicitly define an initial value of 'Z' for each element of a signal at the signal's declaration, then all drivers associated with that signal take the same initial value as their default value (instead of the implicit 'U' for a signal with no explicit initialization inthe declaration).

For an element of an inout port associated with such an initialized signal,which is really treated as an input-only element (and therefore never assigned), the element driver will retain the default value (e.g. 'Z') indefinitely. Meanwhile, other drivers (e.g. in other components) can explicitly override the 'Z' value, allowing them to treat the element as an "output", passing such values to the associated "inputs".

Jim Lewis' (of Synthworks) Advanced Testbench course demonstrates this technique, but I have not tried it in synthesis yet.

Andy

 

[KJ]

On Wednesday, November 20, 2013 8:12:02 AM UTC-6, KJ wrote:







If I'm not mistaken, if you explicitly define an initial value of 'Z' for

each element of a signal at the signal's declaration, then all drivers associated
with that signal take the same initial value as their default value (instead of
the implicit 'U' for a signal with no explicit initialization in the declaration).

I think you're mistaken (but admit I haven't tried). When you have an entity with an out
or inout port, there will be an implicit driver created for the output of that entity with
a value of 'U' for std_(u)logic type. Tying a signal that has an initial value of 'Z' will
do nothing, the 'U' will still be there and win out.

However, if the entity has a default of 'Z' applied in the port definition it will work.

Adding an explicit assignment statement within the architecture or a default value on the
entity will accomplish the goal of overriding the 'U'.

Kevin Jennings

 

[Andy]

Tying a signal that has an initial value of 'Z' will do nothing, the 'U' will still be there and win out.

That's what I thought too, until I took Jim's Advanced TB class... I HIGHLY recommend it!

All drivers associated (e.g. during elaboration) with the signal will get the same initialization/default as the signal. I was quite surprised myself.

That part of the class focused on transactions modeled as resolved records passed between procedures (inout ports on each) rather than entities, but entities and procedures should behave the same WRT this aspect.

I repeat, I have not tried this in synthesis.

Andy

 

[alb]

Hi Mike,

True, but the necessary muxes and control logic could also be
inferred directly in a single process entity. Value flow is my
preferred abstraction. Synthesis can sort out the muxes.

I am also a big fan of 'single process entity' but I still connect
several entities through an on-system-bus which often is described with
tristate logic. In this way my system can scale up (and down) much more
easily, or at least I think it does.

That's another way to do it. Not quite as close to the metal though.

Correct, I find that being close to the metal is something that I can
live without if I gain in maintainability and readability of the code.
This, of course, may not always apply.

Hide assertion declarations (synthesis translate_off) after the
process template to test the synthesis functions. That way I can get
terminal output that tests the actual synthesis functions and other
declarations every time vsim elaborates the synthesis code with
debug_c true.

Uhm, since I'm pretty fresh new to assertion as of today, would it be
possible for you to post a small example?

[]

I agree that synthesis code assertions of some sort are needed to
debug complex control functions. Sometimes rewriting old code and
rolling your own functions is faster. Sometimes work is just hard.

What is difficult to estimate is the short and long term benefits of
debugging vs. rewriting. I often leave this decision to my inner senses
to decide and when their voices say 'enough is enough' I scrap
everything away and start from ground zero!

I certainly believe there's a more 'formal' way for this decision
problem

Al