cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Advisor
Advisor
36,135 Views
Registered: ‎10-10-2014

what exactly is 'elaborating' a design?

Jump to solution

I understand what synthesis, implementation, ... is. But what exactly does the 'elaborate' step do when you select 'open elaborated design'?

 

 

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
54,415 Views
Registered: ‎01-23-2009

When we talk about "implementation", we understand that we are talking about a number of separate processes:

  • opt_design
  • place_design
  • route_design
  • (and a number of others)

In the tool, these are split out a separate processes, each with their own options.

From the user point of view, "synthesis" is a single process, but, in reality, it is a number of processes

  • elaborate the design
  • apply constraints to the design
  • do high level optimizations of the design
  • technology map the design
  • do low level optimizations of the design

The first step, elaboration, is reading in your RTL file (which is text) and recognizing bits of code that represent real hardware structures. Once recognized, these are converted (in Vivado synthesis case) into "generic technology cells" - abstract things like registers, adders, comparators, multiplexers, arbitrarily wide gates, etc...

This step is necessary since the next steps (high and low level optimizations) are timing driven, and hence need constraints. But, constraints cannot be applied to your RTL (which is text) - they need to be applied to a netlist. So elaboration creates the netlist of generic technology cells.

In normal flows, we simply do elaboration as part of synthesis - its more or less invisible (although it may show up in the synthesis log). However, we can ask Vivado synthesis to "stop" after elaboration, and give us access to the netlist of generic technology cells.

There are only a couple of reasons to do this:

  1. to make sure that the synthesis tool understood our RTL code. We can look at things like hierarchical structure, check for things like unconnected inputs and outputs, make sure it recognized higher level structures (like RAMs), all before it goes ahead with the rest of the steps
  2. to verify and create constraints. The next steps of synthesis (optimization) need constraints. These constraints, though, need to be correct for this "generic technology" representation of your design. Generally, the constraints that you write for your design will end up being applicable for both the generic tech representation and the technology mapped representation (where the design is converted to Xilinx Basic ELements or BELs). Sometimes, though, the structure and naming of the generic technology netlist means that the constraints need to be ever so slightly different (or written differently so that they can apply to both forms of netlist). By opening the elaborated design, you can experiment with constraints to find the format that accomplishes what you want - these can then be used for synthesis or for both synthesis and implementation

Once you have done all this, you close the elaborated design, and it goes away (i.e. you cannot "continue" the rest of the synthesis process). When you synthesize the design, it will re-elaborate it as part of the synthesis run.

By the way, the elaboration process is actually done by the synthesis process - in non-project batch mode it is done with the command

synth_design -rtl

This specifically tells the synth_design process to stop after the elaboration has been completed.

Avrum

View solution in original post

Tags (2)
13 Replies
Highlighted
Guide
Guide
54,416 Views
Registered: ‎01-23-2009

When we talk about "implementation", we understand that we are talking about a number of separate processes:

  • opt_design
  • place_design
  • route_design
  • (and a number of others)

In the tool, these are split out a separate processes, each with their own options.

From the user point of view, "synthesis" is a single process, but, in reality, it is a number of processes

  • elaborate the design
  • apply constraints to the design
  • do high level optimizations of the design
  • technology map the design
  • do low level optimizations of the design

The first step, elaboration, is reading in your RTL file (which is text) and recognizing bits of code that represent real hardware structures. Once recognized, these are converted (in Vivado synthesis case) into "generic technology cells" - abstract things like registers, adders, comparators, multiplexers, arbitrarily wide gates, etc...

This step is necessary since the next steps (high and low level optimizations) are timing driven, and hence need constraints. But, constraints cannot be applied to your RTL (which is text) - they need to be applied to a netlist. So elaboration creates the netlist of generic technology cells.

In normal flows, we simply do elaboration as part of synthesis - its more or less invisible (although it may show up in the synthesis log). However, we can ask Vivado synthesis to "stop" after elaboration, and give us access to the netlist of generic technology cells.

There are only a couple of reasons to do this:

  1. to make sure that the synthesis tool understood our RTL code. We can look at things like hierarchical structure, check for things like unconnected inputs and outputs, make sure it recognized higher level structures (like RAMs), all before it goes ahead with the rest of the steps
  2. to verify and create constraints. The next steps of synthesis (optimization) need constraints. These constraints, though, need to be correct for this "generic technology" representation of your design. Generally, the constraints that you write for your design will end up being applicable for both the generic tech representation and the technology mapped representation (where the design is converted to Xilinx Basic ELements or BELs). Sometimes, though, the structure and naming of the generic technology netlist means that the constraints need to be ever so slightly different (or written differently so that they can apply to both forms of netlist). By opening the elaborated design, you can experiment with constraints to find the format that accomplishes what you want - these can then be used for synthesis or for both synthesis and implementation

