Menu
▾
▴
iverilog-devel
|
From: Stephen W. <st...@ic...> - 2009-10-13 14:46:49
Attachments:
tranif1.v
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been working on some fixes to the tranifX handling in Icarus Verilog. I fixed a couple bugs, but now the tranif1.v test in the ivtest suite no longer works. I've been puzzling over it, and I now think that the test itself is not valid. The meat of the program is here: wire pin; pullup (weak1) (keep1); pulldown (weak0) (keep0); tranif1 (pin, keep1, pin); tranif0 (pin, keep0, pin); This is trying to simulate a keeper circuit, the idea being if the "pin" is released to HiZ, the previous value will have left one of the keepers enabled. But I don't believe this should simulate properly. The tranifs are not drivers themselves, so if the external pin driver is released, "pin" will go to Z, which will close *both* gates and pin will stay HiZ. Can people who have access try the attached program on the Big 3? - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFK1JLOrPt1Sc2b3ikRAvxsAJ9zpYB3CFAepTI/oIRI+o7ab6v1lgCgz+iw t6NaKNJ8LYrx1W0JSKFr62o= =IrDG -----END PGP SIGNATURE----- |
|
From: Martin W. <mai...@ma...> - 2009-10-13 14:52:17
|
Both NC-Verilog and Verilog-XL report "PASSED". Stephen Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I've been working on some fixes to the tranifX handling in Icarus > Verilog. I fixed a couple bugs, but now the tranif1.v test in the > ivtest suite no longer works. I've been puzzling over it, and I now > think that the test itself is not valid. The meat of the program > is here: > > wire pin; > pullup (weak1) (keep1); > pulldown (weak0) (keep0); > tranif1 (pin, keep1, pin); > tranif0 (pin, keep0, pin); > > This is trying to simulate a keeper circuit, the idea being if > the "pin" is released to HiZ, the previous value will have left > one of the keepers enabled. > > But I don't believe this should simulate properly. The tranifs > are not drivers themselves, so if the external pin driver is > released, "pin" will go to Z, which will close *both* gates and > pin will stay HiZ. > > Can people who have access try the attached program on the Big 3? > > - -- > Steve Williams "The woods are lovely, dark and deep. > steve at icarus.com But I have promises to keep, > http://www.icarus.com and lines to code before I sleep, > http://www.picturel.com And lines to code before I sleep." > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4-svn0 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org > > iD8DBQFK1JLOrPt1Sc2b3ikRAvxsAJ9zpYB3CFAepTI/oIRI+o7ab6v1lgCgz+iw > t6NaKNJ8LYrx1W0JSKFr62o= > =IrDG > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > > > ------------------------------------------------------------------------ > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: Trevor W. <pha...@gm...> - 2009-10-13 15:06:02
|
VCS.2006.09 passed. 2009/10/13 Stephen Williams <st...@ic...> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I've been working on some fixes to the tranifX handling in Icarus > Verilog. I fixed a couple bugs, but now the tranif1.v test in the > ivtest suite no longer works. I've been puzzling over it, and I now > think that the test itself is not valid. The meat of the program > is here: > > wire pin; > pullup (weak1) (keep1); > pulldown (weak0) (keep0); > tranif1 (pin, keep1, pin); > tranif0 (pin, keep0, pin); > > This is trying to simulate a keeper circuit, the idea being if > the "pin" is released to HiZ, the previous value will have left > one of the keepers enabled. > > But I don't believe this should simulate properly. The tranifs > are not drivers themselves, so if the external pin driver is > released, "pin" will go to Z, which will close *both* gates and > pin will stay HiZ. > > Can people who have access try the attached program on the Big 3? > > - -- > Steve Williams "The woods are lovely, dark and deep. > steve at icarus.com But I have promises to keep, > http://www.icarus.com and lines to code before I sleep, > http://www.picturel.com And lines to code before I sleep." > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4-svn0 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org > > iD8DBQFK1JLOrPt1Sc2b3ikRAvxsAJ9zpYB3CFAepTI/oIRI+o7ab6v1lgCgz+iw > t6NaKNJ8LYrx1W0JSKFr62o= > =IrDG > -----END PGP SIGNATURE----- > > > module main; > > > // Model a pin with a weak keeper circuit. The way this works: > // If the pin value is 1, then attach a weak1 pullup, but > // if the pin value is 0, attach a weak0 pulldown. > wire pin; > pullup (weak1) (keep1); > pulldown (weak0) (keep0); > tranif1 (pin, keep1, pin); > tranif0 (pin, keep0, pin); > > // Logic to drive a value onto a pin. > reg value, enable; > bufif1 (pin, value, enable); > > initial begin > value = 0; > enable = 1; > #1 if (pin !== 0) begin > $display("FAILED -- value=%b, enable=%b, pin=%b", value, enable, > pin); > $finish; > end > > // pin should hold its value after the drive is removed. > enable = 0; > #1 if (pin !== 0) begin > $display("FAILED -- value=%b, enable=%b, pin=%b", value, enable, > pin); > $finish; > end > > value = 1; > enable = 1; > #1 if (pin !== 1) begin > $display("FAILED -- value=%b, enable=%b, pin=%b", value, enable, > pin); > $finish; > end > > // pin should hold its value after the drive is removed. > enable = 0; > #1 if (pin !== 1) begin > $display("FAILED -- value=%b, enable=%b, pin=%b", value, enable, > pin); > $finish; > end > > $display("PASSED"); > end > > endmodule // main > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > |
|
From: Trevor W. <pha...@gm...> - 2009-10-13 15:06:07
|
Oops. Make that VCS 2009.06 passed :) On Tue, Oct 13, 2009 at 10:05 AM, Trevor Williams <pha...@gm...>wrote: > VCS.2006.09 passed. > > 2009/10/13 Stephen Williams <st...@ic...> > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> I've been working on some fixes to the tranifX handling in Icarus >> Verilog. I fixed a couple bugs, but now the tranif1.v test in the >> ivtest suite no longer works. I've been puzzling over it, and I now >> think that the test itself is not valid. The meat of the program >> is here: >> >> wire pin; >> pullup (weak1) (keep1); >> pulldown (weak0) (keep0); >> tranif1 (pin, keep1, pin); >> tranif0 (pin, keep0, pin); >> >> This is trying to simulate a keeper circuit, the idea being if >> the "pin" is released to HiZ, the previous value will have left >> one of the keepers enabled. >> >> But I don't believe this should simulate properly. The tranifs >> are not drivers themselves, so if the external pin driver is >> released, "pin" will go to Z, which will close *both* gates and >> pin will stay HiZ. >> >> Can people who have access try the attached program on the Big 3? >> >> - -- >> Steve Williams "The woods are lovely, dark and deep. >> steve at icarus.com But I have promises to keep, >> http://www.icarus.com and lines to code before I sleep, >> http://www.picturel.com And lines to code before I sleep." >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.4-svn0 (GNU/Linux) >> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org >> >> iD8DBQFK1JLOrPt1Sc2b3ikRAvxsAJ9zpYB3CFAepTI/oIRI+o7ab6v1lgCgz+iw >> t6NaKNJ8LYrx1W0JSKFr62o= >> =IrDG >> -----END PGP SIGNATURE----- >> >> >> module main; >> >> >> // Model a pin with a weak keeper circuit. The way this works: >> // If the pin value is 1, then attach a weak1 pullup, but >> // if the pin value is 0, attach a weak0 pulldown. >> wire pin; >> pullup (weak1) (keep1); >> pulldown (weak0) (keep0); >> tranif1 (pin, keep1, pin); >> tranif0 (pin, keep0, pin); >> >> // Logic to drive a value onto a pin. >> reg value, enable; >> bufif1 (pin, value, enable); >> >> initial begin >> value = 0; >> enable = 1; >> #1 if (pin !== 0) begin >> $display("FAILED -- value=%b, enable=%b, pin=%b", value, enable, >> pin); >> $finish; >> end >> >> // pin should hold its value after the drive is removed. >> enable = 0; >> #1 if (pin !== 0) begin >> $display("FAILED -- value=%b, enable=%b, pin=%b", value, enable, >> pin); >> $finish; >> end >> >> value = 1; >> enable = 1; >> #1 if (pin !== 1) begin >> $display("FAILED -- value=%b, enable=%b, pin=%b", value, enable, >> pin); >> $finish; >> end >> >> // pin should hold its value after the drive is removed. >> enable = 0; >> #1 if (pin !== 1) begin >> $display("FAILED -- value=%b, enable=%b, pin=%b", value, enable, >> pin); >> $finish; >> end >> >> $display("PASSED"); >> end >> >> endmodule // main >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Iverilog-devel mailing list >> Ive...@li... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> >> > |
|
From: Martin W. <mai...@ma...> - 2009-10-13 15:10:31
|
Stephen Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I've been working on some fixes to the tranifX handling in Icarus > Verilog. I fixed a couple bugs, but now the tranif1.v test in the > ivtest suite no longer works. I've been puzzling over it, and I now > think that the test itself is not valid. The meat of the program > is here: > > wire pin; > pullup (weak1) (keep1); > pulldown (weak0) (keep0); > tranif1 (pin, keep1, pin); > tranif0 (pin, keep0, pin); > > This is trying to simulate a keeper circuit, the idea being if > the "pin" is released to HiZ, the previous value will have left > one of the keepers enabled. > > But I don't believe this should simulate properly. The tranifs > are not drivers themselves, so if the external pin driver is > released, "pin" will go to Z, which will close *both* gates and > pin will stay HiZ. > What you are missing is that tranifs are true (bi-directional) switches. Once you turn one of them on, the keeper can drive "pin" through the switch, so will hold "pin" at its last value until something stronger drives "pin" to another value. Martin |
|
From: Stephen W. <st...@ic...> - 2009-10-13 15:44:07
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Whitaker wrote:
> Stephen Williams wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> I've been working on some fixes to the tranifX handling in Icarus
>> Verilog. I fixed a couple bugs, but now the tranif1.v test in the
>> ivtest suite no longer works. I've been puzzling over it, and I now
>> think that the test itself is not valid. The meat of the program
>> is here:
>>
>> wire pin;
>> pullup (weak1) (keep1);
>> pulldown (weak0) (keep0);
>> tranif1 (pin, keep1, pin);
>> tranif0 (pin, keep0, pin);
[...]
> What you are missing is that tranifs are true (bi-directional) switches. Once
> you turn one of them on, the keeper can drive "pin" through the switch, so
> will hold "pin" at its last value until something stronger drives "pin" to
> another value.
I am *not* missing that tranifs are true bi-directional switches.
Believe me, I've gone through a lot of pain to make them work, so
I'm well aware.
In fact, it's their "switch" nature that makes me think this test
is wrong. Ask yourself:
- what happens when "pin" is driven 0?
- what happens when "pin" is driven 1?
- what happens when "pin" is driven X?
- what happens when "pin" is driven Z?
and
- Does it make sense for the answer to any of the above to differ
depending on what happened before it?
You see, the test is relying on a delta delay between an assignment
of Z to the pin and the tranif enable gates responding. If you were
to solve the value of the island of switches based only on the drivers,
you should see this:
tranif1 (pin=Z, week1, pin=Z);
tranif0 (pin=Z, week0, pin=Z);
Tell me what that is without invoking delta delays or state machines
or hysteresis.
Now the following I think is well defined.
wire pin;
wire keeper;
assign #(delta) keeper = pin;
pullup (week1) peek1;
pulldown (week0) peek0;
tranif1 (pin, keep1, keeper);
tranif0 (pin, keep0, keeper);
That at least 2 of the big3 get the do-what-I-mean answer to the
original example is freaking me out. Modelsim?
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFK1KA+rPt1Sc2b3ikRAi9/AKCKe1+YrpPSABjooUH/tZOGg4YiDwCgzHOg
A4xY5HgJNsB0HKPQRg/RI+o=
=1DlH
-----END PGP SIGNATURE-----
|
|
From: Jared C. <jar...@gm...> - 2009-10-13 16:13:29
|
On Tue, Oct 13, 2009 at 8:43 AM, Stephen Williams <st...@ic...> wrote: > That at least 2 of the big3 get the do-what-I-mean answer to the > original example is freaking me out. Modelsim? > ModelSim 6.5A -- PASSED. :) Jared |
|
From: Cary R. <cy...@ya...> - 2009-10-13 16:19:39
|
--- On Tue, 10/13/09, Stephen Williams <st...@ic...> wrote:
> In fact, it's their "switch" nature that makes me think
> this test is wrong. Ask yourself:
>
> - what happens when "pin" is driven 0?
> - what happens when "pin" is driven 1?
> - what happens when "pin" is driven X?
> - what happens when "pin" is driven Z?
> and
> - Does it make sense for the answer to any of the above to
> differ depending on what happened before it?
0 and 1 are real signals, X is an indeterminate real signal
(it's 1 or 0, we just don't know which one), but Z is special,
it is supposed to represent a lack of drive. I don't think
of this as driving Z, but more as not driving anything. In
that context it seems to make sense that the tranif gates
work as they do. If you are no longer driving a signal the
pulls keep it in the previous state.
Cary
|
|
From: Stephen W. <st...@ic...> - 2009-10-13 17:18:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cary R. wrote: > --- On Tue, 10/13/09, Stephen Williams <st...@ic...> wrote: > >> In fact, it's their "switch" nature that makes me think >> this test is wrong. Ask yourself: >> >> - what happens when "pin" is driven 0? >> - what happens when "pin" is driven 1? >> - what happens when "pin" is driven X? >> - what happens when "pin" is driven Z? >> and >> - Does it make sense for the answer to any of the above to >> differ depending on what happened before it? > > 0 and 1 are real signals, X is an indeterminate real signal > (it's 1 or 0, we just don't know which one), but Z is special, > it is supposed to represent a lack of drive. I don't think > of this as driving Z, but more as not driving anything. In > that context it seems to make sense that the tranif gates > work as they do. If you are no longer driving a signal the > pulls keep it in the previous state. But when "pin" becomes HiZ, your logic is relying on the switch not disconnecting until after tran resolution is done. In other words, one of the switches is remembering that it is closed while the new value is calculated. And of course then it discovers that the feedback is holding the switch closed. But if you start with the switches open (which is reasonable because someone just propagated a HiZ to "pin") then the keepers are not attached to anything and "pin" remains HiZ. Or that is what is happening in Icarus Verilog. So what should happen here (Drive pin=1, then pin=HiZ)? tranif1 (pin, keep0, pin); tranif0 (pin, keep1, pin); Or here? buf (buffered_pin, pin); tranif1 (pin, keep1, buffered_pin); tranif0 (pin, keep0, buffered_pin); Every argument claiming that the tranif1.v test is "correct" has so far relied on some hysteresis or capacitance or memory in the switch for it to work. But how can that memory be justified, or modeled. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFK1LZsrPt1Sc2b3ikRAqIOAJ9AGewQinI6PVX0zvTQgMboaYKl/wCgmX+X Bc/KTztWOA7aAn+M0LxyVpU= =o+Ri -----END PGP SIGNATURE----- |
|
From: Martin W. <mai...@ma...> - 2009-10-13 19:06:41
|
Stephen Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Cary R. wrote: >> --- On Tue, 10/13/09, Stephen Williams <st...@ic...> wrote: >> >>> In fact, it's their "switch" nature that makes me think >>> this test is wrong. Ask yourself: >>> >>> - what happens when "pin" is driven 0? >>> - what happens when "pin" is driven 1? >>> - what happens when "pin" is driven X? >>> - what happens when "pin" is driven Z? >>> and >>> - Does it make sense for the answer to any of the above to >>> differ depending on what happened before it? >> 0 and 1 are real signals, X is an indeterminate real signal >> (it's 1 or 0, we just don't know which one), but Z is special, >> it is supposed to represent a lack of drive. I don't think >> of this as driving Z, but more as not driving anything. In >> that context it seems to make sense that the tranif gates >> work as they do. If you are no longer driving a signal the >> pulls keep it in the previous state. > > But when "pin" becomes HiZ, your logic is relying on the switch > not disconnecting until after tran resolution is done. In other > words, one of the switches is remembering that it is closed while > the new value is calculated. And of course then it discovers that > the feedback is holding the switch closed. > Absolutely. As I said before, "pin" doesn't become HiZ - one of the drivers of "pin" becomes HiZ. You can't change the state of "pin" until you have performed tran resolution. From section 11.6.5. of the standard: "Switch processing shall consider all the devices in a bidirectional switch-connected net before it can determine the appropriate value for any node on the net because the inputs and outputs interact." The only memory involved here is the current state of the network. That seems perfectly reasonable to me. Martin |
|
From: Evan L. <sa2...@cy...> - 2009-10-13 21:45:56
|
Stephen Williams wrote: > Every argument claiming that the tranif1.v test is "correct" has > so far relied on some hysteresis or capacitance or memory in the > switch for it to work. Mine doesn't. "tranif.v" is correct because it models a real transmission gate, and the simulator is responsible for applying any appropriate bodge to make this so. The LRM doesn't, I think, say how this bodge works, but Steven Sharp *does* say in the post I quoted (see below). There's a good chance that XL and NC both do what Steve S says. First off, the bodge is nothing to do with drivers and driver resolution. You can't model a transmission gate using drivers, because there's *no* driver in a transmission gate; it's just a voltage-controlled resistive element. Martin quotes 11.6.5: > "Switch processing shall consider all the devices in a bidirectional > switch-connected net before it can determine the appropriate value for any > node on the net because the inputs and outputs interact." But this is just a get-out; it says nothing about *how* the inputs and outputs interact, or how any combination of drivers could model a resistive element without interfering with each other or locking up. I don't buy it as an explanation of how tranif works. Back to Steve W: > But how can that memory be justified, or > modeled. The memory is justified because tranif is described as a "bidirectional pass switch", and the simulator needs to make that happen. Steve S gives a more complex model in the post I quoted. Ben Cohen also gives VHDL models for a resistor and a switch in his FAQs book (pages 160 and 178), which are conceptually similar to Steve S's; Ben puts in break-before-make switches at each end of the resistor. This is what Steve S says in: http://groups.google.co.uk/group/comp.lang.verilog/browse_frm/thread/282f1cb11335752d/fe2d15e1bfb5f697?hl=en&q=tranif1+sharp+group:comp.lang.verilog#fe2d15e1bfb5f697 > You have described a fundamental problem in implementing transmission gates. > A simulator can do this for a tran gate by splitting the connected nets into > separate parts. The tran gate passes through the value of the net before > the contribution from the tran gate. All other readers of the net get the > value of the net after the contribution of the tran gate. You can't do this > yourself, because you have no way to split the net without having to use > two explicit nets. The closest you can get to a behavioral version of > > tranif1 (A, B, control); > > would be > > module my_tran(A_in, A_out, B_in, B_out, control); > input A_in, B_in, control; > output A_out, B_out; > > assign A_out = A_in; > assign A_out = control ? B_in : 1'bz; > > assign B_out = B_in; > assign B_out = control ? A_in : 1'bz; > > endmodule > > and connect other outputs on A to A_in and other inputs on A to A_out. > If you have any other inouts on A or B, you need an even more complex > splitting of the nets. You just never realized how much work you were > making the simulator do for you when you used a tran. Note that 'control' is a reader of the net, and it gets "the value of the net after the contribution of the tran gate". Consider what happens when A_in and control are both 1, and A_in is then driven with Z: 1 - the first driver on A_out drives Z 2 - the value of control used in the second A_out driver is the *old* value of A_out (1), since A_out hasn't been resolved yet; the second driver therefore contributes B_in, or 1 3 - A_out resolves to 1, so control remains at 1 Basically, you just do whatever's necessary to get a transmission gate. I think this is pretty much what Steve W said here: > You see, the test is relying on a delta delay between an assignment > of Z to the pin and the tranif enable gates responding. So Icarus presumably worked before the recent tranif changes because the delta delay did the same job. -Evan |
|
From: Stephen W. <st...@ic...> - 2009-10-14 15:23:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Evan Lavelle wrote: > Stephen Williams wrote: > >> Every argument claiming that the tranif1.v test is "correct" has >> so far relied on some hysteresis or capacitance or memory in the >> switch for it to work. > > Mine doesn't. "tranif.v" is correct because it models a real > transmission gate, and the simulator is responsible for applying any > appropriate bodge to make this so. The LRM doesn't, I think, say how > this bodge works, but Steven Sharp *does* say in the post I quoted (see > below). There's a good chance that XL and NC both do what Steve S says. I *still* say that this replies (and models) an epsilon work of hysteresis, but I figured out how to get the vvp run time to do it cleanly, and without rewriting switch modeling support. So thanks all for the robust discussion on the issue. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFK1ez7rPt1Sc2b3ikRAl0lAJ4lW8yCvFUMXnLhPP1vThVkLFGdnQCfRegm xnE3kzGMYYmRYm7fJbZReWs= =Y5Ju -----END PGP SIGNATURE----- |
|
From: Evan L. <sa2...@cy...> - 2009-10-13 16:29:06
|
Stephen Williams wrote: > In fact, it's their "switch" nature that makes me think this test > is wrong. Ask yourself: > > - what happens when "pin" is driven 0? > - what happens when "pin" is driven 1? > - what happens when "pin" is driven X? > - what happens when "pin" is driven Z? > and > - Does it make sense for the answer to any of the above to differ > depending on what happened before it? > > You see, the test is relying on a delta delay between an assignment > of Z to the pin and the tranif enable gates responding. I haven't had a chance to think about this in detail, and I have to leave in 5 minutes, but I think this pseudo-delay is required for the operation of tranif (is this delay why VHDL can't do bidi gates?) Steven Sharp mentions this in http://groups.google.co.uk/group/comp.lang.verilog/browse_frm/thread/282f1cb11335752d/fe2d15e1bfb5f697?hl=en&q=tranif1+sharp+group:comp.lang.verilog#fe2d15e1bfb5f697: "The tran gate passes through the value of the net before the contribution from the tran gate". -Evan |
|
From: Martin W. <mai...@ma...> - 2009-10-13 16:32:58
|
Stephen Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin Whitaker wrote: >> Stephen Williams wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> I've been working on some fixes to the tranifX handling in Icarus >>> Verilog. I fixed a couple bugs, but now the tranif1.v test in the >>> ivtest suite no longer works. I've been puzzling over it, and I now >>> think that the test itself is not valid. The meat of the program >>> is here: >>> >>> wire pin; >>> pullup (weak1) (keep1); >>> pulldown (weak0) (keep0); >>> tranif1 (pin, keep1, pin); >>> tranif0 (pin, keep0, pin); > > [...] > >> What you are missing is that tranifs are true (bi-directional) switches. Once >> you turn one of them on, the keeper can drive "pin" through the switch, so >> will hold "pin" at its last value until something stronger drives "pin" to >> another value. > > I am *not* missing that tranifs are true bi-directional switches. > Believe me, I've gone through a lot of pain to make them work, so > I'm well aware. > > In fact, it's their "switch" nature that makes me think this test > is wrong. Ask yourself: > > - what happens when "pin" is driven 0? The node is driven to 0 with strength strong by the source driver. If the tranif1 is currently enabled, the node is being driven to 1 with strength weak1 by the pullup. This resolves to the node being driven to 0, and the tranif1 is turned off. > - what happens when "pin" is driven 1? The node is driven to 1 with strength strong by the source driver. If the tranif0 is currently enabled, the node is being driven to 0 with strength weak0 by the pulldown. This resolves to the node being driven to 1, and the tranif0 is turned off. > - what happens when "pin" is driven X? Not sure about this one. I'd have to consult the standard. I would expect it to resolve to the node being driven to X. > - what happens when "pin" is driven Z? The node is driven to Z with strength *HiZ0* or *HiZ1* by the source driver. If the tranif1 is currently enabled, the node is being driven to 1 with strength weak1 by the pullup. This resolves to the node being driven to 1, and the tranif1 remains turned on. Similarly, if the tranif0 is currently enabled, the node is being driven to 0 with strength weak0 by the pulldown. This resolves to the node being driven to 0, and the tranif0 remains turned on. > and > - Does it make sense for the answer to any of the above to differ > depending on what happened before it? > > You see, the test is relying on a delta delay between an assignment > of Z to the pin and the tranif enable gates responding. If you were > to solve the value of the island of switches based only on the drivers, > you should see this: > > tranif1 (pin=Z, week1, pin=Z); > tranif0 (pin=Z, week0, pin=Z); > > Tell me what that is without invoking delta delays or state machines > or hysteresis. > My argument is that assigning Z to the pin does not actually drive the node to Z - the keeper has a stronger drive strength. This also reflects what happens in real life - which is good! Martin |
|
From: Cary R. <cy...@ya...> - 2009-10-13 15:10:49
|
--- On Tue, 10/13/09, Stephen Williams <st...@ic...> wrote:
> But I don't believe this should simulate properly. The
> tranifs
> are not drivers themselves, so if the external pin driver
> is
> released, "pin" will go to Z, which will close *both* gates
> and
> pin will stay HiZ.
>
> Can people who have access try the attached program on the
> Big 3?
Since this is so poorly documented in the standard and every
other place we look, I think comparing is the only way to
know if we are on the right track. It may be a good idea to
test the other tran/tranif related tests to make sure they
match. The obvious functionality is not always what the big
3 have implemented.
Cary
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X