Request for information for a new LAr ATCA board project

1

Hi Julian,

In the context of the Phase II upgrade, the LAPP is developing an ATCA board (i.e. LARTOURNETT board) managed by your IPMC.

In order to finalize our choices before the routing/manufacturing of the board.

We have several questions/requests to share with you.

  • How can I manage the user status LEDs on the front panel?
  • We would like to use interrupts to detect the change of state of input pins instead of pooling
  • Is it possible to store the FRU/SDR externally instead of the internal flash of the Cortex-M3? On our board we plan to put an EEPROM on the MGT_I2C bus to store FRU/SDR in order to have the serial number of the board.
  • Between the IPMC and our central FPGA we will have a private UART interface (i.e. PI). How can we receive data asynchronously (e.g. with callback) via this interface?
  • Between the IPMC and our CPLD we will have a SPI interface. Which pins should be chosen (i.e. via IPMC_user_IO) to map on an SPI interface and how to configure it?
  • How to implement (i.e. available API) a UDP or TCP/IP server?

Thanks in advance.

Fatih

2

Hi Fatih,

Thanks for your message. A lot of people are on holiday these days, so that’s why the response is slow. I will try to answer some of your questions as far as I can:

Markus recently made an addition ot hte user OEM commands which allow one to user the FRU LEDs, see New features in the core S/W

I am not sure how you want to use the Payload Interface. It is defined to used with IPMI messages. So far, we have only used it from the payload (IPMI request) to the IPMC (IPMI response).

I think there is a light-weight TCP server in the IPMC available, but it is probably better to wait until Julian is back from holidays to find out how it works.

Hope this helps already - more to come soon. Cheers,
Ralf

3

Hi Julian,

I didn’t get any answers from you, we need these informations (at least concerning the SPI interface) to advance in our project, it will become problematic, we need to freeze the pinouts as soon as possible.

Thanks in advance.

Cheers,

Fatih

4

Dear Fatih,

Sorry for my late reply. Julian is not working on this project any longer. Unfortunately, Markus, Stefan, and myself are not yet fully up to speed to reply to your questions immediately. I understand that your most important issue is the SPI interface? Is this the case? If so, we will start looking at the firmware/software to understand how it can be used and if and what pins are reserved for it.

Cheers,
Ralf.

5

Dear Ralf,

Thank you for this clarification.
About the SPI interface, Could you start looking at that?

Cheers,

Fatih

6

Dear Fatih,

After checking on the schematics, the pin-out, and the IPMC code, as well as consulting Stefan on this, I am afraid that there is no SPI interface. There are no SPI pins defined on the connector.
Of course, you could use any GPIO and do some bit banging. The real question is, what do you need this SPI interface for? What is it supposed to do?

Cheers,
Ralf.

7

Dear Fatih,

I now also have the reply from the support of PigeonPoint Systems, who provide us with the software for the IPMC. Such an SPI driver over user-GPIO could in principle be developed. It does not exists as of today, and it would probably be rather slow. So, I am asking you again, what you need the SPI interface for, and if you could find an alternative way of providing the functionality? If it is for selecting between a small number of functions in the CPLD, could it also be achieved using static GPIO lines?

Cheers,
Ralf.

8

Dear Ralf,

We need this SPI interface, to communicate with the CPLD in order to get either data from the CPLD or data from the central FPGA through the CPLD (i.e. HUB) with a high speed.

In case I want to do some bit banging, can I manage to have an interrupt rate of 8MHz?

Cheers,

Fatih

9

Dear Fatih,

The IPMC is running on a relatively small micro-contoller, with low frequency (80 MHz) and with frequent interrupts. The PigeonPoint support therefore state that “… such SPI implementation will be very slow (less than 100kHz for SCLK and inaccurate due to software interrupts).”
Besides of the fact, that such a driver does not exists today, but would still have to be developed and debugged. To me this looks like a dead end, and I would strongly advise to look for alternatives.
I would also like to add that the IPMC is not meant to be at all a device for high-speed data transfer, but rather classical “slow control” hardware control, in terms of temperatures, voltages, currents etc.

Cheers,
Ralf.