Basic var question

[slowstart]

Hello.

I'm new to VHDL and sometimes get mixed up. Maybe you could help me clear something up.

I know variable assignment is instant whereas with signal assignment there is a delta delay. In the following code :

rd_en <= rd = '1' and empty ='0';

process
begin
if rising_edge(Clk) then

if Rd_en then

datum_out <= Fifo(0);

Fifo(14 downto 0) <= Fifo(15 downto 1);
wr_addrs := wr_addrs -1;

if wr_addrs = 7 then
empty <= '1';
end if;

end if;
end if;
end process;

My question is the following: Due to delta delay from signal assignment even if rd = '1' and empty = '0' i will not read until the next clock cycle because rd_en will nto instantly take on the value of '1'. Which means i'm basically losing one clock. If I don't declare rd_en as a signal and instead declare it as a variable. Then i could simply create another process stating if rd = '1' and empty = '0' then rd_en := 1; . Would doing so save me that clock cycle ? would it work ?

thank you in advance for any help.

 

[jeandelfrigo]

slowstart,

let's get a few things straight.

Delta delay is a simulation thing. It is there because 1 processor cannot do two things at the same time, where hardware can. So a processor simulator needs delta delays to emulate concurrency of hardware.

Now decent hardware design is synchronous, so using clocks that determine the rythm of the logic.

rd_en <= rd = '1' and empty ='0'; is a parallel or concurrent statement. In reality this will mean that rd_en will get its value nearly instantly (only the LUT propagation delay and routing delay and this amongst others depends on the speed grade of the target device). In simulation this will be one delta delay.

Now rd_en is evaluated on the rising edge of the clock. So this will mean that you will have to wait a fraction of the clock period untill for example datum_out <= Fifo(0); gets done. Worst case this is one clock. If empty and rd are synchronous to clk then they will change tco (clock to output) after the clock edge and datum_out will get its new value tco after the next clock edge so one clock delay. This is not the case if empty and rd are asynchronous to clk, then the delay can be less than a clock (but you might get troubles see later).

On a simulator this will react the same, only during functional simulations the combinatorical delays will be multiples of the delta delay. If you want to go more realistic you need to perform timing simulations.

The thing is you will need to learn to live with this because this is reality.

Sure you could make it a bit faster by not using the clock and writing everything combinatorical (who needs clocks anyway right?)

Guess what, you'll probably get it to work in simulations.

But when it is synthesized the fun starts and timing parameters kick in as well as for example temperature, voltages, etc. In short the design might work in reality on a nice cool morning but might fail in the afternoon.

Using clocks and working synchronous will not produce the fastest logic, but if you keep to some rules and achieve your timing it will work all the time. So it will produce the fastest reliable logic.

I know from Xilinx that they have a division or team that writes pure asynchronous designs, for fun or benchmarking or whatever I don't know for sure (will probably not be for fun) and these guys have designs in I think Virtex2Pro or V4 running over 1 GHz equivalent.
So if you really want to squeeze everything out of your FPGA or PLD try contacting them, but make sure to ask them how great a job debugging the code is .

I'm sure Intell are able to make a pure asynchronous processor that uses less power and performs (sometimes) equally to a normal processor, but I'm also sure they do prefer people complaining about non Intell software bugs instead of processor hardware bugs.

If you want speed use high end devices (Virtex5, Stratix III), use the highest possible clock frequency and try to pipeline or parallelize as much as possible. But do not go asynchronous.

About variables and signals. I've written a fair bit of VHDL and I almost never use variables. Is this a must? No other and better programmers might use them all the time, but I don't like having to think to much about the diffenreces in behavior between signals and variables and since I allways wrtie code that needs to go in a FPGA or PLD I prefer to keep some visibility over what will be the result in hardware (I still don't 100% trust tools to give the best or optimal result).

Anyhow, I would leave the code as is, especially if you want to synthesize it.

regards

jeandelfrigo

 

[slowstart]

Lol - Dude, thank you so much. It makes my day when someone actually takes the time to help me understand something ! I really appreciate it.