Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Legal enable?

Reply
Thread Tools

Legal enable?

 
 
PatC
Guest
Posts: n/a
 
      09-05-2008
Hi folks,

A friend of mine wrote some component that includes an enable
construct that I haven't seen before. We discussed it and he swears that
it's legal code. Simulation and synthesis don't report any issues with
it, but now a functional issue came up in hw and it could be related to
this.
Paraphrasing, the code is similar to this:

process (reset, clk)
begin
if (reset = '1') then
state <= idle;
elsif (rising_edge(clk) and hold = '0') then
case (state) is
when idle => ...
when write => ...
end case
end if;
end process

Here, the /hold/ signal acts as an enable. Is this legal or should it
be recoded as a nested if?
Now that I look at it again, in case it's legal, shouldn't /hold/
need to be in the sensitivity list?

Thanks in advance,
-Pat
 
Reply With Quote
 
 
 
 
Muzaffer Kal
Guest
Posts: n/a
 
      09-05-2008
On Thu, 04 Sep 2008 23:12:34 -0700, PatC <(E-Mail Removed)>
wrote:

>Hi folks,
>
> A friend of mine wrote some component that includes an enable
>construct that I haven't seen before. We discussed it and he swears that
>it's legal code. Simulation and synthesis don't report any issues with
>it, but now a functional issue came up in hw and it could be related to
>this.
> Paraphrasing, the code is similar to this:
>
> process (reset, clk)
> begin
> if (reset = '1') then
> state <= idle;
> elsif (rising_edge(clk) and hold = '0') then
> case (state) is
> when idle => ...
> when write => ...
> end case
> end if;
> end process
>
> Here, the /hold/ signal acts as an enable. Is this legal or should it
>be recoded as a nested if?
> Now that I look at it again, in case it's legal, shouldn't /hold/
>need to be in the sensitivity list?
>
>Thanks in advance,
>-Pat


I'm not a VHDL language lawyer but this looks perfectly fine to me.
There would be no logical difference between this style and nesting
the "if (hold..". There is no need for hold in the sensitivity list
because it's a synchronous enable so it's only evaluated on the
posedge of clk so changes to it outside that event are not meaningful.
 
Reply With Quote
 
 
 
 
Pascal Peyremorte
Guest
Posts: n/a
 
      09-05-2008
PatC a écrit :
> Hi folks,
>
> A friend of mine wrote some component that includes an enable
> construct that I haven't seen before. We discussed it and he swears that
> it's legal code. Simulation and synthesis don't report any issues with
> it, but now a functional issue came up in hw and it could be related to
> this.
> Paraphrasing, the code is similar to this:
>
> process (reset, clk)
> begin
> if (reset = '1') then
> state <= idle;
> elsif (rising_edge(clk) and hold = '0') then
> case (state) is
> when idle => ...
> when write => ...
> end case
> end if;
> end process
>
> Here, the /hold/ signal acts as an enable. Is this legal or should it
> be recoded as a nested if?
> Now that I look at it again, in case it's legal, shouldn't /hold/ need
> to be in the sensitivity list?
>
> Thanks in advance,
> -Pat

Hi,

(Beginner look, so take it with care)
* I do not think that a nested if would change anything from a combined AND
condition. Both should produce exactely the same equation.
As a beginner, I would have written
elsif (rising_edge(clk) and (hold = '0')) then
to definitively ensure that (hold='0') is evaluated first before the and operator.

* Again, I do not think that Hold needs to be present in the sensitivity list
because it does not trigger any "start of update" of that process.

Maybe the problem is elsewhere ?
Can you describe more the HW issue ?

Pascal


 
Reply With Quote
 
PatC
Guest
Posts: n/a
 
      09-05-2008
Jonathan Bromley wrote:
> On Thu, 04 Sep 2008 23:12:34 -0700, PatC wrote:
>
>> A friend of mine wrote some component that includes an enable
>> construct that I haven't seen before. We discussed it and he swears that
>> it's legal code. Simulation and synthesis don't report any issues with
>> it, but now a functional issue came up in hw and it could be related to
>> this.
>> Paraphrasing, the code is similar to this:
>>
>> process (reset, clk)
>> begin
>> if (reset = '1') then
>> state <= idle;
>> elsif (rising_edge(clk) and hold = '0') then
>> case (state) is
>> when idle => ...
>> when write => ...
>> end case
>> end if;
>> end process
>>
>> Here, the /hold/ signal acts as an enable. Is this legal
>> or should it be recoded as a nested if?

