My own custom verilog component complaining about too many pterms.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
SaWa_284216
Level 4
Level 4

 I am making a simple state machine for an alarm system using the PSoC 4 Pioneer.

   

However the build is failing saying I have used too many unique pterms. I have no idea what these are?

   

Bundle is attached

   

 

   

*********************************************************************************************************************************************

   

Resource Type                 : Used : Free :  Max :  % Used

   

============================================================

   

Digital clock dividers        :    2 :    2 :    4 :  50.00%

   

Pins                          :   15 :   21 :   36 :  41.67%

   

UDB Macrocells                :   19 :   13 :   32 :  59.38%

   

UDB Unique Pterms             :   67 :   -3 :   64 : 104.69%

   

Error: mpr.M0014: Resource limit: Maximum number of UDB Unique Pterms exceeded (max=64, needed=67). (App=cydsfit)

   

UDB Total Pterms              :   72 :      :      : 

   

UDB Datapath Cells            :    0 :    4 :    4 :   0.00%

   

UDB Status Cells              :    0 :    4 :    4 :   0.00%

   

UDB Control Cells             :    0 :    4 :    4 :   0.00%

   

Interrupts                    :    0 :   32 :   32 :   0.00%

   

Comparator/Opamp Fixed Blocks :    0 :    2 :    2 :   0.00%

   

SAR Fixed Blocks              :    0 :    1 :    1 :   0.00%

   

CSD Fixed Blocks              :    0 :    1 :    1 :   0.00%

   

8-bit CapSense IDACs          :    0 :    1 :    1 :   0.00%

   

7-bit CapSense IDACs          :    0 :    1 :    1 :   0.00%

   

Temperature Sensor            :    0 :    1 :    1 :   0.00%

   

Low Power Comparator          :    0 :    2 :    2 :   0.00%

   

TCPWM Blocks                  :    0 :    4 :    4 :   0.00%

   

Serial Communication Blocks   :    0 :    2 :    2 :   0.00%

   

Segment LCD Blocks            :    0 :    1 :    1 :   0.00%

0 Likes
12 Replies
ViDv_264506
Level 5
Level 5
50 sign-ins 25 sign-ins 5 solutions authored

Hi, samwalsh01

   

your Verilog is clean, but the functionality of the state machine is too large to fitt into PSoC4 42xx. 

   

a. use PSoC5LP or wait some time for new PSoC4 devices with more UDB's

   

b. reduce functionality

   

Regards,

   

Viktor

0 Likes
SaWa_284216
Level 4
Level 4

 Well that upsets me a lot..

   

Do you know what is taking up the "pterms" I could try and trim it down if i knew where to look.., I have to use this chip its all been built. I never thought such a small state machine would take over the 4 full UDB's

0 Likes
ViDv_264506
Level 5
Level 5
50 sign-ins 25 sign-ins 5 solutions authored

 Hi,

   

search cypress.com with Verilog keyword. Thera are nice Application notes and Verilog demos. Think, UDB is not the same as pterms where warp fits the code ....

   

Viktor

0 Likes
ViDv_264506
Level 5
Level 5
50 sign-ins 25 sign-ins 5 solutions authored

 Hi, 

   

you can find nice startpoint here http://www.cypress.com/?rID=40410

   

Viktor

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

PTerms are programmable logic that can be compared to the formerly used "PALs", look here: en.wikipedia.org/wiki/Programmable_Array_Logic

   

Within an UDB is a number of such programmable logic lines which are used to build the logic to generate the compares to decide which state you are in and which state will be next.

   

Since the count of these logic lines is restricted you can easily run out of this resource, particularly when using a PSoC4 which has got only 4 UDBs compared to 24 of a PSoC5.

   

A chance to reduce the number of used pterms could be done by

   

Replacing components that are UDB-based with fixed-function components

   

Reducing used gates in the schematic

   

Reducing the number of states of your state-machine

   

 

   

Bob

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I just ran a test: It looks like when using an LUT-component that does not increase the number of used Pterms, so you could put part of your state-machine into an LUT. At least it is worth a try.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Why not sue the DFB Assembler to build the state machine ?

   

 

   

    

   

          http://www.cypress.com/?rID=60720

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Oops, not paying attention, no DFB in PSOC 4. Ignore my post.

   

 

   

Regards, Dana.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

I would guess its due to having too much state. Each bit of state that needs to be stored blocks one macro cell (utilizing the DFF in there). So try to reduce that. (and even if the DFFs itself are fine, since they are spread over multiple macrocells, connecting them needs PTERMs)

0 Likes
Anonymous
Not applicable

Hi Sam,

   

I recommend examining the "macrocell listing" portion of your rpt file to determine what's taking up all your pterms. I scanned through it quickly and it seems that many of the pterms are being consumed by your password functionality. For example, this equation (generated from the synthesis of your verilog) uses 8 pterms:

   

 MacroCell: Name=\AlarmSystem:MODULE_1:g1:a0:xeq_split\, Mode=(Combinatorial)
        Total # of inputs        : 10
        Total # of product terms : 8
            Clock Enable: True
        Main Equation            : 8 pterms
        (
              \AlarmSystem:currentPassword_4\ * !Net_260_4
            + \AlarmSystem:currentPassword_3\ * !Net_260_3
            + !\AlarmSystem:currentPassword_2\ * Net_260_2
            + \AlarmSystem:currentPassword_2\ * !Net_260_2
            + !\AlarmSystem:currentPassword_1\ * Net_260_1
            + \AlarmSystem:currentPassword_1\ * !Net_260_1
            + !\AlarmSystem:currentPassword_0\ * Net_260_0
            + \AlarmSystem:currentPassword_0\ * !Net_260_0
        );
        Output = \AlarmSystem:MODULE_1:g1:a0:xeq_split\ (fanout=1)

   

The product terms are the inputs to the equation (combined by logical OR '+'). I see a few other big product term equations also involving your password functionality. I also see in your verilog where you are making several equality compares involving the password. Try reducing the password length by a bit or two, and I'll bet you'll be able to fit.

   

It might be possible to implement your password function in the datapath block, potentially saving a bunch of pterms and some macrocells. Equality and greater than / less than comparisons are things that the datapath block does well. A UDB editor was added to PSoC Creator in v3.0 to make datapath development easier. Go to this link and scroll down to find "Using the UDB Editor" to watch a 6-part tutorial video: http://www.cypress.com/?rID=40547

   

 

   

Regards,

   

Kris

0 Likes
SaWa_284216
Level 4
Level 4

 Thanks guys that's such a big help. To be honest this project is for University and was meant to be built on an Altera board, the code has to be constructed that way as its been specified to be fully verilog.

   

I wanted to try and use the PSoCs instead of the altera silicon but I just didn't anticipate how little digital fabric the PSoC 4 has..

   

I think I am going to have to complete it on the Altera board and just remember I will have to use LUTs and Datapaths the next time i want to use this chip..

   


Thanks again!

0 Likes
Anonymous
Not applicable

to learn a bit more about the fabric you can review section 16 in Psoc4 TRM http://www.cypress.com/?docID=48637

0 Likes