GDPR, 2018: Please see the revised Pivacy Policy for this wiki: General Data Protection Regulation
EU Cookie Directive: Please see the following note regarding opting in to the use of cookies for this wiki: EU Cookie Directive

Please Note: You must be logged in to edit this wiki and your account must be assigned "editor" rights (set by administrator).

Talk:Volume 4

Revision as of 20:55, 2 March 2009 by Ian McIntosh (talk | contribs) (Changed forum link)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

See forum discussion:

Implementation Issues

Remove first person perspective: At the moment (early Feb 2009), there are passages which reflect a first person viewpoint. This is understandable given that the text has been drawn from existing resources but needs to be re-worded to a more objective sounding third person perspective. --Ian McIntosh 21:22, 8 February 2009 (UTC)

Device Programming Language

I suppose the opening gambit here would be to state that IEEE std 1532 ought to be the preferred device programming language. But that would be a bit trite and would be ignoring the vast number of devices in current use (and will no doubt continue in use for some time) that do not support 1532, and where SVF/STAPL are the generally accepted methods (outside of the vendor's own tools). An additional complication arises with devices such as microcontrollers with internal flash memory. These can fall into two categories: The first where the microprocessor core and the flash memory are essentially seprate device dies built into a single package, the second where the entire device is a unique, single silicon device. The former type of part can generally be programmed using conventional Flash progamming methods, assuming that the microprocessor has a JTAG TAP; the latter is more difficult and generally requires either vendor tooling or some other dedicated programming process.--Ian McIntosh 21:01, 15 February 2009 (UTC)

Effects of Architecture

The outline text in this section perhaps also leads into a discussion on SJTAG as an "enabling technology" (although this is not directly pertinent to a document on languages and data formats): Supporting concurrency may not be a driving factor for some users (e.g. there may be no view on using JTAG during POST or for FPGA configuration). However, if a simple multi-drop architecture is adopted on that premise then it may preclude the later incorporation of FRUs which do use JTAG for those operations. It is a case where failure to take an adequate view on "future-proofing" the system architecture may impose limitations on future design options for upgrades, expansions, etc.--Ian McIntosh 19:42, 1 March 2009 (UTC)