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, and is believed to be clean.Received on Thu Mar 27 22:44:02 2014
This archive was generated by hypermail 2.1.8 : Thu Mar 27 2014 - 22:44:21 PDT