Which to learn: Verilog vs. VHDL?

[Brian Drummond]

On Wed, 09 Jan 2013 04:59:25 -0800, Michael S wrote:

On Jan 8, 3:02 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
On Mon, 07 Jan 2013 10:47:43 -0800, jonesandy wrote:
Verilog has so many rabbit holes that look like they should work,
but don't, and if you don't use a separate linter, you'll never find
them.

Rabbit holes ... I like it! that was my impression on the brief look I
took at Verilog, and I have never had to use it (other than adding DDR2
memories to my VHDL projects).

From that I learn that so far you managed to avoid qsys.

Apparently it's an Altera tool. Yes I have, so far.

Yesterday I looked (again) at VHDL-2008 additions.
I like few of them.

By comparison to 2 items above, (all) specification in sensitivity list
may look as minor addition, but until now those error-prone sensitivity
list were the main reason for me to avoid combinatorial processes
altogether. Now I can reconsider.

I think it's a harmless addition, but I've never found a role for
combinational processes anyway!

Would also be nice to see an interface to proof tools, along the lines
of SPARK
I don't consider proof tools particularly useful.

Understandable. They have been around since the 80s, but it's only in the
last couple of years they have started to gain any traction.

- Brian

 

[Michael S]

On Jan 10, 2:28 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:

On Wed, 09 Jan 2013 04:59:25 -0800, Michael S wrote:
On Jan 8, 3:02 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
On Mon, 07 Jan 2013 10:47:43 -0800, jonesandy wrote:
 Verilog has so many rabbit holes that look like they should work,
but don't, and if you don't use a separate linter, you'll never find
them.

Rabbit holes ... I like it! that was my impression on the brief look I
took at Verilog, and I have never had to use it (other than adding DDR2
memories to my VHDL projects).

From that I learn that so far you managed to avoid qsys.

Apparently it's an Altera tool. Yes I have, so far.

Yesterday I looked (again) at VHDL-2008 additions.
I like few of them.
By comparison to 2 items above, (all) specification in sensitivity list
may look as minor addition, but until now those error-prone sensitivity
list were the main reason for me to avoid combinatorial processes
altogether. Now I can reconsider.

I think it's a harmless addition, but I've never found a role for
combinational processes anyway!

I am thinking about one specific use case.
<code>
signal bar, bar0, bar1 : bar_record_t;
begin
x:foo1 port map (..., bar_out => bar);

process (all)
begin
bar0 <= bar;
bar1 <= bar;
bar0.valid <= bar.valid and not addr(5);
bar1.valid <= bar.valid and addr(5);
end process;

y0:foo2 port map (bar_inp => bar0, ...);
y1:foo2 port map (bar_inp => bar1, ...);
</code>

Pay attention that combinatorial process is required only because of
not sufficiently powerful syntax for concurrent assignment of record
types.
I'd very much prefer to write (outside of the process) something like:

bar0 <= (valid => bar.valid and not addr(5), others => from bar);

May be, in the next VHDL edition?

 

[Brian Drummond]

On Thu, 10 Jan 2013 02:35:05 -0800, Michael S wrote:

On Jan 10, 2:28 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
On Wed, 09 Jan 2013 04:59:25 -0800, Michael S wrote:

Yesterday I looked (again) at VHDL-2008 additions.
By comparison to 2 items above, (all) specification in sensitivity
list may look as minor addition, but until now those error-prone
sensitivity list were the main reason for me to avoid combinatorial
processes altogether. Now I can reconsider.

I think it's a harmless addition, but I've never found a role for
combinational processes anyway!

I am thinking about one specific use case.
code
I can see the rationale for that use case.

I'd very much prefer to write (outside of the process) something like:
bar0 <= (valid => bar.valid and not addr(5), others => from bar);

I appreciate the desire for this in a future VHDL.

Meanwhile, this is a good place for a function.

