---------------------------------------- > Date: Mon, 23 Mar 2015 07:55:31 +0100 > From: [email protected] > To: [email protected] > Subject: Re: [Ghdl-discuss] About -gNAME=VALUE > > On 20/03/15 08:08, Hannu Vuolasaho wrote: >> >> >> ---------------------------------------- >>> Date: Fri, 20 Mar 2015 06:48:36 +0100 >>> From: [email protected] >>> To: [email protected] >>> Subject: Re: [Ghdl-discuss] About -gNAME=VALUE >>> >>> >>> So ideas and proposals are welcome! >> >> I have one itch which would be nice to scratch. >> >> When working on design I sometimes just make terrible mistakes and >> and put wrong element in wrong place or actually connect it all wrong. >> >> I have been thinking about how to get the structure of my design in such >> way that it would be fast to understand. >> >> As always some block diagram generation would be nice and graphviz >> generates them nicely. Could this be one possible feature? > > There is currently the --disp-tree option which displays the structure > of the design. It wouldn't be hard to generate instead a dot file, > but I am not sure that this is exactly what you need. > > If you want to have progress, it would be welcome to have a small > example of a vhdl design with an example of a dot file.
I spent some time thinking about this today. I started with my most common
problem. What is the interface of some entity.
I came up this kind of graph:
digraph entity_doc{
rankdir=LR;
pyth_tb_pyth[shape="record" label="pythagora_s_triangle (structural)|
{Generics|{in_width_g (16) |out_width_g (16) }}|
{Constants|{speed_of_light_c (300000000)}}|
{{<clk_pyth>clk|<rst_n_pyth>rst_n|
<a_in_pyth>a_in|<b_in_pyth>b_in}|
{<c_out_pyth>c_out}}|
"];
}
This draws some boxes and gives information of input and output names.
It also looks something which could be put on docs on front page.
However usually there is always some other entities and their instances.
So I designed some structural entity. It is the pyth part of the graph.
Inputs and outputs are plain texts and arrow show which instance they
connect and which direction.
Pyth's generics and constants are shown in their own boxes and if there
were signals which would be used something else than just connecting the
instances, they would also have own box.
As I hadn't any process, I wrote testbench diagram. Now when the signals
aren't port-signal-port type, they are shown. Does GHDL know which
process read and write signal? So that arrows can have directions. How to show
sensitivity list or clock and reset?
Generics have notation of generic (default) [evaluated from mapping] set value
Some kind of mapping should show how generic values propagate
through design. I don't like how I solved them and how there should
be some arrow to show the mapping or nice visual stuff.
On the dot file there is commented out the notation of the entity record
and how I think there won't be any naming conflicts.
Also there is commented out part which makes connections having
type information. Sometimes very needed information and sometimes
just messes the graph. Another option I think would be nice to hide
some connections commenting out rst_n and clk makes the graph
much more readable. And how deep recursion there is to open up
the hierarchy.
This doesn't cover all the possibilities of VHDL but I think it is for a start.
I believe everyone can implement the pythagora_s_triangle entity after
seeing that graph.
So now comes to the questions. How hard that kind of output would be
to add GHDL? And is it desirable or totally useless or has someone
already done this?
The big design below and also as attachment if it gets through.
Best regards,
Hannu Vuolasaho
digraph highest_detail{
rankdir=LR;
subgraph cluster_pyth{
//Name of instance\nentity name (arch)
label="pyth\npythagora_s_triangle (structural)";
node [shape=record];
//Generics of pyth (default) set
pythagora_s_triangle_generics [label="Generics|{in_width_g|(16) [32]}|
{out_width_g|(16) [32]}"];
//Constants of pyth
Pythagora_s_triangle_constants [label="Constants|
{speed_of_light_c|300000000}"];
pyth_square_a[label="square (my_arch)|
{Generics|{in_width_g (16) [32]|out_width_g (16) [32]}}|
{ Constants| { meaning_of_life_c (42)}}|
{{<clk_square_a>clk|<rst_n_square_a>rst_n|
<input_unsigned_square_a>input_unsigned}|
{<output_squared_square_a>output_squared}
}|
square_a"];
//entity, generics, constants input, outputs and instance own lines.
pyth_adder_a_b[label="adder (my_arch)|
{Generics|{in_width_g (16) [32]|out_width_g (16) [32]}}|
{Constants|{sum_of_all_fears_c (2)}}|
{{<clk_adder_a_b>clk|<rst_n_adder_a_b>rst_n|
<a_adder_a_b>a|<b_adder_a_b>b}|
<sum_adder_a_b>sum}|
adder_a_b"];
//Sample naming idea.
//name_of_instance_in_hierarchy[label="entity_name (arch_name)|
//{Generics|{generic1 (default) [evaluated] set|generic2
(default)[evaluated] set}}|
//{Constants|{constant (value)}|
//{{<input_name1_instance_name>input_name|
// <input_name2_instance_name>input_name2}|
//<output_name_instance_name>output_name}|
//instance_name"];
pyth_square_b[label="square (my_arch)|
{Generics|{in_width_g (16) [32]|out_width_g (16) [32]}}|
{Constants|{meaning_of_life_c (42)}}|
{{<clk_square_b>clk|<rst_n_square_b>rst_n|
<input_unsigned_square_b>input_unsigned}|
{<output_squared_square_b>output_squared}}|
square_b"];
pyth_sqrt[label="square_root (my_arch)|
{Generics|{in_width_g (16) [32]|out_width_g (16) [32]}}|
{Constants|{hundred_sqrt2_c (141)}}|
{{<clk_sqrt>clk|<rst_n_sqrt>rst_n|
<input_squared_sqrt>input_squared}|
{<output_squre_root_sqrt>output_squre_root}}|
squarert"];
//Top level connections
pyth_clk [shape="plaintext" label="clk"];
pyth_rst_n [shape="plaintext" label="rst_n"];
pyth_a_in [shape="plaintext" label="a_in"];
pyth_b_in [shape="plaintext" label="b_in"];
pyth_c_out [shape="plaintext"label="c_out"];
//Hierarchy
/*
pyth_clk -> pyth_square_a:clk_square_a [label="std_logic"];
pyth_clk -> pyth_square_b:clk_square_b [label="std_logic"];
pyth_clk -> pyth_adder_a_b:clk_adder_a_b [label="std_logic"];
pyth_clk -> pyth_sqrt:clk_sqrt [label="std_logic"];
pyth_rst_n -> pyth_square_a:rst_n_square_a [label="std_logic"];
pyth_rst_n -> pyth_square_b:rst_n_square_b [label="std_logic"];
pyth_rst_n ->pyth_adder_a_b:rst_n_adder_a_b [label="std_logic"];
pyth_rst_n -> pyth_sqrt:rst_n_sqrt [label="std_logic"];
pyth_a_in -> pyth_square_a:input_unsigned_square_a
[label="std_logic_vector(31 downto 0)"];
pyth_b_in -> pyth_square_b:input_unsigned_square_b
[label="std_logic_vector(31 downto 0)"];
pyth_square_a:output_squared_square_a -> pyth_adder_a_b:a_adder_a_b
[label="std_logic_vector(31 downto 0)"];
pyth_square_b:output_squared_square_b -> pyth_adder_a_b:b_adder_a_b
[label="std_logic_vector(31 downto 0)"];
pyth_adder_a_b:sum_adder_a_b -> pyth_sqrt:input_squared_sqrt
[label="std_logic_vector(31 downto 0)"];
pyth_sqrt:output_squre_root_sqrt -> pyth_c_out
[label="std_logic_vector(31 downto 0)"];
*/
pyth_clk -> pyth_square_a:clk_square_a;
pyth_clk -> pyth_square_b:clk_square_b;
pyth_clk -> pyth_adder_a_b:clk_adder_a_b;
pyth_clk -> pyth_sqrt:clk_sqrt;
pyth_rst_n -> pyth_square_a:rst_n_square_a;
pyth_rst_n -> pyth_square_b:rst_n_square_b;
pyth_rst_n ->pyth_adder_a_b:rst_n_adder_a_b;
pyth_rst_n -> pyth_sqrt:rst_n_sqrt;
pyth_a_in -> pyth_square_a:input_unsigned_square_a;
pyth_b_in -> pyth_square_b:input_unsigned_square_b;
pyth_square_a:output_squared_square_a -> pyth_adder_a_b:a_adder_a_b;
pyth_square_b:output_squared_square_b -> pyth_adder_a_b:b_adder_a_b;
pyth_adder_a_b:sum_adder_a_b -> pyth_sqrt:input_squared_sqrt;
pyth_sqrt:output_squre_root_sqrt -> pyth_c_out;
}
subgraph cluster_pyth_tb{
label="pyth_tb\npythagoras_bench (sitting_and_lookin_at_sea)";
pyth_tb_test_process [label="test_process"];
pyth_tb_generics [shape="record" label="Generics|{in_width_g|() 32}|
{out_width_g|() 32}"];
pyth_tb_signals [shape="record" label="Signals|<clk_pyth_tb>clk|
<rst_n_pyth_tb>rst_n|<a_pyth_tb>a|<b_pyth_tb>b|<c_pyth_tb>c"];
pyth_tb_pyth[shape="record" label="pythagora_s_triangle (structural)|
{Generics|{in_width_g (16) [32]|out_width_g (16) [32]}}|
{Constants|{speed_of_light_c (300000000)}}|
{{<clk_pyth>clk|<rst_n_pyth>rst_n|
<a_in_pyth>a_in|<b_in_pyth>b_in}|
{<c_out_pyth>c_out}}|
pyth"];
pyth_tb_test_process -> pyth_tb_signals:clk_pyth_tb;
pyth_tb_test_process -> pyth_tb_signals:rst_n_pyth_tb;
pyth_tb_test_process -> pyth_tb_signals:a_pyth_tb;
pyth_tb_test_process -> pyth_tb_signals:b_pyth_tb;
pyth_tb_signals:c_pyth_tb -> pyth_tb_test_process;
pyth_tb_signals:clk_pyth_tb -> pyth_tb_pyth:clk_pyth;
pyth_tb_signals:rst_n_pyth_tb -> pyth_tb_pyth:rst_n_pyth;
pyth_tb_signals:a_pyth_tb -> pyth_tb_pyth:a_in_pyth;
pyth_tb_signals:b_pyth_tb -> pyth_tb_pyth:b_in_pyth;
pyth_tb_pyth:c_out_pyth -> pyth_tb_signals:c_pyth_tb;
}
}
highest.dot
Description: MS-Word document
justfordoc.dot
Description: MS-Word document
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
