From bmason at gb.nrao.edu Tue Jan 4 13:30:25 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Tue, 4 Jan 2005 13:30:25 -0500 (EST) Subject: [Gb-ccb] telecon Wed 4pm Message-ID: hi all- we agreed back before christmas to have a telecon tommorrow (Wed jan 5th) at 4pm eastern time-- does this still work for everyone? I will assume so and reserve a room unless I hear otherwise. Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From bmason at gb.nrao.edu Wed Jan 5 10:44:16 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Wed, 5 Jan 2005 10:44:16 -0500 (EST) Subject: [Gb-ccb] CCB hardware schedule Message-ID: Rich has made a pdf version of the GB CCB hardware schedule Gantt chart. I made an area on our wiki page for schedules http://wiki.gb.nrao.edu/bin/view/Projects/CcbDesignArea (very bottom of the page, in the table of attachments; I also put Caltech's software task list there) and posted it there. -Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From rlacasse at nrao.edu Thu Jan 6 11:54:48 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 06 Jan 2005 11:54:48 -0500 Subject: [Gb-ccb] Meeting minutes Message-ID: <41DD6D58.8020209@nrao.edu> All, Meeting minutes including action item summary are at http://wiki.gb.nrao.edu/bin/view/Projects/CcbDesignArea Please send any corrections to me. Thanks, Rich From jford at nrao.edu Mon Jan 10 14:54:06 2005 From: jford at nrao.edu (John Ford) Date: Mon, 10 Jan 2005 14:54:06 -0500 Subject: [Gb-ccb] shop work Message-ID: <200501101954.j0AJs6Xe031599@prospero.gb.nrao.edu> All, the shop's workload is ramping up, so we need to get our requests in ASAP, also for Jeff's time. The requests do not have to have completed drawings, just a part name and estimated work-hours. The drawings can come anytime prior to the begin date of the job. So far, March, April, and May have shop time avaiable, but as I say it is filling up pretty fast. John From bmason at gb.nrao.edu Tue Jan 11 16:07:39 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Tue, 11 Jan 2005 16:07:39 -0500 (EST) Subject: [Gb-ccb] telecon wed Message-ID: All- is our regular telecon time of Wed 4pm EST good for everyone tommorrow? Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From tjp at astro.caltech.edu Tue Jan 11 17:45:57 2005 From: tjp at astro.caltech.edu (Tim Pearson) Date: Tue, 11 Jan 2005 14:45:57 -0800 Subject: [Gb-ccb] telecon wed In-Reply-To: References: Message-ID: <8EF07622-6422-11D9-818A-000A959B4DC8@astro.caltech.edu> Dear Brian, I will be unable to participate - I'm at the AAS. But please go ahead without me. Tim On Jan 11, 2005, at 1:07 PM, Brian Mason wrote: > > All- is our regular telecon time of Wed 4pm EST good for everyone > tommorrow? > > Brian > -- From rlacasse at nrao.edu Wed Jan 12 07:57:26 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Wed, 12 Jan 2005 07:57:26 -0500 Subject: [Gb-ccb] telecon wed In-Reply-To: References: Message-ID: <41E51EB6.8050307@nrao.edu> Brian, Fine with me. Rich Brian Mason wrote: > All- is our regular telecon time of Wed 4pm EST good for everyone > tommorrow? > > Brian From rmccullo at nrao.edu Wed Jan 12 08:55:33 2005 From: rmccullo at nrao.edu (Randy McCullough) Date: Wed, 12 Jan 2005 08:55:33 -0500 Subject: [Gb-ccb] telecon wed In-Reply-To: References: Message-ID: <41E52C55.4030508@nrao.edu> Brian Mason wrote: >All- is our regular telecon time of Wed 4pm EST good for everyone >tommorrow? > > Brian > > Brian, OK with me... Randy From rlacasse at nrao.edu Thu Jan 13 10:15:55 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 13 Jan 2005 10:15:55 -0500 Subject: [Gb-ccb] meeting minutes available Message-ID: <41E690AB.4050501@nrao.edu> All, Minutes of yesterday's telecon are available at http://wiki.gb.nrao.edu/bin/view/Projects/CcbDesignArea Please e-mail corrections to me or edit them in yourself. Thanks, Rich From mcs at astro.caltech.edu Thu Jan 13 12:53:58 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Thu, 13 Jan 2005 09:53:58 -0800 (PST) Subject: [Gb-ccb] meeting minutes available In-Reply-To: <41E690AB.4050501@nrao.edu> References: <41E690AB.4050501@nrao.edu> Message-ID: On Thu, 13 Jan 2005, Richard Lacasse wrote: > Minutes of yesterday's telecon are available at > > http://wiki.gb.nrao.edu/bin/view/Projects/CcbDesignArea > > Please e-mail corrections to me or edit them in yourself. Thanks for writing up the minutes. Note that I've made a minor correction. Whereas the minutes said that I had entered most of the modules of the slave FPGA into the Xilinx software, and simulated said modules; what was actually reported in the meeting was that I had entered *all* of the modules of the slave FPGA into the Xilinx software, and had simulated most of them. Martin From bmason at gb.nrao.edu Tue Jan 18 10:11:51 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Tue, 18 Jan 2005 10:11:51 -0500 (EST) Subject: [Gb-ccb] ccb telecon Message-ID: Wednesday 4pm eastern time as usual? -Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From rmccullo at nrao.edu Tue Jan 18 10:20:27 2005 From: rmccullo at nrao.edu (Randy McCullough) Date: Tue, 18 Jan 2005 10:20:27 -0500 Subject: [Gb-ccb] ccb telecon In-Reply-To: References: Message-ID: <41ED293B.1050409@nrao.edu> Brian Mason wrote: >Wednesday 4pm eastern time as usual? > > -Brian > Brian, Works for me... Randy From rlacasse at nrao.edu Thu Jan 20 08:42:46 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 20 Jan 2005 08:42:46 -0500 Subject: [Gb-ccb] Telecon Notes Message-ID: <41EFB556.6010102@nrao.edu> All, Notes from yesterday's telecon are available at the usual place: http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes Please pass corrections on to me or edit them in yourself. Especially, please check the summary of action items; I neglected to go over it at the end of the meeting. Thanks, Rich From rlacasse at nrao.edu Thu Jan 20 16:23:00 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 20 Jan 2005 16:23:00 -0500 Subject: [Gb-ccb] Updated schedule Message-ID: <41F02134.7070301@nrao.edu> All, I've updated the GB CCB schedule per our recent progress. I've also figured out how to make a "baseline" schedule and have included in the attached. It's pretty neat: you can fairly easily discern the original schedule (gray), the new schedule (blue or red) and the critical path (red). The schedule is at: http://wiki.gb.nrao.edu/bin/view/Projects/CcbDesignArea#MyAnchor Click on projectschedule_rev3.pdf at the bottom of the page. Rich From mcs at astro.caltech.edu Thu Jan 20 21:47:42 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Thu, 20 Jan 2005 18:47:42 -0800 (PST) Subject: [Gb-ccb] Update to FPGA design documentation Message-ID: I have just placed version 8 of my CCB FPGA firmware documentation at: http://www.astro.caltech.edu/~mcs/GBT/ccb_fpga_design.pdf This version includes revisions to the documentation to reflect the changes that I made while entering and simulating the slave portion of the design. At the top-level of the design, the documented changes to the slave are as follows: 1. Xilinx's tri-state buffers have active-low drive-enable inputs, whereas I had assumed that they would be active-high. Along with updating their output-enable inputs to reflect this in the diagram, I replaced the logic that drove them with a single OR gate whose inputs are the active-low 'read' and 'select' inputs of the slave. Following this OR gate I added a NOT gate to drive the 'shift' inputs of the PISOs. 2. Since it turns out that the names, "read", "write" and "select" are reserved words in VHDL, I have renamed the active-low inputs that have these names to "nread", "nwrite" and "nselect". 3. I have inserted a tri-state buffer between the spare data(16) output pin and the internal ground that drives this signal onto the bus. This was the only output onto the data-bus that wasn't tri-stated. 4. I no longer pass a copy of the ADC clock to the Sampler components, since it makes more sense to latch the ADC samples into the Sampler using the global FPGA clock. Without this change we wouldn't be able to use the configurable phase-shift between the ADC and FPGA clocks to accomodate the readout timing requirements of the ADCs. Within the Signal Injector, I made the following change. The master FPGA tells both the Samplers and the Signal Injector to start a new integration by asserting the 'start' signal. The result is that the Samplers latch their first input sample on the same rising clock edge at which the Signal Injector is just starting to reset itself for the new integration. Thus, before my fix, the first sample of each new integration in test mode was whatever the Signal Injector happened to be generating when it was interrupted, rather than the repeatable number that would be needed for an accurate diagnostic. To fix this, I simply added a transparent MUX, which sets the output of the Signal Injector to the value (2^13 - 1) while the Signal Injector is being reset by the start signal. This number happens to be the terminal number in the random-number sequence, and usually precedes the Signal Injector output wrapping back to its initial value. The result is as though the sequence was started one number earlier in the circular sequence. Changes to the Accumulator components include the following: 1. In three places I had used bussed versions of AND and OR gates to implement what were essentially 2-port multiplexers with one port connected to values of either all-bits zero or all bits one. While there was nothing technically wrong with this, and this might have used fewer gates, I decided that clarity was more important than any minor saving in gates, and ended up using multiplexers. The circuit is thus easier to understand (at least for me) than before. 2. I have moved the job of blanking input ADC samples out of the Accumulator component. Again, this makes the Accumulator circuit easier to understand, and slightly reduces the overall complexity of the slaves. 3. The ADC overflow bit is now no longer a separately named input, but is instead simply the topmost bit of the sample input. Previously, the overflow bit and the sample were already combined like this in the Sampler, for the convenience of being able to pass them through a single shared MUX, but then they were split back into separate signals before being fed to the Integrators. Since they need to go through 2 more routing mutiplexers, it makes more sense to keep them together, until after the final one in the Accumulator. Again, this is a cosmetic change to make it easier to understand and modify the circuit. 4. The logic that determined when to load the overflow indicator into the output register of the accumulator was incorrect. The new implementation is completely different, and much simpler, partly because of the above change, and partly because the bug originally made things overly complicated. 5. Since the word "select" is a reserved word in VHDL, I had to change the name of the "select" input of the Accumulator module to "sel". The changes to the Integrator component were as follows: 1. As mentioned above, the overflow signal is now the topmost bit of the sample signal, so I have removed the 'overflow' input of the Integrator, and removed the signal lines that routed this to the 4 Accumulator modules. 2. Similarly, since blanking is no longer performed in the Accumulator components (nor in their parent Integrator component), I have removed the 'blank' input of the Integrator, and removed the signal lines that routed this to the 4 Accumulator modules. The changes the Sampler are as follows: 1. Blanking is now performed in the Sampler component. This takes the form of a 2-input multiplexer which replaces the input samples and their overflow bits with zero, whenever the 'blank' input is asserted. 2. The overflow bit is no longer split out from the sample before being presented to the Integrator component. 3. As mentioned previously, the ADC samples and overflow bits are now latched by the global FPGA clock, instead of the ADC clock. Martin From bmason at gb.nrao.edu Wed Jan 26 15:09:22 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Wed, 26 Jan 2005 15:09:22 -0500 (EST) Subject: [Gb-ccb] CCB Project Meeting Agenda Message-ID: A rough agenda follows. -Brian Thurs ----- 9am-noon thurs: Martin & Randy present the status of the design work review remaining parts/construction costs -- ethernet & power?? 1-3pm: devise/brainstorm acceptance tests -- 3-5pm: turn caltech's software to do list into a schedule review what software-- generally, and other than the FPGA-- needs to be written, by whom, and by when. Friday ------ 9-10am: Budget discussion (Phil, Tim, & Brian -- Phil's office) -- through noon-- any follow up discussions -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From bmason at gb.nrao.edu Wed Jan 26 15:11:51 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Wed, 26 Jan 2005 15:11:51 -0500 (EST) Subject: [Gb-ccb] CCB Project Meeting Agenda In-Reply-To: Message-ID: Note that I've reserved the auditorium for all of Thurs/Fri so we will meet there. -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From rlacasse at nrao.edu Fri Jan 28 15:51:14 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Fri, 28 Jan 2005 15:51:14 -0500 Subject: [Gb-ccb] Re: power inlet module PCB and schematic file In-Reply-To: <41FA95AE.5090904@nrao.edu> References: <41FA95AE.5090904@nrao.edu> Message-ID: <41FAA5C2.10002@nrao.edu> John, Looks good. You might consider increasing the clearance between traces, pads and ground fill. Ground fill between the pads of the 0805 devices has been a problem my boards before: the solder paste likes to sneak under there and short things out. Also soldering wires on the thru holes is tough with 0.010 clearance (likes to bridge) and a fair amount easier with 0.020 clearance. At least that's what Nathan has told me based on his experience with my boards. Rich John Ford wrote: > Here's the finished power inlet module PCB. Have a look and let me know > of any problems you see. > > John > From jford at nrao.edu Fri Jan 28 16:52:40 2005 From: jford at nrao.edu (John Ford) Date: Fri, 28 Jan 2005 16:52:40 -0500 Subject: [Gb-ccb] Re: power inlet module PCB and schematic file In-Reply-To: <41FAA5C2.10002@nrao.edu> References: <41FA95AE.5090904@nrao.edu> <41FAA5C2.10002@nrao.edu> Message-ID: <16890.46120.757433.532261@gargle.gargle.HOWL> OK. I'll open it up a bit. This board will have a solder mask, so it should be easy to solder it cleanly. Thanks for looking it over. John Richard Lacasse writes: > John, > > Looks good. > > You might consider increasing the clearance between traces, pads and ground fill. Ground > fill between the pads of the 0805 devices has been a problem my boards before: the solder > paste likes to sneak under there and short things out. Also soldering wires on the thru > holes is tough with 0.010 clearance (likes to bridge) and a fair amount easier with 0.020 > clearance. At least that's what Nathan has told me based on his experience with my boards. > > Rich > > John Ford wrote: > > > Here's the finished power inlet module PCB. Have a look and let me know > > of any problems you see. > > > > John > > From rlacasse at nrao.edu Mon Jan 31 11:16:26 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Mon, 31 Jan 2005 11:16:26 -0500 Subject: [Gb-ccb] New additions to CCB wiki pages Message-ID: <41FE59DA.5020701@nrao.edu> All, I've added the latest iteration of the CCB schedule, which includes both NRAO and CIT tasks, to the CCB wiki. Also, I've added and linked a new page to the CCB wiki which will document the parts budget. So far it includes the latest iteration of the cost_to_complete spreadsheet in pdf format. I hope to also track purchase amounts and have added a dummy table for that purpose. Comments and criticisms appreciated! Rich From tjp at astro.caltech.edu Tue Feb 1 15:07:13 2005 From: tjp at astro.caltech.edu (Tim Pearson) Date: Tue, 1 Feb 2005 12:07:13 -0800 Subject: [Gb-ccb] Computer-related parts costs for CCB Message-ID: Here are some cost estimates to be included in the "cost to complete" spreadsheet. Prices exclude tax and shipping. - Tim/Martin 1. Computer (4 needed). We have purchased one, originally shipped to Green Bank, currently being configured at Caltech: Qty Description Vendor # Manufacturer # Price --- ------------------------ -------- ---------------------- ------- 1 933MHz PC104+ CPU board 1LK9335 S-104P-CRR3-K933+512MB 1335.00 1 Stacking kit for CPU board 1LC3SPC 1LC3SPC 46.00 1 Set of cables for CPU board 1CSCRII S-KAB-CRR2-SET 88.00 Vendor: EMJ America Inc. Prices for August 2004. 2. Microdrive (4 needed). We have purchased one, currently at Caltech: Hitachi MD2GBA 2GB MicroDrive 3K4 with Travel Kit: $129.88 Vendor: J&R Music World (www.JR.com). Price for Nov 2004. 3. I/O board (4 needed). We have purchased 3, two are at Green Bank and one at Caltech: SCIDYNE GPIO-104 Analog and Digital I/O PC/104 module. Price: $265 each (Sep 2004). Vendor: Scydine (www.scydine.com) 4. USB module (4 needed). We have purchased 2, currently at Caltech for testing: Vendor: Saeling 2 x DLP-USB245M at $25 each (ie. $50 total). From mcs at astro.caltech.edu Wed Feb 2 23:20:17 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Wed, 2 Feb 2005 20:20:17 -0800 (PST) Subject: [Gb-ccb] Simulation of placed and routed slave FPGA. Message-ID: I have now successfully run a full simulation of the "placed and routed" slave FPGA firmware, using the same test-bench stimulus script that I used for the previous behavioral simulation. It took modelsim about 2 hours to run the simulation out to 26ms, at the recommended 1ns resolution, so I hope that I don't have to repeat this too often! Anyway, the simulation results matched the expected values, as hoped, so it looks as though I can now go on to entering the firmware of the master FPGA. Martin From rmccullo at nrao.edu Thu Feb 3 07:24:16 2005 From: rmccullo at nrao.edu (Randy McCullough) Date: Thu, 03 Feb 2005 07:24:16 -0500 Subject: [Gb-ccb] Revisions To The Master Card (02-FEB-05)... Message-ID: <420217F0.3090509@nrao.edu> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CCB MASTER CARD REVISIONS.doc Type: application/msword Size: 28672 bytes Desc: not available URL: From rlacasse at nrao.edu Thu Feb 3 11:08:06 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 03 Feb 2005 11:08:06 -0500 Subject: [Gb-ccb] 1 PPS characteristics Message-ID: <42024C66.9080104@nrao.edu> Randy, Just so we've got a written record, here are the characteristics of the 1 PPS signal distributed in the equipment room. I measured the only two that were uncommitted and they were essentially identical. The characteristics of the ones in the receiver room ought to be very similar. Pulse low level: 0.00 V Pulse high level: 4.24 V Pulse width: 1.04 usec (from 50% point to 50 % point) Pulse rise time: 35 ns Pulse fall time: 12 ns Rich From mcs at astro.caltech.edu Thu Feb 3 14:14:26 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Thu, 3 Feb 2005 11:14:26 -0800 (PST) Subject: [Gb-ccb] Simulation of placed and routed slave FPGA. In-Reply-To: References: Message-ID: Just in case anybody is perplexed by this, note that the simulation that I ran yesterday was to pico-second resolution, not the nanosecond resolution that I incorrectly reported last night. Martin From rlacasse at nrao.edu Thu Feb 3 15:04:53 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 03 Feb 2005 15:04:53 -0500 Subject: [Gb-ccb] Minutes and schedule updated Message-ID: <420283E5.9000000@nrao.edu> All, Minutes of yesterday's telecon are available on the wiki at http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes Also a new version of the schedule is attached to http://wiki.gb.nrao.edu/bin/view/Projects/CcbDesignArea I had to fight with this one for a while to get what I wanted. The software tasks are now included in the baselining so we can track the schedule more easily. Also, they are moved up above the testing so top-to-bottom will be more chronologically correct. This took some major surgery, so it would not be a bad idea to double-check it for accuracy. Rich From jford at nrao.edu Thu Feb 10 19:49:40 2005 From: jford at nrao.edu (John Ford) Date: Thu, 10 Feb 2005 19:49:40 -0500 Subject: [Gb-ccb] forwarded message from APC Status Server Message-ID: <16908.292.27221.604548@gargle.gargle.HOWL> An embedded message was scrubbed... From: "APC Status Server" Subject: APC Status Update for q002.zip Ref #:146713 is Shipped Date: Thu, 10 Feb 2005 13:15:04 -0700 Size: 2945 URL: From jford at nrao.edu Fri Feb 11 13:38:22 2005 From: jford at nrao.edu (John Ford) Date: Fri, 11 Feb 2005 13:38:22 -0500 Subject: [Gb-ccb] xilinx FPGA's Message-ID: <200502111838.j1BIcMNZ028430@prospero.gb.nrao.edu> All, Rich told me there was some discussion on the Master FPGA code, and the fact that it might not fit into the mere 400,000 gates in our FPGA. I checked out some options. Xilinx has a xc3s1000 part (1M gates) with a 256 pin BGA package. It is in stock at Avnet for $51.00 each. The xc3s400 is also available in the same package, for $29.00. It seems to me that if there is doubt that cannot be resolved quickly, we should switch to the BGA package for the Master cards, and not purchase the FPGA's until we know for sure which one we need. It's only a difference of a couple of hundred dollars in any event, and both parts are in stock at Avnet. . John From rmccullo at nrao.edu Fri Feb 11 14:19:27 2005 From: rmccullo at nrao.edu (Randy McCullough) Date: Fri, 11 Feb 2005 14:19:27 -0500 Subject: [Gb-ccb] xilinx FPGA's In-Reply-To: <200502111838.j1BIcMNZ028430@prospero.gb.nrao.edu> References: <200502111838.j1BIcMNZ028430@prospero.gb.nrao.edu> Message-ID: <420D053F.2060800@nrao.edu> An HTML attachment was scrubbed... URL: From mcs at astro.caltech.edu Fri Feb 11 18:24:50 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Fri, 11 Feb 2005 15:24:50 -0800 (PST) Subject: [Gb-ccb] xilinx FPGA's Message-ID: For some reason the following reply, that I sent to the CCB mailing list a few hours ago, bounced, so here it is again. Hopefully you won't get two copies... On Fri, 11 Feb 2005, John Ford wrote: > Rich told me there was some discussion on the Master FPGA code, and > the fact that it might not fit into the mere 400,000 gates in our > FPGA. The problem is that the 400,000 figure is not the number of configurable gates. The important number is the number of slices, of which there are only 3500. Each of these slices contains a lookup table that is used to implement a single 4-input, 1-output logic gate. The output of this gate can optionally be registered with the single one-bit flip-flop that is also in the slice. In other words there are about 3500 programmable 4-input, 1-output logic gates, along with 3500 flip-flops, that can only be used as part of these logic gates. These numbers are less than one 100th of the 400,000 gates that xilinx likes to emphasize in their advertising. It appears that their figure includes all of the fixed suport logic that is used to implement the logic blocks, DCMs, flip-flops, 288K of RAM etc... > I checked out some options. Xilinx has a xc3s1000 part (1M gates) > with a 256 pin BGA package. According to the Spartan-3 data sheet, the effective number of gates (slices), in the above chip is just under 7700. I'm afraid that its still too early for me to be able to guarantee that this will be sufficient, although I am still keeping my fingers crossed that our original FPGA will turn out to be okay in the end. Thanks. Martin From mcs at astro.caltech.edu Fri Feb 11 20:40:11 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Fri, 11 Feb 2005 17:40:11 -0800 (PST) Subject: [Gb-ccb] xilinx FPGA's In-Reply-To: References: Message-ID: I have now entered the Control Gateway module. Although this has more inputs and outputs than the FPGA has I/O pins, and I thus can't place and route it as though it were the sole occupant of the FPGA, I have run a preceding logic-mapping stage which reports how many slices would be used. The answer is 6% of the slices in the FPGA. The number of flip flops that were reported to be used, precisely matched the number that I estimated from my documentation a few days ago, so I am confident that my estimates of the number of flip-flops in the other 2 top-level modules will be essentially correct. Thus, going out on a limb, if I use my counts of the number of flip-flops in the 3 top-level modules of this FPGA, as a crude estimate of the relative complexities of the 3 modules, then the number of slices that will be needed for the master FPGA program, comes out at 44% of the available maximum. Thus there is still hope that everything will fit. Furthermore, given that the Xilinx ISE documentation says that ISE makes no attempt to optimize slice usage until slices start to run out, the 6% figure that was reported for the Control Gateway, may be a pessimistic number on which to base the usage of the completed Master-FPGA firmware. Martin From rlacasse at nrao.edu Tue Feb 15 08:16:43 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Tue, 15 Feb 2005 08:16:43 -0500 Subject: [Gb-ccb] Meeting minutes Message-ID: <4211F63B.3060200@nrao.edu> All, I've spent most of my time since last Wednesday fighting fires. Consequently, I just finished with last week's meeting minutes. It was quite a memory test; have a look and feel free to change anything that you don't remember the same way I do! http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes Rich From bmason at gb.nrao.edu Wed Feb 16 15:25:39 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Wed, 16 Feb 2005 15:25:39 -0500 (EST) Subject: [Gb-ccb] telecon in 1/2 hr Message-ID: Rich remdinded me, and this is to remind everyone else! We'll call you, Tim. -Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From rlacasse at nrao.edu Wed Feb 16 15:37:41 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Wed, 16 Feb 2005 15:37:41 -0500 Subject: [Gb-ccb] Re: CCB power supplies In-Reply-To: <3.0.1.32.20050216134807.0110ccd0@mail.gb.nrao.edu> References: <3.0.1.32.20050210124746.0115f250@mail.gb.nrao.edu> <3.0.1.32.20050210124746.0115f250@mail.gb.nrao.edu> <3.0.1.32.20050216134807.0110ccd0@mail.gb.nrao.edu> Message-ID: <4213AF15.4090607@nrao.edu> Roger, Randy is now assigned to that task, but that may change depending on how things go. I'll be glad to discuss the details with whoever you designate sometime soon so we have some idea where we're heading with this. Thanks, Rich Roger Norrod wrote: > Rich, > > Who is responsible for packaging the supplies? We do not have rack space > on the turret (I think), so mounting will take some thought. I'll probably > want one of the microwave people to coordinate with whoever is packaging > the supplies, since it's on the turret. > > Roger > > > > At 04:40 PM 2/10/2005 -0500, Richard Lacasse wrote: > >>Roger, >> >>Those are to be in a separate chassis. The front panel connector on the > > CCB is for DC > >>power input. >> >>Rich >> >>Roger Norrod wrote: >> >> >>>Rich, >>> >>>What are the plans for the CCB power supplies? Will they be included in >>>the receiver mounted module, or will we need to find a separate place to >>>mount them? >>> >>>Roger >>> >> > From rnorrod at nrao.edu Wed Feb 16 16:16:06 2005 From: rnorrod at nrao.edu (Roger Norrod) Date: Wed, 16 Feb 2005 16:16:06 -0500 Subject: [Gb-ccb] Re: CCB power supplies In-Reply-To: <4213AF15.4090607@nrao.edu> References: <3.0.1.32.20050216134807.0110ccd0@mail.gb.nrao.edu> <3.0.1.32.20050210124746.0115f250@mail.gb.nrao.edu> <3.0.1.32.20050210124746.0115f250@mail.gb.nrao.edu> <3.0.1.32.20050216134807.0110ccd0@mail.gb.nrao.edu> Message-ID: <3.0.1.32.20050216161606.0110ccd0@mail.gb.nrao.edu> Rich, I'm not sure of the size/weight of the power supply package, but if it's "small enough" (not sure what that is :)), it might be desirable to mount it on the receiver adjacent to the CCB package. In that case, coordinate with Galen. But if we think that's not practical, please coordinate with Bob Simon to find a location. Thanks, Roger At 03:37 PM 2/16/2005 -0500, Richard Lacasse wrote: >Roger, > >Randy is now assigned to that task, but that may change depending on how things go. I'll >be glad to discuss the details with whoever you designate sometime soon so we have some >idea where we're heading with this. > >Thanks, >Rich > >Roger Norrod wrote: > >> Rich, >> >> Who is responsible for packaging the supplies? We do not have rack space >> on the turret (I think), so mounting will take some thought. I'll probably >> want one of the microwave people to coordinate with whoever is packaging >> the supplies, since it's on the turret. >> >> Roger >> >> >> >> At 04:40 PM 2/10/2005 -0500, Richard Lacasse wrote: >> >>>Roger, >>> >>>Those are to be in a separate chassis. The front panel connector on the >> >> CCB is for DC >> >>>power input. >>> >>>Rich >>> >>>Roger Norrod wrote: >>> >>> >>>>Rich, >>>> >>>>What are the plans for the CCB power supplies? Will they be included in >>>>the receiver mounted module, or will we need to find a separate place to >>>>mount them? >>>> >>>>Roger >>>> >>> >> > >_______________________________________________ >gb-ccb mailing list >gb-ccb at listmgr.cv.nrao.edu >http://listmgr.cv.nrao.edu/mailman/listinfo/gb-ccb > From bmason at gb.nrao.edu Wed Feb 16 16:26:07 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Wed, 16 Feb 2005 16:26:07 -0500 (EST) Subject: [Gb-ccb] ccb fits file specification draft Message-ID: As I mentioned at the telecon today, I've drafted a specification for the CCB fits files, which is at http://wiki.gb.nrao.edu/bin/view/Projects/CcbFitsSpec Maybe we could discuss it at next week's telecons if people have significant comments. Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From mcs at astro.caltech.edu Wed Feb 16 18:35:11 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Wed, 16 Feb 2005 15:35:11 -0800 (PST) Subject: [Gb-ccb] ccb fits file specification draft In-Reply-To: References: Message-ID: On Wed, 16 Feb 2005, Brian Mason wrote: > As I mentioned at the telecon today, I've drafted a specification for the > CCB fits files, which is at > > http://wiki.gb.nrao.edu/bin/view/Projects/CcbFitsSpec A few comments: 1. I note that whereas the active switches keyword (ACTPSW) uses values from the set "A","B" "Both" and "None", the closed switches keyword (INPSWST) uses the values "00", "01", "10", "11". For consistency, might it be better to use one convention for both of these parameters? 2. Alternatively, have you considered splitting the above two keywords into two keywords each? For example: Keyword Value -------- ----- ACTPSWA TRUE ACTPSWB FALSE INPSWSTA ON INPSWSTB OFF Note that this is just another possibility. I personally don't mind which method you choose. 3. The CALSUSED keyword is said to take values of "A","B", and "Both". Shouldn't there also be a "None"? Although we wouldn't normally be operating without using at least one calibration diode, there is nothing in my code that dissallows this, and one could conceive of doing live tests without either cal-diode being used. 4. The diode_rise_dt parameter (keyword CRISEDT) is documented as being the "pause before start of CAL ON integration". This appears to imply that an integration starts precisely this long after a cal-diode is switched on. Contrary to this, integrations are continually being taken, while the cal-diode is still settling, and this parameter is just one of those that determine how many of these integration periods get flagged at the start of a "CAL ON" integration. A similarly succinct, but more correct, comment for this keyword would be: "Cal diode settling time after being switched on". 5. As in 4, above, I would comment the diode-fall-time keyword (CFALLDT), as: "Cal diode settling time after being switched off". 6. In your Note 2, below the table in section 2, you say "We purposely omit the information passed in the call ccb_queue_timing_cnf.sample_dt, since I think this is always fixed at 100ns." ccb_queue_timing_cnf() hasn't taken a sample_dt parameter for a long time, so I am wondering if you are using an old version of my documentation. 7. Should we also include keywords for the roundtrip_dt and holdoff_dt configuration parameters? 8. Should we include a keyword that records whether the integrated data came from the ADCs, or from the internal test signal? Having such a keyword could ease post-mortem analysis of weird data, after somebody accidentally enabled test mode during their observing run. 9. In the "Data Table", I don't see a column that would list the states of the 4 slaves. What I am refering to are the 4 CCB_SLAVE*_OK flags that I return in the 'flags' parameter of each integration. 10. In the documentation of the "Data table", you mention the possibility of the addition of individual overflow flags to the information returned by the CCB libraries. No such flags are planned, because each integrated data-value that has overflowed is already indicated by a special value that has all 32-bits of the value set to 1 (ie. 2^32-1). So, if you want to have a separate column for overflow bits, then simply generate overflow flags by comparing each integrated data-value that you receive, to the unsigned integer value 2^32-1 In C this value would most conveniently be expressed as 0xFFFFFFFFUL, and the comparison would performed against integrated values stored in unsigned long's (assuming that longs on the target system are at least 32 bits wide). Beware that if you plan to rescale and/or convert the integrated values to floating point before storing them in the FITS file, then you must generate separate overflow flags before doing this, since you will lose the ability to do a reliable equality test against the special value, once the data are in floating point. 11. There is no mention of the data-type used for the integrated data values. Unless you plan to rescale them to double-precision floating point values, then you must use an unsigned integer data-type of at least 32 bits. The same goes for faithfully preserving such values in the code of pre and post-processing software. Martin From bmason at gb.nrao.edu Wed Feb 16 20:00:24 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Wed, 16 Feb 2005 20:00:24 -0500 (EST) Subject: [Gb-ccb] ccb fits file specification draft In-Reply-To: Message-ID: Thanks Martin- I've incorporated most of your suggestions into the draft. Comments below. On Wed, 16 Feb 2005, Martin Shepherd wrote: > > 1. I note that whereas the active switches keyword (ACTPSW) uses > values from the set "A","B" "Both" and "None", the closed switches > keyword (INPSWST) uses the values "00", "01", "10", "11". > > For consistency, might it be better to use one convention for both > of these parameters? > > 2. Alternatively, have you considered splitting the above two keywords > into two keywords each? For example: > > Keyword Value > -------- ----- > ACTPSWA TRUE > ACTPSWB FALSE > INPSWSTA ON > INPSWSTB OFF > > Note that this is just another possibility. I personally don't mind > which method you choose. Both good points. I slightly favor one keyword (A,B,Both,NONE) for ACTPSW. > > 3. The CALSUSED keyword is said to take values of "A","B", and "Both". > Shouldn't there also be a "None"? Although we wouldn't normally be > operating without using at least one calibration diode, there is > nothing in my code that dissallows this, and one could conceive of > doing live tests without either cal-diode being used. > (points 4-6) -- Agreed > 7. Should we also include keywords for the roundtrip_dt and holdoff_dt > configuration parameters? probably so. > > 8. Should we include a keyword that records whether the integrated > data came from the ADCs, or from the internal test signal? Having > such a keyword could ease post-mortem analysis of weird data, after > somebody accidentally enabled test mode during their observing run. Does your api return that info? > > 9. In the "Data Table", I don't see a column that would list the > states of the 4 slaves. What I am refering to are the 4 > CCB_SLAVE*_OK flags that I return in the 'flags' parameter of each > integration. Good point. Do you see this would be useful for every integration, or would a single-bit logical OR of a whole scan be sufficient? > > 10. In the documentation of the "Data table", you mention the > possibility of the addition of individual overflow flags to the > information returned by the CCB libraries. No such flags are > planned, because each integrated data-value that has overflowed is > already indicated by a special value that has all 32-bits of the > value set to 1 (ie. 2^32-1). > ....... 10&11 sound fine. I'm inclined to a) preserve 32bit ints in the data; b) do overflow comparisons and type conversions downstream in the analysis software. One further comment-- the "appendix" section of my document lays out my understanding of what the datastream corresponds to physically. It would be good to have that "meaning of the datastream" type information in your interface document. At some point, we should also verify that the labels correspond to what's meant to be on the panel front in terms of data order! -Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From mcs at astro.caltech.edu Wed Feb 16 21:11:20 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Wed, 16 Feb 2005 18:11:20 -0800 (PST) Subject: [Gb-ccb] ccb fits file specification draft Message-ID: On Wed, 16 Feb 2005, Brian Mason wrote: > Thanks Martin- I've incorporated most of your suggestions into the draft. > Comments below. > > On Wed, 16 Feb 2005, Martin Shepherd wrote: > >... > > 8. Should we include a keyword that records whether the integrated > > data came from the ADCs, or from the internal test signal? Having > > such a keyword could ease post-mortem analysis of weird data, after > > somebody accidentally enabled test mode during their observing run. > > Does your api return that info? It is requested via the ccb_set_sampler_cnf() function and can subsequently be queried using the ccb_get_sampler_cnf() function. Note that like the other configuration parameters, this is part of the scan configuration, so it can't change from one integration to the next during a scan. > > 9. In the "Data Table", I don't see a column that would list the > > states of the 4 slaves. What I am refering to are the 4 > > CCB_SLAVE*_OK flags that I return in the 'flags' parameter of each > > integration. > > Good point. Do you see this would be useful for every integration, or > would a single-bit logical OR of a whole scan be sufficient? In the case of a really flaky connection to one of the slaves, or an intermittent fault within a slave, then it would be possible for these flags to change sporadically from one integration to the next. I would thus suggest that we record these flags separately for each integration. > One further comment-- the "appendix" section of my document lays out my > understanding of what the datastream corresponds to physically. It would > be good to have that "meaning of the datastream" type information in your > interface document. Okay. Martin From rlacasse at nrao.edu Thu Feb 17 13:47:16 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 17 Feb 2005 13:47:16 -0500 Subject: [Gb-ccb] Meeting minutes are available Message-ID: <4214E6B4.4020100@nrao.edu> All, Minutes of yesterday's meeting are available at http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes As usual please either e-mail me corrections or edit them in yourself. Thanks, Rich From tjp at astro.caltech.edu Thu Feb 17 19:37:35 2005 From: tjp at astro.caltech.edu (Tim Pearson) Date: Thu, 17 Feb 2005 16:37:35 -0800 Subject: [Gb-ccb] ccb fits file specification draft In-Reply-To: References: Message-ID: <1d9fb55c6d9b87d662a7356e54b86888@astro.caltech.edu> Some comments and questions. Apologies if they are stupid questions. 1. To summarize the general philosophy: there is one file per "scan", and one row in the DATA table for each integration in the scan. Parameters that are constant for the whole scan appear as keywords in the primary header or in the header of the DATA table: is there any rhyme or reason as to which? Additional scan-constant data go in the PORT and CCBSTATE tables, presumably mostly for consistency with other GBT FITS files. I hope that subsequent processing never separates the DATA table from its corresponding primary header and PORT and CCBSTATE tables; if that could potentially happen, then I would prefer to see all the scan-specific parameters in the header of the DATA table, and have unique IDs on each PORT and CCBSTATE table that are recorded in the header of the DATA table. Or at least repeat PROJID and OBSID in the headers of all the tables. Does the combination OBSID+PROJID uniquely identify this scan among all GBT scans? Where does the "manager parameter source" come from? The CCB data stream is independent of what source the telescope is pointing at, and the source may change during a scan, so I'm not sure it's relevant in this FITS file. Isn't the combination of PROJID and OBSID sufficient? 2. I think it is undesirable to include "additional keyword values that are deduced from the above". If the same information can be stored in two different places, the software has to worry about what it should do when they are inconsistent. 3. PORT table, CCBSTATE table. The numbers of rows in these tables are what you call NPORTS and NPHASES. This should be made explicit. I assume (is this correct?) that the numbers in the PORT column of the PORT table are (possibly a subset of) the numbers written beside the input connectors on the CCB front panel. 4. DATA table, SLV*_OK parameters. Is "OK" = 1 or 0 ? If it is 1, you want logical AND, not OR. I don't think we need these for every integration. They are alarm conditions to be signaled to the operator, not recorded in the FITS file. If any integration has a bad slave, the manager probably shouldn't write out the FITS file at all. Exception: if we are using 3 or less slaves (e.g., for 3 mm) we don't care about the ok-ness of the others. There is an implicit assignment of PORTS to SLAVES. If there is anything in the FITS file that refers to individual slaves, we need a record of which ports are handled by which slaves. 5. Martin suggests we record DATA as unsigned 32-bit. FITS has no native way to store unsigned 32-bit quantities, only signed (twos-complement) quantities. "Unsigned sixteen-bit integers can be represented in FITS files by subtracting 32 768 from each value (thus offsetting the values into the range of a signed sixteen-bit integer) before writing them to the FITS le. The BZERO keyword (or the TZEROn keyword in the case of binary table columns with TFORMn = 'I') must also be included in the header with its value set to 32 768 so that FITS reading software will add this offset to the raw values in the FITS file, thus restoring them to the original unsigned integer values. Unsigned thirty-two-bit integers can be represented in FITS files in a similar way by applying an offset of 2147483648 (2^31) to the data values." I hope this does not corrupt the magic value, which will be -1 in twos-complement. 6. I take it that your plan is that the manager will extract the active subset of the 64 CCB outputs (4 phases x 16 ports) and discard the others. This is ok by me, but it does complicate the manager and to some extent subsequent software. If you are worried about data volume, then maybe we should combine CALAON, CALBON, INTEGOK (each is a single bit) in one column. 7. The enumerated choices for ACTPSW would be better as "", "A", "B", "AB", or 00, 01, 10, 11, rather than "None", "A", "B", "Both": this makes the extension to more than 2 phase switches straightforward. (Or have one keyword per switch, as Martin suggests.) Not that I can imagine ever having more than 2, but I like extensibility as a general philosophy. 8. Can you point me to the corresponding document for DCR? From bmason at gb.nrao.edu Thu Feb 17 21:32:09 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Thu, 17 Feb 2005 21:32:09 -0500 (EST) Subject: [Gb-ccb] ccb fits file specification draft In-Reply-To: <1d9fb55c6d9b87d662a7356e54b86888@astro.caltech.edu> Message-ID: Thanks Tim- On Thu, 17 Feb 2005, Tim Pearson wrote: > Some comments and questions. Apologies if they are stupid questions. > > 1. To summarize the general philosophy: there is one file per "scan", > and one row in the DATA table for each integration in the scan. > Parameters that are constant for the whole scan appear as keywords in > the primary header or in the header of the DATA table: is there any > rhyme or reason as to which? correct generally. integration by integration data go in the data table. scan-constant things that pertain to the whole dataset go in the primary header, except... > Additional scan-constant data go in the > PORT and CCBSTATE tables, presumably mostly for consistency with other > GBT FITS files. for things we feel would be better represented as tables than a list of keyword/values (or in this case indeed: tables that are part of the GBT FITS spec) > > I hope that subsequent processing never separates the DATA table from > its corresponding primary header and PORT and CCBSTATE tables; if that > could potentially happen, then I would prefer to see all the > scan-specific parameters in the header of the DATA table, and have > unique IDs on each PORT and CCBSTATE table that are recorded in the > header of the DATA table. Or at least repeat PROJID and OBSID in the > headers of all the tables. Does the combination OBSID+PROJID uniquely > identify this scan among all GBT scans? I don't see the issue here: isn't it up to the analysis software to sensibly represent the information in the FITS file? Data structures should be defined accordingly, and needn't mirror the structure of the FITS file (shouldn't really). In my software anyway, the PORT and CCBSTATE tables are only used in constructing physical interpretations and indices that are then valid for a given scan. > > Where does the "manager parameter source" come from? The CCB data > stream is independent of what source the telescope is pointing at, and > the source may change during a scan, so I'm not sure it's relevant in > this FITS file. Isn't the combination of PROJID and OBSID sufficient? > If I recall, the source parameter is part of the GBT FITS specification. It is redundant. In principle all you need is a scan number and project id. > 2. I think it is undesirable to include "additional keyword values that > are deduced from the above". If the same information can be stored in > two different places, the software has to worry about what it should do > when they are inconsistent. Ok. > > 3. PORT table, CCBSTATE table. The numbers of rows in these tables are > what you call NPORTS and NPHASES. This should be made explicit. I > assume (is this correct?) that the numbers in the PORT column of the > PORT table are (possibly a subset of) the numbers written beside the > input connectors on the CCB front panel. Agreed- thanks. and yes. > > 4. DATA table, SLV*_OK parameters. Is "OK" = 1 or 0 ? If it is 1, you > want logical AND, not OR. I don't think we need these for every > integration. They are alarm conditions to be signaled to the operator, > not recorded in the FITS file. If any integration has a bad slave, the > manager probably shouldn't write out the FITS file at all. Exception: > if we are using 3 or less slaves (e.g., for 3 mm) we don't care about > the ok-ness of the others. There is an implicit assignment of PORTS to > SLAVES. If there is anything in the FITS file that refers to individual > slaves, we need a record of which ports are handled by which slaves. Correct! Good point about the SLAVE to PORT index. If others agree this is needed (as opposed to just having the SLAVEOK info available for experts to see problems happening) I think we can add a column to the PORT table to do this. Is it true it's just a static lookup table? ie slave 1 will always map to J3,J4,J5,J6 for instance. > > 5. Martin suggests we record DATA as unsigned 32-bit. FITS has no > native way to store unsigned 32-bit quantities, only signed > (twos-complement) quantities. "Unsigned sixteen-bit integers can be > represented in FITS files by subtracting 32 768 from each value (thus > offsetting the values into the range of a signed sixteen-bit integer) > before writing them to the FITS le. The BZERO keyword (or the TZEROn > keyword in the case of binary table columns with TFORMn = 'I') must > also be included in the header with its value set to 32 768 so that > FITS reading software will add this offset to the raw values in the > FITS file, thus restoring them to the original unsigned integer values. > Unsigned thirty-two-bit integers can be represented in FITS files in a > similar way by applying an offset of 2147483648 (2^31) to the data > values." I hope this does not corrupt the magic value, which will be -1 > in twos-complement. we'll have to think about that one. > > 6. I take it that your plan is that the manager will extract the active > subset of the 64 CCB outputs (4 phases x 16 ports) and discard the > others. This is ok by me, but it does complicate the manager and to > some extent subsequent software. If you are worried about data volume, > then maybe we should combine CALAON, CALBON, INTEGOK (each is a single > bit) in one column. It does complicate the manager but I think this simplifies the downstream software. It is also consistent with the standard way that STATE (here CCBSTATE, as slightly non standard) tables are defined. Otherwise the STATE table would index phases that don't occur in the data and need a special column saying which phases actually ocurred. Or the software would have to infer that from keyword/values-- again not standard. I guess the idea is that the standard constructs are meant to embody some generic features of the data across instruments (like phases, and mappings of data columns to physical plugs) instead of having all that inferred from an instrument-dependent set of keyword/value pairs. I did consider combining the flags and just passing on the raw flag byte, and maybe that's better. > > 7. The enumerated choices for ACTPSW would be better as "", "A", "B", > "AB", or 00, 01, 10, 11, rather than "None", "A", "B", "Both": this > makes the extension to more than 2 phase switches straightforward. (Or > have one keyword per switch, as Martin suggests.) Not that I can > imagine ever having more than 2, but I like extensibility as a general > philosophy. Ok. > > 8. Can you point me to the corresponding document for DCR? > Unfortunately no. The DCR format to my knowledge is undocumented (I've figured it out by playing with the data), and in fact is not compliant with GBT FITS standards unlike other backends. However here is one http://www.gb.nrao.edu/~bmason/ccb/2005_01_02_20:23:01.fits the other file there ( 2004_11_15_09:56:17A.fits) is in many ways a better example (it's a spectrometer FITS file, which is compliant with our standards) -Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From mcs at astro.caltech.edu Fri Feb 18 05:46:15 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Fri, 18 Feb 2005 02:46:15 -0800 (PST) Subject: [Gb-ccb] ccb fits file specification draft In-Reply-To: References: Message-ID: On Thu, 17 Feb 2005, Brian Mason wrote: > On Thu, 17 Feb 2005, Tim Pearson wrote: > >... > > 4. DATA table, SLV*_OK parameters. Is "OK" = 1 or 0 ? It's 1. > > If it is 1, you > > want logical AND, not OR. I don't think we need these for every > > integration. They are alarm conditions to be signaled to the operator, > > not recorded in the FITS file. Okay, although this could make debugging an intermittent problem more difficult. Since you couldn't practically signal a new alarm condition every few milliseconds, all that you would know was that a slave had experienced a problem during at least one 1ms integration period, in the last minute or two. > > If any integration has a bad slave, the > > manager probably shouldn't write out the FITS file at all. Exception: > > if we are using 3 or less slaves (e.g., for 3 mm) we don't care about > > the ok-ness of the others. If the real-time software is going to generate this alarm, then I'll need to add another configuration parameter that the manager can use to tell me which slaves it cares about. Otherwise I won't know whether to generate an alarm condition or not when a slave appears to have gone belly-up. Alternatively, since the manager already gets a copy of the slave_ok flags along with each frame of integrated data, the manager could generate the alarm. This brings up question. Randy's addition of a slaves-ok LED to the front panel means that I am already going to have to generate something like this operator-alarm in the real-time computer. Consistency would appear to dictate that both the LED and the operator alarm should be generated in one place, using the same criteria. However, this would mean that the front-panel LED would mean different things, depending both on whether there was a manager currently connected, and on the latest configuration parameters from the manager. That could lead to confusion. So there appear to be 3 options: 1. The real-time software could generate both the LED and operator alarms, by comparing the slave_ok flags to a list of important slaves. This list would be received from the manager, unless no manager was connected, in which case it could default to either all slaves, or no slaves. 2. The real-time software could generate both the LED and operator alarms under different criteria. The operator alarm would be raised according to the list of important slaves received from the manager compared to the slave_ok flags, whereas the LED would be lit whenever any number of slaves were unresponsive. 3. Alternatively, the real-time software could just be responsible for lighting the LED, which would light up whenever any of the slaves was broken. Meanwhile, the manager would take on the responsibility for generating the operator alarm, according to its own criteria, applied to the slave_ok flags that it receives. Any preferences? > Good point about the SLAVE to PORT index. If others agree this is needed > (as opposed to just having the SLAVEOK info available for experts to see > problems happening) I think we can add a column to the PORT table to do > this. Is it true it's just a static lookup table? ie slave 1 will always > map to J3,J4,J5,J6 for instance. Yes. I think that you would have to deliberately cross wire the cables in the RFI filter box to change this mapping, and I can't think of any reason why anybody would want to do that. > > ... > > Unsigned thirty-two-bit integers can be represented in FITS files in a > > similar way by applying an offset of 2147483648 (^31) to the data > > values." I hope this does not corrupt the magic value, which will be -1 > > in twos-complement. It would be -1 if you simply cast the number from unsigned to signed, without changing the bit pattern. However if you subtracted 2^31, as specified above, then the magic value would become 2147483647, rather than -1. Anyway, I can see a few ways of dealing with the issue of preserving the 32-bit overflow value (and other integrated 32-bit unsigned values). 1. If you performed the offsetting using integer arithmetic, before passing the data to the FITS writer, and set TSCALn to 1.0 and TZEROn to 0.0, then I would imagine that any practical floating point implementation would get a multiplication by 1.0 and an offset of zero correct, provided that its double precision data-type had at least 32 bits in its mantissa/fraction, and used a binary exponent. IEEE-754 (as used on PCs, Suns etc) has 52 bits in its mantissa, and uses a binary exponent, so it has more than enough precision to exactly hold any 32-bit unsigned integer value. Conversion back to unsigned integers should be performed by the analysis software, rather than by the FITS library. 2. You could specify the magic value via the FITS TNULL keyword, such that the FITS library would check for it, before the scaling and offsetting potentially had a chance to mangle the magic value. 3. You could use the TFORMn='X' format to directly store the unsigned integer verbatim as 4 bytes. For consistency with other data-types in FITS, GBT's writing program would ideally present these unsigned integers to the FITS writer in big-endian format, and it would be up to the subsequent analysis program to convert them back to whatever byte-order the host platform used. Note that such conversions can be written in a platform independent manner, if you don't mind a small loss in efficiency. 4. You could add a column of 64 overflow-flags, one per integrated data value, and generate these flags from the raw data, before handing the data to the FITS file. If you did this, then you wouldn't have to worry about the magic value getting mangled by the FITS software, and you could use any of the above techniques for storing the data in the table. This seems like the safest solution. Martin From jford at nrao.edu Fri Feb 18 08:04:50 2005 From: jford at nrao.edu (John Ford) Date: Fri, 18 Feb 2005 08:04:50 -0500 Subject: [Gb-ccb] ccb fits file specification draft In-Reply-To: References: Message-ID: <16917.59378.288566.215097@gargle.gargle.HOWL> Martin Shepherd writes: > > On Thu, 17 Feb 2005, Brian Mason wrote: > > On Thu, 17 Feb 2005, Tim Pearson wrote: < snip > > So there appear to be 3 options: > > 1. The real-time software could generate both the LED and operator > alarms, by comparing the slave_ok flags to a list of important > slaves. This list would be received from the manager, unless no > manager was connected, in which case it could default to either all > slaves, or no slaves. > > 2. The real-time software could generate both the LED and operator > alarms under different criteria. The operator alarm would be raised > according to the list of important slaves received from the manager > compared to the slave_ok flags, whereas the LED would be lit > whenever any number of slaves were unresponsive. > > 3. Alternatively, the real-time software could just be responsible for > lighting the LED, which would light up whenever any of the slaves > was broken. Meanwhile, the manager would take on the > responsibility for generating the operator alarm, according to its > own criteria, applied to the slave_ok flags that it receives. > > Any preferences? The LED's on the front panel should show the state of the hardware. If only 3 slaves are installed, it should reflect that state. Not being installed is different than broken, and if the system can tell the difference, that would be a useful thing. The software could be told via a config file or whatever what slaves are installed or not. I would prefer #2 with a config file or #3 above. #3 appears to me to be the correct choice. John From bmason at gb.nrao.edu Fri Feb 18 10:58:33 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Fri, 18 Feb 2005 10:58:33 -0500 (EST) Subject: [Gb-ccb] ccb fits file specification draft In-Reply-To: Message-ID: On Fri, 18 Feb 2005, Martin Shepherd wrote: > > > If it is 1, you want logical AND, not OR. I don't think we need > > > these for every integration. They are alarm conditions to be > > > signaled to the operator, not recorded in the FITS file. > > Okay, although this could make debugging an intermittent problem more > difficult. Since you couldn't practically signal a new alarm condition > every few milliseconds, all that you would know was that a slave had > experienced a problem during at least one 1ms integration period, in > the last minute or two. It's easy enough to record a single multi-bit flag column in the FITS file which has all the flag info and has been suggested before-- are there objections to doing that? I don't think we should make writing the FITS file contingent on error conditions in individual components of the system. It will be straightforward to reconstruct which data channels correspond to which slaves from the FITS files so the suspect data are identifiable that way, and the bad data are available via the normal data path should Martin or others want to look at them. > > Good point about the SLAVE to PORT index. If others agree this is needed > > (as opposed to just having the SLAVEOK info available for experts to see > > problems happening) I think we can add a column to the PORT table to do > > this. Is it true it's just a static lookup table? ie slave 1 will always > > map to J3,J4,J5,J6 for instance. > > Yes. I think that you would have to deliberately cross wire the cables > in the RFI filter box to change this mapping, and I can't think of any > reason why anybody would want to do that. Ok good. > > > ... > > > Unsigned thirty-two-bit integers can be represented in FITS files in a > > > similar way by applying an offset of 2147483648 (^31) to the data > > > values." I hope this does not corrupt the magic value, which will be -1 > > > in twos-complement. > > It would be -1 if you simply cast the number from unsigned to signed, > without changing the bit pattern. However if you subtracted 2^31, as > specified above, then the magic value would become 2147483647, rather > than -1. > > Anyway, I can see a few ways of dealing with the issue of preserving > the 32-bit overflow value (and other integrated 32-bit unsigned > values). > > 1. If you performed the offsetting using integer arithmetic, before > passing the data to the FITS writer, and set TSCALn to 1.0 and > TZEROn to 0.0, then I would imagine that any practical floating > point implementation would get a multiplication by 1.0 and an > offset of zero correct, provided that its double precision > data-type had at least 32 bits in its mantissa/fraction, and used a > binary exponent. IEEE-754 (as used on PCs, Suns etc) has 52 bits in > its mantissa, and uses a binary exponent, so it has more than > enough precision to exactly hold any 32-bit unsigned integer value. > > Conversion back to unsigned integers should be performed by the > analysis software, rather than by the FITS library. > > 2. You could specify the magic value via the FITS TNULL keyword, such > that the FITS library would check for it, before the scaling and > offsetting potentially had a chance to mangle the magic value. > > 3. You could use the TFORMn='X' format to directly store the unsigned > integer verbatim as 4 bytes. For consistency with other data-types > in FITS, GBT's writing program would ideally present these unsigned > integers to the FITS writer in big-endian format, and it would be > up to the subsequent analysis program to convert them back to > whatever byte-order the host platform used. Note that such > conversions can be written in a platform independent manner, if you > don't mind a small loss in efficiency. > > 4. You could add a column of 64 overflow-flags, one per integrated > data value, and generate these flags from the raw data, before > handing the data to the FITS file. If you did this, then you > wouldn't have to worry about the magic value getting mangled by the > FITS software, and you could use any of the above techniques for > storing the data in the table. This seems like the safest solution. I favor (4) in the form of a multi-dimensional "overflow" column that mirrors the data column in structure (but not datatype for each datum). Tim, do you have a preference among the overflow options? -Brian > > Martin > -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From bmason at gb.nrao.edu Wed Feb 23 14:47:25 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Wed, 23 Feb 2005 14:47:25 -0500 (EST) Subject: [Gb-ccb] telecon at 4pm Message-ID: gb folks let's meet in 137. -Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From mcs at astro.caltech.edu Wed Feb 23 20:18:33 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Wed, 23 Feb 2005 17:18:33 -0800 (PST) Subject: [Gb-ccb] FPGA 3.3V LVCMOS configuration Message-ID: In the CCB telecon today I said that I hadn't explicitly configured which interfacing standard the FPGA should use for its pins. Others in the telecon said that it was likely that the default was 3.3V low-voltage CMOS, which is what we want. Unfortunately it turns out that the default interface standard is actually 2.5V low-voltage CMOS, so yes, I need to find out how to override the default in my two designs. While looking into this, I came across the following document, which elaborates the external electrical requirements for configuring Spartan-3 FPGAs using 3.3V low-voltage CMOS components. http://direct.xilinx.com/bvdocs/appnotes/xapp453.pdf Although I believe that the same information can be gleaned from the Spartan-3 data-sheet, the above document could be useful. Martin From bmason at gb.nrao.edu Thu Feb 24 11:27:37 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Thu, 24 Feb 2005 11:27:37 -0500 (EST) Subject: [Gb-ccb] telecon notes Message-ID: I've put notes from the telecon on the wiki http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes also below. Please send me corrections or additions. -Brian ========================================================= Telecon 23 Feb 2005 NEW TP, MS, RM, JF, BM * Green Bank Progress Report (Randy ) o Randy completed entering the library of modules for the master card schematic into EAGLE and is proceeding with stitching them together into a real schematic, has finished 3 sheets. Expects to finish the schematic by mid-week next week or so. o Chuck is working on the cost to complete estimate and needs some vendor info from JF in order to get competitive bids. o So far in the pricing exercise one red flag has been raised. Our original rough estimate of the Daughter Card cost was $4K total. So far Chuck has $7200 for 18 units (this includes: parts, boards, but no assembly; we're not sure if it includes the FPGA's) * DRAFT FITS Specification Review (Brian) o Brian has updated the draft FITS spec to reflect comments since its circulation. The main changes were: + specifying integration data type as 32 bit 2's complement with a TZERO fo 2^{31} + adding a multi-dimensional overflow column of type LOGICAL which will record overflow information + consolidating flags into a one-byte FLAG column + adding a SLAVE column to the PORT table. o Martin & Tim suggested we consider just recording the raw bit patterns of the integration data (rather than converting to 2's complement) and reconstructing the real values in the data processing side. * Caltech Progress Report (Martin) o Martin has entered the entire master FPGA program and fitted it! This uses only 20% of the available gates (we don't understand the discrapancy to the original estimates) so we can use the originally planned FPGA's. o Martin has started assigning pins and reports that he can't find 1pps and 10 MHz inputs. It appears that the diagram Martin is using is out of date and Randy will provide a current one. o The next step for Martin will be simulating the FGPA and debugging. -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From mcs at astro.caltech.edu Fri Feb 25 22:52:05 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Fri, 25 Feb 2005 19:52:05 -0800 (PST) Subject: [Gb-ccb] FPGA pinout problem Message-ID: I'm afraid that there is a significant problem with both of the current FPGA pinouts, and that this will require some significant rework of the PCB routing. On entering the revised master-FPGA pinout that Randy sent me today, using the Xilinx PACE program, PACE generated the following error messages: WARNING: Bank2 SSO Threshold Exceeded WARNING: Bank5 SSO Threshold Exceeded SSO apparently stands for "Simultaneously Switching Outputs". According to the Spartan3 data-sheet, the maximum number of pins that can be switching simultaneously, depends on the type of FPGA package (PQ208 in our case), the signaling standard (3.3V Low-Voltage CMOS in our case), the number of Vcco/Gnd pairs per bank (2 for the Spartan3), and the selected output switching speed and current. If I select the slowest I/O speed, in order to get the highest SSO limit, then according to the data-sheet we can only have 8 output pins per I/O bank switching simultaneously. Our current pin usage per bank is as follows. Inputs Outputs Unused Bank 0: 0 0 16 Bank 1: 6 8 1 Bank 2: 1 15 3 Bank 3: 0 4 16 Bank 4: 0 2 15 Bank 5: 0 11 4 Bank 6: 15 4 0 Bank 7: 3 1 16 Note that the "outputs" column includes both bi-directional and output-only pins. Clearly PACE is correct to note that there are too many outputs assigned to banks 2 and 5. Bank 1 is also right at the limit. We currently have a total of 45 outputs. Thus, given 8 banks, the ideal distribution of outputs would have 5 banks with 6 outputs, and 3 banks with 5 outputs. The resulting maximum of 6 outputs per bank would enable us to configure the speed up one notch, although the resulting difference in I/O speed would probably be too small to be significant. I haven't finished entering the I/O buffers for the slave yet, so I haven't re-run PACE on it, but a quick look at the slave-FPGA pinout suggests that it too has a problem, this time with Bank 6, which currently has 15 outputs assigned to it. We could also potentially have problems with Banks 0 and 7 if we were to use too many of the currently unused auxiliary header pins as outputs. I haven't yet figured out how to determine whether the slowest FPGA I/O speed is ok. I imagine, however that what I should be interested in is the time that it takes for a rising clock signal in the master FPGA to result in a latched output signal from a slave FPGA arriving back within the master FPGA. If I only take account of the propagation delays of the I/O blocks within the FPGAs, then (assuming that I am reading the data-sheet correctly) it appears that I should expect about 20ns roundtrip delay. In addition to this, the data-sheet for the bus-drivers that Randy selected, says that the maximum of their output-enable and propagation delays is about 6ns, so doubling this to get the roundtrip delay, would add another 12ns, yielding a total roundtrip I/O delay of 32ns. That's about a third of a clock period, so it sounds as though it should be okay. It would be great if somebody could check if I have got this estimate correct, since there are a lot of timings listed in the FPGA data-sheet, and I'm not sure if I have used the right ones. If my speed estimate turns out to be optimistic, and we do need to configure a higher I/O speed, then it appears that the only way to allow this, without exceeding the SSO limit, would be to go to at least an FT256 ball-grid array package, which has a higher SSO limit per Vcco/Gnd pair, and 3 such pairs per bank, instead of 2. Martin From bmason at gb.nrao.edu Wed Mar 2 12:42:32 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Wed, 2 Mar 2005 12:42:32 -0500 (EST) Subject: [Gb-ccb] telecon today 4pm eastern Message-ID: hi All- I've booked 137 for our weekly ccb telecon. -Brian -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From bmason at gb.nrao.edu Thu Mar 3 11:07:49 2005 From: bmason at gb.nrao.edu (Brian Mason) Date: Thu, 3 Mar 2005 11:07:49 -0500 (EST) Subject: [Gb-ccb] telecon notes Message-ID: are on the wiki http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes and below -Brian Telecon 02 Mar 2005 NEW TP, MS, RM, JF, BM * Caltech Status report o There was much discussion of the Simultaneously Switching Output (SSO) warnings that Martin encountered late last week in fitting the master. The underlying concern is that too much current will change the ground level inside part of the FPGA and cause inputs referred to that ground to be misinterpreted (most problematic would be asynchronous inputs like reset or clock). This will affect both the master and the slave FPGAs at some level. + We would like to avoid changing the slave pinout if at all possible. On the slave the reset and clock pins are physically far away from the most heavily SSO'd bank; Randy & John hypothesize that the effect of SSO will be minimal. We will also look into slowing down the lines. + For the master we still have options even including changing the pinout if needed. o Martin has been working on documentation (not yet released) o There have been some problems with XILINX software crashing needing to be sorted through * Green Bank Status o Randy has been thinking about the SSO problem and reviewing the new (Jan 05) datasheets that would have told us to expect it. o Tim Bastian has confirmed that money is available for Cristobal to return this summer. Brian will pursue visa arrangements etc. o The office here was shut down for snow Mon & Tues so little else has happened. o John points out that we should review our schedules and update them. o Brian will probably miss the next two telecons. 137 has been reserved every Wed at 4pm through october. -- -------------------------------------------------------------------- Brian Mason | office: +1(304)456-2338 Associate Scientist | fax: +1(304)456-2229 National Radio Astronomy Observatory | mail: PO Box 2 bmason at gb.nrao.edu | Green Bank, WV 24944 http://www.gb.nrao.edu/~bmason/ | -------------------------------------------------------------------- From rlacasse at nrao.edu Thu Mar 10 11:45:39 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 10 Mar 2005 11:45:39 -0500 Subject: [Gb-ccb] Meeting minutes available Message-ID: <423079B3.8080607@nrao.edu> All, Minutes of yesterday's meeting are available on the wiki: http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes Please forward any corrections to me or edit them in yourself. Thanks, Rich From jford at nrao.edu Thu Mar 10 14:22:18 2005 From: jford at nrao.edu (John Ford) Date: Thu, 10 Mar 2005 14:22:18 -0500 Subject: [Gb-ccb] EPP specs In-Reply-To: <423079B3.8080607@nrao.edu> References: <423079B3.8080607@nrao.edu> Message-ID: <16944.40554.643789.267677@gargle.gargle.HOWL> This is IEEE Standard #1284, which can be obtained from IEEE for some money, or maybe caltech's library has a copy. Another source for infor is Axelson's Parallel Port Complete, see http://www.amazon.com/exec/obidos/ASIN/0965081915/ref%3Dnosim/janaxelsonslakev/102-0239159-1129769 John From mcs at astro.caltech.edu Thu Mar 10 15:04:47 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Thu, 10 Mar 2005 12:04:47 -0800 (PST) Subject: [Gb-ccb] EPP specs In-Reply-To: <16944.40554.643789.267677@gargle.gargle.HOWL> References: <423079B3.8080607@nrao.edu> <16944.40554.643789.267677@gargle.gargle.HOWL> Message-ID: Hi John, On Thu, 10 Mar 2005, John Ford wrote: > This is IEEE Standard #1284, which can be obtained from IEEE for > some money, or maybe caltech's library has a copy. It turns out that the standards are online, and that Caltech has a site license for accessing them. When Tim told me about this yesterday, after the telecon, I downloaded and read the IEEE 1284 spec. The result was that I discovered that the descriptions of the EPP protocol that I had previously found online, and in a PC-internals book, have errors and omissions that resulted in my EPP handshaker circuit not conforming to the timing requirements of the official spec. In particular, all of the references that I had found implied that at the end of a transaction, an EPP peripheral could hold the EPP WAIT signal high indefinitely, to stop the host from starting a new transaction until the peripheral was ready, whereas the official spec says that this signal must return low within 125us of the data and address strobes being deasserted by the host. For example, at: http://www.fapo.com/eppmode.htm the timing diagram for EPP write-cycles, and the description that follows it, indicate that the WAIT line must not be returned low until after the active-low WRITE signal is deasserted by the host. This is the reverse of what the IEEE spec says. Later on, in the same web page one finds the following: "pre-1284 EPP devices deviated from the 1284 protocol. At the start of the cycle, the nDataStrobe or nAddrStrobe would assert regardless of the state of the nWAIT signal. This means that the peripheral could not hold off the start of a cycle by having nWAIT deasserted." Although this paragraph is technically correct, it is misleading, especially in the light of their incorrect timing diagram, since it omits to say that the hold-off can only last 125ns. Other sources of information that I was using simply ommitted saying when the WAIT line was supposed to return high, so I used the information at the above site to design my handshaking circuit. Anyway, the fix is straightforward. What's more it actually simplifies my circuit, because in order to conform to the erroneous timing sequence given at the above web site, which required me to hold the WAIT signal high until after the host had deasserted the WRITE signal, I had to use sequential logic to resolve an otherwise ambiguous concurrent logic state, whereas conforming to the official IEEE spec only requires concurrent logic for the handshake. Thanks for the information. Martin From rlacasse at nrao.edu Fri Mar 11 16:21:25 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Fri, 11 Mar 2005 16:21:25 -0500 Subject: [Gb-ccb] Updated schedule available Message-ID: <42320BD5.6020102@nrao.edu> All, An updated schedule is available at http://wiki.gb.nrao.edu/bin/view/Projects/CcbDesignArea The main changes from the last one are the following: 1 - added per-cent completion to relevant tasks 2 - delayed the completion of the daughter card task to reflect recent delays. 3 - delayed the completion of the master card schematic by 2 weeks based on new estimates by Randy. 4 - added 2 weeks of dead time between the completion of the master card pcb and the start of the chassis design to account for time that Randy must spend on the detector amps. 5 - added M&C support (last two tasks) One of the 2-week delays was in the critical path. This will result in our testing starting later this summer and the project being scheduled to finish up two weeks later, on 12/22. Rich From rlacasse at nrao.edu Mon Mar 14 09:45:35 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Mon, 14 Mar 2005 09:45:35 -0500 Subject: [Gb-ccb] Daughter Card Schematics Message-ID: <4235A38F.3070407@nrao.edu> All, Updated daughter card schematics are now available on the wiki at http://wiki.gb.nrao.edu/bin/view/Projects/CcbDrawingsAndSchematics Rich From rlacasse at nrao.edu Mon Mar 14 10:04:43 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Mon, 14 Mar 2005 10:04:43 -0500 Subject: [Gb-ccb] Updated schedule available In-Reply-To: References: Message-ID: <4235A80B.6010703@nrao.edu> Brian, Brian Mason wrote: > I have one question on the schedule: can we compress "production"? > currently it starts 14sep and goes until early december, at which point > commissioning starts. I'm not sure the assumptions that go into "testing" > but could we test on what is more or less a full unit, and commission > that? This might require some work done in parallel (like chassis testing > & assembly) You point out an oversight on my part. In the rev. 6 schedule, Chassis Assy (task 98) is dependent on the previous task 97, MC and DC cards delivered. In practice, much of these two tasks can go on in parallel. We should be able to gain some time there. I think we could also gain some time by starting the purchasing of master card parts sooner in the schedule, like right after the schematic is done. With a little bit of judicious shopping we can probably save part of (most of?) the month we spend waiting for parts to show up (task 50). I can see advantages both ways but would hate to miss two > months of precious high frequency conditions, especially since in the same > season we will be commissioning the Penn Array, and guest observers will > also want high frequency nights. On the other hand, our budget is tight, so we can ill afford to take risks that will cost us later. For instance, if we commit to getting cards built and then find in later testing that some changes are required to get the performance we need, we stand a chance of over-running the budget. In general, we have to be pretty sure of ourselves before we commit money. Rich > > -Brian > > On Fri, 11 Mar 2005, Tim Pearson wrote: > > >>Hi Rich, >> >>Thanks. We may want to reconsider Cristobal's dates in the light of >>this. I hope he can be at GB for some of the performance tests. >> >>Tim >> >>On Mar 11, 2005, at 1:21 PM, Richard Lacasse wrote: >> >> >>>All, >>> >>>An updated schedule is available at >>> >>>http://wiki.gb.nrao.edu/bin/view/Projects/CcbDesignArea >>> >>>The main changes from the last one are the following: >>> >>>1 - added per-cent completion to relevant tasks >>> >>>2 - delayed the completion of the daughter card >>> task to reflect recent delays. >>> >>>3 - delayed the completion of the master card schematic by 2 weeks >>>based on >>> new estimates by Randy. >>> >>>4 - added 2 weeks of dead time between the completion of the master >>>card pcb >>> and the start of the chassis design to account for time that Randy >>>must >>> spend on the detector amps. >>> >>>5 - added M&C support (last two tasks) >>> >>>One of the 2-week delays was in the critical path. This will result >>>in our testing starting later this summer and the project being >>>scheduled to finish up two weeks later, on 12/22. >>> >>>Rich >>>_______________________________________________ >>>gb-ccb mailing list >>>gb-ccb at listmgr.cv.nrao.edu >>>http://listmgr.cv.nrao.edu/mailman/listinfo/gb-ccb >> > From mcs at astro.caltech.edu Wed Mar 16 20:30:45 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Wed, 16 Mar 2005 17:30:45 -0800 (PST) Subject: [Gb-ccb] Slave FPGA pinout report Message-ID: I have entered the revised pinout for the slave FPGA, and got the number of warnings fromt he place&route program down to zero. There were no warnings from the pinout assignment program, this time. However I would take that with a pinch of salt, because it turns out that the pinout assignment program doesn't actually base its warnings on a knowledge of the Spartan-3 FPGA. Instead, it turns out that there is a configuration parameter that tells it when to complain, and the default value of this paramater, which appears to be specific to an older virtex device, isn't relevant to the Spartan-3. Furthermore, this parameter doesn't have a form that is compatible with the SSO guidelines of the Spartan-3, so I can't simply set it to a more appropriate value. In other words we were lucky to get a heads-up on the SSO problem before. Accomodating the revised pinout for the master will take me a bit longer, since I have to first modify the firmware to handle the new "Ground bounce mitigation" pins. I'll get this done ASAP. Martin From rlacasse at nrao.edu Thu Mar 17 09:40:58 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 17 Mar 2005 09:40:58 -0500 Subject: [Gb-ccb] Meeting minutes Message-ID: <423996FA.3040803@nrao.edu> All, Minutes for yesterday's telecon are now on the wiki: http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes As usual, please correct any mistakes you find, elaborate on points I short-changed or send me corrections and I'll take care of it. Rich From mcs at astro.caltech.edu Thu Mar 17 22:20:05 2005 From: mcs at astro.caltech.edu (Martin Shepherd) Date: Thu, 17 Mar 2005 19:20:05 -0800 (PST) Subject: [Gb-ccb] Master FPGA pinout assigned Message-ID: I have now entered the revised master-FPGA pinout, and placed and routed the design using this. There were no apparent problems (apart from the xilinx schematic editor crashing and losing half a day's work at one point!). Martin From rlacasse at nrao.edu Thu Mar 24 09:02:10 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 24 Mar 2005 09:02:10 -0500 Subject: [Gb-ccb] Meeting minutes Message-ID: <4242C862.8070507@nrao.edu> All, Minutes for yesterday's meeting are available at the usual place: http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes Please forward corrections to me or edit them in yourselves. Thanks, Rich From rlacasse at nrao.edu Thu Mar 31 11:33:49 2005 From: rlacasse at nrao.edu (Richard Lacasse) Date: Thu, 31 Mar 2005 11:33:49 -0500 Subject: [Gb-ccb] Meeting Minutes Available Message-ID: <424C266D.3080604@nrao.edu> All, Minutes of yesterday's meeting are available at http://wiki.gb.nrao.edu/bin/view/Projects/CcbTeleconNotes As usual, please feel free to edit these yourselves or pass corrections on to me. Thanks, Rich