I'd rather switch than fight!

On Apr 20, 11:46=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 10, 8:21=A0pm, Jan Decaluwe <jandecal...@gmail.com> wrote:
>
>
>
> > On Apr 9, 6:53=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
>
> > > On Apr 9, 9:07=A0am, rickman <gnu...@gmail.com> wrote:
>
> > > > I think I have about had it with VHDL. =A0I've been using the
> > > > numeric_std library and eventually learned how to get around the
> > > > issues created by strong typing although it can be very arcane at
> > > > times. =A0I have read about a few suggestions people are making to =
help
> > > > with some aspects of the language, like a selection operator like
> > > > Verilog has. =A0But it just seems like I am always fighting some as=
pect
> > > > of the VHDL language.
>
> > > > I guess part of my frustration is that I have yet to see where stro=
ng
> > > > typing has made a real difference in my work... at least an
> > > > improvement. =A0My customer uses Verilog and has mentioned several =
times
> > > > how he had tried using VHDL and found it too arcane to bother with.
> > > > He works on a much more practical level than I often do and it seem=
s
> > > > to work well for him.
>
> > > > One of my goals over the summer is to teach myself Verilog so that =
I
> > > > can use it as well as I currently use VHDL. =A0Then I can make a fu=
lly
> > > > informed decision about which I will continue to use. =A0I'd apprec=
iate
> > > > pointers on good references, web or printed.
>
> > > > Without starting a major argument, anyone care to share their feeli=
ngs
> > > > on the differences in the two languages?
>
> > > > Rick
>
> > > The best online references are the Sutherland Verilog references.
> > > There is an online HTML reference for Verilog 95 (excellent), and a
> > > PDF for Verilog 2001 (good):
>
> > >http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.h.=
.....
>
> > > Cliff Cummings has a lot of good papers on Verilog at his site:
>
> > >http://sunburst-design.com/papers/
>
> > > In particular, if you read and carefully grok his paper about non-
> > > blocking vs. blocking assignments, you will be well on your way to
> > > being a Verilog wizard:
>
> > >http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
>
> > The infamous Guideline #5 bans variable semantics from always blocks
> > with sequential logic. It must be the Worst Guideline ever for RTL
> > designers.
> > The result is not wizardry but ignorance.
>
> > How are we supposed to "raise the abstraction level" if Verilog RTL
> > designers
> > can't even use variables?
>
> I didn't notice this post until today. =A0I think you are completely
> misreading the guidelines if you think they mean "Verilog RTL
> designers can't even use variables"

I use that line as a shorthand for "Guideline #5 combined with
Guideline #1, if taken seriously, forbids the use of traditional
variable semantics provided by blocking assignments, in the
context of a clocked always block".

No matter how absurd I hope this sounds to you, that's really
what it says.

Jan

On Apr 20, 5:14=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> On Apr 20, 11:46=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> > > >http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
>
> > > The infamous Guideline #5 bans variable semantics from always blocks
> > > with sequential logic. It must be the Worst Guideline ever for RTL
> > > designers.
> > > The result is not wizardry but ignorance.
>
> > > How are we supposed to "raise the abstraction level" if Verilog RTL
> > > designers
> > > can't even use variables?
>
> > I didn't notice this post until today. =A0I think you are completely
> > misreading the guidelines if you think they mean "Verilog RTL
> > designers can't even use variables"
>
> I use that line as a shorthand for "Guideline #5 combined with
> Guideline #1, if taken seriously, forbids the use of traditional
> variable semantics provided by blocking assignments, in the
> context of a clocked always block".
>
> No matter how absurd I hope this sounds to you, that's really
> what it says.

Well, the guidelines absolutely _do_ "forbid the use of traditional
variable semantics provided by blocking assignments, in the context of
a clocked always block", but I don't think that translates into
"Verilog RTL designers can't even use variables."

What it *does* translate into is "The cleanest way to write Verilog is
somewhat verbose, in that it requires you to separate your
combinatorial logic from your sequential logic."

Basically, this method of thinking/coding requires two variables for
each sequential variable.  It's really handy to have a nice naming
convention, like next_x is the variable that will be placed into x on
the next clock.

So you have your definitions:

reg       y,  next_y;
reg [5:0] x,  next_x;

and your combinatorial block:

always @* begin
    next_x =3D x + 1;
    next_y =3D x =3D=3D 0;
end

and your sequential block:

always @(posedge clk or negedge rstn)
    if (!rstn) begin
        x <=3D 0;
        y <=3D 0;
    end else begin
        x <=3D next_x;
        y <=3D next_y;
    end

The declaration of registers and the sequential block both become,
pretty much, boilerplate code with this method of coding -- all the
action happens in the combinatorial block.  I am actually, slowly, in
my spare time, working on a project that will create a lot of the
boilerplate for coding in this method.

