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
Hi, by curiosity, has someone already connected the hidden SPI_ACCESS site in S= partan-6 FPGAs to see what happens? You can make this site appear in FPGA Editor by using Edit->Find, and enter= ing SPI_ACCESS. This will make the site selected internally, but the Array = view will not reflect the new selection (the site remains hidden). But by c= licking the Add button, a new COMP is created for this site, which you can = select in the List view and play with. This site is normally used for internal Flash memory on Spartan-3A, which S= partan-6 does not have. I guess, not yet :) There are also undocumented OCT_CALIBRATE sites that you can reveal using t= he same procedure... S.Article: 151101
On Sunday, March 6, 2011 4:24:38 AM UTC-5, glen herrmannsfeldt wrote: > Gabor <ga...@alacron.com> wrote: > > > Actually XST supports encrypted sources. PLDA > > delivers their "EZ-DMA" core as an encrypted > > source. This allows users to customize > > the core. I'd be very surprised if the major > > third-party synthesis tools didn't also > > allow encrypted sources. > > But if XST can decrypt it, then why can't someone else, > if they find the decryption key? > XST uses license manager to do the decryption. The key is not made public. So someone else would need to also have the same node ID for a node locked license as well as the decryption license file. This is no better and no worse than the license control for most software products. -- Gabor > > -- glen > > -- glenArticle: 151102
On Sunday, March 6, 2011 10:49:20 AM UTC-5, Sebastien Bourdeauducq wrote: > Hi, >=20 > by curiosity, has someone already connected the hidden SPI_ACCESS site in= Spartan-6 FPGAs to see what happens? >=20 > You can make this site appear in FPGA Editor by using Edit->Find, and ent= ering SPI_ACCESS. This will make the site selected internally, but the Arra= y view will not reflect the new selection (the site remains hidden). But by= clicking the Add button, a new COMP is created for this site, which you ca= n select in the List view and play with. >=20 > This site is normally used for internal Flash memory on Spartan-3A, which= Spartan-6 does not have. I guess, not yet :) >=20 > There are also undocumented OCT_CALIBRATE sites that you can reveal using= the same procedure... >=20 > S. On the Spartan 3AN series this would connect to the internal flash chip. So if S6 doesn't have an internal flash chip, then I would guess the flash connections to the SPI_ACCESS block would not be bonded, making the SPI_ACCESS block itself useless, unless I'm missing something? -- GaborArticle: 151103
Gabor <gabor@alacron.com> wrote: > On Sunday, March 6, 2011 4:24:38 AM UTC-5, glen herrmannsfeldt wrote: >> Gabor <ga...@alacron.com> wrote: >> >>> Actually XST supports encrypted sources. PLDA >>> delivers their "EZ-DMA" core as an encrypted >>> source. This allows users to customize >>> the core. I'd be very surprised if the major >>> third-party synthesis tools didn't also >>> allow encrypted sources. >> >> But if XST can decrypt it, then why can't someone else, >> if they find the decryption key? >> > XST uses license manager to do the decryption. The > key is not made public. So someone else would need > to also have the same node ID for a node locked > license as well as the decryption license file. > This is no better and no worse than the license > control for most software products. > > -- Gabor >> >> -- glen >> >> -- glen Yes, these are somewhat trivial to circumvent. Also, obfuscation != security.Article: 151104
Forget about that obfuscation snake oil (decrypting Modelsim-compatible enc= rypted models and messing with Xst's NGC files isn't even hard) and DRM-lik= e "protections" that create more problems than they solve. The only true wa= y you can enforce your IP licenses is by having a tool that automatically t= ells you if some binary bitstream uses your code so you can catch and sue p= eople who violate your license. Something akin to http://arstechnica.com/open-source/news/2010/04/tool-snif= fs-oss-binaries-for-sweet-smell-of-license-compliance.ars would be perfect.= Who wants to develop that? S. PS: Please no whining about the proprietary FPGA bitstream format: it can, = and has been, reverse engineered. By whining about that you will only show = your incompetence and laziness. And I never said that developing such a too= l would be easy, both technically and legally-wise.Article: 151105
On 03/02/2011 08:26 AM, Tim Wescott wrote: > On Wed, 02 Mar 2011 08:37:35 -0600, francesco_pincio wrote: > >> Hello! >> I'm new in the forum and just done an FPGA university course, very very >> small...we have only turned on/off led with finite state machine and so >> on...now i'm tryng to develope an IIR filter with XSA50 board form Xess >> with spartanIIe50 fpga. FIlter kernel is just a 2 pole system with a >> zero in 0, i would do a bandpass with changable passaband with >> pushbuttons; i 've idealized that main structure of the program would be >> a module with a counter for generating clock for the ADC/DAC, a module >> that pass this samples in the filtern kernel, the filter kernel iir >> itself and a module that passes filtererd samples to DAC; mainly i have >> 2 problems: >> >> 1) i can do only operation with radix-2 coefficient, so i can use only >> 1/2, 1/4 an so on. i don't understand how to pass a float value and >> multiply it > > Who needs floating point? You can do this all with fixed point > arithmetic. Let your coefficients range from -1 to 1, or 0 to 2, or > whatever you need, then implement your filter. In an HDL, this is a > matter of doing your multiplication, and picking the leftmost (or nearly > leftmost) bits out of the answer, instead of the rightmost. > >> 2)do i need a ram to store at least y[n-2] sample? > > Are you trying to do this in batch mode, or continuous? If it's > continuous, you should only need to keep two filter states. > > You will find that you need to keep more precision on your filter states > than you have on your incoming (and probably outgoing) data. > > This is not a subject that can be done justice to in a newsgroup posting, > and everyone and his sister wants to know. Do a web search on "IIR > Filter for FPGA" and you should find at least one tutorial. > Dangit! I forgot my shameless plug!!! The last chapter of my book, "Applied Control Theory for Embedded Systems" shows how to implement fixed-point filters in C, and discusses the issues of implementing fixed-point filters in general. There's no HDL of any kind (which, in hindsight, I see I should have included). But you may find it useful none the less. http://www.wescottdesign.com/actfes/actfes.html http://www.elsevier.com/wps/find/bookdescription.cws_home/707797/description#description -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 151106
Sebastien Bourdeauducq <sebastien.bourdeauducq@gmail.com> wrote: > Forget about that obfuscation snake oil (decrypting Modelsim-compatible > encrypted models and messing with Xst's NGC files isn't even hard) and > DRM-like "protections" that create more problems than they solve. The > only true way you can enforce your IP licenses is by having a tool that > automatically tells you if some binary bitstream uses your code so you > can catch and sue people who violate your license. > > Something akin to > http://arstechnica.com/open-source/news/2010/04/tool-sniffs-oss-binaries-for-sweet-smell-of-license-compliance.ars > would be perfect. Who wants to develop that? > > S. > > PS: Please no whining about the proprietary FPGA bitstream format: it > can, and has been, reverse engineered. By whining about that you will > only show your incompetence and laziness. And I never said that > developing such a tool would be easy, both technically and legally-wise. Could you provide a source for the complete reverse engineer (bitstream to source/netlist) of a bitstream. I'd like to read about it.Article: 151107
On Mar 1, 8:41=A0am, Peter wrote:
> Andy, I completely agree with what you have written above.
> One should strive for maintainable and understandable version.
> Although, on my particular case, I have to find a good solution
> in terms of LUT resources, because I need 8 instances of
> one counters with 64-bit input data. And the device is getting full...
Peter,
It looks like you've solved your problem simply by moving to a
better synthesis tool, so this may not be of interest anymore.
However, in addition to space, finding a more compact implementation
often leads to a speed increase as well, AND power savings.
Additionally, I like this counting bits problem, it turns up often
enough that it deserves some attention. As to maintainability, nothing
promotes that more than good comments. Once the function is written it
can be stuffed away in a package, never dealt with again (If anyone
copies the code, please include credit).
See my other post for the most compact/fastest way to implement the 32-
bit sum using 4-LUTs and taking advantage of carry logic fabric.
Gabor's post of the 35 LUT number when using 6-LUTs got me looking at
that case. Here are the results (Spartan 3 for the 4-LUTs, Spartan 6
for the 6-LUTs, XST for both, I'd be curious if any other synthesis
tool does better). Synthesizers continually improve, but nothing beats
a good look at the problem, as the 6-LUT case illustrates with a
better than 2:1 savings:
vec32_sum2: 4-input LUTs: 53 Slices: 31
vec32_sum3: 6-input LUTs: 15 Slices: 4
Finally, this is a neat problem because it's nice to make the little
things count.
Best regards all,
John L. Smith
Code for 6-LUT based 32 bit sum:
function vec32_sum3( in_vec : in UNSIGNED ) return UNSIGNED is
type Leaf_type is array ( 0 to 63 ) of UNSIGNED( 2 downto
0 );
-- Each ROM entry is sum of address bits:
constant Leaf_ROM : Leaf_type :=3D (
"000", "001", "001", "010", "001", "010", "010", "011",
"001", "010", "010", "011", "010", "011", "011", "100",
"001", "010", "010", "011", "010", "011", "011", "100",
"010", "011", "011", "100", "011", "100", "100", "101",
"001", "010", "010", "011", "010", "011", "011", "100",
"010", "011", "011", "100", "011", "100", "100", "101",
"010", "011", "011", "100", "011", "100", "100", "101",
"011", "100", "100", "101", "100", "101", "101", "110" );
type S3_Type is array ( 0 to 4 ) of UNSIGNED( 2 downto 0 );
variable S3 : S3_Type;
variable result : UNSIGNED( 5 downto 0 );
variable Leaf_Bits : natural range 0 to 63;
variable S4_1 : UNSIGNED( 3 downto 0 );
variable S4_2 : UNSIGNED( 3 downto 0 );
variable S5_1 : UNSIGNED( 4 downto 0 );
begin
-- Form five 3-bit sums using three 6-LUTs each:
for i in 0 to 4 loop
Leaf_Bits :=3D TO_INTEGER( UNSIGNED( in_vec( 6 * i + 5 downto 6 *
i ) ) );
S3( i ) :=3D Leaf_ROM( Leaf_Bits );
end loop;
-- Add two 3-bit sums + leftover leaf bits as a carry in to get 4
bit sums:
S4_1 :=3D ( "0" & S3( 0 ) ) + ( "0" & S3( 1 ) )
+ ( "000" & in_vec( 30 ) );
S4_2 :=3D ( "0" & S3( 2 ) ) + ( "0" & S3( 3 ) )
+ ( "000" & in_vec( 31 ) );
-- Add 4 bit sums to get 5 bit sum:
S5_1 :=3D ( "0" & S4_1 ) + ( "0" & S4_2 );
-- Add leftover 3 bit sum to get 5 bit result:
result :=3D ( "0" & S5_1 )
+ ( "000" & S3( 4 ) );
return result;
end vec32_sum3;
Article: 151108http://www.ulogic.org http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.6043&rep=rep1&type=pdfArticle: 151109
Sebastien Bourdeauducq <sebastien.bourdeauducq@gmail.com> wrote: > http://www.ulogic.org > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.6043&rep=rep1&type=pdf I've read that. It's only a partial reversal, and is outdated due to current bitstream encryption methods.Article: 151110
Maybe the Ulogic implementation lacks a few features, but I can't see any o= bstacle to implement them using the proposed methods. Are you talking about the battery-backed SRAM holding the encryption key? I= have not seen any consumer device using this, and I also do not know how s= trong this protection is for someone armed with strong knowledge of FPGA in= ternals and bitstream format. For example, readback of the cleartext of an encrypted bitstream is allowed= through the ICAP on Spartan-6. Now, you can't partially reconfigure an enc= rypted FPGA to gain access to the ICAP, but what about inserting the malici= ous logic while the FPGA reads its encrypted bitstream? Normally CBC would = prevent that, but perhaps this could be in turn circumvented by unexpected = modifications of the on-chip configuration system's frame address register = during the transfer of the encrypted data. That's something that needs some= research I think, before blindly believing in the promises of the FPGA com= panies.Article: 151111
In article <ikvjsl$41r$3@news.eternal-september.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >The question, then, is how valuable is the IP? >How hard do you need to make it to reverse engineer? > >There is always the obfuscator, that replaces all the symbolic >(and maybe human readable) names with random symbols, often >made of 0, 1, O, I, and maybe l. Presumably also removing >any comments that were in there. > I've often wondered what I'd do in the OP's position. I'd think I'd just supply the source. It's just not worth the trouble, and all those darned protection methods are a PITA for you, waste your resources (time) on throw-away work, and pisses the customer off. Maybe if you didn't have the GENERICS issue - supply just a synthesized netlist, and an NGC. But the GENERICS screw this route. At the very most, I'd use an obfuscator as Glen suggested. Here, it still works plain and simple, and the customer could debug things - it's not much worse than debugging netlists that have been hammered by a synthesis engine. But not many people are going to go through too much trouble to reverse engineer the obfuscation. --MarkArticle: 151112
On Mar 8, 12:37=A0pm, gtw...@sonic.net (Mark Curry) wrote: > In article <ikvjsl$41...@news.eternal-september.org>, > glen herrmannsfeldt =A0<g...@ugcs.caltech.edu> wrote: > > >The question, then, is how valuable is the IP? > >How hard do you need to make it to reverse engineer? > > >There is always the obfuscator, that replaces all the symbolic > >(and maybe human readable) names with random symbols, often > >made of 0, 1, O, I, and maybe l. =A0Presumably also removing > >any comments that were in there. > > I've often wondered what I'd do in the OP's position. =A0I'd think > I'd just supply the source. =A0It's just not worth the trouble, > and all those darned protection methods are a PITA for you, waste your > resources (time) on throw-away work, and pisses the customer off. =A0 > > Maybe if you didn't have the GENERICS issue - supply just a synthesized > netlist, and an NGC. =A0But the GENERICS screw this route. > > At the very most, I'd use an obfuscator as Glen suggested. =A0Here, > it still works plain and simple, and the customer could debug > things - it's not much worse than debugging > netlists that have been hammered by a synthesis engine. =A0But not many > people are going to go through too much trouble to reverse engineer the o= bfuscation. > > --Mark Hey Guys, Thanks for all your replies. Its amazing there seems be no standard/ safe way of IP delivery (if you don't want to supply source)! Cheers JasonArticle: 151113
Thank you all for the replies, I think I will go with what Mike suggests. Regarding the ADC, I was aware of the poor performances of the FPGAs regarding clock jitter, so it's all ok for the performances we need. Thanks again! Stefano. Mike Shogren wrote: > Stefano, > > I would _strongly_ recommend stubbing out the top level with all of > the pins in the design, especially the "picky" ones that you pointed > out. It may take some time up front, but well worth it not to get > burned with a bad pin placement that cripples your design once you get > boards back. You should not need the entire design completed, but you > will need some logic in place to ensure that things don't get > synthesized out by the tools. > > Regarding the comment about clocking the ADC with an FPGA output... > This assumes that the FPGA-driven clock drives the sample rate of the > ADC. Depending on what you need, performance-wise, this may still be > fine. Something to keep in mind though, for sure. > > Good luck! > -- > Mike Shogren > Director of FPGA Development > Epiq Solutions > www.epiq-solutions.comArticle: 151114
> But not many > people are going to go through too much trouble to reverse engineer the obfuscation. But why would they bother if the source works? They can just use the obfuscated module wherever they want. Nial.Article: 151115
Michael <michael_laajanen@yahoo.com> writes: >>>> I am trying a design that is from ISE 9.2 on the latest 12.4 using >>>> CentOS >>>> 64 bit and receive the following error, I can't find anything >>>> on Xilinx that refers to it. >>>> >>>> Anyone seen the same and know a solution? >>>> >>>> >>>> >>>> INTERNAL_ERROR:Portability:basutencodeimp.c:229:1.24 - Number of bytes >>>> peeked >>>> does not match number of bytes requested. Corrupted file? >>> >>> >> >> /michael > Just an update. CentOS is not supported and does not seam to run on IS > 12.4 sadly. 9.2 does! we have on our Servers CentOS (5.5), and ISE 12.4 works on it. Never saw your error, maybe its something in your design, that the new version no longer supports? http://www.xilinx.com/support/answers/32912.htm indicates that maybe some permissions are wrong (the link leads to a VISTA Problem, but it got exact the same error message). FlorianArticle: 151116
I was once involved on a joint project with another company. The (rather unpopular) project manager at the other company rejoiced in the name Maycock and one of our managers christened him Mayhem and Halfcock.Article: 151117
It was interesting to read some synthesis benchmarking results on comp.lang.vhdl last week. I feel it's high time that EDA vendors drop the anti-benchmarking clauses from their license agreements: http://www.sigasi.com/content/your-milage-may-vary-lot To summarize my points: 1. There is no clear definition of what a "benchmark result" is, you don't know when you are breaching the contract. 2. Public benchmarking hinders competition and innovation. 3. Customers deserve to be treated with more respect. I'd love to hear your thoughts, either on this newsgroup, or on my webpage. kind regards -- Philippe www.sigasi.comArticle: 151118
"mary helen aka lisa lee" <user@compgroups.net/> wrote in message news:8c-dnc6rdORSn_LQnZ2dnUVZ_qmdnZ2d@giganews.com... >I am his sister... he is a ufo hunter and inventor and he talks all the >time...more proof? he went to Boerne High in Tx. he built an airplain in >his senior yr. http://lmgtfy.com/?q=jerry+harthcockArticle: 151119
It seems to me that obfustication is only really worthwhile if you want to try and stop someone finding out how your ip works. It will not stop anyone from actually using the ip which is surely what most people would want. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151120
"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote in message news:IaidneHsCrW-w-vQnZ2dnUVZ_s6dnZ2d@giganews.com... > It seems to me that obfustication is only really worthwhile if you want to > try and stop someone finding out how your ip works. It will not stop anyone > from actually using the ip which is surely what most people would want. > Jon Exactly. Nial.Article: 151121
On Mar 6, 11:30=A0pm, JustJohn <justjohna...@gmail.com> wrote: > On Mar 1, 8:41=A0am, Peter wrote: > > > Andy, I completely agree with what you have written above. > > One should strive for maintainable and understandable version. > > Although, on my particular case, I have to find a good solution > > in terms of LUT resources, because I need 8 instances of > > one counters with 64-bit input data. And the device is getting full... > > Peter, > =A0 It looks like you've solved your problem simply by moving to a > better synthesis tool, so this may not be of interest anymore. > However, in addition to space, finding a more compact implementation > often leads to a speed increase as well, AND power savings. > Additionally, I like this counting bits problem, it turns up often > enough that it deserves some attention. As to maintainability, nothing > promotes that more than good comments. Once the function is written it > can be stuffed away in a package, never dealt with again (If anyone > copies the code, please include credit). > > See my other post for the most compact/fastest way to implement the 32- > bit sum using 4-LUTs and taking advantage of carry logic fabric. > Gabor's post of the 35 LUT number when using 6-LUTs got me looking at > that case. Here are the results (Spartan 3 for the 4-LUTs, Spartan 6 > for the 6-LUTs, XST for both, I'd be curious if any other synthesis > tool does better). Synthesizers continually improve, but nothing beats > a good look at the problem, as the 6-LUT case illustrates with a > better than 2:1 savings: > > =A0 vec32_sum2: =A04-input LUTs: 53 =A0Slices: 31 > =A0 vec32_sum3: =A06-input LUTs: 15 =A0Slices: 4 > > Finally, this is a neat problem because it's nice to make the little > things count. > > Best regards all, > John L. Smith > Chagrinned OOPS!, synthesizer was throwing the leaf ROMs into BRAMs for the 6-LUT case. Actual numbers for the 6-LUT case without BRAMs are (and this is not a synthesis benchmark, it is an illustraion of efficient circuit structure expressed via coding style to reduce LUT usage, applicable across all synthesis tools, thanks for the warning Philippe, and BTW I AGREE, EULAs forbidding benchmarks are evil): vec32_sum3: 6-input LUTs: 30 Slices: 4 Still tops 35, although some may consider the code too complex for marginal improvement. Regards, JohnArticle: 151122
Hi, I am new to the FPGA world and trying to design my first Spartan-3E board (mostly using "copy and paste"...). Why are there 2 resistors on inputs M0 and M2 on the following schematic? http://cjoint.com/?1dis6y5LNzz (Basys 2 board) By the way why is there a resistor on M1 ? Direct grounding is not OK ? Thanking you in advance.Article: 151123
Thank you for everyone who responded! This last one seems to be good for this purpose. --- Peter On m=E1rc. 5, 11:48, Socrates <mail...@gmail.com> wrote: > http://www.ebv.com/index.php?id=3D162&ct_ref=3Du103-c84&tx_ebvproductfe_p= i1[uid]=3D2011 > > Smallest Cyclone IV GX, DDR2 RAM, embedded USB blaster and 24pins I/Os > - 170 EU @ EBV.Article: 151124
Le 08/03/2011 19:02, PovTruffe a écrit : > Hi, > > I am new to the FPGA world and trying to design my first Spartan-3E board > (mostly using "copy and paste"...). > > Why are there 2 resistors on inputs M0 and M2 on the following schematic? > http://cjoint.com/?1dis6y5LNzz (Basys 2 board) > > By the way why is there a resistor on M1 ? Direct grounding is not OK ? Hi and welcome to this wonderful world ;-) The configuration selection pins are also user pins after configuration. If you want to use them as IOs you won't like them to be directly connected to ground or Vcc. Nicolas
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