WWDC

[DT]

We used Perl (on Sun boxes) during our first several years in web development (this was early in the market, mid-to-late 90s), wrote some pretty major solutions (including a pretty decent CMS product).

As we got good, and I got more devs (to compliment the design side of the business), we started seeing how abbreviated we could write code, if something that was written in 10 lines that could be done in 2, it was a mark of shame Of course, this led to incredibly difficult to manage, read and maintain code ... but hey, look, I wrote this complex string parser in one line! Can't decipher it a month later? Too bad

 

[Cmaier]

We used Perl (on Sun boxes) during our first several years in web development (this was early in the market, mid-to-late 90s), wrote some pretty major solutions (including a pretty decent CMS product).

As we got good, and I got more devs (to compliment the design side of the business), we started seeing how abbreviated we could write code, if something that was written in 10 lines that could be done in 2, it was a mark of shame Of course, this led to incredibly difficult to manage, read and maintain code ... but hey, look, I wrote this complex string parser in one line! Can't decipher it a month later? Too bad

I wrote a bunch of web stuff in the 90’s in perl on sun boxes. Got a write up in the Philadelphia Inquirer for an AI I did, which I eventually sold to Virgin Interactive. Code was embarrassingly bad.

 

[Cmaier]

Some new rumors from Gurman today, but not specific enough to be worthy of discussion. The one interesting thing was a reference to yet another multitasking interface on iPad.

My suspicion: when you hit the … button you will have an option to convert your window to a floater that can be arbitrarily sized and arranged. Something like that, anyway.

 

[mr_roboto]

We used Perl (on Sun boxes) during our first several years in web development (this was early in the market, mid-to-late 90s), wrote some pretty major solutions (including a pretty decent CMS product).

As we got good, and I got more devs (to compliment the design side of the business), we started seeing how abbreviated we could write code, if something that was written in 10 lines that could be done in 2, it was a mark of shame Of course, this led to incredibly difficult to manage, read and maintain code ... but hey, look, I wrote this complex string parser in one line! Can't decipher it a month later? Too bad

Perl tends to encourage write-once read-never coding styles, but your shop really leaned into it.

 

[Cmaier]

Perl tends to encourage write-once read-never coding styles, but your shop really leaned into it.

The vast majority of the design automation flow at AMD was based on Perl. I was responsible for most of it, but my buddy Alan taught me enough Perl to make it possible, and he helped work out a lot of the advanced Perl-C interface stuff. It was pretty cool. Sort of worked like a makefile system, but much more advanced and flexible.

You would create your preliminary netlist and cell placement by hand, then type a command like “ace -place” and it would take all the input files, run them through tools, and create the appropriate output. If earlier steps needed to be run based on datestamps, it would run those first. It could parse out jobs in parallel to multiple machines, if appropriate (using lsf). Each module (place, route, etc.) was its own perl file with callback functions that ace would invoke to determine dependencies, etc. A lot of the individual tools were also written in perl, including things like automated repeater insertion, clock tree buffering, block pin placements, wire pre-routing, etc.

We even had a tool called Wanda that was a perl/tk script that would display the chip layout (cells and wires) and let you move things around and tell you the effect on timing and stuff. A lot of that ended up as a mixture of C and perl over time, and as the years went on, a lot of my more advanced tools were written in C++ with sdks so they could be called from the various perl scripts.

We had a really weird situation there because we had an actual CAD team, but almost all the CAD work was actually done by us cpu designers, or by us designers telling the CAD folks exactly what to do.

 

[mr_roboto]

I worked at a place which had an interesting CAD system built on top of perl too. A bit of a different focus - it was an ASIC design house for the most part, so it was all focused on RTL. You wrote Verilog in a weird hybrid of Perl and Verilog, and it was all passed through a "compiler" written in Perl to generate the real synthesizable Verilog RTL.

That probably sounds horrifying, but it was actually really nice to write RTL in compared to plain Verilog 95, the version of the language the system had been designed to enhance. A bunch of it is now obsolete thanks to SystemVerilog, but I do miss some of the things it did.

For example: it had a dot-star scheme similar to SystemVerilog's, for making automatic connections between wires and port signals with the same names, but it was far more powerful because you could have multiple dot-star statements and each could use regexes (on either side of the port connection) to do transformations on signal names.

Another one: it could automate the entire job of routing signals through ports. Say you were working on a module; if you just used a signal name without giving it a driver, it would detect that and generate the lines of Verilog to make it into an input port. Same worked for outputs, if a local signal had no loads it would infer an output port. Combined with the dot-star features, and its ability to propagate these inferred port connections up and down hierarchy, it made connecting signals between two modules living in different parts of the design hierarchy trivial: just generate the signal in one module, and consume it in the other, and magically all the port connections and wires needed to get it from place A to B would appear when you ran the RTL makefile.

 

