OH please, stop talking nonsense. what you get from the fab is not just the cell library, its also all the design rules and parameters. You can ignore the cell library if you want, like bitfury apparently did, but you cant do any meaningful physical design without adhering to the process rules. How are you going to implement one if you dont even know what layers the process has, transistor width, channel length, and a gazillion other process specific parameters and constraints?
Huh, more of this crap?
It's not a question of "not knowing" those things, it's a question of
having that data for all of the potential feature sizes you want to target. I don't understand why you think you can only know one thing at once.
Now it really sounds like you've never written software (or maybe aren't any good at it), because you can write software that runs on multiple architectures and operating systems really easily. You don't have to decide if you're writing a Windows program or Linux program before you start, even if you're using a language like C, C++. You just use different libraries and have the compiler generate binaries for different CPUs.
Yeah einstein, analogies break down. But if you want to continue it, HDL would be your pseudo code and what you get from the fab is the programming language and compiler. It may be less work to port your code from Java to C++ than starting from scratch, but it aint no last minute job either.
[/quote]
Analogies do break down. I seriously doubt it's equivalent to manually porting a program from Java to C++, or vice versa - but even if it was there are still tools that can convert programs in one programming language into programs into another programming langue automatically. For example
C++ to java converter and
Java to C++ converter. People use tools that convert other languages to JavaScript all the time.
It certainly wouldn't be a last minute job, but if you were building your program from the start to work after being run through one of these converters (i.e. running it as a compiler step and ensuring that everything worked, including your test cases while developing your code) then you're not going to run into a problem.
The only thing your "analogies" to software development are showing is that you don't know much about it.
Right. I get it. Because whats really important here is not whether or not Labcoin could ever deploy their 65nm asic before next spring, its who of us knows more about chip design right? Well, as it turns out, it seems I was on the money about labcoins inability and you were not. Probably just a coincidence.
Huh? They're late, and they're under powered. But they're only a week late and they're only under-powered by 60%. And their price is a lot lower then it was a week ago, reflecting reduced expectations.
Anyway, none of that has anything to do with whether or not you can design an IC in a way that's technology flexible.
