[hpsdr] Atlas Update - From whence we have come

[Lyle Johnson]

> There are still a number of basic questions unanswered, things like, but 
> not limited to:
> What are the form factors for the plug-in cards?

100mm x 100mm

> What are the specifics of the ATLAS bus (some of it is written down, but 
> there are a bunch of blanks)?

It is a simple, passive backplane.  Some characterization has been done. 
  It is *not* designed for "high speed" signals.  it does support 
daisy-chaining of JTAG, SPI and as yet unspecified signals.

> Is a 10MHz or a 1pps reference signal going to be supported? If so, it 
> it going to be distributed over the backplane?

This depends on the applications cards that are developed over time. 
Certainly, a line can be suggested for one or both signals.  Janus and 
Ozy are using FPGAs or CPLDs to allow reconfiguration of backplane 
signal definitions so we can be agile as things develop.

> Are the JTAG connectors going to be put in a common location on the top 
> of each plug-in card?

No.  At least, that is not practical with Janus as it has so many I/O 
connectors there.  The intent is that Ozy, or some other master 
controller, has the ability to control the JTAG chain, and the JTAG is 
daisy-chained through the various option cards.  For development, it may 
be useful to use a JTAG programmer/emulator/etc.  An extender card may 
be required for this.  For operation, Ozy will do the configuration, at 
least for USB-based systems.

> Does OZY have the throughput to handle both a MERCURY and a JANUS board 
> operating at the same time?

Don't know.  What throughput is required?  JANUS can be set up to as 
little as 2 channels of 48 kHz data at 16 bits, or as much as 4 channels 
of 192 kHz/24 bit data plus 4 channels of 96 kHz, 24 bit data.  And you 
could have more than one JANUS card in a backplane.

MERCURY will downsample in its own FPGA, not unlike the SDR-14 from rfspace.

> What the project need is some design documentation, so that folks who 
> want to design a circuit know how to integrate it in. I'd be tickled 
> pink with some block diagrams!

Keep in mind that each card is being designed for the purposes its 
designer envisions.  There is bound to be disagreement on what features, 
functions, etc. that a given card may have.  But, as an open source 
project, just as a user can recompile the code to suit his personal 
preferences, so can a user re-design a given card.  And most cards in 
the development queue at present have CPLD or FPGA logic on board, so 
the hardware itself can be redefined and reconfigured within limits by 
any user who wishes to do so.

> So, yes, I would hold my order until the group has a baselined design 
> for JANUS, OZY and ATLAS. JANUS is going through a redesign currently! 
> If I have to I'll run a set of boards myself.

True.  And Sasquatch is in preliminary design as well.  I'd like to see 
a run of ATLAS simply because there are at present only 3 ATLAS boards, 
and more than three people already need them.  The boards have been 
characterized, and the information intended to be derived from the Alpha 
stage has been gathered.  It is low risk to get ATLAS in the pipeline 
now, with a slow turnaround to keep costs down.  And give folks a chance 
to start building something :-)

If we have ATLAS, then JANUS can be further verified at the Alpha level, 
and a Xylo board patched onto the ATLAS backplane to simulate Ozy.  Ozy 
can then be bootstrapped on th ATLAS + JANUS platform.

If we wait for ATLAS, then Xylo is patched to Janus, but the benefit of 
characterizing JANUS with ATLAS is lost.

Also, once we have a number of ATLAS built, the designers of the cards 
that plug in will have a certain level of confidence that ATLAS is "cast 
in stone" rather than still being a soft target with some uncertainty 
associated with it.

The risk here is certainly low if we wait for ATLAS. On the other hand, 
the risk is also low if we go ahead with ATLAS.

> I am more than happy to work on documentation, but it's going to take 
> lots of questions and the corresponding answers.
> A valid answer to a question can be "we don't know yet".

The above are just my personal observations/opinions/impressions, and 
not necessarily factual or even minimally accurate...

73,

Lyle KK7P


 1147152777.0