Once you have done all this, you close the elaborated design, and it goes away (i.e. you cannot "continue" the rest of the synthesis process). When you synthesize the design, it will re-elaborate it as part of the synthesis run.

By the way, the elaboration process is actually done by the synthesis process - in non-project batch mode it is done with the command

synth_design -rtl

This specifically tells the synth_design process to stop after the elaboration has been completed.

Avrum

View solution in original post

Tags (2)
Highlighted
Advisor
Advisor
36,105 Views
Registered: ‎10-10-2014

Thanks @avrumw for this exceptionally clear answer!  

 

Glad I asked the question, the word 'elaborate' is all over the vivado manuals but didn't really find a great explanation.

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Highlighted
Scholar
Scholar
36,063 Views
Registered: ‎09-16-2009

I'd add a few more notes to avrum's answer.  I break that first synthesis step down (mentally) into 2 steps:

Compilation of code

Elaboration of code

 

During compiliation, the tool's looking at basic syntax, and verifying there's no syntax errors.  Verifying that you're code obeys the rules of the language, pretty much on just a file-by-file basis.

 

Next, during elaboration, the tool's checking more global, connectivity, and other rules to the entire design.

During elaboration, it's evaluating parameters (generics), setting port sizes, etc, accordingly.  The tool's checking to make sure the the connectivity is legit.  i.e. a top level module calls a sub-module with a port "A".  Well does port "A" actually exist on the sub-module?  Is it the correct width?  And many similar checks.  After elaboration, it's ready for the next steps as avrum's described.

 

For me this has it's roots in Cadence's simulation software.  You used to call three seperate tools to simulate:

ncverilog

ncelab

ncsim

 

So the steps there were very explicit.  Cadence probably didn't invent the terms, but that's where I became familiar with them.

 

Modelsim's similar - where you run:

vlog

vsim

 

Here the vsim command does the elaboration, and simulation. Actually, for Mentor, there's some flows which include a "vopt" command after vlog, which (among other things) does an elaboration.

 

Regards,

 

Mark

 

Highlighted
Advisor
Advisor
35,974 Views
Registered: ‎10-10-2014

Thanks Mark, I can see now that during development just 'opening the elaborated design' the design in Vivado is the quickest way to check for syntax errors etc. For some reason I always skipped the 'open elaborated design' and just clicked on synthesize to see if there were any errors.

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Highlighted
34,772 Views
Registered: ‎07-15-2015

Chiming in a little late, with an added question link at the end...

 

markcurry wrote:

For me this has it's roots in Cadence's simulation software.  You used to call three seperate tools to simulate:

ncverilog

ncelab

ncsim

 

So the steps there were very explicit.  Cadence probably didn't invent the terms, but that's where I became familiar with them.

 

Modelsim's similar - where you run:

vlog

vsim

 

Synopsys' Design Compiler also followed a similar flow during synthesis:

 

analyze file1.vhd

analyze file2.vhd

analyze fileN.vhd

elaborate

compile

 

"analysis" was the process of translation: parsing the file, doing syntax checks, and building a binary representation of the code that could be read in the next step.

 

"elaboration" was the process of assembling and linking all the analyzed file outputs with other libraries, so a netlist (generic structures) could be built. In the really old tools, the elaborated netlist could be read by their simulator as well as their synthesizer, which saved a step and made sure synthesizer and simulator were interpreting source code the same way.

 

For any constraints that apply to objects in the design, the objects first have to exist before the constraint can be applied and validated. Elaboration is also the point at which VHDL generics and Verilog parameters can be expanded. Analyzing source files in isolation is too early for this. But to build a complete and correct netlist with all parts connected to each other, different places where generics are used have to expand to matching widths in all occurrences, and elaboration is the earliest phase in which it can be done. Certain optimizations such as resource sharing (and to a degree, even routing congestion and timing, based primarily on knowledge of fanout) can also be explored at this step.

 

"compile" was the Design Compiler term where the generic logic representation got mapped to gates of the target library, and where timing constraints had to initially be satisfied.

 

Placement and routing were follow-on steps after that, especially before Syopsys had their own place and route tools. :)

 

I actually first heard the terms "analyze/elaborate" in context of the Ada programming language, the first place I remember seeing generics. Yes, I am old. :)

 

 

