PROWESS_FAQ_20221026.pdf

Processor Reconfiguration for Wideband Spectrum Sensing (PROWESS)

HR001123S0006

Frequently Asked Questions (FAQs) Published 10/26/2022

Proposers Day, FAQ, abstracts, and proposal submissions

1. Q: Are proposers day slides and attendance lists available?

A: Proposers day materials are posted to SAM.gov and also to the www.darpa.mil (under “Work with Us” => “Opportunities”) for convenience. The attendance list is appended to the end of the proposers day slides.

2. Q: Are FAQ questions posted anonymously?

A: Yes.

3. Q: If we submit an abstract will we be told whether we are on track or not?

A: DARPA will reply by letter to submitted abstracts with one of two possible responses:

(1) encourage full proposal, and may provide feedback, or (2) discourage full proposal, and will provide rational (BAA p. 43).

4. Q: What is the expected level of fidelity for the cost estimate in the abstract?

A: Per the BAA, abstract responses should provide a cost estimate for resources (e.g., labor, materials) and any subcontractors over the proposed timeline of the project, broken down by program phase (BAA p. 20). No substantiation of these estimates is required in the abstract.

Proposers may provide additional cost information at their discretion.

5. Q: Are multiple proposal or abstract submissions from the same organization allowed?

A: Multiple proposals or abstracts from the same organization are permitted. If multiple proposals or abstracts are submitted, each would be reviewed independently. If the proposed solutions are interrelated and cannot be evaluated independently, they should be combined into a single proposal or abstract. If the combined proposal includes multiple portions that could be partitioned for purposes of funding, identify these as options with separate cost estimates (BAA p. 30).

Teaming

6. Q: Should proposals address both technical challenges identified in the BAA?

A: Yes. If you have a technology solution for only one technical challenge, consider teaming.

7. Q: What is DARPA’s guidance on teaming?

A: DARPA encourages teams as needed to address the program goals and provide best value to the Government (BAA p. 8). As proposers consider teaming arrangements, DARPA recommends that proposers weigh the tradeoffs between offering diverse technical capabilities and the complexities of managing teams as they increase in size.

8. Q: Since PROWESS is a 6.2 program, are academic proposers encouraged to team with industry?

May academic organization propose fundamental research?

A: DARPA neither encourages nor discourages that academic proposers team with industry. If a proposer considers the prime or subcontractor effort to be fundamental research, proposals should include justification for this assertion (BAA p. 27). The Government has sole discretion to determine whether the proposed research shall be considered fundamental (BAA p. 16).

Program structure and scope

9. Q: Will DARPA be providing a total program budget, expected award value, or the total number of anticipated awards?

A: No.

10. Q: Does spectrum sensing include signal detection AND characterization?

A: Yes.

11. Q: May spectrum sensing workloads include both statistical signal processing AND machine learning, or only the former?

A: Both. Performers specify representative spectrum sensing workloads for their devices (BAA p.

10).

12. Q: Is the goal of PROWESS to develop reconfigurable processor where spectrum sensing is one of the many applications?

A: PROWESS focuses on spectrum sensing. Proposers are encouraged to identify additional high-impact applications that could diversify that transition of their solutions (BAA p. 8).

13. Q: What is the goal of Phase 1?

A: The goal of Phase 1 is to get processor design to the level of a preliminary design review (PDR), ready for tapeout early in Phase 2. The design should be grounded in risk reduction experimentation. See BAA p. 11.

14. Q: Is modeling and simulation of spectrum sensing in scope? Should this include mission-level modeling for specific DoD applications?

A: Performers are encouraged to develop models of spectrum sensing workloads to ground their architectural design decisions in the objective application (BAA p. 10). Mission-level modeling for specific DoD applications is not a focus of PROWESS, but such activities could be included as part of a proposer’s transition plan.

15. Q: May performers prototype their architectures using FPGAs in Phase 1?

A: Yes, this is considered a type of risk reduction experiment (BAA p. 11).

16. Q: May performers fabricate devices in Phase 1?

A: Yes. It is up to the proposer to define a specific constructive plan that meets program goals while incrementally reducing risk and providing the best value to the Government.

17. Q: Are performers required to include device fabrication in Phase 2? What if the program goals can be met with an existing device?

A: Phase 2 requires demonstration of real-time signal processing on a fabricated device (BAA p.

11). DARPA does not expect that Phase 2 goals can be met with existing devices. However, proposers may choose to offer solutions that use existing devices, but should provide a detailed rationale for why these solutions address PROWESS goals and meet or exceed metrics.

18. Q: Are performers required to use the same device in Phase 3 that was demonstrated in Phase 2?

A: Performers may plan to use their Phase 2 demonstration device for Phase 3, but are not required to do so.

19. Q: How important is it to implement and characterize specific complex algorithms in detail?

