yosys/kernel/fstdata.cc

274 lines
7.9 KiB
C++
Raw Permalink Normal View History

2022-01-26 03:23:38 -06:00
/*
* yosys -- Yosys Open SYnthesis Suite
*
* Copyright (C) 2022 Miodrag Milanovic <micko@yosyshq.com>
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
*/
#include "kernel/fstdata.h"
USING_YOSYS_NAMESPACE
2022-01-31 03:52:47 -06:00
static std::string file_base_name(std::string const & path)
{
return path.substr(path.find_last_of("/\\") + 1);
}
2022-01-26 03:23:38 -06:00
FstData::FstData(std::string filename) : ctx(nullptr)
{
#if !defined(YOSYS_DISABLE_SPAWN)
std::string filename_trim = file_base_name(filename);
if (filename_trim.size() > 4 && filename_trim.compare(filename_trim.size()-4, std::string::npos, ".vcd") == 0) {
filename_trim.erase(filename_trim.size()-4);
tmp_file = stringf("%s/converted_%s.fst", get_base_tmpdir().c_str(), filename_trim.c_str());
std::string cmd = stringf("vcd2fst %s %s", filename.c_str(), tmp_file.c_str());
log("Exec: %s\n", cmd.c_str());
if (run_command(cmd) != 0)
log_cmd_error("Shell command failed!\n");
filename = tmp_file;
}
#endif
2022-01-31 03:52:47 -06:00
const std::vector<std::string> g_units = { "s", "ms", "us", "ns", "ps", "fs", "as", "zs" };
2022-01-26 03:23:38 -06:00
ctx = (fstReaderContext *)fstReaderOpen(filename.c_str());
2022-02-04 04:11:36 -06:00
if (!ctx)
2022-02-18 08:06:49 -06:00
log_error("Error opening '%s' as FST file\n", filename.c_str());
2022-01-31 03:52:47 -06:00
int scale = (int)fstReaderGetTimescale(ctx);
timescale = pow(10.0, scale);
timescale_str = "";
int unit = 0;
int zeros = 0;
if (scale > 0) {
zeros = scale;
} else {
if ((scale % 3) == 0) {
zeros = (-scale % 3);
unit = (-scale / 3);
} else {
zeros = 3 - (-scale % 3);
unit = (-scale / 3) + 1;
}
}
for (int i=0;i<zeros; i++) timescale_str += "0";
timescale_str += g_units[unit];
2022-01-26 03:23:38 -06:00
extractVarNames();
}
FstData::~FstData()
{
if (ctx)
fstReaderClose(ctx);
if (!tmp_file.empty())
remove(tmp_file.c_str());
2022-01-26 03:23:38 -06:00
}
uint64_t FstData::getStartTime() { return fstReaderGetStartTime(ctx); }
uint64_t FstData::getEndTime() { return fstReaderGetEndTime(ctx); }
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
static void normalize_brackets(std::string &str)
{
for (auto &c : str) {
if (c == '<')
c = '[';
else if (c == '>')
c = ']';
}
}
2022-01-26 03:23:38 -06:00
fstHandle FstData::getHandle(std::string name) {
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
normalize_brackets(name);
2022-01-26 03:23:38 -06:00
if (name_to_handle.find(name) != name_to_handle.end())
return name_to_handle[name];
else
2022-01-28 07:20:16 -06:00
return 0;
2022-01-26 03:23:38 -06:00
};
dict<int,fstHandle> FstData::getMemoryHandles(std::string name) {
if (memory_to_handle.find(name) != memory_to_handle.end())
return memory_to_handle[name];
else
return dict<int,fstHandle>();
};
2022-01-26 03:23:38 -06:00
static std::string remove_spaces(std::string str)
{
str.erase(std::remove(str.begin(), str.end(), ' '), str.end());
return str;
}
void FstData::extractVarNames()
{
struct fstHier *h;
2022-03-30 08:55:15 -05:00
std::string fst_scope_name;
2022-01-26 03:23:38 -06:00
while ((h = fstReaderIterateHier(ctx))) {
switch (h->htyp) {
case FST_HT_SCOPE: {
2022-03-30 08:55:15 -05:00
fst_scope_name = fstReaderPushScope(ctx, h->u.scope.name, NULL);
2022-01-26 03:23:38 -06:00
break;
}
case FST_HT_UPSCOPE: {
2022-03-30 08:55:15 -05:00
fst_scope_name = fstReaderPopScope(ctx);
2022-01-26 03:23:38 -06:00
break;
}
case FST_HT_VAR: {
FstVar var;
var.id = h->u.var.handle;
var.is_alias = h->u.var.is_alias;
var.is_reg = (fstVarType)h->u.var.typ == FST_VT_VCD_REG;
2022-01-26 03:23:38 -06:00
var.name = remove_spaces(h->u.var.name);
2022-03-30 08:55:15 -05:00
var.scope = fst_scope_name;
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
normalize_brackets(var.scope);
2022-01-26 03:23:38 -06:00
var.width = h->u.var.length;
vars.push_back(var);
if (!var.is_alias)
handle_to_var[h->u.var.handle] = var;
std::string clean_name;
bool has_space = false;
2022-01-26 03:23:38 -06:00
for(size_t i=0;i<strlen(h->u.var.name);i++)
{
char c = h->u.var.name[i];
if(c==' ') { has_space = true; break; }
2022-01-26 03:23:38 -06:00
clean_name += c;
}
2022-01-28 07:10:39 -06:00
if (clean_name[0]=='\\')
clean_name = clean_name.substr(1);
if (!has_space) {
size_t pos = clean_name.find_last_of("[");
std::string index_or_range = clean_name.substr(pos+1);
if (index_or_range.find(":") != std::string::npos) {
clean_name = clean_name.substr(0,pos);
}
}
size_t pos = clean_name.find_last_of("<");
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
if (pos != std::string::npos && clean_name.back() == '>') {
std::string mem_cell = clean_name.substr(0, pos);
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
normalize_brackets(mem_cell);
std::string addr = clean_name.substr(pos+1);
addr.pop_back(); // remove closing bracket
char *endptr;
int mem_addr = strtol(addr.c_str(), &endptr, 16);
if (*endptr) {
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
log_debug("Error parsing memory address in : %s\n", clean_name.c_str());
} else {
memory_to_handle[var.scope+"."+mem_cell][mem_addr] = var.id;
}
}
pos = clean_name.find_last_of("[");
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
if (pos != std::string::npos && clean_name.back() == ']') {
std::string mem_cell = clean_name.substr(0, pos);
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
normalize_brackets(mem_cell);
std::string addr = clean_name.substr(pos+1);
addr.pop_back(); // remove closing bracket
char *endptr;
int mem_addr = strtol(addr.c_str(), &endptr, 10);
if (*endptr) {
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
log_debug("Error parsing memory address in : %s\n", clean_name.c_str());
} else {
memory_to_handle[var.scope+"."+mem_cell][mem_addr] = var.id;
}
}
fstdata: Handle square/angle bracket replacemnt, change memory handling When writing VCDs smtbmc replaces square brackets with angle brackets to avoid the issues with VCD readers misinterpreting such signal names. For memory addresses it also uses angle brackets and hexadecimal addresses, while other tools will use square brackets and decimal addresses. Previously the code handled both forms of memory addresses, assuming that any signal that looks like a memory address is a memory address. This is not the case when the user uses regular signals whose names include square brackets _or_ when the verific frontend generates such names to represent various constructs. With this change all angular brackets are turned into square brackets when reading the trace _and_ when performing a signal lookup. This means no matter which kind of brackets are used in the design or in the VCD signals will be matched. This will not handle multiple signals that are the same apart from replacing square/angle brackets, but this will cause issues during the VCD writing of smtbmc already. It still uses the distinction between square and angle brackets for memories to decide whether the address is hex or decimal, but even if something looks like a memory and is added to the `memory_to_handle` data, the plain signal added to `name_to_handle` is used as-is, without rewriting the address. This last change is needed to successfully match verific generated signal names that look like memory addresses while keeping memories working at the same time. It may cause regressions when VCD generation was done with a design that had memories but simulation is done with a design where the memories were mapped to registers. This seems like an unusual setup, but could be worked around with some further changes should this be required.
2022-11-07 04:55:22 -06:00
normalize_brackets(clean_name);
2022-01-26 03:23:38 -06:00
name_to_handle[var.scope+"."+clean_name] = h->u.var.handle;
break;
}
}
}
}
static void reconstruct_clb_varlen_attimes(void *user_data, uint64_t pnt_time, fstHandle pnt_facidx, const unsigned char *pnt_value, uint32_t plen)
{
FstData *ptr = (FstData*)user_data;
ptr->reconstruct_callback_attimes(pnt_time, pnt_facidx, pnt_value, plen);
}
static void reconstruct_clb_attimes(void *user_data, uint64_t pnt_time, fstHandle pnt_facidx, const unsigned char *pnt_value)
{
FstData *ptr = (FstData*)user_data;
uint32_t plen = (pnt_value) ? strlen((const char *)pnt_value) : 0;
ptr->reconstruct_callback_attimes(pnt_time, pnt_facidx, pnt_value, plen);
}
void FstData::reconstruct_callback_attimes(uint64_t pnt_time, fstHandle pnt_facidx, const unsigned char *pnt_value, uint32_t /* plen */)
{
if (pnt_time > end_time || !pnt_value) return;
2022-01-26 03:23:38 -06:00
// if we are past the timestamp
bool is_clock = false;
if (!all_samples) {
for(auto &s : clk_signals) {
if (s==pnt_facidx) {
is_clock=true;
break;
}
2022-01-26 03:23:38 -06:00
}
}
if (pnt_time > past_time) {
past_data = last_data;
past_time = pnt_time;
}
2022-01-26 03:23:38 -06:00
if (pnt_time > last_time) {
if (all_samples) {
callback(last_time);
last_time = pnt_time;
} else {
if (is_clock) {
std::string val = std::string((const char *)pnt_value);
std::string prev = past_data[pnt_facidx];
if ((prev!="1" && val=="1") || (prev!="0" && val=="0")) {
callback(last_time);
last_time = pnt_time;
}
}
2022-01-26 03:23:38 -06:00
}
}
// always update last_data
last_data[pnt_facidx] = std::string((const char *)pnt_value);
2022-01-26 03:23:38 -06:00
}
void FstData::reconstructAllAtTimes(std::vector<fstHandle> &signal, uint64_t start, uint64_t end, CallbackFunction cb)
2022-01-26 03:23:38 -06:00
{
clk_signals = signal;
callback = cb;
start_time = start;
end_time = end;
2022-01-28 05:50:41 -06:00
last_data.clear();
last_time = start_time;
past_data.clear();
past_time = start_time;
all_samples = clk_signals.empty();
2022-01-28 05:50:41 -06:00
fstReaderSetUnlimitedTimeRange(ctx);
2022-01-26 03:23:38 -06:00
fstReaderSetFacProcessMaskAll(ctx);
fstReaderIterBlocks2(ctx, reconstruct_clb_attimes, reconstruct_clb_varlen_attimes, this, nullptr);
2022-04-22 08:24:02 -05:00
if (last_time!=end_time) {
past_data = last_data;
callback(last_time);
}
past_data = last_data;
2022-04-22 08:24:02 -05:00
callback(end_time);
2022-01-26 03:23:38 -06:00
}
std::string FstData::valueOf(fstHandle signal)
2022-01-26 03:23:38 -06:00
{
if (past_data.find(signal) == past_data.end()) {
return std::string(handle_to_var[signal].width, 'x');
}
return past_data[signal];
2022-01-26 03:23:38 -06:00
}