Highlighted
34,758 Views
Registered: ‎07-15-2015
0 Kudos
Highlighted
Advisor
Advisor
34,733 Views
Registered: ‎10-10-2014

thanks john.johnson2@rockwellcollins.com for sharing your knowledge on this, that clarifies things further for me :-)

 

In the meantime I also learned that there are different 'stages' of simulation :

 

1. behavorial -> requires elaborated design

2. functional -> requires synthesized or implemented design

3. timing -> requires synthesized or implemented design

 

 The results of the 3 simulations could be different I guess. 

 

Q: So I'm wondering what might cause a different result between a behavorial and a functional simulation, using the same stimuli/testbench?

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Highlighted
Scholar
Scholar
34,715 Views
Registered: ‎09-16-2009

I'm not sure your definitions of "behavorial" and "functional" are accepted standards.  In fact these definitions IMHO have always been hazy.  Usually when I hear those terms, I need more info from the source to clarify what the speaker means by those terms.  I prefer the term "RTL" which means to me "The synthesizable description of a design".

 

In any event, to have a design successfully synthesized into a netlist that matches the RTL, you need to follow certain guidelines.  Most are documented fairly well by the vendor (Xilinx, in this case within the Synthesis users guide).  Most of the guidelines overlap fairly well between vendors.

 

If you follow those rules, then you'll almost always get a synthesized netlist that matches the RTL.  The only exception would be tool error.

 

Gate level simulations are very rarely done in my experience.  I can think of 3-4 times in the past 10 years or so that I've found it neccesary.  Each of these cases was using a new language feature (i.e. SystemVerilog), and wanting to ensure the tool was creating what we expected.  The tools are fairly robust and mature, and very rarely produce netlists which don't match RTL.

 

Gate-level simulations with timing?  Waste-of-time IMHO. There's better ways to solve that problem.

 

Regards,

 

Mark

 

0 Kudos
Highlighted
34,705 Views
Registered: ‎07-15-2015

Regarding syntax checks: Brand A FPGAs with tool "Q" support a command called "analyze_file" which can do the syntax check in the blink of an eye, without the need to analyze all files together and build an elaborated netlist. Since it doesn't look at other modules, it wouldn't know if generics like port widths cause a mismatch until you elaborate them and try to build the netlist that interconnects them.

 

IIRC, Vivado will show modules with syntax errors in the GUI (sources pane?) automatically, but is there a quick way to do analyze (syntax check) only from the command line?

 

------------------

 

Regarding "simulation/synthesis mismatches": Google that exact term and you'll find a number of good references.

 

One old but thorough description is here:

http://www.sunburst-design.com/papers/CummingsSNUG1999SJ_SynthMismatch.pdf

 

As MarkCurry mentions, it *might* catch that very rare tool error, but is more often a result of "incomplete" coding styles, interpretation of don't-cares, some optimizations, and stuff related to resets and power-up initial states. Of course "X" values don't appear in real hardware, but can still be propagated through a gate-level netlist sim.

 

--------------

 

