<Taek>
nmz787: looking briefly at the slide deck, it seems like it's more aimed at sythesis design as opposed to full custom design. Do you know if full custom houses are starting to look at software like this?
mrdata_ has joined #homecmos
pebble`_ has joined #homecmos
pebble` has quit [Ping timeout: 240 seconds]
mrdata has quit [Ping timeout: 240 seconds]
BitEvil is now known as SpeedEvil
<nmz787>
Taek: can you elaborate a bit more on what you mean "synthesis design" vs "full custom design"
<nmz787>
Taek: if I interpret what you're saying a bit more... I think you are asking to go from HDL to constraint-solver-generated schematics, then to constraint-solver-generated layout? or are you also asking for constraint-solver fab layer process steps to be solved for as well?
<nmz787>
the latter is something that I think is going to be fab sekretz, and I assume big timers have them, but maybe talk about it even less?
<nmz787>
i.e. their database about what material layers have compatible/incompatible thermal expansion coefficients, [in]compatible processing steps that would be required for certain features or materials
<nmz787>
mayyyybe the CRC handbook could give you some of that kind of data, which would then be usable by a constraint solver... but my bet is that only the big fabs will really have enough data on a really wide range of materials and processes, and wouldn't be giving that away (and probably not selling it either, outside of contract fab service)
<nmz787>
layer compatibility is something I fear might bite me even with a few simple layers
<nmz787>
Taek: also from what I know, more analog-feeling stuff is laid out by hand, like at the litho mask levels of design...
<nmz787>
it feels like it could/should all be automated, but it seems like all the details and IP and $ are preventing it from happening "now"/anytime-too-soon
pie_ has joined #homecmos
pie___ has quit [Ping timeout: 260 seconds]
<Taek>
I think we're more intersted in constraint solver layout
<Taek>
unless you think you could use a constraint solver to do something like develop a custom adder
<Taek>
actually, let me step back a bit
<Taek>
by synthesys design I mean going from HDL -> synthesizer -> chip layout
<Taek>
and by full custom I mean everything is hand-rolled, starting from the schematic, and then going to the cell choice, the routing, and sometimes even developing custom cells
<Taek>
as you get to the smaller transistor sizes, the design rules become really unmanageable
<Taek>
routing by hand gets a lot more difficult because you simply can't memorize a 300 page pdf with all the rules for how to route the various layers together
<Taek>
which means you end up doing a ton of guess-and-check, and probably missing a lot of stuff you might not miss if you had a machine helping you out
<Taek>
<nmz787> it feels like it could/should all be automated, but it seems like all the details and IP and $ are preventing it from happening "now"/anytime-too-soon
<Taek>
I would disagree with this
<Taek>
based on the fact that humans can hand-roll assembler substantially better than compilers can even on old open source languages that have been hyper optimized
<Taek>
Most of the advantages there sourcing from the fact that the computer knows things about the program that are very difficult for the compiler to understand unless your language is extremely expressive
<Taek>
My guess is that you've got a similar problem when it comes to routing. HDL probably isn't expressive enough to tell the synthesizer what all of the context is for routing
<Taek>
and so a human can do a lot better because they know a bunch of shortcuts that the synthesizer belives would create an invalid program
<Taek>
*circuit
pie_ has quit [Ping timeout: 264 seconds]
pie_ has joined #homecmos
<nmz787>
Taek: human-assisted or computer-assisted design flows are definitely a thing/possibility
<nmz787>
I feel a bit confused though, sounds like you disagree with my thoughts that the whole process can be a lot more automated, but you also realized humans suck when there's i.e. 300 pages of rules
<nmz787>
it isn't that design rules become unmanageable, I think, rather no one has come up with a system to properly manage all of them, and the various levels of abstraction they work on...
<nmz787>
lots of modelling/simulation issues come up, sometimes really stupid stuff like file formats (really their respective tools) being incompatible, all the way to things like modelling the whole chip in physical analog simulators (or SPICE) would take too slow for actual interesting (integration level) test content
<Taek>
no definitely do agree that the whole process could be a lot more automated, I just don't think that humans will be out of the picture anytime soon
<Taek>
and also definitely agree that this stuff would be a lot further along if it wasn't so bogged down by IP agreements and other garbage
<Taek>
best I can tell, pretty much everyone has their own in-house way of doing everything, whether it's Intel vs. TSMC, or whether it's Cadence vs. Synopsys, etc.
<nmz787>
fyi I'm at intel in validation
<Taek>
ah good to know
<Taek>
from what I understand, Intel is some of the worst at this in the business, even have to do in-house packaing
<nmz787>
hard to tell for me, since I haven't worked elsewhere in semiconductors
<nmz787>
but it's definitely a big hulking system
<sync>
what is so bad about doing in house packaging?
<sync>
I mean, they implement the full product lifecycle
<Taek>
sync: just means that you can't learn from what everyone else is doing as easily, because decisions you made years ago may get in the way
<nmz787>
I took that comment to mean they have even more shit to think about and coordinate
<sync>
well, you usually don't want to do that
<sync>
as everybody has their process figured out more or less
<sync>
so any deviation is a risk
<nmz787>
yeah they are super risk averse
<sync>
I mean, this is why "copy exactly" is a thing
<Taek>
right but if you aren't interoperable at all, it slows down innovation
<nmz787>
I regularly sigh at software/tool-flow fixes not making it to things I'm working on for an estimated ~2 years
<sync>
you don't need to be interoperable
<nmz787>
because no one who's already started design wants to make up for (new) technical debt (because they needed to update some software/tool, which causes some design refactoring to be necessary)
<sync>
for a fabless customer it doesn't matter as well
<sync>
as you just yell at the fab to make your file
<nmz787>
lack of modularity and seemless handoff is definitely a reason for anxiety (and probably profit loss)
<nmz787>
I get stuck at not knowing if this is inherent to semiconductors at large
<nmz787>
due to i.e. the immense complexity
<Taek>
best I can tell, it is
<Taek>
sync: it depends on what your goals are. If you make a diverse set of chips, the total lack of interoperability means that any tooling or parts you build for one process are completely irrelevant to chips that you need on another process
<nmz787>
there are definitely plenty of days I wonder if Intel's gonna get eaten alive by some fully-streamlined chinese/foreign effort
<nmz787>
but so far... they're still raking in the top $
<sync>
well, they have their market cornered
<nmz787>
Taek: I think they call that 'fungibility'
<sync>
but yeah, I suspect that this is gonna happen
<sync>
Taek: well, sure
<sync>
but if you make a lot of the same stuff, e.g. high power computing silicon you just clone the fab 3 times
<sync>
and be done
<sync>
lots of other vendors have dedicated fabs or lines for a purpose
<sync>
and the customer has to decide which standard cells they want or which process is applicable
<sync>
and if that fab closes down you need to respin your design
<nmz787>
sync: reusing fab lines is a popular issue... people get highly recognized for getting things like that to work, even if it's between only 2 products
<sync>
yes
<nmz787>
most of that is probably solvable with a constraint solver really
<Taek>
take the example of a constraint sovler for various routing problems. Lack of interoperability means you can't easily make one constraint solver that you can sell to all designers, though such a thing would probably benefit all designers
<sync>
yes, but usually that is the job of the vendor
<sync>
I know a lot of people that just get their HDL made
<sync>
so they can switch between fabs if they need to
<sync>
and pay for the fab to do the actual layout
<Taek>
that's going to get you a chip that's, depending, 2-5x worse than a full custom solution
<sync>
yes, but for most applications that does not matter
<Taek>
right, but the industry as a whole would be better if solutions we invented for solving certain problems on one process could be easily ported
<nmz787>
I'd say it probably matters how much you pay the fab for the design service (how well the solution will turn out)
<Taek>
you'd have a lot more incentive to pursue those types of solutions and automation
<nmz787>
too much $$ involved for things to move fast
<Taek>
but if your automated solution is only ever going to be relevant to 5 products, it's better just to do it by hand 5 times in a row
<nmz787>
not just cost of capital equipment either
<nmz787>
just the profits alone
<nmz787>
so much no one wants to risk all that $/power
<nmz787>
from what I can tell that sort of motivation even happens at a very low level (i.e. individual employees)... why document your process when you can be the gatekeeper (job security)... at least that's what I speculate on days where I'm really annoyed with some bullshit at work
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #homecmos
pie_ has quit [Read error: Connection reset by peer]