<TITLE: Design and Analysis of Interconnection Architectures for On-Chip Digital Systems
ACADEMIC DOMAIN: technology
DISCIPLINE: information technology
EVENT TYPE: doctoral defence discussion
FILE ID: UDEFD090
NOTES: presentation UDEFP090 in Finnish, not transcribed

RECORDING DURATION: 176 min 17 sec

RECORDING DATE: 21.6.2004

NUMBER OF PARTICIPANTS: unknown

NUMBER OF SPEAKERS: 3

S1: NATIVE-SPEAKER STATUS: Finnish; ACADEMIC ROLE: research student; GENDER: male; AGE: 31-50

S2: NATIVE-SPEAKER STATUS: Finnish; ACADEMIC ROLE: unknown; GENDER: male; AGE: 31-50

S3: NATIVE-SPEAKER STATUS: German; ACADEMIC ROLE: senior staff; GENDER: male; AGE: 51-over>


<S2> okay so we now change the language but hope hope you can understand even my english so just just to give er a little bit background background of of what what's going on and what's er what is kind of part of of <NAME S1>'s thesis so as <NAME S1> mentioned this interconnect is a crucial part crucial part of this whole system so actually without some o- some real real interconnect we cannot connect these many (xx) together so so clearly something is needed there , and especially we discuss a lot of these I-Ps so intellectual property models so so er in practice it is ext- ext- extremely important that we have one way or at least one in- interface that you can have or that you can use so that's kind of er nice to have these kind of models available . and actually it's one of these er w- w- one of these (xx) factors or whatever stop- er there there are other things also but it's one of these that why why the I-P model has not (xx) (exported or or) (xx) , and er that as a de- definition as we are going to discuss also these I-Ps and and their their interconnect so these er compartment definitions so it's a (xx) that is predesigned er or er yeah that profile of predesigned (xx) would be implemented in one or both (xx) dividing such applications like the internet servers or or some other device and er then find other definition what what's the what's the meaning of that is that er or what's the value in these I-P models I-P stuff is that er it can be the technology it can be the application implemented it can be some support service or or whatever but but in the end the meaning of of this whole system is that it it has to be easy to use for the customers to evaluate (by) and and to implement for the system and for that reason we need some some way to make that easy and and <NAME S1> is now in his thesis trying let's see how well he managed but he's at least trying to explain -plain us a brilliant interconnect that he has developed , er the other other point here i thought kind of inactive point of view is the standardisations and er that's er commonly understood that there needs to be some common commonly agreed standards and er different companies are working on that er and er i will next explain how a a few a few of these organisations that that give a brief overview how how big big area this is actually even i- i- in inactive way and but anyway i think the importance of this kind of er research work is is really that that in in the industry usually it happens that er the goals are after one years or two years something like that so so that they are near future they they they have a problem they want to solve and er now this research view is needed to make a long-term solution for that and er there is kind of er a few companies that are are part of this VSI alliance that is one of er a consortium defining these kind of things and (xx) so so there are a lot lot of lot of different companies but here is just just just a few and as you can see almost all big companies are are there then we go to the next er very important is the OCB I-P that's the other open open standard forum and you can see that er all all the same big companies are there and actually it's very interesting (xx) the VSI alliance so so they are they are cooperating a lot and actually (something) from their web page i noticed that even tampere university of technology seems to be a member at least according to the web page er so so you can see that there are kind of or or a system of big (xx) there are (xx) members there are some er (xx) there are (tool vendors) big (xx) and er , and then we have the next or the third big big kind of consortium is ARM based AMBA system and this is out of from ARM ARM web page so so basically ARM is taking care of that so that's not (xx) standard (xx) they are communicating with a lot of companies , so i think today we are we are going to discuss of different requirements and and goals goals what the interconnect have and er here is very simple point of view of the of the stuff so so it has to be easy to modify and maintain it has to be somehow related to standards it needs to be very flexible so that we can send it to new new environments it should be smart input-ruled performance (xx) effective and so n- on on so so the requirement list is er very long and er of course the least i- is that it has to be (xx) and they cannot be (xx) even the small (xx) here is too much in in that position so well it has to be easy easy to use and and easy to (run) these I-Ps so i think that's that's one of the main requirement we have here <P:05> okay we can start the start go through this this thesis and er i think we can start in a traditional way so we can start from the topic topic so first of all i would like to ask the how how how you selected the topic , okay are you topic of this this thesis </S2>
<S1> well actually it's a , comes from many years of er different project works and , research that we have done so , i i i sort of picked it four or five years ago and it led me to here </S1>
<S2> so are there some some works or something in this topic you'd like to emphasise i mean what's the what is the </S2>
<S1> well , actually all of them i i i wouldn't like to pick any any work in particular </S1>
<S2> you have you have limited your work for on-chip digital systems so are they some- <PREPARING EQUIPMENT, P:11> okay so so , so you needed a system for this pointing system so wouldn't it be more (wide) </S2>
<S1> of course and as i stated in my opening speech these on-chip systems are in many res- many respect like the older systems but they are they have some differences also so i i wanted to focus on the on-chip systems </S1>
<S2> okay , then just er one other (point) so you said that you (write a) monograph so what was the reason behind it er it is er collecting of the erm publications so you'd have that i don't (understand it) </S2>
<S1> well actually the de- decision was made less than a year ago and er the reason was that i wanted to make a a more er i guess clear or structured would have to be read and understood more clearly although it's based on publications </S1>
<S3> but don't you think the title is <SIC> choosen </SIC> too (broad) so it's more title like a textbook and not showing your research behind the title directly </S3>
<S1> maybe but it it gives the sort of the area where we are dealing it it's it is quite broad but it gives the field in which we are doing research </S1>
<S3> could you say in some words what is the real research you have done behind that you give some overall classification </S3>
<S1> well </S1>
<S3> could you summarise it a little bit </S3>
<S1> yes actually this book is more or less divided into two parts and the first part is er sort of a background study and the that background study that led to some experiments that we did and it is quite a broad broad subjects and it deals with the whole whole title of the book but the latter part of the book is our one of our of our implementation and it's more like clearly targeted to certain systems mainly er multimedia type systems or continuous media systems so it would add add it to the list of on-chip digital systems </S1>
<S3> perhaps we can start with some general questions and as you said in your introduction er system on-chip is is a big topic and the question would be here where do you see the major differences between classically multiprocessor systems and the field you have considered emerging field of on-chip solutions what you could call multiprocessor S-O-Cs </S3>
<S1> well it has many similarities but also some differences like like the area is actually and if you take one example the buffer area it becomes much more important in in on-chip systems , so area power efficiency are i think that are the most important things </S1>
<S3> so how do you can take care of system requirements </S3>
<S1> well i i see that that the system on-chip concept er requires that we target power our systems to certain applications so we don't make or at least in this book we don't make any general purpose systems so we we have to be very careful what what we really need in the system and what what's the sort of what we (can do without) </S1>
<S3> and cost modelling when you compare the cost modelling in both cases the classical multiprocessor system solution and the system on-chip solution </S3>
<S1> you mean what what is the [(c-co-)] </S1>
<S3> [how] how you models cost in both cases </S3>
<S1> in in a sort of traditional multiprocessor systems i weigh the performance much heavier over the costs so it doesn't have to be so cost-sensitive than a system on-chip </S1>
<S3> and er on (your point of view now) that your knowledge would have accumulated in your teaching work er what do you as a (CS doc) let's say in five to ten years what are the most critical (factors) or what are the areas what are important to consider in the future </S3>
<S1> well actually of course interconnections are one of the one of the many most important things but i think it's it will be er an evolution so the things that we see today will [just] </S1>
<S3> [(perhaps)] we start with technology </S3>
<S1> it's er i see it as [a] </S1>
<S3> [(xx) (product of)] technology for example </S3>
<S1> well i don't see any big change there (C-MOS) really evolve too i guess </S1>
<S3> but then they go not to some 90 nanometre nodes or 60 nanometre nodes do you have an idea how many active electrons we have in the gate the below the gate in the active channel of a MOS transistor <S1> [yeah] </S1> [what] happens to the good old MOS transistor then </S3>
<S1> yes i i i understand that there are a lot of problems on th- on the technology side but , you may i would like to look at this all thing is through a digital abs- abstraction so it will be more difficult to make make usable blocks but it's still possible </S1>
<S3> this is your hope or are you (working) </S3>
<S1> i i hope that somebody else will (xx) </S1>
<S3> @@ so let's discuss another topic er was a topic of system integration and you see the heterogeneous form of blocks you have to integrate </S3>
<S1> sorry what </S1>
<S3> er (digital block) as a system integration topic <S1>  yes </S1> that you have not only digital blocks but er RF blocks or other other blocks and </S3>
<S1> yes that that also causes some problems in addition like different digital memories or whatever that require different types of technologies so the integration it will be (a little bit difficult) </S1>
<S3> and another topic i think would be er to to discuss a little bit in your work the feature of (reconfigur- reconfigurab-) circuits and can you comment on the topic of the future importance of runtime reconfigurability </S3>
<S1> er i think it's going to be very important reconfigurability in in many respects like runtime reconfi- reconfigurability and reconfigurable systems in general </S1>
<S3> and what about er evolution of design styles personally i don't like too much the term platform based design because in every domain er people speak about platforms they are using for processing something </S3>
<S1> yes it used to mean mean quite different things , well <COUGH> although the design styles have evolved but the real benefit's in in in chip chip design (come from) technology so i think that the design methods need to be made better so so that we can make the future (chips) </S1>
<P:08>
<S3> erm you talked about er this er abstraction for digital system and from that high level you can you comment er the topic of transaction level modelling can you comment about that what are the features of transaction level modelling </S3>
<S1> we- well the only way with theory (xx) with or the or the the complexities is to abstract (away the things) that you don't want to know about then transaction level modelling is is one of them so you can forget of about all the low level details like blocking or or or anything like that </S1>
<S3> can you go in more detail when you look at the communication aspects in a er in the modelling process and in the computation process and both are (xx) (aligned) to one another and what are the points of interest in the plane for for communication axis and er com- computation axis </S3>
<S1> we- well , they , we need need to separate them in in some some way so that the whole design process is so so large that we cannot pay attention to all every detail detail all the time so we need to be able to also separate these these er computations and communications from each other </S1>
<S2> do do you see any difference there that now you say that this is all should be (trans) systems but their modelling issue do you see any difference here how you (want) it or how (would be) the systems compared to to this kind of system i mean you brought some of this transaction (language) (xx) so (whose or) </S2>
<S1> er in a er depends on what kind on what level you look at it but if you look at it at a sort of like logic design level there's not not much difference </S1>
<S2> but are (xx) (what) (xx) that kind of (xx) as a first (xx) you have the PC <S1> yes </S1> and there are many components when you want to (xx) this kind of PC (on-chip) so do you think it's er easier to do that or is it more difficult or (xx) (means of reduce) (xx) </S2>
<S1> it's it's going to be difficult more more difficult it brings into the picture some some of the issues technology issues </S1>
<S3> er when we talk about system on-chip er we have to consider also the software part and er their er operating system real-time operating systems are dominant er can you give us a definition er of a real-time operating system and describe some of the features </S3>
<S1> well first of all i i sort of have left almost all the software aspects out of this thesis but of course i have some some experiences with those so real-time operating systems they they are usually required to be actually quite small use er very little memory for example be able to run on systems with very few resources and be able to respond to er react (something) something something that happens on the environment very quickly </S1>
<S2> so was there actually some some reasons (behind) or do you have some ideas why you ask that (we take this) (xx) </S2>
<S1> well i think that you have to somehow focus on something you cannot er study everything </S1>
<S2> can there be any other reason i think i might have some reasons why (xx) this might even be crucial (selection) (xx) </S2>
<S1> well i er er they are sort of different things and can be st- studied in isolation or the (xx) but other- otherwise i wouldn't (xx) </S1>
<S2> (xx) most most people at least (i've have known) have (been) is interconnect (is) shouldn't be seen by the software so i think (xx) (that's a) (xx) try to separate (technologies) so so the interconnection (xx) invisible for the for the software (that there is) </S2>
<S3> can you explain the difference between a hard and a soft interrupt </S3>
<S1> well in hard interrupt there is usually a strict deadline when it should be (answer) and the soft interrupt there isn't so in hard interrupt when if you don't react to it fast enough (er it sort of) becomes useless in a soft interrupt the you might lose for example some accuracy but it's still useful </S1>
<S3> on some of the transparencies er you mentioned ASICs and ASSPs what is the difference between the two </S3>
<S1> well usually ASICs are seen as more more like application specific built for very or for certain use like for example if somebody at nokia would design a chip for their new phone the i would call that an ASIC a application specific standard product is something that is meant for a broader use it has for example some programmable elements that can be used to do with different things </S1>
<S3> so what is a typical product life cycle ASIC will experience will it finally become desolate or where does a typical ASIC finally move to to what area </S3>
<S1> er </S1>
<S3> at the beginning of (chip was as) you said done completely for certain application in mind and then </S3>
<S1> do you mean that when when time goes by er actually one reason for doing ASICs is that er if you really want to optimise for something and then over time there might be standard for a (product) that can do the same </S1>
<S3> so it moves to ASSP <S1> yes </S1> and what are normally occurring engineering costs </S3>
<S1> er they are the costs that the one product for example design cost that one er sort of used only once at when you design the product and then when you make it (xx) </S1>
<S3> er the term intellectual property is a term which is quite new (thing) for the electronics community but much older for the software people and er we will see how we we introduce intellectual property features er or standardisation features er in the electronic development process er there was a definition from theo claasen on a design information conference where he introduced four levels of er I-P standardisation can you comment er what is the oldest form of classification and how's this evolve </S3>
<S1> i i'm sorry i don't <S3> [mhm] </S3> [(xx)] so </S1>
<S3> but <S1> [(classification)] </S1> [for example] you started (with the) classical digital circuits as catalogues of ETL functions and then you moved up to standard cell and then you came to the intellectual property function description and are there different forms of er how we can handle intellectual property in the design process how how i as a user can buy different forms I-P (props) from you </S3>
<S1> er the whole term is , er i think it er intellectual properties it's almost like abstract er you you buy sort of knowledge from me so you can buy sort of just the block like a hard or (micro) [(xx)] </S1>
<S3> [and] what do i get from you </S3>
<S1> you get a GBS-2 file that you can modify in many ways </S1>
<S3> so (xx) or <S1> [yes] </S1> [(xx)] but if i don't like set form because it's not very flexible for me do you have something better for me </S3>
<S1> yes i have er something in VHDL or or some other hardware description language so you can modify them just as you wish </S1>
<S2> would that actually (mean that) people are buying some I-P props i don't see they they are really buying (xx) (code) they are buying something else </S2>
<S1> yes they are buying the ideas and the intellect behind the design work </S1>
<S2> (then maybe) there's some kind of ideas or or whatever related to that issue that's what i think they are really buying </S2>
<S1> yes </S1>
<S3> er i have another area of question er in classical port design er it was important er to have information about the number of pins coming out of the board and on the board you have a set of a number of logic gates and there was a famous rule giving an answer of the number of pins you might have in a typical design as a function of the number of gates so there was a famous or there's still a famous company in the (work) and some (boss of) that company invented er that law or rule can you comment about that </S3>
<S1> i i know the rule but was it rent's rule <S3> yeah </S3> <S3> [rent's rule] </S3> [yes] rent's rule yes </S1>
<S3> can you a little bit explain the rent's rule er as it was important in the old days of mainframe computer design </S3>
<S1> it's not my area of exp- of expertise but as i understand it was something like er experimental rule so it was sort of found out that er how the complexity of these components have the number of pins that they have </S1>
<S3> so there was a law in the form that the number of pins N-P is equal to a constant K-P times the number of gates power (vector) , yeah so it's quite simple law N-P equal K-P times N-P power beta and beta was something like one half and this K-P was 2.5 for the typical er IBM computers and later on this law was used to calculate the average length er in a gate array so er er the new question now to you is there also something that you could exploit such a rule of thumb from rent's rule on the system level chip system level that we have now (another) mainframe computer some (portable) mainframe computer (that has) system on a chip and you can calculate some of the features like this average length </S3>
<S1> yes of of course those sort of rules of thumbs would be very very useful but i i haven't seen any any one one (making) suggestions like that this doesn't mean that they wouldn't exist but </S1>
<S3> mhm mhm , but i guess it would be an interesting area where <S1> [yes yes] </S1> [you could] also introduce such er rule of thumbs for (ending) the design (complexity) in system on chips , an important area of your field is network on chip er . and er currently we see more and more runtime reconfigurable com- components being used in (industrial) designs and future (xx) designs we discuss it shortly will rely on runtime reconfiguration to adapt to different operational scenarios as we have it for example in ubiquitous computing and reconfiguration can severely alter the application's communication profile so er , will this influence on-chip communication architectures </S3>
<S1> very much so i think yes </S1>
<S3> and how will you tackle that . if you have different operational scenarios </S3>
<S1> well in a implementation sort of point of view it's it's not that difficult but er how to control it and how to see what what sort of parameters and what sort of reconfiguration would be (would be s- having) be a problem </S1>
<S3> so the profiling of er the multi- multiple application <S1> yes </S1> domains er could communication profiles be be important [in this case] </S3>
<S1> [yes yeah] </S1>
<S2> <WHISPERING> (xx) </WHISPERING> </S2>
<S3> <WHISPERING> (we can go)(xx) </WHISPERING> </S3>
<S3> er you're not so far from the networking world er and in the networking world we have the ISO-OSI model as a well-known reference model er , i'm sure you are aware of the different er layers you have in the OSI model and do you think er that this model is appropriate for describing and modelling on-chip communication architectures and protocols </S3>
<S1> yes i've seen it used many times it's it's quite appropriate for those </S1>
<S3> and can you go in more detail and assign the functions of on-chip communication system er especially (bus layer) to the seven layers from the OSI model what is a comparison between both </S3>
<S1> well i can't remember all the layers of the OSI model i used in this book the (VSA) layer model it is very close to the </S1>
<S3> what page is it </S3>
<S1> er it's in . page 101 </S1>
<S3> mhm <P:10> okay </S3>
<P:09>
<S1> so that physical layer it's [(xx)] </S1>
<S3> [physical] layer there might not be so much difference i think yeah </S3>
<S1> yes and the , bus transfer layer deals with the protocols and of of that type , and the transaction layer then with the transa- transfers from sender to receiver sort of point to point transfers <S3>  mhm </S3> . then system level you have a some objects that are communicating with each other and then the application is on top of that </S1>
<P:08>
<S3> so er the answer would be that er you don't need all er the layers of the OSI model it is er too explicit for many practical er purposes and you can come along with the four to five layer models you have here <S1> yes </S1> and can it even be simplified or is it necessary to have them all </S3>
<S1> yeah maybe you could combine some of those , maybe for the bus transaction and transfer layer <S3> mhm mhm </S3> so physical layer the protocol layer and then the system [layer] </S1>
<S3> [mhm] </S3>
<S2 AND S3 WHISPERING, P:52>
<S3> (xx) (instructed to be you know) </S3>
<S2> so i think (xx) might be (xx) for these objectives and and (xx) er (in the during the) end of this er (xx) er so er (xx) part of the design (xx) (direct) (xx) of the uses and when you state in the last sentence you say er er <READING ALOUD> system designers to choose the interconnect architecture for their own cases </READING ALOUD> so are there any (xx) standards </S2>
<S1> well the standard usually don't build the interconnections (in the) apart from the (xx) that they usually deal with the interfaces of so <S2> yeah </S2> so the way in which and even the way it's (then) (xx) based system or or interconnection could could be designed it's still a design issue of how you use pitches and (past) segments and so forth <S2> okay </S2> (xx) </S1>
<S2> (could you tell us) a little bit more that that why you cannot find the one solution that fits for everybody so finding (means) (xx) (this stuff) </S2>
<S1> because the different applications have different er transfer profiles and maybe they require different types of bandwidths and connectivity </S1>
<S2> what about the (xx) this type (xx) </S2>
<S1> then it would be a waste for some simpler application </S1>
<S2> so so you think that there isn't any any kind of super interconnected pitch for everything so (do you have any) (xx) simple interconnecting in simple case and for difficult (in which) (xx) case </S2>
<S1> yes definitely yes </S1>
<S2> okay and then in the next sentence you (convert er) the you (say say) <READING ALOUD> the selection process is almost always a trade-off between complexity and performance </READING ALOUD> so could you could you can you explain how (or what kind of) (xx) you have (xx) complexity and performance (within the) (xx) so how they are related or </S2>
<S1> well , i think that usually the case is such that you you require some some performance and you try to design your interconnection to be so simple as i- simple a- or as low in complexity as possible </S1>
<S2> but er are these complexity and performance then related to each other or do we <S1> [well] </S1> [(xx)] (interconnection) has to (go through) performance </S2>
<S1> well not not directly no but er usually it's such that er with more complex systems you get more performance like er (file) transfers and some something like that </S1>
<S2> then it's it's er it's a question of defining the complexity in (scenarios) (i think that's) (xx) the system can be (ascertained) (xx) so in all the (positive) but it depends how high you define the complexity (xx) . then i think in the third paragraph you you say that er <READING ALOUD> the practical studies are conducted with the aid of a standard simulation and synthesis procedure </READING ALOUD> so er do you refer to either of these standards here or <S1> [no] </S1> [what kind] of standard you have </S2>
<S1> no it's a more or less the way in which er (xx) like a industry so it's a practice actually more than standard </S1>
<S2> okay so more or less no no standard </S2>
<S1> yeah but the but some a way of (a) design way that is used very widely </S1>
<S2> okay so then you (xx) <S1> yes </S1> (xx) </S2>
<S3> what level of confidence do you have for your method </S3>
<S1> do you mean that do i do i trust this <S3> yeah </S3> [(xx)] </S1>
<S3> [(xx)] trust er </S3>
<S1> well i usually like to check the results <S3> mhm </S3> the synthesis is quite er old but it's it still has some holes in it , i think </S1>
<S3> what is the difference between simulation and emulation </S3>
<S1> well i think that the simulation it's a lot more like a software approach so you er the system that is that you are trying to verify is is described as as software mod- modules and in hardware you somehow combine it to a hardware platform or some hardware receiver </S1>
<S3> so the main difference would be what when you want to have let's say real-time execution of your system </S3>
<S1> well er </S1>
<S3> can you do it when you couple it to a simulator </S3>
<S1> no usually you require a emulator for that </S1>
<S3> mhm </S3>
<S2> er just one more question for this terminology you er you say that this er (divide) you've done is heterogeneous I-P block (xx) so could you (xx) define heterogeneous (is) in your case </S2>
<S1> it means that the blocks that are connected by the bus vary in many respects they can been processors for example of different sort memories some er (educated) I-P blocks and they are they can they can vary in many respects </S1>
<S2> so do you mean that you have one one in interconnect or interface (only small) (xx) whatever is inside the (hole) would be (xx) </S2>
<S1> yes so it's not usually it actually can be applied for different systems also but it's not usually used for situations where you er would use a certain component and then implement it several times </S1>
<S2> okay so so you mean that that er non-heterogeneous would be (xx) component (executed) (xx) <S1> yes </S1> and that would require (an entirely) different kind of solution that you are (connecting) and i mean you say that you won't discuss analogism in this thesis so are you considering that (xx) (obviously) so much interest </S2>
<S1> yes </S1>
<S2> okay </S2>
<S3> and the interface when you see the interface that couples digital sub-blocks together you need a certain complexity and later on er in er sections six and seven we'll go into more detail but don't you feel that er the overhead you had to pay for using such a general interconnection scheme is much too high to afford it let's say for high performance designs in video processing in industry <S1> <COUGH> well </S1> it might perhaps be good for coupling big networks together of computers in internet (style) but er the question is if you can really afford something like that er er how system on-chip case because requirements are too high concerning chip area when you go for production (data) on you must have the smallest chip area otherwise the cost are getting too high </S3>
<S1> er it's of course a trade-off if you want to tune tune your hardware and get the best possible outcome then you have to do everything separately but the gain you get from using a standard interface is that the design time is short but if you want maximum performance of course you have to modify it by hand </S1>
<S2> (xx) </S2>
<S3> okay mhm </S3>
<S2> okay maybe it's on to the next (big) chapter then so first these kind of normal questions or (what situation) (xx) selected or did the title of this i mean (xx) things like that </S2>
<S1> no </S1>
<S2> so it was real choice or or word processing @choice@ or </S2>
<S1> processing choice </S1>
<S2> that's i mean that's a gen- general way how how things happen so you have some tools and then you use it and you can't find @what you want@ so so you see it that that this er (VLSI) design or whatever is (xx) (same) so you you use something and then the end is what the tools happens to do for this </S2>
<S1> well the the way in which of course (you'd like) do things is that you sort of describe something in VHDL and then you (we- it goes through synthesis) what you get is actually what you wanted but it er it might be so so you are sort of in the mercy of the synthesis programs in that respect also so you have to check what what comes out also </S1>
<S2> er so you just say on word processing (make nice) (xx) for me and then then it it makes (them) and that's it <S1> yes </S1> then you need it to mask or (xx) </S2>
<S3> what is the benefit we have (from the by-product of the gajski) </S3>
<S1> i think that er it quite nicely sort of graphically illustrates the er [(co- co-)] </S1>
<S3> [there's the] axis and </S3>
<S1> [(xx)] </S1>
<S3> [what] is the purpose of these circuits and what can i really do with er er gajski representation </S3>
<S1> wh- well i don't know what you can really do with it but er sort of , it's it's quite an illustrative er way of looking at the different ways of looking at the system it's it's (xx) behaviour and how it's still , and then how the sort of normal or one [(xx)] </S1>
<S3> [(and isn't it important)] for your topic of your work (it was) interconnection architectures </S3>
<S1> no it's not crucial it's just just to explain this (formula) (on for chip) most of most of the time </S1>
<S3> mhm , (xx) </S3>
<S1> er </S1>
<S3> some benefit you must have from the (gajski chart i hope) </S3>
<S1> o- only the illustrative points for me as er </S1>
<S3> but if you think to the design flow of er such an er interconnection centric design in your case how you how would you run through the gajski representation we cannot have a design flow with the gajski representation , wh- when you see the mapping of a of a communication architecture in your case how can that be represented in the gajski net </S3>
<S1> if if you you look at the how it how would the normal sort of practical <S3> mhm </S3> design process go through this it would er more or less start from registered transfer do you mean like that , (if you) start from a behavioural domain then use this synthesis process that we are used to talk about today and go to the structural domain so you can er change the domain through synthesis , and then through mapping we can get to the centre of the circle which er implies sort of a lower abstraction (and all the) so you can co- close it to the implementation </S1>
<S3> you mentioned the golden reference how how would we get the golden reference </S3>
<S1> well it usually it's it's just something that we know that works somehow it it requires that we test it and er see that it works er really thoroughly er i i'm wouldn't like to use it as a something that's er i i wouldn't like to use it very strongly it's just something that we are almost sure that it works correctly or we have checked as thoroughly as we can </S1>
<S3> then we have found it out purely by er intuition and using simulation </S3>
<S1> yes yeah we <S3> [mhm] </S3> [(have)] we somehow know how what what it's supposed to <S3> [mhm] </S3> [do] and we <S3> [mhm] </S3> [check] manually that it does <S3> [mhm] </S3> [(them)] just so </S1>
<S3> mhm you show in figure two two the classical digital system design flow <S1> [(yes)] </S1> [yeah] and er when you see this design flow and you look to something like the design automation conference where hundreds of companies are offering tools for , on what level do we have good tools available nowadays what is industry standard and what is still a problematic er part in the design flow </S3>
<S1> i i think [that] </S1>
<S3> [and] the second part of the question would be and why do we go through platform based design , yeah </S3>
<S1> the first [part] <S3> [yes] yeah </S3> is easy part er so the standard industrial flow is (at least) starts from the registered transfer level description so <S3> mhm </S3> there are behavioural synthesis (goals) but and they are good for some some stuff like er like data (prototype or stuff but) usually (RT-) RTL project synthesis and then (xx) are the like industry industry standard tools </S1>
<S2> (what about in transportation) you you say the complementary so could you (xx) the complementary for this use or in which context (complementary is located) </S2>
<S1> i- in the flow that i describe it would be the RTL simulation </S1>
<S2> okay so basically you say that this is the first model with no (xx) kind kind of er (i mean) (xx) this is the right one this is what i want and that's the RTL (xx) </S2>
<S1> y- y- yeah <COUGH> yeah the system in the clock cycle er or what that what that accuracy phase is is based on </S1>
<S2> i i (mean) just just (it's) methodological so so we see that (xx) behavioural (indication) or whatever it has systems (xx) language (that) but you are (claiming) today that that they cannot be (wholly recognised for at least) (xx) </S2>
<S1> yes i at least i have used that (there) i think that they could be the golden reference but i . i have no experiences of a case where where it could happen a thing like that </S1>
<S2> okay so what what can you describe the saying that the er (many times) that there are formal verification and er (xx) </S2>
<S1> formal verification </S1>
<S2> yeah i i mean i guess that you have (developed a) very (xx) and then you said that it's in your case RTL so or are you (sure enough) that they they make (xx) or is it like (xx) anything like that if it's anything like that </S2>
<S1> i have toyed with the formal verification tools for some times but er they they might be good for some things but er i would still want to check it some other way also </S1>
<S2> but er are you (xx) then you stated you have golden reference (xx) (manage to say) that the results before that are are exactly the same </S2>
<S1> well er er using the golden reference to in in simulation for way that we can check that the simulation results from different levels are the same </S1>
<S2> so you are you are saying that that you designed a system and on (hardware) level you you (initiated it) and then then you went through it all and you don't trust that the tools are even right so so you can run run the test again in er in er (xx) </S2>
<S1> (xx) that the results are the same </S1>
<S2> so you think that (the things) might be better in the next generation or things like that , i mean er is it (xx) </S2>
<S1> i i know that a lot of (lot of) people and lot of companies are doing (heavy) research on many areas here and i i would at least hope that er something useful comes out of that </S1>
<S3> let's come back to the diagram for the digital system design flow if you like you can even use the blackboard and what are the extensions when you go to this platform based design this is a classical design flow and it has been recently extended to take care of this platform based design and er what is the extension essentially you can either explain it or even draw it on the board if you like </S3>
<S1> well er i think that er if i try it first without using the board er the extension is that we first design these I-P blocks or whatever blocks they are in in this manner as is described here and then er extension would be how to in the sort of high levels high level designs er how you design systems using these blocks that are already ve- verified </S1>
<S3> but before you can design these blocks you must start with some system description and er what is (read) as a top level then </S3>
<S1> it's just </S1>
<S3> before you can think about specific I-P blocks . what is the highest level and how do you describe er your designed information on that level </S3>
<S1> just er the requirements of for for the system and er . then sort of the , so that (behavioural is) consistent without any any like er (xx) to the how it's actually (built) </S1>
<S3> but it's the beginning you have pure information about the behaviour of the system or even higher and you don't know about hardware software and what about hiding what to do in hardware what to do with software so can you comment about that </S3>
<S1> well actually that's a also a very very big problem and something that is er researched at our laboratory also so how how you do sort of the mapping and </S1>
<S3> but there are (portraits) in the literature since many years how to proceed with the hardware software partitioning , <S1> yes </S1> can you comment them (tell about them) </S3>
<S1> er i know of a few examples i can't remember who whose proposals they were i i think that er some people start from a (whole) er first design their system like it's whole whole implemented on software only and then if they need some [like (xx)] </S1>
<S3> [(xx) mhm] mhm move it <S1> yes </S1> mhm to a hardware section </S3>
<S1> yes and i that think also other way around so do it as a whole whole system as hardware and then you <S3> [mhm] </S3> [can] build parts on software if you wish </S1>
<S3> you you have here section which is fairly small but very important in er the second chapter er with the name design and fabrication cost and you gave the definition of N-R-E cost and you mention the high er extremely high cost for mask er fabrication and what higher what what how how we can really live with this high mask cost it means essentially we ten years ago we were able to design chips and present them proudly to the public because everything was affordable but when you see now the high mask cost we we cannot er do the chips and we need er other forms of prototyping <S1> yes i  </S1> and other types of reuse and can you comment about it what are those strategic directions we need in the future to live (with) the high mask cost what what are the possibilities we have to develop for example </S3>
<S1> well i think er where to go is to programmable and reconfigurable systems so <S3> i didn't understand </S3> so programmable and reconfigurable systems so when you design a system it needs to be applicable to different cases so all (or) did you want to design a chip that is only used for one particular application then <S3> [mhm] </S3> [you] need to be sure that it </S1>
<S3> can you give concrete examples how we can go for some form of silicon reuse not only reuse on on the level of I-P blocks in VHDL but er er silicon reuse </S3>
<S1> do you mean reconfiguration or </S1>
<S3> could be a possibility </S3>
<S1> well parts of parts of the silicon could be designed so that the end user can implement their own mask (straight) </S1>
<S3> when you go to the (ISSSE) conference you see good examples of er how the designs evolve in the companies we have an example from (port- er porto) for example where the er (headset) M-PEG two decoder and a year or two later er they have er a set-top box has a single chip where this M-PEG two decoder is a sub-block so this is really an example of silicon reuse <S1> mhm mhm </S1> . could come back to power consumption also in chapter three we discuss it in chapter three as a . (xx) (discuss) <S1> y- yeah yes </S1> <P:06> so we need not discuss it here you you could please simply tell us er why the power delay product is something of importance and in what physical dimensions you measure it or the classified technologies </S3>
<S1> well power delay product it's a more or less one (or) the same things as energy and energy is the <S3> en- </S3> energy so so it's the important thing that should be minimised </S1>
<S3> and (the important) physical dimension it is (beginning to to empower this) , and what what do we do with er hardware to measure the power delay product </S3>
<S1> we just give it a task and see how long it takes [to (xx)] </S1>
<S3> [what is] a ring oscillator </S3>
<S1> what is a ring oscillator <S3> mhm </S3> er just something that goes around in a circle [(xx)] </S1>
<S3> [(xx) more] (concrete) what do we have in the chain <S1> (xx) </S1> in a ring oscillator <S1> yes </S1> what do we try to get (and make) the feedback as you said what are the individual blocks (to do with it) </S3>
<S1> er . you cut me out </S1>
<S3> @@ there is a basic blocks of different digital logic families and what is a basic digital block when we look on these electrical features . most simple logic function </S3>
<S1> er just (a er an) inverter <S3> yeah </S3> yeah </S1>
<S3> mhm what number of inverters we have to couple together and make the feedback </S3>
<S1> er for example two </S1>
<S3> is that a good choice two </S3>
<S1> er i don't know , i really don't know </S1>
<S3> yeah you know it er you have to find it out (xx) <S1> oh </S1> if you do it with two <S1> [oh oh oh] </S1> [inverters it's not a a] how do we call such an element then </S3>
<S1> yeah it's it does nothing but one </S1>
<S3> how do you call it , if you couple if you do a cross-coupling of two inverters we've come to famous basic digital block which is a </S3>
<S1> (buffer) </S1>
<S3> mhm </S3>
<S1> (xx) do you mean if you con- connect two inverters but you get you get nothing er buffer </S1>
<S3> no no no no , how do you define flip-flop </S3>
<S1> er you m- yeah yeah (xx) registers </S1>
<S3> so selecting two is logical choice because if we're hopefully stuck in (logic) three or (logic) one <S1> yes </S1> and you need at least an what number three or five or seven <S1> yes </S1> mhm , and how do you compare let's say er the power delay product of a bipolar er classical bipolar technology with some advanced C-MOS technologies </S3>
<S1> [well] </S1>
<S3> [and] how do you compare it when you drive (with) your car on a highway </S3>
<S1> well some , it's it's again a a trade-off problem so do you want to er go very fast or do you want to your car to burn as lit- er <S3> mhm  </S3> little fuel as possible </S1>
<S3> mhm </S3>
<S2> maybe maybe just just one one in this case (i think so) so you say that er <READING ALOUD> power <SIC> minimation </SIC> minimisation is usually obtained at the price of increased area or decreased circuit speed  </READING ALOUD> do you think about that i mean this (server is the only) (xx) talking about </S2>
<S1> er the penalty doesn't need to be very large but you need something to add there if you want to you can ask for example block (gateway) so is it some circuitry you would cut </S1>
<S2> (yeah you could use a blockade do you mean you have the blockade yes) or or do you (xx) but but (xx) is it always (good) (xx) increased area (xx) (probably much better than the) </S2>
<S1> no actually of course if you make the chip as simple as possible it it should consume little energy then </S1>
<S2> yeah (i think that's it) </S2>
<S1> @@ </S1>
<P:13>
<S3> i think you could could look (xx) </S3>
<S2> yes so the section three now <P:27> that's a (xx) (used to discuss with er many) (xx) (in this picture and to fam- to make familiar) and compare the both cases from this university so he's quite probably presented here i think so (i i) any questions or (xx) </S2>
<S3> i don't think so </S3>
<S2> so for this paper (would very very) (xx) (contained) 3.2 so you you keep this theoretical (xx) how well do you think (these are related) to wrapper designs </S2>
<S1> i think that they give just sort of a rough idea of what's going on but they are not not very accurate no </S1>
<S2> then when you used (xx) interconnect or or network (based on) (xx) bandwidth (xx) (they would with er) </S2>
<S1> no not not (hierarchy) based that is no </S1>
<S2> so do you (pretend) it's (xx) so how should i say (as you say) (xx) (can't) think what to do </S2>
<S1> well er as i said earlier this selection of the interconnection is more or less (a trade-off) problem so you can look at this table and choose if you want er something that theoretically provides a lot of er capabilities or something that implies a small cost </S1>
<S2> so if you're (going to take this) (xx) (as four parts here) so in a single file you you say (xx) (the dissertation) (xx) </S2>
<S1> the longest path er as it is defined in here doesn't take into or or actually or none of these do- don't take into account the physical dimensions of the of the (chip) so this is just means that there are no switch components on the on the longest path but er in a single bus typically the the wire would be longer than in some of the other networks </S1>
<S2> yeah that's that's what i mean if you run (xx) (it won't be there compared to) (xx) (might have been there so) (xx) (actually) (xx) in the right one but with (xx) in a sense that if it doesn't doesn't say say for example that in in (today's) (xx) or (xx) (must be done buffers) or or something like that so you have (actually) some components there or you (xx) in in single file er so it's logic that you go to the (xx) at least (xx) </S2>
<S1> (xx) it is er tries to be on a very high (level here) </S1>
<S2> i'm just trying to find out what's the significance of this table i mean does this (xx) mean that (xx) </S2>
<S1> no it's in a (xx) </S1>
<S2> (is it) just outside (research (xx) look at that) (xx) </S2>
<S1> well both of course but er you can use these as a when you can't understand what's what this says and what this doesn't say </S1>
<P:10>
<S2> okay then the with the next table actually (erm er) what is that er <P:10> so you said in the text that er <READING ALOUD>  one requirement of an ideally scalable system is that the bisection bandwidth per node must be constant </READING ALOUD> and then the next sentence you say that <READING ALOUD> this requirement is not met with systems having constant bisection bandwidth </READING ALOUD> so this kind of (xx) just below the table </S2>
<P:09>
<S1> i have to think about it for a while </S1>
<S2> are you hoping for two two (causes) here or </S2>
<S1> it seems to me like that also but . so actually what it tries to say is the first sentence only but </S1>
<S2> so you think that the bisect- er bisection bandwidths per node should be constant that's </S2>
<S1> no no it should be something that the . this er scale with the large numbers of nodes , so constant bisection bandwidth is not good </S1>
<S3> but the requirement as you write it down (here so) should be correct er <S1> [(xx)] </S1> [(maybe)] can you explain it even the requirement er by telling that requirement is not meant for systems having constant bisection bandwidth as seen in the (xx) bus by (xx) </S3>
<S1> so what what's the problem there actually the what it tries to say is that the bisection bandwidth per node should be constant so er er it's it's an ideal requirement and then you have a constant bisection bandwidth which gets smaller as the number of nodes increases </S1>
<S2 AND S3 WHISPERING, P:25>
<S2> so page 41 . so (that you on line four) (xx) er you say something that i (didn't) think (switch is slow but) (xx) (so i think on page 41 where it says) (xx) </S2>
<S1> (where is it) </S1>
<S2> so you say that er er . <READING ALOUD> this makes the switching more complex and slower than in the circuit-switched case  </READING ALOUD> so you are saying that packet-switched system are are worse at least in in in (feedback) circuit-switches </S2>
<S1> no this only means that usually circuit-switching implies some sort of er initial or (start-up) time when you follow paths and after that you don't need to do any (xx) you shouldn't (xx) on the path in the packet-switching you usually er route every packet in- individually </S1>
<S2> er but er (do do you think it has to be compared) (xx) so what's actually the the biggest di- i mean you (did) explain it in the text but er what's actually the the difference between packet-switching and circuit-switching based systems or , (can you) (xx) maybe maybe (having designed thought there) er different terms and then it would mean different different stuff but when you start to design this kind of (methods) or what's actually the difference </S2>
<S1> well er i see that the packet-switch scheme requires sort of more int- intellect- perfor- intellectual er er routers so because the routers make make the deci- decision somehow how they how the messages or the data is routed from the sender to the receiver and in the circuit-switching case (you) usually just follow the path somehow and then the data can go through the path </S1>
<S2> but er what about er the (xx) (also needs some information) (xx) packet or stuff like that . i i mean in circuit-switch design you clearly need to somehow select the destination in that case too </S2>
<S1> yes yes and you need some sort of er actually cen- (you know) centralised control for that </S1>
<S2> yeah but what's then the difference . i mean in in both cases (xx) <S1> [yeah] </S1> [in the] circuit-switches you have to address an (instant) destination (address) </S2>
<S1> yes you can the the packet you can use those er with er with respect to circuit-switch schemes but i i think the the diffi- difference is really that the in the packet-switch scheme the routers make the decisions they usually have buffers and some sort of a routing scheme implemented in them and in the circuit-switched case the in- intellect is somewhere else </S1>
<S2> but er (into these components er why) (xx) you could have (xx) (or buffers) in your system that takes care of them </S2>
<S1> well maybe you could but er i </S1>
<DISC CHANGE>
<S2> (i mean) you have quite a much of of these buffers in your system </S2>
<S1> yes but they are only the well they might be a- also somewhere else in the system but in the simplest form they are only in the sending and the receiving component not in the in the (integrate) itself <S2> yeah </S2> unless you want to utilise (well) complex hierarchical structures </S1>
<S2> yeah (xx) you can say that they're not that far away from each other so (xx) really really (xx) comparing (them there might be they are quite close to each other) so it it depends on (xx) requirement stuff and the difference and so on (again) i i know that if you if you just er take some textbook of (xx) i'd like to have it (xx) interface so they are typical (for all reasons) </S2>
<S1> yes </S1>
<S2> okay </S2>
<S3> okay er this term arbitration er i think it's , it's a classical term in principle and er it plays a central role here and you define it in section three four and you talk about static and dynamic arbitration , and are both equally important for er the design of your communication structures </S3>
<S1> well i think i think that the parame- -meters are usually a- (are) (xx) studied (methods) are that's my sort of er how i feel but , they er both can be used and (i think) best results are (xx) if we use them both </S1>
<S3> and the cost for introducing dynamic arbitration , what is the overhead er we have to pay er using dynamic arbitration </S3>
<S1> you have to have a arbiter a unit </S1>
<S3> mhm and we have to pay for the <S1> [yeah area] </S1> [area the] routing of the information i guess <S1> yes </S1> mhm , and er you mention here round-robin as a dynamic arbitration method and this is quite a classic old method which we had also in handling er interrupt schemes in microprocessor-based systems are there other er dynamic arbitration methods available </S3>
<S1> well these pri- priority priority based schemes <S3> mhm </S3> also </S1>
<S3> mhm okay let's come to er the section on physical interconnection , and you start with a fairly extensive er description also going to the er layout level of the geometrical parameters of interconnection wires and some question at the beginning which two types of power dissipation does do you distinguish in your work </S3>
<S1> it it's two er dynamic and static </S1>
<S3> mhm , and er , can you go in more detail in handlings of power dissipation what are the physical contributions here , we have either we can classify the static or dynamic power er dissipation and what are the physical origins </S3>
<S1> well usually in C-MOS er </S1>
<S3> we have a s- (the arbitration) you can go to the example on the C-MOS circuit </S3>
<S1> er so wh- when the dynamic power consumption occurs when we when we have some sort of switching in the scheme so value of something changes [from] </S1>
<S3> [do we] have some form switching </S3>
<S1> er the values changes <S3> [yeah] </S3> [from (one to)] zero zero to one </S1>
<S3> mhm that's one contribution </S3>
<S1> [and the] </S1>
<S3> [and] another one </S3>
<S1> to the [dynamic] </S1>
<S3> [if you] think to the C-MOS circuit [(xx)] </S3>
<S1> [you have] dynamic part er actual switching process then then you have a short circuit might have [or (xx)] </S1>
<S3> [short] circuit between <S1> [yes] </S1> [(xx)] and (xx) so you have a short circuit (just a part) and finally when you think the gate is in state zero or one what [then] </S3>
<S1> [the] we are getting the sort of static or leakage [power yes] </S1>
<S3> [leakage leakage] power yeah and can you talk little bit more about the dynamic power er dissipation what is the classical formula (i want to hear now) </S3>
<S1> er do you mean this activity [(xx)] </S1>
<S3> [(i)] (think the er gate) it has a certain power supply (xx) and some output capacitance and how do we calculate the dynamic power </S3>
<S1> er it's the , it's er the voltage times the [(frequency)] </S1>
<S3> [can you] use that formula you can write it to the paper if you like </S3>
<S1> do we have a chalk somewhere </S1>
<S3> but you can also <S1> okay i [know] </S1> [(xx)] text (xx) </S3>
<S2> <FOREIGN> sen tohon pöydälle </FOREIGN> </S2>
<S3> you can <S2> okay </S2> just give us the formula in words <S1> [er] </S1> [that's] okay </S3>
<S1> it's er capacitance times the the the frequency or the er (well if i ) (xx) it's the capacitance times the frequency op- operation times the op- operation operating voltage to the second power and then divided er multiplied by activity how how <S3> [yeah mhm] </S3> [(xx) changes] </S1>
<S3> and now it's important if you really want to realistically model the power in the physical interconnect you must go to er (IPSA) (xx) technologies and what happens er in (IPSA) (xx) technologies regarding classical C-MOS power consumption </S3>
<S1> er the leakage power becomes it it has been out of control but it becomes more important with <S3> yeah </S3> so so </S1>
<S3> and , er can you give a formula how the leakage power depends on something (or the) and you (looked as) a sup- special current that is flowing in the transistors </S3>
<S1> it's just the (if you if you have) the current it's current times the er voltage </S1>
<S3> i didn't understand that </S3>
<S1> well i i'm not sure i don't know what what formula are you aiming at here usually it's just the if you have some sort of leakage current then the (it's) current current times the voltage </S1>
<S3> mhm mhm but there's an exponential law how it depends on (xx) minus (xx) </S3>
<S1> yes i . i i have i believe i have seen it some somehow somewhere but [i have] </S1>
<S3> [and if you] consider now such a technology like the 90 nanometre er technology er this leakage power how much of the total power is it </S3>
<S1> er i i don't know how much really but i i know o- only that [it's it's it's] </S1>
<S3> [(give a guess)] </S3>
<S1> it's becoming more important (than) i would say (half) </S1>
<S3> er it's not half but it's a value in (detail) some 42 per cent or 40 per cent <S1> mhm </S1> and what happens in the circuit you could say i i er increase (VT) the threshold voltage what happens to the speed when we increase the threshold voltage </S3>
<S1> er . er it becomes slow or <S3> gets slower </S3> yes </S1>
<S3> you reduce the speed okay mhm , i think i must (help your) formula three one , F-O four plus one half over R wire times C wire and F-O four is some (integra value) er er <READING ALOUD> four identical copies of itself </READING ALOUD> you say <S1> yes </S1> and then you have something which (has a dimension) of a (time then) so you add something that is out of dimension to something that's a dimension of time this is formula three one is it correct can it be correct </S3>
<S1> er these formulas are not developed by me i just wanted er some way to model the interconnects and (it is) <S3> mhm mhm </S3> and i think i have seen in in many occasions the same same formula </S1>
<S3> and when you look to the formula 3.2 what is the fringe capacitance when you or what is it </S3>
<S1> er capacitance so to (xx) <S3> mhm </S3> (xx) </S1>
<S3> i didn't understand that </S3>
<S1> er the sort of [capacitance] </S1>
<S3> [when] you look to plate <S1> yes </S1> classical <S1> from the  </S1> plate capacitor </S3>
<S1> from the [plate (xx)] </S1>
<S3> [(what does)] mhm okay . in this formula 3.3 er , you calculate the resistance of a wire and you have those er specific resistance rho divided by the thickness minus the barrier times the width minus two times the barrier and is it correct er you don't have to take the barrier and two times the barrier out of that formula so we have only rho divided by the thickness times the width </S3>
<S1> well you could (simplify) it <S3> mhm </S3> but you could (simplify) of course but er this is only to show er it might be [(xx)] </S1>
<S3> [(xx) not] with your your diagram . because er the resistance value is only given by the (black) area <S1> okay </S1> mhm . and you take the thickness times the width as a product in the denominator </S3>
<S1> yes actually i- in here the width should be actually the from the edge of the figure so the width minus two times the barrier is the <S3> mhm </S3> width of the <S3> mhm </S3> wire </S1>
<S3> mhm can you explain your figure 3.13 </S3>
<S1> it's just the results of that using those calculations [er] </S1>
<S3> [can you] physically explain what what what's going on there </S3>
<S1> well the resistance of a fixed wire is <S3> [mhm] </S3> [growing] as we move from one technology generation to another <S3> [mhm mhm] </S3> [(with) different er] (xx) </S1>
<S3> and can you comment about er circuit techniques to manage su- such a leakage what would be appropriate circuit techniques </S3>
<S1> er i i only know that the the methods are actually quite quite er on low low level but er you could play with the threshold voltages or the supply voltages or use either [(which is sup-)] </S1>
<S3> [but you] have some fixed supply we are good er we can change the supply voltage mhm </S3>
<S1> or the threshold voltage or </S1>
<S3> changing the thre- threshold voltage means er that you have some fabrication technology as a let's say tool (repeat) partitioning <S1> yes  </S1> yeah <S1> yeah </S1> or you might even think to not only (tool) but to multi- (special) circuits </S3>
<S1> yeah yes and i i believe i have seen somewhere that you can use er transistor stacks to lower the [leakage yes] </S1>
<S3> [or even a] that you have stack arrangement mhm , then er for what kind of transistors in your design you choose a low VT and for what kind of transistors you choose a large VT </S3>
<S1> er low VT for the timing critical parts </S1>
<S3> okay performance critical parts yes and the large VT for the less <S1>  yes </S1> er timing critical parts , you didn't mention anything about inductances are they unimportant or </S3>
<S1> well , i know know that the many people think that they are going to dominate and the trans- this sort of er (transition like effects) <S3> mhm mhm </S3> are going to dominate but it goes so deep into the physics that i it was too tempting to leave them out because er there are i wa- just wanted to form this sort of rule of thumb that's accurate enough for me </S1>
<P:13>
<S2> er just just one one (one question) you say that there are (xx) (golden reference) but and if you or think they need er a system that (xx) for instance (xx) , or is it (xx) </S2>
<P:11>
<S1> no not nothing else but the but to use as we (talked about) earlier use low-leakage product er er parts for those parts in a system that are not so [critical] </S1>
<S2> [that that's] (xx) i'm thinking much higher than the leakage </S2>
<S1> i if we still talk about only C-MOS or or are we talking about silicon insulator or </S1>
<S2> neither actually (xx) (mathematical) technologies we have in the (xx) very high level (xx) so (xx) (has developed) </S2>
<S1> i think you cut me out </S1>
<S2> one idea would be (xx) </S2>
<S1> yes if if (because of) all the power consumption </S1>
<S2> er i i think that er the these issues are are (relevant) these high level issues so so you can't (turn o- off) (xx) system (xx) (designed it at all) also these (xx) are then (xx) </S2>
<P:12>
<S2> (xx) </S2>
<S3> mhm yeah okay (xx) </S3>
<S2> okay so next for these NOC architectures so er do you think (they're a good) example of the of (telephone networks) and and say latency (is another) problem (in this kind of stuff) and is that correct or (xx) in the first first first paragraph erm . (xx) but then they they have (these sort of these latencies have been) usually (programmed for example) </S2>
<S1> i can't , in page 47 of er <S2> yeah </S2> at the first paragraph </S1>
<S2> first paragraph and and in in (later) you say that <READING ALOUD> communication networks like like telephone networks </READING ALOUD> (you know that) and then in the middle you say that <S1> okay </S1> <READING ALOUD> latency is not usually a problem </READING ALOUD> </S2>
<S1> not not of course it's a problem if it's it becomes too long but er (yeah) in the circuit (development) we are talking about clock cycles and very very small latencies can become problem in er communication systems at at least in some most of the cases it it's not so important ex- ex- except as it's kind of stated here in the (xx) so in systems that require real-time traffic </S1>
<S2> yeah so so now you're actually s- using the word latency and and er in different places you (are using) different things so so really i mean (of course i know) latency (is one of key clock cycle) (xx) that i mean must must (be also needs) (xx) things like that but are you (xx) latency's important in that issue so (xx) you would like <S1> yes </S1> and actually i think that (xx) a little bit (xx) the definition definition what are (the relevant) (xx) what kind of latencies for example (xx) (technology) so so we know that there are (xx) latencies (xx) can handle that so </S2>
<S3> the examples er you are giving in tables three five er three six and three seven are they really representative for what is wh- or what has to be designed er as S-O-Cs for example the real er chip coming out was only this PADDI system i remember <S1> yes </S1> from (xx) and it's a big crossbar er dynamically configuring the crossbar and getting different types of interconnect er so and even that was not a real system on a chip i would say but more some kind of flexible er er (portable) er system </S3>
<S1> yes this whole network on chip concept is actually i think quite new and er these are just representatives of of different ideas that people are having (at any one time) i don't think that many have actually implemented anything at the moment </S1>
<S3> any record of (more) (xx) related to classical computer architectures computer networking than er to real system on-chip requirements </S3>
<S1> do you mean (ex- ex-) examples or <S3> yeah yeah </S3> yes (xx) yes . they are usually presented only at the at the concept level </S1>
<S3> mhm </S3>
<S2> so maybe chapter four then (it has) (xx) . in figure 4.1 , so (in addition to) some referencing in in in figure or this bus (xx) do you use the maximum frequenting or or is it (running) </S2>
<S1> yes we i tried to follow the requirements that were presented earlier in this er table (2.1) , the frequency requirements of that </S1>
<S2> (nice to see on one) page number can you say the page number </S2>
<S1> er 26 </S1>
<S2> is the and the (xx) and do you (thought) that the (xx) bus (xx) (mainly) should be the same as the program's given state </S2>
<S1> yes </S1>
<S2> is that er (xx) </S2>
<S1> of course it doesn't have to be (xx) but the bus (stream) was (xx) (below) </S1>
<S2> (i see) (xx) then an example for (xx) computer for example so from the (levelling) is much lower than that (it seems to be) so actually there is er i mean the table (xx) (problem) for that must be (xx) it could be that the the (xx) theory that i (xx) for example inside this (xx) or (singular) bus it might be pretty (xx) than it would be in that sense , er (it's this) keeps the bus (xx) <S1> [yes] </S1> [(xx)] they're really really different in the lower (frequency) </S2>
<S1> yes of course yes , but the fr- the point still is that there is a link somewhere on how many components you can connect to your bus </S1>
<S2> yeah but er the point is that by having the same (xx) latency the (limit) is is not that small i mean you can connect more more components <S1> yes [(xx)] </S1> [(xx)] </S2>
<P:13>
<S3> you discuss these er different techniques for bus arbitration and can you comment about er having (simpler) bus arbiter or having a distributed scheme , er </S3>
<S1> what so was the </S1>
<S3> what are the aspects in how how easy is it find a distributed arbitration scheme </S3>
<S1> er it's er schemes are more limited when you use the distributed scheme or i i can only think of like er round-robin or TDMA actually in in our our own (bus ) (xx) or so implement some sort of a priority scheme but when you use a central arbiter there are no limits on on the scheme <S3> mhm </S3> and on the other hand when you use a central arbiter it's a distinct unit it's has to be in- in- included in the system and it's has to have a er line coming from its components in the system so it's it might induce some (xx) problems </S1>
<S2> yes so you know (there is) interesting example of this lottery bus is it used in in lottery machines or where it is used </S2>
<S1> it was actually so funny that i wanted to in- include it in here , they are u- give er sort of er lottery tickets to the components in the system and then they hold this lottery and give a winning number and if you want to give a higher priority to some component you give it more lottery coupons than besides it (all it's based) on that </S1>
<S2> er so are those really used to (xx) lottery machines [or] </S2>
<S1> [i i really i doubt it] quite much </S1>
<S2> okay so it is just a , okay i i thought that if you if you really have some some (weird) ideas that okay this this <S1> [mhm] </S1> [(xx)] on this and can help or can make out (xx) </S2>
<S1> actually i , the idea might seem funny but er actually they try to prove it with quite (heavily) that it actually is er applicable also to use the random test of the arbitration </S1>
<S2> er i mean this (xx) this this (whole) lottery bus anyway even that the (traditional) ideas are really (xx) quite (xx) that these pic- pic- in different different (order) , might be interesting (i just thought) by (xx) using (xx) lottery machine might be good example that okay </S2>
<S2 AND S3 WHISPERING, P:19>
<S2> so then in page 60 you you say er give an example of this marble bus so <READING ALOUD> asynchronous transfer technique </READING ALOUD> so does this exist in (xx) </S2>
<S1> i think that it it was implemented this m- marble in a system in which they had al- also implemented er asynchronous (xx) copy or (xx) , er copy and processor (code) </S1>
<S2> and it seems to be working okay or </S2>
<S1> at at least they claim so </S1>
<P:10>
<S3> this global asynchronous locally synchronous design technique cannot be you mention it here but can it not be exploited to a bigger extent in er final communication architectures for system on-chip because it's finally very attractive that they are only locally the synchronisation procedure </S3>
<S1> er yes i i it's one of the , the issue that comes out of (xx) when you look at the new new proplo- proposals for (the new) interconnections and it seems very very good idea </S1>
<S3> mhm </S3>
<S2> but we haven't used it </S2>
<S1> well in this phase not really only in concept level </S1>
<S2> then on page 62 so you mention something that er there are sort of mhm so so what (xx) (characters) or whatever you you used (do you think) (xx) hamming distance and things like that (xx) first paragraph on page 62 </S2>
<S1> sorry where </S1>
<S2> in in first paragraph on page 62 <S1> yes </S1> so you say that there are (encoding techniques) such as hamming distance and invert bit and er and data (blockíng) and things like that so do you can you say a few words of that </S2>
<S1> er </S1>
<S2> i mean is it is it (further) use </S2>
<S1> well i think that the problem with all these encoding schemes is that er if you look at only at the bus power consumption then there are few (for use) but they don't really usually take into account the complexity of the of the encoders and decoders of the system so they claim that it's a i think 25 per cent power co- consumption reduction in the bus but they don't say how much it costs to intervene </S1>
<S2> mhm but er if they say that 25 per cent savings and that's (kind of) the interconnect part so i think it's pretty much (intervening) from from the (xx) or i mean (this distribution scheme) (xx) (what do you say) </S2>
<S1> er , it it could be usable and yes but er i would like to test it first what are the benefits </S1>
<S2> so i i'm thinking a lot about this (xx) <S1> mhm </S1> (publishing) and (xx) i mean <S1> yes </S1> so that i i (xx) publications or things like that to (xx) (barriers) to this kind this kind of thinking so </S2>
<S1> there there might be some even by the same crew but i don't remember </S1>
<S2> but (anyway) (you have thoughts on) this this (xx) so </S2>
<S1> well actually you cannot try everything but it's a one interesting idea i think it should be tried out in practice </S1>
<S3> you mention this er quality of service aspect er and you say that erm erm S-O-C applications would also bene- benefit er er to judge on the quality of interconnection that we have to guarantee for er certain transaction number of transactions and we have to er calculate some quality of service measure er is there really work done er to have something like quality of service (analytically) calculated for given er communication architectures or is it only comparison with data communication aspects </S3>
<S1> i i think it's more only combines the </S1>
<S3> mhm . i think this point four , point eight standardisation is an important topic because er you derive this V-C-I scheme with a virtual component interface scheme in figure five four five yeah <S1> yes </S1> and can you explain a little bit the idea behind that </S3>
<S1> the [idea] </S1>
<S3> [(well)] this is er let's say some public standard or (post) standard the V-C-I standard and er of course we can discuss what available or what type of buses we have in the public domain but perhaps er er as we're discussing section in chapter six when you come to your own er interface structure perhaps what what i want to hear now from you is a discussion of the essential features of the interface scheme the virtual component interface scheme and how this er relates to your HIBI how what is the difference (what you later) have done with your HIBI er scheme </S3>
<S1> well the this scheme that it's presented here </S1>
<S3> we we can discuss it later on in more detail but the er (if we) concentrate now on the V-C-I scheme and how your HIBI scheme profited or is it the same or what is the difference </S3>
<S1> well the HIBI interconnection it would sort of it's shown in the same place would be shown in the same place in this figure we didn't use any standard interface at the moment or or in this work that is presented here we are implementing OCP at the moment but the idea behind this er our presented implementation is that we try to give er extremely as as simple interface as possible that's a that can be used in the same way as this virtual component interface here and can be quite easily fitted to other schemes also </S1>
<S3> on concerning the the number of published er buses are they really important for system on-chip . you you mentioned some ten or twelve er <S1> [yeah] </S1> [different] schemes yeah </S3>
<S1> well this was just to show <S3> [mhm] </S3> [that] what kind of features they usually have these publish- published schemes logic bus schemes </S1>
<S3> how do you compare these different er schemes with one another </S3>
<S1> er it's extremely difficult i think that er that's er one reason why these tables are here because <COUGH> with these tables with these tables you can compare theirs their features and [(basic)] </S1>
<S3> [yeah for example] if you look to table four two <S1> yes </S1> and you explain the difference between the two variants of the AMBA bus scheme </S3>
<S1> er the AMBA er this older er what is it called this H- advanced high performance bus is the sort of an old , bus standard that is used quite much in the in implemented devices it's er quite er actually classical centralised bus system and then the new AXI advanced extensible interface standard is a sort of builds upon that adds some new features to it </S1>
<S2> (xx) some of that or </S2>
<S1> they claim in the specification that they are sort of er backward compatible to the </S1>
<S2> (quite a lot of) people have said that it's only (a new) bus </S2>
<S1> but the new new bus from the same (provider) </S1>
<S2> yeah er d- do you somehow (now) summarise these tables or or i mean these three tables so why can't i find this kind of (xx) the sum- summary your view of this , i mean (xx) (contents of the information what you have so the bus) (xx) </S2>
<S1> well if you look at the most widely used buses in here they more or less they support the same features i have to say so (xx) </S1>
<S2> er did you find out any any transfer differences in the frequencies or or are they all the same or [or just] </S2>
<S1> [no no] there are differences there are some radical er designs like the marble bus that was discussed earlier er and some other also but the and when there are small differences between er between er more widely used buses </S1>
<S2> okay so . for example here in table 4.1 you have this ST bus that doesn't support (xx) (from clock domain) so why (you've done it why you have) (xx) </S2>
<S1> well first of all to find out whether the bus (xx) feature or not is quite difficult because nobody says in their specification that we don't support this but this er ST bus it's a more of a research project by (xx) and other but they implemented the system er , that had er four units in it and a quite large (xx) and it was sort of a number cruncher implementation </S1>
<S2> so so it was originally (xx) or implementation (we're going to have) (xx) support <S1> yes </S1> okay , so then on the next table i think you are listing all the H-I-B-I bus (xx) so (for) someone taking the first first is that er (each bus) supports handshaking so the HIBI is the only one that doesn't support <S1> yes </S1> so is it (xx) that HIBI is (xx) and others are (xx) or </S2>
<S1> well it's an approach that was taken in this personal HIBI to we try to make the communication as simple as possible so we tried whether it can be done without handshaking at all </S1>
<S2> so so actually (wasn't then) (xx) this starting (criteria) (xx) you thought okay it's it's good that we don't have handshaking so let's let's see if we can (xx) (bus) without handshaking </S2>
<S1> yes that's one of the starting points </S1>
<S2> okay and then i think there are actually quite usually usually used is this broadcast supporting but er (the er) can you comment the relevance of that (or) some based on your (video encoding case) or things like that </S2>
<S1> the applicability of broadcast [components] </S1>
<S2> [yes] , i mean how can you use it </S2>
<S1> well in in our case is <S2> [yeah] </S2> [(xx)] but er o- only for reconfiguration and and we need to broadcast some some reconfiguration formats to all the components </S1>
<S2> i i think that er so basically you're saying this format is not used basically at all and all you (xx) (what's the important) (xx) (discuss the hardware) so this is just er i mean i- it's really difficult to do this comparison and see what are the relevant parameters things like that but this broadcast is for example one parameter that i don't see that relevant </S2>
<S1> [(xx)] </S1>
<S2> [since] i haven't seen many people using it so </S2>
<S1> yeah yeah like data (flow time application) like the video encoding (xx) </S1>
<S2> okay </S2>
<S3> should (we do the next part) </S3>
<S2> yeah yeah </S2>
<S3> er concerning five er we have this section five one circuit-switched architectures and er in this second last block starting with <READING ALOUD> as was tabulated in table 3.3 </READING ALOUD> you say <READING ALOUD> on the other hand a single bus only allows one parallel transaction at a time regardless of the number of connected nodes </READING ALOUD> and then you say in brackets N was it not a little bit er lazy formulation as if you have to give some er complexity formulation of order of N with all these N and N square over two so this er should be exactly formulated as order of N <S1> no </S1> no yeah [(xx)] </S3>
<S1> [it's er] . it doesn't try to be (xx) (figure) any (xx) </S1>
<S3> and what does that N mean then </S3>
<S1> it's </S1>
<S3> or the [(xx)] </S3>
<S1> [it's the number number] of connected nodes </S1>
<S3> mhm </S3>
<S1> number of connected nodes how many components are or nodes are connected to a system </S1>
<S3> mhm , mhm and can you explain formula five point er two </S3>
<S1> it's just the com- if you forget all the er I-P blocks or whatever are connected by this interconnection then the frequency of the interconnection is dictated by the fre- frequency that the multiplexer can support the frequency that the wrapper components can support or the frequency that the arbiter unit can support and in this case the arbiter was so complex that the er let let it consume so many clock cycles that er it didn't er limit the maximum [frequency] </S1>
<S3> [and are] you using a full clock cycle or a half a clock cycle </S3>
<S1> er for arbitration as many clock cycles as is needed </S1>
<S3> mhm but this formula relates to a full clock cycle or half a clock cycle </S3>
<S1> full </S1>
<S3> full clock cycle mhm <S1> yes </S1> <P:17> <WHISPERING> (do you have any question)(xx) </WHISPERING> </S3>
<S2> i have on six </S2>
<S3> yes okay </S3>
<S2> so , er (that's it) (say) he- here have er in figure 5.8 so you have a the areas of implemented buses (and then crossbars) have you listed (xx) (any of these buses) or something like that </S2>
<S1> so only the (progress) and the arbiters and the er small amount of for example (xx) or (xx) (should) be in the (distributed bus) </S1>
<S2> so so is this figure important </S2>
<S1> it's er there's the logic complexity of the of the (xx) system </S1>
<S2> so it's mo- more for the (xx) logic complexity still on the final gate </S2>
<S1> y- yes it's er the the higher the logic complexity the more the final gate count gate count will be </S1>
<S2> yeah okay i i was just thinking o- on (total total) (xx) in (interconnect) area we have the (highest parameters and these are) (xx) on page ten [(xx)] </S2>
<S1> [and the] buffers and whatever are er (linked) to a system are on top of this but (they should) be (that we go through all this this) and </S1>
<S2> but okay so (xx) (logic complexity) (xx) in this this figure makes sense . okay </S2>
<S3> <WHISPERING> i have some questions on six </WHISPERING> </S3>
<S2> yeah i (think) i think it's it's good time to jump on the so so on the HIBI HIBI pathway </S2>
<S3> yeah . erm let's go to this chapter six design of HIBI , and er we discuss it for a little bit but it's common knowledge that a chip by synchronous designs might become infeasible in the future especially for S-O-Cs based on er reused I-P cores nevertheless your HIBI design relies on synchronous transfers and do you see limitations for the applications of HIBI in large designs and why have you not <SIC> choosen </SIC> asynchronous communication </S3>
<S1> er actually . we er only want to use er we only want to use as large bus segments that can be done using synchronous designs and then when the er area becomes or the systems become so big that we cannot do it anymore we can use bridges to break it into different parts , so totally asynchronous design style was not considered </S1>
<S2> so just the single chart on page 102 you compare HIBI to (risk) (xx) (centre) so (what) do you (try to argue with that) </S2>
<S1> er it's . it means just that the HIBI design is we try to keep the interconnection itself and the protocols and the way in which data is transferred in HIBI as simple as possible and then the more complex operations are (really the what give) them using these extreme simple operations </S1>
<S2> okay so so you try to decrease the number of (xx) in your (xx) or </S2>
<S1> yes and er the signal lines and the and the phases in protocols </S1>
<S2> (i mean) that's why i'm i'm just going through basics so so is the removal of handshaking one one part of this or </S2>
<S1> yes it's one part </S1>
<S2> if you summarise (the the standards) what were the starting point what were the the (boundaries) that you (talked in the beginning) when you started to design this so (what were the main) (xx) (wanted to show) </S2>
<S1> well the simplicity is one of course and then modularity we wanted to design a wrapper that that can be used what else er reconfigurability of course , and maybe it's something else (yeah) , probably yes but i just they don't go come to my mind right now </S1>
<S2> okay then it looks that this this (xx) has been really really one of the drivers of this bus <S1> yes </S1> okay </S2>
<S3> so we we discussed about er y- you have given the layers of your HIBI scheme and you show how the erm block (diagram) ex- example of a HIBI based system is looking and when you now go to such an implementation we discussed about the differences between validation and verification and we also talked about the golden reference model er which is needed in order to verify the design after refinement and transformation er the question here is can this golden reference be described at any abstraction level f- for instance system er level or RTL or gate level and what are the implications the advantages of having RTL code as a golden reference </S3>
<S1> well RTL code is is already quite close to the implementation so you can it a- already gives the things like er clock in a clock cycle manner so , of course the gol- it's in a practical sense it seems quite difficult to think of a golden reference that is not (xx) (that) doesn't give clock cycles at this at the way we are i'm i'm looking at this system but er one thing is that the systems become so complex that if (we impl-) er model its its component that in a very low level (the send-ender) verification times become extremely low so we would might want to use some high level modules for some blocks am- and make them look like the implemen- er or through the same (task) </S1>
<S3> and er concerning the design flow for getting such a HIBI based system if the designer wants to build er a HIBI based system what are the steps he has to follow and what er tool support he can expect </S3>
<S1> well actually the flow i can talk about what what at this point as we are (now) as is described in this book but er actually the flow development is something that is going on at the moment but er basically what you could do we have implemented some like processor units or hardware units and see er if you can make your system based on these three design units and if you can't then you must design your own application specific hardware units or processors adapters and then of the models that we have developed we have er models in in different abstraction levels so you can you can model and simulate your er system in in high level simulations and then in hardware software co-simulations </S1>
<S3> concerning the performance of er the HIBI approach er you have the first test case in section 8- 2.1 and you describe a two-step approach and you state <READING ALOUD> after the original test run the bus parameters were reconfigured to fit the utilised data </READING ALOUD> and the question here is was reconfiguration performed at design time or at runtime </S3>
<S1> er , the parameters were decid- decided at bit prior to the runtime but the reconfiguration itself was done runtime <S3> at runtime yes </S3> mhm </S1>
<S2> so i'm still on page one 101 so [so] </S2>
<S3> [perhaps] i can just (ask) a small question </S3>
<S2> okay </S2>
<S3> so er since you performed this reconfiguration with just the bus parameters to the transmitted data er what would be the effect if the data transfer (occurrence) of the application changed slightly at the (later time) when the system is running what do you do then </S3>
<S1> well the effect would be that the result would be would be worse <S3> [mhm] </S3> [so] if you really want to optimise then you have to monitor all the time because only the bus has (free) activity and that requires some sort of a system monitor or control (activity) </S1>
<S3> mhm and for the selection of optimal communication architecture you have to know the communication profile of the application and how can you determine and formulise these communication profiles , that is part of your design methodology </S3>
<S1> only only through simulations and experiments you can see by simulating the system you can see when when the components (want) to transmit data </S1>
<S3> mhm </S3>
<S2> and er i i think the just (following in this stream) so so so you say in your book that you (predict) the (xx) and actually i think that has been one of the starting points at least (xx) application (in the end) </S2>
<S1> it proved to be quite difficult , the accurate (xx) </S1>
<S2> (xx) monitoring (and so-called) high tech systems (for example) </S2>
<S1> yes (and er) we we ast- actually we are talking about the development of this scheme we are looking at into different applications that might have this behaviour in the (more) (xx) than the video encoding </S1>
<S2> so may let's just er (go) back to little bit basics so so if you could first define the word latency i mean we discussed it a little bit earlier already but could you define that in this context now again </S2>
<S1> it's sort of the in this context it's the actually the practically the clock cycles that are consumed when you start a a transfer process the clock cycles that it takes until the data is actually received at the other end </S1>
<S2> so do you (need to) define the latency that is (kind of) the latency that the data is is is (regenerated) are you (xx) is that the latency (as) you say or </S2>
<S1> er it er </S1>
<S2> i mean not if i understood correctly (your answer to my) question you said that okay so so (xx) (or) some data and then it goes back then you say okay it looks that (xx) so this must be (it) </S2>
<S1> no actually i i'm only thinking about one way (that) so in in HIBI the for example the if you if you ask data it says bit transaction so only one , the the (then) clock cycles it takes from the receiver and to send and the receiver sends the data and in the other end receives it [er] </S1>
<S2> [is the] is that a good good (value) i mean back on this (xx) (map i don't know what) (xx) for me i asked so so for me me the important information and i (get back with) (xx) (happy or unhappy is very hard) </S2>
<S1> the if i if we consider also the return of the data then it also concerns other matters than the bus i think but if you don't take into account that there might be some delay in the receiver also then it's more or less the same thing which just then the reading process is just two writing processes and the same latencies are in all of them </S1>
<S2> yeah but (i'm thinking) in this in (important) (xx) after the figure you say that <READING ALOUD>  smallest possible transaction latencies </READING ALOUD> (and and as) we understand it now you define latency as a (latency) to send data from one point to another , so i i think most cases i think the er well that's that's latency but but when thinking on one people what you want as simply both of you (xx) basically don't care about the e- e- (can can can) (xx) (or of the data clock cycle or) (xx) that's kind of latency in that sense <S1> yes </S1> and now i i think that it's not completely the same with us saying that the smallest possible transaction latencies in both cases but er it depends on the definition so i- if you really (think in) take care about or if you define the latencies are (interrelated) or to (xx) that (xx) then it's a little bit different , i i think you combine your your HIBI bus to some (xx) bus and and you take the latency how many (xx) is (CPU weight) and you get the result so i don't know if if (your sort of) if the HIBI is (basic- sort of basically a word) in that sense or do you agree </S2>
<S1> (no) er well i don't , know i- if what kind of phenomena are you taking into account are you considering the HIBI for example HIBI arbitration and the [the] </S1>
<S2> [(no)] no i mean just the basic basic issues so so you have some (xx) software and you'd like to read a constant from memory for example so how many cycles it takes i i mean it can be (xx) defined (xx) could be said for example here you mention that (xx) so how many cycles it takes er i think it it's it's very (xx) CPU (xx) that's kind of basically how how CPUs are operating <S1> yes </S1> so if you consider thi- that latency it's er it's not same same latency like like you are considering you are you are just considering the latencies (xx) basically </S2>
<S1> yes that's correct yes but what this only tries to say is that er the transactions have as few phases as possible so there are no like y- no handshaking as was discussed </S1>
<S2> but i'm (really mean) that that i mean this wasn't (this this) was taken into use but this is only one part of the problem i think you are you are now facing the problem that you said (starts only in) (xx) and that's not it but then then the other part is that that you need to be able to respond fast so things like that er two problems and and you don't clearly clearly concentrating to (maybe) solve one problem (i have then) (xx) methods methods to battle that one </S2>
<S1> yes and actually this one one thing more is that the HIBI is not actually meant to be used as a processor local bus (where typically you) read stuff from the memory it's meant to be used in a in a continuous media or a multimedia type applications where you send data from one place to another </S1>
<S2> so you are you are basically targeting applications that doesn't need any feedback they (will) just throw something out and then they'd be happy </S2>
<S1> they they might require some feedback but the HIBI (as i said) is not not at at its best in er in er as a memory bus for example </S1>
<S2> but i i mean it would be would have been better to kind of define this latency term for somebody who (xx) has used the (main) latency for (many) different meanings and i i agree that the same problem with (xx) applications everybody seems to have his his own own his or her own definition for the word (what what makes) yeah </S2>
<S3> erm when you look to the two figures six one the layers of the HIBI scheme and figure six two an example of a HIBI based system er when you look to figure six two what is the task the functionality of the adapter you depict in figure six two and where we have to position it in figure six one </S3>
<P:04>
<S1> actually it be- becomes er part of the bus transfer layer it's used because no designer of micro controllers at the moment is supporting HIBI so </S1>
<S3> i didn't understand that </S3>
<S1> so no no designer of micro processors is supporting HIBI at the moment so we have to put er adapter in between the processor interface and the HIBI wrapper so that so that converts signals from the processor to the HIBI wrapper </S1>
<S3> mhm but it was finally (effort) </S3>
<S1> yes we have done it for a few few examples er ARM processor and texas (BSP) so the idea is that only you do it once for for each (process) case </S1>
<S3> and you start in er er er you state in er six one here in your thesis at <READING ALOUD> the start and the end of transactions are signal- are signalled by a single bus reservation signal this fits well into the dataflow type applications in which the data transactions and the sizes of the required buffers can you determine in advance with statically analysing er the application </READING ALOUD> and to somehow related questions er to the er what about non dataflow applications </S3>
<S1> well it's more difficult in the , the the statically analysed then it becomes more difficult case </S1>
<S3> but it means that er the application domain is (xx) narrow <S1> yes </S1> when you have only er dataflow applications </S3>
<S1> yes er if if the if the application demands something else then then there are other ways of doing it in HIBI than when we can implement handshaking with high-level commands <S3> mhm </S3> but then we lose the sort of the precision of the (xx) </S1>
<S3> and the second question is static analysis in advance (feasible) and er sufficient </S3>
<S1> it's er , if we if we would have er sort of system or sort of application that we targeted at the beginning then it it should be quite easy but the even the applications that we thought of would fit very well into the scheme proved to have some (undete- dete-) (xx) in them so they proved it proved to be quite difficult </S1>
<S3> and er another topic in this er paragraph concerns er your statements on the utilisation of message passing you say that er <READING ALOUD> the uti- utilisation of message passing to implement handshaking is an application-level decision that is left to the designer </READING ALOUD> and er in general terms me- message passing er (xx) these types any (xx) based on the exchange of messages and er handshaking is something on a lower level so er the question here is can you explain a little bit about message passing and if it er really er does solve all handshaking problems efficiently </S3>
<S1> er er in HIBI the message message passing is meant to be used only in in extreme cases and it's not an efficient way to implement handshaking that's true <S3> mhm </S3> if the some appli- in some applications you for example want to check that the receiver is ready so you use use messages to do it </S1>
<S3> mhm </S3>
<S2> so so if we go to point (now) 6.2 so do you think this realistic i mean we know (quite a lot always) (xx) (i mean) (xx) here you say that this is good for lottery bus but then you don't have any (memory on) (xx) (or at least) sorting memory (xx) </S2>
<S1> er the implementation of for example the micro micro processor is shown in figure 8.5 (xx) (136) , so it's HIBI is not meant to be used as a processor local bus in that sense it's sort of (memory) bus [and so] </S1>
<S2> [(if so so)] this kind of er theoretical figure that you <S1> [no no] </S1> [(use)] it would be or </S2>
<S1> we have (done it done) systems like this in this case the memory is er data storage memory and the adapter adapter makes it possible to transfer da- er data in a in a one block so if somebody wants a block of data they (pa-) just send one message to the memory adapter and the me- memory adapter sends the whole block back </S1>
<S2> yeah but does this (differ) a little bit from from (xx) i mean they are i usually think that these (people) (xx) (rough to do that) (xx) and now now this this (would be you are) just looking for (this) (xx) (it looks like) there is just one (xx) is that (xx) of this is located </S2>
<S1> maybe maybe it's too unclear this figure tries to be (xx) </S1>
<S3> i have one question concerning this figure six two er in your thesis you are using simultaneously the term HIBI interconnect network and HIBI bus er are they <SIC> meaned </SIC> to be synonymous and is it a (good known platform) </S3>
<S1> well i i i hope that i have used it [so] </S1>
<S3> [especially] this HIBI interconnection network you're saying [figure six two] </S3>
<S1> [it it's a] more abstract so HIBI bus it's a usually a single bus connect used to connect components and HIBI interconnection network is might be something else than a single bus for example a hierarchy of buses or it might the newer versions might even [(xx)] </S1>
<S3> [but what] HIBI itself was always introduced as a form of a synchronous bus </S3>
<S1> yes [(but)] </S1>
<S3> [so er] </S3>
<S1> yes and this version is but it can also be used as a hierarchical bus with more [(xx)] </S1>
<S3> [and then] it would fill the requirements for an interconnection network </S3>
<S1> in my mind yes </S1>
<S3> but in general HIBI is a a bus (key) <S1> yes </S1> , you you state in your thesis that <READING ALOUD> the designer can freely choose the length of the streaming burst during the system design time er it is given as a generic parameter to the system synthesis process after which it becomes a fixed value for the whole system  </READING ALOUD> this is cited out of your work on on my page one 106 mhm and er why has this decision to be made at design time and and what are the advantages and limitations of er this approach </S3>
<S1> er the sort of possible ways to do to do this is to only implement one burst length or implement several burst lengths we decided in this version to only implement one burst length that is applicable to all and one one er way in which this is helpful or makes the design more simple is that er we can calculate whether we have enough time to transfer a burst </S1>
<S3> so you can handle the case er er that er some longer steam stream burst has to be sent you can handle that </S3>
<S1> yes and and we see that for example a time slot for other component is coming and we can [transfer] </S1>
<S3> [but does] it not mean that it would be poss- that it would be possible to include er this parameter in the set of runtime reconfigurable parameters </S3>
<S1> yes it it would could be yes </S1>
<S3> mhm </S3>
<S2> so what this burst (xx) so what's the effect in creating in performance-wise so so it it looks looks like they they are effective to be used but and of course it's how how much (xx) you get (when you use it) </S2>
<S1> using burst </S1>
<S2> (xx) of this (xx) </S2>
<S1> well , in theory you you're talking about the HIBI stream (burst) operations theoretically it makes it possible to double the transmission speed </S1>
<S2> but in in in in practice what's the i i mean measured bus bus the i mean theory theory can satisfy but then in in practical solutions so </S2>
<S1> practical solutions might have er problems for example if you have a 32-bit microprocessor it can accept two variable big values at the same time so in in practice the the only way to get any any like help from this is to buffer the data before the before the [(burst starts to)] </S1>
<S2> [(xx)] if if if (xx) (reduce two points) in practical values so timing gives ten per cent more than in average case or 50 per cent or five per cent or </S2>
<S1> er i think in the test case that was in here it was something like ten per cent , 20 per cent </S1>
<S2> 20 per cent </S2>
<S1> yes </S1>
<S2> [so that's] </S2>
<S1> [er i'm] sorry 17 per cent </S1>
<S2> okay so do you mean that 17 per cent er of these components are (burst components) or or (xx) </S2>
<S1> in in that case 20 per cent (xx) (burst) components and then it (these are) 17 per cent </S1>
<S2> okay <S1> okay </S1> okay i'm er do you have some limitations on using these components or </S2>
<S1> some limitations </S1>
<S2> i i er there has to be (a number of) (xx) limitations of using this this stream performance </S2>
<S1> er . for example the data because it uses both the data (and these) buses then it might be so that for example the last slot is not used </S1>
<S2> (xx) yeah or i mean or this arbitration (stuff) and this and that so does that (mean) any limitations </S2>
<S1> @@ yes in in in this implementation the first commands are only used in time slots purely time slots </S1>
<S2> so so if it it means that that first of all you need to have this (implementation) arbitration <S1> yes </S1> and and secondly you you need to have a long block of data and then you can (implement it) <S1> yes </S1> and and you measure the receiving is it any different from this case or </S2>
<S1> in in a case that can use the in which the 20 per cent of the transmissions are </S1>
<S2> okay so so in case where it is like that but what about you used it so do you mix that 20 per cent with stream performance or </S2>
<S1> in the in the used i- in with the video encoder that is presented here it (that) didn't use TDMA at all </S1>
<S2> so basically it it used this (xx) then </S2>
<S1> in that video encoder only </S1>
<S2> yeah so so actually er you made it up for the situation that i- it (keeps) double bandwidth and and that's kind of (lame in the) (xx) so so still still we find out that even in (your use) case it (didn't) bring benefit from that at all basically so that was the end result </S2>
<S1> the yes (that's because) the in the video encoder case the bus was 32-bit bus and the processors were 32-bit processors and the penalty for using the (sec-) sort of different HIBI arbitration method the priority (randomly based) method it proved to be quite good </S1>
<S2> okay so that's fine but er what i was thinking really in in the (xx) is nice and and this is a suitable (use) case suitable solution that it gives the bandwidth but but but the it's not proven that it it works like that in every (use) case that we have so okay </S2>
<S3> and would it be possible for you er to give a description or draw picture of the design process we have to follow for your design (with a few little) steps and what steps are mandatory and er which steps are optional is something like that possible before we go to the final chapter seven with the implementation </S3>
<S1> well the HIBI scheme is is (xx) and how it's how it's presented here doesn't er take (or force) any sort of design flow (and) in the system (xx) in itself , but er what we are are implementing is a sort of platform based design or maybe first er implem- optimise the bus usage using whatever models of the (con- the) clocks that we are trying to interconnect . and then the sort of system design process is (xx) (on top of that) </S1>
<S2> er no it's just one one (is important question) </S2>
<S3> <WHISPERING> (xx) </WHISPERING> </S3>
<S2> okay so i have just a few questions from this (xx) (60) , so first this (xx) (information in general) are you do you (really discuss) are you (wrapping) (xx) (interested) (xx) (or something like that) so is (xx) (technique) in system on-chip and is that (xx) i mean here is maybe one (impact in) the last sentence so do you use this three state logic in your implementation i mean (that's one half) the differences or what do you mean </S2>
<S1> yes er the choice for three state logic was made quite early on and it for example in the emulation process that was conducted i- it proved it was (already itself) very a very good approach and i'd like to say that in the versions that we are (going to be) now they don't have three three state logic in them </S1>
<S2> (er that's kind of er) is kind of (xx) this kind of components or system on-chip or i think this may be one of these different differences that we see so they may be partly depending on the on (how they are integrating or not) <S1> yes </S1> . then i think (xx) for a little bit for this er general (xx) (that) we discussed the (loop) theory already but but this er system you say (xx) that you don't have this handshaking (xx) things like that and then your solution is that there are these FIFOs and er now i think the main question is wh- what are the main (options to) make sure that the receiver can can really receive them in the (hardware state) so so do you know </S2>
<DISC CHANGE>
<S1> few occasions and find out when the or the system works properly what kind of FIFOs it requires , i would say and then if the it s- it seems that the system requires so large FIFO buffers that they are not meaningful to implement then i wo- will recom- recommend using the message passing scheme </S1>
<S2> i i think in general this is kind of the argument is okay but i think in general it's it's pretty difficult to simulate in simple system you can do that but when your system is starting to be more complex than (that) especially you don't know exactly what's going to happen there let's say that you have some older system and (maybe) (xx) can maybe all do something something for your (case) or something like that (i mean instead of) er if you can do it it's good but it's really challenging </S2>
<S1> yes if you can't do it then you need to utilise the message passing and in the simplest form you just (make) make sure that the recipi- the receiver of data is ready to receive </S1>
<S2> yeah yeah i i mean this is this is (xx) but then then we are (xx) we discussed early that (xx) (importance of) these packets packets (stuff mainly) so you have to make sure that we have enough room for certain packets or certain number of (xx) (data) and then then we can (xx) (process) itself (xx) </S2>
<S1> yes </S1>
<S3> er concerning this final chapter implementation and verification of HIBI er you present here the layout design for er the case of a specific HIBI with 16-bit buswidths and FIFO (widths of five) er was there a specific reason or motivation for doing that selection of HIBI er for the (old) generation and might this instance be er particularly very suited for application and if so why </S3>
<S1> actually i can't remember why this particular implementation was chosen it was not meant at that moment to to or target it to any any like application <S3> mhm  </S3> er it it was only so that we could run it run er HIBI block to the place and route flow and then check that there <S3> [mhm mhm] </S3> [is a (xx) were] (connected) </S1>
<S3> mhm you you are stating furthermore that the size of the FIFO buffers is relative la- relatively large er and from that fact you might think perhaps er if there are other more area friendly possibilities for implementing the buffer and functionality </S3>
<S1> actually- </S1>
<S3> or something that you use simply some centralised buffer and you have some memory instead of the distributed FI- FIFOs </S3>
<S1> yes it it might be in some cases <S3> [mhm] </S3> [but] when we used like in this case we have only five five buffer <S3> [mhm] </S3> [stages] it's it's still quite small to implement (different memory) but if if you have a memory somewhere it (xx) use it </S1>
<S3> and for typical application what utilisation of the FIFOs do you expect </S3>
<S1> well , to to minimise the size of the FIFOs we would want the utilisation to be as high as possible so very very close to <S3> mhm </S3> (100 per cent) </S1>
<S3> you present you're presenting here the layout of the HIBI wrapper and in table seven two er you use the data of the layout implementation and er regarding the numbers you give in this section seven one for the area of the layout er the how do you explain the 68 per cent difference between the synthesis estimate and the final layout area </S3>
<S1> (and er) it's caused by the brought by the place and route to that the synthesis process program only uses when it co- com- calculates the area calculates the cell area and only estimates (at it) at best the wire area and the place and route process it places the cells and it can can't really place them as close to ea- each other as it would want because it leaves er space for routing so the the u- usage of space on a routing chip is not a 100 per cent </S1>
<S3> and if you do this 16-bit HIBI wrapper would there not be a simple solution with some (field) (problem) (xx) structure that is for demonstration purposes </S3>
<S1> do you mean </S1>
<S3> yeah that you need not go to such a standard set implementation </S3>
<S1> it it would be <S3> mhm </S3> (epigenous) </S1>
<S3> you have section 7.2.1 simulation and emulation of the HIBI wrapper , er you describe there the gate-level simulation of your design have you found any bugs with it </S3>
<S1> you mean in the start (xx) </S1>
<S3> yeah , so er on the other side we might question if the simulation process is necessary at all because er you're also using synthesis methods and er they should be correct by guarantee </S3>
<S1> yes but </S1>
<S3> so can you explain the nature of the er errors (were they) found where you were intending to find with this simulation </S3>
<S1> the errors that were in the synthesis results were caused (xx) by by er <SIC> unexperienced </SIC> designer doing the doing the coding </S1>
<S3> mhm </S3>
<S2> okay can you comment about (the number of the) (xx) application (for the) first time </S2>
<S1> well when the as you might predict they were mainly with the three-state logic parts there were some (xx) VHDL there were some some incomplete structures in the codes </S1>
<S2> so that's the (implemented) logic (parts that you) were (implementing) VHDL simulation in in (xx) </S2>
<S1> yes </S1>
<S3> er in your thesis you give results you give synthesis results for (process) 16.5 and 8.5 HIBI while the FIFOs in the 16.5 HIBI are twice as wide as those in the 8.5 HIBI the difference in the needed standard cells is rather small in the first case it's 2052 er the other's er 1951 so plus 500 cells how do you explain this and how does er this cause (come to) your statement that the majority of the wrapper area is due to the FIFOs </S3>
<S1> er these two figures wouldn't be compared because they're totally different technologies <S3> [okay] </S3> [so] if you really want to compare [these differences] </S1>
<S3> [for the reason] is that er that was also what was i was arguing that you have completely different [technologies] </S3>
<S1> [yes from different] (xx) </S1>
<S3> okay mhm </S3>
<S1> if you'd like to compare the different implementations then it's done in chapter eight </S1>
<S3> mhm <P:07> but it's not a contradiction to your statement er that the largest number of standard cells is not due to the FIFOs </S3>
<S1> no it's er i i if i remember correctly in this this er case where we where i give the layout what 60 per cent (was it) consumed by (xx) </S1>
<S3> perhaps i might have a final question </S3>
<S2> yeah i mean </S2>
<S3> this is a er your equation 7.1 and there you have er an error function of T er (big) bracket here this T synthesise T compile T verify and T debug <S1> yes </S1> and in the context of er it's it's not clear what is the meaning of this error function (is) the context of the equation error (must return) time <S1> yes </S1> but you define as a number of encountered errors <S1> yes </S1> so er er i think you should write this equation a little bit different as T script plus T synthesis of error plus T compile of error T verify of error plus T debug of error <S1> mhm </S1> , this should be my </S3>
<S2> <WHISPERING> (xx) </WHISPERING> okay (then) next (xx) i think i'm (not) going to the figure 8.1 just so so so (xx) very small comment or (what you'd) (xx) </S2>
<S1> i- it's not </S1>
<S2> i mean in figure 8.1 you say 8.1 you you (give) the areas of these wrappers so i think they are not very small or </S2>
<S1> no not very small but compared about two other implementations </S1>
<S2> yeah </S2>
<P:09>
<S3> i have a final question otherwise yeah you have you stated that you were working five years on your PhD here in the institute are you aware of at least one other big research area or two or three other big research areas at tampere university which were going on at the same time , you understand that question <S1> yes </S1> okay </S3>
<S1> so you want me to name a few or </S1>
<S3> something what what happened in your university at that time might be in biology or philosophy or whatever </S3>
<S1> i er really i i most of the research i know is from our own laboratory <P:07> so most of the research i know that (well) is from our own laboratory so i can only cite some for example projects by <S3> [mhm mhm] </S3> [(xx)] like er (xx) plan designs they have done </S1>
<P:08>
<S3> okay this er finishes our (part) <P:31> so i can read the final assessment report er <READING ALOUD> to the information technology department of tampere university of technologies of technology as opponent in the public defence of <NAME S1>'s thesis design and analysis of er interconnection architectures for on-chip digital systems we give the following er statement the thesis considers interconnect implementation options in integrated circuits industry and university studies of different interconnect toplo- topologies are presented and er their properties are analysed implementation and detailed analysis of er (developed) interconnect is presented the thesis is a monograph consisting of nine chapters and references the text is mainly based on already published er articles the thesis is a good collection of the issues discussed in the publications but it gives also detailed analysis of the implementation the thesis describes the HIBI interconnect the original idea is presented already earlier as stated in the thesis but the implementation and detailed analysis are for the first time presented in <NAME S1>'s publications and the thesis the presented interconnect is new but it has been shown to fit only in a limited set of applications all the interconnect development targets have not been met but on the other hand the detailed analysis has led to the development of the next generation interconnect architecture which er illustrates importance of real hardware implementation and detailed analysis the organisation and clarity of the thesis is good the thesis is useful to other researchers working in the field by giving detailed analysis of the HIBI bus however the comparison and analysis to other interconnect implementation could have been better even though interconnect flexibility makes neutral comparison difficult the candidate defended his thesis well and showed maturity in his treatment of the work we recommend er the acceptance of the thesis as a doctorate dissertation of er <NAME S1> </READING ALOUD> </S3>
<S1> thank you very much <COUGH> <READING ALOUD> if anyone present still has some remarks to make or questions to ask concerning my dissertation i respectfully request that they ask the <FOREIGN> kustos </FOREIGN> for the floor </READING ALOUD> </S1>
