profile
viewpoint

rswarbrick/clg 4

clg is an interface to the GTK+ graphical toolkit for the CMUCL, SBCL and CLISP implementations of Common Lisp.

rswarbrick/scraperfaker 4

A "fake" scraperwiki that you can use as a drop-in replacement for the real one when developing scraper scripts

robertgoss/K---Theory 2

Lecture Notes from the K - Theory course given by Prof John Jones in Warwick 2012

rswarbrick/giplayer 2

A factor-based GUI/frontend to get-iplayer

rswarbrick/mbcl 2

A common-lisp based wrapper around (some of) MusicBrainz's web API.

rswarbrick/mbedit 2

CL-based editing interface to MusicBrainz

rswarbrick/plonker 2

A trivial python application that makes a "ding" every so often

rswarbrick/rjs-maxima-tools 2

Extra code for use in GNU Maxima (and might get submitted there eventually)

rswarbrick/scrapr 2

Scrape "original image" urls from a Flickr set.

rswarbrick/spice-mode 2

Major mode providing a spice mode hook for fontification

issue openedlowRISC/opentitan

Newbie guide to contributing fixes to Opentitan

Hello, One question while I was trying to fix some low hanging issues on Riviera/Questa support.

From https://github.com/lowRISC/opentitan/blob/master/CONTRIBUTING.md I read:

Create pull requests from a fork rather than making new branches in github.com/lowrisc/opentitan.

I generally follow the fork --> clone --> add remote --> branch --> commit flow as in:

https://jarv.is/notes/how-to-pull-request-fork-github/

Do you folks differ slightly in that, you don't want me to create a branch?

Also, what exactly you mean by "do not commit" - how do I raise a pull request otherwise?

Sorry if this is too simple, but not so obvious to me.

Regards Srini

created time in 5 hours

pull request commentlowRISC/opentitan

[usbdev] Test on NexysVideo with TUSB1106 USB PHY PMOD

@vogelpi and @stefanlippuner need your thoughts on if we want this in the repo or I should just carry as a local change since I only made 3 of the special PMOD boards (I have parts for 3 more).

Stefan may have something similar (although I believe his test PHY chip was from someone other than TI).

mdhayter

comment created time in a day

PR opened lowRISC/opentitan

[usbdev] Test on NexysVideo with TUSB1106 USB PHY PMOD

Add support in nexys video top and pins for having a PMOD with TUSB1106 USB PHY in PMOD JC. This allows testing of the usbdev in FPGA using a PHY with the same interface ase contemplated on the first OpenTitan chip implementation. The PHY uses single ended TX signals but has the differential RX needed by USB spec (with the single ended RX being used to detect SE0). The PHY also privides the pullup on D+. Direction is set by an active low OE (i.e. inverted from the comportable active high oe).

Top level FPGA wrapper supports both PMOD options based on SW2 (i.e. GPIO2). SW2=0 uses the single ended resistor only PMOD in connector JB (same as before). SW2=1 uses the TUSB1106 PMOD in connector JC. The wrapper supports faking pinswap for both PMODs. The single ended PMOD must be run with single ended configuration. The TUSB1106 can be set to use either single ended or differential RX but only supports single ended TX. (There were not enough pins on the PMOD connector to support the switchable TUSB1105.)

Modified the hello_usbdev code to detect the TI phy from SW2 and prevent differential TX when it is used.

Added the kicad files for the PMOD board to the usbdev/pmod directory.

Tested on Nexys Video with both PMODs and confirmed Verilator tests still run correctly (with line number and printf changes).

Signed-off-by: Mark Hayter mark.hayter@gmail.com

+90142 -14

0 comment

20 changed files

pr created time in a day

PR closed lowRISC/opentitan

Reviewers
[entropy_src/dv] Changed sanity to smoke

Signed-off-by: Steve Nelson steve.nelson@wdc.com

+20 -21

1 comment

8 changed files

senelson7

pr closed time in a day

push eventlowRISC/opentitan

Steve Nelson

commit sha 8d54c6c660939fdd17a8a16ad533ad11eb783288

[csrng/dv] push_pull_agent parameter .DataWidth->.HostDataWidth Signed-off-by: Steve Nelson <steve.nelson@wdc.com>

view details

push time in a day

PR merged lowRISC/opentitan

Reviewers
[csrng/dv] push_pull_agent parameter .DataWidth->.HostDataWidth

