Valerie Taylor: Okay, I think I'm in the right one. I'm the only one here so far.
Valerie Taylor: Let me just see.
Valerie Taylor: Yeah, this is the one.
Valerie Taylor: But I let's see if others join.
Valerie Taylor: Yes, there we go.
Valerie Taylor: Hello.
Christian Mailhiot (Sandia): Hello!
Valerie Taylor: Hi.
Valerie Taylor: okay, sweet is when I reported.
Paul McIntyre: Hey! Valerie?
Valerie Taylor: Hi, Paul, how are you?
Paul McIntyre: Doing? Well, thanks. How about yourself?
Valerie Taylor: I'm doing well.
Paul McIntyre: Good.
Valerie Taylor: S.
Valerie Taylor: Hi, mark.
Mark Hersam: Hey, Valerie, how you doing.
Valerie Taylor: Good. So Salmon and I are at the Tpc. Meeting in San Jose.
Mark Hersam: Gotcha.
Valerie Taylor: Yes.
Valerie Taylor: I'm gonna take off my name.
Valerie Taylor: Oops.
Valerie Taylor: Great.
Valerie Taylor: But yeah, just put everybody's. I think you're right. I did this.
Valerie Taylor: So I in my slide. I didn't see what you were referring to. Oh, see right here.
Valerie Taylor: and then see?
Valerie Taylor: Oh, man, okay, thank you.
Valerie Taylor: And then I took out.
Valerie Taylor: You have one here, too. So
Valerie Taylor: and then I have this with Andrew.
Valerie Taylor: Okay.
Valerie Taylor: oh.
Valerie Taylor: let me make it
Valerie Taylor: all right. Let me know.
Valerie Taylor: Let's see, Andrew.
Paul McIntyre: Well, we're we're 5 min in Valerie, I think. Should we get started.
Valerie Taylor: We can. We can start whenever you're ready.
Paul McIntyre: Great. Thank you.
Valerie Taylor: Okay, so I'll go ahead and bring up my slides. And so
Valerie Taylor: let's see, are you able to see my slides and let me just
Valerie Taylor: bring it up in presentation, mode.
Paul McIntyre: It looks good.
Valerie Taylor: Okay, so that's good. And we have the the Bea leadership here as well. So we'll do a team presentation. So thank you. So we're happy to present to Meerkat in terms of the center about Bia, let me just
Valerie Taylor: okay. And that's looking at a co-design methodology to transform materials and computer architecture research for energy efficiency. So Bia is not an acronym for the project, but just the name of the project. And it's because it's a Olympian goddess for power and energy.
Valerie Taylor: So, and just in terms of a little bit more about what we want to do.
Valerie Taylor: So I'm going to just give an overview of the project. And then within Bia we have 3 thrust, and that's the application thrust, simulation and architectures, thrust and materials and devices. And so Solomon is going to talk about the application. We also have Andrew to talk about simulation and architectures, and then mark with the materials and devices.
Valerie Taylor: So just to give an overview of the Bia team. So we have excellent researchers that really reflects a multidisciplinary aspect of the Bia project. And that's where we have researchers from Argonne, also University of Chicago, Northwestern
Valerie Taylor: Fermilab, as well as Rice University. So a great team that covers all the areas of materials to architectures, to also system software as well as the applications.
Valerie Taylor: So just in terms of that overview. When we look at end-to-end co-design, we look at it in terms of having that opportunity to really frame the way we do research in devices and materials. And so if we go back to the 2018 Brn report, where we had all those different levels of the stack
Valerie Taylor: going from. And that's the design stack going from materials and chemistry all the way up to applications.
Valerie Taylor: It's recognized that it's often the case that we are aware of the relationships between adjacent layers of the stack. But when it comes to non adjacent levels of the stack. That's where there's complications in terms of really understanding direct relationships between non adjacent
Valerie Taylor: levels of the design stack. And by that meaning to look at the metrics and features that are important between those non adjacent levels, because oftentimes, if you go between from one level just to the adjacent to the next level. Some information or some aspects may be lost. But you want to have that direct relationship.
Valerie Taylor: also understanding to the technologies involved and how they're being used by again that non-adjacent level and then representing those relationships.
Valerie Taylor: As cost functions. And so those are some of the challenges that we're looking at with respect to the be a project.
Valerie Taylor: And let me ask Paul if you can let me know if we have any questions, because I I can't see the the questions.
Paul McIntyre: Will do no questions yet.
Valerie Taylor: Okay, thank you. And so what we want to do in terms of understanding those relationships with non adjacent layers that we hypothesized that if we look at the co-design for 2 vertical design problems, we can use that to
Valerie Taylor: identify and develop a co-design methodology that can be that can be tailored to other vertical design problems. And so here, that's where we're looking at our approach of producing innovative devices, architectures, algorithms that's really tailored to DOE science
Valerie Taylor: so just to talk a little bit more about the design problems, the 2 vertical design problems.
Valerie Taylor: They're both focused in the area of detectors.
Valerie Taylor: And so the reason for focusing on detectors is that it's recognized within the next 2 decades that there'll be 3 orders of magnitude increase in the data rates. And that's in the data that's being produced by the detectors. And so we look at 2 particular design problems.
Valerie Taylor: And one is related to data reduction where you're identifying the important features with that data reduction and looking at the transport of that reduced data. And that's for both high energy physics and X-ray science type detectors. So 2 different types of detectors
Valerie Taylor: and then related to X-ray science. We're looking at the ability to have some steering, and that's where where we can do some analysis close to the detectors. So we can have the feedback. And we're looking at with those 2 design problems, looking at that in terms of from materials all the way up to applications for our co-design approach.
Valerie Taylor: So when we look at that, just to go a little bit more into detail with the co-design methodology, we recognize that it's a continuous process. So that while we apply the co-design methodology to those 2 different problems that it's important that we continuously look at
Valerie Taylor: what we're doing and how we're translating features from one level to another level that's not adjacent.
Valerie Taylor: And so we're extracting those important features that are important across the stack and developing those cost models. And we're looking at in having those cost models. It allows us to explore trade-offs, and it may be
Valerie Taylor: trade-offs between performance with power, also size, accuracy. And when we look at performance, that's where we're looking at different metrics. Those metrics can be. For example, data rate, it can be latency. It can be time, so different aspects that we're considering it could also be the use of memory.
Valerie Taylor: So with our different resources. So that's going into a little more details about what we mean with the co-design.
Valerie Taylor: So when we look further at the objectives, that's where 1st we have 2 objectives, one in terms of looking at those 2 vertical design problems where we're making advances at all the levels in terms of materials, devices, computational architectures.
Valerie Taylor: exploring, you know, different type of architectures as well as the software, to map with the applications to enable new applications and also radically improved energy efficiency.
Valerie Taylor: Then, in addition to solving those 2 design problems. That's where we're looking at. Also that co-design methodology of translation between non-adjacent levels of the design stack.
Valerie Taylor: So just to go a little bit more into detail about each area. So, for example, with the he with the applications area, we're looking at high energy physics, X-ray science.
Valerie Taylor: Where, when we look at the increasing data rates, what does that mean in terms of the advances needed in materials? What does that mean in terms of advances needed in the communication capabilities, the computing system, the algorithms.
Valerie Taylor: And you know, there's a need to also do at sensor data reduction and doing that sensor to feature, extraction and some analysis, so that we can go back and do the steering.
Valerie Taylor: And also when we look at that aspect of the applications we'll talk about in a moment. What does that mean with different levels? And as we have different architectures, what does that mean in terms of the applications and what they could do differently, that they're not doing. Now
Valerie Taylor: when we look at simulations and architectures, that's where here we're leveraging new materials and devices where we're looking at many different levels, the circuits.
Valerie Taylor: the interconnects, the computing components we're also looking at. In addition to the computing components, the software models. And so here, we're looking at those aspects to divine, to define new hardware and software computational architectures. And then we're looking at optimizing across those components focused on the energy efficiency.
Valerie Taylor: When we go to materials and devices. That's where there's work that's currently focused on neuromorphic materials and devices. And that's meeting the needs having to do with low power data reduction. But we're also exploring materials and also photonic design related to optical interconnects.
Valerie Taylor: Then, if we start to look at now, some of those relationships. That's where we're translating, for example, what's needed with the application requirements into what does it need in terms of the different computational components. What does that mean in terms of also how algorithms are mapped to those components. So the system software.
Valerie Taylor: then there's also the feedback about algorithms that are used with respect to detectors, it may be where, depending upon the components we have, we should utilize different type of algorithms to better utilize those components. And again, now that we're looking at those relationships, always looking at the cost functions to explore the trade-offs.
Valerie Taylor: Then let's just look at, for example, the co-design approach between, for example, the simulation and architecture, level and materials and devices. And that's where we're looking at, you know. What does it mean in terms of the characterization of the materials that's used for the devices. How does that translate into the computational components?
Valerie Taylor: Then, with respect to the system software requirements, what does that mean in terms of the computational components that are being used.
Valerie Taylor: And then there's again those cost functions coming up as we express the relationships.
Valerie Taylor: Then, lastly, just want to mention between application and material and devices. And this, again, the question that comes up is, as we look at the future needs, especially in terms of the detectors. What does that mean in terms of materials and devices? Are there some unique aspects and pain points
Valerie Taylor: with respect to those detectors that's looking in terms of the future needs that can actually be aided by
Valerie Taylor: research in the material space. Then we also have again those cost models to represent those relationships that can be used to explore the trade-offs.
Valerie Taylor: So now, just to use one example, and let's say, with the X-ray science steering, so as we have to do the steering. The question that comes up is, what's the computational load in terms of the feature extraction that's important to actually look at the steering. What does that mean in terms of latency?
Valerie Taylor: What does that mean in terms of compute if we're doing it close to the sensors? What does that mean in terms of power requirements.
Valerie Taylor: How does that translate? Then, in addition to the compute, we're also having to look at, how does that translate in terms of the transfer of data between the different components. So that relates to our interconnect technology.
Valerie Taylor: And so what does that mean? Also are the different algorithms that we can explore to help us with that feature extraction that's used to help us with the steering. So we recognize that this process of co-design of going between these different levels is iterative. And it's also a continuous process.
Valerie Taylor: And so just to note we are leveraging our work that was done with thread work where with thread work which was a previous co-design project. It focused on high energy physics detectors, but it was with simple geometries
Valerie Taylor: and the analysis focused on one D data. And so some of the outcomes we on the material side, there was research that resulted in a dual gated, mixed kernel heterojunction transistors that was used with Hep detectors.
Valerie Taylor: We also had some initial development of system flow, and we'll hear about that in a moment to do more analysis that connects materials and Hep detectors.
Valerie Taylor: Then we also developed some tools like spikelearn and Remsistor spikelearn to really explore spiking neural networks. But then, with the Memristar spikelearn it was going down to incorporate different materials that are used with neuromorphic devices. And so now that helped us to be ready for a more
Valerie Taylor: complex vertical design and incorporating the goal of documenting that process
Valerie Taylor: so just to note the impact, looking at different materials and new devices, also demonstrating the use of those devices and addressing the Hep and X-ray science detectors and looking at developing that end-to-end co-design methodology
Valerie Taylor: and also working within the Meerkat center.
Valerie Taylor: So with that, I'm going to turn it over to Salman to talk about the applications thrust, and just want to quickly see if there were any initial questions.
Valerie Taylor: Okay, then we'll continue with salmon. All right, thanks, Valerie, so I'll just sort of give a more
Valerie Taylor: the perspective from the application side, because a lot of the flow down requirements come from the application. And then, of course, there's a loop. So the applications can also change, depending on what comes back from below. So I think it's important. So we have a team here. Nantron from Fermilab is a high energy. Physics lead and tejas. Kuruswami from Aps is the Xrs lead on this, so can you move on to the next slide.
Valerie Taylor: So the applications for detectors are very diverse, as you can imagine. So that's because the detectors are extremely diverse. So if you go to the large Hadron Collider, or generally Hadron colliders in principle, where what's happening is, you are basically colliding 2 beam punches in a high energy physics beam and.
Paul McIntyre: Could you please mute your yourself if you're not presenting.
Valerie Taylor: So so in the case of a high energy physics, Collider, basically, the the detectors are
Valerie Taylor: pages.
Valerie Taylor: Oh, your microphone is on. Okay.
Paul McIntyre: Muted.
Valerie Taylor: Okay, thank you.
Valerie Taylor: So in the case of a high energy physics detector, when you're working with colliders, you basically have a detector that covers the interaction region. And what happens is that in a Hadron Collider it's a very, very messy interaction, and every bunch crossing you can have something like 50 to a few 100 separate proton proton collision. So that gives, you.
Valerie Taylor: you know, extreme particle densities, radiation doses and large raw data rates. So you basically cannot actually look at the entire data set you have to do triggering and so forth. The other kinds of colliders that we have in high energy physics are. Of course, you know, electron colliders where you now have point particles that are in the collision. And so that's a lot cleaner. And the detector design process is completely different.
Valerie Taylor: Another thing that's of interest in the future are Muon colliders. So Muon colliders are also Lepton colliders. So they have the same in principle, clean interaction. That is what happens with electrons. However, muons are
Valerie Taylor: not stable particles in the muon ring, they decay. So what happens is, you also have what's called a beam induced background or bib, which can be extremely problematic in the detector. So you have to take care of that. So
Valerie Taylor: and the Xrs. The X-ray detectors are obviously X-ray detectors, so they don't have. They don't necessarily cover the interaction region. Obviously, but they are more like cameras. And but the next generation. Detectors
Valerie Taylor: have extremely high throughputs, and the throughput rates are looking very similar to current generation. High energy physics detectors. So all of these detectors have these very strict requirements, and I don't have time to go into detail. The other thing that's mentioned on this slide is simply how much power it takes to run these facilities which
Valerie Taylor: obviously most of the power goes into the accelerator. But nonetheless it gives you an idea of how large things are on the high energy physics side, and also from the light sources.
Valerie Taylor: So when you are designing something for these detectors, as I mentioned, they have commonalities, but they also have quite a bit of differences. So there's a very diverse sort of design parameter range that you have to consider next slide next.
Valerie Taylor: So
Valerie Taylor: so, for example. Now, if you look at the current power requirements or Hep directory electronics, there's about 2 megawatts for Atlas and Cms at Lhc. And if you look at this figure on the right. That sort of gives you an idea of where things are
Valerie Taylor: for the beer applications at the level of the sensors. What the data rates are is on the Y-axis. What the computation time requirements are is on the X-axis, and we're headed into the left future corner, and which are like really, really extreme data rates, as you can imagine. So this means that you can't have obviously a simple approach for handling this. It has to be hierarchical in the sense that you have very close decision making at the edge and then followed by multiple layers of data, analysis and rejection.
Valerie Taylor: So the other important point is that if you have all of this data, motion and all of this compute, and something like a 3 orders of magnitude, improvement in the throughput that is almost linearly adding to the power cost which
Valerie Taylor: obviously it's unrealistic. You cannot have that just for the detectors, but it does mean that you need a new co-design approach to handle some of these things. Now, for
Valerie Taylor: the other important point is that for Xrs
Valerie Taylor: as distinct from Hep Hep, the directors are essentially static, meaning that you have lots of collisions. But you're not changing the detector on the fly. You're not actually changing a sample positioning or anything like that which you might do with a light source. So there's that other difference there that the closed cycle time scale for interaction with an Xrs detector are much shorter.
Valerie Taylor: So even though the individual
Valerie Taylor: time analyses are maybe easier. The fact that you have to react in real time makes it harder.
Valerie Taylor: So so we have to take into account all of these numerical issues and technical issues in in designing the co-design approach. So next slide.
Valerie Taylor: So the detector structure is very, very crudely speaking, is you have a sample in the case of an Xrs detector, and in the case of a collider is actually a collision. Right the beam collision. And then that is read off by a detector. And then they're often computing extremely close detector, which is what we're calling edge computing.
Valerie Taylor: Then that communicates to online computing, which is also very close. And then data is further reduced. Maybe you know, various kinds of choices are made, and then it goes to offline which could be large forums which could be.
Valerie Taylor: you know, so online and offline computing could be some combination of Gpu and CPU, or it could be specialized architectures, asics, etc. And those things are also going to happen at the edges. So this is where this is kind of the design space that you have to kind of figure out and optimize the detector, as I mentioned, have to be composite because of the data rates being so high and they come in different levels. So level one trigger is Asics and Fpgas and I just put some power numbers here just to give people an idea.
Valerie Taylor: The rejection factor is simply how much of the data that you are rejecting
Valerie Taylor: at the level of the trigger.
Valerie Taylor: Then high level triggers follow level. One triggers, the rejection factors there are even higher. And once again, these numbers are notional. Just to give you an idea of what they are.
Valerie Taylor: There are different kinds of readout electronics again, implemented in different ways. And so there's a lot of design space here to optimize. Basically, that's the important thing to keep in mind.
Paul McIntyre: There's there's a question by Chris Gores.
Grzegorz_Deptuch: Yes. Can you hear me?
Paul McIntyre: Yes.
Grzegorz_Deptuch: Okay? So I have questions looking at this slide, the most important question is
Grzegorz_Deptuch: in high energy physics detectors, when you have a detector plane
Grzegorz_Deptuch: somewhere embedded in the whole detector system. That is, you know, gigantic.
Grzegorz_Deptuch: The problem of such detector plane is that it doesn't have any information of the entire topology of events.
Grzegorz_Deptuch: So edge computing in such applied at such low level, you know, cannot be used effectively for generating high level.
Valerie Taylor: Well, the edge computing is not designed to do anything like that. It's essentially a rejection system that you're using very quickly.
Grzegorz_Deptuch: Detection system, but based on what? Because, you know, if you have just few hits in the plane of the detector that you are showing, you know, just receiving the signals. You know these hits are sparse in into the plane points, and the only.
Valerie Taylor: Well, this is not a 2D. Sorry. This is a very confusing picture, because high energy physics detectors are not 2D. Right. I mean, they're extremely complicated. So if you look at for something like something like Atlas, or something like Cms, they, you know, they have calorimetry. They have.
Grzegorz_Deptuch: Yes, of course I I think I'm quite aware of that. So this edge computing sits outside of Detector Block like.
Valerie Taylor: No, it's inside the detector.
Grzegorz_Deptuch: Okay? So you are, you are back to. My question
Grzegorz_Deptuch: is inside a detector. You don't have context to do any high level processing. How would you.
chris kenney: So so in a calendar, for instance, could you tell? There's a jet from a single plane or not that it's necessarily a plane even. But so for tracking, for texting, you're probably right. But the parts of the detector system, it's not clear that you couldn't provide useful information.
Grzegorz_Deptuch: It's still, you still need to collect data from certain
Grzegorz_Deptuch: volume, certain area. This, this is what I mean. I'm asking this educate effectively myself, because many, many of us are proposing similar kind of things things and approaches to computing.
Grzegorz_Deptuch: And then at least myself, I thought that in order to perform meaningful computation. You still need to have a context and information about the jet. You know it can. It doesn't come from one segment of the detector. It has to be.
Valerie Taylor: No, it doesn't come from one segment. No, I.
Grzegorz_Deptuch: How would you? How would you? How would you answer? Such, you know, challenge that you have to have a context.
Valerie Taylor: So I mean, I kind of agree with the fact that you need some sort of context. But the point also is that you want to bring computing as close as possible. So other, because otherwise it's a matter of like how much data you're going to push to further down the line
Valerie Taylor: where you are not. So so that makes the detector even more complicated. So the question is as much computing as possible. You want to put at the front end
Valerie Taylor: of the director.
Valerie Taylor: Exactly how you're gonna do. It is a design decision, like I said, I mean.
Grzegorz_Deptuch: So like
Grzegorz_Deptuch: this computing next to the detector as much as possible of it. Because if you don't have object that you can compute on because you have just sparse heats and or maybe jet information. Maybe you have tracklets. You have very limited ability of computing higher level information.
Valerie Taylor: So I'm not. You know. The expert on this, I guess, is none here, or is he not?
Valerie Taylor: But I'm I'm happy to take this question.
Valerie Taylor: John is not. He's not.
Valerie Taylor: You don't.
Grzegorz_Deptuch: Don't take this question as only to your.
Valerie Taylor: No, no, I mean, it's a good question. So fundamentally.
Grzegorz_Deptuch: Question that I'm asking myself, and you know any answer question would be.
Valerie Taylor: No, it is. It is a good question. I don't disagree. I mean this because a lot of the data is going to be very sparse. And so the question fundamentally is, how much compute is actually there. You know a context, as you say, how much information is there to compute on. So some of these things are basically just cuts that you're going to have to make on sparse.
Paul McIntyre: Perhaps we could move to Angelo. I think he, you may have a comment or a question to add to this.
Angelo Dragone (SLAC): Think this is maybe a comment for- for- for as well as a
Angelo Dragone (SLAC): So I think I think the the way you should see, that is that when you talk about the computing element at the very sense of it, is not that it does the full computation.
Valerie Taylor: No, no, of course no.
Angelo Dragone (SLAC): To work together with the other computing elements that you have in a network. So the question is how you distribute a computer across various elements. And of course, there might have to be
Angelo Dragone (SLAC): multiple layer within this, the detector that do the actually, the communication across the multiple elements at the deeper level that do the computation. So it's a problem while you distributed computing. And now you do the fast interlayer communication within the architecture. This is very similar to some aspects that we have in the Arrays proposal
Angelo Dragone (SLAC): in particular, from what I'm seeing so far, there could be a lot of potential synergies between the and arrays in particular interest to the studies, the network of the detector of the way, all the various elements are interconnected and also transform which you are part, Gregor, which is the communication across layers.
Valerie Taylor: Yeah, no, I think that's very important. I mean, I mentioned here about the Hlt to offline storage and other things, but
Valerie Taylor: the and we have a separate group of people thinking about this, the communication and networking in the project, as well.
Paul McIntyre: There's a question or a comment by Alexander.
Alexander Paramonov: Yeah, it's it's a comment to answer the question.
Alexander Paramonov: So the the purpose of this edge computing is to reduce the data volume
Alexander Paramonov: for example, it's critical for Aps applications, since they just can't read out the the sensor because of the very large data volume. It's also critical for collider physics, since the cabling is a major limitation. So if you can provide some higher level information or reduce backgrounds noise this can allow you a better detector.
Paul McIntyre: Thank you.
Valerie Taylor: Okay, yeah. So I think this conversation is kind of the next slide is simply just an example of, you know, the kind of scenario with a something like a current cms upgrade. So these are just the numbers. And and that I was talking about
Valerie Taylor: over here. So that gives you an idea about the latencies and about yeah
Valerie Taylor: feeds and throughputs. And what needs to be done. So the point is, of course, this is the current upgrade. So it's not like you can do too much with the current upgrade that's going on. But these are the kinds of numbers that you are dealing with in this thing.
Valerie Taylor: So you can see that the range of computing is all the way from like I was saying, closer detector, and then far all the way to the worldwide computing grid. And so so there's abilities to optimize lots of things everywhere in this chain.
Valerie Taylor: Okay, so
Valerie Taylor: so basically, what we're doing right now is from the application side, is looking at designs for next generation detectors for the Fcc. Both Ee and Hh. That's a far future kind of scenario, and also for a potential muon collider.
Valerie Taylor: And and actually, this discussion we already had about the communication channels between the detector and the processing stages and the fact that the initial collision event sizes are expected to grow quite a bit. There's also a question of motivation for optical data links and improved data reduction algorithms in this chain. So that's part of this thought process. The other question basically is, if you're going to put edge processing.
Valerie Taylor: then there is also a question of how much power you can. Probably you can devote to that. And what kind of radiation tolerance that will have. So these are the kinds of questions that will affect the material science. For example, if you're going to put something like this there for the X-ray detectors, I know Thejos is here, but next generation detectors, target data, rates of petabytes per second. So this is megapixel detection and gigahertz readouts
Valerie Taylor: and the raw data of the current hardware needs to be improved by about 5 orders of magnitude in order to get there. The other thing that we mentioned also is this need for closed loop control requirements which for some of these things, because of those shots taking place very rapidly, you have to go down to sub microsecond latency, and currently that latency is something of the order of seconds. That's my understanding, so that will have to be improved considerably.
Valerie Taylor: so that that also gives you an idea of how many
Valerie Taylor: orders of magnitude we are dealing with here.
Valerie Taylor: Okay, next.
Valerie Taylor: So it's important to have a simulator to evaluate all the composable, both the digital and the analog components for the Hep and Xrs application, and have a, you know, unified hardware architecture for composing these components build out the underlying software frameworks to generalize beyond the current applications, because, like in the high energy physics situation, we have a long lead time in order to think about these things. Not so for the
Valerie Taylor: X-ray X-ray scenario.
Valerie Taylor: There's also needs to be some sort of methodology for doing like system wide optimization, not just locally optimizing things.
Valerie Taylor: So the application stream objectives are basically to develop a set of benchmarks and data sets on which you can try out all these optimization techniques. And where you can say, all right. These are what our requirements are. And you know, how would different levels of computing and communication address these requirements for these 2 kinds of detectors? So that would be the set, the requirements, benchmark and data sets they would hand over to the simulation and architecture teams, and also at a lower level to the materials and devices folks.
Valerie Taylor: so they know exactly what
Valerie Taylor: what the situation is, what it is for radiation, damage requirements. What is it that we want for latency and other things, so that these metrics can be converted into sort of requirements for each module that you're putting in into the stack.
Valerie Taylor: So this I think I'll skip through because Andrew cover this. This is the other scenarios. So basically, at this moment the application team is developing a set of benchmarks and data sets for evaluating new technologies and providing feedback into their development cycle.
Valerie Taylor: And here are a couple of examples about the future needs and data reduction for energy physics, for example, the Muons I mentioned already the decay, background, rejection, the event, triggering.
Valerie Taylor: gallometry and tracking, and for X-ray sources. It's the control and positioning of samples, for example, and some of these samples are sensitive, you know.
Valerie Taylor: Destroy them. And then there's fast processing of complex data, such as typographic images. And the other interesting question is, you know, how do you actually change the beam focus and steering, using actual models for the for the control systems and the accelerators.
Valerie Taylor: So
Valerie Taylor: and again, the time resolved data has to be at the rep rate of the light source. If you're going to do these controls.
Valerie Taylor: So that is something that this whole real time thing is a brand new kind of situation for all the light sources.
Valerie Taylor: Alright, thank you, Salman, and let's see. And Andrew. It's Andrew on the call.
Valerie Taylor: The danger, wasn't
Valerie Taylor: I? I let me see, is was Andrew able to join.
Mark Hersam: I don't see him here, Valerie.
Valerie Taylor: Oh, okay, well, let me go ahead and go through about the architecture software and a simulation for the energy, efficient
Valerie Taylor: experiments. And so here, that's where, with respect to the vision.
Valerie Taylor: it's looking at the combination of the Hep detector. And that's the data reduction. The X-ray science, both in terms of the data reduction, but also in terms of the real time feedback. And so that's where you're seeing at the top here, where there could be different type of domain, specific accelerators.
Valerie Taylor: and so depending upon what type of accelerators that are available. And that depends upon the materials, but also depends upon the application needs. It has different implications in terms of the software infrastructure of how it's being mapped.
Valerie Taylor: As well as looking at that hardware infrastructure. So it's exploring different type of domain specific accelerators and looking at the aspects in terms of the capabilities.
Valerie Taylor: but also the customized experiments. And so here, that's where we look at the architecture and the hardware, we're looking at the speed we're looking at what the capability is or the functionality. But we're also looking at the ability to scale
Valerie Taylor: in the software, we're looking at a combination. 2 of the integration how it's doing the optimization. But also, as this area talked about, there's the simulation so that you can explore different type of scenarios. And what ifs
Valerie Taylor: then going a little bit more into the optimization? That's where you're looking at the design. You're also looking at the operation time, and also the infrastructure flexibility in terms of your different components that you have.
Valerie Taylor: So here, there's 2 canonical architectures that's being explored. And so one can architecture that's being explored. And that's where at the top, you're looking at the data, the initial data reduction. But you can have as multiple data reductions depending upon what your target is for ruling out
Valerie Taylor: different components or during different rejections
Valerie Taylor: then. And that's with the Hep and the X-ray science. But then there's the part where you're in the microseconds here of looking at that steering.
Valerie Taylor: and that's where that becomes important in terms of having that
Valerie Taylor: feedback to do that steering, and how much analysis is is needed to be done.
Valerie Taylor: So we want to be able to look at these 2 canonical architectures so that we can explore different type of domain specific architectures to be used with each one.
Valerie Taylor: So here, that's where we're also, for example, if we go a little bit more into detail, there's work that's been done at the University of Chicago that has to do with what's called an up-down system.
Valerie Taylor: And so up down system is really tailored to doing a streaming of data where you can do the analysis with the up down system. And so it allows for scalable bandwidth and also in terms of the components you're using state of the art components in terms of the data transformation. So
Valerie Taylor: this is an example of where we're looking at some domain, specific architectures where up down has really been utilized
Valerie Taylor: and design for doing that streaming of data. And it can help, for example, with the streaming and also the latency that we may have in terms of those needs to have that feedback where it can do the rapid computation. So there are some unique aspects, too, with respect to the Up down
Valerie Taylor: architecture and the up-down system
Valerie Taylor: that's being explored with respect to the Bia Project, and this leveraging from the work that's been done at the University of Chicago.
Valerie Taylor: And so here.
Mark Hersam: Valerie.
Valerie Taylor: Yes.
Mark Hersam: It looks like there's a question from Sadas Shankar.
Valerie Taylor: Okay.
Sadas Shankar: Yeah. Audrey, can you go to the previous slide? Please?
Valerie Taylor: Yes.
Sadas Shankar: The one before this.
Sadas Shankar: So what are the quantitative metrics you are planning to use
Sadas Shankar: here? Is it just the data rate and latency.
Sadas Shankar: Because I don't see anything about energy here. So I'm wondering.
Sadas Shankar: do you use them as a proxy for energy, or do you have any intent to measure them systematically or work with somebody else.
Valerie Taylor: So that's a really good question. Thank you. So we do intend to include, for example, there's the power requirements. There's also the size requirements. And so we're going to mention that, too, when we get to a component that's here that's called system flow. But those are components that we are considering with respect to the architecture.
Sadas Shankar: Okay. Okay. Thank you.
Valerie Taylor: Yes. So that's a good point. Thank you.
Valerie Taylor: But this one we mentioned the data rates and latency, because that differentiates the 2 type of vertical designs
Valerie Taylor: with respect to the steering. But you're right. We are considering size and power and other factors as well, because you can also
Valerie Taylor: consider the memory usage.
Valerie Taylor: So thank you.
Valerie Taylor: Are there other questions, Paul?
Paul McIntyre: I don't see any others right now.
Valerie Taylor: Okay, okay?
Valerie Taylor: So then,
Valerie Taylor: when we start to look at the software components. So in addition to the architecture, we're also looking at the system software. And that is how are we mapping the algorithms that we're using with respect to
Valerie Taylor: the applications or the detectors? How is that being mapped to
Valerie Taylor: the different components that we have especially taking into account that we can have some domain specific components. So we're looking at things that have to do with the memory model that's being used? How is data transferred between the components? Do we have a shared memory model? We're also looking at the execution model.
Valerie Taylor: In terms of what functionality is there in terms of the different components? Then there's also
Valerie Taylor: the idea about security, isolation of devices and failures that we also need to consider, and that comes up a great deal when we look at scaling up with respect to the different components.
Valerie Taylor: So here's an example. And this is system flow. So system flow was a component that we had with thread work. But now we're extending it extensively with respect to the Bia Project.
Valerie Taylor: to better represent the connection between the application, the architecture, and also with respect to the materials. And so that's where you can start to explore, for example, what happens between different systems, where you may want to explore system A where? Maybe you're using the Fbga and CPU
Valerie Taylor: system? B, again, a. What if what if you're using accelerator and Gpu, okay? And that's where.
Valerie Taylor: as was brought up, we are exploring power. We're exploring effectiveness in terms of those different components. And it may be size, it may be memory. It may be time.
Valerie Taylor: So we're using our system flow to define that interface and represent those relationships between the different levels. And those levels include the application, the architecture as well as the system software, then also materials and devices.
Valerie Taylor: And so the architecture I want to go back. It includes the different components as well as the interconnect. And so that's really important.
Valerie Taylor: so we, we've been doing some work. And, for example we looked at when we looked at the Iv characteristics for MOS 2, a device we looked at power, consumption and accuracy, you know, in terms of high energy physics type of algorithms that were done with respect to thread work. So
Valerie Taylor: just to give an example of a question that you may ask around that
Valerie Taylor: to with system, flow.
Paul McIntyre: There is a question. Sadas has another question.
Sadas Shankar: Yeah, so what? What is effectiveness? Valerie.
Valerie Taylor: So by effectiveness, meaning in terms of you have power. But we can have other different metrics. It may be time.
Valerie Taylor: Were you effective in in achieving the requirements. For, let's say, the steering which has to do with time. But it could be where you also have a space
Valerie Taylor: requirement, so effectiveness in terms of meeting the application requirements.
Sadas Shankar: Is programmability also part of effectiveness. Because you are having an Fpga basic on the other side.
Valerie Taylor: Right.
Sadas Shankar: There's an effort there as well, isn't it?
Valerie Taylor: Pardon me.
Sadas Shankar: There should be a bigger effort on the Fpga side in terms of programmability.
Valerie Taylor: Right. And so the Fpga was used as an example. But it is with Fpga. You do have to worry about programmability. Fpgas are really good to giving you rapid prototyping. But with Fpgas you also have to worry about the time. Okay.
Sadas Shankar: Okay. Thanks.
Valerie Taylor: But that's where the effectiveness is really to look at meeting the requirements with the applications.
Valerie Taylor: And so there's also, for example, with system flow. You can also look at different type of technology descriptors. And that's where you're going down to really get into more details at the materials level.
Valerie Taylor: And so that's where, for example, you can go down and look at communication attributes where you're looking at the photonics. Oh, I didn't realize the time. Okay, let me go quickly, because I want to give Mark a chance. I thought I was at 3 40 and looked up. I'm at 3 50.
Valerie Taylor: So with system flow. That's where you can look at hardware software. Also, runtime type of optimization. I will skip the detail here and just note that we can do cross area guidance and do a lot of exploration.
Valerie Taylor: So I'm going to quickly move to Mark. So sorry about that sorry, mark. I just recognized the time.
Mark Hersam: No problem. I'll try to be quick. So my name is Mark Herson from Northwestern University. I'm speaking on behalf of the materials and devices thrust next slide, please.
Mark Hersam: So we have 2 major objectives. So the 1st is to look at understanding, prototyping and integrating nanomaterials-based neuromorphic devices for energy efficient data processing hardware
Mark Hersam: for high energy physics and X-ray science detectors.
Mark Hersam: And secondly, to look at the fundamental research aimed at energy efficient optical interconnects. Again, for these 2 detector technologies next slide.
Mark Hersam: The normal for computing paradigm is one where we want to circumvent the famous Von Neumann bottleneck. The fact that we need to move data back and forth between the memory block and the processor block.
Mark Hersam: By having in-memory computing, you can avoid that, or at least minimize the energy consumption coming from that Von Neumann bottleneck.
Mark Hersam: And to do that, we need to realize fast, dense analog, and importantly, tunable, non-volatile memory next slide.
Mark Hersam: Towards that end we're going to be exploring those goals, using low, dimensional nanoelectronic materials. These materials possess
Mark Hersam: high mobilities relatively defect-free interfaces and atomic scale thicknesses that ultimately, enable scaling
Mark Hersam: additionally atomic scale thicknesses imply weak screening, and that allows a high degree of tunability of almost any electronic device with respect to a gate.
Mark Hersam: And this could include devices like memristers that historically have not been gate tunable.
Mark Hersam: Additionally, we're going to be looking at optical responses to enable integration with some of the optical interconnect
Mark Hersam: goals of this overall thrust.
Mark Hersam: Additionally, loading materials provide mechanical flexibility and back end of line integration
Mark Hersam: which will further facilitate edge sensing applications. Next slide.
Mark Hersam: If we look at the materials themselves, we're going to be trying to understand fundamental relationships and ultimately mechanisms.
Mark Hersam: Between low dimensional material properties and neuromorphic function in 3 categories.
Mark Hersam: first, st the mechanism and role of defects in a device called a memtransistor, which is a hybrid memrister transistor.
Mark Hersam: secondly, interfacial effects in van der Waals heterojunctions, and finally correlated electrical and thermal effects
Mark Hersam: in printed nanomaterial films which will enable
Mark Hersam: of biorealistic spiking responses. Next slide
Mark Hersam: on the device side, we're looking more at applications, such as exploring the the scaling limits and different gating schemes in the context of mem transistors
Mark Hersam: to integrate non-volatile gating and signal amplification in Van der Waals heterojunctions and to develop biorealistic spiking neurons and oscillators using printed 2D memoristive films
Mark Hersam: next slide.
Mark Hersam: The optimal and interconnects is the other major objective of this thrust
Mark Hersam: and the underlying motivation for this is that current materials limit the speed and efficiency of optical interconnects, particularly for electric optic modulators.
Mark Hersam: For example, if we looked at state of the art silicon optical modulators which rely upon free carrier dispersion effects. This is limited to approximately 100 Gigahertz, based upon the carrier mobility of silicon.
Mark Hersam: In contrast, if we went to materials like graphene with higher charge, carrier mobility in principle, they could go to faster speeds. But the problem is that monolayer graphene is relatively weakly interacting with light.
Mark Hersam: And as a result, this thrust is going to be looking at bulk semimetals that are 3 dimensional analogs to graphene.
Mark Hersam: A bismuth is among the most promising candidates due to its low, effective mass and high mobility.
Mark Hersam: This enables ultra-fast gate tunable electro absorption effects in a bulk material, and consequently it also has high optical absorption.
Mark Hersam: Next slide.
Mark Hersam: Some early results from this thrust include the demonstration of gate tunability of semi-metallic and relatively thick bismuth films.
Mark Hersam: This requires high capacitive coupling to the tune of one to 10 microfarads per square centimeter.
Mark Hersam: This can be realized using a material developed within the team, namely, hexagonal boron, nitride ionogels, which are also compatible with
Mark Hersam: variable temperature conditions. On these devices often be measured at low temperature.
Mark Hersam: Next slide.
Mark Hersam: There's also going to be effort in this thrust to look at modulators based upon the pockols effect, IE. Electric field, induced changes in the refractive index in materials like lithium niobate.
Mark Hersam: particularly integrating lithium nibate with photonic crystal microcavities will reduce device footprints.
Mark Hersam: and thereby enable high speed and lower switching energies next slide.
Mark Hersam: and then, to conclude, I'll give you some deep dive. Examples of ongoing research, beginning 1st with Memtransistors, next slide.
Mark Hersam: So the Memtransistor, as Valerie alluded to before was a device we were looking at in the previous threadwork project.
Mark Hersam: One of the limitations of that device is that there's a lack of independent control over the transistor action and the Memrister action
Mark Hersam: in the new Bia Project. We're now looking at Split Gate mem transistors where we have a different gate under the body of the channel versus underneath the contacts.
Mark Hersam: This allows us to independently modulate the memristor and transistor responses.
Mark Hersam: and this is quite useful in the context of more efficient reinforced learning.
Mark Hersam: Next slide.
Mark Hersam: We're also looking at so-called self-aligned mem transistors. These are devices which allow very short channel length and the ability to have asymmetry between so-called drain, gated and source gated modes.
Mark Hersam: The 2 curves here show you the differences which are not only quantitative but qualitative in nature. For example, in terms of current saturation.
Mark Hersam: this ability to switch between drain and source gated modes is particularly useful for efficient novelty detection, which is certainly of high interest in the detector context. Next slide.
Mark Hersam: We're also looking at another family of devices. The so-called mixed kernel Heterojunction transistor which Valerie mentioned was also initially explored in the Threadwork project.
Mark Hersam: This is a device that allows you to tune just by different applied biases
Mark Hersam: between a sigmoidal response and a Gaussian response or a mixture of the 2
Mark Hersam: which is of high interest for support vector machine classification.
Mark Hersam: Next slide.
Mark Hersam: Indeed, we've been applying this mixed kernel support vector machine classification to high energy physics detectors. This enables efficient data filtering, as was alluded to earlier in the presentation by Solomon, which is useful for high energy physics detectors.
Mark Hersam: We're now extending this methodology also to the X-ray science detectors next slide.
Mark Hersam: And then, finally, because we have the ability to tune the Gaussian response in these mexurnal heterojunctions. If we can integrate that with non-volatile gate memory which we're doing using materials like ferroelectrics.
Mark Hersam: This will allow us to store that in a crossbar array, thereby allowing hardware, efficient implementation of Bayesian neural networks which will enable probabilistic predictions.
Mark Hersam: And with that I believe it's my last slide. So I apologize for being a couple minutes over, but I'll be happy to take any questions.
Valerie Taylor: And thank you, Mark, and sorry to give
Valerie Taylor: so little time, so thank you for that.
Paul McIntyre: There's a question in the chat from Maya.
Paul McIntyre: Let's see.
Paul McIntyre: Okay.
Mark Hersam: Yeah, this, the question is, is there.
Paul McIntyre: About system. Flow. Yeah, for Github.
Mark Hersam: For system, flow. Valerie.
Valerie Taylor: Yes. So we're working on making that available so it should be available soon in terms of system flow.
Valerie Taylor: Yes.
Paul McIntyre: Well, we're a little bit over,
Paul McIntyre: and I think I and others have to have to jump onto other calls. Thanks so much, Valerie, Mark, Solomon for sharing, and and your whole team, I'm sure, collaborated in the slide, the slide making and and preparing an excellent presentation overview. I think it was very stimulating, and
Paul McIntyre: look forward to having opportunities to work together on aspects of of what via is doing, and also having an opportunity to see what some of the other teams are doing in future. iterations of this meeting. So thanks. Everybody
Paul McIntyre: have a great day.
Valerie Taylor: And thanks Mark and Solomon. Yes.
Paul McIntyre: Cheers.