Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
74
datasets available to search
ShareScore release 0.9.0
Dataset results
74 results for “hardware”
Ascon SCA software and hardware databases
<h2><strong>Software and hardware side-channel analysis databases for attack on Ascon AEAD</strong><br> </h2><p>This repository contains datasets collected for side-channel analysis attack on Ascon AEAD.</p><p>The repository is divided into two folders, one for software side-channel analysis and one for hardware side-channel analysis:</p><p> </p><p>- cw.zip</p><p> - ascon_collect.ipynb : Jupyter Notebook used to collect the traces for the unprotected Ascon implementation</p><p> - ascon_protected_collect.ipynb : Jupyter Notebook used to collect the traces for the protected Ascon implementation</p><p> - simpleserial-ascon : Ascon firmwares used to collect the traces</p><p>- hw.zip</p><p> - ascon_g_protected</p><p> - test_ascon.py : Script to test the protected Ascon implementation</p><p> - collect_lecroy.py : Script to collect traces for unprotected Ascon implementation with Lecroy oscilloscope</p><p> - rtl_src : RTL source files for the protected Ascon implementation</p><p> - ascon_g_unprotected</p><p> - test_ascon.py : Script to test the unprotected Ascon implementation</p><p> - collect_lecroy.py : Script to collect traces for unprotected Ascon implementation with Lecroy oscilloscope</p><p> - rtl_src : RTL source files for the unprotected Ascon implementation</p><p>- helpers.zip</p><p> - ASCON.py : Python implementation of Ascon</p><p> - SASEBO.py : Helper functions to communicate with the SAKURA-G board</p><p> - lecroy3.py : Helper functions for Lecroy oscilloscope</p><p> - ascon_helper.py : Helper functions for Ascon</p><p> - convert_trs_to_h5.py : Script to convert Trsfile traceset to HDF5 database</p><p> </p><p>ascon_cw_protected.h5 : Side-channel database for software protected Ascon implementation</p><p>ascon_cw_unprotected.h5 : Side-channel database for software unprotected Ascon implementation</p><p>ascon_hw_protected.h5 : Side-channel database for hardware protected Ascon implementation</p><p>ascon_hw_unprotected.h5 : Side-channel database for hardware unprotected Ascon implementation</p><p> </p><p>ascon_cw_protected.trs : Traces for software protected Ascon implementation</p><p>ascon_cw_unprotected.trs : Traces for software unprotected Ascon implementation</p><p>ascon_hw_protected.trs : Traces for hardware protected Ascon implementation</p><p>ascon_hw_unprotected.trs : Traces for hardware unprotected Ascon implementation</p><p> </p><h3><strong>Ascon authenticated encryption attack on a Chipwhisperer STM32F4</strong> </h3><p>The dataset was used for side-channel attack on Ascon initialization phase attack of the authenticated encryption mode on a ChipWhisperer STM32F4 target board.</p><p>The power traces are collected with the ChipWhisperer-Lite oscilloscope at a sampling rate of 4x the target clock frequency, and captures the first call of the round function of the Chi function of Ascon permutation.</p><p>The code used to collect the traces is also available in this repository, and the trace collection can be replicated with a ChipWhisperer-Lite and a STM32F4 target board.</p><p> </p><h3><strong>Ascon authenticated encryption attack on a SAKURA-G FPGA</strong></h3><p>The hardware designs of the unprotected and protected Ascon implementations are available in the `hw` folder.</p><p>Both implementations are written in VHDL/Verilog and can be synthesized for Spartan6 (XC6SLX75) with Xilinx ISE.</p><p>Traces are collected with a Lecroy WaveRunner 610Zi oscilloscope at a sampling rate of 500 MS/s.</p><p> </p><h3><strong>Databases description:</strong></h3><p>Database | Ntraces | Traces (samples) | Label* (bytes) | Metadata (bytes) </p><p> | Nf | Nr | | | Key | Nonce | Plaintext | Associated data | Ciphertext | Tag</p><p>ascon_cw_unprotected.h5 | 100,000 | 100,000 | 772 | 64 | 16 | 16 | 4 | 4 | 4 | 16</p><p>ascon_cw_protected.h5 | 500,000 | 500,000 | 1408 | 64 | 32 | 32 | 16 | 16 | 16 | 32</p><p>ascon_hw_unprotected.h5 | 100,000 | 100,000 | 6,000 | 64 | 16 | 16 | 4 | 4 | 4 | 16</p><p>ascon_hw_protected.h5 | 500,000 | 500,000 | 10,000 | 64 | 32 | 32 | 8 | 8 | 8 | 32</p><p> </p><p>*Label computed with the intermediate_value leakage model described in `ascon_helper.py`</p>
Reconfiguration Time Measurements for Evolving Hardware
<p>The dataset contains the raw measurements of the time necessary to reconfigure Lattice iCE40 FPGAs.</p> <p>The main goal is to see the effect of two approaches of implementing the reconfiguration process in software for Evolvable Hardware. One approach is to use existing open-source software externally, the other is to integrate the functionality in the software for Evolvable Hardware.</p> <p>The conditions for the reconfiguration measurements were altered in four dimensions:</p> <ol> <li>The FPGA board <ul> <li>iCEstick <ul> <li>Lattice iCE40 HX1K FPGA</li> <li>Sample bitstream created by <a href="https://github.com/evolvablehardware/BitstreamEvolution">Bitstream Evolution Software</a></li> <li>No direct reconfiguration possible</li> </ul> </li> <li>iCE40 breakout board (ICE40HX8K-B-EVN) <ul> <li>Lattice iCE40 HX8K FPGA</li> <li>Sample bitstream created by CoBEA</li> </ul> </li> </ul> </li> <li>Write Target <ul> <li>Flash <ul> <li>Bitstream first written to an external EEPROM, then pulled by the FPGA from the EEPROM</li> </ul> </li> <li>Direct <ul> <li>Bitstream written directly to the FPGA</li> </ul> </li> </ul> </li> <li>Reconfiguration approach <ul> <li>Icestorm <ul> <li>Use external tools from Project Icestorm</li> </ul> </li> <li>CoBEA <ul> <li>Use integrated function of CoBEA reconfiguration module</li> </ul> </li> </ul> </li> <li>Bitstream size <ul> <li>Full <ul> <li>No size reduction</li> </ul> </li> <li>Compact <ul> <li>Size reduced as much as allowed by write approach <ul> <li>Icestorm: skip BRAM</li> <li>CoBEA: skip BRAM, skip comment, full compaction (level 4)</li> </ul> </li> </ul> </li> </ul> </li> </ol> <p> </p> <p>This upload contains three groups of files:</p> <ul> <li>2 bitstreams <ul> <li>One for each used FPGA board</li> </ul> </li> <li>12 measurements <ul> <li>Comma-separated values</li> <li>File name contains the contiditions of the measurement</li> <li>Only 12 out of 16 possible combinations of conditions as "iCEstick" cannot be combined with "Direct"</li> </ul> </li> <li>1 aggregated statistic <ul> <li>Comma-separated values</li> <li>Minimum, mean, maximum, mean-minimum, maximum-mean for every measurement</li> </ul> </li> </ul>
Displacement measurements of the open-hardware sandbox using the AS5311 high-resolution magnetic sensor
<p>This dataset includes the experimental data from the AS5311 sensor for measuring the displacement of the Open-Hardware Geological Sandbox.</p> <p>These experiments are explained in the journal article: <a href="https://doi.org/10.1109/ACCESS.2023.3262617">Designing low-cost open-hardware electromechanical scientific equipment: A geological analogue modeling sandbox</a></p> <p>To understand this dataset, go to the Tectonic Open Hardware (TectOH) Sandbox project: <a href="https://github.com/URJCMakerGroup/TectOH">https://github.com/URJCMakerGroup/TectOH</a>. Then go to the <a href="https://github.com/URJCMakerGroup/TectOH/tree/main/optional">optional</a> folder and to the <a href="https://github.com/URJCMakerGroup/TectOH/tree/main/optional/as5311_magn_sens">magnetic sensor</a> folder.</p> <p>This data set contains two kind of files:</p> <ul> <li><strong>bin</strong>: raw binary files received from the AS5311 high resolution sensor. Although this sensor sends 12 bit data, we have truncated the most significant bits and receive only 8 bits (one byte). Therefore, each byte of these binary files is a measurement of the distance. Each distance increment corresponds to ~0.488nm (2mm/2048)</li> <li><strong>csv</strong>: csv files that can be opened with any spreadsheet app, such as Libreoffice Calc or Microsoft Excel, or even with a text editor. This file contains the processed data from the binary files. These files have been generated with the proc_magn_sensor.py Python script located in the <a href="https://github.com/URJCMakerGroup/TectOH">project repository</a>. There are some columns, which are: <ul> <li>index: measurement number</li> <li>time in milliseconds: each measurement is taken every 250 us</li> <li>median2: in micrometers, since the sensor may jitter, we have applied the median filter twice. All the data has been subtracted to the lowest value, making the lowest value equal to zero.</li> <li>median1: in micrometers, median filter only applied once. All the data has been subtracted to the lowest value, making the lowest value equal to zero.</li> <li>mean: in micrometers, mean filter. All the data has been subtracted to the lowest value, making the lowest value equal to zero.</li> <li>mean int: in micrometers, mean filter rounded to an integer value. All the data has been subtracted to the lowest value, making the lowest value equal to zero.</li> <li>orig_base: this is not in micrometers, but in the units of the sensor (~0.488nm). The only processing done is that when there is an overflow of 255 to 0, or from 0 to 255, it adds the overflow to continue the trend. All the data has been subtracted to the lowest value, making the lowest value equal to zero.</li> <li>original: this is the data received from the sensor with no processing, each value is ~0.488nm</li> <li>mean2: in micrometers, mean filter applied twice. All the data has been subtracted to the lowest value, making the lowest value equal to zero.</li> </ul> </li> </ul> <p>There are two set of experiments:</p> <ul> <li><strong>Experiments with no load</strong>. These files start with <em>noload_</em><br> In these experiments the gantry is moved 1 mm alternatively to the front and then reversing direction. Moving in this alternate way a few times. There are five experiments each of them with a different speed: v= 10 mm/h; 25 mm/h; 50 mm/h; 82 mm/h and 100 mm/h. The name of the file indicates the speed: <ol> <li>noload_100mmh_1mm: FBFBF: 1mm forth, 1mm back, 1mm forth, 1mm back, 1 mm forth</li> <li>noload_25mmh_1mm: FBFFBBFB</li> <li>noload_50mmh_1mm: FBFBFB</li> <li>noload_82mmh_1mm: FBFBFB</li> <li>noload_100mmh_1mm: FBFBFB</li> </ol> </li> <li><strong>Experiments pushing a 5kg sand load</strong>. These files start with <em>load5kg_</em> <ol> <li>load5kg_25mmh_5mm: moving 5kg at 25mm/h a distance of 5mm</li> <li>load5kg_25mmh_10mm: moving 5kg at 25mm/h a distance of 10mm</li> <li>load5kg_25mmh_20mm: moving 5kg at 25mm/h a distance of 20mm</li> <li>load5kg_75mmh_20mm: moving 5kg at 75mm/h a distance of 20mm</li> <li>load5kg_75mmh_50mm: moving 5kg at 75mm/h a distance of 50mm</li> <li>load5kg_100mmh_25mm: moving 5kg at 100mm/h a distance of 20mm</li> <li>load5kg_100mmh_50mm: moving 5kg at 100mm/h a distance of 50mm</li> </ol> </li> </ul> <p> </p> <p> </p> <p> </p>
Low-entropy Packed Binary Detection using Hardware Performance Counters
<p><span>Malware analysis faces a critical challenge in accurately identifying packed executables, especially those with low entropy. Existing software-based solutions often fail in detecting packers used by malware, resulting in inaccurate classifications. To address this shortcoming, in this study we introduce a novel method using<br>Hardware Performance Counters (HPCs) to facilitate the classification of binary packers due to HPCs’ minimal access overhead and ability to obviate the necessity for source code. We trained classic machine-learning models by selecting relevant hardware attributes associated with the unpacking procedure for detecting<br>packers used by low-entropy binary programs. Extensive experiments shows the substantial role played by Hardware Performance Counters in detecting binary packing characterized by low entropy,<br>offering a promising avenue for further exploration and refinement of techniques in malware analysis<br><br><br></span></p> <p><span>The following zip files are executables that represent low entropy versions of software packers using byte-padding. The name of the files are the names of the packers which are represened, Acprotect, Armadillo, Aspack, Nspack, Pecompact, Petite, UPX, and Zprotect. These can be used to measure the unpacking process using hardware performance counters in order to test & train machine earning classifiers for accurate classification of low entropy packers.</span></p>
Dataset: An Open-hardware Platform for MPSoC Thermal Modeling
<p>This repository contains the experimental data for the paper</p> <p>"An Open-hardware Platform for MPSoC Thermal Modeling"</p> <p>published at 2019 samos conference</p> <p>http://samos-conference.com</p> <p>The data is released under a CC-BY Creative Commons license.<br> If you use this dataset, cite the following paper:<br> Federico Terraneo, Alberto Leva, William Fornaciari, "An Open-hardware Platform for MPSoC Thermal Modeling", 2019 IEEE International Conference on Embedded Computer Systems: Architectures, Modeling and Simulation (SAMOS)</p>
Eye image data with gaze labels recorded using custom video-oculography hardware at 120Hz
<p>The repository of eye image data with corresponding gaze labels collected from 40 subjects. The preview contains a collage of random image samples, one per subject. </p> <p>All recorded subjects gave informed consent under an experimental protocol approved by the Institutional Research Board of Texas State University (approval code 2018044) and their data were anonymized prior to public release.</p> <p>The data were recorded using the custom video-oculography (VOG) desktop hardware setup at 120Hz. The full description of this eye-tracking system's capabilities is provided at https://doi.org/10.48550/arXiv.1904.07361.</p> <p>This VOG set contains recordings of the random oblique saccades task. It is comprised of 174 on-screen fixation targets that densely cover the range of ±20.51° horizontally and ±16.7° vertically (in degrees of visual angle). More detail on the presented stimuli can be found at https://doi.org/10.1145/3379156.3391370.</p> <p>The data were also used in Dmytro Katrychuk's Ph.D. thesis "Generating Realistic Eye Images to Evaluate Photosensor Oculography Eye-Tracking for Portable Headsets" (https://hdl.handle.net/10877/19437); with the release for public use in the upcoming publication "An appearance-based gaze estimation as a benchmark for eye image data generation methods" accepted to MDPI Journal of Applied Sciences. </p> <p>Each .zip archive represents a recording from one subject, which includes:</p> <ul> <li>Video of the close eye capture in ".avi" format</li> <li>Calibration data in ".xml" format</li> <li>Gaze data in ".tsv" format</li> <li>On-screen target stimulus position in ".tsv" format</li> </ul> <p>The "src.zip" provides a Python script to unpack each ".avi" video recording to a set of ".png" images. The direct playback of ".avi"s may require special codecs and is not supported. </p> <p>Any additional code will be uploaded to https://github.com/dkatrychuk/psog-eval-diss2023</p> <p>The authors can be contacted at their corresponding emails: Dmytro Katrychuk - d_k139@txstate.edu; Oleg Komogortsev - ok@txstate.edu.</p>
Software, Dataset, and Techreport: Mixed-precision finite element kernels and assembly: Rounding error analysis and hardware acceleration
<p>This upload contains a techreport titled "Mixed-precision finite element kernels and assembly: Rounding error analysis and hardware acceleration" together with the software (with documentation) and dataset generating the results. The software is also available on GitHub at https://github.com/croci/mpfem-paper-experiments-2024/ . The GitHub version may be updated in the future. This upload corresponds to commit number 8506dd368b84655201c8c72b1307239b9b4e43fd . See README.md file for installation instructions. The manuscript is also available on the arXiv: https://arxiv.org/abs/2410.12614.</p>
2D materials-based homogeneous transistor-memory architecture for neuromorphic hardware
<p>This dataset contains the raw data used for the publication:</p> <p><strong>2D materials-based homogeneous transistor-memory architecture for neuromorphic hardware</strong></p> <p>By Lei Tong<sup>1</sup>, Zhuiri Peng<sup>1</sup>, Runfeng Lin<sup>1</sup>, Zheng Li<sup>1</sup>, Yilun Wang<sup>1</sup>, Xinyu Huang<sup>1</sup>, Kan-Hao Xue<sup>1</sup>, Hangyu Xu<sup>2</sup>, Feng Liu<sup>3</sup>, Hui Xia<sup>2</sup>, Peng Wang<sup>2</sup>, Mingsheng Xu<sup>4</sup>, Wei Xiong<sup>1</sup>, Weida Hu<sup>2,</sup>*, Jianbin Xu<sup>5</sup>, Xinliang Zhang<sup>1</sup>, Lei Ye<sup>1,</sup>*, Xiangshui Miao<sup>1</sup></p> <p>Detailed descriptions for each file can be found in "Dataset description.docx".</p>
Hardware-biased quantum random numbers
<p>Bitstring from a hardware-biased quantum random number generator. The data is used in the numerical experiments for the publication "On the effects of biased quantum random numbers on the initialization of artificial neural networks" (<a href="http://arxiv.org/abs/2108.13329">arXiv:2108.13329</a>).</p> <p> </p>
EXTREMA: Random autonomous interplanetary mission scenarios for EXTREMA Simulation Hub (ESH) hardware-in-the-loop simulations
<p>EXTREMA (short for Engineering Extremely Rare Events in Astrodynamics for Deep-Space Missions in Autonomy) enables self-driving spacecraft, challenging the current paradigm under which spacecraft are piloted in the interplanetary space [1]. Deep-space guidance, navigation, and control applied in a complex scenario is the subject of EXTREMA, which wants to engineer ballistic capture in a totally autonomous fashion. EXTREMA is erected on three pillars. Pillar 1 is on autonomous navigation. Pillar 2 involves autonomous guidance and control. Pillar 3 deals with autonomous ballistic capture. The outcomes from each one of the three pillars is validated with a tailored experiment featuring the model of the associated CubeSat subsystems. Integrated experiments involving all the components of a CubeSat GNC system are carried on in the EXTREMA Simulation Hub, an integrated facility simulating an interplanetary transfer with a hardware-in-the-loop setup. The project has been awarded a European Research Council (ERC) Consolidator Grant in 2019.</p> <p>The data set is made of 1000 (even more in some releases) random interplanetary mission scenarios used for hardware-in-the-loop simulations performed in the EXTREMA simulation Hub (ESH). Each scenario comes with the following information: generation seed, initial epoch, initial state (Keplerian elements and Cartesian coordinates), initial attitude (quaternion and direct cosine matrix), initial mass, number of revolution, time of flight, target final epoch, target final state (Keplerian elements and Cartesian Coordinates), and other supplementary data. Scenarios are organized in directories each containing at least the following files:</p> <ul> <li>'esh_ic.json': random scenario information saved in .json format;</li> <li>'esh_ic.mat': random scenario information saved in .mat format.</li> </ul> <p>Some releases provide only a limited set of data in the 'esh_ic.json' file. For those, the full set of information is found in the 'esh_ic_full.json' file.</p> <p>For additional information about the EXTREMA project visit the page <a href="http://extrema.polimi.it/">extrema.polimi.it</a>.</p> <p><strong>References</strong><br> [1] Di Domenico G., et al. "The ERC-Funded EXTREMA Project: Achieving Self-Driving Interplanetary CubeSats." <em>Modeling and Optimization in Space Engineering: New Concepts and Approaches</em>. Cham: Springer International Publishing, 2022. 167-199. DOI: <a href="https://doi.org/10.1007/978-3-031-24812-2_6">10.1007/978-3-031-24812-2_6</a>.</p>
Root multiple ion uptake kinetics data for maize NAM founders, statistical code, and RhizoFlux hardware plans
<p>This repository contains tabular data, R statistical code, protocols, and hardware plans associated with the following manuscript:</p> <p><strong>A multiple ion-uptake phenotyping platform reveals shared mechanisms that affect nutrient uptake by maize roots</strong></p> <p>Marcus Griffiths, Sonali Roy, Haichao Guo, Anand Seethepalli, David Huhman, Yaxin Ge, Robert E. Sharp, Felix B. Fritschi, Larry M. York</p> <p>Plant Physiology; doi: <a href="https://doi.org/10.1093/plphys/kiaa080">https://doi.org/10.1093/plphys/kiaa080</a></p> <p><strong>Equipment designs.zip</strong> - Contains the hardware plans, parts lists, and experimental protocol</p> <p><strong>ImageJ_macro.zip</strong> - Contains scripts to use within ImageJ to segment images to calculate leaf area</p> <p><strong>Supplementary_Data.zip</strong> - Contains the actual supplemental figures and tables for the manuscript as well as RNAseq data</p> <p><strong>R code & raw data.zip</strong> - Contains a single .R text file containing all the R code to generate all the figures and and supplemental figures from the include raw data files</p> <p>E-mail mgriffiths at danforthcenter.org or lmyork at noble.org with any questions.</p> <p>Version 1 was used for the preprint.</p> <p>Version 2 was used for the final submitted manuscript.</p> <p>Version 3 is the final published version.</p>
Hardware Synthesis of Weakly Consistent C Concurrency
<p>Hardware Synthesis of Weakly Consistency C Concurrency</p> <p>This webpage contains additional material for the paper Hardware Synthesis of Weakly Consistent C Concurrency (FPGA17paper.pdf). </p> <p>Contents</p> <ol> <li>Verifying that our scheduling constraints implement the C11 standard</li> <li>Verifying the lock-free circular buffer</li> <li>Motivating examples</li> <li>Experimental Data</li> </ol> <p>1. Verifying that our scheduling constraints implement the C11 standard</p> <p>As explained in Section 4.4, we have used the Alloy tool to verify that our scheduling constraints are sufficient to implement the memory consistency model defined by the C11 standard. In alloy.zip, we provide the Alloy model files that we used. The first four are taken from Wickerson et al.'s work on comparing memory consistency models; the fifth is new.</p> <ul> <li>relations.als contains helper functions.</li> <li>exec.als encodes general program executions.</li> <li>exec_C.als encodes C11 program executions.</li> <li>c11.als encodes the constraints imposed by the C11 memory consistency model.</li> <li>question.als encodes our scheduling constraints, and several queries for checking that these scheduling constraints are strong enough to enforce the constraints required by the C11 memory consistency model.</li> </ul> <p>To reproduce our result, save the five files above into the same directory, download Alloy, open question.als in Alloy, and run the queries contained within.</p> <p>2. Verifying the lock-free circular buffer</p> <p>As explained in Section 5.1, we have used the CppMem tool to verify that our case-study application, a lock-free circular buffer, is free from data races. In order to make the verification feasible, we removed the while-loop, replaced the array variable with a scalar, removed some unimportant local variables, and simplified the increment function. Below, we give the actual code that we verified.<br> <br> int main() {<br> atomic_int tail = 0;<br> atomic_int head = 0;<br> int arr = 0;<br> {{{ {<br> int chead = head.load(memory_order_acquire);<br> int ctail = tail.load(memory_order_relaxed);<br> if (ctail+1 != chead) {<br> arr = 42;<br> tail.store(ctail+1, memory_order_release);<br> }<br> } ||| {<br> int ctail = tail.load(memory_order_acquire);<br> int chead = head.load(memory_order_relaxed);<br> if (ctail != chead) {<br> arr;<br> head.store(chead+1, memory_order_release);<br> }<br> } }}}<br> return 0;<br> }</p> <p>To reproduce our result, paste the code above into CppMem's web interface and click Run. The tool should report (after a couple of minutes) that the code has 92 candidate executions, of which two are consistent, neither of which exhibit data races.</p> <p>3. Motivating Examples</p> <p>We provide the actual code that displays coherence and message-passing violation in motivating-examples.zip, as described in Section 2 of our paper. These examples have been tested and verified on LegUp's VM. For convenience, we have included the output logs of each experiment for viewing. We include a "transcript" of the execution and a schedule trace, which can be visualised using LegUp's scheduleviewer.</p> <p>4. Experimental Data</p> <p>We also provide the raw experiment data from Section 5 of our paper. We conduct two experiments, for which we provided raw data on all seven design points.</p> <ul> <li>chaining.csv contains the raw data for the chaining experiment.</li> <li>bursting.csv contains the raw data for the bursting experiment.</li> <li>The version number are from 1 to 7 for Unsound, SC, OMP criticals, SC atomics, Weak atomics, Mutexes and OMP atomics respectively.</li> </ul>
Hardware Trojan Dataset of RISC-V and Web3
<p>This dataset contains hardware trojans of RISC-V and Web3 (Crypto Wallet and Proof-of-Work Miner) in Verilog.</p> <p>A total of 10 golden models were obtained from GitHub (https://github.com/Saazh/Trojan-D2/tree/main/TrojanD2/Trojan_D2/RISC-V/ALL_FILES_IN_ONE_FOLDER, https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/tree/master/src, https://github.com/jmaldon1/Crypto_wallet/tree/master/firmware).</p> <p>There are 10 generated hardware trojans for each golden model. The hardware trojans have a "T" in their name. For example, the golden model for the top module of the miner is "fpgaminer_top.v", and one of related hardware trojan files is "fpgaminer_top_T0.v".</p>
BRAIN Journal-An Energy-Saving Concept of the Smart Building Power Grid with Separated Lines for Standby Devices-Figure 3. The unified hardware unit based on NodeMcu Lua ESP8266 WiFi development board, ACS712T ELC-30A current sensor, and relay SRD-05VDC-SL-C
<p>The software consists of two parts, low-level Arduino sketches and high-level C# Windows form appplication. They are connected using the open-source message MQTT broker Mosquitto.11 Every hardware unit has the unique identifier and commands to control the relay. The MQTT topic “/VPP/Relays” is used by subscribers and publishers. The number “50” sent from C# Windows form (it equals number “2” sent from the standard Mosquitto publisher) is a command to switch on the second relay, “51” (“3”) – to switch off, respectively. The prototype was developed with one root controller and two descendant relays. The commands are as follows: “52” (“4”) / “53” (“5”) – to switch on / off the first relay, “54” (“6”) / “55” (“7”) – to switch on / off the third relay, respectively. This solution is similar to the one presented in [22], but ACS712T ELC-30A current sensor and ESP8266WiFi.h library are applied here. In addition, other commands, e.g. “56” (“8”) to get the value of the current in the 3rd segment, are in use as well.</p>
CERN Open Hardware Survey 2017
<p>Data + notebook for the "CERN Open Hardware Survey" of 2017.</p>
Ginkgo's performance on Intel Gen12 hardware
<p>These two performance plots show the performance of the Ginkgo library on Intel Gen12 hardware relative to the peak performance of the hardware. The performance is after an initial porting of the library and some tuning on non-HPC hardware, thus it is expected that the performance is not optimal. We compare our library's performance to the native vendor-provided oneMKL functionality for the Sparse Matrix-Vector product. We see that Ginkgo is at least competitive if not better than the vendor implementation. The solver results show that Ginkgo's solvers are also suitable for Intel hardware although some solvers, in particular GMRES, could be better optimized.</p>
Hardware of the robot RiBot V2.0 (Mechanics and Electronics)
<p>The RiBot is an actuated robotic fish-lure that was designed to study the behavior of zebrafish. The design was based on the scan of a real zebrafish to produce the electronic boards and mechanics at the right scale. The robot can be controlled using Infrared RC5 signals and can beat its tail with different range of frequencies and amplitudes.</p> <p>The electronics was designed using the software Altium designer and the mechanics using CREO 3. The step file of the mechanics can be open by other types of CAD software. The firmware of the RiBot to program the electronics is described in:</p> <p>https://zenodo.org/record/830181#.WXtAIYTyipo</p> <p>The design of the lure is presented in detail in the following publication:</p> <p>F. Bonnet, N. Crot, D. Burnier and F. Mondada. Design Methods for Miniature Underwater Soft Robots. 6th IEEE RAS & EMBS International Conference on Biomedical Robotics and Biomechatronics (BioRob 2016), Singapore, Proceedings of the IEEE RAS-EMBS International Conference on Biomedical Robotics and Biomechatronics, 2016.</p> <p> </p> <p> </p>
Data supporting "Local Clustering Decoder: a fast and adaptive hardware decoder for the surface code"
<p>The data consists of a CSV file containing the raw performance data collected from running our decoder on a Xilinx Virtex Ultrascale+ VU19P FPGA. The Stim circuits that were used to create the samples are provided in a ZIP file. Our internal fork of Stim with support for leakage is needed to sample noise from the circuits.</p>
Data from "Hardware-efficient quantum error correction using concatenated bosonic qubits"
<p>Includes data for characterizing the bit-flip and logical phase-flip rates of the logical memory. See the README for more details.</p>
Hardware Performance Archive
<h3>SHA256</h3> <h3>MD5</h3>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.