Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

"waiting" for the combinatorial logic

Status
Not open for further replies.
S

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,302
I have a synthesizable VHDL function called - "do_something"
it works on 2 signals and returns a result :

Code: 
result <= do_something ( x , y ) ;

The problem is that it has a combinatorial delay of many system clocks.
Will the following work:

Code: 
process ( clock , reset ) is
begin
  if reset = '1' then 
     result <= ( others => '0' ) ;
     ready <= '0' ;
  elsif rising_edge ( clock ) then
     if delay < enough_cycles then
        result <= do_something ( x , y ) ;
        delay <= delay + 1 ;
     else
        ready <= '1' ;
     end if ;
  end if ;
end process ;

Assuming "do_something" takes 10 system clocks to complete, and "enough_cycles" is a constant that equals 20.
If we read the "result" signal when "ready" is '1' - will we read a valid value of "result" ?
 

What do your simulations tell you?

r.b.
 

do_something is a function, and so it will always complete instantly. A function cannot take 10 clocks to complete, unless the values of x and y are changing elsewhere, based on the result value, and then that has nothing to do with the function.
But why havent you simulated it?
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
I have simulated it.
In simulation it works fine...My question is about real life - not simulation.
I just wanted to know if I wrote correctly the "waiting" section...
 

You are going to have a big problem. Because you're relying on a the time genertor to tell you the delay, you have to remember that this will be affected by temperature, so you cannot garantee it will always take that time.

It would be much much safer just to pipeline the function.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
It would be much much safer just to pipeline the function.
Click to expand...
But then it would no longer be a function...
 

But it would be a workable solution.
Sometimes suitability trumps simplicity. If your solution was viable, then every large design would use the same methodology. I have never seen this ever. Pipelining is the only sensible solution, and is a lot more portable because delays will vary between devices.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
In the original example, the delay isn't properly implemented. Although I agree completely with Tricky's suggestion of doing everyting in pipeline, a multicycle delay can be of course implemented. We have to be aware of a certain delay range of n1 to n2 cycles to get the result from the combinational logic. So what you can do is
- register the input signals and start the delay counter
- register the output after > n2 clock cyclces.
Strictly spoken, the input must be hold at least for n2 - n1 clock cycles, so it's easier to hold it for the complete delay time
 

In the original example, the delay isn't properly implemented.
Click to expand...
is it properly implemented now ?

Code: 
process ( clock , reset ) is
begin
	if reset = '1' then 
		registered_x <= ( others => '0' ) ;
		registered_y <= ( others => '0' ) ;	
	elsif rising_edge ( clock ) then
		registered_x <= x ;
		registered_y <= x ;				
	end if ;	
end process ;

change_xy <= '1' when ( x /= registered_x or y /= registered_y ) else '0' ;

process ( clock , reset ) is
begin
	if reset = '1' then 
		result <= ( others => '0' ) ;
                               delay <=  ( others => '0' )  ;
		ready <= '0' ;
	elsif rising_edge ( clock ) then
		if change_xy = '1' then
			ready <= '0' ;
                                               delay <=  ( others => '0' )  ;
		elsif delay < enough_cycles then
			result <= do_something ( x , y ) ;
			delay <= delay + 1 ;
		else
			ready <= '1' ;
		end if ;
	end if ;
end process ;
 

The code will only give a result, if the input data doesn't change too often. It's a possible implementation, but opposite to the idea to hold the registered input data until the result has been stored.

Calling the function in conditional code looks strange at first sight, but should be O.K. because the result value is calculated uncondtionally and registered conditionally.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top