The Godfather talking
You can run, but you can't hide.
Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
March 28, 2024, 03:27:58 15:27


Login with username, password and session length


Pages: [1]
Print
Author Topic: Chip Circuits, schematics, HDL, layouts, libs, and IP thread  (Read 10195 times)
0 Members and 1 Guest are viewing this topic.
solutions
Hero Member
*****
Offline Offline

Posts: 1823

Thank You
-Given: 655
-Receive: 900



« on: August 21, 2011, 09:41:26 21:41 »

Hi,

I think it would be useful if we had a thread where we could request and share schematics, files, and HDL for blocks and standard cells for IC design.

If you have or need IP or libraries, circuits, cells, blocks, SPICE blocks, or HDL - schematics, listings, layouts, library files, please post here.

thanks

Posted on: August 21, 2011, 10:39:14 22:39 - Automerged



REQ: Rail to Rail Comparator

What we'd like to have:

*rail to rail inputs, sensing to ground is the must..to Vcc not so much.
*5V, 3.3V, 3.3 to 5V (ideally), anything to 5V, anything to 10V operation, but needs to be single supply
* Ideally in 1um CMOS, though we can scale the design if we have to
* Temp performance -40 to 125C, though 80C may be OK
* Low offset, drift, and good sensitivity.
* Hysteresis is OK, have it or not doesn't matter
* NOT latched
* Continuous time (not switched or clocked)
* All biasing, current mirrors, included in schematic
* Ideally shows device widths
* Ideally a real design, versus a paper, but we'll take what we can get
* no patents on it that are still valid

This is for a standard cell, so please don't post things like an LM339. This is for an IC design we are playing with.

thanks.
« Last Edit: August 22, 2011, 07:30:56 07:30 by solutions » Logged
BuBEE
Newbie
*
Offline Offline

Posts: 29

Thank You
-Given: 82
-Receive: 16

- Idea -


« Reply #1 on: August 24, 2011, 02:01:57 14:01 »

I agree  Cheesy
Logged
solutions
Hero Member
*****
Offline Offline

Posts: 1823

Thank You
-Given: 655
-Receive: 900



« Reply #2 on: October 27, 2012, 10:10:22 22:10 »

So, does anyone have CMOS (or BiCMOS, bipolar) regulator, rail to rail comparator, dac/adc, controller IP (ideally schematics and GDSII layouts) that they can share? For chip design, not boards.
Logged
Matrixx
Junior Member
**
Offline Offline

Posts: 37

Thank You
-Given: 68
-Receive: 37


« Reply #3 on: October 29, 2012, 03:13:38 15:13 »

OPA2342, OPA4342 is good for rail-to-rail applications. Single supply capable.
I use in my designs.
Logged
Aldec_forever
Senior Member
****
Offline Offline

Posts: 401

Thank You
-Given: 72
-Receive: 523



« Reply #4 on: December 02, 2012, 06:33:05 18:33 »

Please post here all requests about Digital & Analog-RF Designs & IPs (not Mechatronics, Microcontroller or simple spice related materials) . For good documentation, post Guides how to use it. If you would  be familiar with opencores.com in that site cores have been designed only in the RTL level (usually verilog or VHDL) and do not consider system level or technology constraints ( in some designs only implementations in FPGA platforms have been reported). My goal from creating this thread is taking system level considerations and going downstream to RTL Synthesizers (like Magma talus design, Synopsys design compiler etc.) and finally continuing to transistor or layout levels. I think this thread can be also good resources for integrating tools.
For the first try I have written the following C code snippet that is part of a communication filter.

#define   NUM_TAPS 8
void  fir_filter(int *input, int coeffs [NUM_TAPS], int *output) {
         static int<8> regs [NUM_TAPS];
         int temp = 0;
         int i;
         SHIFT : for (i = NUM_TAPS-1; i >= 0; i-- ) {
            if (i == 0)
               regs = *input;
            else
               regs = regs [i-1];
         }
         MAC : for (i = NUM_TAPS - 1; i >= 0; i--) {
            temp += coeffs * regs ;
         }
         *output = temp >> 7;
}


Can Anyone give a systematic flow how it can be implemented in real hardware (ASIC or FPGA) with all of the considerations like delays, area etc.. Please do not forget that name your using tools. If you are an ASIC designer, I will be pleased to hear your notes.

