There’s still time to win a $15 Amazon gift card by participating in the annual “ASIC Prototyping with FPGAs” survey. The deadline for responses is Thursday, June 28, 2012.

Redux: The Interface - Beware the Jabberwocky!

Redux means to bring back, to restore. That's what I'm doing with my pre-blog IEEE columns from the late 90's. These columns were written when the term "blogging" was just starting to enter our collective consciousness. More than merely a stroll down memory lanes, these columns offer a glimse as to how much we've advanced thanks to the Internet - or how little. But enough pontificating. Let the redux begin! - JB

"Beware the Jabberwocky ..."
by Lewis Carroll, Alice in Wonderland

Not again, thought Bill! Another unreadable email message. Well, not unreadable, but certainly unintelligible. Just an apparent random jumble of common keyboard characters; letters, numbers, forward and back slashes, pluses and minuses, brackets and periods. It seemed like some kind of code, but one to which he had no key ... or clue. He did, however, know where to find a clue, and immediately moved his computer's mouse to rest on the email icon. Many years ago, when Bill was a struggling undergraduate student, he chanced upon a strange but knowledgeable hacker on the Internet, an person who went simply by the initials BC, a non de Usenet, as Bill was to learn latter. Bill had maintained his contact with BC every since, communicating with his cyber-tutor via email whenever he had a tough question to be answered. BC was not always reliable, often responding with an answer as puzzling as the question. Nevertheless, BC would usually come through, after enough cajoling.

Bill forwarded his unintelligible email message to BC, commenting on the fact that he had no idea what to do with it. A short time later his computer beeped BC's reply: "Read the crud, then begin at the beginning"! Bill stared dumbfoundedly at the message. "What the @#%$ is that supposed to mean", he said aloud, little realizing that his expletive contained these key. Bill knew, from painful experience, that asking BC for clarification would result in silence or a "flaming" retort. Crud, though Bill, certainly sounds like a hackers term. His hands involuntarily reached for the Hacker's Dictionary [1] and, after a few false starts, found what he sought:

cybercrud: /si:'ber-kruhd/ /n./ 1. [coined by Ted Nelson] - Obfuscatory tech-talk. Verbiage with a high {MEGO} factor. The computer equivalent of bureaucratese. 2. Incomprehensible stuff embedded in email. First there were the "Received" headers that show how mail flows through systems, then MIME (Multi-purpose Internet Mail Extensions) headers and part boundaries, and now huge blocks of hex for PEM (Privacy Enhanced Mail) or PGP (Pretty Good Privacy) digital signatures and certificates of authenticity. This stuff all services a purpose and good user interfaces should hide it, but all too often users are forced to wade through it.

Bill opened the unintelligible email message again and, after reading through the cybercrude, came upon the MIME header information:

This is a multi-part message in MIME format.
--------------6A118D532C4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------6A118D532C4
Content-Type: application/octet-stream; name="mystery.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="mystery.txt"
--------------6A118D532C4--
Section 1/1 file mystery.txt [ Wincode 2.7.3 ]

begin 644 mystery.txt

