How to implement pipeline in this case?

In order to improve the performance, I try to implement the pipeline.
But variables make me sad.

For example.

-- Input: IN1, IN2 / output : OUT
signal S1,S2,S3
process(clk)
variable V1,V2,V3
begin
V1 := IN1
S1 <= V1
V2 <= S1
S2<=IN2
V3:= S2+V2
S3 <= V3
OUT<= S3
end process;

is there anyone with idea about this?

lkjrsy@gmail.com writes:

> In order to improve the performance, I try to implement the pipeline.
> But variables make me sad.
>

It might help us to help you if you tell us what function you are
trying to pipeline, rather than us having to figure out what you think
you might be trying to do from your code :-)  Which seems to be posted
three times, differently!

Try posting your un-pipelined original code...

As a general point, you can pipeline using variables by writing the
pipeline stages "bottom up" (ie the first stage at the bottom of the
process). This will infer flipflops for each variable.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Hi,

My first recommendation would be to avoid mixing signals and variables 
unless absolutely necessary because the two have different update 
policies. Variables are updated on-the-fly or "in program order" while 
signals are updated with the last written value only after all triggered 
processes have been evaluated.

Assigning a value to a signal from within a synchronous process will 
always infer FFs. Results with variables may vary wildly from one 
synthesis/simulation tool to another and how they get interpreted is 
also highly dependent on how the code is arranged. Using signals 
exclusively avoids introducing unnecessary confusion.

Since ISE supports register balancing and a few other related options 
that will automatically move FFs up and down combinational logic paths 
to improve timing margins, you can try adding registers in front and 
after combinational blobs. Most of the time, ISE does a decent job 
relocating two or three register levels. This is not ideal for 
bleeding-edge results but is worth a shot to nudge large-ish 
combinational blobs into timing margins without having to untangle them 
(or at least postpone that with minimal effort if possible) for explicit 
pipelining.

lkjrsy@gmail.com wrote:
> In order to improve the performance, I try to implement the pipeline.
> But variables make me sad.
> 
> For example.
> 
> -- Input: IN1, IN2 / output : OUT
> signal S1,S2,S3
> process(clk)
> variable V1,V2,V3
> begin
> V1 := IN1
> S1 <= V1
> V2 <= S1
> S2<=IN2
> V3:= S2+V2
> S3 <= V3
> OUT<= S3
> end process;
> 
> is there anyone with idea about this?
> 

Daniel S. wrote:

> Assigning a value to a signal from within a synchronous process will 
> always infer FFs. Results with variables may vary wildly from one 
> synthesis/simulation tool to another and how they get interpreted is 
> also highly dependent on how the code is arranged.

Synthesis results will match simulation.
Simulation will match the LRM.
Nothing varies wildly.

> Using signals 
> exclusively avoids introducing unnecessary confusion.

As does using variables exclusively.
Some examples:

http://home.comcast.net/~mike_treseler/

     -- Mike Treseler

Mike Treseler wrote:
> Daniel S. wrote:
> 
>> Assigning a value to a signal from within a synchronous process will 
>> always infer FFs. Results with variables may vary wildly from one 
>> synthesis/simulation tool to another and how they get interpreted is 
>> also highly dependent on how the code is arranged.
> 
> Synthesis results will match simulation.
> Simulation will match the LRM.
> Nothing varies wildly.
> 
>> Using signals exclusively avoids introducing unnecessary confusion.
> 
> As does using variables exclusively.
> Some examples:
> 
> http://home.comcast.net/~mike_treseler/
> 
>     -- Mike Treseler

The situation might have improved over the last 5+ years but from my 
experience in the ASIC field, "if it was broken five years ago, presume 
it is still broken today even if it has been fixed four years ago."

When Modelsim gate-level disagrees with Cadence about what some bits of 
HDL does because either of them got confused by user-defined types, 
mixtures of signals and variables, etc., it turns into a costly and 
puzzling experience on the testbenches once A0 silicon comes around. 
Since I worked mostly with ASIC-minded people up to now, I was always 
asked to write the most plain, boring, simple and flat VHDL possible to 
avoid most language-feature-specific tool bugs elsewhere in the tool chain.

When running gate-level netlist equivalence checks, there sometimes are 
startling discrepancies between what Cadence and Modelsim think of a 
particular design... this has been a major cause of dead ducks in the 
past and it still nearly scares the life out of the few people 
responsible for initial production sign-offs today.

Daniel S. wrote:

> Since I worked mostly with ASIC-minded people up to now, I was always
> asked to write the most plain, boring, simple and flat VHDL possible to
> avoid most language-feature-specific tool bugs elsewhere in the tool chain.

My comments were intended for FPGA designs
where VHDL source is still in the mainstream.
For some reason VHDL is depreciated for
ASIC designs in the USA.

           -- Mike Treseler