Posted on: October 09, 2011, 08:09:28 20:09 - Automerged

Hi everyone!
As any micro-architecture designer know hardware side of systems is composed of miscellaneous big and small parts (in RTL or sythesized formats). Sometimes rich companies are buying cores from IP providers without full descriptions about them (not part of agreement or trying to be secret (in an encrypted way)). In this situation, lots of test cases should be applied for better understanding the functionality inside the cores. This method is really time consuming and also trying to design every thing from scratch for lazy asses like me is killing.
Does anyone have knowledge about faster investigations, specially with mathematical methods like formal ones?
Thanks so much!
« Last Edit: December 02, 2012, 06:37:59 18:37 by Aldec_forever » Logged
TucoRamirez
Senior Member
****
Offline Offline

Posts: 307

Thank You
-Given: 257
-Receive: 115


Tuco ... dead or Alive


« Reply #5 on: December 02, 2012, 10:58:13 22:58 »

i remember we did a fir filter as an exercice with a fpga board, an adc and a dac...
the steps we did where:

1: study of the filter in matlab.
2: study of the quantisation and arithmethics adjusts to fit in simple cells.
3: calculations of the corrected coefficients.
4: adders and multiplyiers implementation in quartus
5: verification test ...

unfortunately i dont have my course material anymore, i think i have the fpga files from a friend... i'll dig in my disk anyway ...
Logged

Whoever double crosses me and leaves me alive... he understands nothing about Tuco.
fpgaguy
Active Member
***
Offline Offline

Posts: 138

Thank You
-Given: 154
-Receive: 166


« Reply #6 on: December 05, 2012, 11:11:36 23:11 »

for the FIR example one could have a possible path as such

1/ recode given code in systemC
1a/ code testbench in sv or systemC
2/ build in forte as behavioral model, and debug/verify using forte / verdi / or just systemC
2a/ Design/add I/O pipeline for model purpose only not for implementation
2b/ modify design for area/speed by adjusting SystemC code and forte pipeline options
3/ convert to equivalent RTL expression using forte
4/  verify RTL design with modelsim
5a/ if required add FPGA or ASIC specific macro blocks in forte
6/ repeat step 4 as needed
7/ export RTL to favority FPGA path

8/ in fpga project place this in your processing pipeline as an imported verilog module
9/ add your real I/O structures made elsewhere

this is very similar to the example design in forte


Logged
Aldec_forever
Senior Member
****
Offline Offline

Posts: 401

Thank You
-Given: 72
-Receive: 523



« Reply #7 on: December 06, 2012, 12:18:31 12:18 »

Thanks to the guys for the reply!
Yes that's right. This flow is the most successful and the fastest way of designing and implementation. Finding the best coding style that every tool can handle it, is the most time consuming part. The HLS tools in the market are going to be global but their numbers are not much enough. Forte, CTOS, Synphony C. Their mechanism is almost the same. Unfortunately they are not covering the complexities of Processor designing and that's one of the weakness points of these kinds of tools.
BTW, do you fpgaguy have the license for FORTE? I am not the user of verdi (maybe due to running of it in Linux or maybe because, its company does not exist anymore and has been merged with synopsys) though I have heard of its power. Can someone please explain its main difference from Modelsim, Active HDL or even Riviera?
« Last Edit: December 06, 2012, 12:52:44 12:52 by Aldec_forever » Logged
solutions
Hero Member
*****
Offline Offline

Posts: 1823

Thank You
-Given: 655
-Receive: 900



« Reply #8 on: December 06, 2012, 02:58:35 14:58 »

Guys: Please keep the thread focused on the topic intent. You can always start a tools request elsewhere.

Proven and debugged libraries and designs/IP, including "Mechatronics, Microcontroller or simple spice related materials"

thanks
Logged
Aldec_forever
Senior Member
****
Offline Offline

Posts: 401

Thank You
-Given: 72
-Receive: 523



« Reply #9 on: December 06, 2012, 08:51:56 20:51 »

