Guidelines and tips for large / complex designs

Hi.

I am asking for a few tips and tricks on how to approach a more complex design with many signals and processes.
I am new to VHDL (and FPGA)

As a C/java programmer I would start from top, write some functions,test, write some more function etc.
As I understand, this is not the way to approach VHDL programming.


I found that it is very easy to make mistakes that is very hard to find and solve ...

Please share some of your techniques ...

Thanks

metcal said:

As a C/java programmer I would start from top, write some functions,test, write some more function etc.
As I understand, this is not the way to approach VHDL programming.

Click to expand...

First understand you are not writing programs (I know some consider VHDL to be a programming language, I don't. Try writing a web browser in VHDL then tell me it's a programming language when you get it working!). What you are doing is describing hardware, so unless you know how to do digital hardware design, trying to jump in and write VHDL programs having only a software background is likely going to be a painful experience.

I came from a schematic board design background (EE) and picked up both VHDL and Verilog and wrote descriptions of my register transfer level schematic designs, i.e. I stared writing VHDL after I drew a schematic of my circuit.

Similarly to software engineers I just break the design into sub-modules and write the sub-modules, sometimes those sub-modules are so big they have sub-modules as well, I also make sure anything that can be remotely resued somewhere else on some other project gets written in a parameterizable way so I can modify it by changing the instantiated module.

In my experience, many company use below approach to design hardware by Verilog/VHDL:

1/ Understand the requirement or the function of design.
2/ Describe the design in schematic or block diagram. It is not mandatory but it is better to make it closed to gate level ( AND, OR, NOT.. FF, RAM .) with connection.
3/ Write the RTL code base on that description of step 2.
4/ Build the test pattern and testcase from each function that you have from step 1.
5/ Run simulation
6/ Synthesis
7/ PnR ( place & route, STA, Power .... in case of FPGA it is Implemetation steps)

My tips:
1.) favor predictable, well-defined interfaces between modules over ad-hoc "optimized" interfaces.
Reason: It is much easier to understand the design when each module can be tested independently. When the interfaces are not well defined, it becomes harder to test them correctly. ad-hoc interfaces also lead to designs where a key interface requirement is not met because neither side handles it.

2.) favor keeping pipeline-matching logic within a module. There is a common design pattern where one signal is processed for two cycles within module A, and a process is placed in another file to delay another signal by two cycles. There are some exceptions to this rule, but they are rare. The main intent is to make the design a simple line as much as possible vs a mesh.

3.) always be mindful of cycle-delay vs sample-delay, as well as adding either by accident. Pipelines often incorporate a mixture of the two, and it is easy to mess up. It is sometimes tempting to just add an additional assignment within a process, but this can add additional registers.

4.) sandbox! Test out small bits of common logic or any constructs you don't normally use in a small design to see how it works. Too many "experts" may design based on designs they did five-ten years ago. For new designs, this can mean pre-optimizing and making the design overly complex for performance issues that don't exist. The same goes for needlessly avoiding language features that could simplify a design.


IMO, sandboxing is more important than drawing a low-level schematic. FPGAs are constructed from LUTs with some other logic elements. As a result, your idea of how things are implemented won't match the actual reality. This can lead to the feeling that you need to pre-optimize everything. By looking at a handful of small designs on your actual FPGA, you can better determine what logic has performance issues and what just seems like it would.

slutarius said:

In my experience, many company use below approach to design hardware by Verilog/VHDL:

1/ Understand the requirement or the function of design.
2/ Describe the design in schematic or block diagram. It is not mandatory but it is better to make it closed to gate level ( AND, OR, NOT.. FF, RAM .) with connection.
3/ Write the RTL code base on that description of step 2.
4/ Build the test pattern and testcase from each function that you have from step 1.
5/ Run simulation
6/ Synthesis
7/ PnR ( place & route, STA, Power .... in case of FPGA it is Implemetation steps)

Click to expand...

I would suggest doing step 4 before writing any RTL, or at least someone else doing it in parrellel (and document it.)
The problem with writing test cases after the RTL is it can be too easy to design for success rather than design for failure. Writing a small set of test vectors to ensure it works will often miss important corner cases you probably didnt think of.
If you are just a single designer, then think about constrained random verficication - ie. dont draw specific test cases - drive the input as randomly as possibly (constrained so that illegal input combinations are ignored).

TrickyDicky said:

I would suggest doing step 4 before writing any RTL, or at least someone else doing it in parrellel (and document it.)
The problem with writing test cases after the RTL is it can be too easy to design for success rather than design for failure. Writing a small set of test vectors to ensure it works will often miss important corner cases you probably didnt think of.
If you are just a single designer, then think about constrained random verficication - ie. dont draw specific test cases - drive the input as randomly as possibly (constrained so that illegal input combinations are ignored).

Click to expand...

You are right!
In real projects, we can do it right after we get the detailed specifcation for a design.
Or say, step 4 can be processed once you get the step 1 done.

Thanks all for sharing your expertise ...

I have a pretty complex project going on ... We started with an ARM but it is just not fast enough.
So I am doing some kind of a PoC.
Looked very easy at start but the as the signals, processes increases together with different timing settings I found it very hard to grab the whole picture ...

If you are new to VHDL - I highly recommend you stay well away from the architecture.
Get someone in with experience with this level of design - doing it with no experience of design is going to lead to a messy, poor design at best - at worst you'll have nothing usable.

At least you need to know something below well in term of hardware description language.
Assignment, flipflop, latch, module, instance, testbench, clock, input, output, memory, and or not xor ..gate, IO,
waveform, bus, simulation, ....

Before you enter the design work, make sure that you can draw the waveform from some circuit at gate level,
as well as you can draw the logic gate circuit if you have a waveform.

My point was that there is a point at which you believe you know more than you actually do. For example, if you start with only the basics and do small designs you will see how they fit into an FPGA. If you go very in-depth with traditional gate-level design you can make bad decisions for an FPGA platform.

This becomes more true as you work with different technologies and different performance/area/power constraints. As an example, five years ago I worked on a design that had a simple control loop. I had tuned it a bit earlier in the week and just got curious what a PI control would do. So I did some simulations for fun at home. I decided to do a build of what I considered a simulation design. This was something like a*x + b*y (with appropriate shifting) where all were 32b values. Keep in mind that the same file had a custom designed 32b accumulator. The much higher complexity mma had no problem meeting timing. (I didn't use it in the end -- it would have taken more time to document and discuss than could be justified.)