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
dajjou <swissiyoussef@gmail.com> wrote in news:9d0ab964-2168-4eb5-a0ce-a52421b3b3f4@i38g2000yqd.googlegroups.com: > On 17 fév, 15:16, Allan Herriman <allanherri...@hotmail.com> wrote: >> Gabor <ga...@alacron.com> wrote in news:e0edd268-99d3-44de-b126- >> 90be94098...@m15g2000vbp.googlegroups.com: >> >> >> >> > On Feb 16, 5:37 am, Antti <Antti.Luk...@googlemail.com> wrote: >> >> On Feb 16, 12:16 pm, dajjou <swissiyous...@gmail.com> wrote: >> >> >> > Hi everybody, >> >> >> > When configuring my Virtex 5 with encrypted bitstream (CCLK rate >> >> > is 100 MHz) the FPGA doesn't start up ! >> >> > whereas it is not the case for unencrypted one . Why ??? >> >> > I need to configure the FPGA as quickly as possible. >> >> >> > Thanks. >> >> >> you need to use parallel mode :( >> >> i think the 100mhz ecnrypted mode may not be supported, please >> >> check the datasheets >> >> >> Antti >> >> > I've run into other problems at 100 MHz for unencrypted bitstreams >> > as well. When the DONE signal is allowed to float high, the >> > startup state logic can sample it in the threshold region >> > (yes the chip samples the pin unless you set "Internal Done Pipe") >> > and lock up. I solved this using the internal done pipe, but >> > another recommendation was to "Drive Done High". My external >> > DONE pullup was 330 ohms as recommended, but at 100 MHz, this >> > is not fast enough. Another approach to fix this might be to >> > slow down CCLK at or near the end of the bitstream. >> >> The last time I looked into this (Virtex2?), the specification for >> maximum frequency with encryption wasn't specified in the datasheets. >> The figure was specified in some obscure app note, and was something >> like 10MHz, much lower than the frequency allowed without encryption. >> >> Things may have improved with more recent FPGA families though. >> >> Regards, >> Allan > > Hi ! > I guess that decryption is done at the same frequency as the config > rate, isent it ? Yes, it is fairly obvious that it will decrypt the frames as they come in. AllanArticle: 138376
John Eaton skrev: > emeb wrote: >> On Feb 7, 8:13 pm, John Eaton <nos...@spam.com> wrote: >> >>> Digilent (www.digilentinc.com) sells a nice usb to 6 pin cable for >>> $37.95. Problem is it only works with their windoze software. Would be >>> nice if they supported linux. >> >> I've got one of these and it works nicely (very fast) under WinXP, >> although the driver application has a few limitations (can only >> configure, not verify / readback). There is an open source app that >> purports to drive this device here: >> >> http://sourceforge.net/projects/xilprg >> >> It's a few years out of date and the author seems to have dropped off >> the face of the planet. I've tried this with my Digilent USB<->JTAG >> cable and while it recognizes the device it can't seem to detect any >> devices on the bus. Hanging a 'scope probe from the JTAG signals shows >> that they're not moving, so I suspect there are still some issues. It >> might be a good starting point for someone who knows more about this >> than I do. >> >> Eric (not the OP) > > > I also tried xilprg with the same results. Glad to see that I'm not the > only one who can't get anything to work. > > John Eaton If you are looking for a cheaper USB JTAG cable that works with xilinx software, you can find it here: http://www.morphologic.dk/shop/product_info.php?products_id=28 Regards, FinnArticle: 138377
Svenn Are Bjerkem wrote: > Hi, > > our development workstation is getting old and the project is getting > bigger. We need to run more long modelsim simulations and each > synthesis run take 20 minutes in ISE on a spartan-3A DSP 3400 which is > only half full. > > It's a long time since I put together a maximum-performance computer > and I am not up to date on the latest CPUs. Our IT is not of much help > since they care for mobile phones and laptops and windows networks. We > run our FPGA development on Linux and 3 people share one workstation > for design, simulation and synthesis. It is most likely only one > person who is doing heavy sim and synth at a time, but with tools like > SmartXplorer it is nice to have as many cores or machines as possible > to run many jobs in parallel. > > Are the new Nehalems (core i7) that much better than core 2 that the > extra price is justified? A 4-core is a natural decision, but would an > 8-core be better, or will 8 modelsim jobs just tie down disk and > memory? Will DDR3 memory have an advantage over DDR2 memory for FPGA > type work? > > I hope somebody who have just upgraded would share some of their > experience. > I haven't tried FPGA work on many different machines, but here's a few pointers: FPGA placing and routing (I don't know about simulation) is *mostly* single-threaded. Quartus has been getting steadily more SMP-friendly, but I believe SMP doesn't give you more than about 30% or so. So unless your simulator is fully multi-threaded, anything more than 2 cores will not speed up FPGA work. The i7 has 4 cores (turning on hyper-threading would not help here), and it will automatically overclock one of the cores if the other cores are idle. These sorts of programs are often very demanding on the memory usage and cache usage. The i7 has 8 MB core, the Core2 dual has 4 MB (IIRC). The i7 also has its memory controller on chip for lower latency and higher bandwidth (basically, the i7 has copied all of AMD's good ideas). I've never seem a benchmark that shows memory types (DDR3 vs. DDR2) or speed giving more than a couple of percent difference for non-synthetic tests. You are probably better off prioritising quantity of memory over speed (unless your budget is very large). The latest AMD devices will, as usual, give you more performance for your money and more performance per watt, than an Intel-based system. But the i7 should be the fastest device available, and the 920 is not expensive.Article: 138378
Hi, Thank you all for your answers. When I make a diff between the encrypted bitstream and the unencrypted one I realize that the encrypted one contains 9 extra NOP WORDS just before CRC checking. Moreover, I noted that he needs exactly 7 Nop words to start up my design when using x8 parallel mode and this is true for all config rates. My conclusion is that the decryptor(AES in CBC mode) needs these 7x4 clocks to decrypt the last block of the encrypted data (128 bits). Am I right ?Article: 138379
Hi all, XPS 10.1 returns me these errors... /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: region ilmb_cntlr_dlmb_cntlr is full (TestApp_Memory/executable.elf section text) /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .init [00000050 -> 00000073] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .fini [00000074 -> 0000008f] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .rodata [00000090 -> 00000873] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .sdata2 [00000874 -> 00000877] overlaps section text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .data [00000878 -> 000009d7] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .ctors [000009d8 -> 000009df] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .dtors [000009e0 -> 000009e7] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .eh_frame [000009e8 -> 000009eb] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .jcr [000009ec -> 000009ef] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .bss [000009f0 -> 00000a13] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .heap [00000a14 -> 00000e17] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: section .stack [00000e18 -> 00001217] overlaps section .text [00000050 -> 00006863] /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: TestApp_Memory/executable.elf: section .text lma 0x50 overlaps previous sections /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: TestApp_Memory/executable.elf: section .fini lma 0x74 overlaps previous sections /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: TestApp_Memory/executable.elf: section .rodata lma 0x90 overlaps previous sections collect2: ld returned 1 exit status make: *** [TestApp_Memory/executable.elf] Error 1 May someone explain to me what they mean please? Thanks a lot DanieleArticle: 138380
charlie78 schrieb: > Hi all, > XPS 10.1 returns me these errors... > > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > region ilmb_cntlr_dlmb_cntlr is full (TestApp_Memory/executable.elf section > .text) > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .init [00000050 -> 00000073] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .fini [00000074 -> 0000008f] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .rodata [00000090 -> 00000873] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .sdata2 [00000874 -> 00000877] overlaps section > .text [00000050 -> 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .data [00000878 -> 000009d7] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .ctors [000009d8 -> 000009df] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .dtors [000009e0 -> 000009e7] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .eh_frame [000009e8 -> 000009eb] overlaps section .text [00000050 > -> 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .jcr [000009ec -> 000009ef] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .bss [000009f0 -> 00000a13] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .heap [00000a14 -> 00000e17] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > section .stack [00000e18 -> 00001217] overlaps section .text [00000050 -> > 00006863] > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > TestApp_Memory/executable.elf: section .text lma 0x50 overlaps previous > sections > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > TestApp_Memory/executable.elf: section .fini lma 0x74 overlaps previous > sections > /cygdrive/c/Programmi/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: > TestApp_Memory/executable.elf: section .rodata lma 0x90 overlaps previous > sections > collect2: ld returned 1 exit status > make: *** [TestApp_Memory/executable.elf] Error 1 > > May someone explain to me what they mean please? Your system is out of memory. You need to add more memory to store your microblaze program > > Thanks a lot > > DanieleArticle: 138381
On Tue, 17 Feb 2009 15:37:53 -0800 (PST), Poojan Wagh <poojanwagh@gmail.com> wrote: >I'm trying to run through simulation of the PIO example given with >Xilinx PCIe endpoint block plus. However, when I run modelsim with >the .do file given in the example, I get: > >vcom -work work -f board_rtl.f ># Model Technology ModelSim PE vcom 6.5 Compiler 2009.01 Jan 22 2009 ># -- Loading package standard ># ** Error: ../../example_design/xilinx_pci_exp_ep.v(1): near "/": >syntax error >(For illustration, I executed the .do file manually line by line). > >I don't know much about ModelSim (thus the post), but it seems like it >thinks ../../example_design/xilinx_pci_exp_ep.v is a VHDL file >(rather than Verilog). How do I fix this misunderstanding? The problem is apparently in the example script. vcom is the VHDL compiler, which IMO can legitimately assume its input is VHDL... I think you need to edit the script (or find a more suitable one) to use the Verilog compiler. I think it's called vlog, but I've never used it. - BrianArticle: 138382
I'll start by saying we are still only letting HB2 out to selected customers on an early release program. It's a very complex board to fully design test and we are also suffering an extremely large work overload virtually since we released this product and we are behind schedule doing things with this board. The DDR3 is one few remaining areas we have to complete testing on and it was a late addition to the design replacing a DDR2 memory stack. I have a realistic expectation that the DDR3 will work. We are not aiming to run at full speed but at a speed sufficient for our intended use that of supporting a MicroBlaze design. The DDR3 offers the highest density and lowest power for the application. If by chance we are wromg on the way we intend to achive the working DDR3 the design will fall back to the original DDR2 for the main build batch but I don't expect that to be necessary. Historically we have always led in technology and with a very high success rate at making the new technology work. On Antti's point about aerospace etc. there are a lot of applications there that are not safety critical e.g. entertainment systems where new technology isn't always a barrier. That aside all technology was new at some point and eventually got adopted and is flying now. We also do a lot of derivative designs from the public development boards and the development boards mainly act as showcases as to what can be done. A particular customer can always ask SRAM or SDRAM instead on their custom if they don't like DDR3. If they are prepared to pay the NRE and we can physically get it on the board they can have what they want. We do have a lot of things planned for the Hollybush range and HB2 is only a taster of what we have planned. I will also say we have a reasonable number of cards flying around in helicoopters and other aircraft without issue. Assuming that this all works ok we will be releasing a DDR3 core as a product and even if it's not used on HB2 we have plenty of boards coming that will support the technology. We have a big year to celebrate this year and as part of that celebration we will release a record number of new products. I will be talking more about this in our next newsletter to customers and maybe letting a one or two pleasant surprises out of the bag. John Adair Enterpoint Ltd. On 17 Feb, 23:06, n...@puntnl.niks (Nico Coesel) wrote: > Antti <Antti.Luk...@googlemail.com> wrote: > >On Feb 17, 6:51=3DA0pm, n...@puntnl.niks (Nico Coesel) wrote: > >> "koethe.daniel...@googlemail.com" <dkoe...@web.de> wrote: > >> >Hello Antti, > >> >on the webpage is a .ucf file available, but this contains NOT the > >> >DDR3-SDRAM pins. > > >> >You are right, spartan-3A DSP does not support DDR3-Voltage Levels. > > >> >Use the SSTL18_[I,II] at VCCO=3D3D1.5V and Vref=3D3D0,75V should be p= ossible=3D > >, > >> >but nobody guarantees the IO-Timing and Voltage Levels. > > >> >But there is a second challenge. The maximal clock cycle with DDR3- > >> >SDRAM DLL enabled is 3.3 ns (~300 Mhz) this should be above any the > >> >Spartan-3A Memory-Controllers. > > >> >Micron Datasheet: > >> >http://download.micron.com/pdf/datasheets/dram/ddr3/1Gb%20DDR3%20SDRA= ... > > >> >This DLL can disabled, but the relationchip between clk and data > >> >output delay is lost. Second you must disable the ODT (On Die > >> >Termination). > > >> If you disable the DLL, the clock range of DDR3 is very wide. Actually > >> much wider when using DDR or DDR2 memory. So it makes perfect sense to > >> use DDR3 on an FPGA because its lower power and easier to design and > >> still have dual data rate memory. Running it at 80MHz or 100MHz is > >> very feasible IMHO. > > >> -------------------------------------------------------------- > > >hmm > > >enterpoint Press Release promotes the HB2 for: > >"aircraft, automotive, shipping and rail applications." > > >would you recommend to design in a product > >with DDR3 and disabled DLL for aerospace use? > > As long as it meets timing and its operation is more or less > guaranteed by the manufacturor. Micron is not recommending operating > the memory with the DLL off, but they do specify the timing. Samsung > does the same. It seems the DDR3 devices operate similar with some > timing restrictions when the DLL is off. The biggest problem seems > that Jedec didn't specify the timing requirements with the DLL off. > This potentially kills interoperability between memories. > > Back to the real world. Some DDR3 controllers require to read/write > the memory before enabling the DLL for timing calibrations. In other > words if the memory can't be read/written reliably with the DLL off > the memory might not work in every situation. > > But lets see what John has to say about this. > > -- > Failure does not prove something is impossible, failure simply > indicates you are not using the right tools... > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg= er hammer!" > --------------------------------------------------------------- Hide quot= ed text - > > - Show quoted text -Article: 138383
On Feb 16, 4:48=A0am, Zhiguo <chee...@gmail.com> wrote: > very useful tool to discuss timing. I have download it and use it! > On Feb 15, 9:10=A0pm, timinganalyzer <timinganaly...@gmail.com> wrote: > > > Hi All, > > > A new beta version of the TimingAnalyzer is available. =A0 Since it > > taking much longer than expected to finish the program, =A0a few change= s > > have occurred. > > > 1) There is only one version now that includes all the features that > > are functional to this point. =A0You can download and use without any > > restrictions. > > > 2) =A0A new license simply says that the TimingAnalyzer will always be > > completely free to use with no limitations for personal and academic > > use. =A0 There will be a one time charge for commercial use when the > > final release occurs. =A0Expected cost will be very low compared to the > > competition. > > >www.timing-diagrams.com > > > As always, =A0feedback and suggestions are welcome. =A0This way, =A0you= can > > shape the look and feel of the TimingAnalyzer. > > > Regards, > > Dan > > Thanks. Are you using it to discuss timing diagrams in meetings or presentations or design reviews?Article: 138384
Yesterday, the nice marketing people from Gennum informed me that, in their unbiased opinion, their GN4124 PCI Express to Local Bus bridge chip is the finest solution that the world has ever seen for connecting an FPGA as a PCIe endpoint, and that anyone trying to do so any other way is sadly misguided, and will in future years be looked back on as a group with flat Earth believers and Chicago Cubs fans. The surface level stuff I've had a chance to look over on the chip is pretty interesting. At first glance, it should have no trouble handling my needs for about a 1 Gbps average throughput and should be pretty straightforward. But before I get too far into the depths of the restricted datasheets, driver code samples, provided Verilog, etc, I figured I'd go on a quick CAF fishing trip. Anyone had any experiences with the GN4124? Or alternatively, with the PEX8311 by PLX, which is the only other chip I've managed to find that performs a similair task? The ultimate project goal is going to be a PCIe card with an FPGA talking to a mini-ITX running Linux, and I'm likely going to be the one doing the coding on all ends. Total project run's only likely about 200, 250 pieces, so it's easier to spend BOM money than it is to buy expensive IP or spend weeks and weeks of extra coding. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 138385
On Feb 18, 8:50=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > Yesterday, the nice marketing people from Gennum informed me that, in > their unbiased opinion, their GN4124 PCI Express to Local Bus bridge > chip is the finest solution that the world has ever seen for connecting > an FPGA as a PCIe endpoint, and that anyone trying to do so any other > way is sadly misguided, and will in future years be looked back on > as a group with flat Earth believers and Chicago Cubs fans. > > The surface level stuff I've had a chance to look over on the chip is > pretty interesting. =A0At first glance, it should have no trouble handlin= g > my needs for about a 1 Gbps average throughput and should be pretty > straightforward. =A0But before I get too far into the depths of the > restricted datasheets, driver code samples, provided Verilog, etc, I > figured I'd go on a quick CAF fishing trip. > > Anyone had any experiences with the GN4124? =A0Or alternatively, with the > PEX8311 by PLX, which is the only other chip I've managed to find that > performs a similair task? =A0The ultimate project goal is going to be a > PCIe card with an FPGA talking to a mini-ITX running Linux, and I'm > likely going to be the one doing the coding on all ends. =A0Total project > run's only likely about 200, 250 pieces, so it's easier to spend BOM > money than it is to buy expensive IP or spend weeks and weeks of extra > coding. > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order hm, i am planning to use GL9701 but it may not deliver your performance as it is simple PCIe to PCI bridge well it is easy as it is delivered in TQFP128 package AnttiArticle: 138386
Dear FPGA group, I have a state machine done with one flag for each state. Most of the states are sequential accomplished with a default assignment: signal state : std_logic_vector(0 to 61); begin if(clk'event and clk='1')then state<='0'&state(0 to 60); etc. There are some variations to this sequential flow. Elsewhere I assign data paths to these states like this: if(clk'event and clk='1')then if state(33 to 36)>0 then mem_out<=a; elsif state(37)>0 then mem_out<=b; etc. The elsif are a bit long and have unnecessary priority logic since state(33 to 36) trumps state(37). This happens although I can be very sure that the states are mutually exclusive by design. I am using Xilinx ISE9.2, ModelSim, and an ML402 kit. I am of the understanding that a series of "if end if" statements would only serve to put the priority on the last "if end if" statement and therefore would still result in a chain of priority logic. So my question is how to get rid of the priority logic? If I have to resort to a case statement, how do I code this succinctly with this long state vector? And is there some other way to do it, perhaps with a variable? Brad Smallridge AiVisionArticle: 138387
On Feb 18, 5:39=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > Dear FPGA group, > > I have a state machine done with one flag for each state. > Most of the states are sequential accomplished with a default assignment: > signal state : std_logic_vector(0 to 61); > begin > if(clk'event and clk=3D'1')then > =A0state<=3D'0'&state(0 to 60); > etc. > There are some variations to this sequential flow. > > Elsewhere I assign data paths to these states like this: > if(clk'event and clk=3D'1')then > =A0if state(33 to 36)>0 then > =A0 mem_out<=3Da; > =A0elsif state(37)>0 then > =A0 mem_out<=3Db; > =A0etc. > > The elsif are a bit long and have unnecessary priority > logic since state(33 to 36) trumps state(37). > This happens although I can be very sure that the states > are mutually exclusive by design. > > I am using Xilinx ISE9.2, ModelSim, and an ML402 kit. > > I am of the understanding that a series of "if end if" > statements would only serve to put the priority on the > last "if end if" statement and therefore would still > result in a chain of priority logic. > > So my question is how to get rid of the priority logic? > If I have to resort to a case statement, how do I code > this succinctly with this long state vector? > And is there some other way to do it, > perhaps with a variable? > > Brad Smallridge > AiVision If it were Verilog I would use a case statement and add "// synthesis parallel-case" to remove the priority logic. Since this is a synthesis directive, it might also work in VHDL?Article: 138388
Brad Smallridge wrote:
> I have a state machine done with one flag for each state.
> Most of the states are sequential accomplished with a default assignment:
> signal state : std_logic_vector(0 to 61);
> begin
> if(clk'event and clk='1')then
> state<='0'&state(0 to 60);
> etc.
> There are some variations to this sequential flow.
(snip)
> The elsif are a bit long and have unnecessary priority
> logic since state(33 to 36) trumps state(37).
> This happens although I can be very sure that the states
> are mutually exclusive by design.
So you want something like AND/OR logic. Each signal
ANDed with its enable, OR them all together.
> if(clk'event and clk='1')then
> if state(33 to 36)>0 then
> mem_out<=a;
> elsif state(37)>0 then
> mem_out<=b;
> etc.
I am not sure what it would look like in VHDL, but I might try:
assign mem_out <= (a & {8{|state[33:36]}}) | ( b & {8{state[37]}});
That could be extended to any number of inputs with only two
levels of logic.
You should verify that if it does get into an unexpected
state that it will recover. (Either at initialization
or due to random cosmic rays.) Also, that bad things
don't happen (enable tristate outputs at the wrong time).
-- glen
Article: 138389Gabor > If it were Verilog I would use a case statement and > add "// synthesis parallel-case" to remove the priority > logic. Since this is a synthesis directive, it might > also work in VHDL? If your assumption was wrong, would you expect to get any warnings before implementing your chip? See Cliff's paper titled, "full_case parallel_case", the Evil Twins of Verilog Synthesis at: http://www.sunburst-design.com/papers/ Cheers, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis SynthWorks VHDL Training http://www.synthworks.com A bird in the hand may be worth two in the bush, but it sure makes it hard to type.Article: 138390
Beat me to the punch. I also recommend reading this paper and his others. Case statements in VHDL are automatically parallel and full anyway. ---Matthew Hicks > Gabor > >> If it were Verilog I would use a case statement and >> add "// synthesis parallel-case" to remove the priority >> logic. Since this is a synthesis directive, it might >> also work in VHDL? > If your assumption was wrong, would you expect to > get any warnings before implementing your chip? > See Cliff's paper titled, > "full_case parallel_case", the Evil Twins of Verilog Synthesis > at: http://www.sunburst-design.com/papers/ > > Cheers, > Jim > A bird in the hand may be worth two in the bush, > but it sure makes it hard to type.Article: 138391
dajjou <swissiyoussef@gmail.com> wrote in news:00da3286-d674-43ae-baa0- 749c2b1605d9@x38g2000yqj.googlegroups.com: > Hi, > Thank you all for your answers. > > When I make a diff between the encrypted bitstream and the unencrypted > one I realize that the encrypted one contains 9 extra NOP WORDS just > before CRC checking. > Moreover, I noted that he needs exactly 7 Nop words to start up my > design when using x8 parallel mode and this is true for all config > rates. > My conclusion is that the decryptor(AES in CBC mode) needs these 7x4 > clocks to decrypt the last block of the encrypted data (128 bits). > Am I right ? > >From this web page: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation "[in] CBC ... the message must be padded to a multiple of the cipher block size." The block size is 128 bits in this case. Regards, AllanArticle: 138392
On Feb 18, 12:50=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > Yesterday, the nice marketing people from Gennum informed me that, in > their unbiased opinion, their GN4124 PCI Express to Local Bus bridge > chip is the finest solution that the world has ever seen for connecting > an FPGA as a PCIe endpoint, and that anyone trying to do so any other > way is sadly misguided, and will in future years be looked back on > as a group with flat Earth believers and Chicago Cubs fans. > > The surface level stuff I've had a chance to look over on the chip is > pretty interesting. =A0At first glance, it should have no trouble handlin= g > my needs for about a 1 Gbps average throughput and should be pretty > straightforward. =A0But before I get too far into the depths of the > restricted datasheets, driver code samples, provided Verilog, etc, I > figured I'd go on a quick CAF fishing trip. > > Anyone had any experiences with the GN4124? =A0Or alternatively, with the > PEX8311 by PLX, which is the only other chip I've managed to find that > performs a similair task? =A0The ultimate project goal is going to be a > PCIe card with an FPGA talking to a mini-ITX running Linux, and I'm > likely going to be the one doing the coding on all ends. =A0Total project > run's only likely about 200, 250 pieces, so it's easier to spend BOM > money than it is to buy expensive IP or spend weeks and weeks of extra > coding. > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order Hi, Rob. If you're doing an embedded solution, you should check out Xilinx' EDK. The Virtex-5 FXT devices have a built-in PowerPC that can run Linux, and Xilinx' EDK has a PCIe -> processor local bus IP block. I haven't used it, but it seems to me that putting all this stuff in a single chip would be a good thing--especially when you can leverage the EDK.Article: 138393
>From InsideDSP: http://www.insidedsp.com/Articles/tabid/64/articleType/ArticleView/articleId/294/Default.aspx "Specific chip pricing has not yet been disclosed, but Xilinx says it will be in the range of $2-$35 for Spartan-6 and $57-$2100 for Virtex-6. This pricing is for large quantities in the second half of 2011, which is when the chips are expected to go into volume production." Second half of 2011???? It's a long wait! Luiz CarlosArticle: 138394
On Feb 19, 1:38=A0pm, oen_br <oen_no_s...@yahoo.com.br> wrote: > From InsideDSP:http://www.insidedsp.com/Articles/tabid/64/articleType/Art= icleView/ar... > > "Specific chip pricing has not yet been disclosed, but Xilinx says it > will be in the range of $2-$35 for Spartan-6 and $57-$2100 for > Virtex-6. This pricing is for large quantities in the second half of > 2011, which is when the chips are expected to go into volume > production." > > Second half of 2011???? > It's a long wait! > > Luiz Carlos well it says: expected :) if something doesnt go so well, the expected will be shifting even further away into the future i wonder if S3A ALL devices will be shipping in H1 2011? or maybe they will be already be obsoleted by that. S3A VQ100 seems to be still unavailable... AnttiArticle: 138395
Brad,
Your post actually contains two distinct, yet related, questions:
Question 1: does an if-elsif-elsif...-else statement always implement
a priority encoder?
Not always. Good synthesis tools will try to evaluate if all branch
conditions are mutually exclusive. If they indeed are, the synthesis
tool will build parallel logic, identical to the logic built from a
VHDL case statement or a truly full Verilog case statement.
Here is an example for when good synthesis tools will produce parallel
logic from an if-elsif statement:
if A="01" then
Z <= I1;
elsif A="10" then
Z <= I2;
else
Z <= I3;
Indeed, it is obvious that there is no overlap between the conditions.
Now, here is an example where a priority encoder will be inferred.
(Note: A and B are primary inputs to the design) :
if A="1" then
Z <= I1;
elsif B="1" then
Z <= I2;
else
Z <= I3;
Indeed, since are primary inputs to the design, there is no
information that tells that A and B might be mutually exclusive.
Question 2: how can I build parallel logic when, by design, my
conditions are mutually exclusive?
One solution consists in grouping the conditions into a single vector,
and using "don't care" assignments to indicate that the vector is in
fact one-hot. In the above example, if A and B are mutually exclusive
(implying the else condition is useless), you could recode it as:
COND <= A & B; -- VHDL concatenation
case COND is
when "01" =>
Z <= I1;
when "10" =>
Z <= I2;
when others =>
Z <= "--"; -- VHDL don't care assignment
end case;
Et voila!
Finally, to relate closely to your example:
- A is "state(33) or state(34) or state(35) or state(36)"
- B is "state(37)"
Hope that helps,
- gael
Article: 138396On Feb 18, 8:47=A0pm, Jim Lewis <j...@synthworks.com> wrote: > Gabor> If it were Verilog I would use a case statement and > > add "// synthesis parallel-case" to remove the priority > > logic. =A0Since this is a synthesis directive, it might > > also work in VHDL? > > If your assumption was wrong, would you expect to > get any warnings before implementing your chip? > The point is that the OP has exactly the case where he knows his assumption is correct and wants to tell the synthesizer. I pointed out how to do it in Verilog. There may be other ways in VHDL. In general I don't use parallel_case or full_case unless I understand the design. In such cases I don't want warnings to remind me that it is possible to make errors, just reduce my logic and move on! > See Cliff's paper titled, > "full_case parallel_case", the Evil Twins of Verilog Synthesis > > at: =A0http://www.sunburst-design.com/papers/ > > Cheers, > Jim > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jim Lewis =A0 =A0SynthWorks VHDL Training =A0 =A0http://www.synthworks.co= m > > A bird in the hand may be worth two in the bush, > but it sure makes it hard to type.Article: 138397
On Thu, 19 Feb 2009 03:06:48 -0800 (PST) zazpximytig@gmail.com wrote: > On Feb 18, 12:50=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > > Yesterday, the nice marketing people from Gennum informed me that, > > in their unbiased opinion, their GN4124 PCI Express to Local Bus > > bridge chip is the finest solution that the world has ever seen for > > connecting an FPGA as a PCIe endpoint, and that anyone trying to do > > so any other way is sadly misguided, and will in future years be > > looked back on as a group with flat Earth believers and Chicago > > Cubs fans. > > > > The surface level stuff I've had a chance to look over on the chip > > is pretty interesting. =A0At first glance, it should have no trouble > > handling my needs for about a 1 Gbps average throughput and should > > be pretty straightforward. =A0But before I get too far into the > > depths of the restricted datasheets, driver code samples, provided > > Verilog, etc, I figured I'd go on a quick CAF fishing trip. > > > > Anyone had any experiences with the GN4124? =A0Or alternatively, with > > the PEX8311 by PLX, which is the only other chip I've managed to > > find that performs a similair task? =A0The ultimate project goal is > > going to be a PCIe card with an FPGA talking to a mini-ITX running > > Linux, and I'm likely going to be the one doing the coding on all > > ends. =A0Total project run's only likely about 200, 250 pieces, so > > it's easier to spend BOM money than it is to buy expensive IP or > > spend weeks and weeks of extra coding. > > > > -- > > Rob Gaddi, Highland Technology > > Email address is currently out of order >=20 > Hi, Rob. If you're doing an embedded solution, you should check out > Xilinx' EDK. The Virtex-5 FXT devices have a built-in PowerPC that can > run Linux, and Xilinx' EDK has a PCIe -> processor local bus IP block. > I haven't used it, but it seems to me that putting all this stuff in a > single chip would be a good thing--especially when you can leverage > the EDK. Gave it some looking at, but a bridge chip + Spartan 3A is about a tenth the cost of a V5FX answer. Even counting the $400 SBC, doing it all in the FPGA is twice the price, and means that I'm having to put together the entire system (Ethernet, SATA, RAM, etc), rather than having all of the "build a computer" part of the project come built in a box. --=20 Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 138398
Well through trial and terror I finally have a reasonable "hello
world" program that I think is worthy. Thanks goes out big time to
Jonathan Bromley and Rick for all their input.
Jonathan's finite state machine, JB_Data_Generator in combination with
the UART example from Xilinx were the combination that allows a
programmer to get his first program fpga program running where he can
print "hello world" onto a screen via the UART port.
I added a few bells and whistles to make the program test the FPGA
board as well, pushbuttons as well as keyboard entry (via the uart
port) are all explored.
the heart of the processor of the messages is the JB_DATA_GENERATOR,
which can process a commanded string
of messages. Here is my final test commanded string:
generic map
( PC_bits => 9
, the_program =>
-- Long startup delay
op_DELAY & 200
& --2 bytes long
-- Welcome message
op_MESSAGE & tua(LF& "program begin 090219 jl02-11
label jump"&LF) & EOM &
op_LABEL & 01 &
op_MESSAGE & tua("wait for +"&LF) & EOM &
-- Wait for a "+" from the keyboard...
op_WAIT_FOR_CHAR & tua("+") &
-- and then print another message
op_LABEL & 02 &
op_MESSAGE & tua("abc wait for -"&LF) & EOM &
-- Wait for a "-" from the keyboard
op_WAIT_FOR_CHAR & tua("-") &
op_MESSAGE &tua("wait for button push"&LF) &EOM &
-- and then go back to the beginning! - no delay this
time.
op_WAIT_FOR_LBL & -- new test here! lets see if we
can get this to work
op_LABEL & 03 &
op_MESSAGE & tua("the left button has been pushed.
thank you "&LF) & EOM &
op_WAIT_FOR_LBL &
op_LABEL & 04 &
op_MESSAGE & tua("right pb has been pushed. your
welcome."&LF) & EOM &
op_WAIT_FOR_LBL &
op_HALT
)
The big thing that was added to JB's base program was the op_LABEL and
OP_WAIT_FOR_LBL commands.
the model now allows for any number of messages to be added using the
3-tupple: LABEL, MESSAGE, WAIT_FOR_LABEL.
The result is, when the calling process sets the label (in my case
either 2, 3, 4) the corresponding message will print. I hooked up
labels 3 and 4 to the pushbuttons left and right respectively,
debounced the inputs, waited for the falling edge of the pushbutton,
and then signaled the process JB_DATA_GENERATOR to print the correct
message. Here is the sample output copied from a terminal session:
program begin 090219 jl02-11 label jump
wait for +
abc wait for -
wait for button push
right pb has been pushed. your welcome.
right pb has been pushed. your welcome.
right pb has been pushed. your welcome.
the left button has been pushed. thank you
right pb has been pushed. your welcome.
the left button has been pushed. thank you
right pb has been pushed. your welcome.
In the data_generator I ran into a bit of problem not realizing the
parallel nature of the value updates. when
trying to use a created index, I need to wait a clock cycle in order
for the update to the index to take effect. So I originally wrote the
wait for label jump as so:
when waiting_for_lbl =>
if (lbl_data /= x"00") then
lbl_needed <= '0';
temp_label_index <= to_integer(unsigned(lbl_data(3
downto 0)));
PC <= the_label(temp_label_index); --lbl
gen_state <= new_PC;
end if;
but strange things were happening. PC was being updated with the
value of the_label(0) rather than
the_label(2|3|4) By putting things on the testbench and simulating
the putton push, I could see that
temp_label_index and PC were both updated at the same time, and the
new value of temp_label_index was
not "in effect" to the next clock cycle. To fix the problem, I
changed waiting_for_lbl to a two clock cycle implementation as such:
when waiting_for_lbl =>
if (lbl_data /= x"00") then
lbl_needed <= '0';
temp_label_index <= to_integer(unsigned(lbl_data(3
downto 0)));
gen_state <= waiting_for_lbl2;
end if;
when waiting_for_lbl2 =>
PC <= the_label(temp_label_index); --lbl
gen_state <= new_PC;
temp_label_index <= 0;
Now, this print is far from bulletproof. Most evil is that the if two
signals to print come in at the same time, only the first one prints,
and the second gets ignored. some sort of queue or wait state needs
to be build for this to be fixed, but alas, Its looking like I'm going
to be put on a new project on Monday, so this one will be regulated to
non-billable hours.
Article: 138399
On Feb 18, 5:39 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> Dear FPGA group,
>
> I have a state machine done with one flag for each state.
> Most of the states are sequential accomplished with a default assignment:
> signal state : std_logic_vector(0 to 61);
> begin
> if(clk'event and clk='1')then
> state<='0'&state(0 to 60);
> etc.
> There are some variations to this sequential flow.
>
> Elsewhere I assign data paths to these states like this:
> if(clk'event and clk='1')then
> if state(33 to 36)>0 then
> mem_out<=a;
> elsif state(37)>0 then
> mem_out<=b;
> etc.
>
> The elsif are a bit long and have unnecessary priority
> logic since state(33 to 36) trumps state(37).
> This happens although I can be very sure that the states
> are mutually exclusive by design.
>
> I am using Xilinx ISE9.2, ModelSim, and an ML402 kit.
>
> I am of the understanding that a series of "if end if"
> statements would only serve to put the priority on the
> last "if end if" statement and therefore would still
> result in a chain of priority logic.
>
> So my question is how to get rid of the priority logic?
> If I have to resort to a case statement, how do I code
> this succinctly with this long state vector?
> And is there some other way to do it,
> perhaps with a variable?
Using "one flag for each state" is also called "one-hot" encoding.
This means N states are encoded with N bits, all mutually exclusive.
I do this all the time and I prefer to not use IF or CASE statements.
The logic for each bit in one-hot encoding is very simple. The bit is
true if the bit is false AND any of the input conditions are true OR
if the bit is true AND all of the output transitions are false. So
instead of a long case statement or a deep IF statement, you can just
use a single assignment for each state variable defining each input
and each output condition...
if(clk'event and clk='1')then
if state(33) = '0' then -- enter this state
state (33) <= inputA and state(31) or
inputB and state (32) or
inputC and state(34);
else -- leave this state
state (33) <= not (inputD or inputE);
endif;
if state(34) = '0' then -- enter this state
state (34) <= inputD and state(33);
else -- leave this state
state (34) <= not inputE;
endif;
if state(35) = '0' then -- enter this state
state (35) <= inputD and state(33) or inputE and state(34);
else -- leave this state
state (35) <= not inputF;
endif;
...
"Good synthesis tools will try to evaluate if all branch
conditions are mutually exclusive. If they indeed are, the synthesis
tool will build parallel logic"
The key here is the term "Good synthesis tools". That requires you to
put your faith in the tools, no matter which tools are being used.
Also, you might want to use descriptive names for the indexes of
state, such as state (memory_read).
Rick
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