It can be declared locally, but my solution is to treat bar_record_t as
an abstract type. Wrap it in a package along with functions to manipulate
it.

package bar_type is
type bar_record_t is...
function validate (B : bar_record_t; V : bar_valid_t)
return bar_record_t;
....
end bar_type;

-- in the package body
function validate (B : bar_record_t; V : bar_valid_t)
return bar_record_t is
variable temp: bar_record_t := B;
begin
temp.valid := V;
return temp;
end validate;

Then the main code simply reads:

bar0 <= bar_type.validate(bar, bar.valid and not addr(5));
bar1 <= bar_type.validate(bar, bar.valid and addr(5));

To my eyes, this makes the main code cleaner, so I wouldn't even
contemplate a combinational process here.

- Brian

 

[Michael S]

On Jan 10, 3:27 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:

On Thu, 10 Jan 2013 02:35:05 -0800, Michael S wrote:
On Jan 10, 2:28 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
On Wed, 09 Jan 2013 04:59:25 -0800, Michael S wrote:
Yesterday I looked (again) at VHDL-2008 additions.
By comparison to 2 items above, (all) specification in sensitivity
list may look as minor addition, but until now those error-prone
sensitivity list were the main reason for me to avoid combinatorial
processes altogether. Now I can reconsider.

I think it's a harmless addition, but I've never found a role for
combinational processes anyway!
I am thinking about one specific use case.
code

I can see the rationale for that use case.

I'd very much prefer to write (outside of the process) something like:
bar0 <= (valid => bar.valid and not addr(5), others => from bar);

I appreciate the desire for this in a future VHDL.

Meanwhile, this is a good place for a function.

It can be declared locally, but my solution is to treat bar_record_t as
an abstract type. Wrap it in a package along with functions to manipulate
it.

package bar_type is
type bar_record_t is...
function validate (B : bar_record_t; V : bar_valid_t)
         return bar_record_t;
...
end bar_type;

-- in the package body
function validate (B : bar_record_t; V : bar_valid_t)
         return bar_record_t is
   variable temp: bar_record_t := B;
begin
   temp.valid := V;
   return temp;
end validate;

Then the main code simply reads:

bar0 <= bar_type.validate(bar, bar.valid and not addr(5));
bar1 <= bar_type.validate(bar, bar.valid and addr(5));

To my eyes, this makes the main code cleaner, so I wouldn't even
contemplate a combinational process here.

- Brian

That's what I do today, more or less. Except I prefer to keep things
as local as possible, so, unless it is used by more than one entity,
I'll not put validate() function into package.
It works, but it takes few minutes when writing code - not a big deal.
More importantly, when reading a code, understanding what's going on
takes few tens of second, unless similar technique already appeared
many times in the project an the reader already caught with writer's
patterns.

BTW, in order to facilitate reader's pattern recognition I'd call the
helper function set_valid() rather than validate().

The advantage of built in tool, i.e. non-existent "others=>from"
syntax, is that reader already knows what it means.
The advantage of solution with combinatorial process is that although
reader does not know what it means, he is able to figure it out
without jumping back and and force between different source LOCs and
files.

 

[Rob Gaddi]

On Fri, 11 Jan 2013 00:22:53 +0000 (UTC)
Brian Drummond <brian@shapes.demon.co.uk> wrote:

On Thu, 10 Jan 2013 07:14:54 -0800, Michael S wrote:

On Jan 10, 3:27 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:

function validate (B : bar_record_t; V : bar_valid_t)
         return bar_record_t;
...
Then the main code simply reads:

bar0 <= bar_type.validate(bar, bar.valid and not addr(5));
bar1 <= bar_type.validate(bar, bar.valid and addr(5));

To my eyes, this makes the main code cleaner, so I wouldn't even
contemplate a combinational process here.

That's what I do today, more or less. Except I prefer to keep things as
local as possible, so, unless it is used by more than one entity, I'll
not put validate() function into package.

Fair enough - for single uses, I do use locally declared functions too.

