nic30/hwt

VHDL/Verilog/SystemC code generator, simulator API written in python/c++

HWToolkit (hwt),

the library for hardware development in Python

Keywords

• Metaprogramming (Hardware Construction Language HCL, templatization) + HLS.
• Simulator API, UVM
• Buildtool, IP core generator

How HWT can help you?

• The lower layer (IR, HDL serializers) is a shield against a problems related to VHDL/Verilog. It is checking for correctness and synthetisability and removing specific of HDLs.
• The system level and HLS layer allows you to quickly build desing generators with advance optimisation techniques of your choice.
• Simulator API and it's UVM simulation environment is just python object with C++ binding. This makes it easy to use while not sacrificing performance.
• Rich type system can describe also data locality and packet features. This significantly simplifies configuration of component which are working with packets or any data over remote bus.
• HWT is not compiler nor transpiler but it is actually a core library. It contains only necessary stuff and you can can modify/extend any part any time. Because the word of HW developement is always full of unexpected situations.

Features

• Hardware Construction Language (HCL) (example simple, showcase). It is somewhere between HLS and HDL. It offers HLS style of coding but at the same time it allows you to manipulate HDL objects. This means it is a little bit slower to write a prototype than you would in HLS, but you always know what, how and why is happening.
• Digital circuit simulator with UVM like verification environment (example usage CAM, structWriter_test.py)
• Tools for static analysis (resourceAnalyzer, example usage cntr_test.py)
• Serializers to export HWT designs into multiple target HDLs (verilog, VHDL, system-c, IP-core packager, hwt itself...)

HWT uses hilevel-netlists for internal representation of target design. Optimized netlists are generated from usual code statements, function calls, statements etc (hw processes are automatically resolved). This netlist is easy to use and easy to modify or analyse by user if there is something missing in main library. Also serialization modes allows to tweaks how component should behave during serialization.

HWT performs no HLS planing or schedueling. HWT is also good as API for code generating by more advanced tools. Hierarchy of components/interfaces/types is not limited. User specifed names are checked for collision with target language.

HWT designs are objects. No specific compiler execution is required, just run python3, import the thing and use to_rtl metod or other (take a look at examples).

HWT ecosystem

Installation

This library is a regular python package. You can install it using:

# system-wide, use -u for local use only
sudo pip3 install hwt

# or directly from git
pip3 install --upgrade --force-reinstall --no-cache-dir -r https://raw.githubusercontent.com/Nic30/hwt/master/doc/requirements.txt git+https://github.com/Nic30/hwt.git@master#egg=hwt

Then you are able to use functions and classes defined in the hwt library from a python console or script. Installation of hwtLib is recomended as it contains common interfaces, agents, components etc...

FAQ

• Where is the entry point of the compiler?
  • This is not a compiler, it is library of the objects which can be converted to Verilog/VHDL and back.
• How do I get Verilog/VHDL?
  • Use to_rtl method example
• How do I define my interface type, protocol and simulation agent?
  • Derive from any Interface class. example
• I do have c structure of UDP header, how do I send/recieve UDP packet over AXI-stream interface?
  • Define HStruct type composed of eth_header_t, IPv4_header_t and HStream(uint8_t) and use AxisFrameGen. There is and example of ping responder

Similar projects

