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
peter.kampmann@googlemail.com wrote: > I also want to run my program out of the memory of the sdram of my > Xilinx Virtex 2 Pro, unfortunately I get outputs from stdout/stdin only > in the debug mode. > But I can live with that, the more serious problem is, that the code > seems not to work as it should, when running it from sdram. Is the code running at all or do you just see no packets so the ppc could be dead? > I use the Ethernet-MAC on the Board together with LWIP and I get no > packets send, when running the board in the normal way. When I switch > into debug mode, I get the right behaviour and I receive packets send > by the board. sdram cannot be loaded from the config prom. You have to write your own loader. How are you loading the sdram with code in non-debug mode? By debug, do you mean XMD? XMD *does* load code into sdram. Alan NishiokaArticle: 106626
Thomas Stanka wrote:
> Hi,
>
> arant schrieb:
>
> > The device core asserts reset to the device peripherals asynchronously
> > and releases (deasserts) the reset synchronously after 4 clock periods
> [..]
> > reset_out <= reset_reg(3);
> [..]
> > reset_out <= reset_reg(0) and reset_reg(1) and reset_reg(2) and
> > reset_reg(3);
>
> > "I think the second implementation reduces the problem of metastability
> > at the reset_out as it is less probable that ll the four flops go
> > metastable at the same time"
> >
> > Is the above statement (" I think ... time") valid
>
> No, it is invalid. Metastability _may_ affect the output of any gate
> regardless of the other inputs.
That is what I am not so sure of. If that is true, then I agree with
your assessment. But I am pretty sure the way gates are designed, if
one input is in a state that assures the output condition, the other
inputs will not have an effect on the output even if they are not
within the proper digital voltage range. However, if this is a LUT in
and FPGA, I am not as certain. I believe they use pass transistors to
connect the output of memory elements to the output of the LUT. No
matter how they decode the inputs to connect the memory element to the
output, I can see a single metastable input possibly making the LUT
output invalid.
So it depends on whether a LUT is used or a standard gate.
> On the other side has option 2 a more stable reset release in case of
> "bouncing"
> imagine your reset has a low ripple and goes clocked in as
> 00010110111111
> Option 2 waits until all four registers are stable, option 1 may lead
> to a problem if theres a "weak" '0' which resets only part of the FF
> but not the shift register properly (e.g. due to metastability). It is
> very unlikely to have such a problem, but I would prefer a mixture of
> both: AND at least two FF to release Reset and don't use the first FF
> or first two FF for reset release to be safe against metastability.
Not a bad idea!
Article: 106627> Altera's Cyclone II family is fully supported by free tools and the > largest (EP2C70) is about 68k LUT, much more than the 3S5000. > > I don't know how the pricing compare though. I think you may have proposed a great plan. Their prices range from $125 to $300 for their 672 pin chips (according to their website). That's still three times what I had been hoping for, but maybe I could make that work. And it is 25% cheaper than Xilinx. Can I get these Cyclone II chips for less than that through some other dealer?Article: 106628
Evan Lavelle schrieb: > Does anyone know of any open-source software which will program an > XCF04S (Xilinx serial PROM) on JTAG? It also needs to issue a CONFIG > command to start configuration. JDrive should do the job: http://direct.xilinx.com/bvdocs/appnotes/xapp500.pdf You can also check what algorithms openwince supports: http://openwince.sourceforge.net/jtag/ Kolja SulimmaArticle: 106629
I have responded to Tejo personally. The problem is know an dfixed in a newer version of the script, which for some reason is not linked to the XAPP. I have sent Tejo the new version seperately and all is well. Kind regards, Stephan Neuhold <sutejok@gmail.com> wrote in message news:1155634747.642024.198180@m79g2000cwm.googlegroups.com... > Hi, > > i'm trying to put my data into the PROM on the spartan 3 Starter Kit > Board. I followed the instructions in XAPP694 from xilinx and still > have a problem. > > here is a part from the .MCS file generated by the perl script: > > .. > .. > :10FF500004000000040000000C000180000000A06C > :10FF60000C000580000000000C0000800000FAEA90 > :10FF70000C000180000000B004000000040000003C > :08FF8000040000000400000071 > :10FF90008F9FAFBF000000000000000000000000C5 <--starting of > my data > :10FFA0000000000000000000000000000000000051 > :10FFB000000000000000000000000000FF02F20549 > :10FFC000536443425401520144425201444252019B > :10FFD0004442F60556105796580347465601484680 > :10FFE0005601444656014446160017001800F6050F > :10FFF0005608579658034746560148465601444608 > :020000040001F9 > <--breaking point > :1000000056014446160017001800F6055618579674 > :100010005803474656014846560144465601444651 > :10002000000000000000000000000000FFFFFFFFD4 > :00000001FF > > > at :10FF90008F9FAFBF000000000000000000000000C5 seems to be where my > data starts. > I have no problem loading my data for as long as the amount of data > does not pass the :020000040001F9 point. > > if ever my data pass that point, programming will pass but verification > (using iMpact) fails. > > I'm not sure whose mistake is this. the file is generated automatically > by the perl script. > > have anyone seen this problem before? > Thx > > tejo >Article: 106630
>> you can use XFIG to draw your State Diagramm and convert it with brusey20 to VHDL. >> >> http://www.2ub.org/brusey20/ >> > that's a very nice tool! > mmh, I tried to run it under Cygwin and under Linux. Got on both segementation faults or application errors with the provided examples. A nice idea, but didn't work. MartinArticle: 106631
Hi, Mentor's HDL Designer has many functions. But I really do not see any requirement to use a tool to generate a state machine (I have tested the tools from mentor and Xilinx ISE). Directly writing the code in a single always block is already very clear and easy. By using such tools usually cost more time. Many other functions in the HDL Designer are very useful. As a large company, Mentor's products indeed cover a very wide area, but at least in some cases, the free tools from Topweaver family are much more powerful. 1, Comparing TME with HDL Designer's Tabular IO, TME shows better performance in parameter/generic, dynamical adjustment of HDL code format, secure code synchronization, complex HDL code template and launch speed. 2, Like ISE, QUARTUS, ActiveHDL and other tools, HDL Designer's module integration function is based on traditional schematic method, which is hardly used in large projects. You can see these tools' demo all using only a few modules and wires. Topweaver can easily deal with hundreds of ports. A quick demo from http://www.topweaver.com/demo.htm can show how to fulfill the integration work within a few minutes. If you can use any other tool to get the same performance, please let me know. Now the new version of Topweaver is in the final test. www.topweaver.comArticle: 106632
Peter, There is no sequence sensitivity that I am aware of. Perhaps there is something introduced as the device configures, and starts or tries to calibrate MGTs before all the supplies are present? Since the device requires one Vcco (for the config bank), Vccaux, and Vccint to be above their power on reset thresholds, the device could configure and start before the MGT supplies are present or even while they are still changing (depending on how fast they power on in relation to the other three supplies I mentioned). That might be the source of your problem? Austin Peter Mendham wrote: > Does anyone know if it's a problem if the LDO supplies to V4 MGTs come > up before supplies to the rest of the chip (i.e. before VCCINT)? > > Thanks, > > -- PeterArticle: 106633
Xesium wrote: > Hi guys, > Sorry this subject was discussed in a different way a year ago. > However: > > I have a Microblaze based system and I need to attach some > co-processors to it to implement several applications. The problem is > that I can't put all my data on the BRAMs so I have to use off-chip > memory in my design. I know that I can have DMA on OPB bus (I think > from off-chip mem controller to OPB BRAMs, yes?) however for contention > reasons and low communication bandwidth as well as high power > consumption I'd really rather not put the co-processors on the OPB bus > however on the other hand I don't want my microblaze to be just a > memory controller for FSL co-processors. I know that this is not a new > problem however from the previous messages I got this impression that > it might be possible to use the DMA to transfer data to FSL > co-processors. > I'd be happy if you could tell me what options I have to have an > efficient data transfer mechanism from off-chip memory to FSL > co-processors. > > Thanks beforehand, > > Amir > Connect the co-processor directly to the memory controller (mch_* or MPMC2 with XCL pim). However you have to follow the XCL protocol and write your own DMA core. /SivaArticle: 106634
On Wed, 16 Aug 2006 18:07:50 +0200, Kolja Sulimma <news@sulimma.de> wrote: >JDrive should do the job: >http://direct.xilinx.com/bvdocs/appnotes/xapp500.pdf > >You can also check what algorithms openwince supports: >http://openwince.sourceforge.net/jtag/ thanks - looks good. EvanArticle: 106635
Kolja Sulimma schrieb: > Evan Lavelle schrieb: > > Does anyone know of any open-source software which will program an > > XCF04S (Xilinx serial PROM) on JTAG? It also needs to issue a CONFIG > > command to start configuration. > > JDrive should do the job: > http://direct.xilinx.com/bvdocs/appnotes/xapp500.pdf > > You can also check what algorithms openwince supports: > http://openwince.sourceforge.net/jtag/ > > Kolja Sulimma 1) JDrive does not support XCF ASFAIK 2) openwince defenetly does not support XCF the programming specs for XCFxx are not public! it is of course possible to program then from your own apps using your own software AnttiArticle: 106636
Brannon wrote: > I think you may have proposed a great plan. Their prices range from > $125 to $300 for their 672 pin chips (according to their website). > That's still three times what I had been hoping for, but maybe I could > make that work. And it is 25% cheaper than Xilinx. Can I get these > Cyclone II chips for less than that through some other dealer? Glad to be of (self-) service :-) I might be a taker if it has big enough devices (insert my usual plea for lots of RLDRAM II memory). TommyArticle: 106637
Thanks for the comments. I think I phrased my inital post rather awkwardly....In this instance I'm not overly interested in the absolute value of power consumption (i.e. using XPower), but rather I'd like to understand the switching mechanisms which are causing the power consumption in the SRAM. quickwayne@gmail.com wrote: > Probably it is because that on-chip memory are dual port memory, at > least for Xilinx FPGA, and much more power consuming compared to single > port memory. > > I am not sure if the underlying processing technology is a reason as > well because FPGA and SDRAM chip employ different processing > technology. > > Xilinx provides a tool, XPower, to estimate power consumption. Maybe it > is worthy to have a try... > > Wayne > > daniel.larkin@gmail.com wrote: > > All, > > > > A general (and possibly very naive!?) question: for data intensive > > routines (for example functions within image or video processing > > algorithms) power consumption is apparently dominated by the memory > > rather than than the datapath logic (or at least memory power is as > > important). Whilst this seems reasonable if there is off-chip memory > > accesses so theres considerable power lost in the decode logic, > > routing, possible access arbitration, etc,etc). I'm not clear why this > > would be the case for on-chip sram since the routing would seem to be > > minimal and less control logic would be necessary for tiny SRAM memory > > relative to off-chip SDRAM for example?. Is it because that everytime a > > memory location is accessed, its not just the switching in the > > transistors at this memory location thats consuming power, but rather a > > full row/column etc? > > > > As a "hard" example lets say you have 2 single port SRAMs containing > > 256 8-bit words and the data path consists of adding together a value > > from each SRAM every clock cycle. Will power consumption in the > > memories dominate in such a scenario? and why? > > > > I'd be delighted if anyone could elaborate on this or indeed point me > > to some decent links on the topic > > > > thanks > > DanielArticle: 106638
Antti wrote: > Kolja Sulimma schrieb: > > > Evan Lavelle schrieb: > > > Does anyone know of any open-source software which will program an > > > XCF04S (Xilinx serial PROM) on JTAG? It also needs to issue a CONFIG > > > command to start configuration. > > > > JDrive should do the job: > > http://direct.xilinx.com/bvdocs/appnotes/xapp500.pdf > > > > You can also check what algorithms openwince supports: > > http://openwince.sourceforge.net/jtag/ > > > > Kolja Sulimma > > 1) JDrive does not support XCF ASFAIK > 2) openwince defenetly does not support XCF > > the programming specs for XCFxx are not public! This seems rather silly. A real product doesn't have a parallel IV (or any of the other Xilinx hardware) attached, nor does it have iMpact. Indeed, a large number of real soltuions probably don't have a 'standard' OS, yet we want to be able to program the device in-situ **in the field**. I looked around the Xilinx site just now and I admit I can't find a document that states 'to program the XCFxxx, issue a <command>, followed by <data+commands> and read <some status>. Of course, that's not saying much. Although they've got better, the Xilinx site search <understatement> still leaves something to be desired </understatement>. To do that requires the spec for programming the XCF configuration device. I guess I could fairly easily figure it out with a serial analyzer, but it would be nicer if Xilinx simply published the spec. Just think, people would *want* to use it because they can write their own software to program the device in-situ. Of course, that requires thought beyond the NDA boundary ;) Cheers PeteS > it is of course possible to program then from your own apps using your > own software > > AnttiArticle: 106639
PeteS schrieb: > Antti wrote: > > Kolja Sulimma schrieb: > > > > > Evan Lavelle schrieb: > > > > Does anyone know of any open-source software which will program an > > > > XCF04S (Xilinx serial PROM) on JTAG? It also needs to issue a CONFIG > > > > command to start configuration. > > > > > > JDrive should do the job: > > > http://direct.xilinx.com/bvdocs/appnotes/xapp500.pdf > > > > > > You can also check what algorithms openwince supports: > > > http://openwince.sourceforge.net/jtag/ > > > > > > Kolja Sulimma > > > > 1) JDrive does not support XCF ASFAIK > > 2) openwince defenetly does not support XCF > > > > > the programming specs for XCFxx are not public! > > This seems rather silly. A real product doesn't have a parallel IV (or > any of the other Xilinx hardware) attached, nor does it have iMpact. > Indeed, a large number of real soltuions probably don't have a > 'standard' OS, yet we want to be able to program the device in-situ > **in the field**. > > I looked around the Xilinx site just now and I admit I can't find a > document that states 'to program the XCFxxx, issue a <command>, > followed by <data+commands> and read <some status>. Of course, that's > not saying much. Although they've got better, the Xilinx site search > <understatement> still leaves something to be desired > </understatement>. > > To do that requires the spec for programming the XCF configuration > device. I guess I could fairly easily figure it out with a serial > analyzer, but it would be nicer if Xilinx simply published the spec. > Just think, people would *want* to use it because they can write their > own software to program the device in-situ. > > Of course, that requires thought beyond the NDA boundary ;) > > Cheers > > PeteS > > > > > it is of course possible to program then from your own apps using your > > own software > > > > Antti Hi Pete, the amount of RE involved is rather minimal, the most stuff that is not known is relevant to XCFxxP devices only the XCFxxS have less thing to worry about. I have full working custom XCFxxP programming software - and gosht I had real headache getting it working. And dont look and dont ask - the specs are not available under NDA either. Just plain not available. Most of the stuff can be retrived from BSDL file, the rest you can retrive by looking at impact generated SVF - the rest is painful trial and error. Thats the only way todo it as official docs are not obtainable at all. AnttiArticle: 106640
quickwayne@gmail.com wrote: > Probably it is because that on-chip memory are dual port memory, at > least for Xilinx FPGA, and much more power consuming compared to single > port memory. > There is no reason to assume that a dual-port memory uses any more power than a single-port memory (as long as the second port is not being exercised). Dynamic power is almost exclusively in the address decoding structure. Static power consumption is in all transistor cells. I do not think that nebulous speculations belong in this newsgroup. Peter Alfke, XilinxArticle: 106641
Perhaps I am missing something, but I was going to program XCF parts with a XSVF player as described in XAPP058.... /MikhailArticle: 106642
In article <1155685199.857669.180670@74g2000cwt.googlegroups.com>, Brannon <brannonking@yahoo.com> wrote: >So is Xilinx working on another budget-line FPGA? Or are they intending >that small V5 chips replace the Spartan line altogether? What's their >next budget chip with the new LUT structure and when can I look for it? > >According to Xilinx's website, the Spartan-3E line is for gate-centric >uses and goes up to 1.2M gates. Yeah. Huge. > >I just finished a project that uses 4.5M gates (so says the MRP) on >each of eight 2v6000 chips. It's only using 1/3 the block RAM and none >of the MUL blocks on any chip. It only accesses DRAM from one chip. I >want that project on cheap hardware. Is it impossible to make the project use 1.25M gates on each of thirty-two 3S1500 chips? http://www.hyperelliptic.org/tanja/SHARCS/talks06/copa_sharcs.pdf is the sort of hardware that I imagine targetting when contemplating cheap FPGA approaches to problems. TomArticle: 106643
MM schrieb: > Perhaps I am missing something, but I was going to program XCF parts with a > XSVF player as described in XAPP058.... > > > /Mikhail this *MAY* work but have you looked how large is SVF file for XCF32P with verify on !? AnttiArticle: 106644
"Antti" <Antti.Lukats@xilant.com> wrote in message news:1155755995.537746.86650@i42g2000cwa.googlegroups.com... > > this *MAY* work > > but have you looked how large is SVF file for XCF32P with verify on !? No, I haven't :) However, I only need to program XCF08P... So, what's the ratio of svf/bit size-wise? Also, I believe the whole point of xsvf is that it is substantially smaller than svf... So, really the question should be what's the ratio of xsvf/bit?... /MikhailArticle: 106645
Thanks for clearing that up Peter, For others, I found the following link quite useful: https://intranet.insa-toulouse.fr/view/422/content/64bit_ram.html Peter Alfke wrote: > quickwayne@gmail.com wrote: > > Probably it is because that on-chip memory are dual port memory, at > > least for Xilinx FPGA, and much more power consuming compared to single > > port memory. > > > There is no reason to assume that a dual-port memory uses any more > power than a single-port memory (as long as the second port is not > being exercised). > Dynamic power is almost exclusively in the address decoding structure. > Static power consumption is in all transistor cells. > > I do not think that nebulous speculations belong in this newsgroup. > Peter Alfke, XilinxArticle: 106646
logjam wrote: > I'm working on a Power-On-Jump GAL/SPLD for an 8080 machine. I'm > trying to figure out how to write it using Sequence/Present/Next > syntax. I'm not sure if a standard 22v10 GAL can handle what I need. > I can also use a 750 from Atmel that is basically two 22v10s (I guess > this means it has internal pinnodes?) yes. > Here is the required flow. The state machine will have to wait for an > input condition and then respond with an output action. > > Inputs: > RESET > PDBIN > > Outputs: > DI7...0 > CCDSB > > I: RESET LOW > O: DI7...0 output enable > O: CCDSB LOW > I: RESET HIGH (do not necessarily need to wait for) > I: PDBIN HIGH > 0: DI7...0 = C3 > I: PDBIN LOW > I: PDBIN HIGH > O: DI7...0 = 00 > I: PDBIN LOW > I: PDBIN HIGH > O: DI7...0 = FF > I: PDBIN LOW > O: DI7...0 output disable > O: CCDSB HIGH > > Then I would like for the state machine to start waiting for another > reset. > > I tried writing a Sequence/Present routine but the way I wrote it there > were duplicated states. Does anyone have any pointers or suggestions > on how I should attack this problem? if it complains about duplicated states, you need to add some dummy state-bits, to make each state unique. - above you seem to have 5 output choices, so you need 5 states, which is 3 state bits, at a minumum. DI7..0 seem to have no restrictions on value, so cannot be used for state variable saving, but CCDSB can be part of the state engine. So that means >= 2 more bits, and unless you can prune DI7..DI0 to DI6..DI0, you will need to use the ATF750CL, to get enough macrocells. > > I have 8 other inputs that I did not mention. JMP15...8. Once I get > the basic logic down I want to make the last byte sent reflect jumper > settings (DI7...0 = JMP15...8) That needs to be added to your state sequence. -jgArticle: 106647
Dear everyone We are doing DDR interface design with the Xilinx Virtex-4. Actually, it's kind of straight forward, I just want to use MIG 1.5 to generate a module that we want to use. Is that necessary to use Modsim to simulate the design? Can we just use Xilinx ISE to do that job? Since this will cost extra and we are in tight budget. We don't have too much experiences on that. Anyone did that? Thanks, C.Article: 106648
Evan Lavelle <eml@nospam.uk> wrote: >Does anyone know of any open-source software which will program an >XCF04S (Xilinx serial PROM) on JTAG? It also needs to issue a CONFIG >command to start configuration. If you want to use this to make your own on-board programmer I strongly suggest to stay away from writing your own JTAG for programming Xilinx devices. Been there, won't go there again. JDrive looks nice, but it is a huge piece of software. You are probably better off using an SPI compatible flash like the M25P from SGS-Thomson (www.st.com). These are available with memory densities of 128Mb (16 megabytes) while having a very small footprint. In one of my designs I connected Dout from such a flash memory to the Din of an FPGA (thru an AND gate, so not all data is pumped into the fpga). The FPGA is programmed by simply reading the flash memory after activation the program pin. A 200kB configuration takes less than 2 seconds to load using a 6MHz microcontroller without DMA facilities. Another advantage is that you can use the SPI flash memory to store other stuff as well. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106649
"Chao" <ssc3k@yahoo.com> wrote in message news:ebvthe$jcu$1@news.ks.uiuc.edu... > Dear everyone > We are doing DDR interface design with the Xilinx Virtex-4. Actually, > it's kind of straight forward, I just want to use MIG 1.5 to generate a > module that we want to use. Is that necessary to use Modsim to simulate > the design? No, it's not, however it might be useful to do some signal integrity simulation instead... /Mikhail
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