compact bus description

Discussion in 'VHDL' started by alb, Nov 15, 2013.

  1. alb

    alb Guest

    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,


    [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 :-/
    alb, Nov 15, 2013
    1. Advertisements

  2. alb

    KJ Guest

    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
    KJ, Nov 15, 2013
    1. Advertisements

  3. I agree with KJ, but I don't understand your requirement.
    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.
    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.

    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
    Mike Treseler, Nov 16, 2013
  4. alb

    alb Guest

    Hi 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?

    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:

    -- ...
    signal a;
    signal b;


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

    component_1: foo
    port map (
    a => b,
    b => a,
    -- ...

    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:

    component_0: foo
    port map (
    a => component_1.b,
    b => component_1.a,

    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.

    alb, Nov 18, 2013
  5. alb

    HT-Lab Guest

    HT-Lab, Nov 18, 2013
  6. alb

    alb Guest

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

    what do you mean by 'test statically'?
    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.
    alb, Nov 18, 2013
  7. alb

    Rob Gaddi Guest

    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.
    Rob Gaddi, Nov 18, 2013
  8. alb

    Anssi Saari Guest

    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:

    Was this just rejected?
    Anssi Saari, Nov 19, 2013
  9. alb

    HT-Lab Guest

    HT-Lab, Nov 19, 2013
  10. alb

    rickman Guest

    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.

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

    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.
    rickman, Nov 19, 2013
  11. 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.
    That's another way to do it. Not quite as close to the metal though.
    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.
    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
    Mike Treseler, Nov 19, 2013
  12. alb

    KJ Guest

    Yes it has, see this link

    VHDL language standards are currently being proposed, here is the home page for that group.
    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, Nov 20, 2013
  13. alb

    KJ Guest

    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
    KJ, Nov 20, 2013
  14. alb

    alb Guest

    Hi KJ,

    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.

    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.

    alb, Nov 20, 2013
  15. alb

    Andy Guest

    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, Nov 20, 2013
  16. alb

    KJ Guest

    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
    KJ, Nov 20, 2013
  17. alb

    Andy Guest

    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, Nov 21, 2013
  18. alb

    alb Guest

    Hi Mike,

    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.
    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.
    Uhm, since I'm pretty fresh new to assertion as of today, would it be
    possible for you to post a small example?

    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 :)

    alb, Nov 22, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.