Thanks solutions for the noticing!
Your created topic is so general and also IC circuits without discussing about the tools used in developing them is not complete enough. As you know, every company enforces its customers to use its own created design flows and tools and also finding any design that would be independent of tools is practically impossible. OK I admit that I should not ask any tool's license but as you know again, naming tools is vital for re-developing or using the IPs in the whole project.

cheers! Roll Eyes
« Last Edit: December 06, 2012, 08:54:56 20:54 by Aldec_forever » Logged
Aldec_forever
Senior Member
****
Offline Offline

Posts: 401

Thank You
-Given: 72
-Receive: 523



« Reply #10 on: December 15, 2012, 03:07:24 15:07 »

Large schematic. Who can find out what's going on inside? Is there any method for reverse engineering and discovering the designer's intent?
Just zoom it.
« Last Edit: December 15, 2012, 06:22:37 18:22 by Aldec_forever » Logged
UncleBog
Active Member
***
Offline Offline

Posts: 131

Thank You
-Given: 165
-Receive: 170


« Reply #11 on: December 15, 2012, 04:27:24 16:27 »

It looks like a machine generated schematic, probably from an HDL source intended for an FPGA or gate array ASIC. Many HDL development tools will generate such schematics.
Logged
Aldec_forever
Senior Member
****
Offline Offline

Posts: 401

Thank You
-Given: 72
-Receive: 523



« Reply #12 on: December 15, 2012, 04:58:04 16:58 »

Yes you're totally right. But I am really interested in any tool or method that can help in the reverse manner. RTL compilers generate schematics and low level codes like the above one most of times unaware of the designer' view and the designer usually do not have any choice except only relying on the the tools' results because who will try to verify the gate level netlists (though my posted one is not gate but it's RTL) specially when the design is getting bigger and bigger.

If you can not understand the generated netlist by any tool or etc. you can never manipulate it in any way you like (For example changing it for DFT or even trying to turn it into a low power one).

The usual methodology is writing the behavioral code (For example in VHDL) and synthesizing it (e.g. by design compiler or XST or Vivado for FPGAs) but from this step down, about 90% of people do not try to investigate the generated netlist and only verify it by some non-complete wave-form based testbeches (even not assertion or formal based ones).

Suppose a company like INTEL. What are they doing for these steps for example suppose 1,000,000,000 transistors (approximately 250,000,000 gates) have been resulted.

I know that lots of tools exist from e.g. Cadence and Synopsys but still one systematic flow that could cover all the steps (Top-down flow) is required. Could someone discuss about it?

Thanks so much for everybody's attention!
« Last Edit: December 15, 2012, 05:25:59 17:25 by Aldec_forever » Logged
fpgaguy
Active Member
***
Offline Offline

Posts: 138

Thank You
-Given: 154
-Receive: 166


« Reply #13 on: December 17, 2012, 06:15:07 18:15 »

that schematic looks like a a recursive viterbi implementation for xilinx V6 - I see some max log MAP code, some V6 references, and


...

But who knows(!)

Logged
Aldec_forever
Senior Member
****
Offline Offline

Posts: 401

Thank You
-Given: 72
-Receive: 523



« Reply #14 on: December 17, 2012, 07:16:31 19:16 »

FPGA companies try to encrypt the bit stream for protecting it form unauthorized access by pirates. In it (bit stream), codes are even lower than schematic, even lower than EDIF. But FPGA companies even have forecasted it and tried to develop some methods for anti-hacking. My posted schematic is in higher level than that and if it'd be for ASIC, it's obviously higher than layout. Suppose a team that its some major members have taken apart from the company and new team wants to discover the previous team's design structure. What should be done.......
« Last Edit: December 17, 2012, 08:48:38 20:48 by Aldec_forever » Logged
Aldec_forever
Senior Member
****
Offline Offline

Posts: 401

Thank You
-Given: 72
-Receive: 523



« Reply #15 on: January 12, 2013, 02:38:05 14:38 »

A we know, CPUs are special kinds of ASIC designs. I have investigated lots of papers about maximum achievable frequencies in the ASIC field. Usually Max.Freq is identified by the critical path (worst path) of design after post place and route static timing analysis has been applied.

For ASICs the Max.freq are about 400 Mhz or a little higher. I know that this can be increased by using additional pipe-line registers or some other techniques but practical designs are being traded-off (Area v.s. Speed).

