Re: Re: [OPENRAM] Fw: Re: Re: Re: openram consultation

[戴悦]

After debuggning, I found that the unsuccessful reading of gdsfile is caused by incorrect format of pin in layout. GdsMill requires the pin to be an regular rectangular without unfilled corner. 

However, I met another problem. When I tried to generate a write_driver_array in smic40, it can generate the gdsfile successfully in temp file, but the gdsfile couldn't be open with calibredrv. Of course, its drc check failed.

Have you ever met the same problem? I reckon that maybe it was caused by bug of gdsmill?

-----原始邮件-----
发件人:"Matthew Guthaus" <m...@ucsc.edu>
发送时间:2018-08-29 22:16:46 (星期三)
收件人: Openram <ope...@soe.ucsc.edu>
抄送: 31401...@zju.edu.cn
主题: Re: [OPENRAM] Fw: Re: Re: Re: openram consultation

For details about GDS, you can look at:

http://www.artwork.com/gdsii/gdsii/index.htm

Zoom is the "magnification" parameter for SREFs. It is only used on text labels in openram.

On Wed, Aug 29, 2018 at 6:27 AM Stine, James <james...@okstate.edu> wrote:

Again, I would recommend, as we pointed out, check out SCN3ME.  I know these EDA tools are tough, but its best looking at an example and being tedious about it.  Keep us updated.

On Aug 29, 2018, at 8:25 AM, 戴悦 <31401...@zju.edu.cn> wrote:

well, every gds file do have a boundary. Still, it cannot read information from gds file...... 

Also， I wonder what does parameter｛zoom｝ mean ?

-----原始邮件-----
发件人:"Stine, James" <james...@okstate.edu>
发送时间:2018-08-29 00:19:51 (星期三)
收件人: "戴悦" <31401...@zju.edu.cn>
抄送: "<ope...@soe.ucsc.edu>" <ope...@soe.ucsc.edu>
主题: Re: [OPENRAM] Fw: Re: Re: Re: openram consultation

You have to be extra sure the gds layers has a boundary - try using a gds viewer.  There are many free ones out there.

On Aug 28, 2018, at 11:15 AM, 戴悦 <31401...@zju.edu.cn> wrote:

Well, I define layer just as the example.

layer[boundary]=127 in smic40. I think the problem is not caused by this...

-----原始邮件-----
发件人:"Stine, James" <james...@okstate.edu>
发送时间:2018-08-28 23:53:00 (星期二)
收件人: "戴悦" <31401...@zju.edu.cn>
抄送: "Matt Guthaus" <m...@ucsc.edu>
主题: Fwd: [OPENRAM] Fw: Re: Re: Re: openram consultation

Getting the boundary working is key in understanding how to piece together anything (including pcells).  Dr. Guthaus’ suggestion on examining SCN3ME in a wise one.

Begin forwarded message:

From: Matthew Guthaus <m...@ucsc.edu>

Subject: Re: [OPENRAM] Fw: Re: Re: Re: openram consultation

Date: August 28, 2018 at 10:37:32 AM CDT

To: Openram <ope...@soe.ucsc.edu>

Reply-To: ope...@soe.ucsc.edu

The required name in our tech file is "boundary" like the examples. Please follow the SCN3ME as an example.

On Tue, Aug 28, 2018 at 8:34 AM 戴悦 <31401...@zju.edu.cn> wrote:

-----原始邮件-----
发件人:"戴悦" <31401...@zju.edu.cn>
发送时间:2018-08-28 23:32:07 (星期二)
收件人: "matthew guthaus" <m...@ucsc.edu>
抄送: 
主题: Re: Re: Re: openram consultation

Dear Prof.Guthaus::

I have changd the layers in tech.py according to the layer map of smic40 as shown in the picture. The difference between cell_6t and other modules is the number of layer[boundary]. The layer name of cell_6t is "border", 127.0, while the layer name of other modules is "prboundary", 127.1.

In tech.py, I set layer[boundary] as 127. Well, does it care? 

-----原始邮件-----
发件人:"Matthew Guthaus" <m...@ucsc.edu>
发送时间:2018-08-28 23:18:32 (星期二)
收件人: "戴悦" <31401...@zju.edu.cn>
抄送: 
主题: Re: Re: openram consultation

What layers does the GDS file is? It is likely a different layer map... This is foundry specific 

---
Matthew Guthaus
Professor, Computer Science & Engineering
University of California Santa Cruz
https://www.soe.ucsc.edu/people/mrg

On Tue, Aug 28, 2018, 08:17 戴悦 <31401...@zju.edu.cn> wrote:

Dear Prof.Guthaus:

Thank you for your reply！

Well, I don't know why the code cannot read information from cell_6t.gds and replica_cell_6t.gds. While it can read information from ms_flop.gds ,tri_gate.gds, dff.gds and other modules.

In fact, cell_6t.gds and replica_cell_6t.gds are provided by foundry, other modules are drawing by logic rule.

Thanks for your reading,and I look forward to receiving your reply!

Yours faithfully,

Yue Dai

-----原始邮件-----
发件人:"Matthew Guthaus" <m...@ucsc.edu>
发送时间:2018-08-28 20:56:56 (星期二)
收件人: "戴悦" <31401...@zju.edu.cn>
抄送: 
主题: Re: openram consultation

Yes, this is possible. Gdsmill works with any technology, but it does not support paths very well. You should convert these to rectangles.

You also need to ensure that your technology file is correctly set up. It sounds like the layers may not be correct for your new technology.

Please ask all questions to the OpenRAM email list for a faster response. 

Thanks,

Matt

---
Matthew Guthaus
Professor, Computer Science & Engineering
University of California Santa Cruz
https://www.soe.ucsc.edu/people/mrg

On Tue, Aug 28, 2018, 04:02 戴悦 <31401...@zju.edu.cn> wrote:

Dear Prof.Guthaus:

I sent several questions to you yesterday.The error points to layer[boundary].

After one days' effort, I reckon that the error happens because of invalid reading of gds file.

GDSmill didn't read correctly from cell_6t.gds of smic40 so the code didn't get the number of boundary.drawinglayer, also it didn't get information of pins. 

I wonder whether GDSmill can read gds files of other technology such as smic40. 

Thanks for your reading,and I look forward to receiving your reply!

Yours faithfully,

Yue Dai

-- 
You received this message because you are subscribed to the Google Groups "OPENRAM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openram+u...@soe.ucsc.edu.

-- 

Matthew Guthaus

Professor, Computer Science and Engineering

University of California Santa Cruz

https://www.soe.ucsc.edu/people/mrg

-- 
You received this message because you are subscribed to the Google Groups "OPENRAM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openram+u...@soe.ucsc.edu.

--
You received this message because you are subscribed to the Google Groups "OPENRAM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openram+u...@soe.ucsc.edu.

--
You received this message because you are subscribed to the Google Groups "OPENRAM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openram+u...@soe.ucsc.edu.

--
You received this message because you are subscribed to the Google Groups "OPENRAM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openram+u...@soe.ucsc.edu.

--

Matthew Guthaus

Professor, Computer Science and Engineering

University of California Santa Cruz

https://www.soe.ucsc.edu/people/mrg

[Matthew Guthaus]

We haven't had this problem in SCMOS or FreePDK45. Our designs work fine with Calibre.

---
Matthew Guthaus
Professor, Computer Science & Engineering
University of California Santa Cruz
https://www.soe.ucsc.edu/people/mrg