Loading...

Follow VLSI System Design Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid

That’s because it takes 18 transistors to design it….

The above image is a layout of a D-flipflop which I designed from scratch, i.e. from inv to nand to D-flipflop. And you will find all files in below github link:

https://github.com/kunalg123/flipflop_design

But the question then you should be asking me is – Why did I design this? Well, if you look it from basic concepts and from “first principle” point of view, it has so many things for you to learn and get started with “Standard Cell design”, which is by far the most popular and demanding field as it deals directly with foundry

Did you realize the first gate is an INVERTER, and the next 4 gates are NAND?

Things to learn from this (and reasons I find this horrible, other than the 18 transistors it takes)–

  • Power rail discontinuity – We would like to have continuous power rail
  • N- and P-diffusion discontinuity – We would like to have continuous diffusion. For my Physical design friends, remember, we add “FILLER” cells at the end of routing, and you always wondered why we are doing so.
  • Small substrate contacts – Except for inverter, all substrate contacts are single width, which will create high resistance path for current, thus increasing “Clk-to-Q” delay
  • Hanging metal1 – If you see for the NAND gate outputs, there is lot of hanging metal1

Now you see why I find this horrible….If you find more reasons, please email….I know 7 more reasons for this one to be a bad design

This gives you a chance, to download all files from github, modify them, play around with them and come up with the best flipflop design.

Now, even though this flipflop was badly designed, I went ahead and characterized it with SPICE and below is what I got:

Except for clock rise edge at 6.3ns and 16.3ns (see first image for clk), at all other rising clock edge, it violates setup time. Why? Because we except the data at ‘Q’ to be stable, once captured with rise-edge of flip-flop. But for every other clock edge, the ‘Q’ varies, except at 6.3ns and 16.3ns.

This gives a “library setup time” of 477ps, which is quite a “typical” number for 180nm technology node. Now that will happen in characterization, irrespective of whether design is horrible or not, because we are still characterizing

In conclusion, there are many things to learn even from the worst design you have ever made. And FYI – I have corrected my design, reviewed it from experts and got their sign-off. But I have not uploaded it, as I want you to use this as starting point

Here’s the github link again:

https://github.com/kunalg123/flipflop_design

All the best

Happy designing and learning…

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hey There,

Of-course there is a requirement for open-source verification, but that’s not the only thing we want to cater to. There are other verification trends and challenges which system verilog and other verification platforms are not able to meet. So, we want to position Embedded-UVM for that

In the past decade or so, the major thing which is making verification tougher than it used to be, is the death of Moore’s law

As far as processor frequency goes, it stabilizes at 4GHz and its coming down as we move to multi-core processors. So, when you look at it from simulation perspective, post 2005 it is becoming increasingly difficult to run simulations on bigger chips.

Chip size keeps increasing, while processor speed is stagnant and hence, simulation is a limiting factor. Simulation speed is going to be limited unless we move to multi-core processors

Contemporary EDA tools runs RTL simulations in multi-core environment. System Verilog doesn’t run in multi-core environment.

Therefore, test-bench runs on one thread and RTL runs on multiple threads. RTL is more formal in nature, in sense, it can be synthesized, it can be partitioned, different partitions can run on different processors, while testbench is behavioral in nature and it cannot be partitioned the way RTL can be

So how do we move from below….

……to below??

Stay tuned to below link for upcoming webinar on “Opensource Verification and Emulation using Embedded-UVM”

https://www.udemy.com/user/anagha/

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hey There,

It’s time – We are looking to talk to our hardware, and we need you in Bangalore (2-3 or 4-6 yrs work ex)

Read below very carefully, and if you think you fit, please send us email at “contactvsd@vlsisystemdesign.com”….

If you have experience Developing/Reviewing/Verification and testing maintainable, high performance embedded software in C/C++ with systems programming experience writing Embedded Systems Programs preferably including OS components and BSPs – You are hired

If you have the capacity to work in a team and agility to work multiple potentially disparate projects simultaneously – You are hired