A: Performers are encouraged to develop models of spectrum sensing workloads to ground their architectural design decisions in the objective application (BAA p. 10). The level of detail of such models is up to performers.

20. Q: The BAA (p. 5) identifies three technology trends: uncertainty, increased bandwidth, and lower power signals. Do implementations need to address all three emerging trends?

A: DARPA intends these trends to motivate architectures, rather than define specific test cases or signal processing workloads. Proposers are encouraged to consider how their solutions can simultaneously manage uncertainty, scale to wide bandwidths, and support increased algorithm computational complexity.

21. Q: On page 9, the BAA states "approaches that address program switch time objectives through global context switching across a handful of preprogrammed options are strongly discouraged."

May solutions incorporate other kinds of preprogramming?

A: Yes. Solutions may incorporate preprogrammed options defined at compile time that can be switched at run time. Proposers are encouraged to detail the range of switching timescales their architectures support (BAA p. 21). The quoted BAA statement discourages approaches that can only meet program switch time metrics through highly constrained switching, e.g., ping-ponging a device between two (and only two) preprogrammed modes.

22. Q: May solutions incorporate advanced packaging or integration techniques, including 3D integration?

A: Yes, for existing techniques, but PROWESS does not intend to focus on new device packaging or integration methods (BAA p. 9). Solutions may include 3D integration, but compute density will be calculated as the average density across the component layers in the die or wafer stack (BAA p. 10).

23. Q: May solutions include FPGA or GPU-based processing elements?

A: Yes. However, DARPA does not expect that existing FPGAs or GPUs will meet program goals.

24. Q: May solutions include analog or photonic computing?

A: Yes. Proposals should provide rationale for incorporating these technologies, clearly articulating why they meet program metrics and align with PROWESS goals to create high-density processing arrays that switch at waveform timescales. As with any approach, proposals should detail key risks and mitigations for such solutions.

25. Q: May solutions include reconfigurable RF front-ends?

A: PROWESS focuses on reconfigurable receiver processing and is not expected to develop new reconfigurable RF front ends. However, performers may consider any impacts or synergies if runtime reconfigurable arrays (RTRAs) are integrated into RF systems with end-to-end flexibility (BAA p. 9).

26. Q: Is DARPA interested in solutions for multi-node sensor systems?

A: Solutions that scale to multiple nodes are potentially beneficial, but this is not a focus of the program.

27. Q: Are devices required to be radiation hardened?

A: No.

Metrics

28. Q: The compute density metric is stated for a 16nm CMOS process—is this process required?

A: No. 16nm was used to define the compute density metric and was not intended to be a requirement. Proposers are encouraged to use the process that demonstrates the capability of their architectures, enables transition to future receiver systems, and provides the best value to the Government. Each proposer should define a metric scaling factor for their device geometry.

29. Q: The compute density metric is stated for IEEE half-precision floating point operations—is this numerical precision required?

A: No. 16-bit floating point was used to define the compute density metric and was not intended to specify a requirement. Proposers are encouraged to use the precision that best matches the spectrum sensing workloads they identify. Proposers may define a mixture of precisions and/or have programmable precisions. Proposer should define a metric translation factor for their computational precision. This metric scaling discourages from decreasing precision to increase compute density at the expense of spectrum sensing performance.

30. Q: Will the Government provide standard scaling factors to 16nm IEEE half-precision floating point for different process nodes or numerical precisions?

A: No. DARPA anticipates a wide range of architectures could be proposed and does not want to constrain solutions to a pre-defined list. Proposers should report their compute density projections both unscaled and scaled and provide a rationale for their derived scaling factor.

31. Q: What is the required input vector size for vector operations?

A: The input is continuous streaming data from one or more receiver channels (BAA p. 12).

Proposers should determine whether to implement vectorization, and if so at what vector size.

32. Q: How was the compute density requirement derived?

A: The compute density goal was set to be challenging but achievable while balancing tradeoffs between compute density and switch time.

33. Q: What circuitry is included in the compute density metric?

A: Compute density metrics is measured across the complete RTRA system, including both the processing core and any support circuitry (BAA p. 9). Support circuitry will vary, but it is meant to include any design element that directly enables program switching, e.g., control logic, distributed memory, and on-chip networks. Depending on the specific solution, circuits such as on-die voltage regulators may be excluded if they do not play a role in the key PROWESS tradeoff between compute density and switch time.

34. Q: Are there objectives for overall processor area, power consumption, or thermal design considerations?

A: RTRAs are envisioned to replace or augment FPGAs in embedded environments, with comparable overall processor area, power consumption, and thermal constraints to these devices.

35. Q: How do we calculate compute density with a chiplet approach?

A: Measure the density over the total device area required to produce the final scaled solution.

