System Specification bare bones

About Forums Omega-Design System Specification bare bones

This topic contains 2 replies, has 2 voices, and was last updated by  admin 11 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #255

    admin
    Keymaster

    I’ve uploaded a bare-bones copy of the system specification as it stands right now. I’m in the middle of various bits of design, so I’ll keep updating the spec as I find issues that need detailing.

    System specification

    #256

    macaba
    Participant

    Current:
    Req2.4.3 The backplane PCB size shall be 300mm long by 100mm wide

    Suggestion:
    Req2.4.3 The backplane PCB size shall be 426.72mm long by 128.7mm wide

    Discussion:
    Self explainatory. PCB pricing was checked and full length backplane deemed viable.

    Current:
    Req2.4.6 There shall be a “missing slot space” between slot 0 and where slot 1 would be located to enforce the special nature and extra size of the slot zero control card feature. Slot 1 shall start at a horizontal spacing of 8HP.

    Suggestion:
    Req2.4.6 There shall be a ‘key’ on slot 0 which shall prevent non-control cards being fully inserted. The next available slot [slot 1] shall start at a horizontal spacing of 8HP.

    Discussion:
    Slot 0 card is 8HP. The next slot connector is at the 8HP point, leaving 76HP [19 instrument slots at 4HP].

    Current:
    Req2.5.1 PCB size shall be 3U-160 or 100 mm x 160 mm

    Suggestion:
    Req2.5.1 PCB size shall be a 3U-160 or 100 mm x 160 mm with slight tolerance allowable as per Req2.5.2.

    Discussion:
    Self explanatory. It seems obvious but I’d prefer explicit statement to prevent bike-shedding later.

    Current:
    Req2.7.1 CORE Daughtercard to be rear mounted on the function card

    Suggestion:
    Req2.7.1 CORE Daughterboard must be mounted close to the card-to-backplane connection [within the rear 50% area] and on the top layer.

    Discussion:
    Probably a contentious point – I think the daughterboard should be mounted on the Top PCB layer.

    Additional discussion:
    [A] You mention a ‘ping-pong’ timing loop. I have to wonder if the easiest way to do this would be to have both a 10MHz clock and a 1PPS clock. Cards would align a local oscillator to the 10MHz clock, and use the 1PPS clock to get the 1 second boundary. As soon as a 1PPS pulse is sent, the master could send a ISO 8601 datetime string to the card so the card would know which second it is in, NTP would also satisfy this role. Part of me really wants IEE1588V2 but also recognises that a backplane is hardly a wide-area network as we’ve got plenty of dedicated timing lines available to us. It could be justified if we wanted the ability to have chassis-to-chassis sync, so my suggestion is just to make sure that all the PHY/MACs have a hardware timestamping peripheral for future-proofing.

    [B] “Card-to- card 100BaseTX Ethernet connection per card” – do you mean each card is connected to a switch IC on the backplane? Thus allowing peer-to-peer through a switch. The Digital Interconnect functionality will allow for true ‘direct’ peer-to-peer UART operation if needed.

    #257

    admin
    Keymaster

    Updates merged. I’m holding off on Req2.7.1 until I’ve thought about it some more.

    [A] Regarding timing sync: I’ve not looked at how ping pong would work in our system yet, so let’s hold back a while.
    I agree, NTP would be a way to go for in-system. IEE1588v2 is too heavy weight for card to card, and inaccurate. This could be a control card feature for chassis-to-chassis and sync to other equipment,

    [B] I intend there to be an Ethernet switch on the backplane (as well as a USB hub) for card-to-card. Direct digital interconnect via uart or higher speed links are also viable with the digital interconnect. This would be simplest option for low speed data and clocks/sync from card to card.

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.