"Chip ID" and "REG_ID" Disambiguation?

[dstulken]

I recently set down a path to read the EVE "Chip ID", and in the process, discovered that some unfortunate naming/wording choices by FTDI have carried through as some ambiguity in the library here.

Specifically, the first is the "Chip ID", the "chip identification code", at address 0xC0000 through 0xC0003 in RAM_G, which returns a code that identifies the version of the EVE chip (FT810, FT811, FT812, FT813, BT815, BT816, BT817, and BT818). The library includes a definition for this address (EVE_ROM_CHIPID).

The second is "REG_ID", the "built-in ID of the chip", at address offset 0 and defined in the library as REG_ID. despite the similar terminology, this register only returns a singular value (0x7C) if the chip is an EVE chip.

Where this gets confusing is that the library has a function called "wait_chipid", which in addition to the function name, uses "chipid" terminology throughout - "EVE_FAIL_CHIPID_TIMEOUT", "uint8_t chipid", etc. But this is all code which manages REG_ID, not EVE_ROM_CHIPID. The current code doesn't seem to query or use the chip ID in RAM_G.

I would therefore humbly propose some strategic renaming...

wait_chipid() -> wait_regid()
EVE_FAIL_CHIPID_TIMEOUT -> EVE_FAIL_REGID_TIMEOUT
uint8_t chipid -> uint8_t regid,
etc,

to clarify which "ID" this function and these variables are related to. It might also be good to rename EVE_ROM_CHIPID (to EVE_RAMG_CHIPID perhaps?), since the address points to RAM_G data which is volatile? (Bridgetek cautions that the data must be read before the application overwrites the data.)

[dstulken]

Tangentially, does anyone happen to know the proper sequence for reading and programmatically handling the chip ID? I'm comparing both the earlier FTDI and later Bridgetek docs... and there's an interesting sequencing issue present.

Specifically, the BT81X docs recommends using CLKSEL to change the system clock from 60MHz to 72MHz for better performance, and this is done very early in the EVE init process, before sending the ACTIVE command, and before the spin wait for REG_CPURESET to indicate the chip is ready. Presumably we need to wait until after the CPU is ready to query the Chip ID... but it is only after querying the Chip ID that you would positively know if the chip was a later generation that supported the 72MHz clock speed... which was already set before the chip was "ready"... so it's a circular dependency?

Also a puzzle to me which I found while digging through this - The FT81X docs describe using REG_FREQUENCY to set the main clock frequency (60Hz default), but no additional guidance is given, nor is it listed as a part of the init sequence. In the BT81X docs, "host_command(CLKSEL)" is called without parameters to "select the system clock frequency", then "wr32(REG_FREQUENCY, xxxxxxx)" to configure the frequency to a specific value. I don't see any other information on "CLKSEL" or its usage.

In the library code, an extra parameter appears with CLKSEL:

EVE_cmdWrite(EVE_CLKSEL, 0x46U); /* set clock to 72 MHz */

followed by:

/* tell EVE that we changed the frequency from default to 72MHz for BT8xx */
EVE_memWrite32(REG_FREQUENCY, 72000000UL);

... so the library is setting the clock twice? Is there an error in the BT81X initialization sample code, or how did you know that CLKSEL takes a parameter (or what the format of that parameter would be?)

Just some curiosities... Thanks as always for your efforts on this library.

[RudolphRiedel]

I would therefore humbly propose some strategic renaming...

I agree and changed the references accordingly. :-)

EVE_ROM_CHIPID is the same though that Bridgtek is using.

I never bothered to use the chip ID though.
And this allows to use a BT817 as FT813 for example.

CLKSEL and every other host command is a three byte sequence.
Check the datasheet for this, chapter 4.1.5 Host Command.
CLKSEL is 0x61 or 0x62 and the second byte has the configuration for the PLL clock.

/* tell EVE that we changed the frequency from default to 72MHz for BT8xx */
EVE_memWrite32(REG_FREQUENCY, 72000000UL);

... so the library is setting the clock twice? I

No, writing to REG_FREQUENCY does not configure the clock at all.
I believe this is only to tell the coprocessor-engine which frequency was configured,
but I actually wonder why the coprocessor-engine could not figure that out by itself.
The issue might be that there is no REG_PLL to check or configure the PLL but then CLKSEL
has to configure it somehow.
And just because there is no REG_PLL in the public API does not mean it does not exist internally.