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
pbFJKD@ludd.invalid wrote: >>which is a WINE port. One user reports some ISE 8.2 compatibility. Of >>course, what we really need is a Mac port of the Xilinx tools. > > > Won't the linux-32bit version run under Mac OS X ..? > ISE runs on FreeBSD and Mac OS X is based FreeBSD. > I am in no way an expert on this topic, but my limited understanding (based on Google Group searches) is that Linux programs run on FreeBSD using the Linux compatibility layer, but the Linux compatibility layer doesn't really work on OS X. --- Joe Samson Pixel VelocityArticle: 114826
On 2007-01-24, Sylvain Munaut <SomeOne@SomeDomain.com> <246tnt@gmail.com> wrote: > > This takes a stream of continous data, and they have to be continuous, > 1 each clock (there are pauses but very far apart) and they don't have > "enable" on their registers. Now, the rest of my chain only can process > 2 data in 3 cycles ... So run the two processes in different clock domains. Make one from the other with a DCM so there's no long-term drift. Then connect the two with a fifo. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 114827
Bill, Is your bitstream synchronous with the input clock? You could try sychronizing your data using two (or three) D-type FF, such that the rising edge of the input clock, clocks the data into the first FF, then into the second on the next rising edge. This will allow the first FF (if the bit stream is not 100% synchronous) to stabilize before entering the second FF before allowing to pass to the bitstream decode locic. You will have a 2 clock delay. You can also use the DDR register to make the synchronized bitstream and clock souce synchronous. Clock the DDR register with the same input clock, tie one of the DDR's inputs to Logic 1 and the other to 0, and also clock your bitstream through a FF using the same input clock. Set the constraints to keep the all that logic in the same area. I've done this in the past for asynchronous signals and it worked okay. You may also want to look in to the DCM, though i have less expeirence with the DCM and there full capabilities in the Vertix 4. Hope this helps. --Brian On Jan 24, 1:08 pm, Bill <seabass...@yahoo.com> wrote: > I am using a virtex 4. I have an clock input, and another input for bitstream. What is the best way to align the rising edge of a bit to the rising edge of a clock? It needs very quick. Currently I am using IDELAY to shift the data until I notice no bit errors, but it is taking up to 500ms.Article: 114828
Always consult the datasheet. You may need more than 0.1uF bypass caps. I will usually use a range from 0.01uF to 10uF and for more powerful FPGAS up too 1000uF. This is something that can be determined using the XPower tools from Xilinx ISE. For prototype you may not need to go crazy on bypassing, but at a min 1 0.1uF per Power Pin as close to to the power pin with a good low impeadance via (or three) to the ground plane. Also, the amount of bypassing needed will depend on the power supply used, the routing of the power to the chip and how close it is to you IC. If you use a switching PS you will need good high quality bypass caps to clean out the high frequency switching noise. If the power supply has a slow response to current spikes you will need more larger caps to fill in where the Power supply cannot. Keeping the PS as close to the load will always improve power quality and also using large tracks or better yet power planes in pairs. Even if it is a pour on the top and bottom. Granted Xilinx CPLDs are great for low power consumption, but during flashing, they can draw a significant load on the supplies. --Brian On Jan 24, 2:47 pm, Ben Jackson <b...@ben.com> wrote: > On 2007-01-24, <imity> <> wrote: > > > I have previous experience with microchip pics, do I need a > > 0.1uF bypass cap for the +/- pins?If you don't, I doubt you will even be able to program it. The charge > pump for the flash programming will fail. > > -- > Ben Jackson AD7GD > <b...@ben.com>http://www.ben.com/Article: 114829
steve.lass@xilinx.com wrote: > Doug, > > If you have a case number, I can track it down and try to get you > an answer. > > Steve > > "doug" <doug@doug> wrote in message > news:12rf4t0tknpph59@corp.supernews.com... > >>jbnote wrote: >> >>>>Memory leaks come from sloppy programmers. Not fixing memory leaks >>>>comes from lazy or incompetent programmers. >>> >>> >>>Even incompetent programmers can manage this. The use of valgrind >>>[http://www.valgrind.org] will pinpoint memory leaks right to the line >>>where the allocation was made. It runs on unmodified software. This >>>would be, oh, one hour work maximum if you have the source. >>> >>>JB >>> >> >>So, Austin and the other Xilinx people that monitor the board-- >>Why is Xilinx not willing to take the hour to fix a show stopper >>problem that has existed for at least a year in at least NINE >>versions of ISE? >> >>There have been 7 sevice packs issued which still have this >>problem. This means it is a management decision to not fix >>things. The fact that the service pack and the release came >>at the same time was a very bad sign. >> >>On the other hand, could I get a job as a xilinx programmer, >>or better yet, as a manager. I have always had bosses who >>exptected me to do things correctly. This would be a nice >>change. >> >> > > > Case number 662555. CR 430822, 430823Article: 114830
On 24 Jan 2007 11:41:42 -0800, gsosar@gmail.com wrote: >ERROR:MapLib:30 - LOC constraint L23 on PIN_L23 is invalid: No such >site on the ... > >I understand that this pins labels are invalid in the FPGA of ML403 >board, and when I look for the pins in the Virtex IV datasheet I see >that this both pins are not connected in the xc4vfx12ff668-10 FPGA. >The BLUEpins, GREENpins, REDpins, VSYNCpin, HSYNCpin and CLOCKpin are >right the wrong are: > >BLANKpin "M24" >SYNCpin "L23" > >Thanks in advance > >Gerardo Sosa Hi, namesake, On the ML403, some VGA pins are missing, IIRC there are only 5 bits per colour. On the ML402, these pins are available. The epoxy board seems to be the same. (I have ML402s only) The 3 bits are not much of a loss, because the analog quality of the DAC outputs is so sh***y that you will never see pretty eye diagrams etc if you use them as pseudo-analog test points for your DSP stuff (clock feedthru, overshoot...) That hurts, because the ML402 is meant for DSP. BTW, will the Webpack 9.1 recognize a valid full ISE 8.1 installation and work for the V4-SX35 on the ML402? (interim solution until the CDs are here) regards, GerhardArticle: 114831
Hi there, I have noticed that in microchip pic's the power pins are next to each other, making it very easy to simply stick a 0.1u cap between them. I wonder if this is the sign that a bypass cap is required (as opposed to chips were the power pins are furthest away, like e.g. pins 7/14 or 14/28 etc?) "Tim Wescott" <tim@seemywebsite.com> wrote in message news:urGdnQTweMpjDCrYnZ2dnUVZ_uOmnZ2d@web-ster.com... > imity wrote: > > I have previous experience with microchip pics, do I need a > > 0.1uF bypass cap for the +/- pins? > > > > > Every chip, everywhere should have bypass caps on all power pins. > > Period. > > If the manufacturer says not to do it, then you should comply, but > reluctantly (re: Microchip Vpp line, which is driven by the programmer > and Must Have Fast Edges). > > If it has more than one power pin, it should have more than one cap. > The rule of thumb is to have one cap per power pin. Extras never hurt. > If the chip designers were paying attention you'll find power and > ground pins in pairs; you should lay out your board so you have short > runs to the caps. If the chip designers were _really_ paying attention > you'll find a section of the data sheet that specifies how the bypass > caps should be laid out. Follow it. > > -- > > Tim Wescott > Wescott Design Services > http://www.wescottdesign.com > > Posting from Google? See http://cfaj.freeshell.org/google/ > > "Applied Control Theory for Embedded Systems" came out in April. > See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 114832
Doug, The case was created on December 6, 2006. We reproduced the problem in-house and created the CRs on December 13. This was after 9.1i was released. CR 430822 is a memory leak and has been scheduled to be fixed in 10.1 to coincide with an intiative we have to fix memory issues. We're going to try to fix CR 430823 in 9.2. Regarding spending an hour running Valgrind and finding all of the memory leaks, that might make sense for a smaller application, but isn't possible for a multi-million line program that has a large number of developers. We do use Valgrind and have spent at least a man year on this resulting in many of the issues found and fixed, but not all. Steve "doug" <doug@doug> wrote in message news:12rfge2gh2ugh2c@corp.supernews.com... > steve.lass@xilinx.com wrote: >> Doug, >> >> If you have a case number, I can track it down and try to get you >> an answer. >> >> Steve >> >> "doug" <doug@doug> wrote in message >> news:12rf4t0tknpph59@corp.supernews.com... >> >>>jbnote wrote: >>> >>>>>Memory leaks come from sloppy programmers. Not fixing memory leaks >>>>>comes from lazy or incompetent programmers. >>>> >>>> >>>>Even incompetent programmers can manage this. The use of valgrind >>>>[http://www.valgrind.org] will pinpoint memory leaks right to the line >>>>where the allocation was made. It runs on unmodified software. This >>>>would be, oh, one hour work maximum if you have the source. >>>> >>>>JB >>>> >>> >>>So, Austin and the other Xilinx people that monitor the board-- >>>Why is Xilinx not willing to take the hour to fix a show stopper >>>problem that has existed for at least a year in at least NINE >>>versions of ISE? >>> >>>There have been 7 sevice packs issued which still have this >>>problem. This means it is a management decision to not fix >>>things. The fact that the service pack and the release came >>>at the same time was a very bad sign. >>> >>>On the other hand, could I get a job as a xilinx programmer, >>>or better yet, as a manager. I have always had bosses who >>>exptected me to do things correctly. This would be a nice >>>change. >>> >>> >> >> >> > Case number 662555. CR 430822, 430823 >Article: 114833
No, this is just history. On the old 7400 gates and MSI parts, Vcc and GRND were diagonally opposed, for no good reason (it actually gave max length to the bond wires, and thus max inductance.) One of the "Original Sins" of this industry. But remember, rise and fall times were >10 ns ! Peter Alfke On Jan 24, 2:56 pm, <imity> wrote: > Hi there, > I have noticed that in microchip pic's the power pins are next > to each other, making it very easy to simply stick a 0.1u cap > between them. I wonder if this is the sign that a bypass > cap is required (as opposed to chips were the power pins are > furthest away, like e.g. pins 7/14 or 14/28 etc?) > > "Tim Wescott" <t...@seemywebsite.com> wrote in messagenews:urGdnQTweMpjDCrYnZ2dnUVZ_uOmnZ2d@web-ster.com... > > > imity wrote: > > > I have previous experience with microchip pics, do I need a > > > 0.1uF bypass cap for the +/- pins? > > > Every chip, everywhere should have bypass caps on all power pins. > > > Period. > > > If the manufacturer says not to do it, then you should comply, but > > reluctantly (re: Microchip Vpp line, which is driven by the programmer > > and Must Have Fast Edges). > > > If it has more than one power pin, it should have more than one cap. > > The rule of thumb is to have one cap per power pin. Extras never hurt. > > If the chip designers were paying attention you'll find power and > > ground pins in pairs; you should lay out your board so you have short > > runs to the caps. If the chip designers were _really_ paying attention > > you'll find a section of the data sheet that specifies how the bypass > > caps should be laid out. Follow it. > > > -- > > > Tim Wescott > > Wescott Design Services > >http://www.wescottdesign.com > > > Posting from Google? Seehttp://cfaj.freeshell.org/google/ > > > "Applied Control Theory for Embedded Systems" came out in April. > > See details athttp://www.wescottdesign.com/actfes/actfes.htmlArticle: 114834
Joseph wrote: > I wonder if anyone here are in the same situation as me. > I am think of buying a new PC, but wondering if I should > wait for Windows Vista become available first. No. Windows Vista won't do any better for FPGA development than XP. Likely it will just create new hassles. Stick with what's known to work. Personally, I much prefer Linux. I'm now using WebPACK 9.2i on Fedora Core 6, and it works great, so I expect that the full ISE 9.2i should be fine also.Article: 114835
Peter Alfke wrote: > No, this is just history. On the old 7400 gates and MSI parts, Vcc and > GRND were diagonally opposed, for no good reason (it actually gave max > length to the bond wires, and thus max inductance.) > One of the "Original Sins" of this industry. But remember, rise and > fall times were >10 ns ! > Peter Alfke The spin I heard, for the reason for corner pins, was to allow better Power Supply grid layouts. Yes, even using AC mains terminology & thinking :) In those days, multi-layer PCBs were rare, and WIDE traces were also needed, to handle the Amps needed on a card with many TTL devices. So, no trace-between-pins fancy stuff on the Supply traces. Some cards used physical BUS Rails, to run the power/gnd supplies. -jgArticle: 114836
Hi! I've been trying to find some resources on the subject, but can't seem to find much. Has this been done? And to what extent? Is it doable, or is this a very hard task? If anyone could point me in any direction with more resources on this subject, I would be happy. In advance, thanks! -- ThomasArticle: 114837
The input clock and input bitstream is probably not synchronized most of the time, and I need to synchronize it.Article: 114838
In article <ep8rri$gbs$1@orkan.itea.ntnu.no>, Thomas Langås <tlan@stud.ntnu.no> wrote: >Hi! > >I've been trying to find some resources on the subject, but can't seem >to find much. Has this been done? And to what extent? Is it >doable, or is this a very hard task? 'General Number Field Sieve' is more a system than a task, simply breaking down the task of factoring a big number into implementable chunks is quite a job. The place to look is probably the SHARCS conference reports (Special- purpose Hardware for Attacking Cryptographic Systems): http://www.ruhr-uni-bochum.de/itsc/tanja/SHARCS has links to the slides for the 2005 and 2006 conferences, the VAMPIRE project of ECRYPT is source of much of the funding. As far as I know, the status is: * people have implemented ECM on large FPGAs, it's faster than a P4 but not faster-per-dollar * the designs people have proposed for lattice-sieving and linear algebra are all special-structure hardware with a structure very different from FPGAs, particularly in terms of memory per logic-element; it's not clear they could be helpfully fitted into FPGA. In any case they tend to propose rather peculiar external memory configurations (huge fast memories plus large extremely-fast memories) so you'd have to build costly custom boards before being able to test anything. * to do anything very interesting is likely to require hardware costs and engineering effort well beyond the casual. TomArticle: 114839
Hi Lancer, Lancer wrote: > I want to install uClinux on a Spartan 3 XC3S1000. > Now I need auto-config.in file to compile uClinux distro! > But...How to generate this file "auto-config.in"? > What I need? > I'm using EDK 8.1i sp2 on Windows XP. Take a look at developer.petalogix.com - there are quick start guides, complete documentation, tutorials and all sort of things to get you going. If you take a look at the MSS file in some of the reference designs we provide (e.g. S3E-1600 or -500 boards), you'll see how the "OS" section defines which memory device to use, the IO peripherals and so on. The auto-config.in file is generated during the EDK project build phase (libgen). Then there is a petalinux helper script called petalinux-copy-autoconfig that automatically copies it across from the EDK HW directory into the correct place in the uClinux SW tree. One thing to note, Windows is not a supported environment for building Microblaze / uClinux systems. It may be one day, but for now you'll need a Linux box or virtual machine to build the embedded Linux software. Regards, Regards, JohnArticle: 114840
The beauty of IDELAY is that you do not need any super-fast clock like the previous post implies. There really is no need to have multi-millisecond delays. You can increment or decrement IDELAY as fast as you want. Your acquisition time is governed by how long it takes you to make a decision. For 500 ms you must have evaluated many thousand bits before you ventured a small change. It's entirely your decision. If you are in a hurry, you could be thousand times faster. Peter Alfke On Jan 24, 4:13 pm, Bill <-...@-.com> wrote: > The input clock and input bitstream is probably not synchronized most of the time, and I need to synchronize it.Article: 114841
Bill wrote: > The input clock and input bitstream is probably not synchronized most of the time, and I need to synchronize it. If the data and clock aren't synchronized most of the time, how is adjusting the delays going to help? Or do you mean "not aligning the sampling clock to the center of the bit" rather than "exact same frequency/bit rate, just an unknown phase?" Synchronous items are at the same frequency. Precisely. If there's a phase/freq modulation on one synchronous item, the same phase/freq modulation should be on the other. What are the data and clock rates you're working with? Is it a high speed application where the data is a constant bit rate but you only have a solid asynchronous clock to work from? Do you have multiple bits to synchronize? If so, I'll point out the App note.Article: 114842
hello every body, currently i am masters student working on the xilinx virtex II pro board (xupv2p). I have to design a daughter board with four telephone interfaces(slics from silver telecom, Ag1170) and a quad channel codec (National semi con's TP3094). The daughter board is supposed to connect to the development board through the 100 pin hirose connector provided on the board. The above mentioned CODEC requires 50mA of current at 5V and each SLIC requires 1A in the worst case at 3.3V. I need help about the power supply of the daughter board. Can the power supply present on the development board deliver such huge current. If not how much current can it deliver or do i have to design a separate power supply for the daughter board. Please help me on this issue Thanking you all yashuArticle: 114843
On 2007-01-23, bgshea <bgshea@gmail.com> wrote: > So, I ask Martin, as he posted a method of using build scripts, if you > could even if in part, post some of what you use, that might benefit > the community here. I would certainly build on those scripts and post > them back. Hi, I wrote some Makefiles that we use in a course here. The entire lab skeleton is actually available for download but I have uploaded just the Makefiles to my homepage if you are interested: http://www.da.isy.liu.se/~ehliar/stuff/ It is not perfect but it works ok for me and most students in the course seem to think so as well :) They have been tested in both Linux and cygwin. I wrote the Makefiles for the following reasons: * Since they are text based, revision control is easy * We can avoid the (for now) unstable Project Navigator * Building a project will not spew lots of temporary files in the project directory. (They will end up in the synthdir directory.) The Makefile has been tested with ISE 8.1 and 8.2. I also have a small shell script which I use to build small projects where I haven't bothered to create a Makefile. That is also available on the web page. It is heavily inspired by the Makefile mentioned above. Some things which would be nice to be able to handle: * VHDL libraries (not everything should end up in work) * Don't recompile all files when starting a simulation target * Mixed VHDL/Verilog in the Makefiles Tips and tricks for these Makefiles will be gratefully received :) I know that they are a bit ugly at the moment. /AndreasArticle: 114844
anesserm wrote: >> Only if you disable logic optomizations in your synthesis tool....which in >> most cases is generally 'not' what you want to do. PLL (Altera), DCM >> (Xilinx) or re-examining the design as to why you think you need a delayed >> clock is a better approach. > > Is there a way to fool the optimizer? > Sometimes you can put a "keep" attribute on the intermediate signals. But this has to be a very bad way of doing things: your design will probably not work on a different device, may be sensitive to temperature, supply voltage, moon's phase, etc.Article: 114845
Does Xilinx microkernel (xilkernel) support for Condition Variables in Pthread?. That is, can I use code such as: pthread_cond_init pthread_cond_wait Thanks for your help. Pablo Ant=FAnezArticle: 114846
Hi Steve, first of all, I appreciate your comments. I think I can say that actual Xilinx employees with an insight reading and posting here is really a "feature" most of us appreciate. :) steve.lass@xilinx.com wrote: > Actually, for the 9.1i release, feature freeze was in June 2006 and the > release to manufacturing was in December. We spend about 6 months fixing bugs > and improving quality. Then why do you release the first service pack days after the software? Why not just push back the release for a few weeks and ship something that is usable right away? I can't comment on other customers, but in our case it's not like we're desperately waiting for new ISE releases. It's not like we're waiting for those new features (because we usually don't have any idea what these new features might be, except the usual promised 30% increase in speed). It's not like we're waiting for bugs to be fixed... we have our workarounds, because we can't just wait until Xilinx fixes it, we need a solution now. It really is of no importance or relevance to us when a new ISE is coming out. When it's there, it's there, and we'll give it a try to see what's been changed/improved, hoping that some of the issues I had with earlier versions are resolved. As stated in my earlier post: I know of no other EDA software vendor who handles the release cycle like Xilinx does (and Xilinx didn't always do it like that either). And you really can't claim other vendors don't have the same problems with dependencies between different products and 3rd party software etc. > Yes, 7.1i had a new database and 8.1i had a new ProjNav GUI. The > database was created in 1990 and needed to be rewritten and so did the > GUI. I agree. The switch to QT (or whatever it is you're using now) was long overdue and made the GUI finally usable under Linux (be gone, WindU!). > It's not as simple as saying we will release when its ready because of other > dependencies. We need to make sure all of our other software products > (ChipScope, PlanAhead, System Generator, EDK, etc.), all of our IP, and > 3rd party tools all work together. Yes, you have to, but they don't. A new EDK version is usually not released for weeks or months after the corresponding ISE, so in most cases I can't use the latest ISE anyway because it won't work with my older EDK. Same applies for some IP (like MiG, for example): Those usually don't work right away as well, but they will be released sometime later in a version compatible with the latest ISE (BTW, the later IP-updates are a friggin' 600MB in size, helloooo?). So in what way does the fixed (and too early, quality-wise) release date help the integration of other products, IP and 3rd party tools? > Defining a release date and sticking to that > date is the best way to accomplish this. So instead, we define a feature > freeze date. If a feature can't be done by that date, it gets pushed to the next > release. I don't really understand this. Feature freeze date, yes. But why a fixed release date? Just to compare, look at the Debian Linux project (or any other bigger open source project). There's a feature freeze date, and a projected release date. At the feature freeze date, there's a certain number of release-critical bugs, and a number of not-so critical bugs. The release date usually will be pushed back until the number of release-critical bugs drops below a certain threshold, or is 0. Only then is it more or less guaranteed to work when it's released. I had assumed it is similar at Xilinx, but with a release date fixed well in advance, this can never work. I realize that software can never be bug-free, but that's beside the point. Why release a software that you *KNOW* has a bunch of critical bugs (you already have the first service pack ready!), just so the release date fits your regular release cycle? 3rd party tools as well as your other products and IPs are being worked on long before ISE is released, so the actual release date is of no relevance to those either. > I agree with all of this. To be honest, no customers told us they were using > partial reconfig in ISE 4 - 7, so we did not make it a priority. Well, I did. John Williams initiated a whole separate mailing list just for the topic. The subject regularly pops up in this very newsgroup. So you can't say noone told you. But I guess noone "important" told you, since all the people who used it until very recently were students or researchers, not high-volume-customers. But I totally understand that, this is not meant to be critizism. I guess it's pretty complicated to implement it in the software, and you can't expect a huge company doing all the work to fix it just for a handful of academic customers. Again, this is not meant to be sarcastic, I wouldn't do it any other way if I were in charge at Xilinx. The thing that bugs me is just that if it's not a priority for you to fix, why not just tell people? From ISE4 through ISE7, I was told "This is going to be fixed in the next service pack/release", but it never was. And after every new release, I invested a couple of days "porting" my designs to the new software, only to find out that it's still not working. A lot of time I could've spent smelling the roses or hugging trees or generally doing something useful if only I would've been told what's up right away. > Don't be shy about reporting bugs to us and don't > complain about bugs not being fixed if you don't report them. Most of the time I run into known problems. I first check your website and find that someone else has already reported it and "it will be fixed in the next service pack". But if you say duplicate reports might help prioritizing things, I'll start reporting. > Steve Lass > One of those Marketing guys. I apologize if my post read like I had something against marketing. :) It's just my experience that priorities and ways of thinking simply differ between "techies" and "marketing". I see it in our projects, too. Sometimes we have to implement features that are complete nonsense that no customer will ever use, but it looks good in the brochure and the competition has it in their brochures as well, so it's gotta be implemented; just in case a crazy customer decides to check if the brochure is totally accurate (which occasionally does happen)... I've had some interesting (and funny) chats with engineers from the competition at trade shows about the very same subject, and it's the same everywhere. The problem is that the people who decide which product will be bought often aren't "techies" and hence rely only on the brochures to compare, so it's gotta be in there. The question is who started it in the first place, who put it in the first brochure. :) And I'm not so sure how many of the new features are actually things customers need or want. I can't imagine any customer requesting the format of the project files to be switched to binary, or requesting the feature to send detailed information about my designs to Xilinx after synthesis... And I don't think a lot of customers need the "feature" of a new ISE release for christmas every year. cu, Sean -- My email address is only valid until the end of the month. Go figure what the address is going to be after that...Article: 114847
Eric Smith <eric@brouhaha.com> writes: > Martin Thompson <martin.j.thompson@trw.com> writes: >> The best development environment I have ever used for Xilinx devices >> is Emacs (with vhdl-mode) and a command-line build script :-) > > I do my editing in Emacs, but I despise vhdl-mode. I normally use > the GUI for everything but editing. > Interesting - could you say any more about what makes vhdl-mode so bad? My experience has been more of people thinking Emacs sucks, but they wish their editor did all that vhdl-mode does! Thanks, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 114848
Hi, I'm working on a V4FX design that contains cryptographic primitives. To secure the system against an expected threat, it is necessary to produce a different seed for every session. The seed doesn't have to be random nor unpredictable, but the same seed should never be used more than once. The system contains non-volatile storage for the purpose of generating a non-repeating seed. However the storage is external to the V4FX. An attacker could isolate the V4FX and make it repeat a seed by replaying the external stimulus (as recorded from a previous session). To counter this threat, I wish to mix the externally acquired seed with on-chip generated "randomness". That would result in a different seed even during a stimulus replay attack. I know that chips are designed to behave as repeatable as possible, and I'm asking for quite the opposite. But at least I want to try, given that even a small amount of entropy can discourage an attack. For example I'm thinking about an oscillating combinatorial loop, sampled during the regular clock events. I expect the output would vary (at least a little bit) with temperature, supply voltage and perhaps moon phase. What other V4FX resources could be (mis)used for this purpose? I'd like to use two or three unrelated methods. If you have any suggestion or experience, I'd highly appreciate your input. Regards, MarcArticle: 114849
On 25 Gen, 02:26, John Williams <jwilli...@itee.uq.edu.au> wrote:
First of all, thanks for your reply (and sorry for my english, I'm an
italian student...)
> Take a look at developer.petalogix.com - there are quick start guides,
> complete documentation, tutorials and all sort of things to get you going.
...but petalogix provide petalinux documentations, isn't it?
> If you take a look at the MSS file in some of the reference designs we
> provide (e.g. S3E-1600 or -500 boards), you'll see how the "OS" section
> defines which memory device to use, the IO peripherals and so on.
I've downloaded examples at this link:
http://www.petalogix.com/resources/reference_designs/xilinx
> The auto-config.in file is generated during the EDK project build phase
> (libgen). Then there is a petalinux helper script called
> petalinux-copy-autoconfig that automatically copies it across from the
> EDK HW directory into the correct place in the uClinux SW tree.
>
> One thing to note, Windows is not a supported environment for building
> Microblaze / uClinux systems. It may be one day, but for now you'll
> need a Linux box or virtual machine to build the embedded Linux software.
I'm using Slack 11 machine to build uClinux, and Win XP SP2 machine
with Xilinx tools to build Microblaze project.
When I begin a project, I specify the repository path
(edk_user_repository) that I've downloaded there:
http://www.petalogix.com/resources/downloads/uclinux-bsp (BSP uClinux
package)
Then I build my Microblaze (for my Spartan 3 XC3S1000) e then I specify
in "Software Platform Settings" the uClinux OS.
Then I launch the libgen, and always I obtain this error message:
"ERROR:MDT - ERROR FROM TCL:- uclinux () - ERROR :: No MAIN_MEMORY
peripheral or
START/SIZE parameters specified
while executing
"error "ERROR :: ${msg}""
(procedure "do_manual_memory_setup" line 14)
invoked from within
"do_manual_memory_setup $config_file $os_handle $param_prefix
$config_prefix"
(procedure "do_memory_setup" line 14)
invoked from within
"do_memory_setup $config_file $os_handle "MAIN_MEMORY"
CONFIG_XILINX_ERAM"
(procedure "::sw_uclinux_v1_00_d::generate" line 22)
invoked from within
"::sw_uclinux_v1_00_d::generate 42422920"
Copying Library Files ...
ERROR:MDT - Error while running "generate" for processor
microblaze_0...
make: *** [microblaze_0/lib/libxil.a] Error 2
Done!"
What does it means?
Thank you very much
Regards
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