[vhdl-200x] Clocked Shorthand Proposal - Need Consensus

Hi all,
> Hence with '@', we are not introducing a new operator, just recycling the
one from PSL.

Okay, I guess if we consider PSL, then yes we won't be introducing new
syntax.


> Personally I prefer expressive code and am not fond of either '@' or
"after" since they do not mention
> Clk.  Who knows though, if the "C/C++" style behavioral synthesis takes
hold, maybe we no longer
> need to specify clock in our designs.  Just waiting for someone to do a
decent VHDL behavioral
> synthesis tool.

I'm not sure if "C/C++"-style behavioral synthesis will be able to really
replace existing techniques for synthesis. In my opinion, we would still
want to be able to have control over our clocks and resets.  For software
guys, they don't have to worry about such things, and I believe
"C/C++"-style synthesis caters for this group of people and try and make
their life easier. However, I don't think it will make the life of hardware
designers easier. It's hard for us to optimize our designs when we lose
control over a lot of things. My view is that these tools take away such
control from us.

Well, I haven't toyed around with those tools, so I can't know for sure if
this were the case. Perhaps someone who have used Catapult or Handel can
comment here? This is just my general perception about using existing HLS
tools. Things could change though.


> OTOH, I am not convinced we need any syntax for this.  When you start
looking at adding reset, we
> do not have anything
> that is all that much better than:
>    Q <= D when rising_edge(Clk) ;
>  Q <= '0' when not nReset else D when rising_edge(Clk) ;
>  Q <= '0' when not nReset and rising_edge(Clk) else D when
rising_edge(Clk) ;
>
>Ok, so you loose the pipelining, however, maybe that is what we need the
operator for.

Exactly. That's one of the primary purpose of this proposal, i.e. to
introduce an easy way to do pipelining.
If we wanted to have an asynchronous reset and pipelined output, we will
need to have something like:
Q <= '0' when not nReset else D after 2;
or
Q <= '0' when not nReset else D @ 2;

>If I want more concise, but less expressive code, I can always switch to
using a procedure:
>  Reg(Clk, D, Q) ;
>  RegAr(Clk, not nReset, D, Q) ;
>  RegSr(Clk, not nReset, D, Q) ;
>  RegR(Clk, not nReset, D, Q) ; -- default reset style choosen by
selecting/compiling a particular package body.
>
>   RegPipe(Clk, D, Q, 5) ;
>
>Some of the reset issues would be simplified if synthesis tools provided a
mechanism for shifting
>reset styles.

This will make writing DSP equations pretty hard IMO. Something that could
easily be written with 'after' or '@' like the following,

q <= to_signed(0, dataWidth) when not enable else to_signed((123_456 * (d0
after 2) - 78_901 * (d1 after 5)) / 2**(d0 after 1), dataWidth);

would probably have to be written as multiple statements instead.


YG,

> This also raises the question of _which_ clock to use for the delay.
> and since "cycle" or "cycles" might be already used as a variable name,
> why not use the clock's name as a delay qualifier ?
>
> a <= b after 3 clk;

Which clock to use is determined by the attribute

attribute default_clock of ent1 : entity is clk_sig;


> But I'm not totally satisfied by this,
> the word "after" traditionally involves a time delay,
> while here we have a different semantic.
> The pipelining would be more obvious with
> a "delayed" or "pipelined" keyword.
> Or something like that.

Yes, 'after' traditionally involves a time delay, but my view is that a
pipelined signal is also a time-delayed signal with the duration of the
delay as discrete multiples of the clock period (or clock half-period, if
you're talking abo
Inbox (426) <https://mail.google.com/mail/u/0/?pli=1#inbox>
ut DDR).
I thought of the 'after' as delays, and can be applied to both
continuous-time (using time units such as us, ns, etc.) and also
discrete-time (multiples of the clock period) in which case is considered a
pipelined signal. This was also one of the reasons why the term z-transform
was used in the early discussions, where 'z^(-k)' refers to the discrete
time delay.

I agree that 'delayed' or 'pipelined' makes things more obvious, but this
also introduces potential new keywords to the language.
BTW, 'delayed' is already a predefined VHDL attribute. Will it be a good
idea to extend its use in this case?

The signal s when delayed by an amount N, could be written as:
s'delayed(N)

This however depends on the _unit_ of N. If N is in ns, then s will be
delayed by N ns.

If we were to extend its use for pipelining, we could introduce another
time unit, in addition to the standard us, ns, ps, ms, etc. We could
introduce a _discrete_ time unit, and let's just make it simple by calling
it 'cycles'.

type Time is range
  units
     fs;            -- femtosecond
     ps  = 1000 fs; -- picosecond
     ...
     *cycles*;
 end units;

The user will then need to link the time variable to a clock signal (for
synthesis), something like the following:
attribute default_clock of N : time is clk;

and will be able to use N as an independent variable in discrete time:
constant N: time := 1 cycles;

where '1' here would refer to 1 clock cycle. Possibly, elsewhere in the
design, the clock period was also specified in ns:
constant period: time := 20 ns;
...
clk <= not clk after period;

After this, the simulation tool will be able to implicitly infer how much
time '1 cycle' would take, i.e. 1 cycle = 20 ns. Simply because the
constant 'N' was already bound to 'clk' earlier, and 'clk' was found to be
toggling at 20 ns.
For synthesis tools, they don't have to bother about how many ns the delay
will take, but rather they would just be interested in the number of
pipeline registers to infer, by looking at the value preceding the 'cycles'.


Applying this in an earlier example, we could write something like:
Q <= '0' when not nReset else D'delayed(2*N);
or simply
Q <= '0' when not nReset else D'delayed(2 cycles);

and for the mathematical example, we could write:
q <= to_signed(0, dataWidth) when not enable
    else to_signed((123_456 * (d0'delayed(2*N)) - 78_901 * (d1'delayed(5*N)
)) / 2**(d0'delayed(1*N)), dataWidth);


Summarized, what a (future) user would write if this option were chosen
would be something like:
attribute default_clock of N : time is clk;
Q <= '0' when not nReset else D'delayed(2 cycles);

or
attribute default_clock of N : time is clk;
constant N: time := 1 cycles;
Q <= '0' when not nReset else D'delayed(2*N);

Just my $0.02.


Personally, I'm not very fond of adding new keywords such as 'pipelined',
but would like to hear from anyone else in support of this idea.


regards, daniel


On 28 March 2014 09:01,
<whygee@f-cpu.org<javascript:_e(%7B%7D,'cvml','whygee@f-cpu.org');>
> wrote:

> Le 2014-03-27 20:12, ryan.w.hinton@L-3com.com a écrit :
>
>  True, there is the possibility of confusion. There are a few
>> differences, though, between the pipelining "after" and the
>> "asynchronous" after. First, the synchronous "after" only works in the
>> new clocked process context.
>>
>
> This also raises the question of _which_ clock to use for the delay.
> and since "cycle" or "cycles" might be already used as a variable name,
> why not use the clock's name as a delay qualifier ?
>
> a <= b after 3 clk;
>
> But I'm not totally satisfied by this,
> the word "after" traditionally involves a time delay,
> while here we have a different semantic.
> The pipelining would be more obvious with
> a "delayed" or "pipelined" keyword.
> Or something like that.
>
> I don't see how/where I would use this.
> But to me, mentioning the clock signal is a step forward.
>
> yg
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>


-- 
Best regards,
Daniel Kho, Consultant
Tauhop Solutions
VHDL | Python | bash | DSP | Matlab | Sage | Design Services
Tel.: +60 (16) 333 0498

http://www.tauhop.com

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.