text:
Healthcare Needs APIs More than Apps
This post was written with my colleagues Joris Van Dam, Translational Sciences Strategic Project Leader at Novartis Institutes for Biomedical Research (NIBR); and John R. Walker, director of NIBR IT for Novartis.
As frequent attendees of mobile health conferences, we've been excited by the momentum and creativity we've seen in mobile health solutions (Health Apps). But we've also been concerned.
We're excited because of the number of Health Apps being developed for patients and consumers in different disease areas, for wellness, prevention and care. As big believers in the potential of Health Apps to improve outcomes and lower healthcare costs, we're glad to see this market really take off.
At the same time, it seems there's an App for everything – and anything. Yet there's very little talk of interoperability or data exchange – heck, even about preserving my personal health data when I want to exchange my App for a new one, when I need to re-image my phone, or when I want to buy a new phone.
It seems like in the rush to capture the value of mHealth, we're launching and creating a staggering amount of new health data silos – making health data less liquid and shareable when we need just the opposite. This is a big concern, because in the longer term, data liquidity is the key to sparking innovation, improving outcomes, and reducing healthcare costs.
At the recent 2012 mHealth Summit, it was encouraging to see that this approach is starting to shift. It seems that more and more healthcare companies are recognizing that even though their patients or their customers need these Apps, perhaps jumping head-first into Apps development isn't their best bet. Instead, maybe healthcare companies should let "the market" develop these Apps (they seem to know what they're doing!) while they support the market – with funding, with infrastructure, and with content (liquid data).
Getting It Right
One of the great examples at mHealth Summit was presented by Aetna, a 160-year-old health insurance company. Rather than joining the Apps Race, Aetna has developed and published the CarePass platform. The platform provides a set of APIs that allows you to build your own Apps, plus it provides interoperability among your App and all the other Apps developed using CarePass – including the 20+ Apps that Aetna has developed and acquired itself, such as iTriage. Update of January 24, 2013: Check out this great video interview with Aetna Vice President Martha Wofford.
AT&T and Qualcomm Life also presented their platforms, with APIs that connect to a variety of different health and wellness devices. These APIs allow you to build Apps that connect to these devices, yet also thereby become independent of the devices. For example, you could switch from one fitness sensor to another, buy a different wireless weight scale, or use a new blood-pressure monitor while the App preserves your health data.
Entirely in the same vein, earlier this year Athena Health, the Watertown, Mass-based provider of cloud-based Electronic Health Record (EHR) systems, launched their "More Disruption Please" program. Participants in the program receive access to the API of Athena Health's EHR system, a platform to build Apps. They can even get access to start-up funding and launch support for their Apps in the network of Athena Health customers.
Allscripts launched a similar developer program for their EHR. And in 2009 Cerner launched its uDevelop platform, providing their customers with a platform and APIs to develop new Apps, and an App store to share these Apps with each other.
Of course, the largest, and perhaps most influential, organization to get it right is the ONC, which has been setting the tone for improving data liquidity in healthcare, and thereby stimulating healthcare innovation in Health Apps development, through an array of policies and programs. These include health information exchanges, meaningful use criteria for EHR adoption, Project Blue Button, and the Health Data.gov platform – to name just a few.
Many of these programs also provide funding for you to develop Apps with their APIs. And, if not, there is always Health 2.0, which announced in May 2012 that it had already awarded more than $1 million to mobile health initiatives through its Developer Challenge series.
Where to Go from Here
There will always be a new App, a better App, an App that fits my health needs better as they evolve over time – and that's OK. Yet all this tremendous activity and investment in Health Apps will only really and truly pay off, for individuals and their individual health needs as well as for a sustained impact on the healthcare system overall, if those Apps are built on, and contribute to, an underlying layer of liquid health data.
As patients and consumers, we need to be able to switch from one device to the other, carry our health data from one provider to the other, switch insurance companies as we take new jobs, exchange one App for the other and so on – as our personal healthcare needs evolve over time. And those personal healthcare needs will really and truly only be served if our health data moves with us, as opposed to being caught in the latest fad and locked in the latest App.
For mHealth to pay off, we need APIs more than we need Apps. It's great to see that so many companies are getting it right. A year ago, we felt both excited and concerned at the prospect of mHealth. Today, we're just pumped.


text:
Due to current health and safety measures, all wineries are accepting visitors by appointment only
Arkenstone is an all Estate Winery located on the Western shoulder of Howell Mountain. Our 13 acres of vineyard, which overlook the Napa Valley to the West and Bell Canyon to the East, are split into 22 blocks planted to Cabernet Sauvignon, Cabernet Franc, Merlot, Petit Verdot, Malbec, Sauvignon Blanc, Semillon and Syrah. We go from 1,400 feet of elevation to 1,650 feet, with a mix of steep hillside and rolling level vineyard. The majority of the vineyard was planted in 1998 and the entire vineyard has always been, and continues to be, organically farmed.
Our wines reflect our terroir as well as our vineyard and winemaking practices. Arkenstone produces an Estate Cabernet blend, Obsidian (Cabernet Sauvignon, Cabernet Franc, Merlot, Petit Verdot and Malbec), a Graves style Estate Sauvignon Blanc/Semillon blend and an Estate Syrah. We also produce our Coliseum Block Cabernet Sauvignon with fruit that we source from the Hossfelt vineyards's Coliseum Block in Soda Canyon. Howell Mountain, with its volcanic, rocky soils, gives us incredibly small concentrated berries along with robust tannins, lush acidity and distinctive earthy, minerality. Our winemaker, Sam Kaplan oversees the vineyards as well as the winemaking and creates beautifully balanced wines with now characteristic Arkenstone depth and complexity.
During harvest we use gravity flow to move our fruit from the crush pad into fermentors 40 feet below in our underground winery caves. These grand caves house the fermentation hall as well as barrel storage and hospitality areas.
Tours through the vineyards and the exploration of our extensive winery caves give our guests a thorough overview of how our wines are crafted from vine to bottle. There is a true connection created between the sense of this beautiful place and the wine itself. Tastings, of course, are part of this experience.
Our tasting room setting allows our visitors to enjoy the seasons in the vineyards, moving from the soft green sea of just budding vines of spring to the full, lush growth of summer into the brilliant changing palate of fall colors, and finally, to the proud silhouettes of the winter vines at rest. Whether you come during the warm summer days and evenings that draw us out into the vineyards or the cold, rainy days of winter tasting cozily by the fire, it is always the right time to visit the winery. We offer all of our tours and tasting by appointment. We invite you to come and experience Arkenstone.
Plan a trip to Arkenstone Vineyards on our interactive winery map:
Elegant yet comfortable. Combination of Arts and Crafts design and rustic barn feel. Tastings are intimate and led by either the owners or Hospitality director. We taste at our large wood plank table, at the tasting bar, or sitting comfortably in cozy armchairs around the fireplace. During covid-19, we also have comfortable outdoor tasting areas that overlook the vineyards.View from Tasting Room: The tasting room looks out over our vineyards. Our vineyards overlook the Napa Valley looking South and Bell Canyon looking North.
Arkenstone Vineyards Wine Club
Wine clubs are a great way to stay connected to your favorite wineries.
To join the wine club, visit www.arkenstone.com or call 707-965-1020.
Because Arkenstone has a small, highly allocated production, we offer an allocation membership created to assure our loyal customers an allocation of selected wines upon release.
Once a year the rarest new Napa Valley wines become available under one roof at Premiere Napa Valley. Wineries throughout the Napa Valley are given one task to participate: create a one-of-a-kind wine for this event to be purchased by one lucky bidder. This event is only open to select members of the wine trade and the successful bidder is the sole owner of this unique wine.
Arkenstone Vineyards
Cases: 5
Varietal: Cabernet Sauvignon
Vintage: 2017
Release Date: October - 2020
Appellation: Howell Mountain
To purchase this wine or check on availability contact:
Napa Wine Ltd.

subset: commoncrawl


