«

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.

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

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.

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.

"Paul Taylor" <pt@false_email.co.uk> wrote in message
news:4984081a$...
>
> 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

On Jan 31, 8:15*pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Paul Taylor" <pt@false_email.co.uk> wrote in message
>
> news:4984081a$...
>
>
>
> > 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.