Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Re: Mixed clocked/combinatorial coding styles

Reply
Thread Tools

Re: Mixed clocked/combinatorial coding styles

 
 
rickman
Guest
Posts: n/a
 
      08-25-2008
On Aug 25, 2:59 pm, Andy <(E-Mail Removed)> wrote:
>
> I also took a couple of ada programming courses to gain some
> knowledge in the use of packages, procedures, functions, etc. That's
> where I started learning about using scoping rules to isolate an
> implementation from its interface, at various levels of design.


Ok, now we are getting somewhere. When you took the programming
courses, what did they teach was the reason for wanting to use
"scoping rules to isolate an implementation from it's interface"? If
those reasons are not concrete and don't apply equally to HDL as to
software, then I see no need to carry that baggage.

I find there are any number of important techniques in software design
that are much less important when coding in an HDL. The idea of scope
is one of those rules. The concept of scope is to prevent you from
using the wrong variable in the wrong situation when you only need to
be able to access a few "local" variables. Why is this important in
software design? Because when variables were global, people often
used them in very confusing ways. The real issue is how people used
them. A method of forcing better programming skills is to limit how
you can access variables.

I don't find this to be an issue in coding in HDL. For one, my code
is generally structured by using entities. For another, these sort of
rules have much less benefit for more experienced programmers. It is
not unlike training wheels. When you are learning, they help keep you
from making mistakes. But once you have enough experience to balance
on your own, why keep the training wheels? I have given up on a
number of software rules that I learned in college. Not that they
aren't useful, I just don't need to enforce them strictly because I
know when they are useful and when they get in the way.


> Mike's example is a very good one because it demonstrates that you can
> take advantage of the immediate update behavior of variables to do
> things that would be more difficult in signals. Your counter-example
> of using a concurrent assignment is functionally valid, but I prefer
> not to hop out of a sequential process, into a concurrent statement,
> and then back to the process when I can use a variable to do the same
> thing without changing contexts.


Hopping, I don't think I have ever heard it expressed that way. I
don't like breaking code up into excessively small pieces either. But
I find very few cases where this happens. The only time I pull logic
outside of a process is when the signal is useful outside of the
process and I want it to be combinatorial, not sequential. If I don't
want a signal to be clocked, I just don't make an assignment to it
inside a clocked process. In fact, to use a variable outside of a
process requires that you make it a global variable and that opens the
can of worms that you are trying to keep a lid on.


> Another benefit occurs when the
> device driver writer and I are in the lab, integrating his SW with my
> HW. Having an HDL coding style that both of us can understand is very
> handy (I could already understand his programming language). I lost
> count of how many times I used to have to explain that sequential code
> (processes) using signals is only partially sequential, the updates
> still happen concurrently. Perhaps that's another reason why the HW
> approach to HDL coding makes more sense to some users: that's the only
> way you can really make sense of signals in clocked processes (by
> mentally mapping them to registers), they sure don't make sense
> functionally to me.


I don't want to badmouth software people. But the last couple of
cooperative working situations I had made me want to work alone as
much as possible. But I feel no need in any case to alter the way I
code to suit someone who has no need to view my code. That is
certainly no reason to burden myself with using features that I have
no need for.

Rick
 
Reply With Quote
 
 
 
 
Kim Enkovaara
Guest
Posts: n/a
 
      08-26-2008
rickman wrote:
> The main point is that one of us has a misunderstanding of how a logic
> cell FF gets it's initial state. I think this is fundamental to the
> discussion. I am pretty confident that I am correct, but if you know
> I am wrong, I would like to know that. I would feel like a fool if I
> were having this discussion with a customer and turned out to be
> wrong. I much prefer to find out now.


I would say that this information is device family specific and
information that the vendors are not telling in their datasheets
completely, it is partly visible in the netlists the external
synthesizers generate, but how are those attributes transferred to
bitstream is proprietary.

For example in V5 FF there are 6 settable parameters (FF, LATCH,
INIT1, INIT0, SRHIGH, SRLOW). Are those INIT0/1 bits only in the
bitstream and processed during the upload, or are they persistent,
I do not know. At the end of September I'll meet some A and X guys
who might know the answer, I'll ask if I remember.

This is for example from the V5 manual. How this is implemented is not
told.