36. Q: How does dark silicon impact compute density?

A: Dark silicon lowers compute density. A goal of PROWESS is to maximize the amount of time device silicon is employed for useful work.

37. Q: How are fixed-function circuits included in the metric calculations?

A: Fixed-function circuits must be included in the compute density and utilization metric calculations. Fixed-function circuits for universal “always on” processing functions may be considered when motivated by substantial metric improvements. Any such circuits included in proposed solutions should align with the PROWESS goal to prepare for environments whose characteristics are difficult to fully specify at design time (BAA p. 9).

38. Q: What is the motivation for 50 nanosecond program switch time metric?

A: A key PROWESS goal is to adapt at waveform timescales, measuring part of a signal and reconfiguring the processing pipeline based on that measurement. Switching times of 50 ns support this capability.

39. Q: Is 50 nanoseconds an average goal for program switching?

A: The program switch time metrics is for the minimum switch time supported by the architecture. RTRAs may support multiple program switch mechanisms, and are not penalized if some of these mechanisms operate at slower timescales.

40. Q: How does program switching yield processor throughput gains?

A: Throughput gain is defined as the system bandwidth increase from time-multiplexed processing pipelines while maintaining consistent probability of detection for important signals.

Switching rapidly aligns processing resources to sensed signal environment; redeploying resources assigned to unimportant tasks to increase throughput on important signals.

41. Q: Is external autonomous decision logic included in the 50 nanosecond program switch time?

A: No. Program switch time is measured from when a decision is made (either internal or external to the RTRA) to when decision outcome begins execution.

42. Q: How is a task or program defined?

A: Example tasks include an FFT or a FIR filter. Proposers may define different levels of task granularity depending on their architectures.

43. Q: Why are 100 tasks specified in processor utilization metric?

A: This is a nominal objective derived from the number of important signals that may be concurrently active in the environment. This is intended as a guideline; proposers may derive alternate objectives for the task granularity they define.

44. Q: Following a program switch, do processing elements keep operating on the same data or different data?

A: Processing elements operate on continuously streaming data. Performers are encouraged to use models of spectrum sensing workloads or other methods to derive their data flow requirements (BAA p. 10).

45. Q: Does the goal of 40 GHz input bandwidth refer to a single channel?

A: Not necessarily. This is the total input bandwidth and is the number of receiver channels multiplied by the bandwidth per channel. This could be a single 40 GHz channel, or spread across multiple channels, e.g., a 5 GHz bandwidth per channel for each of eight antenna elements.

46. Q: Does Phase 2 need to demonstrate metric performance or show that metric performance can be achieved in Phase 3?

A: Metrics are intended to be demonstrated on devices with real-time streaming data by the end of Phase 2 (BAA p. 8). Proposers are expected to develop their own constructive plans that align with BAA goals.

Software

47. Q: Which is more important to PROWESS, hardware or software development?

A: Both are important. PROWESS seeks to develop new devices, but expects these devices to be highly reprogrammable. Software development is expected to play a critical role in successful demonstration of these new devices for spectrum sensing workloads.

48. Q: May performers use open-source software? May performers publish software developed under PROWESS as open source?

A: Performers are encouraged to maximize the use of free and open-source software (BAA p.

11). Performers may publish PROWESS software as open source subject to the publication restrictions included in their award instrument (BAA p. 15-16).

49. Q: What maturity of software tools is expected?

A: Performers are encouraged to develop software tools to the level needed to demonstrate RTRA functional and metric performance. Software tools need to be sufficiently stable and complete to support third-party application development in mid Phase 2 (BAA p. 13). However, performers as not encouraged to invest in mature tools suitable for end users.

50. Q: Should proposers develop software that is portable to different hardware devices?

A: Software portability is not an explicit program goal. At their discretion, performers could use hardware-software co-design to improve metric performance at the expense of software portability. However, software portability could facilitate the transition of PROWESS technology.

51. Q: Will the government provide common benchmarking software for apples-to-apples comparisons of solutions?

A: DARPA expects a diverse set of processing architectures that would be difficult to align with a common set of Government-provided benchmarks. Performers should plan on providing benchmarking software aligned with their architectures. In Phase 1, the Government may provide data and/or benchmarking software; in Phase 2, the Government will provide streaming digital environment data and autonomous RF decision software as GFI (BAA p. 11).

52. Q: Does the Phase 2 GFI software assume a specific processor architecture?

A: Proposers may assume that GFI software runs on a general-purpose processor. During Phase 1, DARPA and performers will collaboratively define the execution environment and interfaces for this software (BAA p. 11).

53. Q: If performer software incorporates artificial intelligence or machine learning, will the Government provide training data?

A: No. Performers are responsible for any training data needed by their solutions.

Applications and use cases

54. Q: What types of RF sensing functions does PROWESS require?