How does this help?  It's more about a human's ability to mentally
manage complexity than anything else.  In the sequential block, every
line must be 'xxx' <=3D next_'xxx'.  Very easy to verify.  In the
combinatorial block, 'next_' must appear on the lhs, and only on the
lhs, of any assignment involving a sequential variable.  Nothing keeps
you from using if, case statements, etc. in the combinatorial block,
and it's very easy to think about, because you see two variables
simultaneously -- what is 'x' right now, and what will 'x' be after
the next clock.

I have worked at several companies and with several individuals where
this coding style is used.  I did not invent it; as far as I know it
was probably invented at multiple places independently.  It works
quite well, but is, as I mentioned, a bit verbose.  There is no reason
to use it for extremely simple modules, but OTOH, the breakover point
where it is better to use it comes much sooner than you might think.

Regards,
Pat

>> The point is that if you don't do static timing analysis (or have an
>> analyzer that is broken) timing verification is nearly impossible.
>
> And even if you do, the device might still have timing problems.


Can you expand on this Glen?

As I have always understood it one of the bedrocks of FPGA design is that
when it's passed a properly constrained static timing analysis an FPGA design
will always work (from a timing point of view).



Nial.

In comp.arch.fpga Nial Stewart <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote:
>>> The point is that if you don't do static timing analysis (or have an
>>> analyzer that is broken) timing verification is nearly impossible.

>> And even if you do, the device might still have timing problems.
 
> Can you expand on this Glen?
 
> As I have always understood it one of the bedrocks of FPGA design 
> is that when it's passed a properly constrained static timing 
> analysis an FPGA design will always work (from a timing point of view).

Well, some of the comments were regarding ASIC design, where
things aren't so sure.  For FPGA designs, there is, as you say,
"properly constrained" which isn't true for all design and tool
combinations.   One that I have heard of, though haven't actually
tried, is having a logic block where the delay is greater than
one clock cycle, but less than two.  Maybe some tools can do that,
but I don't believe that all can.

-- glen

On Apr 21, 12:38=A0am, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 20, 5:14=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>
>
>
> > On Apr 20, 11:46=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> > > > >http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
>
> > > > The infamous Guideline #5 bans variable semantics from always block=
s
> > > > with sequential logic. It must be the Worst Guideline ever for RTL
> > > > designers.
> > > > The result is not wizardry but ignorance.
>
> > > > How are we supposed to "raise the abstraction level" if Verilog RTL
> > > > designers
> > > > can't even use variables?
>
> > > I didn't notice this post until today. =A0I think you are completely
> > > misreading the guidelines if you think they mean "Verilog RTL
> > > designers can't even use variables"
>
> > I use that line as a shorthand for "Guideline #5 combined with
> > Guideline #1, if taken seriously, forbids the use of traditional
> > variable semantics provided by blocking assignments, in the
> > context of a clocked always block".
>
> > No matter how absurd I hope this sounds to you, that's really
> > what it says.
>
> Well, the guidelines absolutely _do_ "forbid the use of traditional
> variable semantics provided by blocking assignments, in the context of
> a clocked always block", but I don't think that translates into
> "Verilog RTL designers can't even use variables."
>
> What it *does* translate into is "The cleanest way to write Verilog is
> somewhat verbose, in that it requires you to separate your
> combinatorial logic from your sequential logic."
>
> Basically, this method of thinking/coding requires two variables for
> each sequential variable. =A0It's really handy to have a nice naming
> convention, like next_x is the variable that will be placed into x on
> the next clock.
>
> So you have your definitions:
>
> reg =A0 =A0 =A0 y, =A0next_y;
> reg [5:0] x, =A0next_x;
>
> and your combinatorial block:
>
> always @* begin
> =A0 =A0 next_x =3D x + 1;
> =A0 =A0 next_y =3D x =3D=3D 0;
> end
>
> and your sequential block:
>
> always @(posedge clk or negedge rstn)
> =A0 =A0 if (!rstn) begin
> =A0 =A0 =A0 =A0 x <=3D 0;
> =A0 =A0 =A0 =A0 y <=3D 0;
> =A0 =A0 end else begin
> =A0 =A0 =A0 =A0 x <=3D next_x;
> =A0 =A0 =A0 =A0 y <=3D next_y;
> =A0 =A0 end
>
> The declaration of registers and the sequential block both become,
> pretty much, boilerplate code with this method of coding -- all the
> action happens in the combinatorial block. =A0I am actually, slowly, in
> my spare time, working on a project that will create a lot of the
> boilerplate for coding in this method.
>
> How does this help? =A0It's more about a human's ability to mentally
> manage complexity than anything else. =A0In the sequential block, every
> line must be 'xxx' <=3D next_'xxx'. =A0Very easy to verify. =A0In the
> combinatorial block, 'next_' must appear on the lhs, and only on the
> lhs, of any assignment involving a sequential variable. =A0Nothing keeps
> you from using if, case statements, etc. in the combinatorial block,
> and it's very easy to think about, because you see two variables
> simultaneously -- what is 'x' right now, and what will 'x' be after
> the next clock.
>
> I have worked at several companies and with several individuals where
> this coding style is used. =A0I did not invent it; as far as I know it
> was probably invented at multiple places independently. =A0It works
> quite well, but is, as I mentioned, a bit verbose. =A0There is no reason
> to use it for extremely simple modules, but OTOH, the breakover point
> where it is better to use it comes much sooner than you might think.