"The initial state after configuration or global initial state is
defined by separate INIT0 and INIT1 attributes. By default, setting the
SRLOW attribute sets INIT0, and setting the SRHIGH attribute sets INIT1.
Virtex-5 devices can set INIT0 and INIT1 independent of SRHIGH and
SRLOW."

For Altera the SIV documentation was quite vague on this area. But
at least in the past they had only "init to zero" style thing, and
they added inversion if one was needed. Actually Synplify 8.8
had a bug in this inversion, with retiming it got very confused
wheter the signal was inverted or not


--Kim
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      08-26-2008
rickman wrote:

> For one, my code
> is generally structured by using entities.


I share this preference narrowly:

1. When I do have to wire things up myself,
I prefer to map pretested boxes with
the outs and ins clearly marked.

2. In a single-process box, variable/register IDs
are just as "global" as architecture signal IDs.

I find keeping track of signal drivers
and receivers for wires inside a multi-process box
to be tedious and hard to test.

Inside a single process box, synthesis is happy to
wire up the variable/registers and subprogram/gates
for me and then draw a schematic.
(thank you very much)

My logical "structures" are the types and subtypes
used to declare, and update, a gaggle of variable/registers at a time.

-- Mike Treseler

 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      08-26-2008
On Aug 26, 2:18 am, Kim Enkovaara <(E-Mail Removed)> wrote:
> rickman wrote:
> > The main point is that one of us has a misunderstanding of how a logic
> > cell FF gets it's initial state. I think this is fundamental to the
> > discussion. I am pretty confident that I am correct, but if you know
> > I am wrong, I would like to know that. I would feel like a fool if I
> > were having this discussion with a customer and turned out to be
> > wrong. I much prefer to find out now.

>
> I would say that this information is device family specific and
> information that the vendors are not telling in their datasheets
> completely, it is partly visible in the netlists the external
> synthesizers generate, but how are those attributes transferred to
> bitstream is proprietary.
>
> For example in V5 FF there are 6 settable parameters (FF, LATCH,
> INIT1, INIT0, SRHIGH, SRLOW). Are those INIT0/1 bits only in the
> bitstream and processed during the upload, or are they persistent,
> I do not know. At the end of September I'll meet some A and X guys
> who might know the answer, I'll ask if I remember.
>
> This is for example from the V5 manual. How this is implemented is not
> told.
>
> "The initial state after configuration or global initial state is
> defined by separate INIT0 and INIT1 attributes. By default, setting the
> SRLOW attribute sets INIT0, and setting the SRHIGH attribute sets INIT1.
> Virtex-5 devices can set INIT0 and INIT1 independent of SRHIGH and
> SRLOW."
>
> For Altera the SIV documentation was quite vague on this area. But
> at least in the past they had only "init to zero" style thing, and
> they added inversion if one was needed. Actually Synplify 8.8
> had a bug in this inversion, with retiming it got very confused
> wheter the signal was inverted or not


There is a very simple test. Does the GSR control the FF? If the GSR
signal controls the power up state of the FF, then there is no reason
to add extra controls to the bitstream and hardware. The answer is,
Yes, the GSR *will* control the state of a FF which has an initial
value.

Why anyone would imagine that there is extra logic and configuration
memory to control the initial state of CLB FFs is beyond me. There is
no reason to do it this way and the extra logic required is just
wasted silicon.

Rick
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      08-26-2008
On Aug 26, 9:32*am, rickman <(E-Mail Removed)> wrote:
> On Aug 26, 2:18 am, Kim Enkovaara <(E-Mail Removed)> wrote:
>
> There is a very simple test. *Does the GSR control the FF? *The answer is,
> Yes, the GSR *will* control the state of a FF which has an initial
> value.
>


But only for those devices that have this extraneous 'GSR' that the
user apparently is forced to worry about...simply to get the device
into a specified state at power up. Glad I don't have those worries.

KJ

 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      08-26-2008
On Aug 25, 6:24 pm, rickman <(E-Mail Removed)> wrote:
>
> Ok, now we are getting somewhere. When you took the programming
> courses, what did they teach was the reason for wanting to use
> "scoping rules to isolate an implementation from it's interface"? If
> those reasons are not concrete and don't apply equally to HDL as to
> software, then I see no need to carry that baggage.