If you understand requirements from an Architecture/Design inputs, Review and implement/Review implementation of OS Component modules to specific safety and mission critical standards – You are hired

If you can design, develop, analyze, and test software modules from prototype to operational using modern software development languages and practices – You are hired

If you can assess performance on real-world data – You are hired

If you can document the Design, and test results via written reports and/or well-commented code – You are hired

If you are bachelor’s or Master’s in Computer science / Electronics Engineering with minimum of 2 years of experience in Embedded systems programming

And if you have experience developing agile, maintainable, high performance software in C/C++ and/or C#

And if you Understanding/Exposure in using/developing real-time operating system components with a flair for understanding Embedded systems hardware

And if you have Capacity to work in a team

And if you have Good written and verbal communication skills

And if you are familiar with developmental environments for Linux and/or VxWorks

And if you understand multithreaded architectures, thread synchronization and queues

And if you have Experience with microcontrollers and Embedded systems programming, BSP development, etc with a flair for understanding underlying hardware, especially Xilinx FPGAs and AGILE software development methodology

YOU ARE HIRED….

I never said it would be easy……

All the best and happy learning…..

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hey There – Think about it…!!

Problem Statement – For hierarchical designs ~500k instance count, participants are expected to develop code which will modify existing clock tree routes with non-default rules for selected nets

Inputs given for code development and testing:

  • A text file in DEF format with clear definitions of core/die width, pad placement, pre-placed cells, power rings around core/pre-placed cells, clock tree buffers/routes and other information unplaced/placed/fixed cell with locations of all flip-flops and combinational cells
  • A netlist in Verilog format corresponding to above DEF
  • Industry grade 180nm PDK’s (standard cells, memories, pads) LIB and LEF formats

Expected output:

A text file in standard DEF format and Verilog netlist which has all information about inputs which were provided + information about clock tree routes with non-default rules for selected nets (shown in below image)

In principle, the output and qualification criteria are shown in below image

Step 1) Find a way to parse input DEF file and verilog file provided by VSD, which has locations, co-ordinates, instance names, connectivity details and many more information of all instances that you see in below fig. It can be a command something like below

read_def <input_def_file>

read_verilog <input_verilog_file>

If the DEF file syntax is not in par with standard DEF syntax, issue an error message specifying line number where there is a syntax error. Same with verilog syntax

Step 2) Develop code (or command) which will enable users to create non-default rules, something like below. Refer to default rules from tech lef, which will be a good starting point

create_my_ndr -name <non_default_rule_name>

update_my_ndr -name <non_default_rule_name> -width <double_or_triple_width> -spacing <double_or_triple_spacing> -layer <layer_name>

User can use the above commands, like below

create_my_ndr -name ndr1

update_my_ndr -name ndr1 -layer m1 -width 0.5 -spacing 0.7

update_my_ndr -name ndr1 -layer m3 -width 0.8 -spacing 1.0

create_my_ndr -name ndr2

update_my_ndr -name ndr1 -layer m1 -width 0.25 -spacing 0.35

update_my_ndr -name ndr1 -layer m3 -width 0.4 -spacing 0.5

Step 3) Develop code (or create command) to report newly created NDR’s, something like below

report_my_ndr -name <ndr_name>

User can use above command like below

report_my_ndr -name ndr1

Output:

my_ndr_name “ndr1”

layer_name:width:spacing

m1:0.5:0.7

m3:0.8:1.0

Step 4) Develop code (or command) to “route leaf cell + 1 level buffer route output + same buffer input till branch-off point with ndr2” and “route other clock nets with ndr1”

It can be a command something like below.

special_route_clock_nets -leaf_cell_clock_net ndr2 -other_clock_nets ndr1

Step 5) Clock tree quality will be checked for skew, pulse width, duty cycle, latency, clock tree power and crosstalk coupling as shown in below image

Terms and condition:

  1. You are free to use the source code of existing (and only) opensource tools like magic, qflow, graywolf, qrouter or any other
  2. Each line of your code needs to be open-sourced and documented

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hey There,

