> From: "Matthew Wishek" <matthew_wishek@smtp.ESL.COM>
> Subject: ESNUG Archive Question
>
> John, I received the back posts from Kareen Haddock, but there are no
> dates on the posts. Just to get a time reference, what date was post 40
> put out, and with what frequency were posts put out?
>
> Matthew Wishek
If memory serves me ESNUG 40 came out mid June of '92 and the frequency
of posts mathematically works out to ~1.8 posts per week. (In reality,
it varied from 1 to 4 posts a week depending on the topics being discussed.)
Anyway, your point is well taken and I'm now incorporating the date in
each item separator line.
- John Cooley
the ESNUG guy
( ESNUG 129 #1 ) -------------------------------------------------- [5/93]
From: sylvie@ncrcol.columbiasc.NCR.COM (Sylvie.Haddad)
Subject: re: (ESNUG Post 128 #1) "Using Qbar on DFFs"
John,
It looks like I have emailed you the wrong code to answer ESNUG 128 #1
(Using Qbar on DFFs). I apologize for the confusion. The difference
is that a 'tmp' signal is set inside the process statement and the
output 'z' is set to not tmp as a concurrent assignment.
The correct VHDL code that should do this is:
entity example is
port ( clk,a : in bit;
z : out bit);
end example;
architecture my_arch of glock is
signal tmp : bit;
begin
process (clk)
begin
if (clk'event and clk = '1') then
tmp <= a;
end if;
end process;
z <= not tmp;
end my_arch;
- Sylvie Feghali Haddad
NCR, Midrange Computer Products Division
West Columbia, South Carolina
( ESNUG 129 #2 ) -------------------------------------------------- [5/93]
From: uunet!uranus!morpheus!lanette (Lanette Mccuistion)
Subject: (ESNUG Post127 #4) "Q_Bar pins on DFFs"
Well, I finally found one of these I may be able to answer!
I have been having the same problems with the q-bar flip-flop outputs not
being used. The solution I have found is in how the behavioral code is
written. You can not use negation in the flip-flop inference. For
Example:
always @(posedge ph1)
out1 = ~in1;
This code will use only the q outputs with inverters. Instead use this:
always @(posedge ph1)
out1x = in1;
wire out1 = ~out1x;
An extra compile with area minimization at the end also seemed to help.
GOOD LUCK!
- Lanette McCuistion
Ford Microelectronics
( ESNUG 129 #3 ) -------------------------------------------------- [5/93]
Subject: ( ESNUG 128 #3) "Does a Verilog Execute Path Checker Exist?"
> I have a question concerning Verilog only. Do you know if there is any
> product or s/w in the public domain that can help in RTL/behavioral model
> simulation and tell you if all the lines are executed and all possible
> branches of 'if' and 'case' statements are exausted during a simulation
> with a certain stimulus ?
-- -- -- -- -- --
From: Mark Sprague <msprague@sequoia.sequoia.com>
We wrote a few of PLI routines, and some shell scripts to get most of
this information. The basic idea was to add a PLI call after each 'begin'
statement that would increment a counter specific to that statement. This
information was then sent to a file, and was later postprocessed into the
source code.
The complete flow was:
1) run a script that would replace each `begin' with `begin
$perftrace(number)' where number is an integer unique to this begin
statement.
2) start verilog, and call a pli routine to initialize the counter array.
3) run the test.
4) before exiting verilog, call another pli routine to dump the counter
array to a file.
5) repeat steps 2-4 for all tests, writing the results to seperate files.
6) run a script that totals all of the saved results, and then adds
comments into the source file with the total number of times that begin
statement was executed.
7) scan the resulting source file for `small' numbers. These statements
have either not been executed, or were exercised only during
initialization.
This method gave us the information we needed to extend our regression
suite. The usefullness of the results varied from one designer to another,
since some designers tend to have many small blocks, and surround `then'
and `else' clauses with begin statements even if they aren't needed, while
other designers tend to have a few very large blocks.
- Mark Sprague
Sequoia Systems, Inc.
-- -- -- -- -- --
From: dbennett@canstar.alcatel.ca (Dwayne Bennett)
The Cadence verilog simulator can provide a disassembly of verilog
code with 'line counts' representing the number of times that particular line
of code was encountered during simulation. The command is $listcounts; and
the following is an example of the output it produces...
1: 248 always
107: 248 @(posedge ck33)
106: 249 begin :create_wrpulse
106: 250 if(reset)
3: 251 regwrq <= #(0) 1'b0;
0: else
103: 253 begin
103: 254 regwrq <= #(0) regwr;
103: 256 if(strobe & smaq[5] & smaq[0])
7: 256 begin
7: 257 regwr <= #(0) 1'b1;
7: 258 regwr_dat <= #(0) ibus[31:0];
7: 259 end
0: else
96: 261 regwr <= #(0) 1'b0;
103: 263 if(fcce & sma[5] & sma[0])
7: 264 waddr <= #(0) sma[4:1];
103: 266 end
106: 267 end
| |__ source line number
|__ # times executed during simulation.
- Dwayne Bennett, CANSTAR, Toronto, Canada
( ESNUG 129 #4 ) -------------------------------------------------- [5/93]
From: mbendak@sdcc3.UCSD.EDU (Michael Bendak)
Subject: Possible db2sge Bug
John,
In converting a schematic from design analyzer db format into sge format
using db2sge I have found that the converted schematic was not fully wired.
That is the wires were not connected to the pins of the components thus
making it necessary to manually complete the schematic. Has anyone run
into this problem? Is there a way to avoid it or is this a bug in the
software?
Thanks,
- Mike Bendak
|
|