The ada courses taught me a lot about how to design/code with
maintenance in mind, with a LOT more than just limiting scope. In this
regard, limiting the scope of a sig/var limits the impact on later
changes to the behavior of that sig/var. For example, if my FSM state
is held in a variable, then there is nothing outside of the process
that depends directly on the state definitions, transitions, etc.,
since all those dependencies must be transmitted through separate,
well-defined (hopefully) signals of wider scope. I can later modify
the state machine, and be confident that all references to it are
contained within that process, where they can be modified accordingly.
Can you do this without variables or blocks? Sure you can, but there
is no compiler keeping you honest. More importantly, if you are
modifying someone else's design/code, there was no compiler keeping
them honest either.

Of course you could break everything down into tiny entities and
architectures to achieve the same scope control, but blocks and
variables allow a "lightweight" hierarchy, with less coding overhead
(no entity definitions or port maps), and a "semi-global" signal
concept (external signals are not global, but also not completely
local). There is a place for entity level hierarchy, and there is a
place for block/process level hierarchy.

Just like in SW, how you write HDL code depends a lot on your work
environment. If you typically work alone, and don't have a lot of
reuse across projects, then some of these techniques make less sense
in your environment. If you work in teams, on large projects, these
concepts can save a lot of time and effort down the road. In my
experience, once you are familiar with the concepts, the additional up
front effort is negligible.

I should also mention that not everything I learned in the ada courses
was taught by the instructors. I learned a lot from the other SW
students while working through lab exercises and just in general
conversation. I learned an awful lot about SW development on a large
scale, and design/code techniques that do and don't work on a large
scale project. I was a pretty good coder in C and VHDL before the
class. Afterwards, I was a better designer/developer/engineer.

>
> I find there are any number of important techniques in software design
> that are much less important when coding in an HDL. The idea of scope
> is one of those rules. The concept of scope is to prevent you from
> using the wrong variable in the wrong situation when you only need to
> be able to access a few "local" variables. Why is this important in
> software design? Because when variables were global, people often
> used them in very confusing ways. The real issue is how people used
> them. A method of forcing better programming skills is to limit how
> you can access variables.
>
> I don't find this to be an issue in coding in HDL. For one, my code
> is generally structured by using entities. For another, these sort of
> rules have much less benefit for more experienced programmers. It is
> not unlike training wheels. When you are learning, they help keep you
> from making mistakes. But once you have enough experience to balance
> on your own, why keep the training wheels? I have given up on a
> number of software rules that I learned in college. Not that they
> aren't useful, I just don't need to enforce them strictly because I
> know when they are useful and when they get in the way.


This is true so long as only you have to maintain only your code.

>
> I don't want to badmouth software people. But the last couple of
> cooperative working situations I had made me want to work alone as
> much as possible. But I feel no need in any case to alter the way I
> code to suit someone who has no need to view my code. That is
> certainly no reason to burden myself with using features that I have
> no need for.


I try to learn from different disciplines as much as I can. Some
things are useful, some things aren't. I've also had SW "experts" tell
me I had too many levels of nested case/if/loop statements in my
code...

I understand where you are coming from. Your style makes sense and
works for you in your environment. Mine makes sense and works in my
environment.

Andy

 
Reply With Quote
 
Paul Taylor
Guest
Posts: n/a
 
      08-26-2008
On Mon, 25 Aug 2008 16:24:35 -0700, rickman wrote:

> I find there are any number of important techniques in software design
> that are much less important when coding in an HDL. The idea of scope
> is one of those rules.


Locality is good because:

(1) Imagine if in C you couldn't use local variables in functions, and
had to scroll up to the top of the file to declare *every* variable, and
then scroll back down to continue writing your functions. It would
interrupt your train of thought - it would be a PITA.

(2) Using locality effectively allows easier review of code (not only for
someone else, but for you too) and debug. If you can *easily* determine a
variable is local to a chunk of code, then you don't have to concern
yourself with its use anywhere else in that file - it lightens the load on
the brain and makes the job easier.

In various studies in bug detection rates/costs in software (I suspect
there is *some* correlation to HDL coding), it has been found that bugs
found by code review cost a lot less per bug compared to unit testing. I
suspect that's why verification often consists of test benches + code
review.

But I guess not *everyone* will find those things useful.

