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)

Richard Head
@trickyhead_gitlab
global signals: synth tools will refuse to synth them, hence their lack of use. They only have use in simulation - and now with external names they are more redundant than they once were - plus mentor had signal spy (plus aldec equivolent) which gave you 2008 external name like access to signals within a design.
Back to re-usable frameworks - I think we're having a heyday in Verification - OSVVM, UVVM, VUNIT and CocoTB are all seeing much more use in industry than 5 years ago.
I think a few teams started using UVM and realised that while the return on investment was good with lower bug returns, maintaining a split VHDL/SV+UVM department is just too hard. I certainly went through redundancies where the verification team got the chop first because "RTL engineers can do verification right?" Well turns out their UVM skills are just non existant, so these teams want to keep the level of verification going but with a VHDL based framework (and python is getting popular hence VUnit and CocoTB)
Colin Marquardt
@cmarqu
@bpadalino "PoC" mentioned by @Paebbels in this context means https://github.com/VLSI-EDA/PoC
Brian Padalino
@bpadalino
@cmarqu thanks for the clarification
first time i've heard of it
@trickyhead_gitlab i swear i've been able to synthesize global signals in packages before .. maybe it was just a synplify pro thing ?
Brian Padalino
@bpadalino
some initial criticisms of PoC - they are naming a package PoC with capitalization in a case insensitive language .. some of the words being used in the entities are shortened by 1 letter for no reason .. grnt instead of grant .. randomly looking at a UDP example, seems like lots of vectors and no records for instantiation - https://github.com/VLSI-EDA/PoC/blob/master/src/net/udp/udp_Wrapper.vhdl#L49 ..
i am unsure if the PoC stuff exemplifies the modern VHDL approach that i think i am advocating for .. i guess, in all honesty, i am wondering if there are general guidelines and a consensus from the VHDL WG or VHDL community in general about best practices for those 4 things i mentioned
here's one i am unsure about .. when declaring std_logic_vector as an input to, say, a RAM module for data .. should you really write a WIDTH generic to supply the width .. or should modern VHDL rely on VHDL-2019 to use in_data'range to supply the output? in an ideal world where the language is actually supported, what is the best practice ?
Jari Honkanen
@johonkanen
I think that reuse is most useful when we create as small reusable modules as possible since small things are easier to find use for than large modules. For example hvhdl ram module has a separate read record and its associated interface https://github.com/hVHDL/hVHDL_memory_library/blob/main/fpga_ram/ram_read_port_pkg.vhd this is also used for a lookup table sine https://github.com/hVHDL/hVHDL_math_library/blob/main/sincos/lut_sine_pkg.vhd
Richard Head
@trickyhead_gitlab
@bpadalino definitely didnt work last time I used quartus - I even raised a ticket and they said "NO"
Brian Padalino
@bpadalino
as another example, here is vhdl-2019 trying to make an axi streaming entity where you just hook up the signals that are implemented and don't have to keep either open or drive with 0's the other fields .. https://www.edaplayground.com/x/U6x9
@trickyhead_gitlab huh, interesting .. bummer
Jari Honkanen
@johonkanen
Also the lookup table sine has a separate generator function package for changing the function that creates the contents of the lookup table, thus any function that takes in real numbers from 0.0 to 1.0 and returns values between -1.0 and 1.0 can be used. Currently there are functions for sine and sine with harmonics https://github.com/hVHDL/hVHDL_math_library/tree/main/sincos/lut_generator_functions
Jari Honkanen
@johonkanen
The best way that have come up with is by defining word lengths and any other changeable parts of a module in a separate package. This way the configuration can be defined with the library to which the module is compiled to. For example if 16x1024 and 32x512 rams are required then a package can be defined where these constants are. Then the sources just need to be compiled to the same library with the ram record where the memory is defined and we can add versions of this record by compiling the same sources to different libraries of different names. Since we can change both the functions and the insides of records this way we can add pretty much any functionality to any module.
Brian Padalino
@bpadalino
i mean, that seems like what the tools support .. but it still seems like a lot of effort on the designer side .. we know information about the instantiation - and it can determine the size of the vectors .. the functionality of the architecture can even changed based on what is connected to it without changing generics .. which could be a point of misconfiguration, right ?
Patrick Lehmann
@Paebbels
@bpadalino like other libraries, PoC has a history dating back to 2007...
  • Having names like grnt instead of Grant was done by a single person who isn't active with PoC anymore. So there is work ongoing behind the scenes to release a drastically updated PoC Library with things like that cleaned up!
    Besides interface updates, it will bring this when finished:
    • New IO interfaces
    • A full AXI component set for AXI4, AXI4-Lite and AXI4-Stream
    • Additional OSVVM verification models
    • performance enhancements and less hardware resources
    • improved timing and constraints
    • an interface from AXI register descriptions to generate data structures for e.g. C
    • full traceability of Git repository state in a read-only register
  • For records vs. Vectors: That's a question what tools are supported. The current "public" version of PoC is compatible to ISE. An updated version will skip all this change interfaces.
  • For reuse, I haven't seen any IP core out there either as open source or commercial that has more reuse then PoC in itself.
    • Try to find a library where IP cores work the same way on Microsemi, Lattice, Intel and AMD FPGAs or can be synthesized to ASICs!
Brian Padalino
@bpadalino
@Paebbels understandable .. i like the lofty goal of PoC then .. it just seems like the internal consistency needs to be remedied, which seems you are trying to do
so kudos to that for sure .. other than that, i noticed the VHDL coding guidelines stated whitespace recommendations of 2 spaces which, personally, i don't like .. but i am curious if there are actual language based guidelines which should be used .. such as - when writing subprograms which take in std_logic_vector, always alias to a known vector index scheme ..
Patrick Lehmann
@Paebbels
Yes for sure. It was always hard fighting at university to bring components together.
And I'm willing to break interfaces to align naming. It might not be a naming style everyone will agree on, but it will be consistent!
we use one tab per indentation level (because that's what TABs are fore ...). we also add .editorconfig files to repositories.
Brian Padalino
@bpadalino
i think of other programming languages, and the fact there is a "standard library" that is commonly associated with it .. that people can pick up from to stand on the shoulders of giants .. i think it helps reduce the burden of entry and also shows as an example of how to write "good code"
i dunno, tabs are supposed to work that way but it never does, does it?
Patrick Lehmann
@Paebbels
PoC will also be split in two parts in the future. The PoC library will continue to hold IP cores, the helper packages will go into CoreLibrary. Besides this, PoC will kick out the simulation helpers and transition to OSVVM for IP core tests.
Brian Padalino
@bpadalino
what are the timelines for these things ?
Patrick Lehmann
@Paebbels
Python scripting in PoC (pyIPCMI) will be replaced by EDA²

what are the timelines for these things ?

want to support ;) ?

Patrick Lehmann
@Paebbels
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