Mike Treseler wrote:
> Daniel S. wrote:
> 
>> Since I worked mostly with ASIC-minded people up to now, I was always
>> asked to write the most plain, boring, simple and flat VHDL possible to
>> avoid most language-feature-specific tool bugs elsewhere in the tool chain.
> 
> My comments were intended for FPGA designs
> where VHDL source is still in the mainstream.
> For some reason VHDL is depreciated for
> ASIC designs in the USA.
> 
>            -- Mike Treseler

This is an FPGA forum so I know most people's comments are primarily 
FPGA-oriented... but this does not change the fact that most synthesis 
and simulation tools have had, have and will continue to have weird and 
totally obscure bugs, diverging or faulty interpretations of some 
language features that will cause unexpected hardware behavior.

Since FPGAs target a much broader engineering public than ASICs, related 
tools are exposed to more diverse design methodologies and corner-cases, 
further accelerating the advancement of the tool vendors' test coverage. 
Since respins cost over a million and have two months turnarounds, ASIC 
designers avoid corner cases and bleeding-edge language features to 
reduce unnecessary technological risks - the ASIC bleeding-edge does not 
have as much material to sharpen itself against.

Yes, the situation has improved a lot on both fronts over the years and 
will continue to improve in the future but bugs and divergences will 
always exist. ASIC people simply try to stick with the path of least 
unnecessary pain since doing otherwise is several orders of magnitude 
more expensive (time+money) than it is with FPGAs.

BTW, my last job at an ASIC shop used VHDL as the primary language and 
translated verilog to run equivalence checks on synthesis tools' output 
netlists to weed out language-specific synthesis issues. In the process, 
our validation team whacked Cadence a few times for incorrect
gate-level output from VHDL. This sort of risk alone explains a lot of 
why VHDL is not very popular for ASICs.

On Mon, 05 Mar 2007 15:08:40 -0500
"Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote:

> In the process, 
> our validation team whacked Cadence a few times for incorrect
> gate-level output from VHDL.

Don't tell me that you are surprised that Cadence Verilog
synthesis is better than their VHDL synthesis? They were
the ones who promoted Verilog for the last 15 years after all.

			Attila Kinali

-- 
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
                        -- Daniel Hottinger

Attila Kinali wrote:
> On Mon, 05 Mar 2007 15:08:40 -0500
> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote:
> 
>> In the process, 
>> our validation team whacked Cadence a few times for incorrect
>> gate-level output from VHDL.
> 
> Don't tell me that you are surprised that Cadence Verilog
> synthesis is better than their VHDL synthesis? They were
> the ones who promoted Verilog for the last 15 years after all.

My point was simply to illustrate that not only do tool vendors often 
disagree on specific language features, one vendor's tools may also show 
major (design-breaking) disagreements on netlists synthesized from exact 
HDL equivalent in different languages, hence the need to do equivalence 
checks to catch probable language-specific issues before ordering masks 
and wafers.

The path of least pain when dealing with one specific vendor would be to 
stick with that vendor's preferred language... but things are not quite 
that simple when the complete tool chain includes software and IP cores 
  from over a dozen different providers.

Surprised that Cadence prefers Verilog? Not really... after seeing so 
many ISE VHDL bugs suggesting Verilog as the work-around until ISE 
v90.87 (many of these fixes keep getting pushed back to the next 
revision), I might decide to switch to Verilog for my future projects - 
VHDL 200X (which promises significant nonsense reduction) is getting 
nowhere and it'd be years until ISE gets it right anyhow.

On Mar 6, 3:59 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:
> My point was simply to illustrate that not only do tool vendors often
> disagree on specific language features, one vendor's tools may also show
> major (design-breaking) disagreements on netlists synthesized from exact
> HDL equivalent in different languages, hence the need to do equivalence
> checks to catch probable language-specific issues before ordering masks
> and wafers.
>
> The path of least pain when dealing with one specific vendor would be to
> stick with that vendor's preferred language... but things are not quite
> that simple when the complete tool chain includes software and IP cores
>   from over a dozen different providers.
>
> Surprised that Cadence prefers Verilog? Not really... after seeing so
> many ISE VHDL bugs suggesting Verilog as the work-around until ISE
> v90.87 (many of these fixes keep getting pushed back to the next
> revision), I might decide to switch to Verilog for my future projects -VH=
DL 200X(which promises significant nonsense reduction) is getting
> nowhere and it'd be years until ISE gets it right anyhow.

Instead of ditching VHDL for Verilog, you might want to consider
Synplify instead of xst. I am using some tidbits of VHDL-200x in my
current design and xst produced a wrong netlist from that vhdl. I have
access to Synplify for my master's degree (thankfully) and I ran that
piece of code through Synplify. The post-synthesis simulation showed
that the result from Synplify was correct, contrary to xst (v9.1 btw).

I have been bitten a few times by wrong netlists for using slightly
"advanced" features of VHDL that xst didn't handle properly. Now I do
much more post-synthesis simulations than before (and I learned the
hard way that using records in ports causes problem in that case, but
that's another story...).

My 2=A2.

Patrick