Paul.
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      08-26-2008
On Aug 26, 9:50 am, KJ <(E-Mail Removed)> wrote:
> On Aug 26, 9:32 am, rickman <(E-Mail Removed)> wrote:
>
> > On Aug 26, 2:18 am, Kim Enkovaara <(E-Mail Removed)> wrote:

>
> > There is a very simple test. Does the GSR control the FF? The answer is,
> > Yes, the GSR *will* control the state of a FF which has an initial
> > value.

>
> But only for those devices that have this extraneous 'GSR' that the
> user apparently is forced to worry about...simply to get the device
> into a specified state at power up. Glad I don't have those worries.


I guess you don't use FPGAs then.

This conversation seems to have taken a wrong term somewhere. I don't
know why this is getting contentious.

I have been talking about FPGAs from the beginning and I have stated
that clearly. ASICs are a whole different animal and I have not
addressed that at all. If you are using a programmable device that
does not have a global power-on reset signal, then you are either
using a very small device (CPLD) or you are using one I have never
heard of.

The "worry" is always there. You have to get the device into a known
state following configuration and any time another reset is applied.
Of course you can use configuration as a reset if you want. But the
issue is still there that you have to have a way to specify the
initial condition for the sequential logic. Most people consider the
GSR to be a *useful* feature toward this goal.

Rick
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      08-26-2008
On Aug 26, 1:46 pm, Paul Taylor <pt@false_email.co.uk> wrote:
> On Mon, 25 Aug 2008 16:24:35 -0700, rickman wrote:
> > I find there are any number of important techniques in software design
> > that are much less important when coding in an HDL. The idea of scope
> > is one of those rules.

>
> Locality is good because:
>
> (1) Imagine if in C you couldn't use local variables in functions, and
> had to scroll up to the top of the file to declare *every* variable, and
> then scroll back down to continue writing your functions. It would
> interrupt your train of thought - it would be a PITA.


No one is suggesting that locality is useful. But micro-managing of
locality is not so useful. If you have a variable for a counter and
later you find that you *need* the value of that counter, then you
have to change the code to use a signal. On the other hand, the fact
that a signal is declared does not require that it is used anywhere
other than in the process where it is assigned.

Comparing the use of signals to C code with only global variables is
not really useful and is just a straw man argument.


> (2) Using locality effectively allows easier review of code (not only for
> someone else, but for you too) and debug. If you can *easily* determine a
> variable is local to a chunk of code, then you don't have to concern
> yourself with its use anywhere else in that file - it lightens the load on
> the brain and makes the job easier.


If you spend more time reviewing code than writing, I guess this can
be important. I prefer to write code that is inherently easy to
read. Of course this is not always possible for complex problems, but
that is my goal. Using variables will do little to make the difficult
code more readable.


> In various studies in bug detection rates/costs in software (I suspect
> there is *some* correlation to HDL coding), it has been found that bugs
> found by code review cost a lot less per bug compared to unit testing. I
> suspect that's why verification often consists of test benches + code
> review.


So how does using signals preclude code review? This is just a non-
sequitur.


> But I guess not *everyone* will find those things useful.


I find *useful* things useful. I don't use forced techniques when
they are not needed. I use appropriate techniques. I expect that NASA
uses all of these techniques and many more. But that doesn't stop
problems from happening, like mixing feet and meters at an
interface.

Rick
 
Reply With Quote
 
Paul Taylor
Guest
Posts: n/a
 
      08-26-2008
On Tue, 26 Aug 2008 12:33:13 -0700, rickman wrote:

> So how does using signals preclude code review? This is just a non-
> sequitur.


Of course using signals doesn't preclude code review - my point was that
localization aids code review.

Paul.
 
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
typedef a struct [C Coding styles] MJ_India C Programming 5 10-10-2008 12:53 PM
Mixed clocked/combinatorial coding styles (another thread) whygee VHDL 23 08-26-2008 03:28 PM
Re: Mixed clocked/combinatorial coding styles Mike Treseler VHDL 0 08-19-2008 06:18 AM
Re: Mixed clocked/combinatorial coding styles kennheinrich@sympatico.ca VHDL 0 08-18-2008 05:46 PM
C Coding Styles and the use of Macros davej C Programming 5 11-21-2003 04:38 PM



Advertisments