General code issues thread

[TaraHoleInIt]

I'll start the first one:

In my attempt to debug WaitForRisingEdge by passing in a debug LED I now receive the following error message:

^^^^^^^^^^^^^^^^^^^ incorrect input parameters in call to algorithm 'WaitForRisingEdge', last correct match was parameter 'Signal'

I've checked the documentation and examples a few times, and its not immediately obvious why this is coming up.

$$Period = 1 / Frequency;
$$NSPerClock = 1000000000 * Period;
$$ClocksPerMS = math.floor( 1000000 / NSPerClock );

algorithm Debounce( input uint1 Source, output uint1 Dest ) <autorun> {
	uint24 Clocks = 0;
	uint8 Bitmap = 0;

	while ( 1 ) {
		Clocks = Clocks + 1;

		if ( Clocks == $ClocksPerMS$ ) {
			Bitmap = ( Bitmap << 1 ) | Source;
			Clocks = 0;
		}

		// If all the bits are set then the button should have finished bouncing
		// and the output should be reliable.
		Dest = ( Bitmap == 8hff ) ? 1 : 0;
	}
}

subroutine WaitForRisingEdge( input uint1 Signal, output uint1 Debug ) {
	uint1 Last = 0;

	Debug = 1;

	while ( 1 ) {
		if ( Last == 0 && Signal == 1 ) {
			break;
		}

		Last = Signal;
	}

	Debug = 0;
}

