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

 

[devas]

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

 

[rickman]

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

 

[HT-Lab]

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

 

[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,
valtih1978 <do@not.email.me> 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.

 

[valtih1978]

I like to explain students that representation is more structural at the
higher levels of abstraction. It is because you start design at the top
level. You refine the design by implementing the components (defining
their structure). At the bottom level you have the gates. As VHDL
designer you know that components do not have the structure at the
bottom level. You describe the elementary components by behavioral
processes. Now, you understand that the top level is necessarily has
known structure. Might be this intuition is taken too far by some bigots
but the big picture of the World seems to be really useful in any case.

 

[rickman]

On 4/22/2014 11:06 AM, HT-Lab wrote:

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.

And that is why I say "nearly" all.

--

Rick

 

[Anssi Saari]

Tobias Baumann <ttobsen@hotmail.com> writes:

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.

But that kind of overview is usually provided by synthesis tools, no?
Quartus does, years ago when I used Precision it did it too. Can't
remember off hand if other tools can do that.

Maybe someone can give me a few impressions how you handle the
toplevel module.

Once upon a time a coworker created an automated tool to build the
toplevel or in fact the whole hierarchy. It operated on a simple config
file and some very simple rules for connecting signals. Basically if two
modules on the same level had a matching input and output those would be
connected together, otherwise the signal would be pushed up in the
hierarchy. It was for Verilog though and the IP is owned by Ericsson so
not available for general consuption. Too bad really. But automation
over tedium is my first choice.

These days, as Emacs can copy a VHDL entity and paste it as an instance
and signals it's fairly obvious what I prefer as an Emacs user. I had to
take a look at an old hybrid schematic / VHDL design recently which was
done in MaxPlus and I thought it was a filthy mess and very difficult to
figure out what connected where. Of course the readability of a
schematic depends on whoever did the schematic. I guess you could
obfuscate a VHDL toplevel too if you really wanted to.

Some years ago I was in a company where they used I think HDL
Designer. It at least generated reasonable VHDL from the visual
representation so portability wasn't an issue. OTOH, the GUI drawing
part was pretty awful. Autosave with no undo made for a pretty terrible
experience. One false move and spend hours fixing the result...

Related to this, I'd like to get the top level entity and FPGA pin list
from the schematic automagically. I had the pin list part once upon a
time and it was great. I wonder how common this is in schematic tools?
Recently I wrote a few lines of Python to convert from some kind of pin
info from PADS to Quartus pin assignments. Another time years ago some
other Mentor schematic tool could produce a UCF file for Xilinx. Very
handy as the FPGA in that project had over 1000 pins...