text:
- 1 Synopsis
- 2 Working With Genesis2
- 2.1 Setting Your Environment
- 2.2 Working On Stanford Machines
- 2.3 Working Locally On Your Own Server/Machine
- 2.4 Genesis2 File Types
- 2.5 Source Code Structure For Using Genesis2
- 2.6 A Word About Genesis2 Elaboration Order And Parameterization
- 2.7 Invoking The Genesis2 Tool
- 3 Extending Genesis2 With Homemade Perl Libraries
- 4 Behind The Genesis2 Curtain
As power constraints continue to impact traditional chip design, and custom design costs become prohibitively expensive, the only economic way for companies to produce new ASICs is to embed and reuse designers' knowledge. In fact, most companies are already doing exactly that by creating in-house "generator" scripts.
We have developed a pre-processing tool for designing digital and mixed-signal chips. This chip generator technology ("Genesis2") changes the programming paradigm to allow designers to embed their knowledge when constructing RTL design modules. Genesis2 enables the designer to simultaneously code in two interleaved languages for a rich, extensible software environment: one language generically describes the hardware proper and the other one decides what specific hardware to instantiate. This process allows for greater flexibility in the initial construction and later elaboration of the design without compromising strict synthesizability rules for the functionality of the module. Put differently, Genesis2 enables not only an easier, standardized method for creation of module generators, but also aggregates those unit level generators together into a full chip generator. Ultimately, Genesis2 enables users to design an entire family of chips at once using a chip template that is then elaborated into multiple different per-application customized chips.
The rest of this page describes Genesis2 and how to use it.
Comments are welcome: Ofer Shacham,
Working With Genesis2
Setting Your Environment
Setting Xemacs Verilog Mode
To set xemacs such that it starts in verilog mode, add the following code to your ~/.xemacs/init.el file:
;; Load verilog mode only when needed (autoload 'verilog-mode "verilog-mode" "Verilog mode" t ) ;; Any files that end in .v should be in verilog mode (setq auto-mode-alist (append '( ("\\.v\\'" . verilog-mode);; for verilog files ("\\.vh\\'" . verilog-mode);; for verilog header files ("\\.sv\\'" . verilog-mode);; for system verilog files ("\\.svh\\'" . verilog-mode);; for system verilog header files ("\\.vp\\'" . verilog-mode);; for pre-processed Genesis files ("\\.vph\\'" . verilog-mode));; for pre-processed Genesis header files auto-mode-alist))
- Note that a loader for verilog mode may have already been defined. In that case either modify it to identify .vp and .vph files, or replace with the above code.
Of course, you would have to make sure that you have the file ~/elisp/verilog-mode.el. Since we keep an elisp folder on p4 (under $SMASH/elisp/, the easiest option might be to just soft link to that folder from your home directory. See ~shacham/elisp and ~shacham/.xemacs/init.el for reference.
Missing Perl Libraries?
Genesis2 is written in Perl. However not all Linux distributions are born equal and as a result, some machines lack certain Perl Libraries needed by Genesis2. So far, libraries that I have seen missing include XML::Simple and XML::SAX / XML::Parser (you only need one of SAX or Parser).
These libraries are freely available from CPAN. To install these libraries simply follow these steps:
- Login as root
- Open a CPAN shell:
perl -MCPAN -e shell
- Install the library XML::SAX (required by XML::Simple). Make sure to answer yes for installing all library dependencies!
cpan> install XML::SAX
- Install the library XML::Simple
cpan> install XML::Simple
Adding Genesis2 To Your Execution Path
Working On Stanford Machines
New! As of Dec 3rd, 2010: Genesis2 is now available through the common module load system just like any other cad tool. To load Genesis2 do the following:
- If you have not already done so, source the module loader by typing:
source /cad/modules/init_modules.csh
- Load the Genesis2 module
module load genesis2
That's it. You are good to go.
Working Locally On Your Own Server/Machine
First, install the Genesis2 files. For example, you can put them under $USER/bin/PerlLibs/Genesis2. It should look something like this:
vlsi: ~/bin/PerlLibs/Genesis2> ls -R .: Auxiliary/ Genesis2.pl Manager.pm UniqueModule.pm ./Auxiliary: TypeConv.pm
Then, to add Genesis2 to your execution path, simply type (or place at the end of your .cshrc file):
setenv GENESIS_LIBS "~USER/bin/PerlLibs" set path=($GENESIS_LIBS/Genesis2 $path)
Genesis2 File Types
Main File Types
SomeModule.vp And SomeIncludeFile.vph Files
These are the user's files. That is, when you come to write a hardware module that you want Genesis2 to elaborate, you should write it in a file named base_module_name.vp. For example, if the module name is onehotmux, it should be placed in a file named onehotmux.vp.
Included files should be named whatever.vph. In fact, this requirement is not real and whatever.anything or even whatever would work. However, for nice coding style, and for xemacs verilog mode to work nicely, the whatever.vph is recommended.
SomeModule.pm Files
Genesis2 generates intermediate Perl module files (Given the file filename1.vp, Genesis2 would generate filename1.pm). Typically there is no reason to look at these files, except for debugging of parsing errors and their like.
Note that Genesis2 works in two stages: First all the .pm files are generated. These files are, in fact, a complete object oriented program in Perl, where each module represents a module generator. Then, after all the Perl modules are created, Genesis2 executes the newly created Perl program that in turn generates Verilog.
SomeModule.v Files
The final type of file of interest is the generated verilog file. This code should consist of only verilog, and will eventually be fed to VCS/dc_shell/other tools.
- Note: For every somemodule.vp input file, there may be more than one verilog file generated. If somemodule is instantiated in different places using different parameters, each different instance would be uniquified. The resulting verilog files would be named somemodule_unq0.v, somemodule_unq1.v, etc.
Program.xml File
The XML input program has a very simple structure. An example follows. Note that, structure-wise:
- There are a few reserved element names: HierarchyTop, BaseModuleName, InstanceName, Parameters, ImmutableParameters, ParameterItem, Name, Val, Doc, Range, SubInstances, SubInstanceItem, UniqueModuleName, CloneOf, HashType, ArrayType, ArrayItem, InstancePath. Avoid using these key words in any context other than the one explained here or in the output xml representation section.
- There is a single root element which is the name of the top module of the design (since the top module is not instantiated, it is referred to by HierarchyTop and not by its instance name). A minimal input XML structure would contain the following text:
- For each module instance in the hierarchy (including HierarchyTop) the following recursive structure can be used. It must have InstanceName (except for the HierarchyTop), and it can have Parameters and SubInstances. Omitting the Parameters or the SubInstances is ok. However, omitting the InstanceName will result in an error!
- Example of top level:
<HierarchyTop> <!-- Optional: --> <Parameters> <!-- List zero or more ParameterItem elements--> </Parameters> <SubInstances> <!-- List zero or more SubInstanceItem elements--> </SubInstances> </HierarchyTop>
- Example for internal node
<SubInstances> <SubInstanceItem> <!-- Mandatory: --> <InstanceName>someInstanceName</InstanceName> <!-- Optional: --> <Parameters> <!-- List zero or more ParameterItem elements--> </Parameters> <SubInstances> <!-- List zero or more SubInstanceItem elements--> </SubInstances> </SubInstanceItem> ... <!-- More SubInstanceItem elements--> ... </SubInstances>
- SubInstances: (Optional) A list of XML elements that represent the sub-instances in the current hierarchy level. The same rules apply recursively for each of these elements. Note that if an instance is encountered during elaboration, but the corresponding SubInstanceItem is missing from the XML tree, it will be assumed that that instance uses the default parameters or the instantiation line parameters, as noted in the .vp files.
<SubInstances> <SubInstanceItem> <InstanceName>someInstanceName_A</InstanceName> ... </SubInstanceItem> <SubInstanceItem> <InstanceName>someInstanceName_B</InstanceName> ... </SubInstanceItem> ... <!-- More SubInstanceItem elements--> ... </SubInstances>
- Parameters: (Optional) A list of zero or more ParameterItem. Note that if a ParameterItem is missing from the list, it is assumed that its value is not overwritten by XML. If ParameterItem exists for a parameter that is not defined in the .vp file, it is simply ignored. Each myValue of a parameter myParam would be written as:
<Parameters> <ParameterItem> <Name>myParam</Name> <Val>>myValue</Val> </ParameterItem> ... <!-- More ParameterItem elements--> ... </Parameters>
- For Parameters, note that more complicated data structures are also supported for the Val element using the HashType to show that a parameter is a hash rather than a string/scalar or the ArrayType to show that a parameter is an array rather than a string/scalar. Array of hashes and hash of arrays (or any recursive combination) is also supported.
- Each ArrayType contains a list of zero or more ArrayItems elements. An empty array is an ArrayType with no internal ArrayItem. Each ArrayItem must contain a Val element. (see example next)
- Each HashType contains a list of zero or more HashItems elements. An empty hash is a HashType with no internal HashItem. Each HashItem must contain a Key element AND a Val element. (see example next)
<Parameters> <ParameterItem> <Name>myArrayParam</Name> <Val> <ArrayType> <ArrayItem> <Val>1</Val> </ArrayItem> <ArrayItem> <Val>2</Val> </ArrayItem> <ArrayItem> <Val>3</Val> </ArrayItem> ... <!-- More ArrayItem elements--> ... </ArrayType> </Val> </ParameterItem> <ParameterItem> <Name>myHashParam</Name> <Val> <HashType> <HashItem> <Key>somekey</Key> <Val>someval<Val> </HashItem> <HashItem> <Key>anotherkey</Key> <Val>anotherval</Val> </HashItem> ... <!-- More HashItem elements--> ... </HashType> </Val> </ParameterItem> </Parameters>
- For Parameters, one can also use InstancePath to express that a parameter represents a reference to a particular instance in the design hierarchy. Example:
<Parameters> <ParameterItem> <Name>myRefToAnotherInstance</Name> <Val> <InstancePath> name_of_top_module.name_of_sub_instance_1 </InstancePath> </Val> </ParameterItem> </Parameters>
- Full hierarchical XML program input example:
<HierarchyTop> <Parameters> <ParameterItem> <Name>some_param_name_1</Name> <Val>>12</Val> </ParameterItem> <ParameterItem> <Name>some_param_name_2</Name> <Val>>15</Val> <ParameterItem> </Parameters> <SubInstances> <SubInstanceItem> <InstanceName>name_of_sub_instance_1</InstanceName> <Parameters> <ParameterItem> <Name>some_param_name_1</Name> <Val>5</Val> </ParameterItem> <ParameterItem> <Name>some_param_name_2</Name> <Val>3</Val> </ParameterItem> <ParameterItem> <Name>my_empty_array</Name> <Val> <ArrayType></ArrayType> </Val> </ParameterItem> <ParameterItem> <Name>my_empty_hash</Name> <Val> <HashType></HashType> </Val> </ParameterItem> <ParameterItem> <Name>some_array_param_name</Name> <Val> <ArrayType> <ArrayItem> <Val>element_1</Val> </ArrayItem> <ArrayItem> <Val>element_2</Val> </ArrayItem> </ArrayType> </Val> </ParameterItem> <ParameterItem> <Name>some_hash_param_name</Name> <Val> <HashType> <HashItem> <Key>some_key_1</Key> <Val>val_1</Val> </HashItem> <HashItem> <Key>some_key_2</Key> <Val>val_2</Val> </HashItem> </HashType> </Val> </ParameterItem> </Parameters> </SubInstanceItem> <SubInstanceItem> <InstanceName>name_of_sub_instance_2</InstanceName> <Parameters> <some_param_name_1>73</some_param_name_1> <some_param_name_2>45</some_param_name_2> <some_instance_ref> <InstancePath> name_of_top_module.name_of_sub_instance_1 </InstancePath> </some_instance_ref> </Parameters> <SubInstances> <name_of_sub_sub_instance_1> <Parameters> <some_param_name_1>1</some_param_name_1> <some_param_name_2>2</some_param_name_2> </Parameters> <SubInstances> </SubInstances> </name_of_sub_sub_instance_1> </SubInstances> </SubInstanceItem> </SubInstances> </HierarchyTop>
Additional Output File Types
Genesis2 produces some additional outputs, on top of the Verilog files: a dependent list (using the -depend depend_file_name flag), a product list (using the -product product_file_name flag), and an xml hierarchy representation of the design (using the -hierarchy hierarchy_file_name flag).
Depend List
List of the source .vp files and included .vph files that were used by Genesis2
Product List
This very important list is a list of the generated verilog (.v) files. This list is convenient, for example for use as input to downstream tools such as VCS, or for use in makefiles.
Note that the list is arranged in reverse hierarchical order which means the lowest level modules are listed first, and the top module last. The reason for this reversed order is so that it can be used for compilation.
Hierarchy Out
The XML hierarchy output representation is almost identical to the input XML program. It also has a very simple structure, but it adds more information about source and target modules and files.
In addition to providing useful feedback to the designer, the hierarchical XML was designed to be used as a template for the XML input program.
An example of a hierarchical outfile follows. Note that structure-wise:
- There are a few reserved element names: BaseModuleName, InstanceName, Parameters, ImmutableParameters, SubInstances, UniqueModuleName, CloneOf, HashType, ArrayType, ArrayItem, InstancePath. Avoid using these key words in any context other than the one explained here or in the input xml program section.
- There is a single root element which is the name of the top module of the design (since the top module is not instantiated, it is referred to by its module name and not by its instance name).
- Each element in the hierarchy may have the following sub elements:
- BaseModuleName: name of the template module before uniquification
- InstanceName: name of the instance that was generated
- Parameters: a list of parameter definitions, where the definition def of a parameter param_name would be written as <param_name>def</param_name>. More complicated data structures are also supported. See example below.
- Note that more complicated data structures are also supported: Use the <HashType> to show that a parameter is a hash rather than a string/scalar. Use <ArrayType> to show that a parameter is an array rather than a string/scalar, and the <ArrayItem> notation to express items in that array. Use <InstancePath> to express that a parameter represent a reference to an particular instance in the design hierarchy. See examples below.
- ImmutableParameters: a list of parameter definitions with the exact same structure of the previously mentioned Parameters element. However, while Parameters can be altered and re-fed into Genesis2 to create new RTL, ImmutableParameters are parameters that where already assigned a value, either using $self->force_param(...) call or at instantiation using the $self->unique_inst(...) call.
- SubInstances: A list of XML elements that represent the names of sub-instances in the current hierarchy level. The same rules apply recursively for each of these elements.
- UniqueModuleName: name of the generated module after uniquification
- CloneOf: if the instance is a clone of another instance, the field CloneOf appears instead of the fields Parameters and SubInstances. CloneOf would then have a sub-element, InstancePath, that holds the a text path to the original instance (e.g., top.dut.subinst.subsubinst).
<name_of_top_module> <BaseModuleName>name_of_top_module</BaseModuleName> <Parameters> <some_param_name_1>12</some_param_name_1> <some_param_name_2>15</some_param_name_2> </Parameters> <SubInstances> <name_of_sub_instance_1> <BaseModuleName>name_of_base_module_for_sub_instance_1</BaseModuleName> <InstanceName>name_of_sub_instance_1</InstanceName> <ImmutableParameters> <some_forced_param>5</some_forced_param> <some_inherited_param>3</some_inherited_param> </ImmutableParameters> <Parameters> <some_param_name_1>5</some_param_name_1> <some_param_name_2>3</some_param_name_2> <my_empty_array> <ArrayType></ArrayType> </my_empty_array> <my_empty_hash> <HashType></HashType> </my_empty_hash> <some_array_param_name> <ArrayType> <ArrayItem>element_1</ArrayItem> <ArrayItem>element_2</ArrayItem> </ArrayType> </some_array_param_name> <some_hash_param_name> <HashType> <some_key_1>val_1</some_key_1> <some_key_2>val_2</some_key_1> </HashType> </some_hash_param_name> </Parameters> <UniqueModuleName>name_of_generated_module_for_sub_instance_1</UniqueModuleName> </name_of_sub_instance_1> <name_of_sub_instance_2> <BaseModuleName>name_of_base_module_for_sub_instance_2</BaseModuleName> <InstanceName>name_of_sub_instance_2</InstanceName> <Parameters> <some_param_name_1>73</some_param_name_1> <some_param_name_2>45</some_param_name_2> </Parameters> <SubInstances> <name_of_sub_sub_instance_1> <BaseModuleName>neta</BaseModuleName> <InstanceName>netisnt</InstanceName> <Parameters> <some_param_name_1>1</some_param_name_1> <some_param_name_2>2</some_param_name_2> </Parameters> <SubInstances> </SubInstances> <UniqueModuleName> name_of_generated_module_for_sub_sub_instance_1 </UniqueModuleName> </name_of_sub_sub_instance_1> <name_of_sub_sub_instance_2> <BaseModuleName>neta</BaseModuleName> <CloneOf> <InstancePath> name_of_top_module.name_of_sub_instance_2.name_of_sub_sub_instance_1 </InstancePath> </CloneOf> <InstanceName>netisnt2</InstanceName> <UniqueModuleName> name_of_generated_module_for_sub_sub_instance_2 </UniqueModuleName> </name_of_sub_sub_instance_1> </SubInstances> <UniqueModuleName>name_of_generated_module_for_sub_instance_2</UniqueModule_Name> </name_of_sub_instance_2> </SubInstances> <UniqueModuleName>name_of_top_module</UniqueModuleName> </name_of_top_module>
Source Code Structure For Using Genesis2
The code structure for using Genesis2, just like in Genesis 1, is whatever target language your code should generate annotated with directives that tell Genesis2 how to expand the text.
In our case, the target language is Verilog or System Verilog. The meta language that is used on top is simply Perl. You now have the strength of Perl in your hands when you write verilog. Use it wisely.
Perl Escapes
There are two types of Perl escapes that can be used:
- Full Line Escape ( //; Perl text 'til end of line )
- This escape sequence tells Genesis2 that the entire line is Perl. To use it, simply type ' //; ' (i.e. line comment followed by a semi-colon) at the beginning of the line (white space before is also allowed).
- Note that this would look like a comment to the xemacs's (or any other editor's) Verilog mode. Hence, coloring and indentations would not be influenced.
Descriptive example:
This is regular (though not legal Verilog) text that would go directly to output. // This is also regular text that would go directly to the output as a Verilog comment. //; This is text that would be evaluated as a Perl script (and generate a syntax error ;-))
Compilable example:
assign verilog_wire = some_other_verilog_wire; // I am a verilog comment line //; my $to_be_perl_var = "This is Perl";
- Part-Of-Line Escape ( ' Perl text between left-single-quotes ' )
- This escape sequence tells Genesis2 that a part of the line, which is delimited in-between two ' ' ' (i.e. grave accent) signs, is to be evaluated using the Perl interpreter. Unlike the full line escape, in the partial line escape, the result of the Perl evaluation is to be printed to screen.
- Note that this would look like a "tick-define" to the xemcas's (or any other editor's) Verilog mode. Hence, coloring and indentations would not be influenced.
//; my $width = 5; assign some_wire[`$width-1`:0] = some_other_wire[`$width+9`:10]; //; foreach my $idx (0,1,2,3){ assign wire_`$idx` = wire_`($idx+1)%4`; //; }
Which will produce:
assign some_wire[4:0] = some_other_wire[14:10]; assign wire_0 = wire_1; assign wire_1 = wire_2; assign wire_2 = wire_3; assign wire_3 = wire_0;
- Note About The Perl print Function: It is some times convenient to use the built-in Perl print function. Note that for convenience, printing is done by default to the output file (i.e. the Verilog modulename.v file). If you wish to print progress or debug statements that need to go to the screen use print STDOUT "your text here\n" or print STDERR "your text here\n".
Special Built-in Methods
As mentioned before, the entire effort of creating a tool like this is to enable scopes, enhanced parametrization and most importantly uniquification of modules. For this reason, there are a handful of pre-built Perl methods that were defined.
There are no other directives you need to remember. It is all Verilog annotated with Perl from here on.
Data Structure Related Methods
- sub get_parent
- Returns a pointer to the parent instance
//; my $parent = $self->get_parent();
- sub get_subinst
- Returns a pointer to the object of a sub instance (by name)
//; my $subinst_of_someinst = $someinst->get_subinst($subinst_name);
- sub get_subinst_array
- Returns a handle to an array of sub instance objects that match a pattern
//; my $subinsts_of_someinst = $someinst->get_subinst_array($pattern);
- sub get_instance_path
- API method that returns a complete path to the given instance object. An instance path has the strict format of <top_module>.<subinst>.<subsubinst>.... For example: top.dut.regfile.addr_flop.
//; my $inst_path = $inst_obj->get_instance_path();
- get_instance_obj
- API method that accepts an instance path (or an instance object) and returns the corresponding instance object. An instance path has the strict format of <top_module>.<subinst>.<subsubinst>.... For example: top.dut.regfile.addr_flop.
//; my $inst_obj = $self->get_instance_obj($inst_path);
Parametrization Methods
- sub define_param
- API method for defining a new parameter (just like defining a parameter in verilog). Note that using the define_param, parameters can only be defined inside the module to which they belong (i.e., $some_inst->define_param(prm_name => prm_val) will cause a genesis generation error). However, parameters can also be defined at instantiation using the unique_inst method as shown below. Definition at instantiation time overwrites definitions done within the module (just like in verilog). As a middle ground, parameter definitions that are not bounded by instantiation can be set using the input XML configuration file. More details can be found here.
- In this example, the parameter is registered with name prm_name and receive the value prm_val. The value is also returned to the Perl variable $val.
//; my $val = $self->define_param(prm_name => $prm_val);
- sub define_param_array
- This API method is very similar to the previously mentioned define_param, only it forces the parameter value (the returned value) to be an array reference. It is convenient to use it if you know that the parameter is an array but are afraid that someone may use a single value array (which in xml has the same representation as a scalar).
//; my $val = $self->define_param_array(prm_name => [prm_val1, prm_val2, ...]);
- but this should work as well (returning an array of size 1):
//; my $val = $self->define_param_array(prm_name => prm_val1);
- sub force_param
- API method for defining an IMMUTABLE parameter. This is pretty much the equivalent of the localparam keyword in Verilog. It defines a parameter which means other modules (up or down the hierarchy) can query its value using the get_param method (see next definition). However, this parameter definition is immutable---it cannot be altered, neither at module instantiation nor through the XML configuration file.
//; my $val = $self->force_param(prm_name => $prm_val);
- sub get_param
- API method for extracting a parameter's value from the parameter's registry. This sort of definition is useful if your module needs to read a parameter from a different module:
//; my $val = $other_module->get_param('prm_name');
- and also if you don't want to define a value but you want to force someone else (either an instantiator module or an xml entry) to define this parameter (since if neither of them define the parameter prior to you extracting it, an error would be thrown).
//; my $val = $self->get_param('prm_name');
- sub get_top_param
- API method for extracting a parameter's value from the top level parameter's registry.
//; my $val = $self->get_top_param('prm_name');
This is equivalent (but much shorter) to:
//; $tmp = $self; //; while (defined $tmp1){ //; $tmp2=$tmp1; //; $tmp1=$tmp1->get_parent(); //; } //; my $val = $tmp2->get_param('prm_name');
Module Instantiation Methods
- sub generate
- This is syntactic sugar for $self->unique_inst(...)---the main function call for generating (and later instantiating) a new module (described below).
//; my $newObj = generate(base_module_name, inst_name, prm1 => val1, prm2 => val2, ...);
Example: Before (SystemVerilog)
Adder#(.w(8),.n(4)) MyAdder(.in1(a),.in2(b),.out(c));
Example: After (Genesis2)
//; my $my_adder = generate('Adder', 'MyAdder', w=>8, n=>4); `$my_adder->instantiate` (.in1(a), .in2(b), .out(c));
- sub unique_inst
- The main function call for generating (and later instantiating) a new module. Note that this call on its own would not print anything to the output module. Rather, it will return a pointer to the instance module ($unique_inst in the code bellow). Use the $unique_inst->instantiate() and other methods as described above to query this new module and then decide what to print to the generated module code.
//; my $newObj= $self->unique_inst(base_module_name, inst_name, prm1 => val1, prm2 => val2, ...);
Example: Before (SystemVerilog)
Adder#(.w(8),.n(4)) MyAdder(.in1(a),.in2(b),.out(c));
Example: After (Genesis2)
//; my $my_adder = $self->unique_inst('Adder', 'MyAdder', w=>8, n=>4); `$my_adder->instantiate()` (.in1(a), .in2(b), .out(c));
- sub clone
- This is syntactic sugar for $self->clone_inst(...)---A method for replicating a module based on an existing instance.
//; my $clonedObj = clone($src_inst, 'new_inst_name');
- sub clone_inst
- An API method for replicating a module based on an existing instance (i.e., get a handle, or object, which is another instance/copy of an existing one).
//; my $clonedObj = $self->clone_inst($src_inst, 'new_inst_name');
Note that <src_inst> can either be a path (e.g., top.subinst.subsubinst) or it can be just an instance object (like the ones returned by unique_inst or clone_inst)
Auxiliary Methods
- sub include
- includes a (header) file inline with your text
//; include("some_header_file.vph");
- sub get_instance_name
- Returns the name of the current instance
//; my $someObj_inst_name = $someObj->get_instance_name();
Example: Before (SystemVerilog)
Adder#(.w(8),.n(4)) MyAdder(.in1(a),.in2(b),.out(c));
After (Genesis2)
//; my $my_adder = generate('Adder', 'MyAdder', w=>8, n=>4); `$my_adder->get_module_name()` `$my_adder->get_instance_name()` (.in1(a), .in2(b), .out(c));
Also see sub instantiate, below.
- sub iname
- Syntactic sugar for get_instance_name()
//; my $inst_name = iname(); OR //; my $someObj_inst_name = $someObj->iname();
Example: Before (SystemVerilog)
Adder#(.w(8),.n(4)) MyAdder(.in1(a),.in2(b),.out(c));
After (Genesis2)
//; my $my_adder = generate('Adder', 'MyAdder', w=>8, n=>4); `$my_adder->mname()` `$my_adder->iname()` (.in1(a), .in2(b), .out(c));
Also see sub instantiate, below.
- sub get_module_name
- Returns the uniquified module name. This task is especially important since whenever we declare a new module we don't really know whether or not it is going to be uniquified, and how many uniquifations of this module already happened. This enables us to leave the dirty work for Genesis.
//; my $module_name = $self->get_module_name(); module `$module_name` (input logic Clk, ... ); // parameterized module code comes here endmodule
- sub mname
- Syntactic sugar for get_module_name
module `mname` (input logic Clk, ... ); // parameterized module code comes here endmodule
- sub instantiate
- Syntactic sugar for $obj->mname() obj->iname() --- I.e., the module and instance name of $obj for the purpose of instantiating that module.
module `mname`(input clk, ...); // some parameterized module code comes here // Let's generate and instantiate an ALU module: //; my $ALU = generate('ALU', 'ALU_U', param1=>val1, param2=>val2,...); `$ALU->instantiate` (.clk(clk), .arg1(vector1), .arg2(vector2), .cmd(operation), .result(result)); // more parameterized module code comes here endmodule: `mname`
- sub error
- Prints an error message and exits with a printout of the current file and line
//; $self->error("some error message");
- sub warning
- Prints a warning message and a printout of the current file and line. Does NOT exit.
//; $self->warning("some message");
Useful Debug Hints
- Debug level
- In order to see more verbose messages from Genesis during elaboration use the flag -debug n where n is the verbosity level.
- Error and warning messages
- It is always a good habit to check the input (that can many times come from a user filling an xml form), and printing errors or warnings accordingly. See the section about Auxiliary Methods for the use of the error and warning predefined methods.
- Debug messages to the verilog file
- If you want to print debug messages during elaboration, such that they go to the output verilog file, one way is to just use simple text with inline Perl escapes, since simple text is printed to the verilog file by default. You can make these statements a verilog comment so they don't disturb compilation.
1. This text goes as is to the verilog file... but would cause a verilog compile error since it's not legal verilog // 2. This text also goes to the verilog file... but no compile errors this time since for verilog it's a comment //; print "3. This is a Perl print command that prints this line to the verilog file... expect verilog compile errors...\n"; //; print "// 4. This is also a Perl print command. This text also goes to the verilog file... no compile error this time\n";
- Debug messages to the screen
- If you want to print a debug message to the screen (printed during elaboration time), use one of the following...
//; print STDOUT "This message goes to standard output. It does NOT go to the verilog file\n"; //; print STDERR "This message goes to standard error output. It does NOT go to the verilog file\n";
A Word About Genesis2 Elaboration Order And Parameterization
Genesis2 elaboration order and parametrization priorities are identical to Genesis 1.
Elaboration is done as a depth-first search of the hierarchy. That is, the top module would start to be elaborated, until the first unique_inst call is encountered. Then Genesis2 will recursively turn to elaborate the module which is being instantiated. This process repeats recursively, until the leaf instances are elaborated. (Behind the scenes, this strategy makes it very easy to first generate the lower levels of the hierarchy, uniquify when needed, and then tell the upper levels what is the name of the uniquified module and instantiate it.)
Parametrization is also quite simple: 1) A parameter can be defined in a module using the define_param method mentioned above. 2) Parameters can be either added or overwritten by the external XML/configuration file. 3) Finally, parameters can also be added or overwritten at instantiation time (this is similar to Verilog 2001). This means that:
- Defining a parameter inside the module code using define_param has the lowest priority (GENESIS2_DECLARATION_PRIORITY => 1)
- External input priority overrides the original module code (GENESIS2_EXTERNAL_CONFIG_PRIORITY => 2)
- A parameter that is assigned at instantiation is assumed to be highest priority to make sure that the instantiated module is compatible with the instantiating module (GENESIS2_INHERITANCE_PRIORITY => 3)
The rationale is that this enables the designer to give default values to parameters. It enables changing those values later from external configuration files (for example by picking them using an optimizer). But it also enables forcing of the parameter values by the instantiating module if compatibility is required (for example interface bit-widths).
- Note that these are the only ways to set parameters values! Querying the values of parameters can be done at any point, once the instance has been created of course (using the unique_inst method.
- Note that parameters behave as constants! When you assign/get a parameter value, the value is being copied (deep copy if the parameter is a reference to a data structure).
- Note that you can use constants to communicate values to parent modules (not just to sub-instances)! Once a parameter is defined, it can be read from anywhere in the hierarchy using the unique module object (e.g., //; my $param_from_someone_else = $someone_else_instance->get_param('param_name');).
Invoking The Genesis2 Tool
Genesis2 is located in $SMASH/bin/PerlLibs/Genesis2/Genesis2.pl. For help on using the script type Genesis2.pl -help.
Note that though there are two distinct stages in Genesis2: parsing and generation. One can call the script once with both the -parse and the -generate flags on. Genesis2 would perform parsing and then move immediately to generating.
Parsing Mode
Parsing mode performs the first transformation, from Verilog annotated with Perl code (.vp files) to an object oriented set of Perl packages. Each Perl module (.pm file) is a code generator for its corresponding verilog module (.v file), but verilog generation is not yet done at this stage.
Usage: ./Genesis2.pl [-option value, ...] Parsing Options: [-parse] # Parse input file and generate perl modules [-sources|srcpath dir] # Where to find source files [-includes|incpath dir] # Where to find included files [-input file1 .. filen] # List of top level files # The default is STDIN, but some functions # (such as "for" or "while") # may not work properly. [-depend filename] # Generate a dependency file list (list of input files) [-perl_modules modulename] # Additional perl modules to load
Generation Mode
Generation mode is the stage where Genesis2 is asked to start doing the actual elaboration starting from some specified top level (does not need to be the absolute top level of your design). This is when the .pm files generate the .v files.
Usage: ./Genesis2.pl [-option value, ...] Generating Options: [-generate] # Generate a verilog hierarchy [-top topmodule] # Name of top module to start generation from [-product filename] # Generate a product file list (list of output files) [-hierarchy filename] # Generate a hierarchy representation tree [-xml filename] # Input XML representation of definitions [-perl_modules modulename] # Additional perl modules to load
Help and Debugging
Usage: ./Genesis2.pl [-option value, ...] Help and Debuging Options: [-debug level] # Set debug level [-help] # prints the script's usage message [-man [extension_name]] # prints the complete man page for Genesis2 or the # specified extension (e.g. -man Math)
- I have not written the man content yet. So it is likely to print zip.
Sample Graphical User Interface and Demo
Click here for interactive chip generator GUI and demo based on Genesis2.
Extending Genesis2 With Homemade Perl Libraries
One of the best things about using Perl as the language on top of Verilog, is that it is very easily extended. This means that one can use any Perl library in the world as part of the knowledge base that create a module's micro-architecture.
Adding A Perl Built-in Library
Simply put a "\\; use LibraryName;" in your text, just as you would do for any Perl script. Example of using the POSIX library (used for the mathematical ceiling function):
//; # More Perl Libraries //; use POSIX; //; my $reg_list = $self->define_param(REG_LIST => [ {name => 'regA', width => 5, default => 17, IEO => 'ie'}, //; {name => 'regB', width => 10, default => 27, IEO => 'o'}, //; {name => 'regC', width => 15, IEO => 'ieo'}, //; {name => 'regD', width => 31, IEO => 'ieo'}, //; {name => 'regE', width => 32, IEO => 'ieo'}, //; ]); //; my $num_regs = scalar(@{$reg_list}); //; my $num_addr_bits = POSIX::ceil(log($num_regs)/log(2)); // Verilog code for the module module `$self->get_module_name()` ( input Clk, input Reset, input [`$num_addr_bits-1`:0] Addr, ... ); endmodule // `$self->get_module_name()`
Adding Your Own Perl Library
Assuming your homemade Perl package is called MyLib.pm, place it in the folder $SMASH/bin/PerlLibs/Genesis2/Auxiliary/ (you can also place it under $SMASH/bin/PerlLibs/ if this is a generic Perl library which is not specific for Genesis2 usage).
There are two ways for your Genesis2 modules to get the functions of a home-made library into their name space:
- Typical Perl "use" system: (preferred way for not polluting the name space)
- In your module (e.g., your file flop.vp) add a line that reads "use TypeConv". Now you can call TypeConv::funcName(args). If you want some (or all) of the functions to be embedded in the name space, you can also add their names to the EXPORT or EXPORT_OK lists. (As an example, the file $SMASH/bin/PerlLibs/Genesis2/Auxiliary/TypeConv.pm has these lists marked with "METHOD 1 FOR INHERITING ALL METHODS"
- Inheritance:
- You can tell all Genesis2 modules to inherit methods from this module. In order to do that, we force the UniqueModule (which is the base class of all Genesis2 modules) to inherit from this module. Then, given a method with name methodName, each and every module in Genesis would be able to call it by invoking $self->methodName. To activate this inheritance follow these two steps:
- Push the current package into the ISA inheritance array of the base module UniqueModule. (As an example, see in the file $SMASH/bin/PerlLibs/Genesis2/Auxiliary/TypeConv.pm, the Perl lines that are annotated as "METHOD 2 FOR INHERITING ALL METHODS").
- Either add "use TypeConv;" to your Genesis2.pl script at the appropriate location, which would force this library to always be used. Or, use the Genesis2 flag "-perl_modules TypeConv" on your command line.
Behind The Genesis2 Curtain
The Genesis2::Manager and Genesis2::UniqueModule Objects
One day I'll find the time to write this. Not today though :-))
Shacham 14:33, 11 March 2011 (PST)


text:
5 months
5 months, already?! Yes, and he's not slowing down.
Israel loves his little high chair, even though he's not
eating solid foods yet and needs a blanket to help prop
him up. He loves banging almost anything violently against
the tray. What a boy!
Other Stories
6 comments:
so. freaking. precious. :)ReplyDelete
oh man, so cute. growing up so fast!ReplyDelete
Such a cutie. And I love his name.ReplyDelete
Thanks for your sweet comments on my blog!
I can't believe you got French macaroons for Valentine's Day. Laduree's are my favorite- if yours were from there I am even more jealous!
I adore the style of your home.
Wow, Jenn he is getting so big!! He is so adorable!ReplyDelete
What a cutie!!! xxReplyDelete
He is mighty cute and I adore the Miffy books. Just found your blog and it's so fun!ReplyDelete
Thank you for your comments, I love hearing from you!
Questions, comments or sponsorship inquires, please contact me via the 'contact' link.


text:
twentytwentyone are constantly sourcing new designs, here you can view the latest additions.
The Calmo Sofa by Hugo Passos effortlessly combines comfort and customisation. The understated yet elegant design features clean lines and restrained curves, exemplifying a calm, contemporary simplicity.
The latest addition to the Barber & Osgerby Hotaru collection are table and floor lights, launched at the London Design Festival 2019.
Gifts and accessories
In this vibrant new series of posters, Ronan Bouroullec further explores his signature interest in vibrant colour and organic forms.
The Operators, Office, Shoreditch, London
Standard chair
Applique a Volet Pivotant
Anglepoise Type 75 task
Subscribe to our newsletter
Join us on...
twentytwentyone 2014


text:
Assessor Info & Maps
Online Parcel Search:
Tehama County's Online Parcel Search is an up-to-date county resource for checking secured-roll property values, land values, improvement values, and more.
Secured Roll Property Values:
Current secured roll property values are available online, as well as the current assessor parcel map for your area. The secured roll value is the assessed value used for tax purposes in the current fiscal year.
Property Information:
This property search tool will allow you to find your property by the assessor's parcel number (APN) or by street address. Some parcels, such as vacant land, do not have street addresses, so you will need to use the APN for your search. The parcel detail screen will show your APN, property situs address, and abbreviated legal description. The values section will include land value, improvement value, any exemption amount and the total assessed value.
Assessor Parcel Maps:
Parcel maps are grouped by book-page-parcel. These correspond to the first three parts of your APN. For example, the map containing APN 036-110-15-1 would be referred to as Book 36, Page 11. On that Page, Parcel 15 would be yours.
Clicking the Online Parcel Search link will direct you to an off-site data service. Some of the data on this site does come directly from the Tehama County Assessor and is frequently updated. While we have a high confidence in the accuracy of this data, we can not be held liable for any errors, omissions, or inaccuracies. Neither the Tehama County Assessor nor the County of Tehama have any role in establishing the fees found on this site. The County Assessor and the County of Tehama assume no responsibility arising from use of this information.
Click here to Search Parcel Map