I use this environment for asic verification. So one kind of test is to randomize every register with data. But different types of registers have different valid data definitions. For example, one type of register is 16 bits wide with the top 5 bits representing an exponent, and the remaining 11 bits representing the mantissa. There are many registers of this type. They might set a voltage, a current limit, temperature alarm, and so on. And if the value of the voltage is outside the range of the chip, the write to that register needs to be rejected by the chip.
So i was envisioning a class to handle this exponent/mantissa format, then have a method like randomValidData(). There are other register types that 16 bit mantissa and the exponent is held in yet another register. So randomValidData for that type of register would be different. A lot of testing often needs to write random but valid data to registers. So if i have a container of instances of different register classes, i could iterate through all registers and fill them with valid random data. In the other end, if i want to set the registers to some functional value, like 1.3 volts, i would rather not care what type of register it is underneath. I would rather call a method like SetFloat and have it translate the 1.3 value to whatever type/format the register is underneath. So, again, polymorphism. What happens is we end up with a regression suite of tests for a chip that is hundreds of tests. If we have the test set a value in a register directly knowing its type, and then the designers decide they need to change the type, then we may have to go through a lot of tests and change the low level number written to the register. If the test says SetFloat, then the only thing that changes is the code that assigns the register to its type. What Ive done so far is write procedural functions, and that worked ok when the chips were fairly simple and most registers were simply an integer value with no fancy expinent/ mantissa thing, or whatever. But our latest chip has dozens of register format types , at which point our procedural approach is getting in the way. What we did before made sense for the schedule we had. But i think we are at a complexity level where we would be better off taking a hit recoding the register interfaces to be OO. And as i pencil out what it would look like, iwant ti make sure i dont go too far down a bad path and end up with an OO kluge instead of a procedural kluge. Sent via DroidX2 on Verizon Wireless™ -----Original message----- From: Mike Small <[email protected]> To: [email protected] Cc: Greg London <[email protected]> Sent: Thu, Dec 5, 2013 22:59:05 GMT+00:00 Subject: Re: [Boston.pm] ?instances of classA contained in classB, and instances of classB contained in classC? "Greg London" <[email protected]> writes: > This is really convoluted, so feel free to reply to me offlist. > > I'm trying to model a register map for a voltage regulator chip. > > Our chips used to have an extremely simple register map. > There was an I2C interface, and the designers created a > list of register names, defined what address they were > at, how many bits wide they were, masks, etc, and we > were done. It was easy because every register name > was completely unique. > > So I just modeled it as a simple perl hash. > > Our latest regulator chip has multiple voltage outputs > and the old register map approach fell apart. We now have > the same register names occuring at multiple addresses > and each version of a register might behave a little > differently. > > i.e. the "output_voltage" register might be ten > bits wide for the first voltage output core > and another "output_voltage" register might be 12 bits wide > for the second core. And of course, > each "output_voltage" has to have a different address > depending on which output its controlling. > > I don't even know how to model this. Would it work for you to keep your hash but make the values instead be references to arrays of references to objects with the attributes you mention above: address, width, masks, etc.? Are the values in your current hash objects with such attributes? Is it only that before you had one value per name and now you have many or is there more to it than that? I guess what I'm thinking is maybe where in the part of your email I've removed, what you are thinking of as container classes could be regular Perl arrays (and above maybe I missed a level since you mention containers of containers, but still that could be a hash of arrays of references to arrays of references to structs). Maybe you'd want to abstract over it and hide away in a module with subs that know the data structure. I probably don't fully understand your requirements, but I'm not seeing the case for subclassing or polymorphism. Is it that some hash elements you want the old way as simple values and others in collections? So either have a rigid 2 (or 3?) level structure that you walk down and when you only have one you have an array of one, or else use ref to see whether you have an array or scalar in each hash value and in each array element as you walk down the tree. -- Mike Small [email protected] _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