Thanks for explaining your coding style details, that's much
more enlightening than philosophical discussions.

I stand by my quote. The context was clearly "using variables to
raise the abstraction level". That's not what this does.

Your coding style provides a very verbose workaround for temporary
variables. I just can't imagine this is how you do test benches, that
are presumably much more complex than your RTL code. Presumably
there you use temporary variables directly where you need them without
great difficulty. Why would it have to be so different for
synthesizable
RTL?

You refer to a "mental model" to manage complexity. To your credit,
you provide an argument, something the original author of
guideline #5 never did. However, I find it dubious. To manage
complexity,
I don't need to see the hardware registers, complete with Q and D,
so explicitly in the code. I think I understand pretty well what kind
of
coding styles are efficiently supported by synthesis tools. Given
this,
I try to write the code itself as clearly as possible.

Most importantly: your coding style doesn't support non-temporary
variables. In other words, register inferencing from variables is not
supported and therefore ignored as technique. In this sense, this is
actually a good illustration of the point I'm trying to make.

I happen to think that register inferencing from variables is an
essential tool. It raises the abstraction level just one notch. The
registers are not glancing at you from the code (although
unambiguously defined) but in return your coding style can be
much more expressive.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

On Apr 21, 8:19=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote:

> Thanks for explaining your coding style details, that's much
> more enlightening than philosophical discussions.
>
> I stand by my quote. The context was clearly "using variables to
> raise the abstraction level". That's not what this does.

I didn't show any variables raising the abstraction level, no, but I
showed a context they could be provided in.

> Your coding style provides a very verbose workaround for temporary
> variables. I just can't imagine this is how you do test benches, that
> are presumably much more complex than your RTL code. Presumably
> there you use temporary variables directly where you need them without
> great difficulty. Why would it have to be so different for
> synthesizable
> RTL?

You're right.  Testbenches do not suffer from this limitation.  But,
in point of fact, I can use any sort of logic in my testbench.  I use
constructs all the time that aren't realistically synthesizable, so
comparing how I code synthesizable RTL vs how I code testbenches would
turn up a lot more differences than just this.

> You refer to a "mental model" to manage complexity. To your credit,
> you provide an argument, something the original author of
> guideline #5 never did. However, I find it dubious. To manage
> complexity,
> I don't need to see the hardware registers, complete with Q and D,
> so explicitly in the code. I think I understand pretty well what kind
> of
> coding styles are efficiently supported by synthesis tools. Given
> this,
> I try to write the code itself as clearly as possible.

Yes, but when you use if/else, or case statements, or other complex
structures, it is easy to get lost.  Humans can only hold a very few
things in their minds at a time, and this is a powerful tool.  As I
said, I certainly did not invent this style, but I personally know
dozens of people who use it, and I have personally introduced it to at
least 3 people, and they all find it extremely useful.

> Most importantly: your coding style doesn't support non-temporary
> variables. In other words, register inferencing from variables is not
> supported and therefore ignored as technique. In this sense, this is
> actually a good illustration of the point I'm trying to make.

Well, it may be a good illustration to you, but now you're waxing
philosophical again.  Care to show an example (preferably in verilog)
of how not using this coding style supports your preferred technique?

> I happen to think that register inferencing from variables is an
> essential tool. It raises the abstraction level just one notch. The
> registers are not glancing at you from the code (although
> unambiguously defined) but in return your coding style can be
> much more expressive.

I am actually doing something similar, I think, in my verilog
automagic boilerplate code, which can determine size and type of
registers in most cases, and automatically declares them.

Regards,
Pat

glen herrmannsfeldt wrote:
> In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
> > On Apr 17, 7:17?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>  (snip on test benches)
>
> >> Yes, I was describing real world (hardware) test benches.
>
> >> Depending on how close you are to a setup/hold violation,
> >> it may take a long time for a failure to actually occur.
>
> > That is the point.  Finding timing violations in a simulation is hard,
> > finding them in physical hardware is not possible to do with any
> > certainty.  A timing violation depends on the actual delays on a chip
> > and that will vary with temperature, power supply voltage and process
> > variations between chips.
>
> But they have to be done for ASICs, and all other chips as
> part of the fabrication process.  For FPGAs you mostly don't
> have to do such, relying on the specifications and that the chips
> were tested appropriately in the factory.