Problem Statement –For hierarchical designs ~500k instance count, participants are expected to develop code which will build clock tree for a design which has close to ~50k sequential flip-flops using default routing rules

Inputs given for code development and testing:

  • A text file in DEF format with clear definitions of core/die width, pad placement, pre-placed cells, power rings around core/pre-placed cells and other information unplaced/placed/fixed cell with locations of all flip-flops and combinational cells
  • A netlist in Verilog format corresponding to above DEF
  • Industry grade 180nm PDK’s (standard cells, memories, pads) LIB and LEF formats

Expected output:

A text file in standard DEF format and Verilog netlist which has all information about inputs which were provided + information about clock tree buffer locations and clock route width (shown in below image)

Step 1) Find a way to parse input DEF file and verilog file, which has locations, co-ordinates, instance names, connectivity details and many more information of all instances that you see in Fig.2. It can be a command something like below

read_def <input_def_file>

read_verilog <input_verilog_file>

If the DEF file syntax is not in par with standard DEF syntax, issue an error message specifying line number where there is a syntax error. Same with verilog syntax

Step 2) Develop code (or command) to buffer the clock route using the list of balanced clock buffers provided based on estimated routing parasitics, so that there is no mismatch in rise and fall slew

It can be a command something like below.

buffer_clock_routes -list_of_buffers <list_of_buffers> -skew_target <skew_in_ps> -max_latency_target <max_latency_in_ps> -allow_inter_clock_balancing <true/false> -clock_name_list <list_of_clocks_to_be_buffered>

User can give command like below:

buffer_clock_routes -list_of_buffers “clkbuf1 clkbuf2 clkbuf4 clkbuf8” -skew_target 50ps -max_latency_target 10ns -allow_inter_clock_balancing true -clock_name “CLK1 CLK2”

Step 3) Develop code (or command) which will identify and route all “related” flip-flops clock end-points (See below image for description) using default metal routing rules from tech lef. “Related” meaning, there is a path from FF1 to FF2 with CLK1 or CLK2

It can be a command something like below

route_clock_pins

Step 4) Routing over block is not allowed (see below image).

Step 5) For ~50k flops, the clock tree will something like below:

Step 6) Clock tree quality will be checked for skew(given in -target_skew), pulse width(default half of clock period), duty cycle(default 50%), latency(given in -max_latency_target), clock tree power and crosstalk coupling.

Terms and condition:

  1. You are free to use the source code of existing (and only) opensource tools like magic, qflow, graywolf, qrouter or any other
  2. Each line of your code needs to be open-sourced and documented

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hey There – Think about it!!

Today’s version of open-source EDA tools, work very well for hierarchical designs sub-25k instance count. For hierarchical designs ~500k instance count, develop code which will enable users to connect pre-placed power pins to power rings around them and generate power grid within core

Inputs given for code development and testing:

  • A text file in DEF format with clear definitions of core/die width, pad placement, pre-placed cells, power rings around core/pre-placed cells and other information unplaced/placed/fixed cells
  • Industry grade 180nm PDK’s (standard cells, memories, pads) LEF formats

Expected output:

A text file in standard DEF format which has all information about inputs which were provided + information about pre-routes and power grids (shown in below image)

Step 1) Find a way to parse input DEF file, which has locations, co-ordinates, instance names and many more information of all instances that you see in below image. It can be a command something like below

read_def <input_def_file>

If the DEF file syntax is not in par with standard DEF syntax, issue an error message specifying line number where there is a syntax error

Step 2) Develop code (or command) connect memory/ip/macro power pins to main power grid (See below image for description)

It can be a command something like below

connect_pre_placed_cells_vdd_vss_to_power_grid

Step 3) Develop code (or command) to create placement/routing blockage on macro’s/IP’s/memories OR any pre-placed cell so that automated placement/power routing/signal routing tool should not place any cell on top of pre-placed cells or route on top of these cells (See below image for description)

Keyword “BLOCKAGE” is used to define in DEF file (Look up for industry DEF file formats)

It can be a command something like below

