Subject: Re: [sv-ec] SV-BC18f - Logic Data Type - Cliff Cummings action item
From: Dave Rich (David.Rich@synopsys.com)
Date: Sun Dec 08 2002 - 23:02:17 PST
Cliff,
The clarification I am writing up for SV-BC18g will solve your problem.
If you declare a port as an output, there can be no writers outside that
module, so you cannot connect two module's output ports together using a
SystemVerilog type.
BTW, Why did you limit your issue to just logic, bit, and real? Structs,
enums, int's, etc. all have the same behavior through a port.
I agree that this shared variable behavior is not suitable for
synthesis. I do see it useful at testbench level for things like
semaphores, mailboxes, or any data structure you want multiple modules
to be able to manipulate without having to know the hierarchical pathname.
Dave
Clifford E. Cummings wrote:
> Hi, All -
>
> Per my action item per SystemVerilog-BC18f, I must report the
> following concerning logic and other SystemVerilog data types.
>
> The following SystemVerilog data types all have a serious common flaw
> that must be corrected: logic, bit, real.
>
> (1) logic, bit and real do not behave like any known real hardware
>
> The last-assignment-wins behavior at an upper level module for
> multiple lower-level procedural assignments is behavior that does not
> match any known hardware.
>
> Consider the case of two instantiated flip-flop models as shown below:
>
> module top;
> logic q, d1, d2, clk, rst_n;
>
> dff u1 (.q(q), .d(d1), .clk(clk), .rst_n(rst_n));
> dff u2 (.q(q), .d(d2), .clk(clk), .rst_n(rst_n));
> endmodule
>
> module dff (
> output logic q,
> input logic d, clk, rst_n);
>
> if (!rst_n) q <= 0;
> else q <= d;
> endmodule
>
> In this design, an engineer mistakenly connected the q-outputs of two
> flip-flops together in the top module.
> This design has a race condition and last q-assignment wins, which is
> not anything close to how the real hardware works. In Verilog, the
> outputs would resolve on a net and conflicting values would show up in
> a simulation as an unknown (X). The X shows the engineer there is a
> problem in the design that will not be found using the logic data type
> until either a lint-tool shows the problem or until after synthesis
> when a gate-level simulation is performed and fails.
>
> In the above example, logic could be replaced with "bit" for 2-state
> simulation and the same problem would exist.
>
> Similarly, if an engineer modeled a Digital-to-Analog (D-A) converter
> and accidentally instantiated two
> D-A converters with analog outputs tied together, the last D-A
> conversion would win. This again does not behave like any known real
> hardware.
>
> I can think of no real hardware that would behave like this. I can
> think of no verification strategy that would want to take advantage of
> this "feature."
>
> I spent two hours on Friday afternoon discussing with two engineers
> from Intel, issues associated with the "logic" data type in its
> current form. I believe at least the three of us arrived at a
> consensus solution that would satisfy their design requirements very
> nicely as well as modify logic, bit and real to behave correctly for
> all designs. I am working on and I will try to send out a proposal
> later in the day on Monday to again propose that logic become a
> universal data type, along with supporting proposals, enhancements and
> other capabilities that have been fully considered to date. The
> proposals could resolve many of the issues we have tracked with the
> logic data type thus far.
>
> Regards - Cliff
>
> ----------------------------------------------------
> Cliff Cummings - Sunburst Design, Inc.
> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
> Phone: 503-641-8446 / FAX: 503-641-8486
> cliffc@sunburst-design.com / www.sunburst-design.com
> Expert Verilog, Synthesis and Verification Training
>
>
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Sun Dec 08 2002 - 23:03:23 PST