SME 0.5.0

.NET 5.0
dotnet add package SME --version 0.5.0
NuGet\Install-Package SME -Version 0.5.0
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="SME" Version="0.5.0" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add SME --version 0.5.0
#r "nuget: SME, 0.5.0"
#r directive can be used in F# Interactive, C# scripting and .NET Interactive. Copy this into the interactive tool or source code of the script to reference the package.
// Install SME as a Cake Addin
#addin nuget:?package=SME&version=0.5.0

// Install SME as a Cake Tool
#tool nuget:?package=SME&version=0.5.0

Synchronous Message Exchange simulation and component library

Product Versions
.NET net5.0 net5.0-windows net6.0 net6.0-android net6.0-ios net6.0-maccatalyst net6.0-macos net6.0-tvos net6.0-windows net7.0 net7.0-android net7.0-ios net7.0-maccatalyst net7.0-macos net7.0-tvos net7.0-windows
Compatible target framework(s)
Additional computed target framework(s)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (6)

Showing the top 5 NuGet packages that depend on SME:

Package Downloads

Abstract syntax tree builder for SME networks


VHDL transpiler for SME networks


Tracing module for SME networks


GraphViz renderer for Synchronous Message Exchange


C++ transpiler for SME networks

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
0.5.0 807 2/17/2022
0.4.4 984 4/27/2021
0.4.3 1,018 2/18/2021
0.4.2 1,212 9/16/2020
0.4.1-beta 786 6/26/2019
0.4.0-beta 927 2/19/2019
0.3.3-beta 1,219 3/22/2018
0.3.2 1,496 2/11/2018
0.3.1 1,445 12/11/2017
0.3.0 846 12/11/2017
0.1.0 1,257 5/3/2016

New in version 0.5.0 since 0.4.4
* Major changes *
- The decompiler backend (ICSharpCode) has been replaced by a compiler backend
(Microsoft Codeanalysis).
- Upgraded to support .NET 5
* Changes *
- VHDL keyword avoidance prefix was incorrectly added to bus signal names in
the trace file. They already carried a prefix from the bus name.
- Moved from Travis to Github Actions.
- Added support for supplying custom renderers to processes.
- Added preliminary support for floating point data types. They can be used on
buses and initialization values. The generated VHDL inside of the processes
are still incorrect, however.
- Added "generate" as a VHDL keyword.
- Added the clog2 function to the generated VHDL.
- Processes, which uses arrays, are now parameterized in the generated VHDL,
instead of being hardcoded.
- NuGet packages have been updated.
- Added "next" and "constant" VHDL keywords.
- Added optional code coverage during testing.
- Unit testing has increased to improve coverage.
* Fixes *
- Omitted type definitions when buses have multiple fields of IFixedArray type.
- Buses would sometimes carry U values, when it should have been the default
value, in the trace file.
- Naming of the top-level scope now matches the assembly namespace, not the
namespace of the first created process.
- Some processes were incorrectly named.
- Array lengths was sometimes placed incorrectly.
- Multiple type definitions were generated.
- Multiple type conversions on signals were generated.
- Dual port memory is now correctly reset.
- Missing type conversions in function invocations.
- Some loop edges were incorrectly transformed for irregular loop edges.
- Missing sizes on constant arrays.
- Missing initial value in dependency cycle test.
- Internal arrays in memory components shouldn't be readonly.
- Incorrect warning about comparing symbols.
- Updated RAMs to be generic.
- ColorBin example wasn't properly checked.
- Increased the size of the ColorBin, AES, NoiseFilter, ExternalComponent,
SimpleMIPS, and StopWatch tests longer.
- Enum definitions wouldn't compile.
- Found incorrect string comparisons when launching programs.
- Type wasn't loaded properly for parameters.
- Found a race condition in the code for buses, which lead to an improper
modeling of multiple processes writing to the same bus signal. This is still
not properly captured, so multiple processes running in parallel can write to
the same signal, which is not allowed in actual hardware. Current solution
suggestion is to introduce a warning, since the bus cannot know which process
wrote what.