ZMOD vadj rail

[svaughn442]

Hi,

I have an  Eclypse Z7 board with the ZMOD AWG DAC. How do I set the Vadj rail from Eclypse to the SYZYGY port?

thanks

Stan

[artvvb]

The VADJ rail is automatically set by the Eclypse's platform MCU when the board is powered on. You can find more information on this in section 3 of the the PMCU Specification document: https://files.digilent.com/resources/programmable-logic/eclypse/Eclypse-PMCU-Specification-Public.pdf

The rails can be further configured after the fact by using decutil from the Linux images to communicate with the PMCU. The command manual for decutil can be found here: https://digilent.com/reference/_media/reference/programmable-logic/eclypse-z7/decutil.1.pdf

Thanks,

Arthur

[zygot]

Note that the SYZYGY specification is supposed to be "plug and play" using the SYZYGY DNA negotiation phase post power-on. Pods are not meant to have a "hot-plug" capability. This means that you need to secure your pods to the carrier boards ports. I would be nice if SYZYGY pod vendors supplied the necessary hardware to do that, or at least recommended specific spacers, nuts and bolts. 5mm spacers are not readily available. The safest bet is probably to use nylon spacers, nuts and bolts to avoid stressing the pod and carrier board PCBs. Also, users should not normally try and circumvent whatever Vadj is arrived at by the DNA process. If one were doing development on a custom pod board I suppose that manually setting Vadj might be useful as an interim step toward completing the pod design. This would require some careful planning to avoid unintended consequences for your pod and carrier board.

Opal Kelly publishes SYZYGY specifications and I'd suggest that anyone using the SYZYGY interface familiarize themselves with this documentation.

The Eclypse-Z7 implementation of the SYZYGY DNA specification, particularly with respect to ADC and DAC calibration data, is not quite "plug and play" across SYZYGY vendors. Ideally, one would like to be able to choose a SYZYGY carrier board from any vendor and a SYZYGY pod from any other vendor and be able to take full advantage of the hardware. To me that's what 'plug and play' means in the FPGA space. I think that the Eclypse-Z7 situation is mostly a lack of specificity on the part of Opal Kelly's specifications. Given the range of possible pod types this might not be avoidable in all cases. Perhaps now that there are a few SYZYGY pod vendors the specification could be updated for ADC and DAC pods. At least SYZYGY carrier board vendors should consider offering better flexibility in providing access to DNA data.

The PMCU also controls the Eclypse-Z7 fan and this might be something that you might want to control as you are using the board. You don't need to be running Linux on the Eclypse-Z7 in order to change the fan settings but doing so isn't exactly straight-forward using the Standalone OS, but it can be done. Edited May 17, 2022 by zygot

[gueste]

Hi,

I have the same problem as described by Stan.
We're currently developing our own custom pod board for an Eclypse Z7. Since it's only meant to be used in one of our projects, the pod doesn't include an onboard µC and is therefore not able to send any DNA at system startup.
For being able to test and use our hardware, it's necessary to activate the VADJ_A power supply from inside our bare metal project. Therefore I'm not able to use a Linux image with decutil.

The problem is the following:
I'm able to activate/deactivate the onboard CPU fan by reading / writing the corresponding registers of the PMCU via I²C but it seems, that writing the VADJ_A_OVERRIDE registers is not possible.
The register doesn't accept any changes, even if I try to set only a single bit.

Can you please give me some advice on the necessary steps of activating the VADJ_A power supply or at least some tips why I'm not able to write to the VADJ_A_OVERRIDE registers?

I really appreciate any help you can provide :)

Thanks,
Steffen

[zygot]

With regard to how one should implement a one-off custom SYZYGY pod, the following is obviously my personal opinion.

The DNA part of the SYZYGY specification represents a basic feature as this is what tells the carrier board that a pod is present and what the Vadj rail should be set to. By not including this, in even a simple custom pod, you are breaking not only the "plug and play" nature of the interface but the initialization process as well. I realize that it's tempting to omit this part of a custom pod design, as it requires a secondary HW and SW effort. but there are unfortunate consequences and risks for doing so. I'd advise against making this choice.

Nevertheless, I suppose that carrier vendors are free to amend the specs if the user is willing to be responsible for the outcomes. If Digilent provides a VADJ_A_OVERRIDE register then there's a tacit advertisement that they support users setting or changing a port Vio voltage on the fly. Perhaps this functionality hasn't been implemented yet?