It works, but it takes few minutes when writing code - not a big deal.
More importantly, when reading a code, understanding what's going on
takes few tens of second, unless ...the reader already caught with
writer's patterns.

A good argument for adopting a small and consistent set of patterns!

BTW, in order to facilitate reader's pattern recognition I'd call the
helper function set_valid() rather than validate().

It's your example; you have the context to name it better than I do!

The advantage of built in tool, i.e. non-existent "others=>from" syntax,
is that reader already knows what it means.

However you won't be able to sell anyone the idea of a new reserved word
"from" on such a lightweight justification.
How about "others => bar.others" instead?

Equally clear, I think, and quite in keeping with the language.

- Brian

Or others => unaffected

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Brian Drummond]

On Thu, 10 Jan 2013 07:14:54 -0800, Michael S wrote:

On Jan 10, 3:27 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:

function validate (B : bar_record_t; V : bar_valid_t)
         return bar_record_t;
....
Then the main code simply reads:

bar0 <= bar_type.validate(bar, bar.valid and not addr(5));
bar1 <= bar_type.validate(bar, bar.valid and addr(5));

To my eyes, this makes the main code cleaner, so I wouldn't even
contemplate a combinational process here.

That's what I do today, more or less. Except I prefer to keep things as
local as possible, so, unless it is used by more than one entity, I'll
not put validate() function into package.

Fair enough - for single uses, I do use locally declared functions too.

It works, but it takes few minutes when writing code - not a big deal.
More importantly, when reading a code, understanding what's going on
takes few tens of second, unless ...the reader already caught with
writer's patterns.

A good argument for adopting a small and consistent set of patterns!

BTW, in order to facilitate reader's pattern recognition I'd call the
helper function set_valid() rather than validate().

It's your example; you have the context to name it better than I do!

The advantage of built in tool, i.e. non-existent "others=>from" syntax,
is that reader already knows what it means.

However you won't be able to sell anyone the idea of a new reserved word
"from" on such a lightweight justification.
How about "others => bar.others" instead?

Equally clear, I think, and quite in keeping with the language.

- Brian

 

[Michael S]

On Jan 11, 2:26 am, Rob Gaddi <rga...@technologyhighland.invalid>
wrote:

On Fri, 11 Jan 2013 00:22:53 +0000 (UTC)









Brian Drummond <br...@shapes.demon.co.uk> wrote:
On Thu, 10 Jan 2013 07:14:54 -0800, Michael S wrote:

On Jan 10, 3:27 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:

function validate (B : bar_record_t; V : bar_valid_t)
         return bar_record_t;
...
Then the main code simply reads:

bar0 <= bar_type.validate(bar, bar.valid and not addr(5));
bar1 <= bar_type.validate(bar, bar.valid and addr(5));

To my eyes, this makes the main code cleaner, so I wouldn't even
contemplate a combinational process here.

That's what I do today, more or less. Except I prefer to keep things as
local as possible, so, unless it is used by more than one entity, I'll
not put validate() function into package.

Fair enough - for single uses, I do use locally declared functions too.

It works, but it takes few minutes when writing code - not a big deal..
More importantly, when reading a code,  understanding what's going on
takes few tens of second, unless ...the reader already caught with
writer's patterns.

A good argument for adopting a small and consistent set of patterns!

BTW, in order to facilitate reader's pattern recognition I'd call the
helper function set_valid() rather than validate().

It's your example; you have the context to name it better than I do!

The advantage of built in tool, i.e. non-existent "others=>from" syntax,
is that reader already knows what it means.

However you won't be able to sell anyone the idea of a new reserved word
"from" on such a lightweight justification.
How about "others => bar.others" instead?

Equally clear, I think, and quite in keeping with the language.

- Brian

Or others => unaffected

Why unaffected? I want other fields of bar1 to get values from bar.
Remember, we are discussing concurrent assignments, not assignments in
the process