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
On Aug 7, 9:23=A0am, fmostafa <fatma.abouele...@ugent.be> wrote: > On Aug 7, 2:14 pm, John McCaskill <jhmccask...@gmail.com> wrote: > > > > > On Aug 7, 3:40 am, fmostafa <fatma.abouele...@ugent.be> wrote: > > > > hi all; > > > > I have a question about the system clk in EDK project, my processor > > > clk is 100 Mhz and my bus clk is 25Mhz , i tried to increase =A0the b= us > > > clk to =A050 Mhz , i did this by changing in the DCM , as i changed > > > the =A0CLKDV divisor to 2 instead of 4 , which means as i thought > > > (100/2) instead of (100/4), and cleaned the hardware and i stared to > > > generate the netlist and the bitstream but i don't know the uart is > > > not working in a right way , and of course i couldn't examine the res= t > > > of the system . > > > i don't know if what i did is right or there is something missed or > > > there is another way to change the frequency. > > > > thanks > > > fatma > > > There are several cores that need to have their parameters updated > > when you change the OPB/PLB bus speed. > > > The UART lite is one of these cores. =A0It has a parameter C_CLK_FREQ > > that needs to be set to the new frequency. =A0You can change it in the > > MHS file, or from the Configure IP GUI window under system/OPB. > > > There are other cores that need to be updated as well. I don't have a > > complete list of the, but serial IO cores, such as the UART and SPI > > cores, tend to generate baud rates or external clocks from the bus > > clock. > > > Regards, > > > John McCaskillwww.FasterTechnology.com > > hi John; > thanks for your reply , but i have another question in the > plb_bram_if_cntlr i think that i have to change the c_plb_period_ps, i > can't understand how to change this parameter. > > BEGIN plb_bram_if_cntlr > =A0PARAMETER INSTANCE =3D plb_bram_if_cntlr_1 > =A0PARAMETER HW_VER =3D 1.00.b > =A0PARAMETER c_plb_clk_period_ps =3D 20000 > =A0PARAMETER c_baseaddr =3D 0xfffe0000 > =A0PARAMETER c_highaddr =3D 0xffffffff > =A0BUS_INTERFACE SPLB =3D plb > =A0BUS_INTERFACE PORTA =3D plb_bram_if_cntlr_1_port > END > > thanks > fatma c_plb_clk_period_ps should just be the period of the PLB clock in pico seconds. If you want the PLB clock to be 50 MHz, then its period should be 20000 ps, so this looks correct. I believe that this setting is only used for design rule checks performed by the optional TCL file that accompanies this core, or for generating timing constraints. Some cores need to know the bus frequency so that they can generate another signal at the correct rate, while other cores want to know it for DRC or constraint generation. For more information, right click on the core in the system assembly window and select the data sheet PDF to read about the core. Regards, John McCaskill www.FasterTechnology.comArticle: 134376
On Aug 7, 6:16=A0pm, andersod2 <thechrisander...@gmail.com> wrote: > That error is given by the DOS shell when it can't find the command > you've typed.....are you using the default options for ISE (i.e. not > using a batch script)? =A0I know the commands they use aren't prefixed > with the xilinx directory which could create issues with the > path...but that seems screwy that it would hard code the map command > to a seperate directory like that...that's why I ask if you're using a > batch script...check your projects .cmd_log file, and your > paths...sorry if that doesn't help, as I'm a beginner as well to ISE. this is the default behavior of ISE i have never been able to finish working on a project in a version higher than 7.1 cause of this issue. Here's my .cmd_log file: xst -ise "C:/PROGS/FPGA/EE178/lab1/lab1" -intstyle ise -ifn two_input_xor.xst -ofn two_input_xor.syr ngdbuild -ise "C:/PROGS/FPGA/EE178/lab1/lab1" -intstyle ise -dd _ngo - nt timestamp -uc two_input_xor.ucf -p xc3s500e-fg320-4 two_input_xor.ngc two_input_xor.ngd map -ise "C:/PROGS/FPGA/EE178/lab1/lab1" -intstyle ise -p xc3s500e- fg320-4 -cm area -pr b -k 4 -c 100 -o two_input_xor_map.ncd two_input_xor.ngd two_input_xor.pcf xst -ise "C:/PROGS/FPGA/EE178/lab1/lab1" -intstyle ise -ifn two_input_xor.xst -ofn two_input_xor.syr ngdbuild -ise "C:/PROGS/FPGA/EE178/lab1/lab1" -intstyle ise -dd _ngo - nt timestamp -uc two_input_xor.ucf -p xc3s500e-fg320-4 two_input_xor.ngc two_input_xor.ngd map -ise "C:/PROGS/FPGA/EE178/lab1/lab1" -intstyle ise -p xc3s500e- fg320-4 -cm area -pr b -k 4 -c 100 -o two_input_xor_map.ncd two_input_xor.ngd two_input_xor.pcfArticle: 134377
On Aug 6, 12:31=A0pm, eromlignod <eromlig...@aol.com> wrote: > On Aug 6, 11:50=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > > > If you can map this onto a block ram, you will save quite a bit of > > registers. Whether or not you can do this depends on if you can write > > the vectors in one (or a few) at a time, and process them sequentially > > in the time you have available. =A0How much time do you have to process > > the vectors? Ns, us, ms ? > > Ah, I think I'm following along now. =A0Are you talking about sending > the numbers over a single 8-bit vector wire one-at-a-time? =A0Hmmm. > > The vectors are actually independent from each other and refresh at > various random rates, so a few usec here or there shouldn't make a > difference. =A0I'll give it a try! > > Don I changed the individual vectors to a single vector and now my slice count is down to 80% with 0% unrelated logic. Thanks! DonArticle: 134378
"andersod2" <thechrisanderson@gmail.com> wrote in message news:39e8b7cb-dffd-49f7-aaa8-82c907ef5f41@v1g2000pra.googlegroups.com... > >> If you want a low-cost board to experiment with both a Xilinx FPGA and >> a Cypress PSoC, try this $39 kit: >> >> www.em.avnet.com/spartan3a-evl >> > > > Yeah, I just ordered it...but 10-12 week backlog though :( Must be > popular.... I think their seminars get first crack at the supply on that line of product. Mine came just yesterday. Think of the long backlog as a bonus. I had completely forgotten that I ordered it. It was like Christmas in July (but a week later) when the FedEx guy rang the doorbell. It's a really great little board, well made physically and very well thought out, but it has one flaw. There's no RAM onboard, and the 256 pin package leaves only 35 usable lines on the I/O header. It's not enough for what I had in mind, but maybe enough for almost everything else you might try to do in just evenings. I was a little bummed about not checking the RAM size, but remembered just now that I had intended all along to use an AP7 to drive the TFT and USB. That's just as well. There isn't room on the S3-400A for a Microblaze and everything else it needs to do. I'm happy again; maybe happy enough to order 2 more just to keep around as "lollipops". BTW, did you see the Virtex 5FX30T board for $400? The chip alone costs more, and it'll work with the ISE webpack. There's a long wait for that one as well.Article: 134379
Philipp Hachtmann wrote: > Hi folks, > Hi, > I could need some help with my board's network setup (hardware and Linux > and U-Boot drivers). > > > This is my situation: > > I currently have a Xilinx ML403 board (With Virtex4 FX12) sitting on my > desk. > I have an EDK 10.1 system which already worked with simple standalone > applications. > I managed to use crostool to build a working cross toolchain (with > gcc-4.2.4 and glibc-2.3.6). > Then I downloaded vanilla Linux 2.6.25.11 from kernel.org. It took me a > while to get the kernel run on my system. I also had to do some little > changes to get the whole thing together. > > I now have a running Linux 2.6.25.11 kernel in an ace file together with > the design. I can mount a root filesystem from systemace and play around > via serial (ns16550) console. That's it. > > What I want is a full-featured box with ethernet support in Linux and > U-boot (which I like and want to use as well). > > I found some linux ethernet drivers in the EDK directory: > emac_v1_00_e > emac_v1_00_f > emac_v1_01_a > emac_v1_11_a > gemac_v1_00_f > lltemac_linux_2_6_v1_00_a > temac_linux_2_6_v1_00_a > temac_linux_2_6_v2_00_b > temac_linux_2_6_v2_00_c > > EDK offers me the following ethernet related modules: > xps_ll_temac > xps_ethernetlite > hard_temac > > U-Boot (latest git snapshot) comes with > xilinx_emac.c > xilinx_emaclite.c > There is also a U-Boot Version 1.1.4 from Xilinx out there which has quite a lot of Xilinx specific support (Though I must admit, that I haven't had a look at the current u-boot-git. > I also remember that I once used an xps_ethernetlite or emaclite (sone > "light" thing) with µCLinux on microblaze (Petalinux). > > Now the questions: > > Might there be a software compatibility between different emac and temac > modules? > > What should I use? How do things plug together? > I do use the HardTemac as it saves some BRAMs and Slices (and I am always lacking those ;-)) > How do I correctly set up the FX12's Tri-mode Emac with Linux and U-Boot? > I think the Linuxppcembedded-Mailinglist might be a more convenient and informative place to ask this. > Are there drivers readily available? > XPS does generate some drivers, others are in Xilinx's U-Boot. > Or do I have to combine something new? > > > I appreciate every hint, link, information, clarifying question and so on! > Thanks a lot! > Ok, here is a really good Link for ML403 and Linux: Grant Likely's Secretlab: www.secretlab.ca > Best wishes, > > Philipp :-) > Regards, LorenzArticle: 134380
Strange...somehow ISE is looking in the wrong place for map. I would check my system path, and search the registry for references to that directory (always back up the registry before mucking with it). I'd then try removing MinGW, and if that doesn't work, removing ISE as well and re-installing ISE *first* to see what happens...you should also have a XILINX environment variable (system variables) set to your installation directory.Article: 134381
Try to order Montavista Linux evaluation pack this works fine. You can see the sources for the ethernet stuff that works with ML403. Philipp Hachtmann schrieb: > Hi folks, > > I could need some help with my board's network setup (hardware and Linux > and U-Boot drivers). > > > This is my situation: > > I currently have a Xilinx ML403 board (With Virtex4 FX12) sitting on my > desk. > I have an EDK 10.1 system which already worked with simple standalone > applications. > I managed to use crostool to build a working cross toolchain (with > gcc-4.2.4 and glibc-2.3.6). > Then I downloaded vanilla Linux 2.6.25.11 from kernel.org. It took me a > while to get the kernel run on my system. I also had to do some little > changes to get the whole thing together. > > I now have a running Linux 2.6.25.11 kernel in an ace file together with > the design. I can mount a root filesystem from systemace and play around > via serial (ns16550) console. That's it. > > What I want is a full-featured box with ethernet support in Linux and > U-boot (which I like and want to use as well). > > I found some linux ethernet drivers in the EDK directory: > emac_v1_00_e > emac_v1_00_f > emac_v1_01_a > emac_v1_11_a > gemac_v1_00_f > lltemac_linux_2_6_v1_00_a > temac_linux_2_6_v1_00_a > temac_linux_2_6_v2_00_b > temac_linux_2_6_v2_00_c > > EDK offers me the following ethernet related modules: > xps_ll_temac > xps_ethernetlite > hard_temac > > U-Boot (latest git snapshot) comes with > xilinx_emac.c > xilinx_emaclite.c > > I also remember that I once used an xps_ethernetlite or emaclite (sone > "light" thing) with µCLinux on microblaze (Petalinux). > > Now the questions: > > Might there be a software compatibility between different emac and temac > modules? > > What should I use? How do things plug together? > > How do I correctly set up the FX12's Tri-mode Emac with Linux and U-Boot? > > Are there drivers readily available? > > Or do I have to combine something new? > > > I appreciate every hint, link, information, clarifying question and so on! > Thanks a lot! > > Best wishes, > > Philipp :-) > > > >Article: 134382
That might be a bit more than i expected to hear, but i'm sure it'll make sense when i get to it. thanks i'll try that out. On Aug 7, 3:52=A0am, Herbert Kleebauer <k...@unibwm.de> wrote: > laserbeak43 wrote: > > > Very cool looking tutorial! Thanks! > > Will i need the files included or can i look at the images in the pdf > > and complete it? > > If you want to do it yourself, then don't even look at the schematics > in the pdf but only at the specification of the processor architecture > (page 1-3 of the pdf, not page 4 because this already shows the solution)= . > > But I think you first want to get used to the Xilinx software (schematic > entry, simulation and implementation). Therefore I would suggest to > use the provided schematics and follow the step-by-step tutorial and > simulate the provided simple assembly program. If all works, delete > all logic (gates and flip-flops) from the lower level schematics (that's > the starting point for our students) and redesign the CPU yourself. > > But if you want to do all yourself from scratch, you will need at > least the assembler from the "addon" directory. If you worry about > the executable, just compile the provided C sources yourself: > > gcc -O3 -o xdela xdela.cArticle: 134383
found a xilinx entry in the registry when searching "mingw" but the value in it was "MinGW^e" doubt that has anything to do with it. i wonder if ise has problems with the path variable having + symbols On Aug 8, 3:29=A0am, andersod2 <thechrisander...@gmail.com> wrote: > Strange...somehow ISE is looking in the wrong place for map. =A0I would > check my system path, and search the registry for references to that > directory (always back up the registry before mucking with it). =A0I'd > then try removing MinGW, and if that doesn't work, removing ISE as > well and re-installing ISE *first* to see what happens...you should > also have a XILINX environment variable (system variables) set to your > installation directory. From glaser@ict.tuwien.ac.at Fri Aug 08 01:53:53 2008 Path: nlpi059.nbdc.sbc.com!nlpi062.nbdc.sbc.com!prodigy.com!nlpi057.nbdc.sbc.com!prodigy.net!feeder.erje.net!newsfeed.utanet.at!news.it-austria.net!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.arch.fpga Subject: Re: RTL Schematic as EDIF From: Johann Glaser <glaser@ict.tuwien.ac.at> In-Reply-To: <TpqdnSIwcYxpkwbVnZ2dnUVZ_uSdnZ2d@comcast.com> References: <1218101383.15335.13.camel@glaser> <TpqdnSIwcYxpkwbVnZ2dnUVZ_uSdnZ2d@comcast.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1218185633.15335.39.camel@glaser> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Date: Fri, 08 Aug 2008 10:53:53 +0200 Lines: 15 NNTP-Posting-Host: pc53.ict.tuwien.ac.at X-Trace: 1218185492 tunews.univie.ac.at 11868 128.131.80.53 X-Complaints-To: abuse@tuwien.ac.at Xref: prodigy.net comp.arch.fpga:147152 X-Received-Date: Fri, 08 Aug 2008 04:51:55 EDT (nlpi059.nbdc.sbc.com) Hi Sandeep > You might want to take a look at > http://www.eecs.berkeley.edu/~alanmi/abc/ > you can download the source, for research > purposes this might be what you need. Thanks for the hint. These tools are definitely interesting, once because they are open source, and second because they provide functionality for my backend tasks. Bye Hansi From glaser@ict.tuwien.ac.at Fri Aug 08 01:53:53 2008 Path: nlpi059.nbdc.sbc.com!nlpi062.nbdc.sbc.com!prodigy.com!nlpi057.nbdc.sbc.com!prodigy.net!nx01.iad01.newshosting.com!newshosting.com!198.186.194.249.MISMATCH!transit3.readnews.com!news-out.readnews.com!news-xxxfer.readnews.com!207.99.111.53.MISMATCH!newspeer1.nac.net!feeder.erje.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.arch.fpga Subject: Re: RTL Schematic as EDIF From: Johann Glaser <glaser@ict.tuwien.ac.at> In-Reply-To: <g7fcsk$s7l1@cnn.xsj.xilinx.com> References: <1218101383.15335.13.camel@glaser> <kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com> <1218113983.15335.25.camel@glaser> <g7fcsk$s7l1@cnn.xsj.xilinx.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1218185633.15335.40.camel@glaser> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Date: Fri, 08 Aug 2008 10:53:53 +0200 Lines: 17 NNTP-Posting-Host: pc53.ict.tuwien.ac.at X-Trace: 1218185493 tunews.univie.ac.at 11868 128.131.80.53 X-Complaints-To: abuse@tuwien.ac.at Xref: prodigy.net comp.arch.fpga:147153 X-Received-Date: Fri, 08 Aug 2008 04:52:50 EDT (nlpi059.nbdc.sbc.com) Hi Kevin! > The intermiate (RTL) netlist is usually proprietary. I don't think > companies want to give this away. It sounds like you would really like > a tool like Verific, which is an HDL parser that a lot of companies are > buying as a front end for their own synthesis (and simulation) tools. > It outputs an RTL-type netlist, with high level primitive blocks. I > don't know how expensive this would be for an individual user to buy, > though. Thanks for the hint. They have a 30 day trial download, I'll have a look at that! Bye Hansi From glaser@ict.tuwien.ac.at Fri Aug 08 01:53:54 2008 Path: nlpi059.nbdc.sbc.com!nlpi062.nbdc.sbc.com!prodigy.com!nlpi057.nbdc.sbc.com!prodigy.net!feeder.erje.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.arch.fpga Subject: Re: RTL Schematic as EDIF From: Johann Glaser <glaser@ict.tuwien.ac.at> In-Reply-To: <489B1687.4020203@gmail.com> References: <1218101383.15335.13.camel@glaser> <kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com> <1218113983.15335.25.camel@glaser> <489B1687.4020203@gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1218185634.15335.41.camel@glaser> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Date: Fri, 08 Aug 2008 10:53:54 +0200 Lines: 55 NNTP-Posting-Host: pc53.ict.tuwien.ac.at X-Trace: 1218185493 tunews.univie.ac.at 11868 128.131.80.53 X-Complaints-To: abuse@tuwien.ac.at Xref: prodigy.net comp.arch.fpga:147154 X-Received-Date: Fri, 08 Aug 2008 04:53:11 EDT (nlpi059.nbdc.sbc.com) Hi Mike! > > The schematic itself is not important for me, the netlist is the thing I > > want. For my research project I need the RTL netlist because it holds > > "higher level" information, like e.g. counters, MUXes, ... > > What's wrong with the source code? > That's the highest level I have, > and the easiest object to simulate. Some background information to make my intent plausible: In my PhD I'm investigating how to build custom ultra-low-power logic to a SoC, which is still configurable. On a continuum of configurability between fine-grained (e.g. FPGA, CPLD) to coarse-grained (e.g. Cypress PSoC) my plan is to stay in between. Therefore the RTL netlist, i.e. the first synthesis step, is near my planned granularity. For my implementation I need a netlist, with gates and flip-flops. VHDL or Verilog are too user-dependent and flexible. You are right, in some way they also describe a netlist, but rather implicitly. I want to use a synthesis tool to convert this to an explicit netlist. As stated before, the RTL netlist is exactly what I need for further processing. The technology mapping will then be done by another tool (or by hand, if necessary) utilizing my custom configurable blocks. > An RTL schematic shows collections of gates and flops. > Some of the gate collections are drawn as MUXes and > others are drawn as boxes: > http://mysite.verizon.net/miketreseler/uart.pdf May I ask which tool you used to generate this netlist and to print it to a PDF file? > I use these interactively to see what my source > code looks like to synthesis, and for documentation. > However, for simulation or making a synthesis image, > the source is the thing. Yes, exactly what it is intended for. > > Do you know if there is a reason, why synthesis tools refuse the user to > > get the RTL netlist as EDIF? > > Because such a netlist is at a lower level > than the source code that created it, and is > not useful for synthesis. Hmm, it is indeed useful, because it is then technology-mapped. Most tools also offer to import RTL netlists as EDIF files. But why do they refuse to export their work? Bye HansiArticle: 134384
On Thu, 07 Aug 2008 14:59:43 +0200, Johann Glaser <glaser@ict.tuwien.ac.at> wrote: >Hi! > >Am Donnerstag, den 07.08.2008, 13:31 +0100 schrieb Jonathan Bromley: >> On Thu, 07 Aug 2008 11:29:43 +0200, Johann Glaser wrote: >> >> >Hi! >> > >> >My PhD thesis deals with coarse-grained reconfigurable logic. Therefore >> >the RTL schematic synthesis result is one major input for my work. >> > >> >I tried Xilinx ISE 10.1 as well as Synplicity Synplify Pro 9.2. Both >> >tools provide this RTL netlist (before implementing it to the technology >> >netlist), but both in encrypted file formats. >> >> Yes, but every synth tool can write out a post-synthesis netlist >> in VHDL or Verilog ready for functional simulation. Sure you >> don't get a schematic, but I would have thought that a VHDL >> or Verilog netlist of primitives would be just as good. > >The schematic itself is not important for me, the netlist is the thing I >want. For my research project I need the RTL netlist because it holds >"higher level" information, like e.g. counters, MUXes, ... A technology >mapped netlist is of no use for me, because the "interesting" things >have already gone there. > >The HDL netlist is quite nice for me, but unfortunately a bit hard to >work with. I'd have to implement a complex parser and as well as some >"small synthesis" algorithms. I question how complex the parser would need to be; it only needs to understand a small subset of full VHDL. Alternatively, there are VHDL parsers you could possibly use as a starting point, thought I suspect a simple recursive descent parser would be faster to write than researching them. - BrianArticle: 134385
There is a tutorial with the board that describes how to execute MicroBlaze code directly from the Flash. The performance isn't great, but it gets the job done in lieu of RAM. By the way, there is a discussion group related specifically to this board at http://groups.google.com/group/avnet-spartan-3a-eval-kit BryanArticle: 134386
Johann Glaser wrote:
> Some background information to make my intent plausible: In my PhD I'm
> investigating how to build custom ultra-low-power logic to a SoC, which
> is still configurable.
By 'build' do you mean layout a custom chip
with special primitive logic elements
and electronic wiring,
or do you mean make a bit image for
existing or proposed fpga hardware?
> On a continuum of configurability between
> fine-grained (e.g. FPGA, CPLD) to coarse-grained (e.g. Cypress PSoC) my
> plan is to stay in between. Therefore the RTL netlist, i.e. the first
> synthesis step, is near my planned granularity.
This is where you lose me.
Granularity of what?
The logical source text,
some intermediate logical description,
or the hardware container that holds the compiled bit image?
> For my implementation I need a netlist, with gates and flip-flops.
What, exactly are you implementing?
> VHDL or Verilog are too user-dependent and flexible.
Only if a human creates the code.
A quartus .vho file is machine generated netlist
of primitive elements that just happens to use
structural vhdl as a *netlist* format.
As others have said, this could be translated to edif.
Now, if *you* want to specify which logical elements
synthesis is to use, tools from A and X won't help.
In that case, you need a library generation package
from one of the major synthesis vendors.
Then you can make any kind of netlist you like,
but you are on your own for simulation or a target device.
This is why I suggested using something like an act1010 netlist.
> May I ask which tool you used to generate this netlist and to print it
> to a PDF file?
quartus
>>> Do you know if there is a reason, why synthesis tools refuse the user to
>>> get the RTL netlist as EDIF?
>> Because such a netlist is at a lower level
>> than the source code that created it, and is
>> not useful for synthesis.
>
> Hmm, it is indeed useful, because it is then technology-mapped.
A logical technology of gates and flops, I suppose,
but that is far from a placed, routed and timed fpga image.
> Most
> tools also offer to import RTL netlists as EDIF files. But why do they
> refuse to export their work?
I suppose the device vendors are interested in their own devices,
and the synthesis and simulation vendors would like to sell you some
custom library software.
Good luck.
-- Mike Treseler
Article: 134387I have a (commercial) project and need a core for an fpga that takes a sampled-data version of a standard NTSC analog signal (525/60 Interlaced) and converts its to standard CCIR-656 (or closest thing) for further processing downstream. We do not need RGB. If you have such a core, contact me at the following email address to discuss further details; eastwood132@yahoo.com ThanksArticle: 134388
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:noudnebAM4mhCAHVnZ2dnUVZ_qTinZ2d@comcast.com... > I was wondering not so long ago about doing PC board design > in verilog. > > I think you can just restrict what you allow. There is much > that could be written in verilog that current synthesis tools > won't allow. (FF's that work on both edges of the clock, > as an example.) I would say that you should allow all > forms of wiring, but restrict what can be connected to > those wires. > > -- glen > Brilliant idea! I also thought of extending the idea to artwork, whereas instead of having a boring masterpiece hanging on the wall, you could wallpaper the entire room with an HDL description. IckyArticle: 134389
Johann Glaser wrote: (snip) > For my implementation I need a netlist, with gates and flip-flops. VHDL > or Verilog are too user-dependent and flexible. You are right, in some > way they also describe a netlist, but rather implicitly. I want to use a > synthesis tool to convert this to an explicit netlist. As stated before, > the RTL netlist is exactly what I need for further processing. The > technology mapping will then be done by another tool (or by hand, if > necessary) utilizing my custom configurable blocks. I was wondering not so long ago about doing PC board design in verilog. I think you can just restrict what you allow. There is much that could be written in verilog that current synthesis tools won't allow. (FF's that work on both edges of the clock, as an example.) I would say that you should allow all forms of wiring, but restrict what can be connected to those wires. -- glenArticle: 134390
I'm looking for an FPGA (any flavor) development board with an SD card socket connected to the FPGA. It must have all the pins connected (not just SPI mode). So FAR I've found the Arrow LPRP. Any other suggestions? Thanks PeteArticle: 134391
Jeff Cunningham wrote: (snip) >> The device is a self-tuning piano. You can read/listen about it >> here... >> New York Times: >> http://query.nytimes.com/gst/fullpage.html?res=9800E1D8133FF931A35752C0A9659C8B63 >> NPR: >> http://www.npr.org/templates/story/story.php?storyId=878091 >> New Scientist Magazine: >> http://www.newscientist.com/article/dn3143-hotwired-piano-tunes-itself.html (snip) >> I first convert the wave to a "period" wave that has an "on" time >> equal to one period of the string's vibration. I then use this wave >> to enable counting of the 50-MHz system clock. So I get a count of >> how many clock ticks of the system clock occur for one period of >> string vibration. This takes up to 21 bits for the low strings. I >> average 32 of these numbers and calculate an error based on a stored >> setpoint. Currently I'm using a theoretical setpoint, but eventually >> I will want to add the feature whereby a piano tech can hand-tune the >> piano and then "store" his tuning numbers for subsequent use. Instead of averaging 32 values, why not count for 32 cycles? Probably more cycles for higher notes, and fewer for lower notes. (snip) > Are you concerned about the 600W of heat drying out the piano wood? I > know some pianos have humidifiers inside them so it seems like a > potential issue. It seems that the heat is only when it is in use, and maybe not much different from the sunlight that many pianos will receive. The mechanical tuning has to be close enough that each string can be tuned at below 95F, and equal to or above the ambient temperature. With reduced tension when it is not being used, it might stay "in tune" longer. Then again, I don't know how much string stretching increases with temperature. I would say that magnetic coupling to the strings was pretty obvious, but temperature controlled tuning is not. My thought was stepper motors on each tuning peg. (Small and geared down a lot.) -- glenArticle: 134392
Jim Granville wrote: (snip) > Read what I wrote carefully. "Read up on reciprocal Frequecy counters" > A Reciprocal Frequecy counter is not an ordinary frequency counter :) > It counts in two domains: Whole cycles and time. > Your values above are a dT of 17.05us. > Suppose you measure 3 whole cycles, giving ~9 readings a second > then a (relatively low) 1MHz reciprocal Counter will give a 63 count > difference on your 15.9mHz dF example. - so is about 6 bits more > precise than you need. I think that is what he is doing, but averaging 32 counts. But averaging 32 counts is the same as counting 32 times as long, which might take less logic. Putting analog PLL frequency multipliers on each string would be interesting, but take a lot of extra circuitry. I don't know DLL enough to say, but it might work. I would read up on DLL (that is, the digital version of the analog PLL). -- glenArticle: 134393
I don't have one, but i was thinking of buying a protoboard and trying to figure out how to get and SD card interface to work with my spartan3e kit. I know someone that's been playing around with SD cards, so if he'd be kind enough to give me info, i'll be sure to pass it onto you. good luck On Aug 8, 4:09=A0pm, "Pete Fraser" <pfra...@covad.net> wrote: > I'm looking for an FPGA (any flavor) development board > with an SD card socket connected to the FPGA. > > It must have all the pins connected (not just SPI mode). > > So FAR I've found the Arrow LPRP. > Any other suggestions? > > Thanks > > PeteArticle: 134394
sorry didn't read that, i might not be much help :) > So FAR I've found the Arrow LPRP. > Any other suggestions? > > Thanks > > PeteArticle: 134395
On Aug 8, 3:09=A0pm, "Pete Fraser" <pfra...@covad.net> wrote: > I'm looking for an FPGA (any flavor) development board > with an SD card socket connected to the FPGA. > > It must have all the pins connected (not just SPI mode). > > So FAR I've found the Arrow LPRP. > Any other suggestions? > > Thanks > > Pete A project that Antti did is almost what you want: http://www.microdream-1.c= om/Pmod-B.html It has SD connected, but only in one bit mode. When we developed out cards we put a miniSD card slot on the back of them: http://www.fastertechnology.com/extras/pics/p6a/p6a_back_tn.jpg For our development, we just soldered a miniSD to SD converter to a ribbon cable that was crimped to a DIN connector. Then we plugged that into an Avnet development board. We put a few caps on the power pins, and series terminated at the miniSD converter. That worked like a charm, and it was quick and easy as long as you have the stuff to solder with. The miniSD to SD converter came with the miniSD card. We use the miniSD to configure the V4FX, then it boots its software from it. We use it in both SD and SPI modes. Regards, John McCaskill www.FasterTechnology.comArticle: 134396
Dan, Any Uart EDIF provided by Xilinx can be clocked at 24 Mhz divided by 13 to get a suitable clock input to that Uart running at 115200. I usually do this with 48Mhz divided by 26 to get the required clock for 115200. Note that 24 Mhz divided by 13 is 1.846 MHz which is very close to 115200*16 = 1.843 MHz which is within 1% of the desired clock speed to operate the uart for 115200. -Andrew "Dan Arik" <DanA@hotmail.com> wrote in message news:g11ia0$c2l$1@aioe.org... > Hi > > I have an evaluation board with a target and a control FPGA. The control > FPGA is connected to the target FPGA over 32-bit local bus and can write > the data to a host PC over a RS232 interface. Both FPGAs are internally > clocked with 24MHz. So I have to implement on the control FPGA a > transmitter that gathers the 32 bits and sends them in 8 bit chunks to > the host PC. I wonder if somebody has some helpful ressources how to > implement such an simple interface. Also I have to implement a suitable > divisor for the baudgenerator to generate 115200 Hz from 24MHz. > > Would be thankful for helpful comments and ressources ;) > > Dan!Article: 134397
On Aug 8, 5:54 pm, "Andrew Lohbihler" <andr...@rogers.com> wrote: > "Dan Arik" <D...@hotmail.com> wrote in messagenews:g11ia0$c2l$1@aioe.org... > > Hi > > > I have an evaluation board with a target and a control FPGA. The control > > FPGA is connected to the target FPGA over 32-bit local bus and can write > > the data to a host PC over a RS232 interface. Both FPGAs are internally > > clocked with 24MHz. So I have to implement on the control FPGA a > > transmitter that gathers the 32 bits and sends them in 8 bit chunks to > > the host PC. I wonder if somebody has some helpful ressources how to > > implement such an simple interface. Also I have to implement a suitable > > divisor for the baudgenerator to generate 115200 Hz from 24MHz. > > > Would be thankful for helpful comments and ressources ;) > > > Dan! > Dan, > > Any Uart EDIF provided by Xilinx can be clocked at 24 Mhz divided by 13 to > get a suitable clock input to that Uart running at 115200. I usually do this > with 48Mhz divided by 26 to get the required clock for 115200. Note that 24 > Mhz divided by 13 is 1.846 MHz which is very close to 115200*16 = 1.843 MHz > which is within 1% of the desired clock speed to operate the uart for > 115200. > > -Andrew > This works out when you get lucky. I had a similar requirement with a 20 MHz clock. I realized that it's a bit dumb to require a 16x clock source for a uart within an FPGA. I wrote my own UART code that uses a clock divisor that corresponds to the ratio of the input clock to the bit rate (rather than 16x the bit rate). The transmitter uses this divisor directly with a free- running counter. The receiver has a counter that resets on the falling edge of a start bit, and compares the current count to 1/2 the divisor to generate the center bit sampling. So not only you get more frequency resolution to match the baud rate, your bit sampling center is more accurate (in most cases). Regards, GaborArticle: 134398
Icky Thwacket wrote: (snip) > I also thought of extending the idea to artwork, whereas instead of having > a boring masterpiece hanging on the wall, you could wallpaper the entire > room with an HDL description. Intel used to give out posters of the x86 processors. (I believe from the masks, not images of actual chips.) For the 80186, you could still see the wires, but by the 80486 they might have been below the resolution of the process. If CPU mask images are considered art, then CPU HDL descriptions could also be art. I do wonder what the Mona Lisa would look like in verilog, though. Then again, there are alt.ascii-art and alt.ascii.art newsgroups. (Why no alt.ebcdic-art group?) -- glenArticle: 134399
glen herrmannsfeldt wrote: > Jim Granville wrote: > (snip) > >> Read what I wrote carefully. "Read up on reciprocal Frequecy counters" >> A Reciprocal Frequecy counter is not an ordinary frequency counter :) >> It counts in two domains: Whole cycles and time. > > >> Your values above are a dT of 17.05us. >> Suppose you measure 3 whole cycles, giving ~9 readings a second >> then a (relatively low) 1MHz reciprocal Counter will give a 63 count >> difference on your 15.9mHz dF example. - so is about 6 bits more >> precise than you need. > > > I think that is what he is doing, but averaging 32 counts. > But averaging 32 counts is the same as counting 32 times as long, > which might take less logic. > > Putting analog PLL frequency multipliers on each string would be > interesting, but take a lot of extra circuitry. I don't know > DLL enough to say, but it might work. I would read up on > DLL (that is, the digital version of the analog PLL). Why add more jitter/noise ? In my example, a low 1Mhz timebase reciprocal counter is 63 TIMES more accurate than the OP's 15.9mHz spec - so it has 6 extra bits of precision. (500KHz would be my trade-off target) On a more practical note, I can't see a stored-cal approach working very well (too much thermal drifing about..) - this has to be able to work closer to real time, or at least have a mode that allows 'verify during play', so the design target should be reading ALL channels. Block RAM arrays would be one way to pack this into a smaller FPGA, and just clone the Array-Scan as needed. eg if you have the time-budget to scan 50 into one block RAM, then 3 repeats supports 150 channels... 18 bit counters are good, as the reciprocal Cycle Ctr 'scales' these to similar times. (so precison is largely independant of freauency) The Dual-port access to Block Rams, would allow the Cycle Ctr, and TimeCtr to share a block, typical block is 1K x 18, so 50 T_Ctrs, 50 captures, and 50 C_Ctrs + Preloads, is only 200 RAM-lines. Must be something to do with the spare space ? ;) Could do a reading FIFO, but the capture rate is similar on allchannels, with a reciprocal counter, and ~10/sec, even over 120 channels, is only 1200Ch/s reading rate : this could stream the numbers over a SPI or even a RS232 link to a PC. Should fit in the smallest FPGA ? Did the OP mention which FPGA he uses now ? -jg
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