Design toplevel module as schematic?

Discussion in 'VHDL' started by Tobias Baumann, Apr 14, 2014.

  1. Hi everybody,

    the question above has been come up between a colleague and me. Should
    the toplevel module be created as schematic plan or written as text in VHDL?

    I prefer the second one, my colleague the first. The only advantage I
    see for using schematic coding, is that I have a visual overview of my
    toplevel modul and I quickly can find which blocks are connected together.

    On the other side, the development process is much slower because of
    using the mouse instead of keyboard. I also think that using textfiles
    are much easier to handle for revision controlling software like git or svn.

    Maybe someone can give me a few impressions how you handle the toplevel
    module. Before I started my new job, we worked at CERN on very large
    designs with hundreds of moduls in a team with about 10 VHDL engineers.
    We avoided to use graphical coding and this worked excellent, so I don't
    see any reason, why to change this.

    Thanks a lot,
    Tobias
    Tobias Baumann, Apr 14, 2014
    #1
    1. Advertising

  2. Tobias Baumann

    alb Guest

    Hi Tobias,
    Tobias Baumann <> wrote:
    []
    > the question above has been come up between a colleague and me. Should
    > the toplevel module be created as schematic plan or written as text in VHDL?


    After discussing with myself for quite some time I tend to avoid using
    schematics for two main reasons:

    1. portability
    2. readability

    No matter which tool you use as schematic entry you will certainly face
    some portability problem when you have to switch target if the tool
    chain is different. Even if you generate vhdl out of it, you cannot
    simply generate a schematic out of vhdl with the same level of care you
    did your trace routing.

    Text is written to be read while a schematic is drawn to be looked at.
    Without going to far in perception psicology, we often overestimate
    visual representation.

    On top of it, in most *nix environment you are supported by a wealth of text
    manipulation tools. How could you live without *grep* or *sed*.

    > I prefer the second one, my colleague the first. The only advantage I
    > see for using schematic coding, is that I have a visual overview of my
    > toplevel modul and I quickly can find which blocks are connected together.


    use emacs speedbar to see which components are instantiated and if you
    did a good interface job than there's not such an added value in
    graphical representation.

    > On the other side, the development process is much slower because of
    > using the mouse instead of keyboard. I also think that using textfiles
    > are much easier to handle for revision controlling software like git or svn.
    >


    SVN handles binaries as well, but I guess that portability is more of an
    issue rather than revision tracking.

    []
    > We avoided to use graphical coding and this worked excellent, so I don't
    > see any reason, why to change this.


    If you do not see any reason, why don't you ask what are the reasons to
    your colleague instead. It may simply be "tradition" and then you can
    simply forget all your reasonings.

    Al
    alb, Apr 14, 2014
    #2
    1. Advertising

  3. Am 14.04.2014 10:56, schrieb alb:
    > Text is written to be read while a schematic is drawn to be looked at.
    > Without going to far in perception psicology, we often overestimate
    > visual representation.


    I think that too, but there's the problem. Today the project leader came
    and wanted to see the schematic of my toplevel. So he made some trouble,
    because he as a none FPGA designer (but with experience in designing
    ASICs) wants to see a schmeatic to understand. Me as developer want to
    produce results, so I use textfile. If someone wants a schematic, I draw
    on a sheet of paper. The discussion ends up with "everybody uses
    schematic coding for the toplevel and it's silly to use VHDL for the
    toplevel". I really doubt this statement, so I started this discussion
    to see how others handle the toplevel.

    > On top of it, in most *nix environment you are supported by a wealth of text
    > manipulation tools. How could you live without *grep* or *sed*.


    >
    > use emacs speedbar to see which components are instantiated and if you
    > did a good interface job than there's not such an added value in
    > graphical representation.
    >


    I use Sigasi, which is perfect for me. It helps me to get quickly
    through a design. But even editors with VHDL highlighting are enough. It
    depends a bit on the quality of the source code.

    > If you do not see any reason, why don't you ask what are the reasons to
    > your colleague instead. It may simply be "tradition" and then you can
    > simply forget all your reasonings.


    The argument is, that it is standard for ASICs, so it has to be standard
    for FPGAs. But I think the real reason is: He wanted to see a schematic
    and becasue I have none he created an argument which fits his needs.

    Thanks a lot for sharing your opinion on this topic.
    Tobias Baumann, Apr 14, 2014
    #3
  4. Tobias Baumann

    devas Guest

    On Monday, April 14, 2014 9:46:40 AM UTC+2, Tobias Baumann wrote:
    > Hi everybody,
    >
    >
    >
    > the question above has been come up between a colleague and me. Should
    >
    > the toplevel module be created as schematic plan or written as text in VHDL?
    >
    >
    >
    > I prefer the second one, my colleague the first. The only advantage I
    >
    > see for using schematic coding, is that I have a visual overview of my
    >
    > toplevel modul and I quickly can find which blocks are connected together.
    >
    >

    Same discussion in our company. Some designers do not like schematic design (including me) and others like it and are angry when they have to made changes in your text based design.

    I see advantages of schematic design when you get an existing design but a good design description with some figures about the main path etc. helps a lot.

    >
    > On the other side, the development process is much slower because of
    >
    > using the mouse instead of keyboard. I also think that using textfiles
    >
    > are much easier to handle for revision controlling software like git or svn.
    >


    I agree. Text based is faster and easier to use in revision control.

    >
    >
    > Maybe someone can give me a few impressions how you handle the toplevel
    >
    > module. Before I started my new job, we worked at CERN on very large
    >
    > designs with hundreds of moduls in a team with about 10 VHDL engineers.
    >
    > We avoided to use graphical coding and this worked excellent, so I don't
    >
    > see any reason, why to change this.
    >
    >
    >
    > Thanks a lot,
    >
    > Tobias
    devas, Apr 14, 2014
    #4
  5. Tobias Baumann

    alb Guest

    Hi Tobias,
    Tobias Baumann <> wrote:
    []
    >> Text is written to be read while a schematic is drawn to be looked at.
    >> Without going to far in perception psicology, we often overestimate
    >> visual representation.

    >
    > I think that too, but there's the problem. Today the project leader came
    > and wanted to see the schematic of my toplevel. So he made some trouble,
    > because he as a none FPGA designer (but with experience in designing
    > ASICs) wants to see a schmeatic to understand. Me as developer want to
    > produce results, so I use textfile. If someone wants a schematic, I draw
    > on a sheet of paper. The discussion ends up with "everybody uses
    > schematic coding for the toplevel and it's silly to use VHDL for the
    > toplevel". I really doubt this statement, so I started this discussion
    > to see how others handle the toplevel.


    IIRC Quartus generates top level block level view from your top level
    code and a quick search 'vhdl to schematic converter' can help you out.
    Your project leader point might be a valid one since it reflects an
    habit that is difficult to fight with. You may point out what you *can*
    do with a text file and how much portable the resulting code might be.
    But "there's none so deaf as those who will not hear".

    >> If you do not see any reason, why don't you ask what are the reasons to
    >> your colleague instead. It may simply be "tradition" and then you can
    >> simply forget all your reasonings.

    >
    > The argument is, that it is standard for ASICs, so it has to be standard
    > for FPGAs. But I think the real reason is: He wanted to see a schematic
    > and becasue I have none he created an argument which fits his needs.


    Assuming he does not have an argument is not going to help you easing
    the dispute. Try to see if he accepts an automatically generated
    schematic, this will make everybody happy ;-).

    HTH.

    Al
    alb, Apr 14, 2014
    #5
  6. Tobias Baumann

    HT-Lab Guest

    On 14/04/2014 08:46, Tobias Baumann wrote:

    Hi Tobias,

    > Hi everybody,
    >
    > the question above has been come up between a colleague and me. Should
    > the toplevel module be created as schematic plan or written as text in
    > VHDL?
    >
    > I prefer the second one, my colleague the first.


    I also prefer schematics. If you take 2 groups of engineers and you show
    an FSM bubble diagram to the first group and a few pages of RTL to the
    second, which one do you think will understand the circuit the quickest?

    I also know that most engineers (myself included) still draw bubble
    diagram and flow charts in their log book, so why not use a tool to
    capture that and generate some nice RTL for you. Some engineers like
    ASM's again this is something which is ideally suited for a graphical tool.

    > The only advantage I
    > see for using schematic coding, is that I have a visual overview of my
    > toplevel modul and I quickly can find which blocks are connected together.


    Not only that, it can also aid debugging as most of the visual tools
    allow you to back annotate your simulation results onto the schematics.
    This makes it very easy to single step through your FSM and see what is
    happening. Similarly, if you have a block diagram with a number of
    blocks, when an assertion or breakpoint triggers you can get an
    immediately overview of all the signals to each block.

    >
    > On the other side, the development process is much slower because of
    > using the mouse instead of keyboard.


    Not true, I can open a new diagram in my graphical editor, drag a few
    components from my library, connect the similar names signals with
    another mouse click and finally press the generate button to create some
    nicely formatted VHDL or Verilog.

    > I also think that using textfiles
    > are much easier to handle for revision controlling software like git or
    > svn.


    It is true that AFAIK you can't diff a schematic.

    >
    > Maybe someone can give me a few impressions how you handle the toplevel
    > module. Before I started my new job, we worked at CERN on very large
    > designs with hundreds of moduls in a team with about 10 VHDL engineers.
    > We avoided to use graphical coding and this worked excellent, so I don't
    > see any reason, why to change this.


    I suspect you have never tried it. If you have a design with hundreds of
    modules a spreadsheet like entry method might have helped you connect
    them. When RTL languages came out there was also "a bit" of resistance
    towards them (me included as I firmly believed my Viewlogic was all I
    needed to design my FPGA's) and now we can't live without them.

    Schematic editors are useful addition to an RTL designers tool set.
    However, the reality is that EDA has a small user base and developing
    these tools cost a lot of money so not many engineers can effort them
    and hence their uptake is low.

    You mentioned in a follow-up that you are using Sigasi, have you noticed
    they are adding more and more graphical visualisation to their product,
    I am sure that graphical editing capabilities will come next.

    As with everything in life, "horses for courses".

    Regards,
    Hans.
    www.ht-lab.com

    >
    > Thanks a lot,
    > Tobias
    HT-Lab, Apr 14, 2014
    #6
  7. Tobias Baumann

    Rob Gaddi Guest

    On Mon, 14 Apr 2014 17:15:41 +0100
    HT-Lab <> wrote:

    > I also know that most engineers (myself included) still draw bubble
    > diagram and flow charts in their log book, so why not use a tool to
    > capture that and generate some nice RTL for you. Some engineers like
    > ASM's again this is something which is ideally suited for a graphical tool.
    >


    Actually, I've found that I haven't drawn a straight up bubble diagram
    in ages, and only very rarely bother with flow charts any more.

    One major problem with graphical design is that you're tied to the idea
    that there is a "page size", rather than an infinite 2D plane. That's
    good, because the infinite plane very quickly explodes in complexity.
    But when you've got a page of finite size, then for a design above what
    you can visualize in your head, now you're having to span multiple
    pages. At that point, the continuous visualization is shot and you're
    back to having to mentally stitch together text tags.

    Easier to just write VHDL. Although for the last particularly large
    flowchart I really really needed I threw everyone else out of the
    conference room and designed the flow across the entirety of the
    conference table with 3 colors of Post-Its, tape, and butcher's twine.

    --
    Rob Gaddi, Highland Technology -- www.highlandtechnology.com
    Email address domain is currently out of order. See above to fix.
    Rob Gaddi, Apr 14, 2014
    #7
  8. Tobias Baumann

    Andy Guest

    When in Rome, do as the Romans do. If your team is expecting a top level schematic, you'll probably have to give it to them, at least until you can demonstrate alternate means of giving them the "benefits" they currently think they get from a top level schematic.

    I started out using schematics a long time ago. After initially resisting VHDL, I embraced it and would NEVER go back!

    I will not allow developers to use a schematic at any level to generate their RTL. Schematics generate the VHDL code that may "look pretty", but machine-generated VHDL is not maintainable (unless it can modify the schematic per RTL code changes), so you have to maintain the schematic, which then raises some other questions that should be evaluated:

    Is the schematic tool freely distributable (not just the viewer)?
    Does the schematic provide for generate statements?
    Does the schematic provide for top-level generics?
    What about code comments?

    There are also techniques that can be used to simplify a purely structural VHDL architecture to provide some of the understandability of a WELL-CRAFTED schematic. Use more complex data types than SL & SLV to group related signals together (doues your schematic tool do that?)

    By the time the user generates symbols for each underlying component/entity, and places them and connects them, naming each net, in a WELL CRAFTED schematic, they will have spent FAR more time than writing the code. I have yet to see a decent "beautifier" for schematics. Plenty exist for VHDL.

    However, it takes a lot more than a beautifier to create human-understandable VHDL. Good coding standards, coding for function rather than netlist, etc. go a long way.

    As previously noted, there are good tools for generating graphical documentation from RTL: Sigasi (my favorite), DVT-Eclipse, Understand (sci-tools) and many synthesis tools.

    Displaying single-stepped simulation results on a schematic has got to be the worst excuse I have ever heard! That sounds like something a marketing manager would want to see (or a tool vendor would talk up).

    Andy
    Andy, Apr 14, 2014
    #8
  9. Tobias Baumann

    Dio Gratia Guest

    On Monday, April 14, 2014 7:46:40 PM UTC+12, Tobias Baumann wrote:
    > Hi everybody,
    >
    >
    >
    > the question above has been come up between a colleague and me. Should
    >
    > the toplevel module be created as schematic plan or written as text in VHDL?
    >
    >
    >
    > I prefer the second one, my colleague the first. The only advantage I
    >
    > see for using schematic coding, is that I have a visual overview of my
    >
    > toplevel modul and I quickly can find which blocks are connected together..
    >
    >
    >
    > On the other side, the development process is much slower because of
    >
    > using the mouse instead of keyboard. I also think that using textfiles
    >
    > are much easier to handle for revision controlling software like git or svn.
    >
    >
    >
    > Maybe someone can give me a few impressions how you handle the toplevel
    >
    > module. Before I started my new job, we worked at CERN on very large
    >
    > designs with hundreds of moduls in a team with about 10 VHDL engineers.
    >
    > We avoided to use graphical coding and this worked excellent, so I don't
    >
    > see any reason, why to change this.
    >
    >
    >
    > Thanks a lot,
    >
    > Tobias


    I once wrote a chip design methodology for implementing ASICs at a large corporation.

    If you look at a chip design process (not that different for an FPGA and anASIC) a design specification provides another level of abstraction view ofa design and in general is a superset after implementation of what would go in a data sheet.

    You progress from the most abstract representation to the most detailed (structural based on primitives) implementation. At some point your design specification is updated with pin numbers and other implementation details.

    A design specification is intended to represent agreement between all interested parties what is intended to be (and when updated what is actually) built. It should contain all the necessary information to interact with the target device at a system or software level. Whether or not there are pictures in it (e.g. detailed block diagrams) can be based on whether or not a pictorial representation conveys more information than it occludes.

    Historically the purpose of providing detailed top level information would be to show drive strengths and areas of buffers, allow annular rings to be determined and provide a basis along with a gate count for determining die size, leading to bonding diagrams. All that sort of goes away in FPGAs, where necessary information is generally not kept in VHDL source files, rather part of a design database dependent on a particular vendor's implementation methodology. A design specification can add a one stop shop method of locating the information no matter the implementation method.

    We do design entry at the behavioral level of abstraction for portability which is historically higher for VHDL than Verilog. Schematic entry is likely to prove useless for later incorporating a design specification into an ASIC should volumes dictate. That level of structural detail requires replication in any event. The only helpful thing might be a hierarchical abstraction where the top level does bidirectional to single rail break out. Andthat also tends to define what's in a top level detailed block diagram.

    Note this is implementation detail while VHDL is design entry, optionally with a structural view post synthesis. It's generally not necessary in an FPGA design flow which provides the same information through other means. Ingeneral you don't design to the structural level instead counting on synthesis which uses a vendor's established methodology typically not including a structural schematic top level.

    Now add to that that some of us have done large pin count chip designs where no matter what you do a top level schematic showing all the pins - potentially buffer types, signal name switches and bidirectional to single rail conversions becomes nothing but a glorified net list.

    You could also note that the objective is to build hardware not win arguments.
    If it likely means extra work for you it ought to be justified by the design process deliverables and you could always argue schedule time.
    Dio Gratia, Apr 14, 2014
    #9
  10. Tobias Baumann

    HT-Lab Guest

    Hi Andy,

    On 14/04/2014 18:24, Andy wrote:
    > When in Rome, do as the Romans do. If your team is expecting a top level schematic, you'll probably have to give it to them, at least until you can demonstrate alternate means of giving them the "benefits" they currently think they get from a top level schematic.


    I can see a clear "benefit" if you have to explain your design to
    somebody not familiar with your design.

    >
    > I started out using schematics a long time ago. After initially resisting VHDL, I embraced it and would NEVER go back!


    The point is that you are not going back, tool and technology evolve and
    so have graphical design entry tools (although they are actually design
    entry and management tools to use the proper marketing term, graphics is
    only a small part of their capabilities). We are not talking about
    connecting AND/OR gate together, we are talking about parts of the
    design process which can benefit from schematics.

    >
    > I will not allow developers to use a schematic at any level to generate their RTL.


    Glad I am not working for you ;-)

    > Schematics generate the VHDL code that may "look pretty", but machine-generated VHDL is not maintainable (unless it can modify the schematic per RTL code changes),


    With modern design entry tools the sole aim is to generate perfect RTL,
    the output of the tool is VHDL/Verilog not schematics! The schematic is
    just a method to help you create your RTL.

    > so you have to maintain the schematic,


    No why? I often use my design entry tool to connect some blocks
    together, generate a testbench framework, or an FSM and then I continue
    in VHDL, this is quicker and less error prone then doing it manually.

    > which then raises some other questions that should be evaluated:
    >
    > Is the schematic tool freely distributable (not just the viewer)?


    AFAIK no, most viewers are.

    > Does the schematic provide for generate statements?


    Yes.

    > Does the schematic provide for top-level generics?


    Of course.

    > What about code comments?


    Real man don't use comments....

    Clearly you have never looked at a modern (graphical) design entry tool.

    >
    > There are also techniques that can be used to simplify a purely structural VHDL architecture to provide some of the understandability of a WELL-CRAFTED schematic. Use more complex data types than SL & SLV to group related signals together (doues your schematic tool do that?)


    Yes, you can use records.

    >
    > By the time the user generates symbols for each underlying component/entity, and places them and connects them, naming each net, in a WELL CRAFTED schematic, they will have spent FAR more time than writing the code.


    Again, you should really have a look at a modern design entry tool. The
    symbols are generated automatically, connecting them can be done with a
    single mouse click. The funny thing is that I now find it very tedious
    to connect blocks manually, it is much quicker to let the tool do it for
    me. The same applies to FSM, if somebody doesn't like my n-process FSM,
    no problem a few mouse clicks and I have an m-process one.

    > I have yet to see a decent "beautifier" for schematics.


    yes, don't believe there are any, I have also never seen a tool that can
    create nice graphics from RTL no matter how expensive they are.

    > Plenty exist for VHDL.


    mmmmm, I wouldn't say plenty and the once I looked at all have issues.

    >
    > However, it takes a lot more than a beautifier to create human-understandable VHDL. Good coding standards, coding for function rather than netlist, etc. go a long way.


    I agree and for this reasons most design entry tools will give you a lot
    of options to generate the code you want, again these tools are designed
    to generate RTL not schematics. Some of the design entry tool also
    provide linting capabilities so you can check that your code is adhering
    to your coding standards.

    >
    > As previously noted, there are good tools for generating graphical documentation from RTL: Sigasi (my favorite), DVT-Eclipse, Understand (sci-tools) and many synthesis tools.


    If you like these tools then you will be amazed what a high-end
    purposely designed design entry tool can do for you. Unfortunately as I
    mentioned in my previous post you need a healthy EDA budget to purchase
    them.

    >
    > Displaying single-stepped simulation results on a schematic has got to be the worst excuse I have ever heard! That sounds like something a marketing manager would want to see (or a tool vendor would talk up).


    So when you use your simulator (assuming Modelsim) do you use the list
    window or do you look at the waveform window, perhaps the FSM window or
    dataflow window? If you look at simulator development over the years you
    will see more and more graphical windows. Mentor's Questa includes a
    schematic window similar to what you get from a synthesis tool.
    The point is that graphics may help you debug your code being it by back
    annotating your simulation results on a block diagram or even animation
    of your FSM (exists). I am not advocating people should use them, I
    would just say use whatever works for you.

    I can understand why somebody might be sceptical but to re-iterate my
    point, these are tools to help you design your RTL, they are not moving
    your design into some graphical tools domain from which there is no
    escape. The output is always nicely formatted, readable, editable RTL as
    that is what they are designed for.

    Now back to debugging my SystemC code with printf statements....

    Regards,
    Hans.
    www.ht-lab.com



    >
    > Andy
    >
    HT-Lab, Apr 15, 2014
    #10
  11. Tobias Baumann

    alb Guest

    Andy <> wrote:
    > As previously noted, there are good tools for generating graphical
    > documentation from RTL: Sigasi (my favorite), DVT-Eclipse, Understand
    > (sci-tools) and many synthesis tools.


    there's this interesting tool out there which does not convert vhdl to
    schematics but does the opposite [1]. Unfortunately the developers do not
    want to release the code, but among the 'enhancements' they list:

    - ability to import VHDL or Verilog code for viewing as block-diagram.

    I find the GUI pretty slick and straight forward but the tool is way too
    rudimental and it seg. faults quite too often to be usable. Last update
    of the project page is 2003... :-/

    The tool is distributed free of charge.

    Al

    [1] http://www.atl.external.lmco.com/projects/rassp2/vgui/index.html
    alb, Apr 15, 2014
    #11
  12. Tobias Baumann

    alb Guest

    Hi Hans,
    HT-Lab <> wrote:
    []
    > Now back to debugging my SystemC code with printf statements....


    The greatest advantage of 'tracing' (debugging with printf) over other
    debugging techniques is that you are forced to *read* your code and
    understand it!

    We often brag about new tools and the power they have, simply forgetting
    old ones together with their values ;-)

    Al
    alb, Apr 15, 2014
    #12
  13. Tobias Baumann

    Andy Guest

    Hans,

    Which (single) Graphical Design Entry tool provides all these features you mention?

    Several years ago one of our sister sites was using a Mentor graphics tool ("HDL Designer" or something like that?) but it was very primitive. I have not looked at it lately... perhaps I should. I am always open to new ways of doing things, but only if they are actually better ways!

    Do you only use the tool as the initial entry for the VHDL, and then maintain the design at the vhdl level? If so, how good is that initial schematic after you've made maintenance modifications to the VHDL?

    As Dio mentioned above, many organizations believe that a schematic representation of the top (few) structural level(s) of the design eliminates the need for a Design Specification (including requirements, interface specifications, block diagrams, design constraints etc.) before a single block is placed on a schematic, or a single line of code is written.

    Schematic diagrams tend to be too detailed to serve as an overview, yet notdetailed enough to dismiss with reviewing/augmenting the code itself, especially if the code is maintained outside the graphical environement.

    If, on the other hand, the design is always maintained at the graphical level, then you have to keep that tool around for the life of the product (which, depending on your market, may be decades longer than the tool vendor intends to support the tool).

    If my favorite VHDL editor is no longer available or supported, I can seamlessly bring the design up in a new editor. I can't tell you how many editors I have used over the decades I've been designing FPGAs in VHDL, and none of them had any problem with even the oldest code I opened in them! I take that back... a recent new-to-me editor (IDE) tried to tell me I had a bug for using a reserved PSL keyword in a non-PSL context.

    While most IDEs will not automatically generate an acceptable block/state diagram (visually unorganized), many will export that diagram in an editableform (not pixels!) for augmenting documentation.

    BTW, Who I will work for (or allow to work for me) also has a lot to do with how bad I want my paycheck!

    Andy
    Andy, Apr 15, 2014
    #13
  14. Tobias Baumann

    HT-Lab Guest

    Hi Andy,

    On 15/04/2014 17:50, Andy wrote:
    > Hans,
    >
    > Which (single) Graphical Design Entry tool provides all these features you mention?
    >
    > Several years ago one of our sister sites was using a Mentor graphics tool ("HDL Designer" or something like that?) but it was very primitive. I have not looked at it lately... perhaps I should. I am always open to new ways of doing things, but only if they are actually better ways!


    Yes, that is the one I am using. Perhaps you looked at it in the old
    days when it was called Renoir. Nowadays it is a (massive) design entry
    and management tool, graphics is just a minor part of it.

    >
    > Do you only use the tool as the initial entry for the VHDL, and then maintain the design at the vhdl level?


    I do both, I sometimes use the tool to prototype the structure/testbench
    and other times I stay within the tool for the duration of the project.
    I only use graphics for the top level (unless I have lots of components
    at a lower level), testbench and FSM's.

    > If so, how good is that initial schematic after you've made maintenance modifications to the VHDL?


    Unfortunately you can't, you can only have one master (you can however
    easily switch between a VHDL and schematic version for the same module).

    >
    > As Dio mentioned above, many organizations believe that a schematic representation of the top (few) structural level(s) of the design eliminates the need for a Design Specification (including requirements, interface specifications, block diagrams, design constraints etc.) before a single block is placed on a schematic, or a single line of code is written.
    > Schematic diagrams tend to be too detailed to serve as an overview, yet not detailed enough to dismiss with reviewing/augmenting the code itself, especially if the code is maintained outside the graphical environement.
    >
    > If, on the other hand, the design is always maintained at the graphical level, then you have to keep that tool around for the life of the product (which, depending on your market, may be decades longer than the tool vendor intends to support the tool).


    I agree it is never a good idea to have a design locked to a particular
    tool although nowadays this is becoming increasingly difficult. But this
    is not an issue with HDL Designer as the output is always a set of RTL
    files.

    >
    > If my favorite VHDL editor is no longer available or supported, I can seamlessly bring the design up in a new editor. I can't tell you how many editors I have used over the decades I've been designing FPGAs in VHDL, and none of them had any problem with even the oldest code I opened in them! I take that back... a recent new-to-me editor (IDE) tried to tell me I had a bug for using a reserved PSL keyword in a non-PSL context.


    Same here, my current favourite is notepad++.

    >
    > While most IDEs will not automatically generate an acceptable block/state diagram (visually unorganized), many will export that diagram in an editable form (not pixels!) for augmenting documentation.
    >
    > BTW, Who I will work for (or allow to work for me) also has a lot to do with how bad I want my paycheck!


    I understand,

    Regards,
    Hans.
    www.ht-lab.com


    >
    > Andy
    >
    HT-Lab, Apr 16, 2014
    #14
  15. Tobias Baumann

    rickman Guest

    On 4/14/2014 7:05 AM, Tobias Baumann wrote:
    > Am 14.04.2014 10:56, schrieb alb:
    >> Text is written to be read while a schematic is drawn to be looked at.
    >> Without going to far in perception psicology, we often overestimate
    >> visual representation.

    >
    > I think that too, but there's the problem. Today the project leader came
    > and wanted to see the schematic of my toplevel. So he made some trouble,
    > because he as a none FPGA designer (but with experience in designing
    > ASICs) wants to see a schmeatic to understand. Me as developer want to
    > produce results, so I use textfile. If someone wants a schematic, I draw
    > on a sheet of paper. The discussion ends up with "everybody uses
    > schematic coding for the toplevel and it's silly to use VHDL for the
    > toplevel". I really doubt this statement, so I started this discussion
    > to see how others handle the toplevel.


    I work for myself so I have no boss over me to impose restrictions. But
    I can "see" a lot better than I can read through all the minutiae of a
    text file. A picture is worth a kiloword. Still, I never use a top
    level diagram for HDL. But I do draw a diagram as part of the
    documentation... sometimes.

    I used a tool many years ago that represented the requirements
    decomposition graphically. In the grand scheme of things it didn't work
    out but mostly because we had no idea how to decompose requirements
    rather than any limitation of the tool. However I never saw any
    advantage to the tool either. Manipulating the information graphically
    was some extra work I think and I never saw much return in the way of
    verification or other checking our work. :(


    > I use Sigasi, which is perfect for me. It helps me to get quickly
    > through a design. But even editors with VHDL highlighting are enough. It
    > depends a bit on the quality of the source code.


    Just like your boss is used to diagrams, code bangers are used to text
    tools. That is preference rather than advantage I think.


    >> If you do not see any reason, why don't you ask what are the reasons to
    >> your colleague instead. It may simply be "tradition" and then you can
    >> simply forget all your reasonings.

    >
    > The argument is, that it is standard for ASICs, so it has to be standard
    > for FPGAs. But I think the real reason is: He wanted to see a schematic
    > and becasue I have none he created an argument which fits his needs.


    What? Since when is a top level diagram standard for ASICs? I'd be
    willing to bet just the opposite is true. ASICs are nearly *all* HDL
    with no diagrams.

    --

    Rick
    rickman, Apr 18, 2014
    #15
  16. Tobias Baumann

    HT-Lab Guest

    On 18/04/2014 19:02, rickman wrote:
    ...
    >>
    >> The argument is, that it is standard for ASICs, so it has to be standard
    >> for FPGAs. But I think the real reason is: He wanted to see a schematic
    >> and becasue I have none he created an argument which fits his needs.

    >
    > What? Since when is a top level diagram standard for ASICs? I'd be
    > willing to bet just the opposite is true. ASICs are nearly *all* HDL
    > with no diagrams.
    >


    I also question that, however, look at some of the comments from an
    relative old 2004 DeepChip postings:

    http://www.deepchip.com/items/dac03-07.html

    looks like graphics are used,

    Regards,
    Hans
    www.ht-lab.com
    HT-Lab, Apr 18, 2014
    #16
  17. Tobias Baumann

    rickman Guest

    On 4/18/2014 3:15 PM, HT-Lab wrote:
    > On 18/04/2014 19:02, rickman wrote:
    > ..
    >>>
    >>> The argument is, that it is standard for ASICs, so it has to be standard
    >>> for FPGAs. But I think the real reason is: He wanted to see a schematic
    >>> and becasue I have none he created an argument which fits his needs.

    >>
    >> What? Since when is a top level diagram standard for ASICs? I'd be
    >> willing to bet just the opposite is true. ASICs are nearly *all* HDL
    >> with no diagrams.
    >>

    >
    > I also question that, however, look at some of the comments from an
    > relative old 2004 DeepChip postings:
    >
    > http://www.deepchip.com/items/dac03-07.html
    >
    > looks like graphics are used,


    I don't follow. There are a lot of comments and many were negative
    regarding the schematic capture. Further, it is not clear which of
    these are used for FPGA and which are used for ASICs.

    I see no evidence that drawing schematics is "standard" for designing
    ASICs.

    --

    Rick
    rickman, Apr 19, 2014
    #17
  18. Tobias Baumann

    HT-Lab Guest

    On 19/04/2014 08:16, rickman wrote:
    > On 4/18/2014 3:15 PM, HT-Lab wrote:
    >> On 18/04/2014 19:02, rickman wrote:
    >> ..
    >>>>
    >>>> The argument is, that it is standard for ASICs, so it has to be
    >>>> standard
    >>>> for FPGAs. But I think the real reason is: He wanted to see a schematic
    >>>> and becasue I have none he created an argument which fits his needs.
    >>>
    >>> What? Since when is a top level diagram standard for ASICs? I'd be
    >>> willing to bet just the opposite is true. ASICs are nearly *all* HDL
    >>> with no diagrams.
    >>>

    >>
    >> I also question that, however, look at some of the comments from an
    >> relative old 2004 DeepChip postings:
    >>
    >> http://www.deepchip.com/items/dac03-07.html
    >>
    >> looks like graphics are used,

    >
    > I don't follow. There are a lot of comments and many were negative
    > regarding the schematic capture. Further, it is not clear which of
    > these are used for FPGA and which are used for ASICs.
    >
    > I see no evidence that drawing schematics is "standard" for designing
    > ASICs.
    >


    That was not the point, I agree that schematics are not standard in the
    ASIC world, the link was to counter your *all* argument.

    Regards,
    Hans.
    www.ht-lab.com
    HT-Lab, Apr 22, 2014
    #18
  19. Tobias Baumann

    valtih1978 Guest


    > I also prefer schematics. If you take 2 groups of engineers and you show
    > an FSM bubble diagram to the first group and a few pages of RTL to the
    > second, which one do you think will understand the circuit the quickest?


    I wonder how many people confuse top-level structure from the FSM
    (behavioural diagram). Might be your tools can generate nice VHDL out of
    Abstract State Machines. And What it has to do with the question?
    valtih1978, Apr 24, 2014
    #19
  20. Tobias Baumann

    alb Guest

    Hi valtih1978,
    valtih1978 <> wrote:
    >> I also prefer schematics. If you take 2 groups of engineers and you show
    >> an FSM bubble diagram to the first group and a few pages of RTL to the
    >> second, which one do you think will understand the circuit the quickest?

    >
    > I wonder how many people confuse top-level structure from the FSM
    > (behavioural diagram). Might be your tools can generate nice VHDL out of
    > Abstract State Machines. And What it has to do with the question?


    To some extent, Hans's point is about conveying information through a
    graphical mean rather than a listing and have the two means
    synchronized. IMHO his point of view is not OT.
    alb, Apr 24, 2014
    #20
    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. Michael Dunbar

    Actel Desktop Schematic Viewer

    Michael Dunbar, Sep 16, 2003, in forum: VHDL
    Replies:
    0
    Views:
    638
    Michael Dunbar
    Sep 16, 2003
  2. Sleep Mode

    Xilinx ISE schematic design

    Sleep Mode, May 4, 2004, in forum: VHDL
    Replies:
    0
    Views:
    1,787
    Sleep Mode
    May 4, 2004
  3. ZackS
    Replies:
    5
    Views:
    6,781
    Just an Illusion
    Jul 9, 2004
  4. ALuPin
    Replies:
    1
    Views:
    2,178
    Subroto Datta
    Apr 1, 2005
  5. Trans
    Replies:
    30
    Views:
    309
    Yukihiro Matsumoto
    Aug 24, 2006
Loading...

Share This Page