4 ms·

I feel like this is kind of like saying people shouldn't write imperative software until they've drawn a flowchart for all the logic. Sure there are some cases

I feel like this is kind of like saying people shouldn't write imperative software until they've drawn a flowchart for all the logic. Sure there are some cases where it might be a good idea, but if it's a requirement to understand the design, then your language isn't doing its job.

theyoungestgun 10y ago
Psst . . . verilog (not saying the same for systemVerilog) isn't doing its job ;)
deleted 10y ago
[deleted]
blackguardx 10y ago
Drawing a timing diagram is the same as thinking about how a CPU will execute instructions that you write or your compiler spits out. Optimization is important in hardware due to cost, speed, and power implications of hardware design. These tradeoffs are there for software design as well, but to a much less extent.
akiselev 10y ago
It's not the same thing at all. Since modern processors abstract over the physical location/layout of memory, code at any location can access data or call code at any other location. This allows you to just jump in and write your logic without worrying about how the silicon physically moves your bits around. You simply can't do that when designing silicon. All of your transistors have to be physically connected on a 2d plane so you can't abstract over the physical location or layout of your "objects" (logical groups of transistors and how they interconnect in this case). This means that the vast majority of possible Verilog designs are impossible to physically implement because there is only a finite amount of space to route traces from one transistor to another. Writing Verilog before drawing a block diagram is like writing an embedded IoT framework in Ruby before checking whether your target microcontrollers have enough ROM/RAM to run the Ruby interpreter. For example, if you had a stack allocated object containing a queue and you changed it to always heap allocate the queue, it would still do the same thing as before but with a different memory layout. If you did the equivalent in silicon (like move the location of a group of transistors), at best it would break your functionality and at worst it would make the design unsynthesizable. Swapping an interface to point to an implementation with a different size (I.e. switching an IQueue* to an MPSC Queue from a SPSC Queue) is a trivial change with software but when you swap a 100 transistor interface with a 1000 transistor one you have to move the blocks around it, often requiring significant changes to avoid breaking functionality.
- aninhumer 10y ago
  Sure locality is important, but I think you're overestimating the necessity of planning for it. When I was doing hardware design a few years ago, I wasn't worrying about the physical layout of anything. We kept the interconnect limited to a modular hierarchy, and we didn't seem to have many problems. Of course, we were in a research group, so performance was less important to us. And we were working with FPGAs, so we didn't need to get it right in one go (and I think the fabric is better able to cope with looser style). That said, I think there are cases where you can afford to sacrifice a bit of design efficiency to increase development speed. And if you're working with FPGAs, you may even be able to optimise later. EDIT: Also the impression I got is that while industry does spend a lot of effort on it, complex designs are nowhere near as optimal as they could be. The first clue should be that an Intel chip has clearly defined blocks on it, rather than being a mess of interleaved logic. They divide the design like that to make it tractable for the designers. > If you did the equivalent in silicon (like move the location of a group of transistors), at best it would break your functionality and at worst it would make the design unsynthesizable. I don't think this makes much sense unless you're presupposing a prescriptive physical layout. Sure, if you were to move a bunch of synthesized circuitry somewhere else and then try to reconnect it, it's not going to work. But that's not something you'd actually do in an abstract model. What you might do is move a bunch of HDL logic from somewhere in the module hierarchy to somewhere else, in which case the synthesizer will move everything else around to compensate.
  - akiselev 10y ago
    >> Of course, we were in a research group, so performance was less important to us. And we were working with FPGAs, so we didn't need to get it right in one go. What were you researching/designing? The higher your clock speeds/bandwidth requirements are and the more complex your designs, the more locality matters. The last design I worked on, for example, was a 32x32 crosspoint switch with total bandwidth in the low hundreds of gigabits and we eventually had to tweak cell locations manually on the mask to get the design working to spec. In modern chip design, bandwidth on that scale is pretty common so i don't think we're talking about the extremes of hardware design. >> I don't think this makes much sense unless you're presupposing a prescriptive physical layout. Sure, if you were to move a bunch of synthesized circuitry somewhere else and then try to reconnect it, it's not going to work. But that's not something you'd actually do in an abstract model. Again, depends on a variety of factors. Some of the designs I've worked on have had internal clock signals that couldn't travel across a fraction of the chip before attenuating too much to switch a transistor. Sure a low speed design can be synthesized without caring about physical layout but once you're in the RF/high speed digital realm, the relative location of dependent high speed blocks matters much more and the HDL abstractions start to leak or breakdown entirely.

