Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Sunday, February 7, 2016 at 3:15:25 PM UTC+3, Brian Drummond wrote: > On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote: > > > I'm looking for a peace of advice. > > Currently I use git for version control in my VHDL projects and I > > usually include all .vhd files as well as .xdc constrains files in it. > > But I don't know what I should do with ip cores. Including the whole > > directory of ip core to repository doesn't seem to be a good idea > > because there are to many files and too many of them are changed after > > any change of ip settings. Other choice, manual description of ip > > settings in comments is tedious and error prone. > > I hear you loud and clear. FPGA tool vendors are a couple of decades > behind in their understanding of development practices, and often don't > seem to consider version control at all. > > It takes some digging and experimentation to work out which > configuration files you need to regenerate the IP cores from, and how to > regenerate them with minimal GUI interaction. > > Maybe worth digging around in the "command log" files to see which > command line tools are run when you press "Generate", and which files > they take as inputs. That command line can then be extracted for > scripting the process. > > Specific details will depend on the tools of course. > > -- Brian Ok. That is the approach I'm going to try. It has one disadvantage - configuration files are not really human-readable (xilinx .xci), but it looks like the best way by now. Thank you for response.Article: 158626
In article <n97cbb$re0$2@dont-email.me>, Brian Drummond <brian@shapes.demon.co.uk> wrote: >On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote: > >> I'm looking for a peace of advice. >> Currently I use git for version control in my VHDL projects and I >> usually include all .vhd files as well as .xdc constrains files in it. >> But I don't know what I should do with ip cores. Including the whole >> directory of ip core to repository doesn't seem to be a good idea >> because there are to many files and too many of them are changed after >> any change of ip settings. Other choice, manual description of ip >> settings in comments is tedious and error prone. > >I hear you loud and clear. FPGA tool vendors are a couple of decades >behind in their understanding of development practices, and often don't >seem to consider version control at all. Preach it Brian. Version control (at least for vendor X) is a late addition, very poorly bolted on. The design flows were created with an image of a single user owning and maintaining a single FPGA by themselves. Very 90's. > >It takes some digging and experimentation to work out which >configuration files you need to regenerate the IP cores from, and how to >regenerate them with minimal GUI interaction. > This. We'll often check in a zip'ed archive of the dummy run we used to create the IP - along with ALL it's junk. Just for information purposes. As to what's actually USED in FPGA development, we usually peel back all the layers of cruft, and find the source RTL under all the chaff. That's what's actually used in our scripts / development. It's usually much more flexible to use the actual RTL as well, as opposed to the crap they bolt on top of it. Regards, MarkArticle: 158627
> ... If you > wanted to push the clock frequency, and especially if you were going to > run multiple boards, then arranging things for best propagation delay > would get -- interesting. > This reminds me of the odd shape of the Cray 1. Effective, but probably a pain to assemble and debug. I think the bus wires of the Cray were also cut to the same length to reduce skew.Article: 158628
Mark Curry <gtwrek@sonic.net> wrote: > In article <n97cbb$re0$2@dont-email.me>, > Brian Drummond <brian@shapes.demon.co.uk> wrote: > > > >I hear you loud and clear. FPGA tool vendors are a couple of decades > >behind in their understanding of development practices, and often don't > >seem to consider version control at all. I'm also quite tired of vendors trying to re-implement their own version control systems. Altium has 'vaults', for instance, which are essentially a poor interface to Subversion ten years too late. The files are still binary and there's no usable merging. That's no good when your vcs of choice is git/bzr/hg/... > This. We'll often check in a zip'ed archive of the dummy run we used to > create the IP - along with ALL it's junk. Just for information purposes. > As to what's actually USED in FPGA development, we usually peel back all > the layers of cruft, and find the source RTL under all the chaff. That's > what's actually used in our scripts / development. > > It's usually much more flexible to use the actual RTL as well, as opposed > to the crap they bolt on top of it. We have the opposite problem. As an open source project we cannot ship the vendor RTL, because it usually says (c) Vendor, Do Not Distribute or something on it. But checking in the vendor RTL is the only way to get things done. So we have a split workflow: devs check in whatever vendor cruft into the private repo they need to make things work. Then, when we want to cut a public release, we have to go through and work out how to generate the RTL from licence-clean sources by some invocation of the tools. Once the invocations are put in the makefile, we can then build and check things still work with the generated RTL. Unfortunately the tools are often not friendly to this workflow. TheoArticle: 158629
On 03/02/16 13:36, Hamid Kavianathar wrote: > I'm going to do a very simple watermarking. I want to embed a signature on unused LUTs. could you please tell me how I can do it? > Thank you very much. What *problem* are you trying to solve with "watermarking"? Only after defining that can you begin to think whether watermarking is a sufficient solution. "If you think cryptography will solve your problem, you don't understand cryptography and you don't understand your problem".Article: 158630
How to make it visible in QuartusII ? Pinout cpld ? How to solder it to pcb ? Links ?Article: 158631
You can find some minimal development boards on ebay / aliexpress. I've used these successfully. Some include a USB Blaster device as well. Something like this: http://www.ebay.com/itm/Altera-MAX-II-EPM240-Core-Board-FPGA-CPLD-Development-Kits-JTAG-USB-Blaster-/330813186044?hash=item4d06009ffc:g:mZ0AAOSwDk5TwKe3 If you look for Altera's documentation about JTAG and Max II devices you'll find the pinout for the MAX 2 device. If you install Quartus II and attach the JTAG to the board you should see the device in the programmer without much hassle. Altera has a lot of video classes on their website that you can use to learn the workflow - I definitely recommend them. The package I tried soldering was a TQFP100 (0.5mm pitch). Personally I had limited success on the first try on a PCB breakout board: - misaligned the TQFP pins so I had to hot air it off the board and realign. - lots of shorts while soldering everything - using solder wick I removed most shorts but bent the pins so there are a few shorts. I'm going to try soldering another one again. Hopefully I'll be more successful this time. If you're ordering your own PCBs, having some larger uncovered traces help suck the additional solder away from pins to remove shorts. On my breakout the pads were pretty small and the rest of the traces going away from the pad were covered by soldermask. Good luck! Emilian On Wednesday, February 10, 2016 at 1:15:19 PM UTC-5, email...@gmail.com wrote: > How to make it visible in QuartusII ? > > Pinout cpld ? > > How to solder it to pcb ? > > Links ?Article: 158632
Emilian Miron wrote: > The package I tried soldering was a TQFP100 (0.5mm pitch). Personally I > had limited success on the first try on a PCB breakout board: - misaligned > the TQFP pins so I had to hot air it off the board and realign. - lots of > shorts while soldering everything - using solder wick I removed most > shorts but bent the pins so there are a few shorts. You need very fine solder, .010" if you can get it, or .015" if you can't get the thinner stuff. A soldering iron with an insanely small, sharp point. My technique is to put a dab of solder on two diagonal pads. Attach the chip to those pads, and then check the alignment. You can "walk" the chip a bit to get good alignment on all 4 sides, by heating one of those pads, then the other. When alignment is good, apply liquid flux to all four rows of leads. Apply it liberally, so the whole area where the leads touch the pads are covered with flux. Then, apply the soldering iron to one pin at a time, working your way around the chip. If the PC board has heavy solder plate, you won't need to add any solder. If the plate is thin, you may need to add solder every 3rd or 4th lead. You will need micro-size sloder wick for the inevitable bridges. I dip the solder wick in the same liquid flux I use in this process. It is messier, but works WAY better when it has lots of flux on it. I've soldered hundreds of TQFP chips in the 100, 128 and 144 size. The smallest were 128-lead with 0.4mm pitch. JonArticle: 158633
Is anybody out there using Microsemi's Libero SoC and the bundled Synplfiy Identify? Identify is giving me problems: 1. It will not accept a depth of greater than 128 even when I ask for it 2. Gives completely wrong and impossible waveform results and gives the error message: ERROR: objectsdb_type.cpp:207: assertion '0' failed Since Synplify is bundled by Microsemi, I have no support with Synosys, nor is there an Actel/Microsemi forum to ask on. thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158634
I don't have an answer, but I sympathize. I did a couple of RTAX designs, = and the tools are pretty primitive. Synplify for the Actel does not work a= s well as it does for other parts. I get the idea there's one guy at Synop= sis who spends one day a week on Actel support.Article: 158635
Hi, I need a full code example on how to use a floating multiplier on FPGA for VHDL-2008. What is the document name from XILINX? Jim's slides on floating multiplier are good, but not full and outdated. It was published on 2007. http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007.pdf Thank you. WengArticle: 158636
On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang wrote: > Hi,=20 >=20 > I need a full code example on how to use a floating multiplier on FPGA fo= r VHDL-2008. What is the document name from XILINX?=20 >=20 > Jim's slides on floating multiplier are good, but not full and outdated. = It was published on 2007.=20 >=20 > http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007.p= df=20 >=20 > Thank you.=20 >=20 >=20 > Weng I am not an expert for VHDL, but I would be really surprised if the tools w= ill be able to synthesize this data type. This VHDL package is meant to be = used for simulation. Xilinx has an IP which does various operations on floating point: http://ww= w.xilinx.com/products/intellectual-property/floating_pt.html. I would also = suggest checking out Vivado HLS since (at least IMHO) gives nice productivi= ty boost when writing floating-point signal processing modules.Article: 158637
On Sunday, February 21, 2016 at 1:58:03 PM UTC-8, Jan Marjanovi=C4=8D wrote= : > On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang wrote: > > Hi,=20 > >=20 > > I need a full code example on how to use a floating multiplier on FPGA = for VHDL-2008. What is the document name from XILINX?=20 > >=20 > > Jim's slides on floating multiplier are good, but not full and outdated= . It was published on 2007.=20 > >=20 > > http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007= .pdf=20 > >=20 > > Thank you.=20 > >=20 > >=20 > > Weng >=20 > I am not an expert for VHDL, but I would be really surprised if the tools= will be able to synthesize this data type. This VHDL package is meant to b= e used for simulation. >=20 > Xilinx has an IP which does various operations on floating point: http://= www.xilinx.com/products/intellectual-property/floating_pt.html. I would als= o suggest checking out Vivado HLS since (at least IMHO) gives nice producti= vity boost when writing floating-point signal processing modules. Hi Jan, very good, what you provided is what I want. But can you give more info abo= ut Vivado HLS? A pdf document link for Vivado HLS? Thank you.=20 WengArticle: 158638
Hi, I'm trying to transfer a small .bin file of size utmost 1-2MB from PC to sdr ddrram of ML403 using a crossover Ethernet cable (TCP/IP). I'm using PowerPC and plb bus. How do I write a socket program to transfer the file?Article: 158639
On 2/21/2016 4:57 PM, Jan Marjanovič wrote: > On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang > wrote: >> Hi, >> >> I need a full code example on how to use a floating multiplier on >> FPGA for VHDL-2008. What is the document name from XILINX? >> >> Jim's slides on floating multiplier are good, but not full and >> outdated. It was published on 2007. >> >> http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007.pdf >> >> >> Thank you. >> >> >> Weng > > I am not an expert for VHDL, but I would be really surprised if the > tools will be able to synthesize this data type. This VHDL package is > meant to be used for simulation. That is not a true statement. Floating point can be used for synthesis if supported by the vendor. I have not needed floating point in a VHDL design so I don't know how widely it is supported, but I know there is nothing special about floating point that makes it unsupportable. -- RickArticle: 158640
On 2/21/2016 7:14 PM, Weng Tianxiang wrote: > On Sunday, February 21, 2016 at 1:58:03 PM UTC-8, Jan Marjanovič wrote: >> On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang wrote: >>> Hi, >>> >>> I need a full code example on how to use a floating multiplier on FPGA for VHDL-2008. What is the document name from XILINX? >>> >>> Jim's slides on floating multiplier are good, but not full and outdated.. It was published on 2007. >>> >>> http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007..pdf >>> >>> Thank you. >>> >>> >>> Weng >> >> I am not an expert for VHDL, but I would be really surprised if the tools will be able to synthesize this data type. This VHDL package is meant to be used for simulation. >> >> Xilinx has an IP which does various operations on floating point: http://www.xilinx.com/products/intellectual-property/floating_pt.html. I would also suggest checking out Vivado HLS since (at least IMHO) gives nice productivity boost when writing floating-point signal processing modules. > > Hi Jan, > > very good, what you provided is what I want. But can you give more info about Vivado HLS? A pdf document link for Vivado HLS? You should be contacting the synthesis and FPGA vendors. -- RickArticle: 158641
On Tuesday, 23 February 2016 14:40:15 UTC+8, rickman wrote: > On 2/21/2016 7:14 PM, Weng Tianxiang wrote: > > On Sunday, February 21, 2016 at 1:58:03 PM UTC-8, Jan Marjanovi=C4=8D w= rote: > >> On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang wrote= : > >>> Hi, > >>> > >>> I need a full code example on how to use a floating multiplier on FPG= A for VHDL-2008. What is the document name from XILINX? > >>> > >>> Jim's slides on floating multiplier are good, but not full and outdat= ed.. It was published on 2007. > >>> > >>> http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_20= 07..pdf > >>> > >>> Thank you. > >>> > >>> > >>> Weng > >> > >> I am not an expert for VHDL, but I would be really surprised if the to= ols will be able to synthesize this data type. This VHDL package is meant t= o be used for simulation. > >> > >> Xilinx has an IP which does various operations on floating point: http= ://www.xilinx.com/products/intellectual-property/floating_pt.html. I would = also suggest checking out Vivado HLS since (at least IMHO) gives nice produ= ctivity boost when writing floating-point signal processing modules. > > > > Hi Jan, > > > > very good, what you provided is what I want. But can you give more info= about Vivado HLS? A pdf document link for Vivado HLS? >=20 > You should be contacting the synthesis and FPGA vendors. >=20 > --=20 >=20 > Rick Xilinx Vivado synthesis supports VHDL-2008, by enabling a Tcl command: set_param project.enableVHDL2008 1 After entering this command, the Project Settings dialogue box will show a = checkbox "Use VHDL 2008". Check this to VHDL-2008 support. Then you can set individual files to use the "VHDL 2008" file type. However, be warned that there is currently a problem with getting the IEEE = floating point package (float_pkg) to work with this option enabled. Howeve= r, previous versions of Vivado, I mean those that have not yet supported VH= DL-2008, do actually support the float_pkg library (weird I know). I have filed a case with Xilinx previously, but I'm not sure of its current= status. I believe they are working on this. If you want to use float_pkg, you need to NOT use the "VHDL 2008" option fo= r now. With this, you can use the "*" multiplication symbol to do floating-= point multiplications. Refer to Chapter 5 (pgs. 177 onwards) of the Vivado Design Suite User Guide= (v2015.3). http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_3/ug901-v= ivado-synthesis.pdf -danielArticle: 158642
On Sunday, 7 February 2016 21:50:30 UTC+8, Ilya Kalistru wrote: > On Sunday, February 7, 2016 at 3:15:25 PM UTC+3, Brian Drummond wrote: > > On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote: > >=20 > > > I'm looking for a peace of advice. > > > Currently I use git for version control in my VHDL projects and I > > > usually include all .vhd files as well as .xdc constrains files in it= . > > > But I don't know what I should do with ip cores. Including the whole > > > directory of ip core to repository doesn't seem to be a good idea > > > because there are to many files and too many of them are changed afte= r > > > any change of ip settings. Other choice, manual description of ip > > > settings in comments is tedious and error prone. > >=20 > > I hear you loud and clear. FPGA tool vendors are a couple of decades=20 > > behind in their understanding of development practices, and often don't= =20 > > seem to consider version control at all. > >=20 > > It takes some digging and experimentation to work out which =20 > > configuration files you need to regenerate the IP cores from, and how t= o=20 > > regenerate them with minimal GUI interaction. > >=20 > > Maybe worth digging around in the "command log" files to see which=20 > > command line tools are run when you press "Generate", and which files= =20 > > they take as inputs. That command line can then be extracted for=20 > > scripting the process. > >=20 > > Specific details will depend on the tools of course. > >=20 > > -- Brian >=20 > Ok. That is the approach I'm going to try. It has one disadvantage - conf= iguration files are not really human-readable (xilinx .xci), but it looks l= ike the best way by now. > Thank you for response. Xilinx's configuration files aren't really that human-unreadable. I am actu= ally amazed at how much standards support Xilinx puts into their tool and f= lows. If you take a good look into an *.xci file with a text editor, you wi= ll notice that it is in a human-readable XML format. And this is no ordinar= y XML - the format of the XML actually adheres to the IP-XACT specification= , which is indeed a portable method to package and transfer components betw= een tools that support this specification. https://en.wikipedia.org/wiki/IP-XACT -danielArticle: 158643
On Tuesday, 23 February 2016 20:38:17 UTC+8, Daniel Kho wrote: > On Sunday, 7 February 2016 21:50:30 UTC+8, Ilya Kalistru wrote: > > On Sunday, February 7, 2016 at 3:15:25 PM UTC+3, Brian Drummond wrote: > > > On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote: > > >=20 > > > > I'm looking for a peace of advice. > > > > Currently I use git for version control in my VHDL projects and I > > > > usually include all .vhd files as well as .xdc constrains files in = it. > > > > But I don't know what I should do with ip cores. Including the whol= e > > > > directory of ip core to repository doesn't seem to be a good idea > > > > because there are to many files and too many of them are changed af= ter > > > > any change of ip settings. Other choice, manual description of ip > > > > settings in comments is tedious and error prone. > > >=20 > > > I hear you loud and clear. FPGA tool vendors are a couple of decades= =20 > > > behind in their understanding of development practices, and often don= 't=20 > > > seem to consider version control at all. > > >=20 > > > It takes some digging and experimentation to work out which =20 > > > configuration files you need to regenerate the IP cores from, and how= to=20 > > > regenerate them with minimal GUI interaction. > > >=20 > > > Maybe worth digging around in the "command log" files to see which=20 > > > command line tools are run when you press "Generate", and which files= =20 > > > they take as inputs. That command line can then be extracted for=20 > > > scripting the process. > > >=20 > > > Specific details will depend on the tools of course. > > >=20 > > > -- Brian > >=20 > > Ok. That is the approach I'm going to try. It has one disadvantage - co= nfiguration files are not really human-readable (xilinx .xci), but it looks= like the best way by now. > > Thank you for response. >=20 > Xilinx's configuration files aren't really that human-unreadable. I am ac= tually amazed at how much standards support Xilinx puts into their tool and= flows. If you take a good look into an *.xci file with a text editor, you = will notice that it is in a human-readable XML format. And this is no ordin= ary XML - the format of the XML actually adheres to the IP-XACT specificati= on, which is indeed a portable method to package and transfer components be= tween tools that support this specification. > https://en.wikipedia.org/wiki/IP-XACT >=20 > -daniel Yes, I think it is a good idea to version control IP-XACT files. -danielArticle: 158644
Ilya Kalistru <stebanoid@gmail.com> wrote: > I'm looking for a peace of advice. > Currently I use git for version control in my VHDL projects and I usually > include all .vhd files as well as .xdc constrains files in it. But I don't > know what I should do with ip cores. Including the whole directory of ip core > to repository doesn't seem to be a good idea because there are to many files > and too many of them are changed after any change of ip settings. Other > choice, manual description of ip settings in comments is tedious and error > prone. I check in only the xci and xml files in the sources_1/ip structure. When checking out a pristine tree from source control and run generate bitstream for the first time, Vivado will go through the process of regenerating all the products of the included IP. This is GUI workflow. -- svennArticle: 158645
In article <4b7d68c4-7824-40d8-a114-b0c331b979a2@googlegroups.com>, Daniel Kho <daniel.kho@gmail.com> wrote: >On Sunday, 7 February 2016 21:50:30 UTC+8, Ilya Kalistru wrote: >> On Sunday, February 7, 2016 at 3:15:25 PM UTC+3, Brian Drummond wrote: >> > On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote: >> > >> > > I'm looking for a peace of advice. >> > > Currently I use git for version control in my VHDL projects and I >> > > usually include all .vhd files as well as .xdc constrains files in it. >> > > But I don't know what I should do with ip cores. Including the whole >> > > directory of ip core to repository doesn't seem to be a good idea >> > > because there are to many files and too many of them are changed after >> > > any change of ip settings. Other choice, manual description of ip >> > > settings in comments is tedious and error prone. >> > >> > I hear you loud and clear. FPGA tool vendors are a couple of decades >> > behind in their understanding of development practices, and often don't >> > seem to consider version control at all. >> > >> > It takes some digging and experimentation to work out which >> > configuration files you need to regenerate the IP cores from, and how to >> > regenerate them with minimal GUI interaction. >> > >> > Maybe worth digging around in the "command log" files to see which >> > command line tools are run when you press "Generate", and which files >> > they take as inputs. That command line can then be extracted for >> > scripting the process. >> > >> > Specific details will depend on the tools of course. >> > >> > -- Brian >> >> Ok. That is the approach I'm going to try. It has one disadvantage - configuration >> files are not really human-readable (xilinx .xci), but it looks like the best way >> by now. > >Xilinx's configuration files aren't really that human-unreadable. I am actually amazed at >how much standards support Xilinx puts into their tool and flows. If you take a good look >into an *.xci file with a text editor, you will notice that it is in a human-readable XML >format. And this is no ordinary XML - the format of the XML actually adheres to the >IP-XACT specification, which is indeed a portable method to package and transfer components >between tools that support this specification. >https://en.wikipedia.org/wiki/IP-XACT (Getting ranty, and not helping the OP, but this is a sore spot for us...) Xilinx support of standards is 2 steps forwards, 1.9 steps back. Sure they're using more "industry standard" files. (SDC, TCL). But they're still burying the landscape in a host of unneccesary, undocumented, randomly changing list of other ancillary files. I'm really not clear as to what IP-XACT is trying to solve, and who it's audience is. But XCI files are a very unreliable way of managing IP. Sure it's XML - there's tools available to manipulate them. But Xilinx doesn't document the data within those files in any way. They're free to change it at any time. Can a user reliably MERGE changes within those files from one development tree, and another? Will the design still build 1, 2, 5, or 10 years down the line using that undocumented src file? Can you simulate an XCI file? Can you run lint on it? Can you modify it's contents? What's configurable within them? In the end, it's just something that gets in the way of what you really need to do those tasks - the RTL (or netlist as neccesary - encrypted at worst case). Regards, MarkArticle: 158646
Hi, I wanted to prepare a small IP core able to serialize multiple interrupts as MSI interrupts handled by the Xilinx AXI MM 2 PCIe bridge. In the newest documentation ( http://www.xilinx.com/support/documentation/ip_documentation/axi_pcie/v2_7/pg055-axi-bridge-pcie.pdf ) it is stated that: * Additional IP is required in the Endpoint PCIe system to create the prioritization scheme for the MSI vectors on the PCIe interface. (that's why I want to create that core) * intx_msi_request Initiates a MSI write request when msi_enable = 1. Intx_msi_request is asserted for one clock period. * The intx_msi_grant signal is asserted for one clock period when the interrupt is accepted by the PCIe core. Does it mean, that I should set the MSI interrupt number on msi_vector_num and assert intx_msi_request for one clock period, and then (with deasserted intx_msi_request) wait until intx_msi_grant goes high for one clock? The more natural way would be for me to keep the intx_msi_request high until intx_msi_grant goes high... Unfortunately the documentation does not contain any example timing diagram/waveform. What if I have multiple interrupts to send? Can I set the new msi_vector_num in the next cycle after asserting intx_msi_request, or should I keep the old value until it is confirmed by intx_msi_grant? If the first option is right, may I assert intx_msi_request in the same cycle in which intx_msi_grant is asserted, to immediately send the next interrupt? I've sent this question also to the Xilinx forum ( https://forums.xilinx.com/t5/PCI-Express/AXI-MM-2-PCIe-sending-MSI-interrupts/m-p/683865 ) but have receive no answer yet. Maybe somebody here Thank you in advance, With best regards, WojtekArticle: 158647
I'm working at a big project with multiple developers and we also want to b=
e able to share sources in a version controlled friendly.
The project mainly uses X... FPGAs and V... tools.
One of possible approaches was to use IP packager, however it seems that it=
is not possible, or at least discouraged to use IP cores with port defined=
as VHDL records (just imagine a few AXI ports as bits and bit vectors, and=
compare it to the clean design of IPbus with record based ports - https://=
svnweb.cern.ch/trac/cactus )
The another approach I've proposed is based on extension of the old good PR=
J files.
The file may contain lines of following types:
- type library file
(Line defining the source file
Possible types: vhdl, verilog, system, header. xci, xdc
File name (path in fact) is defined relatively to the location of the
PRJ file)
- include file
(Line defining the include file
File name (path in fact) is defined relatively to the location of the
PRJ file
Use of relative paths allows easy reuse of so defined
blocks. Use of simple text files makes such solution
SVN/GIT friendly
Article: 158648
Oooops, sorry, I've unintentionally clicked "publish" before my message was=
ready :-(
Here it is again in a complete form.
I'm working at a big project with multiple developers and we also want to b=
e able to share sources in a version controlled friendly.
The project mainly uses X... FPGAs and V... tools.
One of possible approaches was to use IP packager, however it seems that it=
is not possible, or at least discouraged to use IP cores with port defined=
as VHDL records (just imagine a few AXI ports as bits and bit vectors, and=
compare it to the clean design of IPbus with record based ports - https://=
svnweb.cern.ch/trac/cactus )
=20
The another approach I've proposed is based on extension of the old good PR=
J files.
=20
The file may contain lines of following types:
- type library file
(Line defining the source file
Possible types: vhdl, verilog, system, header. xci, xdc
File name (path in fact) is defined relatively to the location of the
PRJ file)
=20
- include file
(Line defining the include file
File name (path in fact) is defined relatively to the location
of the PRJ file)
Use of relative paths allows easy reuse of so defined
blocks. Use of simple text files makes such solution
SVN/GIT friendly
I've prepared a simple routine, which translates PRJ file (with included
files) to the list of files, based on the "prj_add" routine
from UG946 tutorial.=20
Here it is:
# Procedure below reads the source files from PRJ files, extended with
# the "include file" statement
#Important thing - path to the source files should be given relatively
#to the location of the PRJ file.
proc read_prj { prj } {
#initialize results to an empty list
set res []
if {[file exists $prj]} {
puts "\tReading PRJ file: $prj"
set source [open $prj r]
set source_data [read $source]
close $source
#Extract the directory of the PRJ file, as all paths to the
#source files must be given relatively to that directory
set prj_dir [ file dirname $prj ]
regsub -all {\"} $source_data {} source_data
set prj_lines [split $source_data "\n" ]
set line_count 0
foreach line $prj_lines {
incr line_count
#Ignore empty and commented lines
if {[llength $line] > 0 && ![string match -nocase "#*" $line]} {
#Detect the inlude line
lassign $line type file
if {[string match -nocase $type "include"]} {
puts "\tIncluding PRJ file: $prj_dir/$file"
set inc [ read_prj $prj_dir/$file ]
foreach l $inc {
lappend res $l
}
} else {
lappend res [linsert $line 0 $prj_dir]=20
}
}
}
}
return $res
}
Of course the above procedure is a quick&dirty solution lacking the full er=
ror detection.
Anyway it is possible to define each IP block as a tree of directories cont=
aining sources and associated extended PRJ files.
The main disadvantage is that this approach is not supported by the tool ve=
ndor, so it is unclear whether it will work with the future versions...
Maybe this idea may be somehow improved?
With best regards,
Wojtek
Article: 158649
Yet one thing which was missed in my previous post.
How the read_prj procedure is used in the Tcl script building the project?
Below is the appropriate part of the Tcl script:
set prj src/top.prj
set prj_lines [ read_prj $prj ]
foreach line $prj_lines {
# Just read the type
puts $line
lassign $line pdir type lib file
# Handle the source files
if { \
[string match -nocase $type "xci"] || \
[string match -nocase $type "header"] || \
[string match -nocase $type "system"] || \
[string match -nocase $type "verilog"] || \
[string match -nocase $type "vhdl"]} {
set nfile [file normalize "$pdir/$file"]
add_files -norecurse -fileset $sobj $nfile
set file_obj [get_files -of_objects $sobj $nfile]
#Handle VHDL file
if {[string match -nocase $type "vhdl"]} {
set_property "file_type" "VHDL" $file_obj
set_property "library" $lib $file_obj
}
#Handle Verilog file
if {[string match -nocase $type "verilog"]} {
set_property "file_type" "Verilog" $file_obj
set_property "library" $lib $file_obj
}
#Handle SystemVerilog file
if {[string match -nocase $type "system"]} {
set_property "file_type" "SystemVerilog" $file_obj
}
#Handle Verilog header file
if {[string match -nocase $type "header"]} {
set_property "file_type" "Verilog Header" $file_obj
}
#Handle XCI file
if {[string match -nocase $type "xci"]} {
#set_property "synth_checkpoint_mode" "Singular" $file_obj
}
}
if { [string match -nocase $type "xdc"]} {
set nfile [file normalize "$pdir/$file"]
add_files -norecurse -fileset $cobj $nfile
set file_obj [get_files -of_objects $cobj $nfile]
set_property "file_type" "XDC" $file_obj
}
}
With best regards,
Wojtek
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z