Minutes of Weekly Meeting, 2015-08-10

Meeting called to order: 11:04 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Heiko Ehrenberg
Carl Walker
Brian Erickson
Brad Van Treuren
Tim Pender (joined 11:08)

By Proxy:
Michele Portolan
Peter Horwood

Excused:
Adam Ley

2. Review and approve previous minutes:

  • Approval of August 3 minutes (draft circulated 8/3/2015):
    • No corrections noted.
    • Eric moved to approve, seconded by Brad, no objections or abstentions.

3. Review old action items

  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? See also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Ian: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

a. ITC Participation.

  • Ian noted that Michele was now offered an invited talk rather than a poster, which gave us more options for supporting a SJTAG poster.
  • Heiko indicated that he'd be available in any case.

b. Start defining what activities need to be done during pre-conditioning.

  • Brad: I was trying to diagram what it would take for memory-mapped, I2C and other links; there seems to be an overlap between pre-conditioning and data transaction for all cases, especially memory-mapped.
  • Brad: A lot depends on how far up in the tooling you are.  In 'C' it'd be one statement assigning data to a pointer.
  • Brad: When do you leave pre-conditioning and move into data transfer or leave data transfer and move into post-conditioning?
  • Brad: It doesn’t look like we can clearly separate preconditioning from data transfer, e.g. there may be an address latch enable that is needed for addressing but then there are also a chip select or write enable and possibly other control signals that are needed to indicate that data is ready for transfer. There's a control aspect involved in sending data.
  • Brad: With I2C there is an address field followed by acknowledge (ACK), and then a data field, followed by ACK; where do the ACKs fit in? Are they part of a data transmission frame? Or is the ACK outside of the data? 
  • Ian: To me it seems the ACK belongs within the address "frame" or data "frame" it goes with - they tell you something about that frame.
  • Ian: For a well-defined protocol like I2C making that decision may be fairly straightforward, but there is not really a standard memory-mapped access "frame" or protocol - they could all be very different - so that may be much more difficult to handle universally.
  • Brad: Even with I2C, there are things like 16-bit data to deal with and SMBus and PMBus built on top of I2C.
  • Brad: I like your terminology of "frame"; a "transfer cycle" may consist of multiple "frames".
  • Brad: I2C has transaction cycles that includes addressing. Similarly with RS-232, there bits to mark the start, then the data bits, followed by bits mark the end. 
  • Brad: Probably for our core we should define a high level framing structure, and the dot extensions can show how specific cases fit into the structure.
  • Ian: If we define that framework, should we maybe detail how you make something fit it, to make it user extensible, rather than trying to define how all the interfaces fit in?
  • Brad: My only concern would be how/if tools would be able to handle such user-extensible cycles.  There needs to be a driver somewhere and it's not necessarily generic: An I2C master on a bridge will be different to an I2C master connected some other way.
  • Ian: We know that we can deal with these cases in an ad hoc fashion. The problem we seem to have is describing that method in some generic or abstract fashion.
  • Brad: It comes back down to addressing this issue "bottom-up" to define the leaf nodes and how they behave. We should be able to define an I2C master in a BSR (bit bang) on the board - 1149.1-2013 and 1687 were unable to realise that at the time.
  • Brad: Maybe the simplistic diagram we started with (pre-conditioning, data transfer, post-conditioning) can be our core level for general abstraction and then we can drill into it using a "bottom-up" analysis to see how specific protocols fit into this.
  • Brad: Can we enumerate what protocol cases we want to fit in?
  • Ian: That makes me think again "where is the bottom?"
  • Brad: I'd say the individual protocols would be the bottom for us.
  • Ian: OK, protocols as the bottom probably means that the question of hierarchy and whether it's inside a chip or at the chip edge or board edge probably drop out.
  • Ian: I'm wondering if there's a finer grained primitive for us: Sending an address is pretty much like sending data, it's only what the enclosed data is used for and where it goes that is different.  What I'm thinking is that where you have a nested case, say an I2C sensor connected to I2C master in the BSR of a PLD that is in a chain downstream of a gateway device on a multidrop bus, then once you've addressed the BSR the "data" passed into the BSR might contain the "address" of the sensor.
  • Brad: This is what we realised with assemblies; that we have assemblies of assemblies and we're recreating the same thing here. 
  • Brad: there always seems to be a time based ordering.  Data may be pre-conditioning of a lower level step.
  • Brad: This was why I was trying to delineate between Access Links and Data Links.
  • Ian: I'm slightly worried that people might infer that an Access Link is always physically distinct from the Data Link.
  • Brad: OK. I guess an Access Link is a specialisation of a Data Link.
  • Tim: Regarding a BSR for an I2C master: Do we want to perpetuate the ad hoc or standardise the ad hoc? It's kind of slow and messy and it'd be much more useful to define an instrument.
  • Brad: Yes, but I think we were trying to find a corner case that proves we have the generality of abstraction. In any case, the master might be on an AXI bus and we need a JTAG instrument to get to it.
  • Brad: The simplest protocol is the SIB.  That's simply scanning data through a register and setting a bit to enable it or clearing a bit to disable it. It's part of an overall scan chain.
  • Brad: Michele's demo shows how that fits into his top-level Select methodology, but we still have to look at how that fits into our setup/address, data, cleanup cycle.
  • Brad: Once we know we're accessing that Test Data Register, is that the addressing? Is it in the bit position?
  • Ian: I was feeling that the bit position was effectively the "address" as the register might control several SIBs.  But with the parallelism in JTAG tests, the same vector that enables a SIB for some future action could also be testing the interconnects between some other parts of the circuit.  The vector is not clearly "address only" or "data only". 
  • Brad: The portion of the model that deals with the bits or scan segment should deal with the intent of the bits involved.
  • Brad: I can't see how the current execution model can handle mixing of configuration with operation.
  • Ian: JTAG was never designed with the kind of thing we're looking at in mind.
  • Brad: This is why Michele and I invented the TISA execution model.  Only the model understands its role for its segment.  For the SIB, it manages when the sub-chain is bypassed or expanded.  The purpose of a data bit has to be controlled by the portion of the model itself that understands what those bits are being used for.
  • {The following comments were supplied post-meeting by email. The text has been minimally edited to fit the format of the notes, but is otherwise the commentor's original text}
  • [Brad by proxy]: The time at which the bits are sent to the target segment is managed by the TISA scheduler.  In some cases the data represents the addressing.  In others, it represents the content data required for the operation.  Only the model for that segment knows what the role of the data bits are for at that instance in time.  The model then places a request to the scheduler that it is ready to update its segment.  The scheduler only knows there is some segment that needs to be updated at a particular instance in time relative to other segments.  So the combination of both the TISA scheduler allowance of data updates at the appropriate time and the model defining the purpose of the data bits provides the harmonious flow between access and data for each transaction required to apply the target operation.  It may be an iterative cycle with multiple frames that configure the overall data path to the targets identified for the current operation set.  That configuration may then change over time based on the next set of target registers to update.
  • [Michele by proxy]: Sorry I missed this interesting discussion, I will try and make some proxy contribution:  
    • when we look at alternative AccessInterfaces like memory-map or I2C, I believe the bottom should be at the transaction level: read/write. Going deeper and look at ack, select, etc... just complicates things and make abstraction more difficult.
    • to keep pre-condiitioning and data transaction separate, I exploit the Circuit Model Status: a pre-conditioning can involve simply a change in the CM, but the actual application will be pushed into the SUT only during the data cycle. This is for instance what happens for a SIB: during configuration you change the value of its control register in the CM, but the application is actually done during the data cycle;
    • this concept can be translated into AccessInterfaces too: during configuration you change the CM value of the control data (being it an IR register or an I2C, SPI, etc...). These modification will flag preconditioning requests;
    • during the preconditioning step, a flag will result in a preconditioning step. In case of an AccessLink, the "preconditioning info" field and the"do-postconditioning" method are resolved, so the operation can be resolved.

    • if you look at the transaction level, I2C and SPI are actually WAY easier than JTAG: transactions are independent, all you need to provide is the address, the data size and the direction (in this case, write). So for instance I can configure the BrocadeAccessLink, in the preconditioning info I instantied an array with the Address and the Control Register, while the do_preconditioning is an i2c write using the two fields.
    • this should be possible also for IR, as you generate a TIR cycle if there is need to change the instruction. With a twist in the case you have dausy-chained IR registers, but I admit I have not developed the case yet
    • this is all easy CONTROL. It could get uglier if you want to change the protocol used for data transfers (ex: write the TDR registers from I2C). Control-wise this would nor be too difficult (it is a matter of resolving the "pull" method and configuring the CM accordingly), but standard-wise would we need some hardware rules too?
  • [Ian by proxy]: I think what you’re describing maybe aligns with Brad’s comment early on in the discussion – "it depends on how far up in the tooling you are".  I suspect we’re not being entirely self-consistent about "how far", or at least, as individuals our viewpoint maybe tends to wander through the course of the discussion. 
    You’ve maybe worked through much of the bottom-up analysis to arrive at the appropriate viewpoint for your model; the rest of us are probably working through that for the first time now in an attempt to "discover" the right level of abstraction.
  • [Michele by proxy]: It's good we have different points of view: I had to come back many times to refine my approaches when the group made me realize I passed some key points too fast.
    I believe that finding the right balance between different AccessInterfaces is a key point and we need everyone's sensibility to do it. I am seeing 1687 newbies already discussing "1687/I2C translators", without having any clue of what this actually means. So as a WG is our duty to try and clear things up before a huge mess develops.....
  • [Brad by proxy]: Abstraction is a necessary tool in our analysis.  But at the end of the day we need to be able to ensure our description of the domain is able to be applied by the various tooling.  That means we need to provide closure in the description of just how the hardware is operating to bring the intent to the target instrument.  The protocol master may be comprised of very different solutions depending on the implementation.  We can't just generalize it to a protocol and leave it there.  Ultimately, there has to be some way of accessing a set of data registers in the protocol controller to transact the operation required by the protocol.  It is really no different than an instrument.  It gets back to being able to control the addressing (access) sequenced with the data at the appropriate times in the control/execution cycle.  As we pointed out, the addressing portion may actually consist of multiple addressing and data frames to perform the intended access/addressing for a target data register.
  • [Peter by proxy]: Hi guys sorry to miss out on discussion, some interesting views. From a system test point of view should we look at specifying a software packet of vectors to be delivered, this might be on any bus such as SPI, I2C, JTAG, etc. This would allow for host system to interpret this in the manner suiting the system i.e. bit bang hardware etc. If we start specifying complex hardware protocol translator we could risk going the way of .5 i.e. impacting all cards dm costs.
  • [Brad by proxy]: I appreciate your concern and it is good to question directions.  I think the fundamental difference between .5 and what we are looking at now is we are trying to support interfaces people are currently using instead of trying to force a new single interface to replace the current interfaces.  A long time ago I got involved with a product that needed to have firmware updated in the field on a CPLD that did not have an interface from the on-board CPU.  Fortunately, the designer of the system controller interface (via I2C) provided a GPIO hook that was wired to the local JTAG bus.  I ended up writing a special driver to send the bit bang commands via I2C to be able to do a very slow JTAG update for the CPLD with covers on in the field.  It would have been nice to have a capability to be able to create that driver from a standardized description than ad hoc development.  What we are trying to achieve is to simplify the development of the tooling required to support various architectures.
  • [Peter by proxy]: I agree we are looking at how to support the buses that are in use for testing. That is the reason for the suggestion of being able to specify a data packet to be delivered to a specific target bus in the system. For example our JIP20 core we provide for fast SPI flash programming to data sheet numbers is a JTAG to SPI converter. At this level we would just need to be able to target the data to the JTAG bus as the JIP20 handles the final conversion in hardware.
  • [Brad by proxy]: Your JIP20 would be an example of a JTAG to SPI Master bridge.  The model defined for interfacing with it would have the standard pattern interface Michele talked about, but the internals of the model describing the behavior would have what is needed to access the controls of the bridge.  So it would define that an instruction has to be scanned into the device to access the appropriate register as the addressing phase followed by a data register scan to the control register with the data provided by the model method for sending data to the instrument.  The difficulty I see is how do we represent hybrid instruments that are a combination of architectural features?  Are their elements described separately or in aggregate?  If in aggregate, then how do you delineate between instrumentation features from a standardized API?  These are good points you are raising to promote more questions.
  • [Michele by proxy]: These last years I have been working quite a lot with Embedded Linux, and they have a similar problem: how to document the different components embedded with the processor or on the board and associate them with the correct driver?
    • The solution is extremely simple : the device tree. Each chip provider and board assembler has to give some key attributes in a text file, so that the kernel can at startup make the link. For instance, you might find these lines:
    •   ps7_axi_interconnect_0: axi@0 {
          #address-cells = <1>;
          #size-cells = <1>;
          compatible = "xlnx,ps7-axi-interconnect-1.00.a", "simple-bus";
          ranges ;
    • The interesting part is the "compatible" line: it is used by the boot loader to call up the right driver, as each driver declares the same strings.
    • So what for us?
    • I believe that we should define a list of attributes for each node, like for instance "1149.1 CSU" for a standard register,  "1149.1 CS" for a read-only, "1149.1 SU" for a write-only, etc. This way the test tool can control statically verify the DfT network (ex: is an input port of an instrument connected to a writable register?), while also making run-time checks (Error: trying to write to a read-only register).
    • So, for instance, a "SPI" register will need to be connected to either an "SPI" AccessLink, or to an "JTAG2SPI" bridge like Peter's JIP20.
      Most of these information could be automatically extracted from the RTL/ICL, or directly documented by the instrument provider.
    • What do you think about it?
  • [Brad by proxy]: I think you are still looking at this from too high of an abstract level.  "Compatible" for linux means someone has predefined a driver with a certain defined behavior.  If your interface behaves the same, it is what we call duck typing (if it walks like a duck, swims like a duck, and quacks like a duck, it must be a duck).  You still have not address how one in SJTAG defines that driver behavior so a tool vendor may incorporate that driver into their tooling.  Your assumption is that it already exists.  We need to be able to specify exactly what primitive operations have to be performed to talk to Peter's JIL020 and how that control is different than, say, a design that uses a JTAG2AXI bridge synthesized with an AXI2SPIMaster.  Functionally, they are doing the same thing: commanding the SPI bus.  But physically, they behave very differently.  So we have to make sure the interface from the top specifies the functionality and that the description on the back end is able to describe the real behavioral sequences required to control it physically to perform that behavior.  There is a set of primitives we have to define as building blocks to describe this physical interface behavior.  I am not convinced we need to define it at an RTL or VHDL level, but we need to be able to specify certain operations like a memory write/read, JTAG scan, SPI address/data, etc.  This is what I was trying to get to with my flow diagrams.  How do we decompose the flow into its smallest required elements and still keep it abstract.  I think your JTAG CSU, JTAG CS, JTAG SU are part of what I am meaning.  There are a lot more we need to resolve.

6. Topic for next meeting

  • Look at SIB in detail, followed by I2C.

7. Key Takeaway for today's meeting

  • Access Flow and Data Flow look similar although purpose is different.
  • Addressing may occur before or at the same time as the data transfer.

8. Glossary terms from this meeting

  • None.

9. Schedule next meeting

  • August 17 - Peter out for the next two weeks
  • August schedule: 17, 24, 31: Eric out 24 and 31.

10. Any other business

  • The Newsletter was due at the end of July.

11. Review new action items

  • None.

12. Adjourn

  • Eric moved to adjourn, seconded by Brain.
  • Meeting adjourned at 12:01 PM EDT

Thanks to Heiko for providing additional notes this week.

Respectfully submitted,
Ian McIntosh