theyoungestgun 10y ago

Psst . . . verilog (not saying the same for systemVerilog) isn't doing its job ;)

deleted 10y ago

[deleted]

blackguardx 10y ago

Drawing a timing diagram is the same as thinking about how a CPU will execute instructions that you write or your compiler spits out. Optimization is important in hardware due to cost, speed, and power implications of hardware design. These tradeoffs are there for software design as well, but to a much less extent.

akiselev 10y ago

It's not the same thing at all. Since modern processors abstract over the physical location/layout of memory, code at any location can access data or call code at any other location. This allows you to just jump in and write your logic without worrying about how the silicon physically moves your bits around. You simply can't do that when designing silicon. All of your transistors have to be physically connected on a 2d plane so you can't abstract over the physical location or layout of your "objects" (logical groups of transistors and how they interconnect in this case). This means that the vast majority of possible Verilog designs are impossible to physically implement because there is only a finite amount of space to route traces from one transistor to another. Writing Verilog before drawing a block diagram is like writing an embedded IoT framework in Ruby before checking whether your target microcontrollers have enough ROM/RAM to run the Ruby interpreter. For example, if you had a stack allocated object containing a queue and you changed it to always heap allocate the queue, it would still do the same thing as before but with a different memory layout. If you did the equivalent in silicon (like move the location of a group of transistors), at best it would break your functionality and at worst it would make the design unsynthesizable. Swapping an interface to point to an implementation with a different size (I.e. switching an IQueue* to an MPSC Queue from a SPSC Queue) is a trivial change with software but when you swap a 100 transistor interface with a 1000 transistor one you have to move the blocks around it, often requiring significant changes to avoid breaking functionality.

aninhumer 10y ago
Sure locality is important, but I think you're overestimating the necessity of planning for it. When I was doing hardware design a few years ago, I wasn't worrying about the physical layout of anything. We kept the interconnect limited to a modular hierarchy, and we didn't seem to have many problems. Of course, we were in a research group, so performance was less important to us. And we were working with FPGAs, so we didn't need to get it right in one go (and I think the fabric is better able to cope with looser style). That said, I think there are cases where you can afford to sacrifice a bit of design efficiency to increase development speed. And if you're working with FPGAs, you may even be able to optimise later. EDIT: Also the impression I got is that while industry does spend a lot of effort on it, complex designs are nowhere near as optimal as they could be. The first clue should be that an Intel chip has clearly defined blocks on it, rather than being a mess of interleaved logic. They divide the design like that to make it tractable for the designers. > If you did the equivalent in silicon (like move the location of a group of transistors), at best it would break your functionality and at worst it would make the design unsynthesizable. I don't think this makes much sense unless you're presupposing a prescriptive physical layout. Sure, if you were to move a bunch of synthesized circuitry somewhere else and then try to reconnect it, it's not going to work. But that's not something you'd actually do in an abstract model. What you might do is move a bunch of HDL logic from somewhere in the module hierarchy to somewhere else, in which case the synthesizer will move everything else around to compensate.
- akiselev 10y ago
  >> Of course, we were in a research group, so performance was less important to us. And we were working with FPGAs, so we didn't need to get it right in one go. What were you researching/designing? The higher your clock speeds/bandwidth requirements are and the more complex your designs, the more locality matters. The last design I worked on, for example, was a 32x32 crosspoint switch with total bandwidth in the low hundreds of gigabits and we eventually had to tweak cell locations manually on the mask to get the design working to spec. In modern chip design, bandwidth on that scale is pretty common so i don't think we're talking about the extremes of hardware design. >> I don't think this makes much sense unless you're presupposing a prescriptive physical layout. Sure, if you were to move a bunch of synthesized circuitry somewhere else and then try to reconnect it, it's not going to work. But that's not something you'd actually do in an abstract model. Again, depends on a variety of factors. Some of the designs I've worked on have had internal clock signals that couldn't travel across a fraction of the chip before attenuating too much to switch a transistor. Sure a low speed design can be synthesized without caring about physical layout but once you're in the RF/high speed digital realm, the relative location of dependent high speed blocks matters much more and the HDL abstractions start to leak or breakdown entirely.