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
Hello ppl, I have a problem! I need to build a counter that should be clocked depending on mode_pin if mode_pin=0 it should be by cpu_clk (1.79MHZ) if mode_pin=1 it should be by ppu_clk (5.37MHZ) the way im thinking now is by gating the clock, and oring them. But is there a more subtle way of achieving this? Thanks JacArticle: 79526
In what way have you implemented the ROM fonts? (I'm using Xilinx EDK)Article: 79527
<jaxato@gmail.com> schrieb im Newsbeitrag news:1108927608.785215.81110@l41g2000cwc.googlegroups.com... > Hello ppl, I have a problem! > > I need to build a counter that should be clocked depending on mode_pin > > if mode_pin=0 it should be by cpu_clk (1.79MHZ) > if mode_pin=1 it should be by ppu_clk (5.37MHZ) > > the way im thinking now is by gating the clock, and oring them. But is > there a more subtle way of achieving this? Clock gating is not neccessary. A clean way would be to use a 2*5,37 Mhz Clock and divide by two or 6. This can be done easyly and also clock switching is easy (glitch free), since you can register the output. If you have just a 5.37 MHz clock, you need to MUX between the clock itself and a divided by 3 Version. Be carefull, clock MUXes can inhibit glitches if done improperly. But there are glitch free clock muxes. Peter had a small article about this in Xcell years ago. Regards FalkArticle: 79528
Hi all My name is Eliahu from Israel . After some years in the software field I want to come back again to the harware era . I want to start again doing FPGA designs . I feel that XILINX "speaks" to me . My question is : What low cost deseign kit might be right for a "comeback" to the fpga filed ? Any ideas ? Thanks in advance ECArticle: 79529
Hi Eliahu, Just do a google search. You will find tons of matches. I bought one from: http://www.digilentinc.com/ I am pretty happy with it. ZAKArticle: 79530
austin wrote: > Tom, > > Well, as for fast, HDL is the way to go (as in get it done quickly). > > Time saved by simulating, etc. will pay off later. > > Fast (as in performance) is tougher. Even in a schematic, you can not > tell the place and route software how to route everything. > > In fact, constraints with or without a schematic are required to get the > best performance. > > Or, as one suggested, open up FPGA Editor, and see what is happening. > (May do that in any event). > > The tradeoff is a difficult one: become an HDL expert and a constraints > expert, or stick with schematics and hack constraints... > > I prefer the first, as it will serve you better as you do other > projects. It will start slower, and finish faster, though. > Howdy Tom, From your description of schematics, it seems like you aren't referring to modern schematic tools... most that I've heard of translate your schematic into an HDL. Overall, I have to admit that I'm a fan of schematics - mainly because I think in more graphical terms, and I think it is somewhat easier for others to pick up and understand the *overall* functionality and flow of the design. But when you get down to doing the details of the functions, it ends up taking quite a bit of time and effort to do it, and you WILL end up finding times where you have to battle with the schematic tool to get it to do what you want. I was going to suggest going HDL for the same reasons as Austin, but had one additional reason: what better time to start learning an HDL than with a small, straight forward project like this? In reality, it isn't hard to find examples (either from the vendors or other example online code) of enough stuff that I'd be surprised if it really slowed you down by more than a day or two. BTW, a schematic entry doesn't force routing internal to the FPGA to be any different than HDL, so I don't see that as being a deciding factor. Have fun, MarcArticle: 79531
tom wrote: > Austin, thanks, I got the message regarding HDL (still I find 50 pages of hierarchical schematics a lot more readable than 50k lines of code, though). But look: the purpose is to use Spartan-3/400s as front-ends for 200Msps DACs and ADCs. I'll be using only the BRAMs and maybe 3-5% of the CLBs, so the logic is simple, but the required speed is critically close to the published S3 limits. Things like ensuring nice, parallel data-flows spring to mind; for example, one could shuffle the bit order in the RAM to prevent needlessly crossed lines. However, I haven't been able to find any pertinent information in the S3 documentation. There's a 1000 tricks and considerations like the above, which every HW-designer knows, but they all reside in that very boundary where HDL-synthesis takes over. I have nothing against HDL, I just wanna get this thing flying, fast. Cheers, Tom Did you look at the ABEL code flows ? ABEL is more direct, and uses dot extensions [.CK, .D, .T, .AR ...] so is very like creating a NET LIST. More like assember vs Visual basic :) If your task is simple, and the learning curve will dominate, you could try that. Last time I looked, ABEL was still supported (actually improving) in the Xilinx tools. [.. and also Lattice, and Altera have a similar flow called AHDL ] I presume it is still there, in Webpack, and will support S3 and BRAMs - Austin ? -jgArticle: 79532
I use xilinx ise foundation the rom is declared in vhdl i declare an array that contains contains each symbol of the font exactely each symbol is reprensated by 8 std_logic of 8 bit i adress the rom by the concatenation of the symbol & the 3 lsb of the adress of the vertical pointer then i peak the right bit with the 3 lsb of horizontal pointer for example 'A' symbol look like --A "00000000", --<< for vertical separation "00011000", "00011000", "00100100", "00111100", "01000010", "01000010", "00000000",--<< for vertical separation ^ ^ for horizontal separation here is the code: http://kclo4.free.fr/fpga/memoire_alphabet.vhdl I'm actually remodeling my VGA display when it will be finish i will share you the code if you want (in 2/3 days i think) alexis "Marco" <marcotoschi@email.it> a écrit dans le message de news: ee8bfb0.4@webx.sUN8CHnE... > In what way have you implemented the ROM fonts? (I'm using Xilinx EDK)Article: 79533
VHDL level simulation of JOP is now available ;-)
The actual version of JOP at the usual download page
http://www.jopdesign.com/download.jsp
now contains (hopefully) all necessary file to run a
simulation with ModelSim or a different VHDL
simulator.
In directory vhdl/simulation you will find:
* A test bench: tb_jop.vhd with a serial receiver to print out
the messages from JOP during the simulation
* Simulation versions of all memory components (vendor neutral)
* Simulation of the main memory
In directory modelsim you will find a small batch file (sim.bat) that compiles
JOP and the test bench in the correct order and starts ModelSim.
A (very) simple step-by-step introduction can be found at:
http://www.jopdesign.com/simulation.jsp
It would be nice if somebody can try the simulation to check whether all scripts
and directories are correctly set.
Cheers and thanks for checking it out ;-),
Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/
Article: 79534It all depends whether you want to switch dynamically, i.e. maintaining the count value, or if this is a way of distinguishing between two different modes of operation, with the count reset in-between. In the latter case, you can just mux the clock. In the former case you have to be far more careful to avoid unintended glitches (extra clocks) while switching. I have a 2-flip-flop glitch-free multiplexer that I can send you if you need it. Peter Alfke peter@xilinx.comArticle: 79535
>> http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D7816%2526CCD%253 >> DUSA%2526SID%253D4746%2526DID%253DDF2%2526SRT%253D1%2526LID%253D0%2526PVW%253D >> %2526BID%253DDF2%2526CTP%253DEVK,00.html > >This web site is your friend: http://tinyurl.com/create.php Please include the full URL even if you do provide a shortcut. The shortcut company may go out of business or decide to blast my screen with ads or ... Or I may recognize the URL or host as a place I do/don't want to visit. (Some require registration or cookies. Some provide good info.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 79536
Hello, first thanks for the hints. I just coded the article "xl24- trouble-free switching between clocks".. First this is still clock gating, but with glitches removed. XST still sees it as being combinational. I think this would fit my application, where I made a 14-bit counter work in one case, clocked by 5.37mhz, and in the other case at 1.79mhz. What happens when I put the attribute clock_source in the vhdl code? is it just to remove the warning from xst, or will it, by some sort of magic, route the output from the "clock selector" block, to the clock routing in my FPGA? And to the question of Peter, I need to be able to switch between clocks arbitrarily, while the counter still holds the count, and hence incrementing at the new rate. Thanks so much for the hints! JacArticle: 79537
Rene Tschaggelar wrote: > Michel Billaud wrote: > >> Hi, >> >> Some CS research papers propose the use of FPGA as PC co-processors >> for very specialized hard computing task (like searching DNA sequences). >> >> It's easy to find starter kits in the $100-200 range to experiment >> with FPGAs, but connecting them through the parallel port doesnt give >> a supercomputer :-; and the price of PCI based cards seem to be 2 >> orders of magnitude higher. Why is it so ? Is there no market niche >> for a cheap (say $200-500) general purpose co-processor card ? > Writing a PCI driver for the various Windows PC platforms is > not that trivial. Then come the powerusers that wish changes > or don't the stuff to run because they understand it differently. That is being generous. Actually, writing a Windows PCI driver is a royal pain if you want any kind of high performance bus mastering et al. I can't in fact imagine being able to get away with giving a customer any kind of Windows driver for an FPGA. The alternative is to put an extra chip, a PCI to local bridge, that *can* have a common Windows driver, and then write that Windows driver and ship it with the board. I can tell you from experience that once that Windows driver is written, no vendor is going to feel magnanamous about giving it away. It's painful and expensive to develop, and surely comes with plenty of support headaches:-( -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 79538
Stephen Williams wrote: > Rene Tschaggelar wrote: >> Writing a PCI driver for the various Windows PC platforms is >> not that trivial. Then come the powerusers that wish changes >> or don't the stuff to run because they understand it differently. > > > That is being generous. Actually, writing a Windows PCI driver is > a royal pain if you want any kind of high performance bus mastering > et al. I can't in fact imagine being able to get away with giving > a customer any kind of Windows driver for an FPGA. > > The alternative is to put an extra chip, a PCI to local bridge, > that *can* have a common Windows driver, and then write that Windows > driver and ship it with the board. I can tell you from experience > that once that Windows driver is written, no vendor is going to > feel magnanamous about giving it away. It's painful and expensive > to develop, and surely comes with plenty of support headaches:-( Another option would be to write a PCI driver for Linux - there's lot of source code for drivers that already exist, for a start. It all depends on who you want using it :) I know this was/is the approach taken by WAND (www.wand.net.nz) when they were originally doing research on network measurement gear. Does anybody know how the relative difficulty of the two approaches differs? I would have suspected that linux would be slightly easier due to more examples/code available, better documentation, and more open-source people to discuss the code with. JeremyArticle: 79539
Hi, I'm in the process of designing a small spartan-3 based board. The board will have the following memory devices on a common bus: -2x(1Mx16b) SRAM's part #CY62167DV30 configured as one 32b memory -2Mx16b Flash part #LHF00L15 What I need to determine is how to connect the address busses of these devices, and also in doing so ensure compatibility with the Xilinx EMC core. Currently I'm connecting the address bus on the board as follows: FPGA SRAM Flash 0 NC NC 1 NC 0 2 0 1 3 1 2 ... With this arrangement will I be able to configure to Xilinx EMC core with a Flash bank and an SRAM bank? Also what size datatypes will be wirteable/readable from each bank? Thanks in advance, MattArticle: 79540
Stephen Williams wrote: > Rene Tschaggelar wrote: > >> Michel Billaud wrote: >> >>> Hi, >>> >>> Some CS research papers propose the use of FPGA as PC co-processors >>> for very specialized hard computing task (like searching DNA sequences). >>> >>> It's easy to find starter kits in the $100-200 range to experiment >>> with FPGAs, but connecting them through the parallel port doesnt give >>> a supercomputer :-; and the price of PCI based cards seem to be 2 >>> orders of magnitude higher. Why is it so ? Is there no market niche >>> for a cheap (say $200-500) general purpose co-processor card ? > >> Writing a PCI driver for the various Windows PC platforms is >> not that trivial. Then come the powerusers that wish changes >> or don't get the stuff to run because they understand it differently. > > That is being generous. Actually, writing a Windows PCI driver is > a royal pain if you want any kind of high performance bus mastering > et al. I can't in fact imagine being able to get away with giving > a customer any kind of Windows driver for an FPGA. > > The alternative is to put an extra chip, a PCI to local bridge, > that *can* have a common Windows driver, and then write that Windows > driver and ship it with the board. I can tell you from experience > that once that Windows driver is written, no vendor is going to > feel magnanamous about giving it away. It's painful and expensive > to develop, and surely comes with plenty of support headaches:-( That is what I assumed. To deliver a prebuilt FPGA functionality for the PCI to be added to the FPGA was another thinkable solution. In the last couple years I tended to get materials from a company called OSR which appear to be only writing drivers and telling people how to write a driver. The one week courses for a few k$ are considered a bargain when compared to the effort required to get the information together yourself. Anyway writing drivers appeared to me as specialty job that only bigger companies can afford. Meaning whoever does write the driver has to be writing drivers the whole year round, otherwise the investment into the knwoledge and keeping it up to date is hard to justify. Then comes this chipset with this quirk and, and, and, ... Yes, and then comes the 96 channel 1GHz logic analyzer to have a look at the 64bit PCI bus. Setting this one up and working with it efficiently is another half employee. Then divide the effort by the number of boards sold. I too believe there'd be a market in supercomputing to the desktop. But first some data would have to be released. How many floating point units can be integrated in parallel running at what speed. And then the software manufacturers writing the powerhungry software should have a standardized interface, such that the boards are multi-sourceable. The competition is using clusters of PCs or clusters of other machines. The hardware is fairly cheap and softwarewise not that difficult to distribute. Compare this to a to be written compiler to let the software run partly on an FPGA. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 79541
Martin wrote: >>>You could not allow your engineers to go home or use >>>the phone or use the internat > > > "Symon" wrote: > >>Perhaps that's why one of them ripped him off in the past... ;-) > > > The only shackles and chains I had around were already chaining me to my > > desk, so that couldn't be it! :-) > > > I gather from the responses that design work security either isn't a > significant issue (BTW, it has NOT been for me) or that no sensible > approach > exists. By "sensible" I mean anything that does not adversely affect > work > and creativity. It is an issue. However you have to define first who you want to deter. There are chips with a security bit. I'd assume it to be crackable with sufficient effort, say 1 man month and gear for 10k$. This means you're back at square one. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 79542
Would a low-cost USB-based board work? Transfer rates aren't as high as
PCI, but a fat lot more than parallel.
http://www.opalkelly.com/
Jake
Michel Billaud wrote:
> Hi,
>
> Some CS research papers propose the use of FPGA as PC co-processors
> for very specialized hard computing task (like searching DNA sequences).
>
> It's easy to find starter kits in the $100-200 range to experiment with
> FPGAs, but connecting them through the parallel port doesnt give a
> supercomputer :-; and the price of PCI based cards seem to be 2 orders
> of magnitude higher. Why is it so ? Is there no market niche for a
> cheap (say $200-500) general purpose co-processor card ?
>
> (Just wondering)
>
> Michel Billaud
>
Article: 79543"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:37s7tfF5h3oanU1@individual.net... > > "TonyF" <not@valid.address> schrieb im Newsbeitrag > news:ZX0Sd.1675$%F6.1428@newsfe4-gui.ntli.net... > >> > Nonsense. XST can handle inouts quite good. >> >> Only if they are at the top level. If they are in a sub-module, XST will >> complain about not finding the *_I, *_O and *_T ports in your sub-module >> (see my other post). > > ???? If you have ionout between modules that go not offside, XST can > handle > them too. But I wouldnt use inout inside the FPGA, there is no reason to > do > so and after all it will not translate in "real" tristates in newer FPGA > families and uses up more ressources than seperate ins and outs. > > Regards > Falk Falk, From what I have seen, the problem is that platgen.exe (Part of EDK, not XST) is auto generating wrappers for the IP blocks. The auto-generated wrappers breaks out "inout" to *_I, *_O, *_T ports. It also generates a top level file where these signals are fed into instantiated IO blocks at the top level. My guess is that the program that autogenerates these files assumes that the user defined IP blocks conform to the _I, _O, _T convention, and XST complains when it sees incompatible connections.. -NewmanArticle: 79544
"newman5382" <newman5382@yahoo.com> schrieb im Newsbeitrag news:Xn8Sd.104376$JF2.1558@tornado.tampabay.rr.com... > From what I have seen, the problem is that platgen.exe (Part of EDK, not > XST) is auto generating wrappers for the IP blocks. The auto-generated > wrappers breaks out "inout" to *_I, *_O, *_T ports. It also generates a top > level file where these signals are fed into instantiated IO blocks at the > top level. My guess is that the program that autogenerates these files > assumes that the user defined IP blocks conform to the _I, _O, _T > convention, and XST complains when it sees incompatible connections.. OK, this sounds like a different story. I didnt use EDK yet. Regards FalkArticle: 79545
<jaxato@gmail.com> schrieb im Newsbeitrag news:1108934387.311998.7590@g14g2000cwa.googlegroups.com... > Hello, first thanks for the hints. I just coded the article "xl24- > trouble-free switching between clocks".. > First this is still clock gating, but with glitches removed. XST still > sees it as being combinational. I think this would fit my application, > where I made a 14-bit counter work in one case, clocked by 5.37mhz, and > in the other case at 1.79mhz. If this is for a counter inside the FPGA, DONT use clock gating. Use a CE (clock enable) instead. Because a CE input is a clean synchronous design, where the counter can interact with the other logic without any trouble. If you do clock gating, the counter is not driven by the global clock net (in opposite to the rest of the logic) and so interaction is going to be troublesome (skew, hold time problems). Do clock gating only when there is REALLY no other way. Ususally there is a clean synchronous (single clock) solution. > What happens when I put the attribute clock_source in the vhdl code? is > it just to remove the warning from xst, or will it, by some sort of > magic, route the output from the "clock selector" block, to the clock > routing in my FPGA? It will just remove the warning, the basic problem will persit. > And to the question of Peter, I need to be able to switch between > clocks arbitrarily, while the counter still holds the count, and hence > incrementing at the new rate. So even more a argument for CE instead of gating. Go for it. Regards FalkArticle: 79546
does anyone have a c compiler for the picoblaze?Article: 79547
does anyone have a c compiler for the picoblaze?Article: 79548
Isnt that GNU? "ramy" <eng_ramy_gad@yahoo.com> wrote in message news:468282399cf6dbc07fac483062f74ec2@localhost.talkaboutelectronicequipment.com... > does anyone have a c compiler for the picoblaze? >Article: 79549
Well, ell. CE is not such a good solution when the two clocks are unrelated or have an uncertain phase relationship. The worst one could do is to feed an asynchronous CE into a long counter. First synchronizing the CE to the faster clock domain, before using it, is better. It is hard to make a definitive suggestion when the real design is unknown... What does the counter output do, how many clock domains are involved, etc? Peter Alfke
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