Protocol Aware Debug System

[ginty]

View the RFC here - https://github.com/Origen-SDK/rfcs/blob/pa/text/0000-protocol-aware-pattern_debug.md

[pderouen]

This proposal seems like it would work well for registers of fixed (or predictable) size that are accessed through a common mechanism. We have cases (JTAG registers) where the registers vary in size from 3 bits to >700 bits and are located in varying places in a complex TAP structure (requiring any combinations of IR writes and pause DR instructions to access registers). These specifics are all handled in the read/write methods of our apps. This I think adds another level of complexity. Any thoughts on how (or if) this might be handled?

[pderouen]

...If you go straight to the TCP socket implementation, I think the JTAG register problem becomes a non-issue. But, then you need to add on ATE command set to the existing Link command set to perform the ATE operations (like read frequency counter etc)

[pderouen]

...Sorry, I wish they would move the "Close and comment" button somewhere else!

[xnappo]

Paul - your example of 'read frequency counter' is for an ATE frequency counter or on chip?

Really the RFC as written feels like it is trying to straddle the two options - I really think going either all-in with Origen driving the tester directly (TCP socket) or all in on generating a PA language for each platform that IS good for production should be the goal.

Doing something that does not allow for direct Origen debug, and does not result in something usable for production - I am not sure how much we would use that.

[pderouen]

@xnappo, the ATE command set I mention would be the way origen requests the ATE perform a non-pattern operation. So, off-chip frequency counter read. The response from the ATE TCP server would be the result which would be displayed in the origen interactive debug console... at least that was what I was picturing in my head.

[xnappo]

Okay, yes agreed. Of course as you know I make it my mission to put all such instrumentation on chip - but agree this would be needed in this scenario.

[ginty]

Doing something that does not allow for direct Origen debug, and does not result in something usable for production - I am not sure how much we would use that.

@xnappo, what's really the difference in your mind between this proposal and one in which the edits you make could remain in production?
Are you really saying that if you had true PA here, your workflow would change to making permanent edits in the live program and then never back-porting them to Origen and going through a re-generation step?

On the all-in OrigenLink-style debug, I really worry about how useful that would be in practice. I think on the tester people really want the high level debug code in combination with the ATE's debug tools. I don't think completely divorcing the code environment (i.e. making it back at your Origen workspace) from the ATE debug tools is really that attractive and probably will be quite awkward to use in practice.

[redxeth]

Could someone please briefly elaborate on the TCP socket implementation? Let's you use this protocol to talk to the tester at a lower level than a IG-XL Program ?

[redxeth]

Also having "Protocol Aware" in the RFC name threw me at first and despite this not being a native vendor PA implementation wonder if there isn't another name we could use. Or this could be an effort to 'take back' the PA name so it doesn't have to mean vendor-native implementation. Just thinking that with PA being a marketed / licensed feature on ATEs perhaps there isn't a better name we could use.

[redxeth]

@ginty another benefit of not using vendor native PA is that it frees up interface HW design so as to have more DUTs with fewer pins for example. I recall this being an issue on one of the UF HWs.

[pderouen]

@redxeth OrigenLink uses a TCP server/client to communicate vectors and dut responses back and forth between origen and your evb. The advantage of this type of implementation is that it can easily handle very complex read/write register tasks. The disadvantage is that you become separated from the ATE debug tools.

[ginty]

@redxeth, yeah we might go with "Register-Level Debug", which is really what this is. PA is a more recognized term though, so it has merit, but ultimately I don't think people really want PA anyway, they want register level debug.

[redxeth]

@pderouen Yeah I knew that for OrigenLink for EVB, but wasn't sure how it applied to talking to an ATE.

[pderouen]

It is one of the proposed options for implementation.

[redxeth]

@pderouen I get it now thanks. Trying to think how the TCP client would talk to the tester.

[redxeth]

@ginty Seems like then the implementation mentioned here is using the pattern overlay approach @jiangliu23 did as opposed to using pin states as done by @pderouen ? Or is that technical detail left to each tester support implementer? Would this be part of Origen Std Lib or Origen Testers?

[xnappo]

@ginty - no - wouldn't be that I wouldn't push back to Origen.

• Not sure I would want to debug in that environment. The addresses and data have been reverted back to hex, and I still have to get out several decoder rings to figure out the base address, offset, bit names and bit fields. Really not much better than having good comments in the pattern.

• Don't really like the idea of having to use vectors for production in general. By the time I retire, I want new engineers going to actual vectors as much as we go to ASM now :)

