This is especially useful for serializing large data structures. When emitting Strings, it makes it much easier to avoid materializing the entire serialized String in memory. It also helps avoid materializing intermediate datastructures in memory. Finally, it reduces iteration overhead and helps optimize I/O performance.
It may seem strange to use Array[Byte] in an otherwise immutable API, but for maximal performance it is best to use the JVM primitive that file I/O uses. These Arrays should only used immutably even though the Java API technically does allow mutating them.
Attributes
Deprecated
[Since version Chisel 7.0.0] All APIs in package firrtl are deprecated.
A buffered version of getBytes for more efficient serialization
A buffered version of getBytes for more efficient serialization
If you only need to serialize an Iterable[String], you can use the String.getBytes method. It's also helpful to create a view which will do the .map lazily instead of eagerly, improving GC performance.
Optionally, a sequence of annotations that will replace this annotation in the output annotation file.
Optionally, a sequence of annotations that will replace this annotation in the output annotation file.
A non-empty implementation of this method is a mechanism for telling a downstream Stage how to deserialize the information that was serialized to a separate file. For example, if a FIRRTL circuit is serialized to a separate file, this method could include an input file annotation that a later stage can use to read the serialized FIRRTL circuit back in.
Output filename where serialized content will be written
Output filename where serialized content will be written
The full annotation sequence is a parameter to allow for the location where this annotation will be serialized to be a function of other annotations, e.g., if the location where information is written is controlled by a separate file location annotation.