4 Replies Latest reply on May 25, 2018 7:51 AM by chloc_1378511

    PSoC6 UDB A0 Register write

      Hi,

      I've been having some trouble with a UDB design which I have just tracked down to an accumulator register write which is failing sometimes.

       

      The design uses 8 UDB's, but the datapath in question is a simple 8bit stand alone function (not concatenated).

       

      Both cores run at 98MHz, and clk_peri = 98MHz, The bus clock to the UDB's is clk_peri/2 (49MHz) and the datapaths are running at clk_peri/8 (circa 12.5MHz).

      I'm writing and reading A0 using CY_SET_REG8() and CY_GET_REG8(), but am finding that writes appear to be failing a bit less than 50% of the time. The writes are coming from CoreM0.

       

      Is there a need to synchronise writes to the accumulator registers? Any other reason why writes periodically fail?

       

      Timing in the design is reported as being met.

       

      Thanks in advance for any pointers.

      Charles

        • 1. Re: PSoC6 UDB A0 Register write
          WaMa_286156

          I have seen things like this before, in the PSOC 5.

           

          Basically, there is probably a timing skew on your clock edge.  Try to synchronize the clock into the UDB with to the master clock using a sync component.

           

          However, that does not always work.  What I had to do in my PSOC5 design was start over, and drag each component into the system one at a time, and work with that component to verify, to see where things went wrong.

           

          During the process, I found out that the order of events of placing things onto the design sheet will change the routing.

           

          By placing my troublesome components onto the design sheet either first, or last, I would change the timing characteristics.  I was able to get some counters that occasionally missed a capture pulse to always see the capture pulse.  It was wide enough, based on the documentation, but skew caused a problem.  By re-creating the project a unit at a time, on the third try I got everything to line up properly, and it always compiled and work. The picker will pick which UDB to use based on what is available at the time of UDB demand (i.e. First Demanded, First Given), and that changes route on a predictable basis.  Sometimes using UDB for a do-nothing will push you into another unit and your problems disappear, or get worse.

           

          Note that unlike a Xilinx or Altera, there are extremely limited routings here, and the route you end up with is almost always predictive, and is also highly dependent upon previous components placed into the fabric as the signal route for your troublesome component is put into play.

           

          One of the clues was when I brought signals out to pins.  That changed the timing enough to cause some things to start working, above and beyond the additional capacitance, etc. of the new route to the pin driver.

          1 of 1 people found this helpful
          • 2. Re: PSoC6 UDB A0 Register write
            RodolfoG_11

            Another thing to look at is if your datapath is performing any operation on the A0.

            1 of 1 people found this helpful
            • 3. Re: PSoC6 UDB A0 Register write
              GyanC_36

              Hello,

               

                Probably the UDB Datapath is also writing the ALU/Shift/Mask operation's output result back to the Accumulator Register (A0) and CPU is reading that value.  Isolate the A0 register from being written by other source and try.

               

              -Gyan

              1 of 1 people found this helpful
              • 4. Re: PSoC6 UDB A0 Register write

                Thanks everyone for taking the time to answer.

                 

                rlos and Gyan are on the money. I found late last night that the counter datapath was loading the ALU into A0 during the idle state, which was obviously sometimes conflicting with the incoming write from the core. I checked for this initially, but had a different datapath selected in the datapath configuration tool (I'm using 8 datapaths), so thought it was safe.

                 

                Thanks also to user_463759797. Some useful experience there, and another tack to try when I hit my next problem.

                 

                Kind regards

                Charles