Signed-off-by: Steve Nelson steve.nelson@wdc.com

+19 -14

0 comment

5 changed files

senelson7

pr closed time in a day

push eventlowRISC/opentitan

Steve Nelson

commit sha 78e90e32fddddbfa35d7ef1581452b587ddb3a5c

[edn/dv] csrng_agent is only genbits, not cmd Signed-off-by: Steve Nelson <steve.nelson@wdc.com>

view details

push time in a day

PR merged lowRISC/opentitan

Reviewers
[edn/dv] csrng_agent is only genbits, not cmd

…IOs, not cmd

Signed-off-by: Steve Nelson steve.nelson@wdc.com

+43 -27

0 comment

5 changed files

senelson7

pr closed time in a day

pull request commentlowRISC/ibex

Fix Jump Latency for Configuration with BTALU

I think this is correct. The branch target ALU accelerates conditional branches, by computing the branch target and the branch condition in parallel. For unconditional branches, i.e. jumps it makes no difference.

ganoam

comment created time in a day

PullRequestEvent

PR opened lowRISC/opentitan

[top] Add support for further top levels

Note: this PR is based on #4294 which contains various fixes to topgen (skip the first 7 commits here).

This PR adds support for additional top levels. This is needed for supporting different FPGAs. On one hand, already the bronze design cannot be implemented on the NexysVideo board. As we move towards silver, we will have to switch the main design to a bigger FPGA but we want to keep supporting low cost boards like the NexysVideo for the community. On the side channel analysis (SCA) front, the situation is even worse: already today, several crypto IPs need to be removed and the flash size needs to be reduced to make the design with a single hardened accelerator fit the smaller FPGA.

Wtih this PR, additional top levels to top_earlgrey can be supported. For those new top-levels, only the hjson config and template files, some top-level core and SystemVerilog files are added under hw/top_... but the auto-generated sources and core files are not added to the repo. These files are automatically generated by FuseSoC at build time by calling topgen under the hood (via generator, similar to what we do with the tech primitives). To this end, FuseSoC needs to be called with a fileset_topgen flag and IPs specific to the top-level (alert handler, clkmgr, rstmgr etc.) have a dependency to this new generator if the flag is specified.

As an example, this PR adds a second top level called top_englishbreakfast that will be used for side channel analysis (basically replacing top_earlgrey_cw305). The generated bitstream has been tested successfully on the ChipWhisperer CW305 FPGA board.

There are currently two workarounds implemented in this PR:

  1. We have hardcoded references to top_earlgrey in the software sources and the SW build configuration. The PR thus contains a script to patch the sources produced by topgen. I will need help from SW folks to solve this properly.
  2. Currently, topgen is run twice by FuseSoC. From the first run, we just take the auto-generated register files and from the second run, we take everything else (some packages, top level). Doing everything in one shot is currently not possible as this results in either unresolved dependencies or cyclic dependencies in FuseSoC. One way out of this would be to allow unresolved dependencies in FuseSoC before the generators (topgen) are run. This is tracked upstream olofk/fusesoc#449.
+5266 -81

0 comment

61 changed files

pr created time in a day

push eventlowRISC/opentitan

Srikrishna Iyer

commit sha 53415ce28934586cd73fa14f0b31ba5f6b50c98e

[DV common] String utils package - A dedicated package that provides string manipulation utility functions. Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

Srikrishna Iyer

commit sha f9b0874cfc5a9123a9dbd3baac2cf6adb346d82d

[dv common] Update dv_utils to use str_utils_pkg Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

Srikrishna Iyer

commit sha a17f941a4f55df41c2a661562a78cab342539776

[dv sw_logger_if] Update to use str_utils_pkg Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

Srikrishna Iyer

commit sha 360e34cc2abcf41545f7d157fc6eea8b7b1d18e0

[chip dv] Move sw build directory - This removes one extra hierarchy in the sw build area for chip dv Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

Srikrishna Iyer

commit sha de5efa04db21f9e1de9b1b8961017c83ee9a5dce

[dvsim] Replace `sw_test` with `sw_images` This change is part 1/4 commit series that updates the way SW tests are build for chip level. For the chip level SW tests to pass, all 4 commits are needed. This change reduces dependency on DVSim to process how SW images for each tests are set and built. The goal is to be able to supply an arbitrary list of images to build, rather than assuming a fixes set (ROM and SW test). The need for this change arose from one more addition - OTBN that requires an image to be built. The processing is now handled by `sim.mk` and testbench code. All SW build steps (specific to DV) are integrated into meson. Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