set ip_cordinate [get_my_property <ip_instance_name> cordinates]

The above command will set a variable $ip_cordinate = {x y}

create_blockage -blockage_cordinates $ip_cordinate

Step 4) Develop code (or command) to create power grid inside core, starting and ending, from and to power rings around core boundary (See below image for description)

It can be a command something like below (V = Vertical, H = Horizontal))

create_power_grid -direction V -width <number_in_um> -net_names {VDD} -pitch <number_in_um> -layer_name <top_vertical_layer> -start_location <x_location_for_vertical_power_strip>

create_power_grid -direction V -width <number_in_um> -net_names {VSS} -pitch <number_in_um> -layer_name <top_vertical_layer> -start_location <x_location_for_vertical_power_strip>

create_power_grid -direction H -width <number_in_um> -net_names {VDD} -pitch <number_in_um> -layer_name <top_horizontal_layer> -start_location <y_location_for_horizontal_power_strip>

create_power_grid -direction H -width <number_in_um> -net_names {VSS} -pitch <number_in_um> -layer_name <top_horizontal_layer> -start_location <y_location_for_horizontal_power_strip>

Terms and condition:

  1. You are free to use the source code of existing (and only) opensource tools like magic, qflow, graywolf, qrouter.
  2. Each line of your code needs to be open-sourced and documented

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hey There,

Our team worked really hard to get Robot + MP3 player using India’s First Indegenious 32-bit RISC-V Microprocessor “Shakti E-Class”…This one is Shakti on FPGA….Many more customer products are getting ready using Shakti processor and indigenous board, for IESA event at Leela Palace, Bangalore on 19th and 20th Feb… Join us and meet the brightest brains of India who built Shakti from scratch…
What’s unique about this robot and the RISC-V core which is driving it?
We know the core, we know RISC-V, we know the software, we know the hardware, we know the chip layout – Full control – That’s the beauty of open-source hardware. You are in full control of everything including it’s security. Stay tuned for more updates….

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hey There – Think about it!!

Today’s version of open-source EDA tools, work very well for hierarchical designs sub-25k instance count. For hierarchical designs ~500k instance count, opensource EDA tools are expected to have  code which will enable users to pre-place cells like macros/IP’s/memories inside core and create power rings around core and pre-placed cells

Inputs given to this EDA tool or code:

  1. A text file in DEF format with clear definitions of core/die width, pad placement and other unplaced cells
  2. Industry grade 180nm PDK’s (standard cells, memories, pads) LEF formats

Expected output from this EDA tool:

A text file in standard DEF format which has all information about inputs which were provided + information about pre-placed cells and power rings (shown in below image)

Let me suggest you some steps to reach to above point:

Step 1) Find a way to parse input DEF file, which has locations, co-ordinates, instance names and many more information of all instances that you see in below image. It can be a command something like below

read_def <input_def_file>

If the DEF file syntax is not in par with standard DEF syntax, issue an error message specifying line number where there is a syntax error

Step 2) Develop code (or command) to create VDD and VSS power rings around core with below options (See below images for description)

  • min spacing from core
  • min spacing from each other
  • width

It can be a command something like below

create_power_rings_around_core -min_spacing_from_core <number_in_um> -min_spacing_from_nearby_layer <number_in_um> -width <number_in_um> -net_names {VDD VSS}

For “-net_names”, there should be an option to create multiple VDD and VSS. For eg. if -net_names {VDD VSS VDD VSS VDD} or -net_names {VDD VDD VSS VSS}, then the code should create 5 power/ground or 4 power/ground in order mentioned above. If spacing between core boundary and pad is not enough to fit 5 power/ground or 4 power/ground, please issue error message

Step 3) Develop code (or command) to place macro’s, memories, IP’s inside core with exact co-ordinates and freeze its location such that, automated placement tools don’t move it (See below image for description). Keyword “FIXED” is used to define such cells in DEF file format (Look up for industry DEF file formats).

It can be a command something like below

pre_place_cell -cell <cell_name> -location <x_cordinate y_cordinate> -fixed <true/false>

