Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 03 02:13

    umarcor on keep-compiling

    ci: use the built-in '--keep-co… (compare)

  • Feb 03 02:12

    umarcor on cosim

    cosim/dpi-ffi: add 'vhdpi_ghdl.… cosim/dpi-ffi: add VHDPI_Test (compare)

  • Feb 03 01:56

    umarcor on cosim

    WIP setenv (compare)

  • Feb 03 01:55

    umarcor on main

    cosim/dpi-ffi/ghdl-vffi/test: a… (compare)

  • Feb 03 01:54

    umarcor on cosim

    (compare)

  • Feb 03 01:52

    umarcor on main

    WIP envvars (compare)

  • Feb 03 01:50

    umarcor on cosim

    WIP envvars (compare)

  • Feb 02 23:13

    umarcor on master

    (compare)

  • Feb 02 23:13

    umarcor on main

    (compare)

  • Feb 02 23:13

    umarcor on cosim

    (compare)

  • Feb 02 23:10

    umarcor on master

    cosim/dpi-ffi: create subdir 'g… cosim/dpi-ffi: fix compilation … cosim/dpi-ffi/ghd-vffi: use VUn… and 2 more (compare)

  • Feb 02 22:58

    umarcor on cosim

    ci: add workflow CoSim cosim/dpi-ffi: add README (compare)

  • Feb 02 22:45

    umarcor on cosim

    ci: add workflow CoSim cosim/dpi-ffi: add README (compare)

  • Feb 02 22:43

    umarcor on cosim

    cosim/dpi-ffi: create subdir 'g… cosim/dpi-ffi: fix compilation … cosim/dpi-ffi/ghd-vffi: use VUn… and 2 more (compare)

  • Oct 05 2021 13:29

    umarcor on top-subtype

    (compare)

  • Oct 05 2021 13:28

    umarcor on master

    2008: ad tb_top_generic_subtype cosim: add ref to aguinet/drago… (compare)

  • Sep 24 2021 20:07

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 2021 19:59

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 2021 19:54

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 23 2021 01:45

    umarcor on style

    (compare)

Jim Lewis
@JimLewis

@DrPi How old are simulators? This is well before Python. Well before Perl. What are you stumbling over WRT tcl/tk?

The awkward part of scripting a simulator in general is:
1) A simulator wants to be in a particular directory and not move. If you move, you loose things like your library configuration.
2) Scripts for IP are best located with the IP, and hence, will not be in the same directory as the simulator runs from.
3) The simulator API is really awkward WRT VHDL libraries. Why do we create a library and then have to specify that same library on compile and simulate commands that follow?

1 reply
Richard Head
@trickyhead_gitlab
@bpadalino just VHDL support? or a recent revision support? Would be amazing to have some 2019 synthesis support
@drpi GHDL doesnt have a built in TCL interpreter.
Richard Head
@trickyhead_gitlab
@JimLewis Wikipedia has TCL and Perl both appearing in 1988, and Python in 1991. So I guess people just chose TCL and its stuck because people like to use old scripts etc?
m-kru
@m-kru
TCL is not that bad, it has its drawbacks, but when you understand what is its purpose you may even understand that this is quite well designed language. People often complain about it as they want to use it as a general programming language, but it is not. It is a TOOL Command Language, it should be used to implement interface for interacting with the tool, not the tool logic.
svenn71
@svenn71
Tcl is stable, Python has never been and will never be.
Farmadupe
@Farmadupe
just my two cents: TCL is inadequately documented by modern standards (the wiki is often just a collection of ramblings and half-baked ideas), different tools come with old or vendor-patched versions of TCL, meaning that portability isn't as easy as it seems, debugging can be very difficult because metaprogramming is a very common technique, performance can be very unpredictable as computational complexity is different to many other languages (especially when eval gets involved), the syntax is idiosyncratic and despite the language being very simple, it's easy to lose hours of development time to simple quoting issues
2 replies
But even after all those problems, it is an incredibly powerful and simple language... It's designed to turn arbitrary jumbles of commandline tools and make a greater whole out of them... which is actually a fairly useful quality
Farmadupe
@Farmadupe
...if you're having a lucky day, sometimes you can make peace with the braces and the backslashes and get difficult stuff done really quickly and neatly with TCL
Farmadupe
@Farmadupe
sometimes I wonder how the world might be different if the world settled on say python.. On the one hand with TCL it's super easy to 'just' compose scripts that boss multiple different tools around, without having to write a separate script for each tool.. On the other hand, I think people would have been less scared to automate things if python was the language... I see far too many projects where tedious GUI clicking/configuration is a core part of the build process.. and maybe this wouldn't be the case if TCL was a bit easier to use
2 replies
Jim Lewis
@JimLewis

I have learned most of the TCL I use from Google. Primarily https://www.tcl.tk/ and https://wiki.tcl-lang.org/welcome.

That said, OSVVM has a simulation abstraction layer that runs on top of TCL that removes most of the need to use TCL. See: https://osvvm.github.io/Overview/Osvvm6ScriptLibrary.html.

