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