Moncler, per decenni è stata l'arrampicata e sci in Europa e in America che sono i marchi più popolari all'aperto. Dal 1952 in poi, hanno cominciato qualità costruttiva è vestito buono e funzionale, in una collaborazione con Moncler, VISVIM la gente ragione principale di questo marchio secolo villaggio europee e americane di comprensione dello stile di produzione, e iniziò a progettare un nuovo co-brand Moncler V, che in questa stagione nel villaggio di beni selezionati su una serie di classici incisi passato Moncler vendere un singolo prodotto da fare. Gamma completa di merce sarà presto ufficialmente il debuttomoncler uomo
moncler vendita

Hi,

Even though the Verilog code has always@(posedge) statements, it is getting synthesized into muxes and not latches.

How to make sure they synthesize into latches.

Hi,

I was also unable to find the *.rul files. They were linked to a non-existent location in the NCSU CDK 1.6 beta.

The *.rul files are all in the 'techfiles' folder. You have to link the files in all the other library directories to these files (using the ln-s command).

Hi,

I contacted cadence with the problem.

Diva licenses are not available in university packages anymore for Cadence Virtuoso version 6.1.4 and later.

Hi,

I am getting the following error when I attempt a DRC from Cadence Virtuoso 6.1.4:

*WARNING* No DRC (Assura_DV_design_rule_checker) or DRC (312) license is available
*WARNING* Verification program terminated.

Would anyone know the way around this one?

Is there some way to either take advantage of DC topological mode (requires Milkyway database) or at least use a reasonable wireload model? I can't tell that there is support for either one in the OSU v2.7 flow.

thanks

Mark

I think I have been able to resolve the issue for now.

The steps to do the same are following:

Create a separate folder say convert:

> mkdir convert
> cd convert
> mkdir cdb
> cd cdb
> vi cds.lib

Copy the contents of your previous cds.lib. This cds.lib must also have paths to the NCSU Library that the vtvt standard cell library requires.

> cd .. (Come back to the convert directory)

Now in CIW->Tools->Conversion Tool Box->CDB TO Open Access ...

It will ask for a cds.lib, give the path of the cds.lib present in directory cdb.

The contents to convert are the vt standard cell libraries as well the NCSU library that these refer to.

If the above steps are followed the error in the previous post will not figure up.

Hi,

I am trying to use the Standard Cell Libraries provided by Virginia Tech for PnR, which require the NCSU kit.

I am using the NCSU 1.6 beta version which works with the Cadence IC 1.6 version, however the VT Cell Libraries have been designed for the older version and have to be converted using cdb2oa.

I am getting the following error when I try to convert the Cell Library files:

*******
ERROR (CDBOA-500) : The translation was stopped because technology library "NCSU_TechLib_tsmc03d" referenced by library "../vtvt_tsmc250" does not exist. Ensure that any technology libraries referenced by the current library are defined in the cds.lib file and available in OpenAccess at the time they are referred.

*******

Now, the vtvt_tsmc250 has to be attached to the NCSU_TechLib_tsmc03d, but since it is in the cdb format even that is giving an error.

Please provide inputs.

Hi,

I am using Synopsys DC to insert a scan chain into a circuit that I want to test in Tetramax. I was able to have Verilog code written to implement the circuit with a scan chain, but do not have any libraries with scan cell definitions so I cannot run it through Tetramax.

Where can I download a library with scan cells? And once I get the library how do I utilize it so that I can test my circuit in Tetramax?

Thanks!

Hi,

I am trying to use the NCSU CDK 1.6 beta with the VTVT kit for digital design.


The VTVT kit asks to copy a divaDRC.rul file in the NCSU kit.
but when I checked in NCSU kit library files all the .rul files such as divaDRC.rul files are marked in red and seem to be corrupted, they cannot be replaced.

when I run the following command
> ll *.rul
lrwxrwxrwx 1 3339 108 49 Jul 9 16:01 divaDRC.rul -> /local/home/wdavis/NCSU_CDK//techfile/divaDRC.rul


What should I do about this?

somebody please tell me this! has no one gone through this experience?

That depends. The NCSU CDK is a PDK based on the old lambda rules developed by Carver Mead and Lin Conway in the late 70's. These rules were accepted by many foundries, but fell out of fashion after the 180nm node. So, the answer is yes, but restricted to the 180nm node and larger and only for foundries that accept them. MOSIS still accepts GDSII designed with these rules for the 180nm node and larger technologies.

