This forces you to create an interface abstractor and double-check the bus definitions used by both vendors. 2/
-
-
Replying to @oe1cxw @OlofKindgren
Sometimes they e.g. differ in default values for when a signal is not driven. Hard to troubleshoot and fix otherwise.. 3/3
1 reply 0 retweets 0 likes -
Replying to @oe1cxw
Well, that's a bug in the IP-XACT file then, and you will see it in the generated verilog
1 reply 0 retweets 0 likes -
Replying to @OlofKindgren
Usually you don't manually check generated verilog, not on that level. You'd see that the generated system doesn't work.
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
And how would you fix it: You can only use the vendor A definition and break the vendor B core or vice versa.
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
You'd have to manually change the cores of one vendor to use a different bus VNLV and create an interface abstractor to fix.
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
So why not have every vendor use their own VLNV in the first place...
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
Also: If both vendors use the same bus VLNV but provide their own XML, which XML do I use in the system?
2 replies 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
If e.g. ARM provides AXI definitions for IP-XACT then everyone should use that of course.
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @OlofKindgren
But until then I'm fine with vendor A having AXI bus definitions in the A namespace, and vendor B in the B namespace.
1 reply 0 retweets 0 likes
Writing an interface abstractor is trivial if the bus specs really are compatible.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.