Though current scaled CMOS technologies allow to reach clock frequencies of several hundreds of megahertz, parallelization is still an effective methodology to achieve high throughputs and to approach the long term objective of 1 Gb/s in e.g. wireless communications. Furthermore, in high-throughput application-specific integrated circuit (ASIC) design, the adoption of lower frequency parallel architectures instead of higher frequency serial ones is an effective method to combat unreliability and reduce nonrecurrent costs. This is one of the reasons of not considering higher frequencies.

My question is this?

What does the "3.1 GHZ" in e.g. intel core i7 series mean exactly? We know that this digital clock signal can not even be created with the current usual methods. So what's that for?
Logged
solutions
Hero Member
*****
Offline Offline

Posts: 1823

Thank You
-Given: 655
-Receive: 900



« Reply #16 on: January 12, 2013, 06:14:36 18:14 »

We had low jitter 20GHz PLL's in 28nm, 11GHz at 40 nm. PRODUCTION.

I've even overclocked 65nm at 10Gb/s on the bench and for customer demos under NDA back then (5 or 6 years ago). It's even easier if you don't care about pristine jitter and use a RO or you don't need I/O running at those bit rates, confining the high frequencies to core transistor use. Being thicker oxide, I/O transistors tend to be a fair bit slower.

All you need is power (the direct tradeoff is power vs speed...area is a consequence of power), usually source-coupled or CML kinds of current-steering topologies, and, as a man, accept that HDL is for girls  Tongue and you need to SPICE the crap out of every aspect of the circuits....

With that acceptance, the clocks are indeed running at those frequencies in an Intel chip and they are distributed in the tree using DLLs and as differential signals if not restricted to local use.

YMMV, but 400MHz is "DC" in comms chips and high end processors.

FWIW, Hairapetian et al were doing 10Gb/s in 180nm and 130nm CMOS over a decade ago, making them multi-millionaires when Broadcom scooped them up.
« Last Edit: January 12, 2013, 06:20:52 18:20 by solutions » Logged
Bobbla
Newbie
*
Offline Offline

Posts: 22

Thank You
-Given: 2
-Receive: 16


« Reply #17 on: January 12, 2013, 06:42:45 18:42 »

What does the "3.1 GHZ" in e.g. intel core i7 series mean exactly? We know that this digital clock signal can not even be created with the current usual methods. So what's that for?

Well, don't quote me on this, but. The way I understand it is that they do actually run at Ghz speed inside the CPU. They way I understand it, they actually do design the whole thing from a transistor level. There is a lot of abstraction, but they don't deal with FPGA like gates. I believe this is what you call a full-custom design.

But to answer your "3.1GHz" question.. You can say that a PIC MCU receives a external clock signal of 1 MHz, it then uses a PLL of 4 to ramp up the internal clock speed to 4 MHz. The PIC's 4 MHz is the equivalent to the i7's 3.1 Ghz, however you might find that the PIC uses a bus to communicate for external communication. Lets say it uses UART of 9600 baud, it will use the internal system clock of 4 MHz and some logic to scale down the clock frequency to 9600 Hz. In this case the PIC's UART is equivalent to many of the i7's buses.

In the good old days there was something called a northbridge which connected the CPU with memory, GPU and the southbridge. The nortbridge was connected to the CPU via the front side bus(FSB), one could say that the UART example is _sorta_ equivalent to the FSB if the PIC MCU was the "Brain" of a larger system. Today however neither AMD nor Intel uses a northbridge, they have integrated it all into the CPU chip.

So you could say that the PIC's UART/SPI/I2C/etc.. is equivalent to the i7's PCIe/DDR3/DMI/etc.. It should be noted that the PIC MCU is a much more complete system then the i7 which rely on a great many other components to function properly.

Again... don't quote me on anything... I am no expert.. and the more I write the more I doubt..
The old way.. http://www.yale.edu/pclt/PCHW/clockidea.htm

Cheers...

edit: a bummer, someone beat me to it and I seem to have gone a little off topic... maybe. But at least solutions seems to know this stuff.
« Last Edit: January 12, 2013, 06:46:29 18:46 by Bobbla » Logged
solutions
Hero Member
*****
Offline Offline

Posts: 1823