Srikrishna Iyer

commit sha 250a399da5f055914ae9d70f10c69da595d33277

[DV] Update how --rodata-sections switch works This change is part 2/4 commit series that updates the way SW tests are build for chip level. For the chip level SW tests to pass, all 4 commits are needed. - THis change updates how `--rodata-sections` switch on this tool works. - The above switch can be supplied multiple times on the command line - all supplied sections will get appended (expanded) into a single list. Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

Srikrishna Iyer

commit sha d8929edef7e4339f9433c39f2a885d438c747e6f

[dv, meson] Integrate DV SW build steps into meson This change is part 3/4 commit series that updates the way SW tests are build for chip level. For the chip level SW tests to pass, all 4 commits are needed. This integrates the step that extracts the logs and rodata sections from the embedded SW elf into meson. This change is only enabled for 'sim_dv' device, so others should remain unaffected. Previously, this was done in DV simulation flow `hw/dv/tools/dvsim/sim.mk`. Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

Srikrishna Iyer

commit sha 10763589923efbff6421daca120097f00cab7e27

[DV] Update the was SW is built for DV This change is part 4/4 commit series that updates the way SW tests are build for chip level. For the chip level SW tests to pass, all 4 commits are needed. This change updates the SV / testbench code to enable the following: - An arbitrary list of SW images can be supplied for each test in the HJson - Each entry in this list is of the format <path-to-sw-test>.<index>.<flags> - Index and flags are optional for the flow, but necessary for chip DV env. Index # indicates what SW image it pertains to: 0 - ROM, 1 - SW test, 2 - OTBN. - The goal is to make it scalable and flexible to any future need that may arise. - The flags can be used for enabling custom modifications (such as build something differently). - The full list of sw_images is passed to the UVM env which breaks it down and sets the images paths for each (ROM, SW test, OTBN etc). Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

push time in a day

PR merged lowRISC/opentitan

Reviewers
[DV] Updates to the way SW is built for DV simulations

This series of commits updates the way SW is built for DV. The motivation was to have a single SW build command do all the steps required to generate all the required outputs. This builds on top of @lenary's change that adds SPIFlash host build as a dependency to SW tests. It includes the extraction of RODATA and log metadata from the built images which are used in DV logging method.

Also, the way SW tests to be built are supplied to DVSim via the HJSon config file is updated - this approach now allows an arbitrary number of SW images to be built to be supplied to DVSim. It is the job of the simulation Makefile to understand how they are to be built. Now , only one variable needs to be set - sw_images which is a list with the following format: [path/to/foo/test:0:flag1, path/to/bar/test:1:flag1:flag2], where each entry is the path to the SW test to be built in meson, followed by index and flags. Index and flags are separated using ':' delimiter. They are both optional. The index is used by the testbench to know what type of SW image is it (0- ROM, 1- SW test, 2- OTBN etc). Flags are additional indicators that can be used to customize their behavior.

This approach reduces the need for hardcoding any logic within DVSim (or having DVSim understand what all the test variables mean). Simulation Makefile is considered 'user' data which can be replaced if needed for a DUT requiring a more customized flow.

The first 3 commits are slightly unrelated - they add a str_utils_pkg to provide some common string manipulation methods for DV, but they are eventually used in this PR.

Commit 5 removes sw_test_is_prebuilt as a 'known' test variable - only thing DVSim needs to know is a list of sw_images.

Commit 6 updates the RODATA/logs extraction script.

Commit 7 integrates the DV specific steps during the SW build into meson.

Commit 8 kind of puts it all together, updating the SV side of the testbench.

These changes are a precursor to building images for OTBN using the RIG with the meson flow.

+538 -169

3 comments

25 changed files

sriyerg

pr closed time in a day

issue commentlowRISC/opentitan

[otbn] Should we supply PC or other information on error?

We could factor in life-cycle state and avoid providing the error PC in certain life-cycle states.

GregAC

comment created time in a day

PR opened lowRISC/opentitan

[rom_ext] Remove Signature Identifier

This was left over from https://github.com/lowRISC/opentitan/pull/3733#issuecomment-726928866.

