Effect of ports number to a circuit

[freelsn]

Hi, guys,

I have a circuit written separately in datapath and FSM. Say, the circuit has 4 inputs and 4 outputs.

If i change it to 3 inputs and 4 inputs, and I don't touch the datapath file which means the micro-architecture of the circuit doesn't change.
So it means "i have to change FSM" or "the tool should change FSM automatically" to meet the I/O scheduling.
So the area of FSM will increase in theory.
So the total area of the circuit with "3 inputs and 4 outputs" should be larger than that of "4 inputs and 4 outputs".
That is also what i got in simulation.

Now, if i change it to "4 inputs and 3 outputs", the area should also be larger than that of "4 inputs and 4 outputs".
However, i got the opposite result, the area of "4 inputs and 3 outputs" is smaller than that of "4 inputs and 4 outputs".
When i further reduce the number of outputs to 2 and 1. The area is even smaller.

So why is that happening, does anyone have any idea about this?

Thanks in advance.

 

[TrickyDicky]

The area it dictated purely by function.
If the 4/4 design requires all 4 inputs or outputs, then removing one will reduce some of the function and therefore area. The tool will not change the function of the circuit, unless the code is designed that way.

So I dont really understand your question.

 

[freelsn]

What do you mean by "reduce some of the function"?
The function of the circuit doesn't change all the way.
The total area consists of MUX, REG, function units.
I mean I have 4 ports for 4 outputs before, but now I only have 3 ports for 4 outputs, so 2 outputs will share a same ports. So it may need more MUXs or /and REGs, but the number of function units will not change.
So the total area should increase when reducing available ports.

 

[TrickyDicky]

Your question is meaningless.
Resource usage depends on the function, not the number of IO ports.
If you're now trying to put the same data that came in from 2 ports onto one port, the function now has to change - hence the resource usage changes. you cannot know the resource usage without knowing the function.

 

[freelsn]

The function doesn't have to change. The circuit only has to wait for an extra clock cycle to get all the data. After getting all the data, the circuit can run normally.

 

[K-J]

The function doesn't have to change. The circuit only has to wait for an extra clock cycle to get all the data. After getting all the data, the circuit can run normally.

That would be a change.

 

[freelsn]

That would be a change.

What kind of change? And why?

 

[K-J]

What kind of change? And why?

You said "has to wait for an extra clock cycle to get all the data" which implies that the latency through the design is different. Latency through a device is part of function.

Kevin

 

[freelsn]

You said "has to wait for an extra clock cycle to get all the data" which implies that the latency through the design is different. Latency through a device is part of function.

Kevin

Yes, latency is different.
But I want to know how area changes.

 

[TrickyDicky]

Yes, latency is different.
But I want to know how area changes.

It depends on how the function changed. This question can only be answered with a specific function that has a specific change. There is no general rule.

 

[ads-ee]

Yes, latency is different.
But I want to know how area changes.

Why don't you just synthesize various circuits in Altera/Xilinx web versions and generate the technology specific schematic and look at how the synthesis tool decides what underlying logic exists in the different designs. It would be easier to do this and will also improve your understanding of how synthesizable code is translated to FF, muxes, decoders, etc.

Asking questions on a forum and then disregarding the answers is unproductive for all involved.

 

[freelsn]

Why don't you just synthesize various circuits in Altera/Xilinx web versions and generate the technology specific schematic and look at how the synthesis tool decides what underlying logic exists in the different designs. It would be easier to do this and will also improve your understanding of how synthesizable code is translated to FF, muxes, decoders, etc.

Asking questions on a forum and then disregarding the answers is unproductive for all involved.

First, if I did something wrong, I will apologise.

I am doing high level synthesis. In most cases, I have bigger area as I reducing number of available ports. But there are cases have the opposite results. And I cannot find out the reason from the reports. So I just try to ask if someone knows what the effect may be if I change the number of available ports. Afterwards, I will find it in the report based on the answers.

 

[ads-ee]

I am doing high level synthesis. In most cases, I have bigger area as I reducing number of available ports. But there are cases have the opposite results. And I cannot find out the reason from the reports. So I just try to ask if someone knows what the effect may be if I change the number of available ports. Afterwards, I will find it in the report based on the answers.

Now it's more understandable, why you can't understand what has been told to you.

High level synthesis is typically so abstracted from hardware that the results will typically be hard to correlate with the original code. A small one line change in a C based flow is like the proverbial butterfly flapping it's wings causing a huge storm on the opposite side of the world.

The problem stems from not understanding the implementation details of any given circuit to get the output vs. input results you've defined. That is where running synthesis on a design and looking at the resulting circuit will help. You should be able to run high level synthesis and open the resulting netlist in the technology (schematic view). It will likely take some effort to understand the logic from the unintelligible (more than likely) names.

 

[freelsn]

Now it's more understandable, why you can't understand what has been told to you.

High level synthesis is typically so abstracted from hardware that the results will typically be hard to correlate with the original code. A small one line change in a C based flow is like the proverbial butterfly flapping it's wings causing a huge storm on the opposite side of the world.

The problem stems from not understanding the implementation details of any given circuit to get the output vs. input results you've defined. That is where running synthesis on a design and looking at the resulting circuit will help. You should be able to run high level synthesis and open the resulting netlist in the technology (schematic view). It will likely take some effort to understand the logic from the unintelligible (more than likely) names.

OK, thanks. I will do that.