Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 24 01:29

    MikePopoloski on master

    Update docs (compare)

  • Oct 24 00:28

    MikePopoloski on master

    Clean up a few TODOs Tests and fixes for bitstream c… (compare)

  • Oct 18 19:51

    MikePopoloski on master

    Add interface class forward typ… Disallow scoped access to incom… Class handles should be boolean… and 1 more (compare)

  • Oct 18 02:14

    MikePopoloski on master

    Add checks for implementing int… (compare)

  • Oct 17 14:10

    MikePopoloski on master

    Add initial support for interfa… Fix lookup of type parameters i… Handle extended interface class… (compare)

  • Oct 07 04:59
    sgherbst commented #329
  • Oct 07 04:59
    sgherbst commented #329
  • Oct 06 23:19
    MikePopoloski closed #329
  • Oct 06 23:19
    MikePopoloski closed #329
  • Oct 06 23:19
    MikePopoloski commented #329
  • Oct 06 23:19
    MikePopoloski commented #329
  • Oct 06 22:50

    MikePopoloski on master

    Fix preprocessor bug related to… parser: add various rules speci… (compare)

  • Oct 06 12:30
    MikePopoloski commented #329
  • Oct 06 12:30
    MikePopoloski commented #329
  • Oct 06 00:47
    sgherbst opened #329
  • Oct 06 00:47
    sgherbst opened #329
  • Oct 04 20:45
    MikePopoloski closed #187
  • Oct 04 20:45
    MikePopoloski closed #187
  • Oct 04 20:45
    MikePopoloski closed #229
  • Oct 04 20:45
    MikePopoloski closed #229
Michael Popoloski
@MikePopoloski
it's essentially one source file
a lot of Verilog tools allow you to jam all of your source files together into one compilation unit
some do it by default
if you treat them as separate though you can do most of the analysis in parallel which can speed up compilation a lot
I'm heading out now but can talk more tomorrow
Martin d'Anjou
@martinda
thank you very much!
Michael Popoloski
@MikePopoloski
no problem
Martin d'Anjou
@martinda
I may leave a question or a few more comments here, no rush and no pressure.
Michael Popoloski
@MikePopoloski
Sure, feel free
Martin d'Anjou
@martinda
I find it hard to get the all the dependencies setup properly, so I am working on a Dockerfile on this branch. It does not work yet, something with C++ is not being recognized or installed properly. If you want to try it, clone my repository and follow the instructions in the docker.md file.
Martin d'Anjou
@martinda
Ah, I just found the docker instructions in the .travis.yaml file... awesome!
Martin d'Anjou
@martinda
@MikePopoloski do you have a Dockerfile with the build environment for development that you can share, without a static copy of the source in it?
jpeezzy
@jpeezzy
Hi, is this project still active?
Alex Wilson
@alwilson
@MikePopoloski This is pretty awesome. :D I played with the driver to get the ast/json from some sample SV. I'll have to see if I can help. I'm no C++ expert though. Man, I really should've taken that grammars class in college... Does the ast not descend into the always blocks yet? I notice dthe ast/json listed the always procedure, but no further.
Jose Renau
@renau

