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
On Tue, 9 Mar 2004 06:56:03 +0800, "Kelvin @ SG" <kelvin8157@hotmail.com> wrote: >Hi, there: > >Can Xilinx XST synthesize encrypted verilog source codes? For example those >encrypted >codes in Samsung RAM model...Assume the original code is synthesizable and >encrypted... >What is the software to do this encryption? `protect is a simulator specific feature and every simulator uses a different and completely proprietary encryption algorithm to generate the protected output. As far as I know `protect is only for simulation and I don't think even a synthesizer from the same vendor would synthesize protected code as that would at least partially invalidate the reason behond protection, to protect the code from unwanted eyes. If they can get it in gates, it would still be valuable in most cases.Article: 67226
bill wrote: > Hi, > In using Xilinx Virtex2 chip, I wonder what's teh general rule to > instantiate a global timing buffer. > If I use a DCM to do some clock divide and use the generated one to > driver in-chip design, I should add a buffer to the DCM output. But > how about my DCm i used to de-skew the clock, meaning clkin is in-chip > clock, while clkfb is off-chip clock, and clk0 going off-chip again, > it seems in this case, I do not have to add a buffer to clk0. but is > there any rule here... I generally think the best rule for instantiating a clock buffer is not to unless necessary. In general, the synthesis tool will infer a clock buffer when necessary and if you are using a DCM as it seems in your case, I would use Architecture Wizard to not only give you an instantiation template for the DCM but also figure out what BUFGs are necessary for your particular configuration. That is the easiest way to go. If you happen to have a case that falls outside of inferrence or what the Architecture Wizard can offer or you desire more control over the implementation, placement and other aspects of the clocking circuit, you are best reading the Virtex-2 User Guide and getting a good understanding of the capabilities and connections of the clocking network and from that, your question will likely be answered. -- BrianArticle: 67227
Allan Herriman wrote: > Hi Brian, > > Reading you loud and clear. > > I think I was misled by a statement on page 254 of the XST User Guide > that said "You must use the KEEP constraint instead of > SIGNAL_PRESERVE" (which is wrong), and didn't mention > equivalent_register_removal at all. > > Regards, > Allan. I will forward this to the appropriate person to hopefully have this corrected in a future revision of that doc. -- BrianArticle: 67228
Denis Gleeson wrote: > Hi Brian > > Thanks for your answer, directed at my problem. > > I should have said that at the end of all the warnings I received, > was the following. > > Warning: No Global(GSR) net could be used in the design because there > is not a unique net that sets or resets all the sequential cells. > > So I am assuming that the STARTUP block has been included, even though > I didnt specifically stipulate that it should. > > I am also assuming that my synthesis tool is trying to assign a signal > assigned to a pin as a stimulus for this global net. > As soon as one register is not cleared by this signal the GSR net is > no more. OK. Now this is starting to come back to me. In the "old days" the synthesis tool would look to see if an asyncronous reset is described for all FFs in a circuit and try to infer a STARTUP block for the design. What this warning is saying is that it sees you have specified a reset for most but not all FFs and thus could not infer the STARTUP block and thus use the dedicated GSR resources. This should not be a big problem for you. For what you have described, you do not want to use the GSR resources as you do not want all FFs to be reset by that signal. > I ran a simulation to see what I would get. The simulation was done > with the scenario described, i.e. one register is not cleared by the > input "clear" pin and synthesis gives the warnings described. > > I get one BUS signal at xxx? and another at 000?. Even though I am > setting my external clear signal high. > This is new and not what I normally get from this simulation. I > normally get things cleared when the > clear signal is high. This is a little odd. First off, are you performing an initial GSR pulse to initialize your simulation you should have a few lines in your testbench like: initial begin force glbl.GSR = 1'b1; #100 force glbl.GSR = 1'b0; end This will put all registers into thier intial state as written in the docs (Synthesis and Simulation Design Guide). If you are using 6.1i or newer, this will be done automatically for you but in the earlier versions of the software you must drive this from your Verilog testbench. You should hold off feeding stimulus until GSR completes. Next, internal signals in your HDL code can get renamed by the synthesis tool. Ensure that this internal bus does exist and has not been renamed or possibly removed by the synthesis tool. That could also be a source to what you are seeing. > From this I assume that my efforts to clear a section of the FPGA > leaving one register un cleared > is not working. Perhaps but I would guess the problem is not with the fact you are not rseting one register but elsewhere. Perhaps what I said above could help you determine that. > Now this is really confusing me. I have a pin assigned to have an > external signal(with the name clear). > This signal is sent to all FFs and counters in the FPGA in my verilog > code. Now because I have not complied with the requirements for a GSR > signal, I effectivly have no clear? I do not follow you here. First off, you do not have to use GSR, it is just there is you want to use it. It will automatically be asserted after power-up but whether you use it after that is up to you. From what you have describe before, it sounds like you do not want to use it. In that case, your code sounded fine the way it was. You do not have to describe the reset for every FF. If you do tie it to every FF which you can, the synthesis tool can infer a STARTUP appearently and use that dedicated resource and you would have a "clear" signal to add FFs. Perhaps I am missing what you are trying to say here. -- Brian > > > Many thanks for your input. > > > Denis > __________________________ > From Concept to Production > http://www.centronsolutions.com >Article: 67229
Hi Sneakernet, You cannot implement their desired output frequency of 12.5 Mhz using the Cyclone PLL without going out of spec. The Cyclone PLL does have a minimum output frequency limit, which is a function of the PLL's minimum VCO frequency. The minimum VCO frequency is 491Mhz, and the maximum output divider counter size is 32, which results in a minimum output frequency of approximately 15.3 Mhz (i.e.491/32). Page 4-31 of the device handbook gives the PLL frequency specs. The input frequency has to be between 15.625 MHz and 464 MHz for the fastest (-6) speed grade, and between 15.625 MHz and 387 MHz for the slowest (-8) speed grade. See http://www.altera.com/literature/hb/cyc/cyc_c51004.pdf for details. - Subroto Datta Altera Corp. "SneakerNet" <nospam@nospam.org> wrote in message news:Ow43c.6282$Nc3.101499@news.xtra.co.nz... > Hello Ppl > > I have actually already asked this question before but I need help again. > > I'm using a Nios Development Board (50MHz Oscillator, FPGA = Cyclone > EP1C20F400C7). I'm using Quartus II v4.0 Build 190 > I need to generate a clock speed of 12.5MHz. While I have my own vhdl code > that can do this, I can't use the ALTPLL to do this for me. > > How can i do this? When I try to generate a speed of 12.5MHz using > MegaFunction Wizard in Quartus it complains ('Post divider max count > exceeded') > Does this mean there is a lower limit? Is there a way to achieve this speed > using ALTPLL and the above specs? > > Thanks > >Article: 67230
Hi Subroto Thanks for the clarification.. This means I must have used my own code to generate the 12.5MHz. Oh well back to using the logic. Thanks again Regards "Subroto Datta" <sdatta@altera.com> wrote in message news:41a3c.22164$cY5.21375@newssvr31.news.prodigy.com... > Hi Sneakernet, > > You cannot implement their desired output frequency of 12.5 Mhz using the > Cyclone PLL without going out of spec. > > The Cyclone PLL does have a minimum output frequency limit, which is a > function of the PLL's minimum VCO frequency. The minimum VCO frequency is > 491Mhz, and the maximum output divider counter size is 32, which results in > a minimum output frequency of approximately 15.3 Mhz (i.e.491/32). > > Page 4-31 of the device handbook gives the PLL frequency specs. The input > frequency has to be between 15.625 MHz and 464 MHz for the > fastest (-6) speed grade, and between 15.625 MHz and 387 MHz for the slowest > (-8) speed grade. See > http://www.altera.com/literature/hb/cyc/cyc_c51004.pdf for details. > > - Subroto Datta > Altera Corp. > > > "SneakerNet" <nospam@nospam.org> wrote in message > news:Ow43c.6282$Nc3.101499@news.xtra.co.nz... > > Hello Ppl > > > > I have actually already asked this question before but I need help again. > > > > I'm using a Nios Development Board (50MHz Oscillator, FPGA = Cyclone > > EP1C20F400C7). I'm using Quartus II v4.0 Build 190 > > I need to generate a clock speed of 12.5MHz. While I have my own vhdl code > > that can do this, I can't use the ALTPLL to do this for me. > > > > How can i do this? When I try to generate a speed of 12.5MHz using > > MegaFunction Wizard in Quartus it complains ('Post divider max count > > exceeded') > > Does this mean there is a lower limit? Is there a way to achieve this > speed > > using ALTPLL and the above specs? > > > > Thanks > > > > > >Article: 67231
> Floorplan the RAMs. The placer goes much quicker if you've directed > placement, and the router is quite a bit faster if it has a good floorplan > to work from. The automatic placement generally does not result in a good > floorplan. Thanks for the advice. Actually much of the time was spent during synthesis of the design. And we realize that making the ROM which is really a 64Kbit async distributed ram, hierarchy-wise, would eventually cut the time into half. Why is it so btw?? What Im thinking is that there's is no longer huge optimization on the netlist made by XST. Before, we were just compiling everything, and im guessing the tool flattens the whole design into a single net list and hence, it would take more time to optimize it (is it the proper word?) Another question, is there a way of reading back the content of block ram while the system is running, using JTAG (parallel cable 3) and impact? The FPGA forum is a great tool! Thanks a lot for everything JacArticle: 67232
Jeff Cunningham <jcc@sover.net> wrote in message news:<m8I2c.274$_43.199987@newshog.newsread.com>... > William Wallace wrote: > > THE IMPORTANCE OF PROVIDING A RESET THAT LEAVES THE RESET > > SYNCHRONOUSLY EVEN IF IT DRIVES THE ASYNCHRONOUS RESET... > > You cannot rely on async reset at startup for initializing one hot state > machines and the like... Please explain why. Meanwhile, releasing the asynchronous reset synchronously, and ensuring that the reset path delay and setup is less than a clock period, would work. Please re-read my original post, and tell me exactly where I am wrong.Article: 67233
rickman <spamgoeshere4@yahoo.com> wrote in message > ...The async global reset is not designed to be fast. So > you have to make sure that your design will work if the FFs come out of > reset on different clock cycles. That is what I was getting at with the static timing analysis checking the reset line to ensure that all flip flops with an asynchronous reset (driven from the output of a FF) see the same first clock. If the static timing analysis tools can do that, you don't need to waste combinatorial real-estate on synchronous resets.Article: 67234
On 8 Mar 2004 20:30:14 -0800, msm30@yahoo.com (William Wallace) wrote: >rickman <spamgoeshere4@yahoo.com> wrote in message > >> ...The async global reset is not designed to be fast. So >> you have to make sure that your design will work if the FFs come out of >> reset on different clock cycles. > >That is what I was getting at with the static timing analysis checking >the reset line to ensure that all flip flops with an asynchronous >reset (driven from the output of a FF) see the same first clock. If >the static timing analysis tools can do that, you don't need to waste >combinatorial real-estate on synchronous resets. As I have mentioned in another post, DFFs have a timing constraint called reset recovery which is similar to setup but on reset input instead of d input and it can be used to check clk->q->rst paths with decent STA tools. But you have to pay attention to another variable while deciding whether to use async resets: Async reset flops are usually larger and slower than their non-reset cousins (at least in most ASIC libraries) so if you use them and if your design is timing critical (which isn't these days?) you might be using more area to meet timing with async reset flops. Especially if you are working on pipelined datapaths, it may better to use non-reset flops and reset only the first stage of the pipeline for faster/smaller designs.Article: 67235
"rickman" <spamgoeshere4@yahoo.com> escribió en el mensaje news:404CE13F.7F74DA2F@yahoo.com... > The ideal marrage might be an ARM7 (like the LPC from Philips) with a > low power CPLD (like the coolrunner which was also from Philips). The > internal RAM and Flash will complement the MCU and PLD so that you can > have the best of all worlds in one part. ... so then Xilinx will have a PSoC'ed Excalibur ;^) I guess the new acquisition is an FPAA company? Concerning the 5V tolerance, as Peter Alfke once said, "Blame the laws of physics if you feel like blaming something." ;^) Sarcastically yours, -- PabloBleyerKocik /"Evidence shows that Linux is more stable. We pbleyer / are moving in general to where the Army is going, @embedded.cl / to Linux-based OS." -- Army Lt. Col. Dave GallopArticle: 67236
William Wallace wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message > > > ...The async global reset is not designed to be fast. So > > you have to make sure that your design will work if the FFs come out of > > reset on different clock cycles. > > That is what I was getting at with the static timing analysis checking > the reset line to ensure that all flip flops with an asynchronous > reset (driven from the output of a FF) see the same first clock. If > the static timing analysis tools can do that, you don't need to waste > combinatorial real-estate on synchronous resets. The analysis tool can't make the GSR network faster than it is. It is not designed to be fast, it is designed to minmize its use of resources (area). I don't have a number for the speed of the path, but even when FPGA logic topped out at 50 MHz, we were warned not to rely on the GSR net to release all the FFs on the same clock cycle. Normally you don't need to worry with the reset release on most of your logic. Things like data path registers don't care about the reset. It is the control logic, and only control logic that will take off running that matters. In most of my designs, the control logic waits for some input signal anyway. I don't build too many FSMs that start off by counting. The ones that do can be set to go through a set of gray codes initially so that they are reset release insensitive. If you can get the reset to release the entire design in the same clock cycle, then you are ok. But you can't use one of the standard clocked FFs to do that. It will have to be an external FF that controls the timing of the release. -- 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 67237
Peter Alfke wrote: > LUTs are very efficient "illegal state" detectors. > Let's say you have a 16-state one-hot machine. Four LUTs can each detect > "exactly one of my inputs is High", and a fifth LUT does the same with the > four LUT outputs. So 5 LUTs can detect any illegitimate 16-bit code. Take it > from there... Eh, what? So the first tier LUT compute f, where f(a,b,c,d) = 1 iff a+b+c+d = 1, else 0. For the 5th LUT we have the same property that a legal 16-state would map exactly one of the four first tier LUTs to 1, thus it sounds like what you have in mind is something like this: f({f(s[3:0]), f(s[7:4]), f(s[11:8]), f(s[15:12])}) but this could accept states like 16'b1111_1110_1100_0001. I don't see how you can detect legal states with only five four-input LUTs. Peter, the FPGA reset question has come many times. What does Xilinx recommend in general? Async-reset+Sync-release, all-sync, or all-async? Which uses fewest resources? Thanks, TommyArticle: 67238
Subroto Datta wrote: > The Quartus II 4.0 Web Edition Software with support for the new Stratix II > (90 nm FPGA's) and Max II (lHigh density, low power CPLD's) device families > is available for download at: > > http://www.altera.com/products/software/pld/products/quartus2/sof-quarwebmain.html Sweet! Thanks. Too bad there's not a Linux version of the zero-cost Web Edition. /TommyArticle: 67239
user@domain.invalid wrote: > > Peter Alfke wrote: > > LUTs are very efficient "illegal state" detectors. > > Let's say you have a 16-state one-hot machine. Four LUTs can each detect > > "exactly one of my inputs is High", and a fifth LUT does the same with the > > four LUT outputs. So 5 LUTs can detect any illegitimate 16-bit code. Take it > > from there... > > Eh, what? So the first tier LUT compute f, where > f(a,b,c,d) = 1 iff a+b+c+d = 1, else 0. > For the 5th LUT we have the same property that a legal 16-state would > map exactly one of the four first tier LUTs to 1, thus it sounds like > what you have in mind is something like this: > > f({f(s[3:0]), f(s[7:4]), f(s[11:8]), f(s[15:12])}) > > but this could accept states like 16'b1111_1110_1100_0001. > > I don't see how you can detect legal states with only five four-input LUTs. Yeah, looks like you are right. This one requires that you *count* all the ones in the FSM. Each set of three requires two LUT3s to count them. You could do four in three LUT4s, but I expect that is not as efficient. In the second stage you can use LUT4s to add three inputs plus a carry in. Each three pairs of inputs from the first state will require five LUT4s to produce 4 outputs (count of 0 to 9)... you get the idea. Once you get to four bits, you are probably better off using the standard carry chain adders. > Peter, the FPGA reset question has come many times. What does Xilinx > recommend in general? Async-reset+Sync-release, all-sync, or all-async? > Which uses fewest resources? I don't think there is a simple answer to this question. Most designs have multiple clocks and a lot of the FFs in a design don't care about an initial state, much less how they are released from reset. Just be aware of which FFs require synchronous release and make sure you handle it properly. I seriously doubt that it will use much resources in any event. -- 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 67240
rickman wrote: > > user@domain.invalid wrote: > > > > Peter Alfke wrote: > > > LUTs are very efficient "illegal state" detectors. > > > Let's say you have a 16-state one-hot machine. Four LUTs can each detect > > > "exactly one of my inputs is High", and a fifth LUT does the same with the > > > four LUT outputs. So 5 LUTs can detect any illegitimate 16-bit code. Take it > > > from there... > > > > Eh, what? So the first tier LUT compute f, where > > f(a,b,c,d) = 1 iff a+b+c+d = 1, else 0. > > For the 5th LUT we have the same property that a legal 16-state would > > map exactly one of the four first tier LUTs to 1, thus it sounds like > > what you have in mind is something like this: > > > > f({f(s[3:0]), f(s[7:4]), f(s[11:8]), f(s[15:12])}) > > > > but this could accept states like 16'b1111_1110_1100_0001. > > > > I don't see how you can detect legal states with only five four-input LUTs. > > Yeah, looks like you are right. This one requires that you *count* all > the ones in the FSM. Each set of three requires two LUT3s to count > them. You could do four in three LUT4s, but I expect that is not as > efficient. > > In the second stage you can use LUT4s to add three inputs plus a carry > in. Each three pairs of inputs from the first state will require five > LUT4s to produce 4 outputs (count of 0 to 9)... you get the idea. Once > you get to four bits, you are probably better off using the standard > carry chain adders. Actually, I just realized that you don't need to implement proper counters for these. You just need to distinguish 0, 1 and *more than 1* from your input combinations. So for each set of 4 inputs, you can use two LUT4s to distinguish these three states. Then each level of logic will combine the previous outputs to give you in the end, *exactly 1* or not. -- 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 67241
>Please explain why. Meanwhile, releasing the asynchronous reset >synchronously, and ensuring that the reset path delay and setup is >less than a clock period, would work. You CAN do it, in theory. That's assuming the tools are smart enough and the data is available. They may not bother to cover that case since few people are interested in it and it would normally generate a blizzard of errors so everybody would use the skip-GSR-errors flag. The problem is that the reset network is slow. Very slow. You can't run the rest of the chip at a reasonable speed if you run it slow enough so that reset will be synchronous. The Spartan-II, -6 data sheet that I have handy doesn't list the setup time for the GSR net. It does list the GSR-Q at 9.9 ns (for both IOBs and CLBs). That's relative to a setup time of under 1 ns for CE and SR. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 67242
>The problem is that the reset network is slow. Very slow. You >can't run the rest of the chip at a reasonable speed if you run >it slow enough so that reset will be synchronous. PS: Don't forget the case where you have multiple clocks on a chip. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 67243
well, maybe that is why i couldnt simulate the Samsung SmartMedia model with Modelsim... How do I find out which is the right simulator? Best Regards, Kelvin Paulo Dutra <Paulo.Dutra@xilinx.com> wrote in message news:c2isnh$dqi2@cliff.xsj.xilinx.com... > Are u refering to the `protect and `endprotect compiler directives? > Looking at the IEEE spec there's > no definition of these compiler directives. It's use I have only seen > associated with simulation > models targeted toward a specific simulator.. As the > encryption/decryption I would assume is proprietary. > Thus, you cannot compile in XST. > > I found this text in the ModelSim user guide: > > Though other simulators have a `protect directive, the algorithm > ModelSim uses to encrypt > source files is different. Hence, even though an uncompiled source file > with `protect is > compatible with another simulator, once the source is compiled in > ModelSim, you could > not simulate it elsewhere. > > > Kelvin @ SG wrote: > > >Hi, there: > > > >Can Xilinx XST synthesize encrypted verilog source codes? For example the > >following style... > >What is the software to do this encryption? > > > >Best Regards, > >Kelvin > > > > > > > > > >Article: 67244
well, maybe that is why i couldnt simulate the Samsung SmartMedia model with Modelsim... How do I find out which is the right simulator? Best Regards, Kelvin kal <kal@dspia.deletethis.com> wrote in message news:hkup40dd3fv5keqpfve19vlnhmvv871kbc@4ax.com... > On Tue, 9 Mar 2004 06:56:03 +0800, "Kelvin @ SG" > <kelvin8157@hotmail.com> wrote: > > >Hi, there: > > > >Can Xilinx XST synthesize encrypted verilog source codes? For example those > >encrypted > >codes in Samsung RAM model...Assume the original code is synthesizable and > >encrypted... > >What is the software to do this encryption? > > `protect is a simulator specific feature and every simulator uses a > different and completely proprietary encryption algorithm to generate > the protected output. As far as I know `protect is only for simulation > and I don't think even a synthesizer from the same vendor would > synthesize protected code as that would at least partially invalidate > the reason behond protection, to protect the code from unwanted eyes. > If they can get it in gates, it would still be valuable in most cases. >Article: 67245
My finding was that, the partial reconfig approach was very unpredicatble. In some of my designs, first version rans correct and clean. Then I added in a few modules into the fixed portion(module "partial"), then even after it completed assembly routing, it gave me a fatal error...for example, Total REAL time to Placer completion: 25 mins 19 secs Total CPU time to Placer completion: 12 mins 32 secs Phase 1: 4 unrouted; REAL time: 25 mins 29 secs Phase 2: 4 unrouted; REAL time: 43 mins 58 secs Phase 3: 0 unrouted; REAL time: 44 mins 2 secs Phase 4: 0 unrouted; (0) REAL time: 44 mins 3 secs Phase 5: 0 unrouted; (0) REAL time: 44 mins 5 secs Phase 6: 0 unrouted; (0) REAL time: 44 mins 8 secs FATAL_ERROR:Ncd:basncsignal.c:283:1.39.8.1 - Could not find a bel for a signal on pin G4 of comp partial/u_int/y(9). Its current programmed state is : XUSED:0 DXMUX:1 F:#LUT:D=((~A4*A1)+(A4*A3)) FXMUX:F5 SYNC_ATTR:ASYNC SRFFMUX:0 FFX:#FF FFX_SR_ATTR:SRLOW FFX_INIT_ATTR:INIT0 G:#LUT:D=((~A1*A2)+(A1*A3)) BXINV:BX CEINV:CE CLKINV:CLK SRINV:SR_B Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.com Sean Durkin <23@iis.42.de> wrote in message news:404c4479$1@news.fhg.de... > Markus wrote: > > Sean and Kelvin, > > > > I had the same problem (Fatal Errors due to logic0/logic1 on signals). The > > logic0/logic1 doesn't seem the problem itself but it leads in the right direction. > > > > In my case, the error was mostly caused by unconstraint top level logic.If the > > logic was moved into a module, the final par was successful. However, I still > > have trouble setting constant '0' and '1' on the bus macro inputs, which also > > causes your problem even if no real logic is involved. What puzzles me is that > > it works for the tutorial (xapp290). > > > > Please correct me if I am wrong. > Yes, you are right. I've opened a WebCase with Xilinx for this, and they > too stated that in all cases where this happens, it is in some way > related to the top level, as you said. But apparently in some cases it > happens even when there is no unplaced or wrongly placed top-level > logic, as in my case (I get this error even if I don't have any > top-level logic or bus macro connections at all). > > Plus they told me that there is a bug in par ISE6.1, that too can cause > this error. This will probably be fixed in one of the first Service > Packs for ISE6.2. > > -- > Sean Durkin > Fraunhofer Institute for Integrated Circuits (IIS) > Am Wolfsmantel 33, 91058 Erlangen, Germany > http://www.iis.fraunhofer.de > > mailto:23@iis.42.de > ([23 , 42] <=> [durkinsn , fraunhofer])Article: 67246
Hello NG, we are planning a high speed data transmission between several devices. We now found the LVDS standard. I found some pages in the WWW which told me some things about cable lengths. But it might be not enough... We would need a transmission rate of 100 MBit and a transmission length of some ten meters (ok, my boss wants a km, but I think that this is impossible if we want to use an electrical standard... This should be an optical solution). Does anyone now how far we can use LVDS using 100MBit? Has anyone already designed such a transmission line? Any help is appreciated. Thanks. Greetz, Thomas Kurth -- No matter if you are going on-piste or off-piste, just hit the slope and stay healthy! For mail reply replace "nospam" with "kurth" and "net" with "de". The above mentioned adress is valid, but ignored.Article: 67247
On Tue, 9 Mar 2004 08:59:11 +0100, Thomas Kurth <thomas.nospam@gmx.net> wrote: >Hello NG, > >we are planning a high speed data transmission between several devices. >We now found the LVDS standard. I found some pages in the WWW which told >me some things about cable lengths. But it might be not enough... We >would need a transmission rate of 100 MBit and a transmission length of >some ten meters (ok, my boss wants a km, but I think that this is >impossible if we want to use an electrical standard... This should be an >optical solution). Does anyone now how far we can use LVDS using >100MBit? Has anyone already designed such a transmission line? > >Any help is appreciated. Thanks. I suggest you look at Ethernet PHYs. They are cheap, readily available, simple to interface to your FPGA, and will work reliably at 100Mb/s over 100m of cat5. They also take care of scrambling and coding such that you effectively have a 100Mb/s clear channel end-to-end. E.g. LXT972A http://www.intel.com/design/network/products/ethernet/linecard_ept.htm Regards, Allan.Article: 67248
Hi, i am new to FPGA's and vhdl.i need to design a sorter of N numbers 32 bit each.i know sorting algorithms bubble sort.But i found that in fpga's we can do bit comparision parallel and there are fast sort methods i can use.i saw a couple but not sure how to implement on virtex-II xc2v1000 which has a 100MHz clock.If some body have an hardware discrption or digital schematic please let me know.i appreciate their help thank you sreeArticle: 67249
In article <MPG.1ab797b9709e1ba99896ef@127.0.0.1>, thomas.nospam@gmx.net says... > Hello NG, > > we are planning a high speed data transmission between several devices. > We now found the LVDS standard. I found some pages in the WWW which told > me some things about cable lengths. But it might be not enough... We > would need a transmission rate of 100 MBit and a transmission length of > some ten meters (ok, my boss wants a km, but I think that this is > impossible if we want to use an electrical standard... This should be an > optical solution). Does anyone now how far we can use LVDS using > 100MBit? Has anyone already designed such a transmission line? > > Any help is appreciated. Thanks. > > Greetz, > > Thomas Kurth > We are using LVDS together with a low capacitance cable of 10 m at 50 MHz clock, and my impression is that it is on it's limit. It is sensitive to disturbances and signal quality depends strongly on quality of the cable. If you really want to do it, do not forget to feed the GND signal too through the cable, since the common mode range of the differential receivers is not large enough for dealing with differences between the ground levels of transmitter and receiver. I seem to remember that somewhere on the National Semiconductor web pages there is a graph about data rates and covered distances. Convince your boss to use an optical link, you will have only advantages! They are not so complicated as it seems. Hope this help. -- Klaus Falser Durst Phototechnik AG kfalser@IHATESPAMdurst.it
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