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
Do you know any?Article: 58576
pagercam@yahoo.com (Mark Sandford) writes: > NOR flash requires larger write (and erase blocks), NAND is cheaper > but not entirely stable reading from one "page" can generate errors on > other pages. Perhaps writing to one page could generate errors on another page, but I've never observed that. Reading a page does not affect any other page. > As far as I know Toshiba only makes NAND. I seem to recall Sandisk, Samsung, and other companies making NAND as well.Article: 58577
On Thu, 24 Jul 2003 18:35:25 GMT, "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote: >Anyhow. I'll give you a specific example here. I wrote a SDRAM controller > >... etc > >Pretty basic stuff. > >That worked very nicely on an XC2V1000 @ 133MHz. I should note that the >only timing constraint I defined was period @ 7.5188ns. > >Later on I decided that it would be better to have variable burst length (my > >... etc > >All timing constraints for the design were met, but this did not work. >Again, the only thing I did was change from an up to a down counter and >modify the terminal condition. Normal good design practice. Synchronous design, timespecs covering the logic in that clock domain. Tragically, I suspect the problem might be with the timespec. The period you have specified matches frequency of operation. The problem I suspect is not the quality of the design, but the reliability of the timing analyzer to "get it right". I am not talking here of gross errors, but rather of poor handling of 100% coverage, poor handling of skew and jitter, and poor handling of reporting what has been implemented. The rule of thumb that I have used (whenever possible) is to always set my timespecs 10% tighter than needed, or 1 to 2 ns, depending on frequency of operation. This extra margin (assuming that P&R is able to meet the tighter spec) seems to result in avoiding problems like this. For your application, I would suggest trying a 7.0 ns goal, and removing the area constraints. The other thing I would check is to run the timing analyzer with "report unconstrained paths" enabled, and see if your timespecs are really covering all your logic. If it cant meet the 7.0 ns goal without the area constraint, then try both together. >In looking at the floorplanner I could see that the sdram controller logic >was all over the place. Adding an area constraint forced the logic into a >tighter space and it all worked fine. What this may have done is improved the margin on paths that are just barely meeting the timespec without the area constraint. Or maybe there are paths that are not constrained (timing) and by forcing them into a restricted area, you are now (luckily?) meeting the unspecified timing requirements. I would not let this issue sleep, even though it seems to be working currently. You should try and understand the root cause, otherwise you may get bitten by this again, next time you run P&R. >Perhaps I don't fully understand the mechanism. I told the tools that the >module is clocked at 133MHz. The tools said that timing looked good after >P&R. I have less trust. >If there were any timing issues (which I obviously had) why didn't it >report them? Check unconstrained paths, which is NOT displayed by default. Look at the detailed timing report. Do you have paths that are just meeting your 7.5188ns spec. What would happen if the timing analyzer was off by 200ps, and your paths were 200ps longer. What if the clock has 200 ps jitter, or maybe 500ps? >Both sdram controller versions had perfectly good HDL that >simulated with exactly the same results. > >More than eager to learn... > >Thanks, Philip Freidin Philip Freidin FliptronicsArticle: 58578
Philip, Thanks for the pointers. I'll enable unconstrained paths and see what comes out. Question regarding reducing the 133MHz period constraint by 10%. Funny enough, I had already tried this ... and did use the 7ns you suggested. Both the up and down counter versions worked with this constraint. I know that the period constraint is followed across DCM boundaries. This is where I wasn't sure where to go. I'm only using the DCM to phase align to the incoming 133MHz clock (I only use the CLK0 output with feedback). I have a period specification in the DCM instantiation. Should this period be specified at 7ns as well? What effect does this have on DCM operation (jitter, locking?). Thanks, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Philip Freidin" <philip@fliptronics.com> wrote in message news:2k88iv0u8v6onj9uddb0vm0lvvtu2ll0nb@4ax.com... > On Thu, 24 Jul 2003 18:35:25 GMT, "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote: > >Anyhow. I'll give you a specific example here. I wrote a SDRAM controller > > > >... etc > > > >Pretty basic stuff. > > > >That worked very nicely on an XC2V1000 @ 133MHz. I should note that the > >only timing constraint I defined was period @ 7.5188ns. > > > >Later on I decided that it would be better to have variable burst length (my > > > >... etc > > > >All timing constraints for the design were met, but this did not work. > >Again, the only thing I did was change from an up to a down counter and > >modify the terminal condition. > > Normal good design practice. Synchronous design, timespecs covering > the logic in that clock domain. > > Tragically, I suspect the problem might be with the timespec. The period > you have specified matches frequency of operation. The problem I suspect > is not the quality of the design, but the reliability of the timing > analyzer to "get it right". I am not talking here of gross errors, but > rather of poor handling of 100% coverage, poor handling of skew and jitter, > and poor handling of reporting what has been implemented. The rule of thumb > that I have used (whenever possible) is to always set my timespecs 10% > tighter than needed, or 1 to 2 ns, depending on frequency of operation. > This extra margin (assuming that P&R is able to meet the tighter spec) > seems to result in avoiding problems like this. > > For your application, I would suggest trying a 7.0 ns goal, and removing > the area constraints. The other thing I would check is to run the timing > analyzer with "report unconstrained paths" enabled, and see if your > timespecs are really covering all your logic. > > If it cant meet the 7.0 ns goal without the area constraint, then try > both together. > > >In looking at the floorplanner I could see that the sdram controller logic > >was all over the place. Adding an area constraint forced the logic into a > >tighter space and it all worked fine. > > What this may have done is improved the margin on paths that are just > barely meeting the timespec without the area constraint. Or maybe there > are paths that are not constrained (timing) and by forcing them into > a restricted area, you are now (luckily?) meeting the unspecified timing > requirements. > > I would not let this issue sleep, even though it seems to be working > currently. You should try and understand the root cause, otherwise you > may get bitten by this again, next time you run P&R. > > >Perhaps I don't fully understand the mechanism. I told the tools that the > >module is clocked at 133MHz. The tools said that timing looked good after > >P&R. > > I have less trust. > > >If there were any timing issues (which I obviously had) why didn't it > >report them? > > Check unconstrained paths, which is NOT displayed by default. > Look at the detailed timing report. Do you have paths that are just > meeting your 7.5188ns spec. What would happen if the timing analyzer > was off by 200ps, and your paths were 200ps longer. What if the clock > has 200 ps jitter, or maybe 500ps? > > >Both sdram controller versions had perfectly good HDL that > >simulated with exactly the same results. > > > >More than eager to learn... > > > >Thanks, > > Philip Freidin > > > Philip Freidin > FliptronicsArticle: 58579
"Hal Murray" <hmurray@suespammers.org> wrote in message news:vi696r3lcomv19@corp.supernews.com... > >The only 64 bit polynomial that I know of, (listed in Numerical Recipes if > >one is interested) has very few 1's, so should be convenient for > >implementing. (snip) > The polynomial and logic were designed at DEC. I'm pretty sure > they idn't do anything to minimize the number of bits in the > polynomial. I am not sure why it is that way, but it is. I don't completely understand the process for generating primitive polynomials. My understanding is that it gets harder as they get bigger. It might be that someone found some relatively simple large ones that work well enough. The properties may not be as good as CRC32 overall, though. It happens that the 64 bit polynomial in Numerical Recipes (and the only one I know of) has relatively few ones. -- glenArticle: 58580
Jon Masters <jonathan@jonmasters.org> wrote in message news:<vi7lc8p5i8su25@corp.supernews.com>... > Hi, > > I am after a book with a title something along the lines of > > ``VHDL for Software Engineers'' > > Finding a suitable book seems pretty challenging as most assume either > the reader is an experienced electrical engineer or that they are a > complete novice coming in. I have years of Computer Science background > and am trying to become more aquainted with the actual hardware design. > > FWIW the Linux port I mentioned before has now progressed further and I > am in the process of adding support for various Xilinx devices. > > Jon. I would suggest the classic "HDL Chip Design" By Doug Smith. It covers synthesizeable HW design and how to do it for many good examples with side be side Verilog, VHDL, schematics for each. Its a reference level rather that intro to HW design. Most of the other books I have on Verilog (and I assume VHDL) spend way too much time on learning multiple ways to create behavioural code that doesn't synthesize and is more like par SW programming. Even when they do get to HW level its too late & the examples too far removed from common HW situations. Since VHDL is so connected to ADA, perhaps an ADA book will help show why it looks the way it does, even though that has little to do with HW. JJArticle: 58581
On Sun, 27 Jul 2003 20:17:54 GMT, "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote: >Philip, > >Thanks for the pointers. I'll enable unconstrained paths and see what comes >out. > >Question regarding reducing the 133MHz period constraint by 10%. Funny >enough, I had already tried this ... and did use the 7ns you suggested. >Both the up and down counter versions worked with this constraint. Which is a an indication that the lack of safety margin is the issue. But you should still check for unconstrained paths (which you say above that you will be doing) >I know that the period constraint is followed across DCM boundaries. This >is where I wasn't sure where to go. I'm only using the DCM to phase align >to the incoming 133MHz clock (I only use the CLK0 output with feedback). The DCM adds jitter to your clock too. >I >have a period specification in the DCM instantiation. Should this period be >specified at 7ns as well? What effect does this have on DCM operation >(jitter, locking?). Don't know. >Thanks, Keep working on it, Regards, Philip Philip Freidin FliptronicsArticle: 58582
Hi Peter, I've got the Developer's Kit V2PDK VP4. I wanted to run the reference designs and test the results via the serial port. I tried and got nothing in the HyperTerminal. Does XST work for the synthesis ? If so, what modifications do I have to make ? (I was told that the only way is to get Synplify synthesis tool) Thanks Lan Peter Ryser <ryserp@xilinx.com> wrote in message news:<3F1F1FE4.B2A8FCB1@xilinx.com>... > Yes, it does. The reference design actually comes with the MLD (Microprocessor > Library Definition) technology that allows you to automatically generate a BSP > for Linux consisting of Xilinx layer 0 and 1 drivers according to the hardware > definition (MHS). When you generate the libraries from the system_linux.xmp > project file you will get this BSP. > > The BSP will also contain necessary patches to the Linux kernel to make the > design work with MontaVista Linux 3.0 (FYI: the only thing that needs to be > patched is the code for the Xilinx interrupt driver since the interrupt > controller from V2PDK and EDK are different) > > - Peter > > > tk wrote: > > > Hi Peter, > > > > I would like to ask if the reference design support > > MontaVista Linux Pro 3.0 ? > > > > Thanks very much! > > > > tk > > > > Peter Ryser wrote: > > > > > Antti, > > > > > > the EDK reference design for ML300 contains > > > - 1 PPC 405 > > > - 1 PLB DDR > > > - 1 PLB bus with arbiter > > > - 1 PLB2OPB bridge > > > - 1 PLB BRAM controller with 32 KB BRAM attached > > > - 1 OPB Uart > > > - 2 OPB GPIO > > > - 1 OPB 10/100 Ethernet (interrupt driven) > > > - 1 OPB IIC > > > - 1 OPB System ACE CF > > > > > > There is no touchscreen, PS/2, TFT, parallel port and AC97. Adding these > > > peripherals to the design is planned for a later release that will most > > > likely happen towards the end of the year. > > > > > > There is some documentation in the zip file that lists the peripherals and > > > explains the design. > > > Again, please contact your Xilinx FAE if you would like to get access to > > > this design. > > > > > > Thanks, > > > - Peter > > > > > > > > > > > > Antti Lukats wrote: > > > > > >> Peter Ryser <ryserp@xilinx.com> wrote in message > > >> news:<3F1846C0.776CD1F5@xilinx.com>... > > >> > > > >> > If you want to work with EDK please contact your FAE and ask him to get > > >> > you access to the EDK reference design for ML300. He will be able to > > >> > get you access to the design. > > >> > > >> Hi Peter, > > >> > > >> when we received the EDK + DDR project, I also asked to be notified > > >> when a better EDK ref. design will be available, and so far have not > > >> got any more info, could you please enlight us what additional cores > > >> are available in the EDK ref. design you mentioned? > > >> > > >> ASFAIK TFT and Touchscreen are not implemented (or hopefully are now?) > > >> I have still having trouble to get EDK to work correctly using the > > >> obsoleted TFT ref. design - eg. display is looking in stripes 8 pixels > > >> missing after 8 ok pixels - if the problem is fixed and ref design > > >> availabl would be greate. > > >> > > >> anttiArticle: 58583
hln01@uow.edu.au (Lan Nguyen) wrote in message news:<70360b52.0307271802.7509c4db@posting.google.com>... > Hi Peter, > > I've got the Developer's Kit V2PDK VP4. I wanted to run the reference > designs and test the results via the serial port. I tried and got > nothing in the HyperTerminal. > > Does XST work for the synthesis ? If so, what modifications do I have > to make ? > > (I was told that the only way is to get Synplify synthesis tool) Hi Lan, yes and no - V2PDK was targetted for synplify synthesis but you can use portions of the reference platforms also with XST synthesis --- flow.cfg --------- # Synthesis (Synplify) #SYN_TOOL = synplify #SYN_CMD = synplify # synplify / synplify_pro # add -batch to SYN_OPT to invoke synplify in batch mode (non-GUI) #SYN_OPT = # inferred (synplify): <none> # Synthesis (XST) SYN_TOOL = xst SYN_CMD = xst SYN_OPT = -hierarchy_separator / -keep_hierarchy Yes -opt_level 2 -opt_mode area -iobuf no # inferred (xst): <none> ----- end cut --- above is the modified flow.cfg notice: you can use XST for the simple vhdl design only for the embedded_vhdl it will not work, only verilog version works and there you need to disable most of the peripherelas (at the end of flow.cfg) to get it to fit into VP7 antti PS has anybody seen the ref. design Peter has talking about?Article: 58585
http://tech-www.informatik.uni-hamburg.de/vhdl/ http://tech-www.informatik.uni-hamburg.de/vhdl/models/gl85/gl85.tar.gz Note that code uses, bit and logic_vector as data types. You can convert these to std_logic, and std_logic_vector! -dasari "Saeed Nari" <saeed@ce.sharif.edu> wrote in message news:<bfr0ni$oa7$1@balder.stud.idb.hist.no>... > Hi, VHDL friends > Does anyone have a synthesizable gl85, or i8085 VHDL > design? I have them, but can't synthesize with leonardo or synopsis. > Please reply to this address. Thank you a lot!Article: 58586
Hi, Do you mean academic or industrial research fields? I know an important field in industrial domain : Signal integrity for very high speed routes INSIDE fpgas. By the way, do you want this info for rsearch in university or other? I propose you to build a home page and collect active research areas in FPGA, categorize areas to chip design (coding), system design, synthesis, test and debug, manufacturing, signal propagation and .... If you want more info please let me know. Regards, Masoud Naderi. lenz19@gmx.de (lenz) wrote in message news:<7f673150.0307270954.1f6256ab@posting.google.com>... > Hi, > > I would like to know what the actual/future FPGA research topics are. > I found a lot of research papers concerning the following topics: > > - low power designs > - asynchronous desings > - software radio > - neural networks > - dynamic reconfiguration > - evolvable hardware > - field programmable analog array > > Are these topics still research fields ? > What are the future research fields ? > > > Thanks in advance.Article: 58587
Hi, I'm now finding the way to contact "my FAE" ..... I really hope that Peter can me a copy of it ... bcoz I've spent one week modifying the reference design (just wanna remove the AC97 and PCI) but failed .... the Linux can't boot ...... tk "Antti Lukats" <antti@case2000.com> wrote in message news:80a3aea5.0307272123.2567fa16@posting.google.com... > hln01@uow.edu.au (Lan Nguyen) wrote in message news:<70360b52.0307271802.7509c4db@posting.google.com>... > > Hi Peter, > > > > I've got the Developer's Kit V2PDK VP4. I wanted to run the reference > > designs and test the results via the serial port. I tried and got > > nothing in the HyperTerminal. > > > > Does XST work for the synthesis ? If so, what modifications do I have > > to make ? > > > > (I was told that the only way is to get Synplify synthesis tool) > > Hi Lan, > > yes and no - > V2PDK was targetted for synplify synthesis but you can use portions > of the reference platforms also with XST synthesis > > --- flow.cfg --------- > # Synthesis (Synplify) > #SYN_TOOL = synplify > #SYN_CMD = synplify # synplify / synplify_pro > # add -batch to SYN_OPT to invoke synplify in batch mode (non-GUI) > #SYN_OPT = # inferred (synplify): <none> > > # Synthesis (XST) > SYN_TOOL = xst > SYN_CMD = xst > SYN_OPT = -hierarchy_separator / -keep_hierarchy Yes -opt_level 2 > -opt_mode area -iobuf no # inferred (xst): <none> > > ----- end cut --- > above is the modified flow.cfg > > > notice: you can use XST for the simple vhdl design only for the > embedded_vhdl it will not work, only verilog version works and there > you need to disable most of the peripherelas (at the end of flow.cfg) > to get it to fit into VP7 > > antti > PS has anybody seen the ref. design Peter has talking about?Article: 58588
Hi if someone wants to play ZX spectrum games on V2Pro ML300 (or some other Virtex + TFT LCD system) I do have a almost functional reference desing. it is basically zxgate.sourceforge + T80.opencores I only changed the Video to work with TFT LCD on ML300 and made some of the vhdl units (Z80 cpu, etc) as Coregen Installable IP (speeds up the bitstream generation a great deal) The top level is Xilinx Schematics, also available are batch files that compile open source ZX roms to binary and convert it to the systemACE files ready to be copied to CompactFlash/Microdrive. current status: ROM Basic does mem check and shows copyright message PS2 keyboard does not work (dont know why) sound and joystick not implemented yet (I had an idea to use AC97 for sound, ie doing digital integration and filtering of the 1 bit sound output) If somebody would like to troubleshoot the PS2 interface I would send the all project. antti PS the low res color TFT LCD module can be used separatly for other purposes :)Article: 58589
My son accidentally erase my system disk 2/3. My current system is 5.50. If someone can send me corresponding disk image or later system release disks, it would be nice. thanx in advance. Hooga (NOSPAMhooga@bigfoot.com)Article: 58590
"Saeed Nari" <saeed@ce.sharif.edu> wrote in message news:<bfr0ni$oa7$1@balder.stud.idb.hist.no>... > Hi, VHDL friends > Does anyone have a synthesizable gl85, or i8085 VHDL > design? I have them, but can't synthesize with leonardo or synopsis. > Please reply to this address. Thank you a lot! the original from hamburg vhdl is probably not fully working at least there is one modified version that claims severl problems beeing fixed this modified version synthesis OK, see below: ----------- Writing NGDBUILD log file "i8085_c.bld"... NGDBUILD done. Completed process "Translate". Started process "Map". Using target part "2vp7ff672-6". Removing unused or disabled logic... Running cover... Running directed packing... Running delay-based LUT packing... Running related packing... Design Summary: Number of errors: 0 Number of warnings: 1 Logic Utilization: Number of Slice Flip Flops: 317 out of 9,856 3% Number of 4 input LUTs: 3,614 out of 9,856 36% Logic Distribution: Number of occupied Slices: 1,876 out of 4,928 38% Number of Slices containing only related logic: 1,876 out of 1,876 100% Number of Slices containing unrelated logic: 0 out of 1,876 0% *See NOTES below for an explanation of the effects of unrelated logic Total Number 4 input LUTs: 3,622 out of 9,856 36% Number used as logic: 3,614 Number used as a route-thru: 8 Number of bonded IOBs: 45 out of 396 11% IOB Flip Flops: 18 Number of GCLKs: 3 out of 16 18% Total equivalent gate count for design: 25,801 Additional JTAG gate count for IOBs: 2,160 ---------------- http://simlab.eecs.tufts.edu/simlab/html/8085_mod.html the report was for code downloaded from above link anttiArticle: 58591
Hello, I'm looking for a programing interface (cheap, selfmade)for a xilinx FPGA (e.g. XCS10-3). Does anybody know some links for a interface? Thanks MichaelArticle: 58592
"tk" <tokwok@hotmail.com> wrote in message news:<bg2n50$b1e$1@www.csis.hku.hk>... > Hi, > > I'm now finding the way to contact "my FAE" ..... > > I really hope that Peter can me a copy of it ... > bcoz I've spent one week modifying the reference > design (just wanna remove the AC97 and PCI) > but failed .... the Linux can't boot ...... hm,, using XST Verilog following peripheral can be used USER_USE_DDR = yes # use "no" for no DDR, "yes" to include DDR Controller USER_USE_TFT = yes # use "no" for no TFT, "yes" to include TFT Display USER_USE_IIC = no # use "no" for no IIC, "yes" to include IIC USER_USE_U450 = yes # use "no" for no U450, "yes" to include 16450 Uart USER_USE_U550 = yes # use "no" for no U550, "yes" to include 16550 Uart USER_USE_PCI = no # use "no" for no PCI, "yes" to include PCI USER_USE_AC97 = yes # use "no" for no AC97, "yes" to include AC97 USER_USE_ENET = no # use "no" for no Enet, "yes" to include Enet USER_USE_PS2 = no # use "no" for no PS/2, "yes" to include PS/2 USER_USE_SPI = no # use "no" for no SPI, "yes" to include SPI USER_USE_TSD = yes # use "no" for no TSD, "yes" to include Touch Screen USER_USE_PP = no # use "no" for no PP, "yes" to include Parallel Port USER_USE_SACE = yes # use "no" for no SACE, "yes" to include System ACE USER_USE_ILA = no # use "no" for no ILA, "yes" to include ILA USER_USE_BGI = no # use "no" for no BGI, "yes" to include OPB-PLB Bridge this defenetly works, and I guess it should be ok for linux boot? ok, if you want networking then you are out luck with XST but as you got synplify there should not be problems? antti PS if you get hold on your FAE please let me know too! I am trying to get hold of mine but so far getting no response at all :(Article: 58593
Michael Petry wrote: > > Hello, > I'm looking for a programing interface (cheap, selfmade)for a xilinx > FPGA (e.g. XCS10-3). Does anybody know some links for a interface? > Thanks > Michael > > Or maybe, the Chameleon POD can be a good opportunity for you, because it can be use as a nice CPLD dev. kit as the UNIQUE Universal JTAG POD for only $129.- In fact, it can be use to configure all FPGA (Altera, Xilinx), to configure ARM processors (wiggler, raven emulator), AVR processor. All JTAG configuration is coming for free. Same hardware, multi JTAG POD configurations ... the power of the reprogrammable logic starts with the Chameleon POD. Try www.amontec.com/chameleon.shtml LarryArticle: 58594
Thank you for the answer. I'm a student working part-time in a company as a fpga designer. My question was because of general interest. With your answers I hope to get a picture of future fpga architectures (like hybrid fpga architectures at University of Toronto) and future fpga applications. BTW, what is the difference between academic and industrial research ? Regards,Mark > Hi, > Do you mean academic or industrial research fields? I know an > important field in industrial domain : Signal integrity for very high > speed routes INSIDE fpgas. > By the way, do you want this info for rsearch in university or other? > I propose you to build a home page and collect active research areas > in FPGA, categorize areas to chip design (coding), system design, > synthesis, test and debug, manufacturing, signal propagation and .... > If you want more info please let me know. > Regards, > Masoud Naderi.Article: 58595
"Jon Masters" <jonathan@jonmasters.org> wrote in message news:vi7lc8p5i8su25@corp.supernews.com... > Hi, > > I am after a book with a title something along the lines of > > ``VHDL for Software Engineers'' > I really like "The Designer's Guide to VHDL" by Pter J Ashenden. Simple, complete and clear. http://www.amazon.com/exec/obidos/tg/detail/-/1558606742/qid=1059406696/sr=8-1/ref=sr_8_1/002-0539235-7329613?v=glance&s=books&n=507846Article: 58596
Michael, what do you mean by interface? Read the data sheet, and it tells you that you have to input a serial bitstream, and you can store this in many ways. The "interface" is the simplest possible, a data line and a clock. Peter Alfke, Xilinx Michael Petry wrote: > > Hello, > I'm looking for a programing interface (cheap, selfmade)for a xilinx FPGA > (e.g. XCS10-3). Does anybody know some links for a interface? > Thanks > MichaelArticle: 58597
"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:<EJWUa.144122$sY2.63223@rwcrnsc51.ops.asp.att.net>... > "Hal Murray" <hmurray@suespammers.org> wrote in message > news:vi696r3lcomv19@corp.supernews.com... > > >The only 64 bit polynomial that I know of, (listed in Numerical Recipes > if > > >one is interested) has very few 1's, so should be convenient for > > >implementing. > > (snip) > > > The polynomial and logic were designed at DEC. I'm pretty sure > > they idn't do anything to minimize the number of bits in the > > polynomial. > > I am not sure why it is that way, but it is. I don't completely understand > the process for generating primitive polynomials. My understanding is that > it gets harder as they get bigger. It might be that someone found some > relatively simple large ones that work well enough. I suspect that is the case. http://www.cs.ucl.ac.uk/staff/d.jones/crcnote.pdf discusses how the "sparse" 64-bit polynomial produced an abnormally high rate of collisions when used as a simple hash. Yes, I know it even a "good" CRC isn't really a good hash function, but that seem to be what they were using it as. > The properties may not > be as good as CRC32 overall, though. It happens that the 64 bit polynomial > in Numerical Recipes (and the only one I know of) has relatively few ones. In addition to the polynomial presented above, looks like one was standardized back in 1992: http://www.ecma-international.org/publications/standards/ECMA-182.HTM MarcArticle: 58598
Amontec Team <laurent.gauch@www.DELALLCAPSamontec.com> wrote in message news:<3F251C3E.6050905@www.DELALLCAPSamontec.com>... > Michael Petry wrote: > > > > Hello, > > I'm looking for a programing interface (cheap, selfmade)for a xilinx > > FPGA (e.g. XCS10-3). Does anybody know some links for a interface? > > Thanks > > Michael > > > > > Or maybe, the Chameleon POD can be a good opportunity for you, because > it can be use > as a nice CPLD dev. kit > as the UNIQUE Universal JTAG POD > for only $129.- Lauerent, I understand you need to make ads for Chameleon but if someone need so program xilinx with cheap and self made then Chameleon is out of the question - cheap is 5 resistors to LPT port, works fine for me I do have Parallel IV too, but for some target boards it is simpler to use 5 wires to LPT port self made cable as to make a flying leads adapter to Parallel IV same for Chameleon the time it is required to get the cable adapter (ok only wires) would be same as to solder 5 resitors to DB25 hood :) antti DB25 8 -- 11 --- 12 shortcircuit wire jumper 25 GND 4 -- R -- TMS 2 -- R -- TDI 13 -- R -- TDO 3 -- R -- TCK 15 -- R -- VCC 3 or 5V (power sense) if someone says it doesnt work I disagree I use it ever day with embedded Microblaze and ChipScope and the Parallel Cable IV has way more problems :(Article: 58599
I'm having a problem with the Coregen Asynch FIFO v5.1. The first time I try to read out the data I've written to the FIFO, I get a word of 0s and then the correct data words. I read the FIFO until it is empty, then write some more data to it. Now when I read, the first word that comes out is the last word of the preceeding write operation, not the first word of the data I want. For example (starting from hard reset with a 16-bit wide FIFO): First write operation - four 16 bit words: 'ab' 'cd' 'ef' 'gh' Read until empty - FIVE 16 bit words: 0x0000 'ab' 'cd' 'ef' 'gh' Second write operation - four 16-bit words: 'as' 'df' 'gh' 'jk' Second read operation - FIVE 16-bit words: 'gh' 'as' 'df' 'gh' 'jk' It looks to me like there is a bug with the pointers or something that is causing this problem. I am using the read acknowldegement flag to verify that these values are valid when I read them. Also I should note that this is occuring in hardware on an XESS development board with an XCV 300, not in simulation. I'm a newbie to FIFOs, but it looks to me like my stuff is correct - after all, I am reading the same value out of the FIFO twice when I've only written it once, so that looks like a problem with the FIFO. Any ideas or suggestions?
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