cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 6

Anonymous
Not applicable

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

0 Likes
1 Solution
GyanC_36
Employee

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

View solution in original post

4 Replies
WaMa_286156
Contributor II

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.

RodolfoGL
Employee

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

GyanC_36
Employee

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

View solution in original post

Anonymous
Not applicable

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

Top labels