As the instigator of 1715 I'm *extremely* confused by this.... > always_ff @(posedge clk or rst_n or set_n) > if (!rst_n) q <= '0; > else if (!set_n) q <= '1; > else if (clk.triggered) q <= d; 1715 attempted to propose that, since a clocking block's name can be used much as an event in an @event_name timing control, then the implied event associated with a clocking block's name should have all the same attributes as any other event; in particular, that it should be possible to use its name also in a wait() timing control. I also very much wanted to be able to assign the clocking block's name to an event handle. None of these concerns makes a lot of sense in synthesis. Even if we could detect the .triggered attribute of a (posedge some_clock) event, it would be a fatally flawed way to mimic the rising_edge() functionality of VHDL. VHDL's rising_edge() is defined (in paraphrase) as clock'event and clock = '1' and clock'last_value = '0' The key issue is that clock'event lasts only for one delta cycle. There is no exact equivalent of a delta cycle in Verilog, but one complete loop around the active region-set is a fairly close approximation (it is one complete round of scheduling zero-delay NBAs and then allowing them to update, which is about as close as you'll get to a VHDL delta). clock'event most definitely does NOT persist until the end of the timeslot, whereas .triggered does. Consider the behaviour of the proposed FF model in the following situation: initial begin clock = 0; // clock quiet #1 set_n = 1; rst_n = 0; // reset, no set #1 rst_n = 1; // come out of reset, q==0 for sure #1 // recovery time to avoid any ambiguity // FF is now cleanly reset and all its inputs are quiet d = 1; #1 clock = 1; // clean posedge on clock wait (q === 1'b1); // wait for FF to respond, later in timeslot rst_n = 0; // assert reset in same timeslot wait (q === 1'b0); // wait for reset to take effect in zero time rst_n = 1; // release reset, retriggers clocked code in FF model !!! The release of reset, late in the t=1 timeslot, has the effect of executing your FF model's "clocked" logic, because (posedge clock).triggered is still active. In VHDL this would not be possible because the various signal updates have consumed more than one delta, so clock'event would be false by that time. Getting the set/reset FF model to work is easy, but requires a leap of imagination for synthesis (forgive the active high resets, but they make the logic easier to follow): always_ff @(posedge clock or posedge rst or posedge (set & !rst)) if (rst) q <= 0; else if (set) q <= 1; else q <= d; Simulates OK, expresses intent OK, clarifies priority of set/reset. No fooling around with event.triggered, which makes little sense for synthesis. Only the "posedge (set & !rst)" is vexatious. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri May 4 14:37:31 2007
This archive was generated by hypermail 2.1.8 : Fri May 04 2007 - 14:37:48 PDT