There are three other changes:

  • One adds verbose logging to the generator script, which makes it easier to understand how layout is being performed when the manifest is changed.
  • One updates the manifest.md to use the format from #4305.
  • One updates the assembly which is used for the skeleton of the ROM_EXT in the elf images (which we plan to auto-generate at some point).
+74 -94

0 comment

7 changed files

pr created time in a day

issue openedlowRISC/opentitan

[otbn] Should we supply PC or other information on error?

Currently on an error only an error code is provided, which can make debugging tricky. Do we want to extend the error information?

The simplest thing to do would be to include an error PC, simply the PC of the instruction executing at the time the error is seen. We could add further information, e.g. the DMem address of a read that resulted in an error. I feel a PC should be sufficient though.

created time in a day

Pull request review commentlowRISC/opentitan

[dvsim, OTBN] Ability to execute arbitrary pre/post build/run commands & working OTBN smoke test

 name:   // TODO: This needs deciding upon. Eventually, it might be nice to allow this   //       to be overridden on the command line ("I've got a bunch of ELF files   //       that stress my new feature; please run the test suite with them")-  otbn_elf_dir: "{sw_build_dir}"-+  otbn_elf_dir: "{run_dir}/build-out"   run_opts: ["+otbn_elf_dir={otbn_elf_dir}"] +  // OTBN run modes.+  run_modes: [+    {+      name: build_otbn_rig_binaries_mode+      pre_run_cmds: ["BUILD_ROOT={run_dir} cd {proj_root} && ./meson_init.sh",+                     "{proj_root}/hw/ip/otbn/dv/uvm/gen-binaries.py --seed {seed} {otbn_elf_dir}"]

... which I think is problematic. Dvsim should not assume it is in full control of building all components of OpenTitan from source, but rely on the output from other build systems, outside of the dvsim boundary, instead. I have opened #4326 to discuss this further.

For this PR: @rswarbrick is gen-binaries.py able to cope with only $BUILD_ROOT being set, but not $OBJ_DIR, and will it set OBJ_DIR = $BUILD_ROOT/build-bin (an assumption that dvsim makes).

sriyerg

comment created time in a day

pull request commentlowRISC/opentitan

[DV] Updates to the way SW is built for DV simulations

I had a look at the changes, and they are fine on their own. I'm however very worried about the path dvsim is taking by including the software build. I have opened https://github.com/lowRISC/opentitan/issues/4326 to discuss this further. I'm hoping we can refrain from going down the route of dvsim orchestrating more builds which cross the DV boundary until we have reached agreement on the issue I linked.

sriyerg

comment created time in a day

issue commentlowRISC/opentitan

Specify interaction between component build systems

CC @sriyerg @msfschaffner @gkelly @lenary @rswarbrick @moidx

imphil

comment created time in a day

issue openedlowRISC/opentitan

Specify interaction between component build systems

We currently have multiple build systems for the different components of OpenTitan, but have not finally agreed on a way how those build systems interact. This is especially critical now that we're seeing more and more chip-level work where build artifacts from different components need to be plugged together.

I have created a document outlining the status quo at https://docs.google.com/document/d/1UxT0jkrGfwvOf6KYoEnrTgWdft-aWjNCoKf06_7C05Y/edit#.

While software, FPGA and Verilator chip-level simulation builds as well as end-to-end system tests are written (and used in CI) to be called individually and build artifacts to be stored in $BIN_DIR, dvsim assumes (and expands more towards) being a "all in one" build system which operates in its own build directory structure and also, for example, triggers software builds when needed for a chip-level DV run. This leads to two ways of building components existing next to each other.

We need to clarify:

  1. How do we want the cross-component builds to happen?
  2. Are we happy with the current lack of a high-level build system, which instead relies on the developer (or CI logic) to orchestrate component builds? If not, how could a minimal solution to that problem look?
  3. Do we want dvsim to be the "high-level build system" that everybody uses? If so, what extensions would be necessary to enable parallelized and distributed multi-stage builds, as we do them in CI?

I'm proposing for everyone to have a look at the linked document and think about the problem. Please comment if you have input, and I'll then try to follow up as necessary (probably in one of the meetings, and then with a final proposal/doc change).

created time in a day

Pull request review commentlowRISC/ibex

Ibex fcov v3

