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
If it really were that lucrative, I would expect the position to be already filled! Austin Franklin wrote: > > > Consultants or FPGA Designers (Field Programmable Gate Array) will be > > involved with designing Programmable Logic Chips, otherwise known as > PLD's. > > These PLD's make up a high density field of gates called FPGA > Architectures. > > The FPGA designers will be involved with designing a "gate array" which > is > > an unfinished chip... > > Now, do you REALLY think someone would be qualified to do this job if you > had to explain this to them...especially like this? -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26551
Austin,
Obviously this is a headhunter or a human resources person that posted
this. (S)he probably had some input from a manager or engineer, and they
had to decipher that input, the end-result being a menage-a-trois of
buzzwords. This poster is probably not technically inclined.
-Simon Ramirez, Consultant
Synchronous Design, Inc.
"Austin Franklin" <austin@darkroo99.com> wrote in message
news:01c03a2b$fe9869a0$e602f7a5@drt1...
> > Consultants or FPGA Designers (Field Programmable Gate Array) will be
> > involved with designing Programmable Logic Chips, otherwise known as
> PLD's.
> > These PLD's make up a high density field of gates called FPGA
> Architectures.
> > The FPGA designers will be involved with designing a "gate array" which
> is
> > an unfinished chip...
>
> Now, do you REALLY think someone would be qualified to do this job if you
> had to explain this to them...especially like this?
>
>
>
Article: 26552PDA DEVELOPERS - San Jose ASIC, FPGA, Windows Device Drivers Pre-IPO firm in San Jose area needs several developers for new modules and components to be developed for use with wireless PDA devices. This is a new technology and a 'fresh paint' - clean canvas' opportunity for you! Hardware engineers should have 3 years design experience in FPGA and ASIC. Software engineers should have 2 years development experience - on Windows device drivers and be proficient in C. We want to hire you immediately! Our salary range is from $80K to $125K plus other financial opportunities - based upon the depth of your skills and the breadth of your experience. We are interested in persons living in the Bay Area only. We prefer to offer permanent employment but will consider contractors. U.S. citizenship or work permit required. We will sponsor visas of persons living in the Bay Area. Recruit EXpress, our search firm, will pay you a $3,000.00 bonus if you are hired - or if the persons you refer to them are also hired for our openings. We have six openings. Call or send your resume to Rex or Howard Frankel, at Recruit EXpress (713) 666-1001 .... or fax (713) 666-9993. Their email is: REX@RecruitEXpress.com or HOWARD@RecruitEXpress.comArticle: 26553
In article <ee6e536.-1@WebX.sUN8CHnE>, "Walter Haas" <walter_haas@pmc-sierra.com> wrote: > I'm using the PCI core from Xilinx, and I'm having some problems when I try to synthesize with Synplify Pro. > > This problem comes in two parts: > > 1) Because the core is a Black Box, Synplify doesn't know that it has it's own pads and especially it's own Global Clock. I usually have to edit out the pad and buffer it instantiates for the core from the EDF netlist, and that > usually works. It's a pain in the ass though, and I only seem to see it sporadically. Anyone know the cause? > > 2) The output (and globally buffered) clock from the PCI core is a clock I use extensively in my design. However, because Synplify doesn't know that it's globally buffered, it inserts more buffers all over the place, which in turn makes the Xilinx Skew analysis puke. Anyone know how to solve this? > > This posting is mirrored on the xilinx general newsgroup, as well as news.synplicity.com, on the synplicity.synplify. I'm a bit of a newbie when it comes to newsgroups... > > Cheers, > > Wally > In my PCI core based design I use FPGA Express. I have been following Xilinx's Implementation Guide, which indicates that it is necessary to include in my FPGA Express project two behavioral HDL files describing the core in addition to my synthesisable design files. That works without any problems. The NGD2VHDL's search path includes the actual location of the core .xnf files, so they are properly inserted in the design. --Yury Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26554
Ray, Unless Dallas is doing something that they are not showing in all of their data sheets and app notes, they guarantee that each and every part in the one wire family has a unique serial number. To the best of my knowledge, you can not order parts with the same number. They have a portion of the number which they will set to a given value to indicate you as a customer, and 8 bits indicate the device type. But the rest of the number, 48 bits IIRC, is always unique. But I am pretty sure that you can't use this as security in an FPGA, even if you tailor each bit stream to match the SN. The problem is that the one wire part can be duplicated very easily in a very inexpensive microP. In fact, I think you can get the microP cheaper than the one wire part!!! Ray Andraka wrote: > > you can order many with the same number. Part of the serial number is a > manufacturer ID that is unique to a customer. The rest is specified by the > customer. The problem with a DS2401 is that it is trivial to capture the serial > number, and then that is easy to duplicate with a CPLD. The timing spec on > those is pretty loose to make sure they work in your application. It is easy to > duplicate the timing within the tolerance of the part. > > Dan wrote: > > > > Hi, > > > > This security method can be broken by replicating the serial number. > > > > How much more secure would it be to not only check the serial number but > > also check the timing. For example: read it a bit too slow and a bit too > > fast and expect it to fail. If it passes, it must be a copy stored in some > > other device with different timing ? > > > > Does every purchaser of the DS2401 get a unique number ?? How could this be > > ?? > > > > If I buy 100 and later buy another 100 how will they have the same serial > > number ?? > > > > How would they know how many to produce with each number ? > > > > Makes it sound like each one is unique. This means every FPGA board must be > > reprogrammed to look for a unique number. Is this the case ? > > > > Dan > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com or http://www.fpga-guru.com -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. 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: 26555
Thanks Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26556
See also Brian Dipert's new article on PLD design security in EDN, "Cunning circuits confound crooks", http://www.ednmag.com/ednmag/reg/2000/10122000/21df2.htm. Jan Gray, Gray Research LLCArticle: 26557
Hi, Thanks for the answer, I now understand the problem better : while the mailbox flag reset pulse is in progress and this can be pretty long, it will miss the rising edge of the clock. It could work if a quite long delay (>40 ns) is observed from the time the mailbox is found empty to the leading edge of the pulse writing new data. looks like the whole synchro described in the 74F552 data sheet that I was trying to duplicate is somehow flawed. I've made my own little mailbox, and it seems to work much better, read and write clock being completely independent and edge triggered (CLR is no more used except as a global reset). Delay from reading the flag to either reading/writing the next data (the one you mentionned as being tREC in the '552 data sheet) is now 1 FD delay + 1combinatorial delay + routing, and output should be glitch free (only 1 input of the XOR changes at a time). Schematic diagram : http://www3.sympatico.ca/erv/mailbox.gif Simulated behavior (various illegal condition tested, always behaved as expected) : http://www3.sympatico.ca/erv/mailbox_sim.gif (write data supposed valid on the rising edge of W) Is here a better, standard solution to design a mailbox ? Thank you for pinpointing the problem and taking time to explain it ! Best regards, Eric. BTW, do you know about schematic libraries of little logic circuits for such common functions that would prevent re-inventing the wheel over and over ? ------------------------------------------------------------------------ rickman wrote: > Eric Montreal wrote: > > Your answer is interesting to me, because you both state that there are no reasons > > why it would not work, but at the same time, you suggest that I should better stay > > away from it. > > Looks like a kind of race condition between reason and doubt, and it's what most > > peoples (including me, else I would not have asked !) seem to think about such designs. > > > > A point in your answer that I don't completely get what you mean by "it all depends on > > how you are using the part" ? > > > > Do you refer to variable conditions such as voltage, temperature, lot to lot variation or > > to routing delays or large output loads degrading the pulse waveform ? > > My caution of using a design like this is not in the ability of such a > design to mimic the behavior of the chip, but rather a caution in how > you use the design just as I would caution you in how you use the chip. > > Part of the problem is the uncharacterized elements that you are working > with which will prevent you from having good data on the maximum width > of the generated reset pulse. This will prevent you from knowing the > maximum frequency of operation. After all, the internal FF reset pulse > must be gone a certain amount of time before you can set it again with > the clock. > > But I have not done a detailed analysis of your circuit or of any of the > timing issues. I will leave that to you since you seem capable. In > general you seem to understand the issues (temp, voltage, etc...). > > My main concern is that this circuit will be hard to test, simulate and > may give unexpected results depending on just how you use it in the > larger circuit. It not only has limitations in how you implement it, but > it has limitations in how you can use it. I guess my main concern is the > recovery time from rising edge of OExx to the rising edge of CPx when > CEx is asserted (tREC in the data sheet). This will be very poorly > characterized in your FPGA since this is determined by the max width of > the reset pulse which is determined by all the unknown stuff like the > routing, etc... > > So if you are running slow and your other circuits are synchronous, you > can likely work with this. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > 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: 26558
I am looking for a Core for the TI C31 DSP. Does anybody know where I can buy this Core ? Thanks Andreas ------------------------------------------- Andreas Kirchgraber // Andreas.Kirchgraber@vs.dasa.de -------------------------------------------Article: 26559
Georg Acher wrote:
> A bit OT, but it may help:
> I haven't actually tried it with this particular Synopsys version, but KDE can move
> windows with <ALT>+<Button1> and resize them with <ALT>+<Button3>, this can be adjusted
> in the KDE Control Center under Windows/Mouse. A window frame is not necessary, it works
> even with the shaped windows of xeyes.
Gee, it works!
Thanks, Georg. Some solutions are so trivial... ;-)
Lars
--
Address: University of Mannheim; B6, 26; 68159 Mannheim, Germany
Tel: +(49) 621 181-2716, Fax: -2713
email: larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/
Article: 26560
On Fri, 20 Oct 2000 04:19:07 GMT, Eric Montreal <ervNOSPAM@sympatico.ca> wrote:
>Hi,
>
>Thanks for the answer, I now understand the problem better :
>while the mailbox flag reset pulse is in progress and this can be pretty long, it will miss
>the rising edge of the clock. It could work if a quite long delay (>40 ns) is observed from
>the time the mailbox is found empty to the leading edge of the pulse writing new data.
As with most flag/mailbox type applications, there is the assumption that there
is the equivalent of a token that is passed back and forth between two domains,
in your case the "writer" and the "reader" . It is important that each domain
not touch the data until it has the token, and should not pass the token back
until it has finished with it (either completed the write or read operation).
In your case the owner of the token is indicated by the state of the FF
in your first design, and the output of the XOR in your second design.
The tragic problem of using the asynchronous reset for passing the token
in one of the two directions is that it must meet some minimal pulse width
to guarantee that the reset occurs. To calculate the delay, you must use
the minimum delay of the various delay elements, and your use of a slew
rate limited output certainly was novel. (the permanently enabled input
latch would have always been trimmed, so that would have been
problematic). Unfortunately the real silicon is probably not at its very
best and so the typical delay would have been longer. As Rick Collins
pointed out, there then arises the issues of recovery time, since the
write side will be ignored during the reset pulse, and for a little time
more.
What you really want is a flipflop with two edge triggered clock pins.
>looks like the whole synchro described in the 74F552 data sheet that I was trying to duplicate
>is somehow flawed.
Yep. It is a sucky design.
>I've made my own little mailbox, and it seems to work much better, read and write clock
>being completely independent and edge triggered (CLR is no more used except as a global
>reset). Delay from reading the flag to either reading/writing the next data (the one you
>mentionned as being tREC in the '552 data sheet) is now 1 FD delay + 1combinatorial delay
>+ routing, and output should be glitch free (only 1 input of the XOR changes at a time).
>
>Schematic diagram :
>http://www3.sympatico.ca/erv/mailbox.gif
>
>Simulated behavior (various illegal condition tested, always behaved as expected) :
>http://www3.sympatico.ca/erv/mailbox_sim.gif
>(write data supposed valid on the rising edge of W)
Your circuit is one of that I have seen many times (which is good, because it
means great minds think alike) and I have used it several times my self. This
circuit was in fact used in the PAL22IP6 from MMI (at the time a wholly owned
subsidiary of AMD) in 1988, and made the cover of Electronic Design magazine
on July 14, 1988. Unfortunately the claims for it included getting rid of
metastability (it doesn't, it just pushes it somewhere else).
More recently, this circuit appeared in Xilinx's XCELL magazine this month, on
page 54. (Fall 2000 issue, #37.) Although it has yet to appear on the Xilinx
web site, the author (from Memec Design Services) has had it available
at his web site for several months.
http://www.memecdesign.com/resources/guides/Flancter_App_Note.pdf
>Is here a better, standard solution to design a mailbox ?
There are lots of solutions. This one is fairly good.
But you must still be careful with it. We will assume that your reader and
writer are in different clock domains (otherwise you wouldn't be using this
circuit). As such, each side will be looking at the output of the circuit when
it does not have the token (i.e. waiting). When the token is passed (the
circuit toggles to the other state), the leading edge of the transition
occurs in the other clock domain, and cannot be reliably used directly
to initiate state changes, as there is the very real probability of setup or
hold time violation. This can be reasonably dealt with by following the
circuit with a two stage synchronizer, for each domain (total of 4
flip flops.). In the Memec article, two of these are shown in their figure
4, for the SYSCLK domain. I believe they should have also shown
two more for the uP domain. Let me clarify for your application:
The output of the XOR feeds the D input of two flipflops, one
clocked by the W domain clock, and the other clocked by the R
domain clock. The output of the W domain FF feeds a second FF
also clocked by the W domain clock, and the output of this second
synchronizing FF can then be used in the W domain. Likewise,
the output of the first R domain synchronizing FF feeds a second FF
clocked by the R domain clock, and its output can be used in the R
domain. This adds two cycles of latency in transfering the token, but
it is necessary to minimize metastability issues. So the whole circuit
is 6 FFs and an XOR and an inverter. FFs are cheap in an FPGA, so
its not like this is expensive.
>Best regards,
>Eric.
>
>BTW, do you know about schematic libraries of little logic circuits for such
>common functions that would prevent re-inventing the wheel over and over ?
Unfortunately the only book I regularly refer to is the 1973 TTL applications
handbook (out of print for about 25 years), much of which is still relevant
in todays high speed logic designs. My copy is autographed by the editor,
Peter Alfke.
========================
Philip Freidin
Mindspring that acquired Earthlink that acquired Netcom has
decided to kill off all Netcom Shell accounts, including mine.
My new primary email address is philip@fliptronics.com
Please update your address book, sorry for the inconvenience
Article: 26561I need to provide 24 TTL I/O lines. Each signal must be able to be set to an IN or an OUT (micro control through FPGA register). When set to OUT, I need the ability to sink 20mA (ish). This (and other) is the reason I've gone for Spartan-II. Anyway, they are really cheap. <eml@riverside-machines.com.NOSPAM> wrote in message news:39ed83ab.12538305@news.dial.pipex.com... > On Sat, 14 Oct 2000 11:12:09 +0100, Rick Filipkiewicz > <rick@algor.co.uk> wrote: > > >Jonas Thor wrote: > > > >> Hello! > >> > >> I have a follow up question. Do you know of any 3.3V <-> 5V integrated > >> translaters around? I can do the translation with a few discrete > >> componentents but I rather use a IC. Any hints??? > >> > >> / Jonas > >> > > > >The best way is to use parts generically called ``QuickSwitch'' from the > >company that first made them [now owned by IDT]. These are basically a bunch > >of pass transistors that have the characteristic that the resistance > >increases as the voltage on the driving size approaches the device's VCC. In > >effect they clamp the output side to about VCC - 0.7. For our 3.3V conversion > >we power the 5V parts from a 3.9V supply. You can now get 3.3V versions which > >we are about to use in the same way to get LVTTL <-> SSTL2 conversion. > > > >These parts have the huge advantage that they add almost no delay - about > >250ps or so - in the transition range of 0 -> 3.0V where Ron stays at about > >10R. > > > >The best place to look for this stuff is probably Pericom's web site. > > Also, the additional power supply is easier than it might seem. You > can just use a diode to drop your 5V to ~4.3V, and power your > QuickSwitch off that. I prefer an active diode, ie. a transistor and a > resistor. You can get 8-bit bidirectional switching with just a > transistor, a resistor, and something cheap like a QS3244. > > EvanArticle: 26562
> For a the guy who wants to copy your design exactly, it is easily
> done. You can make it harder by using unmarked or custom markings
> on the device, and requiring the device to interact with other
> elements in the system that may be harder to copy the board design
> (like a micro with an embedded instruction store).
You should think about what you are trying to protect.
If you are concerned about bitwise copying of your FPGAs than a marking
really should be sufficient. If the market penetration of the forged
designs is that low that you can not find them, then they do not hurt
your profits very much, and it is not worth going after them anyway.
When they start hurting your sales it should be easy to find them.
If you implemented a well known algorithm I can not imagine a competitor
doing the very cumbersome process of reverse engineering just to be
able to use your design tricks and architechture decisions.
Someone with manpower and knowhow to do this propably could outperform
your work with a redesign.
So, what is left:
New algorithms invented by you and secret parts of known algorithms,
such as decryption keys.
Especially for the latter paranoid protection could be useful.
But, as Nick pointed out, that's almost impossible to achieve.
There is - expensive - equipment that can read the content of SRAM
cells. This would even break Xilinx Virtex-II DES approach.
CU,
Kolja
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 26563With enough $ you can get anything you want :-) Anyway, my point was that it doesn't provide much if any security rickman wrote: > > Ray, > > Unless Dallas is doing something that they are not showing in all of > their data sheets and app notes, they guarantee that each and every part > in the one wire family has a unique serial number. To the best of my > knowledge, you can not order parts with the same number. They have a > portion of the number which they will set to a given value to indicate > you as a customer, and 8 bits indicate the device type. But the rest of > the number, 48 bits IIRC, is always unique. > > But I am pretty sure that you can't use this as security in an FPGA, > even if you tailor each bit stream to match the SN. The problem is that > the one wire part can be duplicated very easily in a very inexpensive > microP. In fact, I think you can get the microP cheaper than the one > wire part!!! > > Ray Andraka wrote: > > > > you can order many with the same number. Part of the serial number is a > > manufacturer ID that is unique to a customer. The rest is specified by the > > customer. The problem with a DS2401 is that it is trivial to capture the serial > > number, and then that is easy to duplicate with a CPLD. The timing spec on > > those is pretty loose to make sure they work in your application. It is easy to > > duplicate the timing within the tolerance of the part. > > > > Dan wrote: > > > > > > Hi, > > > > > > This security method can be broken by replicating the serial number. > > > > > > How much more secure would it be to not only check the serial number but > > > also check the timing. For example: read it a bit too slow and a bit too > > > fast and expect it to fail. If it passes, it must be a copy stored in some > > > other device with different timing ? > > > > > > Does every purchaser of the DS2401 get a unique number ?? How could this be > > > ?? > > > > > > If I buy 100 and later buy another 100 how will they have the same serial > > > number ?? > > > > > > How would they know how many to produce with each number ? > > > > > > Makes it sound like each one is unique. This means every FPGA board must be > > > reprogrammed to look for a unique number. Is this the case ? > > > > > > Dan > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com or http://www.fpga-guru.com > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > 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 -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26564
Might be easier to recommend something if you stated your requirements. ;>) Domagoj wrote: > Hi, > I'm looking for Virtex E development boards. I had a look on > http://www.xilinx.com/products/protoboards/protoboards.htm > but couldn't find any company offering what I'm looking for. > > Any recomendations ? > > Thanks. Regards, > > ------------------------------------------- > - Domagoj - > - Domagoj@engineer.com - > -------------------------------------------Article: 26565
OK, this is just too hard to let pass by. See comments inserted below: Edwin wrote: > Our client is looking for FPGA(Field Programmable Gate Array) designers to > work on a major effort to become the embedded technology supplier of choice > for the world's leading telecommunications and networking companies. Wow! That's quite a goal! Can I buy some of their stock? > The > project is part of the effort to utilize FPGA designers Another lofty goal - utilizing FPGA designers :-) This may be harder than the first one. > to help develop a > new line of CPU boards, communication interfaces such as T1/E1 spans or fast > serial ports) and protocol subsystems that can be sold off the shelf to > customers What a novel idea! Boy, this sure is ground breaking stuff! Maybe these guys are going to invent COTS just like Mr. Gore invented the internet. > so that their internal engineers and designers can utilize these > platforms that will be used to develop chips Hang on, are these development tools or end products? > to be used in mobile phones and > telecommunications equipment. > > > Day-to-Day Responsibilities: > > Consultants or FPGA Designers (Field Programmable Gate Array) will be > involved with designing Programmable Logic Chips, otherwise known as PLD's. I wonder if he knows what PLD stands for? > > These PLD's make up a high density field of gates called FPGA Architectures. Hmm, better check with XILINX and Altera to see if they are aware of this. > > The FPGA designers will be involved with designing a "gate array" which is > an unfinished chip with electronic components that have not yet been > connected. Oh, maybe when they say FPGA designer, they mean actually designing the FPGA itself! > The designer will complete the chip by designing and adhering > the top metal layers which provide interconnecting pathways. What do they use for that? An arc welder? Super glue? > Once these > chips are designed, then they will be turned over to manufacturing for mass > production. If its so mass, wouldn't they be ASICs? > These chips will make up final products such as CPU boards, > communication interfaces, and protocol subsystems that will be used in the > telecommunications industry. So, the FPGA designer designs a chip which is mass produced and then used on your other boards?? Wonder what that "FP" stands for in FPGA?? > > There are a total of 9 groups for that have anywhere from 4 to 14 FPGA > designers and Hardware Engineers that are working on the 3 major products > for different customers. Submitted candidates will be placed in groups that > need the most help. That seems like a novel management approach. Put people where they are needed the most. I'd better write that one down so I don't forget it. > This is a cross functional project environment. Yeah, you're working with anywhere from 36 to 126 FPGA designers. Sounds pretty cross functional to me. > > Candidates will always work under a principal engineer. Uh-oh. Sounds like trouble. > FPGA designers will > track their performance and product development with Microsoft Project that > will be reported to the head engineer. What! You want an FPGA designer to use Microsloth Project? Oh well, at least they get to track their own performance. Who's the head engineer? Is he the guy who picks which programming head we get to use? > > > Essential Skills: > > Power PC Power PC? I never thought of that as a marketable skill, although I guess have years of experience plugging in my PC. > PCI Hardware and Software > VHDL > Embedded Hardware Design > 3 years experience in the industry > > Plus Skills: > > View Logic (Schematic Capture Product) > Simulation Experience (Signal Quality or Timing Simulation experience) > UNIX Experience > Telecom Experience (T1/E1 Interfaces) ---- Ron Huizen BittWareArticle: 26566
Hi, Philip Freidin wrote: > On Fri, 20 Oct 2000 04:19:07 GMT, Eric Montreal <ervNOSPAM@sympatico.ca> wrote: > >Hi, > > > >Thanks for the answer, I now understand the problem better : > >while the mailbox flag reset pulse is in progress and this can be pretty long, it will miss > >the rising edge of the clock. It could work if a quite long delay (>40 ns) is observed from > >the time the mailbox is found empty to the leading edge of the pulse writing new data. > > As with most flag/mailbox type applications, there is the assumption that there > is the equivalent of a token that is passed back and forth between two domains, > in your case the "writer" and the "reader" . It is important that each domain > not touch the data until it has the token, and should not pass the token back > until it has finished with it (either completed the write or read operation). > I use it for a bi directional link between a PC (printer parallel port interface) and a target microcontroller and both poll the status flag in software (timing is thus not too critical). > > In your case the owner of the token is indicated by the state of the FF > in your first design, and the output of the XOR in your second design. > that's how it works. > > The tragic problem of using the asynchronous reset for passing the token > in one of the two directions is that it must meet some minimal pulse width > to guarantee that the reset occurs. To calculate the delay, you must use > the minimum delay of the various delay elements, and your use of a slew > rate limited output certainly was novel. (the permanently enabled input > latch would have always been trimmed, so that would have been > problematic). You're right, is there a way to prevent such trimming (if the delay element is used, this should not happend) ? Even now that I dropped the '552 design, I will keep this pulse generator in my bag of tricks, despite it's limitations (consumes a lot of power, generate unpredictable and not unit to unit repetable EMI interference, mostly with bonded pads) it might save the day in the future. > Unfortunately the real silicon is probably not at its very > best and so the typical delay would have been longer. I don't like relying on silicon being slow, reminds me PC loop based delay programming when peoples designed as if a PC would never be more than 2 to 3 times a 5 Mhz 8088 ! In facts the design relied on the delay element, because it's the only part of the Spartans that have a specified minimum delay. (more complete specification, including max delay would be nice). The "slew rate limited" output was more an attempt to limit EMI and increase safety margin than the main delay, because min delay for it is not specified and highly capacitive (thus package/pin location) dependent. > As Rick Collins > pointed out, there then arises the issues of recovery time, since the > write side will be ignored during the reset pulse, and for a little time > more. That's what I discovered reading his reply ! > > > What you really want is a flipflop with two edge triggered clock pins. > > >looks like the whole synchro described in the 74F552 data sheet that I was trying to duplicate > >is somehow flawed. > > Yep. It is a sucky design. > I finally realised it ... > > >I've made my own little mailbox, and it seems to work much better, read and write clock > >being completely independent and edge triggered (CLR is no more used except as a global > >reset). Delay from reading the flag to either reading/writing the next data (the one you > >mentionned as being tREC in the '552 data sheet) is now 1 FD delay + 1combinatorial delay > >+ routing, and output should be glitch free (only 1 input of the XOR changes at a time). > > > >Schematic diagram : > >http://www3.sympatico.ca/erv/mailbox.gif > > > >Simulated behavior (various illegal condition tested, always behaved as expected) : > >http://www3.sympatico.ca/erv/mailbox_sim.gif > >(write data supposed valid on the rising edge of W) > > Your circuit is one of that I have seen many times (which is good, because it > means great minds think alike) and I have used it several times my self. This > circuit was in fact used in the PAL22IP6 from MMI (at the time a wholly owned > subsidiary of AMD) in 1988, and made the cover of Electronic Design magazine > on July 14, 1988. Unfortunately the claims for it included getting rid of > metastability (it doesn't, it just pushes it somewhere else). > Damned, I already prepared myself for nobel prize ;-) In facts, it's just a stripped down FIFO controller (2 saturated counters + comparator). The discussions around metastability often remind me discussions with peoples who believe they just discovered *the* trick that would make multi level marketing work, and can't get why it never will ... > > More recently, this circuit appeared in Xilinx's XCELL magazine this month, on > page 54. (Fall 2000 issue, #37.) Although it has yet to appear on the Xilinx > web site, the author (from Memec Design Services) has had it available > at his web site for several months. > > http://www.memecdesign.com/resources/guides/Flancter_App_Note.pdf > Thanks for the link, it's very interresting, even if it somehow pisses me off ;-) BTW, the author would equally dislike your reference to the 1988 EDM article. > > >Is here a better, standard solution to design a mailbox ? > > There are lots of solutions. This one is fairly good. > > But you must still be careful with it. We will assume that your reader and > writer are in different clock domains (otherwise you wouldn't be using this > circuit). As such, each side will be looking at the output of the circuit when > it does not have the token (i.e. waiting). When the token is passed (the > circuit toggles to the other state), the leading edge of the transition > occurs in the other clock domain, and cannot be reliably used directly > to initiate state changes, as there is the very real probability of setup or > hold time violation. This can be reasonably dealt with by following the > circuit with a two stage synchronizer, for each domain (total of 4 > flip flops.). In the Memec article, two of these are shown in their figure > 4, for the SYSCLK domain. I believe they should have also shown > two more for the uP domain. This figure 4 is an almost perfect illustration of my app, except the microcontroller side gets the flag by polling instead of int. This way, the data is (single stage) latched when the register is accessed. I can't do better, since I don't have access the processor's clock. However, since the communication can be over a long cable, there are provisions for retransmit at the higher level (software). The omission of the synchroniser in the interrupt generation could be just that, or it could be a sign that they rely on the glitch suppression circuit that is present in most processor's interrupt line circuitry. > Let me clarify for your application: > The output of the XOR feeds the D input of two flipflops, one > clocked by the W domain clock, and the other clocked by the R > domain clock. The output of the W domain FF feeds a second FF > also clocked by the W domain clock, and the output of this second > synchronizing FF can then be used in the W domain. Likewise, > the output of the first R domain synchronizing FF feeds a second FF > clocked by the R domain clock, and its output can be used in the R > domain. This adds two cycles of latency in transfering the token, but > it is necessary to minimize metastability issues. So the whole circuit > is 6 FFs and an XOR and an inverter. FFs are cheap in an FPGA, so > its not like this is expensive. > one of the reasons peoples (like me) who discover FPGA want to put them everywhere ;-) > > >Best regards, > >Eric. > > > >BTW, do you know about schematic libraries of little logic circuits for such > >common functions that would prevent re-inventing the wheel over and over ? > > Unfortunately the only book I regularly refer to is the 1973 TTL applications > handbook (out of print for about 25 years), much of which is still relevant > in todays high speed logic designs. My copy is autographed by the editor, > Peter Alfke. > I did the same (Fairchild databook), but hit the wrong number (74F552) ! I would be glad to use & contribute to a website containing schematic libraries of "invented weels" if such a thing existed (the model is already proven to work for software "objects") ... have a nice day, Eric.Article: 26567
Ron Huizen <rhuizen@bittware.com> writes: > > > > > > Essential Skills: > > > > Power PC > Power PC? I never thought of that as a marketable skill, although I > guess have years of experience plugging in my PC. He probably meant PowerPC, as in MPC7400(*). (*) No, that's not AND-gates, it's a proecssor. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 26568
On Thu, 19 Oct 2000 13:26:09 -0700, Andy Peters <"apeters <"@> n o a o [.] e d u> wrote: >Muzaffer Kal wrote: >> >> Ray Andraka <ray@andraka.com> wrote: >> >> >I don't think there is such a thing as neutral ground when it comes to that >> >subject. It is more like religion. That said, I use VHDL because it gives me >> >more control for getting the design to exactly what I want. >> Ray, >> would you like to expand little bit on what things VHDL does better >> for you ? > >Here's my take on it. I had a Verilog refresher yesterday. > >VHDL forces you to think more about what you're trying to accomplish. >It's verbose, but by being verbose, things are clearly specified. > >Also, Verilog gives you enough rope to hang yourself. For instance, it >allows you to connect things (vectors, ports, etc) with mismatched >sizes. Another way of looking at it; Verilog more closely resembles C, while VHDL resembles academically designed programming languages like Modula-2 or Ada. Verilog users prefer Verilog because of its resemblance to C; I prefer VHDL for precisely the same reason! ;-) - BrianArticle: 26569
Hello, I am looking for precisions regarding the "number of logic levels" figure provided in the PAR clock performance report. Specifically I was wondering what is exactly considered as a "logic level": is it the number of primitive(such as MUXCY, XORCY or LUT) in the path ? or is it the number of logic cells delay (considering that a logic cell is a LUT+its assocaited carry logic)?Article: 26570
As people have pointed out, there is no 100% solution to protection. You can make it harder. The FPSLIC AVR+FPGA will soon come out in a multichip package where the configurator is inside the package without visibility of the bitstream. You can program the part and you can erase the part. Not sure how verification works though! While it is not perfect, you cannot easily read the contents without opening up the package and even then you have to use advanced equipment. -- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel Sweden "Yu Chen" <yuchen@edson.ee.ualberta.ca> wrote in message news:8sn8vg$pd4$1@rover.ucs.ualberta.ca... > > Hi, there, > > I'd like to know more about this topic: > How safe is the algorithm which is implemented using Altera's products? I mean, in case someone less got the FPGA(or ASIC)with the algorithm coded in it and he wanted to steal the algorithm, how much effort is needed for him to get the algorithm or just duplicate another FPGA( or ASIC) with the same function? We are thinking about using Altera's product to protect our own algoithms from being stolen. Please also let me know where I could get more information about this. > > Thank you in advance. > Yu Chen >Article: 26571
TRCE counts the number of primitives the signal passes through between registers. So yes, each carry chain element counts as a logic level in this context. Steven Derrien wrote: > > Hello, > > I am looking for precisions regarding the "number of logic levels" > figure provided in the PAR clock performance report. > Specifically I was wondering what is exactly considered as a "logic > level": is it the number of primitive(such as MUXCY, XORCY or LUT) in > the path ? or is it the number of logic cells delay (considering that a > logic cell is a LUT+its assocaited carry logic)? -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26572
In article <d_ZH5.2863$Z75.8018@nntpserver.swip.net>, Ulf Samuelsson <ulf@atmel.spammenot.com> wrote: > As people have pointed out, there is no 100% solution to protection. > You can make it harder. The FPSLIC AVR+FPGA will soon come out in a > multichip package where the configurator is inside the package > without visibility of the bitstream. You can program the part and > you can erase the part. Not sure how verification works though! >While it is not perfect, you cannot easily read the contents without >opening up the package and even then you have to use advanced equipment. One observation: Opening up and probing a set of leads on a multichip module should be easier than opening up and probing for a set of eeprom bits or write once or laser programmed ROM bits within a single chip. I'd personally wonder about the reason for the multichip module format, it seems like pretty expensive and exotic packaging. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 26573
yuryws@my-deja.com wrote: > > Need to create UCF constraints to cover the following scenario: > > 1. 16 bits are being clocked on the falling edge of CLK. > 2. 16 bits are being clocked on the rising edge of CLK. > 3. Data is valid 6 ns before and 6 ns after every CLK edge. > 4. Shortest time between CLK edges is 25 ns. > 5. Data and the clock come into Xilinx (Spartan XL) through input pads. > 6. CLK is fed through a non-clock pad. > > So, the circuit is: > > CLK @ non-clock pad---IBUF---BUFGLS--->FF > Data @ pad------------IBUF-------------FF Put a period constraint of 25 ns on CLK. Put an OFFSET constraint on the data pins. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 26574
Tom Burgess wrote: > > Discontinuation notice here: > http://www.xilinx.com/partinfo/notify/pdn0007.htm > > Looks like everything but the XPLA3 family goes. > Last time buy April 27/01. I like how the recommended replacement for the 22V10 is the 9536. OK, so the replacement chip has three times the amount of logic. What if I don't need all of that logic? I guess Lattice/Vantis still does 22V10s and 16V8s. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u
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