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,

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

    --
    A: Because it fouls the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    alb, Nov 15, 2013
    #1
    1. Advertising

  2. alb

    KJ Guest

    On Friday, November 15, 2013 10:57:14 AM UTC-5, alb wrote:
    > 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
     
    KJ, Nov 15, 2013
    #2
    1. Advertising

  3. On Friday, November 15, 2013 7:57:14 AM UTC-8, alb wrote:
    > 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
     
    Mike Treseler, Nov 16, 2013
    #3
  4. alb

    alb Guest

    Hi KJ,

    On 15/11/2013 22:26, KJ wrote:
    > On Friday, November 15, 2013 10:57:14 AM UTC-5, alb wrote:
    >> 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.


    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
     
    alb, Nov 18, 2013
    #4
  5. alb

    HT-Lab Guest

    On 18/11/2013 08:51, alb wrote:
    > Hi KJ,
    >
    > On 15/11/2013 22:26, KJ wrote:
    >> On Friday, November 15, 2013 10:57:14 AM UTC-5, alb wrote:
    >>> 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.

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



    > 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, Nov 18, 2013
    #5
  6. alb

    alb Guest

    Hi Mike,

    On 16/11/2013 22:15, Mike Treseler wrote:
    > On Friday, November 15, 2013 7:57:14 AM UTC-8, alb wrote:
    >> 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.


    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.

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


    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.

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

    Rob Gaddi Guest

    On Fri, 15 Nov 2013 16:57:14 +0100
    alb <> wrote:

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

    --
    Rob Gaddi, Highland Technology -- www.highlandtechnology.com
    Email address domain is currently out of order. See above to fix.
     
    Rob Gaddi, Nov 18, 2013
    #7
  8. alb

    Anssi Saari Guest

    KJ <> writes:

    > On Friday, November 15, 2013 10:57:14 AM UTC-5, alb wrote:
    >> 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'.


    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?
     
    Anssi Saari, Nov 19, 2013
    #8
  9. alb

    HT-Lab Guest

    HT-Lab, Nov 19, 2013
    #9
  10. alb

    rickman Guest

    On 11/18/2013 8:24 AM, alb wrote:
    > Hi Mike,
    >
    > On 16/11/2013 22:15, Mike Treseler wrote:
    >> On Friday, November 15, 2013 7:57:14 AM UTC-8, alb wrote:
    >>> 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.

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


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

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


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

    --

    Rick
     
    rickman, Nov 19, 2013
    #10
  11. On Monday, November 18, 2013 5:24:33 AM UTC-8, alb wrote:

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

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


    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.

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


    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
    #11
  12. alb

    KJ Guest

    On Monday, November 18, 2013 3:51:30 AM UTC-5, alb wrote:
    > 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, Nov 20, 2013
    #12
  13. alb

    KJ Guest

    On Tuesday, November 19, 2013 3:43:53 AM UTC-5, Anssi Saari wrote:
    >
    > > 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?
    >
    >

    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
    #13
  14. alb

    alb Guest

    Hi KJ,

    On 20/11/2013 15:05, KJ wrote:
    > On Monday, November 18, 2013 3:51:30 AM UTC-5, alb wrote:
    >> 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.

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


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

    Andy Guest

    On Wednesday, November 20, 2013 8:12:02 AM UTC-6, KJ wrote:
    > 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
     
    Andy, Nov 20, 2013
    #15
  16. alb

    KJ Guest

    On Wednesday, November 20, 2013 2:03:44 PM UTC-5, Andy wrote:
    > On Wednesday, November 20, 2013 8:12:02 AM UTC-6, KJ wrote:



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

    Andy Guest

    On Wednesday, November 20, 2013 3:33:53 PM UTC-6, KJ wrote:
    > 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
     
    Andy, Nov 21, 2013
    #17
  18. alb

    alb Guest

    Hi Mike,

    On 19/11/2013 20:28, Mike Treseler wrote:
    > On Monday, November 18, 2013 5:24:33 AM UTC-8, alb wrote:
    >
    >> 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.


    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.

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


    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.

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

    >
    > 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
     
    alb, Nov 22, 2013
    #18
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. hamilton
    Replies:
    0
    Views:
    792
    hamilton
    Apr 1, 2004
  2. Bo
    Replies:
    0
    Views:
    907
  3. Davy
    Replies:
    2
    Views:
    464
    Thomas Stanka
    Mar 28, 2006
  4. Replies:
    0
    Views:
    524
  5. charles

    Compact Privacy Policy?

    charles, Jun 30, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    459
    JiangZemin
    Jul 1, 2003
Loading...

Share This Page