How to implement pipeline in this case?

Hello.

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

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

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

How many stages did your professor want you to pipeline this to?

My best advice is, variables are a fact of life, don't dwell on them. Focus on the things that make you happy, like beer.

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.

S> In order to improve the performance, I try to implement the pipeline.

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

As does using variables exclusively. Some examples:

-- 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.

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.

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

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.

DL 200X(which promises significant nonsense reduction) is getting

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

Which bits?

If I had access to synplify, that would probably make my life sympler... but since I am between jobs right now and ASIC/FPGA-oriented shops in my area can probably be counted on two or three hands, it may be a while until I get an opportunity to update my 8.1 suite (ISE+EDK+ChipScope) for cheap/free... unless I decide to take one or two master classes to sneak into edu programs.

If you ever needs some features/bug fix in a later ISE version (works for xst only), there's one way to do it. You can download the webpack for free and compile some piece of code with a target chip in the same family but smaller that the full ISE Foundation allows. You can then revert to your older full version to compile your top level and merge every ngc together. Of course that only works for the xst part of the flow, for the downstream tools you need to target your final (big) chip AFAIK. I used this technique recently to benefit from some improvement in xst v9.1 over xst v8.1.

Good luck for your job search Daniel. If I recall correctly from your signature, you're from Montreal right?

Patrick

Not much. I'm just using the functions to convert from fixed-point to floating-point and vice-versa (functions to_signed, to_unsigned and to_float). I'm also doing some floating point math but I'm using the Coregen cores from Xilinx for doing that.

Patrick

This sounds like something worth investigating next time I see XST choke on a bit of VHDL - thanks for the tip. An XC2VP7 is not exactly the most spacious FPGA around but still fits sizable chunks of logic.

It would be nice if Xilinx extended WebPack to at least cover the specific chips featured on Xilinx's edu-minded, endorsed and subsidized boards like the XUP-V2P's XC2VP30-7/FF896 - that would make everybody who got XUPs (like me) really happy.

Yup, Montreal, QC, congrats for remembering! Since there aren't too many digital logic or similar jobs around here compared to Ontario, I might start a short master here while looking and head out after that if I do not find anything worth staying around here for.

Well, i burned my fingers with Synplify when i was doing my master thesis a year ago. Within half a year i found a dozen of bugs, just by implementing something that is nothing more than an optimized 64 bit adder. Ok, all but two bugs were related to the Altera backend and worked fine when choosing Xilinx instead. But still....

Attila Kinali

Another good reason to do post-synthesis simulations... Doesn't that suck? I mean, how often do software guys find run-time bugs in gcc for example? It seems less common than VHDL synthesis bugs (but I'm probably biased, since I do more VHDL than software...).

Patrick