Given that the spec has a pod providing min/max Vio requests and the carrier board deciding what Vio will actually be provided there might be some important details for a specific SYZYGY carrier board that might get missed if the user simply selects on Vio voltage; it's something to consider. I can see a situation where a user wants to insist on a particular Vio but without the DNA interaction the carrier has no idea what the max current draw for a pod might be. This may or may not be a problem. Edited May 19, 2022 by zygot

[artvvb]

To add on to what zygot has already said, the override register also requires information from the DNA, and PMCU firmware does not allow values to be set which fall outside of the bounds specified by connected pods.

From the PMCU spec:

Quote

The SOC/FPGA may write the VADJ_n_OVERRIDE register using the SOC/FPGA I2C Slave Interface to override the voltage and enable settings for each individual VIO supply. Each time one of these registers is written the PMCU firmware checks to see if the specified configuration is valid. If the default VADJ settings are being overridden to enable a VIO supply then the PMCU will check to make sure that it’s safe to enable the supply and that the specified voltage is within the allowable range for the VIO group based on all pods/mezzanine cards connected to any ports that are a member of the VIO group, as well as any board/port specific voltage restrictions. If the specified voltage is outside of the allowable range, then it is forced to be the minimum or maximum allowed voltage for that VIO group.

Thanks,

Arthur

[zygot]

Here's a random but pertinent musing about "plug and play" FPGA based carrier/mezzanine boards.

In theory, the HPC or LPC FMC connector, which has become common on both Xilinx and Intel FPGA carrier boards, could provide some "plug and play" functionality as there is a two wire serial link generally assigned to the pins in order to be "compatible" with the Vita57 specification. Not all FPGA boards or FMC mezzanine cards claim or even try to be Vita57 compliant. All of the FMC mezzanine boards that I've used do connect that serial link to an EEPROM. So, in theory, one could do something similar to the SYZYGY DNA in terms of determining adjustable voltages. In this case, the serial link and EEPROM are tied to a 3.3V rail and available to the FPGA. Well, this is true for the Series7 and older devices, but perhaps could complicate the design of newer FPGA devices if there are no IO compatible with 3.3V logic. I've yet to encounter a situation in which the mezzanine card contains any usable information about Vadj voltage and current requirements. For the Nexys Video one could conceivably use such information to set the Vadj rail because GPIO pins are connected to the power supply for user Vadj selection. For the Genesys2 Vadj is controlled by physical user switch settings. For SYZYGY, where a carrier board might have 5 or more SYZYGY ports one can see how this might become an overly complicated power supply problem for the carrier board vendor. I have more than a few FMC mezzanine cards that are compatible with my Series 7 FPGA boards but not my UltraScale+ FPGA boards, and visa versa. UltraScale+ is 16nm technology, which isn't near the bleeding edge, so one can envision that the IO rail voltage limits will continue to get lower over time.

While, as an FPGA board user I'd prefer having the FPGA have a direct link to any add-on card data, this isn't universally easy or cheap to achieve, given the tendency of newer FPGA devices to have ever low maximum IO bank Vccio rails. There's another issue though that perhaps the SYZYGY specification hasn't addressed completely yet. In order to obtain a bitstream or sof file you need to pass a DRC test that requires specifying an IOSTANDARD. Having a pod submit a minimum Vio voltage and maximum Vio voltage as well as the maximum current levels each would see and then allowing the carrier board to select one may be fine for some applications but not for others. At this time however, it's certainly too late to go back and change the constraints to rebuild your FPGA design.

For me, the suitability of "plug and play" for the FPGA space is not certain. In addition to what I've just mentioned, there are real issues with IO bank clocking region restrictions, and other details that render even the FMC connect, Vita57 or not, incompatible with any "plug and play" scheme that I can think of. Then there's the issue of FPGA vendors making their newer devices, like UltraScale, with IO that isn't very general purpose. I do appreciate that Opal Kelly has invested in an attempt at it though. What I want is to be able to use the FPGA IO to its full capability, without having to make a complicated and expensive custom multi-layer add-on card. One doesn't need standard interfaces to accomplish that, just sensible board designs. This isn't the market space that Digilent wants to be in, though they do have boards with FMC and SYZYGY connectors. While it doesn't necessarily service my needs it is something.

