Register Bits

“Rounded Corners” seems like a bogus comment coming from an engineer. The real questions are: what does the output look like, how useful is it, what does it take to prepare the input, and how long do you have to wait for it. If an engineer isn’t asking you about the “goes into’s and goes out of’s” I question how serious a prospect they are. Cosmetic interface issues should be on the feature list for 2013.

I liked your comment on EDA Grafitti about “opportunity cost” related to internal development, I would like to see you develop it more fully in a blog post. Your blog already has some good content, just a suggestion.

Thanks for the tip on an “opportunity cost” posting. I’ve got it down in my blog pipeline.

The “rounded corners” tip was not from a mere prospect but an existing customer that taped out an ASIC with SpectaReg. What goes in, what comes out, how easy it is, and how long it takes is immediately apparent via a free intuitive online eval or interactive WebEx demo. The AJAX GUI is fast. Legacy inputs like CSV and FrameMaker are supported. Standard output deliverables for hardware, HW verification, firmware, and documentation are supported for a variety of on-chip bus interface protocols. Extended IP-XACT is imported and exported.

Usability and styling efforts are not mutually exclusive to R&D feature improvements, it’s complementary and done in parallel. Different people have different perspectives on the value of improving usability through styling and icons.

We want our users to have a simple and visually appealing experience.

Interesting, the web designer said “rounded corners” was so last year. When I look at EDA’s web presence in general it’s outdated and clunky, unlike what engineers have come to expect from the new generation of AJAX apps used in daily life. Apps from the likes of Google and Yahoo.

I think there is a difference between good style and good design.

Style is those aspects that contribute to the aesthetics of a product. What color scheme you choose. Rounded corners. Stuff like that.

Design are those aspects that make a product easier or more productive to use. Having the most common tasks be just one click or keystroke. Having the most important buttons be the most visibly prominent. Being able to open multiple views at the same time.

A good example is a remote control that I have for a karaoke machine I got for my kids. It is very stylish, all black and silver and cuved to fit in the palm of my hand. But the text on the buttons are all black on silver and hard to read. The most important buttons (power, volume, channel) are the same size as the other buttons, so I’m always searching for them. The design sucks.

My advice is to ask yourself if it has to do with style or design. Do the design first, then worry about the style later.

I’ll post more screen shots to solicit feedback as the audience sees fit. It will make for an interesting experiment.

One recommendation, since posting the screen shots, was to remove the question marks and hyperlink the form field names. While this would reduce clutter, it is not as intuitive of using the question mark icon to ask for help with filling in a given field.

Jeremy,

Big box discount stores are designed to look like warehouses. This is not to save money but rather to convince the customer that this place must be the lowest cost because it looks so spartan.

First job is to make it fully functional, then you make it pretty. Do not try to add style to a trivial tool. It doesn’t help.

I have never used your tool but looking at the demo brings up a host of questions.

I see you have three major divisions. ConfigRegisters I assume are read/write registers, StatusRegisters are read only and UNUSED are addressed within in block select range but are unneeded. Do you have to group them together in that order? What happens when I want to mix read/write bits in with read only bits in a single register?

I see the Comp Offset column and can understand what it does but what in the world is a “AB Offset”? I have never heard that term and there are two different data types shown.

Where are the reset values? I need to spec each value and whether or not it is async or sync reset. I also need to spec the constant value returned when you read an UNUSED field. I want to be able to have all 0’s returned from reading a UNUSED field from within a register and all 1’s from unneeded address space. I also need to be able to set this from a parameter. This means that you can have a different memory map for each instantiation of the component.
I want to see them all with their full cpu address. If there are mirrors then I want to see all of them.

And why in the world do designers always create something like a TickPeriod register and fill it with a field for TickHalfPeriod? Either call it TickHalfPeriod or else shift the field by one bit so that you can write in the TickPeriod into this register.