>
> From a VHDL language point of view, the two forms are truly
> identical. The logical "and" operator on booleans does
> short-circuit evaluation, so if rising_edge(clk) is false
> then it won't even evaluate the expression hold='0'.
> As you correctly say, the hold signal is an (active-low)
> clock enable.
>
>> Now that I look at it again, in case it's legal,
>> shouldn't /hold/ need to be in the sensitivity list?

>
> As a synchronous input to the process, it certainly
> should not be in the sensitivity list; you wouldn't expect
> any activity if you wiggled "hold" while the clock was
> inactive, would you?
>
> The only possible problem might be with synthesis.
> Nowadays (as has been discussed here at wearisome length)
> most synthesis tools are quite good at recognizing alternative
> forms of the standard clocked processes. However, it is
> probably still safer to restrict synthesis coding style
> to the standard template:
>
> if <asynch_reset is asserted> then
> <do asynch reset actions>
> elsif <active clock edge> then
> <do synchronous actions>
> end if;
>
> In other words, use a nested "if". It will prevent
> raised eyebrows from colleagues and linting tools,
> and will assure portability among synthesis tools.


Thanks Jonathan for your quick & insightful reply.

For the record, I tried the nested if and xst synthesized it in the
exact same way as before.
As you mentioned, adding it to the sensitivity list wouldn't make sense.

Cheers,
-Pat
 
Reply With Quote
 
Symon
Guest
Posts: n/a
 
      09-05-2008
"Brian Drummond" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> I just want to ask what drives "hold".
> If (a) "hold" is used as an enable by more than one process, and (b)
> "hold" is NOT driven by a FF or register clocked by "clk", you have a
> problem, whichever coding style you use. (Different processes sample
> "hold" at different times according to routing delays in the FPGA; if it
> is asynchronous, they may see it at different levels in the same clock
> cycle).
>
> - Brian
>

Hi Brian,
I don't think it's a problem if 'hold' is driven by combinationial logic,
iff the combinatorial logic is driven by FFs in the domain of 'clk'. In this
case, the FPGA static timing analysis tools will alert the designer to any
timing issues.
Cheers, Syms.


 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      09-05-2008
Jonathan Bromley wrote:

....
> In other words, use a nested "if". It will prevent
> raised eyebrows from colleagues and linting tools,
> and will assure portability among synthesis tools.


I prefer the standard template style as well,
for the same reasons.

But if I had to defend Pat's friend in court of vhdl,
I would point out that that his
"anded enable" style does save one level of indentation
over the "nested if" enable style.

If it works with with xst as Pat claims,
it likely works with the other popular fpga synthesis tools also,
as xst tends to lag the others in vhdl language coverage.

The defense rests

-- Mike Treseler



 
Reply With Quote
 
kennheinrich@sympatico.ca
Guest
Posts: n/a
 
      09-05-2008
On Sep 5, 12:41*pm, Mike Treseler <(E-Mail Removed)> wrote:
> Jonathan Bromley wrote:
>
> ...
>
> > In other words, use a nested "if". *It will prevent
> > raised eyebrows from colleagues and linting tools,
> > and will assure portability among synthesis tools.

>
> I prefer the standard template style as well,
> for the same reasons.
>
> But if I had to defend Pat's friend in court of vhdl,
> I would point out that that his
> "anded enable" style does save one level of indentation
> over the "nested if" enable style.
>
> If it works with with xst as Pat claims,
> it likely works with the other popular fpga synthesis tools also,
> as xst tends to lag the others in vhdl language coverage.
>
> The defense rests
>
> * * * * * * * -- Mike Treseler


Agreed. But just to muddy the waters a bit, I thought I'd look up what
1076-6.1999 had to say. Three things stood out for me:

(1) 1076-6 doesn't explicitly mention that "gating" the clock edge
with an (... and something) clause is legal. So I'd argue that the
nested if() statement, while redundant according to the language
semantics, is safer to use.

(2) There's a technical inconsistency in sec 6.1.1. "only the values
'0' and 1' shall be used in expressions representing clock levels".
Then it says that the rising_edge() function is an allowable form of
clock edge specification, but rising_edge (when elaborated as per LRM
semantics), uses the To_X01 function which references both 'H' and
'L'. Nit-picking, to be sure, but that's what digital designers live
for