M`0,!"P`%(````6`````>$```->@``"`@``````````"\$"``T`.@0)(#H$25
M*B`"E`*@!)0"0`H7``%0U"+@``,```C"`&((@)```0*```0!````0```"@$`
M``!``/$Y`0```$```(N<(mailto:Z%60@0%60#KQP$```!``2CC`0```)WCOV@O```(KA7B

Still uncertain as to the meaning of this header, he consulted the Internet, searching on the terms encode, decode and MIME. He found many URL's that contained much information. After reading though a few white papers, Bill slowly began to understand the header layout. The encrypted data, for example, started after the "begin" line [begin 644 mystery.txt], hence BC's admonishment to begin at the beginning. The "begin" line itself contained useful information, in this case, indicating that a mode-64 encoding scheme was used to encode a file named "mystery.txt". Of course, this same information was also provided in the MIME header that preceded the "begin" line. The section number [Section1/1] revealed that the file was complete, that is, there were no other parts to the file "mystery.com". Bill remembered reading that most email servers limit the size of an attached message file to 1 MB. Thus, bigger files were split into x number of 1 MB attached files that must be concatenated before decoding. What a pain, thought Bill.

His attention wandered back to the cryptic nature of the encoded file, readable yet incomprehensible. An earlier search of the Internet had yielded several papers that discussed the more popular encoding schemes for converting 8-bit BINARY files to 7-bit ASCII files through a process known as bit-shifting. Since almost all PC-based networks use ASCII-based communication protocols, all transmission had to be in ASCII format. Bill noted the two most popular methods for allowing binary data to be accurately and reliably transmitted through the Internet email system:

1. Base64 - Used by MIME (Multipurpose Internet Mail Extensions) conformant a-mail programs as a way to attach binary data to ASCII email. Developed under guidelines of FRC 1521.
2. BINHEX - A popular encoding algorithm used mainly on Apple Macintosh computers. Developed under guidelines of RFC 1741.

In addition to white papers on various encoding algorithms, Bill also found several utilities designed to encode and decode programs. Using one of these, called WinCode [2], Bill decided to get some "hands on" experience. He opened a text editor and typed in the following test pattern:

AbcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVXWYZ1234567890

He saved this file, in text form, as "uue-test.txt". Next, using WinCode, he uuencoded this file. Opening the resulting file, uue-test.uue, in a text editor, revealed the following:

-------------------------------

section 1/1 file uue-test.txt [ Wincode 2.7.3 ]

begin 644 uue-test.txt

M86)C9&5F9VAI:FML;6YO<'%R7I!0D-$149'2$E*2TQ-3D]045)315%565UA96C$R,S0U-C

`

end

sum -r/size 21107/62

section 1/1 file uue-test.txt [ Wincode 2.7.3 ]

-------------------------------

Now, he thought, lets see what this encoding scheme is all about. He decided to work through the encoding technique himself, following the procedure he had found earlier during his information search on the Internet [3]: "UU-encoding is a way to code a file which may contain any characters into a standard character set that can be reliably sent over diverse networks. The basic scheme is to break groups of 3 eight bit characters (24 bits) into 4 six bit characters and then add 32 (a space) to each six bit character which maps it into the readily transmittable character."

First, Bill needed a table of ASCII character sets to tell him the equivalent decimal and binary values for the standard English alphanumeric characters. An old Engineering-in-Training (EIT) handbook provided the table. Then, grabbing the discarded envelope, he began to encrypt:

Adding an extra zero as the front of each of the 7-bit binary values, he now had the first 3 eight bit characters (24 bits - Modulo 64) group. These he divided into 4 six bit characters and converted back to decimal equivalents, before adding 32 bias to each, as follows:

011000 --> 24 + 32 == 56

010110 --> 22 + 32 == 54

001001 --> 9 + 32 == 41

100011 --> 35 + 32 == 67

Once again, Bill referred to the ASCII character set table to translate these decimal values back into the equivalent character set:

56 --> 8

54 --> 6

41 --> )

67 --> C

The first few characters of the first line of his uu-encoded test file should be: 86)C. Much to his surprise, Bill found that this was correct, with one slight hitch; the first line started with the character M. A quick glance back at the references he found on the Internet revealed that most lines, in a uu-encoded file, start with an M. This represented the number of encoded characters in the line, i.e., 45. Of course, he thought, the ASCII equivalent for 45 (+32) is M. So, the correct encryption, for the first few characters at least, was indeed as he had calculated:

M86)C

Although his encryption test had been performed using alphanumeric characters, but the technique should work as well for non-ASCII character set, e.g., binary files such as executable programs (*.exe), images (*.gif), postscript (*.ps) and program specific word processors (*.doc, *.wp).

This exercise had also revealed the answer to a phenomenon that Bill had often observed with uu-encoded files; the process of uu-encoding increases the size of the file. Here, for example, the first three characters of Bills test program (uue-test.txt) had required 3 eight bit characters, for a total of 24 bits (3 bytes). After uu-encoding, that number had swollen to 4 eight bit characters (6 + 0 + 0), for a total of 32 bits (4 bytes), an increase of 33%.

Being pleased with his new understanding, Bill was ready to deal with the unintelligible email message that had started this whole problem. First, he saved the email message to a file, then using WinCode, he decoded the file. Since the decoded file, mystery.txt, had the extension -txt, he open a word processing application to view its contents. He quickly skimmed over the document, then paused and stared, thoughtfully, off into the distance. After a few moments, he closed the file and deleted all traces of its existence from his hard-drive. Next, he opened his email program and forwarded a copy of the original message to his home email address, before deleting the original message. Again he paused, then, smiling slightly, he typed the following email message