I see that I have three choices for dimensioning: Non-array,1D and 2D. Thats fine. I understand those. But my understanding is that a vector like TickHalfPeriod[3:0] should by a 1D array, You show it as a Non-array. This means that my hopes that I can use your tool without reading the manual are dashed. The primary test of a gui is that a knowledgeable user could pick it up and use it with minimal use of documentation.

Then there is the question of latches. If your status bits are stable then they can be read without latching them during the read cycle. If not then you must add a latch. Where is this speced?

The same goes for write registers. Most of the time you want a latch but there are times when all you want are the write data lines and a latch signal. How do I spec that?

John Eaton

John,

We have been continually increasing and retaining our paying customers since our first beta customer 3 years ago, which we would not be able to do if it was a trivial tool. The paying customer who mentioned that we should improve the styling is happy with the new style. We are very pleased with it too. It does make the tool easier to use.

The best way to learn SpectaReg is to evaluate it online, or arrange a WebEx demo. The assumptions you make above are not in alignment with the way it actually works.

First, each row the dynamic table shown on the left is clickable. The dark blue rows are AddressBlocks, the middle blue Registers, and the light blue BitFields, as defined in the IP-XACT XML standard by the SPIRIT consortium. See my previous posting for more info on that, and an upcoming posting for more info. Any UNUSED space is automatically maintained by the tool. The user clicks on an UNUSED AddressBlock, Register, or BitField to add a new one, then enters in the specs.

Also, AddressBlocks and Registers are easily collapsable / expandable dynamically in the GUI. This sreenshot shows them all expanded.

In the above screenshot, the ConfigRegisters AddressBlock contains an array of 3 Registers each of which contains an ActiveTicks BitField. Arrays are useful for channelized components.

I see you have three major divisions. ConfigRegisters I assume are read/write registers, StatusRegisters are read only and UNUSED are addressed within in block select range but are unneeded.

The user can group registers into AddressBlocks however they see fit. The UNUSED spaces are dynamically managed by the tool and are used for creating new AddressBlocks, Registers, and BitFields.

What happens when I want to mix read/write bits in with read only bits in a single register?

Yeah, that’s possible. The spec used for this screenshot just wasn’t done that way.

I see the Comp Offset column and can understand what it does but what in the world is a “AB Offset”?

AddressBlock (AB) Offset is the offset relative the parent AddressBlock. Again, this is defined in IP-XACT. The whole block of registers can easily be moved by changing the base address of the AddressBlock. Also, the whole AddressBlock can be copied and pasted as a unit.

Where are the reset values?

They are defined in the specifications for a BitField. The screenshot shows the form for specifying a Register. So if you were to click on ActiveTicks BitField you would view/modify the the reset value.

I see that I have three choices for dimensioning: Non-array,1D and 2D. Thats fine. I understand those. But my understanding is that a vector like TickHalfPeriod[3:0] should by a 1D array, You show it as a Non-array.

TickHalfPeriod[3:0] is a BitField that is 4 bits wide (i.e. bits 3 downto 0). It exists within the TickPeriod register which is a non-array. In this specification screenshot, the LightPeriod[3] is the only array of Registers defined.

This means that my hopes that I can use your tool without reading the manual are dashed. The primary test of a gui is that a knowledgeable user could pick it up and use it with minimal use of documentation.

I agree that a GUI needs to be easy and intuitive to use. SpectaReg’s GUI is easy and intuitive, and we have various people from around the world who have been able to pick it up and use it for an online evaluation without reading the documentation. Before judging, it I would recommend you try it. Just from looking at a GUI screenshot and judging from that isn’t fair.

Then there is the question of latches. If your status bits are stable then they can be read without latching them during the read cycle. If not then you must add a latch. Where is this speced?

The same goes for write registers. Most of the time you want a latch but there are times when all you want are the write data lines and a latch signal. How do I spec that?

The types are specified easily in the GUI. Typically typing is done at the BitField level. Many different types are supported (like control, shadow, strobe, status, interrupt, …) and the typing is customer extensible to include custom types. I’ll provide more info on this in future postings.

Hope this helps explain things. Feel fee to sign up to give it a try.