Regarding gate-level sims, especially with timing: In my industry (DO-254), a lot of timing runs still have to happen. :(

 

I try to limit that to any async chip-level interfaces, clock domain crossings, reset circuits, and things like that. If all I/O's are registered, there is little value in simulating synchronous parts of the core. If post-route STA reports no timing violations, then the only case that immediately comes to mind is where you have missing or incorrect timing constraints; e.g. STA detected a multicycle path 5 clocks long and directed synthesis to meet that constraint, but logic actually requires a valid result in 4 clocks. Simulation might catch an apparent functional error or setup violation there.

 

Gate-level simulation is basically like searching for a needle in a haystack, at least beyond those conditions I described earlier.

 

MarkCurry mentioned better ways to solve that problem, and I've been wondering what else is available and realistic in the FPGA space.

 

In ASICs, LEC (Logic Equivalence Checking) + STA has been good enough to sign off millions of chips. I've seen varying support over the years for LEC tools supporting FPGAs, but never had a chance to really test it out, or seen tools and support stay in place long enough with enough documentation to make a plan around.

 

I've had some luck with ChipScope in the past, but never learned enough API to build a test environment around it. And that can't exercise gates at PVT extremes.

 

So, what else is there, and what's working well?

 

Many sincere thanks!

 

 

0 Kudos
Highlighted
Scholar
Scholar
16,911 Views
Registered: ‎09-16-2009

john.johnson2@rockwellcollins.com wrote:

Regarding gate-level sims, especially with timing: In my industry (DO-254), a lot of timing runs still have to happen. :(

 

I try to limit that to any async chip-level interfaces, clock domain crossings, reset circuits, and things like that. If all I/O's are registered, there is little value in simulating synchronous parts of the core. If post-route STA reports no timing violations, then the only case that immediately comes to mind is where you have missing or incorrect timing constraints; e.g. STA detected a multicycle path 5 clocks long and directed synthesis to meet that constraint, but logic actually requires a valid result in 4 clocks. Simulation might catch an apparent functional error or setup violation there.

 

Gate-level simulation is basically like searching for a needle in a haystack, at least beyond those conditions I described earlier.

 

MarkCurry mentioned better ways to solve that problem, and I've been wondering what else is available and realistic in the FPGA space.

 

In ASICs, LEC (Logic Equivalence Checking) + STA has been good enough to sign off millions of chips. I've seen varying support over the years for LEC tools supporting FPGAs, but never had a chance to really test it out, or seen tools and support stay in place long enough with enough documentation to make a plan around.

 

 


For me, the power with LEC tools in the ASIC world was when we were manually mucking with the netlist post-synthesis.  There's a variety of reasons that this may have been neccesary in ASICs - none of which really apply in FPGAs (e.g. adding scan chains, ECO's, other things).  So for FPGA's I just don't see the neccessity of running an LEC tool.  You run an RTL to gate LEC on you're FPGA - you're just QCing the synthesis tool.  That's Xilinx' job, not mine.

 

Good STA is key (along with good synchronous design principles).  Everything should be constrained, with design reviews of constraints.  The main hole in this is the validity of the timing constraints.  Design reviews (and reuse of reviewed constraints) are our only tool here.

 

As to IO timing - I guess we just don't use many "exotic" interfaces.  Sure, multi-GBit transceivers - both those are pretty much packaged up completely by Xilinx.  Wide "parallel" interfaces are mostly trained (i.e. DDR).  Others are slow enough, and have clocked FFs in the IOB, that there's little to go wrong / have already proven existing implementations.

 

Chipscope is useful for debug, and diagnostics.  But not part of any "signoff" flow for us.

 

Gate-level timing sims took too long 15 years ago, and rarely found actual problems.  Just a headache of testbench "chasing the Xs" leading to testbench problems, not actual design problems.  Today, it'd take literally days to simulate even the most minimal of tests.  (And that's after the all the "chasing the Xs" - which could take weeks).

 

Regards,

 

Mark

0 Kudos
Highlighted
16,906 Views
Registered: ‎07-15-2015

Thanks for the feedback Mark.

 

I agree with all of that, except in life/safety-critical applications, regulatory agencies basically require us to re-do Xilinx's job of validating the synthesis too. The required gate-level sims are killing us timewise, leaving a perfect opening for LEC.

 

But without more data and experience on LEC flows, I won't be able to convince anyone there is another way.

 

Cadence, Mentor, and Synopsys have all, at one time or another, offered some LEC support for some FPGA families. I don't know what the current state of that business is, but would certainly like to.

 

OneSpin360 is advertising an LEC tool for FPGAs, and might have more motivation to support it in the less lucrative FPGA space than the big 3 ASIC EDA providers do. Any insight on that?

 

STA is obviously the better approach to verifying timing than gate-level sim, but did you have anything else in mind regarding functional correctness, other than LEC and/or vendor trust?

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
16,176 Views
Registered: ‎07-01-2010

Small correction:

 

@avrumw wrote:

"Once you have done all this, you close the elaborated design, and it goes away (i.e. you cannot "continue" the rest of the synthesis process). When you synthesize the design, it will re-elaborate it as part of the synthesis run."

 

Clarification:

The above paragraph is obsolete, there is no need to “re-elaborate”. Result of elaboration is stored, and synthesis will continue on top of that without repeating the work.

 

Regards,

Achutha

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------
0 Kudos
Highlighted
Guide
Guide
16,111 Views
Registered: ‎01-23-2009

@achutha,

 

I don't think that your "clarification" is correct. Even in the most recent version of the tools (2016.2), the results of elaboration are not stored. The first checkpoint is generated as a result of the "Run Synthesis" process, and is stored in the directory associated with the "synth_1" design. The synthesis process always starts directly from the sources_1 source files, regardless of whether the design has been elaborated previously using the "Open Elaborated Design".

 

So I believe my original description of the elaboration process is still correct and current.

 

Avrum

0 Kudos