Design toplevel module as schematic?

[Tobias Baumann]

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

 

[alb]

Hi Tobias,

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

 

[Tobias Baumann]

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.

 

[devas]

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.

 

[alb]

Hi Tobias,

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

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

 

[HT-Lab]

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

 

[Rob Gaddi]

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.

 

[Andy]

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

 

[Dio Gratia]

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.

 

[HT-Lab]

Hi Andy,

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

 

[alb]

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]

Hi Hans,

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

 

[Andy]

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

 

[HT-Lab]

Hi Andy,

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

 

[rickman]

Am 14.04.2014 10:56, schrieb alb:

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.

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.

 

[HT-Lab]

On 18/04/2014 19:02, rickman wrote:
...

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

 

[rickman]

On 18/04/2014 19:02, rickman wrote:
..

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.

 

[HT-Lab]

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

 

[valtih1978]

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?

 

[alb]

Hi valtih1978,

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.