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