+// Copyright lowRISC contributors.+// Licensed under the Apache License, Version 2.0, see LICENSE for details.+// SPDX-License-Identifier: Apache-2.0++interface core_ibex_fcov_if import ibex_pkg::*; (+  input clk_i,+  input rst_ni,++  input priv_lvl_e priv_mode_id,+  input priv_lvl_e priv_mode_if,+  input priv_lvl_e priv_mode_lsu+);+`ifdef UVM+  import uvm_pkg::*;+`endif

UVM macros call UVM methods underneath, so uvm_pkg needs to be imported wherever they are invoked. Not sure there is a good way to fix this.

GregAC

comment created time in a day

Pull request review commentlowRISC/opentitan

[DV] Updates to the way SW is built for DV simulations

 run: run_result pre_run: prep_tool_srcs 	@echo "[make]: pre_run" 	mkdir -p ${run_dir}-ifneq (${sw_test},)-	mkdir -p ${sw_build_dir}-endif +.ONESHELL: sw_build: pre_run 	@echo "[make]: sw_build"-ifneq (${sw_test},)+ifneq (${sw_images},)+	set -e+	mkdir -p ${sw_build_dir} 	# Initialize meson build system.-	${LOCK_SW_BUILD} "cd ${proj_root} && \+	${LOCK_SW_BUILD_DIR} "cd ${proj_root} && \ 		BUILD_ROOT=${sw_build_dir} ${proj_root}/meson_init.sh"-	# Compile boot rom code and generate the image.-	${LOCK_SW_BUILD} "ninja -C ${sw_build_dir}/build-out \-		sw/device/boot_rom/boot_rom_export_${sw_build_device}"-	# Extract the boot rom logs.-	${proj_root}/util/device_sw_utils/extract_sw_logs.py \-		-e "${sw_build_dir}/build-out/sw/device/boot_rom/boot_rom_${sw_build_device}.elf" \-		-f .logs.fields -r .rodata .chip_info \-		-n "rom" -o "${run_dir}"-	# Copy over the boot rom image to the run_dir.-	cp ${sw_build_dir}/build-out/sw/device/boot_rom/boot_rom_${sw_build_device}.32.vmem \-		${run_dir}/rom.vmem-	cp ${sw_build_dir}/build-out/sw/device/boot_rom/boot_rom_${sw_build_device}.elf \-		${run_dir}/rom.elf--ifeq (${sw_test_is_prebuilt},1)-	# Copy over the sw test image and related sources to the run_dir.-	cp ${proj_root}/${sw_test}.64.vmem ${run_dir}/sw.vmem-	# Optionally, assume that ${sw_test}_logs.txt exists and copy over to the run_dir.-	# Ignore copy error if it actually doesn't exist. Likewise for ${sw_test}_rodata.txt.-	-cp ${proj_root}/${sw_test}_logs.txt ${run_dir}/sw_logs.txt-	-cp ${proj_root}/${sw_test}_rodata.txt ${run_dir}/sw_rodata.txt--else-	# Compile the sw test code and generate the image.-	${LOCK_SW_BUILD} "ninja -C ${sw_build_dir}/build-out \-		${sw_test}_export_${sw_build_device}"-	# Convert sw image to frame format-	# TODO only needed for loading sw image through SPI. Can enhance this later-	${LOCK_SW_BUILD} "ninja -C ${sw_build_dir}/build-out sw/host/spiflash/spiflash_export"-	${LOCK_SW_BUILD} "${sw_build_dir}/build-bin/sw/host/spiflash/spiflash --input \-		${sw_build_dir}/build-bin/${sw_test}_${sw_build_device}.bin \-		--dump-frames=${run_dir}/sw.frames.bin"-	${LOCK_SW_BUILD} "srec_cat ${run_dir}/sw.frames.bin --binary \-		--offset 0x0 --byte-swap 4 --fill 0xff -within ${run_dir}/sw.frames.bin -binary -range-pad 4 \-		--output ${run_dir}/sw.frames.vmem --vmem"-	# Extract the sw test logs.-	${proj_root}/util/device_sw_utils/extract_sw_logs.py \-		-e "${sw_build_dir}/build-out/${sw_test}_${sw_build_device}.elf" \-		-f .logs.fields -r .rodata \-		-n "sw" -o "${run_dir}"-	# Copy over the sw test image to the run_dir.-	cp ${sw_build_dir}/build-out/${sw_test}_${sw_build_device}.64.vmem ${run_dir}/sw.vmem-	cp ${sw_build_dir}/build-out/${sw_test}_${sw_build_device}.elf ${run_dir}/sw.elf-endif +	# Loop through the list of sw_images and invoke meson on each item.+	# `sw_images` is a list of tests to be built into an image, separated by space.+	# Optionally, each item in the list can have additional info supplied using+	# delimiter ':'. The format is as follows:+	# <path-to-sw-test>:<index>:<flag>+	#+	# If no delimiter is detected, then the full string is considered to be the+	# <path-to-sw-test>. If 1 delimiter is detected, then it must be <path-to-sw-+	# test> followed by <index>. The <flag> is considered optional.+	@for sw_image in ${sw_images}; do \+		image=`echo $$sw_image | cut -d: -f 1`;  \+		index=`echo $$sw_image | cut -d: -f 2`; \+		flags=(`echo $$sw_image | cut -d: -f 3- --output-delimiter " "`); \+		if [[ -z $$image ]]; then \+			echo "ERROR: SW image \"$$sw_image\" is malformed."; \+			echo "Expected format: index::path-to-sw-test:optional-flag."; \

