cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC Creator & Designer Software

Skoe
New Contributor II

In a design with combinatorial logic on an PSoc 4 device I run into a placement problem which boils down to the following issue:

An combinatorial enable signal, which is used in several places, like here, p7:

assign enable = x && !y && z;
assign p7 = enable && a && !b && !c

 

is inserted into another term during synthesis and optimization:

Note: Expanding virtual equation for '\FOO_1:enable\' (cost = 2):
\FOO_1:enable\ <= ((not Net_48 and Net_49 and Net_47));

Note: Expanding virtual equation for '\FOO_1:p7\' (cost = 60):
\FOO_1:p7\ <= ((not Net_48 and not Net_38 and not Net_37 and Net_49 and Net_47 and Net_31));

The the digital placement fails with:

W2555: UDB : UDB_0 (PLD : 1) contains 14 data inputs. Maximum allowed 12.

I know that it would fit if the enable signal would go to another PLD and p7 would use enable instead of (not Net_48 and Net_49 and Net_47).

I tried to play with opt_level and placement_force, but these don't seem to help here even though I see they are recognized in the rpt file. However the expansion during synthesis is still done.

Is there a way to avoid this? Something like optimizer settings or explicitly saying that enable must be kept and not expanded into other terms?

0 Likes
1 Solution
Skoe
New Contributor II

Thanks for the heads up! Indeed, I remember that I read that the UDBs are not active in deep sleep and wanted to check if this is only valid for clocked logic, but that's not the case.

Fortunately with juggling with placement_force I could make it fit. So I can leave the core running at 3 MHz and get it for 1 mA, which is sufficient for my application.

PSoc is really a great and flexible platform, I'm happy to work with it and to get to know it better!

View solution in original post

4 Replies
RodolfoGL
Employee

You can pipeline the enable signal by making it a register.

always @(posedge clock)

begin

    enable <= x && !y && z;

end

Skoe
New Contributor II

Thank you for the hint. Indeed, with this, one can prevent the optimizer from including it into the term. Then the logic fits easily into the PLDs. A similar trick I used before was to route enable over an output/input pin. Feels a bit strange that it can solve it when it actually does more than I need. 😁 Still, both are just some hacks to work around the problem:

With the pipelining I must leave the clock running at full speed with high power consumption to get some cheap combinatorial output and still get additional delay of one level of logic plus 1/48 MHz ~ 20 ns (from a different clock domain even).  With the additional pin I get one level of logic plus pin delay and I need a free pin. But all I want is one level of logic - these few ns are totally acceptable.

So I would still be very happy if we could find one of these solutions:

  • tell the synthesizer/optimizer not to insert certain terms but to keep them separate, maybe with an attribute,
  • tell the optimizer to weight low input count over fast propagation delays,
  • connect these signals to something which forbids the optimizer to do that - like making a detour over a pin, but without wasting a physical pin

Any ideas?

A last resort would be to use the clocked logic and patch the generated bitstream to set the BYP bit (see Figure 16-4. PLD Macrocell Architecture in PSoC 4100M/4200M Family PSoC 4 Architecture TRM).  But this should be what the tools do, not me 😏

 

0 Likes
RodolfoGL
Employee

Note that the UDBs don't run in deep sleep, which means you need to have the high frequency clocks running anyway. You will not see much power savings between pure combinational logic and pipelining it with PSoC UDB architecture.

Skoe
New Contributor II

Thanks for the heads up! Indeed, I remember that I read that the UDBs are not active in deep sleep and wanted to check if this is only valid for clocked logic, but that's not the case.

Fortunately with juggling with placement_force I could make it fit. So I can leave the core running at 3 MHz and get it for 1 mA, which is sufficient for my application.

PSoc is really a great and flexible platform, I'm happy to work with it and to get to know it better!

View solution in original post