algorithm main( output uint$NUM_LEDS$ leds, output uint$NUM_GPIO_OUT$ gp, input uint$NUM_GPIO_IN$ gn ) {
	uint1 FilteredButton = 0;
	uint1 Button = 0;
	uint1 State = 0;

	Debounce Btn(
		Source <: Button,
		Dest :> FilteredButton
	);

	Button := gn[ 10,1 ];
	leds[ 0,1 ] := State;

	while ( 1 ) {
		// Error
		// ^^^^^^^^^^^^^^^^^^^ incorrect input parameters in call to algorithm 'WaitForRisingEdge', last correct match was parameter 'Signal'
		( ) <- WaitForRisingEdge <- ( FilteredButton, LED );
		State = ~State;
	}
}
```

[sylefeb]

The syntax for the subroutine call is:
(output0,...,outputN) <- sub <- (input0,....,inputK)
So the line has to be changed for
(LED) <- WaitForRisingEdge <- ( FilteredButton)

Something else, more related to timing -- in this part:

   Clocks = Clocks + 1;
   if ( Clocks == $ClocksPerMS$ ) {
	// ...
   }

It is best to increment Clock after the if (adjusting the logic accordingly). This will help timing as the test and addition will no longer depend on each other within the same cycle. (I started writing guidelines for this, hoping to finish soon). In this case this will have little impact, but it is a good habit to take.

(Edit:) the same is true for Dest = ( Bitmap == 8hff ) ? 1 : 0; which is used in the condition after being updated in the if. Btw, this could also be written with an always assign, writing Dest := ( Bitmap == 8hff ) ? 1 : 0; above the while(1) (this will effectively assign Dest first thing every clock cycle). In this case it does not really impact, but that can be very convenient if Dest has to be constantly updated regardless of the state of the algorithm.

[TaraHoleInIt]

Thank you for the feedback!
I will keep this in mind for the future.

That being said, I'm still having trouble getting WaitForRisingEdge to work:

subroutine WaitForRisingEdge( input uint1 Signal ) {
	uint1 Exit = 0;
	uint1 Last = 0;

	Last = Signal;

	while ( Exit == 0 ) {
		Exit = ( Last == 0 && Signal == 1 ) ? 1 : 0;
		Last = Signal;
	}
}

algorithm main( output uint$NUM_LEDS$ leds, output uint$NUM_GPIO_OUT$ gp, input uint$NUM_GPIO_IN$ gn ) {
	uint1 FilteredButton = 0;
	uint1 Button = 0;
	uint1 State = 0;
	uint1 ADebug = 1;

	Debounce Btn(
		Source <: Button,
		Dest :> FilteredButton
	);

	Button := gn[ 10,1 ];
	leds[ 0,1 ] := ADebug;

	gp[ 0,1 ] := State;

	while ( 1 ) {
		ADebug = 1;
			( ) <- WaitForRisingEdge <- ( FilteredButton );
		ADebug = 0;

		State = ~State;
	}
}

I'm not sure if its a code problem or FPGAs being a bit unfamiliar.
As far as I can tell it never actually returns, but FilteredButton is behaving just as I would expect.

[sylefeb]

I think I see the problem. When you call a subroutine it copies its arguments - precisely to avoid them changing while it processes. This is why WaitForRisingEdge does not see FilteredButton change.

Two possible approaches. 1) Incorporate the subroutine in the algorithm (which they are meant to be), so you can actually access the algorithm internals. This becomes:

algorithm main( output uint$NUM_LEDS$ leds, output uint$NUM_GPIO_OUT$ gp, input uint$NUM_GPIO_IN$ gn ) {

	uint1 FilteredButton = 0;
	uint1 Button = 0;
	uint1 State = 0;
	uint1 ADebug = 1;

        subroutine WaitForRisingEdge( reads FilteredButton ) {
	        uint1 Exit = 0;
	        uint1 Last = 0;
        
	        Last = FilteredButton ;
        
	        while ( Exit == 0 ) {
		        Exit = ( Last == 0 && FilteredButton == 1 ) ? 1 : 0;
		        Last = FilteredButton;
	        }
        }


	Debounce Btn(
		Source <: Button,
		Dest :> FilteredButton
	);

	Button := gn[ 10,1 ];
	leds[ 0,1 ] := ADebug;

	gp[ 0,1 ] := State;

	while ( 1 ) {
		ADebug = 1;
			( ) <- WaitForRisingEdge <- ( );
		ADebug = 0;

		State = ~State;
	}
}

Note the explicit declaration reads FilteredButton ; this is to make it clear what a subroutine is supposed to manipulate.

The other option is to turn WaitForRisingEdge into another algorithm and use parameter bindings:

algorithm WaitForRisingEdge( input uint1 FilteredButton ) {
  uint1 Exit = 0;
  uint1 Last = 0;

  Last = FilteredButton ;

  while ( Exit == 0 ) {
    Exit = ( Last == 0 && FilteredButton == 1 ) ? 1 : 0;
    Last = FilteredButton;
  }
}

algorithm main( output uint$NUM_LEDS$ leds, output uint$NUM_GPIO_OUT$ gp, input uint$NUM_GPIO_IN$ gn ) {

	uint1 FilteredButton = 0;
	uint1 Button = 0;
	uint1 State = 0;
	uint1 ADebug = 1;

	Debounce Btn(
		Source <: Button,
		Dest :> FilteredButton
	);

        WaitForRisingEdge waitedge(
            FilteredButton <: FilteredButton, // parameter binding
        );

	Button := gn[ 10,1 ];
	leds[ 0,1 ] := ADebug;

	gp[ 0,1 ] := State;

	while ( 1 ) {
		ADebug = 1;
		() <- waitedge <- (); // no input parameter as it is bound
		ADebug = 0;

		State = ~State;
	}
}

When a parameter is bound it tracks the value of the source (connected through a wire in terms of hardware). Note that there are two bindings: <: tracks the value as it is updated during the cycle, <:: tracks the value at it was at the cycle starts (this is a topic I will document better, it is a very interesting degree of freedom to play with in designs). In short, <: is typical and allows the algorithm to immediately start refreshing the outputs when a value is changed -- but this can also reduce the max frequency of the design as the signal propagation deepens. <:: will trigger a refresh only at the next cycle: pay one in latency but increase max freq.

[TaraHoleInIt]

I have done some testing with generating delays, it seems like ones done inline are accurate while wrapping them in a subroutine causes problems.

For example, if I have a counter in my main loop and toggle a pin whenever the counter reaches 4 then I get a 250ns signal which is what I would expect from a 16MHz clock.
Trying to make this neater by wrapping it up in a subroutine is nowhere near as accurate.

Maybe I'm just approaching this wrong and there is a more correct way to accurately handle timing?

[sylefeb]

Hi - the timing would have to account for the subroutine entry/exit cycles. This is partially discussed in Section 5 but I really have to revise this with more examples and diagrams, that is an important topic.

So for instance, let's consider this wait subroutine in a small test case:

subroutine wait(input uint16 incount)
{
  uint16 count = uninitialized;
  count = incount;
  while (count != 0) { count = count - 1; }
}
	
algorithm main( output uint$NUM_LEDS$ leds,input uint1 btns ) 
{
  uint16 cycle = 0;

  always { cycle = cycle + 1; }

  __display("[before] cycle %d",cycle);
  () <- wait <- (0);
  __display("[next  ] cycle %d",cycle);
  () <- wait <- (4);
  __display("[done  ] cycle %d",cycle);
}

Now simulating with icarus make icarus (Makefile at the end) we get:

[before] cycle     0
[next  ] cycle     4
[done  ] cycle    12

So we can see the subroutine call, even with a 0 parameter takes 4 cycles. With an input of 4 it then takes 8 cycles. So there is an overhead of four: 2 for entry/exit of subroutine and 2 for the entry/exit of the while. Note that there are chain rules, so adding a while right after the other will add a single cycle instead of 2 (clarifying the documentation right now!).

What if we want a less than 4 cycles wait? We can use multiple ++: operators, or use a circuitry to inline a while loop with a parameter for its duration.

Taking these delays into account should give you the exact timing.

.DEFAULT: test.ice
		silice-make.py -s test.ice -b $@ -p basic -o BUILD_$(subst :,_,$@)

clean:
	rm -rf BUILD_*

[TaraHoleInIt]

Ohhhh okay!
I think I see what was happening then.

I don't think I was taking into account not only that entering and exiting the subroutine were taking cycles, but that the main loop was adding some delay as well.
That being said, nothing I'm doing now requires timing that precise, I just wanted to understand the behaviour I was seeing.

Thank you :)

[at91rm9200]

Hello,

I am a Silice and FPGA newbie and have a question regarding readwrite permissions on subroutines.

In the following example the subroutine out_led is called by the subroutine out_led_inverted. For this, the subroutine out_led_inverted needs to get permission to access the parameter pattern from out_led.

algorithm main(output uint5 leds) {

uint26 cnt = 0;

   subroutine out_led(input uint5 pattern, readwrites leds) {
      leds = pattern;
   }

   subroutine out_led_inverted(input uint5 pattern_inv, readwrites i_out_led_pattern) {
   //                                                              ^^^^^^^^^^^^^^^^^
      () <- out_led <- (~pattern_inv);
   }

   while(1) {
      cnt = cnt + 1;
      () <- out_led_inverted <- (cnt[21,5]);
   }
} 

But the syntax for this is not clear to me. Only from the compiler error message "variable 'i_out_led_pattern' is written by subroutine 'out_led_inverted' without explicit permission" I could recognize the name for this parameter. Is this intentional or did I miss something?

Regards, Bernd.

[sylefeb]

Hello Bernd,

The error message is indeed not useful, I'll improve that. The subroutine out_led_inverted has to explicitly declare it intends to call out_led. Here is how to do that:

Silice/tests/issues/108_rw_perm.ice

Line 9 in 5fa9ed9

subroutine out_led_inverted(input uint5 pattern, calls out_led) {

Welcome to Silice!
Best regards,
Sylvain

[sylefeb]

Improved error message (in wip branch):

() <- out_led <- (~pattern)
^^^^^^^^^^^^^^^^^^^^^^^^^^^ subroutine 'out_led_inverted' calls other subroutine 'out_led' without permssion
                            add 'calls out_led' to declaration if that was intended.

error: Silice compiler stopped

Thanks for pointing this out!!

[at91rm9200]

Hello Sylvain,

thank you for the explanation. It works perfectly.

Regards, Bernd.

[at91rm9200]

Hello,

I am trying to bind two pmod bits, one as input and the other one as output, to an algorithm. The input binding "bit_in <: pmod.i[0,1]" seems to work, but the output binding "bit_out :> pmod.o[1,1]" leads to an error: "cannot find accessed base.member 'pmod.o'". For sure, this is a beginner question. But I cannot see, how to solve this.

algorithm alg_test(input uint1 bit_in, output uint1 bit_out)
{
   bit_out = ~bit_in;
}

algorithm main(output uint5 leds, inout uint8 pmod) {

   alg_test a(bit_in <: pmod.i[0,1], bit_out :> pmod.o[1,1]);  // <-- cannot find accessed....

   while (1) {
      pmod.oenable = 8b00000010;
      () <- a <- ();
   }
}  

Regards, Bernd.