All of this might be moot anyway. For the kinds of things that I want to do I find myself using older devices like Cyclone IV, Cyclone V, Series 7 and when I look into my crystal ball I don't see these existing in the future. What I do see is very expensive, overly complex devices with some programmable logic and tools that are having a hard time keeping up with the changes. I'm not saying that the new stuff isn't exciting or useful for anything.. it just isn't programmable logic ideally suitable for the traditional kinds of problems that programmable logic was designed to address. I'm quite certain that there will be those traditional problems to solve for a long time to come, I just wonder if there will be the availability of suitable devices. A lot of concepts, like JIT, are great when everything is normal, but a real pestilence when the world is in turmoil. Having just two vendors control 90% of a market has unfortunate consequences, even in good times. It's worth thinking about; well, I think about it a lot as I go about my normal business. In electronics, sporadic and seismic change is the only constant. Edited May 20, 2022 by zygot

[gueste]

Thanks to all of you for trying to answer my question.
I'm still an entrant, relatively new on the topic, and therefore not experienced.
It's the first project I'm responsible for by myself.
Of course, now I know that it wasn't a good idea to develop the extension pod without the onboard µC. 

However, my problem is that that hardware has already been manufactured especially for the Eclypse Z7, and the only thing which doesn't work is switching on the VADJ power supply.
There's not much time left to finish the project, and therefore I cannot make extensive changes to the hardware.
So I'm desperately searching for a solution!

12 hours ago, artvvb said:

To add on to what zygot has already said, the override register also requires information from the DNA, and PMCU firmware does not allow values to be set which fall outside of the bounds specified by connected pods.

From the PMCU spec:

Thanks,

Arthur

Of course, I also read this part of the specification sheet. Does it mean that it's strictly not possible to activate the VIO power supply without having specified the min/max values for the port during system startup?

As already mentioned, I'm really grateful for any technical advice on getting this to work.

Thanks,

Steffen

[zygot]

14 hours ago, gueste said:

There's not much time left to finish the project, and therefore I cannot make extensive changes to the hardware.

Yeah, there's the hard way to learn about good processes and the really painful way.... I feel for you.

I've been doing electronics design for a really long time and am well aware of the penalties of poor planning; still I manage, on a rare occasion, to shoot myself in the foot. I have been around long enough to know not to panic and always anticipate unexpected issues.

What I'd do is stop trying to forge ahead and think up a work-around to the missing DNA interface. One time honored way to add circuitry to a completed PCB is the dead bug approach; so called because it involves gluing an IC onto a substrate upside down and hand wiring the pins to the IO connector. This may or may not be feasible, depending on your board layout, soldering skills, and the quality of your tools. The one thing in your favor is that the serial interface only involves two wires and is low frequency. If that isn't possible I'd certainly consider hooking up the SDA/SCL pins to another device that can do the basic DNA communication, like an FPGA or uC board. If you opted out of the DNA interface you probably also didn't implement the R_GA pin either, which is a necessity.. so you'll have to add that as well. Depending on how the environment in which your custom SYZYGY pod will be used neither of these approaches might be suitable. Depending on what your SYZYGY pod does and how it uses the interface it might be possible to purchase a standard SYZYGY breakout prototyping board from Opal Kelly and use that as an intermediary between your pod and the carrier board... just throwing out ideas to consider and get you thinking positively. The last resort might be to reprogram the PMCU on the Eclypse-Z7 to hard code the Vio on one of the ports without doing the DNA interchange. Risky, but perhaps not as much as utterly failing. Obviously, you're on your own in terms of accepting the consequences for any action that you might take. So, I don't know if the is a student project, a personal project, or your first professional experience, so I'll avoid the temptation of giving the "mentor" kind of encouragement and advice.

Sometimes you can get stuck in a situation where there are no good options... it really doesn't matter how you got there as long as you learn from the experience. Personally, in such a situation I'd go down swinging until the end while trying to find a way around the impasse. I wouldn't be waiting around hoping that a Digilent engineer throws me a life-line.

If nothing better comes of this adventure at least you know well that assumptions can be deadly, even for experienced people. You tried to design a board without understanding the interface specification and you assumed that there would be a way to manually set a port Vio voltage when you had the opportunity to verify that assumption with the Eclypse-Z7 at hand before committing to releasing your board design to manufacturing. Hard lessons to be sure, but I bet that you won't repeat them any time soon...

 

Edited May 20, 2022 by zygot