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-21-2008
On Aug 21, 12:27 pm, Mike Treseler <(E-Mail Removed)> wrote:
> rickman wrote:
> > Can anyone
> > come up with a compelling example of why we should suffer the use of
> > variables in our code?

>
> Let say I want to describe a phase accumulator
> in the traditional manner.
> With a mult-process design, I might
> say something like:
>
> accum_s <= '0' & accum_s(accum_s'length - 2 downto 0)
> + ('0' & addend_c);
>
> in one process and pick up the
> output msb in another process:
>
> msb <= accum_s(accum_s'length - 1);
>
> Thats not too bad, but it's pretty easy
> to get a count or length off by one.


I have no idea why you would use two processes for the above??? At
first I thought that maybe you were assigning msb in a concurrent
assignment so that it would not be registered. But in the example
below you are assigning it in a clocked process.

So what is the basis for using two processes above and one below???


> I prefer a single process description
> like this that does exactly the same thing.
> ...
> accum_v := accum_v + addend_c; -- add magic number
> msb_v := accum_v(accum_v'length-1); -- save the carry bit
> accum_v(accum_v'length-1) := '0'; -- clear carry for next time
> ...
> -- Now use msb_v however I like down here ...
>
> To me, there is no comparison.
> It's like calculus vs Laplace transforms.


Yes, it would appear that, to you, there are a lot of things that I
can't see. For example, I can't see how you would make use of a
variable outside of the process it is defined in. Or is "down here"
still inside the process?

Andy seems to think I am being silly or argumentative or whatever.
But I maintain that no one in this discussion has actually explained
how the use of variables provides any advantage. Andy just keeps
waving his arms around saying "Decoupling" and "Proximity" without
actually explaining how any of this is worth the extra trouble using
variables. You have given an incomplete example that does not clearly
show your point.

Why is your point so hard to explain?

Rick
 
Reply With Quote
 
 
 
 
rickman
Guest
Posts: n/a
 
      08-21-2008
On Aug 21, 9:19 am, KJ <(E-Mail Removed)> wrote:
> On Aug 21, 8:32 am, rickman <(E-Mail Removed)> wrote:
>
> > On Aug 21, 2:01 am, Kim Enkovaara <(E-Mail Removed)> wrote:

>
> > > Of course with FPGAs also initial values can be used and then no reset
> > > is connected to the FF. The initial value comes from the configuration
> > > file in that case.

>
> > But this requires the global set reset signal. That is how the FFs
> > get their initial state.

>
> No, implementing an initial value does not require *any* signal in the
> design source files. Maybe we're delving into an area where the tools
> that you're using don't (or you think they don't) support initial
> values in the source code or something and in order to get those
> intial values that tools requires you to code it as if it was an async
> reset.
>
> If xyz is a flip flop output and one can say...
> signal xyz: std_ulogic := '1';
> and signal xyz gets initialized at configuration time then the tools
> support the VHDL language standard as it applies to defining initial
> values.
>
> If instead you have to say...
> if (Reset = '1') then
> xyz <= '1';
> ...
>
> in order to get xyz initialized at configuration time then the tools
> do not support the VHDL language standard as it applies to defining
> initial values and the above code is the work around that might
> help...but still it's a work around to a tool limitation, not some
> fundamental principle.


I am not aware that initial values of signals is part of a VHDL
standard for synthesis. In fact, I was under the impression that
there is no "standard" for what parts of the language were supported
for synthesis. Am I wrong about this? Are initial value assignments
a required construct for synthesis support? I know they have not been
historically.


> > > > own signal, but it is active regardless of your code. But if you want
> > > > to control the state of the FF on power up, then you need to use a
> > > > register template with an async reset.

>
> > > Not always. You can also use the FFs without any reset and give initial
> > > values for the signals. Most synthesizers can transfer those values
> > > to configuration image.

>
> > I don't think this is the rule. If you want to write portable code,
> > you need to use a reset as part of the clocked process.

>
> Not really. If you're talking about portability to tools that don't
> support initial value specification then you could still find yourself
> at the mercy of having to supply an external I/O pin to ultimately
> give you the reset at the end of configuration. Now this tool
> limitation work around is requiring additional PCBA support that would
> not otherwise be required.


If you want your part to come out of configuration cleanly, then you
have to provide a way to synchronizing the end of the internal reset
to the system clock. I have yet to find a way to do this without
proving that external reset pin, even if it is just tied high (or
low).

Maybe the perceived problem of synchronizing the end of reset is a red
herring. I have never seen a problem with it. But if you consider
how FSM and counters work, it is entirely possible that they will not
start up properly when reset in the default async manner.

> Obviously all this only applies to devices that have a defined powerup/
> end configuration state available but which *tools* don't support
> initial value specification now-a-daze?


That has been a large number of tools and FPGA devices by my
experience. Can you state that there are no tools that don't support
this feature?

Rick
 
Reply With Quote
 
 
 
 
rickman
Guest
Posts: n/a
 
      08-21-2008
On Aug 21, 9:07 am, Brian Drummond <(E-Mail Removed)>
wrote:
> On Mon, 18 Aug 2008 11:39:42 -0700 (PDT), rickman <(E-Mail Removed)>
> wrote:
>
>
>
> >> You'll note that this is quite a bit nastier because
> >> it's necessary to assign to the outputs both in the
> >> reset and in the clocked branch, otherwise the
> >> "q" and "count" registers will have subtly different
> >> behaviour and could not be merged.

>
> >I can't say I follow you on this. A reset input by definition defines
> >the state of all registers, state and output. Why would you want to
> >assign the outputs to be dependant on the previous state when the
> >reset is asserted??? I have never done this since it was not the
> >desired behavior.

>
> One reason (not the case in this example): a very long delay line,
> containing delayed state (to be used when a slow operation started by
> the main state machine has completed). You can either reset this along
> with the main state, or simply let its inputs ripple through. The latter
> can be implemented at 16 bits per LUT in SRL16s for Xilinx, saving
> several hundred FFs. The former can't, because the SRL16s don't have the
> necessary reset connections.


Ok, so how does that relate to the issue of using variables?

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

> I have no idea why you would use two processes for the above???


I wouldn't.
I assumed that others would.
How would you do it?

> Yes, it would appear that, to you, there are a lot of things that I
> can't see. For example, I can't see how you would make use of a
> variable outside of the process it is defined in. Or is "down here"
> still inside the process?


Yes. Sorry but I can't publish this entire entity.
See my published examples for simpler cases.

> Why is your point so hard to explain?


I don't know.
My preference is based on writing shell scripts, C and python.

-- Mike Treseler
 
Reply With Quote
 
Jan Decaluwe
Guest
Posts: n/a
 
      08-22-2008
Andy wrote:

> "We" have already given several examples that are compelling to many
> of us:
>
> Ease of discerning cycle based behavior from the code
> Decoupling, etc. without resorting to separate files/entities/
> architectures
> Proximity of the variable definition to where it is used
> Simulation efficiency


All true, but I'm missing the most important point: the difference
in semantics between signals and variables.

There are things you can do with variables that you cannot easily
accomplish with signals. So they add another dimension to the game.

In particular, in a clocked process the same variable can be used
both "combinatorially" and "as a register". Once you get that,
the opportunities for elegant HDL solutions for real problems
pop up everywhere.

I consider register inference from variables the most powerful
tool in the RTL toolbox - however it is poorly understood and
probably banned in a majority of design teams.

http://myhdl.jandecaluwe.com/doku.php/cookbook:jc2

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      08-22-2008
On Aug 22, 6:19 am, Jan Decaluwe <(E-Mail Removed)> wrote:
>
> I consider register inference from variables the most powerful
> tool in the RTL toolbox - however it is poorly understood and
> probably banned in a majority of design teams.


Not to mention poorly supported compared to signals, both in
simulation and synthesis. If you use variables, you will see more
bugs and limitations of the tools. Why? I guess because it is just
not as mainstream. Kinda like driving a Maserati for the daily
commute.

Rick
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      08-22-2008
On Aug 21, 1:11 pm, Mike Treseler <(E-Mail Removed)> wrote:
> rickman wrote:
> > I have no idea why you would use two processes for the above???

>
> I wouldn't.
> I assumed that others would.
> How would you do it?
>
> > Yes, it would appear that, to you, there are a lot of things that I
> > can't see. For example, I can't see how you would make use of a
> > variable outside of the process it is defined in. Or is "down here"
> > still inside the process?

>
> Yes. Sorry but I can't publish this entire entity.
> See my published examples for simpler cases.
>
> > Why is your point so hard to explain?

>
> I don't know.
> My preference is based on writing shell scripts, C and python.


Well, that makes sense. If you are used to writing software, then you
will be more comfortable with variables. I have a much stronger
hardware background. I design my hardware in block diagrams, tables
and state charts before I write any code (if needed). I then write
the code that describes the registers and logic. I take the D in HDL
literally (hardware Description language) and use the language to
describe the hardware I want. I actually did not get a job offer
once because I said that I code RTL. One of the lead engineers felt
very strongly that this was too inefficient to be effective and
blackballed an offer. Funny, I seem to be doing just fine on the
engineering side of things. I wish I had a business manager though.

This is in the clocked process
accum_v <= accum_v + addend_c;

This is a concurrent statement
msb_v <= accum_v(accum_v'high);

I don't recall needing this in a phase accumulator. Isn't the top bit
just your output signal? The NCOs I have written were producing a
digital output of 1 bit for use as a clock. Otherwise, why would you
need the carry? Actually, I didn't use the carry out. I used the
msb. Maybe I don't understand what you are doing with this.
accum_v(accum_v'length-1) := '0'; -- clear carry for next time

I guess my way uses an extra bit in the accumulator, one more than you
have in the phase increment register. You look at this as saving the
"carry" bit. But I don't get why you don't retain the carry bit into
the sum. But then it has been a while since I have done an NCO.
Maybe I am forgetting some things. BTW, "clearing" the carry can be
done in the sum if you really need to.

accum_v <= '0' & accum_v(accum_v'high-1 downto 0) + addend_c;

But where did the extra bit in the addend_c come from? Do you have a
bit in the addend that is never set?

Rick
 
Reply With Quote
 
Martin Thompson
Guest
Posts: n/a
 
      08-22-2008
rickman <(E-Mail Removed)> writes:

> On Aug 22, 6:19 am, Jan Decaluwe <(E-Mail Removed)> wrote:
>>
>> I consider register inference from variables the most powerful
>> tool in the RTL toolbox - however it is poorly understood and
>> probably banned in a majority of design teams.

>
> Not to mention poorly supported compared to signals, both in
> simulation and synthesis.


I really can't imagine a modern simulator not supporting variables to
spec, surely! That would be just plain broken!

> If you use variables, you will see more bugs and limitations of the
> tools. Why? I guess because it is just not as mainstream. Kinda
> like driving a Maserati for the daily commute.
>


I've never seen a variable-related bug in my time. In the old days
there we *limitations*, but I haven't come across any of those
recently either in the tools I use. And I use a *lot* of variables
(and records, and procedures within processes, and all sorts of other
things that didn't used to work, but make my life easier *now*).

YMMV however

Cheers,
Martin

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      08-22-2008
rickman wrote:
> I don't recall needing this in a phase accumulator. Isn't the top bit
> just your output signal?


That would be a counter Q type output.
I need to enable a prescaler with a carry-out.

By saving the bit before clearing it
I have exactly what I need and synthesis
does a fine job with the carry chain details.
I guess the advantage I see with variables
is this ability to build up the values
I need in sequential steps and to make
the computer do more of the detail work.

-- Mike Treseler


 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      08-23-2008
On Aug 21, 9:35 am, Andy <(E-Mail Removed)> wrote:



> On Aug 21, 7:27 am, rickman <(E-Mail Removed)> wrote:


> > On Aug 21, 2:52 am, Mike Treseler <(E-Mail Removed)> wrote:



> > > Kim Enkovaara wrote:
> > > > Yes, I agree that variables are sometimes painful and make debugging
> > > > much harder, but on the other hand they help to make cleaner code
> > > > usually that is easier to read.



> > > ...and less likely to have a logical error in the first place.



> > > -- Mike Treseler



> > People keep saying this, but I have not seen one example. Can anyone
> > come up with a compelling example of why we should suffer the use of
> > variables in our code?



> > Rick



> "We" have already given several examples that are compelling to many
> of us:



> Ease of discerning cycle based behavior from the code




The 'ease of discerning' depends much on the skill of the person
writing the code, not whether or not variables were used.


> Decoupling, etc. without resorting to separate files/entities/
> architectures



Decoupling and hierarchy has nothing to do with the use of variables.
If you don't like the typing overhead of separate entities to express
hierarchy (a valid complaint for some) you're free to express
hierarchy within a block or generate statement and keep it all in one
file...the amount of typing would be the same (slightly less I guess
since 'block' is a shorter word than 'process').

If your point here though was that keeping things (in this case
variables) invisible outside of the scope of the process then this is
exactly analogous to keeping other things (in this case signals) local
to a block or generate...and inside that block you can still plop down
a process with its variables if you so choose. Processes are
handicapped in that they can not define a local signal if needed so
you're forced to use variables to keep it local.



> Proximity of the variable definition to where it is used



The proximity of a variable definition to it's use is identical to
that of a signal definition within a block to it's point of use.


> Simulation efficiency



I measured ~10-15% a while back...so that's one advantage.


> Apparently these are not compelling reasons to you, and you are free
> to limit your use of the VHDL language and tool capabilities
> accordingly.



You listed four reasons, only one of which is a valid advantage (which
in turn must be balanced against the disadvantages previously
mentioned).

@Rick
Where I tend to use variables in synthesis is where the logic to
express the function is best handled with sequential statements (i.e.
'if', 'case', etc.) and I don't want to bother writing it as a
function for whatever reason so that I could use the function output
in a concurrent signal assignment.


The other case I would use variables in synthesis is to compute some
intermediate thing which, if I didn't do it that way, would result in
basically copy/pasting code, or otherwise cluttering up the source
code...in other words, use of the variable becomes much like a
shorthand notation.


The biggest place I find for variables though has to be in the
testbench code where I model the various widgets on the board and
where synthesizability (if that's a word) is not a concern.


The 'compelling example' is only something that you find compelling.
Variables are just a tool in the toolkit for getting the job done.
Like any tool they can be used well or misused. The quality/
readability/*-ity of the resulting code that pops out depends solely
on the skill and knowledge of the designer. Being limited in either
area reduces the *-ity measure.


KJ



 
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