04-06-2021 01:59 PM
Who agrees with me that trying to make the block design editor show a decent diagram of a modest design is like repeatedly throwing spaghetti at the wall and hoping that something beautiful will result?
04-08-2021 03:22 AM - edited 04-08-2021 03:23 AM
Have you tried lasagna? It gives a much nicer result haha
You might want to describe what exactly is the root cause of your frustration. There might be some options you can use to help you.
For example, did you know you can pin the IPs to the BD so they do not move. Also you can hide some wires (for example the AXI4-lite) so it gives a cleaner output. Using hierarchies also help to clean the BD.
While I do not think the goal is to give a beautiful output, there might be some option you can use to help with that. But you need to describe what you do not like.
04-08-2021 03:33 AM
I don't make block diagrams for the sake of beauty. You can make hierarchy blocks and hide clocks and resets to help you focus on signals. Also highlighting nets in different colors helps working with them. And you can have different block diagrams connected. With time you will get used, just don't give up.
04-08-2021 07:44 AM - edited 04-08-2021 07:47 AM
Thanks Florentw and Joancab. I'm using many of these tricks. The main problem I have is that even with IP blocks pinned it makes a mess of wiring when I try to remove loops or move a block manually. It does not place blocks where I set them down or move them to - it has a mind of its own. It will often find the longest way around to make a connection. I cannot redraw a connection line to my own satisfaction. If I hit CTL-Z, it often does not allow reversion to what I had before. So once screwed up, it remains so. I would like more control since I know what I want to see. I see no reason for not letting me decide where lines route to. Those are 5 of the main problems I have with it.
04-08-2021 08:00 AM - edited 04-08-2021 12:58 PM
I look at IPI as a tool for avoiding very tedious structural coding in an HDL. And on that point, it is a wild, amazing, stupendous success.
I do make my diagrams a bit "better" based on criteria I value. I rename interfaces, wires, and hierarchical ports using a naming convention I've come up with (same convention I use in structural HDL--nothing special, just a convention I prefer). This allows me to spend less time cross referencing if I ever need to use VLA.
I also use hierarchy. The earlier in the project the better, because hierarchical names affect xparameters.h and also embedded Linux labels in the device tree. That is: changing a name in IPI will mean you will have to change names in .dtsi files, Linux applications, and bare metal applications, and other places that may depend on instance labels. On a team with software and firmware developers, constant tweaking of hierarchical labels will result in downstream work for them, possibly taking up your time to sort out the mess you created (assuming you keep tweaking instance and hierarchical labels). So work out your hierarchy as early as possible while you and your team are architecting the system. This will allow you to spend more time developing and less time playing tug-o-war over labels.
Lastly, have you tried "adjust pins to reduce jogs for connections" and "move pins to avoid loops for connections"?
But at some point you have to stop and think, what is the product here? A beautiful block diagram a manager will love (if so, get Visio or some other diagramming tool), or a powerful embedded system without the overhead of structural HDL.
Speaking of which, since, in my view, IPI is a shortcut to avoid structural HDL, you are as the designer are still responsible for spending some time organizing your design in IPI, just like you would have to do if you were doing structural HDL.
04-08-2021 08:10 AM
Kill the messenger, right. Did I hit a sore point. I see no reason why this editor cannot be improved in the manner I indicated. I was not aware of the adjust pins and move pins options, and right now I do not know where to look for them. They are not on the menus I have seen while editing. Please point me to where I can find them. So far I see the editor moving pins around for me to make connections easier as IT sees fit, but not optimal for my purposes.
04-08-2021 11:56 AM
>Kill the messenger, right. Did I hit a sore point.
>I see no reason why this editor cannot be improved in the manner I indicated.
How much extra would you pay for this? Because the people who do the improvement have families to feed. And they want to get paid. And Xilinx has to pay them. And it appears their staff is busy implementing new features that matter more in the estimation of their executives. But, if you and a lot of others would be willing to pay a lot more for Vivado to improve the diagram representation to publication quality diagrams, I bet the executives at Xilinx would make it so. In the meantime, I suspect they are interested in revenue generating features.
But ultimately, I agree with you. If we can trick Xilinx into giving us much better diagrams while not charging us for it, I am all in. I'm just not holding my breath that they are willing to do that, when there is so much other stuff they are trying to do.
> Please point me to where I can find them.
I'll pass, as I would hate to trigger you again.
04-08-2021 02:10 PM
> How much extra would you pay for this?
The view from the bottom of the food chain: There are large corporate customers who the Xilinx product managers listen to. Those customers and their managers listen to their designers. Their highly paid designers have almost literally grown up using tools with major foibles such as this one, and they are used to them. It becomes a bad habit kind of like driving a gas guzzler. Meanwhile the average small fry user is seldom heard except in under-monitored posts like these. Or upon hearing, they get this kind of pushback instead of support for positive change. I'm glad you agree. I'm sure their list of needed improvements is as long as a roll of TP, but user productivity should be at the head of the list. That's what a GUI is for. Thanks for your feedback. I hope you appreciate and forward mine to those executives.
04-16-2021 05:29 AM
@florentw one thing that is annoying - but related to the editor I think :
I mostly use tcl scripts to (re)create my bd's, however sometimes it's useful to see the diff between 2 versions of a project : diff in project settings, diff in BD (routing, ...), diff in IP settings
In that case I use write_bd_tcl on both bd's, and try to compare these files. But it looks like the place of things on the bd impacts a lot the output of write_bd_tcl. If you move things around on the bd, the write_bd_tcl starts to move lines around too ... I think at least.
Sometimes it becomes extremely difficult to do a diff with a regular diff tool.
I've been thinking of writing a more advanced diff tool myself, but didn't find the time yet (one that for example removes common lines, wherever they are in the file), and so on. But maybe there are improvements possible from Xilinx side too?
04-16-2021 05:31 AM
great tips @maps-mpls , thanks, haven't used hierarchy so far, but it's on my table now, good that I read there is an (rather annoying) impact on the software side ... so the moment you think 'now it's a good time to cleanup my bd' after initial prototyping, the software guys will kill you
Is there no way to circumvent this in a way? Guess not ... but ... wouldn't that be an improvement that Xilinx could make, or is that rather impossible or a stupid question? @florentw
04-19-2021 01:54 AM
I think @maps-mpls did understand well the context. To get an improvement on the tool there needs to be value for many customers or for few customers if this has a big impact on productivity. Because you need to justify that this worth more engineering time than looking at new features which might have impact on the productivity of many customers.
Here I cannot justify the big impact on the productivity or the impact on the customers as I do not think many use the flow you are using. So asking for enhancement here with the data I have is like throwing a little stone in a lake and expects it to do big waves. All it will do is a little flop.
I understand this is not the way you would like the tool to work but you can probably find workarounds, there is no really blocking point for you to have your design on the device.