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
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.
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 ?
@bpadalino like other libraries, PoC has a history dating back to 2007...
- Having names like
grntinstead ofGrantwas 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!
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 ..
we use one tab per indentation level (because that's what TABs are fore ...). we also add
.editorconfig files to repositories.
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?
what are the timelines for these things ?
want to support ;) ?
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/
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
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 ?
@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
@drpi GHDL doesnt have a built in TCL interpreter.
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.
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
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
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
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
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"
(...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
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