I should have know when I mentioned that ESNUG is coming from a sheep farm
in Massachusetts, I was going to be swamped with sheep jokes! Well, you
know what I have to say to this: "baaaaa!" Happy Friday! Oh, yea, the
number for info on the OVI conference is: (303) 530-4562.
- John Cooley
ESNUG Moderator
( Post 111 Item 1 ) ---------------------------------------------------------
From: martin@cactus.org (Brad Martin)
Subject: Transparent Latches & Multiphased Clocked State Machines
I am very interested on following the progress on using Synopsys to
synthesize logic with enbedded transparent latches in multi-phase clocked
state machines. We were attempting to do this a while ago and while our
communications with Synopsys indicated that their support was coming, we
haven't been able to track exactly what people have been able to accomplish
or the problems that continue to surface on the issue of sharing time
between adjacent clock phases through transparent latches.
Synopsys doesn't talk to small-fry design houses as high priority any
more -- yet we can't commit to using their software until we can hear
*independent* discussion of their software used in this capacity.
Thanks
- Brad Martin,
North Shore Circuit Design L.L.P.
( Post 111 Item 2 ) ---------------------------------------------------------
From: [ A FPGA Compiler User ]
Subject: FPGA compiler problem
John, please do not use my name/company.
We are trying to use the FPGA compiler with Xilinx, and are stuck
because the xnf created contains FMAP declarations which are not
completely specified (not all inputs used). The problem occurs when
you run the Xilinx place and route tools (ppr 1.3), and it errors out
due to these FMAP declarations.
The suggested work around is to generate the xnf without FMAP mapping,
but this pretty much defeats the purpose of using the FPGA Compiler,
because you are then at the mercy of the mapper from Xilinx, you have
to build a separate constraint file for the Xilinx tools and you lose
alot of the top-down design flow. The fix is going to be in the next
release of the ppr, but that isn't due until October.
Has anyone else run into this problem? Have you been able to get any
committment from Xilinx to send out a ppr patch? Locally, we find that
Xilinx is not at supportive of the FPGA Compiler, and instead puts
us under repeated pressure to use schematic capture, BLOX, and hand
instantiation of macros to solve any questions. Xilinx indicates the
only reason to use the FPGA Compiler is to "reduce the design cycle, ie
go from Verilog to XNF from Synopsys", not at all to produce good or
fast FPGAs.
( Post 111 Item 3 ) ---------------------------------------------------------
From: Trevor <trevor@ncd.com>
Subject: Math library
Does any one have, or know where I can get, a math library (doesn't have to be
synthesizable) which inlcudes things like sin, cos, x**y etc.
-- Trevor
( Post 111 Item 4 ) ---------------------------------------------------------
From scottj@talon.ftcollins.NCR.COM ( Scott Johnson )
Subject: Verilog Test Compiler Controlling Bi-Directs Question
I am looking for information relating to how to control bi-directonal
signals in Verilog. In the past, we have always successfully done
something like the following:
module bidir_model (sig_in, sig_io, sig_out);
input sig_in;
inout sig_io;
output sig_out;
....
endmodule
Then in our test fixture we would do:
module test;
reg sig_in, sig_io, sig_io_en;
wire sig_out, sig_io_in;
bidir_model i0 (.sig_in(sig_in), .sig_out(sig_out), .sig_io(sig_io_in));
bufif1 (sig_io_in, sig_io, sig_io_en);
initial
begin
sig_io_en = 1'b0; // This disables the tristate buffer and
// allows the bidir_model to drive out
...
sig_io_en = 1'b1; // This enables the tristate buffer and
// allows us to drive into the bidir_model
sig_io = <some_data>; // drive some data into bidir_model
#1000
...
end
This works just fine. The signal we would monitor as the "real" signal
would be the sig_io_in signal.
However, when using the Test Compiler from Synopsys, it controls them by
doing something like:
module test;
reg sig_in;
wire sig_out, sig_io, _bi;
assign {sig_io} = _bi;
bidir_model i0 (.sig_in(sig_in), .sig_out(sig_out), .sig_io(sig_io));
initial
begin
#0
release _bi; // release it, and don't drive it
...
force _bi = <some_data>; // This forces data on to the bus
...
release _bi; // release the bus again
...
end
endmodule
Now, this looks like when the bidir_model is ready to drive, the
release statement should release the bus and let it do that. However,
what really happens is that the "sig_io" signal actually goes to a
strong unknown. This is not what the Synopsys tool is assuming,
therefore simulations fail.
Can anyone tell me if there is anything wrong with the above
reasoning? I have contacted both Cadence and Synopsys regarding this
with no response yet, though I must admit it hasn't been long. Please
post to ESNUG if you have ideas or solutions. Thanks!
Scott Johnson
NCR, Ft. Collins, Colorado
|
|