Good catch! Fixed.

sriyerg

comment created time in a day

Pull request review commentlowRISC/ibex

Ibex fcov v3

 module ibex_controller #(     end   end +  //////////+  // FCOV //+  //////////+  `FCOV_SIGNAL(logic, interrupt_taken, (ctrl_fsm_cs != IRQ_TAKEN) & (ctrl_fsm_ns == IRQ_TAKEN));+  `FCOV_SIGNAL(logic, debug_entry_if, (ctrl_fsm_cs != DBG_TAKEN_IF) & (ctrl_fsm_ns == DBG_TAKEN_IF));+  `FCOV_SIGNAL(logic, debug_entry_id, (ctrl_fsm_cs != DBG_TAKEN_ID) & (ctrl_fsm_ns == DBG_TAKEN_ID));+  `FCOV_SIGNAL(logic, pipe_flush, (ctrl_fsm_cs != FLUSH) & (ctrl_fsm_ns == FLUSH));

Hmm style guide does allow use of wire 'allowed when necessary' and looks like it's supported in Verilator from a quick look at the manual.

I think the main objection to using that style would be it's a bit error prone, if someone attempts to copy it when setting up some new fcov signals and leaves off the wire it won't work and they may not notice.

GregAC

comment created time in a day

pull request commentlowRISC/opentitan

[DV] Updates to the way SW is built for DV simulations

LGTM (with one nit, below).

We might be using build_by_default: true in too many places, but let's leave evaluating that for a follow-up change, as I'm not sure we have a principle behind when we allow that. I don't think it matters for this PR, this PR is about establishing the dependency graph correctly for DV.

Aah yes, you're right. Its not really needed on these target since they are intermediate. I will go ahead and remove them.

sriyerg

comment created time in a day

push eventlowRISC/opentitan

Srikrishna Iyer

commit sha 6c531b093be8ce22ecd537e5f45a7430a877204b

[DVSim] Method to add pre/post build/run steps Skeletal support for being able to run additional DUT-specific pre/post build/run commands existed in DVSim, but there wasn't a need to fully support it until now. To support the OTBN build-some-binaries before running the simulations usecase, this commit adds the ability to supply the following information: `pre_build_cmds`, `post_build_cmds`, `pre_run_cmds` & `post_run_cmds`. These are list variables that can be set in the following places: 1. Bare, within the HJson (all 4 of them) 2. Within build modes (all 4 of them) 3. Within run modes (only pre/post_run_cmds) 4. In regressions (all 4 of them) 5. In test specifications (only pre/post_run_cmds) Each of these places limits on which builds / tests will they get invoked, enabling a finer control of setting these commands. If these are set inside modes, then all mode-specific functionality still holds (modes can enable other modes, etc). During processing, if these lists are encountered more than once, they get appended together. It is the users responsibility to ensure ordering if required. Before these are supplied to GNUMake, all commands in each of these lists are appended with ' && ' so that they are chained together as a single command when Make invokes them in a subshell. This is done to ensure Make halts if any one of them fails. Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

Srikrishna Iyer

commit sha eb4bc1bd8de18535aefd37ab97004585fa400beb

