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
http://zone.ni.com/devzone/cda/tut/p/id/3953 http://www.cotorelay.com/html/reed_relays_9300-9400_series.htm Using surface mount and low current, the machine would be about the size of a refrigerator, and fairly slow, but workable. I doubt these small reed relays would even make a noise. Its the "fortune" rule. Someone, somewhere makes it, and does it modern. There are still buggy whips made somewhere, you just have to look. rickman wrote: > Grant Stockly wrote: >> >> I really want to build a computer from relays, and even priced out some >> nice ones on e-bay, but I am concerned about how long it would last >> before failing... > > One type of computer that might actually be interesting to build of > relays and operate would be a time piece. To keep the power > consumption down, you might use latching relays. The contain a > permanet magnet that holds the contact in either state and a pulse from > the coil is required to change the state. Each relay is then a FF. > The logic would be done by stringing relays in series or parallel to > form AND and OR functions (with or without inversions). You could also > use diodes to form the logic if you want to save some space. There are > some fairly minature relays available at around $5 or less. We are > using some latching RF relays at that price. They are about 15 x 10 mm > so a clock circuit might take up a square foot depending on the > density. It would also tick every second with major noises on the > minutes and hours. > > I am working on a relay controller circuit for an RF module and when I > do the test code, it will have a few options to sound out tap dancing > like music. That should prove interesting and entertaining! >Article: 112451
Hi, I am using aurora software to create a core to move data from the pc to xupv2p board to another xupv2p board and I am using Chipscope to monitor the signal. When I launch chipscope inserter and go to connect the signal names I can't figure out what names to use, there are so many of them, ie I don't know what most of them mean. Also, the aurora core creates a folder (examples) with three files (aurora_sample.vhd, frame_check.vhd and frame_gen.vhd), I assume frame generator is supposed to generate some data to be transferred between the two boards but I can't see it in chipscope. I used a pre-designed project and it showed me the data (tx_d_i_2 and rx_d_i_1), but when I use my design I do'nt see any data except when I open the pre-designed file (aurora_link_cs.cpj) into my design then I can see data. Can anybody tell me what to do here? I appreciate all help NathanArticle: 112452
http://web.cecs.pdx.edu/~harry/Relay/ Why anyone would use those big relays and point to point wiring is beyond me. http://www.vaxman.de/my_machines/phywe/pgr/pgr.html http://www.electronixandmore.com/project/relaycomputer/index.html What have we learned? There are people with WAY too much time on their hands :-) scott moore wrote: > http://zone.ni.com/devzone/cda/tut/p/id/3953 > http://www.cotorelay.com/html/reed_relays_9300-9400_series.htm > > Using surface mount and low current, the machine would be about the > size of a refrigerator, and fairly slow, but workable. I doubt > these small reed relays would even make a noise. > > Its the "fortune" rule. Someone, somewhere makes it, and does it modern. > There are still buggy whips made somewhere, you just have to look. > > rickman wrote: >> Grant Stockly wrote: > >>> >>> I really want to build a computer from relays, and even priced out some >>> nice ones on e-bay, but I am concerned about how long it would last >>> before failing... >> >> One type of computer that might actually be interesting to build of >> relays and operate would be a time piece. To keep the power >> consumption down, you might use latching relays. The contain a >> permanet magnet that holds the contact in either state and a pulse from >> the coil is required to change the state. Each relay is then a FF. >> The logic would be done by stringing relays in series or parallel to >> form AND and OR functions (with or without inversions). You could also >> use diodes to form the logic if you want to save some space. There are >> some fairly minature relays available at around $5 or less. We are >> using some latching RF relays at that price. They are about 15 x 10 mm >> so a clock circuit might take up a square foot depending on the >> density. It would also tick every second with major noises on the >> minutes and hours. >> >> I am working on a relay controller circuit for an RF module and when I >> do the test code, it will have a few options to sound out tap dancing >> like music. That should prove interesting and entertaining! >>Article: 112453
I am currently using the ISE 8.1 - you seem to use 8.2. Could this be the explanation for the errors? Anyway, I installed the newest available version now, and still have no success. rightclicking the *.ise opens the ISE, but I have no sources and have to add them manually again like before. It seems to be a challenge to get a Xilinx Environment run. (?) Well, when starting with Altera`s, 2 years ago, everything worked fine the first run (eval board board, first project, quartus ide etc). Hm.... Maybe I am a bit to lazy, or missed something important, or I am simply to strong on the Altera line to switch easily. In any case I am a bit disappointed, that there are no simple and working examples in a -> starter kit. Anybody else working with this kit ?Article: 112454
Hi, There are no BUFT in Virtex-4 because of their big delays. Use multiplexers instead. Best Regards On Nov 22, 5:21 pm, Koen Van Renterghem <Ih8teS...@intec.ugent.be> wrote: > Hello, > > I was just browsing the Xilinx Libraries Guide pdf in search of BUFT > component. However, it is not mentioned anymore in the 'Virtex 4 > Libraries Guide for HDL designs'. I was looking into them to optimize > wide muxes and a bus traversing the complete FPGA fabric. > Are tristates left out of the Virtex4? Is there an alternative? What > could be the motivation for such an architectural change? > > Best Regards, > Koen.Article: 112455
On 22 Nov 2006 04:58:55 -0800, "rickman" <gnuarm@gmail.com> wrote: >John Larkin wrote: >> On 21 Nov 2006 20:14:43 -0800, "rickman" <gnuarm@gmail.com> wrote: >> >> >John Larkin wrote: >> >> We just solved a nasty problem with this: >> >> >> >> A d-flop: D tied high; clocked from a pin, CE from internal gating >> >> logic. Its Q output drives a BUFG clock net buffer, and Q also feeds a >> >> delay line back into its own async clear. When the input pin rises, if >> >> CE permits, it makes a single clock pulse. Everything downstream is >> >> "synchronous" in that it's clocked from this gadget. >> >> >> >> The delay line is a chain of AND gates (with transparent latches >> >> enabled in the logic cells, just to add a little more delay), with >> >> each fed from the ff Q and also from the previous gate. This is a >> >> delay line with a fast discharge mechanism when its input goes low, so >> >> we don't have to wait for the 0 to propagate through, chasing the 1. >> > >> >How do you synchronize the input clock with the internal CE signal? If >> >it is not synchronized, couldn't you get nasty splinter pulses? >> >> The gate signal is totally async to the clock. We're sort of hoping >> that the output of the logic block is either going to go high or not. >> A metastability glitch within a Spartan3 flip flop is (optimistically) >> narrower than the inter-cell routing can propagate. We'll have to try >> that and see. I could put setup and hold time requirements on the >> trigger gate specs, and make it the customer's problem! >> >> >How do you control the timing of the delay line? Is the timing window >> >that you can work in pretty wide? >> >> The downstream logic has to work at 80 MHz max. So if we >> experimentally tune the BUFG output width to, say, 4 ns, we should >> have a pretty good margin both ways. Most silicon processes seem to be >> pretty stable these days. >> >> I suppose we could make the delay tunable through a register our uP >> could write, and we could check a test point now and then to make sure >> we have it right. Just a mux selecting delay-line taps would work. We >> only need to do this once in the product, and it's important, so this >> is worth some hassle. The trick is, I suppose, to only take risks when >> you really need to. > >I'm not sure I understand your problem, so I'll ask a few more >questions. What is the speed of the clock in the design? How often >does the internally clocked CE signal gate the external signal to >generate a clock pulse? If the external signal will not generate a >clock edge on every internal clock there might be an easier way to do >this that does not depend on timing delays. It can generate a clock >enable signal that is asserted on every other clock cycle. But this >may or may not work for your application. The product is a digital delay generator. Given a customer trigger, it generates four pulses, each programmable for delay and width from the trigger. There are three clock nets on the chip: 1. Trigger, qualified by a separate gate signal, firing this one-shot. This is the customer's TRIGGER input, any rate from 0 to 80 MHz. This drives a bunch of logic, including optional gate/countdown/burst logic, all of which starts... 2. A non-continuous delay-generator clock. Following the trigger, we start a gated 50 MHz oscillator that's used to time out 8 coarse delays in 20 ns ticks (rise/fall of each of the 4 outputs). Off-chip analog fine delays trim the actual edges to 10 ps resolution. This 50 MHz clock is phase-locked to... 3. A 40 MHz clock, from a TCXO. A digital PLL thing longterm locks the customer-triggered 50 MHz clock to the local 40 MHz crystal oscillator but keeps the 50 MHz thing phase-coherent to the customer trigger, so the delay outputs don't jitter. Given all these clocks, and all the signals making multiple passes on and off the chip, we're getting output jitters in the ballpark of 50 ps RMS, which ain't bad. Our bigger benchtop DDGs have jitter in the 8 ps range, but their critical paths are power-hogging PECL. Generating accurate, low-jitter delays from a random trigger, but with crystal-oscillator accuracy, is an interesting problem in general, and it's been approached a lot of ways. We think ours is nicely suited to implementing in an FPGA with minimal external stuff. Our main limitation seems to be on-chip crosstalk and maybe a bit of ground bounce. JohnArticle: 112456
Sylvain, Protecting IP is one issue. Providing a means for IP developers to be paid for the use of their IP is another problem (and different). Using multiple IP from multiple vendors, and all getting paid is yet a third problem. As you point out, today there are few good ways (really none) to do any of the above. There is AES256 encryption and decryption in V4 and V5 which provides a FIPS-140 compliant solution for the protection of the IP. But the encrypt/decrypt is not authentication, so it does not help you get paid for your work, it just keeps it a secret. In Virtex 5, we have provided for decrypting AND reconfiguration, so that you may load multiple encrypted bitstreams (all using the same key), but again, this does not provide a model for IP 'per use' payments. It does allow for secure crypto solutions for applications like SDR. It is a tough problem, and one we would like to solve (obviously). The use of physically unique coding function (known as PUF codes) would allow each device to uniquely be matched to a bitstream (only that bitstream can work with that device), but this requires each bitstream to be unique for that part. That doesn't help you, unless the customer emailed you their PUFs and AES256 key and you emailed back the matching (partical) bitstreams. Challenge response systems (like RSA) are very complex, and would use a lot of silicon. We would also need a battery backed local session key store of about 4 Kb. This is a topic where there is a lot of opportunity for innovations. Obfuscation (keeping a secret by keeping secrets) should never be considered secure, as paying someone in the parking lot is all it takes to crack it. Keeping your algorithm a secret is equally dumb, as most "clever" and "secret" functions are easily cracked (since they have had no serious peer cypto review). Anyone who claims security by obscurity is just ignorant (and dangerous)! Austin > Hello, > > I'm working for a company that sell FPGA IP in netlist form. > I'd like to protect theses IP as much as I can, to try to make > it as hard as possible to RE them. I know I can't possibly > fully protect them, but that doesn't mean it doesn't worth trying. > > I've already used the "secure netlist" option of the Xilinx tools, > but it's not that secure. Also, the net names stays the same. > So I'm looking at an obfuscating tool that would rename > all net/instances for me. And also other methods you might > know ? > > Thanks, > > Sylvain >Article: 112457
I tried the same tests setting the DCM to D=1 M=4, D=2 M=8 and setting the CLKIN_DIVIDE_BY_2 to TRUE then using D=1 and M=8. All seem to cause problems with the IDELAYCTRL. I then took the RF generator (via the PECL driver) and used it to drive the DCM. Running the RF generator at 200MHz and using the CLK0 to drive the IDELAYCTRL appears to work fine (delay per tap seems correct). Running the RF generator at 50MHz and driving the DCM but using D=1 M=4 and the CLKFX out does not seem to work. Running the RF generator at 100 MHz then using a D=1 M=2, CLKFX out appears to work. Running the RF generator at 200 MHz then using a D=2 M=2, CLKFX out appears to work. Austin had published a note about using a 66MHz clock with the DCM set to D=1 M=3 and having it work. "The Ref Clock may be supplied from any +/- 10% 200 MHz source, including the DCM CLKFX output. For example, if there is a 66 MHz clock, a M=3, D=1 will provide you with a ~ 200 MHz output on CLKFX. There is no need to be concerned with the jitter from the CLKFX, as the analog locked loop which controls the delay is effectively a PLL which filters out the high frequency jitter components (jitter on Refclk is attenuated when transfered to the data lines)." I tried this same test and it appears not to work (I see that same 200pS / tap). It seems to be related to how many multiplier stages used in the DCM. Has anyone else seen this?Article: 112458
"Koen Van Renterghem" <Ih8teSpam@intec.ugent.be> wrote in message news:ek1id8$nng$1@gaudi2.UGent.be... > Hello, > > I was just browsing the Xilinx Libraries Guide pdf in search of BUFT > component. However, it is not mentioned anymore in the 'Virtex 4 > Libraries Guide for HDL designs'. I was looking into them to optimize > wide muxes and a bus traversing the complete FPGA fabric. > Are tristates left out of the Virtex4? Is there an alternative? What > could be the motivation for such an architectural change? > > Best Regards, > Koen. The internal tristates have been gone for a while. Other dedicated resources do a better job even for extremely wide busses. Many designs didn't use the slower, dedicated tristates in the older generation parts so why keep designing the little-used functionality when the generic device provides a better solution? If you're using HDL, you can still implement tristate logic internal to your chip (assigning a driven value or z across your bits) and the synthesis will do the translation to multiplexers for you. No primitive needed. You may get an INFO or WARNING message depending on your synthesizer.Article: 112459
<spartanius@arcor.de> wrote in message news:1164209777.649517.273910@e3g2000cwe.googlegroups.com... > > I am currently using the ISE 8.1 - you seem to use 8.2. Could this be > the explanation for the errors? > > Anyway, I installed the newest available version now, and still have no > success. rightclicking the *.ise opens the ISE, but I have no sources > and have to add them manually again like before. > > It seems to be a challenge to get a Xilinx Environment run. (?) Well, > when starting with Altera`s, 2 years ago, everything worked fine the > first run (eval board board, first project, quartus ide etc). > > Hm.... > > Maybe I am a bit to lazy, or missed something important, or I am > simply to strong on the Altera line to switch easily. > > In any case I am a bit disappointed, that there are no simple and > working examples in a -> starter kit. > > Anybody else working with this kit ? I got the kit and just started modifying the existing demo. The unused pins that aren't included in the top level or .ucf don't cause me any problems. Heck, I even expanded upon the PicoBlaze code to do my own LCD stuff. It was quite a nice experience. I have the full .ucf if/when I need to add signals in my HDL and current .ucf. I used it in 8.1 and 8.2, various service packs. I liked the kit so much I got the 1600E version, too. - John_HArticle: 112460
John Larkin wrote: > On 22 Nov 2006 04:58:55 -0800, "rickman" <gnuarm@gmail.com> wrote: > > >John Larkin wrote: > >> On 21 Nov 2006 20:14:43 -0800, "rickman" <gnuarm@gmail.com> wrote: > >> > >> >John Larkin wrote: > >> >> We just solved a nasty problem with this: > >> >> > >> >> A d-flop: D tied high; clocked from a pin, CE from internal gating > >> >> logic. Its Q output drives a BUFG clock net buffer, and Q also feeds a > >> >> delay line back into its own async clear. When the input pin rises, if > >> >> CE permits, it makes a single clock pulse. Everything downstream is > >> >> "synchronous" in that it's clocked from this gadget. > >> >> > >> >> The delay line is a chain of AND gates (with transparent latches > >> >> enabled in the logic cells, just to add a little more delay), with > >> >> each fed from the ff Q and also from the previous gate. This is a > >> >> delay line with a fast discharge mechanism when its input goes low, so > >> >> we don't have to wait for the 0 to propagate through, chasing the 1. > >> > > >> >How do you synchronize the input clock with the internal CE signal? If > >> >it is not synchronized, couldn't you get nasty splinter pulses? > >> > >> The gate signal is totally async to the clock. We're sort of hoping > >> that the output of the logic block is either going to go high or not. > >> A metastability glitch within a Spartan3 flip flop is (optimistically) > >> narrower than the inter-cell routing can propagate. We'll have to try > >> that and see. I could put setup and hold time requirements on the > >> trigger gate specs, and make it the customer's problem! > >> > >> >How do you control the timing of the delay line? Is the timing window > >> >that you can work in pretty wide? > >> > >> The downstream logic has to work at 80 MHz max. So if we > >> experimentally tune the BUFG output width to, say, 4 ns, we should > >> have a pretty good margin both ways. Most silicon processes seem to be > >> pretty stable these days. > >> > >> I suppose we could make the delay tunable through a register our uP > >> could write, and we could check a test point now and then to make sure > >> we have it right. Just a mux selecting delay-line taps would work. We > >> only need to do this once in the product, and it's important, so this > >> is worth some hassle. The trick is, I suppose, to only take risks when > >> you really need to. > > > >I'm not sure I understand your problem, so I'll ask a few more > >questions. What is the speed of the clock in the design? How often > >does the internally clocked CE signal gate the external signal to > >generate a clock pulse? If the external signal will not generate a > >clock edge on every internal clock there might be an easier way to do > >this that does not depend on timing delays. It can generate a clock > >enable signal that is asserted on every other clock cycle. But this > >may or may not work for your application. > > The product is a digital delay generator. Given a customer trigger, it > generates four pulses, each programmable for delay and width from the > trigger. There are three clock nets on the chip: > > 1. Trigger, qualified by a separate gate signal, firing this one-shot. > This is the customer's TRIGGER input, any rate from 0 to 80 MHz. This > drives a bunch of logic, including optional gate/countdown/burst > logic, all of which starts... > > 2. A non-continuous delay-generator clock. Following the trigger, we > start a gated 50 MHz oscillator that's used to time out 8 coarse > delays in 20 ns ticks (rise/fall of each of the 4 outputs). Off-chip > analog fine delays trim the actual edges to 10 ps resolution. This 50 > MHz clock is phase-locked to... > > 3. A 40 MHz clock, from a TCXO. > > A digital PLL thing longterm locks the customer-triggered 50 MHz clock > to the local 40 MHz crystal oscillator but keeps the 50 MHz thing > phase-coherent to the customer trigger, so the delay outputs don't > jitter. > > Given all these clocks, and all the signals making multiple passes on > and off the chip, we're getting output jitters in the ballpark of 50 > ps RMS, which ain't bad. Our bigger benchtop DDGs have jitter in the 8 > ps range, but their critical paths are power-hogging PECL. > > Generating accurate, low-jitter delays from a random trigger, but with > crystal-oscillator accuracy, is an interesting problem in general, and > it's been approached a lot of ways. We think ours is nicely suited to > implementing in an FPGA with minimal external stuff. Our main > limitation seems to be on-chip crosstalk and maybe a bit of ground > bounce. I can't say I really understand what you are doing. Obviously how you are solving this problem is something that is too complex for a verbal description without diagrams and detailed explanations. But thanks for trying.Article: 112461
scott moore wrote: > http://web.cecs.pdx.edu/~harry/Relay/ > > Why anyone would use those big relays and point to point wiring is > beyond me. > > http://www.vaxman.de/my_machines/phywe/pgr/pgr.html > http://www.electronixandmore.com/project/relaycomputer/index.html > > What have we learned? There are people with WAY too much time on their > hands :-) This one is better than those: http://www.kilian-leonhardt.de/relaiscomputer/ He has it hooked to a typewriter for a terminal! In some of the sound clips you can hear it tapping out the answer! :) The thousand relays make some really neat sounds! GrantArticle: 112462
Pretty cool! If you read the updates on Harry Porter's machine he says he has Linux running on it! scott moore wrote: > http://web.cecs.pdx.edu/~harry/Relay/ > > Why anyone would use those big relays and point to point wiring is > beyond me. > > http://www.vaxman.de/my_machines/phywe/pgr/pgr.html > http://www.electronixandmore.com/project/relaycomputer/index.html > > What have we learned? There are people with WAY too much time on their > hands :-) > > scott moore wrote: > > http://zone.ni.com/devzone/cda/tut/p/id/3953 > > http://www.cotorelay.com/html/reed_relays_9300-9400_series.htm > > > > Using surface mount and low current, the machine would be about the > > size of a refrigerator, and fairly slow, but workable. I doubt > > these small reed relays would even make a noise. > > > > Its the "fortune" rule. Someone, somewhere makes it, and does it modern. > > There are still buggy whips made somewhere, you just have to look. > > > > rickman wrote: > >> Grant Stockly wrote: > > > >>> > >>> I really want to build a computer from relays, and even priced out some > >>> nice ones on e-bay, but I am concerned about how long it would last > >>> before failing... > >> > >> One type of computer that might actually be interesting to build of > >> relays and operate would be a time piece. To keep the power > >> consumption down, you might use latching relays. The contain a > >> permanet magnet that holds the contact in either state and a pulse from > >> the coil is required to change the state. Each relay is then a FF. > >> The logic would be done by stringing relays in series or parallel to > >> form AND and OR functions (with or without inversions). You could also > >> use diodes to form the logic if you want to save some space. There are > >> some fairly minature relays available at around $5 or less. We are > >> using some latching RF relays at that price. They are about 15 x 10 mm > >> so a clock circuit might take up a square foot depending on the > >> density. It would also tick every second with major noises on the > >> minutes and hours. > >> > >> I am working on a relay controller circuit for an RF module and when I > >> do the test code, it will have a few options to sound out tap dancing > >> like music. That should prove interesting and entertaining! > >>Article: 112463
Hi When using data cache in xilinx platform studio, to cache an external DDR memory(64MB) on the OPB bus and a BRAM block, I get some bad errors. The program runs without a hickup when the data cache is only enabled for the BRAM, but when enabled for the DDR memory, faulty data is read from memory. The data space cached is only the DDR memory and the BRAM, so no other hardware should be able the mess up the cache by changing the data on the other side of the cache. I have just enabled the caches with the lines: XCache_EnableICache(0x00000001); XCache_EnableDCache(0x80000001); I expected this to be enough, but I have also tried to invalidate every data cache line before running my program, but without any luck. What am I missing? The system is running on a Virtex4-FX12 PowerPC. -- Rune D. JørgensenArticle: 112464
Hey, programming hardvare is same on each attempt. Using euro connectors (JTAG connected to it for testing puuposes) . The difference between successfull and error message is the software only.... John Adair =EDrta: > Your symptoms suggest a JTAG chain problem and could be reflections on > the chain, poor power supply to JTAG head, poor head connections, > pickup of noise on JTAG. If you are using the flying lead set normally > attached to Cable III head do check the connectors of lead set. These > have a habit breaking eventually. Also check if the TDO line out of the > XC95144XL needs a pullup to operate correctly and it's value. Some > parts do and some don't. > > John Adair > Enterpoint Ltd. > > Jozsef wrote: > > Hello, > > > > as many people over this world, I have a problem. The problem is the > > connection beetween a CPLD and the WEBPACK ISE 8.2.03 software. > > Simptoms like very static: I have an Parallel Cable III, the ISE > > software, and a XC9500XL family CPLD. The Impact cannot recognise the > > CPLD, for example a simple XC95144XL showed five unknown device in the > > JTAG chain on automatic JTAG chain initialize. I' has been tried to add > > the device manually, but there is not accepted as a result, because > > Impact answers unknown device ID. I'm told each family because tried > > with xc9536XL, simptoms are same. > > The cable is OK, I using it to program other devices (for example, > > XC3S400) on everyday. > > On software side, tried an older software (Xilinx Foundation 4) to > > program these devices, that programs all without problems. > >=20 > > The question is what is the problem with ISE 8.2.03 ???Article: 112465
pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote: >> Rob, my best FPGA guy, has given up on using the Xilinx 8.2/sp3 IDE >> software... it's way too flakey. But he says the underlying chunks >> work fine from the command line, so he put together a "make" thing to >> process the chip we're working on. So it looks like the core >> fpga-crunching software was coded by people who know what they're >> doing, and the IDE wrapper (which runs in 90 megabytes of ram!) was >> coded by Windows programmers. > > Seems the GUI-mafia just love RAM.. :) > That's one of the laws of software: All programs expand to consume all available resources I remember implementing a RAM test in 34 bytes, and a 16x16 integer multiply in < 50 bytes. Cheers PeteSArticle: 112466
Sylvain Munaut <SomeOne@SomeDomain.com> wrote: > I'm working for a company that sell FPGA IP in netlist form. > I'd like to protect theses IP as much as I can, to try to make > it as hard as possible to RE them. I know I can't possibly > fully protect them, but that doesn't mean it doesn't worth trying. > > I've already used the "secure netlist" option of the Xilinx tools, > but it's not that secure. Also, the net names stays the same. > So I'm looking at an obfuscating tool that would rename > all net/instances for me. Brands X and A do this for the cores that they resell, so it can be done, but it might also cut your profit margin to zero. Consider distributing your stuff via a vendor IP program. > And also other methods you might know ? The only one I know of is dealing with people you trust and signing legally binding contracts. At the high end, customers are willing to pay for source code and support. -- Mike TreselerArticle: 112467
rickman wrote: > Pretty cool! If you read the updates on Harry Porter's machine he says > he has Linux running on it! I don't think any software ever "runs" on a relay computer... ; )Article: 112468
Thanks. Your post definitely explains why I have problems (or no problems) with certain slaves. Have a Great Thanksgiving! Daniel S. wrote: > Hi, > > I have been having fun with I2C for a while. If you read the I2C specs, > you will see that the same delays come up everywhere for any given bus > speed. > > For 400kbps, this magic number is 600ns: SCL and SDA pulses must be > 600ns wide minimum, a master should leave the bus idle for 600ns between > transactions, SDA-to-SCL edges for start/stop should be at least 600ns > apart, etc. > > Since the condition between your #2 and #3 should be a 'restart', there > should usually not be any extra delays needed there, other than the > usual 600ns SDA-to-SCL for start/stop conditions. Then again, many I2C > devices have quirks that must be dealt with on a case-by-case basis. > > The opencores I2C master is somewhat odd: it seems that its designer > forgot to provide some means of generating interrupts before the master > outputs the ACK bit when reading a slave. Without this, the host has to > divine whether or not the next byte received will be ACK'd. With that > interrupt (and freezing SCL), the host would be able to make this (ACK) > decision after receiving the byte. > > markus wrote: > > Hello > > > > For the I2C read, the step by step, the algorithm is: > > > > 1). write slave address+write bit > > 2). write register address > > 3). write slave addres+read bit > > 4). read > > > > After the end of step 2, and before step 3, you need to set the STA to > > indicate the real read. Note that STA is indicated by transition of > > HIGH to LOW on the SDA while SCL remains HIGH. I am wondering if there > > is minimum wait time between step 2 and beginning of step 3? > > > > Note that my design uses OpenCores' I2C (if it matters). Thanks. > > > > Happy Turkey Day, > > -M > >Article: 112469
Mike Treseler wrote: > Sylvain Munaut <SomeOne@SomeDomain.com> wrote: > >> I'm working for a company that sell FPGA IP in netlist form. >> I'd like to protect theses IP as much as I can, to try to make >> it as hard as possible to RE them. I know I can't possibly >> fully protect them, but that doesn't mean it doesn't worth trying. >> >> I've already used the "secure netlist" option of the Xilinx tools, >> but it's not that secure. Also, the net names stays the same. >> So I'm looking at an obfuscating tool that would rename >> all net/instances for me. > > Brands X and A do this for the cores that > they resell, so it can be done, but it > might also cut your profit margin to zero. > Consider distributing your stuff via a vendor IP program. > >> And also other methods you might know ? > > The only one I know of is dealing with people > you trust and signing legally binding contracts. > At the high end, customers are willing to pay > for source code and support. > > -- Mike Treseler When it comes to these things, it ultimately comes down to trusting customers and partners (backed up by a suitable contract, of course). If someone is determined to crack the IP, they will very probably do so. We both pay per unit for some things and get paid per unit for others. We don't do business any more with certain companies, shown in one particular case where they claimed they only sold 'x' units, but we found out (by coincidentally talking to their biggest customer) that they had sold many hundreds 'x'. Some might say the pricing was too high, but in that case they were free to ask for renegotiation of the contract or simply stop using the provided functionality - if they stopped, we got nothing (we were paid based on sold units), so we had plenty of motivation to look at it should that happen. No - Mike is right - do business with those you can trust. I know that's not necessarily easy for some companies and it can be quite a conundrum. Cheers PeteSArticle: 112470
"PeteS" <peter.smith8380@ntlworld.com> wrote in message news:Xr19h.59126$r4.34900@newsfe3-gui.ntli.net... > That's one of the laws of software: > > All programs expand to consume all available resources > > I remember implementing a RAM test in 34 bytes, and a 16x16 integer > multiply in < 50 bytes. I once wrote an Eratosthenes' prime number sieve using the video display as an array memory (on a 4K machine).Article: 112471
On Wed, 22 Nov 2006 20:28:11 GMT, "Homer J Simpson" <nobody@nowhere.com> wrote: > >"PeteS" <peter.smith8380@ntlworld.com> wrote in message >news:Xr19h.59126$r4.34900@newsfe3-gui.ntli.net... > >> That's one of the laws of software: >> >> All programs expand to consume all available resources >> >> I remember implementing a RAM test in 34 bytes, and a 16x16 integer >> multiply in < 50 bytes. > >I once wrote an Eratosthenes' prime number sieve using the video display as >an array memory (on a 4K machine). --- How high did it go? to 9? -- JFArticle: 112472
Hi, This is the second time I am posting to this group within a week, but I think that this necessitates another thread. (Through google groups my original thread can be accessed at http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/6f620f38f06a19df?hl=en) My problem is that I am trying to synthesize gate level combinational circuits that have a large number of signals. (I actually did not realize how large it was till Thomas and Andreas explained it to me in the previous thread.) My circuit probably uses around 40 K gates, but a lot more signals. From the discussion in my previous thread, I realized that the synthesis tools (I use XST) have/has problems with (1) large number of signals (2) large combinational paths I don't really mind the synthesis time - rather I am concerned that I run out of memory. (I hit 4 GB - and I don't have the 64 bit version.) I would also like to mention that as far as the number of gates is concerned, I am sure that my design would fit onto one FPGA, with a utilization of less than 50%. (Using the xc2v6000-4.) Does anyone have an idea how I can get this to synthesize? Partial Synthesis (i.e. synthesis of parts of my design separately) was suggested to me in my previous post, but I could not figure out how to do this in XST. (I can dump out the NGC files for different parts of my design - but how do I combine them?) If long combinational paths are an issue, is there a way to break up a long combinational path (i.e. add registers or latches etc.). I thought about latches - but then deciding where to insert the latches is a big question. (I don't mind compromising on timing if this is a factor of 2, 3 or even 10, but I don't want this running into a factor of 100's or 1000's.) Thanks to all those who may have some ideas. O.O.Article: 112473
"Antti" <Antti.Lukats@xilant.com> wrote in message news:1164200166.358021.84400@m73g2000cwd.googlegroups.com... > > BUG::: EDK 8.2 generates BMMs incompatible with ISE 8.2 > when BRAM blocks are consecutive. > if there is gap in address space then it all works. > > there is a workaround to manually fix the generated BMM files So they broke it in 8.2!!!! Are you talking about the AR 24296 for the fix? This is as ugly as it can only get :( I can't beleive this.... /MikhailArticle: 112474
Austin Lesea wrote: > Sylvain, > > Protecting IP is one issue. Providing a means for IP developers to be > paid for the use of their IP is another problem (and different). Using > multiple IP from multiple vendors, and all getting paid is yet a third > problem. > > As you point out, today there are few good ways (really none) to do any > of the above. Yes, preventing someone to loading the .bit else where is not really easy ;) > There is AES256 encryption and decryption in V4 and V5 which provides a > FIPS-140 compliant solution for the protection of the IP. Yes, but that's from the guy who provide the .bit perspective. To protect from a user of the final product. Here I'm more talking about the guys who receive the .ngc, prevent them to look inside it too easily. (I know a motivated attacker will succeed at looking inside but if it could take him more than 15 min that would be nice ...) Obfuscating the net name would be a good start, since without names and hierarchy, figuring out how a 10k slices IP work should take him a while. > Obfuscation (keeping a secret by keeping secrets) should never be > considered secure, as paying someone in the parking lot is all it takes > to crack it. Keeping your algorithm a secret is equally dumb, as most > "clever" and "secret" functions are easily cracked (since they have had > no serious peer cypto review). The point here is not a crypto algorithm at all. Every body knows how to do it (video compression standard). But everybody doesn't know how to do it very quickly and efficiently in a FPGA ... Sylvain
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