> then the code to do stuff is generic across ALL the register types. Wouldn't I get that with polymorphism? If every class had randomValidDate() and each method handled the different internal data format, don't I get a "generic" interface for all register types?
I'm not familiar with this "table driving" approach. is there a >>short<< example on the web I could look at? Greg > On 12/06/2013 11:47 AM, Me wrote: >> 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. >> > > i would do some sort of table driving here. have a collection of small > subs (or methods) that do the various tasks like generating > mantissa/exponent data or verifying stuff, etc. this may be a large > collection but each sub does one small task. then make a dispatch table > so you can access all the subs (if they are methods, then just the names > are needed). then for each register type, you assign a list of the subs > to handle it. one set for generating data and another for verifying. > there is actually very little coding here other than the subs doing the > work. then the code to do stuff is generic across ALL the register > types. it just gets the info for the given register, looks up the worker > subs it needs and calls them. there is no need for layers of objects or > complex structures. this can even handle nested stuff, if you define the > workers that way you just make each register have a nested set of keys > telling the code what to do. > > this can all be done procedurally too. OO could help but it may not be > needed. i have done similar things for testing several of my modules. i > even gave a pm talk on it many moons ago. > > uri > > -- > Uri Guttman - The Perl Hunter > The Best Perl Jobs, The Best Perl Hackers > http://PerlHunter.com > > _______________________________________________ > Boston-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/boston-pm > -- _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