• autofpga - C++, A utility for Composing FPGA designs from Peripherals
• 💀 baremetal - Python, simple HCL
• BinPy - Python, An electronic simulation library
• 💀 pervognsen/Bitwise - Python, HDL which translates python directly
• 💀 jamesjiang52/Bitwise - Python, simple HCL.
• blarney - Haskell, HCL
• bsc - Haskell, C++, BSV - Bluespec Compiler
• Cement HDL/CmtHDL - Rust, eHDL
• chisel - 2012-?, Scala, HCL
• Chips-2.0 - , , FPGA Design Suite based on C to Verilog design flow
• circt - 2020-?, C++/LLVM, compiler infrastructure
• circuitgraph - Tools for working with circuits as graphs in python
• concat - 2016-?, Haskell, Haskell to hardware
• DUH - JS, simple convertor between verilog/scala/ipxact
• DFiant 2019-?, Scala, dataflow based HDL
• edalize - 2018-?, Python, abstraction layer for eda tools
• garnet -2018-?, Python, Coarse-Grained Reconfigurable Architecture generator based on magma
• hammer - 2017-?, Python, Highly Agile Masks Made Effortlessly from RTL
• heterocl - 2017-?, C++, A Multi-Paradigm Programming Infrastructure for Software-Defined Reconfigurable Computing
• hoodlum - 2016-?, Rust, HCL
• ILAng - modeling and verification platform for SoCs where Instruction-Level Abstraction (ILA) is used as the formal model for hardware components.
• 💀 jhdl - ?-2017, C++ Verilog/VHDL -> systemC, prototype
• Kactus2 - IP-core packager
• kratos - C++/Python, hardware generator/simulator
• lgraph - C, generic graph library
• llhd - Rust, HCL
• livehd - mainly C++, An infrastructure designed for Live Hardware Development.
• Lucid HDL in Alchitry-Labs - Custom language and IDE inspired by Verilog
• magma - 2017-?, Python, HCL
• amaranth/migen - 2013-?, Python, HCL
• mockturtle - logic network library
• moore - Rust, HDL -> model compiler
• msdsl - Python, real number model -> verilog
• MyHDL - 2004-?, Python, Process based HDL
• Amaranth HDL -, Python, (previously nMigen) A refreshed Python toolbox for building complex digital hardware
• OpenTimer - , C++, A High-Performance Timing Analysis Tool for VLSI Systems
• percy - Collection of different synthesizers and exact synthesis methods for use in applications such as circuit resynthesis and design exploration.
• PyChip-py-hcl - , Python, Chisel3 like HCL
• pygears - , Python, function style HDL generator
• PyMTL3 2018-?
• PyMTL - 2014-?, Python, Process based HDL
• PipelineC - 2018-?, Python, C++ HLS-like automatic pipelining as a language construct/compiler
• PyRTL - 2015-?, Python, HCL
• Pyverilog - 2013-? Python-based Hardware Design Processing Toolkit for Verilog HDL
• rogue , C++/Python - Hardware Abstraction & Data Acquisition System
• rohd, 2023-?, dart, HCL
• sail 2018-?, (OCaml, Standard ML, Isabelle) - architecture definition language
• spatial - Scala, an Argon DSL like, high level abstraction
• SpinalHDL - 2015-?, Scala, HCL
• Silice - ?, C++, Custom HDL
• 💀 SyDpy - ?-2016, Python, HCL and verif. framework operating on TML/RTL level
• systemrdl-compiler - Python,c++, register description language compiler
• UHDM - C++ SystemVerilog -> C++ model
• 💀 Verilog.jl - 2017-2017, Julia, simple Julia to Verilog transpiler
• veriloggen - 2015-?, Python, Verilog centric HCL with HLS like features
• 💀 wyre - 2020-2020, Mupad, Minimalistic HDL
• phi - 2019-?, custom language, llvm based compiler of custom hdl
• prga - 2019-?. Python, prototyping platform with integrated yosys
• Hardcaml - OCaml, HCL
• magia-hdl - 2023-?, Python, HCL
• Metron - C++, C++ -> SystemVerilog syntax translator

Dictionary

• IR - Internal Representation
• HDL - Hardware Design Languge (Lang. construct maps directly to specific HW part)
• eHDL - Embedded HDL (HDL construct avare source code generator)
• HCL - Hardware Construction Language (User code constructs IR. IR can be directly transipled to HDL)
• HLS - High Level Synthesis (User code is translated to IR. IR is compiled to HDL IR in multiple complex steps, typically contains scheduling, arch. mapping etc.)

Related open-source

• fusesoc - package manager and a set of build tools for FPGA/ASIC development
• OpenSTA - a gate level static timing verifier
• RePlAce - global placement tool
• verilator - Verilog -> C/C++ simulator
• vtr-verilog-to-routing
• yosys - RTL synthesis framework
• UHDM - SV -> C++