How can I get the PDK of a FAB like e.g., SILTERRA or CSMC? who is going to provide me the official NDA agreement copy and where would I send it? I emailed at the adress at Silterra's website but didn't receive a reply. I represent a University IC Design Lab.

Is NCSU CDK a substitute for the foundry pdks of FABs. Could a GDS II designed using NCSU CDK be sent directly to a FAB for production?

Hi Adam,

I see tat u started this post some time ago. If you have managed to get some scripts, please share it since am looking out for the same now.

Thank U

Regards,
Rat

Hi all,

I downloaded NCSU CDK 1.6.0 yesterday, because I'm looking for a solution to import JPEGs into cadence virtuoso for the use in a layout. But I couldn't find the menu item IMPORT JPEG. Isn't it already included?

Thanks,
stimm

Hello everyone. Nice forum. Glad to be a part of this.

I am having problem while simulating using ADEL simulator. I cannot find the model library for Vpulse. Help me with it

Hey Bro.... Use 9.1 sdf generation .

ok so I've been searching for few days and came across milkyway flow (attached here -- milkyway user guide is of 5MB sorry look at http://www.cadfamily.com/download/EDA/NanoSim/mwug.pdf )

I've been reading about getting milkyway database from lef (library exchange format) which is provided by osu libraries.

As explained in tutorial with this post read_lef in Milkyway (tool) provide me with required milkyway folders (FRAM and CEL) however I'm still confused about getting .mw

I would like to have some opinions

Thanks

hmm,
R u sure about looking at critical path delay in encounter (floorplan / place and route tool) and not in rc gui (synthesis tool) ?

I've never traced critical path in layout (encounter) but in gate level schematic (rc UI) its quite easy

Hi everyone,
I'm working on ic compiler to get place and route done for one of my designs.

Libraries I'm preferring are OSU libraries for synthesis, gate level simulation and place and route.