Thank You
-Given: 655
-Receive: 900



« Reply #18 on: January 13, 2013, 07:40:24 07:40 »

You've been listening to Intel's marketing BS. THEY tried to take clock speed off the table as a metric because they were in a cold war on clock speed with AMD (who seem to be winning the overclocker records these days).

FPGA core clock speed continues to scale with each node. And, as always, there is a speed/power tradeoff - these days power is more important in most ASSPs/ASICS, so a lower leakage, higher Vt, SLOWER device is used to reduce static power at the expense of speed. Scaling continues, but it has always been speed*power scaling at each node, with short channel effects creating more leakage in recent and future nodes...part of the reason for FINFETs.

And, as I said before, if you take your head out of synthesis and custom design your critical paths in SPICE, you can get MUCH higher clock speeds than you ever could by synthesis alone.

And applications are not fixed...they are enabled. I was in the group that defined DSL in the 1990's...had you said you could put 6Mb/s and more on phone wires, you'd have been locked up in a straight jacket with the key thrown away in the 1940's. There are also lots of new theories and methods being presented, as there always have been - if there weren't, the IEEE paper requests topic here would see zero traffic.

You are getting old and shutting your brain down to new things, settling in your comfort zone.  Go off and do a 28Gb/s SERDES design at the transistor level.....bet you won't because HDL is so easy and familiar and FPGAs carry zero risk compared to an ASIC whose proximity corrected masks cost $16M. That SERDES, by the way, will need a scrambler...at speed....
Logged
mrh
Junior Member
**
Offline Offline

Posts: 57

Thank You
-Given: 96
-Receive: 16


« Reply #19 on: June 26, 2013, 07:05:15 19:05 »

Hi
I'm not sure this is the right place to bring this up but I'm looking for a commercial "Ethernet 10/100/1000 MAC IP Core" (Tri Mode Ethernet MAC) Or just "Gigabit Ethernet MAC IP Core" to use with Xilinx Kintex-7. We're making a custome hardware including Kintex-7 and Marvell 88E1111 as a PHY.
Also looking for "IP" and "TCP/UDP" Stack implementation too.
So do you know any famous vendor who has something good ?

Please help. I've been looking for this for a pretty much long time but I'm not sure which is the greatest vendor ...
for example found this:
http://comblock.com/download/com5401soft.pdf
http://comblock.com/com5402soft.html

or http://arasan.com/products/wireline-interface/ethernet/gigabit-ethernet/

http://www.cast-inc.com/ip-cores/interfaces/mac-1g/index.html
http://www.cast-inc.com/ip-cores/interfaces/udpip/index.html

Huh
« Last Edit: June 26, 2013, 08:10:51 20:10 by mrh » Logged
solutions
Hero Member
*****
Offline Offline

Posts: 1823

Thank You
-Given: 655
-Receive: 900



« Reply #20 on: June 26, 2013, 09:26:39 21:26 »

Why just the external PHY? Why not an external  integrated MAC/PHY? It'll be one heck of a lot cheaper than implementing it in an FPGA.

The latest generation FPGAs have hardened IP for a MAC if you're really bent on having it inside your FPGA.

Soft IP for an Ethernet MAC on an FPGA is a very obsolete concept these days.
Logged
Aldec_forever
Senior Member
****
Offline Offline

Posts: 401

Thank You
-Given: 72
-Receive: 523



« Reply #21 on: September 06, 2013, 11:01:26 23:01 »

A fast base-2 anti-logarithm function, 10 bits in, 24 bits out. Executes every cycle, with a latency of 2.
SystemC source code. Applicable at 150 MHz in Xilinx FPGAs
No testbench is included.
« Last Edit: September 07, 2013, 12:02:44 00:02 by Aldec_forever » Logged
Aldec_forever
Senior Member
****
Offline Offline

Posts: 401

Thank You
-Given: 72
-Receive: 523



« Reply #22 on: September 12, 2013, 12:19:40 00:19 »

CAVLC parsing process in ITU-T H.264
SystemC source code. Fully synthesizable at 100 MHz. By moderate modifications in the Synthesis tool, higher freq will be approachable.
No Test-bench is included.
« Last Edit: September 12, 2013, 12:25:58 00:25 by Aldec_forever » Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC