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)

Patrick Lehmann
@Paebbels

what are the timelines for these things ?

want to support ;) ?

I'm currently working on EDA². This task was startet in oct. 2021. Currently I'm delayed according to my own timeplan in refactoring a 60k line Python project.
Brian Padalino
@bpadalino

just got this email from the folks at https://rapidsilicon.com/:

Raptro does support this, maybe not entirely, but we have been working on it for a few years now.
One of the most popular features in VHDL 2019 is the conditional compilation (Like `ifdef in Verilog) which finally came to VHDL after 30 years...
But again, only one way to find out, one needs to throw at it the particular testcase...

I am guessing it's a typo in their product name of Raptor: https://rapidsilicon.com/raptor/
Brian Padalino
@bpadalino
also just updated that format library i've been writing .. https://github.com/bpadalino/vhdl-format - i think it's a lot closer to where i want it to be .. still deficient in the binary/octal/hex stuff .. and i need to write the functions for std_logic[_vector], [su]fixed .. probably some other standard ones i am missing, too
Brian Padalino
@bpadalino
rapid silicon folks said they will announce raptor alpha in fall timeframe and will include vhdl support in that announcement
DrPi
@drpi:matrix.org
[m]
I always wondered why tcl/tk is the scripting language used in FPGA world. Is it only historical ? Or are there good reasons for using it ?
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.