4 ms·

Are you me? Honestly, that all sums it up even better. In an embedded role, you are always a second class citizen. After 6-12 months of planning by the hardware

Are you me? Honestly, that all sums it up even better. In an embedded role, you are always a second class citizen. After 6-12 months of planning by the hardware folks: "The hardware is all done. Where's the software? What do you mean it's not finished, you had all year...?" You're a complete afterthought, and it's only amplified when working with a team that doesn't really "get" that without access to the actual, finalized hardware you're extremely limited in capabilities. It only gets better when they decide to go with one-off vendors who have a single product support engineer and its pulling teeth any time something goes wrong. It's often hardware related, but who cares -- you're the guy at the end of pipeline who's tasked with making it work, so yeah, you feel the wrath. I'm only extra cynical because I'm dealing with that right now. As I have many times before, though. It's part and parcel.

Taniwha 10y ago
OK, I've worn both hats - chip designer and embedded systems programmer - it makes me better at both - I get to be thye chip guy who understands software and the software guy who understands hardware - it means I get the interrupt setting/clearing logic race free and make sure all the registers can be read, and can make tradeoffs that minimise the amount of hardware we have to build. The big issue is timing (and latency) - the chip guys are working on long timelines - they're already working on the next chip when the first chip's silicon comes back, their investment and attention is elsewhere, the software guys aren't going to rev up much before real hardware is in their laps, and certainly aren't going to spend any time on that second chip while they're still wrangling the first one - it's not so much a cultural gap between the groups as a gap in time
- supahfly_remix 10y ago
  Isn't hardware emulation common these days? Zebu, palladium, etc. Can emulate a chip and software, which can speed time to market.
  - Taniwha 10y ago
    yes, but it's not cheap and is essentially a second parallel tapeout path that slows your chip design time - if you're building a CPU you likely build a high-level software model and code to that (with some register-virtualisation layer), then test against that as part of the chip DV (QA) process

Taniwha 10y ago

OK, I've worn both hats - chip designer and embedded systems programmer - it makes me better at both - I get to be thye chip guy who understands software and the software guy who understands hardware - it means I get the interrupt setting/clearing logic race free and make sure all the registers can be read, and can make tradeoffs that minimise the amount of hardware we have to build. The big issue is timing (and latency) - the chip guys are working on long timelines - they're already working on the next chip when the first chip's silicon comes back, their investment and attention is elsewhere, the software guys aren't going to rev up much before real hardware is in their laps, and certainly aren't going to spend any time on that second chip while they're still wrangling the first one - it's not so much a cultural gap between the groups as a gap in time

supahfly_remix 10y ago
Isn't hardware emulation common these days? Zebu, palladium, etc. Can emulate a chip and software, which can speed time to market.
- Taniwha 10y ago
  yes, but it's not cheap and is essentially a second parallel tapeout path that slows your chip design time - if you're building a CPU you likely build a high-level software model and code to that (with some register-virtualisation layer), then test against that as part of the chip DV (QA) process