Very neat package, and quite fast compared with other parsers around.
I coordinate another project (https://github.com/masc-ucsc/lgraph) that aims at becoming a LLVM-like infrastructure for hardware. One of the main missing pieces is the verilog parser. We are interested only in the synthesizable subset.

Do you have examples of iterating the AST? (like a post-order traversal iterator) or should we build our own?

I am considering to use slang as an input to LGraph Largunage Neutral AST (LNAST).

Martin d'Anjou
@martinda
@renau have a look at https://gitter.im/hdlConvertor/community, their goal is a language neutral AST as well.
Jose Renau
@renau
@martinda , yes the hdlconvertor is pretty similar to the LNAST component. We are looking at it, since we are focusing at incremental and LGraph integration, we may have LNAST. In our project, the LNAST is the high level IR, and the LGraph is the lower level IR.
arikyueh
@arikyueh
Hi @MikePopoloski I am trying to parse the syntax tree with the SyntaxVisitor class. I have question on how to set up it up properly specifically obtaining the BindContext for the class which requires a scope and location data type.
Michael Popoloski
@MikePopoloski
@arikyueh sorry I didn't see your message earlier, for some reason Gitter refuses to notify me for new messages
not sure what you mean about SyntaxVisitor requiring a BindContext; the latter should only be needed when analyzing the AST, not the concrete syntax / parse tree
Jose Renau
@renau
I also was having problems to have a simple example that traverses every node of the AST. If there were a tool wanting to translate from systemverilog to verilog, I would need to do such traversal.
Any hint?
Michael Popoloski
@MikePopoloski
@renau do mean translate in source code order?
If you want to translate source code to source code, you probably want to keep it as similar to the original as possible, so I suspect you want to traverse the syntax tree with SyntaxVisitor (or use the derived SyntaxRewriter helper)
once the tree becomes "abstract" it no longer has a defined ordering
the SemanticModel class is designed as a helper if you're working with a syntax tree and want to ask semantic questions about some of the nodes with having to realize and analyze the entire AST to do it
but that class is certainly pretty bare bones right now if someone wanted to help expand it
if you don't care so much about preserving order, whitespace, comments, etc you can just build a Compilation, get the root of the ast, and traverse each symbol and print it back out
Jose Renau
@renau
Traversing the AST from compile looks like the best approach. I did not see any example doing that. Any hint for files to look at?
Michael Popoloski
@MikePopoloski
ASTVisitor implements this
the DiagnosticVisitor class in Compilation.cpp is an internal example of touching every node in the AST
(to make sure all diagnostics have been issued, since AST realization is lazy)
Jose Renau
@renau
Thanks, I'll try it. (slang is very fast compared with other parsers around. Nice job)
Michael Popoloski
@MikePopoloski
thanks! it was definitely a focus
Jose Renau
@renau
One thing that would make easier to use the slang directly is to have an argument closer to what verilator/vcs tends to support. E.g:
  • It would be great if slang binary supports a -f file argument
  • Support the annoying but typical +incdir+ +define+ args.
    For example, blackparrot uses something like:
    +incdir+$BASEJUMP_STL_DIR/bsg_dataflow
    +incdir+$BASEJUMP_STL_DIR/bsg_mem
    +incdir+$BASEJUMP_STL_DIR/bsg_misc
    +incdir+$BASEJUMP_STL_DIR/bsg_test
    +incdir+$BASEJUMP_STL_DIR/bsg_noc
    # common includes
    +incdir+$BP_COMMON_DIR/src/include
    # fe includes
    +incdir+$BP_FE_DIR/src/include
    # be includes
    +incdir+$BP_BE_DIR/src/include
    +incdir+$BP_BE_DIR/src/include/bp_be_dcache
    # me includes
    +incdir+$BP_ME_DIR/src/include/v
    # top includes
    +incdir+$BP_TOP_DIR/src/include
    ## Packages
    # bsg_ip_cores packages
    $BASEJUMP_STL_DIR/bsg_cache/bsg_cache_pkg.v
    $BASEJUMP_STL_DIR/bsg_noc/bsg_noc_pkg.v
    $BASEJUMP_STL_DIR/bsg_noc/bsg_wormhole_router_pkg.v
    # Interface packages
    $BP_COMMON_DIR/src/include/bp_common_rv64_pkg.vh
Michael Popoloski
@MikePopoloski
I much prefer the clang / gcc style of argument passing, but I could imagine having some kind of compatibility layer that would translate arguments
Jose Renau
@renau

Mostly to ease porting of tools, but I agree that I do not like it so much. I was trying the black-parrot and I saw that most of the errors are due to this example:
file1.v

package file1;

`define MACRO(x) (x)

endpackage

file2.v

import file1::*;
module top();

  initial begin
    $display("hello %d\n", `MACRO(3));
  end

endmodule

It compiles fine with vcs and verilator

 vcs -sverilog  -full64 file1.v file2.v

but it generates this error with slang:

 ~/projs/synth/slang/build/bin/slang  file1.v file2.v
Top level design units:
    top

file2.v:7:28: error: unknown macro or compiler directive '`MACRO'
    $display("hello %d\n", `MACRO(3));
                           ^
file2.v:7:37: error: empty argument not allowed -- expecting value for '%d' format specifier
    $display("hello %d\n", `MACRO(3));
                    ~~              ^

Build failed: 2 errors, 0 warnings
Michael Popoloski
@MikePopoloski
Macros are definitely not members of packages, they are compiler directives
They are scoped to the current file in the individual file model that slang uses by default. It can work if you instead tell slang to combine all files into one compilation unit, which I guess is what vcs is doing.
That makes your build dependent on the order of files you pass to the tool, so it's not great, but lots of verilog projects seem to rely on that.
Michael Popoloski
@MikePopoloski
You can use --single-unit with slang to make that work
Jose Renau
@renau

Perfect, the single-unit flag solves that problem.
Have you tried to compile the black-parrot? https://github.com/black-parrot/black-parrot
I get several errors like:

external/basejump_stl/bsg_cache/bsg_cache.v:104:22: error: cannot select range of [4:4] from 'logic[0:0]'
    = cache_pkt.addr[lg_data_mask_width_lp+lg_block_size_in_words_lp+lg_sets_lp+:lg_ways_lp];
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I can try to debug, but I saw that https://symbiflow.github.io/sv-tests/ fails for it, but looking at the syntax used in black-parrot, it should be fine (it runs verilator, vcs, dc..., but not yosys due to some SV constructs)

Michael Popoloski
@MikePopoloski
no, I haven't tried, but I can take a look later
Michael Popoloski
@MikePopoloski
I did end up looking at this; I believe the errors are from including modules in the build that are never actually instantiated; they have invalid parameter defaults that cause various errors
black-parrot has complicated build instructions so it's likely that they filter out and set parameters correctly if you go through the flow correctly
Jose Renau
@renau
Yes, i think that it is the case. There are several modules but if they are not instantiated in the hierarchy, they should not trigger compile errors for incorrect default parameters. Is there a way to avoid errora for non instantiated modules with parameters?
Or maybe to only report errors going down the top level module?
Michael Popoloski
@MikePopoloski
slang should suppress errors that are caused by parameters in uninstantiated modules, but it looks like that's not happening for nested instantiations in those modules
I think most of the time you still want some error checking applied to those modules (otherwise why even include them in your build at all) but I could add an option to ignore them completely as well
Jose Renau
@renau
That would be great. I am trying to use FIRRTL generated verilog and blackparrot as some key benchmarks for my platform. Let me know if you need help (maybe testing)