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 needed in ASIC flow?

Status
Not open for further replies.
ivlsi

ivlsi

Advanced Member level 3
Joined
Feb 17, 2012
Messages
883
Helped
17
Reputation
32
Reaction score
16
Trophy points
1,298
Activity points
6,868
Hi All,

Why is the LEC flow needed? There are Synthesis tools as also P&R tools... Don't they do their job right?

Could you please provide an example where the LEC tool can find a problem, which cannot be discovered neither by the synthesis nor P&R tools?

Thank you!
 

ivlsi said:
Hi All,

Why is the LEC flow needed? There are Synthesis tools as also P&R tools... Don't they do their job right?

Could you please provide an example where the LEC tool can find a problem, which cannot be discovered neither by the synthesis nor P&R tools?

Thank you!
Click to expand...

You are forgetting the most obvious issue that all tools have... they are piloted by humans. Very easy to make mistakes in physical synthesis that will make the design very different from the RTL.
 

yes, but this is a job of the Synthesis tool... If you cannot rely on the tools, don't use them (otherwise it will be an endless loop)!
 

ivlsi said:
yes, but this is a job of the Synthesis tool... If you cannot rely on the tools, don't use them (otherwise it will be an endless loop)!
Click to expand...

read my comment again. the tools are fine, humans are not. I can tell the tool to connect a reset to an enable instead. the tool will just go with it, doesn't know what my intent is. LEC will catch it, however.
 

its something like this - why do yo use a RTL compiler to validate your code for syntax checks or anything like that. or why do you do GLS after you have done RTL level simulations.
All want to be sure that there are no human or tool issues in the flow and overall design intent/specs are not lost as a part of the implementation.

NOt only does EC catch tool issues but also helps capture human issues in case in your script did not mark the necessary preserve and either synthesis or pnr optimizes that logic you will see these as unmapped in EC and can review.

There are more reasons as well - ob RTL your adding CG, DFT that can cause an impact - GLS takes weeks to come EC is a faster solution to proceed with the flow and so on.
 

why is LEC not involved in the FPGA flow? Bad scripts might be written also by FPGA engineers, FPGA tools are also not perfect... Why? Is this because of the time-to-market issue? Why to check something virtually (like LEC, simulations, etc) while u can just program the device and check it in the lab (I don't like this answer, but... is this real?)
 

either your mistaken or completely aloof from the industry and discussing just for the sake of trying to prove your point. FPGA flows also have EC.. pls do a google search...
you may choose not to like anything.. that is your prerogative...

IN ASIC how will you test something on board till you dont have the device.. these test are done before you have the full packaged IC that sits on your board.
 

why is LEC not involved in the FPGA flow?
Click to expand...
It is surely done, but not as strictly as ASIC design flow.

It completely depends on the tools used by a company. In a place where e.g., Synopsys VCS or Cadence is used, Lints checks are enabled just by adding the appropriate switch to the compilation command script.
 

As far as I know, the Lint is some pre-compelation stage... So, before the RTL Designer sends its RTL to the BackEnd group, it can runs the LINT (HAL) in order to find a potential problems, which might arise during the RTL synthesis.

But what the sense to apply a LINT switch as a part of the synthesis flow? In any casy, the RTL problems will pops up in the synthesis log during RTL elaboration.

But probably I miss some point... Can LINT catch some RTL problems, which are not reported by the synthesys tool during RTL Elaboration? What problems could be catched? Could you probably provide some examples?

Some time ago I tried to add some custom rules to the LINT tool (HAL) and it was an headach ...
 

You are confusing lint with report_timing -lint
One is a class of tools that does code analysis, the other is a verbose report for a timing engine.
 

ivlsi said:
why is LEC not involved in the FPGA flow? Bad scripts might be written also by FPGA engineers, FPGA tools are also not perfect... Why? Is this because of the time-to-market issue? Why to check something virtually (like LEC, simulations, etc) while u can just program the device and check it in the lab (I don't like this answer, but... is this real?)
Click to expand...

If you mess up an FPGA you don's have to spend $2 million dollars to turn a mask.
 

I will tell you a example, what will happen if you touch clock tree in PnR by adding extra inverter in clock path. Your pnr will go through but what you did was logically not correct ,your LEC will point this
 

LEC- Logical equivalence checking Lec we will run to make sure functional intent is retained at every stage of the flow
to ensure the functional check between RTL and netlist
It can be 2representation
1.RTL v/s Netlist
2.netslist v/s Netlist

Stage :before place and route (systhesis stage)
1. We will run lec between RTL code to gate level synthesis Netlist to check synthesis tool didn't changed anything on functional perspective
2. We will run after place_opt stage make sure functionality
After route stage, after each eco stage we will lec
If logical changes done, need to run lec
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top