vhdl questions from a verilog person

[Brian Drummond]

On Thu, 29 Jan 2009 10:46:01 -0800, Jim Lewis <jim@synthworks.com>
wrote:

Andy,
Interesting references to Ada; back in the 90's I took a couple of ada
training classes so that I could learn some "software" techniqes for
vhdl that are not generally taught in vhdl classes (at least the ones
I had taken). I learned general stuff about using types/subtypes
effectively, using scope to control access, applications of packages,
deferred constants (still not synthesizable?!), procedures/functions,
etc. The type-based genericity of ada was really nice; completely
different from what vhdl generics offer.

VHDL-2008 allows both type and subprograms to be generics.
It also adds generics to packages and subprograms. Hopefully
this gets us closer to the capability that you liked.

I probably need that Ada training class as I don't know how
similar what we have is to Ada.

Or perhaps get John Barnes "Programming in Ada 2005" and play with Gnat
(from GCC 4.3) a little. I think generic packages and subprograms will
add a lot; it would be a shame if they are vaguely similar but
annoyingly different to the same facilities in Ada...

It isn't just VHDL that's evolving, I like the look of the new
object-oriented features in Ada-2005, though I haven't had time to try
them yet.

- Brian

 

[Jim Lewis]

Brian,

Or perhaps get John Barnes "Programming in Ada 2005" and play with Gnat
(from GCC 4.3) a little. I think generic packages and subprograms will
add a lot; it would be a shame if they are vaguely similar but
annoyingly different to the same facilities in Ada...

Unfortunately there are minor differences between the existing
implementation (ie: generics after entity rather than before)
and we stayed consistent with that for packages and subprograms.
At the time, it seemed like the only right answer, however, ...

It isn't just VHDL that's evolving, I like the look of the new
object-oriented features in Ada-2005, though I haven't had time to try
them yet.

We have proposals for adding OO to VHDL as well as adding constrained
random to the language, but we really need more users and large user
organizations to back us - at least express serious interest.

Best,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis SynthWorks VHDL Training http://www.synthworks.com

A bird in the hand may be worth two in the bush,
but it sure makes it hard to type.

 

[Brian Drummond]

On Thu, 29 Jan 2009 21:36:58 -0800, Jim Lewis <jim@synthworks.com>
wrote:

Brian,
Or perhaps get John Barnes "Programming in Ada 2005" and play with Gnat
(from GCC 4.3) a little. I think generic packages and subprograms will
add a lot; it would be a shame if they are vaguely similar but
annoyingly different to the same facilities in Ada...

Unfortunately there are minor differences between the existing
implementation (ie: generics after entity rather than before)
and we stayed consistent with that for packages and subprograms.
At the time, it seemed like the only right answer, however, ...

I'd agree that consistency within VHDL is probably more important,
especially on syntax. It's the semantics of what you can/can't do and
why; e.g. where you can use unconstrained subtypes or why not, which are
a great deal harder to learn - and then you have (possibly) a different
set of rules in the other language.

It isn't just VHDL that's evolving, I like the look of the new
object-oriented features in Ada-2005, though I haven't had time to try
them yet.

We have proposals for adding OO to VHDL as well as adding constrained
random to the language, but we really need more users and large user
organizations to back us - at least express serious interest.

I doubt there's the same need for constrained random testing in Ada -
though maybe they could learn from hardware design practice there. Maybe
there is room for some collaboration with the Ada Working Group?

It would be beneficial for the OO additions to learn from the Ada OO
approach where flexibility is not allowed to compromise correctness; if
not to follow it exactly, then to know why VHDL must deviate from it.

(I want class-wide types for ports, where I could connect slv, unsigned,
or my own types inheriting from these, without casting everywhere, and
without losing the semantics of whatever I connect to the port...)

I think where VHDL originally departed from Ada, the designers made
mostly intelligent choices about what to leave out, based on what was
efficiently implementable 20-some years ago, when an Ada compiler could
bring a machine to its knees. But it may be time to re-visit those
decisions.