User can use the command like below

pre_place_cell -cell <memory_name> -location <x1 y1> -fixed true

pre_place_cell -cell <macro_name> -location <x2 y2> -fixed true

pre_place_cell -cell <IP_name> -location <x3 y3> -fixed true

If <x1 y1>, <x2 y2> and <x3 y3> are outside core, please issue an error

Step 4) Develop code (or command) to create power rings around macro’s/IP’s/memories OR any pre-placed cell with below options (See below image for description)

  • min spacing from cell boundary
  • min spacing from each other
  • width

It can be a command something like below

create_power_rings_around_pre_placed_cell -min_spacing_from_cell_boundary <number_in_um> -min_spacing_from_nearby_layer <number_in_um> -width <number_in_um> -net_names {VDD VSS}

Terms and condition:

  1. You are free to use the source code of existing (and only) opensource tools like magic, qflow, graywolf, qrouter.
  2. Each line of your code needs to be open-sourced and documented

Stay tuned for more updates……

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Hey There – Think about it!!!

Last week, we shared our idea and vision of “How to define the width and height of core and die using opensource EDA tools?” – This is not for toy designs, but for a complex hierarchical designs, with instance count up to 500k instance count

Today’s version of open-source EDA tools, work very well for hierarchical designs sub-25k instance count. For hierarchical designs ~500k instance count, let’s develop code which will enable users to place IO pads and dummy pads, in area between core an die, shown in below image. – Sounds like a very simple problem statement…Believe me, it becomes more tougher, but clearer, the more you think about it

Expected output from this problem statement:
A text file in standard DEF format which has all information about inputs which will be provided, like standard cells PDK’s + synthesized verilog + core/die width and height information and output information about all pad locations (shown in below image)

Let me help you with some steps to implement the above

Step 1) Find a way to parse input DEF file, which has locations, co-ordinates, instance names and many more information of all instances that you see in below image. It can be a command something like below

read_def <input_def_file>

If the DEF file syntax is not in par with standard DEF syntax, issue an error message specifying line number where there is a syntax error

Step 2) Develop code (or command) to place pads (from IO libraries which we will be providing) with below constraints

  • Side (left, right, top, bottom)
  • X, Y Locations
  • minimum spacing with nearby pads

It can be a command something like below

place_pads -pad <pad_instance_name> -preferred_side <left/right/top/bottom/corner> -pad_location <first_half_of_preferred_side_or_second_half_of_preferred_side> -min_spacing_from_left_pad <number_in_um> -min_spacing_from_right_pad <number_in_um>

User will use the above command for all pads. (come up with a strategy to define “corner”)

place_pads -pad pad1 -preferred_side right -pad_location first_half -min_spacing_from_left_pad 25 -min_spacing_from_right_pad 25

place_pads -pad pad2 -preferred_side bottom -pad_location second_half -min_spacing_from_left_pad 25 -min_spacing_from_right_pad 25

Below image shows what does “right side first half” and “bottom side second half” mean.

This way we can configure and place all pads. Refer to Tim Edward’s placement tool “graywolf”

Step 3) Fill the rest area with dummy pads, while maintaining min ‘X’ um. (this means you need to create a dummy pad with available pad as reference)

It can be a command something like below

create_dummy_pad <pad_name> -reference_pad_cell <reference_library_pad_cell_name> -count <number_of_pads_user_wants_to_create> OR

create_dummy_pad <pad_name> -pad_width <number_in_um> -pad_height <number_in_um> -count <number_of_pads_user_wants_to_create>

This will create a dummy pad with the name “pad_name_1”, “pad_name_2”, “pad_name_3” and so on using one reference pad cell which is available in library

place_pads -pad <pad_instance_name> -preferred_side <left/right/top/bottom/corner> -pad_location <first_half_of_preferred_side_or_second_half_of_preferred_side> -min_spacing_from_left_pad <number_in_um> -min_spacing_from_right_pad <number_in_um>

