Designer’s Guide Community

cr

New Member

Offline

Posts: 5

Digital gates in Verilog-A
Oct 12^th, 2006, 6:57pm

Hi All,

I'm currently tasked with getting a few control gates working in our Verilog-A system simulations and unfortunately AMS is not currently an option. I have a strong Verilog-D background, have read most of Ken's book and have looked at a lot of the online models and the ones supplied by Cadence. What I am having a problem with is understanding why the Cadence models are written the way they are. The following pattern is used to detect the input transitions:
logic_input = V(vlogic_in) > vthreshold; @(cross(V(vlogic_in) � vthreshold, 1)) logic_input = 1; @(cross(V(vlogic_in) � vthreshold, -1)) logic_input = 0;
What I don't understand is why the �logic_input� (an integer) is being set by both the conditional and the event? I do understand that you want to use some form of cross to more accurately detect transitions.

Any help in expanding my understanding is most appreciated!

C.

Back to top

« Last Edit: Oct 13^th, 2006, 9:03am by cr »

IP Logged

Ken Kundert Global Moderator Offline Posts: 2384 Silicon Valley	Re: Digital gates in Verilog-A Reply #1 - Oct 13^th, 2006, 12:00am The first line is needed to assure the logic is implemented and works proberly for time-domain analyses (such as DC) where the @cross() statements are not active. But I'm with you, I see no purpose behind again assiging them in the cross statements. -Ken
Back to top	IP Logged

cr

New Member

Offline

Posts: 5

Re: Digital gates in Verilog-A
Reply #2 - Oct 13^th, 2006, 9:05am

Thanks Ken!

I noticed I miss typed the last line. It has now been fix. Dang cut and paste. My plan for implementing this was:
logic_input = V(vlogic_in) > vthreshold; @(cross(V(vlogic_in) � vthreshold, 0)) ;
Since you only need to have one cross statement on whatever watch list is used by the simulator and it isn't looking for a particular type of transition I'm assuming it will create the crossing event faster and if nothing else it's fewer lines/more readable.

C.

Back to top

IP Logged

Ken Kundert Global Moderator Offline Posts: 2384 Silicon Valley	Re: Digital gates in Verilog-A Reply #3 - Oct 13^th, 2006, 11:58am Look good. Alternatively you could write it using above() rather than cross(). -Ken
Back to top	IP Logged

cr

New Member

Offline

Posts: 5

Re: Digital gates in Verilog-A
Reply #4 - Oct 13^th, 2006, 9:17pm

Good suggestion! I looked at both and I think above() reads a bit better for combinational logic. To me it's slightly easier to see what is actually going on (fewer parallel paths). Of course I'm still using some crosses for the FF and latch models. Also, while I realize it's easy to fake a below() function, having one sure would make active low inputs easier to spot.

C.

Back to top

IP Logged

jbdavid Community Fellow Offline Posts: 378 Silicon Valley	Re: Digital gates in Verilog-A Reply #5 - Oct 14^th, 2006, 2:11am 'above' wasn't an option when those were written.. but there has been little maintenance on those models over the years.. ... if it ain't broke.. Jonathan
Back to top	jbdavid Mixed Signal Design Verification IP Logged

cr

New Member

Offline

Posts: 5

Re: Digital gates in Verilog-A
Reply #6 - Oct 15^th, 2006, 8:45pm

Understood, and I agree if they are working fine there is really no need to mess with them. Though a couple of examples using more modern constructs would always be helpful. My question was simply to verify there was not a defect in my mental model of how things work since the two assignments appeared to be redundant (confirmed by Ken). Keep in mind my first look at Verilog-A was early last week. My past experience is helping me be a quick study, but I still have a ways to go before I have mastered both the syntax and more importantly the semantics.

C.

Back to top

IP Logged

cr

New Member

Offline

Posts: 5

Re: Digital gates in Verilog-A
Reply #7 - Oct 18^th, 2006, 10:20am

Here's a short update. After actually trying after() and reading a bit more, it turned out to be almost useless for what I was trying to do. The problem is that while it does provide the level sensitivity that is need for the initial simulation step it is only sensitive to the rising edge. That killed it for any combinational logic. I was initially using it on the asynchronous inputs of latches and flip-flops, but I removed those yesterday as I consolidated all the initialization code into the inital_step block. To me this makes it easier to understand how the model variables are being initialized since all the initialization code is in one place.

For those that are curious I did use the pattern in my second post for all the combinational logic.

Thanks for the comments.

C.

Back to top

IP Logged