Dear Ketil,
I'll start to answer..
1a) yes
1b) yes
1c) the manual is inexact.. the thresholds in the manual refer to heavy
ion interactions. Transport thresholds can be set down to 1keV/nucleon 1d)
I would divide the answer in two:
a)the scoring mesh has no influence on transport, therefore the "realism"
of the simulation is not affected by scoring
b) In general, the particle thresholds should be adapted to the scoring
mesh that one intends to use, otherwise artefacts can be generated. IThis
applies in particular to the energy deposition due to secondary electrons
(delta-rays) (see the lecture on transport).Are you sure that you gain
something using bins as small as this?
WARNING: if your protons produce low energy neutrons (<20MeV) that
reinteract, you will NOT get the tracking of recoils and fragmant from
these interactions. Their energy will be deposited at the point of
interaction.
about EVENTBIN time penalty: strange that it has such a big impact.
2a) it is useful for checks, and to keep track of weights in case of
biased simulations. Do you write on formatted or un-formatted files?
Unformatted saves space.
For the rest of your question I need a bit of time.
Paola
> Dear All,
> I need some feedback on a type of simulation I would like to
> carry out using fluka. The simuation problem I am working on is related
to Single Event Upsets (SEU) in SRAM based memory cicuits. The main
purpose of the simulation is to see if it is possible to reproduce the
SEU cross section results from irradiation tests of an SRAM based memory
device. And, if this is possible to do using fluka. The beams of
interest are protons of 30 and 150 MeV.
>
> The approach taken is a based on a fairly simple methodology which has
shown to give reasonably good results by others. If this methodology is
still valid with the decreasing feature sizes of modern
> semiconductor devices, is a separate discussion. For now I therefore
assume that the below described RPP methodology is valid for my case.
>
> An SEU can be defined as a bitflip in a memory cell caused by charge
deposited in the sensitive volume of this memory cell by a single
ionizing particle. In order to cause an SEU the charge deposited (Qdep)
must be larger than a given critical charge (Qcrit)associated with the
memory cell. In a chip of millions of memory cells not every memory cell
is identical and thus the Qcrit is not 1 value, but a distribution of
values.
>
>
> The methodology is based on describing the sensitive volume of a memory
cell as a rectangular parallelpided volume (RPP). Simplified, by
simulating the charge deposited within this volume and comparing the
result to the distribution of Qcrit, the number of SEUs generated equals
the number of charge depositions larger than the Qcrit.
>
> To do this in fluka I have tried to build a geometry that in a
> best possible way represents the real structure of a typical
> chip. To simplify, I assume that the memory cells are evenly
> distributed over the full chip in a periodic fashion. Only a small
sample of the real size is therefore used. The area is approx. 100 x 100
um and the thickness is approximately 1400 um. In the fluka simulation
setup the thickness is along the z-axis/beam axis. A simple schematic of
the geometry is shown below.
>
> ------> Z
> 450um 850um 1um 9um 100um
> ------------------------------------------------
> | | |*| | |
> | | |*| Inter | |
> p--> |Cu Lid |Si substracte |*| connect| Package | 100um
> | | |*| layers | substrate |
> | | |*| | |
> ------------------------------------------------
>
> The layer denoted by stars are where the memory cells are located in the
chip. That is, this is the area where the scoring of deposited charge
should take place. Just after, alternating layers of
> copper interconnect wires and dielectric follow. At the end is the
package substrate which in some cases consists of a flip chip solder
bump (Sn/Pb mixture).
>
> I do not have the detailed layout of the chip and in particular the
interconnect layers. I therefore base my geometry on a simple
> structural examination of the chip. This has allowed me to retrieve for
instance the thickness of each interconnect layer, but not the detailed
layout of the copper wiring. Due to the periodic nature of the chip I
again assume that the fraction of copper wires is evenly distributed. I
therefore assign a fraction(0-100%) of copper to
> dielectric (SiO2) in each layer. A typical copper wire thickness in my
case is approx. 0.5 um thick. To accommodate this granularity I have
utilized the Voxel geometry available in Fluka to build the different
layers. Each layer contains a number of copper voxels corresponding to
the fraction of copper assigned for that layer. The Voxels are
> randomly distributed in each layer. For now this seems to be the best
solution I can come up with when the layout information is not known. To
some extent I believe this approach should
> caputure the granularity of the interconnect layers compared to only
using a uniform layer of a material.
>
>
>
> So far this has been a short introduction to my case study. In the
following are more fluka specific issues where feedback will be greatly
appreciated.
>
> To score the deposited charge by a single particle I believe the
EVENTBIN scoring card is appropriate. An advantage of using EVENTBIN is
that by making a mesh of small sized bins, different sizes of sensitive
volumes can be achieved by combining the result from various bins. This
is particulary valuable when the actual size of the
> sensitive volume is not known. Instead of implementing different sizes
of the sensitive volumes as geometry, and then running several
> simulations for each size, this analysis can rather be done in the
post-processing stage. EVENTBIN scoring is also an easy method to
utilize several sensitive volumes in order to increase the collection
statistics. Because the expected sensitive volume size is close to 0.4
x 0.4 x 1.0 um^3, I would like to use bins of size 0.2 x 0.2 x 0.2 um^3.
This means that a single sensitive volume is built of several bins. The
critical charge/energy in my case is in the order of 10 fC or ~0.2 MeV.
>
> The main suspects to cause an SEU for this device technology are the
highly ionizing fragments produced in inelastic nuclear reactions. In
particular the alpha-particle and residual ion are important.When
produced in an inelastic reaction from a 30 MeV proton on Si, the
typical fragment energy is approx. 5 MeV and below for alpha, and 1 MeV
and below in the case of the residual ion (i.e. Mg24). Using SRIM the
corresponding range in Si is found to be approx. <25 um and <1-2 um
respectively. Thus, only fragments produced close to the layer of
sensitive volumes will contribute to the SEU rate.
>
> 1a) How does fluka treat the residual ion? In the manual it says that
when an ion is below the transport threshold it is ranged out to rest.
Does this mean that if the range crosses a scoring bin, the energy
deposited is calculated as given by slide 18 in
> http://www.fluka.org/content/course/NEA/lectures/Transport.pdf
> [(dl/dx)*dE]
>
> 1b)
> Can an ion that is ranged out be scored by using the AUXSCORE card for
HEAVYION combined with EVENTBIN? Or is this only possible when the
particle is transported?
>
>
> 1c) Can a few MeV ion be transported until it has lost all its energy by
reducing the PART-THRES for HEAVYION? From the manual this does not seem
to be true. The limits are given as 10MeV/n and 100MeV/n
> for transport of secondary and primary heavy ions
> respectively.
>
> However, I still seem to be able do some kind of
> transport of a Mg24 ion. But maybe the transport limit is the
> reason why I do not understand my resuls. See
> information/question further below.
>
> 1d) With sub-micron scoring bin size, does fluka still give valid
results for energy deposition? If possible, what type of
> physics/transport settings should be used to optimize for this type of
simulation?
>
>
>
> **************************************************************************
Using EVENTBIN scoring increases the simulation time. Also, due to the
low probability of inelastic reactions a large number of primaries are
needed to achieve reasonable statistics. Because the EVENTBIN scoring
writes an entry to the log file for every event, in my case, this
results in log files of several GB. Also the expected simulation time
can reach several days to weeks depending on computer specifications and
wanted statistics.
>
> 2a) I understand that it is possoble to score only bins with hits.
However, even if there are no hits, a line giving the event number and
number of hits is still written to the EVENTBIN output. Is there any way
that the latter can be avoided? Is there are reason for writing an entry
for events that have no hits, or is this in fact redundant information?
>
>
> In order to minimize this problem I have tried to divide the
> simulation in two steps. First I run a simulation to locate all
> inelastic reactions and store information about the produced
> fragments. This is done by the USDRAW routine in mgdraw.f. By
> optimizing the simulation for this task and not using any other
> scoring, this reduces the simulation time significantly. However, no
biasing is used since this is not recommended in combination with
EVENTBIN scoring. The optimization is simlply done by minimizing the
transport of all other particles except the primary proton. In the
second step, the source.f routine is used to transport only the
> fragments of interest produced in the inelastic reactions and score them
using EVENTBIN. This greatly reduces the size fo the EVENTBIN log file.
>
> When doing this exercise, I noticed some results that I could not
explain. I therefore need someones feedback on the following
> simulation results.
>
> Starting from the right side of the interconnect layers (in the
> package substrate) a beam of either 10000 5 MeV alpha-particles or 5e-5
MeV (~1.2MeV/n) Mg24 ions are directed towards the interconnect layers
(negative z-direction).
>
> -----> Z
> 450um 850um 1um 9um 100um
> ------------------------------------------------
> | | |*| | |
> | | |*| Inter | |
> |Cu Lid |Si substracte |*| connect| <-- He4 |
> | | |*| layers | Mg24 |
> | | |*| | |
> ------------------------------------------------
>
>
> Two cases are simulated for each beam, one with the voxel geometry
implemented, and one without the voxel geometry but with a layer of only
SiO2 instead.
>
> For the alpha-particle I got what I judge as an expected results. When
the layer contains the voxels of copper more energy is deposited which
in turn slightly decreased the range of the alpha-particle beam.
>
> What I do not understand is that I did not see the same behaviour when I
instead
> used a Mg24 beam. Infact, I observed the opposite. The beam
> seemed to reach further when the copper voxels were present compared to
when they were not. When only a layer of SiO2 was used the fluence and
energy plot shows a that the beam reaches approx. a few
> microns. Compared to what SRIM predicts this sounds reasonable. However,
with
> the copper voxels in the beam path, the fluence and energy plot
> reached almost 15 um.
>
>
> 2b). How can this be? What type of information/knowledge am I lacking
here? Does transport of this low energy heavy ion beam make sense in
Fluka? Could it be related to how I have implemented the Voxel geometry,
eventhough it seems to work reasonable well for the alpha-beam case?
>
> 2c) I have used the default 'PRECISION' and enabled transport of heavy
recoils by the EVENTYPE card with What(3)=2. Does the latter option only
apply to a secondary recoil and not if it is a primary source particle?
>
> 2d)I have set the PART-THRES at 1e-6 for
> Alpha-particles and HEAVYION. Is this a valid approach or does it not
make
> sense? Similar type of questions as 1c)
>
> In general, any suggestions or comments on how to deal with the low
energy residual nucleus is of interest.
>
>
> Some plots showing showing the results can be found here(~50kB):
www.ift.uib.no/~ketil/temp/fluka/plots.tar
>
> The title of the plot indicates the type of simulation.
>
> For instance
>
> HIFluenceUSRBIN_NOVOXEL:
> HI= Mg24
> FluenceUSRBIN: means 1D plot of the fluence of the particle in the
z-axis
> NO_VOXEL: means without voxels
>
> He4EnergyUSRBIN_VOXEL
> He4:alpha
> EnergyUSRBIN: means 2d plot of energy in the y-z plane
> VOXEL: means that Voxels are implemented.
>
>
> An example of the input file for the He4 beam without Voxels can be
found here:
> http://web.ift.uib.no/~ketil/temp/fluka/step2He4.inp
>
> An example of the input file for the Mg24 beam with voxels can be found
here:
> http://web.ift.uib.no/~ketil/temp/fluka/step2HI.inp
>
>
> **********************************************************************************************************************************************************
>
> Ok, I think I will stop here.
>
> The folders containing all the fluka simulations files can be found here
>
> 2 step method (~50MB):
> www.ift.uib.no/~ketil/temp/fluka/2stepmethod.tar
>
> Alpha/Mg24 test (~50MB):
> www.ift.uib.no/~ketil/temp/fluka/TEST.tar
>
>
> The python script (ic.py) generating a voxel text file and the
> corresponding fluka fortran file (writect.f) to convert it into a binary
file can be found here:
> http://web.ift.uib.no/~ketil/temp/fluka/voxel.tar
>
>
> All comments and suggestions are warmly appreciated. Do not hesitate to
reply even if you can or will only answer one of my many
> questions.
>
> Best regards,
> Ketil
>
Paola Sala
INFN Milano
tel. Milano +39-0250317374
tel. CERN +41-227679148
Received on Fri Jan 16 2009 - 14:42:11 CET
This archive was generated by hypermail 2.2.0 : Fri Jan 16 2009 - 14:42:11 CET