Thanks, BC. Don't tron out. BCNU. -- Bill [4,5]

His smile widened as he laughed quietly. He, too, could eschew obfuscation by using the jargon of the net. No, he thought, that's not correct. His meaning was clear to netizens, those people who live on the net, communicating with a language that had evolved out of the shared cinematic and cybernet experiences of the collective. Now there was a frightening thought, he murmured, as the computer hummed unnoticed under his desk.

References:

[1] The on-line hacker Jargon File, version 4.0.0, 24 JUL 1996, [jar400.txt].

[2] WinCode v2.7.3, Multi-Purpose Encoder/Decoder for Windows, Snappy_Software (Freeware), by George Silve, 1993-1996.

[3] Richard Marks, http://w4.lns.cornell.edu/~puhpl/UUSER.TXT

[4] From the Hacker's Dictionary (see [1] above): tron: /v./ [NRL, CMU; prob. fr. the movie "Tron"] To become inaccessible except via email or `talk(1)', especially when one is normally available via telephone or in person. Frequently used in the past tense, as in: "Ran seems to have tronned on us this week" or "Gee, Ran, glad you were able to un-tron yourself". One may also speak of `tron mode'; compare {spod}.

[5] From the Hacker's Dictionary (see [1] above):

BCNU: be seeing you (see :talk mode)

Redux (The Interface): IEEE I&M Column for Fall 97

-- John Blyler (10/22/97)

High-Level Synthesis without IP Hassels?

Start-up Algotochip offers illusive C-to-chip generation in record time, but raises questions of automation vs. customization and IP ownership.

Start-up Algotochip emerged from stealth mode this week at the Globalpress Electronics Summit 2012 in Santa Cruz, CA. The company announced delivery of their silicon solution based on MimoOn’s LTE reference chain, a wireless industry platform for Software Defined Radio (SDR)

Algotochip – short for Algorithm to chip – claims to create production-ready System-on-Chip (SoC) designs from C-code algorithms. Creating low-level, hardware RTL-code from high-level, software C-code is a long sought goal of the electronic design automation (EDA) industry. What makes Algotochip’s position unique is the claim to deliver silicon hardware in as little as 8 to 16 weeks – instead of the more typical months or years. How is this possible?

Satish Padmanabhan, CTO, claims the secret to the companies fast turnaround time lies in the hardware-software partitioning process.

“Designers can not define a complete system in C or System-C since there is no cycle-based information in C-code,” explained Padmanabhan. “One must take the C-code and then decide what needs to run in programmable (software) and non-programmable (hardware) implementations.”

Typical chip designs start with some amount of existing RTL code. But to do high-level synthesize, engineers must start at the architectural levels using C algorithmic code. At this higher level of abstraction, functions have not yet been apportioned to hardware and software implementations. This is where Algotochip claims to help, by solving the difficult challenges of hardware and software tradeoff decisions.

According to the company, customers need only submit their system specification, C-code with test vectors. The company will use these inputs to partition a solution in hardware (SoC, S-ASIC or FPGA) and software (compiler, simulator) and firmware.

How does this approach compare to other design service businesses like eSilicon and Open Silicon? According to the Algotochip’s Padmanabhan, time is the big differentiator as measured in weeks (8 to 16 weeks typically) rather than months or years to tape out.

In terms of semiconductor intellectual property (IP), Algotochip will incorporate third-party IP or will create customer specific IP from proprietary C-code algorithms. Interestingly, the company claims that their customers will retain all intellectual property rights pertaining to the finished design. Some critics doubt this claim as IP makes up a significant portion of revenue for most chip design service companies.

Another area of concern is whether Algotochip SoCs will really be as power-efficient as those that use traditionally longer-time frame development tools and processes. The short development process – 8 to 16 weeks – suggests to some that the Algotochip offers a more customized rather than completely automated approach for C-to-RTL silicon creation.

Time will tell if Algotochip’s design services can really beat traditional C-to-Chip methods for timely and power-sensitive SoC development. Related issues such as IP ownership should also become clearer after the company enjoys further customer engagements.

Originally published on Chipestimate.com "IP Insider"

JB Circuit

I can not maintain yet ANOTHER blog. Follow me at: JB's Circuit

Dark Faust Returns

Mephisto grins in anticipation. Here's my original blog on livejournal, a long time ago: