Hi, Svenn. ----- Original Message ----- From: "Svenn Are Bjerkem" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 09, 2003 3:21 PM Subject: Re: gEDA-user: Support for busses
> On Saturday 08 November 2003 16:35, Bill Cox wrote: > > I want to implement the bus tap rules you suggest. I went to go write > > the code and realized I don't have quite enough information. In > > particular, busses can be multiple signals concatentated. For example, > > a legal bus name is "A1,A2,A3,A4", or "a[7:0],b[7:0]". If I simply put > > an attribute name on a bus tap like [4], then I assume that means the > > 5th signal in the bus. However, if the bus name is "a[63:32]", I would > > like to be able to tap signals with names like "[35]", rather than > > making them 0-based indexes. > > with [4], do you mean then that it is A4 above (in A1,A2,A3,A4) if it is one > based? I don't see how you want to make the user aware that a signal is 1 > based or 0 based. > > Remember there are logical and physical busses in many designs. Cadence do > make a difference between logical and physical busses. I havent quite grasped > the difference in Cadence as I consequently use the <> bus declaration. > > What I do recognize is a need to make simplified representation of complex > signal collections. An example may be on the very top level of a chip or a > module used in a chip, you want to have a human-readable bus name, say, > control[15:0] which go between the two blocks uRom and Accu and consist of > regtl<7:0>,regls<3:2,0>,regrt<9,7,5,3,1> which are the actual lines. (the > names are made up for example only) > > This way you don't need to change the top level bus if the local signal names > change due to reusability. (I could use a different uRom module for the same > Accumulator if the uRom happen to have other signal names) Care must be taken > on the left to right assignment on each of the end of the busses, but that is > also the reason why I use <> all the time in Cadence. (Also there are some > netlisting errors if I use []) > > > -- > Svenn Logical vs. physical busses is an interesting notion that I'm not familiar with. For example, a PCI bus could be very complicated, but at the top level, we could just call it PCI[145:0] (or whatever... I don't know the correct length). Individual signals would be assigned through the bus taps at lower levels. Is this right? It sounds like the bus tap itself might need to hold some range data. For example a bus tap named [31:16] could be a sub-bus tap from a larger bus. This would be useful for tapping out sub-busses from complex busses, such as PCI bus. If a bus tap had no range data on it, I could assume that the net or sub-bus name had to match the logical name on the bus, and figure out the connection that way. If the bus tap had a range, but the sub-bus had no name, I could inherit the logical name of the larger bus onto the smaller one. Does this sound right? I think the rapid adoption of Verilog and VHDL curtailed the advancement of schematic capture to this level for most systems. Basically, by the time busses were so complex that we didn't run feel like writing out the whole bus contents everywhere, it was time to switch to an HDL anyway. Once concerne I have with this scheme is that I don't know how to keep the physical names when I convert the schematics to a netlist, and then flatten it. I'd hate to see names like PCI[54] showing up instead of PCI_WRITEENABLE, or some such thing. I could add the concept of a logical net name to the netlist database. In that case, what should I do when flattening? For example, should I verify that all the physical net names in sub-netlists attached to a logical signal are the same, and then use that instead of the logical name? I can easily do all of this, but I want to make sure I'm doing the right thing first. Bill
