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
Rickman wrote: > This sounds like a good excuse for me to read a few books on > cryptography. I have been waiting for an excuse to do this for a long > time. Rick, Definitely check out the book Applied Crypto by Bruce Schneier (he can also be found at http://www.counterpane.com). In the book there is a fairly large section on LFSR's and their use in Cryptography. > I know that DES is not a simple algorithm to implement in hardware. But > by doing things in a bit serial manner and using CLB RAMs as much as > possible, do you have any idea how small it can be made? Even if only 1 > K bits per second can be produced, this would be enough to use in an > application like this. Check out my web page at http://www.free-ip.com and go to the cores section. You'll find the VHDL source to a DES core. In short, DES isn't small and doesn't lend itself well to a bit serial implementation. It certainly won't fit into a CPLD. There are two types of encryption: block and stream cyphers. DES is a block cypher because it takes a 64 bit block and encrypts it all in one shot. A stream cypher is, well, for a bit stream. The simplest stream cypher would be an XOR between the data stream and the output of an LFSR-- of course there are good and bad LFSR's to use for encryption... David Kessner davidk@free-ip.comArticle: 22401
Guys, I looked and Synplify seems to be giving me a garden-variety IBUF (not an IBUFG) for my input which I want to tie to a pin supporting global buffers (pin 213). So I don't think using "syn_noclockbuf" in Synplify will accomplish anything - I don't really have a clock buffer there, just a plain IBUF. Should I really have trouble using a garden-variety IBUF on a pin supporting global clocks? Do I need to make it a BUFGP somehow (like my typical input clocks are)? By the way, I am not using DLLs in any way. Matt Rick Filipkiewicz wrote: > David Bishop wrote: > > > I'm pretty sure that I've hit this one before with Synplicity. Put > > a "syn_noclockbuf" attribute on the pins that you are tying to IBUFGs > > in your design and it should work. > > > > In Synplicity, if you put a clock buffer on a pin, it will happily > > place another one right after it. I've filed this one as a bug. > > > > > 1. Shouldn't I be able to use global buffer pins for inputs > > > that do NOT require the global buffer? Recall that synplify > > > is instantiating the buffers for me. > > > > Yup, but it looks to me like the router is trying to use one of the > > IBUFGs as a BUFG, then is sees a pin already connected to it, and gets > > confused. It doesn't take much to blow the mind of Design Mangler 2.1i. > > > [snip] > > Yeah, its this sort of problem that has lead me to the decision to > instantiate all the global clock buffering stuff rather than let the synth > tool generate it. [snip]Article: 22402
Jon Kirwan wrote: > > On Mon, 08 May 2000 03:36:56 -0400, Jerry Avins <jya@ieee.org> wrote: > > >I'm hardly a CS expert, but I know a few and I'll check with them. I've > >been dealing with semaphores (though I mostly call them flags) for > >years, but I heard of "mutex" for the first time in this thread. This > >post in particular disabuses me of the notion that the name is akin to > >"mutate". It sounds like pointless (probably academic) jargon to me. Am > >I benighted? > > A semaphore maintains a count between zero and some specified maximum > value. The state of a semaphore is set to signaled when its count is > greater than zero, and nonsignaled when its count is zero. Used in > producer/consumer problems, for example. I suppose you are already > familiar with that. > > A mutex is a semaphore whose state is set to signaled (unlocked) when > it is not owned by any thread, and nonsignaled (locked) when it is > owned. A mutex is a semaphore set to 1, when created. It's a special > purpose semaphore designed to control access to a critical region of > code and data. If one or more threads are waiting on a mutex, exactly > one is released when the mutex is unlocked by the holder. > A flag in plain English then if the 'mutex' is binary? > It's the usage that decides which it is, I believe, and not the > details of the underlying implementation in the O/S. So from the > point of view of an operating system author, you might implement them > the same way. But they are put to different purposes. > > You can usually recognize a mutex when you see something like this: > > myobject.down(); > // serialized access to data > // ... > myobject.up(); > > Operations on a mutex travel in pairs, like nuns. This the above > example, myobject is a mutex. > > But if you see something like: > > myobject01.down(); > myobject.down(); > // serialized access to data > // ... > myobject.up(); > myobject02.up(); > > chances are that myobject01 and myobject02 are common semaphores. > > Maybe that's just academic, as you suggest, but that is still my sense > of the terms. > > JonArticle: 22403
"Clay S. Turner" wrote: > > Jerry Avins wrote: > > > > Rennie Allen wrote: > > > > > > OneStone wrote: > > > > > > > > 1. You list Binary Semaphore and the even less known term mutex yet omit > > > > the simplest term which is a flag or flag bit. > > > > > > Mutex is an "even less known term" than binary semaphore ? You must > > > move in very different circles than I. The pthreads standard (for which > > > there are at least three popular book titles) mentions little else in > > > the way of mutual exclusion mechanisms, besides mutexes; besides, what > > > could be a better name for a mutual exclusion mechanism than mutex ? > > Hello Jerry, > If you do multithreaded programming in windows, you will probably use > "mutexes." They been a part of windows for quite some time. The > computer word that gaulls me the most is "dereferencing" This is about > as bad as flammable and inflammable. As George Carlin says "either it > flamms or it doesn't!" > > Clay So in this case it either mute's or it speaks? Al P.S. can't get a version of windows for my micros thankfully. > > > > > > > Rennie > > > > I'm hardly a CS expert, but I know a few and I'll check with them. I've > > been dealing with semaphores (though I mostly call them flags) for > > years, but I heard of "mutex" for the first time in this thread. This > > post in particular disabuses me of the notion that the name is akin to > > "mutate". It sounds like pointless (probably academic) jargon to me. Am > > I benighted? > > > > Jerry > > -- > > Engineering is the art of making what you want from things you can get. > > -----------------------------------------------------------------------Article: 22404
Hi, I've just made a very easy design, which I want to implement in a Xilinx SpartanXL FPGA using a processor-bus. I'm using the Foundation Series F2.1i. The design is schematic-based. The implementation-file has been succesfully created (bit-file). When I upload the program to the FPGA, everything works fine (INIT remains low during programming and DONE becomes high after all bits have been send and after this at least four CCLK-cycles follow!). Also all timing-specs of programming the FPGA are applied. But when I measuring some output pins, I just don't see what I would expect. For example: I've used a clock-divider which divides the busclock (33 MHz) with 2048. Then I send this signal (16 kHz) to an output-pin. But when measuring this pin, I just see a low signal (not any clock-signal)! What options should I be awear off before implementing my design? Or could there be another problem? Has anyone a bit-file (which consists of a very simple schematic) which I can try to program in the Xilinx XCS30XL-4-PQ208? Maybe my software is invalid. I'm using a 3-months version. You cannot use the constraints manager in this version. Maybe I can't use some more properties of this software (without knowing it!)? It's the first time I'm working with an FPGA and programming it through a processor-bus. So could anyone give me any hints? Jurjen Boss (trainee)Article: 22405
Jon and Clay, Thank you for the patient explanation. I regret having flown off the handle; I hope that impatience with new things isn't a sign of old age! After all, "mutex" is no worse a coinage than "modem". Part of my impatience stems from my history of "just doing it", rather than following a formal paradigm. Much of my work has been done without any operating system at all (or with a simple ASOS* I wrote myself). I have written multitasking programs that way where the distribution of resources and tasks made deadlock possible, but the nature of the job made deadlock unacceptable. I wrote a mechanism to solve this dilemma. If it has a name, I'm unaware of it. It took me less time to design and implement it than it would have taken me to search the literature. Nevertheless, formalism has a valuable place. Perhaps I would profit more from it if I gave it more respect. Jerry ________________________ * Application-specific Operating System. I can coin words too! -- Engineering is the art of making what you want from things you can get. ----------------------------------------------------------------------- Jon Kirwan wrote: > ... > > A semaphore maintains a count between zero and some specified maximum > value. The state of a semaphore is set to signaled when its count is > greater than zero, and nonsignaled when its count is zero. Used in > producer/consumer problems, for example. I suppose you are already > familiar with that. > > A mutex is a semaphore whose state ... > > Jon "Clay S. Turner" wrote: > ... > > Hello Jerry, > If you do multithreaded programming in windows, you will probably use > "mutexes." They been a part of windows for quite some time. The > computer word that gaulls me the most is "dereferencing" This is about > as bad as flammable and inflammable. As George Carlin says "either it > flamms or it doesn't!" > > ClayArticle: 22406
Matt Gavin wrote: > Should I really have trouble using a garden-variety IBUF on > a pin supporting global clocks? Yes you will have trouble doing this, as I understand it this is not permitted by the hardware. --Phil.Article: 22407
All, We are programming multiple FPGAs with the same configuration on mulitple boards through a backplane. Because of many reasons, we are not going to tie all the INIT pins back to the PROMs, but just one. We are going to delay the INIT signal to the PROM to ensure that all of the FPGAs are ready to program. The problem is we don't know how long to delay it. So, if you had 1000 FPGAs (All Virtex E) and they all went through Vcc threshold at the same time, what would be the time delta between the first FPGA INIT signal going high and the last. We really only need the order. Right now we have a delay of 100ms built in which we believe is way more than enough....any thoughts. Yes, I know this is unconventional, but so are most things we do around here. TomArticle: 22408
Tom McLaughlin wrote: > > All, > We are programming multiple FPGAs with the same configuration on > mulitple boards through a backplane. Because of many reasons, we are > not going to tie all the INIT pins back to the PROMs, but just one. We > are going to delay the INIT signal to the PROM to ensure that all of the > FPGAs are ready to program. The problem is we don't know how long to > delay it. > > So, if you had 1000 FPGAs (All Virtex E) and they all went through Vcc > threshold at the same time, what would be the time delta between the > first FPGA INIT signal going high and the last. We really only need the > order. Right now we have a delay of 100ms built in which we believe is > way more than enough....any thoughts. > > Yes, I know this is unconventional, but so are most things we do around > here. > > Tom I looked in the virtex E datasheet and found on page 18 the timing spec Tpl listed as 100 uSec. The diagram shows this as the time from PRGM- going high to INIT- going high. So if you are willing to use a common PRGM- signal, then this number is defined. Otherwise I would guess that because you have not heard from anyone that this information is not provided (or possibly even measured) on Xilinx parts. My guess is that you would need to measure it yourself on a group of chips from different manufacturing lots. Then take the longest number you get and double it. I also would not count on the 100 mSec number unless you tested it as above. If you don't want to do the testing from multiple manufacturing lots, then as a part of system test, you might include multiple startup delay values. The test procedure would be to test with the shortest startup delay, doubling the startup delay each time the test fails. Once the startup is successful, you could double the startup delay once more to provide some safty margin. But even these approaches are risky. Although the chips in general get faster as the process is improved, if you are counting on an unspec'ed parameter, it might get changed because of a "bug" fix. For example, if they found a problem with the power up circuit, the fix might add some significant time to the startup delay. Then even if you had set the startup delay in system test, the unit might not be maintainable in the field. The tech changes a bad chip and now the system won't boot! To be safe, I would tie the PRGM- signals together and use that as a reset. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22409
Thanks for the answer!
Tom Burgess <tom.burgess@home.com> writes:
> While I appreciate that you are thrilled about the possibilities of RSFQ technology,
> I think that your initial request was unfortunately phrased, leading people to
> waste their valuable time supplying simple structure ideas...
Oh, sorry... My wording was probably misleading indeed, thugh I tried
to emphasize that what I needed was an idea for a PROGRAMMABLE
structure as in F_P_GA. Sorry again if I was not clear enough...
> O.K., so you REALLY need
> to use a couple thousand femtosecond gates in an interesting way, not really having
> anything to do with FPGAS. Given the high on/off chip speed ratio, prime number
> factorization or maybe high speed "ILOVEYOU" pattern matching might do,
Unfortunate time to ask questions via e-mail, huh? :)
> though to
> really wow the suits you will have to boot Apple II Basic and run VisiCalc :)
Yes, the simplest 16-bit processor with on-chip memory is what we promised
to do now, memory would not be large enough to stor VisiCalc though!
:) Maybe in the next version... I was thinking of a back-up plan for a demo.
>
> regards, tom
Paul
>
> Paul Bunyk wrote:
> >
> > Hello everyone! Thank you all for your replies!
> >
> > You all basically suggest the simplest experiments ann of which have
> > already been done. What I needed is an idea for "something" which requires
> > couple thousand gates (sponsor's limitation on the simplicity of the demo).
> >
--
("`-''-/").___..--''"`-._ UNIX *is* user-friendly, he is just very
`6_ 6 ) `-. ( ).`-.__.`) picky about who his friends are...
(_Y_.)' ._ ) `._ `. ``-..-' Paul Bunyk, Research Scientist
_..`--'_..-_/ /--'_.' ,'art by (and part-time UN*X sysadm)
(il),-'' (li),' ((!.-' F. Lee http://pbunyk.physics.sunysb.edu/~paul
Article: 22410
Thank you, Rick! This was kind of information I was lookig for.
Sincerely,
Paul
Rickman <spamgoeshere4@yahoo.com> writes:
> Paul Bunyk wrote:
> >
> > Hello everyone! Thank you all for your replies!
> >
> > You all basically suggest the simplest experiments ann of which have
> > already been done. What I needed is an idea for "something" which requires
> > couple thousand gates (sponsor's limitation on the simplicity of the demo).
>
> > By the way, another group here (well, two more people :) ) is
> > designing like 16-bit oversampling ADC chips with digital filters (run
> > now at about 15 GHz internal frequency) and DACs (including a real
> > cool device - voltage amplifier with exactly INTEGER gain - it's a
> > quantum technology, many weird things are possible). But for
> > prolitical reasons our demo should not resemble "just" a digital
> > filter, it should be programmable...
> >
> > Any further suggestions? :)
>
> If you are interesed in FPGAs with simple structures, then you might
> want to look at the Atmel 6000 family. The repeated logic element is a
> single FF with three gates and a tristate buffer. Of course there are
> muxes used to select the paths and SRAM to control the muxes. But this
> is a rather simple logic block compared to the other vendors. You might
> even get them to work with you and provide bitstream info so that you
> can use their software. This structure is very useful for systolic
> processing since it uses direct connects between cell neighbors.
>
> Or based on the signal processing devices being built by others in your
> company, you might want to build an NCO and/or a Digital Down Converter.
> If your circuits really run at multiple GHz speeds, then you could do
> the accumulators and filters in bit serial fashion to keep the circuit
> size down to 1 or 2 K gates. You might even be able to generate the sine
> and cosine as a calculation using the CORDIC (sp?) algorithm. Ray
> Andraka knows a lot about this. I believe he has some papers posted on
> his web site about it.
>
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> remove the XY to email me.
>
>
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com
--
("`-''-/").___..--''"`-._ UNIX *is* user-friendly, he is just very
`6_ 6 ) `-. ( ).`-.__.`) picky about who his friends are...
(_Y_.)' ._ ) `._ `. ``-..-' Paul Bunyk, Research Scientist
_..`--'_..-_/ /--'_.' ,'art by (and part-time UN*X sysadm)
(il),-'' (li),' ((!.-' F. Lee http://pbunyk.physics.sunysb.edu/~paul
Article: 22411Hallo, are there any high pin count ( around 220 usable IO pins) FPGA/CPLD available in Non-BGA package? Thanks for pointers. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 22412
I'm using the Xilinx Alliance 2.1i_sp6 FPGA Editor software to build a design Macro. When can I lock down the routing of my Macro? Do I lock it when I'm creating the macro (*.nmc) or do I lock it when I instantiate into a design (*.ncd). I'm finding that the timing of the macro instance in the design doesn't match the timing of the original macro. I thought that locking down routing would produce the same timing results. I'm using the exact same part when creating the macro and the design. -- NickArticle: 22413
In article <8f76nd$rp4$1@sun27.hrz.tu-darmstadt.de>, Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > Hallo, > > are there any high pin count ( around 220 usable IO pins) FPGA/CPLD > available in Non-BGA package? > > Thanks for pointers. > > Bye > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > It looks like some Xilinx XC4000E and XC4000XL devices are available in 304pin QFPs, with 256 I/Os. Check with Xilinx for real availability. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22414
J. Boss wrote in message <8f6qnq$6uhd5$1@reader1.wxs.nl>...
>Hi,
>
>I've just made a very easy design, which I want to implement in a Xilinx
>SpartanXL FPGA using a processor-bus. I'm using the Foundation Series
F2.1i.
>The design is schematic-based. The implementation-file has been succesfully
>created (bit-file). When I upload the program to the FPGA, everything works
>fine (INIT remains low during programming and DONE becomes high after all
>bits have been send and after this at least four CCLK-cycles follow!). Also
>all timing-specs of programming the FPGA are applied. But when I measuring
>some output pins, I just don't see what I would expect. For example: I've
>used a clock-divider which divides the busclock (33 MHz) with 2048. Then I
>send this signal (16 kHz) to an output-pin. But when measuring this pin, I
>just see a low signal (not any clock-signal)! What options should I be
awear
>off before implementing my design? Or could there be another problem? Has
>anyone a bit-file (which consists of a very simple schematic) which I can
>try to program in the Xilinx XCS30XL-4-PQ208? Maybe my software is invalid.
>I'm using a 3-months version. You cannot use the constraints manager in
this
>version. Maybe I can't use some more properties of this software (without
>knowing it!)? It's the first time I'm working with an FPGA and programming
>it through a processor-bus. So could anyone give me any hints?
Did you do a functional simulation on your design, to ensure that your logic
works as you expect?
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"A sufficiently advanced technology is indistinguishable from magic"
--Arthur C. Clarke
Article: 22415"J. Boss" wrote: > Hi, > > I've just made a very easy design, which I want to implement in a Xilinx > SpartanXL FPGA using a processor-bus. I'm using the Foundation Series F2.1i. > The design is schematic-based. The implementation-file has been succesfully > created (bit-file). When I upload the program to the FPGA, everything works > fine (INIT remains low during programming and DONE becomes high after all > bits have been send and after this at least four CCLK-cycles follow!). Also > all timing-specs of programming the FPGA are applied. But when I measuring > some output pins, I just don't see what I would expect. Well, I have a bit of experience with the XC9500 parts, but I'm just moving into the FPGA world, too. I did see some knowledge base articles on the correct settings for the clock source selection for programming to function correctly. But, DONE shouldn't go high unless the download blocks have passed the checksum, so it sounds like the programming was correctly loaded into the device. Is there some simply combinatorial signal you can check? My guess is that the internal clock is set up wrong, and is not taking the clock from the source you intend it to. JonArticle: 22416
Matt Gavin wrote: > > Running directed packing... > ERROR:xvkpu:19 - The symbol XTAL1200K.PAD failed to join a regular > I/O > component as required. The symbol has a constraint (LOC=P213) > that specifies > an illegal physical site for the component. Please correct the > constraint > value. > Problem encountered during the packing phase. I think you should look closely at the data book for the part. I think you are correct that global clock buffers can be used for user signals, but the XTAL pads are not the same as a normal global clock buffer, they are used to compose a crystal oscillator. JonArticle: 22417
Catalin Baetoniu wrote: > > Hi Jim, > > The context discussed here is that of an open core protection scheme for FPGAs. Something > that it is posted on a www page for all to see (including the potential copier) but is > still very hard to break if you do not know the key. While your approach is valid for a do > it your self protection good for your own use (if you really trust it) it is not good for > what we are discussing here. If I will use your system I want to be sure it works and you > will have to make it public. All your hidden tricks lose their advantage then. The system > must be strong by design not by hiding information. It doesn't have to be triple DES or > PGP but it must be hard enough, at least as hard as reverse engineering the FPGA > bitstream. I agree, a public source/private table(key) system is preferred. > > I would like to propose the following system: > > A 48-bit LFSR with the position of the taps public is loaded at reset with a secret > initial value. The 48-bit state is broken into 6 groups of 4 bits which pass trough six > look-up tables. The content of the look-up tables is also secret and is fixed (your key is > then 144 bits). The six look-up table outputs are xored together and are the only signal > output by the CPLD. There is no input except for the clock and the reset. The output of > the CPLD is both long enough to be captured, stored and played back in a copy of the > system and hopefully complex enough to defy analysis. Everything should fit in a 72 > macrocell CPLD and in less than 10 FPGA CLBs. This is actually very similar to what I had in mind - a combination of shifter and PROM/Tables ( a lot of our IP has this type of code, and I have often thought it woud be a dog to reverse engineer ) The only difference is whether you allow external, or self 'seed' of the shifter. I guess a public source version of this could allow users either option, or maybe more a seed select, than a seed load ( too open ). So, if we accept that this raises the bar sufficently on CPLD and handshake attack, that leaves just bitstream attack on the FPGA. There are potential weaknesses here :- a) If just one copy exists in FPGA, correlation of PROM to bitstream location starts to look simpler. A Hacker can get 100's of your bitstreams quite easily, plus generate their own reference ones. b) I am sure a std HDL compile ( common source code ) will tend to place cells in a similar bitstream order, again aiding hacking. For a) the design could 'fill' the spare space in the FPGA with multiple copies of this engine - now, many bits are changing. For b) the FPGA vendors would need to add a scramble place/route option, so that within a block, the CLBs change order, from compile to compile. > > If anybody wants to try to break this I can set up a challenge test. Send me an email, and we can discuss this further. - jgArticle: 22418
On Tue, 09 May 2000 01:10:00 +0930, OneStone <onestone@chariot.net.au> wrote: >A flag in plain English then if the 'mutex' is binary? A mutex is often just called a "binary semaphore" in my experience. Since you always perform a "down" on it before entering the critical region and always release it by performing an "up," afterwards, it's value is 0 or 1. It never goes above 1, so it's just "binary." But like any semaphore, the "test and set" must be atomic, even in multi-processor systems. I suppose that the term mutex might be applied to any specific implementation that guarantees "mutual exclusion," even message-based. But most of the use I've heard put to the term relates to this obvious, special purpose use of semaphores. So flag works for me, so long as the "flag" can be set and tested atomically and the purpose is understood. JonArticle: 22419
Acording to the Xilinx data sheet, Table 12 - "Power-up Timing Characteristics" The time to INIT going high is the later of 2mS from Power-on Reset occuring (VCC passing through some threshold), and 100uS from the Program signal going high. This is the time it takes for the internal config memory clearing to complete. If one trusted the data sheet, this value of 2mS for Tpor and 100uS for Tpl would be allowing for the slowest internal CCLK (which is 2.5MHz +45%, -30%, see table 10), and the largest Virtex device, since the clearing operation is done 1 frame per clock, using the internal CCLK (not well described in the Virtex data sheets, but the way it has been done in all previous Xilinx products ). So your 100mS seems conservative, and could probably be safely reduced to 10mS without problems. Good luck Tom, Philip In article <39107C12.E5926AA8@arl.wustl.edu>, Tom McLaughlin <tomm@arl.wustl.edu> wrote: >All, >We are programming multiple FPGAs with the same configuration on >mulitple boards through a backplane. Because of many reasons, we are >not going to tie all the INIT pins back to the PROMs, but just one. We >are going to delay the INIT signal to the PROM to ensure that all of the >FPGAs are ready to program. The problem is we don't know how long to >delay it. > >So, if you had 1000 FPGAs (All Virtex E) and they all went through Vcc >threshold at the same time, what would be the time delta between the >first FPGA INIT signal going high and the last. We really only need the >order. Right now we have a delay of 100ms built in which we believe is >way more than enough....any thoughts. > >Yes, I know this is unconventional, but so are most things we do around >here. > >Tom > > >Article: 22420
Jerry Avins wrote: > > I'm hardly a CS expert, but I know a few and I'll check with them. I've > been dealing with semaphores (though I mostly call them flags) for > years, but I heard of "mutex" for the first time in this thread. It's a contraction for "Mutual Exclusion Semaphore". Just a kind of lock to prevent re-entrancy in some critical section. -- Eric C. Weaver weav@sigma.net "Radio, that bar so low on the musical ladder you need a sump pump to keep your hairpiece dry" - BrancaccioArticle: 22421
Result of check: I asked a CS friend (he has a masters degree and is active in the profession) if he knew or could guess what a mutex is. He had a vague memory that it is a species of mosquito. Jerry -- Engineering is the art of making what you want from things you can get. ----------------------------------------------------------------------- Jerry Avins wrote: > > Rennie Allen wrote: > > > > OneStone wrote: > > > > > > 1. You list Binary Semaphore and the even less known term mutex yet omit > > > the simplest term which is a flag or flag bit. > > > > Mutex is an "even less known term" than binary semaphore ? You must > > move in very different circles than I. The pthreads standard (for which > > there are at least three popular book titles) mentions little else in > > the way of mutual exclusion mechanisms, besides mutexes; besides, what > > could be a better name for a mutual exclusion mechanism than mutex ? > > > > Rennie > > I'm hardly a CS expert, but I know a few and I'll check with them. I've > been dealing with semaphores (though I mostly call them flags) for > years, but I heard of "mutex" for the first time in this thread. This > post in particular disabuses me of the notion that the name is akin to > "mutate". It sounds like pointless (probably academic) jargon to me. Am > I benighted? > > JerryArticle: 22422
The Xilinx Spartan II and Vertex datasheets claims (and Mentor documentation backs it up) that: "Currently, LeonardoSpectrum does not infer dual port RAMs that read both read and write address." A dual port RAM has independent clocks and addresses which support simultaneous read from the same/different locations and simultaneous read/write to different locations. The possible interpretations seem to be: 1) LS does not infer dual port RAMs. 2) LS infers dual port RAMs but only one read is allowed at a time, ie either port A or port B. 3) #2 except restriction in place only when writing data. My best guess is #2. Thanks, AndyArticle: 22423
"Jerry Avins" <jya@ieee.org> wrote in message news:3917782C.97DB1182@ieee.org... > Result of check: I asked a CS friend (he has a masters degree and is > active in the profession) if he knew or could guess what a mutex is. He > had a vague memory that it is a species of mosquito. But is he active in multi-threaded programming under Windows NT or perhaps VMS? We've got plenty of people with their CS degrees at work, and only a small fraction of them could tell you what a mutex (or semaphore) is. Rumor has it that David uh... Cutler?, formerly of Digital/father of VMS/hired by Microsquish to architect Windows NT, calls the things "mutants" in NT because he didn't like the way they were implemented. ---Joel KolstadArticle: 22424
Did you do a functional simulation on your design, to ensure that your logic works as you expect? To ANDY: Yes, I did do a functional simulation and everything works fine! Well, I have a bit of experience with the XC9500 parts, but I'm just moving into the FPGA world, too. I did see some knowledge base articles on the correct settings for the clock source selection for programming to function correctly. But, DONE shouldn't go high unless the download blocks have passed the checksum, so it sounds like the programming was correctly loaded into the device. Is there some simply combinatorial signal you can check? My guess is that the internal clock is set up wrong, and is not taking the clock from the source you intend it to. To JON: That's also where I'm thinking of. But I've used the GCK-pin (P2 of the Xilinx XCS30XL) for the clock-signal and designed a IPAD, followed by a BUFG. The signal is divided by using a LogiBLOX-symbol. the output is then send to a OBUF, followed by an OPAD. For both PAD's have used the LOC-attribute in which I specify the pinlocation (e.g. the clock-pin = P2 and the output-pin is P160). I've also used the STARTUP-symbol, to which you can connect the clock-signal, this also doesn't work.
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