cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 5, 3 & 1

Anonymous
Not applicable

I know I'm trying to pack 10lbs in a 5lb bag...

   

I have a delsig/sar/my own verilog code/several timers/ an I2C master in UDB/ an i2c slave in FF/ and a bunch of other random bits and pieces.

   

I am nearly finished adding all the features to the project but just as I'm adding the last few equations to the verilog code, I've come up against:

   

E2071: The design requires 26 UDB(s) but the device has 24. See the report file for details.

   

------------------------------------------------------------
Technology mapping summary
------------------------------------------------------------

Resource Type                 : Used : Free :  Max :  % Used
============================================================
Digital clock dividers        :    4 :    4 :    8 :  50.00%
Analog clock dividers         :    2 :    2 :    4 :  50.00%
Pins                          :   46 :   26 :   72 :  63.89%
UDB Macrocells                :  155 :   37 :  192 :  80.73%
UDB Unique Pterms             :  334 :   50 :  384 :  86.98%
UDB Total Pterms              :  352 :      :      :
UDB Datapath Cells            :   15 :    9 :   24 :  62.50%
UDB Status Cells              :   12 :   12 :   24 :  50.00%
             Status Registers :    3
            StatusI Registers :    9
UDB Control Cells             :    5 :   19 :   24 :  20.83%
            Control Registers :    4
                 Count7 Cells :    1
DMA Channels                  :    0 :   24 :   24 :   0.00%
Interrupts                    :    4 :   28 :   32 :  12.50%
DSM Fixed Blocks              :    1 :    0 :    1 : 100.00%
VIDAC Fixed Blocks            :    0 :    4 :    4 :   0.00%
SC Fixed Blocks               :    0 :    4 :    4 :   0.00%
Comparator Fixed Blocks       :    0 :    4 :    4 :   0.00%
Opamp Fixed Blocks            :    0 :    4 :    4 :   0.00%
CapSense Buffers              :    0 :    2 :    2 :   0.00%
CAN Fixed Blocks              :    0 :    1 :    1 :   0.00%
Decimator Fixed Blocks        :    1 :    0 :    1 : 100.00%
I2C Fixed Blocks              :    1 :    0 :    1 : 100.00%
Timer Fixed Blocks            :    0 :    4 :    4 :   0.00%
DFB Fixed Blocks              :    0 :    1 :    1 :   0.00%
USB Fixed Blocks              :    0 :    1 :    1 :   0.00%
LCD Fixed Blocks              :    0 :    1 :    1 :   0.00%
EMIF Fixed Blocks             :    0 :    1 :    1 :   0.00%
LPF Fixed Blocks              :    0 :    2 :    2 :   0.00%
SAR Fixed Blocks              :    1 :    1 :    2 :  50.00%

   

 

   

The Technology Mapping section - Design Equations has lots of details in it:

   

MacroCell: Name=Net_1267, Mode=(Combinatorial)
        Total # of inputs        : 4
        Total # of product terms : 2
            Clock Enable: True
        Main Equation            : 2 pterms
        (
              Net_1740_5 * \I2CEngine:go_run\ * !\I2CEngine:bit_phase_q_1\ *
              debug_1
            + Net_1740_5 * \I2CEngine:go_run\ * \I2CEngine:bit_phase_q_1\ *
              !debug_1
        );
        Output = Net_1267 (fanout=1)

   

But how can I figure out who is really sucking up all the resources?

   

If each block in the schematic had a corresponding MC count or something that would clue me in. I tried commenting out a few things in the verilog file which made some logic go away but I get very inconsistent results. If I add 1 OR in 1 equation I go from fitting to missing by 2 UDBs, then add another equation and then it fits again???

   

 

   

There are various features I can probably live without but it I'm not sure which one will give me back the most UDBs. I also know that routing is often the real issue and I'm not really out of UDBs but interconnect wires. Is there a report for that somewhere?

   

 

   

