[clean] remove non-ASCIIs where possible
Signed-off-by: Scott Johnson <scottdj@google.com>
diff --git a/doc/project/_index.md b/doc/project/_index.md
index 84b421e..80452af 100644
--- a/doc/project/_index.md
+++ b/doc/project/_index.md
@@ -19,7 +19,7 @@
As a lowRISC CIC Chartered Project, OpenTitan governance is handled via lowRISC's default Technical Charter.
As described in full detail in the [OpenTitan Technical Charter](https://static.opentitan.org/technical-charter.pdf), our governance structure consists of:
-* The Project Director, Dominic Rizzo, who is a representative of the lowRISC CIC’s Board of Directors within the Steering Committee.
+* The Project Director, Dominic Rizzo, who is a representative of the lowRISC CIC's Board of Directors within the Steering Committee.
* The Steering Committee, responsible for project oversight and agreeing the technical roadmap.
* The Technical Committee, responsible for technical decision making required to implement the technical roadmap.
diff --git a/doc/project/hw_stages.md b/doc/project/hw_stages.md
index 3a20ece..b887bcf 100644
--- a/doc/project/hw_stages.md
+++ b/doc/project/hw_stages.md
@@ -107,7 +107,7 @@
| V0 | Initial Work | Testbench being developed, not functional; test plan being written; decided which methodology to use (sim-based DV, FPV, or both). |
| V1 | Under Test | <ul> <li> Documentation: DV Plan available, testplan completed and reviewed <li> Testbench: <ul><li>DUT instantiated with major interfaces hooked up <li>All available interface assertion monitors hooked up <li>X / unknown checks on DUT outputs added <li>Skeleton environment created with UVCs <li>TLM connections made from interface monitors to the scoreboard </ul> <li>Tests (written and passing): <ul> <li>Sanity test accessing basic functionality <li>CSR / mem test suite </ul> <li>Regressions: Sanity and nightly regression set up</ul> |
| V2 | Testing Complete | <ul> <li>Documentation: DV plan completely written <li>Design Issues: <ul><li> all high priority bugs addressed <li> low priority bugs root-caused </ul> <li>Testbench: <ul><li>all interfaces hooked up and exercised <li> all assertions written and enabled </ul> <li>UVM environment: fully developed with end-to-end checks in scoreboard <li>Tests (written and passing): all tests planned for in the testplan <li>Regression: all tests passing in nightly regression with multiple seeds (> 90%) <li>Coverage: 90% code coverage across the board, 100% functional coverpoints covered and 75% crosses covered</ul></ul> |
-| V3 | Verification Complete | <ul> <li>Design Issues: all bugs addressed <li> Tests (written and passing): all tests including newly added post-V2 tests (if any) <li>Regression: all tests with all seeds passing <li>Coverage: 100% code and 100% functional coverage with waivers </ul> </ul> |
+| V3 | Verification Complete | <ul> <li>Design Issues: all bugs addressed <li> Tests (written and passing): all tests including newly added post-V2 tests (if any) <li>Regression: all tests with all seeds passing <li>Coverage: 100% code and 100% functional coverage with waivers </ul> </ul> |
**Stages for FPV approaches**:
@@ -116,7 +116,7 @@
| V0 | Initial Work | Testbench being developed, not functional; test plan being written; decided which methodology to use (sim-based DV, FPV, or both). |
| V1 | Under Test | <ul> <li> Documentation: <ul> <li> DV Plan available, testplan completed and reviewed </ul> <li> Testbench: <ul><li> Formal testbench with DUT bound to assertion module(s) <li> All available interface assertion monitors hooked up <li> X / unknown assertions on DUT outputs added </ul> <li> Assertions (written and proven): <ul> <li>All functional properties identified and described in testplan <li>Assertions for main functional path implemented and passing (sanity check)<li> Each input and each output is part of at least one assertion</ul><li>Regressions: Sanity and nightly regression set up</ul> |
| V2 | Testing Complete | <ul> <li>Documentation: DV plan completely written <li>Design Issues: <ul><li> all high priority bugs addressed <li> low priority bugs root-caused </ul> <li>Testbench: <ul><li>all interfaces have assertions checking the protocol <li> all functional assertions written and enabled <li> assumptions for FPV specified and reviewed </ul> <li>Tests (written and passing): all tests planned for in the testplan <li> Regression: 90% of properties proven in nightly regression <li> Coverage: 90% code coverage and 75% logic cone of influence (COI) coverage </ul> |
-| V3 | Verification Complete | <ul> <li>Design Issues: all bugs addressed <li> Assertions (written and proven): all assertions including newly added post-V2 assertions (if any) <li>Regression: 100% of properties proven (with reviewed assumptions) <li> Coverage: 100% code coverage and 100% COI coverage</ul> |
+| V3 | Verification Complete | <ul> <li>Design Issues: all bugs addressed <li> Assertions (written and proven): all assertions including newly added post-V2 assertions (if any) <li>Regression: 100% of properties proven (with reviewed assumptions) <li> Coverage: 100% code coverage and 100% COI coverage</ul> |
## Signoff Review
diff --git a/doc/security/logical_security_model/index.md b/doc/security/logical_security_model/index.md
index f36e22c..09086f8 100644
--- a/doc/security/logical_security_model/index.md
+++ b/doc/security/logical_security_model/index.md
@@ -25,7 +25,7 @@
* Fabless semiconductors companies that design a chip and prepare a GDSII for silicon foundries
* A silicon foundry which manufactures and wafer-tests the chip
* An OSAT (see glossary) which packages and performs final tests
-* A provisioning entity that manages the chip’s provisioning process
+* A provisioning entity that manages the chip's provisioning process
A creator may also be a single, vertically integrated entity that performs all the above functions.
@@ -63,7 +63,7 @@
In addition to assigning the chip an **Owner Identity**, the Silicon Owner is responsible for supplying a functional software stack.
This can range from a full kernel / operating system to a bare-metal environment depending on application needs.
-In order to support secure boot without including verification keys directly in the silicon design, the owner creates an **“Owner Assignment Blob”** which is endorsed by the creator.
+In order to support secure boot without including verification keys directly in the silicon design, the owner creates an **"Owner Assignment Blob"** which is endorsed by the creator.
This blob is loaded into the device as a part of ownership assignment and contains public keys used to verify the owner's initial boot stage.
#### Overlap between Silicon Owner and Silicon Creator
diff --git a/doc/ug/dv_methodology.md b/doc/ug/dv_methodology.md
index d7dfd03..70e4ff7 100644
--- a/doc/ug/dv_methodology.md
+++ b/doc/ug/dv_methodology.md
@@ -301,7 +301,7 @@
Collecting, analyzing and reporting coverage with waivers is another requirement to assert 'verification complete'.
Any gaps in our measured coverage need to be understood and either waived (no need to cover) or closed by additional testing.
The end goal is to achieve 100% coverage across all applicable coverage metrics.
-This process known as “coverage closure”, is done in close collaboration with the designer(s).
+This process known as "coverage closure", is done in close collaboration with the designer(s).
Coverage collected from all tests run as a part of the regression is merged into a database for analysis.
Our primary tool of choice for our coverage closure needs is Synopsys' VCS & Verdi.
However, the use of other tools / simulators are welcome.
@@ -318,8 +318,8 @@
* **Line Coverage**: This metric measures which lines of SystemVerilog RTL code were executed during the course of the simulation.
This is probably the most intuitive metric to use.
- Note that “assign” statements are always listed as covered using this metric.
-* **Toggle Coverage**: This metric measures every logic bit to see if it transitions from 1→ 0 and 0 → 1.
+ Note that "assign" statements are always listed as covered using this metric.
+* **Toggle Coverage**: This metric measures every logic bit to see if it transitions from 1 → 0 and 0 → 1.
It is very difficult, and not particularly useful to achieve 100% toggle coverage across a design.
Instead, we focus on closing toggle coverage only on the IO ports of the DUT and IO ports of pre-verified IPs within the DUT.
* **FSM state Coverage**: This metric measures which finite state machine states were executed during the course of a simulation.
@@ -344,7 +344,7 @@
* **Assert Coverage**: This metric measures which assertions, cover properties and sequences have been exercised in the course of the simulation.
Note, an assertion precondition counts as a cover point.
-* **Covergroup Coverage**: This metric (sometimes called “Testbench Coverage”) measures covergroups during simulation.
+* **Covergroup Coverage**: This metric (sometimes called "Testbench Coverage") measures covergroups during simulation.
These are usually coded in the testbench to check that the desired stimulus was generated properly, but can also be embedded in the RTL.
Code coverage can reach 100% but it may not be sufficient to indicate whether all interesting combinations of scenarios were exercised (such as boundary conditions, concurrent scenarios and different CSR fields holding specific combinations of values resulting in the DUT being exercised in interesting ways).
diff --git a/hw/ip/aes/doc/_index.md b/hw/ip/aes/doc/_index.md
index e8709fd..e6d6765 100644
--- a/hw/ip/aes/doc/_index.md
+++ b/hw/ip/aes/doc/_index.md
@@ -146,7 +146,7 @@
It only continues once the previous output data has been read and the corresponding registers can be safely overwritten.
In contrast, the initial key can only be updated if the AES unit is idle, which eases design verification (DV).
-The architecture of the AES unit is derived from the architecture proposed by Satoh et al.: [“A compact Rijndael Hardware Architecture with S-Box Optimization”](https://link.springer.com/chapter/10.1007%2F3-540-45682-1_15).
+The architecture of the AES unit is derived from the architecture proposed by Satoh et al.: ["A compact Rijndael Hardware Architecture with S-Box Optimization"](https://link.springer.com/chapter/10.1007%2F3-540-45682-1_15).
The expected circuit area in a 110nm CMOS technology is in the order of 12 - 22 kGE (AES-128 only).
For a description of the various sub modules, see the following sections.
@@ -163,7 +163,7 @@
Since the S-Boxes can be decoupled from the rest of the AES unit, they can easily be replaced by a different implementation if required.
The AES unit currently uses a LUT-based S-Box implementation (default) but also supports the implementation proposed by [Canright: "A very compact Rijndael S-Box"](https://hdl.handle.net/10945/25608) (selectable by a compile-time parameter).
-A possible candidate implementation that employs masking (i.e. that randomizes the power consumption of the AES unit in every cipher round) to aggravate power analysis attacks has been proposed by [Canright and Batina: “A very compact “perfectly masked” S-Box for AES (corrected)”](https://eprint.iacr.org/2009/011.pdf).
+A possible candidate implementation that employs masking (i.e. that randomizes the power consumption of the AES unit in every cipher round) to aggravate power analysis attacks has been proposed by [Canright and Batina: "A very compact "perfectly masked" S-Box for AES (corrected)"](https://eprint.iacr.org/2009/011.pdf).
### ShiftRows
@@ -219,7 +219,7 @@
The cipher data path remains idle (`AES mode`=IDLE).
In every round, the value in `key_full` is updated.
After 10 encryption rounds, the value in `key_full` equals the start key for decryption.
-This value is stored into the Decryption Key register (`key_dec` = K0-3’ at the very bottom).
+This value is stored into the Decryption Key register (`key_dec` = K0-3' at the very bottom).
Now the AES unit can switch between encryption/decryption without overhead as both the start key for encryption (`key_init`) and decryption (`key_dec`) can be loaded into `full_key`.
For details on the KeyExpand operation refer to the [AES specification, Section 5.2](https://csrc.nist.gov/csrc/media/publications/fips/197/final/documents/fips-197.pdf).
diff --git a/hw/ip/i2c/dv/env/seq_lib/i2c_common_vseq.sv b/hw/ip/i2c/dv/env/seq_lib/i2c_common_vseq.sv
index b7e74e9..7fe342e 100644
--- a/hw/ip/i2c/dv/env/seq_lib/i2c_common_vseq.sv
+++ b/hw/ip/i2c/dv/env/seq_lib/i2c_common_vseq.sv
@@ -62,7 +62,7 @@
csr_excl.add_excl({scope, ".", "intr_test"}, CsrExclInitCheck);
end
- // bit_bash: write 1’s and 0’s to every bit of non-RO registers (CsrExclWrite/WriteCheck)
+ // bit_bash: write 1's and 0's to every bit of non-RO registers (CsrExclWrite/WriteCheck)
// making sure that the resulting value matches the mirrored value
if (csr_test_type == "bit_bash") begin
// specify at least one RW register for this test
diff --git a/hw/ip/rv_core_ibex/doc/checklist.md b/hw/ip/rv_core_ibex/doc/checklist.md
index 70dd412..fdbcfee 100644
--- a/hw/ip/rv_core_ibex/doc/checklist.md
+++ b/hw/ip/rv_core_ibex/doc/checklist.md
@@ -116,7 +116,7 @@
Testbench | [TB_GEN_AUTOMATED][] | N/A |
Tests | [SANITY_TEST_PASSING][] | Done |
Tests | [CSR_MEM_TEST_SUITE_PASSING][] | Done |
-Tool Setup | [ALT_TOOL_SETUP][] | Waived | waived for now, doesn’t follow standard tool flow
+Tool Setup | [ALT_TOOL_SETUP][] | Waived | waived for now, doesn't follow standard tool flow
Regression | [SANITY_REGRESSION_SETUP][] | Done |
Regression | [NIGHTLY_REGRESSION_SETUP][] | Done |
Coverage | [COVERAGE_MODEL_ADDED][] | Done |
diff --git a/site/landing/content/privacy-policy.md b/site/landing/content/privacy-policy.md
index 3109738..f7b29ed 100644
--- a/site/landing/content/privacy-policy.md
+++ b/site/landing/content/privacy-policy.md
@@ -7,7 +7,7 @@
We take the privacy of those who visit this website seriously and we aim to be
transparent about our processing of personal information. Accordingly, this
page explains the kinds of information we may collect about you, and the
-reasons for collecting this information.
+reasons for collecting this information.
# General website information
@@ -17,7 +17,7 @@
in which people use our website; to detect bugs; and hostile access. We
routinely delete our server logs after 30 days, and the analytics data
associated with each user is only retained for 26 months after the last time
-they visit the site.
+they visit the site.
We share this information only with our website hosting service Google Cloud,
and analytics provider Google Analytics, who are under an obligation not to use
@@ -26,7 +26,7 @@
# Cookies
To make this website work properly, we sometimes place small data files called
-“cookies” on your device. Most big websites do this too.
+"cookies" on your device. Most big websites do this too.
# What are cookies?
@@ -34,7 +34,7 @@
your computer or mobile device when you visit the site. It enables the website,
including plugins such as YouTube, to remember your actions and preferences
(such as login, language, font size and other display preferences) over a
-period of time, so you don’t have to keep re-entering them whenever you come
+period of time, so you don't have to keep re-entering them whenever you come
back to the site or browse from one page to another. It also enables us to
analyse how this website is being used.
@@ -52,7 +52,7 @@
# How to control cookies
-You can control and/or delete cookies as you wish – for details, see
+You can control and/or delete cookies as you wish - for details, see
[aboutcookies.org](https://aboutcookies.org). You can delete all cookies that
are already on your computer and you can set most browsers to prevent them from
being placed. If you do this, however, you may have to manually adjust some
@@ -66,8 +66,8 @@
* Email address
-Unless we are in direct correspondence with you – for example because you have
-asked us specific questions about our products or services – we will only use
+Unless we are in direct correspondence with you - for example because you have
+asked us specific questions about our products or services - we will only use
this information for the following purposes:
* Promotional emails, for example:
@@ -91,14 +91,14 @@
# Lawful basis
It is lawful for us, under the General Data Protection Regulation (GDPR), to
-process the information described in this notice because we have a
+process the information described in this notice because we have a
* Legitimate interest in operating a website and using the information we
- collect for these purposes.
+ collect for these purposes.
* Where you have signed up to a mailing list, we have a legitimate interest
in emailing you so long as you do not object to our doing so.
-We do not believe the way in which we are processing them is likely to cause you any harm.
+We do not believe the way in which we are processing them is likely to cause you any harm.
# Transfer of data outside the United Kingdom & Europe
@@ -132,7 +132,7 @@
circumstances
For further information on each of those rights, including the circumstances in
-which they apply, see the [Guidance from the UK Information Commissioner’s
+which they apply, see the [Guidance from the UK Information Commissioner's
Office (ICO) on individuals rights under the General Data Protection
Regulation](http://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/).
@@ -145,7 +145,7 @@
website and from what location)
If you would like to unsubscribe from any email newsletter you can also click
-on the ‘unsubscribe’ button at the bottom of the email newsletter. It may take
+on the 'unsubscribe' button at the bottom of the email newsletter. It may take
up to seven days for this to take place.
The [General Data Protection
diff --git a/site/landing/content/trademark-usage-policy.md b/site/landing/content/trademark-usage-policy.md
index 685bcf2..816116f 100644
--- a/site/landing/content/trademark-usage-policy.md
+++ b/site/landing/content/trademark-usage-policy.md
@@ -2,17 +2,17 @@
title: "OpenTitan Trademark Usage Policy"
---
-The OpenTitan trademarks and logos (“OpenTitan Trademarks”) are licensed
+The OpenTitan trademarks and logos ("OpenTitan Trademarks") are licensed
separately from the copyright or patent license grants contained in the
Apache-licensed OpenTitan repositories on GitHub. Except as provided in this
-policy, you may not use any of the OpenTitan Trademarks.
+policy, you may not use any of the OpenTitan Trademarks.
# Purpose of the Trademark Policy
This policy exists to ensure that the identity and meaning of OpenTitan
technology is clear to everyone. By using this policy, the OpenTitan project
can share its technology under open source licenses while making sure that
-“OpenTitan” is protected as a meaningful source identifier in a way that’s
+"OpenTitan" is protected as a meaningful source identifier in a way that's
consistent with trademark law. This policy permits clear and appropriate use of
the OpenTitan project name while preventing abusive uses that could mislead
consumers. By adhering to this policy, you help to promote the freedom to use
@@ -24,22 +24,22 @@
to other sections):
1. To refer to the OpenTitan Project itself;
- 2. To identify OpenTitan design(s) in unmodified forms;
+ 2. To identify OpenTitan design(s) in unmodified forms;
3. To refer to unmodified source code, verilog, or other files shared by
- lowRISC’s OpenTitan repositories on GitHub;
+ lowRISC's OpenTitan repositories on GitHub;
4. To refer to certified, approved chip implementations of the OpenTitan
- design(s) in accordance with the “technical specifications” section of
+ design(s) in accordance with the "technical specifications" section of
this policy; and
5. To explain or disclose that your design or implementation is based on the
OpenTitan design(s), _if and only if_ (i) the use of the OpenTitan
Trademarks is in accordance with this policy, (ii) your product itself
- does not describe itself as being “OpenTitan,” and (iii) it is adequately
+ does not describe itself as being "OpenTitan," and (iii) it is adequately
disclaimed that the implementation is not approved or OpenTitan Certified.
- For example, it is acceptable to say, “This is an unofficial
+ For example, it is acceptable to say, "This is an unofficial
implementation of the OpenTitan design. It is not (yet) OpenTitan
- Certified.” It is not acceptable to say, “This is an OpenTitan chip,”
+ Certified." It is not acceptable to say, "This is an OpenTitan chip,"
unless the OpenTitan Project actually approved that specific
- implementation for the OpenTitan Certification.
+ implementation for the OpenTitan Certification.
# Logo Usage Guidelines
@@ -55,7 +55,7 @@
specifications set forth below. You may not use the OpenTitan Trademarks in any
other manner that might cause confusion as to the source or affiliation of your
product, including but not limited to advertising, websites, or social media,
-or packaging. We ask that you not use the word “OpenTitan,” the OpenTitan logos
+or packaging. We ask that you not use the word "OpenTitan," the OpenTitan logos
and any portion of the logos in association with any other product, service, or
entity other than the OpenTitan project.
@@ -68,12 +68,12 @@
Any person may utilize and implement the designs shared in the OpenTitan GitHub
repositories according to the license terms in the LICENSE file. However, no
-implementations or uses may be referred to as “OpenTitan” unless such usage is
+implementations or uses may be referred to as "OpenTitan" unless such usage is
approved for OpenTitan Certification.
In order to be eligible for OpenTitan Certification, an implementation of the
OpenTitan designs must (i) meet the standards of the OpenTitan Technical
-Framework (“Technical Framework”) approved by the OpenTitan Steering Committee
+Framework ("Technical Framework") approved by the OpenTitan Steering Committee
(as described in the OpenTitan Project Charter), and (ii) be approved by the
lowRISC Board of Directors.
@@ -94,7 +94,7 @@
contributors to the OpenTitan Project. This policy does not authorize you to
act as an agent on behalf of the OpenTitan Project, and we would prefer to make
our own determinations as to whether a given use of the OpenTitan Trademarks is
-acceptable or unacceptable use.
+acceptable or unacceptable use.
If you see any of the OpenTitan Trademarks being used in a way that could be
misleading or infringing, please tell us! Just send an email to
diff --git a/site/landing/content/usage-policy.md b/site/landing/content/usage-policy.md
index be0b13e..5480963 100644
--- a/site/landing/content/usage-policy.md
+++ b/site/landing/content/usage-policy.md
@@ -8,29 +8,29 @@
# General
-1. You may use the web pages located under the domain *OpenTitan.org* (“this
- website”) on the terms set out on this page. They are not intended to form a
+1. You may use the web pages located under the domain *OpenTitan.org* ("this
+ website") on the terms set out on this page. They are not intended to form a
contract between you and us.
1. In these terms, certain words and phrases have a particular meaning as
follows:
- 1. “content” means any text, images, video, audio or other multimedia
+ 1. "content" means any text, images, video, audio or other multimedia
content, software, or other information or material submitted to or on the
website;
- 1. “intellectual property” means any rights in patents, design , copyright,
+ 1. "intellectual property" means any rights in patents, design , copyright,
databases, trade marks, domain names confidential information and all
other forms of intellectual property, whether registered or unregistered,
wherever in the world;
- 1. “you” or “your” means the person accessing or using the website or its
- content;
+ 1. "you" or "your" means the person accessing or using the website or its
+ content;
- 1. “processing” when applied to personal information includes storage of that
+ 1. "processing" when applied to personal information includes storage of that
information; and
- 1. “we”, “us” or “our” refers to lowRISC Community Interest Company, company
+ 1. "we", "us" or "our" refers to lowRISC Community Interest Company, company
registration number 09272283, with VAT registration number 327 0252 32 and
whose registered address is at 4a Newmarket Road, Cambridge, CB5 8DT, UK.
@@ -107,7 +107,7 @@
convenience only. We have no control over third party websites and accept no
legal responsibility for any content, material or information contained in
them. The display of any hyperlink and reference to any third party website
- does not mean that we endorse that third party’s website, products or
+ does not mean that we endorse that third party's website, products or
services. Your use of a third party site may be governed by the terms and
conditions of that third party site.
@@ -125,7 +125,7 @@
1. any incompatibility of this website with any particular browser or browser
plugin; or
- 1. economic loss or other loss of turnover, profit, business or goodwill.
+ 1. economic loss or other loss of turnover, profit, business or goodwill.
1. These terms are to be interpreted in accordance with English law and the
courts of England shall have jurisdiction to settle any disputes arising
diff --git a/site/landing/data/partner_quotes.json b/site/landing/data/partner_quotes.json
index d33f8da..419ff73 100644
--- a/site/landing/data/partner_quotes.json
+++ b/site/landing/data/partner_quotes.json
@@ -25,6 +25,6 @@
},
{
"partner": "Dominic Rizzo, OpenTitan Project Director, lowRISC",
- "quote": "Customers are asked to put faith in proprietary root of trust chips for mission-critical systems without the ability to fully understand, inspect and therefore trust them. By creating OpenTitan with the broader hardware and academic community, we leverage the experience and security principles used to create Google’s Titan chips to make hardware root of trust designs more transparent, inspectable, and accessible to the rest of the industry. Security should never be built on opacity."
+ "quote": "Customers are asked to put faith in proprietary root of trust chips for mission-critical systems without the ability to fully understand, inspect and therefore trust them. By creating OpenTitan with the broader hardware and academic community, we leverage the experience and security principles used to create Google's Titan chips to make hardware root of trust designs more transparent, inspectable, and accessible to the rest of the industry. Security should never be built on opacity."
}
]
diff --git a/site/landing/layouts/index.html b/site/landing/layouts/index.html
index 7163d1c..6ab336b 100644
--- a/site/landing/layouts/index.html
+++ b/site/landing/layouts/index.html
@@ -108,7 +108,7 @@
<div class="benefit__content">
<h3 class="benefit__headline h2">Transparent</h3>
<p class="benefit__body bodytext bodytext--large">
- Anyone can inspect, evaluate, and contribute to OpenTitan’s design
+ Anyone can inspect, evaluate, and contribute to OpenTitan's design
and documentation to help build a more transparent, trustworthy
silicon RoT for all.
</p>
@@ -127,7 +127,7 @@
<div class="benefit__content">
<h3 class="benefit__headline h2">High quality</h3>
<p class="benefit__body bodytext bodytext--large">
- OpenTitan’s aim is to build and maintain a high-quality
+ OpenTitan's aim is to build and maintain a high-quality
logically-secure silicon design, including reference firmware,
verification collateral, and technical documentation.
</p>
@@ -210,7 +210,7 @@
actively mediating access to the first-stage boot firmware. It is
built upon the quality constructs and security principles used to
create
- <a href="{{ .Site.Params.blogpost }}">Google’s Titan chips</a>.
+ <a href="{{ .Site.Params.blogpost }}">Google's Titan chips</a>.
</p>
</li>
<li class="feature-list__item">
@@ -351,7 +351,7 @@
preventScrollOnTouch: 'auto',
controlsPosition: 'bottom',
controlsText: [
- "<span class='sr-only'>prev</span><svg viewBox='0 0 40 40'><path fill='currentColor' fill-rule='evenodd' d='M16 20l9-6v12z' focusable='false'/></svg>",
+ "<span class='sr-only'>prev</span><svg viewBox='0 0 40 40'><path fill='currentColor' fill-rule='evenodd' d='M16 20l9-6v12z' focusable='false'/></svg>",
"<span class='sr-only'>next</span><svg viewBox='0 0 40 40'><path fill='currentColor' fill-rule='evenodd' d='M24 20l-9-6v12z' focusable='false'/></svg>"]
});
diff --git a/util/tlgen/elaborate.py b/util/tlgen/elaborate.py
index 5ae5227..e1c1633 100644
--- a/util/tlgen/elaborate.py
+++ b/util/tlgen/elaborate.py
@@ -53,7 +53,7 @@
a. (New node) Create SOCKET_1N node.
b. Revise every edges from the node to have SOCKET_1N node as start node.
c. (New Edge) Create a edge from the node to SOCKET_1N node.
- d. (for loop) Repeat the algorithm with SOCKET_1N’s other side node.
+ d. (for loop) Repeat the algorithm with SOCKET_1N's other side node.
"""
# If a node has different clock from main clock and not ASYNC_FIFO:
