Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

VHDL Noob question- Recursion?

Hello,

I am studying VHDL and am at the topic of signal changes in dataflow and behavior style architectures. So I have two questions.

1) Will the "compiler" ever allow a scenrio where recursion is possible?

Example: Say in a dataflow architecture signal 'G' is listed on the right side of a signal assignment and signal 'E' on the left. In addition, within the same package/file there is a behavior style architecture that has 'E' in its sensitivety list and when the 'E' changes the behavoiral process is called which updates 'G', which repeats the events noted above.

Now my to architecture syntax maybe invalid, but I hope you get the point.

architecture my_xor_dataflow of my_xor_fun is 
begin 
   E <= A XOR G;   
end my_xor_dataflow; 

architecture my_xor_behavioral of my_xor_fun is 
begin 
xor_proc: process(E,F) 
   begin 
      G <= E OR F;   
   end process xor_proc;  
 
end my_xor_behavioral;

Is such a thing possible? My guess is that a compile error will be raised and that recursion is not possible in VHDL, is that correct?

2) Could a case exist such that a signal is updated in one architecture which results in an event to be scheduled to update another signal in a different architecture? That is, say a signal in a process sensitivety list is changed and the subsequent logic updates another signal which triggers another architecture to re-evaluate a signal assignment. I take it that the compile allows this but ensure there is no circular references. is that correct?

I read a lot of VHDL beginner tutorials but didn't find anything related to this topic. Any positive input would be appreciated.

Thanks,

Moe

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hello,

    1) these two signals assignments are in different architectures. The E signal in one architecture is completely unbound from the same thing with the same name in another architecture; even if the two architectures are of the same entity. I might have missed the point.

    Anyway, you can have a signal that is produced inside the a combinational function that feeds back in the same function. This may give you problems in simulation (if there is not a stable result this may give you too much oscillations and exhaust the number of delta for each signal transition), may give warnings in synthesis (I am not sure, I usually avoid things like this).

    2) I think that you made some confusion about architectures, entities, instances. An architectures gives an incarnation of an entity. You can instantiate as many components as you need and theoretically as many instances as you need for a component. Any VHDL book and tutorials explains the chance to bond different instances of a component to different architectures in the same design. If you manage to do this (I had problems with this when I used Xilinx tools so I lost this habit and never used it with Altera ones), your different architectures will be threated independently. I suggest you to think at the instances of a component (even if you call different architectures for each) like threads with different memory spaces.

    I hope this helps you. Sometimes VHDL can seem very strange and difficult, especially when the learner comes from a long experience of C, C++, Matlab and other languages that do not describe hardware. I think this is common to historical hardware description languages.

    Regards,

    Gabriele
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The construct involves a logic loop rather than recursion. In the present example, the logic loop can either act as a latch or a ring oscillator, depending on the state of signal A.

    Apart from the question if the design serves a reasonable purpose, it's basically synthesizable. The compiler will issue a warning about generating a logic loop. The A='1' F='0' ring oscillator case will cause problems in simulation (signal changing every simulation time step) and probably excessive current consumption in hardware.