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
homoalteraiensis schrieb: > Impossible in replaying to the newsthread "ModelSim Designer", I'd like > to place my quastion here: > > Is the a free tool to draw state machine with and handle signals in an > graphical environment? > > I agree to the former article where it has been said, that most design > engineers might not use HDl-Designer, but I found it very convenient > for keep the overwiev in design with a large amonunt of signal > interactions. > Hi, you can use XFIG to draw your State Diagramm and convert it with brusey20 to VHDL. http://www.2ub.org/brusey20/ have a nice synthesis EilertArticle: 106601
David Tweed wrote: > PeterC wrote: > > I have two clocks which are relatively synchronous (ie. the > > frequencies are exactly the same because the originate from > > the same master clock), but one of the clocks is shifted in > > phase, and this phase shift is dynamically variable and may > > be up to one whole period. > > > > I need to switch between these two clocks, but without losing > > rising edges. > > In that case, it's impossible, because two edges from the two > clocks can be arbitrarily close together. > > Like other respondents, I too have done telecom applications > that needed hitless switching between streams that are > frequency-locked but not phase-locked. The answer involves > passing at least one of the clock+data streams through an > elastic buffer in order to realign their phase before trying > to do the switching. A 3-bit elastic buffer will allow just > shy of 2 unit intervals of peak-to-peak wander before causing > a hit. > > If this is the sort of thing you need, I can dig up an > implementation for such a buffer that requires about 7 > flip-flops and a handful of gates. > > -- Dave Tweed Thank you to all who replied. Without going into details of the application, I have enough new insight to go on. I did omit some details in my OP relating to the phase difference rate change as well as the range, but the postings have certainly helped me think differently about the issue. Big thanks to Pete S for his courageous stance on Peter A's first reply!Article: 106602
>>>>> "Antti" == Antti <Antti.Lukats@xilant.com> writes: Antti> Hi Antti> V4FX Linux 2.6 by end of Aug 2006 Huh? The V4FX has been nicely supported in the mainline kernel since 2.6.16 (March '06) - And V2P since 2.6.10 (Dec '04). -- Bye, Peter KorsgaardArticle: 106603
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, AmirArticle: 106604
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.
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.
bye Thomas
Article: 106605Austin Lesea <austin@xilinx.com> wrote: >Nico, > >You posted: > >" > datasheets lack important information on how the IOB are grouped > together and the clock distribution limits resulting from that > grouping >" > >Could you be more specific? What is it that you found to be missing? >Which part? Which package? What 'important information'? We spend >quite a bit of time on the IO specifications, I would like to understand >better what you felt is missing. Mostly Spartan 3: - Resource sharing on IOBs, multipliers and blockrams - Internal routing of local IOB clocks (for DDR memory purposes) - Minimum and maximum delays, setup / hold for all elements. Now I have to use the timing analyzer to get these numbers. - Other stuff I don't know about -yet- -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106606
Peter Korsgaard schrieb: > >>>>> "Antti" == Antti <Antti.Lukats@xilant.com> writes: > > Antti> Hi > Antti> V4FX Linux 2.6 by end of Aug 2006 > > Huh? The V4FX has been nicely supported in the mainline kernel since > 2.6.16 (March '06) - And V2P since 2.6.10 (Dec '04). > > -- > Bye, Peter Korsgaard Hi Peter, I am more interested in MicroBlaze uClinux-2.6 (currently the development is stalled on 2.4) Xilinx announcement included both ppclinux and mb-uclinux 2.6 infos so I included both as well. For V4FX I am currently using the "Pauls" environment from Johns website what is ppc-linux 2.4.something(released feb 2006), I was wondering why it was 2.4 and did think there must have been a reason for that (maybe there isnt). I know I should try the v4fx linux without the Pauls setup (then 2.6) but just hasnt had time for that. AnttiArticle: 106607
Xesium schrieb: > Hi guys, > I'm trying to design a very simple system based on Microblaze. I can do > Post Place and Route simulation if I have all my instructions and data > on the BRAMs. However unfortunately the current applications that I'm > trying to run and estimate the power don't fit in the BRAMs so I have > no choice but to put them on external memory. Now the problem that I > have is that I don't know how to estimate the power with XPower if I > have my instructions and data on off-chip memory. I'm not sure but I > doubt it if I can do the same simulation with modelsim if I have my > instructions on off-chip memory. > > Thanks alot beforehand for your comments, > > Amir thumb ballbark estimate for you V4LX25+ext memory (MB soc running) - 2W power dissipation. V4LX15, V4FX a little less, larger devices a little more. Add the current for your custom circuitry (if you can estimate) to that. AnttiArticle: 106608
Xesium schrieb: > 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 FSL buses are not accessible from any of the memory spaces hence the DMA can not have access to them. FSL busses are only accesible via special commands those only under software control. You can however have FSL like access to the memory cores, by connecting your circuitry to the XCL ports of mch_ (multichannel) memory cores. AnttiArticle: 106609
Rene Tschaggelar schrieb: > Nevo wrote: >> I am planning on attaching a green LED to each of the 96 I/O pins >> exposed on the connectors through 390 ohm resistors. > LEDs do not need 20mA, in most cases, 1mA is > clearly visible. Green LED on 3.3V over 390R is more like 3mA, not 20mA. I = (3.3V - 2.1V)/390R < 3.1mA Also: I prefer to connect the positive end of the LED to VCC end pull the other end low by the FPGA. This way the stronger NMOS transistors are used. GTL drivers of Spartan-2 sink 200mA. Kolja SulimmaArticle: 106610
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?) 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? 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) Thanks, GrantArticle: 106611
I have been having the exact same problem today!!! When I click on the 222 error it takes me to answers under the search "Simulator:222" to answers: 23037, 23207, 21451. I translated the answers to say: ISE simulator doesn't work and Xilinx is not going to fix it. I recommend using ModelSim XE (the free Xilinx version), which is on the same download page as the Webpack... at the bottom of the page... hiding. After you download it you have to request a license from ModelSim to use it. They will email it to you in the form of an license.dat file. Good luck. I'll check back for a solution from someone more knowledgeable than I.Article: 106612
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: 106613
Brannon wrote:
>>Unless there are specific reasons why you need the 3E, the plain '3' go
>>up to ~5M gates but even that still costs way more than $40/chip: I
>>checked out prices on avnet, XC3S5000-4FG1156C = $390 each.
>>
>>
>
>The series 3 are .13 micron, true? Is that why they're (debateably)
>expensive?
>
>
>
spartan3 (and s3E) is 90 nm
Aurash
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 106614Hi everyone, I have a Problem that's equal to that discussed in January this year (PPC Memory Management, 27. January 2006) in this group: 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. 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. I assume that this has something to do with the set up time of the PowerPC and the SDRAM. Does anybody know a solution to get the PowerPC oder SDRAM wait for initialization until the program is executed? I use the EDK 8.1i. Regards, PeterArticle: 106615
> 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
> 0 0001 1011 1111
> 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.
Hi Thomas,
First of all thanks for taking out time and replying to my query...
Seconly what is the meaning of a "weak" '0'' as the flops share a
common supply rail ?
If you mean the metastability due to reset removal then I can agree
that the shift register will enter an unknown random pattern after the
metastability resolution time has expired and the reset to the device
will be deasserted only when all the flops reach a '1' state.
In the event that any of the register bits settle to '1' then the specs
fail in both the implementations for reset release time of four clock
periods.
Is there any way that still meets the specs even if there is
metastability ...
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.
> 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.
>
> bye Thomas
Article: 106616On 15 Aug 2006 16:36:48 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >> 3. What is the thermal distribution profile? There is core, and there >> is I/O. Each has their own effect on the die, but it may well be >> important to me to know that profile (it has been in the past). >I personally think that this is a secondary effect, given the thermal >properties of silicon. Just my opinion. This is getting to be quite a big area; see Gradient/Firebolt (http://www.gradient-da.com/), Apache/Sahara (http://www.apache-da.com/html/products_solutions/sahara.htm#CHALLENGE), and so on. The spin is that you have to control for temperature distribution across your chip at sub-90nm. You've got an interesting problem here, since you don't know how your chips are going to be used. EvanArticle: 106617
Has anyone tried Ultracontroller PROM solution of V4 in EDK 8.1i? The reference example is built by EDK 7.1i. I went through the flow again in ISE 8.1 SP3 + EDK 8.1i SP2. However, the resultant MCS can't program the XC4VFX12 properly (DONE LED didn't go high). After I got the reference, I only added the -nostartfiles compiler option to fix the multiple _start problem. Regards, louisArticle: 106618
Brannon wrote: >> Unless there are specific reasons why you need the 3E, the plain '3' go >> up to ~5M gates but even that still costs way more than $40/chip: I >> checked out prices on avnet, XC3S5000-4FG1156C = $390 each. > > The series 3 are .13 micron, true? Is that why they're (debateably) > expensive? IIRC, the 3E is the 'Economy' series, the 3L is the 'Low-Power' series and plain 3 is standard parts. Like others said, they all are 90nm. BTW, if you are really wasting BRAMs, you could tell your synthesis tools to map logic into BRAM. If the older Vxxxx have anywhere near the V2P's BRAM-to-logic ratio, this would free up a bunch of LUT/FFs. Me, I am holding my breath until the V5SXes come out - I am hoping for 12xRocketIO for the price of 8 on V4.Article: 106619
> 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! MartinArticle: 106620
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: 106621
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. Thanks - EvanArticle: 106622
Nico, Thank you. Steve Knapp reads this newsgroup for the Spartan division, and I am sure he will appreciate your comments. I am part of the Virtex team, so as these may also apply there, I will make sure the data sheet folks get this feedback, also. I know that we cover quite a bit of what you listed in our user guides: V4 - http://direct.xilinx.com/bvdocs/userguides/ug070.pdf V5 - http://direct.xilinx.com/bvdocs/userguides/ug190.pdf Since Spartan 3 does not have a users guide, perhaps this is part of the problem? 3E also does not have a users guide. Not sure why that division didn't do user's guides; they are a separate business group, and they need to make their customers happy, just as we do. Thanks for the constructive feedback, Austin Nico Coesel wrote: > Austin Lesea <austin@xilinx.com> wrote: > >> Nico, >> >> You posted: >> >> " >> datasheets lack important information on how the IOB are grouped >> together and the clock distribution limits resulting from that >> grouping >> " >> >> Could you be more specific? What is it that you found to be missing? >> Which part? Which package? What 'important information'? We spend >> quite a bit of time on the IO specifications, I would like to understand >> better what you felt is missing. > > Mostly Spartan 3: > - Resource sharing on IOBs, multipliers and blockrams > - Internal routing of local IOB clocks (for DDR memory purposes) > - Minimum and maximum delays, setup / hold for all elements. Now I > have to use the timing analyzer to get these numbers. > - Other stuff I don't know about -yet- >Article: 106623
sutejok@gmail.com wrote: > 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 The MCS file appears to be Intel Hex (IHX) formatted. The "breaking point" line changes the upper 16-bit address from 0000h to 0001h. So the next line (:100000005601...) starts at 00010000h and not 00000000h. Perhaps the S3 board doesn't handle downloads greater than 64K properly? This link explains the IHX format: http://www.google.com/url?sa=t&ct=res&cd=3&url=http%3A%2F%2Fwww.keil.com%2Fsupport%2Fdocs%2F1584.htm&ei=XSzjRM7VJLf8aOurqbQF&sig2=s1WFWioJtszSj0El_yn2Pg Dave PollumArticle: 106624
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, -- Peter
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