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
Just read an article over at FPGA Journal about ways to bypass the security features on FPGA designs: http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-fending/ A lot of scary hype and generalities, but the underlying message seems to be that by using Differential Power Analysis it's possible to decrypt a protected FPGA design. Basic idea is to monitor the power consumption while loading the encrypted design, then via some kind of magic infer what the plaintext bitstream is and then reverse engineer it. Sounds like someone at a security research outfit is trying to sell some consulting hours to me, but what's the general feeling about this? Is this a real threat, and what are the realistic barriers to applying this attack? EricArticle: 145126
On 29 Jan., 00:55, emeb <ebromba...@gmail.com> wrote: > Sounds like someone at a security research outfit is trying to sell > some consulting hours to me, but what's the general feeling about > this? Is this a real threat, and what are the realistic barriers to > applying this attack? Sounds more like a Hype. The attacker should not be able to monitor power when the "key is loaded", because he could simply copy the key then. And when a bitstream key is hidden in SRAM cells or fuses of some FPGA it may be easier to find out what one thinks by looking at MRI images than copying the key by ever so sophisticated power analysis. But thinking about ways to break other protection schemes than in- device key & encrypted bitstream may be useful.Article: 145127
Hi Guys, Just wondering if the CLKIN_PERIOD value needs to be set to the period of input clock when instantiating a DCM component. I have a design where input clock can be either 25MHz or 125MHz, the clock frequency will change during operation. I will be using the DCM mainly for de- skewing. What should the CLKIN_PERIOD be set to in this case? Does it cause any problems if CLKIN_PERIOD is not set? Cheers SudhirArticle: 145128
>Just read an article over at FPGA Journal about ways to bypass the >security features on FPGA designs: > >http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-fending/ > >A lot of scary hype and generalities, but the underlying message seems >to be that by using Differential Power Analysis it's possible to >decrypt a protected FPGA design. Basic idea is to monitor the power >consumption while loading the encrypted design, then via some kind of >magic infer what the plaintext bitstream is and then reverse engineer >it. > >Sounds like someone at a security research outfit is trying to sell >some consulting hours to me, but what's the general feeling about >this? Is this a real threat, and what are the realistic barriers to >applying this attack? > >Eric > Why bother reverse engineering it. Buy a product, extract the bitstream, clone and PCB and partslist, and sell it. Back in the 60's the CIA dug a tunnel under the Berlin wall to tap into an underground telephone cable on the east side. The traffic was all encrypted but they had at one point passed next to some cable with unencrypted traffic. They recorded the noise spikes that were coupled over and could read the unencryted traffic at will. DPA is a cake walk compared to that. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145129
emeb <ebrombaugh@gmail.com> wrote: > Just read an article over at FPGA Journal about ways to bypass the > security features on FPGA designs: > http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-fending/ > A lot of scary hype and generalities, but the underlying message seems > to be that by using Differential Power Analysis it's possible to > decrypt a protected FPGA design. Basic idea is to monitor the power > consumption while loading the encrypted design, then via some kind of > magic infer what the plaintext bitstream is and then reverse engineer > it. Well, DPA is supposed to allow you to find the key. With the key you can then decrypt the bitstream. I would not expect that to be easy for an FPGA with encryption, but I don't know the details. > Sounds like someone at a security research outfit is trying to sell > some consulting hours to me, but what's the general feeling about > this? Is this a real threat, and what are the realistic barriers to > applying this attack? The usual DPA stories for smart cards (or other embedded processors) had to do with detecting the instruction flow. If you make branch decisions based on partly decoded keys, then it is easy to detect. What I had thought that FPGAs did was to decrypt through a DES key, and send the result to the configuration register. As has been discussed here, loading random bits into the configuration can damage the device, so I would expect loading the wrong encrypted bitstream to also do that. Assuming that no branches (state machine transitions) depend on the decoded bitstream, it would not seem easy. With the decryption logic running, would the power due to the decoded bitstream going through a shift register be noticed? It would seem more difficult, though, to protect against microprobes on the chip. In that case, if you can probe the configuration shift register then the bits should just fall out. -- glenArticle: 145130
On Jan 29, 1:55=A0am, emeb <ebromba...@gmail.com> wrote: > Just read an article over at FPGA Journal about ways to bypass the > security features on FPGA designs: > > http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-f... > > A lot of scary hype and generalities, but the underlying message seems > to be that by using Differential Power Analysis it's possible to > decrypt a protected FPGA design. Basic idea is to monitor the power > consumption while loading the encrypted design, then via some kind of > magic infer what the plaintext bitstream is and then reverse engineer > it. > > Sounds like someone at a security research outfit is trying to sell > some consulting hours to me, but what's the general feeling about > this? Is this a real threat, and what are the realistic barriers to > applying this attack? > > Eric security is sure more then just crypting "some part" of the design. a few days ago hackers did enter RING-0 on sony playstation 3 while that doesnt make the master encryption key visible it still allows many privileged things to be done. how it was done: 1 run linux (PS3 does allow that!) 2 execute special kernel module that allocates and deallocates memory manager tables 3 press a BUTTON on FPGA board that makes 40ns GLITCH on ext memory data bus 4 you are at hypervisor access level and basically there will be one memory map entry with supervisor privileges for you to use the story is a little bit more complex, but it only a little more complex then the story with nintendo WII, where the atack was done like this 1 run own app in "GC" mode (possible using other exploits) 2 short circuit one memory address bus with tweazers 3 "unvisible memory area" (protected by ASIC) is remapped into the PPC visible area 4 copy out the stuff and analyze -------- no DPA, no microscope no nothing, both WII and PS3 have ASIC buried master encryption keys that is still unknown to the hackers, but both systems are wide open to hacks.. while simple DPA may not give the Xilinx encryption key, there are things that have to be done to make your system secure. AnttiArticle: 145131
On 29 Jan., 04:09, Sudhir Singh <Sudhir.Si...@email.com> wrote: > Hi Guys, > > Just wondering if the CLKIN_PERIOD value needs to be set to the period > of input clock when instantiating a DCM component. I have a design > where input clock can be either 25MHz or 125MHz, the clock frequency > will change during operation. I will be using the DCM mainly for de- > skewing. What should the CLKIN_PERIOD be set to in this case? > Does it cause any problems if CLKIN_PERIOD is not set? > > Cheers > Sudhir Hi Sudhir, the DCM should work as specified, regardless of the frequency given in the coregenerator GUI or VHDL Generic Maps. Only thing to considder is, that the DCM might loose it's frequency locking when the input frequency changes. You should do some post-par simulations and observe the LOCKED signal. (Locking on a new frequency takes time.) Have a nice synthesis EilertArticle: 145132
On 29 Jan., 00:55, emeb <ebromba...@gmail.com> wrote: > Sounds like someone at a security research outfit is trying to sell > some consulting hours to me, but what's the general feeling about > this? Is this a real threat, and what are the realistic barriers to > applying this attack? DPA should be relatively easy on FPGAs. (But still hard) Usually an attacker using DPA has to guess the workings of the algorithm in the device. They use lots of statisctics to find clock cycles that show a small difference in power consumption when the key has a 1 or 0 at a certain bit. The advantage of an attack an on FPGA is, that the attacker can buy an identical FPGA and start experimenting with his own keys and own bitstreams to see how the individual key bits change the power consumption. For an attack on a smartcard you can only attack a given unknown key. On the other hand, as I understand it, parallel hardware implementations are a lot harder to attack using DPA than serial microcontroller implementations. Kolja SulimmaArticle: 145133
On Thu, 28 Jan 2010 14:11:50 -0800 (PST), rickman wrote: >TIME OUT!!!! When you start talking about "predictable delays", you >are not talking about ICs. The delay of a signal through a LUT is >very much a variable depending on the big three, temperature, voltage >and process (the IC itself). I expect you know this and you know what >you mean by "predictable", Probably :-) >but the actual delays within an FPGA can >easily vary over a range of 2:1 and I suspect the OP does *not* know >this. Very fair comment. >Trying to use delays of elements within an IC for frequency generation >is a very difficult thing to do. The delays are not consistent over >time (assuming the power supply voltage or temperature can change) and >will definitely change between units. There remain applications where a tapped delay chain, that can be adjusted on-the-fly, can be useful even though its absolute delay is very poorly known. Those applications are, of course, getting fewer as the most important ones get mopped-up by dedicated blocks in the FPGAs (PLL, deskewing of DDR clocks, SERDES, that sort of thing). But I found the speculation interesting anyway... >To the OP, how exactly would you expect this to work? There is a >reason why this is not supported in the tools, because everyone learns >very early in their career to not use logic as delays elements except >in a few very specific situations where you don't care about the >absolute delay, but rather only a relative delay or the actual delay >value is not important. Or where it's tweaked inside some kind of feedback loop. In that case, what matters is that the delay be a reasonably smooth function of tap selection - roughly equal increase in delay for each tap step - and that's what I was shooting for. Anyway, thanks for the sanity check! -- Jonathan BromleyArticle: 145134
[older stuff elided] >I will explain my problem. >I have a internal clock of 16.384MHz (50ppm) and a E1 interface >(MT9076B). >The E1 have a 4.096MHz clock (regenerated from E1) and a F0 (Frame >sync signal, active low). >When the E1 is installed (MT9076 chip is soldered at motherboard), I >use the E1 clock as master clock. One of my DCM (I have 2, Spartan3e >S100 sucks) I use to generate a 2MHz clock from E1 clock. This clock I >use to send the E1 data to MT9076, aligned with F0 signal. >What I want to do is use only the internal 2.048MHz (generate from >16.384MHz clock, with DCM) and interface with E1 through a FIFO. >Here is the problem. Internal and external clock are different, so the >FIFO will go underflow or overflow... >What I can do?? Use a DCM to phase lock both clocks?? But when MT9076 >goes free running I will have problem anyway. > >Waiting suggestions.. =3D) > >Thanks! > Ignoring the FPGA implementation issues and concentrating on the system design for a moment: What you want is a local Nx2048kHz clock, which can be slaved to an external 2048kHz clock when it is present (probably by a PLL), but free-runs at the correct nominal frequency when absent. This was quite a common requirement for telecomms equipment about 20 years ago. Thus when there is valid E1 data, none is lost. How to implement this using the inferior clock resources of the Spartan series of FPGAs is a rather harder question, which is left to others... Cheers, Robert --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145135
Hi!, I have been working with Altera FPGAs for a long time and now I have to deal with Xilinx ones. Until now, with Quartus II I have been able to manage the content of different registers and memories with 'In system memory editor' and I would like to do the same with Xilinx. I cannot find the right application to do it. Could you tell me which one I need or how I can do it? Thanx J. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145136
On Jan 29, 2:19=A0am, backhus <goous...@googlemail.com> wrote: > On 29 Jan., 04:09, Sudhir Singh <Sudhir.Si...@email.com> wrote: > > > Hi Guys, > > > Just wondering if the CLKIN_PERIOD value needs to be set to the period > > of input clock when instantiating a DCM component. I have a design > > where input clock can be either 25MHz or 125MHz, the clock frequency > > will change during operation. I will be using the DCM mainly for de- > > skewing. What should the CLKIN_PERIOD be set to in this case? > > Does it cause any problems if CLKIN_PERIOD is not set? > > > Cheers > > Sudhir > > Hi Sudhir, > the DCM should work as specified, regardless of the frequency given in > the coregenerator GUI or VHDL Generic Maps. > Only thing to considder is, that the DCM might loose it's frequency > locking when the input frequency changes. > You should do some post-par simulations and observe the LOCKED signal. > (Locking on a new frequency takes time.) > > Have a nice synthesis > =A0 Eilert If I'm not mistaken the CLKIN_PERIOD is mainly needed for the DFS portion of the DCM, which you shouldn't need for phase shifting. Also I've seen cases where the DCM loses lock and does not negate the LOCKED signal. You should monitor the status bits to be sure that the DCM is locked, and reset it when you detect loss of lock. Regards, GaborArticle: 145137
On Jan 28, 10:57=A0pm, "jt_eaton" <z3qmtr45@n_o_s_p_a_m.gmail.com> wrote: > >Just read an article over at FPGA Journal about ways to bypass the > >security features on FPGA designs: > > >http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-f... > > >A lot of scary hype and generalities, but the underlying message seems > >to be that by using Differential Power Analysis it's possible to > >decrypt a protected FPGA design. Basic idea is to monitor the power > >consumption while loading the encrypted design, then via some kind of > >magic infer what the plaintext bitstream is and then reverse engineer > >it. > > >Sounds like someone at a security research outfit is trying to sell > >some consulting hours to me, but what's the general feeling about > >this? Is this a real threat, and what are the realistic barriers to > >applying this attack? > > >Eric > > Why bother reverse engineering it. Buy a product, extract the bitstream, > clone and PCB and partslist, and sell it. > The point of encrypted bitstreams is that they only work on that one copy of the part, or on parts that have been loaded with the correct key. For Xilinx the key is stored in volatile SRAM and backed up with a battery. It would be pretty hard to take the chip top off for probing while keeping the backup power active, but of course not impossible. Also flip-chip packaging makes this sort of probing even harder. So you can copy the board, bitstream and all, but presumably not the key to make that bitstream work. > Back in the 60's the =A0CIA dug a tunnel under the Berlin wall to tap int= o an > underground telephone cable on the east side. The traffic was all encrypt= ed > but they had at one point passed next to some cable with unencrypted > traffic. > They recorded the noise spikes that were coupled over and could read the > unencryted traffic at will. > > DPA is a cake walk compared to that. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.comArticle: 145138
On Jan 29, 3:22=A0pm, "jmunir" <jmu...@gts.tsc.uvigo.es> wrote: > Hi!, > > I have been working with Altera FPGAs for a long time and now I have to > deal with Xilinx ones. Until now, with Quartus II I have been able to > manage the content of different registers and memories with 'In system > memory editor' and I would like to do the same with Xilinx. I cannot find > the right application to do it. Could you tell me which one I need or how= I > can do it? > > Thanx > > J. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com there is no such tool for Xilinx their programmers are just too lazy to make it AnttiArticle: 145139
On Jan 28, 1:55=A0pm, "Charles" <charlesdlam...@gmail.com> wrote: > Hi All, > =A0 =A0 =A0 =A0I am new to the FPGA design flow. Now I am working on FPGA= editor to > make changes in the design. Once I make changes in the ncd file i can hav= e > either a modified ncd file or a bit file from it (using Bitgen). > > My question is that is it possible to do post route simulation from any o= f > these two files or is there any other way to do it?? > > Thanks in Advance, > > Charles. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Yep. Look at the Command Line Tools User Guide (UG628) for the NetGen function. www.xilinx.com/support/documentation/sw.../xilinx11/devref.pdfArticle: 145140
Antti, Oh, you are so kind! Really, the way to set initial conditions is in your HDL code. For BRAM, there is a whole app note on how to use the data2bram utility to set BRAM contents. http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf I would argue that we are (trying to) prevent poor coding practices, which lead to errors, and poor HDL code, AustinArticle: 145141
On 29 Jan., 15:39, Gabor <ga...@alacron.com> wrote: > The point of encrypted bitstreams is that they only work on that > one copy of the part, or on parts that have been loaded with the > correct key. =A0For Xilinx the key is stored in volatile SRAM and > backed up with a battery. =A0It would be pretty hard to take the > chip top off for probing while keeping the backup power active, > but of course not impossible. =A0Also flip-chip packaging makes > this sort of probing even harder. > > So you can copy the board, bitstream and all, but presumably not the > key to make that bitstream work. DPA is a technique successfully used to read out the key from smartcards that are specifically designed to protect the key. There is no need to take the top off. DPA looks at the power supply of the chip. The differences seen on the power are very small, but with enough averaging you can differntiate any signal from the noise, so they repeat the operation many times until they see differences in power surge from cycle to cyle. With knowledge of the crypto algorithm - which they have in case of the FPGA - they can now simulate what the power consumption pattern for a 1 in the position X of the key would be compared to a 0 at that position. This is still hard work but in many cases a lot faster than a brute force attack. Also: At least for smart cards it is the case that once you learned how to get the key from a given type of smart card you can repeat this automated within a few minutes for another card of the same type. This means if XC5V keys are attacked successfully with this method you can build a device that cracks any other XC5V design quickly. Kolja SulimmaArticle: 145142
All, The clock in period for the DCM is used to set the configuration bits for best performance (tap size, etc.). If you don't set it to the right frequency range, you may not get the best performance, and perhaps it won't work at all if you are set for the low range, and the input is in the high range. The absolute value (accuracy) of the number is not important. The DCM software in ISE is just trying to make decisions based on the low frequency range, and the high frequency range. So, for example, if the input is from 25 MHz to 150 MHz, any value in this range is fine. The DCM will track any input in this range, until it runs out of taps with the delay lines. Then LOCKED goes false (the only reason why it does go false). Also monitor CLOCK_IN_LOST status bit, as when the clock is lost, this is the ONLY bit that changes (everything else is synchronous to CLOCK_IN, so when it is lost, nothing will change, except this one status bit). AustinArticle: 145143
On Jan 29, 6:13=A0pm, austin <aus...@xilinx.com> wrote: > Antti, > > Oh, you are so kind! > > Really, the way to set initial conditions is in your HDL code. > > For BRAM, there is a whole app note on how to use the data2bram > utility to set BRAM contents. > > http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf > > I would argue that we are (trying to) prevent poor coding practices, > which lead to errors, and poor HDL code, > > Austin Austin, I wanted to see the commentary. and well what I said stands: Xilinx could implement MEMORY editor the same way as Altera does suppor it if Xilinx software guys what care about the customers. The BRAM's can be accessed over JTAG, this is possible for Altera and for Xilinx devices Altera software does allow their customer to edit the BRAM over jtag because they have made this software for their customers, and well Xilinx has not. AnttiArticle: 145144
austin wrote: > Antti, > > Oh, you are so kind! > > Really, the way to set initial conditions is in your HDL code. > > For BRAM, there is a whole app note on how to use the data2bram > utility to set BRAM contents. > > http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf > > I would argue that we are (trying to) prevent poor coding practices, > which lead to errors, and poor HDL code, > > Austin Hi Austin, isn't that tool called data2mem now? regards Alan -- Alan Fitch Senior Consultant Doulos – Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.Article: 145145
On Jan 29, 6:42=A0pm, Alan Fitch <alan.fi...@spamtrap.com> wrote: > austin wrote: > > Antti, > > > Oh, you are so kind! > > > Really, the way to set initial conditions is in your HDL code. > > > For BRAM, there is a whole app note on how to use the data2bram > > utility to set BRAM contents. > > >http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf > > > I would argue that we are (trying to) prevent poor coding practices, > > which lead to errors, and poor HDL code, > > > Austin > > Hi Austin, > =A0 =A0isn't that tool called data2mem now? > > regards > Alan > > -- > Alan Fitch > Senior Consultant > > Doulos Developing Design Know-how > VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project > Services > > Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 > 1AW, UK > Tel: =A0+ 44 (0)1425 471223 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: alan.fi...= @doulos.com =A0 =A0 =A0 =A0 > Fax: =A0+44 (0)1425 471573 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.doul= os.com > > ------------------------------------------------------------------------ > > This message may contain personal views which are not the views of > Doulos, unless specifically stated. its data2mem, it is very useful, but it is NOT THE SAME thing! Altera IDE can edit the memory OVER JTAG, Xilinx tools can not. AnttiArticle: 145146
Antti, "If Xilinx cared about the customers...." Cruel, and inappropriate. Of course we care (deeply) about our customers! "Because Xilinx does not have Tool-A, they have no concern for customers..." It would be equally true then to say because the 'other guy' has no domain specific platforms, that they have zero regard for their customers, and force them to re-invent the wheel before they even begin a project ... (which in my humble opinion is all true) So, let us refrain from 'name calling', one could waste a great deal of time, AustinArticle: 145147
So, my question is: When I implement a block and I would like to control several of his parameters to test its behaviour, do I have to recompile each time I want to change one of them? :O That has not sense! It is impractical! J. >On Jan 29, 6:42=A0pm, Alan Fitch <alan.fi...@spamtrap.com> wrote: >> austin wrote: >> > Antti, >> >> > Oh, you are so kind! >> >> > Really, the way to set initial conditions is in your HDL code. >> >> > For BRAM, there is a whole app note on how to use the data2bram >> > utility to set BRAM contents. >> >> >http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf >> >> > I would argue that we are (trying to) prevent poor coding practices, >> > which lead to errors, and poor HDL code, >> >> > Austin >> >> Hi Austin, >> =A0 =A0isn't that tool called data2mem now? >> >> regards >> Alan >> >> -- >> Alan Fitch >> Senior Consultant >> >> Doulos Developing Design Know-how >> VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project >> Services >> >> Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 >> 1AW, UK >> Tel: =A0+ 44 (0)1425 471223 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: alan.fi...= >@doulos.com =A0 =A0 =A0 =A0 >> Fax: =A0+44 (0)1425 471573 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.doul= >os.com >> >> ------------------------------------------------------------------------ >> >> This message may contain personal views which are not the views of >> Doulos, unless specifically stated. > >its data2mem, it is very useful, but it is NOT THE SAME thing! > >Altera IDE can edit the memory OVER JTAG, >Xilinx tools can not. > >Antti > > > > > > > > > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145148
On Jan 29, 7:01=A0pm, austin <aus...@xilinx.com> wrote: > Antti, > > "If Xilinx cared about the customers...." > > Cruel, and inappropriate. > > Of course we care (deeply) about our customers! > > "Because Xilinx does not have Tool-A, they have no concern for > customers..." > > It would be equally true then to say because the 'other guy' has no > domain specific platforms, that they have zero regard for their > customers, and force them to re-invent the wheel before they even > begin a project ... (which in my humble opinion is all true) > > So, let us refrain from 'name calling', =A0one could waste a great deal > of time, > > Austin ah, relax.. both X and A care for the shareholders. but the topic about the "memory editor" is well, it would be SO EASY for Xilinx todo, but it has not been done. some 3rd party could do, i could do it, but it would be much more work for me todo it properly as it would be for xilinx, besides because Xilinx does not open up the xilinx usb cable protocol i could not support xilinx cables from my tool, so it would be pointless todo. there are two reasons why Xilinx does not have memory editor 1) there are some silicon problems, errata, bugs with the silicon preventing the usefulnes of the tool 2) Xilinx just doesnt care to offer this tool I see no other reasons. you can choose. either silicon problems, or lazy programmers. or management issues. i figured out 3rd option. but.. DATA2MEM is MUCH more important (yeah for the customers) then the memory editor and well Altera has no data2mem possibility at all, what is real problem. Xilinx has what is really needed, and misses on optional "good to have" thing that is not that vital. AnttiArticle: 145149
On Jan 29, 7:06=A0pm, "jmunir" <jmunir@n_o_s_p_a_m.gts.tsc.uvigo.es> wrote: > So, my question is: > > When I implement a block and I would like to control several of his > parameters to test its behaviour, do I have to recompile each time I want > to change one of them? :O > > That has not sense! It is impractical! > > J. > NO of course not!!! just use data2mem tool! Antti
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