Board support libraries (Potential candidates for public integration)

• litex - Buildsystem for migen
• loam - Buildsystem for magma
• vivado-boards - Vivado XML/TCL files with board description
• nmigen-boards - board and connector meta fo nmigen

Sources of informations in this area

• computer-engineering-resources - list of conferences and hardware projects

hwt's Issues

replace internal representation of hardware with netlistDB

https://github.com/HardwareIR/netlistDB

Native Async reset support in RtlNetlist?

Dear @Nic30:

Do you consider adding native asynchronous reset support with hwtLib compatibility like this in RtlNetlist to make it more ASIC-friendly(IMHO)? Thanks.

Extraction of netlist graph database and HDL parser/serializer modules

The circuit database has to be somehow implemented in every project related to HDL/FPGA etc.
This leads to ridiculous amount of work for developers of such a libraries and also makes this libraries incompatible because their internal representation of circuit is different and exporting/importing of Verilog/VHDL/FIRRTL is not an effective solution.

In fact this implies that very few of just HW optimization libraries exists.

Plan is to search for use cases https://github.com/HardwareIR/hardwareIr/wiki, f4pga/ideas#19 and who would like to use such a library.

Expected library contains:

• implementation: C++, Python/Java wrapper
• graph database for netlist with AST/IR view available
• HWT like serializers for Verilog-2005, VHDL 2002, 2008, SystemC, FIRRTL
• SystemVerilog, VHDL parserers from hdlConvertor (without python dependency) + FIRRTL parser

Similar functionality is implemented in many projects including de facto all HDL/FPGA related project.

I would gladly just extract the implementation from yosys but it is far more complicated than this and there is very strong will of many other projects to use their current solutions and simply do not make the projects compatible because the authors do not see the profit and it is quite lot of work.

For me it is hard to explain them that they should not lose years on developing of own custom half working HDL parser/generator which will die together with their project because 4K men-hours is likely the time required to develop proposed library and even if it may seems as an easy task in the beginning. Also own custom solution means incompatibility.

Also it is extremely important to finis this library in reasonable time, that means in Q2 2019, I mean I need more committers and testers.

Complete tests for assignments to a cast or slice of registers

Extract interface arrays

Extract interface arrays as separate library, because it is complicated and users does not understand the difference between

• an array of interfaces (= python list of Interface objects)
• an array interface (Interface object with multiplied width and overloaded indexing to allow index parts of this array).

It is useful feature but it is too complicated for base hwt library. Learning curve of uses and intuitive usage has priority.

This also means the removal of SimProxies for this interfaces. And magic indexation overriding, array items cache and it's usage for interfaces.

~ 2018-06-30

Proper tutorial - simulations/verifications

add_param_asserts breaks examples

Hi, I am playing with the examples from the wiki. The second one (SimpleUnitWithParam) introduces parameters. However it seems that since a commit in 2021 this is somehow broken or the API has changed in a way that the example isnt working.

Instead of generating generic code where the verilog parameter / VHDL generic is used, hwt will just use the constant and emit an assertion if the parameter was indeed set to that constant. That is not very useful.

regards
Philip

C/C++ library for IO access to HW in sim. (for driver development)

This library already exists, but it is not public.
This library maybe should be Linux package instead, but installation by setuptools may be an option.
Current implementation is is universal API which can be used with real hardware or on remote hardware or simulator on demand.
Currently it is user space library but currently it is not a problem.

But current connection to simulator is more or less and adhoc.

~ 2018-06-30

Multiple component variants for specified parameter combinations under wrapper

In order to use component from HDL it is usually required to pre-generate at least several component variants and select from them based on used parameter configuration in HDL.

Prevent from dupliacation of generic/params if it shares same value

Currently all parameter on all sub-interfaces are present in target HDL. Problem is that it is too much lines of text which is usually completely useless.

Proposed solutions:

• Remove generics/params entirely
• or make them visible only on demand
• or put generic/params with non unique values in to comments
• or remove all interface generics/params and keep only g./p. from components

params are not set on component instances