[Cmaier]

I worked at a place which had an interesting CAD system built on top of perl too. A bit of a different focus - it was an ASIC design house for the most part, so it was all focused on RTL. You wrote Verilog in a weird hybrid of Perl and Verilog, and it was all passed through a "compiler" written in Perl to generate the real synthesizable Verilog RTL.

That probably sounds horrifying, but it was actually really nice to write RTL in compared to plain Verilog 95, the version of the language the system had been designed to enhance. A bunch of it is now obsolete thanks to SystemVerilog, but I do miss some of the things it did.

For example: it had a dot-star scheme similar to SystemVerilog's, for making automatic connections between wires and port signals with the same names, but it was far more powerful because you could have multiple dot-star statements and each could use regexes (on either side of the port connection) to do transformations on signal names.

Another one: it could automate the entire job of routing signals through ports. Say you were working on a module; if you just used a signal name without giving it a driver, it would detect that and generate the lines of Verilog to make it into an input port. Same worked for outputs, if a local signal had no loads it would infer an output port. Combined with the dot-star features, and its ability to propagate these inferred port connections up and down hierarchy, it made connecting signals between two modules living in different parts of the design hierarchy trivial: just generate the signal in one module, and consume it in the other, and magically all the port connections and wires needed to get it from place A to B would appear when you ran the RTL makefile.

We also wrote in verilog, but we didn’t synthesize. We did have a perl pre processor that would let us do things like arrays with interesting bit index patterns (skip backwards by two; or whatever).

But we did it structurally, not synthesis. So like

Foo1 inx2 (.a(boo), .z(bar))

(forgive syntax errors - been too many years)

We had a separate file that listed module I/O in verilog format, and a physical counterpart - we would manually instantiate “pins” on the boundaries of our blocks, and the router would route to them. If you wanted to move a pin, your neighbor had to make a corresponding change - like two keys in a nuclear submarine. There was automation to tell you if your neighbor moved something.

 

[Citysnaps]

For our fabless semiconductor startup that developed full-custom signal processing ASICs (not programmable DSP chips) we used our own schematic entry program and simulator/verification software, and then…. hand routed using UC Berkeley’s MAGIC layout program to place our own library of gates and functions (adders, registers, etc) and an efficient multiplier generator program that could handle any operand width.

What was great was achieving far better performance (faster clock rates and lower power dissipation) with much smaller dies than similar competitor chips by Harris Semiconductor, Analog Devices, and FPGAs (of that time). And that really irritated them.

Being a small employee-owned company which ranged from three to ten engineers and an admin over its existence, that made the most sense. It was a great place to work. No bs, no dead weight, no company politics.

 

[Runs For Fun]

iMac Pro???

Gurman: Apple could announce two new Macs at WWDC 2022 - 9to5Mac

After announcing the new Mac Studio and Studio Display last month, Apple still has a few more Macs to introduce in 2022.

9to5mac.com

 

[Cmaier]

For our fabless semiconductor startup that developed full-custom signal processing ASICs (not programmable DSP chips) we used our own schematic entry program and simulator/verification software, and then…. hand routed using UC Berkeley’s MAGIC layout program to place our own library of gates and functions (adders, registers, etc) and an efficient multiplier generator program that could handle any operand width.

What was great was achieving far better performance (faster clock rates and lower power dissipation) with much smaller dies than similar competitor chips by Harris Semiconductor, Analog Devices, and FPGAs (of that time). And that really irritated them.

Being a small employee-owned company which ranged from three to ten engineers and an admin over its existence, that made the most sense. It was a great place to work. No bs, no dead weight, no company politics.

Hah! I forgot all about magic. I used that in some classes in college in the 90’s.

Some stuff at AMD was full custom at the transistor level, using schematic capture. That came from the guys who joined us from the Alpha team at DEC (the “circuit team.” I was on that team for awhile). Most of the chip was done using custom cells that we designed, manual netlist generation, manual cell placement, manual pre routing of important buses and wires, and autorouting the rest (the “logic team,” which I was also on for awhile.). And a handful of us handled floor planning, standard cell architecture, etc. (“Globals team.”) AMD was pretty weirdly organized back then, with very small teams (20 or so) who handled lots of job functions.

 

[Cmaier]

iMac Pro???

Gurman: Apple could announce two new Macs at WWDC 2022 - 9to5Mac

After announcing the new Mac Studio and Studio Display last month, Apple still has a few more Macs to introduce in 2022.

9to5mac.com

Not enough whispering about that, so I assume it isn’t happening any time soon. They want you to buy a Mini or Studio with the studio monitor instead, for now.