EDA Marketing Problem

I started out trying to write an eloquent essay on the merits of different ways of sharing new ideas and information in order to further the art of digital design verification (in other words, how to market this stuff), but I couldn't make it sound right. Instead, let me just point to some recent examples:

Good examples


Namespaces, Build Order, and Chickens

Cadence's UVM video series

These are brief and to-the-point. If you have a question, they quickly give you answer. If you are taking 2 or 3 minutes to browse the internet while waiting for a simulation to finish, maybe even on your phone while you take a little time away from your desk, you can get all the info in that time. Perfect.

Examples of Ideas That Could be Marketed Better


Monitoring signals by name, for the UVM register package and more

and:

A 30 Minute Project Makeover Using Continuous Integration

First of all, kudos to Verilab for sharing ideas, knowledge, and source code as much they do. The next section of this document could be, Example of People that Don't Share Knowledge At All and it would be huge, but, you know, there'd be nothing to link to. So, I do not intend to disparage or discourage, rather to point out some areas for improvement. With both of these gems, first of all, I wasn't even sure what exactly I should link to. The PDF directly? The paragraph of text introducing the link to the PDF? Or should I link to the blog entry that links to the introduction text that links to the PDF? Next, the length. The first is a 20 page PDF, the second is 7 pages. If you really want to spread knowledge and advance the art, get to the good stuff quickly! My simulations don't take that long to run. I was about to say more on this, but I'm going to follow my own advice. I'll expound in the comments if you ask me to. Finally, PDFs. Really? This is the internet. Use html. Everything can reformat and display html nicely enough, desktops, laptops, phones. Even printers. PDFs, not so much.

In conclusion, I love that people in the EDA world, and in verification specifically, are sharing more and more information on the internet. It can be even more effective and help advance the art further if we do so in a modern internet-y way using good marketing techniques.

Comments

Anonymous said…
Bryan,
Nice points. As the author of one of the "too long" pieces you pointed to, perhaps you'll let me respond!
First, the PDF-vs-HTML thing. Yes, I take your point. But PDF is truly portable, renders reliably the same way on many platforms, and falls naturally out of my document creation process (it was a conference paper, after all). Writing HTML isn't hard. Writing HTML that will render the way I want it to, on any platform and resized any-old-how, is harder and I just don't have the skill or time to do it. (Yeah, I know, find someone who does. Fair point.)
As far as the length is concerned, I'm guilty as charged. There's quite a bit of pressure on someone writing a conference paper to make it unambiguous, relatively formal, and as comprehensive as possible. Combine that with my own tendency to overwrite and yes, you get something that's too long and should probably have been rewritten for web publication. But life's just too short, it's not my day job, and it's surely better to get the stuff out somehow than not at all.
None of this makes your comments any less relevant. Will Do Better Next Time, and thanks for the thoughts!
Jonathan Bromley, Verilab
June 1, 2012 at 2:45 AM
Bryan said…
Jonathan, of course you may respond! I appreciate it.

Honestly, for me personally, I like to read, so the length doesn't bother me too much. That being said, I still haven't made it through all of your paper yet, even though I really want to.

As for the PDF issue, you just need to take a deep breath, and let go. :-) Relax. Don't worry about your content rendering exactly the way *you* want it to. It's actually better to give the consumers of the information the ability to reformat it to their liking. Case in point: my eyes aren't that great. I usually need to increase the font size of whatever I'm reading online. When I zoom in on a PDF, it doesn't re-wrap the text, so on a small screen like my phone that means I have to scroll side-to-side to be able to ready it. Very annoying.

And conference papers. I don't know. Do authors like that style? Do readers? Are conferences trying to be scientific journals? Is it something that made more sense before the internet made it easy and free to throw a paragraph or two up on a blog and then to discuss things with those that are interested directly?
June 1, 2012 at 7:43 AM
Anonymous said…
As I'm also in the 'guilty' bin.

Just finished a SNUG paper. I guess it'll be coming out in a few weeks. It was written in MS Word (because the destination required it) The formatting, particularly moving between versions of Word on a Mac and Windows was ridiculously painful. The document is largely straight text and source code examples - yet the formatting would vary wildly between versions (adding and removing 20 pages in format/spacing changes)


So the paper is submitted, the PDF has been generated - is it 'worth' turning into an HTML paper?
August 16, 2013 at 7:53 AM
Post a Comment

Popular posts from this blog

SystemVerilog Fork Disable "Gotchas"

This is a long post with a lot of SystemVerilog code. The purpose of this entry is to hopefully save you from beating your head against the wall trying to figure out some of the subtleties of SystemVerilog processes (basically, threads). Subtleties like these are commonly referred to in the industry as "Gotchas" which makes them sound so playful and fun, but they really aren't either. I encourage you to run these examples with your simulator (if you have access to one) so that a) you can see the results first hand and better internalize what's going on, and b) you can tell me in the comments if this code works fine for you and I'll know I should go complain to my simulator vendor. OK, I'll start with a warm-up that everyone who writes any Verilog or SystemVerilog at all should be aware of, tasks are static by default. If you do this: module top; task do_stuff ( int wait_time); #wait_time $display ( "waited %0d, then did stuff" , wa...
Read more

'git revert' Is Not Equivalent To 'svn revert'

I just learned that if you have some changes in your working tree that you want to get rid of, you don't type 'git revert' like you might guess. No, that's what cvs, subversion, mercurial, and bazaar (to name a few) use revert to mean, but not git. With git, revert is used to undo actual commits. Thankfully, you can undo your revert with another 'git revert', I just learned. So let me repeat to be clear, if you have changes to your working files that you want to abandon, DO NOT do this: git revert HEAD That will undo your last commit. Do this instead: git reset --hard HEAD I'm glad I have that straightened out now. I'm wondering if /etc was really a good place for me to start out playing with git. UPDATE: Nearly two years later and I'm still getting comments on this. I'm glad I've been able to help people out this way. The discussion in the comments is good, and one thing I'd like to point out is that I now always use...
Read more

SystemVerilog Streaming Operator: Knowing Right from Left

SystemVerilog has this cool feature that is very handy for converting one type of collection of bits into another type of collection of bits.  It's the streaming operator.  Or the streaming concatenation operator.  Or maybe it's the concatenation of streaming expressions (it's also called pack/unpack parenthetically).  Whatever you want to call it, it's nice.  If you have an array of bytes and you want to turn it into an int, or an array of ints that you want to turn into an array of bytes, or if you have a class instance that you want to turn into a stream of bits, then streaming is amazing.  What used to require a mess of nested for-loops can now be done with a concise single line of code. As nice as it is, getting the hang of the streaming operator is tough.  The SystemVerilog 1800-2012 LRM isn't totally clear (at least to me) on the details of how they work.  The statement from the LRM that really got me was this, "The stream_operator <...
Read more