What are good Design Patterns for FPGA Designs

[vGoodtimes]

This thread is intended as a discussion, not as a specific question with a specific answer. Ideally, it will branch out and others will post discussion-oriented threads. Part of this stems from a question of "What is good VHDL/Verilog?"

In this case, it is more for interesting design methods. Times where a simple assumption/concept can be rigorously used to generate a good design.

For me the "big three" are pipelining, block-processing, and channelizing. Pipelining being the realization that an operation can be completed as a series of independent steps and that throughput can be increased at the cost of latency. Block processing is related as is the idea that some operation occur once per "block" of input while others occur once per input. This allows per-block operations to use smaller circuits even when the logic is more complex. Channelizing is the idea that, when feedback is needed, and a pipeline has N stages, N (or more) independent data streams can time share the pipelined logic without modification -- data hazards can't exist because data for the same channel only comes in a 1:N samples at most.

But there are surely several other simple ideas out there. Times when you've had a realization about how a design works and then applied the logic to other problems.

 

[vGoodtimes]

[Moved]What are Design Anti-Patterns

This thread is intended as a discussion, not as a specific question with a specific answer. Ideally, it will branch out and others will post discussion-oriented threads. Part of this stems from a question of "What is good VHDL/Verilog?"

In this case, I'm looking to generate some interest in "anti-patterns". Common mistakes in design that people make all the time but don't even realize.

For me, the "big-three" are over-pipelining, sample-v-cycle, and ad-hoc interfaces.

Over-pipelining is the mistake that adding more stages to a pipeline will never have logical problems. It is the addition of pipeline stages based on non-performance concerns (eg, line-length limits in a coding standard) and done without examining possible corner cases.

Sample-v-Cycle is the related issue where a valid input cycle is treated the same as a any cycle because the original design mostly has consecutive valid samples. Such code is hard to reuse if the input cadence is different.

ad-hoc interfaces really annoy me. I've had developers who had excessively detailed per-module designs -- without any description of the interfaces between them. When I see a design, my first questions are "what do the modules do" and "how do they interact". ad-hoc interfaces often ignore the second aspect entirely.


I'm looking for more examples of failed designs that you've seen where there was a key misunderstanding/misuse of some design principle.

 

[ads-ee]

Re: [Moved]What are Design Anti-Patterns

Over-pipelining is the mistake that adding more stages to a pipeline will never have logical problems. It is the addition of pipeline stages based on non-performance concerns (eg, line-length limits in a coding standard) and done without examining possible corner cases.

Honestly I don't think this anti-pattern exists. From what I've experienced it is a problem with how some engineers implement their pipelined designs. They use an ad-hoc approach to pipelining...i.e. oh, this signal is transitioning in the wrong spot, I need to add a pipeline delay...
That will almost guarantee corner cases and problems with adding pipeline stages. I don't design pipelines that way I design them before I code and break the problem down in a document with drawings first, then the implementation can be easily done by me or a trained code monkey. Adding pipeline stages never have any repercussions unless the design can't tolerate added latency.

Sample-v-Cycle is the related issue where a valid input cycle is treated the same as a any cycle because the original design mostly has consecutive valid samples. Such code is hard to reuse if the input cadence is different.

Is this really a design anti-pattern or just plan poorly though out code, or code designed for a specific purpose and not to be reused in a different design.

ad-hoc interfaces really annoy me. I've had developers who had excessively detailed per-module designs -- without any description of the interfaces between them. When I see a design, my first questions are "what do the modules do" and "how do they interact". ad-hoc interfaces often ignore the second aspect entirely.

Come on this isn't a design pattern it is a problem with a broken process that lacks accountability and reviews.

One area that seems to have design patterns that are usable across many applications is in the area of CDC and how you manage it with single signals, multi-bit signals, burst data, random arrival data (with a given aggregate rate). This type of code lends itself to building reusable modules (after you've done the initial analysis work). Personally I've seen numerous versions of each of these types of CDC blocks implemented in various different ways and many designs where the engineer use an ad-hoc approach that was different every time.

 

[jt_eaton]

Rather than limit this to FPGA design let's talk about design for reuse in general.

1) A Priori vs A Posteriori. Some problems are so old that they have latin names. A Priori means that you have complete knowledge and understanding of an issue up front and A Posteriori means that you don't. There are pieces of the puzzle that are missing and you will not know what they are until sometime in the future.

We see to many cases of designers coming up with a Priori solutions to A Posteriori problems. They work great when released but it is a question of when rather than if they will fail.

2) Never copy data in a database. Everything is assigned to a single location and anyone who needs it gets it from that location. We break this rule all the time with IP that sometimes goes viral with devastating results.

3) Build your designs using high volume manufacturing techniques. Our designs are too big to hand craft all of the rtl code. Automate!

John Eaton

 

[vGoodtimes]

Re: [Moved]What are Design Anti-Patterns

Honestly I don't think this anti-pattern exists. From what I've experienced it is a problem with how some engineers implement their pipelined designs. They use an ad-hoc approach to pipelining...i.e. oh, this signal is transitioning in the wrong spot, I need to add a pipeline delay...

Sure, and this is why I call it an anti-pattern. The practice of adding pipeline stages is very common. It is easily justified as a method to improve performance. Register balancing and retiming even make non-performance related pipeline stages ok. But the time it takes to decide to add a pipeline stage is often much less than the time required to find corner cases and data hazards. I call it an anti-pattern mainly because the developer knows they are adding pipeline stages due to non-performance reasons -- things like line length limits. This makes me suspicious if they actually thought about the pipeline.

Is this really a design anti-pattern or just plan poorly though out code

Probably just poorly thought out code. There are a few design pardigms for designs where data can be marked valid AND has is pipelined for performance. Not realizing the difference between sample/cycle delay can make it through simulation.

Come on this isn't a design pattern it is a problem with a broken process that lacks accountability and reviews.

Maybe, it is more the opposite of a design pattern where all modules have consistent interfaces or a few consistent interfaces.

I've seen numerous versions of each of these types of CDC blocks implemented in various different ways and many designs where the engineer use an ad-hoc approach that was different every time.

The best is when there are two CDC methods and the developer made assumptions about the latency of one based on the other. eg, that one fifo being non-empty implies the other is non-empty because the latter was always written to first.