diamondman / proteusisc Goto Github PK

Most controllers support configuring the clock rate that they use to send data over JTAG. Proteusisc must be able to set this speed, and keep track of the current speed for being able to convert (seconds) time into clock cycles (hertz).

Device drivers should be able to specify their max speed to proteusisc, which could allow automatic speed calculation.

Currently, Sleep Primitives stall the whole command queue as they are executable lv2 primitives with no way to merge with nearby LV1 primitives. But in many cases, Sleep Primitives could be replaced by looping for n cycles in the current TAP state. A Sleep primitive would only be able to expand if the current state is loopable (TLR, RTI, SHIFTDR, SHIFTIR), and if the transfer rate of the controller is known.

This enhancement will allow multiple RunInstruction Primitives to combine into a single LV1 primitive, even if the RunInstruction Primitives have sleeps in them.

Requires #5

The ConstantBitarray and NoCarebitarray classes allowed for defining the intended behavior and requirements of the bits they represent. But when they are combined, we often lose the original purpose of those bits. For example, if these two bitarrays represent when bits should be read from tdo, the result can be unoptimal:

readtdo1 = ConstantBitarray(True, 32)
readtdo2 = NoCareBits(9)
readtdo1 + readtdo2 # Results in ConstantBitarray(True, 41)

If after several layers of primitive combination, the above bits got to a primitive that supported arbitrary tdo bits, the original intent specified by the NoCarebitarray would not be recoverable, and the primitive would read data for all bits.

The result is returning much more data from the controller than necessary.

A solution is to keep reference to the constituent bitarrays when it makes sense to do so, and then fitting that data to the capabilities of the primitive.

Most tests to the compilation system are functional tests. This leaves too much room for error, or unclear test failures.

As described in #7 it is possible to lose the original intent of NoCarebitarrays. For primitives that support reading arbitrary tdo bits, the result is often reading much more data than is necessary.

Requires #7

http://www.openjtag.org/download/protmanual/1.1/OPENJTAG_Communication_Protocol_Manual_1.1.pdf
The previous link describes the protocol. It requires Serial emulation over usb so data can't just be sent raw.

The Digilent protocol is not particularly fast, but it is rather straight forward to use. The main limiting factor is the need to send many small requests to the controller over different USB messages (which makes the limiting factor the transfer and response time of USB).

Some Digilent controllers support batching multiple commands together into a single stream, thus mitigating the main issue of the protocol for configuring large devices.

There is insufficient documentation on the purpose and behavior of the Primitive classes, as well as the primitive compiler related code (CommandQueue, Frame, etc).

Proteus' JTAG core was built first, but in the long run it should support more wire (ISC) protocols.

Proteus should also be able to combine multiple wire protocols at once.

For example, on a system with an FPGA attached to a flash chip (containing the FPGA's startup configuration) over spi. A common approach to programming the SPI Flash is to load a program into the FPGA's RAM that turns the FPGA into a flash chip writer so the Flash device can be programmed over JTAG (with the FPGA as an adapter).

Proteus should be able to load a flashing program into the FPGA's RAM, and then use the FPGA as an SPI controller (automatically adapting the JTAG calls).

Related to the issue diamondman/adapt-xpcusb-firmware#12

All reads in current tests have been 32 bit multiples. It turns out that the XPCU may reply incorrectly when reading data over 32 bits not divisible by 4. Will need to test if it breaks, and if so, check how the Xilinx tools read off numbered data.

A broader solution may be to write new firmware for the XPCU's CPLD hardware accelerator since it appears to be the thing misbehaving.

Usb is common for modern hobby and development controllers, but many controllers use different connections.

Older controllers often use serial or parallel ports.
High performance or industrial controllers often use Ethernet.

Proteus needs to not only add support talking to controllers over these connections, but also a way to add new connection types without requiring a rewrite of all controller drivers.

https://github.com/swetland/jtag/blob/master/usb-blaster-protocol.txt
http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cable_Altera_USB-Blaster

Open hardware hackers often use battle tested and straightforward FTDI devices to be their on board JTAG controller. These devices are very important to a large portion of proteus' target user base.