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 Jun 2, 9:53=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > does anybody have real and realistic performance figures for Xilinx > GbE solution with XPS_TEMAC/MPMC ? > > we need to get 60% of GbE wirespeed, UDP transmit only but it seems > like real hard target to reach :( > > MPMC has memory latency of 23 cycles (added to EACH memory access > cycle) so the ethernet > SDMA takes a lot of bandwith already, there is another DMA writing > data at same speed, and the > PPC itself uses the same memory too > > Antti Antti, Take a look at http://www.treck.com They do high performance TCP/IP But if all you need is UDP, you don't have to use XPS at all. You can design custom logic that does DMA from the memory controller directly into the GbE MAC. I've done it with very good performance results. Email me for more info. -outputlogic -- visit http://outputlogic.com : tools that improve productivity --Article: 141026
On 2 June, 21:47, Jan Pech <inva...@void.domain> wrote: > On Tue, 2009-06-02 at 11:32 -0700, Antti.Luk...@googlemail.com wrote: > > On 2 June, 21:05, Jan Pech <inva...@void.domain> wrote: > > > On Tue, 2009-06-02 at 09:53 -0700, Antti wrote: > > > > Hi > > > > > does anybody have real and realistic performance figures for Xilinx > > > > GbE solution with XPS_TEMAC/MPMC ? > > > > > we need to get 60% of GbE wirespeed, UDP transmit only but it seems > > > > like real hard target to reach :( > > > > > MPMC has memory latency of 23 cycles (added to EACH memory access > > > > cycle) so the ethernet > > > > SDMA takes a lot of bandwith already, there is another DMA writing > > > > data at same speed, and the > > > > PPC itself uses the same memory too > > > > > Antti > > > > With custom Ethernet core + MPMC we get data rates slightly above > > > 100MBps, depending on MTU. The single memory is shared by MicroBlaze/= PPC > > > for code and data access, at least one streaming data source (custom = PIM > > > for NPI) and the custom Ethernet IP (MAC + some packet composers, > > > decoders, etc.) again connected to NPI. > > > We rejected to use XPS_TEMAC because its low performance. The problem= is > > > I lost my benchmark results. Sorry. > > > > Jan > > > hum.. my current task is to optimize a XPS_TEMAC based system > > (with 1 single DDR2 chip as main memory!) > > to reach about 580MBps > > > :( > > > I have never said that to be possible, but i need money :( > > and if the goal cant be reached there will be none... > > > over 100MBps is sure possible (with XPS_TEMAC too) > > =A0but 580MBps is beyong doable i think for sure > > > Antti > > Just a simple calculation: > 125000000 / 1024 / 1024 =3D 119.2MBps > It is without protocol overhead, FCS, IFGs. How do you want to exceed > limit of Gigabit Ethernet? > > Jan ups silly me :( B is as byte I wanted say we need 580Mbit/s AnttiArticle: 141027
On 2 June, 21:51, OutputLogic <evgen...@gmail.com> wrote: > On Jun 2, 9:53=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > Hi > > > does anybody have real and realistic performance figures for Xilinx > > GbE solution with XPS_TEMAC/MPMC ? > > > we need to get 60% of GbE wirespeed, UDP transmit only but it seems > > like real hard target to reach :( > > > MPMC has memory latency of 23 cycles (added to EACH memory access > > cycle) so the ethernet > > SDMA takes a lot of bandwith already, there is another DMA writing > > data at same speed, and the > > PPC itself uses the same memory too > > > Antti > > Antti, > > Take a look athttp://www.treck.com > They do high performance TCP/IP > But if all you need is UDP, you don't have to use XPS at all. You can > design custom logic that does DMA from the memory controller directly > into the GbE MAC. > I've done it with very good performance results. Email me for more > info. > > -outputlogic > > -- > visithttp://outputlogic.com: tools that improve productivity > -- hm we DO NOT COPY the UDP buffers around at all they are pre-formatted by custom DMA so i do not see much where treck would give us any gain AnttiArticle: 141028
On 2 June, 21:50, Jan Pech <inva...@void.domain> wrote: > On Tue, 2009-06-02 at 20:47 +0200, Jan Pech wrote: > > On Tue, 2009-06-02 at 11:32 -0700, Antti.Luk...@googlemail.com wrote: > > > On 2 June, 21:05, Jan Pech <inva...@void.domain> wrote: > > > > On Tue, 2009-06-02 at 09:53 -0700, Antti wrote: > > > > > Hi > > > > > > does anybody have real and realistic performance figures for Xili= nx > > > > > GbE solution with XPS_TEMAC/MPMC ? > > > > > > we need to get 60% of GbE wirespeed, UDP transmit only but it see= ms > > > > > like real hard target to reach :( > > > > > > MPMC has memory latency of 23 cycles (added to EACH memory access > > > > > cycle) so the ethernet > > > > > SDMA takes a lot of bandwith already, there is another DMA writin= g > > > > > data at same speed, and the > > > > > PPC itself uses the same memory too > > > > > > Antti > > > > > With custom Ethernet core + MPMC we get data rates slightly above > > > > 100MBps, depending on MTU. The single memory is shared by MicroBlaz= e/PPC > > > > for code and data access, at least one streaming data source (custo= m PIM > > > > for NPI) and the custom Ethernet IP (MAC + some packet composers, > > > > decoders, etc.) again connected to NPI. > > > > We rejected to use XPS_TEMAC because its low performance. The probl= em is > > > > I lost my benchmark results. Sorry. > > > > > Jan > > > > hum.. my current task is to optimize a XPS_TEMAC based system > > > (with 1 single DDR2 chip as main memory!) > > > to reach about 580MBps > > > > :( > > > > I have never said that to be possible, but i need money :( > > > and if the goal cant be reached there will be none... > > > > over 100MBps is sure possible (with XPS_TEMAC too) > > > =A0but 580MBps is beyong doable i think for sure > > > > Antti > > > Just a simple calculation: > > 125000000 / 1024 / 1024 =3D 119.2MBps > > It is without protocol overhead, FCS, IFGs. How do you want to exceed > > limit of Gigabit Ethernet? > > > Jan > > Or did I get you wrong and you talk about Mbits per second? I was > talking about Mbytes per sec. > If it is so, your goal should be reachable using xps_ll_temac instead of > xps_temac. > Jan oh, i am talking wrong today yes Mbit/sec or Mbps and sure XPS_LL_TEMAC with ALL hardware options tuned to maximum and we do not copy buffers, and do not calc UDP checksum with PPC but, even TRECKs marketing booklet promised only 355 Mbps for MTU1500 abd i need 580Mbps AnttiArticle: 141029
Antti <Antti.Lukats@googlemail.com> writes: > > sure the code is maybe not fully correct, nice, i would never write > like this, > but it works with 3 different type of tools, and fails with the 4th Me neither. I would think it like this: if DidPause = "01" or (Pause = "00" and DidPause(1) = '0') then if Rst_r = '1' or Inst_Skip = '1' then -- Skip/flush: NOP insertion Inst <= (others => '0'); else Inst <= ROM_Data; end if; Since I have no access to any VHDL tool at the moment, I cannot be quite sure about the correctness but it gives the general idea how I used to write VHDL. Or maybe there is some particular reason this could not be done so? > so question is, is the code "wrong enough" to allow Magma synthesis > to generate valid as per VHDL code, that doesnt work? > I do not have any personal experience about Magma, but different interpretation of synthesizable code between synthesis tools does not surprise me at all. My students were very good at finding those kind of problems where another tool might even refuse to continue when the other did not find anything wrong :) - PauliArticle: 141030
On 2 June, 22:25, Pauli Per=E4l=E4 <nob...@nowhere.com.invalid> wrote: > Antti <Antti.Luk...@googlemail.com> writes: > > > sure the code is maybe not fully correct, nice, i would never write > > like this, > > but it works with 3 different type of tools, and fails with the 4th > > Me neither. I would think it like this: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if DidPause =3D "01" or (= Pause =3D "00" and DidPause(1) =3D '0') then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if Rst_r = =3D '1' or Inst_Skip =3D '1' then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 -- Skip/flush: NOP insertion > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Inst <=3D (others =3D> '0'); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Inst <=3D ROM_Data; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if; > > Since I have no access to any VHDL tool at the moment, I cannot be quite > sure about the correctness but it gives the general idea how I used to > write VHDL. Or maybe there is some particular reason this could not be > done so? > > > so question is, is the code "wrong enough" to allow Magma synthesis > > to generate valid as per VHDL code, that doesnt work? > > I do not have any personal experience about Magma, but different > interpretation of synthesizable code between synthesis tools does not > surprise me at all. My students were very good at finding those kind of > problems where another tool might even refuse to continue when the other > did not find anything wrong :) > > - Pauli it seems that all other except magma syntheis think this way another way is to create feedback mux, it would create also working code whatever magma did, did not work AnttiArticle: 141031
Rich Webb <bbew.ar@mapson.nozirev.ten> wrote:
>On Mon, 1 Jun 2009 13:15:13 -0700 (PDT), "jack.gassett"
><jack.gassett@gadgetfactory.net> wrote:
>
>>Hello all,
>>
>>I just wanted to post that I have released an open source FPGA circuit
>>design. Please feel free to use it as is or to quick start your own
>>designs. It is released under the Creative Commons Attribution license
>>exactly like the Arduino. This is a work in progress so any feedback
>>is appreciated.
>>
>>Here are some specifications:
>>-Schematic and Board layout in EAGLE.
>
>Just curious, but why EAGLE and not one of the open source schematic
>capture and board layout apps like gEDA or Kicad?
I'd recommend using PCB (also open source) instead of KiCad. PCB works
better (don't forget to turn the DRC on).
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 141032<Antti.Lukats@googlemail.com> wrote in message news:244fac96-a937-48b4-949e- > > but, even TRECKs marketing booklet promised only 355 Mbps for MTU1500 > abd i need 580Mbps Antti, I think Treck numbers assume TCP/IP. I am actually in the middle of evaluating the same thing. I have a design similar to the one described in XAPP1041 running on a custom V4FX60 board and I seem to be getting the numbers you are looking for (raw Ethernet Tx traffic) although it is early for me to say whether they are "real", i.e. I haven't yet analyzed properly what the Xilinx perf_app software does. /MikhailArticle: 141033
hello! I'm using xps_ll_temac in my project to send media from ML507 to internet. But after serveral minutes the system automatic reset and an error occur with message: "incorrect configuration: xps_ethernetlite drivers not present?". I don't know why because I'm using xps_ll_temac? On the other hand, when I pressed reset button there was the same error occured. Have you got any advance? Thanks!Article: 141034
Hi all, I am wondering what would be the distinct advantage of implementing Memory using the Dedicated BRAM instead of using the LUTs (assuming I have plenty of LUTs at my disposal). Will Speed be a criterion? While I am working on that deeply, if someone had prior experience researching this point, will be glad to hear your views. Thanks in advance, Venkat.Article: 141035
Anybody could give some advice? Thanks a lot!Article: 141036
Venkat wrote: > I am wondering what would be the distinct advantage of implementing > Memory using the Dedicated BRAM instead of using the LUTs (assuming I > have plenty of LUTs at my disposal). Will Speed be a criterion? While > I am working on that deeply, if someone had prior experience > researching this point, will be glad to hear your views. If you have plenty of LUTs, you can use it. Synthesizing time might be really slow, but a big advantage is that you don't have a read latency like with BRAM, so might be easier to build fast caches or registers with it. I use LUTs for small register memory, too, e.g. in my signal generator: http://www.frank-buss.de/SignalGenerator/ -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 141037
On 3 Jun., 07:28, Venkat <venkat.ja...@gmail.com> wrote: > Hi all, > > I am wondering what would be the distinct advantage of implementing > Memory using the Dedicated BRAM instead of using the LUTs (assuming I > have plenty of LUTs at my disposal). Will Speed be a criterion? While > I am working on that deeply, if someone had prior experience > researching this point, will be glad to hear your views. > > Thanks in advance, > Venkat. Hi Venkat, speed will surely be a point as the distributive memory grows. The other point is size. IT makes no sense to waste LUTs for memory if your BRAMs are empty. And you need a lot of LUTs to make a of RAM the same size as a BRAM- Block. Use each memory wisely to take advantage of it's special abilities. some generic examples: If you need some kB of RAM for average bus sizes of 8,16,32 (+parity) BRAMs are most likely the best choice. if you need a wide ram with limited size (e.g. 256 x 4) Distributive RAM is your friend. The first example will be found quite often in processor related designs and video processing. The second one is mainly used in DSP or cryptographic applications. Of course there are always unique problems that need special handling of your ressources. You need to deal with these individually. Have a nice synthesis EilertArticle: 141038
Venkat wrote:
> I am wondering what would be the distinct advantage of implementing
> Memory using the Dedicated BRAM instead of using the LUTs
BRAM is synchronous and easy to use, and it often goes /unused/.
While LUTs and flops are good for almost anything,
BRAM is designed to
be RAM.
-- Mike Treseler
Article: 141039On Jun 3, 11:01=A0am, goo...@twinmail.de wrote: > On 3 Jun., 07:28, Venkat <venkat.ja...@gmail.com> wrote: > > > Hi all, > > > I am wondering what would be the distinct advantage of implementing > > Memory using the Dedicated BRAM instead of using the LUTs (assuming I > > have plenty of LUTs at my disposal). Will Speed be a criterion? While > > I am working on that deeply, if someone had prior experience > > researching this point, will be glad to hear your views. > > > Thanks in advance, > > Venkat. > > Hi Venkat, > speed will surely be a point as the distributive memory grows. > The other point is size. IT makes no sense to waste LUTs for memory if > your BRAMs are empty. > And you need a lot of LUTs to make a of RAM the same size as a BRAM- > Block. > Use each memory wisely to take advantage of it's special abilities. > > some generic examples: > If you need some kB of RAM for average bus sizes of 8,16,32 (+parity) > BRAMs are most likely the best choice. > if you need a wide ram with limited size (e.g. 256 x 4) Distributive > RAM is your friend. > > The first example will be found quite often in processor related > designs and video processing. > The second one is mainly used in DSP or cryptographic applications. > > Of course there are always unique problems that need special handling > of your ressources. > You need to deal with these individually. > > Have a nice synthesis > =A0 Eilert Hello Eilert and Frank, Thank you so much for the responses. So the deciding factors would be Size of the Memory and Efficient Utilization of the Available Resources. On the Speed factor, from Eilert's views, speed is going to slow down on LUT based RAMs as the size grows larger. However for reasonably smaller size, the speed on LUT would be higher? I came across one paper where the DES algorithm has been implemented with/without BRAMs and the figures show a better Data Rate for LUT Implementation. The reason quoted is the number of critical paths (larger for BRAM based than LUT based). Any idea on this point? Appreciate your time. Venkat.Article: 141040
On Tue, 02 Jun 2009 09:06:18 -0700, OutputLogic wrote: > On Jun 1, 3:34 pm, phil hays <philh...@dont.spam> wrote: >> soar2morrow wrote: >> >> Has anyone tried to install a Xilinx floating license? >> >> Yes, three days ago. It really was no problem. And this was on Fedora, >> which isn't supported. >> >> > Now, just try to find XLCM on Xilinx's website (all you will find are >> > references to it. >> >> If the Xilinx tools are installed on the system, open a command prompt >> and type xclm. >> >> > To further complicate issues, it seems like the only way to get help >> > of ANY KIND is to submit a web case. Just try to talk to someone on >> > the phone! I actually did; guess what they said: SUBMIT A WEB CASE! >> >> I'll be happy to solve problems like this for you for $85/hour plus >> expenses and travel. Send me an email. I'm very familiar with the >> Xilinx tools and FPGA design. >> >> -- >> Phil Hays >> (phil_hays at eeei.gro (fix the order for email) > > > I installed the floating license yesterday on Windows 64-bit server. So > far so good. > Speaking of licenses, we needed a few node-locked licenses in addition > to the floating one. It made things much more expensive and as the > result we want to re-evaluate our commitment to Xilinx. Does anybody > have a recent experience with Altera licensing cost. The Altera license was roughly half the cost, the last time I bought one. The Xilinx license is more flexible though - you can get a node locked license and run multiple concurrent instances of the software on that machine. (You can verify this for yourself - the license file has "uncounted" in it. The local FAE confirmed that this is not a mistake, and we will be holding him to this.) Cheers, AllanArticle: 141041
Hello, I'm working on a system combining a MicroBlaze, memory and some user RTL logic. I'm not the creator, I've received all the files and I'm supposed to introduce a few changes... However, I've encountered a problem. I'll try to describe it. In the design, there are a few clock signals used, generated by a clock generator IP. I was supposed to add a new clock signal in the generator and feed with it a clock input of one of the system components. I've done it. But... I have to add a constraint for this new clock in the UCF file. Once I've added a constrained (manually), I've received an error in Xilinx ISE (clock signal I've added is unknown). And Xilinx ISE doesn't allow me to add a constraint in GUI because of the same reason. What the hell is wrong? Maybe there is a simple obvious thing I don't know. Anyway, iif you have any idea - please, tell me! Thanks in advance. *** ADDITIONAL INFO *** The exact error message I've received is as follows: ERROR:ConstraintSystem:59 - Constraint <NET "MB_SYSTEM/clock_generator_0/clock_generator_0/PLL0_CLK_OUT<5>" TNM_NET = MB_SYSTEM/clock_generator_0/clock_generator_0/PLL0_CLK_OUT<5>;> [MB_ENCODER.ucf(287)]: NET "MB_SYSTEM/clock_generator_0/clock_generator_0/PLL0_CLK_OUT<5>" not found. Please verify that: 1. The specified design element actually exists in the original design. 2. The specified object is spelled correctly in the constraint source file. <end of msg> As far as I know, the specified design element does actually exist in the original design!Article: 141042
<snip> > > > > hum.. my current task is to optimize a XPS_TEMAC based system > > > > (with 1 single DDR2 chip as main memory!) > > > > to reach about 580MBps > > > > > :( > > > > > I have never said that to be possible, but i need money :( > > > > and if the goal cant be reached there will be none... > > > > > over 100MBps is sure possible (with XPS_TEMAC too) > > > > =A0but 580MBps is beyong doable i think for sure > > > > > Antti > > > > Just a simple calculation: > > > 125000000 / 1024 / 1024 =3D 119.2MBps > > > It is without protocol overhead, FCS, IFGs. How do you want to exceed > > > limit of Gigabit Ethernet? > > > > Jan > > > Or did I get you wrong and you talk about Mbits per second? I was > > talking about Mbytes per sec. > > If it is so, your goal should be reachable using xps_ll_temac instead o= f > > xps_temac. > > Jan > > oh, i am talking wrong today > yes Mbit/sec or Mbps > and sure XPS_LL_TEMAC with ALL hardware options tuned to maximum > and we do not copy buffers, and do not calc UDP checksum with PPC > > but, even TRECKs marketing booklet promised only 355 Mbps for MTU1500 > abd i need 580Mbps > > Antti Antti, The USRP2 (http://en.wikipedia.org/wiki/ Universal_Software_Radio_Peripheral) is a software-defined radio that uses a Spartan III + gigE PHY chip to reach 800 Mbits/sec sustained. I believe the MAC in their FPGA has a few limitations (only supports 1000 Base-T) but was originally based on the opencores tri-mode MAC (though significant modifications were needed to make it reliable, IIRC). The other caveat here is that the USRP2 guys push raw ethernet frames into a PC...i.e., they don't use TCP or UDP. I believe their analysis showed that they needed a custom network layer to support the sustained high data rates. So I wouldn't give up hope on making something work here at 580 Mbits/ sec. All of the USRP2 code (software + HDL) is open-sourced, and should be available through their subversion repositories. Good Luck, JohnArticle: 141043
On Jun 3, 5:33=A0am, "john.orla...@gmail.com" <john.orla...@gmail.com> wrote: > <snip> > > > > > > > > > > hum.. my current task is to optimize a XPS_TEMAC based system > > > > > (with 1 single DDR2 chip as main memory!) > > > > > to reach about 580MBps > > > > > > :( > > > > > > I have never said that to be possible, but i need money :( > > > > > and if the goal cant be reached there will be none... > > > > > > over 100MBps is sure possible (with XPS_TEMAC too) > > > > > =A0but 580MBps is beyong doable i think for sure > > > > > > Antti > > > > > Just a simple calculation: > > > > 125000000 / 1024 / 1024 =3D 119.2MBps > > > > It is without protocol overhead, FCS, IFGs. How do you want to exce= ed > > > > limit of Gigabit Ethernet? > > > > > Jan > > > > Or did I get you wrong and you talk about Mbits per second? I was > > > talking about Mbytes per sec. > > > If it is so, your goal should be reachable using xps_ll_temac instead= of > > > xps_temac. > > > Jan > > > oh, i am talking wrong today > > yes Mbit/sec or Mbps > > and sure XPS_LL_TEMAC with ALL hardware options tuned to maximum > > and we do not copy buffers, and do not calc UDP checksum with PPC > > > but, even TRECKs marketing booklet promised only 355 Mbps for MTU1500 > > abd i need 580Mbps > > > Antti > > Antti, > The USRP2 (http://en.wikipedia.org/wiki/ > Universal_Software_Radio_Peripheral) is a software-defined radio that > uses a Spartan III + gigE PHY chip to reach 800 Mbits/sec sustained. > I believe the MAC in their FPGA has a few limitations (only supports > 1000 Base-T) but was originally based on the opencores tri-mode MAC > (though significant modifications were needed to make it reliable, > IIRC). =A0The other caveat here is that the USRP2 guys push raw ethernet > frames into a PC...i.e., they don't use TCP or UDP. =A0I believe their > analysis showed that they needed a custom network layer to support the > sustained high data rates. > > So I wouldn't give up hope on making something work here at 580 Mbits/ > sec. =A0All of the USRP2 code (software + HDL) is open-sourced, and > should be available through their subversion repositories. > > Good Luck, > John I'm using UDP and getting sustainable 600-700Mbits/sec. In fact this number is limited by the PC side: either a network card or a stack. - outputlogicArticle: 141044
Is your top level design in ISE or EDK? Can you post your system.mhs file? /MikhailArticle: 141045
On Tue, 02 Jun 2009 22:28:58 -0700, Venkat wrote: > Hi all, > > I am wondering what would be the distinct advantage of implementing > Memory using the Dedicated BRAM instead of using the LUTs (assuming I > have plenty of LUTs at my disposal). Will Speed be a criterion? While I > am working on that deeply, if someone had prior experience researching > this point, will be glad to hear your views. > > Thanks in advance, > Venkat. If it's bigger than 32 deep then use BRAM otherwise use LUT RAM. Small LUT RAMs are faster, the read is asynchronous, and they place less burden on the place and router. The advantage of BRAM is size, if you need lots of RAM then you use BRAM.Article: 141046
On Jun 2, 10:44=A0pm, vcar <hi...@163.com> wrote: > Anybody could give some advice? Thanks a lot! My advice is to read the data sheets for the chips mounted on the modules. ALArticle: 141047
"Allan Herriman" <allanherriman@hotmail.com> wrote in message news:004237cd$0$9747$c3e8da3@news.astraweb.com... > > The Xilinx license is more flexible though - you can get a node locked > license and run multiple concurrent instances of the software on that > machine. Do you know if the same can be done with a floating license, i.e. running multiple instances on a single machine with a single license? /MikhailArticle: 141048
How would I create a create a secure netlist that I could give to a 3rd party. Ideally I would like the edif output from Synplify but in a protected form. Cheers JonArticle: 141049
maxascent wrote: > How would I create a create a secure netlist that I could give to a 3rd > party. Ideally I would like the edif output from Synplify but in a > protected form. http://download.cnet.com/windows/encryption-software/
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