The above command is what we have created in step 2). This will place pads having instance names as “pad_instance_name” as shown below.

User can use the command like below. If square shape pad not available, create dummy square shape pad using -pad_height and -pad_width options given in above “create_dummy_pad” command

create_dummy_pad corner_pad -pad_width 40 -pad_height 40 -count 4

create_dummy_pad normal_pad -reference_pad_cell lib_pad_cell_with_rectangle_shape -count 20

place_pads -pad corner_pad_1 -preferred_side corner

place_pads -pad normal_pad_1 -preferred_side right -pad_location first_half -min_spacing_from_left_pad 25 -min_spacing_from_right_pad 25

place_pads -pad normal_pad_2 -preferred_side left -pad_location second_half -min_spacing_from_left_pad 25 -min_spacing_from_right_pad 25

Step 4) Fix pad locations using standard DEF syntax (+FIXED) which will make sure that any automated placement and routing tool don’t move it

It can be a command something like below

select_cell <list_of_pads> -fixed <true/false>

Terms and condition:

  1. You are free to use the source code of existing (and only) opensource tools like magic, qflow, graywolf, qrouter.
  2. Each line of your code needs to be open-sourced and documented

Doesn’t that sound exciting?

Stay tuned below for more….

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Hey There – Think about it!!!
Today’s version of open-source EDA tools, work very well for hierarchical designs sub-25k instance count.
For hierarchical designs ~500k instance count, what if, we develop code which will enable users to design/decide chip area based on width and height of chip OR utilization factor and aspect ratio of core?

What if, Inputs given for code development and testing are:

  1. Full hierarchical RTL code for any RISC-V micro-processor in Verilog format
  2. Industry grade 180nm PDK’s (standard cells, memories, pads) in LIB and LEF formats

And Expected output should be:

A text file in standard DEF format which has all information (shown in below image) about the core and die. “Remember – This is for hierarchical designs AND NOT FLAT“. So existing solutions will not work

All existing open-source solutions work very well for flat and within 25k instance count

Does that sound easy? It is easy and proven for a flat design, so this ideally should be just an extension to that as practically all designs in the world, are hierarchical designs

Let me suggest some steps to reach above point:

Step 1) Find a way to parse macro/memory/IP LEF’s and. libs. These files have all information regarding physical shapes & sizes, timing characteristics of all logic elements which will be used in design. It can be a command like below:

read_lef <list_of_all_lef_files> [you might want to refer to “lef read” command of MAGIC]

read_lib <list_of_all_lib_files> [you might want to refer to “read_liberty” command of yosys]

If lef file and lib file syntax is not in par is standard LEF and LIB syntax, issue an error message specifying line number where there is a syntax error

Find a way to parse synthesized hierarchical verilog netlist (about 300k instance count). It can be a command like below:

read_verilog <synthesized_verilog_file> [you might want to refer to “read_verilog” command of yosys]

If verilog file syntax is not in par is standard VERILOG syntax, issue an error message specifying line number where there is a syntax error

Step 2) Develop code (or command) to create core with either of below options (See below images for description)

  • Hard-coding width and height OR
  • Aspect ratio (height/width) and utilization factor

It can be a command something like below

create_my_core -width <number_in_um> -height <number_in_um>

OR

create_my_core -aspect_ratio <number> -utilization_factor <number_between_0_to_1>

If user gives -width/-height with -aspect_ratio/-utilization_factor, please issue an error

Step 3) Develop code (or command) to create die with below options (See below images for description)

  • core2die_left
  • core2die_right
  • core2die_top
  • core2die_bottom

It can be a command something like below

create_my_die -core2die_left <number_in_um> -core2die_right <number_in_um> -core2die_top <number_in_um> -core2die_bottom <number_in_um>

But there are terms and condition:

  1. Free to use the source code of existing (and only) opensource tools like magic, qflow, graywolf, qrouter.
  2. Each line of code needs to be open-sourced and documented
Sounds interesting and challenging – Let’s Re-Think
Are you ready for a ride? Stay tuned for more updates on this…..

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview