tr-pmc issueshttps://ohwr.org/project/tr-pmc/issues2019-02-12T11:41:03Zhttps://ohwr.org/project/tr-pmc/issues/1REVB production: mounting of some components does not look as expected.2019-02-12T11:41:03ZDietrich BeckREVB production: mounting of some components does not look as expected.On REVB, some components don't look as expected.
\- USB Connector USBCon1, Connectors DIS1 and HPLA1, and even the SFP
cage are misaligned with respect to the PCB edges. This is not expected.
Just guessing: Either imprecise mounting of components or drifting of
components during the soldering process (see attached image).
\- The soldering of the connector AUXPOW1 does not look pretty (see
attached image).
Maybe just aesthetics? Please check\!
### Files
* [pmcREVB_tiltedComponents.jpg](/uploads/30cce25b2c468c1c4abdc3d37c2f35b9/pmcREVB_tiltedComponents.jpg)
* [pmcREVB_powerConnector.jpg](/uploads/5e64ddc1ba0e3302da41a1288228a159/pmcREVB_powerConnector.jpg)Dusan SlavinecDusan Slavinechttps://ohwr.org/project/tr-pmc/issues/2REVB mechanics: USB connectors JTAGCON1 und USBCON12019-02-12T11:41:04ZDietrich BeckREVB mechanics: USB connectors JTAGCON1 und USBCON1The USB connectors stick too far outside the PCB and prevent mounting of
the board in case of a neighbouring board: As an example, mounting was
impossible on a VME CES RIO2 CPU (see attached image).
### Files
* [pmcREVB_mechanicsUSB.jpg](/uploads/ade5b8f9e15101620fbdda7062b4d1d8/pmcREVB_mechanicsUSB.jpg)Dusan SlavinecDusan Slavinechttps://ohwr.org/project/tr-pmc/issues/3Implementation of JTAG on PMC2019-02-12T11:41:04ZDietrich BeckImplementation of JTAG on PMCThere is a proposal for modifying JTAG connections on the PMC:
(see attachment)
Modifications would be to just connect JTAG chain signals to PMC
connectors via 0R resistors.
This means that JTAG chain can be connected to PMC JTAG pins if needed.
By default it is connected only to micro USB connector.
### Files
* [hbhpfdikgobipghh.png](/uploads/b2fc5944d282057d6b93f7db1efeff36/hbhpfdikgobipghh.png)
* [1510920026148-0.png](/uploads/095a625ec61575f612301acf102897c0/1510920026148-0.png)Dusan SlavinecDusan Slavinechttps://ohwr.org/project/tr-pmc/issues/4PMC Supply Voltage 3.3V AND 5V2019-02-12T11:41:05ZDietrich BeckPMC Supply Voltage 3.3V AND 5VRequirement from Specs (TR\_6040): Power – The PMC mezzanine must
support the two supply voltages 3.3V and 5V.
This requirement is not quite clear what is referring to. One
interpretation was that this is referring to the PCI signal levels and
not actual powering of the board since 3.3V rail on the FTRN is
generated from whatever is on the input of the LTM4619 power converter.
Carriers with 5V PCI signals these day are practically extinct. We could
not find PC in house that would have motherboard with 5V signaling on
PCI pins.
Question is if this requirement is still relevant? Can we drop it?
### Files
* [pmcREVB_hostBus5V.jpg](/uploads/5206f3a92fc569d759db63b81990bf28/pmcREVB_hostBus5V.jpg)Dusan SlavinecDusan Slavinechttps://ohwr.org/project/tr-pmc/issues/5PCI pins pullued up during FPGA boot2019-02-12T11:41:06ZDusan SlavinecPCI pins pullued up during FPGA bootDuring schematic and PCB review of the REVB, Piotr spotted a bug:
"I checked only schematic and I have found one thing that might be
risky.
PMC/pcie is not disconnected during FPGA boot.
It may lead to unpredictable state. In worst case CPU will be not able
to finish POST (just like in the past).
This is just my guess so if they are 110% sure it might be left as it
is."
As a reference for PCI connections between FPGA and PCI/PMC connectors
the schematic \[1\] from Altera was used but with a different FPGA
(Stratix).
After rechecking the \[1\] schematic, Stratix and ArriaV datasheets I
found following:
Comparing Stratix and Arria V datasheets there is difference between
them during boot, before FPGA enters user mode:
\- Stratix has IO output drivers disabled, but internal pull-ups can be
enabled OR disabled, in case of \[1\], they are disabled
\- Arria V GX has IO output drivers disabled, but internal pull-up are
ENABLED
\- on the REVB schematic bus switches are enabled, therefore PCI lines
would be pulled-up by internal FPGA pull-ups during ArriaV boot,
effectively driving PCI bus signals and this might cause issues that
Piotr mentioned
Therefore schematic needs to be changed to be on the safe side:
\- pull-up added to bus switch enable pins, disabling them on power-up,
before FPGA enters user mode
\- FPGA enables bus switches by pulling low bus switch enable pins when
it enters user mode (and also disables internal pull-ups)
Schematic is already fixed I am waiting on the PCB to be changed.
\[1\]
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ds/ds_stratix_pci_bd.pdf
### Files
* [FTRN_Stratix_vs_ArriaV_boot_pull-up.pdf](/uploads/a78de539c3dc3642d895f5b7e68106a3/FTRN_Stratix_vs_ArriaV_boot_pull-up.pdf)
* [FTRN_PMC_REVB_PCI_bus_switch_enable_fix.JPG](/uploads/d70d126022f313bb6778d964350c762c/FTRN_PMC_REVB_PCI_bus_switch_enable_fix.JPG)Dusan SlavinecDusan Slavinechttps://ohwr.org/project/tr-pmc/issues/6Replace LTM4620 DC-DC converters with LTM46192019-02-12T11:41:07ZRok TavčarReplace LTM4620 DC-DC converters with LTM4619After detailed measurements on FTRN's power rails and estimates of
maximum current consumption on the PMC prototype, we decided to replace
the LTM4620 DC-DC converters with LTM4619.
Also after taking into account the design differences between PMC, AMC
and VME, we intend to replace LTM4620 with LTM4620 on all three FTRN
form factors.
In discussions with GSI so far, there were no objections to such
change.
@Dietrich, please acknowledge the change, we can Skype if you need more
deails.
Here are our reasons, explanation and measurements, perhaps it's
interesting also for your designs:
Reasons:
\- when running all IOs at 200Mhz, WR lock, etc on PMC, we are near
maximum power consumption, prescribed by the PMC standard (7.5W).
\- by replacing the switchers, we will conserve 1.4W power, because
LTM4619 has substantially lower power dissipation in idle state than
LTM4620 (0.5W on 4619 vs. 1.9W on 4620)
\- also, we'd like to lower the heat dissipation on the board
\- LTM4619 is a safe choice, because even if we estimate 200% margin
over measurements with current FPGA design, the consumption would not
exceed 55% of LTM4619 capacity (see
FTRN\_PMC\_current\_consumption\_by\_voltage\_rail\_measurement.docx)
\- in FTRN conditions, LTM4620 operates in very low efficiency, being
designed for 13A but using \<1A.
Attached are more details about measurements and conclusions:
FTRN\_PMC\_current\_consumption\_by\_voltage\_rail\_measurement.pdf
### Files
* [FTRN_PMC_current_consumption_by_voltage_rail_measurement.pdf](/uploads/971dd36f6fbe6acf1cc2da93aea7d98c/FTRN_PMC_current_consumption_by_voltage_rail_measurement.pdf)
* [PMCLTM4620PerformanceMeasurement.pdf](/uploads/d829e0a82576d551535703748c1cf529/PMCLTM4620PerformanceMeasurement.pdf)
* [FTRN_PMC_LTM420_vs_4628_efficiency_table.JPG](/uploads/7840af19b3c978495b1a84f7e15af800/FTRN_PMC_LTM420_vs_4628_efficiency_table.JPG)
* [FTRN_PMCB_total_power_measurement_under_load.PNG](/uploads/247dd5b406896457c53574a514773cfc/FTRN_PMCB_total_power_measurement_under_load.PNG)https://ohwr.org/project/tr-pmc/issues/7IO CLK hangs?2019-02-12T11:41:09ZPiotr MiedzikIO CLK hangs?It seems that wb\_serdes\_clk\_gen hangs under some conditions (hi=1ns
lo=2ns).
Output is generated only on output
1
for i in 1 2 3 4 5 ; do eb-clock -c ${i} -H 1 -L 2 dev/ttyUSB0; done
/ttyUSB0; done
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x1
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x1
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x1
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x1
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x1
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
![](/uploads/d10e90dd4f0e3486a9b4abd59e48f3a6/160324_130843.png)
If I set in folowed way:
- hi=1ns
- lo=2ns
I see picks with 1ns and 2ns width and clock generation not
hang.
for i in 1 2 3 4 5 ; do eb-clock -c ${i} -H 2 -L 1 dev/ttyUSB0; done
/ttyUSB0; done
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x2
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x2
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x2
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x2
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
IOHACK+4: 1f
IOHACK+4 modify: 1f
wide_period = 9.000000
period_integer = 0x9
period_high = 0x2
period_fraction = 0x0
phase_offset = 0x0
bit_pattern_norm = 0010010010010010
bit_pattern_skip = 0010010001001001
![](/uploads/d6de051004c6d9a014c2b98e5a45d1b8/160324_131123.png)
Similar behavior observed on Exploder5a which means there is rather HDL.
### Files
* [160324_130843.png](/uploads/d10e90dd4f0e3486a9b4abd59e48f3a6/160324_130843.png)
* [160324_131123.png](/uploads/d6de051004c6d9a014c2b98e5a45d1b8/160324_131123.png)https://ohwr.org/project/tr-pmc/issues/8IO random peaks2019-02-12T11:41:11ZPiotr MiedzikIO random peaksSN: 89283
[root@sddsc045 scripts]# eb-info dev/ttyUSB0
Project : pci_pmc
Platform : pmc
FPGA model : Arria V (5AGXMA3D4F27I3)
Build type : developer preview
Build date : Fri Jan 15 16:13:49 CET 2016
Prepared by : A. Hahn <a.hahn@gsi.de>
Perpared on : dell-precision-t3610
OS version : Ubuntu 14.04.3 LTS, kernel 3.13.0-74-generic
Quartus : Version 13.1.0 Build 162 10/23/2013 SJ Full Version
bc431ba pmc: changed general-cores ptr
5f7a3ef pmc: set IO_STANDARD LVDS for IO1..5
b77e640 pmc: added modules
0381680 pmc: pci-core pointer
a9c284a pmc: added pci-core submodule
for i in 1 2 3 4 5 ; do eb-clock -c ${i} -H 20 -L 20 dev/ttyUSB0; done
![](/uploads/9f08a50562fef84bfa5cc369d780ab4b/pmc1-160324_104128.png)
### Files
* [pmc1-160324_104128.png](/uploads/9f08a50562fef84bfa5cc369d780ab4b/pmc1-160324_104128.png)https://ohwr.org/project/tr-pmc/issues/9IO activity leds2019-02-12T11:41:12ZA. HahnIO activity ledsI observed the following behavior:
When I drive an IO (i.e. with the Clock Generator) and connect the
IO/LEMO to a scope, then the activity LED stops blinking/indicating
activity.
Did you noticed that too?A. HahnA. Hahnhttps://ohwr.org/project/tr-pmc/issues/10IO output duty cycle unstable on PMC S/N: 892852019-02-12T11:41:14ZRok TavčarIO output duty cycle unstable on PMC S/N: 89285All prototypes pass our IO test except S/N 89285 (see Test Plan and Test
report, \[1\]).
Have you experienced this IO behaviour before with any of your boards?
Details:
1\. Duty cycle/period on IO not stable at certain settings, example:
\- 200MHz clock, 60% duty cycle, eb-clock -c X -H 3 -L2 dev/ttyUSB0
Image attached (IMG1).
2\. Same settings zoomed out, trigger on rising edge, it seems to be
correlated with 40ns period (25MHz)
Image attached (IMG2)
Comment to IMG2: on the screenshot there are 3 rising edges that are
aligned on every trigger, they are divided by 40ns (third from the left,
middle one, second from the right)
\[1\]
https://www.ohwr.org/project/tr-pmc/commits/master/PMC_REVA/Test/FTRN-PMC_Test_Report.xls
### Files
* [89285_-_200mhz_clk_-_ch2_-_5.png](/uploads/a63216e8520a562bd8a9936934dd8b19/89285_-_200mhz_clk_-_ch2_-_5.png)
* [89285_-_200mhz_clk_-_powercycle2_-_ch1_-_2.png](/uploads/d03eca8da9cd0a1d7112d987f8090dc5/89285_-_200mhz_clk_-_powercycle2_-_ch1_-_2.png)https://ohwr.org/project/tr-pmc/issues/11placement of usb connectors2019-02-12T11:41:16ZDietrich Beckplacement of usb connectorswould it be possible to move the micro-usb connectors (usb + jtag) to
\- the other long edge of the board *and*
\- to the other side of the board (not the FPGA side)
this would ease debugging when the board is mounted in a host systemDietrich BeckDietrich Beckhttps://ohwr.org/project/tr-pmc/issues/12placement of jtag and debug headers2019-02-12T11:41:17ZDietrich Beckplacement of jtag and debug headerswould it be possible to move the jtag and debug headers to the other
side of the board (not the FPGA side?). This would ease debugging when
the board is operated in a host system.
### Files
* [616qev8o.bmp](/uploads/723a0d569d082726f192305de927974d/616qev8o.bmp)Piotr MiedzikPiotr Miedzikhttps://ohwr.org/project/tr-pmc/issues/13type of buffers / bus switches2019-02-12T11:41:19ZDietrich Becktype of buffers / bus switches(reported by Piotr Miedzik)
I haven't found any PMC carrier without 3.3V I/O support. I checked
followed devices:
\- PC motherboards have only 3.3v PCI slots
\- VME CPU (including RIO)
\- PCI-PMC carrier (depends on motherboard)
\- PCIe-PMC carrier
\- uTCA-PMC carrier
FPGA may have 3.3 volt banks with PCI compatible clamping diodes.
Maybe buffers are not necessarily anyway.
Buffers like SN74LVC8T245 should be considered anyway if someone will
find 5V only pmc carrier.
### Files
* [CSL-FAIR_FTRN-PMC_PCI_Technical_Concept_PCI_Bus_switch.pdf](/uploads/d81b6eca811555d6960bdc55253c0dfb/CSL-FAIR_FTRN-PMC_PCI_Technical_Concept_PCI_Bus_switch.pdf)
* [CSL-FAIR_FTRN-PMC_PCI_Technical_Concept_PCI_Bus_switch_1_0.pdf](/uploads/58aff31ec1ae0cabae406e3046d6f06f/CSL-FAIR_FTRN-PMC_PCI_Technical_Concept_PCI_Bus_switch_1_0.pdf)
* [CSL-FAIR_FTRN-PMC_PCI_Technical_Concept_PCI_Bus_switch_1_1.pdf](/uploads/dbe7531b4b1f4cc9bf2eef54c924bf92/CSL-FAIR_FTRN-PMC_PCI_Technical_Concept_PCI_Bus_switch_1_1.pdf)Dietrich BeckDietrich Beckhttps://ohwr.org/project/tr-pmc/issues/14biderectional buffers inappropriate2019-02-12T11:41:20ZDietrich Beckbiderectional buffers inappropriate(reported by Piotr Miedzik)
txb0108: This bidirectional buffers with direction autosensing are
inappropriate for this kind of application. Lack of direction control
will not work properly in pci environment.
Txb010x changes direction by detecting rising/falling edge. It's
independent for each channel. It might happen that one pin will change
direction without any particular reason (gravity waves?)Dusan SlavinecDusan Slavinechttps://ohwr.org/project/tr-pmc/issues/15PCI Output signals does not meet Timing Parameters2019-02-12T11:41:21ZPiotr MiedzikPCI Output signals does not meet Timing ParametersPCI Output signals does not meet Timing Parameters
maximum CLK to Signal Valid Delay: 11ns
measured CLK to Signal Valid Delay:
20ns
![](/uploads/2e70013d6d356f90368fffc450591aad/160218_172708.png)
### Files
* [160218_172708.png](/uploads/2e70013d6d356f90368fffc450591aad/160218_172708.png)Piotr MiedzikPiotr Miedzikhttps://ohwr.org/project/tr-pmc/issues/16PCI bridge randomly does not response to master2019-02-12T11:41:22ZPiotr MiedzikPCI bridge randomly does not response to masterPCI bridge randomly does not response to master.
You may see the trace on attached picture
![](/uploads/8ef7cbdb877601c1baf2976912f33960/160218_160507.png)
[root@sdlx008 ~]# lspci -s 5:04 -x
05:04.0 Bridge: CERN/ECP/EDU Device c570 (rev dc)
00: dc 10 70 c5 ff ff ff ff dc 10 70 c5 ff ff ff ff
10: 00 00 00 71 00 00 00 f1 00 00 00 70 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 dc 10 ef be
30: 00 00 00 00 50 00 00 00 00 00 00 00 00 01 08 1a
### Files
* [160218_160507.png](/uploads/8ef7cbdb877601c1baf2976912f33960/160218_160507.png)
* [pmc_pci_151020_1228_AcromagCarr_PCI2slot_zo_lspci_IDSEL_oscilating_IRDY_lo_rk.JPG](/uploads/3400d86d0e4bda42b8c326fcdbf8baf6/pmc_pci_151020_1228_AcromagCarr_PCI2slot_zo_lspci_IDSEL_oscilating_IRDY_lo_rk.JPG)
* [160219_122848.png](/uploads/c615fce27a6b43fbb46cdd1ba2e255db/160219_122848.png)
* [160219_123006.png](/uploads/e81d9c0a89c969ecd335c1bffcc963de/160219_123006.png)
* [160219_123032.png](/uploads/6d38035d4d95ba34e36752b0e5691e96/160219_123032.png)
* [160219_124105.png](/uploads/a3ded69b2ed074b15f3a1366176aaa00/160219_124105.png)
* [160219_124247.png](/uploads/e7ac39e6d04c00bc870f9c3754a0ea3c/160219_124247.png)
* [160219_124523.png](/uploads/64d20a525cbd24d8f6a3c9b1218896bc/160219_124523.png)Piotr MiedzikPiotr Miedzikhttps://ohwr.org/project/tr-pmc/issues/17errors when initializing BAR 02019-02-12T11:41:24ZPiotr Miedzikerrors when initializing BAR 0[root@sdlx008 ~]# lspci -vv -s 5:0
05:00.0 Bridge: CERN/ECP/EDU Device c570 (rev 01)
Subsystem: CERN/ECP/EDU Device beef
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx-
Interrupt: pin A routed to IRQ 0
Region 0: Memory at f4000000 (32-bit, non-prefetchable) [disabled] [size=8K]
Region 1: Memory at f4002000 (32-bit, non-prefetchable) [disabled] [size=4K]
Region 2: Memory at f0000000 (32-bit, non-prefetchable) [disabled] [size=64M]
Expansion ROM at <ignored> [disabled by cmd]
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
[root@sdlx008 ~]# dmesg | grep 5:0
pci 0000:05:00.0: reg 10: [mem 0x00000000-0x00001fff]
pci 0000:05:00.0: reg 14: [mem 0x00000000-0x00000fff]
pci 0000:05:00.0: reg 18: [mem 0x00000000-0x03ffffff]
pci 0000:05:00.0: BAR 2: assigned [mem 0xf0000000-0xf3ffffff]
pci 0000:05:00.0: BAR 2: set to [mem 0xf0000000-0xf3ffffff] (PCI address [0xf0000000-0xf3ffffff]
pci 0000:05:00.0: BAR 0: assigned [mem 0xf4000000-0xf4001fff]
pci 0000:05:00.0: BAR 0: error updating (0xf4000000 != 0xffffffff)
pci 0000:05:00.0: BAR 0: set to [mem 0xf4000000-0xf4001fff] (PCI address [0xf4000000-0xf4001fff]
pci 0000:05:00.0: BAR 1: assigned [mem 0xf4002000-0xf4002fff]
pci 0000:05:00.0: BAR 1: set to [mem 0xf4002000-0xf4002fff] (PCI address [0xf4002000-0xf4002fff]Piotr MiedzikPiotr Miedzikhttps://ohwr.org/project/tr-pmc/issues/18FTRN PMC LED luminosity2019-02-12T11:41:26ZRok TavčarFTRN PMC LED luminosity1\. Front panel: Luminosity OK
2\. Non-front panel LEDs: upon request from GSI, luminosity can be
lowered by changing resistor values.
Rok: to minimize iterations between us, I propose that CSCO specifies
new values.
If CSCO deem no change is necessary, this issue can be closed.https://ohwr.org/project/tr-pmc/issues/19AUX power connector placement2019-02-12T11:41:27ZRok TavčarAUX power connector placement@Cesar, just to verify: our assumption is, that we should keep the
connector size for consistency with other FFs. Am I right or do you use
smaller AUX power connectors anywhere that you actually prefer?
AUXPOW1 power connector (part number KLDX-SMT-0201L-B) is placed on
PMCP4 connector' location, so there's a cca 1mm mechanical conflict when
carrier has PMCP4.
Proposed solutions are:
a) replacement with lower element (preferred), or
b) current one needs to be mounted similarly as HEX switches or
c) it needs to be moved to other location where it does not interfere
with carrier PMC connectors (P3, P4)https://ohwr.org/project/tr-pmc/issues/20BUSMODE Signals2019-02-12T11:41:28ZPiotr MiedzikBUSMODE SignalsFor PMC standard compatibility all BUSMODE\[4:1\]\# signals should be
connected to CPLD via separate buffer.
BUSMODE1\# may be pulled down via 1k Ohm resistance.Piotr MiedzikPiotr Miedzik