A: It is up to proposers to define specific spectrum sensing workloads that align with the PROWESS goal to detect and characterize complex and uncertain waveforms in dense environments (BAA p. 6). Such functions may include detection, frequency and spatial separation, parameter estimation, classification, and tracking (BAA p. 10). These workloads may include multichannel processing, e.g., beamforming or spatial demultiplexing. Developing end-to-end communication systems is not a PROWESS goal; correspondingly, performers are not expected to demonstrate such functions as demodulation or forward error correction.

Proposers may note if their architectures are capable of supporting these or other additional functions for future applications.

55. Q: Are there specific signals of interest?

A: No. PROWESS goal is to address future environments that include many autonomous RF systems capable of operating across many waveform types and frequencies. Such environments may include communications, radar, and multi-function RF systems (BAA p. 10).

56. Q: Are there target frequency bands of interest?

A: No.

57. Q: Are you targeting specific spectrum sensing applications, e.g., dynamic spectrum access

(DSA)?

A: No, though DSA could be considered a representative application.

58. Q: Is PROWESS intended to address specific missions, or transition to specific mission partners?

A: No, but proposers are encouraged to identify specific missions and transition partners relevant to their solutions.

System Integration

59. Q: The BAA states that maximizing detection of important signals is a PROWESS goal. How are important signals defined?

A: Important signals are signals that drive the decision making of autonomous RF systems (BAA

p. 7). Autonomous RF decision software defines which signals and measurements are important by providing a real-time policy to the RTRA subsystem. These policies define the relative importance of signals and signal measurements, and RTRA real-time schedulers are expected to implement these policies. For example, the decision software may indicate it is especially interested in OFDM modulated signals, and if the RTRA detects such a signal it should make certain detailed measurements. Policies may change over time in response to dynamic environments.

60. Q: What is the interface to inform RTRA schedulers that a specific signal type is important?

A: In Phase 1, performers are expected to collaborate with the Government to define the policy interface between RTRAs and the autonomous RF decision software that describes important signals (BAA p. 11).

61. Q: Are high-level decision agents expected to be part of the solution?

A: PROWESS is not focused on inventing new intelligent agents, only showing that solutions respond to dynamic prioritization from such agents leveraging existing decision logic (BAA p.

10).

62. Q: Will the autonomous RF decision software be provided?

A: Such software will be provided as GFI in Phase 2. This is in addition to any decision logic software developed by performers for internal benchmarking purposes (BAA p. 11).

63. Q: Do we need to be account for the timelines required by the decision agent?

A: The autonomous RF decision software operates on timescales much slower that program switching in the RTRA. While the policies this software generates will change, they will change much slower than the program switch time.

64. Q: The BAA says DARPA will work with performers in Phase 1 to integrate interfaces for digital streaming data. Are there specific constraints on these interfaces?

A: Performers are free to propose any interface that aligns with program goals to support future integration of analog to digital converters (ADCs). DARPA favors standards-based approaches. Interfaces may be specific to each performer’s solution.

65. Q: Are we expected to do data conversion from fixed to floating point format on the input data stream?

A: Assume that in Phase 2 GFI test data will be provided in the format you require. In Phase 3 devices would need to interface with ADCs.

66. Q: May solutions change the ADC rate change to match the signal of interest?

A: Expect a high-rate ADC with bandwidth greater than an individual signal of interest to continuously sense across wide bands. Performers may incorporate mechanisms to change ADC or other RF front-end parameters if they choose.

Devices and Fabrication

67. Q: Is there a preference for integrated devices or chiplets?

A: No. Proposers should offer the approach that provides the best value to the government while managing technical, cost, and schedule risk (BAA p. 10).

68. Q: If using a chip-based approach, does each chiplet need to support 100 tasks?

A: No. The complete integrated system is expected to support 100 tasks, i.e., the goal bounds the scheduler not chiplet size.

69. Q: How many tape-outs should be included?

A: Proposers should plan on the number of tape-outs that provide the best value to the government while managing technical, cost, and schedule risk. DARPA anticipates there will be at least one tape-out in Phase 2.

70. Q: How much feedback do you see Government experts providing into the architecture?

A: While the Government will review the architecture at quarterly review, performer teams should bring enough internal expertise to make good architectural choices for spectrum sensing applications.

71. Q: Does DARPA have any preferences or constrains on foundries, e.g., domestic foundries only?

A: No, performers may use any foundry. Performers are responsible for adhering to all applicable export control regulations.

72. Q: Is DARPA separately funding access to fabrication run or does fabrication need to be fully costed by proposers?

A: Fabrication should be fully costed by the proposers.

73. Q: Does the government plan to provide performers access to large-scale ASIC emulators?

A: No. Performers are responsible for any simulation or emulation of their architectures.