Re: Verilog/ASIC development support is insufficient in git , help!

From: Christian MICHON <christian.michon@gmail.com>
Date: May 11, 2008, 09:21 UTC
Message-ID: <46d6db660805110221y1207974dt3be709e1b67cf3d6@mail.gmail.com>
In-Reply-To: <BA7F9A3C7EDA4CDD99016093B0DB55C0@justinuTop>

On Sun, May 11, 2008 at 7:08 AM, Justin Leung <jleung@redback.com> wrote:

> Hi all,
>
> * This email probably represent the whole hardware ASIC community about git
> *

I'm an ASIC designer too.

> here are the things not fitting right in ASIC dev:
>
> - no incremental revision numbers (they are so scared of the 40hex SHA1)

this is unimportant: if they want to track a specific release of a file, it's better to look at what was the file's content from this cut to that cut.

>
> - Inability to reference without SHA1, they want simple numbering (ie,
> version 100, 120, 120.1, 130.4.5)

this is where tags and branches are useful to point to a specific release/cut.

>
> - Inability to refer to a file by a simple number
> (the backend guys will be confused by SHA1; they can't work with anything
> more than 4-5 digits)

same answer

>
> - Complexity of commands (although we can have warpper, but real git
> commands for non-sw guys is not going to happen)

just use gitk and git-gui: almost all can be done with these two graphical tools.

>
> Most hardware chip designers were using CVS since their first job.
> It suited the purpose very well.

for linear development, yes. but when we were requested to perform maintenance on a specific old cut, this was becoming a nightmare.

Show 10 quoted lines

>
> Most RTL design veterans only use less then 5-6 cvs commands in their whole
> life (LOL, i m serious) :
>
> $ cvs checkout
> $ cvs update
> $ cvs log
> $ cvs diff (tkdiff)
> $ cvs status
> $ cvs commit

gitk, git-gui: two commands (actually gitk can be called from git-gui)

>
> We don't use branches.

this is the wrong approach.

> Our model is strict forward with a centralized, one main branch model to
> avoid mistakes .
> We see branches as evil ; some merges in Verilog codes means another 10+
> hours of simulation and regression.

use branches to reference the different ressources (rtl, simulation, layout). then track these branches between them for deliveries and work/flow.

use tags to mark specific releases/cuts.

> - 'git-show-branch' actually show reversed serialized version numbers (we
> want it the other way, accending)

you can create an alias: git-show-branch | tail -r

> - 'git-describe' gives you commit numbers since your last annotated tags (
> ie, git-5423-g7def45b)
>
> so, i understand that a simple numbering scheme can be done .

yes, I used to be scared by sha1 too: I even created numbered tags for each commit. Until I read more about git, and stopped expecting using git as svn/cvs.

>
> I truly hope that the in the main repository model of git this can be turned
> on by a switch or in the git config .

no, it would kill the right approach: embrace the index, and never look back.

>
> Is it too complicated to incorporate this model ?

you have to adapt your methods instead: trust another ASIC designer :-)

-- 
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !