I need to mix together code where one library uses Apple SIMD types such as simd_packed_float4, and another part of the code uses NEON SIMD types such as float32x4_t. I don't want to change the types used in either part, so I need to cast the data types where they interface. This is using the latest Xcode/clang where they appear not to be simple aliases of each other.
Obviously the correct C++ way is to use a memcpy() but I wondered if I had missed another simpler way that wasn't an undefined behaviour cast or lane by lane copying. And thus was better for code generation across debug builds?
I'm currently analyzing a given FPGA Verilog program and I stumbled upon the lpm_constant IP-Core, provided by Altera.
The only thing it does is to provide a constant value to a bus.
My Question is, why one should use this IP-Core, instead of a wire with constant value, or a reg with initialization in initial block, or reset cycle.
I also don't see the point of the reason being either to improve performance (Fitter should take care of this anyways, regardless of implementation) or compatibility with other designs (the language Verilog/VHDL is standardized, so why would this be an issue).
Thanks for clarification.
One can use the In-System Memory Content editor to change the value of the "constant" at design run time, to help in debug and testing of the design. We lose this capability if we hard code a value in RTL.
As #JHBonarius said the only reason to use lpm_constant (Altera Megafunction) if you describe your project in a schematic way, i.e. use Block Design File (*.bdf). If you use HDL-like approach use CONSTANT to make code CAD Tools independent.
In many of my VHDL designs I create a lot of low level components in HDL (which is fine). However, when I am ready to create multiple instantiations and link them together at the top-level, I find that the file ends up being rather large with tons of internal signals going between tons of component instantiations. It gets a little unwieldy and hard to follow.
Instead, I thought what might be easier to understand and faster to develop with is if there was a graphical tool to do the high level component linking. It would be able to parse my low level HDL files and determine the port inputs/outputs and create a block (or multiple instances of that block). I could then use my mouse to create connections between the blocks and give them a text label. When I am done, it would be able to auto-generate a VHDL file with all appropriate syntax for creating internal signals, component instantiations, port declarations, etc.
I tried experimenting with Xilinx Schematic Editor, but this thing was a beast and I did not have any luck.
Is there any tool out there like this? If it could even get me 90% of the way I'd be happy.
You should take a look at www.sigasi.com
Sigasi has autocompletes to help you with the instantiations and quick-fixes to help you with the wiring. There is also a premium version that gives you a live, graphical block diagram view (demo screencast)
I am implementing something in VHDL, and I don`t understand the errors that I get:
library IEEE;
use IEEE.std_logic_1164.all;
use work.primitive.all;
entity LogicF is
port(A,B,C:in std_logic; Y:out std_logic);
end LogicF;
architecture STRUCTURAL of LogicF is
signal notA, notB, andSign:std_logic;
begin
inv1:inverter port map (i=>A,o=>notA);
inv2:inverter port map (i=>B,o=>notB);
si1:and2 port map (i1=>notA, i2=>notB, o=>andSign);
sau1:or2 port map (i1=>andSign, i2=>C, o=>Y);
end STRUCTURAL;
Error: (3,10): Cannot find referenced context element.
Error: (8,1): Cannot find referenced entity declaration "LogicF"
As Brian points out Line 3, Character 10 (3,10) is the first character of the word primitive in use.work.primitive.all;. It seems the package hasn't been in the working library.
%% ghdl -a LogicF.vhdl
LogicF.vhdl:3:10: primary unit "primitive" not found in library "work"
ghdl: compilation error
%%
The question about which tool comes from the second error at (8,1), the entity LogicF did not successfully analyze and wasn't placed in the working library.
IEEE Std 1076 (the LRM), Design units and their analysis, Order of analysis:
If any error is detected while attempting to analyze a design unit,
then the attempted analysis is rejected and has no effect whatsoever
on the current working library.
The second error comes from the entity LogicF not being present in a referenced library.
(The LRM) same section (11.4 -1993, 13.5 -2008):
The rules defining the order in which design units can be analyzed are
direct consequences of the visibility rules. In particular:
a. A primary unit whose name is referenced within a given design unit must be analyzed prior to the analysis of the given design unit.
b. A primary unit must be analyzed prior to the analysis of any corresponding secondary unit.
An entity is a primary unit (LogicF) an architecture (STRUCTURAL) is a secondary unit.
When I used ghdl to analyze your design 'file' it quit after the first error. In this case because the second design unit was a secondary unit, the first failing was sufficient to stop analysis from succeeding. If there were further unrelated design units their analysis could have continued should they have proven to be error free (and didn't depend on the package primitives).
What's missing from the error messages are explanations of any assumptions, which are typically found in the tool implementation's documentation.
To answer Brian's question in his comment the format of the error message is from Aldec, apparently the Aldec-HDL tool (Google is useful betimes).
His was a professional curiosity question, Brian is one of the ghdl developers. There is no requirement VHDL that an error requires you to not analyze further design units found in the same design file. It's an implementation detail, where now we know what Aldec does.
Aldec doesn't share documentation other than with customers which otherwise makes it hard to seek third party help. You see a lot of universities publish tutorials on using Aldec tools.
I found the error message in another third party forum where the vendor was identified.
I've recently just started learning VHDL again after not having touched it for years. The hope is to use it to develop a control system with various sensor interfaces, etc. I'm fairly competent in embedded C, which has been my go-to language for any embedded projects I've had up until this point, which makes learning VHDL all the more frustrating.
Basically, my issue right now, which I see as my biggest barrier in being able to progress with my intended project, is that I don't know how to develop and incorporate a module that I can just pass variables to and call (like a function in C) to carry out some task, i.e. display an integer 0-9999 on a 4 digit 7-segment display.
I know there are components in VHDL, but that seems like such a long winded way of performing one task. Is there a better way of doing this?
It seems to me like after you've done all the digital tutorials, there's a huge gap in the info on how to actually develop a full system in VHDL.
EDIT : further explanation re: third comment at the bottom. Apologies for the length of this!
VHDL has functions and procedures too, just like C. (OK, C calls its procedures "void functions"!) And, just like C, you can call them from sequential code using the same kinds of sequential code constructs (variables, loops, if statements, case-statements which have some similarities to C's switch), and so on.
So far, all this is synthesisable; some other VHDL features are for simulation only (to let you test the synthesisable code). So in simulation you can - like C - open, read and write files, and use pointers (access types) to handle memory. I hope you can see why these parts of VHDL aren't synthesisable!)
But what is different in VHDL is that you need a few extra lines to wrap this sequential code in a process. In C, that happens for you; a typical C program is just a single process (you have to resort to libraries or OS functionality like fork or pthreads if you want multiple processes)
But VHDL can do so much more. You can very easily create multiple processes, interconnect them with signals, wrap them as re-usable components, use "for ... generate" to create multiple processes, and so on. Again, all synthesisable : this imposes some restrictions, for example the size of the hardware (number of processes) cannot be changed while the system is running!
KEY: Understand the rules for signal assignment as opposed to variable assignment. Variables work very much as in C; signals do not! What they do instead is provide safe, synchronised, inter-process communication with no fuss. To see how, you need to understand "postponed assignment", delta cycles, wait statements, and how a process suspends itself and wakes up again.
You seem to be asking two questions here:
(1) - can I use functions as in C? Very much so; you can do better than C by wrapping useful types and related functions, procedures in a package and re-using the package in multiple designs. It's a little like a C++ reusable class with some stronger points, and some weaker.
(2) can I avoid entities, architectures and components altogether in VHDL? You can avoid components (search for "VHDL direct entity instantiation") but at some point you will need entities and architectures.
The least you can get away with is to write a single process that does your job, receiving inputs (clk, count) on signals and transmitting to the LEDs on other signals.
Create an entity with all those signals as ports, and an architecture containing your process, connecting its signals up to the ports. This is easy - it's just boilerplate stuff. On an FPGA, you also need to define the mapping between these ports and the actual pins your LEDs are wired to. Synthesise it and you're done, right? .. not quite.
Create another "testbench" entity with no external ports. This will contain your entity (directly instantiated), a bunch of signals connecting to its ports, and a new process which drives your entity's input ports and watches its output ports. (Best practice is to make the testbench self-checking, and assert when something bad comes out!) Usually "clk" comes from its own one-liner process, and clocks both testbench and entity.
Now you can simulate the testbench and watch your design working (or not!) at any level of detail you want. When it works - synthesise.
EDIT for more information: re: components, procedures, functions.
Entities/components are the main tool (you can ignore components if you wish, I'll deal with entities later).
Procedures and functions usually work together in a single process. If they are refactored into a package they can be re-used in other like-minded processes (e.g. operating on the same datatypes). A common abstraction is a datatype, plus all the functions and procedures operating on it, wrapped in a package - this somewhat resembles a C++ class. Functions also have uses in any declaration area, as initialisers (aka "factory" pattern in software terms)
But the main tool is the entity.
This is a level that is probably unfamiliar to an embedded C programmer, as C basically stops at the level of the process.
If you have written a physical block like an SPI master, as a process, you will wrap that process up in an entity. This will communicate with the rest of the world via ports (which, inside the entity, behave like signals). It can be parameterised via generics (e.g. for memory size, if it is a memory). The entity can wrap several processes, other entities, and other logic that didn't fit neatly into the process (e.g. unclocked logic, where the process was clocked)
To create a system, you will interconnect entities, in "structural HDL code" (useful search term!) - perhaps a whole hierarchy of them - in a top level entity. Which you will typically synthesise into an FPGA.
To test the system via simulation, you will embed that top level entity (=FPGA) in another entity - the testbench - which has no external ports. Instead, the FPGA's ports connect to signals inside the testbench. These signals connect to ... some of them connect to other entities - perhaps models of memories or SPI slave peripherals, so you can simulate SPI transactions ... some of them are driven by a process in the testbench, which feeds your FPGA stimuli and checks its responses, detecting and reporting errors.
Best practice involves a testbench for each entity you create - unit testing, in other words. An SPI master might connect to somebody else's SPI slave and a test process, to start SPI transactions and check for the correct responses. This way, you localise and correct problems at the entity level, instead of attempting to diagnose them from the top level testbench.
A basic example is shown here :
Note that he shows port mapping by both positional association and (later) named association - you can also use both forms for function arguments, as in Ada, but not C which only allows positional association.
What "vhdlguru" doesn't say is that named association is MUCH to be preferred, as positional association is a rich source of confusion and bugs.
Is this starting to help?
Basically there are two possibilities of handing information to an entity:
At runtime
Entities communicate with each other using signals that are defined inside a port statement. For better readability I suggest using std_logic_vector, numeric_std or even better record types where appropriate. See link below.
At synthesis time
If you want to set a parameter of an entity to a fixed value at synthesis time (for instance the size of a fifo) you might want to use a generic statement. See also link below.
I can also recommend reading this paper. It helped me a lot when coping with system that exceed a certain complexity:
A structured VHDL design method
Some simple generalizations for entity/component vs subprogram (function / procedure).
Use an entity when a reusable block of code contains a flip-flop (register).
Use a function do to a calculation. For RTL code, I use functions for small, reusable pieces of combinational logic.
I primarily use procedures for testbenches. I use procedures to apply a single transaction (waveform or interface action) to the design I am testing. For testbenches, I further use procedures to encapsulate frequently used sequences of transactions.