All just opinion from a user; my company doesn't count as a large user
organisation - not yet, anyway.

- Brian

 

[Paul Taylor]

On Thu, 29 Jan 2009 11:22:16 -0800, Jim Lewis wrote:

How do you handle the rare case where you need a mealy
output unregistered? I have had some that go to the
load enable input of a datapath register, and hence,
its timing path terminates there. It seems like your
choices would be:
1) Eat a clock cycle of latency
2) Move data path into statemachine
3) Write code outside of statemachine

I use both one and two process state machines depending on what it is
that I'm doing. A problem with the two process state machine is if you then
need some signals registered you need extra signals to the clocked process
to communicate what you want - more typing!! (I'm lazy)

I can't help thinking that modelling registers with the rising edge
construct was the wrong way to go. If you could declare signals as
registered instead, you could have assignments to registered and
unregistered signals in the same block of code, rather than have one block
of code only for the assignment of registered signals, and another block
of code only for unregistered signals - which I find awkward,
and ultimately time-consuming.

Regards,

Paul.

 

[Mike Treseler]

Paul Taylor wrote:

A problem with the two process state machine is if you then
need some signals registered you need extra signals to the clocked process
to communicate what you want - more typing!! (I'm lazy)

Me too.

I can't help thinking that modeling registers with the rising edge
construct was the wrong way to go. If you could declare signals as
registered instead, you could have assignments to registered and
unregistered signals in the same block of code, rather than have one block
of code only for the assignment of registered signals, and another block
of code only for unregistered signals - which I find awkward,
and ultimately time-consuming.

Plain vanilla vhdl can do that, if I model the
nodes using process variables instead of signals.
I code up a functional description that
matches a synthesis template and
let synthesis worry about the gates and flops.


begin
a:a_v := a_v + 1; -- fast count
b:if a_v(a_v'left) = '1' then -- a carry?
a_v(a_v'left) := '0'; -- msb is asynch, rest is regs
b_v := b_v + 1;
c:if b_v(b_v'left) = '1' then -- b carry?
b_v(b_v'left) := '0'; -- msb is async, rest is regs
c_v := c_v + 1; -- slow count, unsigned rolls over, no carry
end if c;
end if b;


-- Mike Treseler

 

[Paul Taylor]

On Fri, 30 Jan 2009 10:12:38 -0800, Mike Treseler wrote:

Paul Taylor wrote:

A problem with the two process state machine is if you then
need some signals registered you need extra signals to the clocked process
to communicate what you want - more typing!! (I'm lazy)

Me too.

I can't help thinking that modeling registers with the rising edge
construct was the wrong way to go. If you could declare signals as
registered instead, you could have assignments to registered and
unregistered signals in the same block of code, rather than have one block
of code only for the assignment of registered signals, and another block
of code only for unregistered signals - which I find awkward,
and ultimately time-consuming.

Plain vanilla vhdl can do that, if I model the
nodes using process variables instead of signals.
I code up a functional description that
matches a synthesis template and
let synthesis worry about the gates and flops.


begin
a:a_v := a_v + 1; -- fast count
b:if a_v(a_v'left) = '1' then -- a carry?
a_v(a_v'left) := '0'; -- msb is asynch, rest is regs
b_v := b_v + 1;
c:if b_v(b_v'left) = '1' then -- b carry?
b_v(b_v'left) := '0'; -- msb is async, rest is regs
c_v := c_v + 1; -- slow count, unsigned rolls over, no carry
end if c;
end if b;

Yes. But the variables can't be taken out of the process and say assigned
to ports unregistered as (I'm assumming) they are in a rising_edge if
statement somewhere? So the signals at the ports become registered.

My comment about assigning to registered and unregistered signals in the
same block was about signals that go out of the process, say to ports for
example. In which case with VHDL the registered signals would be in a
rising_edge block of code, and the unregistered signal would have to be in
another block, for example as per a two process state machine.

Hence the comment about the rising_edge construct not being a great idea
for modelling registers - IMHO of course I wouldn't be at all suprised
if someone tells me the good reasons why they are done that way.

Paul.

 

[Mike Treseler]

Paul Taylor wrote:

So the signals at the ports become registered.

Yes, but that is a good thing in my book.
It simplifies timing analysis.
I will make a large process if I have to.

Hence the comment about the rising_edge construct not being a great idea
for modelling registers - IMHO of course I wouldn't be at all suprised
if someone tells me the good reasons why they are done that way.

I will defer.
The main point is that it isn't done this way
and that there are several coding styles
that get the job done as is.

-- Mike Treseler

 

[Paul Taylor]

On Fri, 30 Jan 2009 13:57:36 -0800, Mike Treseler wrote:

I will defer.
The main point is that it isn't done this way
and that there are several coding styles
that get the job done as is.

Sure, I was just musing on why rising edge construct was used to model
registers. All very hypothetical, and taking the thread way off on a
tangent to boot.

The point that I was making was if vhdl didn't model registers with a
rising edge construct but with a declaration, then a vhdl module module
implementing a state machine with registered and unregistered output
signals might have looked _something_ like:

architecture...
-- signal declarations, one is declared registered
registered signal LED_ON_s : ...
signal DONE_s : ...
...
begin
process...
begin
if ARST = '1' then
LED_ON_s := '0'; -- asynchronously set LED_ON_s with ':='
...
else -- note no rising_edge
...
DONE_s <= '0';
case STATE_s is
...
when A_STATE =>
LED_ON_s <= '1'; -- registered
DONE_s <= '1'; -- unregistered
....

And then you wouldn't need two-process state machines for situations where
you have unregistered and registered outputs.

The above seems to me to be a better way of describing that hardware,
eschewing rising_edge and two processes. But what do I know!! Not as much
as those who specified VHDL for sure

Regards,

Paul.

 

[Paul Taylor]

On Sat, 31 Jan 2009 08:13:14 +0000, Paul Taylor wrote:

architecture...
-- signal declarations, one is declared registered
registered signal LED_ON_s : ...
signal DONE_s : ...
...
begin
process...
begin
if ARST = '1' then
LED_ON_s := '0'; -- asynchronously set LED_ON_s with ':='
...
else -- note no rising_edge
...
DONE_s <= '0';
case STATE_s is
...
when A_STATE =
LED_ON_s <= '1'; -- registered
DONE_s <= '1'; -- unregistered
...

Ignore this post (it doesn't work) !!!! I knew I shouldn't have 'mused' out
in the open!!

Paul.

 

[KJ]

"Paul Taylor" <pt@false_email.co.uk> wrote in message
news:4984081a$1_2@mk-nntp-2.news.uk.tiscali.com...

The point that I was making was if vhdl didn't model registers with a
rising edge construct but with a declaration, then

The defunct tool called PlDesigner from Minc used to do just this, when a
signal was declared you would say something like "xyz clocked_by
clock"...the declaration could also have things like "reset_by" or
"preset_by" or "enabled_by" as needed as well...if memory serves, they went
out of business around 10 years ago or so.

ABEL does the same thing with the "istype" property in the declaration.

VHDL trumped them both though

KJ

 

[Tricky]

On Jan 31, 8:15 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:

"Paul Taylor" <pt@false_email.co.uk> wrote in message

news:4984081a$1_2@mk-nntp-2.news.uk.tiscali.com...



The point that I was making was if vhdl didn't model registers with a
rising edge construct but with a declaration, then

The defunct tool called PlDesigner from Minc used to do just this, when a
signal was declared you would say something like "xyz clocked_by
clock"...the declaration could also have things like "reset_by" or
"preset_by" or "enabled_by" as needed as well...if memory serves, they went
out of business around 10 years ago or so.

ABEL does the same thing with the "istype" property in the declaration.

VHDL trumped them both though

KJ

Again, altera's proprietry language AHDL does exactly this. things
like:

my_reg : DFFE;

my_reg.clk = clk;
my_reg.enable = enable;
my_reg.d = input;
output = my_reg.q;


TBH, ID have VHDL and its rising_edge processes any day.