<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
Brian Mason wrote:<br>
<blockquote type="cite"
cite="midPine.LNX.4.44.0402121934080.6813-100000@mimas">
<pre wrap="">I'm also thinking mostly about normal operations. Note that #3
(selectable control) need not necessarily be done via software. We
shouldn't be doing that very often.
Brian
On Thu, 12 Feb 2004, Martin Shepherd wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 11 Feb 2004, Brian Mason wrote:
</pre>
<blockquote type="cite">
<pre wrap="">... I believe the two most significant changes to the CCB software
interface resulting from the faster ADC sampling, as Tim & I
corresponded about around 13aug03, are a) samp_per_state now must
support larger values; & b) there is no analog blanking dt.
</pre>
</blockquote>
<pre wrap="">It's a bit too early to say yet, since I am still at the earliest
stages of getting to grips with the FPGA programming, but I can think
of at least a couple of additions.
1. An extra parameter specifying the round-trip delay between the FPGA
toggling a phase-switch or cal-diode control line, and the arrival
from the ADC of the first sample that is affected by this. This will
include the propagation delay through the opto-isolators and other
electronics, plus the pipeline delay in the ADC and probably also
the pipe delay in the FPGA.
2. All of the parameters needed to control the new dump mode. I am too
bogged down in trying to figure out how to program the FPGA(s) to
handle the normal operating mode to think about this yet.
3. If we are really going to have 4 FPGAs, and Randy's idea of being
able to have warm backups by being able select which of the FPGAs
controls the cal-diode and phase-switch control lines, then there
will also need to be a parameter selecting which board does this.
Similarly the returned error codes etc, presumably will need to
include extra parameters identifying the originating board(s).
Martin
_______________________________________________
gb-ccb mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:gb-ccb@listmgr.cv.nrao.edu">gb-ccb@listmgr.cv.nrao.edu</a>
<a class="moz-txt-link-freetext"
href="http://listmgr.cv.nrao.edu/mailman/listinfo/gb-ccb">http://listmgr.cv.nrao.edu/mailman/listinfo/gb-ccb</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
All,<br>
<br>
I agree with Brian's statement regarding the very infrequent use of <br>
my newly proposed "warm backup" functionality for the various <br>
control lines. This concept actually derives <u>only secondarily</u>
from <br>
the advent of having four identical "Frequency Channel" modules<br>
and should only come into play in the (hopefully!) rare case of<br>
a suspected hardware failure. This, in turn, implies that it might <br>
more appropriately be viewed as an "off-line" event and, as such,<br>
could be handled either through the configuration DIP SWITCHES<br>
found in each module or, alternatively, through use of the instrument's
<br>
diagnostics (RS-232) port. <br>
<br>
Or...<br>
<br>
In order to keep things utterly simple, we could permanently enable<br>
the output drivers in all four modules, operate all four simultaneously<br>
in a parallel fashion, and simply plug the corresponding field connector<br>
into which ever module we'd like to use. In the event of a suspected<br>
failure, we could then just move the field connector to another module,<br>
flag the suspected offender for future replacement, and reestablish the<br>
instrument's full functionality with minimal downtime... <br>
<br>
Randy<br>
<br>
</body>
</html>