Axi_basic_slave_140321357064568 : COMPONENT Axi_basic_slave
    GENERIC MAP (
        C_S_AXI_ADDR_WIDTH => 4,
        C_S_AXI_DATA_WIDTH => 32
...

class AxiLiteSlaveContainer(Unit):
    ADDR_WIDTH = Param(8)
    DATA_WIDTH = Param(8)
    ...
    slv.C_S_AXI_ADDR_WIDTH.inherit(ADDR_WIDTH)
    slv.C_S_AXI_DATA_WIDTH.inherit(DATA_WIDTH)

Tests for replace_input_in_expr

Proper tutorial - components, interfaces

Proper tutorial - python project packaging and distribution, doc, visualization

• pip, distutils, requirements.txt,
• virtualenv, docker, execution without installation
• where it is after installation
• what to do if something is wrong

tests for operators with signed Bits

IP core importing

XCI contains parameters of ipcore.
component.xml contains definitions of bus interfaces.

Import xci as a Unit instance.

• component.xml with pregenerated values usually stored in .srcs/sources_1/bd/top_name/ip/<ip_name> together with xci

Incorrect initialization with Verilog serializer

For the following code:

import math
from hwt.synthesizer.param import Param
from hwt.synthesizer.unit import Unit
from hwt.hdl.types.bits import Bits
from hwt.interfaces.std import Signal
from hwt.hdl.types.array import HArray

class LUTSin(Unit):
   
    def _declr(self):
        self.idx  = Signal(Bits(4))
        self.data = Signal(Bits(8))._m()

    def _impl(self):
    
        lut = self._sig(name="lut", dtype=HArray(Bits(8,signed=True),16), 
                                    def_val=[int(math.sin(i*math.pi*2/16)*127+0.5) for i in range(16)])

        self.data(lut[self.idx])


if __name__ == "__main__":

    from hwt.synthesizer.utils import to_rtl_str
    from hwt.serializer.vhdl import Vhdl2008Serializer
    from hwt.serializer.verilog import VerilogSerializer

    print(to_rtl_str(LUTSin(), serializer_cls=Vhdl2008Serializer))
    print(to_rtl_str(LUTSin(), serializer_cls=VerilogSerializer))

Output of VHDL serializer (Correct initialization):

LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
ENTITY LUTSin IS
    PORT(
        data : OUT STD_LOGIC_VECTOR(7 DOWNTO 0);
        idx : IN STD_LOGIC_VECTOR(3 DOWNTO 0)
    );
END ENTITY;

ARCHITECTURE rtl OF LUTSin IS
    TYPE arr_t_0 IS ARRAY (15 DOWNTO 0) OF SIGNED(7 DOWNTO 0);
    CONSTANT lut : arr_t_0 := (
        SIGNED'(X"00"),
        SIGNED'(X"31"),
        SIGNED'(X"5A"),
        SIGNED'(X"75"),
        SIGNED'(X"7F"),
        SIGNED'(X"75"),
        SIGNED'(X"5A"),
        SIGNED'(X"31"),
        SIGNED'(X"00"),
        SIGNED'(X"-30"),
        SIGNED'(X"-59"),
        SIGNED'(X"-74"),
        SIGNED'(X"-7E"),
        SIGNED'(X"-74"),
        SIGNED'(X"-59"),
        SIGNED'(X"-30"));
BEGIN
    assig_process_data: PROCESS(idx)
        VARIABLE tmpCastExpr_0 : SIGNED(7 DOWNTO 0);
    BEGIN
        tmpCastExpr_0 := lut(TO_INTEGER(UNSIGNED(idx)));
        data <= STD_LOGIC_VECTOR(tmpCastExpr_0);
    END PROCESS;
END ARCHITECTURE;

Output of Verilog serializer (Incorrect initialization)

module LUTSin (
    output reg[7:0] data,
    input wire[3:0] idx
);
    reg signed[7:0] lut[0:15];
    always @(idx) begin: assig_process_data
        data = $signed(lut[idx]);
    end

    initial begin
        lut[0] = 0;
        lut[1] = 1;
        lut[2] = 2;
        lut[3] = 3;
        lut[4] = 4;
        lut[5] = 5;
        lut[6] = 6;
        lut[7] = 7;
        lut[8] = 8;
        lut[9] = 9;
        lut[10] = 10;
        lut[11] = 11;
        lut[12] = 12;
        lut[13] = 13;
        lut[14] = 14;
        lut[15] = 15;
    end

endmodule

Extract bit precise math

Value of param at top level is invalid

ENTITY AxiLiteSlaveContainer IS
    GENERIC (
        ADDR_WIDTH : INTEGER := <Param, val=8>;
        DATA_WIDTH : INTEGER := <Param, val=8>
...

Complete tests for RtlSignals generated from composed types like HStruct, HArray

Support for formal verification statements

Add formal verification statement in same manner as constraint specification.

• https://github.com/YosysHQ/SymbiYosys

Tests for StructIntf._eq/__ne__ operators

naming optimizations

• Prefix for HCL objects needs to be specific so it is more easy to automatically update code after library updates
  • visually separation of normal Python objects and HCL
  • simplifies search in code

• Names of signal, interface or component

  • Involves: BasicRtlSimProxy, RtlSignal, HwIO, HwModule
  • now it is not clear what the name actually means
    • .name -> ._name - logical name, name from user description
    • ._name -> ._hdlName - physical name, full name with resolved name collisions etc.

• Backward type reference of signals and constant

• type property name is too long
  ._dtype -> ._ht

• Split HConst and HVar classes (because of performance reasons)

def tv(signal):
    return signal._dtype.getConstCls()

class RtlSignalOps():
    def __invert__(self):
        return self.naryOp(AllOps.NOT, tv(self).__invert__)

# currently the const class contains code also for signal/variable operator
class BitsConst:
    def __invert__(self):
        if isinstance(self, HConst):
            return Bits3val.__invert__(self)
        else:
            ...

• Bits -> HBits (act as an int but it is not named int to avoid things like float inheriting from int)
• hwt.synthesizer.unit.Unit -> hwt.hModule.HwModule (Using module stem because it is more widely used)
  • ._interfaces -> ._hwIOs
  • ._subunits -> ._subHwModules
  • ._params -> ._hwParams
  • ._paramsShared() -> ._hwParamsShared()
• Interface -> HwIO
• Signal -> HwIOSignal (adding HwIO so user do not think that this is the signal instance which should be normally used for communication inside of module)
• Param -> HwParam
• HValue -> HConst (same convention as in LLVM)
• Operator -> HOperatorNode
• OpDefinition -> HOperatorNodeDef
• AllOps -> HwtOps
• UniqList -> SetList (same convention as in LLVM)
• SimTestCase.u -> SimTestCase.dut (replacing u after Unit -> HModule)
• EmptyUnit -> hwtLib.abstract.emptyHModule.EmptyHModule
• hwt.synthesizer.utils -> hwt.synth
• HsStructIntf -> HwIOStructVldRd
• StructIntf -> HwIOStruct
• VldSyncedStructIntf -> HwIOStructVld
• RdSyncedStruct -> HwIOStructRd
• HdlType_to_Interface -> HdlType_to_HwIO
• Interface_to_HdlType -> HwIO_to_HdlType
• DifferentialIntf -> HwIODifferentialSig
• RegCntrl -> HwIORegCntrl
• TristateSig -> HwIOTristateSig
• UnionSink -> HwIOUnionSink
• UnionSource -> HwIOUnionSource
• RdSynced -> HwIODataRd
• RdSync -> HwIORdSync
• VldSynced -> HwIODataVld
• VldSync -> HwIOVldSync
• Handshaked -> HwIODataVldRd
• HandshakeSync -> HwIOVldRdSync
• Clk -> HwIOClk
• Rst -> HwIORst
• Rst_n -> HwIORst_n
• ReqDoneSync -> HwIOReqDoneSync
• BramPort_withoutClk -> HwIOBramPort_noClk
• BramPort -> HwIOBramPort
• FifoWriter -> HwIOFifoWriter
• FifoReader -> HwIOFifoReader
• AxiStream -> Axi4Stream
• hwtLib.amba.axi_intf_common -> hwtLib.amba.axi_common
• walkPhysInterfaces -> HwIO_walkSignals
• walkFlatten -> HwIO_walkFlatten
• packHwIO -> HwIO_pack
• connectPacked -> HwIO_connectPacked
• IntfIpMetaNotSpecified -> IntfIpMetaNotSpecifiedError

flatten to parent:

• move constants from hwt.synthesizer.rtlLevel.constants, hwt.hdl.constants to hwt.constants
• hwt.synthesizer.interfaceLevel.interfaceUtils
• hwt.synthesizer.rtlLevel.signalUtils
  • walkers -> rtlSignalWalkers
  • ops -> rtlSignalOps
• hwt.synthesizer.hObjList -> hwt.hObjList

Proper tutorial - compilation phases and serialization customizations, vendor tools integration

multidimensional index in vhdl

It seems that index on multidimensional arrays is like this:

mem(1)(1)

not like this:

mem(1, 1)

as it should be.

rm relicts of interface direction discoverry logic

• better error msgs

  hwt/hwt/synthesizer/interfaceLevel/unitImplHelpers.py

  Line 163 in e121a6b

  raise IntfLvlConfErr(

Clean stack trace for exception in RtlSignal operators

If the exception is raised somewhere deep inside of operator function it usually means ~5 function calls and user can get lost easily. It also does not look like an error in user code.

Convert interfaces to HDL as well (VHDL records, SV interface)

1. Extract interface as a VHDL records, SV interfaces and not just a separate signals.
2. Nice methods for connecting rather than assignments.

Quartus ip core compatibility

assigment semantics unclear

Hi @Nic30,

I have the following piece of code (please ignreo the Flow stuff for now). HWT complains that valid has multiple drivers.

    def _declr(self):
        addClkRstn(self)
        
        self.a = Flow()._m()
        self.b = Flow()
    
    def _impl(self):
        data = self._reg(name="data", dtype=self.a.data._dtype)
        valid = self._reg(name="valid", dtype=Bits(1))

        valid(valid & ~self.a.fire())

        If(self.b.fire(),
        data(self.a.data),
        valid(True))
        
        self.a.data(data)
        self.a.valid(valid)

What I want to describe the the verilog equivalent of

valid_a <= 0;
if(valid_b) begin
valid_a <= 1;
end

So essentially I am wondering if I can have a "last assigment wins" policy. I know this example is not so meaningful and you can easily get around it be using else clauses. This is more a conceptional question.
Is there some other channel to ask questions?

Interface direction in definition of component

To simplify parallel build of HLS components it is required to know direction of all interfaces on boundaries of components.

Also platform definition which is passed to toRtl() function should contains predefined pool of worker processes for HLS engines.

Also interface direction resolution should be extracted to https://github.com/Nic30/hwtHdlParsers

Condition tree rework

Currently If-then-else and other condition containers are constructed in HDL rendering phase.
This means every Assignment instance has list of it's conditions and condition containers are resolved from them.
This makes thing complicated and slow.

This has to be removed and replaced with condition tree with hierarchy represented by real objects.
Every object has to have reference on it's parent and has to have specified where it is in the parent.

Every RtlSignal then will have only top condition container in it's drivers or endpoints.

Instantiate VHDL or Verilog IPs as black-boxes

Hi Nic30:

Is it possible to instantiate a VHDL or Verilog IP as a black-box component like Spinalhdl? Thanks.

Params are not working at hierarchical interfaces

ENTITY AxiLiteSlaveContainer IS
    GENERIC (
        ADDR_WIDTH : INTEGER := 8;
        DATA_WIDTH : INTEGER := 8
    );
    PORT (axi_ar_addr : IN STD_LOGIC_VECTOR(31 DOWNTO 0);
        axi_aw_addr : IN STD_LOGIC_VECTOR(31 DOWNTO 0);
        axi_r_data : OUT STD_LOGIC_VECTOR(63 DOWNTO 0);
...

the param from interface declaration is used instead

Help with design low-level HDL language

FPGA world suffers a lot from fragmentation - some tools produce Verilog, some VHDL, some - only subsets of them, creating low-level LLVM-like alternative will help everyone, so HDL implementations will opt only for generating this low-level HDL and routing/synthesizers accept it. LLVM or WebAssembly - you can see how many languages and targets are supported now by both. With more open source tools for FPGA this is more feasible now than ever.

See f4pga/ideas#19

Extract rtl simulator

Nic30/pycocotb#12

Extract the simulator

HDL/RTL simulator should not be part of this library. It will be extracted to separate library.
Temporal repository for this library is https://github.com/Nic30/pycocotb.
Also the C++ Verilator simulator will be available.

Properties of the Verilator:

• the fastest, multi-thread native simulation
• long spin-up time
• Additional check of Verilog code

I am also working on simple simulation API which will make the writing of UVM like interface agents easy.

The state is that I do have working prototype but I do not have to submit patches to Verilator.
I do expect that library will be finished after December or in February.

CLI utils for component/interface introspectivity

They actually exists https://github.com/Nic30/hwt/blob/master/hwt/simulator/utils.py#L8,
but there is no tutorial about it.

Issues with basic example

I am getting

No module named 'hdlConvertorAst.translate._verilog_to_basic_hdl_sim_model'

when doing python simple.py

I have installed both hwt and hwtlib packages, and I see how all dependances got installed properly. If I do a

pip freeze | grep hdlConvertorAst, I get hdlConvertorAst==0.8

Any idea on how to debug this further?

Thanks!

If then else block can't find its block automaticaly

rtlLvl/simpleRegister.py

IF ((rst = '1') AND (RISING_EDGE(clk))) THEN
     val <= STD_LOGIC_VECTOR(TO_UNSIGNED(0, val'LENGTH));
END IF; 
IF ((( NOT(rst)) = '1') AND (RISING_EDGE(clk))) THEN
     val <= val_next;
END IF;

instead of :

IF ((rst = '1') AND (RISING_EDGE(clk))) THEN
     val <= STD_LOGIC_VECTOR(TO_UNSIGNED(0, val'LENGTH));
ELSE
     val <= val_next;
END IF; 

Error with sensitivity lists in If statement

I'm getting the error

File "/home/ben/Code/hwt/hwt/hdl/ifContainter.py", line 193, in _discover_sensitivity                                                
    assert self._sensitivity is None, self
AssertionError: If(a._eq(0x1),
    intermed_next(0x1),
)
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /home/ben/Code/hwt/hwt/hdl/ifContainter.py(193)_discover_sensitivity()                                                               
-> assert self._sensitivity is None, self

when running the following code:

from hwt.synthesizer.unit import Unit
from hwt.hdl.types.enum import HEnum
from hwt.hdl.types.bits import Bits
from hwt.code import If
from hwt.interfaces.std import Signal, VectSignal
from hwt.serializer.verilog.serializer import VerilogSerializer

class Minimal(Unit):

    def _declr(self):
        self.clk = Signal()
        self.a = VectSignal(2)
        self.b = VectSignal(2)
        self.c = Signal()._m()

    def _impl(self):
        one = self._sig('one', Bits(1))
        intermed = self._reg('intermed', Bits(1))
        one(1)
        self.c(intermed)
        If(one._eq(1), (
                If(self.a._eq(1), (
                        intermed(1),
                        )),
                If(self.b._eq(1), (
                        intermed(0),
                        )),
                If(self.b._eq(2), (
                        intermed(1),
                        )),
            ))
''

def main():
    from hwt.synthesizer.utils import toRtl
    u = Minimal()
    contents = toRtl(u, serializer=VerilogSerializer)
    filename = 'minimal.v'
    with open(filename, 'w') as f:
        f.write(contents)

if __name__ == '__main__':
    main()

readable debug of Value instances

BitVal/HBoolVal/HIntVal ... instances does not require type definition and validity mask if it can be derived from python value

HArrayVal/HSliceVal ... instances does not require specification for all items if they are same and they do not require type defnition if it can be expressed in python