Of course, internally OSVVM uses tcl
Nicolas Pinault
@NicoPy
Are underscores legal in a string literal without prefix ?
I mean, b"1000_0100" is legal but is "1000_0100" also legal ?
Farmadupe
@Farmadupe
hmm, if I'm reading the 2008 specification right, the answer is no. The distinction actually seems to be in the grammar. When there is no prefix the grammar says you have a "string_literal". When there is a prefix the grammar says "bit_string_literal". The language specification states that underlines are always removed from "bit_string_literal", but not "string literal".
I'd guess that the rule is in place because the compiler hasn't used type inference to work out whether your string literal was meant to be an 'actual string' or a 'bit string' To enable underscore removal without a prefix would mean that the language spec would effectively be declaring that the strings "hello_world" and "helloworld" were identical
Farmadupe
@Farmadupe
relevant sections of the 2008 specification are the "literal", "string_literal" and "bit_string_literal" productions in the grammar, "9.3.2 Literals" (Specifically the text "The type of a string or bit string literal shall be determinable solely from the context in which the literal appears") and "15.8 Bit string literals"
Farmadupe
@Farmadupe
hmm, I'm assuming that the text that I quoted is speclish for "sorry but you can't determine the type of a string literal at parse time without building a symbol table"
Farmadupe
@Farmadupe
(...in which case, the distinction between string_literal and bit_string_literal is probably moot anyway. Since the spec acknowledges that you probably need a symbol table in the parser, it could have instead required that the type first be determined, and then underline deletion could be done depending on type)
...I guess alternatively the spec could have not awkwardly borrowed the syntax for string literals for use with bit string literals
Nicolas Pinault
@NicoPy
All this makes sense.
The funny thing is that you can write signal Test : std_logic_vector (8-1 downto 0) := "00000000"; Here the string literal is automatically converted to bit_string literal.
But you can't write signal Test : std_logic_vector (8-1 downto 0) := "0000_0000";
Richard Head
@trickyhead_gitlab
not only is it converted to a "bit_string_literal" but actually interpreted as binary. so b"0000_0000" would be fine
Nicolas Pinault
@NicoPy
For me, there is some sort of inconsistency here.
Brian Padalino
@bpadalino
what's the inconsistency ?
Nicolas Pinault
@NicoPy
"00000000"which is a string is automatically converted to bit_string litteral. While "0000_0000" is not automatically converted.
Farmadupe
@Farmadupe
ah, I think it's implicit in the spec that if a literal is a bit_string_literal, it can never be type inferred to be a 'actual string'
an also, because the spec is using the langauge of teh grammar when describing unerline deletion, it's also inferred that type resolution will not have been done at the point of underline deletion
oh, so to reply to your last comment, "00000000" is never converted to bit string literal, as the spec says this conversion doesn't exist. It is type inferred to be a "bitty" type, no a "stringy" type
Nicolas Pinault
@NicoPy
Yes, this is a subtle difference (convertion / type inference) which has its consequences.
Jari Honkanen
@johonkanen
Why assignment operators := and <= are not overloadable? Could they be made overloadable?
2 replies
Farmadupe
@Farmadupe
as a guess 1) Either to avoid having to reword any sections of the Ada spec when drafting VHDL'87, or 2) to avoid the code author having to remember whether an identifier is a sig/var when reading code for the first time
1) is just a wild guess on my part though, 2) feels more plausible to me
Brian Padalino
@bpadalino
@johonkanen what's your use case for wanting to overload them ?
Farmadupe
@Farmadupe
(possibly flipflopping over whether to use a signal or a shared-variable?)
Brian Padalino
@bpadalino
you think he means to allow := to operate like <= and vice versa ?
i read it to mean he wants to be able to overload what := means for different types
so instead of assignment requiring the same type on both sides, one could overload := to take in integer and return a std_logic_vector
Jim Lewis
@JimLewis
@johonkanen they are not operators.
Farmadupe
@Farmadupe
ohh inteeresting, I guess that is what they'd said asked for, my head jumped to interchangeability
Jim Lewis
@JimLewis
If they were operators then what they currently do is allow like type to be assigned to like type.
If they were overloadable one could create conversions in the assignment operation.
Brian Padalino
@bpadalino
right .. but if you already have to write the conversion subprogram, being able to name it <= or := is just syntactic sugar, and possibly confusing
Jari Honkanen
@johonkanen
Mostly that would be useful syntactic sugar for assigning real valued constants directly to floating point objects instead of writing to_float(3.517) or equivalent for each. This is so common automatic conversion that practically every language does it.
Farmadupe
@Farmadupe
hmm how do other languages eachieve this without creating circular references? imagine.. function ":="(lhs : some_type; rhs : some_type) return some_type is begin lhs := rhs; end; <- creates an infinite recursive loop
Jari Honkanen
@johonkanen
Also, if we want to overload other operators like "+", "-" etc, then being able to overload the assigment operator would make the conversion call automatically, which is slighly more convenient than writing integer_signal <= to_integer(signed_a + signed_b). Though the effort here is so small that it is debatable whether clarity would be more valuable than very slight convenience.
Brian Padalino
@bpadalino
@Farmadupe what are you returning in that function? a call to itself? i don't think assignment operators are given both left and right sides .. just one and you return the other
it seems like @johonkanen is looking more for like an implicit conversion .. so he doesn't have to keep writing to_float
but i think that implicit conversion goes against the strong typing of vhdl/ada
sckoarn
@sckoarn
@JimLewis Please confirm you go my direct message ... we would like to contribute back our standards test cases.
2 replies
sckoarn
@sckoarn
@Paebbels looks like you are the one to contact regarding standards test suite ? Drop me a note or invite so we can start having a look at the process.