( ESNUG 358 Item 12 ) -------------------------------------------- [8/23/00]
Subject: ( ESNUG 357 #9 ) Not Wanting Instantiated MUXes In Clock Gating
> Thank you very much for your offer. What I tried to avoid is to
> instantiate a technology/vendor specific MUX in my RTL code in order
> to make the code technology independent and portable in future. The
> best solution I have found from solvit is to instantiate a GTECH MUX.
> I am still not very happy for this solution either.
>
> - London Jin
> Toshiba San Jose, CA
From: [ Hurricane Floyd ]
John - (anon pls)
We have had this problem before, though not quite for the same reasons. As
many of the commenters suggested, I think it is best to not allow synthesis
to muck with your clock trees, and therefore you should hand-instantiate
the MUXes, since it gives a controllable "handle" on the instance name if
you need to refer to it later. However, this is very difficult to balance
against the portability of the design to other cell libraries, which is
something we do a lot.
What we normally do is add one layer of abstraction (similar to GTECH) like
module mux2by1hi (in1,in2,sel,out);
/* hi-drive-strength 2-by-1 mux */
/* here instantiate your vendor's appropriate mux cell */
endmodule
Even better is to use the "//synopsys translate_off" and "`ifdef" suggested
by someone else to prevent simulation speed penalties.
In your top-level module, you would instantiate mux2by1hi where you are
currently using GTECH cells.
Then, you can put all the mux2by1hi.v files in different directories
organized by vendor, and just point to that one directory for simulation
or synthesis. We use this method for fan-out repeater structures that we
want to hand-instantiate, or for hand-crafted adder blocks, etc.
Trying to keep the design "only RTL" is not possible, that I know of, since
you have to do something with the IO cells, right? Therefore you will have
to link/compile with some vendor's cell library at simulation/synthesis time
anyway. Using GTECH is just Yet Another Library you will have to carry
around (particularly for simulation), so why not just use a vendor's
library? This is also probably better for formal verification.
- [ Hurricane Floyd ]
---- ---- ---- ---- ---- ---- ----
> My design is a multiple clock domain design. In scan mode, however, there
> is only one clock: master_clock from chip pin. In order to balance the
> clocks, I need to MUX all clocks including the master_clock.
>
> wire scan_clk = scan_mode ? master_clk : master_clk;
>
> Design Compiler recognizes that this is feedthrough logic, and thus no
> MUXing logic is generated at all. I talked to Synopsys tech support, and
> was told that there was no way to generate MUXing logic with the above
> code. I seeks for designers' help.
>
> - London Jin
> Toshiba San Jose, CA
From: [ A Synopsys AE ]
London, this will definitely be a problem with the code you present. Since
a synthesizer's job in life is to optimize away logic, it's hard to
convince it otherwise. :)
The way that comes to mind is to write your block so that the synthesizer
*doesn't* know it's the same clock:
module clockgen (scan_mode, clock1_in, clock1_test, clock2_in, ...)
...
clock1_out = scan_mode ? clock1_in : clock1_test;
clock2_out = scan_mode ? clock2_in : clock2_test;
clock3_out = scan_mode ? clock3_in : clock3_test;
This will create three muxes when you synthesize. Now you can simply
control which clocks are which by how you connect them at the next level up.
- [ A Synopsys AE ]
( ESNUG 358 Networking Section ) --------------------------------- [8/23/00]
Sunnyvale, CA -- BrightLink.com seeks engineers w/ Vera, Verilog, Perl exp.
for verification; DC & PrimeTime exp. for design. "sherria@brightlink.com"
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
