Michael S (already5chosen.delete@this.yahoo.com) on August 19, 2019 4:37 am wrote:
> aaron spink (aaronspink.delete@this.notearthlink.net) on August 19, 2019 4:05 am wrote:
> > Jouni Osmala (fname.sname.delete@this.aalto.fi) on August 15, 2019 9:03 pm wrote:
> > > Does that operate on C code or VHDL or what? Just curious if really fast
> > > c compiler/linker with good optimizations would solve that problem.
> > >
> > It is an HDL to C object code flow instead of the more traditional interpreted flow (though those if
> > anything are slower to compile). The HDL to C results in models that run significantly faster( order
> > to orders of magnitude). In addition, it leverages all the benefits of a standard C flow over some
> > proprietary interpreter including the robust testing and debug infrastructure and optimizations.
> >
> >
>
> So C part of the tool chain has to deal with huge number of machine-generated modules with unusually
> high, relatively to hand-written C, proportion of global functions and variables?
> I.e. something for which "major" compilers and linkers (gcc,
> llvm-clang, MSVC, ICC) were not really optimized?
> Or is it even worse and generated modules are in C++?

I don't know which exact tool Aaron is using but
a) Xilinx's simulator clearly uses GCC. I think it's C but I never looked under the hood.

b) Cadence's simulator somehow converts to native code. It _seems_ to handle it internally without using open source compilers as infrastructure.

In any case, 10 million lines of code isn't underheard for software projects. And 15 minutes link time isn't either.