Skip to main content ↑ ↓
Topic: SUMP capture options vs firmware capability (Read 1857 times) previous topic - next topic

SUMP capture options vs firmware capability

Just a simple question:

The various firmwares seem to have different capabilities:
- max capture width (8-16-31 bit) vs buffer size
- pin numbering

The capture dialog of the SUMP client always displays all capabilities.

Does this means I will have to know which firmware is programmed into the FPGA and configure my capture with these limitations in mind ?

For example if my firmware contains a 16bit-8k firmware I'll have to abide by these limits ?

What happens if I don't ?

Does the firmware contains a software readable ID-string so the the SUMP client could read its capabilities and only enable the capabilities of the hardware ?
Markus

Re: SUMP capture options vs firmware capability

Reply #1 –
The word firmware is not quite correct and rather confusing when talking about the FPGA configuration files (bitstreams).

When we speak about firmware we mean the code for the PIC MCU. At this point only one firmware version for the PIC
MCU should be used, the version that shipped with the OLS boards from Seeed. The PIC firmware has no impact on the
SUMP features like capture width, pin numbering, RLE etc. as the PIC acts as an asynchronous serial to USB bridge only
while in application (SUMP logic analyzer) mode. When updating the FPGA configuration image (bitstream) in the SPI
flash, the PIC MCU acts as an USB to SPI bridge (SPI flash programmer).

When using the different FPGA configuration images (bitstreams) you must consider their limitations/restrictions when
configuring the client ... to my knowledge the client has no feature that verifies if the selected features are valid/supported
by the configuration image loaded/active in the FPGA. For this it is recommended to use the "standard"
32bit-4k for now. All other configuration images should be considered "experimental" at this point.

I am not quite sure what willl happen exactly if the user does not abide to the limits/restrictions of the active FPGA
configuration when configuring the client. The captured data will not be shown correctly, the defined trigger condition
may not be met and thus the LA will not start capturing data at all ... essentially it will depend on the features/options
selected in the client but not available in the loaded FPGA configuration. However, feel free and encouraged to play
around and test the other configurations at your own risk ... there should be no danger of damaging the OLS hardware
when selecting unsupported features/options.

The configuration image contains an ID that can be requested with the ID command (02h). Here you can find a(n)
(imcomplete) description of the SUMP Communication Protocol.

There is plenty of room for improvements and new features in the client, the VHDL code (FPGA configuration) and the
communication code ... the OLS hardware has a number of features and resources that have not been used/explored,
yet. The SPI interface between the PIC and the FPGA is one example. Jack works on the VHDL code to replace the
asynchronous serial interface that's used currently used with a faster and more stable SPI interface. Once the VHDL
code will support the SPI interface a new firmware for the PIC will be required to make use of it, so.

Re: SUMP capture options vs firmware capability

Reply #2 –
Hi,
I think we will see many improvements on the Java client code once the firmware and bitstreams on the hardware have reached a stable status.
Without knowing anything about FPGA's I think it should be for instance possible to add a command that returns some sort of ID that identifies for the installed bitstream, so the client can show only available options at runtime.

... and since we are talking about ID's, from the atmel xplain board I learned that every DataFlash also has a globally unique ID. If there was a command to retrieve this number from the  client I would be able to tell my 2 boards apart, by putting a sticker on them and selecting them in the client by this number.
(Is there are sort of wishlist, for future Client development?)

Eberhard

Re: SUMP capture options vs firmware capability

Reply #3 –
The different bitstreams are temporary solution. There is a development thread where Jack has tried to etch the further development of the VHDL design - this includes one bitstream for all different combinations of ram/inputs.

The ID from the Fpga is SUMP id that is used to identify that the OLS is present, and there is only ONE ID. So it is not possible to distinguish between different bitstreams just by poking the serial port.

Re: SUMP capture options vs firmware capability

Reply #4 –
[quote author="robots"]
The ID from the Fpga is SUMP id that is used to identify that the OLS is present, and there is only ONE ID. So it is not possible to distinguish between different bitstreams just by poking the serial port.
[/quote]
Yes I know, I was talking about future developments.
I read the thread about the plans for revision 2  , so there will be at least boards available with more on-board memory.
There should be some kind of getRevision()/getMemorySize()/getWhatEverBoardSettings() command implemented in the firmware, which the Pump Client can use for querying the device capabilties.

Eberhard

Re: SUMP capture options vs firmware capability

Reply #5 –
[quote author="wayoda"]
[quote author="robots"]
The ID from the Fpga is SUMP id that is used to identify that the OLS is present, and there is only ONE ID. So it is not possible to distinguish between different bitstreams just by poking the serial port.
[/quote]
Yes I know, I was talking about future developments.
I read the thread about the plans for revision 2  , so there will be at least boards available with more on-board memory.
There should be some kind of getRevision()/getMemorySize()/getWhatEverBoardSettings() command implemented in the firmware, which the Pump Client can use for querying the device capabilties.[/quote]
Such a capability would be very useful, even for the current hardware.

I could also imagine that the current ID indicates the capabilities. The Java client could look up the capabilities in a table and use the ID as index. This could be implemented without breaking compatibility.
Markus