LOGIC LEVELS IN RTL DESIGN

[abhinavpr]

Hi,

i would like to know How do you define the max number of logic levels in a RTL design i.e before synthesizing how can we decide that we will code RTL in such a way that the number of logic levels does not exceed certain limit (3 or 4 or 5) .

While coding RTL we only consider the design to be functionally correct, So what should be the approach for RTL coding so that the design satisfies our logic level requirement as well.

regards,

abhinavpr

[awillen]

Is this about meeting timing requirements? If yes, don't concentrate on controlling the maximum number of logic levels (especially since routing delays are often higher than logic delays), let the tools do it.

[abhinavpr]

Hi,

thanks for the response. But would RTL code for a design which should work at 10 Mhz and another which should operate at 250 Mhz  be written in same way?

i would like to know before syntheis how do we decide pipeline stages etc?

after synthesis we can see the combinational delay etc and introduce pipelining etc to satisty the timing constraints but do we have to take logic levels into consideration while writing the RTL code?. If yes then how do we decide it?.

[qureshi031]

i dont think you can know the actual combinational path delay while writing the code. but we can have an idea and sometimes we will have to check if the total combinational path doesnt exceed our requirement.

for example if i want a design to work at 100 mhz in my current FPGA i know that if i perform 3 logical operations in 1 cycle and dont exceed, my design will run at more than 100 mhz. 100 Mhz means 10ns so if sum of the combinational path of all the logical operations i perform in a cycle is under 10ns, my design will run easily on 100Mhz. so u will hv to actually knw the combinational path delay of each operation which is quiet difficult i assume and it varies with no of LUTs used which depends on no of bits on which the operation is being performed. also it varies from one fpga to another.

P.S. this is not an expert opinion, just the way i do my work not sure if there is a better way of estimating before designing

[bassman59]

---

@abhinavpr wrote:

Hi,

thanks for the response. But would RTL code for a design which should work at 10 Mhz and another which should operate at 250 Mhz  be written in same way?

i would like to know before syntheis how do we decide pipeline stages etc?

after synthesis we can see the combinational delay etc and introduce pipelining etc to satisty the timing constraints but do we have to take logic levels into consideration while writing the RTL code?. If yes then how do we decide it?.

---

You're overthinking it. Write the code in the most meaningful way possible. Don't try to outmaneuver the tools. 

Run the tools and if you meet your timing constraints, you are done.

If you don't meet the constraints, then start to optimize the failing paths.

[avrumw]

i would like to know before syntheis how do we decide pipeline stages etc?

after synthesis we can see the combinational delay etc and introduce pipelining etc to satisty the timing constraints but do we have to take logic levels into consideration while writing the RTL code?. If yes then how do we decide it?.

This is where the expertise in designing digital logic lies. It is absolutely true that you have to write your RTL differently if you are planning to run at 10MHz vs. 250MHz, you will need much more pipelining to run faster. However, how do you know how much? Unfortunately, there is no easy answer.

I don't like using the word "writing RTL code". In spite of the fact that we are using a hardware description language, we are not "writing code", but "designing hardware". Using RTL just makes us more productive in designing hardware.

So the answer is - design your hardware! Every combinatorial function you infer from RTL represents some number of gates. As you get comfortable with design, you start getting the feel for how long some operations take.

For example, you know that any function of 6 inputs is one LUT, and the speed of the LUT with associated routing is knowable based on your technology - at least after doing a couple of designs. A much wider function - say one of 20 inputs, will require more LUTs, and they will need to be cascaded - probably 2 levels of logic.

Things like adders are also knowable - when you add (or subtract, or do < or > operations) you know the carry is critical, and needs to propagate from LSB to MSB - again, taking some time to do each bit (or group of 4, really). Wider adder/subtractor/comparators take longer.

Variable tap shifters, wide MUXes, very large case statements are slower operations, and will hence take longer.

The key is always to "think hardware" - you don't have to 2nd guess exactly what the synthesis tool is going to do, but just think about the complexity of the operations you are inferring - you will start to get a feel for what can be done in a given technology at a given speed.

Avrum