Is there a cocept of hardware design patterns (as in software design patterns)?

Is there a concept of hardware design patterns (as in software design patterns)?

Greetings.
I am a beginner who wants to get into industry of HDL design. I have some knowledge and understanding of RTL design (in VHDL/Verilog), but I cannot design an entire system. And I want to fix that.
I have never come across a description of design patterns in hardware design. If you had - please suggest a book. Also, please suggest a good book on high-level (not RTL) HDL/hardware design practices and approaches.
Thanks!

System level modelling can be done using System languages like SystemC, SystemVerilog etc.
You can use book: A SystemC Primer by J. Bhasker. for learning SystemC
SystemVerilog Books
SystemC - Wikipedia, the free encyclopedia
SystemVerilog - Wikipedia, the free encyclopedia
Welcome To SystemVerilog Central

Thank you.
Actually, I did study both SystemVerilog and SystemC (never liked SV, though). What I am asking is how and when to use those tools. I need to understand basic techniques and approaches for system-level, architecture design, not specific languages.

Computer Architecture: A Quantitative Approach by Hennessy and Patterson.
Computer System Architecture by M. Morris Mano
Electronic System Level Design: An Open-Source Approach by Sandro Rigo and Rodolfo Azevedo

I think the OP wants things more along the line of how to design a system. Things like determining when to use multiple clock domains, when to gated clocks, when to provide a qualifier with data, when to perform control on a b-by-block basis, when to do it on a cycle-by-cycle basis, how to avoid fifo overflows/underruns, how to avoid deadlocks, determining effective handshaking methods, strategies for sharing resources, effective HW/SW boundaries, when/what to pipeline, when c-slow works well, etc...

I had looked at a few of the design patterns and attempted to place them into an HDL context. Obviously the structural ones are applicable, while the creation ones are mostly not.

permute said:

I think the OP wants things more along the line of how to design a system.

Click to expand...

Exactly! Thanks!

in anycase, my best advice is to start with a few of the general topics I've listed. the biggest concepts are:
1.) handshaking -- does the destination request data from the source, or does the source inform the destination of new data? several issues arise, especially with fringe cases. the streaming data case is different from the packet-data case in that in the latter, logic must be able to flush itself. eg, any partially processed data shouldn't wait for more valid data. in the streaming case, it is ok to assume that more data will be available in a timely fashion. in some cases, new data is available every cycle. in others, it is available in a predictable cadence, in others, it is available occasionally.
2.) block vs cycle based control -- control logic is often complex (at least for high-speed designs). It also often has very tight feedback (minimum latency in cycles between a change in control and the resulting effect). by making decisions every 16 cycles (or more), instead of on every cycle, the control logic can be run very slow. This makes it much easier to meet timing.
3.) pipelining and c-slow -- both techniques to increase throughput. c-slow allows for tight feedback in a pipelined system as long as the problem can be broken into multiple independent channels. Pipelining itself allows a problem to be broken into several stages, allowing shorter logic paths per stage. like a factory, multiple steps are required to get even one assembled output, but once the pipeline has started, many outputs could be "in the pipeline".
4.) HW/SW -- the most important practical choice. By far. Once you get comfortable with logic, pipelining, etc, you can make VERY fast logic. But there is a lot of logic that doesn't need this. In such cases, a software approach can be best. Either by means of a one-time CPU, soft-cpu, external CPU, etc... Often, large amounts of time (area, etc...) are wasted on writing highly complex, high-performance HDL for things that could be performed by software. IMO, if you want to excel at FPGA/ASIC design, you should learn how capable microprocessors/DSPs are, and determine what you don't need to waste FPGA/ASIC resources on.
5.) bandwidth and storage requirements. basically, determining if/how fifo's overflow/underflow and how large they must be.

permute said:

I think the OP wants things more along the line of how to design a system.

Click to expand...

Alexium said:

Exactly! Thanks!

Click to expand...

+1 on that.

Given how much there is to know on the subject I consider myself a newbie on this as well. Afore mentioned design patterns + some best practices would be much appreciated! Any books, links, papers, etc... Thanks in advance!

---------- Post added at 09:46 ---------- Previous post was at 09:35 ----------

Thanks permute, all great points!

And most of all this one:

permute said:

4.) HW/SW -- the most important practical choice. By far. Once you get comfortable with logic, pipelining, etc, you can make VERY fast logic. But there is a lot of logic that doesn't need this. In such cases, a software approach can be best. Either by means of a one-time CPU, soft-cpu, external CPU, etc... Often, large amounts of time (area, etc...) are wasted on writing highly complex, high-performance HDL for things that could be performed by software. IMO, if you want to excel at FPGA/ASIC design, you should learn how capable microprocessors/DSPs are, and determine what you don't need to waste FPGA/ASIC resources on.

Click to expand...

That one is the biggest factor of all. By chosing what to do and what NOT to do in HDL, you get to spend your HDL design time on the things that actually matter.

Solving part of the problem in software is SO much cheaper than doing the same thing in a properly designed module in an fpga.

Pipeline + c-slow is also very useful. Actually if I remember correctly, I only learned about c-slowing because permute mentioned it to me. Used it succesfully in a working design.

The main thing there (IMO) is to design such that your feedback loop is fairly loosely coupled. As in as many cycles as you can make it. That gives you more breathing space as it were to do the c-slowing properly.

Never heard of C-slowing before, quite a neat trick.
I'd like to emphasize that I'm asking for any books and guidelines on high level design (architecturing), because at the moment we are discussing the details of implementation, which is at the bottom of the designing process. And I'm interested in mastering the top of it. And by design patterns I meant something more general than what you are currently suggesting, because software design patterns are not about implementation, they are all about architecture, modularity and flexibility.

which themselves are implementations.

as an example, one common thing between software and hardware is the idea of coupling. In HDL, this expresses itself very often in a block diagram.

eg, module A sends signals to B and C. B sends signals to C. C sends signals to D.
In such cases, I will generally have module A send signals only to B, and B to C, C to D. this simplifies the block diagram. It might seem silly for A to communicate with C by sending signals through B, but it often makes things easier. Further, it allows for the formation of generic interfaces to a much larger extent. In software, this is similar to "chain of command", at least to some degree. For hardware it becomes very nice when you need to balance pipeline delays (both in terms of cycles, and qualified clock cycles). It also becomes useful when FIFO's and processing is done between two communicating modules.

Like I've said, the structural patterns lend themselves to HDL designs in fairly obvious ways. visitor and chain of command are fairly common.

But design goals heavily influence what you can and can't do in logic. design for pipelines, c-slow, reconfiguration, multi-clocks, gated-clocks, streaming, non-streaming, blocks at a time, etc... is all different. For example, c-slow and reconfigurable logic place some limitations on the FPGA resources. multi-clock designs clearly have domain crossings that need to be addressed. gated clocks and non-streaming designs become difficult to pipeline because flushing must occur. the idea of processing blocks at a time becomes difficult if blocks can be fragmented, variable size, etc... design for simulation, for test, for etc... are all other goals that must be considered. Each places slightly different restrictions on what you can and can't do.

and as before, the HW/SW boundary should always be considered. There are so many times when a simple 8b uC can be used to implement slow logic, but instead it is implemented using months of work and 10-25% of an FPGA.

unfortunantly, I've not seen any good books on the topic. "Reconfiguarable Computing" details high-level synthesis and transaction level modeling, and a few stream-processing and other paradigms (including c-slow), but overall it not that close to what you want.

@ mrfibble:
making the feedback requirements loose also allows large and often complex portions of control logic become simple. This becomes important even if c-slowing can't be applied. Further, b-processing often allows for this case.