I don't follow your reasoning.  Why is finding timing violations in
ASICs any different from FPGA?  If the makers of ASICs can't
characterize their devices well enough for static timing analysis to
find the timing problems then ASIC designers are screwed.


> > I had to work on a problem design once
> > because the timing analyzer did not work or the constraints did not
> > cover (I firmly believe it was the tools, not the constraints since it
> > failed on a number of different designs).  We tried finding the chip
> > that failed at the lowest temperature and then used that at an
> > elevated temperature for our "final" timing verification.  Even with
> > that, I had little confidence that the design would never have a
> > problem from timing.  Of course on top of that the chip was being used
> > at 90% capacity.  This design is the reason I don't work for that
> > company anymore.  The section head knew about all of these problems
> > before he assigned the task and then expected us to work 70 hour work
> > weeks.  At least we got them to buy us $100 worth of dinner each
> > evening!
>
> One that I worked with, though not at all at that level, was
> a programmable ASIC (for a systolic array processor).  For some
> reason that I never knew the timing was just a little bit off
> regarding to writes to the internal RAM.  The solution was to use
> two successive writes, which seemed to work.  In the usual operation
> mode, the RAM was initialized once, so the extra cycle wasn't much
> of a problem.  There were also some modes where the RAM had to
> be written while processing data, such that the extra cycle meant
> that the processor ran that much slower.
>
> > The point is that if you don't do static timing analysis (or have an
> > analyzer that is broken) timing verification is nearly impossible.
>
> And even if you do, the device might still have timing problems.

You keep saying that, but you don't explain.

> >> Yes, I was trying to cover the case of not using static timing
> >> analysis but only testing actual hardware. ?For ASICs, it is
> >> usually necessary to test the actual chips, though they should
> >> have already passed static timing. ?
>
> > If you find a timing bug in the ASIC chip, isn't that a little too
> > late?  Do you test at elevated temperature?  Do you generate special
> > test vectors?  How is this different from just testing the logic?
>
> It might be that it works at a lower clock rate, or other workarounds
> can be used.  Yes, it is part of testing the logic.
>
> (snip)
>
> >> If you only have one clock, it isn't so hard. ?As you add more,
> >> with different frequencies and/or phases, it gets much harder,
> >> I agree. ?It would be nice to get as much help as possible
> >> from the tools.
>
> > The number of clocks is irrelevant.  I don't consider timing issues of
> > crossing clock domains to be "timing" problems.  There you can only
> > solve the problem with proper logic design, so it is a logic
> > problem.
>
> Yes, there is nothing to do about asynchronous clocks.  It just has
> to work in all cases.  But in the case of supposedly related
> clocks, you have to verify it.  There are designs that have one
> clock a multiple of the other clock frequency, or multiple phases
> with specified timing relationship.   Or even single clocks with
> specified duty cycle.  (I still remember the 8086 with its 33% duty
> cycle clock.)
>
> With one clock you can run combinations of voltage, temperature,
> and clock rate, not so hard but still a lot of combinations.
> With related clocks, you have to verify that the timing between
> the clocks works.

But you can't verify timing by testing.  You can never have any level
of certainty that you have tested all the ways the timing can fail.
If the clocks are related, what exactly are you testing, that they
*are* related?  Timing is something that has to be correct by
design.

Rick

I also use seperate sequential and combinatorial always blocks. At
first I felt that I should be able to have just a single sequential
block but quickly became accustomed to 2 blocks and it now feels
natural and I don't think it limits my ability to express my intent at
all. Most of the experienced designers I work with use this style but
not all of them.

glen herrmannsfeldt wrote:
> combinations.   One that I have heard of, though haven't actually
> tried, is having a logic block where the delay is greater than
> one clock cycle, but less than two.  Maybe some tools can do that,
> but I don't believe that all can.

Just normal multicycle path, has been normal thing in tools for
a long time. At least Altera, Xilinx, Synplify, Primetime and
Precision support it.

--Kim

rickman wrote:
> But you can't verify timing by testing.  You can never have any level
> of certainty that you have tested all the ways the timing can fail.

Especially with ASIC you can't verify the design by testing. There are
so many signoff corners and modes in the timing analysis. The old
worst/best case in normal and testmode are long gone. Even 6 corner
analysis in 2+ modes is for low end processes with big extra margins.
With multiple adjustable internal voltage areas, powerdown areas etc.
the analysis is hard even with STA.

--Kim