Hi Srini, Please feel free to expand your ideas on Syntax Option 5 (PSL) as another potential candidate for this proposal. Earlier I have put this under the Reject list, but now that the topic of PSL comes back up, I've returned it as another Syntax Option. http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ClockedShorthand regards, daniel On 28 March 2014 13:47, Srinivasan Venkataramanan <svenka3@gmail.com> wrote: > Daniel, > Binding to a physical clk source, describing pipelines - is natively > done in PSL as far as I understand. Maybe I am missing something here. > > On Synthesizable PSL - already EDA vendors do this for Formal Verif (Model > Checking), so theoretically speaking the big vendors can leverage on their > adjacent tools/platforms. > > Srini > > > > On Fri, Mar 28, 2014 at 11:13 AM, Daniel Kho <daniel.kho@tauhop.com>wrote: > >> Hi Srini, >> >> > a <= {next[2] d}; >> >> PSL is an option we could have, but we need support from synthesis >> vendors to support PSL. Perhaps we could define a subset of PSL that is >> synthesizable. >> >> Again, this brings about the question on how to bind to a physical clock >> source. If we were to use PSL, we will need both PSL and VHDL to be able to >> fully describe a pipeline and bind the set of registers to a clock source. >> >> regards, daniel >> >> On 28 March 2014 12:53, Daniel Kho <daniel.kho@tauhop.com> wrote: >> >>> 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> 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* <http://www.mailscanner.info/>, and >> is >> believed to be clean. >> > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Mar 27 23:59:04 2014
This archive was generated by hypermail 2.1.8 : Thu Mar 27 2014 - 23:59:21 PDT