close By using this website, you agree to the use of cookies. Detailed information on the use of cookies on this website can be obtained on OneSpin's Privacy Policy. At this point you may also object to the use of cookies and adjust the browser settings accordingly.

Partitioning Drives Architectural Considerations

By Ann Steffora-Mutschler, Semiconductor Engineering

Semiconductor Engineering sat down to explore these issues with Raymond Nijssen, vice president of system engineering at Achronix; Andy Ladd, CEO at Baum; Dave Kelf, chief marketing officer at Breker; Rod Metcalfe, product management group director in the Digital & Signoff Group at Cadence; Mark Olen, product marketing group manager at Mentor, A Siemens Business; Tom Anderson, technical marketing consultant at OneSpin; and Drew Wingard, CTO at Sonics. What follows are excerpts of that discussion.

Semiconductor Engineering logo

Anderson: I want to add four important aspects. One involves the IP blocks you’re going to use. People decide fairly early on in most chips what processor they’re going to use, how many processors, and those are pretty fundamental decisions plus any changes. You need to be aware of those even in the early stage of the architectural analysis. The second aspect is how those are connected to the top-level bus structure. A hot topic now and in the last few years is networks on chips, where you reduce your bus structure by just having a bunch of independent chips that are connected by a completely asynchronous bus, resolving some of the old verification and implementation challenges. That tends to be decided very early. Power would be the third aspect. Power domains are pretty fundamental to every chip that’s out there these days, no matter what you’re building. People want more power, and there are lots of techniques, but most of them boil down to turning off or reducing power in low voltage on a whole set of blocks over time. That’s not decided quite as early, but it’s in the minds of the architects pretty early on because power is very much a part of the system specification. The last thing is the notion of designing with verification in mind, and maybe even changing your design a little bit with verification in mind. It’s something that’s been floating around for a while. I’m not convinced that it happens very often, but being in the verification space. Maybe using a NoC is one way to reduce the verification problem. So you have a bunch of blocks you really can verify independently, you verify the bus formally, make sure the protocol is right, and maybe you don’t actually do a whole lot with that whole chip as a monolithic verification entity. Those are the different dimensions as I see them.


Related Links