[OTBN DV] Prototype impl of gen-binaries This builds on top of the previous commit to generate some binaries for a test and a pre-run step. This is suitable in terms of reproducability and wider coverage since the test seed is also passed on to the RIG binary generator script. The downside of this approach is the generator is invoked for each and every seed of each and every test that needs it, which could be an overkill. It however does not seem to be a strain o the simulation time though. If a post build step is desired instead, then that can also be achieved by moving the commands to `post_build_cmds` variable placed bare in the HJSon to ensure it is executed for all available builds. The paths of course, will need to be updated. The downside of this is the `--seed` switch of the script would have to be foregoed. Signed-off-by: Srikrishna Iyer <sriyer@google.com>

view details

push time in a day

PR merged lowRISC/opentitan

Reviewers
[dvsim, OTBN] Ability to execute arbitrary pre/post build/run commands & working OTBN smoke test

The first commit enhances DVSim to be able to add pre/post build and run commands art various levels.

The second updates OTBN DV to add the binary generation as a pre-run step.

+110 -30

6 comments

5 changed files

sriyerg

pr closed time in a day

issue closedlowRISC/opentitan

[dvsim] Add support for running arbitrary commands before / after builds and runs

This is needed to support OTBN, which requires some binaries to be built before launching a simulation run.

closed time in a day

sriyerg

pull request commentlowRISC/opentitan

[dvsim, OTBN] Ability to execute arbitrary pre/post build/run commands & working OTBN smoke test

Merging this in - I am happy to make any further amends in future PRs.

sriyerg

comment created time in a day

Pull request review commentlowRISC/ibex

Ibex fcov v3

 module ibex_controller #(     end   end +  //////////+  // FCOV //+  //////////+  `FCOV_SIGNAL(logic, interrupt_taken, (ctrl_fsm_cs != IRQ_TAKEN) & (ctrl_fsm_ns == IRQ_TAKEN));+  `FCOV_SIGNAL(logic, debug_entry_if, (ctrl_fsm_cs != DBG_TAKEN_IF) & (ctrl_fsm_ns == DBG_TAKEN_IF));+  `FCOV_SIGNAL(logic, debug_entry_id, (ctrl_fsm_cs != DBG_TAKEN_ID) & (ctrl_fsm_ns == DBG_TAKEN_ID));+  `FCOV_SIGNAL(logic, pipe_flush, (ctrl_fsm_cs != FLUSH) & (ctrl_fsm_ns == FLUSH));

The logic foo = value; syntax sets an initial value (rather like assigning it in an initial block though not precisely, all those initialisations occur before any initial block is scheduled) rather than creating a continuous assignment so won't do what we want in this case.

You can do this with nets, i.e. this would do what we want:

wire logic fcov_var = expr;

Though we don't use nets anywhere else and I don't think this alone justifies their inclusion (for one thing I don't know if Verilator even supports them).

Good point on the aggregate unused, one thing to deal with is the unknown width of the aggregate (at least unknown within the macro). I think we can use a unary or to deal with this, e.g.:

`define FCOV_UNUSED(__name, __sigs) assign unused``__name == |__sigs;

I guess this is a preference thing.

Pretty much, I'm not too opposed to doing it with explicit extra logic declaration lines though. Let's give @imphil the casting vote.

GregAC

comment created time in a day

Pull request review commentlowRISC/ibex

Ibex fcov v3

   end `endif +// Creates a SVA cover that can be used in a covergroup.+//+// This macro creates an unnamed SVA cover from the expression `__sva` and an event with the name+// `__ev_name`. When the SVA cover is hit, the event is triggered. A coverpoint can cover the+// `triggered` property of the event.+`ifndef DV_FCOV_SVA+`define DV_FCOV_SVA(__ev_name, __sva, __clk = clk_i, __rst = rst_ni) \+  event __ev_name; \+  cover property (@(posedge __clk) disable iff (__rst == 0) (__sva)) begin \+    -> __ev_name; \+  end+`endif++// Creates a coverpoint for a 1-bit signal where only the asserted state is of interest for coverage+// (e.g. where the signal indicates an event has occured).+`ifndef DV_FCOV_SEEN+`define DV_FCOV_SEEN(__cp_name, __sig_name) __cp_name: coverpoint __sig_name { bins seen = {1}; }+`endif

Will do, had failed to realize I'd accidentally written a macro that worked with arbitrary expressions!

GregAC

comment created time in a day

more