I faced a problem when using Quartus II from Altera.
In the VHDL course, I have a problem about the behavior of VHDL variables VS signals.
The theory says that the VHDL variables get its new value immediately. On the other hand , the signal's new value requires a delay. So the result is different between the two cases.
But this is not what happens when I use Quartus tool. I unexpectedly get the same result for both. I don't Know why this happens, please advise??
If your assignments all go without an explicit delay clause like y <= x after 10 ns; then the difference is a single delta cycle. A delta cycle is no physical time and is not visible in the waveform. You will see a difference though when you use either the updated variable or signal to assign to another output signal later in the same process. Assigning from the variable copies its newly computed value, assigning from the signal copies the value it started with into the current delta cycle.
You should get the same result. There shouldn't be any delay. In programs which use VHDL, the programs operate so fast that you can't measure a delay. If you want a delay you can use the "wait for x ns" command.
Related
I'm trying to make a program to power a dc motor for 2 seconds when a 1 is inputted. I already have a circuit designed with an LED and a capacitor for the motors protection, but i can't figure out a way to make this VHDL script.
if i try to use a "wait" statement or something, it conflicts with my "if" statements. This is for a cyclone IV FPGA
The "wait" statement is not synthesizable.
This means, you will not be able to run it on any board. It is more like a "helping" tool for modelling - e.g. when you need to model the real time delays of flipflops or make a testbench.
The easiest way to create a time delay on your board is to create a counter, that counts up to a given value and changes signal/output when value reached.
I use Xilinx ISE as a IDE.
If I add a 100 ps delay at every assignment in a always(Verilog)/process(VHDL) with sensitive list only have clock and reset.
Like this.
always#(posedge clk)
if(rst)
a <= #100 'd0;
else
a <= #100 b;
end
I think the delay function is only effect the simulation process.Because every book and user guide tell us delay is not synthesizable.
But I still wondering if the delay function can really effect the place or route's result?Like static timing or clock report?
Like can make a circuit max frequency higher or slower?
No the #delay in your code is not going to affect the timing of the design when it is loaded on to the FPGA.
It also does not affect the place and route results or the static timing analysis. Both of these steps use timing information that is provided by the manufacturer in the form of device models.
You are correct that there's nothing intrinsic about delay statements that makes them unsynthesizable, however it's wildly impractical to attempt to do so. The reason for this is that once on the FPGA you are dealing with a physical circuit whose performance varies with PVT (process, voltage, temperature) and can do so by a lot! The only hedge against this would be an analog circuit that attempts to sense all of the above and adjust itself accordingly. Such a beast will still be limited in what it can do, and would be physically large and power hungry depending on the rage of delay and the variance in all of the above you want to support.
So with than in mind and considering that there is very little (read: no) demand for this outside of special purpose IO FPGA vendors don't provide any such components making the construct unsythesizable.
Delay statements (#100) are usually ignored during synthesis in Verilog. So in synthesis it is the same as:
always#(posedge clk)
if(rst)
a <= 0;
else
a <= b;
end
Xlinx Synthesis and Simuation Design Guide states:
Delays in Synthesis Code
Do not use Wait for XX ns (VHDL) or the #XX (Verilog) statements in
your code. (...) This statement does not synthesize to a component.
In designs that include this construct, the functionality of the
simulated design does not always match the functionality of the
synthesized design.
(...)
Wait for XX ns Statement Verilog Coding Example
#XX;
Do not use the After XX ns statement in your VHDL code or the Delay
assignment in your Verilog code
(...)
Delay Assignment Verilog Coding Example
assign #XX Q=0;
XX specifies the number of nanoseconds that must pass before a
condition is executed. This statement is usually ignored by the
synthesis tool. In this case, the functionality of the simulated
design does not match the functionality of the synthesized design.
"Usually" there is no impact on synthesis and P&R results.
Xilinx: This statement is usually ignored by the synthesis tool.
When does it have impact then?
Although the delay statement is ignored by the synthesis tool, the HDL code is a little bit different. That may change the seed of randomization in any stage (parsing, elaboration, synthesis etc.), so there is a possibility for different results. These results may be better or worse.
If a delay statement exists in the code, the following warning is expected from Xilinx ISE:
WARNING:Xst:916 - design.v line x: Delay is ignored for synthesis.
I am looking to build a VHDL circuit which responds to an input as fast as possible, meaning I don't have an explicit clock to clock signals in and out if I don't absolutely need one. However, I am also looking to avoid "bouncing" where one leg of a combinatorial block of logic finishes before another.
As an example, the expression B <= A xor not not A should clearly never assign true to B. However, in a real implementation, the two not gates introduce delays which permit the output of that expression to flicker after A changes but the not gates have not propagated that change. I'd like to "debounce" that circuit.
The usual, and obvious, solution is to clock the circuit, so that one never observes a transient value. However, for this circuit, I am looking to avoid a dependence on a clock signal, and only have a network of gates.
I'd like to have something like:
x <= not A -- line 1
y <= not x -- line 2
z <= A xor y -- line 3
B <= z -- line 4
such that I guarantee that line 4 occurs after line 3.
The tricky part is that I am not doing this in one block, as the exposition above might suggest. The true behavior of the circuit is defined by two or more separate components which are using signals to communicate. Thus once the signal chain propagates into my sub-circuit, I see nothing until the output changes, or doesn't change!
In effect, the final product I'm looking for is a procedure which can be "armed" by the inputs changing, and "triggered" by the sub-circuit announcing its outputs are fully changed. I'd like the result to be snynthesizable so that it responds to the implementation technology. If it's on a FPGA, it always has access to a clock, so it can use that to manage the debouncing logic. If it's being implemented as an ASIC, the signals would have to be delayed such that any procedure which sees the "triggered" signal is 100% confident that it is seeing updated ouputs from that circuit.
I see very few synthesizable approaches to such a procedural "A happens-before B" behavior. wait seems to be the "right" tool for the job, but is typically only synthesizable for use with explicit clock signals.
my doubt is how to pass a clock between two entities that are at the same hierarchical level in VHDL.
What I have is an entity "wrapper" in which there are instantiated two components "comp_1" and "comp_2". comp_1 has an output port (let's say "clk_out") that is its clock and that must be also the clock for comp_2. Now, if I use a signal in "wrapper" to pass the clock from comp_1 to comp_2, this cause a functional error in simulation (at least with Modelsim), because the two designs are considered not synchronous (right?). Can this cause an error also in synthesis (with Xilinx)? How can I avoid the problem without changing all the structure?
architecture bhv of my_wrap is
signal tmp_clk : std_logic;
begin
comp_1_i : comp_1
port map(out_clk => tmp_clk,
...
);
compo_2_i : comp_2
port map(in_clk => tmp_clk,
...
);
In this case, in simulation there is the delta cycle problem in the signals between the two components. Can this problem also affect the implemented design on FPGA?
It sounds like you may have a delta cycle delay on the clock, which is a feature in VHDL, but it may appear as if clock and data is out of sync.
This only shows in simulation, but is general VHDL thus not ModelSim specific. After synthesis (in hardware) the internal delay gives similar behavior. Note that ModelSim has a feature ("Expanded Time Delta Mode") to show delta delays.
Without code, I guess that the generated clock in comp_1 is also used for output generation, besides being output on clk_out. Depending on the implementation, it may result in a delta cycle delay difference between clock and data, which is may appear as not synchronous, but it is actually a delta cycle issue.
A possible fix is to output the generated clock from comp_1 without using it, and then making an additional clk_in input on comp_1, similar to the clk_in on comp_2, and then use that clock internally in comp_1. The clock use will then be similar on comp_1 and comp_2, removing the issue with delta delays on clock.
As Morten also pointed out some source code could help making your question more precise.
There is nothing wrong in connecting the clock out signal from one component to the clock in signal of another component. What might be a problem in your case is the way you generate the clock signal.
Depending on your use case you have different options.
If your target is an FPGA you should use a clock generator IP form the given vendor.
Simply having a code like this :
if(rising_edge(clk)) then
temp(0):="001";
temp(1):="011";
temp(2):="101";
temp(3):="000";
temp(0):=temp(3)xor temp(5);
end if
For the example above all this variable assignment would be done in 1 clock cycle which is pretty unpractical. In the behavioral simulation it works fine but in post synthesis it's messed up. Can I add like a delay or a sth like a wait(wait statement is un-synthesizable) to make it wait util the variable gets its value before jumping to the next line?
Doing all of those things in one clock cycle is simple. Hardware is extremely fast, and FPGA clock rates aren't that high relative to processors.
Since you are using variables, the intermediate results are used immediately. If you want a more explicit delay, you could use a signal. The above code with signals would use temp(3) from the previous rising edge.
for synthesis you can not make delays like wait. well defined, controllable delays in synthesis can only be made with pipelining (clock cycles as delay units).