Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

Status
Not open for further replies.
hariharan.gb

hariharan.gb

Junior Member level 1
Joined
Feb 2, 2012
Messages
17
Helped
3
Reputation
6
Reaction score
3
Trophy points
1,283
Location
Bangalore, India, India
Activity points
1,430
LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

Hi,

Please can anyone share the exact findout of why we add RAM as black box and also give lib files in addition for proeceeding with LEC.

For Example,
*******************
lec.do>>>>>

add no_translate /
ram1 /
ram2 /
ram3

add search path ..../*.lib /
ram1.lib /
ram2.lib /
ram3.lib


<compare >
*******************

what actually happens, when we are including this Library ?, and without this Library definition LEC will pass?

any comments ..

Hariharan.gb
.......
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

Hariharan.gb

The idea of performing LEC is do a verification of RTL with the GLN (Gate Level Netlist) after synthesis. Hence during synthesis the memory models are not synthesized and are only macros hence to avoid their compare all memories, analog blocks and non-synthesizable constructs RTL constructs are treated as notranslate.

Also your RTL will only have the instantiation of the memory (in your case ram) which will be picked up from the library provided.

Since we are not comparing these modules, LEC will pass if all other logic is verified as per the RTL (golden).

Hope this helps...
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

thanks ...

but then, i have one more quick question, like. as far as LEC is concerned, we need to have proper key points on both golden and revised.
For which in synthesis i perform wrappers over my RAM, which will be treated as keypoints now for considering start point of In cones and Out cones.

So, now here we do have proper proper keypoints, and so putting RAM as Black box, logical comparison on RAM(BBOX) will not be performed.

Is that still i need to give lib files for reference, what difference it makes if i am not giving lib files for reference, and does it varies with your LEC licences, like higher version licesnces will need this lib refernce of RAM also, to perform LEC.

Please correct me if my understanding is wrong.
any materials for refernce
Click to expand...

hariharan :)
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

hariharan,

you're correct in LEC we need to have proper key points. First answering your BBOX issue. Pls note that addnotranslate when set on memories also uses an option "both" so the RAM gets BBOX both the sides - one more reason once you have build your golden and revised side your report black box output should be balanced on both sides. (G and R).

Now coming to the wrapper that is created, if your doing hierarchical compare this will be handled by LEC since it goes bottom-up in hier comparison. Once it reaches the top module it will unblackbox / flatten all the modules that had non-eq's and re-compare them for which these wrapper based ones should be gone and it should be clean until and unless there is no other logic being added.

I don't think this has got anything to do with a specific license.
 
Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

englishdogg said:
hariharan,

you're correct in LEC we need to have proper key points. First answering your BBOX issue. Pls note that addnotranslate when set on memories also uses an option "both" so the RAM gets BBOX both the sides - one more reason once you have build your golden and revised side your report black box output should be balanced on both sides. (G and R).

Now coming to the wrapper that is created, if your doing hierarchical compare this will be handled by LEC since it goes bottom-up in hier comparison. Once it reaches the top module it will unblackbox / flatten all the modules that had non-eq's and re-compare them for which these wrapper based ones should be gone and it should be clean until and unless there is no other logic being added.

I don't think this has got anything to do with a specific license.
Click to expand...

Please brief me the challenges of LEC
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

Challenges of LEC:

1. Map the golden and revised design correctly and in a throughout. Make sure that nothing important is not left as not-compared.
2. When non equivalent points are found (due to synthesis problems or hand-made changes) - know how to use the LEC tools to spot the problems and fix them.
3. Reduce run-time (big blocks LEC run might take a few days - whole week).
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

OhaAmo said:
Challenges of LEC:

1. Map the golden and revised design correctly and in a throughout. Make sure that nothing important is not left as not-compared.
2. When non equivalent points are found (due to synthesis problems or hand-made changes) - know how to use the LEC tools to spot the problems and fix them.
3. Reduce run-time (big blocks LEC run might take a few days - whole week).
Click to expand...

What do you mean by run time???? whole week???
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

Yes, i mean a whole week.
A basic RTL vs Netlist LEC run involves actually an entire synthesis of the RTL, then mapping key points and finally comparing to the netlist.
This process can take in big blocks (over 1 million cells) can take from several days to even a week. Therefore a proper mapping of both golden and revised designs can reduce the run-time dramatically.
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

OhaAmo said:
Yes, i mean a whole week.
A basic RTL vs Netlist LEC run involves actually an entire synthesis of the RTL, then mapping key points and finally comparing to the netlist.
This process can take in big blocks (over 1 million cells) can take from several days to even a week. Therefore a proper mapping of both golden and revised designs can reduce the run-time dramatically.
Click to expand...

If some IP contains approx 7000 gates then how much time it will take to synthesize and LEC of that IP
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

Well it depends on the logic complexity, but i would say on average that a basic synthesis and LEC run of 10K gates shouldn't take more than 1 hour.
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

For me anything that takes a week for LEC however big the design is either is the problem of the flow or an issue with the tool/product.
Especially if it is netlist to netlist falt compare it should not take that long at all.

In which stage and what comparison you see such huge runtime.
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

Huge runtimes happens to me when:
1. RTL vs Netlist (full synthesis of the RTL is required).
2. Huge designs (around 300-400K of flip flops).
3. Complex design that involves many hierarchies, multipliers, adder etc.
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

For case 1 - i believe you are reffering to a post synthesis netlist (handoff to PnR) in this case the runtime is usually high bt never a week. In cases where the runtime is high we break it down to two steps - a. from RTL to 1st map hierarchical b. 1st map to final flat.

In big designs also i hv not seen the runtime of a week so far only for LEC, it is completely unproductive and useless (my personal view)
 

Re: LEC - why RAM as "Not Translate" or as "black box", and lib file's also in LEC.

OhaAmo said:
Well it depends on the logic complexity, but i would say on average that a basic synthesis and LEC run of 10K gates shouldn't take more than 1 hour.
Click to expand...

I would like to add here, it depends on the License that you use, Normally the 1 Hour is XL ind of license. (Not GXL). Am i right OhaAmo?

- - - Updated - - -

englishdogg said:
For case 1 - i believe you are reffering to a post synthesis netlist (handoff to PnR) in this case the runtime is usually high bt never a week. In cases where the runtime is high we break it down to two steps - a. from RTL to 1st map hierarchical b. 1st map to final flat.

In big designs also i hv not seen the runtime of a week so far only for LEC, it is completely unproductive and useless (my personal view)
Click to expand...

1 week run time, even I have seen - when have more logical macros, or complex adders or multipliers, we face this issue.,
I have seen a runtime of 5 days, which made us to debug and call Application engineer, and resolved issue by adding new modeling directives, which was later release as patch in LEC. 8-O
May be if we miss some constraints, we face this problem. add proper modeling directive., and guide files like .svf (Formality) or .ovf (cadence LEC). :p
 
Last edited:

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top