I have learned a few things along the way:

   

in Verilog code:

   

1) NEVER build arithmetic devices in verilog. Use a schematic. Verilog turns into AND/OR terms and quickly explodes UDB count. In schematics, they use data-path cells which there are plenty of. So counters, adders and anything arithmetic do them via schematic. Verilog code should be just control.

   

 

   

Well maybe I only learned 1 thing so far... Can't think of anything else right now - I should have written more down as I was going...

0 Likes
8 Replies
ETRO_SSN583
Esteemed Contributor

Each component has a datasheet, and in that datasheet is a table of resources used.

   

Includes FLASH and SRAM usage also.

   

 

   

Right click the component (it should be unselected) to get to the datasheet. For example the

   

SR component shgown below.

   

 

   

Regards, Dana.

   

 

   

0 Likes
Anonymous
Not applicable

 You have free hardware timer blocks. See if you can change your UDB timer to fixed one. They are not exactly the same, but worth trying the change.

0 Likes
ETRO_SSN583
Esteemed Contributor

Also consider muxing (if applicable) a block that is otherwise replicated,

   

eg, make blocks multi functional.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

If you only use TX or RX of a UART, you can select that and save some blocks as well. You can also try the new software UART.

0 Likes
Anonymous
Not applicable

Well I squeezed my design down enough to fit by removing one of the I2C bus masters and instead doing the I2C function in software with GPIOs. A little more firmware (and FLASH of which I have plenty to spare) and this particular I2C bus is not speed critical. So that solved my immediate problem.

   

 

   

But it still doesn't get back to my original problem - how do you identify the piece of logic that is burning up all the UDBs?

   

 

   

You can go thru the data sheets one at a time, create a spreadsheet, then sort that. But that's a lot of tedious work. And it doesn't help when I've got a few chunks of verilog code which don't have a nice datasheet.

   

 

   

I was hoping there was a summary report somewhere that said:

   

 

   

I2C - 3 UDBs - 12%

   

UART - 4 UDBs - 16%

   

Verilog1 - 8 UDBs - 33%

   

Verilog2 - 1 UDB - 4%

   

routing - 3 UDBs - 12%

   

...

   

 

   

I'm not sure this is exactly possible as some macros (especially the Verilog) may share UDBs. But something that would at least give me an idea of which block was burning up all the UDBs would give me a clue would be a big help. In the example above I would know that verilog1 was using up all the UDBs vs verilog2 so I would look at that code and see if there was something that was obviously wasting UDBs (like arithmetic that is better done with datapath).

   

 

   

My original design implmented several counters in verilog code. I quickly ran out of UDBs. That's when I figured out to draw arithemtic operations in schematics is WAY more efficient than verilog.

0 Likes
ETRO_SSN583
Esteemed Contributor

Consider posting a CASE with the archived project to get this answer -

   

 

   

    

   

          

   

To file a tech case -

   

 

   

www.cypress.com

   

“Support”

   

“Technical Support”

   

“Create a MyCase”

   

 

   

You have to be registered on cypress.com to do this.

   

 

   

Regards, Dana

0 Likes
HeLi_263931
Honored Contributor II

There is no such direct list. But the *.rpt file created during compile has some answers which might help you.

   

 

   

Look for these sections:

   
        
  • Technology mapping summary
    this is an overview how much of each resource is used
     
  •     
  • Macrocell listing / Status register listing / Sync listing / Control register listing
    these listings show which resource is connected where (net names) and for which component
  •     
  • Component Placement Details
    this shows which UDBs are used for which component, and what the macro cells in there are used for
  •    
   

 

   

The problem is that sometimes resources are needed indirectly because of wiring, or because of placement restrictions (just to connect some components). But these informations at least can show you where all the UDBs/MCs are going...
 

0 Likes
ETRO_SSN583
Esteemed Contributor

He has already looked at that report per his original post.

   

 

   

Regards, Dana.

0 Likes