From 7f5d8c8dba9600a3ab47fae955802c1cf8c96290 Mon Sep 17 00:00:00 2001 From: David Biancolin Date: Wed, 24 Feb 2021 13:05:14 -0800 Subject: [PATCH 1/5] Update frequency selection related comments --- generators/firechip/src/main/scala/TargetConfigs.scala | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/generators/firechip/src/main/scala/TargetConfigs.scala b/generators/firechip/src/main/scala/TargetConfigs.scala index 92cd02c3..ece2546b 100644 --- a/generators/firechip/src/main/scala/TargetConfigs.scala +++ b/generators/firechip/src/main/scala/TargetConfigs.scala @@ -68,8 +68,10 @@ class WithFireSimConfigTweaks extends Config( new WithFireSimSimpleClocks ++ // Required*: When using FireSim-as-top to provide a correct path to the target bootrom source new WithBootROM ++ - // Optional*: Removing this will require adjusting the UART baud rate and - // potential target-software changes to properly capture UART output + // Optional: This sets the default frequency for all buses in the system to 3.2 GHz + // (since unspecified bus frequencies will use the pbus frequency) + // This frequency selection matches FireSim's legacy selection and is required + // to support 200Gb NIC performance. You may select a smaller value. new chipyard.config.WithPeripheryBusFrequency(3200.0) ++ // Optional: These three configs put the DRAM memory system in it's own clock domian. // Removing the first config will result in the FASED timing model running @@ -93,7 +95,7 @@ class WithFireSimConfigTweaks extends Config( new testchipip.WithDefaultSerialTL ++ // Optional: Removing this will require using an initramfs under linux new testchipip.WithBlockDevice ++ - // Required*: Scale default baud rate with periphery bus frequency + // Optional: Set a UART baudrate (this selection matches FireSim's historical value) new chipyard.config.WithUART(BigInt(3686400L)) ++ // Required: Do not support debug module w. JTAG until FIRRTL stops emitting @(posedge ~clock) new chipyard.config.WithNoDebug From bbaebcd596c18def77c59f4c963fa52189c04d0b Mon Sep 17 00:00:00 2001 From: Anoop Date: Wed, 31 Mar 2021 17:28:24 +0530 Subject: [PATCH 2/5] Update barstools.rst Added info about adding our own sram-macros cache --- docs/Tools/Barstools.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Tools/Barstools.rst b/docs/Tools/Barstools.rst index 6bd8f036..a36a29b1 100644 --- a/docs/Tools/Barstools.rst +++ b/docs/Tools/Barstools.rst @@ -24,7 +24,7 @@ A list of unique SRAM configurations is output to a ``.conf`` file by FIRRTL, wh Without this transform, FIRRTL will map all ``SeqMem`` s to flip-flop arrays with equivalent behavior, which may lead to a design that is difficult to route. The ``.conf`` file is consumed by a tool called MacroCompiler, which is part of the :ref:`Tools/Barstools:Barstools` scala package. -MacroCompiler is also passed an ``.mdf`` file that describes the available list of technology SRAMs or the capabilities of the SRAM compiler, if one is provided by the foundry. +MacroCompiler is also passed an ``.mdf`` file that describes the available list of technology SRAMs or the capabilities of the SRAM compiler, if one is provided by the foundry. You may wish to create a cache of your available SRAM macros either manually, or via a script. An reference script for creating a JSON of your SRAM macros is in the `asap7 technology library folder `__; the expected JSON format is `here `_. Typically a foundry SRAM compiler will be able to generate a set of different SRAMs collateral based on some requirements on size, aspect ratio, etc. (see :ref:`Tools/Barstools:SRAM MDF Fields`). Using a user-customizable cost function, MacroCompiler will select the SRAMs that are the best fit for each dimensionality in the ``.conf`` file. This may include over provisioning (e.g. using a 64x1024 SRAM for a requested 60x1024, if the latter is not available) or arraying. From a7befc8c5c45f0c3a77fe660e1b96a7ba2991d61 Mon Sep 17 00:00:00 2001 From: Anoop Date: Wed, 31 Mar 2021 22:19:49 +0530 Subject: [PATCH 3/5] Updated barstools.rst after review-1 Edits after review-1 --- docs/Tools/Barstools.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/Tools/Barstools.rst b/docs/Tools/Barstools.rst index a36a29b1..d8dd0427 100644 --- a/docs/Tools/Barstools.rst +++ b/docs/Tools/Barstools.rst @@ -24,13 +24,14 @@ A list of unique SRAM configurations is output to a ``.conf`` file by FIRRTL, wh Without this transform, FIRRTL will map all ``SeqMem`` s to flip-flop arrays with equivalent behavior, which may lead to a design that is difficult to route. The ``.conf`` file is consumed by a tool called MacroCompiler, which is part of the :ref:`Tools/Barstools:Barstools` scala package. -MacroCompiler is also passed an ``.mdf`` file that describes the available list of technology SRAMs or the capabilities of the SRAM compiler, if one is provided by the foundry. You may wish to create a cache of your available SRAM macros either manually, or via a script. An reference script for creating a JSON of your SRAM macros is in the `asap7 technology library folder `__; the expected JSON format is `here `_. +MacroCompiler is also passed an ``.mdf`` file that describes the available list of technology SRAMs or the capabilities of the SRAM compiler, if one is provided by the foundry. Typically a foundry SRAM compiler will be able to generate a set of different SRAMs collateral based on some requirements on size, aspect ratio, etc. (see :ref:`Tools/Barstools:SRAM MDF Fields`). Using a user-customizable cost function, MacroCompiler will select the SRAMs that are the best fit for each dimensionality in the ``.conf`` file. This may include over provisioning (e.g. using a 64x1024 SRAM for a requested 60x1024, if the latter is not available) or arraying. Arraying can be done in both width and depth, as well as to solve masking constraints. For example, a 128x2048 array could be composed of four 64x1024 arrays, with two macros in parallel to create two 128x1024 virtual SRAMs which are combinationally muxed to add depth. If this macro requires byte-granularity write masking, but no technology SRAMs support masking, then the tool may choose to use thirty-two 8x1024 arrays in a similar configuration. +You may wish to create a cache of your available SRAM macros either manually, or via a script. A reference script for creating a JSON of your SRAM macros is in the asap7 technology library` folder `__. For information on writing ``.mdf`` files, look at `MDF on github `__ and a brief description in :ref:`Tools/Barstools:SRAM MDF Fields` section. The output of MacroCompiler is a Verilog file containing modules that wrap the technology SRAMs into the specified interface names from the ``.conf``. @@ -73,7 +74,6 @@ Likewise, the ``--force-compile [mem]`` option allows the user to force MacroCom SRAM MDF Fields +++++++++++++++ - Technology SRAM macros described in MDF can be defined at three levels of detail. A single instance can be defined with the `SRAMMacro` format. A group of instances that share the number and type of ports but vary in width and depth can be defined with the `SRAMGroup` format. @@ -82,12 +82,14 @@ A set of groups of SRAMs that can be generated together from a single source lik At the most concrete level the `SRAMMAcro` defines a particular instance of an SRAM. That includes its functional attributes such as its width, depth, and number of access ports. These ports can be read, write, or read and write ports, and the instance can have any number. -In order to correctly map to these functional ports to the physical instance each port is described in a list of sub-structures, in the parent instance's structure. +In order to correctly map these functional ports to the physical instance, each port is described in a list of sub-structures, in the parent instance's structure. Each port is only required to have an address and data field, but can have many other optional fields. -These optional fields include a clock, write enable, read enable, chip enable, mask. +These optional fields include a clock, write enable, read enable, chip enable, mask and its granularity. The mask field can have a different granularity than the data field, e.g. it could be a bit mask or a byte mask. Each field must also specify its polarity, whether it is active high or active low. +The specific JSON file format described above is `here `_. A reference cache of SRAMs from the nangate45 technology library is `available here `_. + In addition to these functional descriptions of the SRAM there are also other fields that specify physical/implementation characteristics. These include the threshold voltage, the mux factor, as well as a list of extra non-functional ports. From a401861f5b9d650f3eab89f37d2516fc12bd9d93 Mon Sep 17 00:00:00 2001 From: Anoop Date: Tue, 6 Apr 2021 10:02:47 +0530 Subject: [PATCH 4/5] Update Barstools.rst --- docs/Tools/Barstools.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Tools/Barstools.rst b/docs/Tools/Barstools.rst index 0ebf9e70..fa4176c4 100644 --- a/docs/Tools/Barstools.rst +++ b/docs/Tools/Barstools.rst @@ -31,7 +31,7 @@ This may include over provisioning (e.g. using a 64x1024 SRAM for a requested 60 Arraying can be done in both width and depth, as well as to solve masking constraints. For example, a 128x2048 array could be composed of four 64x1024 arrays, with two macros in parallel to create two 128x1024 virtual SRAMs which are combinationally muxed to add depth. If this macro requires byte-granularity write masking, but no technology SRAMs support masking, then the tool may choose to use thirty-two 8x1024 arrays in a similar configuration. -You may wish to create a cache of your available SRAM macros either manually, or via a script. A reference script for creating a JSON of your SRAM macros is in the asap7 technology library` folder `__. +You may wish to create a cache of your available SRAM macros either manually, or via a script. A reference script for creating a JSON of your SRAM macros is in the `asap7 technology library folder `__. For information on writing ``.mdf`` files, look at `MDF on github `__ and a brief description in :ref:`Tools/Barstools:SRAM MDF Fields` section. The output of MacroCompiler is a Verilog file containing modules that wrap the technology SRAMs into the specified interface names from the ``.conf``. From ffd312f6ea1c904a56ddffeb016c8c55fa2b2bae Mon Sep 17 00:00:00 2001 From: Anoop Date: Tue, 6 Apr 2021 10:10:39 +0530 Subject: [PATCH 5/5] conflict resolution --- generators/firechip/src/main/scala/TargetConfigs.scala | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/generators/firechip/src/main/scala/TargetConfigs.scala b/generators/firechip/src/main/scala/TargetConfigs.scala index dd2e2bcc..43fea874 100644 --- a/generators/firechip/src/main/scala/TargetConfigs.scala +++ b/generators/firechip/src/main/scala/TargetConfigs.scala @@ -77,7 +77,7 @@ class WithFireSimDesignTweaks extends Config( new freechips.rocketchip.subsystem.WithExtMemSize((1 << 30) * 16L) ++ // Optional: Removing this will require using an initramfs under linux new testchipip.WithBlockDevice ++ - // Optional: Set a UART baudrate (this selection matches FireSim's historical value) + // Required*: Scale default baud rate with periphery bus frequency new chipyard.config.WithUART(BigInt(3686400L)) ++ // Required: Do not support debug module w. JTAG until FIRRTL stops emitting @(posedge ~clock) new chipyard.config.WithNoDebug