(3) More interestingly, though, in sec 6.1.2 which defines the
expected form of clock edge specification. In addition to the usual
(clk'event and clk='1') and (rising/falling_edge(clk)), the form

if (not (clk'stable) and clk='1')

is also allowed! Has anyone ever written or seen this form of clock
edge specification? Was this a common form back in the 80's when the
language was young and standard coding forms were competing for
viability?

Cheers,

- Kenn

 
Reply With Quote
 
kennheinrich@sympatico.ca
Guest
Posts: n/a
 
      09-05-2008
On Sep 5, 12:41*pm, Mike Treseler <(E-Mail Removed)> wrote:
> Jonathan Bromley wrote:
>
> ...
>
> > In other words, use a nested "if". *It will prevent
> > raised eyebrows from colleagues and linting tools,
> > and will assure portability among synthesis tools.

>
> I prefer the standard template style as well,
> for the same reasons.
>
> But if I had to defend Pat's friend in court of vhdl,
> I would point out that that his
> "anded enable" style does save one level of indentation
> over the "nested if" enable style.
>
> If it works with with xst as Pat claims,
> it likely works with the other popular fpga synthesis tools also,
> as xst tends to lag the others in vhdl language coverage.
>
> The defense rests
>
> * * * * * * * -- Mike Treseler


Agreed. But just to muddy the waters a bit, I thought I'd look up what
1076-6.1999 had to say. Three things stood out for me:

(1) 1076-6 doesn't explicitly mention that "gating" the clock edge
with an (... and something) clause is legal. So I'd argue that the
nested if() statement, while redundant according to the language
semantics, is safer to use.

(2) There's a technical inconsistency in sec 6.1.1. "only the values
'0' and 1' shall be used in expressions representing clock levels".
Then it says that the rising_edge() function is an allowable form of
clock edge specification, but rising_edge (when elaborated as per LRM
semantics), uses the To_X01 function which references both 'H' and
'L'. Nit-picking, to be sure, but that's what digital designers live
for

(3) More interestingly, though, in sec 6.1.2 which defines the
expected form of clock edge specification. In addition to the usual
(clk'event and clk='1') and (rising/falling_edge(clk)), the form

if (not (clk'stable) and clk='1')

is also allowed! Has anyone ever written or seen this form of clock
edge specification? Was this a common form back in the 80's when the
language was young and standard coding forms were competing for
viability?

Cheers,

- Kenn

 
Reply With Quote
 
PatC
Guest
Posts: n/a
 
      09-06-2008
Brian Drummond wrote:
> I just want to ask what drives "hold".
> If (a) "hold" is used as an enable by more than one process, and (b)
> "hold" is NOT driven by a FF or register clocked by "clk", you have a
> problem, whichever coding style you use. (Different processes sample
> "hold" at different times according to routing delays in the FPGA; if it
> is asynchronous, they may see it at different levels in the same clock
> cycle).


A fair question. I should've added that hold is a registered signal
in the same clock domain.

-P@
 
Reply With Quote
 
PatC
Guest
Posts: n/a
 
      09-06-2008
Brian Drummond wrote:
> I just want to ask what drives "hold".
> If (a) "hold" is used as an enable by more than one process, and (b)
> "hold" is NOT driven by a FF or register clocked by "clk", you have a
> problem, whichever coding style you use. (Different processes sample
> "hold" at different times according to routing delays in the FPGA; if it
> is asynchronous, they may see it at different levels in the same clock
> cycle).


A fair question. I should've added that hold is a registered signal
in the same clock domain.

-P@
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is it legal to write an logical equation for a FPGA LUT in claims of a patent? Weng Tianxiang VHDL 12 12-10-2005 03:49 PM
Research: File-sharers big legal download spenders. Silverstrand Front Page News 0 07-27-2005 03:00 PM
State machine transition on internal signals - is it legal? Divyang M VHDL 9 05-18-2005 03:58 PM
State machine transition on internal signals -- is it legal? Divyang M VHDL 1 05-15-2005 09:36 AM
Is this legal? Valentin Tihomirov VHDL 20 10-29-2003 10:31 AM



Advertisments