1 of 1 people found this helpful
Nets are mapped by bus index so providing you name the bus DATA_A[3:0] and connect it to pin DATA[3:0] it will map correctly (and automatically), the same for DATA_B[3:0] connected to pin DATA[3:0] on the second instance of the block. Make sure you have 'Frozen' the block before creating the second instance (Right Mouse Button - Freeze on the block).
I understand that it works for indexed buses of the same size. Does it still work if I want to connect a bus DATA[7:0] to the two blocks by connecting DATA[7:4] to the first block and DATA[3:0] to the second? What if I want to mix the indexes and connect DATA7, DATA5, DATA3, DATA1 to the first block and the other nets to the second block?
If we could have a real mapping of the nets, we could connect buses that are not indexed. For instance, if I have two I2C buses that I want to group in one bus I2C_MAIN [I2C_SCL_A, I2C_SDA_A, I2C_SCL_B, I2C_SDA_B]. When connecting this bus to a I2C peripheral (a hierarchical block) which has a bus port named I2C, I would like to be able to select which bus it connects to in I2C_MAIN.
Is it a functionnality that is already implemented or do we need to develop a script ?
You can do this by taking the sub bus from the pin, name it with the sub nets and then connect this to the full bus. You will see a bus ripper at the join. You can modify the mapping if needed on the ripper.
Sent from Samsung mobile
I think we are getting close but there is still a little issue.
Let's say I have a hierarchical block with a I2C_BLOCK port. Inside this block, the port is connected to a bus named I2C_BLOCK containing nets I2C_BLOCK_SCL and I2C_BLOCK_SDA. If I connect a bus I2C_A to this block and if both buses I2C_BLOCK and I2C_A are defined in Settings->Bus Contents, then the nets are connected using the order of the content definiyion. This could lead to some issues if buses content are not defined in the same order as illustrated by the two examples below:
- First example:
Name Content I2C_BLOCK I2C_BLOCK_SCL,I2C_BLOCK_SDA I2C_A I2C__A_SCL,I2C_A_SDA
Buses are defined with nets in the same order. It seems to work fine as SCL nets are connected together and SDA nets too.
- Second example:
Name Content I2C_BLOCK I2C_BLOCK_SCL,I2C_BLOCK_SDA I2C_A I2C__A_SDA,I2C_A_SCL
This time, SCL and SDA nets are not in the same order and when I connect my I2C_A bus to the I2C_BLOCK port, I2C_BLOCK_SCL is connected to I2C_A_SDA and I2C_BLOCK_SDA is connected to I2C_A_SCL.
If I connect a bus that is not defined in my project like DATA[1:0], I would like to know which net is connected to my underlying SCL net and SDA net and if the mapping is not correct, I would like to change it.
Is there a way to verify the mapping between a bus outside a block and the bus inside the block? Actually, it would be great to have exactly the same interface as the one we have for sub buses when clicking on the bus ripper.
I hope I managed to describe correctly the situation.
In the case you describe the bit order is worked out from left to right (always) so if you connect DATA[1:0] to 12C_A in the second bus contents, DATA1=12C_A_SDA and DATA0=12C_A_SCL. The same order as described in the bus contents. A simple illustration would be:
Bus DATA_A[7:0] connected to pin DATA_B[0:7]. here you have effectively inverted the bus:
DATA_A7 - DATA_B0
DATA_A6 - DATA_B1
DATA_A5 - DATA-B2
The 'flat net' is the net at the highest level of the hierarchy. The Navigator will also show the mapping if you display the nets, see attached picture.
BusMap.PNG 53.1 KB
I think that with all these elements, we can use buses in hierarchical designs in an effective way. Maybe we'll write a script to create a report in order to verify that buses are correctly mapped just to be safe but at least, we understand how to work with buses.
Just to be sure, can we modify the mapping afterwards or is it exclusively from left to right ?
This works for bus rippers but there is no such dialog box for mapping buses through a hierarchical or a reuse block. We have to use the left-to-right mapping and this is why I was thinking of creating a script to verify this kind of mapping.
Doubling clicking the bus ripper does not open the mapping dialog box; is there a setting missing?
There isn't a setting to control this, can you provide a picture of how you have connected the buses? If it is a simple sub-bus then you shouldn't need to edit the mapping, by a simple sub-bus I mean something like:
Main bus = AA[15:0]
Sub bus = AA[7:0]
In which case the names provide the mapping:
Main bus AA7 connects to sub-bus AA7 etc.
As this is related to your earlier questions on hierarchy it might be an idea to contact your customer support representative to take you through the necessary steps rather than try and figure it out via communities.
Thanks for the advice Robert.
While I’ve successfully created sub-busses off mains I haven’t been able to fully propagate them across several blocks; the signals don’t match. I’ll seek help elsewhere rather than bother you with the details.
image001.jpg 332 bytes
What do you mean by the signals don't match? In a repeated block the nets will get resolved from the top down, so in the attached example there is a block called RepeatedBlock instantiated twice. The block has an 8-bit wide pin BB[7:0] which is connected to a 16-bit bus AA[15:0]. The first instance is connected to sub-bus AA[15:8] and the second to AA[7:0]. In the first instance AA15 connects to BB7, AA14 to BB6 etc. In the second instance AA7 is connected to BB7, AA6 to BB6 etc. So in layout you get two ICs connected to the 16 nets, one IC with AA15 to AA8 and the other with AA7 to AA0, even though inside the block schematic you see BB7 to BB0 in both instances. The NetMapping picture shows how this gets resolved in layout. Does this help describe how repeated hierarchy works?