Now the problem occurs when I try to refer milkyway database (either I didn't look properly or there is not one).

So I saw I can create milkyway reference library with ASTRO (I'm interested if there is any other way as well)

Can someone refer me a way to create milkyway library (unless I'm not understanding it properly).

Thanks for all your opinions :)

Hi!
I've just visited this forum. Happy to get acquainted with you. Thanks!



__________________
Watch Battle: Los Angeles Online For Free

Hello everyone,

Well this might be a silly question, I want to measure the experimental THD of an amplifier, I measure it directly from the signal source and get a THD of 2%, when I measure it with my circuit connected I get a 2.3% error, so can I say my circuit has a THD of 0.3%?

Thanks in advance,

Ivan

HEY GUYS,
I AM TRYING TO FIND OUT CRITICAL PATH DELAY FROM ENCOUNTER. I AM NOT SURE HOW TO FIND IT DIRECTLY FROM ENCOUNTER. PLEASE HELP ME OUT. YOUR HELP WILL BE GREATLY APPRECIATED

We are using OSU cell library version 2.7 in a VHDL to GDSII flow. We are finding that the delays we observe in a pre-layout Modelsim simulation of the design based on the cell library are significantly longer than the delays predicted by the static timing analysis done in Design Compiler.

In a gate level simulation of a state machine controlled datapath the delay from register file output, through an ALU doing an addition operation, and back to the register file was appoximately 4ns. The DC reported a critical path, also from reg file -> ALU -> reg file of approximately 3.6ns.

If anything, I would have expected the Modelsim delays to be less than the DC static timing results except if the simulation happens to hit the exact sensitization conditions for the worst case path. Has anyone run into this?

Note: we checked the time resolution in Modelsim & saw roughly the same results for 1ps, 10ps, and 100ps resolution.

Mark

If we use the "cds_thru" component from the "basic" library, or perhaps a patchcord from the Create -> Patchcord menu (at least in IC61x that's where it is) helped resolve the problem.

Hi,

I am building a digital system where i have to pass a bit of input-bus directly to the output bus, but cadence schematic composer gives an error when i try to do that.

Error: Shorted terminals - memTerms "IN<7>" & "A<3>" thru signal "IN<7>".
Error: Shorted terminals - memTerms "A<3>" & "IN<7>" thru signal "IN<7>".

Is there a way to resolve this error .

Thanks in Advance.

The following method of invoking the tool resolved my issue.

encounter -64 -simplefont

Hi ,

when i try to use encounter 8.1 version to load my design, I am getting the following error.

system details:

My system is linux9.0, the kernel version is 2.4.20-8, my encounter version is 8.1

logdump:

<CMD> fit
<CMD> setDrawView fplan
Encounter terminated by internal (SEGV) error/signal...
*** Stack trace:
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(syStackTrace+0x132)[0x5deed63]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter[0x11a65df]
/lib64/libpthread.so.0[0x352800eb10]
/usr/lib64/libX11.so.6(XTextExtents+0xf)[0x35290442cf]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(_Z14winTextExtentsP7winsWinP9winsLayerPc PiS4_S4_+0x90)[0x5062f3e]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(_Z16winDrawTextInBoxP7winsWinP9winsLayer PcP6sysBoxici+0x18[0x509732a]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter[0x507b6a9]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter[0x507c21b]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter[0x5078f17]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(_Z20winViewListIterationP7winsWini+0x10[0x50662ec]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(_Z13winDbDrawViewP7winsWin+0x97)[0x50865a7]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(_Z11winDrawViewP7winsWin+0x19)[0x509f3f9]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(_Z10winDisplayP7winsWin+0x8c)[0x5061bcc]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter[0x5064310]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(TclServiceIdle+0x4b)[0x6e236db]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(Tcl_DoOneEvent+0x14c)[0x6e1609c]
/usr/local/Cadence/SOC81/tools/lib/64bit/libtq.so(_ZN17TqEventDispatcher13processEventsE6QF lagsIN10QEventLoop17ProcessEventsFlagEE+0xc0)[0x2ac301d78d66]
/usr/local/Cadence/SOC81/tools/Qt/64bit/lib/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFl agsINS_17ProcessEventsFlagEE+0x2[0x2ac300dbdf18]
/usr/local/Cadence/SOC81/tools/Qt/64bit/lib/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17P rocessEventsFlagEE+0x69)[0x2ac300dbe029]
/usr/local/Cadence/SOC81/tools/Qt/64bit/lib/libQtCore.so.4(_ZN16QCoreApplication4execEv+0xb0)[0x2ac300dbfe90]
/usr/local/Cadence/SOC81/tools/lib/64bit/libtq.so(_ZN13TqApplication4execEv+0x2c[0x2ac301d7b31a]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(_Z7fe_mainiPPc+0x2ea)[0x118afd2]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(main+0x72)[0x118b088]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x352741d994]
/usr/local/Cadence/SOC81/tools/fe/bin/64bit/encounter(_ZN11QFileDialog6acceptEv+0x512)[0x118a7aa]
========================================
pstack
========================================
Thread 4 (Thread 0x41a57940 (LWP 14789)):
#0 0x000000352800e1c1 in nanosleep () from /lib64/libpthread.so.0
#1 0x00000000019e8ccb in rdaiLicRecheck(void*) ()
#2 0x000000352800673d in start_thread () from /lib64/libpthread.so.0
#3 0x00000035274d3f6d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x42458940 (LWP 14790)):
#0 0x00000035274cd212 in select () from /lib64/libc.so.6
#1 0x0000000006e33e4d in NotifierThreadProc ()
#2 0x000000352800673d in start_thread () from /lib64/libpthread.so.0
#3 0x00000035274d3f6d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x42e59940 (LWP 14791)):
#0 0x000000352800e838 in do_sigwait () from /lib64/libpthread.so.0
#1 0x000000352800e8dd in sigwait () from /lib64/libpthread.so.0
#2 0x00000000011a6a1d in ctrlCHandle(void*) ()
#3 0x000000352800673d in start_thread () from /lib64/libpthread.so.0
#4 0x00000035274d3f6d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x2ac3025a3f70 (LWP 14739)):
#0 0x0000003527499fff in waitpid () from /lib64/libc.so.6
#1 0x000000352743c331 in do_system () from /lib64/libc.so.6
#2 0x000000352743c687 in system () from /lib64/libc.so.6
#3 0x0000000005deedc0 in syStackTrace ()
#4 0x00000000011a65df in rdaiErrorHandler(int, siginfo*, void*) ()
#5 <signal handler called>
#6 0x00000035290442cf in XTextExtents () from /usr/lib64/libX11.so.6
#7 0x0000000005062f3e in winTextExtents(winsWin*, winsLayer*, char*, int*, int*, int*) ()
#8 0x000000000509732a in winDrawTextInBox(winsWin*, winsLayer*, char*, sysBox*, int, char, int) ()
#9 0x000000000507b6a9 in winiDrawHInstText(winsWin*, dbsHInst*, sysBox*) ()
#10 0x000000000507c21b in winiHInstDraw(winsWin*, dbsObject*) ()
#11 0x0000000005078f17 in winiHInstIter(winsWin*, void (*)(winsWin*, dbsObject*)) ()
#12 0x00000000050662ec in winViewListIteration(winsWin*, int) ()
#13 0x00000000050865a7 in winDbDrawView(winsWin*) ()
#14 0x000000000509f3f9 in winDrawView(winsWin*) ()
#15 0x0000000005061bcc in winDisplay(winsWin*) ()
#16 0x0000000005064310 in winiTkDisplay(void*) ()
#17 0x0000000006e236db in TclServiceIdle ()
#18 0x0000000006e1609c in Tcl_DoOneEvent ()
#19 0x00002ac301d78d66 in TqEventDispatcher::processEvents(QFlags<QEventLoop ::ProcessEventsFlag>) () from /usr/local/Cadence/SOC81/tools/lib/64bit/libtq.so
#20 0x00002ac300dbdf18 in QEventLoop::processEvents(QFlags<QEventLoop::Proce ssEventsFlag>) () from /usr/local/Cadence/SOC81/tools/Qt/64bit/lib/libQtCore.so.4
#21 0x00002ac300dbe029 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsF lag>) () from /usr/local/Cadence/SOC81/tools/Qt/64bit/lib/libQtCore.so.4
#22 0x00002ac300dbfe90 in QCoreApplication::exec() () from /usr/local/Cadence/SOC81/tools/Qt/64bit/lib/libQtCore.so.4
#23 0x00002ac301d7b31a in TqApplication::exec() () from /usr/local/Cadence/SOC81/tools/lib/64bit/libtq.so
#24 0x000000000118afd2 in fe_main(int, char**) ()
#25 0x000000000118b088 in main ()
========================================
gdb
========================================
Using: gdb
[Thread debugging using libthread_db enabled]
[New Thread 0x42e59940 (LWP 14791)]
[New Thread 0x42458940 (LWP 14790)]
[New Thread 0x41a57940 (LWP 14789)]
0x0000003527499fff in waitpid () from /lib64/libc.so.6

Thread 4 (Thread 0x41a57940 (LWP 14789)):
#0 0x000000352800e1c1 in nanosleep () from /lib64/libpthread.so.0
#1 0x00000000019e8ccb in rdaiLicRecheck(void*) ()
#2 0xfffffffe7fffffff in ?? ()
#3 0xffffffffffffffff in ?? ()
#4 0xffffffffffffffff in ?? ()
#5 0xffffffffffffffff in ?? ()
#6 0xffffffffffffffff in ?? ()
#7 0xffffffffffffffff in ?? ()
#8 0xffffffffffffffff in ?? ()
#9 0xffffffffffffffff in ?? ()
#10 0xffffffffffffffff in ?? ()
#11 0xffffffffffffffff in ?? ()
#12 0xffffffffffffffff in ?? ()
#13 0xffffffffffffffff in ?? ()
#14 0xffffffffffffffff in ?? ()
#15 0xffffffffffffffff in ?? ()
#16 0xffffffffffffffff in ?? ()
#17 0xffffffffffffffff in ?? ()
#18 0x0000000000000086 in ?? ()
#19 0x0000000000000000 in ?? ()

Thread 3 (Thread 0x42458940 (LWP 14790)):
#0 0x00000035274cd212 in select () from /lib64/libc.so.6
#1 0x0000000006e33e4d in NotifierThreadProc ()
#2 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x42e59940 (LWP 14791)):
#0 0x000000352800e838 in do_sigwait () from /lib64/libpthread.so.0
#1 0x000000352800e8dd in sigwait () from /lib64/libpthread.so.0
#2 0x00000000011a6a1d in ctrlCHandle(void*) ()
#3 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x2ac3025a3f70 (LWP 14739)):
#0 0x0000003527499fff in waitpid () from /lib64/libc.so.6
#1 0x000000352743c331 in do_system () from /lib64/libc.so.6
#2 0x000000352743c687 in system () from /lib64/libc.so.6
#3 0x0000000005deedc0 in syStackTrace ()
#4 0x0000000005deed63 in syStackTrace ()
#5 0x00000000011a65df in rdaiErrorHandler(int, siginfo*, void*) ()
#6 <signal handler called>
#7 0x000000000118a7aa in _start ()
A debugging session is active.

Inferior 1 [process 14739] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]

*** INTERRUPTED *** [signal 1]
14739: No such process