I have to write the VHDL code for the following entity-architecture design:
develop a "machine" with the following signals:
- clock input (100Mhz)
- 4 input lines (1-bit) called: REQ0...REQ3
- 4 output lines (1-bit) called: GRANT0...GRANT3
- a reset signal (input)
The machine checks the input lines on every clock rising edge.
If one input line is "high" (bit 1), it sets an high value on the corresponding GRANT line. The GRANTi line turns low when, on the rising edge of the clock, the corresponding REQi line turns low, or after 8 (module 8 counter) clock cycles.
If more than ones REQi lines are high at the same time, only one GRANTi line can turns high (whatever line GRANTi you want), but can't turns high the line just lowered.
I hope the text is clear. I was not able to figure out the problem.
Related
I am trying to create a half adder circuit using logisim to compute two 4 bit binary numbers but somehow Logisim tells me that I have incompatible widths and I therefore have to change the bit width of every single component including the carry-out which is suppose to be a 1 bit (showing carry 1 or carry 0). Now I understand that my output has to be at least 4 bit in length and I need an extra bit as a carry out but even when I change the length the way Logisim wants then my design does not work anymore.
Half adder of a 2 four bit binaries
It's simply because the input width on the AND gate is 1 bit. You can't have a 4-bit output going into a 1-bit input.
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.
This question is an extension of the another shown here, VHDL Process Confusion with Sensitivity Lists
However, having less than 50 Rep points, I was unable to comment for further explanation.
So, I ran into the same problem from the link and accept the answer shown. However, now I am interested in what the recommended approach is in order to match simulation with post-synthesis behavior. The accepted answer in the link states that Level Sensitive Latches are not recommended as a solution due to them causing more problems. So my question is what is the recommended approach? Is there one?
In other words, I want to acheive what was trying to be achieved in that post, but in a way that won't cause more problems. I need my sensitivity list to not be ignored by my synthesis tools.
Also, I am new to VHDL so it may be possible that using processes is not right way to achieve the result I want. I am using a DE2-115 with Quartus Prime 16.0. Any information will be greatly appreciated.
If you are using VHDL to program your FPGA-based prototyping board you are interested in the synthesis semantics of the language. It is rather different from the simulation semantics described in the Language Reference Manual (LRM). Even worse: it is not standardized and varies between synthesis tools. Anyway, synthesis means translation from the VHDL code to digital hardware. The only recommended approach here, for a beginner who still do not clearly understands the synthesis semantics is:
Think hardware first, code next.
In other words, draw a nice block diagram of the hardware you want on a sheet of paper. And use the following 10 rules. Strictly. No exceptions. Never. And do not forget to carefully check the last one, it is as essential as the others but a bit more difficult to verify.
Surround your drawing with a large rectangle. This is the boundary of your circuit. Everything that crosses this boundary is an input or output port. The VHDL entity will describe this boundary.
Clearly separate edge-triggered registers (e.g. square blocks) from combinatorial logic (e.g. round blocks).
Do not use level-triggered latches.
Use only rising-edge triggered registers and use the same single clock for all of them. Its name is clock. It comes from the outside and is an input of all square blocks and only them. Do not even represent the clock, it is the same for all square blocks and you can leave it implicit in your diagram.
Represent the communications between blocks with named and oriented arrows. For the block an arrow comes from, the arrow is an output signal. For the block an arrow goes to, the arrow is an input signal.
Arrows have one single origin but they can have several destinations. If an arrow has several destinations, fork the arrow as many times as needed.
Some arrows come from outside the large rectangle. These are the input ports of the entity. An input arrow cannot also be the output of any of your blocks.
Some arrows go outside. These are the output ports. An output arrow has one single origin and one single destination: the outside. No forks on output arrows. So, an output arrow cannot be also the input of one of your blocks. If you want to use an output arrow as an input for some of your blocks, insert a new round block to split it in two parts: the input of the new block, with as many forks as you wish, and the output arrow that comes from the new block and goes outside. The new block will become a simple continuous assignment in VHDL. A kind of transparent renaming.
All arrows that do not come or go from/to the outside are internal signals. You will declare them all in the architecture.
Every cycle in the diagram must comprise at least one square block.
If you cannot find a way to describe the function you want with this approach, the problem is with the function you want. Not with VHDL or the synthesizer. It means that the function you want is not digital hardware. Implement it using another technology.
The VHDL coding becomes a detail:
one synchronous process per square block,
one combinatorial process per round block.
A synchronous process looks like this:
process(clock)
begin
if rising_edge(clock) then
o1 <= i1;
...
on <= in;
end if;
end process;
where i1, i2,..., in are all arrows that enter the corresponding square block of your diagram and o1, ..., om are all arrows that output the corresponding square block of your diagram. Do not change anything, except the names of the signals. Nothing. Not even a single character. OK?
A combinatorial process looks like this:
process(i1, i2,... , in)
<declarations>
begin
o1 <= <default_value_for_o1>;
...
om <= <default_value_for_om>;
<statements>
end process;
where i1, i2,..., in are all arrows that enter the corresponding round block of your diagram. all and no more. Do not forget a single arrow and do not add anything else. There are no exceptions. Never. And where o1, ..., om are all arrows that output the corresponding round block of your diagram. all and no more. Do not change anything except <declarations>, the names of the inputs, the names of the outputs, the values of the <default_value_for_oi> and <statements>. Do not forget a single default value assignment. If you had to create a new round block to split a primary output arrow, the corresponding process is just:
process(i)
begin
o <= i;
end process;
which you can simplify as:
o <= i;
without the enclosing process declaration. It is the equivalent concurrent signal assignment.
Once you will be comfortable with this coding style and only then, you will:
Skip the drawing for simple designs. But continue thinking hardware first. Draw in your head instead of on a sheet of paper but continue drawing.
Use asynchronous resets:
process(clock, reset)
begin
if reset = '1' then
o <= reset_value_for_o;
elsif rising_edge(clock) then
o <= i;
end if;
end process;
Merge several combinatorial processes in one single combinatorial process. This is trivial and is just a simple reorganization of the block diagram.
Merge some combinatorial processes with synchronous processes. But in order to do this you must go back to your block diagram and add an eleventh rule:
Group several round blocks and at least one square block by drawing an enclosure around them. Also enclose the arrows that can be. Do not let an arrow cross the boundary of the enclosure if it does not come or go from/to outside the enclosure. Once this is done, look at all the output arrows of the enclosure. If any of them comes from a round block of the enclosure or is also an input of the enclosure, you cannot merge these processes in a synchronous process.
And later on you will also start using latches, falling clock edges, multiple clocks and resynchronizers between clock domains... But we will discuss these when the time will have come.
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.
I want to implement a PUF using ring oscilator in VHDL, I want to generate 32 Ring Oscilator with different gate delays. How can I do that?
My code is as follows:
generate_ros:
for i in 0 to 31 generate
ro_1: ring_oscilator
generic map (delay => 200 ps , chain_len => 15) -- 200ps shall be random
port map (
rst_i => s_rst,
clk_o => s_inp(i)
);
end generate;
According to Improved Ring Oscillator PUF: An FPGA-friendly Secure Primitive all ROs should be identical and have the same delay (most ring oscillators works that way).
The delay in a ring oscillator loop is caused by random process variation and systematic variation and not by nominal delay (as explained in 3.1.1). That's why when you create n ROs, you'll get (with high probability) n/2 0's and n/2 1's at each positive edge of your clock. You do not need to define delay at HDL level.
To realize the PUF on FPGA, you should use Hard Macro for single RO FPGA design. As the PUF depends upon static delay variation ( Process dependent variation ), Hard Macro will fix the design parameter(LUT, slice) on FPGA. Once you got one, you can replicate as many as you want, in your case 31.