Honestly, it could be we want to do both things here.. OrigenLink for ATE and Register Based API for ATE.

[ginty]

@redxeth, yes my preference is to the register overlay style approach rather than a pin toggler. It will be quicker but also I really like the elegance (and ease of implementation) of having the protocol details fully encapsulated in a single read/write_reg pattern generated by Origen.
The question of how we handle different sized register transactions is something that still needs to be answered though.

[pderouen]

Not only different sizes, also different sequences based on current dut state. I'm still thinking through how to solve this.

[ginty]

@xnappo, OK got you on the proposed API being a dog, I agree.
I think that can be improved, in principle we should be able to have Origen generate some kind of local language look up table to enable named register and bit access.

Not with you on the vectors must be destroyed at all costs thing though. To me, if we have a system like this which means you can debug above the vectors, I don't see what difference it makes.
I honestly have not liked what I have seen at all from what you have to do to enable true PA, it seems like a very high price to pay here (in terms of more/harder development effort) just to say we've eliminated ATE machine code (which is what it really is rather than ASM) at the lowest level.

[ThaoHuynhFsl]

Hi @ginty and @pderouen , what i had done on the c90tfs for the different register size and sequence are in the VB, have a class definition of registers that are interested or will need for the tests.

have Origen to fill in the default value that would use in the pattern something like this

%rst_vref = $nvm.params(:default).overrides.rst_vref

then if i want to overlay bit AB in the rst_vref

Call copybits("AB", Hex(sVrefoDefaultVal), <%= rst_vref.bits(:AB).position %>, <%= rst_vref.bits(:AB).size %>, sRegData)

then there is a copbits function, where it will do the calcuation of the regData of that bits and depend on the length of the register and the position of the bit AB combine with the rest default data of the rst_vref and use padstring to fill either 0 or 1 if needed

[pderouen]

Hi @ThaoHuynhFsl the main problem lies in the fact that the pattern run by read/write register function (ATE version) will need to have different content (and number of vectors) from operation to operation (at least for our use case). If I am writing to a JTAG register I may need to first traverse the TAP hierarchy and enter a password. Then, the size of the write itself will be different based on the register. The protocol would also be different if I am writing to an IPS register (causing the pattern content to be different).

[priyavadan]

@pderouen @ThaoHuynhFsl @ginty thinking out loud, for different sized/sequence register transactions it almost feels like we need to have Origen make the decision based on size, content and protocol. That would probably mean a new Origen model that ties into the registers?

[ginty]

@pderouen, per @xnappo's point about address-based transactions not being so useful, I think as part of this we will have Origen render a lookup table which will just be another view of the DUT registers, described in the target ATE language.
As part of that, and probably along the lines of @priyavadan's point, we could include additional model information to help decide how a read/write to a particular register should be dispatched.

On the variable register sizes: from that table (and from the DUT model in general) we should be able to work out what all the potential sizes would be.
I'm starting to envisage that we have an Origen command to generate all of the application-specific collateral needed to enable this debug system on the ATE. Could we have that command simply generate multiple read/write register patterns that cover all possible sizes (which is presumably finite and not too many)?
Then at dispatch time on the ATE, we can look at the table to see the size of the target register and then overlay into the appropriate pattern.

On the dispatch via different protocol aspect, I can't really see any way around it without the application giving some specific guidance to the debug system in how to handle it.
Conceptually, I'm thinking that we just have the equivalent of the top-level read/write_register methods implemented in the ATE language. If the application doesn't implement that it will dispatch to a default pattern, but if present the application can use the info in the lookup table to dispatch to specific read/write patterns for the available protocols.
I think the application will also have to give some guidance to the generate collateral command to help it create the different patterns in the first place. Not sure of the detail yet, but should be pretty simple.

[pderouen]

At least for our use case all of the information that tells you how to access each register is stored in the register meta-data. So, getting that information into ATE language should be just a matter of preserving the meta-data. I like the idea of having a command to generate the required collateral for debug. That gives me a way to explicitly define and create what is needed (beyond what can be automated easily).

I don't think that there's a good way to get around some non-automated development on the ATE side for our use case. But, I'm ok with 95% automation. It seems like a reasonable approach. If we have a eureka moment in the future, the last 5% could be added at that point.

[Dieleman]

I was indeed also thinking more in the line of providing the ATE with the top-level write/read methods written automatically by Origen using the device specific protocol. This would prevent having to implement each Origen-supported protocol separately on the ATE as parts of the standard library or having to pre-generate each conceivable length write/read vector to patch.