RE: [sv-bc] RE: [sv-ec] Case @*

From: <jonathan.bromley_at_.....>
Date: Tue May 19 2009 - 03:34:46 PDT
Shalom

> There is tons of perfectly good legacy design code that used the 
> same loop index variable everywhere (except with nested loops), 
> assuming there are no delays in the code. 

For sure this has traditionally worked, but I'd argue that it
is very poor coding style whose bad effects have been hidden
by good fortune.  There is nothing in the LRM that says the
loop executes atomically; it could (in theory) be interleaved
with the execution of some other loop that shares the same
loop counter.  Even if this were not true, the idea of using
a module-global variable as a loop counter horrifies me,
merely as a matter of coding hygiene.

> The problem started with always @*.

No, the latent problem was exposed by always @* :-)

If RTL designers were forced (perhaps by their lint tools)
to declare loop counters locally, then they would have less
trouble working out what goes wrong in their testbenches
when they share a loop counter among concurrently-executing
loops that contain time delays.  I don't think we should be
encouraging or justifying unnecessary bad coding habits, 
even if they have extensive historical precedent.
-- 
Jonathan Bromley
Consultant

Doulos - Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, 
UK
Tel:  + 44 (0)1425 471223                       Email: 
jonathan.bromley@doulos.com 
Fax:  +44 (0)1425 471573                        http://www.doulos.com

--------------------------------------------------------------------------------
Doulos Ltd is registered in England and Wales with company no. 3723454
Its registered office is 4 Brackley Close, Bournemouth International 
Airport,
        Christchurch, BH23 6SE, UK. 

This message may contain personal views which are not the views of
Doulos, unless specifically stated.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue May 19 03:52:06 2009

This archive was generated by hypermail 2.1.8 : Tue May 19 2009 - 03:52:32 PDT